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: Fontification error backtrace [Was: Why is it so difficult to get a Lisp backtrace?] Date: Wed, 29 Jun 2022 22:00:54 +0300 Message-ID: <83r1375m6x.fsf@gnu.org> References: <87edzchi3d.fsf@gnus.org> <83sfnsadow.fsf@gnu.org> <83o7yg9f0w.fsf@gnu.org> <83r1396lvr.fsf@gnu.org> <83edz87ivz.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3735"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 29 21:04:13 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 1o6cyy-0000gS-NA for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Jun 2022 21:04:12 +0200 Original-Received: from localhost ([::1]:41036 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6cyx-0007xo-4v for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Jun 2022 15:04:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57582) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6cvi-0006IS-2f for emacs-devel@gnu.org; Wed, 29 Jun 2022 15:00:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35052) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6cvh-00020t-2W; Wed, 29 Jun 2022 15:00:49 -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=ieSsJ5f5iYSbQNEJyMEqU9kONt8LdlfQvs0sbITtWC8=; b=CPJYMy43K0bx XwtY6tRPWJYsFZ6XOxonEoZviSepZ1Q6YrkfQ9o0j2dI4ttwYn30n3Q3htkXNGKg0JhEOL8Eiacp+ aSpCyPXQEalC9iN4AxeGqpYKQJSFM7ObF1QkD0KJIfcuEBI6wP1j3A3KyBdSM2r+3tVCQQxiiJMx/ xsCY0mTQ1PVrkdP5Nj5zGV4ftG9mpEiEEtJuGUHpYFyfdUWJM32fG43Qac0Fvyk3culltIwvVnSgv 2XHQ9f4zkwRys5XoHUiFoMZuklNUt84uGK5mceyArUANuA8nOwTYrJhRO1nCPXVIaCn0e4d4baidL /o/9SrzOD8ptevASs0bQdQ==; Original-Received: from [87.69.77.57] (port=1286 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 1o6cvg-00035w-D8; Wed, 29 Jun 2022 15:00:48 -0400 In-Reply-To: (message from Alan Mackenzie on Tue, 28 Jun 2022 19:31:59 +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:291725 Archived-At: > Date: Tue, 28 Jun 2022 19:31:59 +0000 > Cc: larsi@gnus.org, emacs-devel@gnu.org > From: Alan Mackenzie > > > > *Messages* just doesn't feel the right place to put a backtrace. > > > That's where we currently log all the errors during redisplay, since > > Emacs 21.1. So why this one is different? > > It's not a single line, or a small number of lines. It could potentially > be a stack overflow error, generating a large backtrace, which might have > more lines than message-log-max. We could temporarily bind message-log-max to a larger value, if that's the problem. But I really doubt that something like this could be an issue in practice. > > But you _really_ dislike *Messages*, then put the stuff into another > > buffer, like *backtrace-in-redisplay* or somesuch. > > I'm currently using the buffer *Backtrace*. Is there anything wrong with > that? Not that I see, no. > > The buffer with warnings pops up very soon after redisplay, which is > > more-or-less exactly what you wanted? > > 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. > 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. > > It will, because any Lisp we call goes though safe_eval. The only > > reason why your original proposal didn't was because it bound the > > variable which enables this only in handle_fontified_prop. But we > > don't need this flag if the logic to decide what to do with the error > > will be in save_eval_handler. > > 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. > > And you need to consider one more factor: code from display engine, > > including fontification via handle_fontified_prop, is called also from > > user commands, not via redisplay_internal. For example, commands like > > C-n and C-v invoke display code. Errors signaled there _can_ be left > > to go to top-level and probably could call the debugger. To test > > whether any given code was called from redisplay_internal, test the > > value of the variable redisplaying_p. > > OK, this is a further complication. But it would be good to get to the > debugger if possible, rather than just having a "historical" backtrace. If the display code is called from "normal" commands, you can.