GNU bug report logs - #44854
[PATCH] Add lexical-binding cookie to autoload files

Previous Next

Package: emacs;

Reported by: Stefan Kangas <stefan <at> marxist.se>

Date: Tue, 24 Nov 2020 19:35:02 UTC

Severity: wishlist

Tags: fixed, patch

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#44854: [PATCH] Add lexical-binding cookie to autoload files
Date: Fri, 27 Nov 2020 22:39:27 +0000
On Thu 26 Nov 2020, Eli Zaretskii wrote:

>> From: Stefan Kangas <stefan <at> marxist.se>
>> Date: Wed, 25 Nov 2020 16:07:19 -0500
>> Cc: 44854 <at> debbugs.gnu.org
>> 
>> >> I was not discussing specifically `loaddefs.el`.
>> >> The reason to change it in `loaddefs.el` now rather than later is
>> >> because I can't see any benefit to doing it later.
>> >
>> > That's not a reason good enough in my book, sorry.
>> 
>> FWIW, I have been working towards this crude metric:
>> 
>>   find -iname "*.el" -exec egrep -L "lexical-binding: *t" {} \; | wc -l
>> 
>> This gives some indicator for how ready we are to "flip the switch".  An
>> even better metric would of course be possible, for example by counting
>> SLOC or making it ignore files with side-effect free statements.  But it
>> hasn't seemed worth the trouble.
>> 
>> Also, the above metric can easily be converted to a TODO-list:
>> 
>>   find -iname "*.el" -exec egrep -L "lexical-binding: *t" {} \; | sort
>> 
>> This is how I've been using it.  I've been looking to make the number of
>> files go down by adding the cookie to even insignificant files, as they
>> stand in the way of seeing the files that actually need work.[1]
>> 
>> May I ask why you are against it?  If we agree that it should make no
>> difference one way or the other, why not just do it?
>
> I have nothing against converting Lisp files to lexical-binding, and
> have never objected to any of your recent changes in that direction.
> But this makes sense only in files which be affected by that, and
> autoloads files aren't.  "Converting" them to lexical-binding, and
> modifying the code which produces those files on top of that, sounds
> like we are afraid of our own shadows, or don't know what
> lexical-binding is about (or both).

If adding a lexical-binding tag has no effect on the autoload files
(other than making them a few bytes larger), then it should be of no
consequence. The "conversion" would be the same as for many other files
that did not require any substantive code changes.

Adding the tag to the autoloads is not about needing code changes, but
simply a marker that those files are ready for the flip-the-switch
event.

> My point is that when the time comes to "flip the switch", we can do
> that without having lexical-binding in autoloads files.  They cannot
> be affected by the switch.  If they are, it's probably some subtle bug
> somewhere.

However, by treating all .el files uniformly (including autoloads), it
makes it easier to write scripts that check for lexical binding support
in source files. Simplifying the conversion process help to ensure that
a future flip-the-switch flag day is less likely to introduce problems.

    AndyM






This bug report was last modified 4 years and 199 days ago.

Previous Next


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