Trash threads in index and view modes #589
Conversation
|
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:
1) 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.
2) 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 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 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
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. |
src/modes/thread_view/thread_view.cc
Outdated
| @@ -1385,6 +1385,20 @@ namespace Astroid { | |||
| return true; | |||
| }); | |||
|
|
|||
| keys.register_key (Key (GDK_KEY_BackSpace), | |||
There was a problem hiding this comment.
Why is it sometimes Backspace and sometimes Delete? Should always be the same I think. I think that we can use d
There was a problem hiding this comment.
I will look again but I believe d is already taken in the default keybindings for one of the modes.
|
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 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 |
|
@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.
|
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).