From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Docstring hack Date: Sun, 31 Jul 2022 10:56:17 +0300 Message-ID: <83o7x54swu.fsf@gnu.org> References: <83bkt6687a.fsf@gnu.org> <871qu2lo29.fsf@yahoo.com> <837d3u63ez.fsf@gnu.org> <834jyy61w6.fsf@gnu.org> <831qu25z5x.fsf@gnu.org> <87mtcqhvot.fsf@yahoo.com> <83sfmh4x0o.fsf@gnu.org> <878ro9iw2q.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31639"; mail-complaints-to="usenet@ciao.gmane.io" Cc: owinebar@gmail.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 31 09:58:20 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 1oI3q8-00083F-2Q for ged-emacs-devel@m.gmane-mx.org; Sun, 31 Jul 2022 09:58:20 +0200 Original-Received: from localhost ([::1]:35632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oI3q7-0004PZ-66 for ged-emacs-devel@m.gmane-mx.org; Sun, 31 Jul 2022 03:58:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60972) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI3oS-0003Ww-GB for emacs-devel@gnu.org; Sun, 31 Jul 2022 03:56:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51602) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI3oR-00030u-5a; Sun, 31 Jul 2022 03:56:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1rWqVsDi3VlAeC3K3ljQyA/tEDp9EHQZav5+ueW/Jjw=; b=sDtpNnJrLJFP GWjPSpX/plaqvTiIQDxTH7gBpvZ455fFJcCdEEl+fPD+kLLIxi1f0k/PWPx5ZZqA/6n5/O/uKT3wZ iPDBHETn6ZVL9P8PHQVMnydXXLN4V0pnc9rehwjSzraQyIznL0ZW9K5hDDufrPJCAbSetRwkhlADy 6bmerjTv4DzyhekYIXNFxgaWSs7w+XPxkgU9R91BcbSsog45e0teZAA+LZhGRzw0aejI3vkCnMyy/ dpaEkuyU+vpJbgO1g3RTBpetBUG33PUvgMNuHq33VFm0a+Kr+1hLBYqUUyhMFA8jR4XSAaWGssqk0 oLwcvfQx0i8CoUfiVsEfDA==; Original-Received: from [87.69.77.57] (port=1598 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI3oN-0005pQ-0B; Sun, 31 Jul 2022 03:56:33 -0400 In-Reply-To: <878ro9iw2q.fsf@yahoo.com> (message from Po Lu on Sun, 31 Jul 2022 15:24:13 +0800) 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:292901 Archived-At: > From: Po Lu > Cc: owinebar@gmail.com, emacs-devel@gnu.org > Date: Sun, 31 Jul 2022 15:24:13 +0800 > > Eli Zaretskii 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.