|
From: | Dmitry Gutov |
Subject: | 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 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |