Ability to mark/hide declined events

[WhyNotHugo]

I currently have some work events which I've declined, and are indistinguishable from accepted events.

I'd like to somehow mark (an icon similar to recurring events), hide, stike-through (this is my first choice, but very few terminals support it, including my own) or dim (eg: slightly darker colour) events which I've declined.

As far as I understand, this also requires khal to know my email[s] (because that's how attendees are identified).

IMHO, dimming or some special character to recognize these are the best choices.

[geier]

Good idea, once khal know about your emails, it can also answer(RSVP) and send them (invite).

I have actually yesterday implemented something similar for STATUS=CANCELLED events, which for now are displayed with a big, fat CANCELLED in front, which is indeed very ugly.

Your suggestions

• strikethrough: I like this best, and my terminal supports this, but tmux which I often use to run khal etc in does not (and it looks like they are not interested to), so this is probably out (to test run echo -e "\e[9mstrikethrough\e[0m" )

• dimmed: I find dimmed (dark gray for dark background, light gray for light background) problematic, because it often leads to me not being able to read that part, than I need more attention to actually read it (which kind of defeats the purpose). But perhaps I would just get used to ignoring unreadable stuff in khal.

• symbol:

  1. do you have a suggestion for a symbol?
  2. is that noticable enough? (also for cancelled events)

[geier]

An alternative to ANSI codes for strikethrough would be unicode strikethrough.

Seems to work for me:

In [1]: STRIKE = '\u0336'

In [2]: def strikethrough(string):
   ...:     new = list()
   ...:     for char in string:
   ...:         new.append(STRIKE)
   ...:         new.append(char)
   ...:     return ''.join(new)
   ...: 

In [3]: print(strikethrough('strikken'))
s̶t̶r̶i̶k̶k̶e̶n

[geier]

font support for that method is only so and so:

DejaVu Sans Mono:

M+1mn:

Iosevka:

all three images are tmux 2.3 + gnome terminal 3.18.1 on FreeBSD 11.0, Iosevka and M+1mn are installed by hand, the former is up to date, the latter might need to be updated.

[untitaker]

I think ANSI escape codes are they way to go despite tmux. I wasn't able to find a terminal on Linux that doesn't support strikethrough.

[geier]

Feel free to add more information to this list

Terminal emulators etc. supporting ANSI strikethrough:

• probably everything based on libvte (tested gnome terminal)
• xterm
• terminology
• st
• tmux (as of 9c0520f, but needs to be enabled)

not supporting:

• urvxt
• screen
• alacritty
• urwid

[WhyNotHugo]

Since, personally, I use tmux, I'm really inclined towards a different choice. Strikethrough+symbol might be the best idea since the symbol itself helps differentiate cancelled vs declined.

I'll leave these symbols here for consideration:

⊗⊘ ⊜⊖ ⊝ ⛔ ꚛ ⏹▣ ■ ⯀x × X ✕ ☓ ✖ ✗ ✘

I think the x marks (eg: ✖) make the most sense for declined events, and the first one for cancelled (⊗). This is really subjective though.

(I basically scrolled the entire unicode symbols table).

[WhyNotHugo]

While we're talking symbols, we also have the "invited but not accepted" status (NEEDS-ACTION?), which might be worth differentiating from accepted (or "created by me") events.

[geier]

Problem with (only using) ANSI strikethrough is, that it gets removed if stdout is not a terminal.

[geier]

urwid doesn't seem to support strikethrough either
https://github.com/urwid/urwid/blob/dc8e8b3fdb0bed9fe6cf8781b4c0b1396b7d406f/urwid/display_common.py

[geier]

After tmux, urwid is the most important part to get working now before we can use strikethrough, because I really want to avoid the situation where khal's and ikhal's output look qualitatively different.

[WhyNotHugo]

I'd kinda like to bring this issue back to life.

I've been thinking about a configuration option to HIDE declined events altogether (since I've way to many laying around in my work calendar). Do you think that might be acceptable (regardless of any decoration added to them when not-hidden)?

[geier]

Sure, go ahead. If you need any help, feel free to contact me.

[ariep]

Sorry to add to this old thread, but it appears tmux now supports this out of the box. At least on my system, the echo -e "\e[9mstrikethrough\e[0m" test works under tmux without special configuration.

[madduck]

Is there a chance of this getttting implemented? Whether struck out or prepended with a symbol, that can be made configurable later, no?

[geier]

Can you send some examples of what we are looking for? (Sorry, this issue is ancient, I have forgotten most of the details)

Are we talking about:
ATTENDEE;PARTSTAT=DECLINED:mailto:[email protected]? Do we want to mark events with the user's mail addresses ? (If so, we will need to collect them in the configuration file)

[geier]

btw: urwid now supports strikethrough, but I'd first go with an icon, as it is easier to implement.

[madduck]

Thanks for your response, Chris!

Yes, ATTENDEE;PARTSTAT=DECLINED:mailto:[email protected] matching against one of the known email addresses. That is the one use case;

The other use case is an event with STATUS:CANCELLED. Also see #587, though I think that DECLINED/CANCELLED are the most important. Just something to keep in mind: there are other statuses as well which might benefit from being exposed.

[geier]

Note to self: We do support "status" already, that is, we can print it in the calendar representation. We could

• print some kind of symbols instead (similar to recurrence symbols)
• make those toggle-able from ikhal

But I'm not sure how STATUS interacts with PARTSTAT. Especially the interface in ikhal is already quite overloaded.

[geier]

@madduck could you have a look if you had something like #1271 in mind? For now, no strikethrough, just symbols. Also no way to modify, but showing status and partstat as symbols.

[madduck]

@madduck could you have a look if you had something like #1271 in mind? For now, no strikethrough, just symbols. Also no way to modify, but showing status and partstat as symbols.

Sorry, took me a bit longer. It works as you had intended it, and that's great. Thank you for that!

A couple of thoughts:

1. Any reason to use ❔ instead of ?
2. Please don't include a leading space (see Better support for status and initial support for partstat #1271 (review))
3. Being able to use terminal control sequences to yield italics and strikethrough, similar to how {calendar_colour} works, would be awesome.
4. Being able to provide a list of addresses, or even have the addresses read from a separate file or files would make this really scalable.

[geier]

Thanks for testing @madduck!

1. no reason really, I'm currently trying out CoPilot for my private coding and it suggested ❔, but will change to ?
2. will fix
3. are you thinking of something you would configure in your khal config? e.g. [colors] declined = strikethrough? If so, I would like to handle it differently, I want to expose color theming to the config anyway (because the supplied ones suck for most people) and then create a new attribute for the status and partstat. Those could then be themed. We would need to think about which one should take precedent if both of them are defined.
4. I actually had a list of addresses first, but then I thought we could use this as a stepping stone for getting invitations to work properly and there the (at least easiest) approach would be to have one mail setting per calendar. What would be your use case of several mail addresses per calendar?

[madduck]

Thank you for your response, @geier!

1. Thanks. I think the default should be as simple as possible. Maybe this can be themed later.
2. Thank you!
3. Theming would of course be best. Maybe irssi can serve as an inspiration, though there's probably a more modern approach. I don't mind having a default colour per calendar, which becomes the default colour (style) for each event from the calendar, and then I think there ought to be a number of conditions that can override the style for each event. To me, that is tentative/cancelled/confirmed and I cannot really think of anything else, though there are two classes, namely whether an event is marked tentative/… or whether my own attendance is marked tentative/…. There's a bit more complicated interplay here, namely if an event is cancelled, my own attendance does not matter. If the event is tentative, I think that should take precedence over whether I've confirmed, and if I cancelled, then I want to see somehow that it's taking place, but that I am not there.
4. I have a dozen addresses (for roles) and one calendar because of the silly physical principle that I cannot be in two places at once. So I will get invitations to [email protected] and [email protected]…