Re: Making Emacs Lisp easier to debug

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 11, 2023 at 19:54:23 +0200, Eli Zaretskii wrote:
> > 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.

When I was starting to use edebug, a long time ago, I would frequently
ask myself why, after instrumenting some code and running it, it would
not bring up an edebug window.  I'm still asking myself that question,
but now I'm attempting to provide some answers.

It's also worth pointing out that a little over a year ago, when I was
writing backtrace-on-redisplay-error, you applied a fair bit of pressure
to me to handle _all_ redisplay's hooks, not just the font lock ones.
Now, by contrast, you're saying all but part of the font locking stuff is
tangents and inessential.

[ .... ]

> > > 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.

OK.

> > > > 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?

Must you be so aggressive, Eli?  What I want is to be able to instrument
a function for edebug, run it, and be able to step through it, all the
time, not just most of the time.  I think I said that in my opening post
in this thread.

> 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.

Nothing prevents people doing that.  Indeed they're forced to go through
such uncomfortable contrivances.  I don't think people enjoy having to do
so, though.  I certainly don't.  I'm trying to propose an improvement.

> > 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.

I mean the Lisp functions which are on fontification-functions.

> > 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"?

I don't think so, no.  The notion I'm playing with at the moment is that
inessential design elements in redisplay are preventing edebug working
smoothly, all the time.  Sure, there are ad-hoc workarounds for parts of
font locking, and some of the other redisplay hooks, but it would be
better to amend redisplay such that edebug simply worked.  That is what I
am trying to propose.

That said, it would indeed be worthwhile trying to fix
jit-lock-debug-mode.

[ .... ]

> > 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 ;-)

But it doesn't feel like you're trying to help me in the formulation of
such a design.

> > 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.

I think I've addressed this point several times.  The redisplay whose
hooks are being debugged in edebug will not be able to display that
edebug session, so we need another one.  Are you saying I'm missing
something, here?

> > > > > .... 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.

I don't feel that addresses my point.  What is this finer control you're
talking about, and how will it help me step through a redisplay hook with
edebug?

-- 
Alan Mackenzie (Nuremberg, Germany).