[feature request] add tags on sent messages

[xunam]

Hello,

It would be useful to have an option to specify tags to apply on composed messages.

In the case of new threads, unless I'm missing something, the only option to tag the message is to make a query to find sent messages and tag the most recent one, which is tedious and discards the current search view.

In the case of replies, we see the message right after it is sent, so the query is not necessary. But in this case, inheriting by default the tags of the message that we reply to would make sense (of course ignoring tags that are inherently message-specific, like unread, signed and so on).

[wangp]

I've added tag.tag_sent_message and tag.tag_replied_message options on the tag-sent-replied branch.

As for inheriting tags, I'm not sure how it would be used. I'm wondering if the set of inheritable tags should be explicitly specified:

[tag]
    inherit_tags_on_reply = blah blah2

or perhaps something more flexible (only if required).

[xunam]

Thanks for your quick reaction.

I realize that I was not clear about the feature I had in mind. What I meant was to add something to specify tags for each composed message independently, at the time of composing. That could be something interactive in the envelope view, like for attachments.

As for inheritance, I feel it makes more sense to list tags that should not be inherited.

But this is all probably specific to each user's habits and workflow. I use most tags as thematic "folders" (which often makes queries more efficient than plain text search) and find it sensible to tag messages I write according to the themes they refer to. Maybe some people have very different usage patterns.

[wangp]

I did a quick implementation of interactive tag editing on the compose screen. Some questions to think about before I commit to it.

[xunam]

Nice, I will try to use this branch to get an idea.

My personal opinions on these questions, as taken from the commit message:

 - uses +tag -tag syntax to leverage existing tag completion code
   but only keeps the +tags

Makes sense and keeps the interface consistent with tagging in other views.

Besides, since sent messages go through notmuch insert, which has a post-insert hook that allows for initial tagging, there might be some cases where one would want to explicitly disable tags that the hook might have added.

 - should tag.tag_sent_message populate the initial tag set,
   rather instead of being in addition to the interactive tag set?

Indeed it would probably make sense as a default value (although I don' see myself using regularly). Maybe include sent there ?

 - should tag.tag_sent_message take a list of tags instead of tag
   operations. I'm not sure why -unread was in that list in the first
   place.

Tag operations would more consistent, in particular with the UI choice above.

 - Maybe drop tag.tag_sent_message and tag.tag_replied_message?
   There's not a strong reason to make them configurable.

I don't see a strong reason either, but usage patterns may vary.

 - Should we store tags for postponed messages somewhere?
   As tags on the draft message (seems dubious)
   or in a special header (which we never do yet?)

Tagging the draft message does not seem dubious to me, it might even be useful on occasion.

Using special headers might have unexpected consequences (although I don't know which) and departs from Notmuch's principle of never modifying messages.

[wangp]

New branch tag-on-compose:

• I decided to drop the tag.tag_sent_message and tag.tag_replied_message config options.

• Tag editing operations now assume + on words without a +- prefix. Tag completion works on words without a prefix.

• The compose screen has a list of extra tags to apply (sent is implied). While technically the prompt takes a list of tag operations, you can just enter a list of tags since unprefixed words are equivalent to +tag. And typing -tag can be easier than manually deleting a tag.

• Postponing a message doesn't apply the set of tags yet.

[xunam]

Ok, I am trying this branch now, it looks nice and appropriately simple.

I find myself mostly using this feature for composed messages that start a new thread, because my notmuch hooks already do the work for replies most of the time.

[wangp]

Updated the branch:

• Tags are saved and restored on draft messages.
• Replies inherit tags from the message being replied to (except for a hardcoded set). Same for forwards and the edit-as-new function.

[xunam]

After a few days trying, I think this works fine. At least, it is enough for my use.

But now I miss the features from the thread-view-only-matched branch… Apparently it rebases on onto tag-on-compose with minor adjustments. I'm trying now the mix of the two.

[wangp]

Merged to master. Thanks for testing.