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: Wed, 4 Dec 2019 10:22:39 +0100 Message-ID: <6fbb734e-2fce-c148-0387-8cbe9bba649c@gmx.at> 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> <87pnh5m16o.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="26025"; 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 Wed Dec 04 11:07:11 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 1icRYp-0006Xs-TU for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Dec 2019 11:07:08 +0100 Original-Received: from localhost ([::1]:36396 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icRYm-0000xh-GM for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Dec 2019 05:07:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39682) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icQsF-0003Nt-Ns for bug-gnu-emacs@gnu.org; Wed, 04 Dec 2019 04:23:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1icQsD-0007nv-SP for bug-gnu-emacs@gnu.org; Wed, 04 Dec 2019 04:23:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35472) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1icQsC-0007lI-PW for bug-gnu-emacs@gnu.org; Wed, 04 Dec 2019 04:23:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1icQsA-000162-GI for bug-gnu-emacs@gnu.org; Wed, 04 Dec 2019 04:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Dec 2019 09:23:02 +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.15754513744176 (code B ref 38354); Wed, 04 Dec 2019 09:23:02 +0000 Original-Received: (at 38354) by debbugs.gnu.org; 4 Dec 2019 09:22:54 +0000 Original-Received: from localhost ([127.0.0.1]:41445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icQs2-00015B-4L for submit@debbugs.gnu.org; Wed, 04 Dec 2019 04:22:54 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:48965) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icQrz-00014m-M2 for 38354@debbugs.gnu.org; Wed, 04 Dec 2019 04:22:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575451360; bh=jav9F8d7jsYaMDsAGknF2YVPGUqJfzchZqugsdWIq18=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=LWes38pMYXGTrrYQjgswjtg0WPr7wuZ6hsdLgZXOEdh6fspR6HHFkt1tPigpJoiGj 0aBdc04gYnFrumdnG8X93NYxbuAZvtTr+d/2nh+V9ZDLDvgYy0SoCBCoHbQQLrSEXK GHXY1kBbWzYE1X69xIRvtrt79CWXTXgm+A08Nkoo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.145]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M5wLT-1iiBEh1PVz-007So4; Wed, 04 Dec 2019 10:22:40 +0100 In-Reply-To: <87pnh5m16o.fsf@mail.linkov.net> Content-Language: de-AT X-Provags-ID: V03:K1:5CFpWXif8atQhTYalH9IeJvIIx0CSlkoEDrr2EA2y3+CAX4Bha2 t8iF8c3fnKU7GHQoSPm3WPgX3o7SHlEZT8BJO8wQQoUv+DrXYiINjm/uy/4XYKtvomjlIyp 3WBS1Hfo/Nv/TDom5s/SdmroUwUmWhOSb3eGqcTie8rd+/XL2lm03NmJzZwASaN8DTvCoct oDpKwTpINhF9xnfleyzQQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:DJruHFjtvjM=:NWAbRNtYwofZl9xBR/4v7G YyROXRAS/09RWg0T8j1YZa2FZvgK6gjvhHVMut/Z3OcqQNSrorx38A+5nlUN97Jsw2my1XTes N9POEvLFJGXMq41/kaK12+EcvtaY8LdizwT5IN2zpIkkBWVKm3Flejw+5QMih6DsFHLixZ4rz 7yapeWaqoBDosqqdtiQ9be4BjeBzeJeuXHdx1+kPq4h8MqngYy45dwQ9OvXtKdd5LBn0y8piA e4Ph5K2ipl2ZxWWL3ujm/KhgPxGHi1GxO0hxuInlRz3bggqsqxTe5Kc2tLM0Ib3kKmm9f8jxu /pZ7hA1HpUiImsV5KOmbu2GCAv6hLdRKYNNnxVfv1Zy1/ljFqxNZwEn+SHNEMGmi+MKlYVe7U h4WsyO3IUKSGhA4ULUkgIJIqjOvEf/Nav+Joe4hEawgWVO1hOnkq9AR34QvYEdhsOg/uSSh+4 Bks5sDxIm/OoPVJLMc2OtZ59T9Ip3STtcWKwGyRiQMzA7s1wIvofuOcwQKsJDrkv0FG6/fXeH 2BkTsH6J5EpOpjELIspj6NVJRSFf7Tq59HHDUpH/TegR9ZIDbxMp4X5AKdjzbM8e2pCRNufQN fdcIMYB66nRGXwHqDCo8TunTt9cGmN9+41k6/9PeqTREmwhRail8AYVIAaGR+bWs43f536kRL /OH+Ke4G3pCWppKlAkm/d+PJDsi5rA+U26on+yNrKWz1w8ShCR72bkuG9BMK7P/LuAN7bNX61 DN3nvAGzzMccy0M+Rb5zcAzBddErT+2HPLrI/Q+xFVxx+fCA7VoSjxAxmopIYKXPlndXQf7/ 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:172830 Archived-At: >>> 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? By no means. I meant to add a 'tab-bar-lines' entry to the list of frame parameters so one can override the standard behavior for individual frames as one can do with the =E2=80=98menu-bar-lines=E2=80=99= and 'tool-bar-lines' parameters. (Obviously, that naming convention is silly because one cannot use it to change the number of lines these objects have.) > Then I'm not sure. But generally sounds like the right thing to do > sometime. [...] >> 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? No. I meant that it should continue to scan frames as long as it has not found a window showing that buffer. During that scan it would record the first tab that has a window whose buffer is the one searched for. The return value would then be preferably (the tab of) a window actually showing the buffer or, if no such window exists, a tab that has a window whose buffer is the one searched for. > 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? It does. But I don't say that 'display-buffer-in-tab' must do the same. What I meant was, as sketched above, to prefer a tab where a window already shows the buffer to tabs that would show the buffer but only if they were current/active or tabs where such a buffer window would have to be added first. > 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 thi= ng: > 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. Then 'tab-bar-close-tab' is probably the wrong function to call here. But why do you want to close a tab (an entire window configuration) here? Shouldn't 'quit-restore-window' just remove that window from a tab, that is, update the current tab of that frame to what it is? Or does the current tab of a frame not necessarily match that frame's window configuration? martin