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: Juri Linkov
Subject: bug#59862: quit-restore per window buffer
Date: Fri, 12 Jul 2024 09:54:48 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)

>> I checked that prev-buffers is nil in both frame and tab cases,
>> so everything is correct here.
>
> It's not correct in the sense that in the tab case the window showing
> *info* had a previous buffer - *scratch*.  Think of users working on
> some buffer who want to consult Info on something in that buffer with
> the intention to turn back to that buffer as soon as they are done.
> While consulting *info* they hit C-h e.  Now quitting *info* would
> delete the window showing *info* and leave them with a window showing
> *Messages* instead.  Is that really the behavior you have in mind?  How
> would a user go back to the original buffer?

The tab case should not differ from the frame case that has no previous buffer.

>> The difference between frame and tab case is that the frame branch
>> calls 'window--delete' that decides whether to delete the frame,
>> or just delete the window.  But in the tab case it either
>> closes the tab, or does nothing.  So in the tab case
>> it should call 'window--delete' as well, that will decide
>> whether to close the tab, or just delete the window.
>>
>> Then 'window--delete' should do something like this:
>>
>>     (unless (and dedicated-only (not (window-dedicated-p window)))
>>       (let ((deletable (window-deletable-p window)))
>>         (cond
>> +       ((eq deletable 'tab)
>> +        (tab-bar-close-tab)
>> +        'tab)
>>          ((eq deletable 'frame)
>>      (let ((frame (window-frame window)))
>>        (cond
>>
>> Then maybe 'seq-count' with (window-parameter w 'quit-restore)
>> should be moved to 'window-deletable-p'.
>
> IIUC when 'display-buffer-record-window' installs a 'quit-restore'
> parameter of the 'tab' type, it assumes full responsibility for all
> windows on that frame as long as the corresponding tab has not been
> closed.  This means that the tab code has to assure a coherent state of
> the frame's windows after the tab has been closed.  If you can guarantee
> that, feel free to move that check wherever you want.

Ok, I will try to move it.





reply via email to

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