From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Docstring hack Date: Sat, 30 Jul 2022 08:14:10 -0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000faa6fa05e504b45f" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32796"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 30 14:15:06 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oHlN4-0008Hu-0D for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Jul 2022 14:15:06 +0200 Original-Received: from localhost ([::1]:36846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHlN2-0000nA-Be for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Jul 2022 08:15:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHlMQ-00005J-LX for emacs-devel@gnu.org; Sat, 30 Jul 2022 08:14:26 -0400 Original-Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]:38698) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHlMP-00007i-4N for emacs-devel@gnu.org; Sat, 30 Jul 2022 08:14:26 -0400 Original-Received: by mail-pg1-x534.google.com with SMTP id e132so5951373pgc.5 for ; Sat, 30 Jul 2022 05:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=KqsNGN1d6uyuVkFoH4fUsXts4s8cEoqonIQrMDdqeEc=; b=O/5z8r3yBiQN3D+/hQL7B30rK3a4/qcpZaKvunjkvUWwOJkwp2AqZM3psfEGDPQHU+ frV+ZepdaL3RV9lANYkQYBa5qeQgnlX3n3Ur7rhRLPEFG9K5HOl4ta2NYP2VHygZ+nhF fw7Rdu//45j36iVx+zA+6OT+T5e3k3NGWMQ9OO+OgxezkBoKu+TVjPB8ruMdef3SMKDF 8BlwkoLyvMtLcWjtXpLx4NlE3w3dn3PkNvYvVKj19IMNekKm0TDSkW2a/krXcnw/nPoq QysCSU49q3lfM1kO4eqUwZtpUmgyMErlaG7itUUqLd4YQKcaNOmZNXNStuHBSOJq7o5w D02Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KqsNGN1d6uyuVkFoH4fUsXts4s8cEoqonIQrMDdqeEc=; b=cN+NSoD80DBLzclb3ZWNlb5Oasps2H/PBbthydDMhysmcgx6PCyhqgP9QJDm71Zah3 UKpAbPLThsg3Yit6G5m9sFxr5xMXoQR7TVmQoBQsG3GMBnToBuEa+MnNBGoHLoYCswn2 oMQNDYFmhoHaIwT+oPQOVFxnP4WRtCR3C06USlxm2ubnAk4lJ6/2Rd3gCcqfTEHdwk0N dPkj9wQcIYB4HM6IF5/PKNdBGkh79/MdrCkilsgrTY9viFzN6po9x9FlfLIfSpTBgaMg 4bF5iKU+cfFH2MKDbshsXbg4WCQnkqYIYBWsJXvHqYK/BlcvGPLnYyxTAIF96pl/IGfY hstQ== X-Gm-Message-State: AJIora9fjj4tKqXVMnREEFISthh+cZDzN3BQs2xJZA7ICDxgqQieFN45 fFNL6m/FjZq6a+oqUjz7vLopW6F5/8msH5yReEtbGdMF X-Google-Smtp-Source: AGRyM1tKRDxOoJu+vYUcxYBbXCyI75Mguepsu8ka8QonS5wyqL6O8F/LHXP0ddgbPc942X0aZQuWYAdVCfr7/cv8F0E= X-Received: by 2002:a63:5302:0:b0:412:219:928f with SMTP id h2-20020a635302000000b004120219928fmr6253601pgb.425.1659183262507; Sat, 30 Jul 2022 05:14:22 -0700 (PDT) Received-SPF: pass client-ip=2607:f8b0:4864:20::534; envelope-from=owinebar@gmail.com; helo=mail-pg1-x534.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292869 Archived-At: --000000000000faa6fa05e504b45f Content-Type: text/plain; charset="UTF-8" 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? Lynn --000000000000faa6fa05e504b45f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The core em= acs lisp libraries are riddled with strings that are erroneously treated as= docstrings in dump mode, which causes problems in the build when, say, for= mat gets a 0 as its template string in a macro expansion.=C2=A0=C2=A0
=
There are a few possible fixes I see, I'm not sure wh= ich is most likely to be accepted.
1) Change every n= on-docstring that starts with and explicit escaped newline to start with \n= instead (there are a lot of them)
2) Change read_li= teral_string in lread.c to respect the setting of the dynamic-docstring set= ting the way the byte compiler does, and change all the lisp files not in l= oadup.el to set it to nil
3) Like 2, but make the de= fault setting of dynamic-docstring nil and either set it as a local variabl= e 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 "wil= l_dump_p" rather than the purify flag, since it's the dumping that= prompts the deferral of docstring loading, not the identification of const= ants.

Any preferences?

Lynn

--000000000000faa6fa05e504b45f--