[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: |
Thu, 11 Jul 2024 09:47:27 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) |
>> But there is no *scratch* in the list of previous buffers for 'C-x t t C-h i'
>> (that can be confirmed when tab-line is enabled), so the user won't expect
>> to show *scratch*. And indeed the frame case doesn't show *scratch*.
>
> 'window--display-buffer' resets that window's previous buffers here
>
> (when (memq type '(window frame tab))
> (set-window-prev-buffers window nil))
>
> In the "window" and "frame" case these are actually not needed because
> when making a new window (on the same or a new frame), that window's
> previous buffers are automatically set to nil - by make_window in the
> release version and by the allocation routine with my patch. I reset
> them just to make sure. When you show *info* in an already existing
> window, that window's previous buffers are not reset. So the presence
> of "tab" in the form above is not entirely correct in this regard.
I checked that prev-buffers is nil in both frame and tab cases,
so everything is correct here.
>> I hoped that it would be possible for the tab case to do the same,
>> but I don't know how the frame case is handled to do the right thing.
>
> In 'quit-restore-window' you count the windows with a 'quit-restore'
> parameter. In the scenario at hand this gives 2 so you don't close the
> tab. If you told me in detail what this counting is supposed to
> accomplish, I might be able to help you.
'seq-count' with (window-parameter w 'quit-restore) is intended to be
equivalent to (frame-root-window window) in the frame case, and even better.
So the problem is not here.
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'.
- 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 <=
- bug#59862: quit-restore per window buffer, martin rudalics, 2024/07/11
- bug#59862: quit-restore per window buffer, Juri Linkov, 2024/07/12
- 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