From: Matt Armstrong <marmstrong@google.com>
To: Jani Nikula <jani@nikula.org>, Carl Worth <cworth@cworth.org>,
notmuch@notmuchmail.org
Subject: Re: notmuch.el: controlling what does and doesn't get expanded in searches
Date: Thu, 15 Sep 2016 23:32:25 -0700 [thread overview]
Message-ID: <qf5poo4fj7q.fsf@marmstrong-linux.kir.corp.google.com> (raw)
In-Reply-To: <87zios9s4z.fsf@nikula.org>
Jani Nikula <jani@nikula.org> writes:
> On Thu, 04 Aug 2016, Carl Worth <cworth@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@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.
next prev parent reply other threads:[~2016-09-16 6:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-04 15:54 notmuch.el: controlling what does and doesn't get expanded in searches Matt Armstrong
2016-08-04 16:17 ` Jani Nikula
2016-08-04 17:12 ` Matt Armstrong
2016-08-04 19:44 ` Carl Worth
2016-08-04 20:49 ` Jani Nikula
2016-09-16 6:32 ` Matt Armstrong [this message]
2017-09-28 12:16 ` Jan Malakhovski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=qf5poo4fj7q.fsf@marmstrong-linux.kir.corp.google.com \
--to=marmstrong@google.com \
--cc=cworth@cworth.org \
--cc=jani@nikula.org \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).