GNU bug report logs - #40897
Negation of pixel-width :width expressions does not work

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Pip Cet <pipcet@HIDDEN>; dated Mon, 27 Apr 2020 08:49:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 40897 <at> debbugs.gnu.org:


Received: (at 40897) by debbugs.gnu.org; 27 Apr 2020 14:32:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 27 10:32:20 2020
Received: from localhost ([127.0.0.1]:37747 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jT4o0-00088I-34
	for submit <at> 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 <eliz@HIDDEN>) id 1jT4ny-000883-0C
 for 40897 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <CAOqdjBcDg2t_kRFmcEftJ_hpC0a70c5HJwFYqa9o-r0bJttRzQ@HIDDEN>
 (message from Pip Cet on Mon, 27 Apr 2020 08:47:50 +0000)
Subject: Re: bug#40897: Negation of pixel-width :width expressions does not
 work
References: <CAOqdjBcDg2t_kRFmcEftJ_hpC0a70c5HJwFYqa9o-r0bJttRzQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 40897
Cc: 40897 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> 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);




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40897; Package emacs. Full text available.

Message received at 40897 <at> debbugs.gnu.org:


Received: (at 40897) by debbugs.gnu.org; 27 Apr 2020 12:19:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 27 08:19:27 2020
Received: from localhost ([127.0.0.1]:35824 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jT2jO-0008KM-QE
	for submit <at> 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 <pipcet@HIDDEN>) id 1jT2jM-0008K6-D4
 for 40897 <at> 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 <at> 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: <CAOqdjBcDg2t_kRFmcEftJ_hpC0a70c5HJwFYqa9o-r0bJttRzQ@HIDDEN>
In-Reply-To: <CAOqdjBcDg2t_kRFmcEftJ_hpC0a70c5HJwFYqa9o-r0bJttRzQ@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Mon, 27 Apr 2020 12:18:41 +0000
Message-ID: <CAOqdjBfZZG38fOu4icmB+r3c55tw6_7HMo1hAZBpn=hVtBAAXA@HIDDEN>
Subject: Re: bug#40897: Negation of pixel-width :width expressions does not
 work
To: 40897 <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 40897
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Mon, Apr 27, 2020 at 8:49 AM Pip Cet <pipcet@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40897; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 27 Apr 2020 08:48:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 27 04:48:38 2020
Received: from localhost ([127.0.0.1]:35649 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSzRN-0000g1-Jl
	for submit <at> 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 <pipcet@HIDDEN>) id 1jSzRL-0000ft-Ia
 for submit <at> 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 <pipcet@HIDDEN>) id 1jSzRK-0003qk-23
 for bug-gnu-emacs@HIDDEN; 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 <pipcet@HIDDEN>) id 1jSzRF-0005av-HI
 for bug-gnu-emacs@HIDDEN; 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 <pipcet@HIDDEN>) id 1jSzRF-0005Zw-4D
 for bug-gnu-emacs@HIDDEN; Mon, 27 Apr 2020 04:48:29 -0400
Received: by mail-ot1-x32a.google.com with SMTP id m13so24840698otf.6
 for <bug-gnu-emacs@HIDDEN>; 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 <pipcet@HIDDEN>
Date: Mon, 27 Apr 2020 08:47:50 +0000
Message-ID: <CAOqdjBcDg2t_kRFmcEftJ_hpC0a70c5HJwFYqa9o-r0bJttRzQ@HIDDEN>
Subject: Negation of pixel-width :width expressions does not work
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/mixed; boundary="0000000000004ad4da05a441c77d"
Received-SPF: pass client-ip=2607:f8b0:4864:20::32a;
 envelope-from=pipcet@HIDDEN; 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-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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: <f_k9i8n4k40>
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--




Acknowledgement sent to Pip Cet <pipcet@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#40897; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 27 Apr 2020 14:45:01 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.