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: Making Emacs Lisp easier to debug Date: Fri, 10 Nov 2023 20:56:54 +0000 Message-ID: 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="25905"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 10 21:57:48 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 1r1YZY-0002dz-Od for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 21:57:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1YYo-0002Uj-91; Fri, 10 Nov 2023 15:57:03 -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 1r1YYm-0002UW-SO for emacs-devel@gnu.org; Fri, 10 Nov 2023 15:57:00 -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 1r1YYk-0005iv-Nj for emacs-devel@gnu.org; Fri, 10 Nov 2023 15:57:00 -0500 Original-Received: (qmail 29859 invoked by uid 3782); 10 Nov 2023 21:56:55 +0100 Original-Received: from acm.muc.de (p4fe158a9.dip0.t-ipconnect.de [79.225.88.169]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 10 Nov 2023 21:56:55 +0100 Original-Received: (qmail 25553 invoked by uid 1000); 10 Nov 2023 20:56:54 -0000 Content-Disposition: inline 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:313512 Hello, Emacs. Despite some recent improvements, and some which are currently being worked on, there are still scenarios where Lisp is difficult to debug. It is possible that we might be able to improve matters. The two scenarios I have in mind at the moment are: (i) Edebugging macro expansions. What happens at the moment is that the arguments given to the macro, when given a suitable edebug spec, get edebugged, but the code generated by the macro remains opaque. I envision an enhancement to Edebug such that the code generated by the macro would get instrumented, and the appropriate bit in the macro source would get displayed when stepping through the containing function. (ii) Edebugging font locking code. It would be nice to be able to debug font locking code which is being called from redisplay, as well as other hooks which are also called from redisplay. At the moment this isn't possible. To make it possible would require redisplay to become reentrant, so that a frame or window in the inner redisplay call could be where debugging of the outer redisplay call happens. I don't know how practicable it would be to enhance redisplay for this (it is certainly possible). Has anybody ever looked into this before? -- Alan Mackenzie (Nuremberg, Germany).