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: Thu, 28 Nov 2019 10:20:59 +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> 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="54760"; 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 Thu Nov 28 10:23:08 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 1iaG0x-000E2w-AD for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Nov 2019 10:23:07 +0100 Original-Received: from localhost ([::1]:46876 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaG0u-0002RP-Tf for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Nov 2019 04:23:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41021) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaFzw-0002Q6-FY for bug-gnu-emacs@gnu.org; Thu, 28 Nov 2019 04:22:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaFzu-0004Dp-Tb for bug-gnu-emacs@gnu.org; Thu, 28 Nov 2019 04:22:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50653) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iaFzu-0004Cq-IA for bug-gnu-emacs@gnu.org; Thu, 28 Nov 2019 04:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iaFzu-0003xr-FI for bug-gnu-emacs@gnu.org; Thu, 28 Nov 2019 04:22: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: Thu, 28 Nov 2019 09:22: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.157493287215181 (code B ref 38354); Thu, 28 Nov 2019 09:22:02 +0000 Original-Received: (at 38354) by debbugs.gnu.org; 28 Nov 2019 09:21:12 +0000 Original-Received: from localhost ([127.0.0.1]:56626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iaFz5-0003wn-Lb for submit@debbugs.gnu.org; Thu, 28 Nov 2019 04:21:11 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:45951) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iaFz4-0003wa-0r for 38354@debbugs.gnu.org; Thu, 28 Nov 2019 04:21:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574932860; bh=pwO83e8VGqG94cWFIgR9EIoGdiKVwBnSMJp6wgEP+9A=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=C3k2YL45NndoXrvvKeyrUNnNF0tzudMpt2mgnTXQgkdAzVFVGh9paKS1FTGmi06/J bF2UboLvHyjmXHRdxHzqs/DmJI7wRQsUqHH60FEugsS8ZBukowcHDFZa0JOl61YKPp lTaTH9iFF/wlS3G49aHVu8eFgZ+v2XKfYCnF8vo8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.73]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MsHns-1hgeWH3jg2-00tjXW; Thu, 28 Nov 2019 10:21:00 +0100 In-Reply-To: <87d0dd3yb7.fsf@mail.linkov.net> Content-Language: de-AT X-Provags-ID: V03:K1:+FTzbcCwl4hA8cak7uQGWVLb9bLrMCgRFMVMlh3dvXOLggiu463 7oKpJaJKWjS1/lg0xSgM3y/Q4eGonC7piw6w9mF2P+oYWeHRXfe8g0Rz27GeHp+HsATBGYE SlfNkdWzcQokJ4Tq+S72orOfIFLnZerFsIR4VkUhVg7bQUlU/zhbp8k0SEdq7xI+WE2MlHR vuQCilMiubSMa745gNEew== X-UI-Out-Filterresults: notjunk:1;V03:K0:z1uKOR6tIa0=:yNZw2YAGOUyM1bGWSiplk1 RAUUsdtt2g2B0Qc4i7OJKRlwvYZNqklC9tI9RKrUmZhf9hq1TIPd5YOof/R7JSjiAPtZVB1O7 mJSDWUlzNXndvQgpxl1ikWZDKigdSHFhHsnw0QD23lXtomBHS7B7Ags2ImVPtBsI2clFUa/GE HWQqO9Y0iRgxUT3zy+ygSPJ3R6oy4l7tH1vHuTxTELumJj+9ZmGipVbWnFL+KInDtxjtdVqQW rr+ynP6EWw/XZGx8esf/RXmX+Zd21/JFr5YZeuJPm5qYEHXoqV42ZQ3LIPRjN3Ypl5q9uEwD9 1Sn51DkzbmL0KXE85GVg3UGfCMc419Ve7CqD/H7RDz2KxrpZkpIva/dtPxAIay8uB/1roggNb c9xnIR3ZxGLBImfc2HxScWVFu+QY1A2fIg/c0hjYg9cGeiMHfgy95uvLKmynmXmkuI0bF3WDx pqmk8xTcgs/m6M3YAwOb+5MaUSi+C+iSG0LqRDzoZRd2LFyz0xFKORoBotWeDedGaDtO+YZPi 0t4HC95zVSgv+AGKvozP56Y1NFHzOejCYcmyeaMnIqquQXF4pwgyHxPJbxyEt1dDonN2mjBrQ 2o90AoPkXSqqCGU0riWvLPcSnqckVUskBi9alf09R3j+/mpv2vfJKN/mbhAmeX0G4jRktDUHr wEPvmmG1s2yiqz2873s+oaBxmdNrrHb3qS/NdU+NCq1WsjHn8QtTS4HozzZWa7U2+XgPR/xs9 fUVE9ijGS6+fQei3fqmK6xsP9mZW1L4LCpkS5/NPrgkIa0jocomcU3cECfTVW2EYpnats0Xa 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:172587 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 > > In my code I use for this: > > (tab-bar-buffer-visible-in-tabs-p buffer) But this may also return non-nil when the buffer is invisible, that is not shown in any window. We already have the "visible frames" notation, including the non-obscured frames connotation, so I'd rather not use the term visible in the context of tabs. Wouldn't something like 'tab-bar-buffer-present-in-tabs-p' or 'tab-bar-buffer-in-tabs-p' be more intuitive? >> - to say that a buffer is actually displayed on a frame that has a >> tab-bar. > > In my code I use for this: > > (>= (length (get-buffer-window-list buffer t t)) 1) Why not simply 'get-buffer-window'? In either case what does the above "displayed" in >>> to display the buffer in an existing tab if such buffer is >>> already displayed in it. refer to now? The former, the latter or their > i.e. I check these situations differently, and use 'or' > to combine these conditions: > > (or (>= (length (get-buffer-window-list buffer t t)) 1) > (tab-bar-buffer-visible-in-tabs-p buffer)) > > Should these conditions be combined in one function > (if the current tab can be considered a tab as well)? 'or'? >> 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. > > Not sure if "tabbed" is the right word. None of these definitions fits: > https://www.dictionary.com/browse/tabbed > https://www.urbandictionary.com/define.php?term=tabbed 'tab' itself is already problematic, as we know. >>> This will require a new function function tab-bar-buffer-visible-in-tabs. >> >> What would "visible" precisely stand for here? > > Maybe a better word is "has"? Then the name would be tab-bar-has-buffer-in-tab. OK. But I think that the "has" is superfluous. >> And why "tabs" indiscriminately? Don't you ever want to check for >> presence or visibility in a specific tab only? > > A specific tab referred by name? Maybe such function could be useful as well. Don't you ever want to discriminate the tabs of the selected frame from the tabs of other frames? Or are they all the same? >> 'display-buffer-reuse-window' together with 'reusable-frames' should >> have all the ingredients for this. What is missing? > > Than we need to add 'reusable-tabs'? Why? If a target tab (a tab with the name specified by ALIST) exists on any frame specified by 'reusable-frames', reuse it. Otherwise make a new frame with the target tab as its only entry. >>> 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'? > > Rather calling it explicitly with a new commands, but it should be > possible to use 'kill-buffer-query-functions' too. But the idea is to _not_ kill the buffer. Right? So this might be a disconcerting effect. >>> 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? > > A buffer can't be removed from saved window-configurations and window-states. The buffer's object can be removed. The buffer reference in a saved window structure is weak, it cannot prevent collecting the buffer object. martin