[Top][All Lists]

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

Re: Docstring hack

From: Lynn Winebarger
Subject: Re: Docstring hack
Date: Sun, 31 Jul 2022 08:53:57 -0400

On Sun, Jul 31, 2022, 3:56 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Po Lu <luangruo@yahoo.com>
> Cc: owinebar@gmail.comemacs-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.


reply via email to

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