Cycle-expand all org-style in show-mode and search all
Is it possible to cycle-expand-all subtrees in show-mode, à-la Org?
Related: is it possible to search the entire conversation, even when
messages are folded? If not, the workaround would be to temporarily
expand-all (once the above feature is implemented), and search from
With the point on message 2, have a `notmuch-show-open-or-close'
function that opens/closes all message beneath Message 2 (included), but
does not touch the expansion of Message 1, 5, 6 or 7.
> M-RET should open all of the messages in the thread, but it doesn't do
> anything about regions that are hidden within messages due to washing.
Somehow I had misded M-RET... :p Thanks!
>> Related: is it possible to search the entire conversation, even when
>> messages are folded?
>> If not, the workaround would be to temporarily expand-all (once the
>> above feature is implemented), and search from there.
> You might also be able to do something with isearch-open-invisible
> properties on the overlay used to fold messages.
I found a bunch of variables, none of which is documented:
Re: Cycle-expand all org-style in show-mode and search all
On Wednesday, 2019-04-03 at 13:24:28 +02, Pierre Neidhardt wrote:
>>> Related: is it possible to search the entire conversation, even when
>>> messages are folded?
>>> If not, the workaround would be to temporarily expand-all (once the
>>> above feature is implemented), and search from there.
>> You might also be able to do something with isearch-open-invisible
>> properties on the overlay used to fold messages.
> I found a bunch of variables, none of which is documented:
> - isearch-open-overlay-temporary
> - isearch-open-necessary-overlays
> - outline-isearch-open-invisible
> - outline-isearch-open-invisible-function
sorry for the delay in responding here, i'd missed this proposal when it
I *think* what you're trying to do here is, when reading a thread in
emacs' notmuch-show mode, you want to use "C-s" (I-search?) to find
whatever you're searching for in the folded messages as well as the
expanded ones. Is that right? do you always want to search in the
folded messages, or only sometimes?
In my own use of notmuch-emacs, i confess i've appreciated only
searching in expanded messages sometimes, and resented having to use
M-RET to expand-all before searching other times. I don't know whether
i'd prefer one or the other in any given situation, and i guess i'd like
to be able to switch between them, but i'm not sure how to do that in a
On Wed 2019-04-10 12:33:23 +0200, Pierre Neidhardt wrote:
> The attached patch seems to work.
> What do you think?
I don't think i understand well enough what this change is trying to do,
even from reading the thread. And the commit message itself is
*definitely* not enough to understand what the intent of the patch is.
It certainly doesn't seem to be related to the thread's subject line
"cycle-expand all org-style in show-mode and search all".
We generally try to make notmuch commit messages contain enough
motivation that when you go back and read it a year later you can tell
what you were trying to do here. (some of us are very forgetful!)
You don't need to copy the entire upstream emacs documentation for
invisible text or anything, but it'd be good to have the commit message
explain the problem encountered, and at least point at the mechanism the
patch is using to try to fix it. Ideally, it should put a little bit of
thought into similar scenarios that it is *not* trying to change, so
that we can tell that it's scoped correctly.
One way to legitimately cut down on the length of the commit message
(and to ensure that your fix doesn't itself get broken later) is to
include a change to the test suite in your commit. A good addition to
the test suite shows a plausible series of actions, and documents what
the correct output *should* be. (even better if the use case is broken
before your patch, and fixed afterward!)
So anyway, could you take a stab at regenerate the
(as an aside, i note that you signed your e-mail to the list, but the
patch appears to be outside the cryptographic signature. Is seems
suboptimal -- you'd surely like us to evaluate your signature over the
message *including* the patch. how was this message generated? if it
was in notmuch-emacs, can you help me to recreate the steps you took so
that maybe we can fix it up or at least document it as a dangerous