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

Previous Next

Packages: gnus, emacs;

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


View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: acohen <at> ust.hk, 64391 <at> debbugs.gnu.org, mattias.engdegard <at> gmail.com, eliz <at> gnu.org
Subject: bug#64391: buffer narrowing slowdown regression in emacs 29
Date: Sat, 08 Jul 2023 20:58:44 +0000
>> 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.  That being said, from a Elisp programmer viewpoint, special forms 
and macros are similar, and AFAIU one could say that a special form is a 
macro written in C, and a macro is a special form written in Elisp.

Should the above occurrences of "special form" be corrected in the 
manuals?

>> Indeed, but I'd say it's clear enough from the context that "symbol" 
>> means a quoted symbol here.
>
> Other nitpick: nil can also be quoted :-)
>

I knew someone would say that ;-)

>
> 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".





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.