From: Eli Zaretskii <eliz@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Making Emacs Lisp easier to debug
Date: Sat, 11 Nov 2023 19:54:23 +0200 [thread overview]
Message-ID: <83v8a8uqeo.fsf@gnu.org> (raw)
In-Reply-To: <ZU-4qfdbVJycmMeY@ACM> (message from Alan Mackenzie on Sat, 11 Nov 2023 17:23:53 +0000)
> 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.
next prev parent reply other threads:[~2023-11-11 17:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 20:56 Making Emacs Lisp easier to debug Alan Mackenzie
2023-11-11 6:52 ` Eli Zaretskii
2023-11-11 9:01 ` Ihor Radchenko
2023-11-11 11:04 ` Alan Mackenzie
2023-11-11 11:10 ` Eli Zaretskii
2023-11-11 12:10 ` Alan Mackenzie
2023-11-11 13:47 ` Eli Zaretskii
2023-11-11 14:56 ` Alan Mackenzie
2023-11-11 16:01 ` Eli Zaretskii
2023-11-11 17:23 ` Alan Mackenzie
2023-11-11 17:54 ` Eli Zaretskii [this message]
2023-11-11 19:55 ` Alan Mackenzie
2023-11-12 7:17 ` Eli Zaretskii
2023-11-12 12:08 ` Alan Mackenzie
2023-11-12 12:28 ` Eli Zaretskii
2023-11-13 18:20 ` XY Problems (tangent, related to common discussion issue here) chad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83v8a8uqeo.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.