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: Tue, 28 Jun 2022 21:17:04 +0300 Message-ID: <83edz87ivz.fsf@gnu.org> References: <87edzchi3d.fsf@gnus.org> <83sfnsadow.fsf@gnu.org> <83o7yg9f0w.fsf@gnu.org> <83r1396lvr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20712"; 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 Tue Jun 28 20:17:56 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 1o6Fme-0005C3-LS for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Jun 2022 20:17:56 +0200 Original-Received: from localhost ([::1]:43346 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6Fmd-0006g9-63 for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Jun 2022 14:17:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35462) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6Fll-0005q8-3O for emacs-devel@gnu.org; Tue, 28 Jun 2022 14:17:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37046) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6Flj-0008Ad-VL; Tue, 28 Jun 2022 14:16:59 -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=TLq6xXaho4wHTsIFAwKEDhe7Z6s47g3LMuy/Hgal9Ww=; b=LCjczQnko6o0 Eg5kKExQ4gU4G8+z298pNBk9qZdRw6aJ/pCNoX3hdxOGONsiixegrW9TCD7xCnuTS23k3dIjMIbX7 hiHUJuMYdMPiUmvpIAXpCJd4dDIrtIfFU6Jpt9y8ayLdM0BEEiws1DAexk8qmc3kBQXpk2OQdO/ud hPX03BPkpCXIfvT8UFrxybd4YE5lCHqti2QP9CoR5UwNkKODh82fLxiKB3SIC4rS61/v4A1VdrmYX cYde+tU6rZF/177QnZPxcEBgoNQkkGyVv9mxg996znIRdblwEYUW9aNHtpkbR5k2roErQiGNOVhm+ mQ1CGdMgdu4WdMOUYlySpA==; Original-Received: from [87.69.77.57] (port=1941 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 1o6Flj-0005N7-EC; Tue, 28 Jun 2022 14:16:59 -0400 In-Reply-To: (message from Alan Mackenzie on Tue, 28 Jun 2022 17:28:38 +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:291695 Archived-At: > Date: Tue, 28 Jun 2022 17:28:38 +0000 > Cc: larsi@gnus.org, emacs-devel@gnu.org > From: Alan Mackenzie > > > > > > > . emit the backtrace int *Messages* > > > > > > . add the backtrace to delayed-warnings-list > > > > > > Why can't the backtrace be generated and stored, and only displayed at a > > > > > subsequent redisplay (probably the next one)? > > > > > That's what the second alternative above already does. > > > > OK, I've got some code. :-) > > > Sigh. I suggested two alternatives, but you effectively > > ignored/rejected both of them. Why? > > *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? But you _really_ dislike *Messages*, then put the stuff into another buffer, like *backtrace-in-redisplay* or somesuch. > delayed-warnings-list consists of a list of structured lists, rather than > the vanilla text output by debug-early. Why is it a problem? You could again stash the backtrace somewhere and only show the name of that buffer in the warning text. Using delayed-warnings-list makes sure the problem is not missed. > Also these delayed warnings get displayed between post-command-hook > and redisplay, which is not an optimal time to display a backtrace > generated in redisplay. The buffer with warnings pops up very soon after redisplay, which is more-or-less exactly what you wanted? > > Third, why are you singling out the fontifications? they are not the > > only source of Lisp errors in code called by the display engine. > > Moreover, handle_fontified_prop is not the only way of calling > > expensive Lisp code that deals with faces. > > All that's true, yet fontification errors are an important source of > difficult to debug errors. We could certainly extend the new backtrace > mechanism to handle these other types of bug, too. It makes very little sense to me to create infrastructure that caters only to your current and immediate problem. If we introduce such a feature, it should work with any Lisp called from redisplay. > > > As already noted, the *Backtrace* buffer doesn't appear on the screen, > > > yet. Any hints on how to achieve this would be most welcome. > > > Any reasons you'd want that? Once the buffer exists, why do you need > > to actually pop it up (and thus potentially disrupt the very > > window/frame configuration which you are trying to debug)? > > A debug-on-error backtrace gets displayed immediately, so it would help > consistency. If the window where the error occurred isn't occupying its > entire frame, there should be room to put the backtrace somewhere else, I > think. I'm not at all experienced with things like pop-to-buffer, but > they're supposed to be very flexible. I think showing a delayed-warning with the text that mentions the buffer with the backtrace is completely adequate. It stops short of popping the window with a backtrace itself, but that could be added later, if necessary, perhaps as a feature of delayed-warning. > > > It seems I could really do with after-redisplay-hook, in which I > > > could call pop-to-buffer, then cause redisplay to be restarted. > > > I think you misunderstand what such a hook could do, and why it could > > be useful, if at all, in the first place. If all you want is to cause > > the main loop perform some command after redisplay cycle ends, we > > already have several mechanisms in place for doing that. > > That's what I want, yes, but couldn't find any such mechanism anywhere > when I looked. One thing that comes to mind is a timer. Another thing is pushing something onto unread-command-events. I'm sure there are more. > Yes. How about what you suggested above, namely creating the backtrace > in save_eval_handler rather than signal_or_quit, at least as a second > attempt. Though I don't think this would handle errors in other Lisp > called from redisplay. 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. 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.