GNU bug report logs -
#71386
29.1; Frame is auto-deleted even when it has multiple tabs
Previous Next
To reply to this bug, email your comments to 71386 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 06 Jun 2024 00:11:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Al Haji-Ali <abdo.haji.ali <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 06 Jun 2024 00:11:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
If I open a frame with multiple tabs, and one of the tabs has a dedicated window, then kill the buffer with the dedicated window, the frame is deleted along with its tabs.
I understand that this is the documented behaviour, however my expectation is that the tab should be deleted but the frame should stay when other tabs are available, similar to how the frame is not deleted if other windows are visible.
The following code illustrates the issue:
,----
| (with-selected-frame (make-frame)
| (tab-bar-mode)
| (switch-to-buffer (generate-new-buffer "test"))
| (tab-bar-new-tab)
| (switch-to-buffer (generate-new-buffer "test2"))
| (set-window-dedicated-p (selected-window) t)
| ;;(kill-buffer) ;; Kill buffer manually to see the issue
| )
`----
I am unable to test this on Emacs 30, but I checked the source code and `window--delete` in `window.el`, which is the function that I think should be changed, seems to do the same as in Emacs 29.1.
-- Al
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 06 Jun 2024 06:03:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
> Date: Thu, 06 Jun 2024 00:44:28 +0100
>
>
> If I open a frame with multiple tabs, and one of the tabs has a dedicated window, then kill the buffer with the dedicated window, the frame is deleted along with its tabs.
>
> I understand that this is the documented behaviour, however my expectation is that the tab should be deleted but the frame should stay when other tabs are available, similar to how the frame is not deleted if other windows are visible.
I'm not sure I agree with you. Tabs are just saved frame
configurations, they are not real windows. If we make this behavior
dependent on tab-bar-mode, we basically introduce an incompatible
behavior change in this particular case, which people and Lisp
programs out there might not expect or like.
I'm adding Juri and Martin to this discussion.
> The following code illustrates the issue:
>
> ,----
> | (with-selected-frame (make-frame)
> | (tab-bar-mode)
> | (switch-to-buffer (generate-new-buffer "test"))
> | (tab-bar-new-tab)
> | (switch-to-buffer (generate-new-buffer "test2"))
> | (set-window-dedicated-p (selected-window) t)
> | ;;(kill-buffer) ;; Kill buffer manually to see the issue
> | )
> `----
>
> I am unable to test this on Emacs 30, but I checked the source code and `window--delete` in `window.el`, which is the function that I think should be changed, seems to do the same as in Emacs 29.1.
Emacs 30 behaves the same in this regard.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 06 Jun 2024 06:25:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> If I open a frame with multiple tabs, and one of the tabs has
>> a dedicated window, then kill the buffer with the dedicated window,
>> the frame is deleted along with its tabs.
>>
>> I understand that this is the documented behaviour, however my
>> expectation is that the tab should be deleted but the frame should
>> stay when other tabs are available, similar to how the frame is not
>> deleted if other windows are visible.
>
> I'm not sure I agree with you. Tabs are just saved frame
> configurations, they are not real windows. If we make this behavior
> dependent on tab-bar-mode, we basically introduce an incompatible
> behavior change in this particular case, which people and Lisp
> programs out there might not expect or like.
>
> I'm adding Juri and Martin to this discussion.
I don't understand the logic of window--delete. But maybe
window-deletable-p should also check for existing tabs in tab-bar-mode
and return 'tab' instead of 'frame'. Then window--delete
could close the tab instead of deleting the frame.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 06 Jun 2024 09:21:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> If I open a frame with multiple tabs, and one of the tabs has a
>> dedicated window, then kill the buffer with the dedicated window, the
>> frame is deleted along with its tabs.
>>
>> I understand that this is the documented behaviour, however my
>> expectation is that the tab should be deleted but the frame should
>> stay when other tabs are available, similar to how the frame is not
>> deleted if other windows are visible.
>
> I'm not sure I agree with you. Tabs are just saved frame
> configurations, they are not real windows. If we make this behavior
> dependent on tab-bar-mode, we basically introduce an incompatible
> behavior change in this particular case, which people and Lisp
> programs out there might not expect or like.
The current behavior of 'replace-buffer-in-windows' has been taken over
from 'quit-window' which Richard initially designed as
;; Get rid of the frame, if it has just one dedicated window
;; and other visible frames exist.
It is not carved in stone but if we want to change it for the tabs case
we should leave it in place. So I think that Juri should provide a tabs
option that has 'quit-restore-window' (which 'replace-buffer-in-windows'
should call) spare the frame in that case. Which buffer to show in that
window instead (especially if it never showed another buffer in its
whole life) is another question.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 06 Jun 2024 09:21:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> I don't understand the logic of window--delete.
It mainly tries to deal with the auto hide mechanism. Other then that
it looks pretty innocuous to me.
> But maybe
> window-deletable-p should also check for existing tabs in tab-bar-mode
> and return 'tab' instead of 'frame'. Then window--delete
> could close the tab instead of deleting the frame.
Governed by an option in the tabs code, I would say.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 06 Jun 2024 10:11:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Al Haji-Ali <abdo.haji.ali <at> gmail.com>, martin rudalics
> <rudalics <at> gmx.at>, 71386 <at> debbugs.gnu.org
> Date: Thu, 06 Jun 2024 09:12:10 +0300
>
> >> If I open a frame with multiple tabs, and one of the tabs has
> >> a dedicated window, then kill the buffer with the dedicated window,
> >> the frame is deleted along with its tabs.
> >>
> >> I understand that this is the documented behaviour, however my
> >> expectation is that the tab should be deleted but the frame should
> >> stay when other tabs are available, similar to how the frame is not
> >> deleted if other windows are visible.
> >
> > I'm not sure I agree with you. Tabs are just saved frame
> > configurations, they are not real windows. If we make this behavior
> > dependent on tab-bar-mode, we basically introduce an incompatible
> > behavior change in this particular case, which people and Lisp
> > programs out there might not expect or like.
> >
> > I'm adding Juri and Martin to this discussion.
>
> I don't understand the logic of window--delete. But maybe
> window-deletable-p should also check for existing tabs in tab-bar-mode
> and return 'tab' instead of 'frame'. Then window--delete
> could close the tab instead of deleting the frame.
Sure, technically it should not be hard to make this change. I just
am not sure we should. Martin, WDYT?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 07 Jun 2024 06:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>>> If I open a frame with multiple tabs, and one of the tabs has a
>>> dedicated window, then kill the buffer with the dedicated window, the
>>> frame is deleted along with its tabs.
>>>
>>> I understand that this is the documented behaviour, however my
>>> expectation is that the tab should be deleted but the frame should
>>> stay when other tabs are available, similar to how the frame is not
>>> deleted if other windows are visible.
>>
>> I'm not sure I agree with you. Tabs are just saved frame
>> configurations, they are not real windows. If we make this behavior
>> dependent on tab-bar-mode, we basically introduce an incompatible
>> behavior change in this particular case, which people and Lisp
>> programs out there might not expect or like.
>
> The current behavior of 'replace-buffer-in-windows' has been taken over
> from 'quit-window' which Richard initially designed as
>
> ;; Get rid of the frame, if it has just one dedicated window
> ;; and other visible frames exist.
>
> It is not carved in stone but if we want to change it for the tabs case
> we should leave it in place. So I think that Juri should provide a tabs
> option that has 'quit-restore-window' (which 'replace-buffer-in-windows'
> should call) spare the frame in that case. Which buffer to show in that
> window instead (especially if it never showed another buffer in its
> whole life) is another question.
Sorry, I don't understand what I should do in tab-bar-mode
for quit-restore-window. I expected that changes should be
in window.el.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 07 Jun 2024 08:26:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> Sorry, I don't understand what I should do in tab-bar-mode
> for quit-restore-window. I expected that changes should be
> in window.el.
Provide an option, say 'tab-bar-save-frame', that allows users to
customize whether a frame should be deleted when "other tabs are
available for that frame". And provide a function, say
'tab-bar-save-frame-p', 'window--delete' could call thusly
(let ((deletable (window-deletable-p window)))
(cond
((eq deletable 'frame)
(let ((frame (window-frame window)))
(cond
((and (fboundp 'tab-bar-save-frame-p)
(tab-bar-save-frame-p frame kill))
nil)
(kill
(delete-frame frame))
thus avoiding to kill the frame when that function returns non-nil.
'tab-bar-save-frame-p' itself would be free to do with the frame
whatever it wants according to the value of 'tab-bar-save-frame'.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 07 Jun 2024 17:23:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Sorry, I don't understand what I should do in tab-bar-mode
>> for quit-restore-window. I expected that changes should be
>> in window.el.
>
> Provide an option, say 'tab-bar-save-frame', that allows users to
> customize whether a frame should be deleted when "other tabs are
> available for that frame". And provide a function, say
> 'tab-bar-save-frame-p', 'window--delete' could call thusly
Ok, here is a better patch:
[window-delete-frame-predicate-functions.patch (text/x-diff, inline)]
diff --git a/lisp/window.el b/lisp/window.el
index 2208346ec8c..abc9f1b4011 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4968,6 +4968,10 @@ frame-auto-hide-function
:group 'frames
:version "26.1")
+(defvar window-delete-frame-predicate-functions nil
+ "Don't delete frame when one of functions returns t.
+Called with two arguments: FRAME and KILL.")
+
(defun window--delete (&optional window dedicated-only kill)
"Delete WINDOW if possible.
WINDOW must be a live window and defaults to the selected one.
@@ -4982,6 +4986,10 @@ window--delete
((eq deletable 'frame)
(let ((frame (window-frame window)))
(cond
+ ((run-hook-with-args-until-success
+ 'window-delete-frame-predicate-functions
+ frame kill)
+ nil)
(kill
(delete-frame frame))
((functionp (frame-parameter frame 'auto-hide-function))
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index dac57ce2070..25bfefbc205 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -2631,6 +2631,14 @@ tab-switcher-mouse-select
(goto-char (posn-point (event-end event)))
(tab-switcher-select))
+
+(defun tab-bar-window-delete-frame-p (frame _kill)
+ "Whether FRAME should be deleted when other tabs are available for that frame.
+Used via `window-delete-frame-predicate-functions' by `window--delete'."
+ (and tab-bar-mode (> (length (funcall tab-bar-tabs-function frame)) 1)))
+
+(add-hook 'window-delete-frame-predicate-functions #'tab-bar-window-delete-frame-p)
+
(defun tab-bar--reusable-frames (all-frames)
(cond
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 07 Jun 2024 18:13:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Al Haji-Ali <abdo.haji.ali <at> gmail.com>,
> 71386 <at> debbugs.gnu.org
> Date: Fri, 07 Jun 2024 20:20:03 +0300
>
> > Provide an option, say 'tab-bar-save-frame', that allows users to
> > customize whether a frame should be deleted when "other tabs are
> > available for that frame". And provide a function, say
> > 'tab-bar-save-frame-p', 'window--delete' could call thusly
>
> Ok, here is a better patch:
Thanks, but I think this should be controlled by a user option, since
it's quite a drastic change in behavior.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 07 Jun 2024 18:19:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> Ok, here is a better patch:
>
> Thanks, but I think this should be controlled by a user option, since
> it's quite a drastic change in behavior.
I'm against adding useless options to tab-bar.el
since users can easily remove hook with 1 liner:
(remove-hook 'window-delete-frame-predicate-functions 'tab-bar-window-delete-frame-p)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 07 Jun 2024 18:56:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 71386 <at> debbugs.gnu.org (full text, mbox):
On 07/06/2024, Juri Linkov wrote:
> Ok, here is a better patch:
Hello Juri,
If I may interject a bit, I think it would be better if the tab is closed (i.e., tab-bar-close-tab is called) and another tab is displayed when the dedicated buffer is killed if its the only one in a window. For example, I changed `window--delete` on my machine to have this
(if (and tab-bar-mode
(> (length (tab-bar-tabs)) 1))
(tab-bar-close-tab)
(delete-frame frame))
In your patch, `tab-bar-window-delete-frame-p` doesn't do that, nor should it as it is a predicate. Maybe `window-delete-frame-predicate-functions` should be renamed to `window-delete-frame-actions` or something and `tab-bar-close-tab` should be called in `tab-bar-window-delete-frame-p` (removing `-p` probably) -- in fact, the `delete-frame` code itself could be added as such an action, if we are not averse to changes to the interface.
Also, just FYI, your patch doesn't allow the branches with `auto-hide-function` and `frame-auto-hide-function` to be called when `kill` is nil. I don't know the side-effects of not calling these functions in such cases, but might be worth checking.
-- Al
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 07 Jun 2024 20:06:03 GMT)
Full text and
rfc822 format available.
Message #41 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rudalics <at> gmx.at, abdo.haji.ali <at> gmail.com, 71386 <at> debbugs.gnu.org
> Date: Fri, 07 Jun 2024 21:16:43 +0300
>
> >> Ok, here is a better patch:
> >
> > Thanks, but I think this should be controlled by a user option, since
> > it's quite a drastic change in behavior.
>
> I'm against adding useless options to tab-bar.el
It is not useless IMO.
> since users can easily remove hook with 1 liner:
>
> (remove-hook 'window-delete-frame-predicate-functions 'tab-bar-window-delete-frame-p)
If we document this in NEWS, it could be good enough.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 09 Jun 2024 17:56:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rudalics <at> gmx.at, 71386 <at> debbugs.gnu.org
> Date: Sun, 09 Jun 2024 19:59:29 +0300
>
> +(defun tab-bar-window-delete-frame (frame _kill)
> + "Whether FRAME should be deleted when other tabs are available for that frame.
> +Instead of deleting the frame, close the current tab.
The first and the second sentences contradict each other. The first
implies that this is a predicate which returns a boolean, whereas the
second says that it closes the tab and negtlets to say anything about
the return value.
> +(defvar window-delete-frame-functions nil
> + "Don't delete frame when one of functions returns t.
> +Each of functions is called with two arguments: FRAME and KILL.
> +The function can perform an action instead of deleting the frame.")
This doc string should at least explain what is the KILL argument and
its meaning.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 09 Jun 2024 18:26:03 GMT)
Full text and
rfc822 format available.
Message #47 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> +(defun tab-bar-window-delete-frame (frame _kill)
>> + "Whether FRAME should be deleted when other tabs are available for that frame.
>> +Instead of deleting the frame, close the current tab.
>
> The first and the second sentences contradict each other. The first
> implies that this is a predicate which returns a boolean, whereas the
> second says that it closes the tab and negtlets to say anything about
> the return value.
>
>> +(defvar window-delete-frame-functions nil
>> + "Don't delete frame when one of functions returns t.
>> +Each of functions is called with two arguments: FRAME and KILL.
>> +The function can perform an action instead of deleting the frame.")
>
> This doc string should at least explain what is the KILL argument and
> its meaning.
I tried to improve these doc strings:
diff --git a/lisp/window.el b/lisp/window.el
index 2208346ec8c..e97557b5bb2 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4968,6 +4968,13 @@ frame-auto-hide-function
:group 'frames
:version "26.1")
+(defvar window-delete-frame-functions nil
+ "A list of functions to handle the frame deletion.
+Each of functions is called with two arguments: FRAME and KILL where
+KILL means the buffer shown in window will be killed. When one of functions
+returns a non-nil value then `window--delete' will not delete the frame.
+The function can also perform own action instead of deleting the frame.")
+
(defun window--delete (&optional window dedicated-only kill)
"Delete WINDOW if possible.
WINDOW must be a live window and defaults to the selected one.
@@ -4982,6 +4989,10 @@ window--delete
((eq deletable 'frame)
(let ((frame (window-frame window)))
(cond
+ ((run-hook-with-args-until-success
+ 'window-delete-frame-functions
+ frame kill)
+ nil)
(kill
(delete-frame frame))
((functionp (frame-parameter frame 'auto-hide-function))
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 6ab6324540e..2f7578b842b 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -2659,6 +2659,17 @@ tab-switcher-mouse-select
(goto-char (posn-point (event-end event)))
(tab-switcher-select))
+
+(defun tab-bar-window-delete-frame (frame _kill)
+ "Handle frame deletion in `tab-bar-mode'.
+When there are more than one tab on the selected frame, then close
+the current tab. In this case return t to not delete the frame
+in `window--delete'."
+ (and tab-bar-mode (> (length (funcall tab-bar-tabs-function frame)) 1)
+ (progn (tab-bar-close-tab) t)))
+
+(add-hook 'window-delete-frame-functions #'tab-bar-window-delete-frame)
+
(defun tab-bar--reusable-frames (all-frames)
(cond
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 09 Jun 2024 18:26:03 GMT)
Full text and
rfc822 format available.
Message #50 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> If I may interject a bit, I think it would be better if the tab is
> closed (i.e., tab-bar-close-tab is called) and another tab is
> displayed when the dedicated buffer is killed if its the only one in
> a window.
Thanks, good suggestion.
> For example, I changed `window--delete` on my machine to
> have this
>
> (if (and tab-bar-mode
> (> (length (tab-bar-tabs)) 1))
> (tab-bar-close-tab)
> (delete-frame frame))
>
> In your patch, `tab-bar-window-delete-frame-p` doesn't do that, nor
> should it as it is a predicate. Maybe
> `window-delete-frame-predicate-functions` should be renamed to
> `window-delete-frame-actions` or something and `tab-bar-close-tab`
> should be called in `tab-bar-window-delete-frame-p` (removing `-p`
> probably) -- in fact, the `delete-frame` code itself could be added as
> such an action, if we are not averse to changes to the interface.
It should be sufficient to rename it to just 'window-delete-frame-functions'.
Then it's not a predicate, and also follows the naming convention of hooks
having the '-functions' suffix.
> Also, just FYI, your patch doesn't allow the branches with
> `auto-hide-function` and `frame-auto-hide-function` to be called when
> `kill` is nil. I don't know the side-effects of not calling these
> functions in such cases, but might be worth checking.
Probably the frame should not be hidden after closing the tab,
so these branches should not be handled.
Ok, here is the patch that supports your initial case:
[tab-bar-window-delete-frame.patch (text/x-diff, inline)]
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 6ab6324540e..485ea1d5dd0 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -2659,6 +2659,16 @@ tab-switcher-mouse-select
(goto-char (posn-point (event-end event)))
(tab-switcher-select))
+
+(defun tab-bar-window-delete-frame (frame _kill)
+ "Whether FRAME should be deleted when other tabs are available for that frame.
+Instead of deleting the frame, close the current tab.
+Used via `window-delete-frame-predicate-functions' by `window--delete'."
+ (and tab-bar-mode (> (length (funcall tab-bar-tabs-function frame)) 1)
+ (progn (tab-bar-close-tab) t)))
+
+(add-hook 'window-delete-frame-functions #'tab-bar-window-delete-frame)
+
(defun tab-bar--reusable-frames (all-frames)
(cond
diff --git a/lisp/window.el b/lisp/window.el
index 2208346ec8c..b1e877b82a8 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4968,6 +4968,11 @@ frame-auto-hide-function
:group 'frames
:version "26.1")
+(defvar window-delete-frame-functions nil
+ "Don't delete frame when one of functions returns t.
+Each of functions is called with two arguments: FRAME and KILL.
+The function can perform an action instead of deleting the frame.")
+
(defun window--delete (&optional window dedicated-only kill)
"Delete WINDOW if possible.
WINDOW must be a live window and defaults to the selected one.
@@ -4982,6 +4987,10 @@ window--delete
((eq deletable 'frame)
(let ((frame (window-frame window)))
(cond
+ ((run-hook-with-args-until-success
+ 'window-delete-frame-functions
+ frame kill)
+ nil)
(kill
(delete-frame frame))
((functionp (frame-parameter frame 'auto-hide-function))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 09 Jun 2024 18:41:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: abdo.haji.ali <at> gmail.com, rudalics <at> gmx.at, 71386 <at> debbugs.gnu.org
> Date: Sun, 09 Jun 2024 20:58:10 +0300
>
> >> +(defun tab-bar-window-delete-frame (frame _kill)
> >> + "Whether FRAME should be deleted when other tabs are available for that frame.
> >> +Instead of deleting the frame, close the current tab.
> >
> > The first and the second sentences contradict each other. The first
> > implies that this is a predicate which returns a boolean, whereas the
> > second says that it closes the tab and negtlets to say anything about
> > the return value.
> >
> >> +(defvar window-delete-frame-functions nil
> >> + "Don't delete frame when one of functions returns t.
> >> +Each of functions is called with two arguments: FRAME and KILL.
> >> +The function can perform an action instead of deleting the frame.")
> >
> > This doc string should at least explain what is the KILL argument and
> > its meaning.
>
> I tried to improve these doc strings:
Thanks, they are more clear now. But one point still needs
clarification, IMO:
> +(defvar window-delete-frame-functions nil
> + "A list of functions to handle the frame deletion.
> +Each of functions is called with two arguments: FRAME and KILL where
> +KILL means the buffer shown in window will be killed. When one of functions
So KILL is a boolean, and if it's non-nil, it means the buffer will be
killed? If so, will the buffer be killed even if the function returns
non-nil?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 09 Jun 2024 18:41:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> I tried to improve these doc strings:
>
> Thanks, they are more clear now. But one point still needs
> clarification, IMO:
>
>> +(defvar window-delete-frame-functions nil
>> + "A list of functions to handle the frame deletion.
>> +Each of functions is called with two arguments: FRAME and KILL where
>> +KILL means the buffer shown in window will be killed. When one of functions
>
> So KILL is a boolean, and if it's non-nil, it means the buffer will be
> killed? If so, will the buffer be killed even if the function returns
> non-nil?
I don't know, I just copied the text from the doc string of 'window--delete'.
But I don't understand the logic of using the KILL argument
in 'window--delete':
(kill
(delete-frame frame))
Maybe Martin could explain.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 10 Jun 2024 08:26:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> So KILL is a boolean, and if it's non-nil, it means the buffer will be
>> killed? If so, will the buffer be killed even if the function returns
>> non-nil?
>
> I don't know, I just copied the text from the doc string of 'window--delete'.
> But I don't understand the logic of using the KILL argument
> in 'window--delete':
>
> (kill
> (delete-frame frame))
>
> Maybe Martin could explain.
KILL non-nil here comes from the prefix argument of 'quit-window' which,
if provided, 'quit-window' passes as 'kill' via BURY-OR-KILL to
'quit-restore-window' which then passes t via the KILL argument to
'window--delete'. 'window--delete' itself does not deal with buffers,
it handles windows only.
'quit-restore-window' calls 'kill-buffer' later when BURY-OR-KILL equals
'kill'. At that time, the window should already have been taken care of
- either by deletion or by showing another buffer. The return value of
'window--delete' is used to make the last conjuncts in the first 'cond'
of 'quit-restore-window' succeed or fail (in the latter case the next
clause will be probed).
The idea of deleting the frame comes from the fact that a killed buffer
cannot be re-shown in that frame's sole window. 'quit-restore-window'
calls 'window--delete' in this case iff that window has no previous
other buffer to show instead, so deleting the window (and possibly its
frame) is the obvious choice rather than showing some unrelated buffer
in it.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 11 Jun 2024 15:55:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> But I don't understand the logic of using the KILL argument
>> in 'window--delete':
>>
>> (kill
>> (delete-frame frame))
>>
>> Maybe Martin could explain.
>
> KILL non-nil here comes from the prefix argument of 'quit-window' which,
> if provided, 'quit-window' passes as 'kill' via BURY-OR-KILL to
> 'quit-restore-window' which then passes t via the KILL argument to
> 'window--delete'. 'window--delete' itself does not deal with buffers,
> it handles windows only.
>
> 'quit-restore-window' calls 'kill-buffer' later when BURY-OR-KILL equals
> 'kill'. At that time, the window should already have been taken care of
> - either by deletion or by showing another buffer. The return value of
> 'window--delete' is used to make the last conjuncts in the first 'cond'
> of 'quit-restore-window' succeed or fail (in the latter case the next
> clause will be probed).
>
> The idea of deleting the frame comes from the fact that a killed buffer
> cannot be re-shown in that frame's sole window. 'quit-restore-window'
> calls 'window--delete' in this case iff that window has no previous
> other buffer to show instead, so deleting the window (and possibly its
> frame) is the obvious choice rather than showing some unrelated buffer
> in it.
So it makes no sense to send the value of the KILL arg to tab-bar code?
Because there is nothing to decide based on its value?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 11 Jun 2024 16:28:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 71386 <at> debbugs.gnu.org (full text, mbox):
On 11/06/2024, Juri Linkov wrote:
> So it makes no sense to send the value of the KILL arg to tab-bar code?
> Because there is nothing to decide based on its value?
Perhaps, for consistency, the argument should be send in case `window-delete-frame-functions` is used for other reasons by the user. Also, perhaps the tab should not be closed if `kill` is nil (similar to how the frame is not killed if `kill` is nil) and another buffer should be shown.
-- Al
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Wed, 12 Jun 2024 08:58:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> So it makes no sense to send the value of the KILL arg to tab-bar code?
> Because there is nothing to decide based on its value?
But KILL means to delete the frame and the tab-bar code wants to prevent
that. Or what am I missing?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 13 Jun 2024 07:14:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> So it makes no sense to send the value of the KILL arg to tab-bar code?
>> Because there is nothing to decide based on its value?
>
> But KILL means to delete the frame and the tab-bar code wants to prevent
> that. Or what am I missing?
For frames KILL defines whether to delete or iconify the frame.
There is no such thing as to "iconify" the tab.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 13 Jun 2024 07:14:03 GMT)
Full text and
rfc822 format available.
Message #74 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> So it makes no sense to send the value of the KILL arg to tab-bar code?
>> Because there is nothing to decide based on its value?
>
> Perhaps, for consistency, the argument should be send in case
> `window-delete-frame-functions` is used for other reasons by the
> user. Also, perhaps the tab should not be closed if `kill` is nil (similar
> to how the frame is not killed if `kill` is nil) and another buffer should
> be shown.
If I read `window--delete` code correctly, the frame goes away
in any case:
(kill
(delete-frame frame))
((functionp frame-auto-hide-function)
(funcall frame-auto-hide-function frame))
If `kill` is nil, the frame gets hidden: the default value of
`frame-auto-hide-function` is `iconify-frame` that is like
closing the tab too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 13 Jun 2024 08:22:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> But KILL means to delete the frame and the tab-bar code wants to prevent
>> that. Or what am I missing?
>
> For frames KILL defines whether to delete or iconify the frame.
> There is no such thing as to "iconify" the tab.
Don't you want to distinguish 'kill' non-nil where the frame should get
deleted from 'kill' nil where nothing is done? In the latter case the
window cannot even be deleted because when the return value of
'window-deletable-p' equals 'frame' this implies that WINDOW is the root
window of its frame.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 14 Jun 2024 06:17:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>>> But KILL means to delete the frame and the tab-bar code wants to prevent
>>> that. Or what am I missing?
>>
>> For frames KILL defines whether to delete or iconify the frame.
>> There is no such thing as to "iconify" the tab.
>
> Don't you want to distinguish 'kill' non-nil where the frame should get
> deleted from 'kill' nil where nothing is done? In the latter case the
> window cannot even be deleted because when the return value of
> 'window-deletable-p' equals 'frame' this implies that WINDOW is the root
> window of its frame.
I still don't understand how frame deletion should be handled for tabs
for this bug report and for bug#59862. Probably need to study more.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 14 Jun 2024 18:05:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> But KILL means to delete the frame and the tab-bar code wants to prevent
>>> that. Or what am I missing?
>>
>> For frames KILL defines whether to delete or iconify the frame.
>> There is no such thing as to "iconify" the tab.
>
> Don't you want to distinguish 'kill' non-nil where the frame should get
> deleted from 'kill' nil where nothing is done? In the latter case the
> window cannot even be deleted because when the return value of
> 'window-deletable-p' equals 'frame' this implies that WINDOW is the root
> window of its frame.
This is the best that I can do, you can improve it if you want:
[window-delete-frame-functions.patch (text/x-diff, inline)]
diff --git a/lisp/window.el b/lisp/window.el
index 604b9868921..155b0b55482 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4948,6 +4968,13 @@ frame-auto-hide-function
:group 'frames
:version "26.1")
+(defvar window-delete-frame-functions nil
+ "A list of functions to handle the frame deletion.
+Each of functions is called with two arguments: FRAME and KILL where
+KILL means the buffer shown in window will be killed. When one of functions
+returns a non-nil value then `window--delete' will not delete the frame.
+The function can also perform own action instead of deleting the frame.")
+
(defun window--delete (&optional window dedicated-only kill)
"Delete WINDOW if possible.
WINDOW must be a live window and defaults to the selected one.
@@ -4962,6 +4989,10 @@ window--delete
((eq deletable 'frame)
(let ((frame (window-frame window)))
(cond
+ ((run-hook-with-args-until-success
+ 'window-delete-frame-functions
+ frame kill)
+ nil)
(kill
(delete-frame frame))
((functionp (frame-parameter frame 'auto-hide-function))
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 6ab6324540e..2f7578b842b 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -2659,6 +2659,17 @@ tab-switcher-mouse-select
(goto-char (posn-point (event-end event)))
(tab-switcher-select))
+
+(defun tab-bar-window-delete-frame (frame _kill)
+ "Handle frame deletion in `tab-bar-mode'.
+When there are more than one tab on the selected frame, then close
+the current tab. In this case return t to not delete the frame
+in `window--delete'."
+ (and tab-bar-mode (> (length (funcall tab-bar-tabs-function frame)) 1)
+ (progn (tab-bar-close-tab) t)))
+
+(add-hook 'window-delete-frame-functions #'tab-bar-window-delete-frame)
+
(defun tab-bar--reusable-frames (all-frames)
(cond
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sat, 15 Jun 2024 08:43:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 71386 <at> debbugs.gnu.org (full text, mbox):
+(defvar window-delete-frame-functions nil
+ "A list of functions to handle the frame deletion.
I'd still prefer a tab-bar specific option (like 'tab-bar-save-frame-p'
as mentioned earlier) for two reasons.
The first reason is that 'window--delete' is an internal function of
window.el. I wouldn't want an internal function run a hook "of its own"
because that's difficult to explain to users. OTOH I suppose that a
function like 'tab-bar-save-frame-p' should be callable from any other
function too, as soon as the need arises.
The second reason is that I wouldn't want "anyone" to inhibit frame
deletion. Such a facility could have consequences I cannot fathom at
the moment. Would we want 'delete-frame' to obey it too and possibly
spare the frame?
Let's see what Haji-Ali thinks.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 16 Jun 2024 07:05:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> +(defvar window-delete-frame-functions nil
> + "A list of functions to handle the frame deletion.
>
> I'd still prefer a tab-bar specific option (like 'tab-bar-save-frame-p'
> as mentioned earlier) for two reasons.
>
> The first reason is that 'window--delete' is an internal function of
> window.el. I wouldn't want an internal function run a hook "of its own"
> because that's difficult to explain to users. OTOH I suppose that a
> function like 'tab-bar-save-frame-p' should be callable from any other
> function too, as soon as the need arises.
>
> The second reason is that I wouldn't want "anyone" to inhibit frame
> deletion. Such a facility could have consequences I cannot fathom at
> the moment. Would we want 'delete-frame' to obey it too and possibly
> spare the frame?
Ok, here is the right patch:
diff --git a/lisp/window.el b/lisp/window.el
index b7bd59bc813..872110a8321 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4120,6 +4120,8 @@ window-deletable-p
(let ((frame (window-frame window)))
(cond
+ ((and tab-bar-mode (> (length (funcall tab-bar-tabs-function frame)) 1))
+ 'tab)
((frame-root-window-p window)
;; WINDOW's frame can be deleted only if there are other frames
;; on the same terminal, and it does not contain the active
@@ -4979,6 +4981,9 @@ window--delete
(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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 16 Jun 2024 08:11:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 71386 <at> debbugs.gnu.org (full text, mbox):
+ ((and tab-bar-mode (> (length (funcall tab-bar-tabs-function frame)) 1))
+ 'tab)
How would users get back the old behavior? By customizing
'tab-bar-close-last-tab-choice', 'tab-bar-tab-prevent-close-functions'?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 16 Jun 2024 10:53:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 71386 <at> debbugs.gnu.org (full text, mbox):
On 15/06/2024, martin rudalics wrote:
> I'd still prefer a tab-bar specific option (like 'tab-bar-save-frame-p'
> as mentioned earlier) for two reasons.
>
This is probably the right approach to minimize unattended consequences and it would definitely address the issue (which is, to reiterate, is that fundamentally, tabs behave like windows in many situations, but not when deleting buffers with dedicated windows -- having two windows prevents deleting a frame, but not having two tabs).
I imagine Juri wanted to avoid having tab-specific code in `window.el` with the previous patch, hence the more generic hooks. The current patch of Juri should probably be protected with `featurep` or `fboundp` for tab-specific symbols.
Also if the proposed change to `window-deletable-p` is adopted, then a grep on `window-deletable-p` also reveals that, for consistency, `delete-windows-on` and even `calendar-exit` in `calendar.el` should be modified similarly to `window--delete`.
Best regards,
-- Al
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 16 Jun 2024 16:54:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> + ((and tab-bar-mode (> (length (funcall tab-bar-tabs-function frame)) 1))
> + 'tab)
>
> How would users get back the old behavior? By customizing
> 'tab-bar-close-last-tab-choice', 'tab-bar-tab-prevent-close-functions'?
This patch just copies the logic of frame handling to tab handling.
There is no customization for frame handling, so there is
no customization for tab handling.
In window-deletable-p there is hard-coded 'frame-root-window-p'
that checks if the frame has only 1 window. So the patch
does the same by checking if there is only 1 tab on the frame.
Also in window--delete the call of 'tab-bar-close-tab'
corresponds to the call 'delete-frame'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 17 Jun 2024 06:18:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> + ((and tab-bar-mode (> (length (funcall tab-bar-tabs-function frame)) 1))
>> + 'tab)
>>
>> How would users get back the old behavior? By customizing
>> 'tab-bar-close-last-tab-choice', 'tab-bar-tab-prevent-close-functions'?
>
> This patch just copies the logic of frame handling to tab handling.
> There is no customization for frame handling, so there is
> no customization for tab handling.
>
> In window-deletable-p there is hard-coded 'frame-root-window-p'
> that checks if the frame has only 1 window. So the patch
> does the same by checking if there is only 1 tab on the frame.
>
> Also in window--delete the call of 'tab-bar-close-tab'
> corresponds to the call 'delete-frame'.
Please see a more correct patch:
diff --git a/lisp/window.el b/lisp/window.el
index cf5c07395ab..588014b8f77 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4138,7 +4138,9 @@ window-deletable-p
(not (eq (default-toplevel-value
'minibuffer-follows-selected-frame)
t)))))
- 'frame))
+ (if (and tab-bar-mode (> (length (funcall tab-bar-tabs-function frame)) 1))
+ 'tab
+ 'frame)))
((window-minibuffer-p window)
;; If WINDOW is the minibuffer window of a non-minibuffer-only
;; frame, it cannot be deleted separately.
@@ -4979,6 +4981,9 @@ window--delete
(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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 17 Jun 2024 14:48:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Also if the proposed change to `window-deletable-p` is adopted, then a
> grep on `window-deletable-p` also reveals that, for consistency,
> `delete-windows-on` and even `calendar-exit` in `calendar.el` should
> be modified similarly to `window--delete`.
This means that we should do the entire fix within 'window-deletable-p',
right? That's not an internal function, so we can, in all conscience,
supply an abnormal hook as in the roughly tested patch attached.
martin
[window-deletable-functions.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 17 Jun 2024 14:48:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> This patch just copies the logic of frame handling to tab handling.
> There is no customization for frame handling,
There is: 'auto-hide-function'.
> so there is
> no customization for tab handling.
But we want to customize the new behavior whether to retain a frame
because it has outstanding tabs or not.
> In window-deletable-p there is hard-coded 'frame-root-window-p'
> that checks if the frame has only 1 window. So the patch
> does the same by checking if there is only 1 tab on the frame.
>
> Also in window--delete the call of 'tab-bar-close-tab'
> corresponds to the call 'delete-frame'.
And if a user wants to auto-hide the frame?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 17 Jun 2024 16:11:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 71386 <at> debbugs.gnu.org (full text, mbox):
On 17/06/2024, martin rudalics wrote:
> This means that we should do the entire fix within 'window-deletable-p',
> right? That's not an internal function, so we can, in all conscience,
> supply an abnormal hook as in the roughly tested patch attached.
It would be great if the fix is done entirely in `window-deletable-p`, but is the idea functions in `window-deletable-functions` could have side-effects even though they are called from a predicate?
For tabs, I believe an ideal fix would close the tab in lieu of deleting the frame when the buffer of a dedicated window is killed (similar to what Juri does in per patches).
-- Al
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 17 Jun 2024 16:48:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> It would be great if the fix is done entirely in `window-deletable-p`,
> but is the idea functions in `window-deletable-functions` could have
> side-effects even though they are called from a predicate?
No. We could emphasize that in the doc-string. The idea is that such a
function can have 'window-deletable-p' return nil instead of 'frame' or
t. WOW all functions on 'window-deletable-functions' have to agree that
'window-deletable-p' may return any non-nil value it initially proposes.
> For tabs, I believe an ideal fix would close the tab in lieu of
> deleting the frame when the buffer of a dedicated window is killed
> (similar to what Juri does in per patches).
The patch I proposed will simply cause another buffer to be shown in
that window. How this affects the tab bar code is beyond the limits of
'quit-restore-window' and colleagues. I suppose the tab bar code should
do whatever it does when 'switch-to-prev-buffer' gets called.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 17 Jun 2024 17:04:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 71386 <at> debbugs.gnu.org (full text, mbox):
On 17/06/2024, martin rudalics wrote:
>
> The patch I proposed will simply cause another buffer to be shown in
> that window. How this affects the tab bar code is beyond the limits of
> 'quit-restore-window' and colleagues. I suppose the tab bar code should
> do whatever it does when 'switch-to-prev-buffer' gets called.
Ah, this could work and I can see it being more foolproof than modifying `window--delete`.
However, `switch-to-prev-buffer` does not seem to allow hooks to modify its behaviour (by the tab-bar code or otherwise), except to skip buffers.
Are we open to adding such hooks as well?
-- Al
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 18 Jun 2024 09:53:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> However, `switch-to-prev-buffer` does not seem to allow hooks to
> modify its behaviour (by the tab-bar code or otherwise), except to
> skip buffers. Are we open to adding such hooks as well?
We've been discussing changes to 'switch-to-prev-buffer' in Bug#69993
but ended up in disagreement on what to do. Juri then implemented a
purely tab-bar based method. For my Emacs I use an option that allows
it to switch to buffers that have been already displayed at least once
only and am quite happy with it (I've never managed to derive a suitable
regexp for all buffers I never want to switch to).
But I do not think that we need a hook for 'switch-to-prev-buffer'. A
user may call it at any moment and the tab bar code must already know
how to deal with it via something like 'window-state-change-functions'
(and on a non-selected frame as well).
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 18 Jun 2024 19:08:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 71386 <at> debbugs.gnu.org (full text, mbox):
On 18/06/2024, martin rudalics wrote:
> We've been discussing changes to 'switch-to-prev-buffer' in Bug#69993
> but ended up in disagreement on what to do. Juri then implemented a
> purely tab-bar based method. For my Emacs I use an option that allows
> it to switch to buffers that have been already displayed at least once
> only and am quite happy with it (I've never managed to derive a suitable
> regexp for all buffers I never want to switch to).
I see. The change you suggested is definitely needed in any case and would address the main issue in this bug report (frame being deleted and losing tab configuration). I would just suggest that `window-deletable-functions` be renamed to `window-deletable-predicates` or `window-deletable-p-functions` (as Juri suggested in his very first patch) to emphasize that these should be side-effect-free predicates.
I guess the code that Juri originally suggested for tab-bar can also be used with `window-deletable-functions`.
,----
| (defun tab-bar-window-delete-frame-p (window kill)
| "Prevent deletion of WINDOW and its frame when it contains tabs.
| Used in `'window-deletable-functions'."
| (and tab-bar-mode (> (length (funcall tab-bar-tabs-function frame)) 1)))
|
| (add-hook 'window-deletable-functions #'tab-bar-window-delete-frame-p)
`----
I'll check Bug#69993 and try to figure out how to close the tab when it has a single dedicated window from `switch-to-prev-buffer`, or maybe Juri has some ideas?
-- Al
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Wed, 19 Jun 2024 06:26:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> We've been discussing changes to 'switch-to-prev-buffer' in Bug#69993
>> but ended up in disagreement on what to do. Juri then implemented a
>> purely tab-bar based method. For my Emacs I use an option that allows
>> it to switch to buffers that have been already displayed at least once
>> only and am quite happy with it (I've never managed to derive a suitable
>> regexp for all buffers I never want to switch to).
>
> I'll check Bug#69993 and try to figure out how to close the tab when
> it has a single dedicated window from `switch-to-prev-buffer`,
Unfortunately, there is nothing to figure out from Bug#69993,
because it was about tab-line, not tab-bar.
> or maybe Juri has some ideas?
I don't know why Martin wants to avoid closing the tabs in window.el
when tabs have the same status as frames, and frames are deleted
in window.el.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Wed, 19 Jun 2024 09:39:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> I don't know why Martin wants to avoid closing the tabs in window.el
> when tabs have the same status as frames, and frames are deleted
> in window.el.
I don't want to avoid closing tabs in window.el. But please make sure
that the mechanism works for any window on any frame. Whatever we
choose, 'window-deletable-p' and 'window--delete' have to work for an
arbitrary live window.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 20 Jun 2024 06:51:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> I don't know why Martin wants to avoid closing the tabs in window.el
>> when tabs have the same status as frames, and frames are deleted
>> in window.el.
>
> I don't want to avoid closing tabs in window.el. But please make sure
> that the mechanism works for any window on any frame. Whatever we
> choose, 'window-deletable-p' and 'window--delete' have to work for an
> arbitrary live window.
So the obstacle is that tab-bar-close-tab closes tabs only on the
selected frame? I don't know, this never was a problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 20 Jun 2024 09:31:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> So the obstacle is that tab-bar-close-tab closes tabs only on the
> selected frame? I don't know, this never was a problem.
For example, 'quit-windows-on' has to deal with all windows showing a
specific buffer on all frames specified by the FRAME argument, killing
that buffer if KILL is non-nil. If any such window was created by the
tab-bar code, that is, its second 'quit-restore' element equals 'tab',
'tab-bar-close-tab' has to take care of that window by deleting it or
showing some other buffer in it.
If 'tab-bar-close-tab' doesn't do that, 'kill-buffer' will kick in and
replace that window's buffer by some arbitrary other buffer. If, as we
currently test with my other patch, 'replace-buffer-in-windows' calls
'quit-restore-window' and the buffer is again not replaced, then
'kill-buffer' will fall back on replace_buffer_in_windows_safely which
doesn't care about the 'quit-restore' parameter and puts some arbitrary
buffer in that window.
Now 'quit-windows-on' is already broken because when KILL is non-nil,
the buffer gets killed in the first call of 'quit-restore-window' which
means to call 'replace-buffer-in-windows' on it which on trunk deletes
windows only if they are dedicated. This is probably not in the sense
of the caller but so far nobody protested. In either case we have to
fix this eventually including the leak that results when 'quit-restore'
parameters reference dead buffers. When we do that, the tab-bar
function called by 'quit-restore-window' should be prepared to handle
the scenario sketched above.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sat, 29 Mar 2025 23:12:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've been bitten by this same issue where kill-buffer
/ replace-buffer-in-windows doesn't take available tab-bar tabs into
consideration as viable replacement windows to restore when quitting the
last window on a frame. I looked at 29+, 30, 31 window.el/.c and
tab-bar.el and I can't find if this was resolved or if there was a recipe
to avoid this.
I've resorted to wrapping kill-buffer using a custom function, not advice,
to inhibit deleting the frame.
Do any of you recall if this bug was addressed and how? If not, may I
assist in some way?
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 30 Mar 2025 05:26:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 71386 <at> debbugs.gnu.org (full text, mbox):
severity 71386 wishlist
thanks
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Sat, 29 Mar 2025 19:11:40 -0400
> Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, Juri Linkov <juri <at> linkov.net>,
> abdo.haji.ali <at> gmail.com
>
> I've been bitten by this same issue where kill-buffer / replace-buffer-in-windows doesn't take available
> tab-bar tabs into consideration as viable replacement windows to restore when quitting the last window on a
> frame. I looked at 29+, 30, 31 window.el/.c and tab-bar.el and I can't find if this was resolved or if there was
> a recipe to avoid this.
The tab-bar tabs are just the visual representation of saved
window-configuration objects. replace-buffer-in-windows never
supported selecting one of the available window-configurations to
replace the buffer shown in the single dedicated window of a frame.
Conceptually, I don't see any relation between these two features, and
no reason up front why replace-buffer-in-windows should select another
tab when a window is deleted because the buffer to which it is
dedicated is removed from display.
Also, the behavior you describe to delete the frame is only when the
window is dedicated to its buffer. Is that what happened in your
scenario?
We have already a user option tab-bar-select-restore-windows; did you
try to customize it to get the effect you want?
In any case, I converted this bug report into a feature request, since
I don't see a bug in the behavior you describe.
Severity set to 'wishlist' from 'normal'
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sun, 30 Mar 2025 05:26:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 30 Mar 2025 06:45:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I've been bitten by this same issue where kill-buffer /
> replace-buffer-in-windows doesn't take available tab-bar tabs into
> consideration as viable replacement windows to restore when quitting the
> last window on a frame. I looked at 29+, 30, 31 window.el/.c and
> tab-bar.el and I can't find if this was resolved or if there was a recipe
> to avoid this.
>
> I've resorted to wrapping kill-buffer using a custom function, not advice,
> to inhibit deleting the frame.
>
> Do any of you recall if this bug was addressed and how? If not, may I
> assist in some way?
Sorry, I'm still testing the fix attached below.
Does it work for you?
[tab-bar-frame.patch (text/x-diff, inline)]
diff --git a/lisp/window.el b/lisp/window.el
index befbc679b23..715b8e745c9 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4187,6 +4187,21 @@ window-deletable-p
(let ((frame (window-frame window)))
(cond
+ ((and tab-bar-mode
+ ;; Fall back to frame handling in case of less than 2 tabs
+ (> (length (funcall tab-bar-tabs-function frame)) 1)
+ ;; Close the tab with the initial window (bug#59862)
+ (or (eq (nth 1 (window-parameter window 'quit-restore)) 'tab)
+ ;; or with the dedicated window (bug#71386)
+ (and (window-dedicated-p window)
+ (frame-root-window-p window)))
+ ;; Don't close the tab if more windows were created explicitly
+ (< (seq-count (lambda (w)
+ (memq (car (window-parameter w 'quit-restore))
+ '(window tab frame same)))
+ (window-list-1 nil 'nomini))
+ 2))
+ 'tab)
((frame-root-window-p window)
;; WINDOW's frame can be deleted only if there are other frames
;; on the same terminal, and it does not contain the active
@@ -5022,6 +5037,10 @@ window--delete
(unless (and dedicated-only (not (window-dedicated-p window)))
(let ((deletable (window-deletable-p window)))
(cond
+ ((eq deletable 'tab)
+ (tab-bar-close-tab)
+ (message "Tab closed after deleting the last window")
+ 'tab)
((eq deletable 'frame)
(let ((frame (window-frame window)))
(cond
@@ -5388,13 +5407,7 @@ quit-restore-window
;; If the previously selected window is still alive, select it.
(window--quit-restore-select-window quit-restore-2))
((and (not prev-buffer)
- (eq (nth 1 quit-restore) 'tab)
- (eq (nth 3 quit-restore) buffer))
- (tab-bar-close-tab)
- ;; If the previously selected window is still alive, select it.
- (window--quit-restore-select-window quit-restore-2))
- ((and (not prev-buffer)
- (or (eq (nth 1 quit-restore) 'frame)
+ (or (memq (nth 1 quit-restore) '(frame tab))
(and (eq (nth 1 quit-restore) 'window)
;; If the window has been created on an existing
;; frame and ended up as the sole window on that
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 30 Mar 2025 07:44:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: 71386 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>, Eli
> Zaretskii <eliz <at> gnu.org>, abdo.haji.ali <at> gmail.com
> Date: Sun, 30 Mar 2025 09:35:09 +0300
>
> > I've been bitten by this same issue where kill-buffer /
> > replace-buffer-in-windows doesn't take available tab-bar tabs into
> > consideration as viable replacement windows to restore when quitting the
> > last window on a frame. I looked at 29+, 30, 31 window.el/.c and
> > tab-bar.el and I can't find if this was resolved or if there was a recipe
> > to avoid this.
> >
> > I've resorted to wrapping kill-buffer using a custom function, not advice,
> > to inhibit deleting the frame.
> >
> > Do any of you recall if this bug was addressed and how? If not, may I
> > assist in some way?
>
> Sorry, I'm still testing the fix attached below.
> Does it work for you?
As I wrote, I don't understand what does deleting a window have to do
with tab-bar. Can you explain why this is conceptually reasonable as
the default behavior?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 30 Mar 2025 12:36:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 30, 2025 at 3:43 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Juri Linkov <juri <at> linkov.net>
> > Cc: 71386 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>, Eli
> > Zaretskii <eliz <at> gnu.org>, abdo.haji.ali <at> gmail.com
> > Date: Sun, 30 Mar 2025 09:35:09 +0300
> >
> > > I've been bitten by this same issue where kill-buffer /
> > > replace-buffer-in-windows doesn't take available tab-bar tabs into
> > > consideration as viable replacement windows to restore when quitting
> the
> > > last window on a frame. I looked at 29+, 30, 31 window.el/.c and
> > > tab-bar.el and I can't find if this was resolved or if there was a
> recipe
> > > to avoid this.
> > >
> > > I've resorted to wrapping kill-buffer using a custom function, not
> advice,
> > > to inhibit deleting the frame.
> > >
> > > Do any of you recall if this bug was addressed and how? If not, may I
> > > assist in some way?
> >
> > Sorry, I'm still testing the fix attached below.
> > Does it work for you?
>
> As I wrote, I don't understand what does deleting a window have to do
> with tab-bar. Can you explain why this is conceptually reasonable as
> the default behavior?
>
Because users have implicit expectations of what a frame's behavior
should be in the presence of multiple tabs? One condition contrary to my
expectations are: more than one tab "open" (yes, I know they aren't
"real"), the current window configuration (aka current tab) has a single
(non-dedicated) window with one buffer, no window prev-buffers. If that
sole buffer gets killed, the frame is deleted. Docs for
'replace-buffer-in-windows' say "If that window is the only window on its
frame, delete its frame when there are other frames left [on the
terminal]." However, the concept of "only window" when a user has implied
windows in other dormant tabs, makes this behavior bothersome.
'tab-bar-select-restore-windows' addresses a wholly different problem where
a window configuration is set and a buffer referenced in the configuration
is now no longer live.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 30 Mar 2025 12:38:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 30, 2025 at 2:44 AM Juri Linkov <juri <at> linkov.net> wrote:
> > I've been bitten by this same issue where kill-buffer /
> > replace-buffer-in-windows doesn't take available tab-bar tabs into
> > consideration as viable replacement windows to restore when quitting the
> > last window on a frame. I looked at 29+, 30, 31 window.el/.c and
> > tab-bar.el and I can't find if this was resolved or if there was a recipe
> > to avoid this.
> >
> > I've resorted to wrapping kill-buffer using a custom function, not
> advice,
> > to inhibit deleting the frame.
> >
> > Do any of you recall if this bug was addressed and how? If not, may I
> > assist in some way?
>
> Sorry, I'm still testing the fix attached below.
> Does it work for you?
>
I'll give it a try. I have a question, though, and sorry if the answer is
obvious. Where is the window parameter 'quit-restore get set 'tab to begin
with?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 30 Mar 2025 12:57:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Sun, 30 Mar 2025 08:35:35 -0400
> Cc: Juri Linkov <juri <at> linkov.net>, 71386 <at> debbugs.gnu.org, rudalics <at> gmx.at,
> abdo.haji.ali <at> gmail.com
>
> As I wrote, I don't understand what does deleting a window have to do
> with tab-bar. Can you explain why this is conceptually reasonable as
> the default behavior?
>
> Because users have implicit expectations of what a frame's behavior should be in the presence of multiple
> tabs? One condition contrary to my expectations are: more than one tab "open" (yes, I know they aren't
> "real"), the current window configuration (aka current tab) has a single (non-dedicated) window with one
> buffer, no window prev-buffers. If that sole buffer gets killed, the frame is deleted.
When the window is not dedicated to its buffer? That shouldn't
happen: replacing a buffer in windows does NOT delete a window if it
is not dedicated to the buffer being replaced, and consequently the
frame should NOT be deleted in that case.
Docs for
> 'replace-buffer-in-windows' say "If that window is the only window on its frame, delete its frame when there are
> other frames left [on the terminal]." However, the concept of "only window" when a user has implied windows
> in other dormant tabs, makes this behavior bothersome.
That's how Emacs behaves. Tabs don't change that.
> 'tab-bar-select-restore-windows' addresses a wholly different problem where a window configuration is set and
> a buffer referenced in the configuration is now no longer live.
I think the situation discussed here is sufficiently similar.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 30 Mar 2025 13:03:01 GMT)
Full text and
rfc822 format available.
Message #160 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 30, 2025 at 8:56 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Sun, 30 Mar 2025 08:35:35 -0400
> > Cc: Juri Linkov <juri <at> linkov.net>, 71386 <at> debbugs.gnu.org,
> rudalics <at> gmx.at,
> > abdo.haji.ali <at> gmail.com
> >
> > As I wrote, I don't understand what does deleting a window have to do
> > with tab-bar. Can you explain why this is conceptually reasonable as
> > the default behavior?
> >
> > Because users have implicit expectations of what a frame's behavior
> should be in the presence of multiple
> > tabs? One condition contrary to my expectations are: more than one tab
> "open" (yes, I know they aren't
> > "real"), the current window configuration (aka current tab) has a single
> (non-dedicated) window with one
> > buffer, no window prev-buffers. If that sole buffer gets killed, the
> frame is deleted.
>
> When the window is not dedicated to its buffer? That shouldn't
> happen: replacing a buffer in windows does NOT delete a window if it
> is not dedicated to the buffer being replaced, and consequently the
> frame should NOT be deleted in that case.
>
I thought you meant explicitly made dedicated via set-window-dedicated-p or
a display-buffer-alist action. This case is just a "regular" window
dedicated to its buffer, yes.
Docs for
> > 'replace-buffer-in-windows' say "If that window is the only window on
> its frame, delete its frame when there are
> > other frames left [on the terminal]." However, the concept of "only
> window" when a user has implied windows
> > in other dormant tabs, makes this behavior bothersome.
>
> That's how Emacs behaves. Tabs don't change that.
>
Right. That's what's being discussed.
> 'tab-bar-select-restore-windows' addresses a wholly different problem
> where a window configuration is set and
> > a buffer referenced in the configuration is now no longer live.
>
> I think the situation discussed here is sufficiently similar.
>
Perhaps it is similar in spirit, but it's different use case. In the
controversial case, there aren't any window configurations to restore
because the frame is (controversially and unexpectedly) deleted.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 30 Mar 2025 13:57:02 GMT)
Full text and
rfc822 format available.
Message #163 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> I'll give it a try. I have a question, though, and sorry if the answer is
> obvious. Where is the window parameter 'quit-restore get set 'tab to begin
> with?
At the very end of 'display-buffer-record-window'
((eq type 'tab)
;; WINDOW has been created on a new tab.
(set-window-parameter
window 'quit-restore
(list 'tab 'tab (selected-window) buffer)))))
I suppose. The initial call is from 'display-buffer-in-new-tab'.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sun, 30 Mar 2025 14:40:02 GMT)
Full text and
rfc822 format available.
Message #166 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 30, 2025 at 9:55 AM martin rudalics <rudalics <at> gmx.at> wrote:
> > I'll give it a try. I have a question, though, and sorry if the answer
> is
> > obvious. Where is the window parameter 'quit-restore get set 'tab to
> begin
> > with?
>
> At the very end of 'display-buffer-record-window'
>
> ((eq type 'tab)
> ;; WINDOW has been created on a new tab.
> (set-window-parameter
> window 'quit-restore
> (list 'tab 'tab (selected-window) buffer)))))
>
> I suppose. The initial call is from 'display-buffer-in-new-tab'.
>
Makes sense. Thank you. I don't use those display actions. Juri's patch
should address the main issue for both use cases. I hope to try it out
later today.
Minor point...when reading through the code, I think the docstrings for
'window--display-buffer' and 'display-buffer-record-window' need to add
'tab to the TYPE section in each.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 01:39:02 GMT)
Full text and
rfc822 format available.
Message #169 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 30, 2025 at 10:38 AM Ship Mints <shipmints <at> gmail.com> wrote:
> On Sun, Mar 30, 2025 at 9:55 AM martin rudalics <rudalics <at> gmx.at> wrote:
>
>> > I'll give it a try. I have a question, though, and sorry if the
>> answer is
>> > obvious. Where is the window parameter 'quit-restore get set 'tab to
>> begin
>> > with?
>>
>> At the very end of 'display-buffer-record-window'
>>
>> ((eq type 'tab)
>> ;; WINDOW has been created on a new tab.
>> (set-window-parameter
>> window 'quit-restore
>> (list 'tab 'tab (selected-window) buffer)))))
>>
>> I suppose. The initial call is from 'display-buffer-in-new-tab'.
>>
>
> Makes sense. Thank you. I don't use those display actions. Juri's patch
> should address the main issue for both use cases. I hope to try it out
> later today.
>
> Minor point...when reading through the code, I think the docstrings for
> 'window--display-buffer' and 'display-buffer-record-window' need to add
> 'tab to the TYPE section in each.
>
Hi, Juri,
[The patch probably needs to be rebased on master but I was able to apply
it by hand, I think.]
The conditions it's testing for are not ones that exist in my case.
The conditions are:
I'm not using the display actions in my configuration and I don't invoke
the tab-bar functions that use it.
I have two tabs on a newly opened frame. Both tabs have only one window.
If I'm on tab 2, and I eval (kill-buffer), the frame disappears.
From inside window-deletable-p: tab-bar-mode=t #tabs=2 quit-restore
parameter=nil window-dedicated-p=nil frame-root-window=t
HTH (hope that helps and happy to help),
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 08:00:06 GMT)
Full text and
rfc822 format available.
Message #172 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> Minor point...when reading through the code, I think the docstrings for
> 'window--display-buffer' and 'display-buffer-record-window' need to add
> 'tab to the TYPE section in each.
Should be fixed now.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 08:00:09 GMT)
Full text and
rfc822 format available.
Message #175 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> I'm not using the display actions in my configuration and I don't invoke
> the tab-bar functions that use it.
>
> I have two tabs on a newly opened frame. Both tabs have only one window.
> If I'm on tab 2, and I eval (kill-buffer), the frame disappears.
>
> From inside window-deletable-p: tab-bar-mode=t #tabs=2 quit-restore
> parameter=nil window-dedicated-p=nil frame-root-window=t
Can you give us a sequence of function calls that implement the behavior
you sketch here. From the text above I don't even understand whether
this is about tab-bars or tab-lines. Among others we need to know
whether the window showing the buffer to be killed is dedicated to it
and what the value of 'kill-buffer-quit-windows' is. If the latter is
non-nil, Emacs will try to call 'quit-restore-window' for any window
showing that buffer and that function expects a 'quit-restore' parameter
for that window.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 11:59:03 GMT)
Full text and
rfc822 format available.
Message #178 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Mar 31, 2025 at 3:59 AM martin rudalics <rudalics <at> gmx.at> wrote:
> > I'm not using the display actions in my configuration and I don't invoke
> > the tab-bar functions that use it.
> >
> > I have two tabs on a newly opened frame. Both tabs have only one
> window.
> > If I'm on tab 2, and I eval (kill-buffer), the frame disappears.
> >
> > From inside window-deletable-p: tab-bar-mode=t #tabs=2 quit-restore
> > parameter=nil window-dedicated-p=nil frame-root-window=t
>
> Can you give us a sequence of function calls that implement the behavior
> you sketch here. From the text above I don't even understand whether
> this is about tab-bars or tab-lines. Among others we need to know
> whether the window showing the buffer to be killed is dedicated to it
> and what the value of 'kill-buffer-quit-windows' is. If the latter is
> non-nil, Emacs will try to call 'quit-restore-window' for any window
> showing that buffer and that function expects a 'quit-restore' parameter
> for that window.
>
I haven't experimented with kill-buffer-quit-windows yet so it's nil for me.
I've spelunked through my use-case state and it's, as usual, hard to tease
out. Below with -Q reproduces the effect.
(setq kill-buffer-quit-windows nil)
(tab-bar-mode)
(select-frame-set-input-focus (make-frame))
(switch-to-buffer "FOO")
(tab-bar-new-tab)
(switch-to-buffer "BAR")
;; these emulate the effect I see
(set-window-prev-buffers nil nil)
(setq switch-to-prev-buffer-skip #'always)
(kill-buffer) ; frame is deleted when I expect the first tab to remain
intact
If the patch removes the test for window-dedicated-p, it leaves the first
tab in place. I almost never use dedicated windows outside of a few
packages that do but those haven't been in play vis-a-vis this issue. I
don't pretend to fully understand what situation w-d-p is intended to deal
with but if we can accommodate both, that'd be fine.
((and tab-bar-mode
;; Fall back to frame handling in case of less than 2 tabs
(> (length (funcall tab-bar-tabs-function frame)) 1)
;; Close the tab with the initial window (bug#59862)
(or (eq (nth 1 (window-parameter window 'quit-restore)) 'tab)
;; or with the dedicated window (bug#71386)
(and ;; (window-dedicated-p window) ; <==== THIS WORKS BETTER
(frame-root-window-p window)))
;; Don't close the tab if more windows were created explicitly
(< (seq-count (lambda (w)
(memq (car (window-parameter w 'quit-restore))
'(window tab frame same)))
(window-list-1 nil 'nomini))
2)
)
'tab)
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 13:51:04 GMT)
Full text and
rfc822 format available.
Message #181 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Mar 31, 2025 at 7:57 AM Ship Mints <shipmints <at> gmail.com> wrote:
> On Mon, Mar 31, 2025 at 3:59 AM martin rudalics <rudalics <at> gmx.at> wrote:
>
>> > I'm not using the display actions in my configuration and I don't
>> invoke
>> > the tab-bar functions that use it.
>> >
>> > I have two tabs on a newly opened frame. Both tabs have only one
>> window.
>> > If I'm on tab 2, and I eval (kill-buffer), the frame disappears.
>> >
>> > From inside window-deletable-p: tab-bar-mode=t #tabs=2 quit-restore
>> > parameter=nil window-dedicated-p=nil frame-root-window=t
>>
>> Can you give us a sequence of function calls that implement the behavior
>> you sketch here. From the text above I don't even understand whether
>> this is about tab-bars or tab-lines. Among others we need to know
>> whether the window showing the buffer to be killed is dedicated to it
>> and what the value of 'kill-buffer-quit-windows' is. If the latter is
>> non-nil, Emacs will try to call 'quit-restore-window' for any window
>> showing that buffer and that function expects a 'quit-restore' parameter
>> for that window.
>>
>
> I haven't experimented with kill-buffer-quit-windows yet so it's nil for
> me.
>
> I've spelunked through my use-case state and it's, as usual, hard to tease
> out. Below with -Q reproduces the effect.
>
> (setq kill-buffer-quit-windows nil)
> (tab-bar-mode)
> (select-frame-set-input-focus (make-frame))
> (switch-to-buffer "FOO")
> (tab-bar-new-tab)
> (switch-to-buffer "BAR")
> ;; these emulate the effect I see
> (set-window-prev-buffers nil nil)
> (setq switch-to-prev-buffer-skip #'always)
> (kill-buffer) ; frame is deleted when I expect the first tab to remain
> intact
>
> If the patch removes the test for window-dedicated-p, it leaves the first
> tab in place. I almost never use dedicated windows outside of a few
> packages that do but those haven't been in play vis-a-vis this issue. I
> don't pretend to fully understand what situation w-d-p is intended to deal
> with but if we can accommodate both, that'd be fine.
>
> ((and tab-bar-mode
> ;; Fall back to frame handling in case of less than 2 tabs
> (> (length (funcall tab-bar-tabs-function frame)) 1)
> ;; Close the tab with the initial window (bug#59862)
> (or (eq (nth 1 (window-parameter window 'quit-restore)) 'tab)
> ;; or with the dedicated window (bug#71386)
> (and ;; (window-dedicated-p window) ; <==== THIS WORKS
> BETTER
> (frame-root-window-p window)))
> ;; Don't close the tab if more windows were created explicitly
> (< (seq-count (lambda (w)
> (memq (car (window-parameter w 'quit-restore))
> '(window tab frame same)))
> (window-list-1 nil 'nomini))
> 2)
> )
> 'tab)
>
The patch is unreliable when there are tab-bar-tab-prevent-close-functions.
The following altered repro will block the tab being closed yet the tab
closed message in 'window--delete' will still show. Should tabs be
forcibly closed in this case?
(setq kill-buffer-quit-windows nil)
(tab-bar-mode)
(select-frame-set-input-focus (make-frame))
(switch-to-buffer "FOO")
(tab-bar-new-tab)
(switch-to-buffer "BAR")
;; these emulate the effect I see
(set-window-prev-buffers nil nil)
(setq switch-to-prev-buffer-skip #'always)
(let ((tab-bar-tab-prevent-close-functions (list #'always)))
(kill-buffer))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 15:10:03 GMT)
Full text and
rfc822 format available.
Message #184 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> Below with -Q reproduces the effect.
>
> (setq kill-buffer-quit-windows nil)
> (tab-bar-mode)
> (select-frame-set-input-focus (make-frame))
> (switch-to-buffer "FOO")
> (tab-bar-new-tab)
> (switch-to-buffer "BAR")
> ;; these emulate the effect I see
> (set-window-prev-buffers nil nil)
> (setq switch-to-prev-buffer-skip #'always)
The last two boil down to saying that the selected window is dedicated
to its buffer.
> (kill-buffer) ; frame is deleted when I expect the first tab to remain
> intact
>
> If the patch removes the test for window-dedicated-p, it leaves the first
> tab in place. I almost never use dedicated windows outside of a few
> packages that do but those haven't been in play vis-a-vis this issue. I
> don't pretend to fully understand what situation w-d-p is intended to deal
> with but if we can accommodate both, that'd be fine.
>
> ((and tab-bar-mode
(> (frame-parameter frame 'tab-bar-lines) 0) is more reliable.
> ;; Fall back to frame handling in case of less than 2 tabs
> (> (length (funcall tab-bar-tabs-function frame)) 1)
> ;; Close the tab with the initial window (bug#59862)
> (or (eq (nth 1 (window-parameter window 'quit-restore)) 'tab)
> ;; or with the dedicated window (bug#71386)
> (and ;; (window-dedicated-p window) ; <==== THIS WORKS BETTER
I'd rather make this subject to an option say
'tab-bar-open-tab-inhibits-delete-frame'.
> (frame-root-window-p window)))
> ;; Don't close the tab if more windows were created explicitly
> (< (seq-count (lambda (w)
> (memq (car (window-parameter w 'quit-restore))
> '(window tab frame same)))
> (window-list-1 nil 'nomini))
> 2)
> )
> 'tab)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 15:31:02 GMT)
Full text and
rfc822 format available.
Message #187 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Mar 31, 2025 at 11:09 AM martin rudalics <rudalics <at> gmx.at> wrote:
> > Below with -Q reproduces the effect.
> >
> > (setq kill-buffer-quit-windows nil)
> > (tab-bar-mode)
> > (select-frame-set-input-focus (make-frame))
> > (switch-to-buffer "FOO")
> > (tab-bar-new-tab)
> > (switch-to-buffer "BAR")
> > ;; these emulate the effect I see
> > (set-window-prev-buffers nil nil)
> > (setq switch-to-prev-buffer-skip #'always)
>
> The last two boil down to saying that the selected window is dedicated
> to its buffer.
>
That might be in some way but window-dedicated-p returns nil for that case.
> (kill-buffer) ; frame is deleted when I expect the first tab to remain
> > intact
> >
> > If the patch removes the test for window-dedicated-p, it leaves the
> first
> > tab in place. I almost never use dedicated windows outside of a few
> > packages that do but those haven't been in play vis-a-vis this issue. I
> > don't pretend to fully understand what situation w-d-p is intended to
> deal
> > with but if we can accommodate both, that'd be fine.
> >
> > ((and tab-bar-mode
>
> (> (frame-parameter frame 'tab-bar-lines) 0) is more reliable.
>
I leave this up to Juri.
> ;; Fall back to frame handling in case of less than 2 tabs
> > (> (length (funcall tab-bar-tabs-function frame)) 1)
> > ;; Close the tab with the initial window (bug#59862)
> > (or (eq (nth 1 (window-parameter window 'quit-restore))
> 'tab)
> > ;; or with the dedicated window (bug#71386)
> > (and ;; (window-dedicated-p window) ; <==== THIS WORKS
> BETTER
>
Agree that we don't need the strict window-dedicated-p condition?
I'd rather make this subject to an option say
> 'tab-bar-open-tab-inhibits-delete-frame'.
>
I assume you meant 'tab-bar-close-tab-inhibits-delete-frame'.
> (frame-root-window-p window)))
> > ;; Don't close the tab if more windows were created
> explicitly
> > (< (seq-count (lambda (w)
> > (memq (car (window-parameter w
> 'quit-restore))
> > '(window tab frame same)))
> > (window-list-1 nil 'nomini))
> > 2)
> > )
> > 'tab)
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 15:45:05 GMT)
Full text and
rfc822 format available.
Message #190 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> > (set-window-prev-buffers nil nil)
>> > (setq switch-to-prev-buffer-skip #'always)
>>
>> The last two boil down to saying that the selected window is dedicated
>> to its buffer.
>>
>
> That might be in some way but window-dedicated-p returns nil for that case.
I meant that if you say that the window never showed another buffer
before, you get the same effect as if the window were dedicated to its
buffer.
>> > (and ;; (window-dedicated-p window) ; <==== THIS WORKS
>> BETTER
>>
>
> Agree that we don't need the strict window-dedicated-p condition?
Yes, because it's not related to the issue at hand (IIUC).
> I'd rather make this subject to an option say
>> 'tab-bar-open-tab-inhibits-delete-frame'.
>>
>
> I assume you meant 'tab-bar-close-tab-inhibits-delete-frame'.
What I meant was that if at least one open tab remains, the frame should
not be deleted.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 17:43:01 GMT)
Full text and
rfc822 format available.
Message #193 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> [The patch probably needs to be rebased on master but I was able to apply
> it by hand, I think.]
Now I pushed the current patch, together with the new tests
that cover its 'quit-restore' logic in test/lisp/tab-bar-tests.el.
Could you please write a new test that will contain a sequence of
function calls that implement the logic of your configuration.
Then we could see how to improve the window functions
to pass the tests.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 18:14:02 GMT)
Full text and
rfc822 format available.
Message #196 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Mar 31, 2025 at 1:42 PM Juri Linkov <juri <at> linkov.net> wrote:
> > [The patch probably needs to be rebased on master but I was able to apply
> > it by hand, I think.]
>
> Now I pushed the current patch, together with the new tests
> that cover its 'quit-restore' logic in test/lisp/tab-bar-tests.el.
>
> Could you please write a new test that will contain a sequence of
> function calls that implement the logic of your configuration.
>
> Then we could see how to improve the window functions
> to pass the tests.
>
I thought Martin agreed that we don't need `(window-dedicated-p window)` in
`window-deleteable-p`? That makes my use case work. Or are you waiting
for the test case and do you want that stand alone or in the test suite?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 19:00:02 GMT)
Full text and
rfc822 format available.
Message #199 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> I thought Martin agreed that we don't need `(window-dedicated-p window)` in
> `window-deleteable-p`? That makes my use case work. Or are you waiting
> for the test case and do you want that stand alone or in the test suite?
Currently we have such test:
;; 3. Don't delete the frame with dedicated window
;; from the second tab (bug#71386)
(with-selected-frame (make-frame frame-params)
(switch-to-buffer (generate-new-buffer "test1"))
(tab-new)
(switch-to-buffer (generate-new-buffer "test2"))
(set-window-dedicated-p (selected-window) t)
(kill-buffer)
(should (eq (length (frame-list)) 2))
(should (eq (length (tab-bar-tabs)) 1))
;; But now should delete the frame with dedicated window
;; from the last tab
(set-window-dedicated-p (selected-window) t)
(kill-buffer)
(should (eq (length (frame-list)) 1)))
So you propose to remove the line with 'set-window-dedicated-p', right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 19:32:02 GMT)
Full text and
rfc822 format available.
Message #202 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Mar 31, 2025 at 2:59 PM Juri Linkov <juri <at> linkov.net> wrote:
> > I thought Martin agreed that we don't need `(window-dedicated-p window)`
> in
> > `window-deleteable-p`? That makes my use case work. Or are you waiting
> > for the test case and do you want that stand alone or in the test suite?
>
> Currently we have such test:
>
> ;; 3. Don't delete the frame with dedicated window
> ;; from the second tab (bug#71386)
> (with-selected-frame (make-frame frame-params)
> (switch-to-buffer (generate-new-buffer "test1"))
> (tab-new)
> (switch-to-buffer (generate-new-buffer "test2"))
> (set-window-dedicated-p (selected-window) t)
> (kill-buffer)
> (should (eq (length (frame-list)) 2))
> (should (eq (length (tab-bar-tabs)) 1))
> ;; But now should delete the frame with dedicated window
> ;; from the last tab
> (set-window-dedicated-p (selected-window) t)
> (kill-buffer)
> (should (eq (length (frame-list)) 1)))
>
> So you propose to remove the line with 'set-window-dedicated-p', right?
>
Not quite. The test that simulates the environment I find frames being
deleted in is more like this:
(setq switch-to-prev-buffer-skip #'always)
(setq kill-buffer-quit-windows nil)
(tab-bar-mode)
(select-frame-set-input-focus (make-frame))
(switch-to-buffer "FOO")
(tab-bar-new-tab)
(switch-to-buffer "BAR")
(set-window-prev-buffers nil nil) ; Martin said this is the moral
equivalent of window-dedicated-p, but not technically
;; (kill-buffer)
The suggestion about removing the dedicated window condition is in
`window-deletable-p` here which could be left in place as long as the case
representing the above scenario is also accounted for.
((and tab-bar-mode
;; Fall back to frame handling in case of less than 2 tabs
(> (length (funcall tab-bar-tabs-function frame)) 1)
;; Close the tab with the initial window (bug#59862)
(or (eq (nth 1 (window-parameter window 'quit-restore)) 'tab)
;; or with the dedicated window (bug#71386)
(and (window-dedicated-p window) ; <========================
(frame-root-window-p window)))
;; Don't close the tab if more windows were created explicitly
(< (seq-count (lambda (w)
(memq (car (window-parameter w 'quit-restore))
'(window tab frame same)))
(window-list-1 nil 'nomini))
2))
'tab)
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Mon, 31 Mar 2025 21:28:03 GMT)
Full text and
rfc822 format available.
Message #205 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Mar 31, 2025 at 3:31 PM Ship Mints <shipmints <at> gmail.com> wrote:
> On Mon, Mar 31, 2025 at 2:59 PM Juri Linkov <juri <at> linkov.net> wrote:
>
>> > I thought Martin agreed that we don't need `(window-dedicated-p
>> window)` in
>> > `window-deleteable-p`? That makes my use case work. Or are you waiting
>> > for the test case and do you want that stand alone or in the test suite?
>>
>> Currently we have such test:
>>
>> ;; 3. Don't delete the frame with dedicated window
>> ;; from the second tab (bug#71386)
>> (with-selected-frame (make-frame frame-params)
>> (switch-to-buffer (generate-new-buffer "test1"))
>> (tab-new)
>> (switch-to-buffer (generate-new-buffer "test2"))
>> (set-window-dedicated-p (selected-window) t)
>> (kill-buffer)
>> (should (eq (length (frame-list)) 2))
>> (should (eq (length (tab-bar-tabs)) 1))
>> ;; But now should delete the frame with dedicated window
>> ;; from the last tab
>> (set-window-dedicated-p (selected-window) t)
>> (kill-buffer)
>> (should (eq (length (frame-list)) 1)))
>>
>> So you propose to remove the line with 'set-window-dedicated-p', right?
>>
>
> Not quite. The test that simulates the environment I find frames being
> deleted in is more like this:
>
> (setq switch-to-prev-buffer-skip #'always)
> (setq kill-buffer-quit-windows nil)
> (tab-bar-mode)
> (select-frame-set-input-focus (make-frame))
> (switch-to-buffer "FOO")
> (tab-bar-new-tab)
> (switch-to-buffer "BAR")
> (set-window-prev-buffers nil nil) ; Martin said this is the moral
> equivalent of window-dedicated-p, but not technically
> ;; (kill-buffer)
>
> The suggestion about removing the dedicated window condition is in
> `window-deletable-p` here which could be left in place as long as the case
> representing the above scenario is also accounted for.
>
> ((and tab-bar-mode
> ;; Fall back to frame handling in case of less than 2 tabs
> (> (length (funcall tab-bar-tabs-function frame)) 1)
> ;; Close the tab with the initial window (bug#59862)
> (or (eq (nth 1 (window-parameter window 'quit-restore)) 'tab)
> ;; or with the dedicated window (bug#71386)
> (and (window-dedicated-p window) ; <========================
> (frame-root-window-p window)))
> ;; Don't close the tab if more windows were created explicitly
> (< (seq-count (lambda (w)
> (memq (car (window-parameter w 'quit-restore))
> '(window tab frame same)))
> (window-list-1 nil 'nomini))
> 2))
> 'tab)
>
WIP patch attached with a test and some few refinements we've talked about
in this dialog. I didn't alter tab-bar-mode to tab-bar-lines as Martin
suggested. You're the expert.
-Stephane
[Message part 2 (text/html, inline)]
[0001-Refining-logic-of-tab-handling-when-quitting-windows.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 01 Apr 2025 08:34:04 GMT)
Full text and
rfc822 format available.
Message #208 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> I didn't alter tab-bar-mode to tab-bar-lines as Martin
> suggested.
When did I suggest that? IIRC I only said that I don't know which of
the two you wanted to fix.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 01 Apr 2025 11:40:05 GMT)
Full text and
rfc822 format available.
Message #211 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Apr 1, 2025 at 4:33 AM martin rudalics <rudalics <at> gmx.at> wrote:
> > I didn't alter tab-bar-mode to tab-bar-lines as Martin
> > suggested.
>
> When did I suggest that? IIRC I only said that I don't know which of
> the two you wanted to fix.
>
I meant this suggestion you made "(> (frame-parameter frame 'tab-bar-lines)
0) is more reliable" than "((and tab-bar-mode";
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 01 Apr 2025 14:47:10 GMT)
Full text and
rfc822 format available.
Message #214 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> > I didn't alter tab-bar-mode to tab-bar-lines as Martin
>> > suggested.
>>
>> When did I suggest that? IIRC I only said that I don't know which of
>> the two you wanted to fix.
>>
>
> I meant this suggestion you made "(> (frame-parameter frame 'tab-bar-lines)
> 0) is more reliable" than "((and tab-bar-mode";
Ah yes. A frame might have no tab bar even if tab-bar-mode is enabled.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 01 Apr 2025 15:01:02 GMT)
Full text and
rfc822 format available.
Message #217 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Apr 1, 2025 at 10:46 AM martin rudalics <rudalics <at> gmx.at> wrote:
> >> > I didn't alter tab-bar-mode to tab-bar-lines as Martin
> >> > suggested.
> >>
> >> When did I suggest that? IIRC I only said that I don't know which of
> >> the two you wanted to fix.
> >>
> >
> > I meant this suggestion you made "(> (frame-parameter frame
> 'tab-bar-lines)
> > 0) is more reliable" than "((and tab-bar-mode";
>
> Ah yes. A frame might have no tab bar even if tab-bar-mode is enabled.
>
One can use tab-bar features without displaying the tab-bar, though.
tab-bar-history-mode as a winner-mode replacement works. tabs still work
as window-configuration controls even without a visible tab-bar, isn't that
right? I don't use it this way but I think it works.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 01 Apr 2025 15:52:01 GMT)
Full text and
rfc822 format available.
Message #220 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> Ah yes. A frame might have no tab bar even if tab-bar-mode is enabled.
>>
>
> One can use tab-bar features without displaying the tab-bar, though.
> tab-bar-history-mode as a winner-mode replacement works. tabs still work
> as window-configuration controls even without a visible tab-bar, isn't that
> right? I don't use it this way but I think it works.
I have no idea, Juri will tell. At least 'tab-bar-tabs' which we seem
to run here consults the 'tabs' frame parameter.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 01 Apr 2025 18:45:01 GMT)
Full text and
rfc822 format available.
Message #223 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> WIP patch attached with a test and some few refinements we've talked about
> in this dialog. I didn't alter tab-bar-mode to tab-bar-lines as Martin
> suggested. You're the expert.
We don't need a new unusable option, so please remove it and submit a new patch.
Also please replace tab-bar-mode with tab-bar-lines like Martin suggested.
Then everything should be good. Also it seems you forgot to remove
window-dedicated-p in your previous patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 01 Apr 2025 18:45:02 GMT)
Full text and
rfc822 format available.
Message #226 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> the new tests that cover its 'quit-restore' logic in
> test/lisp/tab-bar-tests.el.
Martin, could you help to understand why this line fails
;; FIXME: uncomment (should (equal (buffer-name) "*Messages*"))
in 'tab-bar-tests-quit-restore-window' in test/lisp/tab-bar-tests.el?
It selects an unexpected buffer. Maybe because the frame focus
is broken?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 01 Apr 2025 19:08:02 GMT)
Full text and
rfc822 format available.
Message #229 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Apr 1, 2025 at 2:44 PM Juri Linkov <juri <at> linkov.net> wrote:
> > WIP patch attached with a test and some few refinements we've talked
> about
> > in this dialog. I didn't alter tab-bar-mode to tab-bar-lines as Martin
> > suggested. You're the expert.
>
> We don't need a new unusable option, so please remove it and submit a new
> patch.
> Also please replace tab-bar-mode with tab-bar-lines like Martin suggested.
> Then everything should be good. Also it seems you forgot to remove
> window-dedicated-p in your previous patch.
>
I'll work on that now. I'll remove
'window-delete-active-tabs-inhibit-delete-frame'. 'window-dedicated-p'
condition now gone.
Are you sure you don't want this to support the case where tab-bar-mode is
active and tabs merely aren't visible?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Tue, 01 Apr 2025 20:14:02 GMT)
Full text and
rfc822 format available.
Message #232 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Apr 1, 2025 at 3:07 PM Ship Mints <shipmints <at> gmail.com> wrote:
> On Tue, Apr 1, 2025 at 2:44 PM Juri Linkov <juri <at> linkov.net> wrote:
>
>> > WIP patch attached with a test and some few refinements we've talked
>> about
>> > in this dialog. I didn't alter tab-bar-mode to tab-bar-lines as Martin
>> > suggested. You're the expert.
>>
>> We don't need a new unusable option, so please remove it and submit a new
>> patch.
>> Also please replace tab-bar-mode with tab-bar-lines like Martin suggested.
>> Then everything should be good. Also it seems you forgot to remove
>> window-dedicated-p in your previous patch.
>>
>
> I'll work on that now. I'll remove
> 'window-delete-active-tabs-inhibit-delete-frame'. 'window-dedicated-p'
> condition now gone.
>
> Are you sure you don't want this to support the case where tab-bar-mode is
> active and tabs merely aren't visible?
>
There's also 'tab-bar--tab-bar-lines-for-frame' if you think that's more
appropriate.
All tests pass unless I set tab-bar-show nil, and I still think this patch
should work even if the tab-bar is hidden, but tab-bar-mode is enabled.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Wed, 02 Apr 2025 07:01:02 GMT)
Full text and
rfc822 format available.
Message #235 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> > WIP patch attached with a test and some few refinements we've
> talked about
> > in this dialog. I didn't alter tab-bar-mode to tab-bar-lines as
> Martin
> > suggested. You're the expert.
>
> We don't need a new unusable option, so please remove it and submit
> a new patch.
> Also please replace tab-bar-mode with tab-bar-lines like Martin
> suggested.
> Then everything should be good. Also it seems you forgot to remove
> window-dedicated-p in your previous patch.
>
> I'll work on that now. I'll remove
> 'window-delete-active-tabs-inhibit-delete-frame'. 'window-dedicated-p'
> condition now gone.
>
> Are you sure you don't want this to support the case where tab-bar-mode
> is active and tabs merely aren't visible?
>
> There's also 'tab-bar--tab-bar-lines-for-frame' if you think that's more
> appropriate.
'tab-bar--tab-bar-lines-for-frame' is used to set tab-bar-lines,
but you need only to get it.
> All tests pass unless I set tab-bar-show nil, and I still think this patch
> should work even if the tab-bar is hidden, but tab-bar-mode is enabled.
It's a different situation when you see tabs like in a web browser.
They have even an option "Ask before closing multiple tabs".
We could add a similar option instead of the above one,
with 3 possible values like
1. nil - don't ask and close all tabs
2. t - close only the current tab
3. 'ask - ask a confirmation
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Wed, 02 Apr 2025 08:16:01 GMT)
Full text and
rfc822 format available.
Message #238 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> Martin, could you help to understand why this line fails
>
> ;; FIXME: uncomment (should (equal (buffer-name) "*Messages*"))
>
> in 'tab-bar-tests-quit-restore-window' in test/lisp/tab-bar-tests.el?
>
> It selects an unexpected buffer. Maybe because the frame focus
> is broken?
IIUC the context is
(quit-window)
(should (eq (length (window-list)) 1))
(should (eq (length (frame-list)) 2))
;; FIXME: uncomment (should (equal (buffer-name) "*Messages*"))
What is 'quit-window' supposed to do - delete the frame? In either case
we would have to know which window gets selected when the 'quit-window'
call returns and which buffer it shows.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Wed, 02 Apr 2025 20:49:02 GMT)
Full text and
rfc822 format available.
Message #241 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Apr 2, 2025 at 3:00 AM Juri Linkov <juri <at> linkov.net> wrote:
> > > WIP patch attached with a test and some few refinements we've
> > talked about
> > > in this dialog. I didn't alter tab-bar-mode to tab-bar-lines
> as
> > Martin
> > > suggested. You're the expert.
> >
> > We don't need a new unusable option, so please remove it and
> submit
> > a new patch.
> > Also please replace tab-bar-mode with tab-bar-lines like Martin
> > suggested.
> > Then everything should be good. Also it seems you forgot to
> remove
> > window-dedicated-p in your previous patch.
> >
> > I'll work on that now. I'll remove
> > 'window-delete-active-tabs-inhibit-delete-frame'.
> 'window-dedicated-p'
> > condition now gone.
> >
> > Are you sure you don't want this to support the case where
> tab-bar-mode
> > is active and tabs merely aren't visible?
> >
> > There's also 'tab-bar--tab-bar-lines-for-frame' if you think that's more
> > appropriate.
>
> 'tab-bar--tab-bar-lines-for-frame' is used to set tab-bar-lines,
> but you need only to get it.
>
> > All tests pass unless I set tab-bar-show nil, and I still think this
> patch
> > should work even if the tab-bar is hidden, but tab-bar-mode is enabled.
>
> It's a different situation when you see tabs like in a web browser.
> They have even an option "Ask before closing multiple tabs".
> We could add a similar option instead of the above one,
> with 3 possible values like
>
> 1. nil - don't ask and close all tabs
> 2. t - close only the current tab
> 3. 'ask - ask a confirmation
>
Hmm. Well Emacs isn't a web browser, but I hear you. I'll try out an
option like that and see how it feels. I haven't looked deeply, but if we
prompt inside window functions and there are state changes along the code
path before the prompt that we can't undo if the user quits while prompted,
I don't think we need that level of complexity. Maybe we can prompt before
state changes using window-deletable-p output as an indication. Again, not
looked that deeply yet.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 03 Apr 2025 07:04:02 GMT)
Full text and
rfc822 format available.
Message #244 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> > > WIP patch attached with a test and some few refinements
> we've
> > talked about
> > > in this dialog. I didn't alter tab-bar-mode to
> tab-bar-lines as
> > Martin
> > > suggested. You're the expert.
> >
> > We don't need a new unusable option, so please remove it and
> submit
> > a new patch.
> > Also please replace tab-bar-mode with tab-bar-lines like
> Martin
> > suggested.
> > Then everything should be good. Also it seems you forgot to
> remove
> > window-dedicated-p in your previous patch.
> >
> > I'll work on that now. I'll remove
> > 'window-delete-active-tabs-inhibit-delete-frame'.
> 'window-dedicated-p'
> > condition now gone.
> >
> > Are you sure you don't want this to support the case where
> tab-bar-mode
> > is active and tabs merely aren't visible?
> >
> > There's also 'tab-bar--tab-bar-lines-for-frame' if you think that's
> more
> > appropriate.
>
> 'tab-bar--tab-bar-lines-for-frame' is used to set tab-bar-lines,
> but you need only to get it.
>
> > All tests pass unless I set tab-bar-show nil, and I still think this
> patch
> > should work even if the tab-bar is hidden, but tab-bar-mode is
> enabled.
>
> It's a different situation when you see tabs like in a web browser.
> They have even an option "Ask before closing multiple tabs".
> We could add a similar option instead of the above one,
> with 3 possible values like
>
> 1. nil - don't ask and close all tabs
> 2. t - close only the current tab
> 3. 'ask - ask a confirmation
>
> Hmm. Well Emacs isn't a web browser, but I hear you.
Why not:
1. C-x 5 5 M-x eww
2. C-x t t M-x eww
3. q
4. q
behaves as expected from a web browser.
> I'll try out an
> option like that and see how it feels. I haven't looked deeply, but if we
> prompt inside window functions and there are state changes along the code
> path before the prompt that we can't undo if the user quits while prompted,
> I don't think we need that level of complexity. Maybe we can prompt before
> state changes using window-deletable-p output as an indication. Again, not
> looked that deeply yet.
Agreed, we don't need that level of complexity and don't need an option.
I don't think anybody might want the first 'q' in the above scenario
to delete the whole frame.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 03 Apr 2025 07:05:01 GMT)
Full text and
rfc822 format available.
Message #247 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> Martin, could you help to understand why this line fails
>>
>> ;; FIXME: uncomment (should (equal (buffer-name) "*Messages*"))
>>
>> in 'tab-bar-tests-quit-restore-window' in test/lisp/tab-bar-tests.el?
>>
>> It selects an unexpected buffer. Maybe because the frame focus
>> is broken?
>
> IIUC the context is
>
> (quit-window)
> (should (eq (length (window-list)) 1))
> (should (eq (length (frame-list)) 2))
> ;; FIXME: uncomment (should (equal (buffer-name) "*Messages*"))
>
> What is 'quit-window' supposed to do - delete the frame?
'q' is supposed to delete one of two windows and move focus
to the remaining window:
1. C-x 5 5 C-h i
2. C-h e
3. q
should make the selected window with the buffer *Messages*.
And it does when trying the same interactively.
> In either case we would have to know which window gets selected when
> the 'quit-window' call returns and which buffer it shows.
Interactively it selects the *Messages* window, but not in tests.
This is because for tests window-system is nil, so it behaves
weirdly in noninteractive tests.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 03 Apr 2025 09:13:02 GMT)
Full text and
rfc822 format available.
Message #250 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> IIUC the context is
>>
>> (quit-window)
>> (should (eq (length (window-list)) 1))
>> (should (eq (length (frame-list)) 2))
>> ;; FIXME: uncomment (should (equal (buffer-name) "*Messages*"))
>>
>> What is 'quit-window' supposed to do - delete the frame?
>
> 'q' is supposed to delete one of two windows and move focus
> to the remaining window:
>
> 1. C-x 5 5 C-h i
> 2. C-h e
> 3. q
>
> should make the selected window with the buffer *Messages*.
> And it does when trying the same interactively.
>
>> In either case we would have to know which window gets selected when
>> the 'quit-window' call returns and which buffer it shows.
>
> Interactively it selects the *Messages* window, but not in tests.
> This is because for tests window-system is nil, so it behaves
> weirdly in noninteractive tests.
The non-interactive behavior is, in some sense, the correct one. Here
in 'quit-restore-window'
;; If the previously selected window is still alive, select it.
(window--quit-restore-select-window quit-restore-2))
quit-restore-2 is the window on *scratch* and it gets selected
interactively _and_ non-interactively. The latter tested with
(progn
(other-frame-prefix)
(info)
(view-echo-area-messages)
(let (window-system)
(quit-window))
(buffer-name))
If, in interactive use, instead of "q" you run
(defun foo ()
(interactive)
(quit-window)
(message "%s" (selected-window)))
you will see that 'quit-window' selects *scratch*. But in interactive
behavior, the *Messages* frame still has input focus and so its window
gets re-selected later.
You get the "correct" interactive behavior with
(defun window--quit-restore-select-window (window)
"Select WINDOW after having quit another one.
Do not select an inactive minibuffer window."
(when (and (window-live-p window)
(or (not (window-minibuffer-p window))
(minibuffer-window-active-p window)))
(let ((frame (window-frame window)))
(set-frame-selected-window frame window)
(unless (eq frame (selected-frame))
(select-frame-set-input-focus frame)))))
but I'm not even sure whether we want it. And it still won't match the
non-interactive behavior if you can't set frame focus there.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 03 Apr 2025 16:32:02 GMT)
Full text and
rfc822 format available.
Message #253 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> 1. C-x 5 5 C-h i
>> 2. C-h e
>> 3. q
>>
>> should make the selected window with the buffer *Messages*.
>
> You get the "correct" interactive behavior with
>
> (defun window--quit-restore-select-window (window)
> "Select WINDOW after having quit another one.
> Do not select an inactive minibuffer window."
> (when (and (window-live-p window)
> (or (not (window-minibuffer-p window))
> (minibuffer-window-active-p window)))
> (let ((frame (window-frame window)))
> (set-frame-selected-window frame window)
> (unless (eq frame (selected-frame))
> (select-frame-set-input-focus frame)))))
>
> but I'm not even sure whether we want it. And it still won't match the
> non-interactive behavior if you can't set frame focus there.
Just removing 'window--quit-restore-select-window' also allows tests to pass.
I wonder why it's needed when 'delete-window' already selects
the right window with 'set-frame-selected-window'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 03 Apr 2025 18:24:02 GMT)
Full text and
rfc822 format available.
Message #256 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> Just removing 'window--quit-restore-select-window' also allows tests to pass.
>
> I wonder why it's needed when 'delete-window' already selects
> the right window with 'set-frame-selected-window'.
But this is not about 'delete-window'. It's about 'quit-window' and
that function should select the window that was selected at the time
'display-buffer' was called. It doesn't do that currently when that
window is on a different frame but it certainly should to do that when
the window is on the same frame as the window to quit. So maybe you
would prefer the following:
(defun window--quit-restore-select-window (window)
"Select WINDOW after having quit another one.
Do not select an inactive minibuffer window."
(when (and (window-live-p window)
(or (not (window-minibuffer-p window))
(minibuffer-window-active-p window))
(eq (window-frame window) (selected-frame)))
(select-window window)))
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 03 Apr 2025 18:48:02 GMT)
Full text and
rfc822 format available.
Message #259 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> Just removing 'window--quit-restore-select-window' also allows tests to pass.
>>
>> I wonder why it's needed when 'delete-window' already selects
>> the right window with 'set-frame-selected-window'.
>
> But this is not about 'delete-window'. It's about 'quit-window' and
> that function should select the window that was selected at the time
> 'display-buffer' was called. It doesn't do that currently when that
> window is on a different frame but it certainly should to do that when
> the window is on the same frame as the window to quit. So maybe you
> would prefer the following:
>
> (defun window--quit-restore-select-window (window)
> "Select WINDOW after having quit another one.
> Do not select an inactive minibuffer window."
> (when (and (window-live-p window)
> (or (not (window-minibuffer-p window))
> (minibuffer-window-active-p window))
> (eq (window-frame window) (selected-frame)))
> (select-window window)))
Looks right to restrict it to the selected frame.
(I don't know if this should be installed since
it only gives an unexpected result in one minor test.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 04 Apr 2025 07:44:02 GMT)
Full text and
rfc822 format available.
Message #262 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Looks right to restrict it to the selected frame.
> (I don't know if this should be installed since
> it only gives an unexpected result in one minor test.)
Hmmm... When the frame is deleted or not the selected one, we should
try to select the one that contains the window that was selected before
calling 'display-buffer'. When the frame is not deleted and is the
already selected one, I think we should keep it alone. Patch attached.
martin
[window--quit-restore-select-window.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 04 Apr 2025 16:16:02 GMT)
Full text and
rfc822 format available.
Message #265 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> Looks right to restrict it to the selected frame.
>> (I don't know if this should be installed since
>> it only gives an unexpected result in one minor test.)
>
> Hmmm... When the frame is deleted or not the selected one, we should
> try to select the one that contains the window that was selected before
> calling 'display-buffer'. When the frame is not deleted and is the
> already selected one, I think we should keep it alone. Patch attached.
I cannot say if this is the correct solution,
but with it the test passes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 04 Apr 2025 16:22:01 GMT)
Full text and
rfc822 format available.
Message #268 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Apr 2, 2025 at 4:48 PM Ship Mints <shipmints <at> gmail.com> wrote:
> On Wed, Apr 2, 2025 at 3:00 AM Juri Linkov <juri <at> linkov.net> wrote:
>
>> > > WIP patch attached with a test and some few refinements we've
>> > talked about
>> > > in this dialog. I didn't alter tab-bar-mode to tab-bar-lines
>> as
>> > Martin
>> > > suggested. You're the expert.
>> >
>> > We don't need a new unusable option, so please remove it and
>> submit
>> > a new patch.
>> > Also please replace tab-bar-mode with tab-bar-lines like Martin
>> > suggested.
>> > Then everything should be good. Also it seems you forgot to
>> remove
>> > window-dedicated-p in your previous patch.
>> >
>> > I'll work on that now. I'll remove
>> > 'window-delete-active-tabs-inhibit-delete-frame'.
>> 'window-dedicated-p'
>> > condition now gone.
>> >
>> > Are you sure you don't want this to support the case where
>> tab-bar-mode
>> > is active and tabs merely aren't visible?
>> >
>> > There's also 'tab-bar--tab-bar-lines-for-frame' if you think that's more
>> > appropriate.
>>
>> 'tab-bar--tab-bar-lines-for-frame' is used to set tab-bar-lines,
>> but you need only to get it.
>>
>> > All tests pass unless I set tab-bar-show nil, and I still think this
>> patch
>> > should work even if the tab-bar is hidden, but tab-bar-mode is enabled.
>>
>> It's a different situation when you see tabs like in a web browser.
>> They have even an option "Ask before closing multiple tabs".
>> We could add a similar option instead of the above one,
>> with 3 possible values like
>>
>> 1. nil - don't ask and close all tabs
>> 2. t - close only the current tab
>> 3. 'ask - ask a confirmation
>>
>
> Hmm. Well Emacs isn't a web browser, but I hear you. I'll try out an
> option like that and see how it feels. I haven't looked deeply, but if we
> prompt inside window functions and there are state changes along the code
> path before the prompt that we can't undo if the user quits while prompted,
> I don't think we need that level of complexity. Maybe we can prompt before
> state changes using window-deletable-p output as an indication. Again, not
> looked that deeply yet.
>
As I guessed, it's not easy to find the right place(s) to put a prompt
before state changed or undoing state is easy. May I suggest that we move
ahead with the patch I've attached and consider enhancements that may
include a prompt at a later time? We can also see how people get on with
the tab-bar-lines condition vs. just tab-bar-mode (which I still prefer)?
-Stephane
[Message part 2 (text/html, inline)]
[0001-Refining-logic-of-tab-handling-when-quitting-windows.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 04 Apr 2025 16:33:02 GMT)
Full text and
rfc822 format available.
Message #271 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> > > WIP patch attached with a test and some few refinements
> we've
> > talked about
> > > in this dialog. I didn't alter tab-bar-mode to
> tab-bar-lines as
> > Martin
> > > suggested. You're the expert.
> >
> > We don't need a new unusable option, so please remove it
> and submit
> > a new patch.
> > Also please replace tab-bar-mode with tab-bar-lines like
> Martin
> > suggested.
> > Then everything should be good. Also it seems you forgot
> to remove
> > window-dedicated-p in your previous patch.
> >
> > I'll work on that now. I'll remove
> > 'window-delete-active-tabs-inhibit-delete-frame'.
> 'window-dedicated-p'
> > condition now gone.
> >
> > Are you sure you don't want this to support the case where
> tab-bar-mode
> > is active and tabs merely aren't visible?
> >
> > There's also 'tab-bar--tab-bar-lines-for-frame' if you think
> that's more
> > appropriate.
>
> 'tab-bar--tab-bar-lines-for-frame' is used to set tab-bar-lines,
> but you need only to get it.
>
> > All tests pass unless I set tab-bar-show nil, and I still think
> this patch
> > should work even if the tab-bar is hidden, but tab-bar-mode is
> enabled.
>
> It's a different situation when you see tabs like in a web browser.
> They have even an option "Ask before closing multiple tabs".
> We could add a similar option instead of the above one,
> with 3 possible values like
>
> 1. nil - don't ask and close all tabs
> 2. t - close only the current tab
> 3. 'ask - ask a confirmation
>
> Hmm. Well Emacs isn't a web browser, but I hear you. I'll try out an
> option like that and see how it feels. I haven't looked deeply, but if
> we prompt inside window functions and there are state changes along the
> code path before the prompt that we can't undo if the user quits while
> prompted, I don't think we need that level of complexity. Maybe we can
> prompt before state changes using window-deletable-p output as an
> indication. Again, not looked that deeply yet.
>
> As I guessed, it's not easy to find the right place(s) to put a prompt
> before state changed or undoing state is easy. May I suggest that we move
> ahead with the patch I've attached and consider enhancements that may
> include a prompt at a later time? We can also see how people get on with
> the tab-bar-lines condition vs. just tab-bar-mode (which I still prefer)?
Sorry, this was fixed yesterday following Martin's request in bug#59862.
I've cc-ed you a mail about this, but maybe you missed it?
Could you please update your patch from current master?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Fri, 04 Apr 2025 17:29:01 GMT)
Full text and
rfc822 format available.
Message #274 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Apr 4, 2025 at 12:32 PM Juri Linkov <juri <at> linkov.net> wrote:
> > > > WIP patch attached with a test and some few
> refinements
> > we've
> > > talked about
> > > > in this dialog. I didn't alter tab-bar-mode to
> > tab-bar-lines as
> > > Martin
> > > > suggested. You're the expert.
> > >
> > > We don't need a new unusable option, so please remove
> it
> > and submit
> > > a new patch.
> > > Also please replace tab-bar-mode with tab-bar-lines
> like
> > Martin
> > > suggested.
> > > Then everything should be good. Also it seems you
> forgot
> > to remove
> > > window-dedicated-p in your previous patch.
> > >
> > > I'll work on that now. I'll remove
> > > 'window-delete-active-tabs-inhibit-delete-frame'.
> > 'window-dedicated-p'
> > > condition now gone.
> > >
> > > Are you sure you don't want this to support the case where
> > tab-bar-mode
> > > is active and tabs merely aren't visible?
> > >
> > > There's also 'tab-bar--tab-bar-lines-for-frame' if you think
> > that's more
> > > appropriate.
> >
> > 'tab-bar--tab-bar-lines-for-frame' is used to set tab-bar-lines,
> > but you need only to get it.
> >
> > > All tests pass unless I set tab-bar-show nil, and I still think
> > this patch
> > > should work even if the tab-bar is hidden, but tab-bar-mode is
> > enabled.
> >
> > It's a different situation when you see tabs like in a web
> browser.
> > They have even an option "Ask before closing multiple tabs".
> > We could add a similar option instead of the above one,
> > with 3 possible values like
> >
> > 1. nil - don't ask and close all tabs
> > 2. t - close only the current tab
> > 3. 'ask - ask a confirmation
> >
> > Hmm. Well Emacs isn't a web browser, but I hear you. I'll try out
> an
> > option like that and see how it feels. I haven't looked deeply, but
> if
> > we prompt inside window functions and there are state changes along
> the
> > code path before the prompt that we can't undo if the user quits
> while
> > prompted, I don't think we need that level of complexity. Maybe we
> can
> > prompt before state changes using window-deletable-p output as an
> > indication. Again, not looked that deeply yet.
> >
> > As I guessed, it's not easy to find the right place(s) to put a prompt
> > before state changed or undoing state is easy. May I suggest that we
> move
> > ahead with the patch I've attached and consider enhancements that may
> > include a prompt at a later time? We can also see how people get on with
> > the tab-bar-lines condition vs. just tab-bar-mode (which I still prefer)?
>
> Sorry, this was fixed yesterday following Martin's request in bug#59862.
> I've cc-ed you a mail about this, but maybe you missed it?
> Could you please update your patch from current master?
>
Aha that was a different bug number so it wasn't immediately apparent it
was the same. It seems, then, that all I need is to submit a patch to
amend tab-bar-tests.el with the one that represents the use case we've been
discussing? If so, it's attached.
-Stephane
[Message part 2 (text/html, inline)]
[0001-Add-tab-bar-test-for-effectively-dedicated-window-bu.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Sat, 05 Apr 2025 18:46:02 GMT)
Full text and
rfc822 format available.
Message #277 received at 71386 <at> debbugs.gnu.org (full text, mbox):
close 71386 31.0.50
thanks
> Could you please update your patch from current master?
>
> Aha that was a different bug number so it wasn't immediately apparent it
> was the same. It seems, then, that all I need is to submit a patch to
> amend tab-bar-tests.el with the one that represents the use case we've been
> discussing? If so, it's attached.
Thanks, now pushed and closed.
bug marked as fixed in version 31.0.50, send any further explanations to
71386 <at> debbugs.gnu.org and Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org.
(Sat, 05 Apr 2025 18:46:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Wed, 16 Apr 2025 06:54:01 GMT)
Full text and
rfc822 format available.
Message #282 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> Looks right to restrict it to the selected frame.
>> (I don't know if this should be installed since
>> it only gives an unexpected result in one minor test.)
>
> Hmmm... When the frame is deleted or not the selected one, we should
> try to select the one that contains the window that was selected before
> calling 'display-buffer'. When the frame is not deleted and is the
> already selected one, I think we should keep it alone. Patch attached.
Do you think it would be right to install this patch now?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Wed, 16 Apr 2025 07:15:02 GMT)
Full text and
rfc822 format available.
Message #285 received at 71386 <at> debbugs.gnu.org (full text, mbox):
> Do you think it would be right to install this patch now?
It's a compromise between the current behavior and the one described in
the docs (although there we nowhere talk about focus IIRC). So I think
it's right to install it now but I'd leave the ultimate decision to you.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71386; Package
emacs.
(Thu, 17 Apr 2025 18:24:05 GMT)
Full text and
rfc822 format available.
Message #288 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> Do you think it would be right to install this patch now?
>
> It's a compromise between the current behavior and the one described in
> the docs (although there we nowhere talk about focus IIRC). So I think
> it's right to install it now but I'd leave the ultimate decision to you.
Thanks, now installed.
This bug report was last modified 2 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.