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

From: Björn Bidar <[email-masked]>
Date: Wed, 12 Feb 2025 21:16:30 +0200

Tassilo Horn <[email-masked]> writes:

> Björn Bidar <[email-masked]> writes:
>
> Hi Björn,
>
>>> 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?
>
> Maybe.  I have no problem with those three being defcustoms.
>

That's great. It would certainly help new user to discover and get
started customizing.

>> With the current default values if not modified it is much harder to
>> use them for anything else but the GNU debbugs instance.
>
> No, bug-reference should work out-of-the-box for every project checked
> out of the forges in bug-reference-forge-alist.  Well, unless you've set
> bug-reference-url-format globally which would turn off the auto-setup.

I get that point however not all or none, depending on one's usecase, might use
forges to track bugs. 

>> 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.
>
> In all three, BUG-REGEXP and URL-FORMAT can be functions as documented
> by bug-reference-bug-regexp and bug-reference-url-format.  Oh, and with
> bug-reference-setup-from-vc-alist there's only a URL-FORMAT-FN which
> must be a function.

OK that sounds good.

>> 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?
>
> As said, it works out-of-the-box for Github, several Gitlab instances,
> codeberg, framagit, salsa.debian.org, and sr.ht.

I know these where the where a customize variable works the easiest
similar to Forge's forge-alist.

Would it make sense to include common instances of FOSS projects such as
for example Freedesktop, KDE and GNOME in to the
bug-reference-forge-alist by default? 

> And adding you company's tracker is quite easy, too.  That's what I use:
>
> --8<---------------cut here---------------start------------->8---
> (let ((shd-jira-regexp (concat "\\b\\(\\("
>                                (regexp-opt '("ARCA" "BRI" "ECOJ" "KASE" "MOBA"
>                                              "PORC" "LOWE" "SABA"))
>                                "-[0-9]\\{1,6\\}\\)\\)\\b")))
>   (add-to-list 'bug-reference-setup-from-vc-alist
>                `("srv-upsource\\.shd\\.lan"
>                  ,shd-jira-regexp
>                  ,(lambda (_)
>                     :dont-hl-value-as-docstring
>                     "http://srvjira-and.shd.lan/browse/%s")))
>
>   (add-to-list 'bug-reference-setup-from-mail-alist
>                `("SHD" nil ,shd-jira-regexp
>                  "http://srvjira-and.shd.lan/browse/%s"))
> --8<---------------cut here---------------end--------------->8---

Oh that's that looks very useful. Thank you.

That would have been what I would try next. 

>>> 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.
>
> That's what I've said, yes.  And I recall some recent discussion where
> it was argued that the browse-url-(default-)handlers split (one for
> users, one for emacs/packages) was adding too much complexity.

Hm I didn't exactly follow those discussions but I know some of those
layered configuration systems had their difficulties.
In this instance I mean with layered that that the default configuration
is taken and then merged with each additional layer where each layer
after it can override the previous configuration.

I know that custom doesn't deal well with list variables.

If this is a common issue some shared solution might help but I digress.

Using some sort of -default variable would make it the easiest to
include more forge's into the alist without messing with defaults even
when not using custom.

I will try to send some patches in a few days.