Re: Making Emacs Lisp easier to debug

[Eli Zaretskii]

> Date: Sat, 11 Nov 2023 17:23:53 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Because the outer redisplay would be the thing being debugged, and hence
> > > not in a position to display the progress of edebug.
> 
> > But you don't want to debug redisplay, you want to debug the font-lock
> > code called by redisplay.
> 
> Or the code called by any other hook in redisplay, including, perhaps,
> the jit-lock mechanism itself.

That's not important, so let's please not introduce tangents.  This
subject is complicated enough as it is.

> > > I think the scope of a redisplay operation could change from everything
> > > to a single frame.
> 
> > Not really, not with the current code design.
> 
> I see 14 FOR_EACH_FRAMEs in xdisp.c.  Are you saying that those loops
> could not be rearranged to do everything in one frame first, followed by
> doing everything in the next, and so on?

I was saying that the current design is not per-frame.  If you look
closer, you will see that between the FOR_EACH_FRAMEs there's
non-trivial code, so rearranging them might not be as easy and obvious
as it might sound at first sight.

> Surely each frame's redisplay is independent of all others'.

Look closer: it is not, at least not as it is now.  For example, did
you look at propagate_buffer_redisplay, which is called outside any
FOR_EACH_FRAME loop?

> > And you don't want a separate frame, you want a separate window.
> 
> Possibly.  A separate window feels like more complicated to implement,
> even if not by much.

No, it is not.  The Emacs redisplay actually works by windows.

> > > 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.
> 
> > So basically, the outer redisplay doesn't exist.  All you need is for
> > it to call the font-lock code.  Which once again brings me to the
> > question: why isn't jit-lock-debug-mode not what you want?
> 
> It's rather restricted: it won't help debug a window_scroll_functions
> function, for example.

So you want to debug window-scroll-functions, not font-lock?  Then why
did you start by talking about font-lock?

And if you are talking about debugging window-scroll-functions, what
prevents you from simply calling such a function interactively, and
debugging it then?  window-scroll-functions generally don't affect
redisplay (it is a very bad idea for them to try), so redisplay is not
involved here at all, it is only a tool for calling the hook.

> It won't help debug the jit-lock mechanism itself, should it be
> decided to amend it.

What do you mean by "jit-lock mechanism"?  Most of what I call
"jit-lock mechanism" is in C anyway.

> Also, as I mentioned, it's not working for me at the moment.  It
> gives the impression of being an unfinished piece of code.

Then how about fixing the problems there before talking about these
far-reaching ideas?  Surely, jit-lock-debug-mode is much closer to a
satisfactory solution than the ideas of "re-entering redisplay"?

> > > 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 will prevent infinite recursion, but it won't solve your problem,
> > because you do want the "inner" redisplay to finish, so it shows the
> > window where you are running the debugger.
> 
> You're pressing me to defend a design I haven't even formulated yet.  ;-)

No, I'm trying to convince you that you have no design to talk about ;-)

> I envisage the inner redisplay simply running, including to a finish,
> whilst the outer redisplay is suspended awaiting edebug to terminate.

Ask yourself why you need another redisplay to begin with.

> > > > .... and what you call "inner redisplay" is not what you want at all.
> 
> > > I don't understand why you say this.
> 
> > I'm saying that what you seem to want is an ability to display a
> > single window, the one where you run the debugger.  All the rest is of
> > no interest to you, and can, for example, be stopped in its tracks.
> > The solution to that is not a reentrant redisplay, it's something
> > else.
> 
> But what?  While the debugger is debugging a redisplay hook (say,
> window-scroll-functions) that invocation of redisplay is stationary.  The
> frame or window where we're running the debugger requires a running
> redisplay, however.  I can't see how we can achieve this without two
> instances of redisplay, one stationary waiting for its hook to finish
> being debugged, the other working for and displaying edebug's progress.
> What am I not seeing, here?

I'm saying that you want the ability to display just one window (well,
actually two: the window with the code being debugged and the
mini-window).  This has nothing to do with re-entering redisplay, it
has everything to do with a finer control on what redisplay does when
entered.