Package: emacs;
Reported by: Björn Bidar <bjorn.bidar <at> thaodan.de>
Date: Tue, 20 Aug 2024 15:36:02 UTC
Severity: wishlist
Found in version 31.0.50
Message #69 received at 72735 <at> debbugs.gnu.org (full text, mbox):
From: Björn Bidar <bjorn.bidar <at> thaodan.de> To: Tassilo Horn <tsdh <at> gnu.org> Cc: Eli Zaretskii <eliz <at> gnu.org>, 72735 <at> debbugs.gnu.org Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables customizeable Date: Wed, 12 Feb 2025 21:16:30 +0200
Tassilo Horn <tsdh <at> gnu.org> writes:
> Björn Bidar <bjorn.bidar <at> thaodan.de> 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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.