bug#59707: 29.0.50; Seeking a more robust `package-quickstart'

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

> With this, emacs fails to launch, instead printing:
>
>     Symbol’s value as variable is void: geiser-active-implementations

Did `--debug-init` provide a backtrace?

> The code for `geiser-activate-implementation' was originally:
>
>     (defsubst geiser-activate-implementation (impl)
>       (add-to-list 'geiser-active-implementations impl))
>
> So the `(add-to-list 'geiser-active-implementations 'guile)' ended up
> inlined into "package-quickstart.elc", which executed directly, without
> first (auto) loading 'geiser-impl' as was intended.  Thus, the
> `geiser-active-implementations' variable did not exist, yet was
> referenced, by inlining, but did not appear textually in
> package-quickstart.el.
>
> Once understood obvious fix to make geiser-activate-implementation a
> defun instead of a defsubst.

FWIW, that's a rather poor fix, since it causes `geiser-impl.el` (and
the files it requires) to be unconditionally loaded during
Emacs startup.  The better fix would be to make sure the
`geiser-active-implementations` itself gets initialized before the calls
to `geiser-activate-implementation`.

> Ideas for improvement (also seeking ideas from others)
> ========================================
>
> 0) Make `package-quickstart t' the default, because it is great, and
> that way people tend to see the same kinds of problems.  :-)

I think it's a good idea to do that on `master`, indeed.

> 1) Harden Emacs such that signaled errors from "package-quickstart.elc"
> don't prevent startup (but are somehow saved and logged, maybe as
> warnings?).

Agreed.  I suspect it should also do things like delete the `.elc` file
(and/or the `.el` file), or at least suggest doing it, so as to help
diagnose/circumvent the problem.

> 2) Make --debug-init functional for errors thrown by
> "package-quickstart.elc".  Currently, package-quickstart is loaded
> before the first frame is initialized, so Emacs takes the "print the
> error and exit" route for any signaled errors, instead of, for example,
> ending up in the elisp debugger.

In the case of `--debug-init` it could at least print the backtrace on
`stderr`.  Or store the backtrace and display it later (even though the
debugger wouldn't be active, it would still be nicer to manipulate than
when sent to stderr).

> 3) Perhaps package-quickstart.elc could be loaded later in the
> initialization phase, after the first frame is created?

I'm not in favor of such a change, no.

> 5) Change "package-quickstart.el" code gen to provide more context for
> errors, perhaps with `condition-case-unless-debug'.  The jwigley's
> use-package package does something similar in its macro expansions and
> it is nice.  In the specific case with the geiser packages, because
> Emacs exited immediately, it would have been useful to know that the
> error came from the "geiser-guile-autloads" portion of
> "package-quickstart.elc".

We could probably use `(setq load-file-name ...)` between file chunks
(instead of `let` binding the var) and wrap the whole file with
a `condition-case` which then prints the "current" `load-file-name`.

> 6) Print a warning when a `defsubst' function is autoloaded, as the
> autoload won't work from byte compiled code.

It works.  It just works differently (it copies the whole `defsubst`
instead of placing an `autoload` statement).  AFAIK byte-compiled or not
doesn't make much difference in this respect.


        Stefan