From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#38354: 27.0.50; Implement display action display-buffer-in-tab Date: Wed, 04 Dec 2019 01:36:31 +0200 Organization: LINKOV.NET Message-ID: <87pnh5m16o.fsf@mail.linkov.net> References: <87imna2nsi.fsf@mail.linkov.net> <8736ea5kcz.fsf@mail.linkov.net> <7979be54-2a01-2e97-d956-2500e7999e26@gmx.at> <87d0dd3yb7.fsf@mail.linkov.net> <87r21r389g.fsf@mail.linkov.net> <87lfrvk7cg.fsf@mail.linkov.net> <6be9eb15-062d-b15f-04c8-993a2a2eee22@gmx.at> <87h82i9tvd.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="218224"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: 38354@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 04 00:48:33 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1icHuA-000uY7-U4 for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Dec 2019 00:48:31 +0100 Original-Received: from localhost ([::1]:60630 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icHu9-0007ea-0M for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2019 18:48:29 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55806) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icHtm-0007d9-My for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 18:48:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1icHtl-0001Pb-15 for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 18:48:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35260) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1icHti-0001OV-18 for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 18:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1icHth-0002Jb-VS for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 18:48:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Dec 2019 23:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38354 X-GNU-PR-Package: emacs Original-Received: via spool by 38354-submit@debbugs.gnu.org id=B38354.15754168338830 (code B ref 38354); Tue, 03 Dec 2019 23:48:01 +0000 Original-Received: (at 38354) by debbugs.gnu.org; 3 Dec 2019 23:47:13 +0000 Original-Received: from localhost ([127.0.0.1]:41230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icHsu-0002IL-Rd for submit@debbugs.gnu.org; Tue, 03 Dec 2019 18:47:13 -0500 Original-Received: from azure.elm.relay.mailchannels.net ([23.83.212.7]:10880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icHsr-0002IB-RG for 38354@debbugs.gnu.org; Tue, 03 Dec 2019 18:47:11 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 36A47500EED; Tue, 3 Dec 2019 23:47:08 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-6-199.trex.outbound.svc.cluster.local [100.96.6.199]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8ABC85003BC; Tue, 3 Dec 2019 23:47:07 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a18.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 03 Dec 2019 23:47:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Battle-Exultant: 3f073a6b7b5e6618_1575416827843_2421529561 X-MC-Loop-Signature: 1575416827843:450230583 X-MC-Ingress-Time: 1575416827843 Original-Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id CEFDBA3A56; Tue, 3 Dec 2019 15:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=yc2r18LhvU8ShHGfSmJh3UZicO4=; b= dcvIeYJJyi/UtwiRXXpfwjqNzuBGcnoTRJ8e9jgkJr5xE/5h4G7wSt+Y7VtRFwpu v36mgfYn3KVrBPxtHvu7O926NtazbKYflxEd94pGWD9mMkXI+XYqLLJraL0eoLWr 83islnHHbypRPTH/b6qYaIYQ211MsUwPmJLlux92UVU= Original-Received: from mail.jurta.org (m91-129-96-42.cust.tele2.ee [91.129.96.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 7AE88A3A54; Tue, 3 Dec 2019 15:47:00 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a18 In-Reply-To: (martin rudalics's message of "Tue, 3 Dec 2019 10:18:02 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:172823 Archived-At: >>> There is one thing I apparently do not understand yet: When you enable >>> 'tab-bar-mode' it is global >> >> Do you think we should have 'global-tab-bar-mode' for all frames, >> and 'tab-bar-mode' to enable/disable the tab-bar in every frame >> separately? > > In the sense that we can enable menu or tool bars for frames > individually? I think so, yes. Oh, this also means redesigning tool-bar-mode and menu-bar-mode? Then I'm not sure. But generally sounds like the right thing to do sometime. >>> - that is any window ever shown on any frame is also in at least one >>> of that frame's tabs. Is that right? So what would 'use-tabs' mean >>> here when every window is in a tab already? >> >> These windows in tabs are in window-configurations and window-states. >> Now I installed tab-bar-get-buffer-tab > > "Return a tab whose window contains BUFFER-OR-NAME, or nil if none." > > is a bit misleading, maybe > > "Return a tab with a|owning a window whose buffer is BUFFER-OR-NAME." Done. > is better. Also the 'lambda's following the 'seq-some' should be > moved to a new line to keep line lengths within their limits. Done. > In either case, do I read the code correctly that it can prefer a > window in a non-current tab to a window in a current tab on another > frame. If so, do we want that? Do you think it should return a list of all tabs owning a window with the buffer? > An aside: Are you sure that 'tab-bar-tabs' should always work on the > selected frame and not take a frame as argument? Thanks for the idea, implemented. >> that can be used >> in display-buffer-reuse-window to search the buffer >> in window-states of tabs when use-tabs is non-nil. > > Given my observation above, this can make a tab current in frame A > although the current tab of frame B already shows the buffer. Right? Why not? Does display-buffer-reuse-window currently prefers a window on the same frame even when a window on another frame also shows the same buffer? >> If t, start a new tab with the current buffer, i.e. the buffer >> that was current before calling the command that adds a new tab >> (this is the same what `make-frame' does by default). > > OK. Then my next nitpick is that the doc-string of > 'tab-bar-new-tab-choice' says > > If the value is a string, use it as a buffer name switch to a buffer > > which apparently should have "... name. Switch ..." instead. Fixed. Additional question: using quit-window on the buffer displayed by display-buffer-in-tab should close its tab. Could you recommend how to implement this? Maybe to add an additional argument CLOSE-TAB to quit-restore-window? e.g. (defun quit-restore-window (&optional window bury-or-kill close-tab) ... For testing I tried to call '(tab-bar-close-tab)' at the end of 'quit-restore-window' unconditionally, but sometimes it does wrong thing: when quitting the last window of the frame closes the frame, '(tab-bar-close-tab)' closes the tab on another frame that is selected after closing the original frame.