From: Tassilo Horn <tsdh@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "Björn Bidar" <bjorn.bidar@thaodan.de>, 72735@debbugs.gnu.org
Subject: bug#72735: 31.0.50; [PATCH] Make more bug-reference variables customizeable
Date: Wed, 21 Aug 2024 07:20:27 +0200 [thread overview]
Message-ID: <87seuyh2p0.fsf@gnu.org> (raw)
In-Reply-To: <86plq3uib0.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 20 Aug 2024 22:04:51 +0300")
Eli Zaretskii <eliz@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
next prev parent reply other threads:[~2024-08-21 5:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87a5h7hz3d.fsf@>
2024-08-20 19:04 ` bug#72735: 31.0.50; [PATCH] Make more bug-reference variables customizeable Eli Zaretskii
2024-08-20 19:49 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-21 5:20 ` Tassilo Horn [this message]
2024-08-21 13:51 ` Eli Zaretskii
[not found] <874j7fnr75.fsf@>
2024-08-20 17:40 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-20 17:40 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-20 18:39 ` Eli Zaretskii
2024-08-20 19:39 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <875xrvhtll.fsf@>
2024-08-21 13:27 ` Eli Zaretskii
2024-08-20 15:34 Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87seuyh2p0.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=72735@debbugs.gnu.org \
--cc=bjorn.bidar@thaodan.de \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).