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 15:47:51 +0200 Message-ID: <83edgwwge0.fsf@gnu.org> References: <838r74ye77.fsf@gnu.org> <83fs1cwnnv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37336"; 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 14:49:09 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 1r1oMG-0009To-HN for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 14:49:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1oLX-0006AD-7v; Sat, 11 Nov 2023 08:48:24 -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 1r1oLA-00065s-FE for emacs-devel@gnu.org; Sat, 11 Nov 2023 08:48:01 -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 1r1oL9-00080w-1O; Sat, 11 Nov 2023 08:47:59 -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=mRtQhxeG8GLQHvHZbps2uUjczV3MJ86f14AGRUKBUvM=; b=MlVYfFup/XsZ fGPH0PH0Um1AbFD1a2IAbTJqFE4MI91crF9TK1UYxD7+7wkDzmpZ81KsHaMgdcYngaglCGR1fKERY JqQ/eWWKhdfdNxN5HQ4r1H89diHNo6eWUA8krVSsVa+QlG4AcFqt97FMKoQ+gcNouPoyP+4CRZqtj NiqRFcnlCd+eva2qz8/tTHCYYWwF/44qQvqPHKOiBF3y7Lo3wxG7lN5WZcH//TsPH+pDKan2yVvsT 27PWtrjs3EPSyb6VHd45GQ1xNhij603qITlTN95rxpL9gyXr8WXgW9rTrgLYr6rTF+JYV5LyomNTe f1+G5aPdOqaNyJwJoSYmbA==; In-Reply-To: (message from Alan Mackenzie on Sat, 11 Nov 2023 12:10:33 +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:312565 Archived-At: > Date: Sat, 11 Nov 2023 12:10:33 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > (I also don't understand why you think this will help with font-lock, > > nor even how it would work in general, should it be possible. > > 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? 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? > > 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. > As I say, it is not clear whether or not this is possible or > practicable. If it were, we could enhance edebug such that a function > in a font lock pattern, or on, say, window-scroll-functions could be > edebugged by doing nothing more than instrumenting it with C-u C-M-x. > Thus Lisp called from redisplay would cease to be an awkward special > case as far as debugging is concerned. I think we should start by having a clear idea of what should such an "inner redisplay" show and how, before we are talking about implementing it. My impression from what you wrote is that the idea is way too vague to discuss the details, and what you call "inner redisplay" is not what you want at all.