From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36312: 27.0.50; (message) in display spec condition causes emacs_abort() Date: Fri, 21 Jun 2019 10:34:26 +0300 Message-ID: <83fto3pf25.fsf@gnu.org> References: <83pnn8p1nk.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="186087"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36312@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 21 09:39:18 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1heE8j-000mJP-Kn for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Jun 2019 09:39:17 +0200 Original-Received: from localhost ([::1]:55336 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1heE8T-0008Es-E5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Jun 2019 03:39:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40567) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1heE5r-0005qs-Mh for bug-gnu-emacs@gnu.org; Fri, 21 Jun 2019 03:36:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1heE4c-0002I2-4q for bug-gnu-emacs@gnu.org; Fri, 21 Jun 2019 03:35:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36035) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1heE4c-0002Go-0a for bug-gnu-emacs@gnu.org; Fri, 21 Jun 2019 03:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1heE4b-00087T-Oz for bug-gnu-emacs@gnu.org; Fri, 21 Jun 2019 03:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jun 2019 07:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36312 X-GNU-PR-Package: emacs Original-Received: via spool by 36312-submit@debbugs.gnu.org id=B36312.156110248631186 (code B ref 36312); Fri, 21 Jun 2019 07:35:01 +0000 Original-Received: (at 36312) by debbugs.gnu.org; 21 Jun 2019 07:34:46 +0000 Original-Received: from localhost ([127.0.0.1]:49579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1heE4L-00086v-Vo for submit@debbugs.gnu.org; Fri, 21 Jun 2019 03:34:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1heE4J-00086h-Pu for 36312@debbugs.gnu.org; Fri, 21 Jun 2019 03:34:44 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1heE4E-0006ZR-KQ; Fri, 21 Jun 2019 03:34:38 -0400 Original-Received: from [176.228.60.248] (port=2755 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1heE4D-0004rV-IG; Fri, 21 Jun 2019 03:34:38 -0400 In-reply-to: (message from Pip Cet on Thu, 20 Jun 2019 19:32:43 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:160924 Archived-At: > From: Pip Cet > Date: Thu, 20 Jun 2019 19:32:43 +0000 > Cc: 36312@debbugs.gnu.org > > > You do realize that calling 'message' in a display-spec form causes us > > to re-enter redisplay in the middle of redisplay? I didn't even know > > we allowed that, but there's something new about our display code to > > learn every day. > > I did learn that today, and it's very puzzling. For starters, why do > we allow '(when ...), but not '(eval ...)? Because the idea was that the result of the evaluation should be used to affect the 'display' property in whose spec it is included, not to run some arbitrary unrelated code. With the intended use, 'when' is more useful than 'eval', because 'when' can do everything 'eval' can do, but not the other way around. > And is it really a good idea to call code from redisplay? That ship has sailed long ago, with Emacs 21.1. We have fontification-functions which are called from within redisplay, we have (height SOMETHING) in display specs, where SOMETHING can be a function or an arbitrary Lisp form which returns the height to be used to display text, we have 'eval' in the mode line format, etc. etc. Just search xdisp.c for safe_call and safe_eval, and you will see how many of them are there. It is true that running expensive Lisp from these hooks is a bad idea, because it will slow down redisplay. But Emacs gives you enough rope to hang yourself, and then trusts you not to do that. > The reason I'm looking at this is that I wanted to define an image > that changes color based on the face properties at point. It turns out > you can do that by abusing a (when ...) spec (which I use to call real > code in a (run-with-timer 0 nil ...), to avoid the issue of recursive > redisplays etc.). > > It's very ugly, and I'm not sure what the best way to handle things > would be; luckily, I'm not dependent on running on older or official > Emacs versions, so I'm free to experiment. Why not do something like that in a post-command-hook instead? The position of point is already up to date then, and retrieving face properties at point is trivial. What am I missing? There's also pre-redisplay-hook. > So far, what I'm thinking about is a hook that's run _after_ redisplay > to let an overlay know that redisplay just happened and the face used > for the text around the overlay changed. I don't understand why you think you must run after redisplay. If redisplay changes the faces (probably via JIT font-lock?), and you must have the corresponding change in your image without any delays (though if you use a timer, you seem to not mind a delay), then why not register a function with jit-lock-register, and do that from there? And if you indeed don't mind a short delay, then I think post-command-hook should be your friend. > But I'd appreciate any suggestions (the immediate application is to > define character-like image-based glyphs that "look like text", but > there might be others). You seem to be thinking about font-lock like use cases, so plugging yourself into jit-lock would be my first suggestion. In any case, (ab)using 'when' in display specs for running code that doesn't affect the value of that same display spec is to be avoided, IMO, as that is not what these features is for. Can we close this bug? Is the crash fixed in your real-life code as well? Thanks.