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 15:42:41 +0300 Message-ID: <835yal82ta.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37345"; 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 14:43:32 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 1ph8fk-0009WI-RO for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Mar 2023 14:43:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ph8fM-0000S9-0M; Tue, 28 Mar 2023 08:43:08 -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 1ph8fH-0000Rn-0b for bug-gnu-emacs@gnu.org; Tue, 28 Mar 2023 08:43: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 1ph8fG-0007HC-5Z for bug-gnu-emacs@gnu.org; Tue, 28 Mar 2023 08:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ph8fF-0007tv-Nf for bug-gnu-emacs@gnu.org; Tue, 28 Mar 2023 08:43:01 -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 12:43:01 +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.168000736630333 (code B ref 62427); Tue, 28 Mar 2023 12:43:01 +0000 Original-Received: (at 62427) by debbugs.gnu.org; 28 Mar 2023 12:42:46 +0000 Original-Received: from localhost ([127.0.0.1]:49141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ph8ez-0007tA-TD for submit@debbugs.gnu.org; Tue, 28 Mar 2023 08:42:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ph8ex-0007sw-E4 for 62427@debbugs.gnu.org; Tue, 28 Mar 2023 08:42:45 -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 1ph8er-0007CU-9p; Tue, 28 Mar 2023 08:42:37 -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=KjWKXvTJbg6V63LaNdFEFE25hCpkIxs0rgZDuGRTDDQ=; b=qOnkLgN8M97J TYrs3m7akrWZK4ss7DhWspR/f5YbWYT8Ed/ei1UlSh3tpMglBaSjJdA0cC5W2Aenm+nYg4txeXDkN 2shwZalzsjj5507o/tTJTBLiBc5AflHmUjGLqUfOwzGT6D1A8Qhb49LOc8z5p0pPnEOEpAUhoJC6R UR4NPXGo6pNoYq9vRVF/IKboqs/7vlRh9q534THfApQEQfqipsgFZVdKUmDuA0EroPOo8IyWP5eGH /mho4PMWxwkh30bVtUq5ygeYHaN+1cYwPCr8/2exF0ao0zAssCUENwZReGWPqooVEESKs9mAcWvjA ndc1wO2enQOHAdav4r3Azw==; 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 1ph8eq-000395-5h; Tue, 28 Mar 2023 08:42:36 -0400 In-Reply-To: (bensonchu457@fastmail.com) 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:258805 Archived-At: > 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?