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: emacs.pdmp not always rebuilt Date: Mon, 04 Oct 2021 19:56:02 +0300 Message-ID: <83k0is6865.fsf@gnu.org> References: <87h7dyqo02.fsf@gnus.org> <83k0iu8e2u.fsf@gnu.org> <87czomqmn6.fsf@gnus.org> <878rzaqilg.fsf@gnus.org> <83pmsl7cc9.fsf@gnu.org> <6c69780538e7dcf21be8@heytings.org> <83fsth6jjr.fsf@gnu.org> <6c697805381c56ec6eda@heytings.org> <6c697805389a800abc59@heytings.org> <83zgro6hdj.fsf@gnu.org> <6c69780538b8456263b4@heytings.org> <83tuhw6epn.fsf@gnu.org> <6c697805389e10ec3f23@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27291"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 04 18:58:32 2021 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 1mXRIO-0006uL-NP for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Oct 2021 18:58:32 +0200 Original-Received: from localhost ([::1]:36532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXRIN-0001zY-Kj for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Oct 2021 12:58:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXRGA-00085K-6d for emacs-devel@gnu.org; Mon, 04 Oct 2021 12:56:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43256) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXRG8-0007u1-Qi; Mon, 04 Oct 2021 12:56:12 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1035 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 1mXRG8-0004cy-HI; Mon, 04 Oct 2021 12:56:12 -0400 In-Reply-To: <6c697805389e10ec3f23@heytings.org> (message from Gregory Heytings on Mon, 04 Oct 2021 16:02:18 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:276232 Archived-At: > Date: Mon, 04 Oct 2021 16:02:18 +0000 > From: Gregory Heytings > cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > If fboundp returns non-nil, it means the symbol's function cell is not > > void, i.e. the symbol can be used as a function. Right? So the call > > can only fail if the function itself has a bug, right? And in the > > latter case, how is that different from any other Lisp function called > > during loadup? > > It's different, precisely because it is not a function among other > functions, it's the function that signals an error. And as we've just > seen, if the function that signals an error itself fails, unexpected > behavior can happen, especially when this happens during bootstrap. > > I would have taken extra care to avoid that possibility, especially given > that the importance of substitute-command-keys on error messages during > bootstrap is close to zero. Perhaps I did not look close enough, but I > could not find a single error message where substitute-command-keys would > have had an effect, and even if there are a few, seeing "Command > \[foobar\] blah blah" instead of "Command M-x foobar blah blah" or > "Command C-x % blah blah" does not make a big difference. Ah, that argument... That train has left the station long ago, and your argument is then not with me. I'm just the janitor, cleaning up after the train that left, trying to have a tidy station nonetheless.