GNU bug report logs - #62427
tab-bar-new-tab-to now handles cases with multiple side-windows

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62427 in the body.
You can then email your comments to 62427 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Benson Chu <bensonchu457 <at> fastmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: tab-bar-new-tab-to now handles cases with multiple side-windows
Date: Fri, 24 Mar 2023 16:07:22 -0500

[Message part 1 (text/plain, inline)]

Hello,

I've noticed that when I call #'tab-bar-new-tab while I'm in a
side-window that has siblings, I get an error from
#'window--sides-check, which happens when #'tab-bar-new-tab calls
#'delete-other-windows. Here's an example of my problem:

(progn
  (display-buffer-in-side-window (get-buffer-create "*hello*")
                                 '((side . right)
                                   (slot . 1)))
  (select-window
   (display-buffer-in-side-window (get-buffer-create "*world*")
                                  '((side . right)
                                    (slot . 2))))
  (tab-bar-new-tab))

The attached patch fixes this issue. Could it be applied to the emacs-29
branch?

Thanks!

[0001-tab-bar-new-tab-to-now-handles-cases-with-multiple-s.patch (text/x-patch, attachment)]

Message #8 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Benson Chu <bensonchu457 <at> fastmail.com>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Sat, 25 Mar 2023 21:14:24 +0200

> I've noticed that when I call #'tab-bar-new-tab while I'm in a
> side-window that has siblings, I get an error from
> #'window--sides-check, which happens when #'tab-bar-new-tab calls
> #'delete-other-windows. Here's an example of my problem:
> ...
> The attached patch fixes this issue. Could it be applied to the emacs-29
> branch?

Thanks.  Unless Eli has objections, I'd like to push the patch
to the emacs-29 branch since it correctly fixes the problem.

Message #11 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Sun, 26 Mar 2023 07:19:12 +0300

> Cc: 62427 <at> debbugs.gnu.org
> From: Juri Linkov <juri <at> linkov.net>
> Date: Sat, 25 Mar 2023 21:14:24 +0200
> 
> > I've noticed that when I call #'tab-bar-new-tab while I'm in a
> > side-window that has siblings, I get an error from
> > #'window--sides-check, which happens when #'tab-bar-new-tab calls
> > #'delete-other-windows. Here's an example of my problem:
> > ...
> > The attached patch fixes this issue. Could it be applied to the emacs-29
> > branch?
> 
> Thanks.  Unless Eli has objections, I'd like to push the patch
> to the emacs-29 branch since it correctly fixes the problem.

I'd like first to understand better the code involved and the
suggested change in it.  Just reading the code of tab-bar-new-tab-to,
it looks strange.  Why does tab-bar.el care about "window parameters
that can cause problems with 'delete-other-windows' and
'split-window'" to begin with?  And why removing these parameters from
windows is TRT for tab-bar.el to resolve such problems, when it
doesn't really "own" those windows?

(Also, the patch's commit log message is not according to our
conventions, but that's a minor issue.)

Message #14 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62427 <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Mon, 27 Mar 2023 10:05:40 +0300

>> > I've noticed that when I call #'tab-bar-new-tab while I'm in a
>> > side-window that has siblings, I get an error from
>> > #'window--sides-check, which happens when #'tab-bar-new-tab calls
>> > #'delete-other-windows. Here's an example of my problem:
>> > ...
>> > The attached patch fixes this issue. Could it be applied to the emacs-29
>> > branch?
>>
>> Thanks.  Unless Eli has objections, I'd like to push the patch
>> to the emacs-29 branch since it correctly fixes the problem.
>
> I'd like first to understand better the code involved and the
> suggested change in it.  Just reading the code of tab-bar-new-tab-to,
> it looks strange.  Why does tab-bar.el care about "window parameters
> that can cause problems with 'delete-other-windows' and
> 'split-window'" to begin with?  And why removing these parameters from
> windows is TRT for tab-bar.el to resolve such problems, when it
> doesn't really "own" those windows?

Indeed, maybe 'delete-other-windows' and `split-window'
should handle these cases.  So since the patch fixes the bug,
it could be pushed to emacs-29.  Then in master
'delete-other-windows' and `split-window' could be rewritten
to handle the 'window-side' parameter.

Message #17 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Mon, 27 Mar 2023 16:36:50 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: bensonchu457 <at> fastmail.com,  62427 <at> debbugs.gnu.org
> Date: Mon, 27 Mar 2023 10:05:40 +0300
> 
> >> > I've noticed that when I call #'tab-bar-new-tab while I'm in a
> >> > side-window that has siblings, I get an error from
> >> > #'window--sides-check, which happens when #'tab-bar-new-tab calls
> >> > #'delete-other-windows. Here's an example of my problem:
> >> > ...
> >> > The attached patch fixes this issue. Could it be applied to the emacs-29
> >> > branch?
> >>
> >> Thanks.  Unless Eli has objections, I'd like to push the patch
> >> to the emacs-29 branch since it correctly fixes the problem.
> >
> > I'd like first to understand better the code involved and the
> > suggested change in it.  Just reading the code of tab-bar-new-tab-to,
> > it looks strange.  Why does tab-bar.el care about "window parameters
> > that can cause problems with 'delete-other-windows' and
> > 'split-window'" to begin with?  And why removing these parameters from
> > windows is TRT for tab-bar.el to resolve such problems, when it
> > doesn't really "own" those windows?
> 
> Indeed, maybe 'delete-other-windows' and `split-window'
> should handle these cases.  So since the patch fixes the bug,
> it could be pushed to emacs-29.  Then in master
> 'delete-other-windows' and `split-window' could be rewritten
> to handle the 'window-side' parameter.

Maybe I'll agree, but I still don't understand the problem well
enough.  Would you please explain the original problem that led
tab-bar.el to care about these window parameters?

TIA

Message #20 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62427 <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Mon, 27 Mar 2023 19:39:25 +0300

>> >> > I've noticed that when I call #'tab-bar-new-tab while I'm in a
>> >> > side-window that has siblings, I get an error from
>> >> > #'window--sides-check, which happens when #'tab-bar-new-tab calls
>> >> > #'delete-other-windows. Here's an example of my problem:
>> >> > ...
>> >> > The attached patch fixes this issue. Could it be applied to the emacs-29
>> >> > branch?
>> >>
>> >> Thanks.  Unless Eli has objections, I'd like to push the patch
>> >> to the emacs-29 branch since it correctly fixes the problem.
>> >
>> > I'd like first to understand better the code involved and the
>> > suggested change in it.  Just reading the code of tab-bar-new-tab-to,
>> > it looks strange.  Why does tab-bar.el care about "window parameters
>> > that can cause problems with 'delete-other-windows' and
>> > 'split-window'" to begin with?  And why removing these parameters from
>> > windows is TRT for tab-bar.el to resolve such problems, when it
>> > doesn't really "own" those windows?
>>
>> Indeed, maybe 'delete-other-windows' and `split-window'
>> should handle these cases.  So since the patch fixes the bug,
>> it could be pushed to emacs-29.  Then in master
>> 'delete-other-windows' and `split-window' could be rewritten
>> to handle the 'window-side' parameter.
>
> Maybe I'll agree, but I still don't understand the problem well
> enough.  Would you please explain the original problem that led
> tab-bar.el to care about these window parameters?

Sorry, I can't explain.  I just did that Martin said to do
in bug#53662.

Message #23 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Mon, 27 Mar 2023 20:06:17 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: bensonchu457 <at> fastmail.com,  62427 <at> debbugs.gnu.org
> Date: Mon, 27 Mar 2023 19:39:25 +0300
> 
> > Maybe I'll agree, but I still don't understand the problem well
> > enough.  Would you please explain the original problem that led
> > tab-bar.el to care about these window parameters?
> 
> Sorry, I can't explain.  I just did that Martin said to do
> in bug#53662.

That's okay, Benson Chu explained it.

Let me think about this.

Message #26 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: "Benson Chu" <bensonchu457 <at> fastmail.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>, "Juri Linkov" <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Mon, 27 Mar 2023 12:43:31 -0500

[Message part 1 (text/plain, inline)]

Oops, I only replied to Eli. I'll send my explanation, and new patch. 

> When the variable tab-bar-new-tab-choice is set to t, the intended
> behavior is to create a new tab with a single window, and that single
> window displaying the current buffer of the currently selected window,
> and the new window should have a fresh set of window parameters.

> Typically, this is done by first calling delete-other-windows, so the
> currently selected window is the only window. The call to
> delete-other-windows also ignores window-parameters, so even windows
> that have the no-delete-other-windows parameter still get deleted. Then,
> the current window is split, to create a fresh new window with fresh
> window parameters, and then delete-window is called to delete the
> currently selected window.

> This strategy doesn't work when the current window is a side-window,
> because delete-other-windows has a check which says that a side-window
> cannot be the only window in a frame. So, to work around this, we just
> remove the window-side parameter beforehand, so the above strategy still
> works.

> Another way we could do this was to get the current-buffer, then delete
> all side-windows. After deleting all side-windows, we know the current
> selected window is NOT a side-window, and then we can call
> delete-other-windows, split-window, and delete-window.

On Mon, Mar 27, 2023, at 12:06 PM, Eli Zaretskii wrote:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: bensonchu457 <at> fastmail.com,  62427 <at> debbugs.gnu.org
>> Date: Mon, 27 Mar 2023 19:39:25 +0300
>> 
>> > Maybe I'll agree, but I still don't understand the problem well
>> > enough.  Would you please explain the original problem that led
>> > tab-bar.el to care about these window parameters?
>> 
>> Sorry, I can't explain.  I just did that Martin said to do
>> in bug#53662.
>
> That's okay, Benson Chu explained it.
>
> Let me think about this.

[0001-tab-bar-new-tab-now-handles-multiple-side-windows.patch (text/x-patch, attachment)]

Message #29 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Benson Chu" <bensonchu457 <at> fastmail.com>
Cc: 62427 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Tue, 28 Mar 2023 15:42:41 +0300

> Date: Mon, 27 Mar 2023 12:43:31 -0500
> From: "Benson Chu" <bensonchu457 <at> fastmail.com>
> Cc: 62427 <at> debbugs.gnu.org
> 
> > When the variable tab-bar-new-tab-choice is set to t, the intended
> > behavior is to create a new tab with a single window, and that single
> > window displaying the current buffer of the currently selected window,
> > and the new window should have a fresh set of window parameters.
> 
> > Typically, this is done by first calling delete-other-windows, so the
> > currently selected window is the only window. The call to
> > delete-other-windows also ignores window-parameters, so even windows
> > that have the no-delete-other-windows parameter still get deleted. Then,
> > the current window is split, to create a fresh new window with fresh
> > window parameters, and then delete-window is called to delete the
> > currently selected window.
> 
> > This strategy doesn't work when the current window is a side-window,
> > because delete-other-windows has a check which says that a side-window
> > cannot be the only window in a frame. So, to work around this, we just
> > remove the window-side parameter beforehand, so the above strategy still
> > works.
> 
> > Another way we could do this was to get the current-buffer, then delete
> > all side-windows. After deleting all side-windows, we know the current
> > selected window is NOT a side-window, and then we can call
> > delete-other-windows, split-window, and delete-window.
> 
> On Mon, Mar 27, 2023, at 12:06 PM, Eli Zaretskii wrote:
> >> From: Juri Linkov <juri <at> linkov.net>
> >> Cc: bensonchu457 <at> fastmail.com,  62427 <at> debbugs.gnu.org
> >> Date: Mon, 27 Mar 2023 19:39:25 +0300
> >> 
> >> > Maybe I'll agree, but I still don't understand the problem well
> >> > enough.  Would you please explain the original problem that led
> >> > tab-bar.el to care about these window parameters?
> >> 
> >> Sorry, I can't explain.  I just did that Martin said to do
> >> in bug#53662.
> >
> > That's okay, Benson Chu explained it.
> >
> > Let me think about this.

After thinking about this, I'm very uncomfortable with removing window
parameters like that.  These windows don't belong to us, right?  They
are windows that just happen to be there when the user creates a new
tab.  So arbitrary removal of their parameters behind the back of the
user and possibly some Lisp program which set these parameters is not
TRT.

Can't we create a completely new window and show the buffer in it?
That new window then can have any parameters we want, since it's new.

Or am I missing something?

Message #32 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Benson Chu <bensonchu457 <at> fastmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62427 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Tue, 28 Mar 2023 11:17:29 -0500

> Can't we create a completely new window and show the buffer in it?

I'm not sure how easy this is. Typically new windows come from calls to
#'split-window, and you can't do that for a side-window.

>                            I'm very uncomfortable with removing window
> parameters like that.  These windows don't belong to us, right?

Let me know if this is wrong, but I am interpreting this statement as:

"We shouldn't be modifying the window parameters of the windows that
belong to the old tab."

Because if that's the case, we're not /really/ modifying the old tab's
window-parameters. They're only "removed" "temporarily", for the
purposes of creating the new tab. You can see right before we modify any
window parameters, we make a call to (tab-bar--tab), which returns a tab
data structure, which contain a representation of the current wconf
(window configuration) - effectively saving the wconf - including the
paramaters. It's kind of like a save excursion:

(let ((old-tab-num (tab-bar--current-tab-index tabs))
      (old-window-configuration (tab-bar--tab)))
  ;; modify window-parameters
  ;; do appropriate splitting
  ;; Now we have the window layout for the new tab

  ;; The old tab should have the old-window-configuration
  (setf (nth old-tab-num tabs) old-window-configuration)

  ;; The rest of the function
  )

Maybe this function would read better if the (setf ...) came first.

So, we capture the current window configuration at the start of the
function, transition the current window configuration into the window
configuration for the new tab (which involves mangling window
parameters and destroying windows), then we make sure that the old tab
has an unmodified window-configuration.

When the user switches back to the tab they left, all the
window-parameters are still present, untouched. Are you still
uncomfortable with doing things this way?

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Mon, 27 Mar 2023 12:43:31 -0500
>> From: "Benson Chu" <bensonchu457 <at> fastmail.com>
>> Cc: 62427 <at> debbugs.gnu.org
>>
>> > When the variable tab-bar-new-tab-choice is set to t, the intended
>> > behavior is to create a new tab with a single window, and that single
>> > window displaying the current buffer of the currently selected window,
>> > and the new window should have a fresh set of window parameters.
>>
>> > Typically, this is done by first calling delete-other-windows, so the
>> > currently selected window is the only window. The call to
>> > delete-other-windows also ignores window-parameters, so even windows
>> > that have the no-delete-other-windows parameter still get deleted. Then,
>> > the current window is split, to create a fresh new window with fresh
>> > window parameters, and then delete-window is called to delete the
>> > currently selected window.
>>
>> > This strategy doesn't work when the current window is a side-window,
>> > because delete-other-windows has a check which says that a side-window
>> > cannot be the only window in a frame. So, to work around this, we just
>> > remove the window-side parameter beforehand, so the above strategy still
>> > works.
>>
>> > Another way we could do this was to get the current-buffer, then delete
>> > all side-windows. After deleting all side-windows, we know the current
>> > selected window is NOT a side-window, and then we can call
>> > delete-other-windows, split-window, and delete-window.
>>
>> On Mon, Mar 27, 2023, at 12:06 PM, Eli Zaretskii wrote:
>> >> From: Juri Linkov <juri <at> linkov.net>
>> >> Cc: bensonchu457 <at> fastmail.com,  62427 <at> debbugs.gnu.org
>> >> Date: Mon, 27 Mar 2023 19:39:25 +0300
>> >>
>> >> > Maybe I'll agree, but I still don't understand the problem well
>> >> > enough.  Would you please explain the original problem that led
>> >> > tab-bar.el to care about these window parameters?
>> >>
>> >> Sorry, I can't explain.  I just did that Martin said to do
>> >> in bug#53662.
>> >
>> > That's okay, Benson Chu explained it.
>> >
>> > Let me think about this.
>
> After thinking about this, I'm very uncomfortable with removing window
> parameters like that.  These windows don't belong to us, right?  They
> are windows that just happen to be there when the user creates a new
> tab.  So arbitrary removal of their parameters behind the back of the
> user and possibly some Lisp program which set these parameters is not
> TRT.
>
> Can't we create a completely new window and show the buffer in it?
> That new window then can have any parameters we want, since it's new.
>
> Or am I missing something?

Message #35 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Benson Chu <bensonchu457 <at> fastmail.com>
Cc: 62427 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Tue, 28 Mar 2023 20:11:12 +0300

> From: Benson Chu <bensonchu457 <at> fastmail.com>
> Cc: juri <at> linkov.net, 62427 <at> debbugs.gnu.org
> Date: Tue, 28 Mar 2023 11:17:29 -0500
> 
> > Can't we create a completely new window and show the buffer in it?
> 
> I'm not sure how easy this is. Typically new windows come from calls to
> #'split-window, and you can't do that for a side-window.

What does display-buffer do in this case? reuse the same window
regardless of any action alists?

> >                            I'm very uncomfortable with removing window
> > parameters like that.  These windows don't belong to us, right?
> 
> Let me know if this is wrong, but I am interpreting this statement as:
> 
> "We shouldn't be modifying the window parameters of the windows that
> belong to the old tab."

There doesn't have to be any "old tab".  AFAIU, this option's default
value is t, so even when you create the first tab, the code you
suggest changing will run and mess with the window parameters of the
windows that happen to exist at that point.  Right?

> Because if that's the case, we're not /really/ modifying the old tab's
> window-parameters. They're only "removed" "temporarily", for the
> purposes of creating the new tab. You can see right before we modify any
> window parameters, we make a call to (tab-bar--tab), which returns a tab
> data structure, which contain a representation of the current wconf
> (window configuration) - effectively saving the wconf - including the
> paramaters. It's kind of like a save excursion:
> 
> (let ((old-tab-num (tab-bar--current-tab-index tabs))
>       (old-window-configuration (tab-bar--tab)))
>   ;; modify window-parameters
>   ;; do appropriate splitting
>   ;; Now we have the window layout for the new tab
> 
>   ;; The old tab should have the old-window-configuration
>   (setf (nth old-tab-num tabs) old-window-configuration)
> 
>   ;; The rest of the function
>   )

Is this inside unwind-protect, so that any error or quit or throw is
caught and the parameters restored?  If so, it might be semi-okay.

> So, we capture the current window configuration at the start of the
> function, transition the current window configuration into the window
> configuration for the new tab (which involves mangling window
> parameters and destroying windows), then we make sure that the old tab
> has an unmodified window-configuration.

Ugh!  That is _soooo_ inelegant...  Also inefficient, and quite
fragile (as any code which uses seve/restore window-configuration is).
But I guess that ship has sailed long ago.

> When the user switches back to the tab they left, all the
> window-parameters are still present, untouched. Are you still
> uncomfortable with doing things this way?

What happens with all kinds of hooks that run due to this saving and
restoring window-configuration? they still will see windows without
their parameters, right?

Message #38 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Benson Chu <bensonchu457 <at> fastmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62427 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Tue, 28 Mar 2023 12:39:54 -0500

> Ugh!  That is _soooo_ inelegant...  Also inefficient

Hehe, I see what you mean, but creating frames is so expensive. These
tabs are like lightweight frames for me. What would you suggest be done
instead?

> Is this inside unwind-protect, so that any error or quit or throw is
> caught and the parameters restored?  If so, it might be semi-okay.

Ahhh, that is a good point. The reason I even noticed this error was
that there wasn't an unwind-protect around it, so not only would Emacs
not switch to a new tab, but my window paramters for the current tab
would be all messed up.

> What does display-buffer do in this case? reuse the same window
> regardless of any action alists?

Huh, that is a gooood question. I will look into what #'display-buffer
does.

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Benson Chu <bensonchu457 <at> fastmail.com>
>> Cc: juri <at> linkov.net, 62427 <at> debbugs.gnu.org
>> Date: Tue, 28 Mar 2023 11:17:29 -0500
>>
>> > Can't we create a completely new window and show the buffer in it?
>>
>> I'm not sure how easy this is. Typically new windows come from calls to
>> #'split-window, and you can't do that for a side-window.
>
> What does display-buffer do in this case? reuse the same window
> regardless of any action alists?
>
>> >                            I'm very uncomfortable with removing window
>> > parameters like that.  These windows don't belong to us, right?
>>
>> Let me know if this is wrong, but I am interpreting this statement as:
>>
>> "We shouldn't be modifying the window parameters of the windows that
>> belong to the old tab."
>
> There doesn't have to be any "old tab".  AFAIU, this option's default
> value is t, so even when you create the first tab, the code you
> suggest changing will run and mess with the window parameters of the
> windows that happen to exist at that point.  Right?
>
>> Because if that's the case, we're not /really/ modifying the old tab's
>> window-parameters. They're only "removed" "temporarily", for the
>> purposes of creating the new tab. You can see right before we modify any
>> window parameters, we make a call to (tab-bar--tab), which returns a tab
>> data structure, which contain a representation of the current wconf
>> (window configuration) - effectively saving the wconf - including the
>> paramaters. It's kind of like a save excursion:
>>
>> (let ((old-tab-num (tab-bar--current-tab-index tabs))
>>       (old-window-configuration (tab-bar--tab)))
>>   ;; modify window-parameters
>>   ;; do appropriate splitting
>>   ;; Now we have the window layout for the new tab
>>
>>   ;; The old tab should have the old-window-configuration
>>   (setf (nth old-tab-num tabs) old-window-configuration)
>>
>>   ;; The rest of the function
>>   )
>
> Is this inside unwind-protect, so that any error or quit or throw is
> caught and the parameters restored?  If so, it might be semi-okay.
>
>> So, we capture the current window configuration at the start of the
>> function, transition the current window configuration into the window
>> configuration for the new tab (which involves mangling window
>> parameters and destroying windows), then we make sure that the old tab
>> has an unmodified window-configuration.
>
> Ugh!  That is _soooo_ inelegant...  Also inefficient, and quite
> fragile (as any code which uses seve/restore window-configuration is).
> But I guess that ship has sailed long ago.
>
>> When the user switches back to the tab they left, all the
>> window-parameters are still present, untouched. Are you still
>> uncomfortable with doing things this way?
>
> What happens with all kinds of hooks that run due to this saving and
> restoring window-configuration? they still will see windows without
> their parameters, right?

Message #41 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62427 <at> debbugs.gnu.org, Benson Chu <bensonchu457 <at> fastmail.com>
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Thu, 30 Mar 2023 19:43:35 +0300

> After thinking about this, I'm very uncomfortable with removing window
> parameters like that.  These windows don't belong to us, right?  They
> are windows that just happen to be there when the user creates a new
> tab.  So arbitrary removal of their parameters behind the back of the
> user and possibly some Lisp program which set these parameters is not
> TRT.
>
> Can't we create a completely new window and show the buffer in it?
> That new window then can have any parameters we want, since it's new.
>
> Or am I missing something?

Sometimes the window configuration gets into such inconsistent state
that the minibuffer window remains on the window list while the
minibuffer is not active.  Then creating a new tab fails with
such error:

Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified window")
  delete-other-windows-internal(#<window 4 on  *Minibuf-1*> #<window 5 on *scratch*>)
  delete-other-windows()
  tab-bar-new-tab-to()
  tab-bar-new-tab()

Please fix this bug as well.

Message #44 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Benson Chu <bensonchu457 <at> fastmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Fri, 31 Mar 2023 11:20:23 -0500

>                            Then creating a new tab fails with
> such error:
>
> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified window")

Sure, I would be happy to investigate the problem! Is there a way to
reproduce this bug? I've personally never seen it before.

Juri Linkov <juri <at> linkov.net> writes:

>> After thinking about this, I'm very uncomfortable with removing window
>> parameters like that.  These windows don't belong to us, right?  They
>> are windows that just happen to be there when the user creates a new
>> tab.  So arbitrary removal of their parameters behind the back of the
>> user and possibly some Lisp program which set these parameters is not
>> TRT.
>>
>> Can't we create a completely new window and show the buffer in it?
>> That new window then can have any parameters we want, since it's new.
>>
>> Or am I missing something?
>
> Sometimes the window configuration gets into such inconsistent state
> that the minibuffer window remains on the window list while the
> minibuffer is not active.  Then creating a new tab fails with
> such error:
>
> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified window")
>   delete-other-windows-internal(#<window 4 on  *Minibuf-1*> #<window 5 on *scratch*>)
>   delete-other-windows()
>   tab-bar-new-tab-to()
>   tab-bar-new-tab()
>
> Please fix this bug as well.

Message #47 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Benson Chu <bensonchu457 <at> fastmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Sat, 01 Apr 2023 21:25:13 +0300

>> Then creating a new tab fails with such error:
>>
>> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified window")
>
> Sure, I would be happy to investigate the problem! Is there a way to
> reproduce this bug? I've personally never seen it before.

Sorry, this bug is not reproducible.  It comes out of the blue.
And has such consequences that there is no recursive edit,
but you still can switch to the minibuffer window that has no prompt
with 'C-x o'.

>> Sometimes the window configuration gets into such inconsistent state
>> that the minibuffer window remains on the window list while the
>> minibuffer is not active.  Then creating a new tab fails with
>> such error:
>>
>> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified window")
>>   delete-other-windows-internal(#<window 4 on  *Minibuf-1*> #<window 5 on *scratch*>)
>>   delete-other-windows()
>>   tab-bar-new-tab-to()
>>   tab-bar-new-tab()

Message #50 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Benson Chu <bensonchu457 <at> fastmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Sun, 02 Apr 2023 21:20:36 +0300

>>> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified window")
>>
>> Sure, I would be happy to investigate the problem! Is there a way to
>> reproduce this bug? I've personally never seen it before.
>
> Sorry, this bug is not reproducible.  It comes out of the blue.
> And has such consequences that there is no recursive edit,
> but you still can switch to the minibuffer window that has no prompt
> with 'C-x o'.

Ok, now here is 100% reproducible case:

0. emacs-29 -Q
1. (setq debug-on-error t enable-recursive-minibuffers t)
2. M-:   (or any other prompt like 'M-x')
3. Resize the minibuffer window e.g. with the mouse to at least 4 lines high
4. M-x windmove-swap-states-up RET
5. Click on the bottom window
6. C-x t 2
7. Click on the bottom window
8. C-x t 2

Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified win...")
  delete-other-windows-internal(#<window 4 on *scratch*> #<window 7 on  *Minibuf-1*>)
  delete-other-windows()
  tab-bar-new-tab-to()
  tab-new(nil)

Message #53 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Benson Chu <bensonchu457 <at> fastmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Sun, 02 Apr 2023 21:51:31 +0300

> 1. (setq debug-on-error t enable-recursive-minibuffers t)
> 2. M-:   (or any other prompt like 'M-x')
> 3. Resize the minibuffer window e.g. with the mouse to at least 4 lines high
> 4. M-x windmove-swap-states-up RET
> 5. Click on the bottom window
> 6. C-x t 2
> 7. Click on the bottom window
> 8. C-x t 2
>
> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified win...")
>   delete-other-windows-internal(#<window 4 on *scratch*> #<window 7 on  *Minibuf-1*>)
>   delete-other-windows()
>   tab-bar-new-tab-to()
>   tab-new(nil)

Maybe the simplest fix is just not to create such a broken
window configuration:

diff --git a/lisp/windmove.el b/lisp/windmove.el
index 06ce16c0d42..57511291588 100644
--- a/lisp/windmove.el
+++ b/lisp/windmove.el
@@ -724,6 +724,8 @@ windmove-swap-states-in-direction
                                            nil windmove-wrap-around 'nomini)))
     (cond ((or (null other-window) (window-minibuffer-p other-window))
            (user-error "No window %s from selected window" dir))
+          ((window-minibuffer-p (selected-window))
+           (user-error "Selected window is the minibuffer"))
           (t
            (window-swap-states nil other-window)))))

Message #56 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Benson Chu <bensonchu457 <at> fastmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Fri, 14 Apr 2023 22:03:34 -0500

[Message part 1 (text/plain, inline)]

I've done some digging into whether we can mimic OR use display-buffer
when creating a new tab, and while we could do this, we also advertise
two other behaviors for tab-bar-new-tab-choice that would make the
function needlessly complex, as use/mimicry of display-buffer would only
help in the case of when tab-bar-new-tab-choice is t.

On a side-note (side-window? haha), I've got a patch that side-steps
(hehe) the issue of modifying the 'window-side parameter completely, by
binding to window--sides-inhibit-check to t.

Having bound this, the issues wrt split-window and delete-other-windows
is no longer present, and thus we no longer have to touch the
'window-side parameter at all.

The same can't be said for the 'window-atom parameter (there's no
variable to bind to ignore checks), so it still needs to be removed in
order to ensure a safe call to delete-other-windows and split-window.

Would this be a better patch? It's now less destructive on existing
window parameters.

[0001-tab-bar-new-tab-inhibit-side-window-checks.patch (text/x-patch, inline)]

From 2eaeea1f815b5e6c75947e9373c1b2f8fc539344 Mon Sep 17 00:00:00 2001
From: Benson Chu <bensonchu457 <at> gmail.com>
Date: Fri, 24 Mar 2023 15:38:03 -0500
Subject: [PATCH] ; tab-bar-new-tab inhibit side-window checks

; Previously, calling tab-bar-new-tab-to only removes the 'window-side
; property on the currently selected window, and then a call to
; delete-other-windows was made to ensure that the selected window was
; the only window. We can skip this check by shadowing
; window--sides-inhibit-check to t.

* lisp/tab-bar.el (tab-bar-new-tab-to): inhibit side-window checks

Copyright-paperwork-exempt: yes
---
 lisp/tab-bar.el | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index dce6fa735fc..c7983146bf9 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1552,15 +1552,14 @@ tab-bar-new-tab-to
       ;; Handle the case when it's called in the active minibuffer.
       (when (minibuffer-selected-window)
         (select-window (minibuffer-selected-window)))
-      ;; Remove window parameters that can cause problems
-      ;; with `delete-other-windows' and `split-window'.
-      (unless (eq tab-bar-new-tab-choice 'clone)
-        (set-window-parameter nil 'window-atom nil)
-        (set-window-parameter nil 'window-side nil))
-      (let ((ignore-window-parameters t))
+      (let ((ignore-window-parameters t)
+            (window--sides-inhibit-check t))
         (if (eq tab-bar-new-tab-choice 'clone)
             ;; Create new unique windows with the same layout
             (window-state-put (window-state-get))
+          ;; Remove window parameters that can cause problems
+          ;; with `delete-other-windows' and `split-window'.
+          (set-window-parameter nil 'window-atom nil)
           (delete-other-windows)
           (if (eq tab-bar-new-tab-choice 'window)
               ;; Create new unique window from remaining window
-- 
2.40.0

[Message part 3 (text/plain, inline)]

Juri Linkov <juri <at> linkov.net> writes:

>> 1. (setq debug-on-error t enable-recursive-minibuffers t)
>> 2. M-:   (or any other prompt like 'M-x')
>> 3. Resize the minibuffer window e.g. with the mouse to at least 4 lines high
>> 4. M-x windmove-swap-states-up RET
>> 5. Click on the bottom window
>> 6. C-x t 2
>> 7. Click on the bottom window
>> 8. C-x t 2
>>
>> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified win...")
>>   delete-other-windows-internal(#<window 4 on *scratch*> #<window 7 on  *Minibuf-1*>)
>>   delete-other-windows()
>>   tab-bar-new-tab-to()
>>   tab-new(nil)
>
> Maybe the simplest fix is just not to create such a broken
> window configuration:
>
> diff --git a/lisp/windmove.el b/lisp/windmove.el
> index 06ce16c0d42..57511291588 100644
> --- a/lisp/windmove.el
> +++ b/lisp/windmove.el
> @@ -724,6 +724,8 @@ windmove-swap-states-in-direction
>                                             nil windmove-wrap-around 'nomini)))
>      (cond ((or (null other-window) (window-minibuffer-p other-window))
>             (user-error "No window %s from selected window" dir))
> +          ((window-minibuffer-p (selected-window))
> +           (user-error "Selected window is the minibuffer"))
>            (t
>             (window-swap-states nil other-window)))))

Message #59 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Benson Chu <bensonchu457 <at> fastmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Sat, 15 Apr 2023 21:42:22 +0300

> On a side-note (side-window? haha), I've got a patch that side-steps
> (hehe) the issue of modifying the 'window-side parameter completely, by
> binding to window--sides-inhibit-check to t.

Thanks, window--sides-inhibit-check is a good find.
Let me test it for a while.

Message #62 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Benson Chu <bensonchu457 <at> fastmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Tue, 18 Apr 2023 09:58:10 +0300

>> On a side-note (side-window? haha), I've got a patch that side-steps
>> (hehe) the issue of modifying the 'window-side parameter completely, by
>> binding to window--sides-inhibit-check to t.
>
> Thanks, window--sides-inhibit-check is a good find.
> Let me test it for a while.

I still can't find a test case that could be fixed by
window--sides-inhibit-check.  Your original test case is fixed
because you removed (set-window-parameter nil 'window-side nil).
And the test case in bug#53662 doesn't need this line because
it was fixed by adding (ignore-window-parameters t).

But maybe there are cases where window--sides-inhibit-check
would help, so we could add it as a precaution.

Message #65 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Sat, 22 Apr 2023 12:05:58 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  62427 <at> debbugs.gnu.org
> Date: Tue, 18 Apr 2023 09:58:10 +0300
> 
> >> On a side-note (side-window? haha), I've got a patch that side-steps
> >> (hehe) the issue of modifying the 'window-side parameter completely, by
> >> binding to window--sides-inhibit-check to t.
> >
> > Thanks, window--sides-inhibit-check is a good find.
> > Let me test it for a while.
> 
> I still can't find a test case that could be fixed by
> window--sides-inhibit-check.  Your original test case is fixed
> because you removed (set-window-parameter nil 'window-side nil).
> And the test case in bug#53662 doesn't need this line because
> it was fixed by adding (ignore-window-parameters t).
> 
> But maybe there are cases where window--sides-inhibit-check
> would help, so we could add it as a precaution.

Should I install the last patch, or should I wait for more testing?

Message #68 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62427 <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Sun, 23 Apr 2023 19:39:10 +0300

>> >> On a side-note (side-window? haha), I've got a patch that side-steps
>> >> (hehe) the issue of modifying the 'window-side parameter completely, by
>> >> binding to window--sides-inhibit-check to t.
>> >
>> > Thanks, window--sides-inhibit-check is a good find.
>> > Let me test it for a while.
>>
>> I still can't find a test case that could be fixed by
>> window--sides-inhibit-check.  Your original test case is fixed
>> because you removed (set-window-parameter nil 'window-side nil).
>> And the test case in bug#53662 doesn't need this line because
>> it was fixed by adding (ignore-window-parameters t).
>>
>> But maybe there are cases where window--sides-inhibit-check
>> would help, so we could add it as a precaution.
>
> Should I install the last patch, or should I wait for more testing?

The patch works in two known test cases, and no more tests were found,
so probably it could be installed.

Message #73 received at 62427-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427-done <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Mon, 24 Apr 2023 14:50:38 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: bensonchu457 <at> fastmail.com,  62427 <at> debbugs.gnu.org
> Date: Sun, 23 Apr 2023 19:39:10 +0300
> 
> >> >> On a side-note (side-window? haha), I've got a patch that side-steps
> >> >> (hehe) the issue of modifying the 'window-side parameter completely, by
> >> >> binding to window--sides-inhibit-check to t.
> >> >
> >> > Thanks, window--sides-inhibit-check is a good find.
> >> > Let me test it for a while.
> >>
> >> I still can't find a test case that could be fixed by
> >> window--sides-inhibit-check.  Your original test case is fixed
> >> because you removed (set-window-parameter nil 'window-side nil).
> >> And the test case in bug#53662 doesn't need this line because
> >> it was fixed by adding (ignore-window-parameters t).
> >>
> >> But maybe there are cases where window--sides-inhibit-check
> >> would help, so we could add it as a precaution.
> >
> > Should I install the last patch, or should I wait for more testing?
> 
> The patch works in two known test cases, and no more tests were found,
> so probably it could be installed.

Thanks, installed on emacs-29 branch, and closing the bug.

Benson, any news on your copyright assignment?

Message #76 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62427 <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Tue, 25 Apr 2023 20:25:29 +0300

> Thanks, installed on emacs-29 branch, and closing the bug.

From the docstring of 'tab-bar-new-tab-choice':

  If the value is the symbol `window', then keep the selected
  window as a single window on the new tab, and keep all its
  window parameters except `window-atom' and `window-side'.
                                              ===========

So still need to remove `window-side' in this case:

(progn
  (display-buffer-in-side-window (get-buffer-create "*hello*")
                                 '((side . right)
                                   (slot . 1)))
  (select-window
   (display-buffer-in-side-window (get-buffer-create "*world*")
                                  '((side . right)
                                    (slot . 2))))
  (tab-bar-move-window-to-tab)
  (split-window))

This should handle it:

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 61e177c051d..42fc5a23990 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1588,7 +1588,9 @@ tab-bar-new-tab-to
           (delete-other-windows)
           (if (eq tab-bar-new-tab-choice 'window)
               ;; Create new unique window from remaining window
-              (window-state-put (window-state-get))
+              (progn
+                (set-window-parameter nil 'window-side nil)
+                (window-state-put (window-state-get)))
             ;; Create a new window to get rid of old window parameters
             ;; (e.g. prev/next buffers) of old window.
             (split-window) (delete-window))))

Message #79 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Benson Chu <bensonchu457 <at> fastmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Tue, 25 Apr 2023 20:30:54 +0300

>> 1. (setq debug-on-error t enable-recursive-minibuffers t)
>> 2. M-:   (or any other prompt like 'M-x')
>> 3. Resize the minibuffer window e.g. with the mouse to at least 4 lines high
>> 4. M-x windmove-swap-states-up RET
>> 5. Click on the bottom window
>> 6. C-x t 2
>> 7. Click on the bottom window
>> 8. C-x t 2
>>
>> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified win...")
>>   delete-other-windows-internal(#<window 4 on *scratch*> #<window 7 on  *Minibuf-1*>)
>>   delete-other-windows()
>>   tab-bar-new-tab-to()
>>   tab-new(nil)
>
> Maybe the simplest fix is just not to create such a broken
> window configuration:
>
> diff --git a/lisp/windmove.el b/lisp/windmove.el
> index 06ce16c0d42..57511291588 100644
> --- a/lisp/windmove.el
> +++ b/lisp/windmove.el
> @@ -724,6 +724,8 @@ windmove-swap-states-in-direction
>                                             nil windmove-wrap-around 'nomini)))
>      (cond ((or (null other-window) (window-minibuffer-p other-window))
>             (user-error "No window %s from selected window" dir))
> +          ((window-minibuffer-p (selected-window))
> +           (user-error "Selected window is the minibuffer"))
>            (t
>             (window-swap-states nil other-window)))))

This is another patch that could be installed either to emacs-29 or master.

Message #82 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62427 <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Mon, 15 May 2023 20:32:28 +0300

>> Thanks, installed on emacs-29 branch, and closing the bug.
>
> From the docstring of 'tab-bar-new-tab-choice':
>
>   If the value is the symbol `window', then keep the selected
>   window as a single window on the new tab, and keep all its
>   window parameters except `window-atom' and `window-side'.
>                                               ===========
>
> So still need to remove `window-side' in this case:
>
> diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
> index 61e177c051d..42fc5a23990 100644
> --- a/lisp/tab-bar.el
> +++ b/lisp/tab-bar.el
> @@ -1588,7 +1588,9 @@ tab-bar-new-tab-to
>            (delete-other-windows)
>            (if (eq tab-bar-new-tab-choice 'window)
>                ;; Create new unique window from remaining window
> -              (window-state-put (window-state-get))
> +              (progn
> +                (set-window-parameter nil 'window-side nil)
> +                (window-state-put (window-state-get)))
>              ;; Create a new window to get rid of old window parameters
>              ;; (e.g. prev/next buffers) of old window.
>              (split-window) (delete-window))))

Now installed on emacs-29 branch.

Message #85 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Tue, 16 May 2023 20:32:56 +0300

>>> 1. (setq debug-on-error t enable-recursive-minibuffers t)
>>> 2. M-:   (or any other prompt like 'M-x')
>>> 3. Resize the minibuffer window e.g. with the mouse to at least 4 lines high
>>> 4. M-x windmove-swap-states-up RET
>>> 5. Click on the bottom window
>>> 6. C-x t 2
>>> 7. Click on the bottom window
>>> 8. C-x t 2
>>>
>>> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified win...")
>>>   delete-other-windows-internal(#<window 4 on *scratch*> #<window 7 on  *Minibuf-1*>)
>>>   delete-other-windows()
>>>   tab-bar-new-tab-to()
>>>   tab-new(nil)
>>
>> Maybe the simplest fix is just not to create such a broken
>> window configuration:
>>
>> diff --git a/lisp/windmove.el b/lisp/windmove.el
>> index 06ce16c0d42..57511291588 100644
>> --- a/lisp/windmove.el
>> +++ b/lisp/windmove.el
>> @@ -724,6 +724,8 @@ windmove-swap-states-in-direction
>>                                             nil windmove-wrap-around 'nomini)))
>>      (cond ((or (null other-window) (window-minibuffer-p other-window))
>>             (user-error "No window %s from selected window" dir))
>> +          ((window-minibuffer-p (selected-window))
>> +           (user-error "Selected window is the minibuffer"))
>>            (t
>>             (window-swap-states nil other-window)))))
>
> This is another patch that could be installed either to emacs-29 or master.

This guard is pushed to master.  But the root problem still persists.
It can be reproduced in emacs-28/29/30:

0. emacs -Q
1. M-x
2. C-x t 2
3. C-x o     ;; switches to the minibuffer
4. C-x t 2

Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified win...")
  delete-other-windows-internal(#<window 4 on  *Minibuf-1*> #<window 8 on *scratch*>)
  delete-other-windows()
  tab-bar-new-tab-to()
  tab-new(nil)
  funcall-interactively(tab-new nil)
  command-execute(tab-new)

Message #88 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Tue, 16 May 2023 20:52:05 +0300

> But the root problem still persists.
> It can be reproduced in emacs-28/29/30:
>
> 0. emacs -Q
> 1. M-x
> 2. C-x t 2
> 3. C-x o     ;; switches to the minibuffer
> 4. C-x t 2
>
> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified win...")
>   delete-other-windows-internal(#<window 4 on  *Minibuf-1*> #<window 8 on *scratch*>)
>   delete-other-windows()
>   tab-bar-new-tab-to()
>   tab-new(nil)
>   funcall-interactively(tab-new nil)
>   command-execute(tab-new)

Martin, could you please help to debug this problem.

Does the error occur because the window configuration is broken?

Message #91 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Tue, 16 May 2023 21:23:39 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Date: Tue, 16 May 2023 20:32:56 +0300
> 
> This guard is pushed to master.  But the root problem still persists.
> It can be reproduced in emacs-28/29/30:
> 
> 0. emacs -Q
> 1. M-x
> 2. C-x t 2
> 3. C-x o     ;; switches to the minibuffer
> 4. C-x t 2

Why does the last command in this scenario make sense?

The below also signals an error:

  emacs -Q
  M-x
  C-x 2

Looks appropriate to me.

If you are arguing for a better error message in your case, I'm okay
with diagnosing that specific situation and emitting a more focused,
user-friendly error.

Message #94 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Wed, 17 May 2023 10:13:18 +0200

[Message part 1 (text/plain, inline)]

>> 0. emacs -Q
>> 1. M-x
>> 2. C-x t 2
>> 3. C-x o     ;; switches to the minibuffer
>> 4. C-x t 2
>>
>> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified win...")
>>    delete-other-windows-internal(#<window 4 on  *Minibuf-1*> #<window 8 on *scratch*>)
>>    delete-other-windows()
>>    tab-bar-new-tab-to()
>>    tab-new(nil)
>>    funcall-interactively(tab-new nil)
>>    command-execute(tab-new)
>
> Martin, could you please help to debug this problem.
>
> Does the error occur because the window configuration is broken?

No.  Binding 'ignore-window-parameters' to t skips the usual error
message that you "Can't expand minibuffer to full frame".  Does the
attached patch fix it?

martin

[delete-other-windows.diff (text/x-patch, attachment)]

Message #97 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Wed, 17 May 2023 19:32:36 +0300

>> 0. emacs -Q
>> 1. M-x
>> 2. C-x t 2
>> 3. C-x o     ;; switches to the minibuffer
>> 4. C-x t 2
>
> Why does the last command in this scenario make sense?

Because the same works in the step 2 above.

Message #100 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Wed, 17 May 2023 19:39:10 +0300

>>> 1. M-x
>>> 2. C-x t 2
>>> 3. C-x o     ;; switches to the minibuffer
>>> 4. C-x t 2
>>>
>>> Debugger entered--Lisp error: (error "Specified root is not an ancestor of specified win...")
>>>    delete-other-windows-internal(#<window 4 on  *Minibuf-1*> #<window 8 on *scratch*>)
>>>    delete-other-windows()
>>>    tab-bar-new-tab-to()
>>>    tab-new(nil)
>>>    funcall-interactively(tab-new nil)
>>>    command-execute(tab-new)
>>
>> Does the error occur because the window configuration is broken?
>
> No.  Binding 'ignore-window-parameters' to t skips the usual error
> message that you "Can't expand minibuffer to full frame".  Does the
> attached patch fix it?

This is just a better error message.

After 'M-x C-x t 2', 'minibuffer-selected-window' returns non-nil that
is used in 'tab-bar-new-tab-to' before calling 'delete-other-windows':

      ;; Handle the case when it's called in the active minibuffer.
      (when (minibuffer-selected-window)
        (select-window (minibuffer-selected-window)))

The problem is that after 'M-x C-x t 2 C-x o C-x t 2',
'minibuffer-selected-window' returns nil while
the current buffer is the minibuffer.

This is because after the first 'C-x t 2', a new window is created by:

            ;; Create a new window to get rid of old window parameters
            ;; (e.g. prev/next buffers) of old window.
            (split-window) (delete-window)

so 'minibuffer-selected-window' refers to the deleted window,
therefore nil.

Would it be possible to update 'minibuf_selected_window'
with a new window after deleting the original window?

Message #103 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Wed, 17 May 2023 20:24:20 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 62427 <at> debbugs.gnu.org
> Date: Wed, 17 May 2023 19:32:36 +0300
> 
> >> 0. emacs -Q
> >> 1. M-x
> >> 2. C-x t 2
> >> 3. C-x o     ;; switches to the minibuffer
> >> 4. C-x t 2
> >
> > Why does the last command in this scenario make sense?
> 
> Because the same works in the step 2 above.

In step 2 we are not in the minibuffer.

Message #106 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Thu, 18 May 2023 10:31:13 +0200

> Would it be possible to update 'minibuf_selected_window'
> with a new window after deleting the original window?

Not really.  We'd change existing behavior that might rely on the fact
that 'minibuffer-selected-window' returns nil once it got deleted.

Besides, it might not make you happy anyway.  With the default of
'minibuffer-follows-selected-frame', a user may correspond with a
minibuffer window that resides on another frame than that returned by
'minibuffer-selected-window' and neither minibuf_selected_window nor
Vminibuf_scroll_window may make sense any more in such context.

Why don't you use 'get-mru-window' on the frame that owns the
'minibuffer-window' instead of 'minibuffer-selected-window'?

martin

Message #109 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Thu, 18 May 2023 18:46:28 +0300

>> Would it be possible to update 'minibuf_selected_window'
>> with a new window after deleting the original window?
>
> Not really.  We'd change existing behavior that might rely on the fact
> that 'minibuffer-selected-window' returns nil once it got deleted.
>
> Besides, it might not make you happy anyway.  With the default of
> 'minibuffer-follows-selected-frame', a user may correspond with a
> minibuffer window that resides on another frame than that returned by
> 'minibuffer-selected-window' and neither minibuf_selected_window nor
> Vminibuf_scroll_window may make sense any more in such context.
>
> Why don't you use 'get-mru-window' on the frame that owns the
> 'minibuffer-window' instead of 'minibuffer-selected-window'?

Thanks for the idea, this works perfectly:

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 42fc5a23990..0ae7fb44b27 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1339,8 +1340,7 @@ tab-bar-select-tab
 
          (ws
           ;; `window-state-put' fails when called in the minibuffer
-          (when (minibuffer-selected-window)
-            (select-window (minibuffer-selected-window)))
+          (when (minibufferp) (select-window (get-mru-window)))
           (window-state-put ws nil 'safe)))
 
         ;; Select the minibuffer when it was active before switching tabs
@@ -1575,8 +1575,7 @@ tab-bar-new-tab-to
 
     (when tab-bar-new-tab-choice
       ;; Handle the case when it's called in the active minibuffer.
-      (when (minibuffer-selected-window)
-        (select-window (minibuffer-selected-window)))
+      (when (minibufferp) (select-window (get-mru-window)))
       (let ((ignore-window-parameters t)
             (window--sides-inhibit-check t))
         (if (eq tab-bar-new-tab-choice 'clone)

Message #112 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Fri, 19 May 2023 09:31:48 +0200

> +          (when (minibufferp) (select-window (get-mru-window)))

Here and below I'd use

(when (window-minibuffer-p)

because it more clearly demonstrates the idea and also handles the
(unlikely) case where a minibuffer is shown in a normal window.

>             (window-state-put ws nil 'safe)))
>
>           ;; Select the minibuffer when it was active before switching tabs
> @@ -1575,8 +1575,7 @@ tab-bar-new-tab-to
>
>       (when tab-bar-new-tab-choice
>         ;; Handle the case when it's called in the active minibuffer.
> -      (when (minibuffer-selected-window)
> -        (select-window (minibuffer-selected-window)))
> +      (when (minibufferp) (select-window (get-mru-window)))
>         (let ((ignore-window-parameters t)
>               (window--sides-inhibit-check t))
>           (if (eq tab-bar-new-tab-choice 'clone)

You might want to try this with multiple frames (some of them without
their own minibuffer window) jumping from one frame to another within
the scope of 'read-from-minibuffer'.

martin

Message #115 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 62427 <at> debbugs.gnu.org
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Fri, 19 May 2023 21:14:27 +0300

>> +          (when (minibufferp) (select-window (get-mru-window)))
>
> Here and below I'd use
>
> (when (window-minibuffer-p)
>
> because it more clearly demonstrates the idea and also handles the
> (unlikely) case where a minibuffer is shown in a normal window.

Thanks, now pushed to emacs-29.

>>             (window-state-put ws nil 'safe)))
>>
>>           ;; Select the minibuffer when it was active before switching tabs
>> @@ -1575,8 +1575,7 @@ tab-bar-new-tab-to
>>
>>       (when tab-bar-new-tab-choice
>>         ;; Handle the case when it's called in the active minibuffer.
>> -      (when (minibuffer-selected-window)
>> -        (select-window (minibuffer-selected-window)))
>> +      (when (minibufferp) (select-window (get-mru-window)))
>>         (let ((ignore-window-parameters t)
>>               (window--sides-inhibit-check t))
>>           (if (eq tab-bar-new-tab-choice 'clone)
>
> You might want to try this with multiple frames (some of them without
> their own minibuffer window) jumping from one frame to another within
> the scope of 'read-from-minibuffer'.

I confirm that this works correctly.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.