astroid
astroid copied to clipboard
Trash threads in index and view modes
Just added the ability to trash threads (toggle 'trash' tag) in index and view modes.
Added potential keybindings following the pattern for archiving threads (which I consider to be the closest action in nature) but left most unbound because it looked a bit overkill and didn't want to take over all remaining keys. In the only few places where I bound a key, I used GDK_KEY_Delete (as "d" and "t" were already taken).
Esteban Sancho writes on October 29, 2018 2:49:
Just added the ability to trash threads (toggle 'trash' tag) in index and view modes.
Added potential keybindings following the pattern for archiving threads (which I consider to be the closest action in nature) but left most unbound because it looked a bit overkill and didn't want to take over all remaining keys. In the only few places where I bound a key, I used GDK_KEY_Delete (as "d" and "t" were already taken).
Thank you, the code looks good. I have hesitated with this functionality previously for two reasons:
-
Notmuch is based around the concept of never deleting or modifying your actual mail. Just the tag metadata. So you would never delete mail, just archive it. I do realize that sometimes messages should just be gotten rid of though.
-
You can fairly easyily achieve the same by using a hook attached to an appropriate keybinding.
Additionally, it might be a bit confusing with a 'Trash' action since we are not actually deleting any e-mail (nor do I think that we should).
Is this tag part of the default exclude tags in notmuch? Or are there any? I can't remember. Is this the tag that maps to the maildir flag when synchronize_maildir_flags is on in notmuch?
I am not convinced about merging this yet. Do you have any thoughts about this? Or does anyone else have any opinions?
Regards, Gaute
Since you asked for others' experiences: I personally also use the tag del
to move things to the trash bin after the next run of poll.sh and a custom script which takes care of moving mails based on their tags.
The same applies to the spam tag which I also use frequently, and for which there is already a built-in keybinding (which I changed).
Obviously, the del
and spam
tags are excluded tags within notmuch.
For actually deleting single emails within threads, for example vacation auto-replies, I use a hook.
I'm not using the archive tag at all so I can't say anything about its usage in astroid or notmuch.
To me, it's almost the same concept as archiving (removing the "inbox" tag). It would work out of the box with some servers (like Gmail) but will need some wrangling with others (Office365, anyone?). For the second case, it would at least mark the threads so something else (like alot) can pick them up.
I don't think all functionality can be implemented right now via hooks. For example
- Delete and close in thread_view mode
- Toggling ("t") multiple threads in thread_index mode and deleting them together.
If we want to be on the safer side, we can leave all actions with unbound keys and document for those who want the feature. Probably no one would use Delete or BackSpace for this anyway ("d" is much more appealing) so they will need to config keybindings anyway.
@e11o What's the state of the PR ? @gauteh proposed changes to your PR, can you please consider them so we can merge this ?
Sorry that I totally dropped the ball here but I will complete the PR now. There's a case that doesn't work as expected though.
Previously trashed threads will appear again in the thread index when a new email is added to the thread. This is desired behavior.
But I would expect thrashing would just trash the thread again but, as it's implemented using a ToggleAction, it will actually delete the existing trash tag. You need to trash twice to delete the thread.
On the other hand, there might be a valid use case for removing the trash tag in thread index mode. As trash would typically be added to search.exclude_tags in notmuch, this use case would be when searching explicitly with tag:trash. Restoring emails is probably the most common scenario.
So it seems like the action in thread_index needs to be contextual and never a toggle. If tag:trash is present in the search string then it should remove the trash tag. If tag:trash is not present then it should remove and add the tag again?
@gauteh Does that make sense? Is it possible to know tags in the search string when executing an action?
Would it make sense to:
if all messages has trash: untrash if some, but not all, or none has trash: trash
this seems to give the same behavior, and I think would be more deterministic.
I like it better, yes.
Alternatively, could use a binding for sending to trash and another for restoring. Both would be no-op in case there's nothing to trash or restore.
Would be more explicit but requires 2 bindings...
@gauteh I updated the key bindings to use "d". Had to also use Delete for one particular case.
Regarding the if all messages has trash: untrash
approach, I originally thought you were refering to "all selected messages" but that wouldn't resolve the problem.
Now I believe you were referring to check all threads in the list store. Wouldn't that be very inefficient for a large result set?
@gauteh Lets get this merged soon please, waiting for this feature ! Thanks !
Esteban Sancho writes on April 18, 2020 23:16:
@gauteh I updated the key bindings to use "d". Had to also use Delete for one particular case.
Regarding the
if all messages has trash: untrash
approach, I originally thought you were refering to "all selected messages" but that wouldn't resolve the problem. Now I believe you were referring to check all threads in the list store. Wouldn't that be very inefficient for a large result set?
I meant to check all the messages of a thread, not threads in the
thread-index. So if a thread is trashed, but has a new untrashed
message appended this will cause the new message to get trash
tag
added -> causing the entire thread to be trashed. Otherwise, if all
messages have trash
tag: untrash thread (i.e. remove trash from all
messages). Notmuch does not store tags on threads, but on messages. That
way you are not dependent on the particular query you are in.