GNU bug report logs - #79481
global-hl-line buffers

Previous Next

To reply to this bug, email your comments to 79481 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: global-hl-line buffers
Date: Sun, 21 Sep 2025 20:05:20 +0300

Recently we added 'tab-line-exclude-buffers'
that is checked by 'buffer-match-p'.

Shouldn't we now rename 'global-hl-line-modes' to something like
'global-hl-line-buffers' and use 'buffer-match-p', given that it was
added in 31.1, so there is no need to provide an alias for deprecation.

Message #8 received at 79481 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 79481 <at> debbugs.gnu.org
Subject: Re: bug#79481: global-hl-line buffers
Date: Sun, 21 Sep 2025 16:26:09 -0600

Juri Linkov <juri <at> linkov.net> writes:

> Recently we added 'tab-line-exclude-buffers'
> that is checked by 'buffer-match-p'.
>
> Shouldn't we now rename 'global-hl-line-modes' to something like
> 'global-hl-line-buffers' and use 'buffer-match-p', given that it was
> added in 31.1, so there is no need to provide an alias for deprecation.

I don't have problem with that, you can do the change, IME
`buffer-match-p` is a better and powerful alternative to
`easy-mmode--globalized-predicate-p`, however the `buffer-predicate`
type does not have a complete UI for `Customize` yet.

-- 
- E.G via Gnus and Org.

Message #11 received at 79481 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: eg642616 <at> gmail.com, 79481 <at> debbugs.gnu.org
Subject: Re: bug#79481: global-hl-line buffers
Date: Mon, 22 Sep 2025 08:01:15 +0300

> Cc: eg642616 <at> gmail.com
> From: Juri Linkov <juri <at> linkov.net>
> Date: Sun, 21 Sep 2025 20:05:20 +0300
> 
> Recently we added 'tab-line-exclude-buffers'
> that is checked by 'buffer-match-p'.
> 
> Shouldn't we now rename 'global-hl-line-modes' to something like
> 'global-hl-line-buffers' and use 'buffer-match-p', given that it was
> added in 31.1, so there is no need to provide an alias for deprecation.

What is the plan here?  Are we going to do something like that with
all the globalized modes? only with some of them? if the latter, which
ones?

IOW, if there's an intent to make similar changes in other minor
modes, we should probably discuss some general mechanism for doing
that, before we go out and make the changes one mode at a time.  One
question that I'd like answered is how come we never needed anything
like that until now?

Message #14 received at 79481 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eg642616 <at> gmail.com, 79481 <at> debbugs.gnu.org
Subject: Re: bug#79481: global-hl-line buffers
Date: Mon, 22 Sep 2025 09:39:30 +0300

>> Recently we added 'tab-line-exclude-buffers'
>> that is checked by 'buffer-match-p'.
>> 
>> Shouldn't we now rename 'global-hl-line-modes' to something like
>> 'global-hl-line-buffers' and use 'buffer-match-p', given that it was
>> added in 31.1, so there is no need to provide an alias for deprecation.
>
> What is the plan here?  Are we going to do something like that with
> all the globalized modes? only with some of them? if the latter, which
> ones?
>
> IOW, if there's an intent to make similar changes in other minor
> modes, we should probably discuss some general mechanism for doing
> that, before we go out and make the changes one mode at a time.  One
> question that I'd like answered is how come we never needed anything
> like that until now?

One possibility is to add a new keyword like e.g. ':filter'

  (define-globalized-minor-mode global-tab-line-mode
    tab-line-mode tab-line-mode--turn-on
    :filter 'tab-line-exclude-buffers

that will enable buffer-local mode selectively
according to the filter option.

But this could work only for 'define-globalized-minor-mode',
not for global modes that use global hooks like this:

  (define-minor-mode global-hl-line-mode
    :global t
    :filter 'global-hl-line-buffers

Message #17 received at 79481 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eg642616 <at> gmail.com, 79481 <at> debbugs.gnu.org
Subject: Re: bug#79481: global-hl-line buffers
Date: Mon, 22 Sep 2025 10:06:39 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 79481 <at> debbugs.gnu.org,  eg642616 <at> gmail.com
> Date: Mon, 22 Sep 2025 09:39:30 +0300
> 
> >> Recently we added 'tab-line-exclude-buffers'
> >> that is checked by 'buffer-match-p'.
> >> 
> >> Shouldn't we now rename 'global-hl-line-modes' to something like
> >> 'global-hl-line-buffers' and use 'buffer-match-p', given that it was
> >> added in 31.1, so there is no need to provide an alias for deprecation.
> >
> > What is the plan here?  Are we going to do something like that with
> > all the globalized modes? only with some of them? if the latter, which
> > ones?
> >
> > IOW, if there's an intent to make similar changes in other minor
> > modes, we should probably discuss some general mechanism for doing
> > that, before we go out and make the changes one mode at a time.  One
> > question that I'd like answered is how come we never needed anything
> > like that until now?
> 
> One possibility is to add a new keyword like e.g. ':filter'
> 
>   (define-globalized-minor-mode global-tab-line-mode
>     tab-line-mode tab-line-mode--turn-on
>     :filter 'tab-line-exclude-buffers
> 
> that will enable buffer-local mode selectively
> according to the filter option.
> 
> But this could work only for 'define-globalized-minor-mode',
> not for global modes that use global hooks like this:
> 
>   (define-minor-mode global-hl-line-mode
>     :global t
>     :filter 'global-hl-line-buffers

I added Stefan to the discussion, in the hope that he might have
comments or suggestions.

Message #20 received at 79481 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 79481 <at> debbugs.gnu.org
Subject: Re: bug#79481: global-hl-line buffers
Date: Mon, 22 Sep 2025 18:03:06 +0300

[Message part 1 (text/plain, inline)]

>> Recently we added 'tab-line-exclude-buffers'
>> that is checked by 'buffer-match-p'.
>>
>> Shouldn't we now rename 'global-hl-line-modes' to something like
>> 'global-hl-line-buffers' and use 'buffer-match-p', given that it was
>> added in 31.1, so there is no need to provide an alias for deprecation.
>
> I don't have problem with that, you can do the change, IME
> `buffer-match-p` is a better and powerful alternative to
> `easy-mmode--globalized-predicate-p`,

Do you think we should add the word "exclude" to the name?
Or it's fine to require using 'not' in the condition?

> however the `buffer-predicate` type does not have
> a complete UI for `Customize` yet.

Here is the patch that makes possible the customization
of all `buffer-predicate` conditions recursively:

[buffer-predicate-widget.patch (text/x-diff, inline)]

diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index 311e39f4c0f..4e2e88c7dfa 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -4387,12 +4387,35 @@ 'widget-visibility-value-create
 
 ;;; Buffer predicates.
 (define-widget 'buffer-predicate 'lazy
-  "A buffer predicate."
+  "A buffer predicate for the condition argument of `buffer-match-p'."
   :tag "Buffer predicate"
   :type '(choice (const :tag "All buffers" t)
                  (const :tag "No buffers" nil)
-                 ;; FIXME: This should be expanded somehow.
-                 sexp))
+                 (regexp :tag "Buffer name regexp")
+                 (function :tag "Predicate function")
+                 (cons :tag "Category"
+                       (const category)
+                       (symbol category))
+                 (cons :tag "This command"
+                       (const this-command)
+                       (symbol this-command))
+                 (cons :tag "Major mode"
+                       (const major-mode)
+                       (symbol major-mode))
+                 (cons :tag "Derived mode"
+                       (const derived-mode)
+                       (symbol derived-mode))
+                 (cons :tag "Not"
+                       (const not)
+                       (buffer-predicate :tag "not-condition"))
+                 (cons :tag "Or"
+                       (const or)
+                       (repeat :tag "List of or-conditions"
+                               buffer-predicate))
+                 (cons :tag "And"
+                       (const and)
+                       (repeat :tag "List of and-conditions"
+                               buffer-predicate))))
 
 (provide 'wid-edit)
 

Message #23 received at 79481 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eg642616 <at> gmail.com, 79481 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#79481: global-hl-line buffers
Date: Mon, 22 Sep 2025 16:45:19 -0400

>> One possibility is to add a new keyword like e.g. ':filter'
>>
>>   (define-globalized-minor-mode global-tab-line-mode
>>     tab-line-mode tab-line-mode--turn-on
>>     :filter 'tab-line-exclude-buffers
>> 
>> that will enable buffer-local mode selectively
>> according to the filter option.

We don't need yet-another-keyword for that, we can do the filtering
inside `tab-line-mode--turn-on` (that's why we have two arguments,
`tab-line-mode` and `tab-line-mode--turn-on`).

If that kind of need is very frequent for globalized minor modes, we
could consider adding such a feature directly in the macro, of course,
but it's a bit delicate since it would tend to "fight" with the
filtering done within the TURN-ON function: we'd probably need to
provide both a way to exclude some buffers and a way to
include buffers (which TURN-ON would otherwise skip).

So, I hope "YAGNI" does the trick here.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.