bug#20640: 24.5; lexical-binding should work like a normal file-local variable

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Philipp Stephani]

The manual
(https://www.gnu.org/software/emacs/manual/html_node/elisp/Using-Lexical-Binding.html)
says about `lexical-binding':

   Note that unlike other such variables, this one must be set in the
   first line of a file.

I think the only reason for this is an implementation detail
(lexical-binding is parsed by other code than the other file-local
variables).  It would be great to make it consistent with other
variables so that the user doesn't need to care about the difference.



In GNU Emacs 24.5.1 (x86_64-apple-darwin14.1.0, NS apple-appkit-1344.72)
 of 2015-04-12 on p
Configured using:
 `configure --prefix=/usr/local/Cellar/emacs/24.5
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs/24.5/share/info/emacs
 --with-file-notification=gfile --with-dbus --with-gnutls --with-rsvg
 --with-imagemagick --without-popmail --with-ns
 --disable-ns-self-contained'

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
(New file)
For this change to take effect revisit file using s-u
Saving file /tmp/foo.el...
Wrote /tmp/foo.el
C-x C-g is undefined
You can run the command `revert-buffer' with s-u

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils warnings help-fns files-x xterm time-date
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
ns-win tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify cocoa ns multi-tty emacs)

Memory information:
((conses 16 79278 6322)
 (symbols 48 17661 0)
 (miscs 40 38 142)
 (strings 32 10374 4568)
 (string-bytes 1 270725)
 (vectors 16 7214)
 (vector-slots 8 341033 28254)
 (floats 8 62 328)
 (intervals 56 188 27)
 (buffers 960 14))

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Stefan Monnier]

> I think the only reason for this is an implementation detail
> (lexical-binding is parsed by other code than the other file-local
> variables).  It would be great to make it consistent with other
> variables so that the user doesn't need to care about the difference.

Allowing it at the end of the file, would require jumping to the end of
the file first, and then starting over from the beginning.
That'd be a very bad requirement.


        Stefan

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

On 05/24/2015 06:59 PM, Stefan Monnier wrote:
>> I think the only reason for this is an implementation detail
>> (lexical-binding is parsed by other code than the other file-local
>> variables).  It would be great to make it consistent with other
>> variables so that the user doesn't need to care about the difference.
> 
> Allowing it at the end of the file, would require jumping to the end of
> the file first, and then starting over from the beginning.
> That'd be a very bad requirement.

Why? We're going to have to read that page eventually anyway.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Stefan Monnier]

>>> I think the only reason for this is an implementation detail
>>> (lexical-binding is parsed by other code than the other file-local
>>> variables).  It would be great to make it consistent with other
>>> variables so that the user doesn't need to care about the difference.
>> Allowing it at the end of the file, would require jumping to the end of
>> the file first, and then starting over from the beginning.
>> That'd be a very bad requirement.
> Why? We're going to have to read that page eventually anyway.

Because we can't read the first page correctly until we know whether it
should be read in lexical-binding mode or in dynamic-binding mode.


        Stefan

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Glenn Morris]

Stefan Monnier wrote:

>>> Allowing it at the end of the file, would require jumping to the end of
>>> the file first, and then starting over from the beginning.
>>> That'd be a very bad requirement.
>> Why? We're going to have to read that page eventually anyway.
>
> Because we can't read the first page correctly until we know whether it
> should be read in lexical-binding mode or in dynamic-binding mode.

A few years ago, we said (IIUC) it was desirable:

http://debbugs.gnu.org/10605
http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00543.html

Or have speed-ups in uncompiled code shifted the balance?

(But no-one shows any sign of doing anything, so it's all academic.)

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Stefan Monnier]

> A few years ago, we said (IIUC) it was desirable:
> http://debbugs.gnu.org/10605

Well, *you* said, but *we* didn't, IIUC.

For me, as long as we intend to allow running .el files without
byte-compiling them, I think allowing lexical-binding to be specified at
the end of the file would be a design mistake.


        Stefan

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Glenn Morris]

Stefan Monnier wrote:

>> A few years ago, we said (IIUC) it was desirable:
>> http://debbugs.gnu.org/10605
>
> Well, *you* said, but *we* didn't, IIUC.

Hah, true enough, although IMO you were a least a little more ambiguous in

>> http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00543.html


Anyway:

> For me, as long as we intend to allow running .el files without
> byte-compiling them, I think allowing lexical-binding to be specified at
> the end of the file would be a design mistake.

Even if the code were to check for "coding:" (which we already have to
scan the end of the file for) and "lexical-binding:" in the same pass?

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Stefan Monnier]

> Even if the code were to check for "coding:" (which we already have to
> scan the end of the file for) and "lexical-binding:" in the same pass?

The check for "coding:" is a misdesign, indeed.  I think we should use
some utf-8 tell-tale sign at the beginning of *.el files to eliminate
the need to check for "coding:" (and to go through
load-with-code-conversion) in the normal case.  It could be a utf-8 BOM
or something like that.  Ideally we could give extra meaning to this
marker so it not only means "uses utf-8" but also "uses
lexical-scoping", so that we can have a future where we don't need to
add "lexical-binding:t" to every file.


        Stefan

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Mi., 27. Mai 2015 um
03:49 Uhr:

> > Even if the code were to check for "coding:" (which we already have to
> > scan the end of the file for) and "lexical-binding:" in the same pass?
>
> The check for "coding:" is a misdesign, indeed.  I think we should use
> some utf-8 tell-tale sign at the beginning of *.el files to eliminate
> the need to check for "coding:" (and to go through
> load-with-code-conversion) in the normal case.  It could be a utf-8 BOM
> or something like that.  Ideally we could give extra meaning to this
> marker so it not only means "uses utf-8" but also "uses
> lexical-scoping", so that we can have a future where we don't need to
> add "lexical-binding:t" to every file.
>
>
>
I don't think this is a misdesign. In most cases files are either seekable
or small enough so that reading the variables from the end is tolerable. I
prefer the end of files for local variables because they tend to be less
important than the actual content.

[-- Attachment #2: Type: text/html, Size: 1421 bytes --]

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Stefan Monnier]

> I don't think this is a misdesign. In most cases files are either seekable
> or small enough so that reading the variables from the end is tolerable. I
> prefer the end of files for local variables because they tend to be less
> important than the actual content.

I'm not talking about file-local variables in general.  I'm talking
about the "coding:" pseudo-variable.


        Stefan

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Mo., 22. Juni 2015 um
17:57 Uhr:

> > I don't think this is a misdesign. In most cases files are either
> seekable
> > or small enough so that reading the variables from the end is tolerable.
> I
> > prefer the end of files for local variables because they tend to be less
> > important than the actual content.
>
> I'm not talking about file-local variables in general.  I'm talking
> about the "coding:" pseudo-variable.
>
>
>
No matter how we choose to call it: My argument stands, reading such
pseudo-variables from the end of the file is desirable, useful, and has
negligible disadvantages. Or do we have evidence that users routinely read
very large (gigabyte-sized) Elisp files from non-seekable sources?

[-- Attachment #2: Type: text/html, Size: 1264 bytes --]

bug#20640: 24.5; lexical-binding should work like a normal file-local variable

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 11 Sep 2016 18:04:13 +0000
> Cc: 20640@debbugs.gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Mo., 22. Juni 2015 um 17:57 Uhr:
> 
>  > I don't think this is a misdesign. In most cases files are either seekable
>  > or small enough so that reading the variables from the end is tolerable. I
>  > prefer the end of files for local variables because they tend to be less
>  > important than the actual content.
> 
>  I'm not talking about file-local variables in general. I'm talking
>  about the "coding:" pseudo-variable.
> 
> No matter how we choose to call it: My argument stands, reading such pseudo-variables from the end of the
> file is desirable, useful, and has negligible disadvantages. Or do we have evidence that users routinely read
> very large (gigabyte-sized) Elisp files from non-seekable sources? 

Guys, is this really such a big deal to justify changes in an area
which was not touched in eons?  Just let the sleeping dogs lie.