GNU bug report logs - #64391
30.0.50; buffer narrowing slowdown regression in emacs 29

Previous Next

Packages: emacs, gnus;

Reported by: Andrew Cohen <acohen <at> ust.hk>

Date: Sat, 1 Jul 2023 00:21:02 UTC

Severity: normal

Found in version 30.0.50

Full log


Message #104 received at 64391 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: acohen <at> ust.hk, 64391 <at> debbugs.gnu.org, mattias.engdegard <at> gmail.com,
 eliz <at> gnu.org, bugs <at> gnus.org
Subject: Re: bug#64391: buffer narrowing slowdown regression in emacs 29
Date: Sat, 08 Jul 2023 17:42:19 -0400
>>> I'm sorry, I don't understand your question.  The only way (except by
>>> using internal functions) to enter a labeled restriction is to use the
>>> with-restriction special form with its optional label argument.
>> Nitpick: it's not a special form, it's a macro.  There's a *big*
>> difference because adding a special form requires changing
>> `macroexpand-all`, the compiler, yadayada, and it introduces backward
>> incompatibilities with packages doing their own code-walks.
> TIL.  I thought that "special form" and "macro" were more or less synonyms.
> The manual describes lambda, prog2, setq-default, dlet, letrec, named-let,
> with-suppressed-warnings, with-no-warnings, with-restriction and
> without-restriction as "special forms", although they are in fact macros.

You're right: from a programmer's stand point the distinction doesn't
really matter.  It matters only from the point of view of the language
implementer.  For some reason it tripped me, here (I went looking at the
code fearing that we were using an actual special form).

Sorry 'bout that, move along, nothing to see :-)

>> BTW, "LABEL is a symbol" sends the wrong message (a quoted symbol
>> evaluates to a symbol but it's not itself a symbol). IOW the docstring
>> should clarify that LABEL is an expression that's evaluated at runtime
>> (and should return a symbol). While I'm here, is it important that LABEL
>> evaluates to a symbol? Or is it like `catch/throw` where we expect most
>> uses to use a symbol but where any other (non-nil) value works as well?
>
> The latter: it's like catch/throw, it's intended to use with a symbol but it
> could be any non-nil value.  So one could write something similar to what is
> found in the docstring of catch: "LABEL is evalled to get the label to use,
> it must not be nil".

+1 from me,


        Stefan





This bug report was last modified 1 year and 342 days ago.

Previous Next


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