unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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: Fri, 17 Sep 2021 23:09:29 +0200	[thread overview]
Message-ID: <AM9PR09MB4977ED30126607C55E0B1AB596DD9@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <jwvpmt7gona.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 17 Sep 2021 12:38:00 -0400")

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

>> Indeed. My thoughts were to read .elc when avialable,
>
> I'm not sure you're familiar with the way it works for functions, but
> basically the docstring is replaced by a "pointer" that's a cons cell
> that combines the name of the file from which the function was loaded
> together with an integer indicating at which byte-offset the docstring
> can be found (the filename string is the same string used in all the
> docstring of that file as well as the string used in `load-history`, in
> terms of memory cost, it only really costs a single con-cell).

Actually I was quite aware of that part, and how it works there. I looked at
that very explicitly. I am quite aware that it costs just an offset there, and I
don't have anything against that. I have no intention to do anything for that
case, it works as it is. I am not sure that we speak about the same thing.

I am talking about the case when there is a nil for doc, and library needs to be
autoloaded. When I ask for the help form describe-function, if there is a 'nil
in the autoload object itself, I would prefer not to load the entire library
just to load the symbol documentation for the use in help-mode buffer. Lars
expressed some concerns about loading library just for the doc purpose, so it
might be more appropriate in that case.

> So there'd be no need for "when available" heuristic.

Yes, in case you have that pointer, which I wasn't objecting to at all, but not
when you have a nil instead of that pointer. Or am I wrong there? 

> And all the code is already there to do the same for autoloads.
You mean to start generating those pointers instead of embedding the docs? It
would be an improvement indeed :). Still the case of hand-crafted code or code
generating but something else than supplied autoloading routines leaves for a
fully valid nil to be a part of the autoload object.

> All it takes is to start compiling the autoloads files.

Ok, but it does not seem that it works the way you say, at least not atm. This
is what I see in my Emacs, correct me if I do something wrong here.

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:

(autoload "winum" "Jump to window 0.
If prefix ARG is given, delete the window instead of selecting it.

(fn &optional ARG)" t nil)

It is also fully possible that someone prefer to omit anything optional :):

#+begin_src emacs-lisp
(autoload 'academic-phrases "academic-phrases")
(autoload 'academic-phrases-by-section "academic-phrases")
(autoload 'ace-select-window "ace-window")
(autoload 'ace-delete-window "ace-window")
(autoload 'ace-swap-window "ace-window")
(autoload 'ace-delete-other-windows "ace-window")
(autoload 'ace-display-buffer "ace-window")
(autoload 'ace-window "ace-window")
(autoload 'ace-window-display-mode "ace-window")

( ... )
#+end_src

That is a fragment of what I use instead of quickstart file. I do compile entire
autoloads file together with my init.el, but I don't get any pointers to doc by
default. After compilining my own autoload.el, byte compiling it, loading and
evaling same (symbol-function 'winum-select-window-0):

Loading /home/arthur/.emacs.d/autoloads.elc...done
Mark set
(autoload "winum" nil nil nil)
Mark set

I thought maybe I needed to tell byte compiler that those autoloads are all
functions:

#+begin_src emacs-lisp
(autoload 'academic-phrases "academic-phrases"nil nil t)
(autoload 'academic-phrases-by-section "academic-phrases"nil nil t)
(autoload 'ace-select-window "ace-window"nil nil t)
(autoload 'ace-delete-window "ace-window"nil nil t)
(autoload 'ace-swap-window "ace-window"nil nil t)
(autoload 'ace-delete-other-windows "ace-window"nil nil t)
(autoload 'ace-display-buffer "ace-window"nil nil t)
(autoload 'ace-window "ace-window"nil nil t)
(autoload 'ace-window-display-mode "ace-window"nil nil t)

( ... )
#+end_src

After recompile and reload I get this:

(autoload "winum" nil nil t)

So the entire business of docs in autoloads is due to autoload file generation,
seems to me, if I don't misunderstanding something? 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. 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.



  parent reply	other threads:[~2021-09-17 21:09 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       ` Arthur Miller [this message]
2021-09-18 13:37         ` Patch: perform autoloading when docs is missing from autoload object Stefan Monnier
2021-09-18 18:25           ` Arthur Miller
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=AM9PR09MB4977ED30126607C55E0B1AB596DD9@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).