Re: Making Emacs Lisp easier to debug

[Eli Zaretskii]

> Date: Sat, 11 Nov 2023 19:55:29 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> 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.

That's not what I said.  I said that debugging the jit-lock mechanism
doesn't bump into the problem of being unable to Edebug font-lock
invoked by jit-lock.

IOW, I'm trying to keep this discussion focused on specific issues,
rather than let it degenerate into another futile dispute, by lumping
together unrelated issues and tangents.

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

It isn't aggression, it's frustration.  I have, as you might imagine,
very little time to waste on pointless discussions, so I get
frustrated when, after no less than 3 messages of me trying to help
you solve some problem you seem to be raising, it turns out you have
something very different in mind, which you didn't clearly state until
now.

Please try to describe the issue more clearly and comprehensively next
time, and save me and others from wasting efforts on looking up
solutions for problems you seem to raise, solutions you don't really
mean to use, because you are actually looking for something very
different.

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

You haven't, not in so many words.  You certainly didn't say that you
won't accept any solution except the one that allows you to "re-enter
redisplay".

In any case, my point is that "reentrant redisplay" is not the path
towards making Edebug capable of debugging Lisp called from C in
general and from redisplay in particular.

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

I don't see what is "contrived" in invoking a function you want to
debug.

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

And jit-lock-debug-mode doesn't use that code?  Which code
specifically?

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

So you decided, up front, that your goal is to make redisplay
reentrant, because you are of the opinion that its being non-reentrant
is due to "inessential design elements", and therefore you are going
to reject any other practical proposal for debugging font-lock or any
Lisp invoked from redisplay because they don't involve removing what
you perceive as "inessential design elements" from redisplay?

Do you see now why I feel frustration in this kind of discussion?  If
you were to explain the above intention and motivation from the
get-go, I would probably have decided not to respond to your message
at all.

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

Because you don't listen to what I'm saying.  You instead are trying
to prove that I'm wrong and don't know what I'm talking about.

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

Yes, you are missing that the Edebug session is shown in a separate
window, not in the same window whose display triggered the code being
debugged.

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

The finer control I allude to is the ability to display specific
windows.  That's not what redisplay currently does, see
redisplay_windows (which is called from a FOR_EACH_FRAME loop).