emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]


From: Eli Zaretskii
Subject: Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]
Date: Wed, 01 Jan 2020 17:30:36 +0200

> From: Michael Heerdegen <address@hidden>
> Date: Wed, 01 Jan 2020 02:19:42 +0100
> Cc: address@hidden, address@hidden, address@hidden,
>  Ihor Radchenko <address@hidden>, Dmitry Gutov <address@hidden>
> 
> | I am thinking if it would make sense to develop more standardised
> | command name conventions for bug reporting and add them to
> | (elisp)Emacs Lisp:Preparing Lisp code for distribution
> |
> | Then, the built-in emacs packages might be changed to follow those
> | conventions and improve discoverability of bug reporting capabilities.
> |
> | Also, an information that different major modes may have they own bug
> | reporting tools might be mentioned in the default template shown in
> | report-emacs-bug.
> |
> | What do you think?
> 
> I think this is a problem that also confuses and discourages users to
> make bug reports, so - any opinions?

I don't really believe on relying on discoverability in this case.
Even if users will discover the various commands, they might not know
which one to invoke.

How about if we add a bug-reporting-function, to be set by any mode
that wants to override the default one (which sends email to debbugs)?
Then report-emacs-bug could be modified to detect the modes active in
the buffer, and suggest the possible alternatives to the user.  I
think adding to our coding conventions a single variable that in most
cases doesn't even have to be set will be easier to propagate to the
few modes which want their own bug-tracking.  And users will benefit
from not having to search high and low for the relevant command.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]