bug#71801: emacs 29.4 windows binaries

[Drew Adams]

> > > You need to install GNU Binutils, which is where as.exe, the GNU
> > > assembler, comes from.
> >
> > Why?
> 
> It's needed for JIT native compilation of Lisp.

Until now, there has been no requirement
to have anything that's needed to support
native compilation.  Until now, Emacs just
ignored native compilation if the local
"infrastructure" to support it was missing.

That approach was good.

> > > > I haven't noticed other problems yet (with -Q), but
> > > > is the continual emission of that warning expected?
> > >
> > > Yes.
> >
> > Why is that a good thing to do?
> 
> It isn't supposed to happen in a working Emacs installation.

I see.  You mean the warning itself, or
the need for a user to have whatever's
needed to support native compilation?

> Its absence is like the absence of dired.el/dired.elc: it should not
> happen.  So by default Emacs warns about it every time it wants to
> natively compile a file.

So is it only a problem with the Emacs build,
or is Emacs considering that the user's
context is inadequate and the user needs to
do something to remedy that?

> > > > Clicking that black, square icon pops up this
> > > > question as a menu:
> > > >
> > > >   Suppress `comp' warnings?
> > > >   _________________________
> > > >
> > > >   Yes, Ignore `Comp' Warnings Completely
> > > >   No, Just Disable Showing Them
> > > >   Quit And Do Nothing
> > > >
> > > > I have no idea what any of that means.
> > >
> > > It allows you to disable these warnings, so that they don't annoy you.
> >
> > Sure.  But _what are_ `Comp' warnings?
> 
> They are the warnings labeled 'comp', as in the warning you've shown.

So just as meaningless as if the label were 'foobar'
or 'guess-what-this-means'.

> > How is someone to know whether they might want to (or need to)
> > ignore, disable, or do nothing?
> 
> By reading the warnings, understanding what they say and mean, and
> deciding what to do with them.  It's a user decision.

So this is a user problem, not an Emacs build
problem?  (That's what user warnings are for.)

If so, that's the problem with the warning:
it's not comprehensible to many (most?) users.
The "user decision" can't be based on any real
understanding of what's involved (in this case).

> Isn't it you that always requests to let the
> users the freedom of deciding how to
> deal with non-trivial situations?

Not by not making clear to them what they can
or need to decide, giving them the info needed
to do that.

> That's what Emacs does there.

I don't see it that way.  I don't understand
the message, and it sounds like someone needs
to know something about Emacs builds, its
dependencies, and perhaps native compilation.

That's not my case, and I'd bet it's not the
case of many (most?) Emacs users.

> > Expecting someone to decide which to do makes
> > no sense if they have no idea what the meaning
> > or consequences are (beyond not seeing msgs).
> 
> We expect our users to understand the warnings and make the above
> decision, yes.

I don't think that expectation makes sense for
most users in this case.  It doesn't make sense
for this one who's used Emacs for 40 years.

> > Warnings should be for things that you need to
> > be WARNed about.  If this is one such thing,
> > then we should tell users what the "this" is.
> >
> >  *****
> >  WARNING - there's a FOOBAR in the vicinity!
> >  Quick!  What do you want to do about it?
> >  *****
> 
> That's an unfair comparison.  The warning in question did tell you
> what was the problem: a specific program was missing or could not be
> found.

What's the meaning/consequence of that program
being missing?  What's the importance of this
missing-something warning?  Does a user need
to remedy the lack of the program?  If so, how
to do that?

> > >   Warning (comp): SOMETHING
> > >
> > > and the prompt asks about suppressing "comp" warnings, which fits the
> > > warning ID.  You are showed 3 possible answers with the meaning of
> > > each one of them.  What is not clear here?
> >
> > Nothing is clear.  I'm a user.  I didn't build
> > Emacs.  I see this:
> >
> >  x86_64-w64-mingw32-gcc-11.3.0: fatal error: cannot
> >  execute 'as': CreateProcess: No such file or directory
> >
> > Is that a problem?  I'm warned about it, so I
> > guess maybe it is.  Is it a problem that I'm
> > expected, and that I can, do something about?
> > If so, what needs to be done?
> 
> What needs to be done is find out why GCC could not fine 'as', and fix
> that.

The warning doesn't tell users that they need to
do that, and _how_ to do it.

> Alternatively, you can just shut up the warnings if you don't
> want to know about that.  See the text popped up by the GUI dialog or
> shown by '?' that explains how to deal with that warning.

I saw it, and spoke to that.

> > > > I also notice that if I put point on that icon and
> > > > hit RET I get the question in the minibuffer, but
> > > > with the additional key `?' highlighted (no such
> > > > option in the menu version).
> > > >
> > > > I hit `?' and this is shown in buffer *Multiple
> > > > Choice Help*:
> > > >
> > > > Suppress `comp' warnings?
> > > >
> > > > y: yes, ignore `comp'    n: no, just disable      q: quit and do
> > > > warnings completely      showing them             nothing
> > > >
> > > > That "help" text seems worse than useless.
> > >
> > > It just repeats what was in the menu.
> >
> > And you're just repeating what I reported.
> > Why have the `?' and `RET' binding, which
> > just repeats the text you're clicking `?'
> > for help about?
> 
> It adds some information about the possible responses, something that
> in the case of clicking is already shown in the dialog Emacs pop up.
> 
> > `?', like an `i' Information icon, should
> > tell you something different, or something
> > more, than the text you're already looking at.
> 
> And it does.  Of course, if you already clicked on the icon, you
> already have seen the same information, but users can press RET right
> away, e.g. if they don't have a mouse or don't use it.
> 
> > If you think about it for a few moments, I
> > hope you'll see it's either misguided or
> > it's missing something.
> >
> > We get a "security fix" point release, and
> > the first thing seen is an indecipherable,
> > continually popped-up scary WARNING.  No
> > help from Emacs to understand what's involved -
> > what the danger/problem is, or what to do
> > about it.
> >
> > And your response is that this is all OK
> > and expected?
> 
> No.  My response was quite more than that.

I'd say that the warning isn't very helpful
to many/most users who would encounter it -
unless it's never supposed to be seen and it
results from a faulty Emacs build and is not
really a user problem.

For most users to understand and act on the
problem, I think the info communicated would
need to be much better.

HTH.