Re: Docstring hack

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]

On Sun, Jul 31, 2022, 3:56 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Po Lu <luangruo@yahoo.com>
> > Cc: owinebar@gmail.com,  emacs-devel@gnu.org
> > Date: Sun, 31 Jul 2022 15:24:13 +0800
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > OK, but I still lack some glue to understand the issue.  Specifically:
> > >
> > >   . the OP said "strings that are erroneously treated as docstrings in
> > >     dump mode" -- where's the code which makes that mistake, and how
> > >     is read_literal_string related to that mistake?
> >
> > He's referring to this part of lread.c:
> >
> >   /* If purifying, and string starts with \ newline,
> >      return zero instead.  This is for doc strings
> >      that we are really going to find in etc/DOC.nn.nn.  */
> >   if (!NILP (Vpurify_flag) && NILP (Vdoc_file_name) && cancel)
> >     {
> >       unbind_to (count, Qnil);
> >       return make_fixnum (0);
> >     }
>
> Does this mean that just resetting purify-flag is enough to avoid the
> problem?  If so, I think purify-flag is only meant for preloaded
> packages, and dumping Emacs with additional packages isn't supposed to
> set that flag.  Or maybe loadup.el should load an additional file
> (beyond site-load and site-init), after it resets purify-flag?
>

I'm not sure why you'd not want to use the purify flag, since there are a
lot of explicit calls to purecopy that appear intended to take advantage of
hash consing.  I don't know why that benefit should not apply to libraries
being preloaded by site-load and site-init.


An alternative is, of course, to make that code in lread.c smarter in
> detecting doc strings and applying that handling only to doc strings.
>
> > >   . why isn't there an alternative to fix read_literal_string not to
> > >     generate zero instead of the format template? the other
> > >     alternatives all look like partial kludges to me
> >
> > I can't answer this question, sorry.  You'll have to ask the OP.
>
> I did: the OP was on the CC list.
>

My fifth alternative was to implement the substitution of 0 directly in the
evaluator semantics, so that it would only record 0 for actual docstrings
identified while evaluating source code forms during dump mode.
That seems like overkill if this is only required for loaddefs.  But the
manual should probably state that files loaded in site-load and site-init
need to be byte compiled for their docstrings to be dynamically loaded.

Lynn

[-- Attachment #2: Type: text/html, Size: 4074 bytes --]