RE: Better startup error handling

["Drew Adams" <drew.adams@oracle.com>]

> > Downsides: loads the byte-compiler even in sessions that 
> > don't need it, and notably inefficient.
> 
> Exactly: in theory it's straightforward, but doing it well 
> will require more work.  IIRC there are some other issues such as
> the fact that .emacs code tends to be very different from typical
> code in Elisp packages, and the kinds of things we want to flag
> aren't all the same (some things are acceptable/normal/unavoidable
> in one but not in the other).

No flames please, but I have a different objection to this idea.  Perhaps you
hinted at in in your last sentence - not sure.  Anyhooo...

.emacs is something that many non-Lisper users use.  Sometimes they load
3rd-party libraries from it.  Sometimes they include 3rd-party snippets directly
in it.  Whether that makes sense in general or for any given library or snippet
is beside the point here.  It is done, and rather often, I believe.

Some such libraries or snippets are designed to work with more than one Emacs
version.  As such, it can be the case that some of the byte-compiler warnings,
e.g. function calls with the wrong number of args or functions not known to be
defined, are not relevant in the end.  The byte compiler is just not smart
enough to get everything right, and understandably so.

That is, some such warnings might be relevant and helpful to some users and are
probably so to developers of the libraries or snippets included, but they are
not necessarily relevant to some other users.  And those are the users whom we
are most worried about wrt the thread Subject line.  They are the users who are
least likely to know what to do when they run into a startup problem etc.

And - and this is important in my experience - some users do not understand, or
misunderstand, when then see such warnings.  Warnings can even frighten people
when they are not understood.  I've gotten more than one question or bug report
which I replied to by reassuring the user that some such warning is not really
relevant in the current situation etc.  I'm probably not alone in that.

In sum, my objection is that we will be throwing warnings at users who will not
necessarily understand them and will not necessarily need to see them anyway.
And yes, I do think this is potentially a big problem, for both users and the
developers of code they use.  Throwing byte-compiler warnings at users to handle
or prevent startup problems is the wrong cure, IMHO - really wrong.

The byte compiler for any given Emacs version is what it is.  It can be helpful
but it is certainly not perfect.  And in particular it is not always on target
when it comes to code that has to work with different Emacs versions.

This problem tends to get worse as the byte compiler gets more helpful (almost
put that word in quotes ;-)), more verbose, more finnicky.  Systematically
applying the byte compiler to user .emacs files sounds like a colossally
misguided idea, to me.