From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Redisplay hook error backtraces Date: Wed, 13 Jul 2022 20:12:42 +0000 Message-ID: References: <83r1396lvr.fsf@gnu.org> <83edz87ivz.fsf@gnu.org> <83r1375m6x.fsf@gnu.org> <837d4hw5to.fsf@gnu.org> <83ilo0vnwh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35534"; 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 Wed Jul 13 22:14: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 1oBikO-00093a-M2 for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Jul 2022 22:14:12 +0200 Original-Received: from localhost ([::1]:53452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oBikK-0007XP-0R for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Jul 2022 16:14:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33450) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBij5-0006po-Pt for emacs-devel@gnu.org; Wed, 13 Jul 2022 16:12:51 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:33982 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oBij2-0004N7-Ox for emacs-devel@gnu.org; Wed, 13 Jul 2022 16:12:51 -0400 Original-Received: (qmail 6031 invoked by uid 3782); 13 Jul 2022 20:12:46 -0000 Original-Received: from acm.muc.de (p4fe15b73.dip0.t-ipconnect.de [79.225.91.115]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 13 Jul 2022 22:12:45 +0200 Original-Received: (qmail 10639 invoked by uid 1000); 13 Jul 2022 20:12:42 -0000 Content-Disposition: inline In-Reply-To: <83ilo0vnwh.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:292114 Archived-At: Hello, Eli. On Wed, Jul 13, 2022 at 22:00:14 +0300, Eli Zaretskii wrote: > > Date: Wed, 13 Jul 2022 18:41:01 +0000 > > Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > From: Alan Mackenzie > > The problem is that other signals go through the same C code in > > signal_and_quit, for example "smaller" condition-cases. We do not want > > to generate backtraces for these routine condition-cases which simply get > > handled by their Lisp code. redisplay_deep_handler records the "deepest" > > pending condition-case, and only if the variable `h' matches that deepest > > condition case do we have an error that we want to output a backtrace for. > I still don't think I understand why testing redisplaying_p and the > new optional variable would not be enough. We've got to distinguish between the signals we want to generate backtraces for and those we don't. redisplaying_p is not relevant to that, I think. For example, we don't want to generate a backtrace for a "failed" evaluation of the code generated by `c-safe'. > > > And what is the test of backtrace_yet about? > > When a backtrace is being generated, it first erases *Backtrace*. We > > only want to do that for the first backtrace generated by the current > > command. So backtrace_yet records whether we've already generated a BT > > in this command. It is reset to false in the command loop. > > This ensures that the user sees that first backtrace, which is > > likely to be the most interesting one. Unless she has configured > > backtrace-last-error to do something different. > > As an alternative to this complicated configuration, perhaps we could > > just erase *Backtrace* for the first BT, then write any further BTs to > > *Backtrace*, too. > Either that, or erase it every time. I think anything more complex is > over-engineered. OK, I'll get rid of the config variable, and just dump every backtrace to *Backtrace*. That will get rid of quite a few lines of code. > > > I still hope this could be done more elegantly and with fewer changes > > > to infrastructure. > > You mean, all the changes in eval.c and keyboard.c? I think the changes > > to internal_condition_case_n are essential to the patch, and I honestly > > don't think it can be done much more elegantly, but I'm open to > > suggestions. > Can we discuss how to implement it without introducing a special > handler and without adding new safe_run_hooks_* functions? OK. Perhaps with extra optional arguments, that kind of thing? -- Alan Mackenzie (Nuremberg, Germany).