GNU bug report logs - #72735
31.0.50; [PATCH] Make more bug-reference variables customizeable

Previous Next

To reply to this bug, email your comments to 72735 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; [PATCH] Make more bug-reference variables customizeable  
Date: Tue, 20 Aug 2024 18:34:38 +0300

[Message part 1 (text/plain, inline)]

Hello,

I noticed that some of the variables that can be modified
by the user or as mentioned as such were not defined as custom variable.
These patches to so and correct the group of one of the existing
defcustom.

The patches don't change any of the existing functionality
but only document these variables better and make them easier to modify.
Because of that I set version to Emacs 30.1. Please tell if that's ok.

Good day,

Björn

[0001-Define-bug-reference-url-format-as-custom-type.patch (text/x-patch, inline)]

From 0a0f4062c41de25225df6b216470141d3537308c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Bidar?= <bjorn.bidar <at> thaodan.de>
Date: Tue, 20 Aug 2024 16:05:31 +0300
Subject: [PATCH 1/3] Define bug-reference-url-format as custom type

* lisp/progmodes/bug-reference.el (bug-reference-url-format): Define as
custom type. The manual and the documentation string talk like the
variable like is a custom variable. It does make sense to define
it as a custom type to check the type and group it under the other
bug-reference-mode settings
---
 lisp/progmodes/bug-reference.el | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/bug-reference.el b/lisp/progmodes/bug-reference.el
index 3bcfc213fc6..815e51aef73 100644
--- a/lisp/progmodes/bug-reference.el
+++ b/lisp/progmodes/bug-reference.el
@@ -48,7 +48,7 @@ bug-reference-map
   "C-c RET"   #'bug-reference-push-button)
 
 ;; E.g., "https://gcc.gnu.org/PR%s"
-(defvar bug-reference-url-format nil
+(defcustom bug-reference-url-format nil
   "Format used to turn a bug number into a URL.
 The bug number is supplied as a string, so this should have a single %s.
 This can also be a function designator; it is called without arguments
@@ -62,7 +62,11 @@ bug-reference-url-format
 If you set it to a symbol in the file Local Variables section,
 you need to add a `bug-reference-url-format' property to it:
 \(put \\='my-bug-reference-url-format \\='bug-reference-url-format t)
-so that it is considered safe, see `enable-local-variables'.")
+so that it is considered safe, see `enable-local-variables'."
+ :type '(choice (function)
+                (string))
+ :version "30.1"
+ :group 'bug-reference)
 
 ;;;###autoload
 (put 'bug-reference-url-format 'safe-local-variable
-- 
2.45.2

[0002-Define-bug-reference-forge-alist-as-custom-type.patch (text/x-patch, inline)]

From 5cad0f9d1cb982f03a60c494f0a363056feab688 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Bidar?= <bjorn.bidar <at> thaodan.de>
Date: Tue, 20 Aug 2024 17:09:14 +0300
Subject: [PATCH 2/3] Define bug-reference-forge-alist as custom type

* lisp/progmodes/bug-reference.el (bug-reference-forge-alist):
Define as custom type. The manual and the documentation string
refere to it like it is a custom variable.
Further defcustom will also ensure that the variable is the right type
when the user modifies it.
---
 lisp/progmodes/bug-reference.el | 49 +++++++++++++++++++++------------
 1 file changed, 31 insertions(+), 18 deletions(-)

diff --git a/lisp/progmodes/bug-reference.el b/lisp/progmodes/bug-reference.el
index 815e51aef73..9f293754c78 100644
--- a/lisp/progmodes/bug-reference.el
+++ b/lisp/progmodes/bug-reference.el
@@ -104,6 +104,37 @@ bug-reference-bug-regexp
 ;;;###autoload
 (put 'bug-reference-bug-regexp 'safe-local-variable 'stringp)
 
+
+(defcustom bug-reference-forge-alist
+  '(("github.com"       github    "https")
+    ("gitea.com"        gitea     "https")
+    ("codeberg.org"     gitea     "https")
+    ("gitlab.com"       gitlab    "https")
+    ("framagit.org"     gitlab    "https")
+    ("salsa.debian.org" gitlab    "https")
+    ("sr.ht"            sourcehut "https"))
+  "An alist of forge instances.
+Each entry has the form (HOST-DOMAIN FORGE-TYPE PROTOCOL).
+HOST-DOMAIN is the host- and domain name, e.g., gitlab.com,
+salsa.debian.org, or sr.ht.
+FORGE-TYPE is the type of the forge, e.g., gitlab, gitea,
+sourcehut, or github.
+PROTOCOL is the protocol for accessing the forge's issue tracker,
+usually \"https\" but for self-hosted forge instances not
+accessible via the internet it might also be \"http\"."
+  :type '(alist :key-type (string :tag "Host-Domain")
+                :value-type (group (choice :tag "Forge-Type"
+                                           (const :tag "Github" github)
+                                           (const :tag "Gitea" gitea)
+                                           (const :tag "Gitlab" gitlab)
+                                           (const :tag "Sourcehut" sourcehut)
+                                           (symbol))
+                                   (choice :tag "Protocol"
+                                           (const "https") (string))))
+  :group 'bug-reference
+  :version "30.1")
+
+
 (defun bug-reference-set-overlay-properties ()
   "Set properties of bug reference overlays."
   (put 'bug-reference 'evaporate t)
@@ -240,24 +271,6 @@ bug-reference--setup-from-vc-alist
 from a few default entries, and the value of
 `bug-reference-forge-alist'.")
 
-(defvar bug-reference-forge-alist
-  '(("github.com"       github    "https")
-    ("gitea.com"        gitea     "https")
-    ("codeberg.org"     gitea     "https")
-    ("gitlab.com"       gitlab    "https")
-    ("framagit.org"     gitlab    "https")
-    ("salsa.debian.org" gitlab    "https")
-    ("sr.ht"            sourcehut "https"))
-  "An alist of forge instances.
-Each entry has the form (HOST-DOMAIN FORGE-TYPE PROTOCOL).
-HOST-DOMAIN is the host- and domain name, e.g., gitlab.com,
-salsa.debian.org, or sr.ht.
-FORGE-TYPE is the type of the forge, e.g., gitlab, gitea,
-sourcehut, or github.
-PROTOCOL is the protocol for accessing the forge's issue tracker,
-usually \"https\" but for self-hosted forge instances not
-accessible via the internet it might also be \"http\".")
-
 (cl-defgeneric bug-reference--build-forge-setup-entry
     (host-domain forge-type protocol)
   "Build an entry for `bug-reference--setup-from-vc-alist'.
-- 
2.45.2

[0003-Set-custom-group-of-bug-reference-bug-regexp.patch (text/x-patch, inline)]

From 5498829ad845ad7763d25f417be52233cc707753 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Bidar?= <bjorn.bidar <at> thaodan.de>
Date: Tue, 20 Aug 2024 17:41:20 +0300
Subject: [PATCH 3/3] ; Set custom group of bug-reference-bug-regexp

---
 lisp/progmodes/bug-reference.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/progmodes/bug-reference.el b/lisp/progmodes/bug-reference.el
index 9f293754c78..00d8f5d506c 100644
--- a/lisp/progmodes/bug-reference.el
+++ b/lisp/progmodes/bug-reference.el
@@ -97,6 +97,7 @@ bug-reference-bug-regexp
 outside the bounds of subexpressions 1 and then don't contribute
 to the highlighted and clickable region."
   :type 'regexp
+  :group 'bug-reference
   ; 24.3: defconst -> defcustom
   ; 28.1: contract about subexpression 1 defines the overlay region.
   :version "28.1")
-- 
2.45.2

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Björn Bidar via "Bug reports for GNU Emacs, the Swiss
 army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 72735 <at> debbugs.gnu.org
Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables
 customizeable
Date: Tue, 20 Aug 2024 20:40:38 +0300

I noticed that there are other variable such as
bug-reference-setup-from-mail-alist that should be change similarly.

Would it make sense to group the changes to convert them to defcustom in
one patch or is one patch per variable better?

Message #14 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 72735 <at> debbugs.gnu.org
Subject: Re: bug#72735: 31.0.50;
 [PATCH] Make more bug-reference variables customizeable
Date: Tue, 20 Aug 2024 21:39:34 +0300

> Date: Tue, 20 Aug 2024 18:34:38 +0300
> From:  Björn Bidar via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> I noticed that some of the variables that can be modified
> by the user or as mentioned as such were not defined as custom variable.
> These patches to so and correct the group of one of the existing
> defcustom.
> 
> The patches don't change any of the existing functionality
> but only document these variables better and make them easier to modify.
> Because of that I set version to Emacs 30.1. Please tell if that's ok.

The emacs-30 release branch is closed to enhancements, it only
receives bugfix changes and improvements in documentation.  Converting
a defvar to a defcustom is not just a documentation change, it
radically changes how the variable is initialized and set.  So this is
not appropriate for the release branch.

Please see several comments below.

> * lisp/progmodes/bug-reference.el (bug-reference-url-format): Define as
> custom type. The manual and the documentation string talk like the
             ^^
> variable like is a custom variable. It does make sense to define
                                    ^^
Our convention is to leave two spaces between sentences in comments,
strings, and commit log messages.  There are several places in the
patch where you left only one space.

> -(defvar bug-reference-url-format nil
> +(defcustom bug-reference-url-format nil
>    "Format used to turn a bug number into a URL.

I wonder how this makes sense as a defcustom, since this variable must
be file-local, AFAIU.  In any case, the doc string should explain the
semantics of the nil value.

> + :group 'bug-reference)

This is redundant (here and elsewhere in the patches), since the
package name will supply the group.

> +FORGE-TYPE is the type of the forge, e.g., gitlab, gitea,
> +sourcehut, or github.

This leaves it unsaid how these symbols are used, and what symbols are
recognized.

Finally, I think this warrants a NEWS entry.

Thanks.

Message #17 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>, Tassilo Horn
 <tsdh <at> gnu.org>
Cc: 72735 <at> debbugs.gnu.org
Subject: Re: bug#72735: 31.0.50;
 [PATCH] Make more bug-reference variables customizeable
Date: Tue, 20 Aug 2024 22:04:51 +0300

> Date: Tue, 20 Aug 2024 20:40:38 +0300
> From:  Björn Bidar via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> 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.

> Would it make sense to group the changes to convert them to defcustom in
> one patch or is one patch per variable better?

I prefer a single patch, thanks.

Message #20 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72735 <at> debbugs.gnu.org
Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables
 customizeable
Date: Tue, 20 Aug 2024 22:39:18 +0300

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Tue, 20 Aug 2024 18:34:38 +0300
>> From:  Björn Bidar via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> I noticed that some of the variables that can be modified
>> by the user or as mentioned as such were not defined as custom variable.
>> These patches to so and correct the group of one of the existing
>> defcustom.
>> 
>> The patches don't change any of the existing functionality
>> but only document these variables better and make them easier to modify.
>> Because of that I set version to Emacs 30.1. Please tell if that's ok.
>
> The emacs-30 release branch is closed to enhancements, it only
> receives bugfix changes and improvements in documentation.  Converting
> a defvar to a defcustom is not just a documentation change, it
> radically changes how the variable is initialized and set.  So this is
> not appropriate for the release branch.

OK I wasn't aware that there's such a difference for existing user that
don't use defcustom.

> Please see several comments below.
>
>> * lisp/progmodes/bug-reference.el (bug-reference-url-format): Define as
>> custom type. The manual and the documentation string talk like the
>              ^^
>> variable like is a custom variable. It does make sense to define
>                                     ^^
> Our convention is to leave two spaces between sentences in comments,
> strings, and commit log messages.  There are several places in the
> patch where you left only one space.

Will fix, in prior changes to the file there were changes with only one space.

>> -(defvar bug-reference-url-format nil
>> +(defcustom bug-reference-url-format nil
>>    "Format used to turn a bug number into a URL.
>
> I wonder how this makes sense as a defcustom, since this variable must
> be file-local, AFAIU.  In any case, the doc string should explain the
> semantics of the nil value.

The doc string says it must be local however I see no reason to not be
able to have a global function that returns a default if no setting is
found for the file. E.g. it's common to have something like
keyword#bugnumber where each keyword would refer to a different
bugtracker. 

>> + :group 'bug-reference)
>
> This is redundant (here and elsewhere in the patches), since the
> package name will supply the group.

ok,.

>> +FORGE-TYPE is the type of the forge, e.g., gitlab, gitea,
>> +sourcehut, or github.
>
> This leaves it unsaid how these symbols are used, and what symbols are
> recognized.

Does the original text not say that already? The choices over all the
existing symbols which are accepted, if it doesn't make sense to
e.g. add a custom symbol to extend the mode than removing the (symbol)
choice is good.

> Finally, I think this warrants a NEWS entry.

Should the news entry explain similarly that the variables can be set
with defcustom and have improved documentation?

> Thanks.

Message #23 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72735 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables
 customizeable
Date: Tue, 20 Aug 2024 22:49:53 +0300

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Tue, 20 Aug 2024 20:40:38 +0300
>> From:  Björn Bidar via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> 
>> I noticed that there are other variable such as
>> bug-reference-setup-from-mail-alist that should be change similarly.
>
> Which ones, specifically?

Besides the one mentioned above bug-reference-setup-from-irc-alist and bug-reference-auto-setup-functions. 
The latter to e.g. the user providing their own functions.

> And let's get Tassilo (CC'ed) on board of this discussion.
>
>> Would it make sense to group the changes to convert them to defcustom in
>> one patch or is one patch per variable better?
>
> I prefer a single patch, thanks.

Ok great.

Message #26 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
 72735 <at> debbugs.gnu.org
Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables
 customizeable
Date: Wed, 21 Aug 2024 07:20:27 +0200

Eli Zaretskii <eliz <at> gnu.org> 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.

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.

So I'd rather keep it as-is.

Bye,
  Tassilo

Message #29 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 72735 <at> debbugs.gnu.org
Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables
 customizeable
Date: Wed, 21 Aug 2024 16:27:01 +0300

> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: 72735 <at> debbugs.gnu.org
> Date: Tue, 20 Aug 2024 22:39:18 +0300
> 
> >> +FORGE-TYPE is the type of the forge, e.g., gitlab, gitea,
> >> +sourcehut, or github.
> >
> > This leaves it unsaid how these symbols are used, and what symbols are
> > recognized.
> 
> Does the original text not say that already? The choices over all the
> existing symbols which are accepted, if it doesn't make sense to
> e.g. add a custom symbol to extend the mode than removing the (symbol)
> choice is good.

It might be enough to say that those symbols are the only predefined
ones.  The text as it is leaves the impression that they are only
examples.  Also, something should be said regarding the differences
between the symbols: why does the user need to specify these symbols
and what could happen if they use a wrong symbol?

> > Finally, I think this warrants a NEWS entry.
> 
> Should the news entry explain similarly that the variables can be set
> with defcustom and have improved documentation?

Just the fact that they are now user options, that's all.

Message #32 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bjorn.bidar <at> thaodan.de, 72735 <at> debbugs.gnu.org
Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables
 customizeable
Date: Wed, 21 Aug 2024 16:51:13 +0300

> From: Tassilo Horn <tsdh <at> gnu.org>
> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
>   72735 <at> debbugs.gnu.org
> Date: Wed, 21 Aug 2024 07:20:27 +0200
> 
> 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.
> 
> 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.
> 
> So I'd rather keep it as-is.

Thanks.

So, Björn, now you get to try to convince Tassilo that making some of
these variables defcustoms does make sense.  IOW, what are the
problems in the current situation that prompted you to suggest these
changes?

Message #41 received at 72735-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bjorn.bidar <at> thaodan.de, 72735-done <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#72735: 31.0.50;
 [PATCH] Make more bug-reference variables customizeable
Date: Mon, 10 Feb 2025 23:29:47 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Tassilo Horn <tsdh <at> gnu.org>
>> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
>>   72735 <at> debbugs.gnu.org
>> Date: Wed, 21 Aug 2024 07:20:27 +0200
>>
>> 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.
>>
>> 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.
>>
>> So I'd rather keep it as-is.
>
> Thanks.
>
> So, Björn, now you get to try to convince Tassilo that making some of
> these variables defcustoms does make sense.  IOW, what are the
> problems in the current situation that prompted you to suggest these
> changes?

No further comments within 24 weeks, so I'm closing this bug.

Message #44 received at 72735-done <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 72735-done <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables
 customizeable
Date: Tue, 11 Feb 2025 21:49:34 +0200

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Tassilo Horn <tsdh <at> gnu.org>
>>> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
>>>   72735 <at> debbugs.gnu.org
>>> Date: Wed, 21 Aug 2024 07:20:27 +0200
>>>
>>> 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.

>>> 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.
>>>
>>> So I'd rather keep it as-is.
>>
>> Thanks.
>>
>> So, Björn, now you get to try to convince Tassilo that making some of
>> these variables defcustoms does make sense.  IOW, what are the
>> problems in the current situation that prompted you to suggest these
>> changes?
>
> No further comments within 24 weeks, so I'm closing this bug.

Sorry I didn't have time to work on this earlier I will reply to the
rest of comments now.

Message #47 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: Tue, 11 Feb 2025 21:59:23 +0200

Tassilo Horn <tsdh <at> gnu.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> 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.

Message #50 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
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 07:25:50 +0100

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.

> 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.

> 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.

> 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.

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---

>> 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.

Bye,
Tassilo

Message #53 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>,
 Björn Bidar <bjorn.bidar <at> thaodan.de>
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: Tue, 11 Feb 2025 23:06:04 -0800

Tassilo Horn <tsdh <at> gnu.org> writes:

> And adding you company's tracker is quite easy, too.  That's what I use:

FWIW, I just throw $DAYJOB related customizations into .dir-locals.el in
my ~/work directory.  It seems more natural to me than having it in my
Init file, for example because some of the information in there is not
necessarily public and can't be shared outside of the company.

Message #56 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
 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 09:06:28 +0100

Stefan Kangas <stefankangas <at> gmail.com> writes:

>> And adding you company's tracker is quite easy, too.  That's what I
>> use:
>
> FWIW, I just throw $DAYJOB related customizations into .dir-locals.el
> in my ~/work directory.  It seems more natural to me than having it in
> my Init file, for example because some of the information in there is
> not necessarily public and can't be shared outside of the company.

Yup, that's obviously fine, too.  I have it differently mostly because I
have no strict ~/work vs. ~/fun separation between projects, so there's
no single root directory for the work stuff.

Bye,
Tassilo

Message #59 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
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 10:56:53 +0100

Tassilo Horn <tsdh <at> gnu.org> writes:

> Oh, and with bug-reference-setup-from-vc-alist there's only a
> URL-FORMAT-FN which must be a function.

I've changed that now so that URL-FORMAT-FN became URL-FORMAT which can
be string or function.  The string variant suffices in many situations
like my own below.

> 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---

With my latest change, the first add-to-list can now be written as

  (add-to-list 'bug-reference-setup-from-mail-alist
               `("SHD" nil ,shd-jira-regexp
                 "http://srvjira-and.shd.lan/browse/%s"))

So now all three variables bug-reference-setup-from-*-alist may contain
entries with only simple strings, none strictly requires a function
(unless you need to derive the bug URL from the VC URL).  As such, they
could become defcustoms (of course, those must allow functions where
applicable, too) that could be customized at least for the simple cases
(like my dayjob config above).  I wouldn't reject a patch in this regard
(although I'm not convinced that many users would prefer that).

As Stefan K. already said: setting up bug-reference using a
.dir-locals.el is probably the better & easier approach for many cases.

Bye,
Tassilo

Message #62 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>,
 Björn Bidar <bjorn.bidar <at> thaodan.de>
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 06:30:38 -0800

Tassilo Horn <tsdh <at> gnu.org> writes:

> As Stefan K. already said: setting up bug-reference using a
> .dir-locals.el is probably the better & easier approach for many cases.

Note also that this is also what is currently recommended in:

    (info "(emacs) Bug Reference")

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.

Message #72 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
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: Thu, 13 Feb 2025 17:05:10 +0100

Björn Bidar <bjorn.bidar <at> thaodan.de> writes:

Hi Björn,

>> 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.

Sure, that's where .dir-locals.el or the three variables come into play.

>>> 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.

Sorry, cannot parse this sentence.

> 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?

Yes, absolutely.

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

As said, I'm positive about the three variables
bug-reference-setup-from-*-alist becoming defcustoms.  But for any other
defcustomization, especially those where additional "default" variables
need to be introduced, I don't think it's worth it.

Bye,
Tassilo

Message #75 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>,
 Björn Bidar <bjorn.bidar <at> thaodan.de>
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: Thu, 13 Feb 2025 08:38:05 -0800

reopen 72735
tags 72735 - wontfix
thanks

Tassilo Horn <tsdh <at> gnu.org> writes:

> As said, I'm positive about the three variables
> bug-reference-setup-from-*-alist becoming defcustoms.  But for any other
> defcustomization, especially those where additional "default" variables
> need to be introduced, I don't think it's worth it.

Björn, can you please respin the patch to make these three variables
defcustoms?  Please also include the changes to the manual and NEWS.

Thanks in advance.

Message #82 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 72735 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables
 customizeable
Date: Thu, 13 Feb 2025 20:23:57 +0200

Stefan Kangas <stefankangas <at> gmail.com> writes:

>> As said, I'm positive about the three variables
>> bug-reference-setup-from-*-alist becoming defcustoms.  But for any other
>> defcustomization, especially those where additional "default" variables
>> need to be introduced, I don't think it's worth it.
>
> Björn, can you please respin the patch to make these three variables
> defcustoms?  Please also include the changes to the manual and NEWS.

Sure no problem. Just to clarify still. I think the
bug-reference-forge-alist should be customizeable too.

The default values are not enough and extended the central list is of
forges similar as done in forge.el is a common feature. Most of the ones
that could be put in to the list by the user can god in public
configuration if so chosen.

Message #85 received at 72735 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>,
 72735 <at> debbugs.gnu.org
Subject: Re: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables
 customizeable
Date: Fri, 14 Feb 2025 15:23:50 +0100

Björn Bidar <bjorn.bidar <at> thaodan.de> writes:

>> Björn, can you please respin the patch to make these three variables
>> defcustoms?  Please also include the changes to the manual and NEWS.
>
> Sure no problem. Just to clarify still. I think the
> bug-reference-forge-alist should be customizeable too.

I guessed that and I'm not a big fan, see below. ;-)

> The default values are not enough and extended the central list is of
> forges similar as done in forge.el is a common feature. Most of the
> ones that could be put in to the list by the user can god in public
> configuration if so chosen.

I've just tested customizing forge-alist and it has the same problem
I've mentioned already.  When there is a custom value, that will be
restored and additions that might have taken place to the default value
are lost.  That's a severe defect.  Having forge-alist as a defcustom is
not a good thing.  You better add-to-list there.

We don't want to make the same mistake in bug-reference.  So either we
let it be a defvar or we do the job of having a defcustom
bug-reference-forge-alist (with default value nil) plus a defvar
bug-reference--default-forge-alist defining the default forges.  And
then the usages have to use a merged version of both where the entries
of bug-reference-forge-alist take precedence.

IMHO, that's quite some hassle for allowing customizing the list of
forges where a simple add-to-list would also do...

If you feel the need, please to that in a separate patch.  If the hassle
is not too bad, I might reconsider my opinion.

Thanks,
Tassilo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.