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: Mon, 2 Dec 2019 10:40:14 +0100 Message-ID: <6be9eb15-062d-b15f-04c8-993a2a2eee22@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> 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="160274"; 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 Mon Dec 02 10:41:39 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 1ibiD4-000fTR-SB for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Dec 2019 10:41:38 +0100 Original-Received: from localhost ([::1]:32942 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibiD3-00006e-GW for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Dec 2019 04:41:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56058) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibiCV-0008NJ-Q0 for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 04:41:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibiCU-0001mQ-Kt for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 04:41:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59354) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibiCU-0001mL-Ds for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 04:41:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ibiCU-0002xK-Cd for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 04:41: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: Mon, 02 Dec 2019 09:41: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.157527962711311 (code B ref 38354); Mon, 02 Dec 2019 09:41:02 +0000 Original-Received: (at 38354) by debbugs.gnu.org; 2 Dec 2019 09:40:27 +0000 Original-Received: from localhost ([127.0.0.1]:37094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ibiBv-0002wN-3L for submit@debbugs.gnu.org; Mon, 02 Dec 2019 04:40:27 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:40165) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ibiBs-0002w8-LN for 38354@debbugs.gnu.org; Mon, 02 Dec 2019 04:40:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575279615; bh=7RvApftm8BAAetRiqOMqFYSjAMAm/IIUb/5eEo54aGQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=cxWEUbkPVWKdNtkRCCgF4/IS3aEQ3R2UWQyIzSQUC9Gamxuz3MW0a97TnoiaZ8GRy W2vLvUTCPoV7ntR95TFfseRXJdZYYFoX3T9cj6HiKmM7iuWKsDr7XN+fjBWeyD2KS2 x6phde9d26PrwdvXan8j7BH8XxRqrgKBufPLtxhw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.45]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N3se2-1hbwWF0EJE-00zjrX; Mon, 02 Dec 2019 10:40:15 +0100 In-Reply-To: <87lfrvk7cg.fsf@mail.linkov.net> Content-Language: de-AT X-Provags-ID: V03:K1:ZXSJfdqiYSHYeRDjzsZQZU2k/cYnbd+M17+gJJQYpcBGm9/n+7Q 2Yd2AQAVGyw2kCXDNu7bpaAMu6qgWCvEGEiCEAFDfixB3VvJh19xNv/WSak74ctUMSOzeyu z0fEYp7GxzlJDseCa6hvIsF+oWC4JTZpqIKXtN0kpuO69gpRsNTbbeEX4kJzc6ux2qmtZPt 7q4HBh6sqfrIJh449v/Fg== X-UI-Out-Filterresults: notjunk:1;V03:K0:CGk5ILH+UDM=:I9tIR1ndO/CTxUo8MiBWkW +em5qL7WmC4afvvd5F59OK/sLaRnKUHvrqBAW6ccIgZM/AcRcnGONQA+ROmwrDPv3RO3CHkZv bL94SaXYRzG+2/A9kEamVqJfYsnNHdrnzposBRbIP8lsqhgig8412x2Ushw9R5qRd0tsqr1F0 N61dPJ2cwji1/gpSpOV1LRqtEmrY1C9DgSi223UwzERPzUUg0vWKCprg1zGkTAr/wvJRsKZAO hlIhGZISRSS7zsMzXz1aY7uNzxD8ytX1wUVB2FQ3BpI/08bY4iJ3fUfXjToozVnFVFPQJKy4r g2NkGKdJyTt+cvt/pUqYJswpENoQCuSun9jMeogZQyDrvQiLGPharlZ7LLoc1THD1vMP9quFa NjldNA/fx2uaLSM4KdTemd+J85yOxiHjCTtOQccRCt1a5i0TeBJHF32r00Ko70esQnuBXDlGs nMGc45PFxRHOBoMXTg5mcDA4ZJZH+csBI9iENC1LAgsGKWh1eCHjIWpk3xl/M3s72XtRLi2Sm DMOZnnt0gt9UHRbMbnqcXd1hVMUAQFVGTNmJFU1VhYxuz77O3IuqNE5M2m1FWgGCiQjYeereJ wsZrB6BNPFit9e7D5nc26zEQqmPXPu6xKn/uNVq2so5Q3oKIVqu1nJTQKN0FBZajPZ5Hr/Gyl LNgrbXK75zpkn1QoucL1nUrGAGVH/df4DdapFd7+F7YHdE40/5JvLyjJ+/XSgkiHdro3N019i zSG44fMYF50B8kuzfIFLmBxq6TSmK+C/rmoviDxKnVJ/ArmKwPYFyOLNd3d/EGekZO/9m0Fa 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:172754 Archived-At: >> 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. > > There are two separate cases to consider: > > 1. Moving an inactive tab to another frame. > In this case we need to use its window-state, not window-configuration, > i.e. just delete the window-configuration from tab data, then it > could be moved to another frame without problems. > > 2. Moving the current tab to another frame. Here we need to save > window-configuration of another frame to its inactive tab, then clone > the original frame to another frame. Do you know if such a function > already exists that duplicates all frame parameters with frame-root > window-state to another frame? With "moving" I really meant "copying" or "cloning" with the additional possibility of deleting the original. So there should be only one question: Can we simply make a copy of a tab using its window state (window configurations can't be used because we cannot clone windows). If not, what is the problem? > An additional question to consider is how to interactively select > an another frame: by frame name, or using other-frame with a numeric > prefix argument? How is this question related to tabs? >>> (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. > > We need an alist entry that will tell display-buffer-reuse-window > to search in tabs. Maybe just the presence of the 'use-tabs' param > will tell display-buffer-reuse-window to search in tabs like: > > (push '("test1" . > (display-buffer-reuse-window > (reusable-frames . visible) > (use-tabs . t))) > display-buffer-alist) There is one thing I apparently do not understand yet: When you enable 'tab-bar-mode' it is global - 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? >> 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. > > Maybe this is better? > > 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? martin