From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Making Emacs Lisp easier to debug Date: Sat, 11 Nov 2023 17:23:53 +0000 Message-ID: References: <838r74ye77.fsf@gnu.org> <83fs1cwnnv.fsf@gnu.org> <83edgwwge0.fsf@gnu.org> <831qcwwa7v.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16269"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 18:24:54 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 1r1rj1-00042R-K3 for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 18:24:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1riC-0006Z2-D7; Sat, 11 Nov 2023 12:24:00 -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 1r1riB-0006Yq-3o for emacs-devel@gnu.org; Sat, 11 Nov 2023 12:23:59 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1ri9-0002NL-7o for emacs-devel@gnu.org; Sat, 11 Nov 2023 12:23:58 -0500 Original-Received: (qmail 16650 invoked by uid 3782); 11 Nov 2023 18:23:53 +0100 Original-Received: from acm.muc.de (p4fe151aa.dip0.t-ipconnect.de [79.225.81.170]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 Nov 2023 18:23:53 +0100 Original-Received: (qmail 7569 invoked by uid 1000); 11 Nov 2023 17:23:53 -0000 Content-Disposition: inline In-Reply-To: <831qcwwa7v.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:312594 Archived-At: Hello, Eli. On Sat, Nov 11, 2023 at 18:01:08 +0200, Eli Zaretskii wrote: > > Date: Sat, 11 Nov 2023 14:56:17 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > > With font lock, or any other Lisp hook called from redisplay, it should > > > > be possible, in a recursive-edit loop, to run edebug, displaying on a > > > > different frame. That different frame would be running in the inner > > > > redisplay while the outer redisplay would be suspended. > > > Why do you need an inner redisplay for that? > > 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. > > > And what will that frame show, given that the outer redisplay is > > > halfway through fontifying the text? what do you expect to see there, > > > and why? > > 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? Surely each frame's redisplay is independent of all others'. > 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. > > 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. It won't help debug the jit-lock mechanism itself, should it be decided to amend it. Also, as I mentioned, it's not working for me at the moment. It gives the impression of being an unfinished piece of code. > > > > > Re-entering redisplay in the middle of a redisplay cycle means that > > > > > the outer redisplay didn't finish preparing the glyph matrices, and > > > > > what do you want the inner redisplay to do in such a case? > > > > Work with the glyph matrices belonging to the inner redisplay whilst the > > > > outer one is suspended. > > > But that will immediately get you into the same problem, since the > > > offending window will get redisplayed by the inner redisplay, and will > > > again cause Edebug, etc., ad nauseam. > > 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. ;-) I envisage the inner redisplay simply running, including to a finish, whilst the outer redisplay is suspended awaiting edebug to terminate. > > > .... 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? -- Alan Mackenzie (Nuremberg, Germany).