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

[Arthur Miller]

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

>> I just tested with generated package-quickstart.el file. Below is what I get
>> when I M-: (symbol-function 'winum-select-window-0), as both before I
>> byte-compiled and after I byte-compiled:
>
> How did you perform the test?

If I remember well, we have removed the no-byte-compile form the
package-quickstart.el a while ago. I just re-created new one, and I can confirm
that is no file-local variable that forbids it to be byte compiled. When I
checked yesterday the file was truly byte-compiled. I opened .elc file and
evaled it when I was writing the mail.
>
> I tested it on my end with the `loaddefs.el` file and "it worked", but
> it required several tweaks (like removing the `no-byte-compile:t` from
> the file-local variables, and telling `loadup.el` to load `loaddefs`
> rather than `loaddefs.el`).

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

> So I wouldn't be surprised if you need to take extra steps to convince
> Emacs to compile the file and to load the compiled version of the file.

Aha. Maybe. Than I am not sure how to do it.

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

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

>> I certainly have no problems if autoloads generation is fixed and
>> built-in autoloads file generator emitted byte offsets instead of kilo
>> bytes of fully embedded docs.
>
> Indeed, I think we should be possible to change `autoload.el` so that it
> directly generates the "comment + byte-offsets" form in the .el files
> so we don't even need to byte-compile them.  Not sure if it's a better
> than byte-compiling them.

I am not either, it is a lot of data that gets pulled in when docs are
compiled. Maybe left it as a user option?

>> But there is the case that nil is a valid value for doc in autoload
>> object, and thus I think it is still important to fix help system, to
>> fetch docs on demand.
>
> That's true.  We could also just always use nil and always load the
> source file to find the doc.  I'm not sure in that case it'd be worth
> the trouble trying to avoid loading the whole file (I think it'd take
> a fair bit of effort to make it work reliably enough).

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

But I think that you are correct; it might not be worth the trouble,
since it would take quite some parsing effort to do it well, if it is even
possible. I think it could only be those symbols that are more or less
explicitly defined as defun, defmacro, defconst, defvar etc.

Indirect definitions are almost impossible to find but I don't think those are
recognized by completion either, so they are probably not possible to request
with describe-* functions.

I have some parsing code I wrote tonight to pull in source for symbols (instead
of built-ins I used yesterday, as seen in patched help-mode.el in the bug report
I filed). What I have noticed is that I can't request from Emacs to give me 
docs for
'package-desc' which is a cl-defstruct in package.el, because completion does
not seem to recoginze it as a symbol. But maybe I am wrong about that one, I am
not sure there.