From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows Date: Tue, 28 Mar 2023 20:11:12 +0300 Message-ID: <83wn307qdr.fsf@gnu.org> References: <875yapvoxh.fsf@fastmail.com> <86jzz4mynj.fsf@mail.linkov.net> <83cz4wb0vz.fsf@gnu.org> <865yamhdx7.fsf@mail.linkov.net> <83cz4u9uz1.fsf@gnu.org> <86jzz2f8si.fsf@mail.linkov.net> <83sfdq86pi.fsf@gnu.org> <835yal82ta.fsf@gnu.org> <87a5zwzvga.fsf@fastmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17953"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62427@debbugs.gnu.org, juri@linkov.net To: Benson Chu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 28 19:12:37 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1phCs9-0004VE-EG for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Mar 2023 19:12:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phCrc-0003ua-7m; Tue, 28 Mar 2023 13:12:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1phCrb-0003uQ-6o for bug-gnu-emacs@gnu.org; Tue, 28 Mar 2023 13:12:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1phCra-0002pi-In for bug-gnu-emacs@gnu.org; Tue, 28 Mar 2023 13:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1phCra-00015I-E1 for bug-gnu-emacs@gnu.org; Tue, 28 Mar 2023 13:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Mar 2023 17:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62427 X-GNU-PR-Package: emacs Original-Received: via spool by 62427-submit@debbugs.gnu.org id=B62427.16800234774114 (code B ref 62427); Tue, 28 Mar 2023 17:12:02 +0000 Original-Received: (at 62427) by debbugs.gnu.org; 28 Mar 2023 17:11:17 +0000 Original-Received: from localhost ([127.0.0.1]:50637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phCqq-00014I-PH for submit@debbugs.gnu.org; Tue, 28 Mar 2023 13:11:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58292) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phCqo-000144-Ju for 62427@debbugs.gnu.org; Tue, 28 Mar 2023 13:11:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1phCqi-0002W5-2Y; Tue, 28 Mar 2023 13:11:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FUZEmEc4tgISthY0c3FWTVLaeCNihXNLibe/wf2XsLk=; b=HOoOrSM7ZCZL Alpcq+MLv2t0ce/uVSJKLSH97A1xaEdGfyXsprSblIT1W69rJHCbj0Rp7fdXkQfXe4CsYj9ANDyDP xzFkg9Xa5ToInTjzhVrRo+BaYmxeWzeuFHMCY+2mpXMHQy9gb07P2YzpT+KjcUc95Ou+DP24pEbY/ 2d9mz0309Wyvis+bn4XZzi0HrMAYIYioebW0jQlW6w5iG5TM5urotp3Axvge22214bLOTwB6Sqlpo 8aOQ3Bi/qUUnZXclRQ79Bvrkc1PWwdDzEHzhShEks3+JWcLo/DGgQUlBophRa3EJHfn+sb3oXI0p9 27X2xZOZmaXbsfsV6yfsGQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1phCqg-0004Zd-I8; Tue, 28 Mar 2023 13:11:07 -0400 In-Reply-To: <87a5zwzvga.fsf@fastmail.com> (message from Benson Chu on Tue, 28 Mar 2023 11:17:29 -0500) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:258816 Archived-At: > From: Benson Chu > 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?