bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename

[Dmitry Gutov <dmitry@gutov.dev>]

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.