unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Arthur Miller <arthur.miller@live.com>
Cc: emacs-devel@gnu.org
Subject: Re: Patch: perform autoloading when docs is missing from autoload object
Date: Mon, 20 Sep 2021 13:02:47 -0400	[thread overview]
Message-ID: <jwvh7efyyxx.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <AM9PR09MB49771D6DD7F85BFF7BDD273196DE9@AM9PR09MB4977.eurprd09.prod.outlook.com> (Arthur Miller's message of "Sat, 18 Sep 2021 20:25:09 +0200")

> I tested with package-quickstart. As said, manually opened .elc and
> evaled the buffer.

Hmm... Can't see an obvious reason why it didn't do "the right thing"
for you (tho `M-x eval-buffer` will result in an unusable (FILE . OFFSET)
pair because the `load-file-name` var is not setup; a better test is to
load the file, but that doesn't explain why you ended up with an actual
doc *string*).

> By the way, when I was reading the manual, and testing all this, I could see
> that autoloads from Emacs sources were with offsets in autoload object.

Yes, this a special case: they're offsets into the `etc/DOC` file,
generated by the `lib-src/make-docfile.c` auxiliary tool.
This so as to bring the cost down further: instead of (FILE . OFFSET) we
can use just OFFSET where FILE is known implicitly to be `etc/DOC`.

> But I couldn't see those from installed packages. That is why I have
> finally ditched the entire package-quickstart and Emacs
> autoload generation.

Looking at the code, everything seems to be in place such that
byte-compiling the `package-quickstart.el` file *should* end up with
(FILE . OFFSET)s, but I haven't tested it to confirm yet.
You say it doesn't work, so apparently there's something somewhere that
still gets in the way :-(

>>> So the entire business of docs in autoloads is due to autoload file generation,
>>> seems to me, if I don't misunderstanding something?
>> I'm afraid I don't know what you mean by "business of docs in autoloads".
> Eh; sorry, that was a goofy expression. I meant that documentation ends up
> in autoload objects, because Emacs code that scrapes for autoloads explicitly put
> it there. I am no 100% sure, that is just my assumption, I hoped you would say
> yes or no :).

Ah, well then "yes" ;-)

> Rationale was that it is faster to just parsing with 'read' without loading
> structures in the memory;

Most Elisp files can be loaded fairly quickly (some exceptions are
things like `org.el` that pull in a lot of dependencies) and we'd only do
it once per session an only in some particular cases (not in loops,
etc...), so it's not that terribly important.


        Stefan




  reply	other threads:[~2021-09-20 17:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15 13:51 Patch: perform autoloading when docs is missing from autoload object Arthur Miller
2021-09-15 18:14 ` Stefan Monnier
2021-09-15 22:29   ` Arthur Miller
2021-09-17 16:38     ` Stefan Monnier
2021-09-17 16:56       ` Generic autoloading? [Was Patch: perform autoloading when docs is missing from autoload object] Qiantan Hong
2021-09-17 19:36         ` Stefan Monnier
2021-09-17 19:51           ` Qiantan Hong
2021-09-17 21:25         ` Arthur Miller
2021-09-17 21:09       ` Patch: perform autoloading when docs is missing from autoload object Arthur Miller
2021-09-18 13:37         ` Stefan Monnier
2021-09-18 18:25           ` Arthur Miller
2021-09-20 17:02             ` Stefan Monnier [this message]
2021-09-22 16:18               ` Arthur Miller
2021-09-16 12:51 ` Lars Ingebrigtsen
2021-09-17  6:49   ` Arthur Miller
2021-09-17 14:01     ` Lars Ingebrigtsen
2021-09-17 15:04       ` Arthur Miller
2021-09-18 13:21         ` Lars Ingebrigtsen
2021-09-18 16:03           ` [External] : " Drew Adams
2021-09-18 17:34             ` Arthur Miller
2021-09-18 17:31           ` Arthur Miller
2021-09-18 17:53             ` Lars Ingebrigtsen
2021-09-18 18:38               ` Arthur Miller

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvh7efyyxx.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=arthur.miller@live.com \
    --cc=emacs-devel@gnu.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).