Defaults for elisp-mode files

Defaults for elisp-mode files

[Stefan Monnier]

I'm seeing more and more Elisp files with "-*- lexical-binding: t;
coding: utf-8 -*-" showing up, and I expect them to become the norm in
the longer term.

So I think in the longer term these annotations should be made
unnecessary because they're ugly.
For the `utf-8', I guess we can simply set auto-coding-alist and we
could do that right now without much risk for serious breakage (IOW
I suggest we do that for the next release after 24.3).

But for the lexical-binding setting, it seems less obvious how to handle
such a switch (other than start warning any file which doesn't set it
explicitly to t or nil, and after a while change the default, and after
yet another while remove the warning, the whole process taking probably
more than 10 years).  Any suggestion would be welcome.


        Stefan

RE: Defaults for elisp-mode files

[Drew Adams]

>I'm seeing more and more Elisp files with "-*- lexical-binding: t;
>
> I think in the longer term these annotations should be made
> unnecessary because they're ugly. Any suggestion would be welcome.

Suggestion: Don't do it.  Let them be (ugly).

Instead, please fix bugs introduced by changing to lexical binding without
sufficient care.

Bug (regression) #12232, for instance, introduced back in May and which has
received no response.  ("Lisp nesting exceeds `max-lisp-eval-depth'")

Re: Defaults for elisp-mode files

[Christopher Schmidt]

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> So I think in the longer term these annotations should be made
> unnecessary because they're ugly.

I use a minor mode that hides these annotations.

[-- Attachment #2: my-hide-file-local-variable-prop-line.el --]
[-- Type: application/emacs-lisp, Size: 2487 bytes --]

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


        Christopher

Re: Defaults for elisp-mode files

[Juanma Barranquero]

On Wed, Oct 3, 2012 at 8:06 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> But for the lexical-binding setting, it seems less obvious how to handle
> such a switch (other than start warning any file which doesn't set it
> explicitly to t or nil, and after a while change the default, and after
> yet another while remove the warning, the whole process taking probably
> more than 10 years).  Any suggestion would be welcome.

Why can't we set lexical-binding from .dir-locals, so it would
automatically "convert" all the lisp packages in the sources (meaning,
we will soon discover the ones that break and we can protect them with
-*- lexical-binding: nil -*-).

That has the advantadge that it wouldn't impact third-party code
unless the maintainters chose to add lexical-bindings to their
.dir-locals or their files.

    Juanma

Defaults for elisp-mode files

[Stephen J. Turnbull]

Stefan Monnier writes:

 > So I think in the longer term these annotations should be made
 > unnecessary because they're ugly.

`-*- coding: utf-8 -*-' should be unnecessary most of the time.  But

 > For the `utf-8', I guess we can simply set auto-coding-alist

I suppose you mean

    (set-coding-system-priority 'utf-8)

XEmacs can't set `auto-coding-list' because 'iso-2022-jp[1] has been
our standard for non-ASCII files since about 1999.  I mention this not
because compatibility is an issue here, but rather I suspect that
something similar, if unofficial, is true for Emacs.  Also, there's
probably a lot of historical user code, especially in init files, with
comments (which will be unreadable) and strings (functionality breaks
silently if they're used for matching auto-detected text) and
occasionally even identifiers in legacy encodings.

Legacy encodings (especially GB 2312, Shift JIS, and Big5 in my
experience, and I bet Russians and Ukrainians will say the same about
KOI8, etc) continue to be in heavy use on Windows and in email.

While you *can* set `auto-coding-alist', I think it will cause a lot
of pain.

 > But for the lexical-binding setting,

I think you have to live with that as long as for the foreseeable
future you're going to allow users to use implicit dynamic binding.
In other words, you shouldn't get rid of it until you actually
stop consulting the lexical-binding variable itself, and always use
lexical environments for non-special variables.

*Each* file really should contain a *prominent* statement about how
variables are evaluated, since the semantics differ.  Worse, the
semantics are determined by the *file*, not by Emacs.  That is, just
because Emacs changes its default, doesn't mean the developer will at
exactly the same time.  The developer working on the file needs that
indication.


Footnotes: 
[1]  What I really meant was iso-2022-int, but we didn't have it at
the time, and there's very little difference.  None that matters. :-)
Despite the "jp", in fact iso-2022-jp favors ASCII, not Japanese.

Re: Defaults for elisp-mode files

[Stefan Monnier]

>> For the `utf-8', I guess we can simply set auto-coding-alist
> I suppose you mean
>     (set-coding-system-priority 'utf-8)

No, I mean to set auto-coding-list so that .el files get read as utf-8.

> something similar, if unofficial, is true for Emacs.

I don't think so: if the file doesn't have a `coding:' cookie but has
significant non-ASCII chars in it, we usually sooner or later get bug
reports about it (because someone loaded the file in an locale where
the encoding ended up not recognized correctly).

So I suspect the main breakage will be in personal files (typically the
.emacs file) rather than in packages.

> While you *can* set `auto-coding-alist', I think it will cause a lot
> of pain.

We'll see ;-)


        Stefan

Re: Defaults for elisp-mode files

[Christopher Monsanto]

I think Juanma's dir-locals idea is a good one. But I would call them
"package-locals" instead. Many languages have a notion of package and
allow package specific settings, and now with package.el we also have
a notion of package...

Christopher Monsanto
chris@monsan.to  --  http://monsan.to/

Re: Defaults for elisp-mode files

[Juanma Barranquero]

On Thu, Oct 4, 2012 at 5:56 AM, Christopher Monsanto <chris@monsan.to> wrote:

> I think Juanma's dir-locals idea is a good one. But I would call them
> "package-locals" instead.

Well, it is already called .dir-locals. See node "48.2.5 Per-Directory
Local Variables" in the Emacs manual.

    Juanma

Re: Defaults for elisp-mode files

[Christopher Monsanto]

Hi Juanma,

I know what directory local variables are :) They are loaded when
emacs visits a file (that is, to be opened in a buffer), not when
opened by the Lisp load primitive. To do what you are wanting for
lexical-binding, we would have to instrument load to read directory
locals, but that seems strange because none of the variables normally
set in directory locals have relevance to the semantics of LIsp
programs. Which is why I would suggest introducing a new file for such
behavior, that the load function WOULD pick up, but wouldn't be
uselessly set when editing files in the package.

Christopher Monsanto
chris@monsan.to  --  http://monsan.to/

Re: Defaults for elisp-mode files

[Juanma Barranquero]

On Thu, Oct 4, 2012 at 5:37 PM, Christopher Monsanto <chris@monsan.to> wrote:

> I know what directory local variables are :)

:-)

> They are loaded when
> emacs visits a file (that is, to be opened in a buffer), not when
> opened by the Lisp load primitive. To do what you are wanting for
> lexical-binding, we would have to instrument load to read directory
> locals, but that seems strange because none of the variables normally
> set in directory locals have relevance to the semantics of LIsp
> programs.

Yes, I know, but the scaffolding is here. Introducing another
mechanism seems messier than expanding what we already have. Or not,
I'm not sure. Of course, I'm happily handwaving performance
considerations, etc., not to mention that adding that (be through
.dir-locals or another file) just for lexical-binding seems a bit
heavy handed.

But, if we have a (external-to-the-file) way to set variables for
editing files, why not for compiling them? In fact, we already mix
editing-time variables (like mode or tab-width) and compile-time
variables (byte-compile-dynamic, generated-autoload-file,
no-byte-compile, no-update-autoloads, lexical-binding itself) through
the same mechanism.

    Juanma

Re: Defaults for elisp-mode files

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

> But, if we have a (external-to-the-file) way to set variables for
> editing files, why not for compiling them? In fact, we already mix
> editing-time variables (like mode or tab-width) and compile-time
> variables (byte-compile-dynamic, generated-autoload-file,
> no-byte-compile, no-update-autoloads, lexical-binding itself) through
> the same mechanism.

You need to make sure that such settings are copied together with the
file when installing it somewhere else.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Defaults for elisp-mode files

[Juanma Barranquero]

On Thu, Oct 4, 2012 at 7:00 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:

>> variables (byte-compile-dynamic, generated-autoload-file,
>> no-byte-compile, no-update-autoloads, lexical-binding itself) through
>> the same mechanism.
>
> You need to make sure that such settings are copied together with the
> file when installing it somewhere else.

Yes, and no, I think. If you're copying an entire project, presumably
you would copy any .dir-locals (or .compilation-whatever-its-name).

But, if you're copying an elisp file to fork it or add it to another
project, many of these variables could change value easily, even
lexical-binding if you're adding it to a back-compatible package.
There's nothing really specific to a given elisp file in the
assignation of autoload file, or whether update autoloads or not, for
example; that's more likely project-specific. Some properties are on
the fence, like no-byte-compile (which usually depends more on the
size of the file that anything else) .

That it's not to say that my idea was particulary good, but if you
want, as Stefan wanted, to get rid of marking individually each file
for a given property, either you change the default (and resort to
marking the hopefully fewer files that so require it), or you add
metada externally to the files.

  Juanma

Re: Defaults for elisp-mode files

[Stephen J. Turnbull]

Christopher Monsanto writes:

 > programs. Which is why I would suggest introducing a new file for such
 > behavior, that the load function WOULD pick up, but wouldn't be
 > uselessly set when editing files in the package.

It's *not* useless.  emacs-lisp-mode needs to know about
lexical-binding in order to invoke `eval' correctly, at least.
Editing modes for programming languages usually have provisions for
invoking translators, so this kind of consideration is not necessarily
unique to Lisp.

Re: Defaults for elisp-mode files

[Stephen J. Turnbull]

Stefan Monnier writes:

 > No, I mean to set auto-coding-list so that .el files get read as utf-8.

I was afraid you meant that, but one can always hope. ;-)

 > I don't think so: if the file doesn't have a `coding:' cookie but has
 > significant non-ASCII chars in it, we usually sooner or later get bug
 > reports about it (because someone loaded the file in an locale where
 > the encoding ended up not recognized correctly).

Funny, that's another bug that just doesn't show up on XEmacs channels
that I know of.  The reason is simple: ISO-2022-JP is unambiguous and
very reliably detectable.[1]

Very occasionally somebody will ask for help with a 3rd party file.  I
explain about coding cookies and C-u C-x C-f ... C-x C-m f iso-2022-jp
and never hear from them about that again.

Of course, all of the above would be true of UTF-8.

 > > While you *can* set `auto-coding-alist', I think it will cause a lot
 > > of pain.
 > 
 > We'll see ;-)

You were warned. ;-)

Footnotes: 
[1]  At least in my experience.

Re: Defaults for elisp-mode files

[Andreas Röhler]

Am 03.10.2012 20:06, schrieb Stefan Monnier:
> I'm seeing more and more Elisp files with "-*- lexical-binding: t;
> coding: utf-8 -*-" showing up, and I expect them to become the norm in
> the longer term.
>
> So I think in the longer term these annotations should be made
> unnecessary because they're ugly.
> For the `utf-8', I guess we can simply set auto-coding-alist and we
> could do that right now without much risk for serious breakage (IOW
> I suggest we do that for the next release after 24.3).
>
> But for the lexical-binding setting, it seems less obvious how to handle
> such a switch (other than start warning any file which doesn't set it
> explicitly to t or nil, and after a while change the default, and after
> yet another while remove the warning, the whole process taking probably
> more than 10 years).  Any suggestion would be welcome.
>
>
>          Stefan
>
>

It's not nice, but obvious. Being in favour of the present state here.

Using  .dir-locals or other non-related locations would rather obfuscate than being useful.

Best,

Andreas