[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.
- bug#59862: quit-restore per window buffer, martin rudalics, 2024/07/08
- bug#59862: quit-restore per window buffer, Juri Linkov, 2024/07/09
- bug#59862: quit-restore per window buffer, martin rudalics, 2024/07/09
- bug#59862: quit-restore per window buffer, Juri Linkov, 2024/07/10
- bug#59862: quit-restore per window buffer, martin rudalics, 2024/07/10
- bug#59862: quit-restore per window buffer, Juri Linkov, 2024/07/11
- bug#59862: quit-restore per window buffer, martin rudalics, 2024/07/11
- bug#59862: quit-restore per window buffer,
Juri Linkov <=
- bug#59862: quit-restore per window buffer, martin rudalics, 2024/07/12
- bug#59862: quit-restore per window buffer, Juri Linkov, 2024/07/14
- bug#59862: quit-restore per window buffer, martin rudalics, 2024/07/15
- bug#59862: quit-restore per window buffer, Björn Bidar, 2024/07/16
- bug#59862: quit-restore per window buffer, martin rudalics, 2024/07/16
- bug#59862: quit-restore per window buffer, Björn Bidar, 2024/07/16
- bug#59862: quit-restore per window buffer, martin rudalics, 2024/07/17
- bug#59862: quit-restore per window buffer, martin rudalics, 2024/07/30
- bug#59862: quit-restore per window buffer, Juri Linkov, 2024/07/31