Re: Making Emacs Lisp easier to debug

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 11, 2023 at 15:47:51 +0200, Eli Zaretskii wrote:
> > Date: Sat, 11 Nov 2023 12:10:33 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > (I also don't understand why you think this will help with font-lock,
> > > nor even how it would work in general, should it be possible.

> > With font lock, or any other Lisp hook called from redisplay, it should
> > be possible, in a recursive-edit loop, to run edebug, displaying on a
> > different frame.  That different frame would be running in the inner
> > redisplay while the outer redisplay would be suspended.

> Why do you need an inner redisplay for that?

Because the outer redisplay would be the thing being debugged, and hence
not in a position to display the progress of edebug.

> And what will that frame show, given that the outer redisplay is
> halfway through fontifying the text? what do you expect to see there,
> and why?

I think the scope of a redisplay operation could change from everything
to a single frame.  So in normal operation a high level routine would
call redisplay2 for each of Emacs's frames in turn.

While stepping through a hook in edebug in the inner redisplay, the
outer redisplay would (I think) carry on looking like it did before the
outer redisplay started.  Or, possibly, it might look like a bare frame,
I'm not sure.

> > > Re-entering redisplay in the middle of a redisplay cycle means that
> > > the outer redisplay didn't finish preparing the glyph matrices, and
> > > what do you want the inner redisplay to do in such a case?

> > Work with the glyph matrices belonging to the inner redisplay whilst the
> > outer one is suspended.

> But that will immediately get you into the same problem, since the
> offending window will get redisplayed by the inner redisplay, and will
> again cause Edebug, etc., ad nauseam.

We could put a limit on the nesting depth of redisplay nesting that
edebug would cope with, a small integer (2 or 3, probably).  That is
very similar to what edebug currently does during a redisplay, i.e. it
bypasses edebug's processing entirely.

> > As I say, it is not clear whether or not this is possible or
> > practicable.  If it were, we could enhance edebug such that a function
> > in a font lock pattern, or on, say, window-scroll-functions could be
> > edebugged by doing nothing more than instrumenting it with C-u C-M-x.
> > Thus Lisp called from redisplay would cease to be an awkward special
> > case as far as debugging is concerned.

> I think we should start by having a clear idea of what should such an
> "inner redisplay" show and how, before we are talking about
> implementing it.

I agree.

> My impression from what you wrote is that the idea is way too vague to
> discuss the details, ....

Yes.  It's currently just a vague idea, and it's not even clear as yet
whether it's practicable.  But if it is, I think it would be worthwhile
implementing.

> .... and what you call "inner redisplay" is not what you want at all.

I don't understand why you say this.  Do you see any particular problems
with it (in addition to what you've already written), or perhaps have a
better scheme for running edebug on redisplay's several Lisp hooks?

-- 
Alan Mackenzie (Nuremberg, Germany).