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: Sun, 12 Nov 2023 09:17:14 +0200 Message-ID: <83il67v3t1.fsf@gnu.org> References: <838r74ye77.fsf@gnu.org> <83fs1cwnnv.fsf@gnu.org> <83edgwwge0.fsf@gnu.org> <831qcwwa7v.fsf@gnu.org> <83v8a8uqeo.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13514"; 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 Sun Nov 12 08:17:55 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 1r24jD-0003H9-1s for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Nov 2023 08:17:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r24iu-0004By-O5; Sun, 12 Nov 2023 02:17:36 -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 1r24is-0004Az-IO for emacs-devel@gnu.org; Sun, 12 Nov 2023 02:17:34 -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 1r24is-0004JG-53; Sun, 12 Nov 2023 02:17:34 -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=Q8WiiVOa/KSNlrD/rMiiOqYGY/uK0VEaHF/Ncyo9TZ8=; b=HiyHilHJupbz Pb1tM8arjHg76Q2O7f5EXocntrLM21wwa4QDXnU9QDBQsEX0j/m4z75CnGL0jhmMvcv4jFnnXlo/k I9GHg0WQzndIiVEDP7TJgF60X74qGLY1aONdNBXyL2JClN/9T1v4Bhg192qIW8XiIYMuK0NxehA7B r4YoOiN3GTwdKYdiC4OQOelmCe6BULthVGJ3bpjVqG1N88bCUtZBsaZLvkFOJe3FDEuMmI6Xmjfl9 C0NtINkyiKHokaewehMcA5fV/ERLeGpiInpSsNPFsTCvE4PCJ8zISmxRkutpcg6Z/VISEO2T/rIpH OsvCvnVOn4rEOF35ASoYqw==; In-Reply-To: (message from Alan Mackenzie on Sat, 11 Nov 2023 19:55:29 +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:312642 Archived-At: > Date: Sat, 11 Nov 2023 19:55:29 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > 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).