GNU bug report logs - #59707
29.0.50; Seeking a more robust `package-quickstart'

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Matt Armstrong <matt <at> rfc20.org>
Cc: 59707 <at> debbugs.gnu.org
Subject: bug#59707: 29.0.50; Seeking a more robust `package-quickstart'
Date: Wed, 30 Nov 2022 08:11:29 -0500

> I'd rather suggest that the gesier package autoloads simply not use the
> helper function at all.  Instead, just have the autoloads defvar
> `geiser-active-implementations' and call `add-to-list' on it explicitly.
> Seems simpler and unsurprising.

But that exposes the implementation of `geiser-activate-implementation`.
Copying the whole function definition to the autoloads file is "cleaner"
in this sense.

>> 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).
>
> Yes, though see the backtrace above.  It isn't very helpful, at least
> for me, since the bottom of the lisp stack is the current
> `command-error-function'.

The GDB backtrace you got it from a time after the actual Lisp error was
caught, so you didn't get the relevant Lisp backtrace.  If you put
a breakpoint on something like `Fsignal` you'd get something closer.
This said, it's still the case that the backtrace wouldn't show very
much info because the autoloads file is very "flat".

> Ah, ok.  It looks like geiser's autoloads are hand written (and might
> predate package.el), so an actual autoload for the defsubst ends up in
> package-quickstart.el.  See
> https://gitlab.com/emacs-geiser/geiser/-/blob/master/elisp/geiser.el#L104

Ah! :-(

> Yet, geiser wants to support use directly from downloaded source.  What
> is our current suggestion for packages that want to ship their own
> pre-canned autoloads?

Don't do that.  Help us improve `package-vc` instead :-)

> Do you know of a package supporting this without resorting to hand
> edited autoloads?

Most largish packages do, sadly.

> I assume there is some canonical 'emacs -f batch_blah_blah' but,
> maybe not?

Kind of, but it's not very widely advertized (nor defined well enough to
be convenient to use) so it's a bit cumbersome and the actual
incantation used varies.

E.g. Hyperbole uses things like:

    $(EMACS_BATCH) --debug --eval "(progn (setq generated-autoload-file (expand-file-name \"kotl/kotl-autoloads.el\") backup-inhibited t) (let (find-file-hooks) (hload-path--make-directory-autoloads \"kotl/\" generated-autoload-file)))"


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.