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

[Konstantin Kharlamov]

On Fri, 2023-03-31 at 10:54 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: 60854@debbugs.gnu.org
> > Date: Fri, 31 Mar 2023 10:48:12 +0300
> > 
> > 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.
> 
> Better testing should fix these.

Sure. Setting up a CI to run upon PRs before they're merged would be ideal. But
I don't believe people will start doing that just because there is native-comp
now.

> > That, and given that some modes in (M)Elpa may be unmaintained — I don't see
> > native-comp warnings go away any time soon.
> 
> Well, they went away in Emacs a long time ago.  So it's doable.

Last I checked Emacs was maintained 😄 For unmaintained modes there will be
simply no one to merge fixes that someone creates.

> > 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.
> 
> Feel free to suggest defcustoms to allow users to customize the
> symbols.  That should leave everyone happy.

The problem is about OOTB behaviour. (although now that I think about that, Doom
Emacs which seems quite popular could maybe replace the emoji in their config.
Hmm…)

> In any case, it's too late to suggest such changes for the emacs-29
> branch.

I see. Oh, well…