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: Redisplay hook error bactraces [Was: Fontification error backtrace] Date: Wed, 13 Jul 2022 15:33:07 +0300 Message-ID: <837d4hw5to.fsf@gnu.org> References: <83sfnsadow.fsf@gnu.org> <83o7yg9f0w.fsf@gnu.org> <83r1396lvr.fsf@gnu.org> <83edz87ivz.fsf@gnu.org> <83r1375m6x.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16101"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 13 14:34:07 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 1oBbZ8-0003xn-5b for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Jul 2022 14:34:06 +0200 Original-Received: from localhost ([::1]:50310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oBbZ6-0002PF-Qm for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Jul 2022 08:34:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37320) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBbYM-0001UW-Hw for emacs-devel@gnu.org; Wed, 13 Jul 2022 08:33:18 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51652) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBbYL-00032E-GO; Wed, 13 Jul 2022 08:33:17 -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=TZs36kaKApcWgHjfOQAhNlVeCXQX2OsDsqmMEtppDRA=; b=SsENzn4yZJNJ mGX6aYu34/tVKA6ljj7D9sMwSovEuZbIdmzSQSs7Nvk6eMAyfLcE+Aq+Y4aK2/yYNPxHOyCQnjVpY 0uTLLlrLnm/ibRgri7wHmCNfsDtGRWi6KWAuzoUzjdkXp3EakjPII8mW07RO48sqU7aRsMIlef986 WtriawB+lRg7cC8LMHrS0lEqTGRNxogQQlrgXp6+TOtUqknonPqR6LJeJHNNpFD9Y3v9Beskzy77o mfaiv5rCCkg0TSJyZTNzETFsSmif1QJGidGGGI5iroAB/QDWMYxt9e5Ps+GamxZTZzF7BQoKSBLNR IEJWEVE8VR3yJWdhLLqikA==; Original-Received: from [87.69.77.57] (port=4917 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 1oBbYK-0007ko-T6; Wed, 13 Jul 2022 08:33:17 -0400 In-Reply-To: (message from Alan Mackenzie on Tue, 12 Jul 2022 19:48:49 +0000) 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:292103 Archived-At: > Date: Tue, 12 Jul 2022 19:48:49 +0000 > Cc: larsi@gnus.org, Stefan Monnier , > emacs-devel@gnu.org, acm@muc.de > From: Alan Mackenzie > > To use it, set the variable backtrace-on-redisplay-error to t. There's no such variable in the patch. > Optionally, configure redisplay-last-error, which determines which > backtrace(s) to keep, should a command cause more than one. Why do we need two variables for that? why not a single variable that is not a boolean? > > > OK, I've never used it. On reading the documentation, I expected it to > > > wait until after the next command. > > > That's because the ELisp reference manual describes it from the POV of > > setting up the warning as part of some command. And even then, it > > says: > > > The value of this variable is a list of warnings to be displayed > > after the current command has finished. > > > "Current command", not "next command". > > > If you add a warning to the list inside redisplay, it will pop up > > after redisplay returns. > > I've tried to use it, but the list of warnings does indeed wait until > after the next command before being displayed. I think it's a terminology issue: how do you define "next command" in this context? I'm telling you: we have code in the display engine that uses delayed warnings, and the warnings pop up right away, not after one more command. > > > Now I remember why I created the backtrace in signal_or_quit - it needs > > > to be done before the stack gets unwound, which happens later in > > > signal_or_quit. On return to save_eval_handler is just too late for > > > this. > > > That's orthogonal, I think? You can collect the data inside > > signal_or_quit, and the signal handler then only needs to handle the > > error gracefully after it adds the warning. > > The "handling" of the error is to allow the redisplay to continue, just > as though no backtrace were generated. Since there's no possibility of > user interaction or a recursive redisplay, that should be OK. I don't understand this response. It seems to be unrelated to what I wrote. > > > Then the mechanism I've implemented, namely to set redisplay_deep_handler > > > to the handler which would handle an error, could be made to serve for > > > other sorts of Lisp code. > > > It could, but I see no reason for having a new handler. > > Sorry, I didn't express that well. That variable redisplay_deep_handler > merely records the handler that a condition-case might use. In > signal_or_quit, if the handler about to be used matches > redisplay_deep_handler, then a backtrace gets generated. ??? You use a handler as a flag? Then why not just use a simple flag variable? > + /* If an error is signalled during a Lisp hook in redisplay, write a > + backtrace into the buffer *Backtrace*. */ > + if (!debugger_called && !NILP (error_symbol) > + && redisplay_lisping > + && backtrace_on_redisplay_lisp_error > + && (!backtrace_yet || !NILP (Vredisplay_last_error)) > + && (NILP (clause) || h == redisplay_deep_handler) > + && NILP (Vinhibit_debugger) > + && !NILP (Ffboundp (Qdebug_early))) Why do we need so many conditions and flags? Why do we need a new variable redisplay_lisping, when we already have redisplaying_p? Why do you need to compare both redisplay_deep_handler and backtrace_on_redisplay_lisp_error? And what is the test of backtrace_yet about? I still hope this could be done more elegantly and with fewer changes to infrastructure. Thanks.