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 19:55:29 +0000 Message-ID: References: <838r74ye77.fsf@gnu.org> <83fs1cwnnv.fsf@gnu.org> <83edgwwge0.fsf@gnu.org> <831qcwwa7v.fsf@gnu.org> <83v8a8uqeo.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="9073"; 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 20:56:49 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 1r1u65-00028F-7F for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 20:56:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1u52-0001WC-DM; Sat, 11 Nov 2023 14:55:44 -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 1r1u50-0001W1-P3 for emacs-devel@gnu.org; Sat, 11 Nov 2023 14:55:42 -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 1r1u4y-0002sE-FU for emacs-devel@gnu.org; Sat, 11 Nov 2023 14:55:42 -0500 Original-Received: (qmail 85851 invoked by uid 3782); 11 Nov 2023 20:55:29 +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 20:55:29 +0100 Original-Received: (qmail 8132 invoked by uid 1000); 11 Nov 2023 19:55:29 -0000 Content-Disposition: inline In-Reply-To: <83v8a8uqeo.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=ham 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:312605 Archived-At: 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 > > > > 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).