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, 27 Nov 2019 10:49:17 +0100 Message-ID: <7979be54-2a01-2e97-d956-2500e7999e26@gmx.at> References: <87imna2nsi.fsf@mail.linkov.net> <8736ea5kcz.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="40793"; 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 Nov 27 10:50:47 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 1iZtyB-000AT6-En for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Nov 2019 10:50:47 +0100 Original-Received: from localhost ([::1]:36414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZty9-0000O6-BT for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Nov 2019 04:50:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57695) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZtxT-0000Le-1q for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 04:50:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZtxR-00073o-Uj for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 04:50:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47476) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iZtxR-00073c-Ly for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 04:50:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iZtxR-0003ZN-Jg for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 04:50: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: Wed, 27 Nov 2019 09:50: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.157484817013669 (code B ref 38354); Wed, 27 Nov 2019 09:50:01 +0000 Original-Received: (at 38354) by debbugs.gnu.org; 27 Nov 2019 09:49:30 +0000 Original-Received: from localhost ([127.0.0.1]:53449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZtww-0003YP-9p for submit@debbugs.gnu.org; Wed, 27 Nov 2019 04:49:30 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:50351) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZtwu-0003YA-7D for 38354@debbugs.gnu.org; Wed, 27 Nov 2019 04:49:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574848158; bh=/MdWraiEpZYW+Ru9l9D6hyhMwuKYXbbwiQqFof82/ss=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Q8BIfUw7T5Ymf8z5jaxQml5C0+IM85FtXc3tegSZyMBDvh0qtCTfHO+redYELKiiG JtT72S2/azifqt/JMUUwEdZxYkpELzOGhcZmePMyiRhC7y8pTasnEKJkoP6F6lCXbd yxF+I+K/tPTPRJ1yeNm3xVay1juJKwjRbCU1WiPE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.23]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MHXFr-1ied2t26HB-00DZCL; Wed, 27 Nov 2019 10:49:18 +0100 In-Reply-To: <8736ea5kcz.fsf@mail.linkov.net> Content-Language: de-AT X-Provags-ID: V03:K1:UlOMSNOuoS0Rk8qHlUDTAqwfUCUbxldXMGrF6kJ72oQUHBUt82D 2hBXhPjFoO4PLjalbNnaoHJC+SSO0U4cg/YV3vq4SBr0p1Anophi1WtDT9zs4CxdN2mOVJl 2G68RfYF6wDjEJCaU5f/OVIWL93ke5epfH0aWcj6AdDLa9gMovYu9z+fRDTcXJ8JIARhfEN BxcGGM8DFix4Tl24CU2nw== X-UI-Out-Filterresults: notjunk:1;V03:K0:5P4FkViLTJ8=:OwGvZXIxyreDJPraSxy5VW PouB23hKspewQsRlINeyhCSpF8vCRYog9kaJzFeTiK3wH5LiYbAVeOSGmCwuCA2A+Si9fUwsW jUcSEcZudnO+CSFrjnMuHC1X/iVS0h+vqMufOanB7Os6pRCW1NgWE/itSZg6/mBM5dKgor3AJ MoNPjv0szwVpgZN/sdY2KvQ7NuuS4ecokkOcHTI8ycMgI0SlIndredSfg/+ugBiI94zG2AYTT a/HegQ4h7oFNltiAK+x3D82EBs+ZANrG1lSLndPHiBEhiZ6o4rUaQ3CsMJW0bAtXsjq7RuBu8 cz83PcbGUOdVlX1up5LApTZE9/KculX1AbQXmIbu4Sw54a90Mv1t5uTEiG6DKLSHTY1RBtycm KxEIcJUzATiPaR+HLZ/2FPCnOCeSmAJN2dl4a0QhLSjZI9OROso6yiHlfIV0ZlrqJU+WMZ4xc 8P1U1WYmipmV3teA0pc/pR8p7IAzbqI8Bl5Sa7pOHzwv2FaG3fkvqM9MzLjb74MoawxYqLWel JVlO8kdmPvIHjus1DtCPyaGXx+5zvO9+Tjg/BiQ/Ro1xrp58PC664xAum6QzpZI6/14nvmbuS lwp65GeSsRwlfR/AQ8/BHNGlXrZ74HVf2VZHWZBe9IIkEJe281w482vKg4uAxYFVGue44elCH 72dXnJ+qtjAN7lR5Y6g3/5pSme7vuL7wVl1TMlFwyS/t2+qlbfYLGcA96QpdylpL6x/Mge0pJ qRmuHqOEOkP22bHIQrJU7yu+PBRBgwczEMigo5pmBgdahsGXe6iXiyFXOFRLC6WZohypuv+F 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:172516 Archived-At: > display-buffer-in-tab is implemented now, but we need also an action > to display the buffer in an existing tab if such buffer is > already displayed in it. Could we please clarify the term "display(ed)" in this context. IIUC you use it - to say that a buffer is part of a tab (a window configuration that can be shown on a frame), and - to say that a buffer is actually displayed on a frame that has a tab-bar. Right? Then the former should not use the term "display(ed)" but maybe something like "tab(bed)". "Tab a buffer" would then mean to make sure that the buffer is part of a tab, "tabbed" that it is part of at least one tab. > I tried to copy an existing action > that supports frames, but can't find such a frame action that > would select another frame if the buffer is already is displayed in it. > Does such frame action exist whose behavior could be copied to tabs? 'display-buffer-reuse-window' together with 'reusable-frames' should have all the ingredients for this. What is missing? > This will require a new function function tab-bar-buffer-visible-in-tabs. What would "visible" precisely stand for here? And why "tabs" indiscriminately? Don't you ever want to check for presence or visibility in a specific tab only? > Also I use this function in a wrapper that kills the buffer, such wrapper checks > > (tab-bar-buffer-visible-in-tabs-p (current-buffer)) > > If true, it doesn't kill the buffer, but buries it. Via 'kill-buffer-query-functions'? > So switching back to that tab still displays the buffer. When I do 'kill-buffer', I expect that buffer to get removed from 'buffer-list' and all windows showing it, that it won't be switched to by many functions and so on. Whatever we'd do, we have to manage this controversy somehow. Think of changes or the deletion of the visited files. How would we try to avoid saving such buffers to their files in that case? martin