Re: Fontification error backtrace [Was: Why is it so difficult to get a Lisp backtrace?]

[Eli Zaretskii]

> Date: Mon, 27 Jun 2022 19:48:45 +0000
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > > 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.