all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* file local variables
@ 2009-12-14 18:24 Francesc Rocher
  2009-12-14 21:29 ` Juri Linkov
  2009-12-14 21:34 ` Juri Linkov
  0 siblings, 2 replies; 11+ messages in thread
From: Francesc Rocher @ 2009-12-14 18:24 UTC (permalink / raw)
  To: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: file local variables
  2009-12-14 18:24 file " Francesc Rocher
@ 2009-12-14 21:29 ` Juri Linkov
  2009-12-14 22:26   ` Francesc Rocher
  2009-12-14 21:34 ` Juri Linkov
  1 sibling, 1 reply; 11+ messages in thread
From: Juri Linkov @ 2009-12-14 21:29 UTC (permalink / raw)
  To: Francesc Rocher; +Cc: emacs-devel

> 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/




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: file local variables
  2009-12-14 18:24 file " Francesc Rocher
  2009-12-14 21:29 ` Juri Linkov
@ 2009-12-14 21:34 ` Juri Linkov
  2009-12-14 23:39   ` Juri Linkov
  1 sibling, 1 reply; 11+ messages in thread
From: Juri Linkov @ 2009-12-14 21:34 UTC (permalink / raw)
  To: emacs-devel

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/




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: file local variables
  2009-12-14 21:29 ` Juri Linkov
@ 2009-12-14 22:26   ` Francesc Rocher
  0 siblings, 0 replies; 11+ messages in thread
From: Francesc Rocher @ 2009-12-14 22:26 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: file local variables
  2009-12-14 21:34 ` Juri Linkov
@ 2009-12-14 23:39   ` Juri Linkov
  2009-12-15  0:20     ` Juri Linkov
  0 siblings, 1 reply; 11+ messages in thread
From: Juri Linkov @ 2009-12-14 23:39 UTC (permalink / raw)
  To: emacs-devel

> 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/




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: file local variables
  2009-12-14 23:39   ` Juri Linkov
@ 2009-12-15  0:20     ` Juri Linkov
  0 siblings, 0 replies; 11+ messages in thread
From: Juri Linkov @ 2009-12-15  0:20 UTC (permalink / raw)
  To: emacs-devel

>> 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/




^ permalink raw reply	[flat|nested] 11+ messages in thread

* File local variables
@ 2014-12-08 10:03 Vikas Rawal
  2014-12-12  4:51 ` Vikas Rawal
  0 siblings, 1 reply; 11+ messages in thread
From: Vikas Rawal @ 2014-12-08 10:03 UTC (permalink / raw)
  To: org-mode mailing list

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File local variables
  2014-12-08 10:03 File local variables Vikas Rawal
@ 2014-12-12  4:51 ` Vikas Rawal
  2014-12-12  5:01   ` Aaron Ecay
  0 siblings, 1 reply; 11+ messages in thread
From: Vikas Rawal @ 2014-12-12  4:51 UTC (permalink / raw)
  To: org-mode mailing list



> 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File local variables
  2014-12-12  4:51 ` Vikas Rawal
@ 2014-12-12  5:01   ` Aaron Ecay
  2014-12-12  6:32     ` Kyle Meyer
  0 siblings, 1 reply; 11+ messages in thread
From: Aaron Ecay @ 2014-12-12  5:01 UTC (permalink / raw)
  To: Vikas Rawal, org-mode mailing list

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File local variables
  2014-12-12  5:01   ` Aaron Ecay
@ 2014-12-12  6:32     ` Kyle Meyer
  2014-12-12  6:33       ` Vikas Rawal
  0 siblings, 1 reply; 11+ messages in thread
From: Kyle Meyer @ 2014-12-12  6:32 UTC (permalink / raw)
  To: Vikas Rawal; +Cc: org-mode mailing list

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File local variables
  2014-12-12  6:32     ` Kyle Meyer
@ 2014-12-12  6:33       ` Vikas Rawal
  0 siblings, 0 replies; 11+ messages in thread
From: Vikas Rawal @ 2014-12-12  6:33 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: org-mode mailing list

>> 
>> 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2014-12-12  6:33 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-08 10:03 File local variables Vikas Rawal
2014-12-12  4:51 ` Vikas Rawal
2014-12-12  5:01   ` Aaron Ecay
2014-12-12  6:32     ` Kyle Meyer
2014-12-12  6:33       ` Vikas Rawal
  -- strict thread matches above, loose matches on Subject: below --
2009-12-14 18:24 file " Francesc Rocher
2009-12-14 21:29 ` Juri Linkov
2009-12-14 22:26   ` Francesc Rocher
2009-12-14 21:34 ` Juri Linkov
2009-12-14 23:39   ` Juri Linkov
2009-12-15  0:20     ` Juri Linkov

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.