From unknown Sun Jun 15 10:55:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40897: Negation of pixel-width :width expressions does not work Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2020 08:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 40897 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 40897@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.15879773182610 (code B ref -1); Mon, 27 Apr 2020 08:49:01 +0000 Received: (at submit) by debbugs.gnu.org; 27 Apr 2020 08:48:38 +0000 Received: from localhost ([127.0.0.1]:35649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSzRN-0000g1-Jl for submit@debbugs.gnu.org; Mon, 27 Apr 2020 04:48:37 -0400 Received: from lists.gnu.org ([209.51.188.17]:36494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSzRL-0000ft-Ia for submit@debbugs.gnu.org; Mon, 27 Apr 2020 04:48:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53850) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSzRK-0003qk-23 for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2020 04:48:35 -0400 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSzRF-0005av-HI for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2020 04:48:33 -0400 Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]:39640) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSzRF-0005Zw-4D for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2020 04:48:29 -0400 Received: by mail-ot1-x32a.google.com with SMTP id m13so24840698otf.6 for ; Mon, 27 Apr 2020 01:48:28 -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=5WxPetgRP8Iz7CTkEPdMzOIIKoXk4S2iCU5ugN9cjvc=; b=XrLzXJusbVH0I6jwXKREGXY0mt6672Vqdhox7bdlp3nnkL8nelHocCuLNXfj6YfZzv BN3KpYEh6QMgfSU8zn6IKLKpkl2dP4BtjYmn9z7fYokvKPlT//OQnpnm1sY+WADJX8/b H13R2MeDXTO/eOKlv6K+0ytRlxsqlM5hapCtfTXTUJGE/x2bqXCRC+ODFgmYCsrNEOT7 BBhAV9aJrghJIFjqApaIJJf3lr0NtoRNXzGcQtvyvOctecv8iHkLyc0Zc44P9ro4oqUC cyZ00/IqnPwS5ukdSz/keOGRY+T95OXIwoa2C/1ttsdzrSB1usdaO7K0h/XLah4dZdiN 3NLQ== 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=5WxPetgRP8Iz7CTkEPdMzOIIKoXk4S2iCU5ugN9cjvc=; b=VDvjq857J+RlebL+QbXnKrIPpKWR1Bg3dwqdN0kz5vZuhSCv8EhZ01uC1VqVpCK46G OJ7dQlNNIWZqKsedwcBIkkd5IDMbqs74OBXWMM3D9b9d0jG9s1mxZZ19dg5F6H5Oejgg bKbyK6hQE6fLVdSVh3qjH1bZ/YjVIneig/u4tY3z2ffzeVd8P1fgNL4DnEUifu1A4nai GZbFQKoHxgY90/1aTZOzd/4Xa3op1jdGX6AhYEGHEmDGjheXb1LOjRMW6muefs44SaYD WukaD49EXkD8ST6fRQhPi/v2rsJDjXGaAbSUVuTS1T0qjhAuUDSvDcEce6u0j+PXFhbt zIPQ== X-Gm-Message-State: AGi0PuZ0uD7QBgKhTk1Ggi+8PbODvwsAPXY6XmPYgSfDj35TQsQZWofz PAdCbue+BDMO1fxwp7cCe32Z0Wi9Qmsk0bFLeOrXrV7m3nA= X-Google-Smtp-Source: APiQypIUsMc+GLt3hEVNt+XJtHDz/fnHv6MpV97mckV/U1d71K2EteklaEE2mrXWuTtjl2GHui2iBe4DFt6GjJUjM3s= X-Received: by 2002:a05:6830:1059:: with SMTP id b25mr69552otp.292.1587977306938; Mon, 27 Apr 2020 01:48:26 -0700 (PDT) MIME-Version: 1.0 From: Pip Cet Date: Mon, 27 Apr 2020 08:47:50 +0000 Message-ID: Content-Type: multipart/mixed; boundary="0000000000004ad4da05a441c77d" Received-SPF: pass client-ip=2607:f8b0:4864:20::32a; envelope-from=pipcet@gmail.com; helo=mail-ot1-x32a.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2607:f8b0:4864:20::32a X-Spam-Score: 0.7 (/) 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 (--) --0000000000004ad4da05a441c77d Content-Type: text/plain; charset="UTF-8" In looking over the xdisp.c code, I noticed that calc_pixel_width_or_height has at least three problems: 1. negation of width specifiers doesn't work 2. a circular list passed to (+) will hang Emacs 3. a circular list passed directly will crash Emacs (1) is a significant bug and should be fixed. (2) is easy to fix, and we should probably do so on the master branch. (3) is difficult to fix, but I'd like to fix all these, and undiscovered similar issues, by converting calc_pixel_width_or_height to using the Lisp interpreter. The underlying problem is we're writing yet another mini-interpreter for a limited Lisp-like language, in C. That means no quitting, no protection against stack overflows, and getting tricky semantics (such as the different behavior of (- A) and (- A B ...)) wrong. My proposal is to move the somewhat complex logic of calc_pixel_width_or_height to Lisp code, run when the display spec is actually evaluated (i.e. when "(when ...)" display specs run their Lisp code). This could be achieved by a method similar to the patch for bug#40845 in https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-04/msg01096.html. This would also resolve bug#40856 by allowing more complicated space calculations at a time when the font metrics are known. I'm attaching a patch, against master, for (1) only. I haven't tried to restore the previous "optimization" of avoiding (very cheap) calls to EQ for all but the first argument. Recipes: (1): (insert (propertize " " 'display '(space :width (+ 50 (- 50))))) Expected result: a zero-width space Actual result: a space of width 100 (2): (let ((l (cons 0 nil))) (setcdr l l) (insert (propertize " " 'display `(space :width (+ . ,l))))) Expected result: a quittable infinite loop Actual result: a non-quittable infinite loop (3): (let ((l (cons 0 nil))) (setcdr l l) (insert (propertize " " 'display `(space :width ,l)))) Expected result: a Lisp stack overflow error Actual result: a C stack overflow, Emacs crashes --0000000000004ad4da05a441c77d Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Fix-pixel-width-evaluation-of-negated-specs.patch" Content-Disposition: attachment; filename="0001-Fix-pixel-width-evaluation-of-negated-specs.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_k9i8n4k40 RnJvbSBiNzQ5M2ZmOTM0NTUzYTJkMDA4Y2NlNGZiODg0NGQyNWZkMmRmOTk4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBNb24s IDI3IEFwciAyMDIwIDA4OjQxOjUyICswMDAwClN1YmplY3Q6IFtQQVRDSF0gRml4IHBpeGVsLXdp ZHRoIGV2YWx1YXRpb24gb2YgbmVnYXRlZCBzcGVjcwoKKiBzcmMveGRpc3AuYyAoY2FsY19waXhl bF93aWR0aF9vcl9oZWlnaHQpOiBGaXggZXZhbHVhdGlvbiBvZiAoLSBYKQpTUEVDLgotLS0KIHNy Yy94ZGlzcC5jIHwgMTAgKysrKystLS0tLQogMSBmaWxlIGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygr KSwgNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMveGRpc3AuYyBiL3NyYy94ZGlzcC5j CmluZGV4IDE0MGQxMzQ1NzIuLjFhYmE0Yzg5MDEgMTAwNjQ0Ci0tLSBhL3NyYy94ZGlzcC5jCisr KyBiL3NyYy94ZGlzcC5jCkBAIC0yNzI3OCw3ICsyNzI3OCw3IEBAIGNhbGNfcGl4ZWxfd2lkdGhf b3JfaGVpZ2h0IChkb3VibGUgKnJlcywgc3RydWN0IGl0ICppdCwgTGlzcF9PYmplY3QgcHJvcCwK IAkgICAgIHJlY3Vyc2l2ZWx5IGNhbGN1bGF0ZWQgdmFsdWVzLiAgKi8KIAkgIGlmIChFUSAoY2Fy LCBRcGx1cykgfHwgRVEgKGNhciwgUW1pbnVzKSkKIAkgICAgewotCSAgICAgIGJvb2wgZmlyc3Qg PSB0cnVlOworCSAgICAgIHB0cmRpZmZfdCBjb3VudCA9IDA7CiAJICAgICAgZG91YmxlIHB4Owog CiAJICAgICAgcGl4ZWxzID0gMDsKQEAgLTI3Mjg3LDEzICsyNzI4NywxMyBAQCBjYWxjX3BpeGVs X3dpZHRoX29yX2hlaWdodCAoZG91YmxlICpyZXMsIHN0cnVjdCBpdCAqaXQsIExpc3BfT2JqZWN0 IHByb3AsCiAJCSAgaWYgKCFjYWxjX3BpeGVsX3dpZHRoX29yX2hlaWdodCAoJnB4LCBpdCwgWENB UiAoY2RyKSwKIAkJCQkJCSAgIGZvbnQsIHdpZHRoX3AsIGFsaWduX3RvKSkKIAkJICAgIHJldHVy biBmYWxzZTsKLQkJICBpZiAoZmlyc3QpCi0JCSAgICBwaXhlbHMgPSAoRVEgKGNhciwgUXBsdXMp ID8gcHggOiAtcHgpLCBmaXJzdCA9IGZhbHNlOwotCQkgIGVsc2UKKwkJICBpZiAoY291bnQrKyA9 PSAwKQogCQkgICAgcGl4ZWxzICs9IHB4OworCQkgIGVsc2UKKwkJICAgIHBpeGVscyArPSAoRVEg KGNhciwgUXBsdXMpID8gcHggOiAtcHgpOwogCQkgIGNkciA9IFhDRFIgKGNkcik7CiAJCX0KLQkg ICAgICBpZiAoRVEgKGNhciwgUW1pbnVzKSkKKwkgICAgICBpZiAoRVEgKGNhciwgUW1pbnVzKSAm JiBjb3VudCA9PSAxKQogCQlwaXhlbHMgPSAtcGl4ZWxzOwogCSAgICAgIHJldHVybiBPS19QSVhF TFMgKHBpeGVscyk7CiAJICAgIH0KLS0gCjIuMjYuMgoK --0000000000004ad4da05a441c77d-- From unknown Sun Jun 15 10:55:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40897: Negation of pixel-width :width expressions does not work Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2020 12:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40897 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 40897@debbugs.gnu.org Received: via spool by 40897-submit@debbugs.gnu.org id=B40897.158798996732018 (code B ref 40897); Mon, 27 Apr 2020 12:20:02 +0000 Received: (at 40897) by debbugs.gnu.org; 27 Apr 2020 12:19:27 +0000 Received: from localhost ([127.0.0.1]:35824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT2jO-0008KM-QE for submit@debbugs.gnu.org; Mon, 27 Apr 2020 08:19:26 -0400 Received: from mail-ot1-f43.google.com ([209.85.210.43]:41521) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT2jM-0008K6-D4 for 40897@debbugs.gnu.org; Mon, 27 Apr 2020 08:19:24 -0400 Received: by mail-ot1-f43.google.com with SMTP id c3so25700593otp.8 for <40897@debbugs.gnu.org>; Mon, 27 Apr 2020 05:19:24 -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; bh=MfF6VuMt8q/CjJhg3Jue0Hpe1/6NGE4KYqnkjh+1j2w=; b=HnQXiM601+4gVsgrPYQsyNknOgJ+L2WzgjA1Ny9Z64WOsq9KZKYNV1lc0UaXQGoS3M LYRdYzTjDo5g2w1gWoF9zZgg6WAXMs0sEzH5kk1XHS0PHEfdU6B58gyYfuWSrAbF1crO Bhrm7Lnj9X8IpvZTbcIVfRpIriIv6ctU7OGqKuYE0WvP2VfEg6i2nn7biG5XAFNRI5FS aAUcb05FpH9l4ga8RstG+iukhk7lrTvcnc/rNKiJgvFCvIxt9yGYeXDqUYtz8qEOyyvk 4OQeMDl7a+qnE2gd5mAgHoCmmGePdI/a8/LvR/15u+45FsXX8bHCPVwgvJ/QjVaa03mW J0VA== 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; bh=MfF6VuMt8q/CjJhg3Jue0Hpe1/6NGE4KYqnkjh+1j2w=; b=eBdR07vzGwTVKn3wSWfjBI+xhYy+wMwaWwcvD9jqDyc/im8XL3oS0d0WrAy7RhYu/z 5zPS90vrKByVdHv0nY2ThAG5rzO2/p17uSOvs7IpCafj0qHl0uQIAgOoiwZ7OF+TnQMM OJOwVoruK/1NMqlwptPqsC9o2ssMe6Y2i7PiogZAPUEECsY+SSSzVRn0HtHxdh3fL0Qg IGFW5I4NdhFRqKszvRudogkbmIbyuzjh0w5DG4genbx+9MUZbL5meETz1kstrl9m9xbe XF1zmYFdQur/p9jwsSFHBh3W+C/dn2KAU3OV/4/P5ffMl9hoS4cYClPecchDjgmULUpy 2bKQ== X-Gm-Message-State: AGi0PuavuS4nguqh2OHx5jGAHl5pD+8uBN+NALOSZlcmYUZSDhhb9D/I XdxBGs3QJByTq68//up7gkzMLTURfiuMyOJRAdwS5ARnNnU= X-Google-Smtp-Source: APiQypKNv2rga15fn0SpL5X4lFwgHjDqe9Pd7dac1nSj3/3sI0FlfHesiQ05w+evY/bcUhjJBlGi5k7oHO0igFJghYQ= X-Received: by 2002:aca:5614:: with SMTP id k20mr15234266oib.30.1587989957962; Mon, 27 Apr 2020 05:19:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pip Cet Date: Mon, 27 Apr 2020 12:18:41 +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 Mon, Apr 27, 2020 at 8:49 AM Pip Cet wrote: > 3. a circular list passed directly will crash Emacs I'm not saying this is a security issue, but you can create a text/enriched file, in the obvious way, which will crash emacs -Q when you open it. That's very inconvenient. From unknown Sun Jun 15 10:55:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40897: Negation of pixel-width :width expressions does not work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2020 14:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40897 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 40897@debbugs.gnu.org Received: via spool by 40897-submit@debbugs.gnu.org id=B40897.158799794031271 (code B ref 40897); Mon, 27 Apr 2020 14:33:01 +0000 Received: (at 40897) by debbugs.gnu.org; 27 Apr 2020 14:32:20 +0000 Received: from localhost ([127.0.0.1]:37747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT4o0-00088I-34 for submit@debbugs.gnu.org; Mon, 27 Apr 2020 10:32:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT4ny-000883-0C for 40897@debbugs.gnu.org; Mon, 27 Apr 2020 10:32:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36622) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT4nr-000195-LI; Mon, 27 Apr 2020 10:32:11 -0400 Received: from [176.228.60.248] (port=1674 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jT4nq-0007JU-8L; Mon, 27 Apr 2020 10:32:11 -0400 Date: Mon, 27 Apr 2020 17:32:05 +0300 Message-Id: <83y2qh3spm.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Pip Cet on Mon, 27 Apr 2020 08:47:50 +0000) References: 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: Mon, 27 Apr 2020 08:47:50 +0000 > > In looking over the xdisp.c code, I noticed that > calc_pixel_width_or_height has at least three problems: > > 1. negation of width specifiers doesn't work Thanks. That should tell us how many people tried to use this feature since it was introduced, 16 years ago ;-) > 2. a circular list passed to (+) will hang Emacs > 3. a circular list passed directly will crash Emacs > > (1) is a significant bug and should be fixed. (2) is easy to fix, and > we should probably do so on the master branch. (3) is difficult to > fix, but I'd like to fix all these, and undiscovered similar issues, > by converting calc_pixel_width_or_height to using the Lisp > interpreter. I don't think converting this to Lisp is a good idea, and I try to explain below why. It doesn't seem to be needed for fixing these particular problems (see the proposed patch below), and even more so given the evidence of this feature's popularity. > The underlying problem is we're writing yet another mini-interpreter > for a limited Lisp-like language, in C. That is true, but there's a reason to this. > That means no quitting, no protection against stack overflows You cannot usefully quit or protect against stack overflow inside redisplay anyway. Quitting or signaling an error during redisplay just gives you an endless redisplay loop, because signaling an error immediately enters another redisplay cycle. And even if you catch the error and quietly return, in many/most cases you have another redisplay either immediately or soon enough, and that presents a locked-up or almost a locked-up Emacs ("almost" means that typing M-< or M-> enough time might eventually get you out of the vicious circle, if the problematic place is not at BOB/EOB). The only reasonable way of avoiding these is to prevent the need to error out. You say (3) is difficult to fix, but the patch below does succeed in preventing the stack overflow, so I don't think I understand why you thought this to be difficult. What am I missing? > getting tricky semantics (such as the different behavior of (- A) > and (- A B ...)) wrong. AFAIU, the semantics is the same as in Lisp, isn't it? The implementation has a bug, but the semantics doesn't, I think. > My proposal is to move the somewhat complex logic of > calc_pixel_width_or_height to Lisp code, run when the display spec is > actually evaluated (i.e. when "(when ...)" display specs run their > Lisp code). This could be achieved by a method similar to the patch > for bug#40845 in > https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-04/msg01096.html. > > This would also resolve bug#40856 by allowing more complicated space > calculations at a time when the font metrics are known. You have promoted similar views elsewhere, on at least 2 other occasions, so let me now try to explain why I very much object to moving display functionality to Lisp, as a general tendency (as opposed to some selected circumstances where this could be justified). My reasons are as follows: . Lisp slows down redisplay. First it does that because it's Lisp, and second because it causes GC. We already have enough complaints against redisplay slowness (even on today's fast desktop machines!), so we should be very careful about this. . Handling Lisp errors inside redisplay is tricky, for the reasons explained above. It is even more tricky when Lisp computes something that the rest of redisplay needs for its operation (as opposed to calling various hooks, such as window-scroll-functions, which are basically a one-way street -- if the hook errors out, it doesn't disrupt the display itself). . Last, but not least -- and people tend to forget about this important factor -- using Lisp to calculate display elements makes it nigh impossible to know when certain redisplay optimizations can be validly applied and when not. That's because A Lisp program can potentially do anything and depend on any numbers of global and local state variables, and users will expect the display to change when these variables change their values. Redisplay optimizations are based on tracking some key state variables to deduce when a more thorough redisplay is needed and when it is safe to use shortcuts. This is already a hard task, especially since we consistently made Emacs redisplay more and more lazily starting from Emacs 25 -- we still get bug reports about some situations where some state change fails to trigger redisplay, even though the number of possible variables to track is not very large. Using Lisp much more than we do now will make tracking the relevant variables impossible. The result will be only one: we will have to disable more and more optimizations and shortcuts to keep what's on the glass accurate. And Emacs's redisplay can be *really* slow without the optimizations, especially in simple cases, like when you just move the cursor, or delete or insert a character. So my suggestion is to use Lisp as part of redisplay only where no other solution is reasonable or practical, and when the feature we want is really important to have. Once again, there could be certain situations where calling Lisp from the display code might be the only practical solution for some serious and important problem. The above just tries to explain why I don't think that idea is good _in_general_, and why we should try to avoid it if at all possible. I hope I made my position on this clear enough. Here's the patch I came up with to handle the problems you reported. WDYT? diff --git a/src/xdisp.c b/src/xdisp.c index 140d134572..bc27fb15e0 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -27284,11 +27284,16 @@ calc_pixel_width_or_height (double *res, struct it *it, Lisp_Object prop, pixels = 0; while (CONSP (cdr)) { + if (EQ (cdr, XCDR (cdr))) + return false; if (!calc_pixel_width_or_height (&px, it, XCAR (cdr), font, width_p, align_to)) return false; if (first) - pixels = (EQ (car, Qplus) ? px : -px), first = false; + pixels = + (EQ (car, Qminus) && CONSP (XCDR (cdr)) + ? -px + : px), first = false; else pixels += px; cdr = XCDR (cdr); @@ -27305,13 +27310,15 @@ calc_pixel_width_or_height (double *res, struct it *it, Lisp_Object prop, /* '(NUM)': absolute number of pixels. */ if (NUMBERP (car)) -{ + { double fact; int offset = width_p && align_to && *align_to < 0 ? it->lnum_pixel_width : 0; pixels = XFLOATINT (car); if (NILP (cdr)) return OK_PIXELS (pixels + offset); + if (EQ (cdr, XCDR (cdr))) + return false; if (calc_pixel_width_or_height (&fact, it, cdr, font, width_p, align_to)) return OK_PIXELS (pixels * fact + offset); From unknown Sun Jun 15 10:55:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40897: Negation of pixel-width :width expressions does not work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2020 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40897 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 40897@debbugs.gnu.org Received: via spool by 40897-submit@debbugs.gnu.org id=B40897.15879991599118 (code B ref 40897); Mon, 27 Apr 2020 14:53:02 +0000 Received: (at 40897) by debbugs.gnu.org; 27 Apr 2020 14:52:39 +0000 Received: from localhost ([127.0.0.1]:37815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT57e-0002N0-Qc for submit@debbugs.gnu.org; Mon, 27 Apr 2020 10:52:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT57d-0002Mn-7k for 40897@debbugs.gnu.org; Mon, 27 Apr 2020 10:52:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37023) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT57X-0000vi-QU; Mon, 27 Apr 2020 10:52:31 -0400 Received: from [176.228.60.248] (port=2909 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jT57W-0000Te-O1; Mon, 27 Apr 2020 10:52:31 -0400 Date: Mon, 27 Apr 2020 17:52:26 +0300 Message-Id: <83r1w93rrp.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Pip Cet on Mon, 27 Apr 2020 12:18:41 +0000) References: 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: Mon, 27 Apr 2020 12:18:41 +0000 > > I'm not saying this is a security issue, but you can create a > text/enriched file, in the obvious way, which will crash emacs -Q when > you open it. That's very inconvenient. Sure, crashes caused by Lisp should be fixed. From unknown Sun Jun 15 10:55:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40897: Negation of pixel-width :width expressions does not work Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 09:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40897 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 40897@debbugs.gnu.org Received: via spool by 40897-submit@debbugs.gnu.org id=B40897.158832615529088 (code B ref 40897); Fri, 01 May 2020 09:43:02 +0000 Received: (at 40897) by debbugs.gnu.org; 1 May 2020 09:42:35 +0000 Received: from localhost ([127.0.0.1]:48258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUSBm-0007Z6-OF for submit@debbugs.gnu.org; Fri, 01 May 2020 05:42:34 -0400 Received: from mail-ot1-f50.google.com ([209.85.210.50]:34456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUSBl-0007Yr-0L for 40897@debbugs.gnu.org; Fri, 01 May 2020 05:42:33 -0400 Received: by mail-ot1-f50.google.com with SMTP id 72so2186689otu.1 for <40897@debbugs.gnu.org>; Fri, 01 May 2020 02:42:32 -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=EE4A8MbusQRr8rCozFnhQtaFhGjPlb1Jpz+DLUMzW8g=; b=Lg7auaKXIQzieTfmke7Ub+la9nhjNUZaFcf1HOc6gz2Pr1z1KynBVDhfvATcoj9XJQ SkGkdVks7677ISojzkN4cib5frpZSqiYw2728mUoLLGpP9gAxmLomjpWZ3EZIu8rhNHU 4at6hCjk9MuOYFqHXDPn5njbZOjniY9F+kn4KpdVnVm2AfoShutSeidiBVFVzJHA1Gol OuBmtYXBf4bqkTjMtl/9chnAzD/aJtKxH/tl8m7wWofCyep5puxrbY9ZPZ04uTXahgd1 ZGAwLx39mH2H87UMhHW1v9MXj8/aTL7jR0vT6G1giGaF1dOVA6ANzN8bxkGCia7lmEfz FFbA== 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=EE4A8MbusQRr8rCozFnhQtaFhGjPlb1Jpz+DLUMzW8g=; b=IE8xqBNqKAjojQA1lf9+oT9xL3Jv0c39zmbFXMUyUM0H3dlfY0tq1ddJkbpBLw6udO QQN7Emm0Kq8jWBF26cic4etpQ8h1CqYGx1txLQ/Au/hlE4j4Xg2x8F0+KwVtz8ZILZ90 6ZDK3FexKzgGdDk/K5MSBoRLTXX3VzY39thh1bYVXZtBC3ITTLwKZs+0MRjuLiCV+YNW jm/Gaa9lwkM/aw4LHD69tE1phjjwCd5xZXl0oVKW51PhMOW/5y1wyocQZC5Z7iLiK/v5 wDSglGBZcq2WNIuZWkxraCuC6XJNLJhutrxwcJ34Ft8lg8Ww1W8eoqaGMSdu1dncdikw wkZA== X-Gm-Message-State: AGi0PuafYLEMTPQe0U2vrQFevAV2ONMnM2d9Xd8xIDcxP4IBnLM3Nyjx gBm2zuF+PFGnLfKFfy8PRjKpoRins4qy0W4spOM= X-Google-Smtp-Source: APiQypKKvuG3WoVSzz/rh1s48qx8GIYDMPoYlPYqMhJbkBng/bvLzUQmoKM+PS+7hsv1K0uPVSm955iEeUStAMr/05g= X-Received: by 2002:a9d:6b98:: with SMTP id b24mr2943771otq.287.1588326147235; Fri, 01 May 2020 02:42:27 -0700 (PDT) MIME-Version: 1.0 References: <83y2qh3spm.fsf@gnu.org> In-Reply-To: <83y2qh3spm.fsf@gnu.org> From: Pip Cet Date: Fri, 1 May 2020 09:41:51 +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 Mon, Apr 27, 2020 at 2:32 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Mon, 27 Apr 2020 08:47:50 +0000 > You say (3) is difficult to fix, but the patch below does succeed in > preventing the stack overflow, so I don't think I understand why you > thought this to be difficult. What am I missing? Circular lists can have a cycle of length greater than one. However, a simple limitation of how deeply we recurse into the display spec would work, and potentially be more robust. Would you agree with that? Thank you for your other explanations. I've taken the opportunity to have a look at the redisplay code. I'll confess it's a bit overwhelming in its complexity, and my understanding so far is tentative, but it seems to me like it "essentially" goes from buffer text to the glyph matrix in one shot: there's no intermediate state that represents what CSS would call the "resolved style" of the document. Trying to write this email, I'm realizing I need to think about this more: I still think the current state of things, where we call Lisp as part of redisplay but usually don't rely on it, is much better than to exclude Lisp from the process entirely. From unknown Sun Jun 15 10:55:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40897: Negation of pixel-width :width expressions does not work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 10:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40897 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 40897@debbugs.gnu.org Received: via spool by 40897-submit@debbugs.gnu.org id=B40897.158832755931312 (code B ref 40897); Fri, 01 May 2020 10:06:01 +0000 Received: (at 40897) by debbugs.gnu.org; 1 May 2020 10:05:59 +0000 Received: from localhost ([127.0.0.1]:48267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUSYQ-00088x-Q9 for submit@debbugs.gnu.org; Fri, 01 May 2020 06:05:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35446) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUSYP-00088c-32 for 40897@debbugs.gnu.org; Fri, 01 May 2020 06:05:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44925) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUSYI-00016T-UO; Fri, 01 May 2020 06:05:51 -0400 Received: from [176.228.60.248] (port=4273 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jUSYI-0000x1-0y; Fri, 01 May 2020 06:05:50 -0400 Date: Fri, 01 May 2020 13:05:37 +0300 Message-Id: <834kt0vuku.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Pip Cet on Fri, 1 May 2020 09:41:51 +0000) References: <83y2qh3spm.fsf@gnu.org> 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: Fri, 1 May 2020 09:41:51 +0000 > Cc: 40897@debbugs.gnu.org > > On Mon, Apr 27, 2020 at 2:32 PM Eli Zaretskii wrote: > > > From: Pip Cet > > > Date: Mon, 27 Apr 2020 08:47:50 +0000 > > You say (3) is difficult to fix, but the patch below does succeed in > > preventing the stack overflow, so I don't think I understand why you > > thought this to be difficult. What am I missing? > > Circular lists can have a cycle of length greater than one. However, a > simple limitation of how deeply we recurse into the display spec would > work, and potentially be more robust. Would you agree with that? Yes, I agree. But maybe we should do that in addition to the simple check I suggested, as that is much faster. Of course, I have no idea of the relative frequency of each of these use cases, but a single EQ test seems a small price to pay. > Thank you for your other explanations. I've taken the opportunity to > have a look at the redisplay code. I'll confess it's a bit > overwhelming in its complexity, and my understanding so far is > tentative Feel free to ask questions, I'm very much interested in spreading the knowledge about the display engine internals among as many regular contributors as possible. > but it seems to me like it "essentially" goes from buffer text to > the glyph matrix in one shot: there's no intermediate state that > represents what CSS would call the "resolved style" of the document. I'm no CSS expert, but AFAIU we don't have a single equivalent of what CSS can do. We do have a large portion of that, though: the faces. There, we do have the equivalent of the "resolved style", IIUC: the "realized face", see xfaces.c. As part of producing the glyphs in the glyph matrices, the display engine does realize faces that were not (yet) realized, for example, when it finds a character whose appearance is affected by several sources of face information (text properties, overlays, mouse-face, etc.). But this is done on the fly, without a separate pass: the pertinent faces are merged in the appropriate order, then the merged face is realized and cached, and the iteration through text continues using this cached face ID. See the function handle_stop in xdisp.c, which is the focal point for handling anything "unusual" the display engine bumps into while walking the text to display. > Trying to write this email, I'm realizing I need to think about this > more: I still think the current state of things, where we call Lisp as > part of redisplay but usually don't rely on it, is much better than to > exclude Lisp from the process entirely. We don't exclude Lisp entirely. You will see quite a few hooks we call along the way, and also some non-hooks; a notable example of the latter is fontification-functions. What I'm saying is that we need to keep this in check, for those use cases and situations which are important and cannot be reasonably supported via variables or simple forms. We shouldn't add Lisp calls in redisplay "just because we can."