bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#59862: quit-restore per window buffer


From: martin rudalics
Subject: bug#59862: quit-restore per window buffer
Date: Mon, 3 Jun 2024 11:34:33 +0200
User-agent: Mozilla Thunderbird

> Martin, do you agree with this?  I tested this patch for a long time.
>
>> 1. C-x 4 d RET C-h C-t q q         -- the bottom window is NOT deleted
>> 2. C-x 4 d RET C-h C-t C-x k RET q -- the bottom window is deleted
>> 3. C-x 4 d RET C-h C-n C-x k RET q -- the bottom window is NOT deleted
>>
>> The accidental difference between the last two is that the former uses
>> `switch-to-buffer' whereas the latter uses `pop-to-buffer-same-window'.

'switch-to-buffer' leaves the 'quit-restore' parameter the way it was
set up by C-x 4 d.  'pop-to-buffer-same-window' changes it to the
'reuse' type.  So one fix is to have 'switch-to-buffer' record the
window when it does not obey display actions and it gets the 'reuse'
type as well.  This way there are no more accidental differences when
quitting the help buffer.

>> The root of the problem is that displaying a buffer in an existing
>> window, or quitting a buffer in an existing window overwrites its
>> window parameter `quit-restore', and thus invalidates the history of
>> how the first window was displayed.

We could fix the former in 'display-buffer-record-window' by having it
not overwrite an existing 'quit-restore' parameter when it displays
another buffer.  Then 'quit-window' would always delete the window in
the scenarios above instead of showing the dir buffer.  The backside is
that additional information recorded by 'display-buffer-record-window'
like the now selected window or window sizes would no more get recorded.

>> A partial fix that solves only the first test case above is at least
>> not to overwrite `quit-restore' on quitting other buffers in the same
>> window:

You cannot simply fix the third test in 'quit-restore-window' alone
because C-x k leaves the 'quit-restore' parameter of the NEWS buffer
unchanged.  That's arguably a bug: When killing buffers and in some
other cases we should remove the 'quit-restore' parameter.

>> diff --git a/lisp/window.el b/lisp/window.el
>> index a11293d372a..e3b057599d5 100644
>> --- a/lisp/window.el
>> +++ b/lisp/window.el
>> @@ -5275,14 +5276,14 @@ quit-restore-window
>>        (set-window-prev-buffers
>>         window (append (window-prev-buffers window) (list entry))))
>>         ;; Reset the quit-restore parameter.
>> -      (set-window-parameter window 'quit-restore nil)

Why keep it here?  After all, this one has accomplished its mission so
keeping it looks like an UXB to me.

>>         ;; Select old window.
>>         ;; If the previously selected window is still alive, select it.
>>         (window--quit-restore-select-window quit-restore-2))
>>        (t
>>         ;; Show some other buffer in WINDOW and reset the quit-restore
>>         ;; parameter.
>> -      (set-window-parameter window 'quit-restore nil)

Keeping this one looks OK.  If the buffer shown in the window is not the
one the parameter mentions, chances are that a 'quit-restore-window' can
eventually use it in the future.

>> But the proper fix for other problems would be to replace the window
>> parameter `quit-restore' currently shared by all buffers in the same window
>> by a stack where every window buffer should keep own quit-restore data.
>> There is already such a stack in `window-prev-buffers', so a possible
>> solution would be to add quit-restore data to each buffer
>> in window-prev-buffers.

And how would such a stack handle intertwined 'next-buffer' and
'prev-buffer' calls?  Stacks are one of those things that set apart
computers from human beings.

>> Alternatively, it would be nice to have an option that would prevent
>> overwriting the initial value of the window parameter `quit-restore',
>> thus `quit-restore-window' could delete the window regardless of
>> how many buffers were displayed in that window, like it does in case
>> of dedicated windows.

I attach a patch that tries to do that.  Here it handles all scenarios
you describe above.  However, it's by no means trivial and requires at
least _one month_ of testing on your side.  I have not addressed the

           (eq (nth 1 quit-restore) 'tab)

case in 'quit-restore-window'.  You have to look into this yourself.
And there might obviously be other cases missing.

martin

Attachment: quit-restore.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]