emacs-devel
[Top][All Lists]
Advanced

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

Re: Docstring hack


From: Po Lu
Subject: Re: Docstring hack
Date: Sat, 30 Jul 2022 20:25:24 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)

Lynn Winebarger <owinebar@gmail.com> writes:

> The core emacs lisp libraries are riddled with strings that are erroneously 
> treated as docstrings in dump mode, which causes problems in the build when, 
> say, format gets
> a 0 as its template string in a macro expansion.  
> There are a few possible fixes I see, I'm not sure which is most likely to be 
> accepted.
> 1) Change every non-docstring that starts with and explicit escaped newline 
> to start with \n instead (there are a lot of them)
> 2) Change read_literal_string in lread.c to respect the setting of the 
> dynamic-docstring setting the way the byte compiler does, and change all the 
> lisp files not in
> loadup.el to set it to nil
> 3) Like 2, but make the default setting of dynamic-docstring nil and either 
> set it as a local variable in the files in loadup, or set it in loadup when 
> dump-mode is set
> 4) Make a special read syntax for literal docstrings, e.g. #", and do away 
> with the weird context-sensitive semantics of ordinary string literals 
> altogether.
>
> Also, the test in read_literal_string should probably be for "will_dump_p" 
> rather than the purify flag, since it's the dumping that prompts the deferral 
> of docstring
> loading, not the identification of constants.
>
> Any preferences?

None in particular, except that option 4 is unacceptable as it is not
compatible with older code, and is completely different from all other
Lisp implementations.

Thanks.


reply via email to

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