[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 12:39:54 -0500 |
User-agent: |
mu4e 1.8.14; emacs 30.0.50 |
> 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@gnu.org> writes:
>> From: Benson Chu <bensonchu457@fastmail.com>
>> Cc: juri@linkov.net, 62427@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?
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, (continued)
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Juri Linkov, 2023/03/25
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Eli Zaretskii, 2023/03/26
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Juri Linkov, 2023/03/27
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Eli Zaretskii, 2023/03/27
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Juri Linkov, 2023/03/27
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Eli Zaretskii, 2023/03/27
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Benson Chu, 2023/03/27
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Eli Zaretskii, 2023/03/28
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Benson Chu, 2023/03/28
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Eli Zaretskii, 2023/03/28
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows,
Benson Chu <=
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Juri Linkov, 2023/03/30
- bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows, Benson Chu, 2023/03/31