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

Previous Next

Full log

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

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, bugs <at> gnus.org
Subject: Re: bug#64391: buffer narrowing slowdown regression in emacs 29
Date: Sun, 09 Jul 2023 16:03:52 +0000

>> Well, there's at least something that could be fixed in the manuals. I 
>> admit I had never read the "Special Forms" section, and if the manual 
>> had been consistent about the special form vs. macro distiction, 
>> perhaps I wouldn't have confused these two similar, but subtly 
>> different, notions.
>
> At the same time, for the ELisp programmer, this distinction is just an 
> implementation detail (except for rare corner cases where the programmer 
> needs to look at the output of `macroexpand`).  What is a macro and what 
> is a special form has changed in the past and will likely change again 
> in the future (e.g. `defun`, `defmacro`, and `prog2` are now macros but 
> used to be special forms).
>

Indeed, but... what would you suggest?  Leave the manual, in which that 
distinction is not always clear, as it is?  Fix the manual to make that 
distinction clearer?  Remove that distinction, which is indeed an 
implementation detail, from the manual (and perhaps mention that some 
macros are not defined in Elisp but in C, in which case they can also be 
called "special forms")?

Previous Next

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