emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: perform autoloading when docs is missing from autoload object


From: Arthur Miller
Subject: Re: Patch: perform autoloading when docs is missing from autoload object
Date: Wed, 22 Sep 2021 18:18:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 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*).

Sorry for bit late answer, I was little busy with playing with help-buffer, so
wasn't have so much time for anything else. I wanted to try this with Emac -Q to
be sure it's not my init file.

I did as you describe, and just loaded the file in Emacs -Q, but it still puts
in embedded docs. I am not sure, I have just been looking now around, without
actually exectuing anything, but I think that the actual data is emitted in

(defun autoload-print-form (form)) in autoload.el, and I don't see there
anything about offsets.

But I am not sure about it, to be honest; was just quick look at the pipleine. I
have tried to trace package-quicstart-refresh calls, but I didn't come out more
informed than I was before, so I will leave it for the moment.

>> 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`.

Cool, thank you for the info. Can't generated autoloads use the same trick for
every file? I reason that every .elc file installe din elpa is known at compile
time and load time as well. Since file itself is recorded in autoload object,
can't the same be applied? Or are there more details in the play? 

>> 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 :-(

As mentioned above, I just tried with Emacs -Q and doing as you described, but I
just see embedded docs. I am not trolling or anything, I'll be glad to help to
find why is it so if I can.

>>>> 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.
>
Indeed require/provide mechanism is a good thing and I also think it is not that
important.

When you touch on loading files; may I ask, if you have time to anser; why
require/provide isn't automated in a sense, that it always provide a feature
equaly named as the file loaded?

When I was learning  about it, as I understand, a file can provide several
features, which not many elisp file actually do. It can also be used to name
feature differently from the file itself, which few actually do. It is all good,
flexibility is always good, but for if I would like to check if a file is
loaded, and I don't know which features it provides, if any, do I have any easy
way of knowing it? I can look at load-hist and serach in lists, but it is very
convenient to say, as an example, (require 'subr) and be confident that the file
won't be loaded if it is already loaded. 'load' loads files unconditionally,
right? It probably should since it is a low-level function I guess. Sorry if I
am asking too much, there is so much to learn about Emacs :). 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]