From unknown Mon Aug 18 11:26:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36312: 27.0.50; (message) in display spec condition causes emacs_abort() Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jun 2019 16:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 36312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 36312@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.156104749615147 (code B ref -1); Thu, 20 Jun 2019 16:19:02 +0000 Received: (at submit) by debbugs.gnu.org; 20 Jun 2019 16:18:16 +0000 Received: from localhost ([127.0.0.1]:49181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdzlQ-0003wF-9p for submit@debbugs.gnu.org; Thu, 20 Jun 2019 12:18:16 -0400 Received: from lists.gnu.org ([209.51.188.17]:38843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdzlP-0003w8-8S for submit@debbugs.gnu.org; Thu, 20 Jun 2019 12:18:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36754) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdzlL-0002bx-RO for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2019 12:18:15 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hdzaZ-0002Aj-HK for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2019 12:07:04 -0400 Received: from mail-ot1-x344.google.com ([2607:f8b0:4864:20::344]:38837) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hdzaZ-00028B-C6 for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2019 12:07:03 -0400 Received: by mail-ot1-x344.google.com with SMTP id d17so3262272oth.5 for ; Thu, 20 Jun 2019 09:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RKB6iwsNQTaiwoLQcxEqr5QgA5TBoEmGsxQ2r6xOSjA=; b=OfFVDzB9kJj2BBOyUBNHxfCbX25QleSh2/cl+MUX0GdGCNbrZT2hERU53o54DgKKSe RSTwFLTmi0kXYsGpaYQmXRf4alXhRYBqEsa7KSP/DttogKNkrpzXj3QEpysApR60SC54 bXWEIx+kwd37fXi3jGC/T9DgfOOeNqy7VpN9d3/NO/eEqiMqiJ/RrCkCkt/4NK+Yo3Yv 9wI1rBankOtoB0NIqjgo0EEHPyLkRO6O+BYleC4pCOXwavnXjfppjAS3Wvpf0+DhEAF+ xTSwJz3aC7iuqdp+DWxQjwnSJo1oLDe5xLi4w5+9INQvDuTE/ySQJg7qLkvEm40W/c/g BvrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RKB6iwsNQTaiwoLQcxEqr5QgA5TBoEmGsxQ2r6xOSjA=; b=iGBRnMEv6WJQfakvliXRcsLhCK1XSUeHWDDoW2rAzCJyMn7jqTrgdfel5RNR9nCNC7 QNVmsApRnyRNP0gx5K9WOESG7rUAijaDAvAyK/+ag86v0o94EK3D/i95Jb1PL2zsp+Pj TakJRebn60Md8szgIQocD7jXDGSX6O+A0pxmvn38bSaTwPe/TsLM/s3X+Km6D8v9agxi u7DPu3Y2hEOjxxXvp0ondlZzJgd2iKxjlfAHCnkvJOChoqrDd7VUxcq80OKuUDJCYVVG k/2WcZm3rLKp+0GPo1oz+siJuAdh/EZ7z95EkDM3lsFYznc2M7TbSFgQa+Zoyb6Mt1x+ ptZw== X-Gm-Message-State: APjAAAXPWtixlQej+wmom8U35OOqtgBvvVbVSo37m87RcDdUi1UKv8m8 rWTHNBVRPR/uUam9eaBINgHLlJLOtGXnbBqMFD9urrKUziw= X-Google-Smtp-Source: APXvYqyqVcp1W7a0GejOVYac0i3RWupaqgg6XEkz7oKS8GSn/3wsuOFc+vMubSvSGhiOwO5U0y+WUr6sct15gojOaio= X-Received: by 2002:a9d:3c5:: with SMTP id f63mr27340223otf.210.1561046822147; Thu, 20 Jun 2019 09:07:02 -0700 (PDT) MIME-Version: 1.0 From: Pip Cet Date: Thu, 20 Jun 2019 16:06:25 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::344 X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) In emacs -Q, evaluate (let ((o (make-overlay (point) (point)))) (overlay-put o 'after-string (propertize " " 'display '(when (message "a") . "b")))) This causes a SIGABRT in the bidi stack code. Backtrace: #0 0x00007ffff4b4d5cb in raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x000055555559573b in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:406 #2 0x0000555555595b37 in emacs_abort () at sysdep.c:2453 #3 0x00005555555942e3 in bidi_pop_it (bidi_it=bidi_it@entry=0x7fffffff99b0) at bidi.c:947 #4 0x00005555555b2174 in pop_it (it=0x7fffffff8fc0) at xdisp.c:6356 #5 0x00005555555c3594 in next_overlay_string (it=it@entry=0x7fffffff8fc0) at xdisp.c:5754 #6 0x00005555555c8edc in set_iterator_to_next (it=0x7fffffff8fc0, reseat_p=) at xdisp.c:7871 #7 0x00005555555cf9ba in display_line (it=0x7fffffff8fc0, cursor_vpos=) at xdisp.c:22296 #8 0x00005555555d491b in try_window (window=window@entry=0x555555f99fa5, pos=..., flags=flags@entry=1) at xdisp.c:17863 #9 0x00005555555e80df in redisplay_window (window=0x555555f99fa5, just_this_one_p=) at xdisp.c:17311 #10 0x00005555555eae1e in redisplay_window_1 (window=window@entry=0x555555f99fa5) at xdisp.c:15044 #11 0x00005555556eb3ca in internal_condition_case_1 (bfun=bfun@entry=0x5555555eadf0 , arg=0x555555f99fa5, handlers=, hfun=hfun@entry=0x5555555afd00 ) at eval.c:1376 #12 0x00005555555d834f in redisplay_internal () at xdisp.c:14614 #13 0x000055555567b5d7 in read_char (commandflag=1, map=0x555556856f83, prev_event=0x0, used_mouse_menu=0x7fffffffe4db, end_time=0x0) at keyboard.c:2474 #14 0x000055555567df1e in read_key_sequence (keybuf=0x7fffffffe5e0, prompt=0x0, dont_downcase_last=, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=) at keyboard.c:9111 #15 0x000055555567f6fc in command_loop_1 () at lisp.h:1045 #16 0x00005555556eb332 in internal_condition_case (bfun=bfun@entry=0x55555567f520 , handlers=handlers@entry=0x55b0, hfun=hfun@entry=0x555555676d20 ) at eval.c:1352 #17 0x0000555555671d14 in command_loop_2 (ignore=ignore@entry=0x0) at lisp.h:1045 #18 0x00005555556eb2b1 in internal_catch (tag=tag@entry=0xcc30, func=func@entry=0x555555671cf0 , arg=arg@entry=0x0) at eval.c:1113 #19 0x0000555555671cbb in command_loop () at lisp.h:1045 #20 0x0000555555676926 in recursive_edit_1 () at keyboard.c:714 #21 0x0000555555676c45 in Frecursive_edit () at keyboard.c:786 #22 0x000055555559b227 in main (argc=2, argv=0x7fffffffe978) at emacs.c:1962 It's reproducible here, so I can provide more debugging information if required. I'm aware that doing complicated stuff in a display spec condition is a bad idea, but I think debug messages are such an important special case that we ought, at least, not to abort completely for those. Setting redisplay--bidi-inhibit to t works around the problem. From unknown Mon Aug 18 11:26:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36312: 27.0.50; (message) in display spec condition causes emacs_abort() Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jun 2019 18:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36312@debbugs.gnu.org Received: via spool by 36312-submit@debbugs.gnu.org id=B36312.15610543365750 (code B ref 36312); Thu, 20 Jun 2019 18:13:01 +0000 Received: (at 36312) by debbugs.gnu.org; 20 Jun 2019 18:12:16 +0000 Received: from localhost ([127.0.0.1]:49247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1he1Xk-0001Uf-56 for submit@debbugs.gnu.org; Thu, 20 Jun 2019 14:12:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1he1Xi-0001UU-LY for 36312@debbugs.gnu.org; Thu, 20 Jun 2019 14:12:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37133) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1he1Xd-00016W-J9; Thu, 20 Jun 2019 14:12:09 -0400 Received: from [176.228.60.248] (port=1442 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1he1Xa-0008La-5L; Thu, 20 Jun 2019 14:12:09 -0400 Date: Thu, 20 Jun 2019 21:11:43 +0300 Message-Id: <83pnn8p1nk.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Thu, 20 Jun 2019 16:06:25 +0000) References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pip Cet > Date: Thu, 20 Jun 2019 16:06:25 +0000 > > In emacs -Q, evaluate > > (let ((o (make-overlay (point) (point)))) > (overlay-put o 'after-string (propertize " " 'display > '(when (message "a") > . "b")))) > > This causes a SIGABRT in the bidi stack code. Thanks. 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. Should be fixed now. P.S. Is there a chance fontification-functions will also call 'message'? Because I think we have the same problem there. From unknown Mon Aug 18 11:26:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36312: 27.0.50; (message) in display spec condition causes emacs_abort() Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jun 2019 19:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36312@debbugs.gnu.org Received: via spool by 36312-submit@debbugs.gnu.org id=B36312.156105920722123 (code B ref 36312); Thu, 20 Jun 2019 19:34:01 +0000 Received: (at 36312) by debbugs.gnu.org; 20 Jun 2019 19:33:27 +0000 Received: from localhost ([127.0.0.1]:49320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1he2oJ-0005kl-JU for submit@debbugs.gnu.org; Thu, 20 Jun 2019 15:33:27 -0400 Received: from mail-ot1-f44.google.com ([209.85.210.44]:40840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1he2oH-0005kV-KP for 36312@debbugs.gnu.org; Thu, 20 Jun 2019 15:33:26 -0400 Received: by mail-ot1-f44.google.com with SMTP id e8so3883749otl.7 for <36312@debbugs.gnu.org>; Thu, 20 Jun 2019 12:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N9ifV3me4np3cXm3YkqVzBoo7cRattYOQyQMo3W1jtY=; b=qTJncQcPZPMfBYvGATkZxGQIrLBYdi5SPWJ80bxiqI8D0hPZL5mArlsOo6zmfctlO4 +ytE/btw7EIfto3lWHOnqoDZx6n4aYCrVk59te/EpWFWHFYAHyDmegKslSaTP2j6RDgx 0nGDw2TjnL/aJsAFuBm6nhl/P+/8r5R3CB+XaNDSOVj3yV/cJfHnmkxlvCFIsexMbRH3 alUg7BH6TbhwF/DBocnPmcdGvNsGjDJXosqa8tFeW9TDxwU6pV6LT2SQnQeTaUfyg3F/ 8MOXI69wUt9neG8L+31P0eQDv50RioQLcPL1rOeyIYRd8rID8QCHdyX/SN7pYjdvl5S6 j84Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N9ifV3me4np3cXm3YkqVzBoo7cRattYOQyQMo3W1jtY=; b=J3fUnTcz74NSBcD+QGkl9DV8cdR3x2bCzpHmX/EOPz7sKifCyc1Oo50tm6ZQJOnaVf cWjzNRM0D/chCm49ClH645DKvj+2zF/wmtFNposlq4AARip0vXFh6bQcyij71G0XJ/VW YO3fH3YYxwJdKNIClY8xiwwnPfYVYKpfSUcevzfWomY9qhEGL9w14Ycd0pUXvAeswI8y kishdRcPiK0Rk8qtYNGx96kjqy8vxv7BAzOnpqwNLmZhBmQc2XlBXlbbtYfd+DfDqk9q U+3E0EUGb5Zh+V3XayQ9q5wo9sUzCOeO5RKPXpny1nvIJLcRX7Fhr2jALrUM8pGQbphW RQkQ== X-Gm-Message-State: APjAAAVxKUsqV6Hq22/3SsyRQA3jrtHmu0ZoThPkMZSf09ZngSncINrA aXxNPVgigswP+zL1q9zx1z1hxqis487BSCUVBpQ= X-Google-Smtp-Source: APXvYqzWtHD2jvkL3UtM0Ujf/ZCi5PmDd5abHkqP/7/KqNBjaC+k1h1y7MWudn71wZCxGMFE9Kdji0NYJjkMtn7u9IU= X-Received: by 2002:a9d:7284:: with SMTP id t4mr13500529otj.154.1561059199021; Thu, 20 Jun 2019 12:33:19 -0700 (PDT) MIME-Version: 1.0 References: <83pnn8p1nk.fsf@gnu.org> In-Reply-To: <83pnn8p1nk.fsf@gnu.org> From: Pip Cet Date: Thu, 20 Jun 2019 19:32:43 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Jun 20, 2019 at 6:12 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Thu, 20 Jun 2019 16:06:25 +0000 > > > > In emacs -Q, evaluate > > > > (let ((o (make-overlay (point) (point)))) > > (overlay-put o 'after-string (propertize " " 'display > > '(when (message "a") > > . "b")))) > > > > This causes a SIGABRT in the bidi stack code. > > Thanks. > > 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 ...)? And is it really a good idea to call code from redisplay? 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. 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. It's soon enough to change things and trigger another redisplay then, as far as I'm concerned. (There's some flickering, but for my application that's okay). 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). From unknown Mon Aug 18 11:26:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36312: 27.0.50; (message) in display spec condition causes emacs_abort() 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 X-GNU-PR-Keywords: To: Pip Cet Cc: 36312@debbugs.gnu.org Received: via spool by 36312-submit@debbugs.gnu.org id=B36312.156110248631186 (code B ref 36312); Fri, 21 Jun 2019 07:35:01 +0000 Received: (at 36312) by debbugs.gnu.org; 21 Jun 2019 07:34:46 +0000 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 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 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 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 Date: Fri, 21 Jun 2019 10:34:26 +0300 Message-Id: <83fto3pf25.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Thu, 20 Jun 2019 19:32:43 +0000) References: <83pnn8p1nk.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From unknown Mon Aug 18 11:26:44 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Pip Cet Subject: bug#36312: closed (Re: bug#36312: 27.0.50; (message) in display spec condition causes emacs_abort()) Message-ID: References: X-Gnu-PR-Message: they-closed 36312 X-Gnu-PR-Package: emacs Reply-To: 36312@debbugs.gnu.org Date: Fri, 21 Jun 2019 08:15:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1561104902-2279-1" This is a multi-part message in MIME format... ------------=_1561104902-2279-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #36312: 27.0.50; (message) in display spec condition causes emacs_abort() which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 36312@debbugs.gnu.org. --=20 36312: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D36312 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1561104902-2279-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 36312-done) by debbugs.gnu.org; 21 Jun 2019 08:14:25 +0000 Received: from localhost ([127.0.0.1]:49599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1heEgj-0000Zr-Hg for submit@debbugs.gnu.org; Fri, 21 Jun 2019 04:14:25 -0400 Received: from mail-oi1-f169.google.com ([209.85.167.169]:43922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1heEgh-0000Zd-RV for 36312-done@debbugs.gnu.org; Fri, 21 Jun 2019 04:14:24 -0400 Received: by mail-oi1-f169.google.com with SMTP id w79so4069471oif.10 for <36312-done@debbugs.gnu.org>; Fri, 21 Jun 2019 01:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=loOe7oKlOpCkrSgqWduu0oQULm3vB5nDwUW2AlC6MnE=; b=E5JaatuJZf9B2jETw9+2aYsIHTrrs/VCd91bCgLxCYium0baeJzYH6hSTIipZiS7qd xe4VUb7EsnFgT7OYk8Qs8ThhLYcFN0lbH0qG0FiTGpLzJHR7rWWx2YkLQgJFndB+8qS+ i2H8qHExkrbNyg2wjNmmJ4LLNnkFHnB6ZdKHk1L7JCG9nePjh+NxVO5ZZUBbwotN0LSO GRJ/wlSai7Si33yT4OxZN+Io1KyUc8959ulohEfBl4/icAYTT73h8MBjrSfATKT9OHfV lhe5c+9Qz3Zg6FmJrD9U9CiGxYe2C7erlObDEh1ezALoW3UPSy5YkyFKwg+3V+jlw3Ln xWJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=loOe7oKlOpCkrSgqWduu0oQULm3vB5nDwUW2AlC6MnE=; b=Yqv/cNNsMOBjsl5YNfEHXrmp4TLuEgInyKx68kjkZ+6OhALw77cyeeVyBluRG9zLtP ysKbdHIPk03NSX1DJZBK/h8ZZxL1ANCvNxyXFyCcsoRqAtjRJppT57s787O7waGilkbE HOgm0NsBfZzOLEIEN2GszWqNPhcrmLXub8sR+HWGePI8Spw5rtfzhj6k2jfE6jcOsh8v +jVZvX5IcOUDDXhXDGIGKhUQLXjU/D0BjJDAcr9Wt5DAsdZdP6lcnqTR6S9oHDscgdMY 2MZ8gPXwiBbg0esBPOhkJeWgP8v8CxDgNTpwiuhtqpoX5SHwm8H+FHLy1nG3+4Dg+/Pl G+2g== X-Gm-Message-State: APjAAAVtHGdZJ98J5/EYXV8SnahOC7EbmJvJBCKh4Wakn7SB6XU5gxcf gPb7eNs/ldm2S9Djn5eVz7Dtux1OiCzrfSQy2cE= X-Google-Smtp-Source: APXvYqynbfjPOBCB8uG0M7Ptg7JN+eZ6TkY5+soi02iFQHH3sbsvFDs2h7O+gCmfozpDh2H59Jh61OkJkV5eXgC2/a8= X-Received: by 2002:aca:4790:: with SMTP id u138mr2074227oia.44.1561104858168; Fri, 21 Jun 2019 01:14:18 -0700 (PDT) MIME-Version: 1.0 References: <83pnn8p1nk.fsf@gnu.org> <83fto3pf25.fsf@gnu.org> In-Reply-To: <83fto3pf25.fsf@gnu.org> From: Pip Cet Date: Fri, 21 Jun 2019 08:13:42 +0000 Message-ID: Subject: Re: bug#36312: 27.0.50; (message) in display spec condition causes emacs_abort() To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36312-done Cc: 36312-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jun 21, 2019 at 7:34 AM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Thu, 20 Jun 2019 19:32:43 +0000 > > Cc: 36312@debbugs.gnu.org > > > Can we close this bug? Is the crash fixed in your real-life code as > well? Thank you very much, it is! ------------=_1561104902-2279-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 20 Jun 2019 16:18:16 +0000 Received: from localhost ([127.0.0.1]:49181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdzlQ-0003wF-9p for submit@debbugs.gnu.org; Thu, 20 Jun 2019 12:18:16 -0400 Received: from lists.gnu.org ([209.51.188.17]:38843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdzlP-0003w8-8S for submit@debbugs.gnu.org; Thu, 20 Jun 2019 12:18:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36754) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdzlL-0002bx-RO for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2019 12:18:15 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hdzaZ-0002Aj-HK for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2019 12:07:04 -0400 Received: from mail-ot1-x344.google.com ([2607:f8b0:4864:20::344]:38837) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hdzaZ-00028B-C6 for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2019 12:07:03 -0400 Received: by mail-ot1-x344.google.com with SMTP id d17so3262272oth.5 for ; Thu, 20 Jun 2019 09:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RKB6iwsNQTaiwoLQcxEqr5QgA5TBoEmGsxQ2r6xOSjA=; b=OfFVDzB9kJj2BBOyUBNHxfCbX25QleSh2/cl+MUX0GdGCNbrZT2hERU53o54DgKKSe RSTwFLTmi0kXYsGpaYQmXRf4alXhRYBqEsa7KSP/DttogKNkrpzXj3QEpysApR60SC54 bXWEIx+kwd37fXi3jGC/T9DgfOOeNqy7VpN9d3/NO/eEqiMqiJ/RrCkCkt/4NK+Yo3Yv 9wI1rBankOtoB0NIqjgo0EEHPyLkRO6O+BYleC4pCOXwavnXjfppjAS3Wvpf0+DhEAF+ xTSwJz3aC7iuqdp+DWxQjwnSJo1oLDe5xLi4w5+9INQvDuTE/ySQJg7qLkvEm40W/c/g BvrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RKB6iwsNQTaiwoLQcxEqr5QgA5TBoEmGsxQ2r6xOSjA=; b=iGBRnMEv6WJQfakvliXRcsLhCK1XSUeHWDDoW2rAzCJyMn7jqTrgdfel5RNR9nCNC7 QNVmsApRnyRNP0gx5K9WOESG7rUAijaDAvAyK/+ag86v0o94EK3D/i95Jb1PL2zsp+Pj TakJRebn60Md8szgIQocD7jXDGSX6O+A0pxmvn38bSaTwPe/TsLM/s3X+Km6D8v9agxi u7DPu3Y2hEOjxxXvp0ondlZzJgd2iKxjlfAHCnkvJOChoqrDd7VUxcq80OKuUDJCYVVG k/2WcZm3rLKp+0GPo1oz+siJuAdh/EZ7z95EkDM3lsFYznc2M7TbSFgQa+Zoyb6Mt1x+ ptZw== X-Gm-Message-State: APjAAAXPWtixlQej+wmom8U35OOqtgBvvVbVSo37m87RcDdUi1UKv8m8 rWTHNBVRPR/uUam9eaBINgHLlJLOtGXnbBqMFD9urrKUziw= X-Google-Smtp-Source: APXvYqyqVcp1W7a0GejOVYac0i3RWupaqgg6XEkz7oKS8GSn/3wsuOFc+vMubSvSGhiOwO5U0y+WUr6sct15gojOaio= X-Received: by 2002:a9d:3c5:: with SMTP id f63mr27340223otf.210.1561046822147; Thu, 20 Jun 2019 09:07:02 -0700 (PDT) MIME-Version: 1.0 From: Pip Cet Date: Thu, 20 Jun 2019 16:06:25 +0000 Message-ID: Subject: 27.0.50; (message) in display spec condition causes emacs_abort() To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::344 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) In emacs -Q, evaluate (let ((o (make-overlay (point) (point)))) (overlay-put o 'after-string (propertize " " 'display '(when (message "a") . "b")))) This causes a SIGABRT in the bidi stack code. Backtrace: #0 0x00007ffff4b4d5cb in raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x000055555559573b in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:406 #2 0x0000555555595b37 in emacs_abort () at sysdep.c:2453 #3 0x00005555555942e3 in bidi_pop_it (bidi_it=bidi_it@entry=0x7fffffff99b0) at bidi.c:947 #4 0x00005555555b2174 in pop_it (it=0x7fffffff8fc0) at xdisp.c:6356 #5 0x00005555555c3594 in next_overlay_string (it=it@entry=0x7fffffff8fc0) at xdisp.c:5754 #6 0x00005555555c8edc in set_iterator_to_next (it=0x7fffffff8fc0, reseat_p=) at xdisp.c:7871 #7 0x00005555555cf9ba in display_line (it=0x7fffffff8fc0, cursor_vpos=) at xdisp.c:22296 #8 0x00005555555d491b in try_window (window=window@entry=0x555555f99fa5, pos=..., flags=flags@entry=1) at xdisp.c:17863 #9 0x00005555555e80df in redisplay_window (window=0x555555f99fa5, just_this_one_p=) at xdisp.c:17311 #10 0x00005555555eae1e in redisplay_window_1 (window=window@entry=0x555555f99fa5) at xdisp.c:15044 #11 0x00005555556eb3ca in internal_condition_case_1 (bfun=bfun@entry=0x5555555eadf0 , arg=0x555555f99fa5, handlers=, hfun=hfun@entry=0x5555555afd00 ) at eval.c:1376 #12 0x00005555555d834f in redisplay_internal () at xdisp.c:14614 #13 0x000055555567b5d7 in read_char (commandflag=1, map=0x555556856f83, prev_event=0x0, used_mouse_menu=0x7fffffffe4db, end_time=0x0) at keyboard.c:2474 #14 0x000055555567df1e in read_key_sequence (keybuf=0x7fffffffe5e0, prompt=0x0, dont_downcase_last=, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=) at keyboard.c:9111 #15 0x000055555567f6fc in command_loop_1 () at lisp.h:1045 #16 0x00005555556eb332 in internal_condition_case (bfun=bfun@entry=0x55555567f520 , handlers=handlers@entry=0x55b0, hfun=hfun@entry=0x555555676d20 ) at eval.c:1352 #17 0x0000555555671d14 in command_loop_2 (ignore=ignore@entry=0x0) at lisp.h:1045 #18 0x00005555556eb2b1 in internal_catch (tag=tag@entry=0xcc30, func=func@entry=0x555555671cf0 , arg=arg@entry=0x0) at eval.c:1113 #19 0x0000555555671cbb in command_loop () at lisp.h:1045 #20 0x0000555555676926 in recursive_edit_1 () at keyboard.c:714 #21 0x0000555555676c45 in Frecursive_edit () at keyboard.c:786 #22 0x000055555559b227 in main (argc=2, argv=0x7fffffffe978) at emacs.c:1962 It's reproducible here, so I can provide more debugging information if required. I'm aware that doing complicated stuff in a display spec condition is a bad idea, but I think debug messages are such an important special case that we ought, at least, not to abort completely for those. Setting redisplay--bidi-inhibit to t works around the problem. ------------=_1561104902-2279-1-- From unknown Mon Aug 18 11:26:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36312: 27.0.50; (message) in display spec condition causes emacs_abort() Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jun 2019 08:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: pipcet@gmail.com Cc: 36312@debbugs.gnu.org Received: via spool by 36312-submit@debbugs.gnu.org id=B36312.15611063884581 (code B ref 36312); Fri, 21 Jun 2019 08:40:02 +0000 Received: (at 36312) by debbugs.gnu.org; 21 Jun 2019 08:39:48 +0000 Received: from localhost ([127.0.0.1]:49614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1heF5H-0001Bo-NM for submit@debbugs.gnu.org; Fri, 21 Jun 2019 04:39:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53341) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1heF5G-0001Bd-AZ for 36312@debbugs.gnu.org; Fri, 21 Jun 2019 04:39:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1heF5B-0004El-57; Fri, 21 Jun 2019 04:39:41 -0400 Received: from [176.228.60.248] (port=3541 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1heF5A-0002sz-Hy; Fri, 21 Jun 2019 04:39:40 -0400 Date: Fri, 21 Jun 2019 11:39:31 +0300 Message-Id: <83a7ebpc1o.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <83fto3pf25.fsf@gnu.org> (message from Eli Zaretskii on Fri, 21 Jun 2019 10:34:26 +0300) References: <83pnn8p1nk.fsf@gnu.org> <83fto3pf25.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 21 Jun 2019 10:34:26 +0300 > From: Eli Zaretskii > Cc: 36312@debbugs.gnu.org > > 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. FTR, I wanted to draw your attention to some problematic aspects of using 'when' in display specs as a kind of "redisplay hook". First aspect that you need to be aware of is that when the display spec is being evaluated, there's no 100% guarantee that the value of point is what will eventually be displayed. In some, admittedly rare, situations, when redisplay is finished, it turns out that point is not in a fully visible screen line. In such cases, the display engine can decide to move point to bring it back into the viewport. It then performs another redisplay cycle, but that is not guaranteed to re-evaluate your display spec, because Emacs might find a redisplay optimization which avoids that (typically, moving point only needs to consider point's line). More generally, if a window is redrawn, the display engine might decide not to redisplay the line where you have your display spec, but instead either scroll the display (i.e. reuse the results of the previous redisplay cycle), or even bypass that line altogether, because it decides that this line is outside of the region affected by the last command. Another problematic aspect is that the display specs are evaluated for purposes other than displaying the results. There are features in Emacs that need to perform text layout calculations without displaying the text whose layout they consider. One popular example is C-n/C-p, which calls vertical-motion internally. vertical-motion then invokes the display engine in a special mode which performs text layout calculations and measures the text dimensions without displaying that text, just because it needs to figure out, for example, what character or buffer position is on display directly below or above the given screen coordinates. The result of this is that your 'when' form will be called in contexts other than redisplay, and if you fire timers or other functions inside that form, you will find that your code is invoked more than once per command, in different contexts you didn't necessarily expect, and with point whose value may not be up to date. To continue the same example, vertical-motion invokes the display routine before it moves point, precisely _because_ it needs to perform layout calculations to decide where to move point.