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: Fri, 29 Nov 2019 10:24:29 +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> 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="145416"; 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 Fri Nov 29 10:47:09 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 1iacrl-000bhS-2a for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Nov 2019 10:47:09 +0100 Original-Received: from localhost ([::1]:56462 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iacri-0000jv-4m for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Nov 2019 04:47:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40909) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iacWV-0003tA-4L for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2019 04:25:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iacWQ-0005XT-Mp for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2019 04:25:08 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53386) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iacWP-0005PY-HD for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2019 04:25:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iacWM-0002ts-E8 for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2019 04:25: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: Fri, 29 Nov 2019 09:25: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.157501947811109 (code B ref 38354); Fri, 29 Nov 2019 09:25:02 +0000 Original-Received: (at 38354) by debbugs.gnu.org; 29 Nov 2019 09:24:38 +0000 Original-Received: from localhost ([127.0.0.1]:59358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iacVx-0002t7-Q9 for submit@debbugs.gnu.org; Fri, 29 Nov 2019 04:24:38 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:47987) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iacVv-0002su-K1 for 38354@debbugs.gnu.org; Fri, 29 Nov 2019 04:24:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575019467; bh=ug2aaNw3LsDDweOCm3Tpby8AMWxM28AL5X9ClRtfYH4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=FyBxW9tCq4wHIHtOvFe8u4CY32bSzz2+Ja5rDd+EHDtC1mJfqE7Qqpcrh3xiyBy8n sdVlugdSAmmGWT7Iux/C+/w3chqDBi6CqqOM+PZ1eXRSO1LU1R5JG8+nZJYyKHqycd 6xayeADWyT9KGGulWfxLCVmas/kaNiUffKdlvba8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.36]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MuDbx-1hnCeU0vKH-00uc8B; Fri, 29 Nov 2019 10:24:27 +0100 In-Reply-To: <87r21r389g.fsf@mail.linkov.net> Content-Language: de-AT X-Provags-ID: V03:K1:4W30AJGLnOzxfJVhf3kbspbGfM3ytmPEME25NzFmc/eOYeaOehs fhvF3ozRIZcxDfnzRhvXfyI2KKB5Nz/8OHeiJ8MTO6MOCUpOfcUvQhM6hFITKAxZYH53+61 L/nhLkN1CaadsCplC18JoVqyi5P3yY9QTqxKOBpJMywoay/Wi5yfSMjXBvEkNB167e6Q0Vt 1ju7TAud4IqoBtpxbldEw== X-UI-Out-Filterresults: notjunk:1;V03:K0:NMCzmO2RMuU=:oNk/MZEjbBAZPXqGYqdcPe FeqV5FRPK53GfPqdHFkDTJr45RZ69EEPX6SeHOaiY0tp8CCWRkS30aiYAEfrni2MzMoqcSNRb Zt2WP0RgtiaGo9UqQN2nfgErFiGacSfkH9yLYUBFfdeU8M6gXW1dmxwq5d0PVg4/rkanAQAGm n4cahTBVtDsnW2hXKgzYbIvu1VtCncQ710zdng0fxuHCnN3ACs+Ed1333qAeYLzTb6ks5RUfM l+kvD98Gs0W4ZbOHPmwAH9ONbjVENtUsG+fVEW6DNuXd1ZMTiGgtCRgimEZXcMRYe4jdJ5owb JzL0lbZd5ZtlD1ynrKVCGcn/WEe9DIggARHTJ4AOKQLGa//nPHS4fW30j1XngK7OHtahDapyE hRm99ZOMtCIPEgdZdKDM2D6dRnQWsGJoNh+S7F4dzlQvJUvKCwpYDHsQUBn2Lh5tbR8bywtfo D8jlTkPQpT8b4eZga0xm7z5pWLrMzFOb6daQwX/WucrV0BZtr6r7p4539f6678+xRwrw0NXKa kgm7ZPqGlxQ73wKcucxrz77GrDLVCUnzTN1S8yLBAcqZRz8il2DX3Xy6QsW7X+ICbtQJ1mqwo bTpIx6FC+jjEyIEsvRY5IISQCE9eJoGvjATiQ0HZhGLLfTB8XYVGoqznjToLKRUX0bJTOqnuE ofGJVO800ikMURtGVi/C7qkyIASsLdk0gL9VOVhJjDuNcIRbcSdI3Kfe871yc6mQNLSqm7K/l 3xRf79/x8aMBOQ2rWrKMfM+bD0waD12GW07LuqAHn/GtWhwS6lq3cDYbeK6OGF3ajcj3I7qx 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:172635 Archived-At: >>> (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. > > Maybe like having the terms "visible frame" and "iconified frame", > we should use the terms "current tab" and "inactive tabs". IIUC, during one and the same session any tab is frame-local, can be shown only on one and the same frame. Deleting a frame kills its tabs too, due to our implementation of window configurations. Right? If so, then we should decide whether we always want to stick to that limitation or, eventually allow moving tabs between frames, probably using window states for that purpose. And we have to decide whether such moving of a tab would mean making a completely self-reliant copy of it or keep properties of it shared among frames. And eventually we should decide whether tabs could become first-class citizens - have a life of their own without being attached to any frame. Once we have decided on what to do here, we can try finding an appropriate nomenclature. That is, for each tab we can then either find a function called 'tab-frame' (to return its one and only frame) or 'tab-frame-list' (to return a possibly empty list of all frames that currently have that tab in their tab-bar). For each frame, we should use 'frame-tab(s)-list' for returning all tabs in their tab-bar, 'frame-selected|current|active-tab' for returning the tab currently shown on that frame. Maybe we could use a fitting ALL-FRAMES arguments to return all tabs in tab-bars of all visible, visible or iconified, ... frames with a function called 'tab(s)-list' or the like. In either case, a suitable, possibly expandable, nomenclature should be established now - we already have enough examples of clashes in our present frames/windows/buffer naming conventions. >> Wouldn't something like 'tab-bar-buffer-present-in-tabs-p' or >> 'tab-bar-buffer-in-tabs-p' be more intuitive? > > Instead of suffix '-p' that assumes the function returns a boolean value, > better to return the found tab with the function name 'tab-bar-buffer-in-tab'. Sure. You just have to decide here and now on the arguments of that function: Which tabs to search for the buffer? > Anyway it seems better not to use the word "displayed". "Displayed" and "shown" are useful for doc-strings and manuals. Elsewhere, they can be ambiguous. >> 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? > > This means we need to add another dimension: first to look for the buffer > in all tabs of the selected frame, then look in tabs of other frames: > visible, iconified, or on any frame. See below. >>>> '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. > > I don't understand. Should ALIST look like this? > > (push '("test1" . > ((display-buffer-reuse-window display-buffer-in-tab) > (reusable-frames . visible) > (name . "Tab1"))) > display-buffer-alist) What would be the downside of it? The 'reusable-frames' would specify the list of frames to investigate - the other dimension you mentioned above. BTW: In the manual you write: By default, a new tab starts with the current buffer that was current before calling the command that adds a new tab. That's confusing, at least. martin