[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages
From: |
Eric Abrahamsen |
Subject: |
bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages |
Date: |
Mon, 01 Jun 2020 12:25:11 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
On 06/01/20 21:41 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Mon, 01 Jun 2020 11:29:14 -0700
>> Cc: 41373@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>,
>> Richard Stallman <rms@gnu.org>, dgutov@yandex.ru
>>
>> + (interactive (list
>> + (read-string "Bug Subject: ")
>> + (completing-read
>> + "Package: "
>> + (progn
>> + (package-initialize)
>> + package-alist)
>> + nil nil)))
>
> Does this mean reporting a bug will initialize all the packages that
> are installed? Will it also access the network and check for
> upgrades?
I don't believe so, no. But we should probably call `package-initialize'
with the NO-ACTIVATE argument, which will skip loading autoloads and
some other stuff. Or, for minimum invasiveness, just skip everything if
`package-alist' is nil.
> I'm not sure I understand the need to produce a potentially huge list
> of completion candidates, when it isn't even clear that the bug is
> about some add-on package. Can we be smarter about this?
Right, this is the part of the suggestion with the biggest question
marks. I can imagine the prompt would get annoying for frequent
contributors who are mostly filing bugs against emacs itself.
The only thing I can think of is providing a separate command,
`report-emacs-package-bug', that is a thin wrapper around
`report-emacs-bug'. That could live in package.el.
Actually, maybe that's the way to go?