From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: The tab-line "All" group Date: Fri, 12 Apr 2024 19:28:08 +0300 Organization: LINKOV.NET Message-ID: <868r1jkodb.fsf@mail.linkov.net> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13594"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: emacs-devel@gnu.org To: Gabriel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 12 18:32:39 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rvJpO-0003PT-SR for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Apr 2024 18:32:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvJoc-0003JR-E5; Fri, 12 Apr 2024 12:31:50 -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 1rvJoZ-0003JI-UY for emacs-devel@gnu.org; Fri, 12 Apr 2024 12:31:47 -0400 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rvJoW-0000bY-Lv for emacs-devel@gnu.org; Fri, 12 Apr 2024 12:31:47 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 3CF7CC0002; Fri, 12 Apr 2024 16:31:40 +0000 (UTC) In-Reply-To: (Gabriel's message of "Mon, 21 Nov 2022 06:42:20 -0300") X-GND-Sasl: juri@linkov.net Received-SPF: pass client-ip=217.70.183.198; envelope-from=juri@linkov.net; helo=relay6-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317698 Archived-At: > The behavior of `tab-line-tabs-buffer-group-function' when returning > nil, according to its docstring, is that the "buffer should be filtered > out". I found it not really elucidative, though. The actual behavior > is to display a group called "All" (currently, a hardcoded value) and > don't display any tab (for the buffers that belongs to this group, i.e., > for cases when (funcall tab-line-tabs-buffer-group-function buffer) > returns nil). > > What are the actual use-cases where the behavior of "filtering out" tabs > (i.e. to don't display) for the "All" group is useful? (i.e., to hide > tabs *only* in the "All" group when the user has explicitly enabled the > tab-line mode to actually see tabs). Sorry for the delay. Some string is needed to display to not leave the tab-line completely empty. > Personally, I find it somewhat confusing, especially because the name > "All" might led the user to think that this group contains all tabs, > which is not true. The name "Others"/"Rest"/etc would make more sense > in this context. If I had to choose, I would demand > `tab-line-tabs-buffer-group-function' to always return a valid (non-nil) > group name. You are right, the "All" group is too confusing. A proper name would be "No group" or "Ungrouped". "No group" is shorter, so let's use it. > If an "All" group is really useful, we can properly > implement it, i.e., to have a group that *actually* contains all tabs. No need to implement an "All" group explicitly since a customized tab-line-tabs-buffer-group-function can return the string "All" for all ungrouped buffers. > At last, when `tab-line-tabs-buffer-group-function' returns an empty > string, it adds the opposite (undocumented and unintended, I guess) > "feature": to display tabs but not the group name. The tabs are > actually added to a group named "", but the tab name is not displayed, > since it's an empty string. Not sure if this info is useful or if we > need to change something here, but I thought it would be nice to share. Thanks for sharing. Maybe someone might need to show no group name for some "default group". > Here is a simple snippet to play with tab-line groups: > > #+begin_src emacs-lisp > (progn > (defvar my-tab-line-group-default-value nil) > > (defun my-tab-line-group-function (buffer) > "Group tab-line tabs by project." > (with-current-buffer buffer > (if-let ((project (project-current))) > (project-root project) > my-tab-line-group-default-value))) > > (setopt tab-line-tabs-function 'tab-line-tabs-buffer-groups > tab-line-tabs-buffer-group-function #'my-tab-line-group-function) > > (global-tab-line-mode 1)) > #+end_src Thanks for suggesting a group by project name. This will be added now as a new option to 'tab-line-tabs-buffer-group-function'. PS: maybe also will add a new option 'prev-buffers' to 'tab-line-tabs-buffer-group-sort-function' to sort buffers by the fixed order of their appearance in the window using information from window prev/next buffers.