From: Arthur Miller <arthur.miller@live.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Patch: perform autoloading when docs is missing from autoload object
Date: Sat, 18 Sep 2021 20:25:09 +0200 [thread overview]
Message-ID: <AM9PR09MB49771D6DD7F85BFF7BDD273196DE9@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <jwvmtoa9fxd.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Sat, 18 Sep 2021 09:37:57 -0400")
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.
next prev parent reply other threads:[~2021-09-18 18:25 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 [this message]
2021-09-20 17:02 ` Stefan Monnier
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=AM9PR09MB49771D6DD7F85BFF7BDD273196DE9@AM9PR09MB4977.eurprd09.prod.outlook.com \
--to=arthur.miller@live.com \
--cc=emacs-devel@gnu.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 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).