GNU bug report logs - #77157
[PATCH] 'uniquify' user option setters and automatic buffer refresh

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77157 in the body.
You can then email your comments to 77157 AT debbugs.gnu.org in the normal way.

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

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

From: Ship Mints <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] 'uniquify' user option setters and automatic buffer refresh
Date: Fri, 21 Mar 2025 14:11:01 -0400

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

Okay, here's a fun one that's been on my list for a while that other people
might find useful.  When I have a lot of buffers open, I occasionally want
to increase or decrease uniquify-min-dir-content to make it easier to
discern, with higher precision, one buffer from another with the same name,
and without reloading buffers...

Changing uniquify user options refreshes buffer names.

Use customize interactively, or setopt in Elisp, to refresh buffer names
when changing 'uniquify' user options.  Previously, reloading or renaming
your buffers (or an Emacs restart) was required.

e.g., (setopt uniquify-min-dir-content 2)

In my init file, I have the following which makes this convenient:

  (defun my/uniquify-dir-content-cycle ()
    (interactive)
    (if uniquify-buffer-name-style
        (progn
          (pcase uniquify-min-dir-content
            (0 (setopt uniquify-min-dir-content 1))
            (1 (setopt uniquify-min-dir-content 2))
            (2 (setopt uniquify-min-dir-content 0)))
          (setopt uniquify-strip-common-suffix (= 0
uniquify-min-dir-content))
          (when (< emacs-major-version 31) ; Hopefully deprecated!
            (my/uniquify-refresh)))
      (message "No `uniquify-buffer-name-style' defined")))

-Stephane

[Message part 2 (text/html, inline)]

[0001-uniquify-user-option-setters-and-automatic-buffer-re.patch (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 77157 <at> debbugs.gnu.org
Subject: Re: bug#77157: [PATCH] 'uniquify' user option setters and automatic
 buffer refresh
Date: Fri, 21 Mar 2025 21:50:58 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 21 Mar 2025 14:11:01 -0400
> 
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -1566,6 +1566,14 @@ This user option replaces 'follow-mode-prefix', which had to be set
>  before loading Follow mode.  This new option allows you to change the
>  prefix even after it was loaded, using 'customize-option' or 'setopt'.
>  
> +---
> +*** Changing uniquify user options refreshes buffer names.
> +Use customize interactively, or setopt in Elisp, to refresh buffer names
> +when changing 'uniquify' user options.  Previously, reloading or
> +renaming your buffers (or an Emacs restart) was required.

I don't think this change warrants a NEWS entry.  It's a minor
convenience improvement, and arguably a bugfix.

>  (defcustom uniquify-buffer-name-style 'post-forward-angle-brackets
>    "How to construct unique buffer names for files with the same base name.
> @@ -121,6 +135,8 @@ uniquify-buffer-name-style
>  		(const post-forward-angle-brackets)
>                  (function :tag "Other")
>  		(const :tag "numeric suffixes" nil))
> +  :initialize #'custom-initialize-default
> +  :set #'uniquify--set-option

Please tell in the doc string that changing the style in the middle of
an Emacs session must be done via Customize or by using setopt, but
not by setting the variable directly (unless uniquify--set-option is
then invoked).

> @@ -136,11 +152,15 @@ uniquify-ignore-buffers-re
>  For instance, set this to \"^draft-[0-9]+$\" to avoid having uniquify
>  rename draft buffers even if `uniquify-after-kill-buffer-flag' is
>  non-nil and the visited file name isn't the same as that of the buffer."
> -  :type '(choice (const :tag "Uniquify all buffers" nil) regexp))
> +  :type '(choice (const :tag "Uniquify all buffers" nil) regexp)
> +  :initialize #'custom-initialize-default
> +  :set #'uniquify--set-option)
>  
>  (defcustom uniquify-min-dir-content 0
>    "Minimum number of directory name components included in buffer name."
> -  :type 'integer)
> +  :type 'integer
> +  :initialize #'custom-initialize-default
> +  :set #'uniquify--set-option)
>  
>  (defcustom uniquify-separator nil
>    "String separator for buffer name components.
> @@ -148,7 +168,9 @@ uniquify-separator
>  base file name from directory part in buffer names (default \"|\").
>  When `uniquify-buffer-name-style' is `reverse', separates all
>  file name components (default \"\\\")."
> -  :type '(choice (const nil) string))
> +  :type '(choice (const nil) string)
> +  :initialize #'custom-initialize-default
> +  :set #'uniquify--set-option)
>  
>  (define-obsolete-variable-alias 'uniquify-trailing-separator-p
>    'uniquify-trailing-separator-flag "31.1")
> @@ -167,7 +189,9 @@ uniquify-strip-common-suffix
>  E.g. if you open /a1/b/c/d and /a2/b/c/d, the buffer names will say
>  \"d|a1\" and \"d|a2\" instead of \"d|a1/b/c\" and \"d|a2/b/c\".
>  This can be handy when you have deep parallel hierarchies."
> -  :type 'boolean)
> +  :type 'boolean
> +  :initialize #'custom-initialize-default
> +  :set #'uniquify--set-option)
>  
>  (defvar uniquify-list-buffers-directory-modes '(dired-mode cvs-mode vc-dir-mode)
>    "List of modes for which uniquify should obey `list-buffers-directory'.
> @@ -197,6 +221,8 @@ uniquify-dirname-transform
>                   (function-item :tag "Include project name in directory name"
>                                  ,#'project-uniquify-dirname-transform)
>                   function)
> +  :initialize #'custom-initialize-default
> +  :set #'uniquify--set-option
>    :version "30.1"
>    :group 'uniquify)

Likewise for these user options.

Thanks.

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

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77157 <at> debbugs.gnu.org
Subject: Re: bug#77157: [PATCH] 'uniquify' user option setters and automatic
 buffer refresh
Date: Fri, 21 Mar 2025 16:02:34 -0400

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

On Fri, Mar 21, 2025 at 3:51 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 21 Mar 2025 14:11:01 -0400
> >  (defcustom uniquify-buffer-name-style 'post-forward-angle-brackets
> >    "How to construct unique buffer names for files with the same base
> name.
> > @@ -121,6 +135,8 @@ uniquify-buffer-name-style
> >               (const post-forward-angle-brackets)
> >                  (function :tag "Other")
> >               (const :tag "numeric suffixes" nil))
> > +  :initialize #'custom-initialize-default
> > +  :set #'uniquify--set-option
>
> Please tell in the doc string that changing the style in the middle of
> an Emacs session must be done via Customize or by using setopt, but
> not by setting the variable directly (unless uniquify--set-option is
> then invoked).
>
>
Eli, how is this wording which I'll put in each docstring?

"To reflect a change to this option's value in your live buffer names,
use `customize' interactively, or use `setopt' in Elisp, both of which
call `uniquify--set-option' (setq will not do that for you)."

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 77157 <at> debbugs.gnu.org
Subject: Re: bug#77157: [PATCH] 'uniquify' user option setters and automatic
 buffer refresh
Date: Sat, 22 Mar 2025 08:50:42 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 21 Mar 2025 16:02:34 -0400
> Cc: 77157 <at> debbugs.gnu.org
> 
>  Please tell in the doc string that changing the style in the middle of
>  an Emacs session must be done via Customize or by using setopt, but
>  not by setting the variable directly (unless uniquify--set-option is
>  then invoked).
> 
> Eli, how is this wording which I'll put in each docstring?
> 
> "To reflect a change to this option's value in your live buffer names,
> use `customize' interactively, or use `setopt' in Elisp, both of which
> call `uniquify--set-option' (setq will not do that for you)."

We usually use the following style for such variables:

  Setting this variable directly will not usually take effect;
  use either \\[customize] or `setopt', or call `uniquify--set-option'
  or restart `uniquify-mode' after setting the variable directly.

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

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77157 <at> debbugs.gnu.org
Subject: Re: bug#77157: [PATCH] 'uniquify' user option setters and automatic
 buffer refresh
Date: Sat, 22 Mar 2025 06:44:53 -0400

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

On Sat, Mar 22, 2025 at 2:50 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 21 Mar 2025 16:02:34 -0400
> > Cc: 77157 <at> debbugs.gnu.org
> >
> >  Please tell in the doc string that changing the style in the middle of
> >  an Emacs session must be done via Customize or by using setopt, but
> >  not by setting the variable directly (unless uniquify--set-option is
> >  then invoked).
> >
> > Eli, how is this wording which I'll put in each docstring?
> >
> > "To reflect a change to this option's value in your live buffer names,
> > use `customize' interactively, or use `setopt' in Elisp, both of which
> > call `uniquify--set-option' (setq will not do that for you)."
>
> We usually use the following style for such variables:
>
>   Setting this variable directly will not usually take effect;
>   use either \\[customize] or `setopt', or call `uniquify--set-option'
>   or restart `uniquify-mode' after setting the variable directly.
>

I'll adapt this language.  Uniquify isn't implemented as a mode.  It's a
rename buffer hook in buffer.c and depends on 'uniquify-buffer-name-style'
to have a defined style.

Even the function 'uniquify-unload-function' doesn't attempt to remove the
hook (it probably should set 'uniquify-buffer-name-style' to nil as part of
its business).  It's not even clear if unload ever gets called by anyone.
Perhaps a candidate to obsolete.

[Message part 2 (text/html, inline)]

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

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77157 <at> debbugs.gnu.org
Subject: Re: bug#77157: [PATCH] 'uniquify' user option setters and automatic
 buffer refresh
Date: Sat, 22 Mar 2025 07:04:08 -0400

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

On Sat, Mar 22, 2025 at 6:44 AM Ship Mints <shipmints <at> gmail.com> wrote:

> On Sat, Mar 22, 2025 at 2:50 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Ship Mints <shipmints <at> gmail.com>
>> > Date: Fri, 21 Mar 2025 16:02:34 -0400
>> > Cc: 77157 <at> debbugs.gnu.org
>> >
>> >  Please tell in the doc string that changing the style in the middle of
>> >  an Emacs session must be done via Customize or by using setopt, but
>> >  not by setting the variable directly (unless uniquify--set-option is
>> >  then invoked).
>> >
>> > Eli, how is this wording which I'll put in each docstring?
>> >
>> > "To reflect a change to this option's value in your live buffer names,
>> > use `customize' interactively, or use `setopt' in Elisp, both of which
>> > call `uniquify--set-option' (setq will not do that for you)."
>>
>> We usually use the following style for such variables:
>>
>>   Setting this variable directly will not usually take effect;
>>   use either \\[customize] or `setopt', or call `uniquify--set-option'
>>   or restart `uniquify-mode' after setting the variable directly.
>>
>
> I'll adapt this language.  Uniquify isn't implemented as a mode.  It's a
> rename buffer hook in buffer.c and depends on 'uniquify-buffer-name-style'
> to have a defined style.
>
> Even the function 'uniquify-unload-function' doesn't attempt to remove the
> hook (it probably should set 'uniquify-buffer-name-style' to nil as part of
> its business).  It's not even clear if unload ever gets called by anyone.
> Perhaps a candidate to obsolete.
>

The following seems more precise.  Okay with you?

Setting this variable directly will not usually take effect; use either
\\[customize] or `setopt', or call `uniquify--set-option'; otherwise
reload your buffers, or restart Emacs.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 77157 <at> debbugs.gnu.org
Subject: Re: bug#77157: [PATCH] 'uniquify' user option setters and automatic
 buffer refresh
Date: Sat, 22 Mar 2025 13:17:02 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Sat, 22 Mar 2025 07:04:08 -0400
> Cc: 77157 <at> debbugs.gnu.org
> 
>  We usually use the following style for such variables:
> 
>    Setting this variable directly will not usually take effect;
>    use either \\[customize] or `setopt', or call `uniquify--set-option'
>    or restart `uniquify-mode' after setting the variable directly.
> 
>  I'll adapt this language.  Uniquify isn't implemented as a mode.  It's a rename buffer hook in buffer.c
>  and depends on 'uniquify-buffer-name-style' to have a defined style.
> 
>  Even the function 'uniquify-unload-function' doesn't attempt to remove the hook (it probably should set
>  'uniquify-buffer-name-style' to nil as part of its business).  It's not even clear if unload ever gets called
>  by anyone.  Perhaps a candidate to obsolete.
> 
> The following seems more precise.  Okay with you?
> 
> Setting this variable directly will not usually take effect; use either
> \\[customize] or `setopt', or call `uniquify--set-option'; otherwise
> reload your buffers, or restart Emacs.

Yes, but I'd omit the "restart Emacs" alternative, as too far-fetched
(we are talking about the ways to make the change take effect in the
same session).

Thanks.

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

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77157 <at> debbugs.gnu.org
Subject: Re: bug#77157: [PATCH] 'uniquify' user option setters and automatic
 buffer refresh
Date: Sat, 22 Mar 2025 07:40:43 -0400

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

On Sat, Mar 22, 2025 at 7:17 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Sat, 22 Mar 2025 07:04:08 -0400
> > Cc: 77157 <at> debbugs.gnu.org
> >
> >  We usually use the following style for such variables:
> >
> >    Setting this variable directly will not usually take effect;
> >    use either \\[customize] or `setopt', or call `uniquify--set-option'
> >    or restart `uniquify-mode' after setting the variable directly.
> >
> >  I'll adapt this language.  Uniquify isn't implemented as a mode.  It's
> a rename buffer hook in buffer.c
> >  and depends on 'uniquify-buffer-name-style' to have a defined style.
> >
> >  Even the function 'uniquify-unload-function' doesn't attempt to remove
> the hook (it probably should set
> >  'uniquify-buffer-name-style' to nil as part of its business).  It's not
> even clear if unload ever gets called
> >  by anyone.  Perhaps a candidate to obsolete.
> >
> > The following seems more precise.  Okay with you?
> >
> > Setting this variable directly will not usually take effect; use either
> > \\[customize] or `setopt', or call `uniquify--set-option'; otherwise
> > reload your buffers, or restart Emacs.
>
> Yes, but I'd omit the "restart Emacs" alternative, as too far-fetched
> (we are talking about the ways to make the change take effect in the
> same session).
>
> Thanks.
>

Revised patch attached.  It's my pleasure.

[Message part 2 (text/html, inline)]

[0001-uniquify-user-option-setters-and-automatic-buffer-re.patch (application/octet-stream, attachment)]

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

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77157 <at> debbugs.gnu.org
Subject: Re: bug#77157: [PATCH] 'uniquify' user option setters and automatic
 buffer refresh
Date: Sat, 22 Mar 2025 08:09:18 -0400

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

On Sat, Mar 22, 2025 at 7:40 AM Ship Mints <shipmints <at> gmail.com> wrote:

> On Sat, Mar 22, 2025 at 7:17 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Ship Mints <shipmints <at> gmail.com>
>> > Date: Sat, 22 Mar 2025 07:04:08 -0400
>> > Cc: 77157 <at> debbugs.gnu.org
>> >
>> >  We usually use the following style for such variables:
>> >
>> >    Setting this variable directly will not usually take effect;
>> >    use either \\[customize] or `setopt', or call `uniquify--set-option'
>> >    or restart `uniquify-mode' after setting the variable directly.
>> >
>> >  I'll adapt this language.  Uniquify isn't implemented as a mode.  It's
>> a rename buffer hook in buffer.c
>> >  and depends on 'uniquify-buffer-name-style' to have a defined style.
>> >
>> >  Even the function 'uniquify-unload-function' doesn't attempt to remove
>> the hook (it probably should set
>> >  'uniquify-buffer-name-style' to nil as part of its business).  It's
>> not even clear if unload ever gets called
>> >  by anyone.  Perhaps a candidate to obsolete.
>> >
>> > The following seems more precise.  Okay with you?
>> >
>> > Setting this variable directly will not usually take effect; use either
>> > \\[customize] or `setopt', or call `uniquify--set-option'; otherwise
>> > reload your buffers, or restart Emacs.
>>
>> Yes, but I'd omit the "restart Emacs" alternative, as too far-fetched
>> (we are talking about the ways to make the change take effect in the
>> same session).
>>
>> Thanks.
>>
>
> Revised patch attached.  It's my pleasure.
>

With bug# added to commit log...

[Message part 2 (text/html, inline)]

[0001-uniquify-user-option-setters-and-automatic-buffer-re.patch (application/octet-stream, attachment)]

Message #34 received at 77157-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 77157-done <at> debbugs.gnu.org
Subject: Re: bug#77157: [PATCH] 'uniquify' user option setters and automatic
 buffer refresh
Date: Sat, 29 Mar 2025 15:07:31 +0300

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Sat, 22 Mar 2025 08:09:18 -0400
> Cc: 77157 <at> debbugs.gnu.org
> 
> On Sat, Mar 22, 2025 at 7:40 AM Ship Mints <shipmints <at> gmail.com> wrote:
> 
>  On Sat, Mar 22, 2025 at 7:17 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>  > From: Ship Mints <shipmints <at> gmail.com>
>  > Date: Sat, 22 Mar 2025 07:04:08 -0400
>  > Cc: 77157 <at> debbugs.gnu.org
>  > 
>  >  We usually use the following style for such variables:
>  > 
>  >    Setting this variable directly will not usually take effect;
>  >    use either \\[customize] or `setopt', or call `uniquify--set-option'
>  >    or restart `uniquify-mode' after setting the variable directly.
>  > 
>  >  I'll adapt this language.  Uniquify isn't implemented as a mode.  It's a rename buffer hook in
>  buffer.c
>  >  and depends on 'uniquify-buffer-name-style' to have a defined style.
>  > 
>  >  Even the function 'uniquify-unload-function' doesn't attempt to remove the hook (it probably
>  should set
>  >  'uniquify-buffer-name-style' to nil as part of its business).  It's not even clear if unload ever
>  gets called
>  >  by anyone.  Perhaps a candidate to obsolete.
>  > 
>  > The following seems more precise.  Okay with you?
>  > 
>  > Setting this variable directly will not usually take effect; use either
>  > \\[customize] or `setopt', or call `uniquify--set-option'; otherwise
>  > reload your buffers, or restart Emacs.
> 
>  Yes, but I'd omit the "restart Emacs" alternative, as too far-fetched
>  (we are talking about the ways to make the change take effect in the
>  same session).
> 
>  Thanks.
> 
>  Revised patch attached.  It's my pleasure.
> 
> With bug# added to commit log...

Thanks, installed on the master branch, and closing the bug.

Previous Next

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