GNU bug report logs -
#60854
Adjust icons shown with warnings
Previous Next
Full log
Message #58 received at 60854 <at> debbugs.gnu.org (full text, mbox):
On Fri, 2023-03-31 at 10:05 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
> > Cc: 60854 <at> 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.
This bug report was last modified 179 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.