bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windo


From: Benson Chu
Subject: bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows
Date: Tue, 28 Mar 2023 11:17:29 -0500
User-agent: mu4e 1.8.14; emacs 30.0.50

> 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@gnu.org> writes:

>> Date: Mon, 27 Mar 2023 12:43:31 -0500
>> From: "Benson Chu" <bensonchu457@fastmail.com>
>> Cc: 62427@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@linkov.net>
>> >> Cc: bensonchu457@fastmail.com,  62427@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?






reply via email to

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