all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Benson Chu <bensonchu457@fastmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 62427@debbugs.gnu.org, juri@linkov.net
Subject: bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows
Date: Tue, 28 Mar 2023 11:17:29 -0500	[thread overview]
Message-ID: <87a5zwzvga.fsf@fastmail.com> (raw)
In-Reply-To: <835yal82ta.fsf@gnu.org>


> 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	other threads:[~2023-03-28 16:17 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-24 21:07 bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows Benson Chu
2023-03-25 19:14 ` Juri Linkov
2023-03-26  4:19   ` Eli Zaretskii
2023-03-27  7:05     ` Juri Linkov
2023-03-27 13:36       ` Eli Zaretskii
2023-03-27 16:39         ` Juri Linkov
2023-03-27 17:06           ` Eli Zaretskii
2023-03-27 17:43             ` Benson Chu
2023-03-28 12:42               ` Eli Zaretskii
2023-03-28 16:17                 ` Benson Chu [this message]
2023-03-28 17:11                   ` Eli Zaretskii
2023-03-28 17:39                     ` Benson Chu
2023-03-30 16:43                 ` Juri Linkov
2023-03-31 16:20                   ` Benson Chu
2023-04-01 18:25                     ` Juri Linkov
2023-04-02 18:20                       ` Juri Linkov
2023-04-02 18:51                         ` Juri Linkov
2023-04-15  3:03                           ` Benson Chu
2023-04-15 18:42                             ` Juri Linkov
2023-04-18  6:58                               ` Juri Linkov
2023-04-22  9:05                                 ` Eli Zaretskii
2023-04-23 16:39                                   ` Juri Linkov
2023-04-24 11:50                                     ` Eli Zaretskii
2023-04-25 17:25                                       ` Juri Linkov
2023-05-15 17:32                                         ` Juri Linkov
2023-04-25 17:30                           ` Juri Linkov
2023-05-16 17:32                             ` Juri Linkov
2023-05-16 17:52                               ` Juri Linkov
2023-05-17  8:13                                 ` martin rudalics
2023-05-17 16:39                                   ` Juri Linkov
2023-05-18  8:31                                     ` martin rudalics
2023-05-18 15:46                                       ` Juri Linkov
2023-05-19  7:31                                         ` martin rudalics
2023-05-19 18:14                                           ` Juri Linkov
2023-05-16 18:23                               ` Eli Zaretskii
2023-05-17 16:32                                 ` Juri Linkov
2023-05-17 17:24                                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a5zwzvga.fsf@fastmail.com \
    --to=bensonchu457@fastmail.com \
    --cc=62427@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.