bug#16846: 24.3.50.1; Info 48.2.4.1 Specifying File Variables

bug#16846: 24.3.50.1; Info 48.2.4.1 Specifying File Variables

[Andreas Röhler]

48.2.4.1 Specifying File Variables

Doesn't mention the required ";;;" before, saying:

..................................

There are two ways to specify file local variable values: in the first
line, or with a local variables list.  Here's how to specify them in the
first line:

      -*- mode: MODENAME; VAR: VALUE; ... -*-

;;;;;;;;;

see also bug-report bug#16836

GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10) of 2014-02-19

bug#16846: 24.3.50.1; Info 48.2.4.1 Specifying File Variables

[Juanma Barranquero]

merge 16836 16846
quit


On Sat, Feb 22, 2014 at 9:11 PM, Andreas Röhler
<andreas.roehler@easy-emacs.de> wrote:
> 48.2.4.1 Specifying File Variables
>
> Doesn't mention the required ";;;" before, saying:

It's not that ";;;" is required. The line used to specify local
variables is usually a comment because presumably the file is to be
processed by some kind of program (a compiler or interpreter, for
program source files, for example).

If you start an elisp file with

-*- mode: emacs-lisp; tab-width: 4 -*-

Emacs will have no trouble understanding the variables. Edit the file
and you'll see that it is in emacs-lisp-mode and tab-width is 4. But
when you eval the buffer, as you did in your bug#16836 report, Emacs
complains that the line is not valid Elisp code.

> see also bug-report bug#16836

Why have you filed two bug reports for the same thing?

bug#16846: acknowledged by developer ()

[Andreas Röhler]

Am 22.02.2014 21:40, schrieb GNU bug Tracking System:
> This is an automatic notification regarding your bug report
> #16846: 24.3.50.1; Info 48.2.4.1 Specifying File Variables,
> which was filed against the emacs package.
>
> Thank you for your report, which has now been closed.
> You can view the full report at
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16846
>
> If you require further information, please followup to 16846@debbugs.gnu.org.
>
> debbugs.gnu.org maintainers
> (administrator, GNU bugs database)
>
>

re-open bug#16846

This bug is about Info files, the former report was about a wrong compiler warning.

bug#16846: acknowledged by developer ()

[Juanma Barranquero]

On Sat, Feb 22, 2014 at 9:50 PM, Andreas Röhler
<andreas.roehler@easy-emacs.de> wrote:

> This bug is about Info files

I don't think there is a bug. That info node talks about the format of
the file variables, but of course says nothing about the format of the
contents of your file. If your file is text, perhaps just

-*- variable: value -*-

in the first line is perfectly acceptable. If the file contains C
source code, or elisp, or another data format to be digested by some
external processor, it should already be clear that the file variables
must be acceptable to these external processors. You can't expect to
have

-*- mode: c -*-

as the first line of a C file and compile it with GCC without getting an error.

That said, the same node that you quote already says:

     Here is an example first line that specifies Lisp mode and sets two
  variables with numeric values:

       ;; -*- mode: Lisp; fill-column: 75; comment-column: 50; -*-

and a little later:

     In shell scripts, the first line is used to identify the script
  interpreter, so you cannot put any local variables there.  To
  accommodate this, Emacs looks for local variable specifications in the
  _second_ line if the first line specifies an interpreter.  The same is
  true for man pages which start with the magic string `'\"' to specify a
  list of troff preprocessors (not all do, however).

which clearly suggests that the file variables must also be acceptable
to the consumer of the file.

>, the former report was about a wrong compiler warning.

Which was, in fact, not wrong at all.

bug#16846: acknowledged by developer ()

[Andreas Röhler]

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

Am 22.02.2014 23:43, schrieb Juanma Barranquero:
> On Sat, Feb 22, 2014 at 9:50 PM, Andreas Röhler
> <andreas.roehler@easy-emacs.de> wrote:
>
>> This bug is about Info files
>
> I don't think there is a bug. That info node talks about the format of
> the file variables, but of course says nothing about the format of the
> contents of your file. If your file is text, perhaps just
>
> -*- variable: value -*-
>
> in the first line is perfectly acceptable.


Do you want  file-local variables restrict to text-mode?
Doesn't make sense for me.


  If the file contains C
> source code, or elisp, or another data format to be digested by some
> external processor, it should already be clear that the file variables
> must be acceptable to these external processors. You can't expect to
> have
>
> -*- mode: c -*-
>
> as the first line of a C file and compile it with GCC without getting an error.
>

We must not discuss possible other bugs here. Let's stay with the reported one.

> That said, the same node that you quote already says:
>
>       Here is an example first line that specifies Lisp mode and sets two
>    variables with numeric values:
>
>         ;; -*- mode: Lisp; fill-column: 75; comment-column: 50; -*-
>
> and a little later:
>
>       In shell scripts, the first line is used to identify the script
>    interpreter, so you cannot put any local variables there.  To
>    accommodate this, Emacs looks for local variable specifications in the
>    _second_ line if the first line specifies an interpreter.  The same is
>    true for man pages which start with the magic string `'\"' to specify a
>    list of troff preprocessors (not all do, however).
>
> which clearly suggests that the file variables must also be acceptable
> to the consumer of the file.

It rather says: implementation is not that straightforward as it could/should be.
It's at Emacs, when sending code, to clear its artistics before.

>
>> , the former report was about a wrong compiler warning.
>
> Which was, in fact, not wrong at all.
>

Attach foo1.png - happens when evaluating a buffer with contents:

;;;;;;


-*- lexical-binding: t -*-

(setq foo 1)

;;;;;;


[-- Attachment #2: foo1.png --]
[-- Type: image/png, Size: 48359 bytes --]

bug#16846: acknowledged by developer ()

[Juanma Barranquero]

On Sun, Feb 23, 2014 at 9:49 AM, Andreas Röhler
<andreas.roehler@easy-emacs.de> wrote:

> Do you want  file-local variables restrict to text-mode?

That's a non sequitur.

> We must not discuss possible other bugs here. Let's stay with the reported
> one.

I see no bug. Neither the "possible other" nor the reported one.

> It rather says: implementation is not that straightforward as it
> could/should be.

It says nothing of the sort. It says: an elisp file with file
variables should still be an elisp file, a C one still has to have C
syntax, etc.

> It's at Emacs, when sending code, to clear its artistics before.

And, somehow, if you have a C file edited with Emacs and having a file
variable line, Emacs is to somehow know when you're about to compile
that file (outside Emacs) and "clear its artistics". Sorry, but it
makes no sense.

> Attach foo1.png - happens when evaluating a buffer with contents:
>
> ;;;;;;
>
>
> -*- lexical-binding: t -*-
>
> (setq foo 1)
>
> ;;;;;;

I still see no bug.

The way it works makes sense, and it's how it has worked for years. If
you want to file a bug report about the info node not being clear
enough of the obvious need to put the file variables in a comment or
another suitable way to protect them from the file content's consumer,
please suit yourself. But the behavior that you're suggesting, that
somehow Emacs should remove the file variables before passing it (to
the Elisp interpreter or anywhere else) is not going to be
implemented.

   J

bug#16846: acknowledged by developer ()

[Andreas Röhler]

Am 23.02.2014 12:07, schrieb Juanma Barranquero:

>> Attach foo1.png - happens when evaluating a buffer with contents:
>>
>> ;;;;;;
>>
>>
>> -*- lexical-binding: t -*-
>>
>> (setq foo 1)
>>
>> ;;;;;;
>
> I still see no bug.
>
> The way it works makes sense, and it's how it has worked for years.

  It works but sends an error.
Sending the error upon working code is a bug.

Or you say: a single file local setting needs to be commented, more of them not.

If a comment is needed, it's a docu-bug.

bug#16846: acknowledged by developer ()

[Juanma Barranquero]

On Mon, Feb 24, 2014 at 1:49 PM, Andreas Röhler
<andreas.roehler@easy-emacs.de> wrote:

>  It works but sends an error.

As it would if you instead of

  -*- variable: value -*-

put

  This line is here just to mess with the interpreter

So, if you don't want to mess with the program that process the file,
follow the file's intended conventions. Nothing to do with file
variables.

> Sending the error upon working code is a bug.

No, its not. That line is not valid elisp.

> Or you say: a single file local setting needs to be commented, more of them
> not.

Sorry, I don't understand you.

> If a comment is needed, it's a docu-bug.

As I already said, if you think the info manual needs to be more
explicit about the implicit (but obvious) need to respect the
conventions of the kind of file you're writing (whether source code,
or any other kind), please file a bug report saying so.

bug#16846: acknowledged by developer ()

[Andreas Röhler]

Am 24.02.2014 13:50, schrieb Juanma Barranquero:
> On Mon, Feb 24, 2014 at 1:49 PM, Andreas Röhler
> <andreas.roehler@easy-emacs.de> wrote:
>
>>   It works but sends an error.
>
> As it would if you instead of
>
>    -*- variable: value -*-
>
> put
>
>    This line is here just to mess with the interpreter
>
> So, if you don't want to mess with the program that process the file,
> follow the file's intended conventions. Nothing to do with file
> variables.

Please tell me, what's the difference between this example and the one given in the info:


      -*- mode: MODENAME; VAR: VALUE; ... -*-

beside specified just one?

>
>> Sending the error upon working code is a bug.
>
> No, its not. That line is not valid elisp.
>
>> Or you say: a single file local setting needs to be commented, more of them
>> not.
>
> Sorry, I don't understand you.
>
>> If a comment is needed, it's a docu-bug.
>
> As I already said, if you think the info manual needs to be more
> explicit about the implicit (but obvious) need to respect the
> conventions of the kind of file you're writing (whether source code,
> or any other kind), please file a bug report saying so.
>

This was done with #16846

bug#16846: acknowledged by developer ()

[Nicolas Richard]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>> -*- lexical-binding: t -*-
>  It works but sends an error.
> Sending the error upon working code is a bug.

It might help if you say why do you write the line "-*- lexical-binding:
t -*-", and in particular why you did not add comment syntax (i.e. semi
colons) at the beginning of it. What doc did you read that lead you to
write that ?

> Or you say: a single file local setting needs to be commented, more of them not.
>
> If a comment is needed, it's a docu-bug.

I might indeed suggest that in
(info "(elisp) Using Lexical Binding")
a direct xref to
(info "(emacs) Specifying File Variables")
could help to know what "first line" means in that context, because it's
not obvious from the elisp manual itself.

-- 
Nico.

bug#16846: acknowledged by developer ()

[Andreas Röhler]

Am 24.02.2014 14:41, schrieb Nicolas Richard:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>>> -*- lexical-binding: t -*-
>>   It works but sends an error.
>> Sending the error upon working code is a bug.
>
> It might help if you say why do you write the line "-*- lexical-binding:
> t -*-",

Just an example here, want lexical-binding in buffer.

and in particular why you did not add comment syntax (i.e. semi
> colons) at the beginning of it. What doc did you read that lead you to
> write that ?
>

I'm referring to:

48.2.4.1 Specifying File Variables
..................................

There are two ways to specify file local variable values: in the first
line, or with a local variables list.  Here's how to specify them in the
first line:

      -*- mode: MODENAME; VAR: VALUE; ... -*-

You can specify any number of variable/value pairs in this way, each
pair with a colon and semicolon.

;;;;;;;


BTW left out the semicolon as understood it's to separate pairs.
The error

Symbol's value as variable is void: -*-

is signaled too with semicolon added.

bug#16846: acknowledged by developer ()

[Nicolas Richard]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> Am 24.02.2014 14:41, schrieb Nicolas Richard:
>> and in particular why you did not add comment syntax (i.e. semi
>> colons) at the beginning of it. What doc did you read that lead you to
>> write that ?
>>
>
> I'm referring to:
>
> 48.2.4.1 Specifying File Variables

That part of the doc doesn't say that you shouldn't write anything else
on that line. In particular, you should at least make that line valid in
the context of that file (e.g. make it a comment if it's a programming
language). Using M-x add-file-local-variable-prop-line, which is
suggested in the doc, should do that for you in most modes (and does for
emacs-lisp).

> BTW left out the semicolon as understood it's to separate pairs.

I meant semicolons at the beginning of line, i.e. to turn the line into
a comment.

-- 
Nico.

bug#16846: acknowledged by developer ()

[Andreas Röhler]

Am 24.02.2014 17:06, schrieb Nicolas Richard:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>> Am 24.02.2014 14:41, schrieb Nicolas Richard:
>>> and in particular why you did not add comment syntax (i.e. semi
>>> colons) at the beginning of it. What doc did you read that lead you to
>>> write that ?
>>>
>>
>> I'm referring to:
>>
>> 48.2.4.1 Specifying File Variables
>
> That part of the doc doesn't say that you shouldn't write anything else
> on that line.

It formulates a general example which isn't general. It's misleading.

A better start would be the Emacs Lisp example below, followed by a hint WRT to plain text-modes.

bug#16846: [debbugs-tracker] Processed: your mail

[Glenn Morris]

GNU bug tracker automated control server wrote:

> Processing commands for control@debbugs.gnu.org:
>
>> reopen 16836
>> merge 16836 16846
>> close 16836

aka:

forcemerge 16836 16846