From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Matt Armstrong <matt@rfc20.org>
Cc: 59707@debbugs.gnu.org
Subject: bug#59707: 29.0.50; Seeking a more robust `package-quickstart'
Date: Wed, 30 Nov 2022 08:11:29 -0500 [thread overview]
Message-ID: <jwv7czca9at.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87cz95rnhf.fsf@rfc20.org> (Matt Armstrong's message of "Tue, 29 Nov 2022 21:59:56 -0800")
> 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
next prev parent reply other threads:[~2022-11-30 13:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 0:14 bug#59707: 29.0.50; Seeking a more robust `package-quickstart' Matt Armstrong
2022-11-30 2:37 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-30 5:59 ` Matt Armstrong
2022-11-30 13:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-11-30 19:13 ` Matt Armstrong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv7czca9at.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=59707@debbugs.gnu.org \
--cc=matt@rfc20.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.