Hi Pierre--

sorry for the delay in responding here, i'd missed this proposal when it
came in!

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
user-friendly way.

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
path?)

        --dkg