From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#38354: 27.0.50; Implement display action display-buffer-in-tab Date: Tue, 3 Dec 2019 10:18:02 +0100 Message-ID: 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; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="231546"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38354@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 03 10:29:30 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 1ic4Ur-000y65-2a for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2019 10:29:29 +0100 Original-Received: from localhost ([::1]:50544 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ic4Uo-0004aA-8E for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2019 04:29:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44885) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ic4Km-0006t4-HI for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 04:19:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ic4Kk-0004B7-8c for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 04:19:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33298) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ic4Kj-00049x-Ud for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 04:19:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ic4Kj-00040X-P3 for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 04:19:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Dec 2019 09:19: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.157536469515331 (code B ref 38354); Tue, 03 Dec 2019 09:19:01 +0000 Original-Received: (at 38354) by debbugs.gnu.org; 3 Dec 2019 09:18:15 +0000 Original-Received: from localhost ([127.0.0.1]:39268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ic4Jz-0003zD-DH for submit@debbugs.gnu.org; Tue, 03 Dec 2019 04:18:15 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:33595) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ic4Jw-0003yw-OS for 38354@debbugs.gnu.org; Tue, 03 Dec 2019 04:18:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575364683; bh=s4V9ERVN5Sd6AQsW+aaBogkQI/JHw1xz5ySD1iivyW8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=TLXulUoOT2Z56ic7jZcJX2q5lRQcWYjHDib2a3zVomGZgGSAn+r4wReJ+Gay7WTL/ ezXy56c8w+ZhnAbVgVtwDqfAb7aIhIYUfAsFy40Ij7Uc3zgvIgxlTKTrdNr9ZByvrA 4gEgU2dSNjnFvkop+ZH7E7Gv53oolpQyK/GIMf9k= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.201]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M59GG-1iayOF05Se-001Ajg; Tue, 03 Dec 2019 10:18:03 +0100 In-Reply-To: <87h82i9tvd.fsf@mail.linkov.net> Content-Language: de-AT X-Provags-ID: V03:K1:H8eef2qokH7YdX/uFSUy+nhmwLUYYqpXBBYbOtdo5rEEshtXUfD nKidGmczRoOQkBVxaKLpyjYJrxKMn0PxXs21R2cpw2So7vVS1JZGB2KHXLp/7WYPC4WJ7PW NDMQEPH+Z/R/W7viuE9GzOWXIfEqQcY8V4NXCe9tqRAFqCQ54ebY+s4u5lHaSlX1vll1q47 rf/oA3gmBZBo+7X8KI8pw== X-UI-Out-Filterresults: notjunk:1;V03:K0:J41mM0SghJQ=:dM+5ACHxX/Ss2bvOXl1MKM QFZ/CL4e+DWxAnxnzDdpBzHhO3A9S+7HzFNyfxlYeYqFaiKhZIOnz/GbfnO+WVDXf6Z2QsYL+ QnRsmmaaw9GAQCb+s0OoTtSa2xXLv+J8LpQQUJF9maRQLxpC7htJZjm87j3BNt8JnVSy6m+XG VXct7nGqsEdy4rT90tO9guc3tw2DsjUNpH8Vdk3ayNxjvj3P0DKj0lskodJ6j+meP3wS2Yt64 is6dbcKKGNQFNHYWLpyp5JBGDrknCE/rdmGcmGI/En0wqTq8bK28E0dwPs1TJbqlW+xKujaZh FwLjPaUkuwnV9FaJCBRRMPbNCSXwarGsiwbzi+Z9PLefXT//Y2+NCzHIKvfTAU2Y7ZnAxxF9z WpaZqMtv1qVwesRjd8XA+86ci17kD4q8EEGy3y/8/+/1cfGio1XZJ2H8VJ+HV8/utpGBUEYny juJADRDy5DfRnycjivbImHH4+Hfnyd7DGGE+LhwnfT0udrsJ2Gm28BNwmOaKX25WTaJ9pNymx xZtObjV2TextjVBFKqg0sRAfx/GXGRy5taGuEwmliDIVlIb7V1DD7vANqZ+tEHfDhElw3jEDw 3r9An1rSlxZoQEIBuEuTe8bqqn/JvSacPsk2eFISqBE/VZuNS5dzaa6bFwUoSuCk+O9ptXXVR 8kf72v8pZ7KnRafVg6Mbdp/Er3Zmf/L+5axaVjzqP9mF25gVhzW9Wk1T8SlRNGo2qzqcOBT7n x714TZ0osB3XERaErrP6BzLIvgNavW6CrEJLPKKouXP2Kg9clgLbwGkTzhZe1Qe91qqJ8gyv 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:172804 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. >> - 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." is better. Also the 'lambda's following the 'seq-some' should be moved to a new line to keep line lengths within their limits. 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? An aside: Are you sure that 'tab-bar-tabs' should always work on the selected frame and not take a frame as argument? > 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? >>> By default, a new tab starts with the buffer that was current >>> before calling the command that adds a new tab. >> >> The current buffer is IMHO a much too obscure object to consider here. >> Don't you mean the buffer of the selected window? > > The manual refers to the default value of tab-bar-new-tab-choice > with its docstring: > > 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. martin