From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: emacs.pdmp not always rebuilt Date: Mon, 04 Oct 2021 16:02:18 +0000 Message-ID: <6c697805389e10ec3f23@heytings.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> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1797"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 04 18:07:31 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 1mXQV1-0000ED-CG for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Oct 2021 18:07:31 +0200 Original-Received: from localhost ([::1]:56544 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXQUz-0006vf-WD for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Oct 2021 12:07:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXQQD-000273-4z for emacs-devel@gnu.org; Mon, 04 Oct 2021 12:02:33 -0400 Original-Received: from heytings.org ([95.142.160.155]:37106) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXQQ2-0004Dg-HZ; Mon, 04 Oct 2021 12:02:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1633363339; bh=niBgGcwyGQMRWduHkGSDO5iWj88Ruds6l8xpr900UqU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=SY5gN4MC7ji6CsyVSGjLhNqte1z4I9z6s9EKVA4uP8y8FUmb/y6Pt6x/0R8v73Awv JNg/r1Ys3d+AE883MDWqLQpF2XH/Yf24KX9sVNFANmXkgNyagIuDMMYYAe8l7AIRHM sziECI11FA1Go4LzhVLbsAi8x6cldOW9wsr0k4gXQw+e3bltt8k8pjkFc3R+0nBKq0 NYElC3E1VEgsY7yKU0LyiU9zv25xq2gYgVX4wYrwp1tfI3hyFG1tOkY8PjNiZv3ZaD 2hAoHATM6it5G4NCjE0WM++p3ES4JNORAqANPdZNOP95Oz2QO7c1dmcozg67vHAJnY FRSpqjaPlM9Kg== In-Reply-To: <83tuhw6epn.fsf@gnu.org> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:276220 Archived-At: >>> What do you mean by "debugged or updated", and how would that affect >>> what we do at loadup time, but not what we do at any other time, >>> including in interactive sessions? >> >> The problem that Lars, you and possibly others experienced (make >> continuing when it should have stopped) was due to the fact that "call1 >> (Qsubstitute_command_keys, Fget (errname, Qerror_message));" in >> print_error_message() failed when it was called while loading the first >> files in loadup. Are you sure that this call to call1 cannot possibly >> fail when fboundp is t? > > 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.