File local variables

File local variables

[Vikas Rawal]

I used to disable evaluation of source code when exporting by using the following as the first line:

;; -*- mode: Org; org-export-babel-evaluate: nil; -*-

This is not working any more. Has something changed?

My org-version is: Org-mode version 8.3beta (release_8.3beta-614-gc10ae1 @ /Users/vikas/.emacs.d/src/org-mode/lisp/)

Vikas

Re: File local variables

[Vikas Rawal]

> I used to disable evaluation of source code when exporting by using the following as the first line:
> 
> ;; -*- mode: Org; org-export-babel-evaluate: nil; -*-
> 
> This is not working any more. Has something changed?
> 
> My org-version is: Org-mode version 8.3beta (release_8.3beta-614-gc10ae1 @ /Users/vikas/.emacs.d/src/org-mode/lisp/)
> 
> Vikas

I think this is a bug. Could somebody confirm.

The following line shows up in the Latex export.

; -*- mode: org; org-export-babel-evaluate: nil -*-

Vikas

Re: File local variables

[Aaron Ecay]

Hi Vikas,

2014ko abenudak 11an, Vikas Rawal-ek idatzi zuen:
> 
>> I used to disable evaluation of source code when exporting by using the following as the first line:
>> 
>> ;; -*- mode: Org; org-export-babel-evaluate: nil; -*-
>> 
>> This is not working any more. Has something changed?
>> 
>> My org-version is: Org-mode version 8.3beta (release_8.3beta-614-gc10ae1 @ /Users/vikas/.emacs.d/src/org-mode/lisp/)
>> 
>> Vikas
> 
> I think this is a bug. Could somebody confirm.

I can’t confirm, in the sense that including that line in a file sets
the buffer-local value of org-export-babel-evaluate to nil.

If that variable isn’t having the effect of suppressing evaluation, that
sounds like a bug, but it’s not clear that that is what is going on.
Can you send an ECM?

> 
> The following line shows up in the Latex export.
> 
> ; -*- mode: org; org-export-babel-evaluate: nil -*-

That is because ; is the comment syntax for (e)lisp.  You probably want
to begin the line with # instead.

-- 
Aaron Ecay

Re: File local variables

[Kyle Meyer]

Aaron Ecay <aaronecay@gmail.com> wrote:
> 2014ko abenudak 11an, Vikas Rawal-ek idatzi zuen:
>>> I used to disable evaluation of source code when exporting by using
>>> the following as the first line:
[...]
>> I think this is a bug. Could somebody confirm.
>
> I can’t confirm, in the sense that including that line in a file sets
> the buffer-local value of org-export-babel-evaluate to nil.
>
> If that variable isn’t having the effect of suppressing evaluation,
> that sounds like a bug, but it’s not clear that that is what is going
> on.  Can you send an ECM?

I can't confirm this either (using the following text).

,----
| # -*- org-export-babel-evaluate: nil; -*-
|
| #+begin_src emacs-lisp :exports both
|   (message "Evaluating?")
| #+end_src
|
| #+RESULTS:
| : Evaluating?
`----

'C-h v' indicates that the buffer-local value is indeed set to nil.

The only place the value of org-export-babel-evaluate is checked is
org-babel-exp-results.  Exporting the example above with
org-babel-exp-results edebugged shows that the main body of that
function doesn't execute.  So, the code isn't being evaluated at export,
unless it's happening elsewhere.

How are you checking that the code is evaluated at export?

--
Kyle

Re: File local variables

[Vikas Rawal]

>> 
>> I can’t confirm, in the sense that including that line in a file sets
>> the buffer-local value of org-export-babel-evaluate to nil.
>> 
>> If that variable isn’t having the effect of suppressing evaluation,
>> that sounds like a bug, but it’s not clear that that is what is going
>> on.  Can you send an ECM?
> 
> I can't confirm this either (using the following text).
> 
> ,----
> | # -*- org-export-babel-evaluate: nil; -*-
> |
> | #+begin_src emacs-lisp :exports both
> |   (message "Evaluating?")
> | #+end_src
> |
> | #+RESULTS:
> | : Evaluating?
> `----


Thanks Aaron and Kyle.

I perhaps confused the fact that the line which started with a ; was showing up in the export to understand that the line was not being treated as it should.

But in my earlier org files, I always started this line with a ; and it used to work fine. Perhaps (perhaps), the behaviour has changed in terms of not treating lines starting with ; as comments in org.

Be that as it may, starting the line with a # works.

Thanks again,

Vikas

file local variables

[Francesc Rocher]

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

Hi,

File local variables doesn't work as expected. If you 'emacs -Q' a file with

Local Variables:
mode: text
mode: auto-fill
End:

or with any other combination of a major and a minor mode, then the major
mode is ignored. Is this a bug? This works fine with emacs-23.1, where both
modes are activated...

-- rocher

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

Re: file local variables

[Juri Linkov]

> File local variables doesn't work as expected. If you 'emacs -Q' a file with
>
> Local Variables:
> mode: text
> mode: auto-fill
> End:
>
> or with any other combination of a major and a minor mode, then the major
> mode is ignored. Is this a bug? This works fine with emacs-23.1, where both
> modes are activated...

(info "(emacs) Specifying File Variables") says:

     You can use the `mode' "variable" to set minor modes as well as the
  major modes; in fact, you can use it more than once, first to set the
  major mode and then to set minor modes which are specific to particular
  buffers.  But most minor modes should not be specified in the file at
  all, because they represent user preferences.

Since the user should be able to specify minor modes more than once,
the following patch fixes this by allowing duplicate modes:

=== modified file 'lisp/files.el'
--- lisp/files.el	2009-11-25 17:11:29 +0000
+++ lisp/files.el	2009-12-14 21:28:58 +0000
@@ -2978,8 +2978,8 @@
 		 (or (eq enable-local-eval t)
 		     (hack-one-local-variable-eval-safep (eval (quote val)))
 		     (push elt unsafe-vars))))
-	      ;; Ignore duplicates in the present list.
-	      ((assq var all-vars) nil)
+	      ;; Ignore duplicates (except `mode') in the present list.
+	      ((and (assq var all-vars) (not (eq var 'mode))) nil)
 	      ;; Accept known-safe variables.
 	      ((or (memq var '(mode unibyte coding))
 		   (safe-local-variable-p var val))
@@ -2999,7 +2999,7 @@
 	     (hack-local-variables-confirm all-vars unsafe-vars
 					   risky-vars dir-name))
 	 (dolist (elt all-vars)
-	   (unless (eq (car elt) 'eval)
+	   (unless (memq (car elt) '(eval mode))
 	     (unless dir-name
 	       (setq dir-local-variables-alist
 		     (assq-delete-all (car elt) dir-local-variables-alist)))
@@ -3427,7 +3427,7 @@
 		(dir-locals-get-class-variables class) dir-name nil)))
 	  (when variables
 	    (dolist (elt variables)
-	      (unless (eq (car elt) 'eval)
+	      (unless (memq (car elt) '(eval mode))
 		(setq dir-local-variables-alist
 		      (assq-delete-all (car elt) dir-local-variables-alist)))
 	      (push elt dir-local-variables-alist))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: file local variables

[Francesc Rocher]

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

> Since the user should be able to specify minor modes more than once,
> the following patch fixes this by allowing duplicate modes:
>


Thanks,  your patch works fine.

-- Rocher

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

Re: file local variables

[Juri Linkov]

BTW, while looking at this bug, I noticed a security hole in using
duplicate file local variables.

`hack-local-variables-filter' checks for the safety the value of the *last*
duplicate local variable in the list (the first in the reversed list), but
`hack-local-variables' uses an unchecked value of the *first* duplicate
local variable.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: file local variables

[Juri Linkov]

> BTW, while looking at this bug, I noticed a security hole in using
> duplicate file local variables.
>
> `hack-local-variables-filter' checks for the safety the value of the *last*
> duplicate local variable in the list (the first in the reversed list), but
> `hack-local-variables' uses an unchecked value of the *first* duplicate
> local variable.

Hopefully, this is a false alarm.  I can't find a recipe to reproduce this.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: file local variables

[Juri Linkov]

>> BTW, while looking at this bug, I noticed a security hole in using
>> duplicate file local variables.
>>
>> `hack-local-variables-filter' checks for the safety the value of the *last*
>> duplicate local variable in the list (the first in the reversed list), but
>> `hack-local-variables' uses an unchecked value of the *first* duplicate
>> local variable.
>
> Hopefully, this is a false alarm.  I can't find a recipe to reproduce this.

Sometimes it's even more safe than necessary.  When .dir-locals.el
contains a variable with an unsafe value, but file-local variables contain
a safe value of the same variable, it asks confirmation for the unsafe
directory-local value, but really uses the safe file-local variable's value.

I think this is not a problem.  It seems better to remind the user that
.dir-locals.el contains an unsafe value.

-- 
Juri Linkov
http://www.jurta.org/emacs/