GNU bug report logs - #62621
29.0.60; uniquify can't make buffers unique based on things other than filename

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, sbaugh <at> catern.com
Cc: sbaugh <at> janestreet.com, 62621 <at> debbugs.gnu.org
Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on
 things other than filename
Date: Tue, 18 Jul 2023 03:34:06 +0300

On 14/07/2023 09:29, Eli Zaretskii wrote:
> IOW, we should NOT immediately generalize to
> functions only because such generalization could make sense in some
> use cases.

I agree with that statement. When only one or two behaviors can be 
needed or foreseen, there's no hard need to make the option open-ended 
(which it becomes when it can be set to a function).

This case, however, looks more like an exception to my eye. Similar to 
save-some-buffers-default-predicate where extensibility makes sense.

And if you also wanted to avoid a direct reference to project-* in 
uniquify.el, that's another argument in favor of extensibility.

> Repeat after me: Use options whose values are functions
> are hard on our users, because they require them to be Lisp
> programmers.

That doesn't have to be the case. If the defcustom's docstring mentions 
several functions that can be used, and the :type widget includes them 
as well, the user can decide to switch to any of them without writing 
any Lisp (or having to understand the implementations).

Examples: the aforementioned save-some-buffers-default-predicate, or 
project-prompter, or xref-history-storage, and so on.

Previous Next

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