[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59707: 29.0.50; Seeking a more robust `package-quickstart'
From: |
Stefan Monnier |
Subject: |
bug#59707: 29.0.50; Seeking a more robust `package-quickstart' |
Date: |
Wed, 30 Nov 2022 08:11:29 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
> 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