Re: Docstring hack

[Eli Zaretskii <eliz@gnu.org>]

> 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?

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.

Thanks.