bug#60854: [PATCH] Make warnings show a "warning" emoji instead of a stop-sign

[Konstantin Kharlamov]

On Fri, 2023-03-31 at 10:05 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: 60854@debbugs.gnu.org
> > Date: Fri, 31 Mar 2023 09:26:38 +0300
> > 
> > Actually, scratch that, it's even worse. You see: the byte-compiled
> > packages are natively-compiled on demand, i.e. on the first use. So,
> > suppose you updated your (M)ELPA packages. What happens is that you
> > get a bunch of warnings for packages that were loaded immediately,
> > which is not all of them. During Emacs use later, as you open new
> > files that weren't opened during the update thus triggering the
> > according modes to load, you will get more and more new warnings.
> 
> Emacs 28 with native-compilation was released a year ago.  MELPA
> packages should have adapted to that long ago, by fixing the problems
> which cause those warnings.  My suggestion is to file issues with the
> respective developers and pinging them until they resolve this.  In
> almost all cases, these warnings are due to missing 'require's or
> other similar omissions.  There's no justification for these problems
> to exist in the year 2023.

FWIW, I co-maintain a color-identifiers mode on github, and I have occasionally
introduced new native-comp warnings (about a variable being referred in a
function before its `defvar`). This happens because you debug and test ELisp
code without it being compiled at all. Then later after everything seems to
work, you test that byte-compilation produces no warnings. But at that point you
don't know there isn't any warnings from native-comp, so you also need to load
the byte-compiled file, which is easy to forget.

That, and given that some modes in (M)Elpa may be unmaintained — I don't see
native-comp warnings go away any time soon.

I do sympathise your wish to improve (M)Elpa packages. But the discussed problem
with the wrong emoji shown is not a problem of those modes, it's the Emacs
problem. When you see "BIG RED ERROR" for a harmless warning from a `foo-mode`,
the bad experience is not related to `foo-mode` but to Emacs that disturbs a
user for no reason.

Simply changing emoji would still show interested users there is a problem with
their mode that they can fix, but at the same time would avoid attributing
negative experience to Emacs per se.