bug#66326: 29.1.50; There should be a way to promote warnings to errors

[sbaugh@catern.com]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> More generally, I'm worried by the tendency of people to submit
>> patches for Emacs as soon as they find something they think is missing
>> in Emacs that they need for some one-time job.  Emacs is not supposed
>> to be a huge heap of random features that someone at some time found
>> useful for some random job.  Emacs is Free Software: you can easily
>> implement this stuff in your local copy and use it as much as you
>> want; no need to add that to the Emacs core, unless there's a real
>> need for it expressed by enough people, and no better solutions in
>> hand.  I do this for my local jobs all the time.
>
> FWIW, I'm generally always in favor of features that make the Emacs Lisp
> developers' lives easier, and as much as I appreciate that some users
> might want to debug warnings, I don't think I understand the use case(s).

I see, let me try to explain further.  (BTW, before submitting I
discussed the idea of this patch on #emacs on Libera IRC and people
seemed interested and approving, which is why I assumed this would be
uncontroversial.  If I had realized I would have sent it to
emacs-devel.)

I had some warnings and I went to debug them, and I assumed there would
be some kind of debug-on-warning like how there is debug-on-error and
debug-on-message and debug-on-quit.  But there is not.  So I figured it
would be uncontroversial to add something which enables a
debug-on-warning, since right now it is difficult to find out what code
triggered some warning.

The alternative which I've been using is
(debug-on-entry 'display-warning)
but this:
1. always debugs regardless of what kind of warning
2. isn't helpful for the "automated tests where warnings
   should fail the test" use case

> These questions come to mind:
>
> - Are there many warnings during startup?

No.  But also it's not just startup.

> - Why are they a problem (can't they just be ignored)?

Well, sure, but they pop up a *Warnings* buffer which is annoying to
users, so it would be better to get rid of them.

> - If some code warns, presumably it's a real issue and should be fixed
>   by the user, not in the code.  Otherwise it should be an error.  No?

Yes, but sometimes either:

- a warning happens because of bugs in other code, so the proper way to
  fix the warning is to fix those other bugs

- More relevantly, sometimes it's hard to find out what is causing the
  warning.

> - Why can't users add an advice to `display-warning' that simply calls
>   `error' or somesuch?  Or even just redefine it?

That would work.  But it's harder to tell a user to do that than (setq
debug-on-warning t) or some equivalent.

> Perhaps this feature would be better as a GNU ELPA package
> `debug-warnings' or something like that, so that the community could get
> more experience with it.  If it catches on, perhaps we could consider
> adding it to core.  Would that way of working make sense?

Telling one of my users to install some other package to debug an issue
is a bit much.  I would probably just guide them through using
debug-on-entry instead.