notmuch.el: controlling what does and doesn't get expanded in searches

[Matt Armstrong]

Jani Nikula <jani at nikula.org> writes:

> On Thu, 04 Aug 2016, Carl Worth <cworth at cworth.org> wrote:
>>>  i) notmuch could have an "also expand tags" feature, where thread based
>>>     results would auto expand matching tags.  I would set this to
>>>     "unread".
>>
>> This approach makes a lot of sense to me based on how notmuch.el works.
>
> My idea on how to do this: I'd like to have a key binding in the show
> view to go through a customizable list of rules on how to
> collapse/expand the messages. The rules could be:
>
> * [ ] expand all matching messages
>   [ ] expand messages having any of the specified tags
>   [ ] expand messages having all of the specified tags
> * expand all messages
> * collapse all messages
>
> (* are mutually exclusive, [ ] are not)
>
> The first rule would define what is displayed by default. So you could
> have, for example, "expand all matching messages and any messages that
> have both inbox and unread tags", followed by "expand all matching
> messages", followed by "expand messages that have inbox tag", followed
> by "expand all messages", etc. any way you wish.
>
> It would be a nice bonus if you could specify at which rule to start per
> each saved search, instead of the first in the list.
>
> I think this could replace the current M-RET and C-u M-RET
> expand/collapse all bindings. Maybe M-RET could be reused for this.
>
> This would obviously not require any changes to the SPC, n, p or other
> navigation bindings, which I think are currently just fine.

I've begun a WIP patch series for this at
id:1474003701-19831-1-git-send-email-marmstrong at google.com under subject
"emacs: show: expand unread tags"

Jani, compared to your idea what I have is very simple.  notmuch-show
retains just the two modes when initially displaying a thread,
controlled by notmuch-show-elide-non-matching-messages.  This is usually
toggled with a prefix arg to RET (e.g. the command that shows a thread).

It employs a search you didn't include explicitly in your list:

* [ ] expand all matching messages and all messages having
      any of the specified flags.

I find it quite useful.

As for your proposal, I'll respond to each:

> * [ ] expand all matching messages

Agreed.  This is the default today.

>   [ ] expand messages having any of the specified tags

See above: I think it makes sense to expand the both the matching
messages and those matching the additional expansion tags
(e.g. tag:unread).

>   [ ] expand messages having all of the specified tags

In the context of a configuration for notmuch-search-messages, this
feels overly flexible.  You could just as well include the required tags
in the original query.  It may make sense as a global default?

I call this out because I think as soon as the feature allows expressing
both a tag conjunction (sequence of AND) and tag disjunction (OR), I
begin to wonder why we don't just ask the user to supply a query.

Perhaps you had a use case in mind?

> * expand all messages
> * collapse all messages

Agreed. These are available today.