From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Claudio Grondi Newsgroups: gmane.emacs.bugs Subject: bug#62575: 29.0.60; Tabs are not showing the right names of the buffers Date: Sun, 2 Apr 2023 17:26:09 +0200 Message-ID: <3e479430-7e02-67de-8bb5-663a2769e6c0@freenet.de> References: <7f7b17d6-63e2-d7fc-1091-802f972f9a62@freenet.de> <83cz4o17tp.fsf@gnu.org> <67687ee4-089d-7997-f9a3-afde7be8b05e@freenet.de> <83sfdjy9va.fsf@gnu.org> <86355iixt1.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26728"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: 62575@debbugs.gnu.org To: Juri Linkov , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 02 17:27:24 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pizc3-0006kn-ON for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 02 Apr 2023 17:27:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pizbs-0004nh-Bj; Sun, 02 Apr 2023 11:27:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pizbk-0004nM-HD for bug-gnu-emacs@gnu.org; Sun, 02 Apr 2023 11:27:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pizbi-0001bl-Fn for bug-gnu-emacs@gnu.org; Sun, 02 Apr 2023 11:27:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pizbh-0007L3-V8 for bug-gnu-emacs@gnu.org; Sun, 02 Apr 2023 11:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Claudio Grondi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Apr 2023 15:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62575 X-GNU-PR-Package: emacs Original-Received: via spool by 62575-submit@debbugs.gnu.org id=B62575.168044917928154 (code B ref 62575); Sun, 02 Apr 2023 15:27:01 +0000 Original-Received: (at 62575) by debbugs.gnu.org; 2 Apr 2023 15:26:19 +0000 Original-Received: from localhost ([127.0.0.1]:42456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pizb0-0007K0-Re for submit@debbugs.gnu.org; Sun, 02 Apr 2023 11:26:19 -0400 Original-Received: from mout3.freenet.de ([195.4.92.93]:46668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pizav-0007Jn-Ou for 62575@debbugs.gnu.org; Sun, 02 Apr 2023 11:26:17 -0400 Original-Received: from [195.4.92.122] (helo=sub3.freenet.de) by mout3.freenet.de with esmtpa (ID claudio.grondi@freenet.de) (port 25) (Exim 4.94.2 #2) id 1pizan-0040MC-L7; Sun, 02 Apr 2023 17:26:10 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=freenet.de; s=mjaymdexmjqk; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=pVkArrYTqQjAHq6GqkFgLFEnfii4dyYFGnxzA1VTtBg=; b=q/7cJHYQjYhOuw/BSWvbv5apDX NpQiIZpASzuaPo9JunIIVvNGkKBVrBFflxxfpAbaq/dgUVOrHzJr7NY7MAr2nwVTckxuJ2VYGAsPv UbSuEEE979ALf1Eiznrv05zO+1PQJbs2urjsHybeLh8Yy8sIwRhjq6uyElJf12yKpBGqeXoBps7Ay RkFey//2dg/aC7ZC5EI260RdP2geX3Q1B+l8dJP63As9jRSZ7kwgj9cM8FDeyWoXTNT8dPfaFEWrt CyDdZUYbBdpmsRKIVgZYTxz8C7YpmsYIA91gwH1zwc7HVDD9KSCR7F2VoHoiBcjOUY7X/sVruVDzQ JWkFoCTQ==; Original-Received: from ip-109-42-240-50.web.vodafone.de ([109.42.240.50]:31767 helo=[192.168.8.100]) by sub3.freenet.de with esmtpsa (ID claudio.grondi@freenet.de) (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (port 587) (Exim 4.94.2 #2) id 1pizas-007WTA-Jn; Sun, 02 Apr 2023 17:26:10 +0200 Content-Language: de-DE, en-US In-Reply-To: <86355iixt1.fsf@mail.linkov.net> X-FN-MUUID: 168044917082FB8BCBA20EO X-Originated-At: 109.42.240.50!31767 X-Scan-TS: Sun, 02 Apr 2023 17:26:10 +0200 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259111 Archived-At: From what I understand reading Juris response the core of the problem and reason for the issue is lack of unambiguous concept of what a Tab Bar is and what the Tabs in the Tab Bar represent. On one side the Tab Bar is considered as an aid helping to switch view to another buffer by clicking on a Tab, on the other side what is actually shown after clicking a Tab Bar is not a visualization of a buffer but visualization of what is sometimes called "root window", sometimes "window configuration", sometimes "window" and sometimes a "frame" (it is the messing around with concepts what makes it so hard to know what is right and what is wrong). To my current state of knowledge the Tabs in the Tab Bar represent in the context of Emacs what in context of an OS Desktop is called Workspace. The only difference of an Emacs Tab to a Workspace is that the Emacs Tab does not allow empty space not filled with a window showing visualization of some elisp object called a buffer. It is on one side a mess to call the file saving Emacs state .emacs.desktop suggesting that it is a desktop saved and not a 'frame' or a 'set of window configurations', on the other side in my eyes already the right wording for saving the state of all of the Workspaces called Tabs in a Tab Bar. My suggestion in this context would be not to work on a patch or on adding one more option, but to fix the problem with lack of an unambiguous concepts for 'frame', 'window', 'root window', 'window configuration', 'tab in tab-bar' first. I am aware that doing this would require to rewrite almost the entire Emacs documentation - but it appears in my eyes worth it considering the future benefits of a clear structure and well defined vocabulary to use while speaking about Emacs. Anyway: if you click a button labeled "OK" you expect that the result of it would be confirmation and not a change of a button label to "Cancel". If you click a Menu item labeled "Open File" you expect that it will result in a process of opening a file and not in changing the label "Open File" to "Close File" or another one. Generally you expect by clicking on a button or a Tab or elsewhere that it would result in what is stated as text labeling it. How much of overall confusion is needed in order to not be able to see such an obvious fact? Considering keeping a label on a button which text does not represent the action which will be triggered by clicking it a "design decision" worth to be preserved appears in my eyes just insane. How does it come you don't see it the same way I do??? Am ** I ** insane expecting that clicking a button labeled "show me buffer X" will show me buffer X??? --- By the way: I have placed the below provided code into my Emacs initialization file and the issue is gone. On killing the buffer the labels on Tabs in the Tab Bar are updated. Thanks :) . What still remains is the issue with renaming a buffer, enforcing my believe that fixing the problem with lack of a well unambiguous concept/definition of what a buffer, a tab-bar, a window, a tab, etc. actually represent will fix this and all similar issues just as a side-effect. On 4/2/23 08:48, Juri Linkov wrote: >>> The bug: the third Tab still keeps its  .emacs  label, the click on the >>> second Tab labeled  .emacs  did not show the .emacs file, but the buffer >>> *Messages*. >> After looking at the code, I'm not sure this is a bug. The tab names >> are just labels, although they are conveniently set to the name of the >> buffer in the window to be selected when the tab is current. But >> otherwise they are just labels. When you click on the tab, its name >> is updated to reflect the buffer shown in the selected window, so I >> think Emacs is behaving correctly, although it might be a bit >> unexpected. >> >> Juri, am I right? If not, where is the code that's supposed to update >> the labels when some buffers or windows are deleted or renamed? > Right, tab names are just labels, or by another analogy are "bookmarks". > It was a design decision to keep labels even after a buffer is killed, > so the users know what buffer was displayed in the tab created to > display that buffer. > > What we could do is to help to create additional code that could be > used to update tab names according to user wishes. > > But the problem is that there are too many ways to do this, > so the implementation logic is too fuzzy and not well defined. > Here are some considerations that could be took into account: > > 1. First there is no need to update tabs with names set explicitly > by 'tab-rename' (C-x t r). > > 2. Also no need to update a tab name when non-current buffers > are killed on a window configuration saved to the tab, > in case when tab-bar-tab-name-function is unchanged from > its default value tab-bar-tab-name-current. However, > when it's customized to tab-bar-tab-name-all, then > killing any buffer on the window configuration can change > the tab name. There are other values that may or may not > change the tab name after the buffer is killed. > > 3. It seems the reported wish was to rename the tab > after the buffer was killed. But I imagine some users > instead might prefer to automatically close all tabs that > displayed the killed buffer. This also makes sense. > > 4. As noted by Ruijie, the code should react not only > to killing a buffer, but also to renaming a buffer. > This means that instead of using kill-buffer-hook, > it should rely on buffer-list-update-hook, but > the problem is that buffer-list-update-hook is > not called with a buffer name, so need to develop > much more complicated code. > > I invite Claudio and anyone to try the code I wrote > for bug#52019 and bug#60096 as a staring point. > Then after fulfilling the expectations, it could be > later added to tab-bar.el as an option: > > ;; Visit affected tabs to update their names: > (add-hook 'kill-buffer-hook > (lambda () > (let ((tabs (reverse > (mapcar (lambda (tab) (1+ (alist-get 'index tab))) > (tab-bar-get-buffer-tab nil t nil t))))) > (run-with-timer > 0 nil > (lambda (tabs) (dolist (tab tabs) (tab-bar-select-tab tab))) > tabs))))