Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables customizeable

From: Björn Bidar <[email-masked]>
Date: Tue, 11 Feb 2025 21:59:23 +0200

Tassilo Horn <[email-masked]> writes:

> Eli Zaretskii <[email-masked]> writes:
>
> Hi all,
>
>>> I noticed that there are other variable such as
>>> bug-reference-setup-from-mail-alist that should be change similarly.
>>
>> Which ones, specifically?
>>
>> And let's get Tassilo (CC'ed) on board of this discussion.
>
> As Eli already mentioned, bug-reference-url-format is usually set via a
> file local variables section or programatically so neither a defcustom
> nor a default value makes sense.
>
> Wrt. bug-reference-setup-from-mail-alist,
> bug-reference-setup-from-irc-alist, and
> bug-reference-setup-from-vc-alist: yes, they could be defcustoms but
> their entries can all (and are likely to) contain functions which are
> hard to specify in the defcustom interface.  I've thought it wouldn't be
> needed.  After all, bug-reference is a programmer's tool.

Isn't that a weak argument against changing those to a defcustom? One
could argue that Emacs itself is a programmers tool and yet with a have
defcustom to make it easier to customize Emacs and avoid errors.

With the current default values if not modified it is much harder to use
them for anything else but the GNU debbugs instance.

Correct me if I'm wrong but all those variables only regular expressions
and a format string which is something that already has been done using
defcustom e.g. as in Gnus.

Isn't it the policy that for settings variables there should be
defcustom variables? E.g. as mentioned in (info "(elisp) Documentation
Tips"):

>    • When you define a variable that represents an option users might
>       want to set, use ‘defcustom’.  *Note Defining Variables::.

Or is the purpose of bug-reference mode GNU specific and not intended to
be used for anything but GNU?

> Wrt. bug-reference-forge-alist: if it became a defcustom and a user
> would set it, she wouldn't see updates (like support for some new forge)
> in its default value anymore because their old saved custom value
> overrides the new default value.  It's much better to add new entries
> programatically using add-to-list or push/cl-pushnew.  Of course, one
> could split the variable in some *-default-alist defvar and a defcustom
> *-alist where the latter is meant for user customization but I think
> it's not worth the added complexity here.

Didn't have time to work on this. Besides that the general downside with
custom is that if the user modifies it they do not get the updates to
the default value a separate variable similar to browse-url-handler and
browse-url-defautl-handlers would be an option.