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 14:57:44 +0300 Message-ID: <83r1396lvr.fsf@gnu.org> References: <87edzchi3d.fsf@gnus.org> <83sfnsadow.fsf@gnu.org> <83o7yg9f0w.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20267"; 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 13:58:28 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 1o69rQ-00054x-Mn for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Jun 2022 13:58:28 +0200 Original-Received: from localhost ([::1]:36270 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o69rP-0002rk-B1 for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Jun 2022 07:58:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o69qg-0002AF-SY for emacs-devel@gnu.org; Tue, 28 Jun 2022 07:57:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57234) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o69qf-0001lJ-VS; Tue, 28 Jun 2022 07:57:41 -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=bEfNTfcgNpOInmD+0Rs/VMhVVkPxp3Nq+OADohXvl/k=; b=WckbuplExOLH OmHXH/I47Jnjr8MCvzq2OwbCGp2Svwwi3AO/RfHYnVi7ya2Dh/hFdCsUX9A4CDXMEP14ZB2cFi/Gx QMHf3GmOAUBU/WqKfgM8vqiYY9AYHenttQYCw7IZA//5flnslOeAERCuCWqvnRsZhsG4IWIdmKgYq iqe8ttsGdYqHTRhTChs19HxU3rKNwaFujSYIfexxQgTj0OezR+OsRvctO3FOSGSPgOEyX1WJsiDsz eUzIQQHHGS+8PV7CGwxIKQZHmSob3UdlGZYLLC6pNhKsE7i7PpZmKkMbLvavzx7OVce8ZF9U7IV2N RCEvTF6mSmEwZMrM1CE6ew==; Original-Received: from [87.69.77.57] (port=2438 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 1o69qf-0007OH-DM; Tue, 28 Jun 2022 07:57:41 -0400 In-Reply-To: (message from Alan Mackenzie on Mon, 27 Jun 2022 19:48:45 +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:291680 Archived-At: > Date: Mon, 27 Jun 2022 19:48:45 +0000 > Cc: larsi@gnus.org, emacs-devel@gnu.org > From: Alan Mackenzie > > > > > The only two ways of having that, AFAIK, are: > > > > > . 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? > What it does, on a fontification error during redisplay, is to write a > backtrace into the *Backtrace* buffer, attempts a pop-to-buffer (which > isn't working, not surprisingly), and aborts the redisplay. I don't understand why you needed to do it this way. First, what's wrong with the two ways I suggested? They are simple to implement, use existing infrastructure, don't require any changes in the APIs, and are safe. Why didn't you use one of them? Second, if you _must_ roll out something new (but please explain why), why do you need a special handler? why not slightly modify the existing handler, safe_eval_handler? Doing that would have avoided the need to change existing APIs. 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. Forth, why on Earth do you want to abort redisplay?? Once you collected the backtrace, there should be no need in such drastic measures. I've just finished adding a feature that _really_ needs to abort redisplay, and I can tell you: it's NOT safe! It can easily crash Emacs within a few commands, and your patch didn't do what I needed to do to avoid that. You just throw to top-level from the bowels of the display code, assuming that it's okay. Well, it isn't, not if handle_fontified_prop is called from redisplay_internal and its subroutines! So basically, I'm extremely confused, to say the least, by the proposed changes and by your rationale, and am not happy at all with installing them. > 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)? > 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. But all that is secondary. We should first agree on the correct design and implementation of the main part, which is how to handle these errors for collecting Lisp backtrace information.