Re: [PATCH v2 0/4] Add refresh all buffers functionality

[Mark Walters <markwalters1009@gmail.com>]

On Sun, 25 Sep 2016, Ioan-Adrian Ratiu <adi@adirat.com> wrote:
> On Sat, 24 Sep 2016, David Bremner <david@tethera.net> wrote:
>> Ioan-Adrian Ratiu <adi@adirat.com> writes:
>>
>>> On Sat, 24 Sep 2016, Ioan-Adrian Ratiu <adi@adirat.com> wrote:
>>>> Argh, so right after I posted this I found a bug: for every new window
>>>> in which you open the same notmuch-show buffer it creates a new buffer.
>>>>
>>>> For example if from notmuch-search you open a thread "hello" in multiple
>>>> windows, each window will show a different "hello<1>" "hello<2>" etc
>>>> buffer instead of showing a single "hello" buffer for all windows.
>>>
>>> This is really weird. I'm experiencing this bug even without my patches
>>> so it's not a fault in my code. I've tried with both emacs 25.1 and the
>>> latest emacs git rev, does anyone else experience this behaviour?
>>>
>>> Am I missing something, is this an expected behaviour and not a bug?
>>
>> I don't (yet) have an opinion on whether this is a bug, but I can
>> confirm the behaviour exists, e.g. using devel/try-emacs-mua -Q in emacs 24.5.1
>
> It's caused by the generate-new-buffer-name call in notmuch-show(), it's
> been there since cca 2010 by 9bee20aed (notmuch.el: Make notmuch-show
> buffer name first subject...)
>
> I don't quite understand why generate-new-buffer-name is called at all
> there. What's wrong with the existing buffer names and why do we want
> to create others? :)

Hi

I think this behaviour is expected in the sense that this is what the
code has always done. It could be that the current behaviour made more
sense before dme's commit 30f1c43e which made q only kill the current
buffer if it was the only copy.

If I understand this code correctly the buffer gets the name the subject
of the thread. Obviously we can't reuse (i.e. overwrite/kill) a buffer
just because it has the same subject as the new thread so some
care would be needed.

Plausibly we could reuse the existing buffer it was for the same
thread. However, there are some things to consider before doing this
since a notmuch-show buffer does have a fair amount of internal state,
some of which could be lost if it is refreshed, and some of which could
linger into the new buffer and be confusing.

For example:

1) tags deleted or added since the last refresh are shown in the show
buffer (red strikethough, green underline by default) and these visual
cues would be lost (the tag changes have already happened so that is
fine)

2) Which messages are collapsed or expanded. Notmuch normally attempts
to keep this the same when the buffer is refreshed (see
notmuch-show-capture-state and notmuch-show-apply-state). Keeping the
old state would be confusing as some matching messages might not be
expanded, but removing the old state could lose information.

I am definitely not saying that we don't want to change to just allowing
one show buffer for a particular search -- indeed the above two are
probably pretty trivial -- but I think they, and other similar
things, should be thought about first.

Best wishes

Mark