From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Benson Chu Newsgroups: gmane.emacs.bugs Subject: bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows Date: Tue, 28 Mar 2023 11:17:29 -0500 Message-ID: <87a5zwzvga.fsf@fastmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5039"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.8.14; emacs 30.0.50 Cc: 62427@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 28 18:35:21 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 1phCI2-0000yz-Qw for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Mar 2023 18:35:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phCHo-000870-Nw; Tue, 28 Mar 2023 12:35: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 1phCHn-00084F-AY for bug-gnu-emacs@gnu.org; Tue, 28 Mar 2023 12:35: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 1phCHn-0002fq-1q for bug-gnu-emacs@gnu.org; Tue, 28 Mar 2023 12:35:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1phCHm-00067d-Ds for bug-gnu-emacs@gnu.org; Tue, 28 Mar 2023 12:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Benson Chu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Mar 2023 16:35: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.168002126423480 (code B ref 62427); Tue, 28 Mar 2023 16:35:02 +0000 Original-Received: (at 62427) by debbugs.gnu.org; 28 Mar 2023 16:34:24 +0000 Original-Received: from localhost ([127.0.0.1]:50585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phCHA-00066e-1v for submit@debbugs.gnu.org; Tue, 28 Mar 2023 12:34:24 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:42029) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phCH8-00066R-GA for 62427@debbugs.gnu.org; Tue, 28 Mar 2023 12:34:23 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7B4055C01C7; Tue, 28 Mar 2023 12:34:16 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 28 Mar 2023 12:34:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1680021256; x=1680107656; bh=0J G92sLsgLedOiQ9+jB2kcYMxpwhaK5HlXlmgXWVVMs=; b=FK6pGpEF4oSZv2FfSK jXQsakgDCOGBNBMXfHRsr/rf4OSL/X0occzPsavntkaEebq7RvM8QtUnMa7VXwsw gDPkDDPbkzcOQe4CdoOwlQBujN45bVjq0mcGWaF+ysxVpDPEC3eHcz5qpxrsrL7J boa61C6sX+wNoLfxLnuAKLnzPkYqZJ07B4g7UQpzkxah2ijRDwb+S9BIky1d/OKR s4rcFYTCdqBzuPZ/ehKNUiW2rpl45qdc9b4RhrUUxnJzzJB0bojcMYSi4Em487Ya nGBu66QZcaQNaa0gzR1aV5k7xSkDzuNLO8HzE5j3PWHHQZbcW975sA+NPQOQncdJ 9IlQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1680021256; x=1680107656; bh=0JG92sLsgLedO iQ9+jB2kcYMxpwhaK5HlXlmgXWVVMs=; b=ZpjiLs1CTueFG2EtgjDSjLSUluvhk cUBXw/mOhnS3ViOxbWsx0pKpfQfdjg4sOjgXfrf2cNrC+1bakKcwZrp7TCeFo5L/ JEy+OMzuUwQNGF7ilTZaWa5POOpofLSdoRB894qmeKNVoHfojIvBiopHdTDOEVCL iDVBDIOICfih0wnHNqnw9ejmI68r6NV6f8vMcmqfwegu96Gk37ACwyaQNdV+Lgrr 7OtGq0PtJCckuXCzbSQoukPMJcfPCnBtzXi97iDMNl1hqzXgv0+BtkHXx8S/r/q0 INZfOXqcLMXBPV9tclGGi1cJl67qEdB6pPP5IPaiJ2Jp2ZcrkQgelVELQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdehgedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpehffgfhvfevufffjgfkgggtsehttdertddtredtnecuhfhrohhmpeeuvghn shhonhcuvehhuhcuoegsvghnshhonhgthhhugeehjeesfhgrshhtmhgrihhlrdgtohhmqe enucggtffrrghtthgvrhhnpeffteeffeeuieffgfffteevieduhffhgeduudehudeuleet ledtvdegleeljeehleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegsvghnshhonhgthhhugeehjeesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: id5c9466e:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 28 Mar 2023 12:34:14 -0400 (EDT) In-reply-to: <835yal82ta.fsf@gnu.org> 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:258813 Archived-At: > 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 writes: >> Date: Mon, 27 Mar 2023 12:43:31 -0500 >> From: "Benson Chu" >> 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 >> >> 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?