From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Making Emacs Lisp easier to debug Date: Sat, 11 Nov 2023 19:54:23 +0200 Message-ID: <83v8a8uqeo.fsf@gnu.org> References: <838r74ye77.fsf@gnu.org> <83fs1cwnnv.fsf@gnu.org> <83edgwwge0.fsf@gnu.org> <831qcwwa7v.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39349"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 18:55:17 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r1sCS-000A3Q-Ik for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 18:55:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1sBr-00055o-Jh; Sat, 11 Nov 2023 12:54:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1sBp-00055P-3d for emacs-devel@gnu.org; Sat, 11 Nov 2023 12:54:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1sBo-0006LH-7V; Sat, 11 Nov 2023 12:54:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=my95F3bFdxwE2kDISSEDHvaB1Vye9t65f6yt/6vdDds=; b=hLxvRMuqr1wT iv9LtCM7QCnyPOiVWhoXHuWqWuQXioHQiJxt1eH6rSeLSZAKDrYIifO6Ul3gYbIOG8B0APJC6aBtR rJmS6gItAO/bNQgrmxgqwtIDMbMVbBbeCGVnsZR5HF4/StTNDIIGvTAPBLbjAmjoxFPPrJ0dLCxz2 XV9GMF0jRKLQ5PWIcx+OplG45AYvL6z8yNh4SEOZfzK4XFEPnkBGCXPLS4n7hQnctfuh3upporjf0 jg77hC/F3BicikdpOf68B89nuvcWHN8Qgk7zsQADjjAJJm0cuNrNx+Cidek5VffAUzaEk3udSN0KZ YLKibHaO2el6mY8lN5H/AA==; In-Reply-To: (message from Alan Mackenzie on Sat, 11 Nov 2023 17:23:53 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312595 Archived-At: > Date: Sat, 11 Nov 2023 17:23:53 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > > 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.