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

[Tomi Ollila]

On Sun, Sep 25 2016, Mark Walters <markwalters1009 at gmail.com> wrote:

> On Sun, 25 Sep 2016, Ioan-Adrian Ratiu <adi at adirat.com> wrote:
>> On Sat, 24 Sep 2016, David Bremner <david at tethera.net> wrote:
>>> Ioan-Adrian Ratiu <adi at adirat.com> writes:
>>>
>>>> On Sat, 24 Sep 2016, Ioan-Adrian Ratiu <adi at 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.

I have 2 quick (drive-by-;) comments...

1) could we include thread in in the generated subject and how much would
that helo

2) then, minor commit message related comment: if there is going to be v3,
in id:20160924200735.25425-2-adi at adirat.com adi mentioned 'next patches'
-- those are not patches (anymore) when commits are made, so it would be
better to reword that sentence. If anythine else doesn't come up, simplest
thing is to change the word to 'commits'. As said, this is minor thing,
and we have worse things in commit messages; if there is no need to send
v3, or the message change is forgotten then it may go in as it is now...


Tomi


>
> 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
>
>
>
> _______________________________________________
> notmuch mailing list
> notmuch at notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch