Re: Local variables

[Daniel Clemente <n142857@gmail.com>]

Thank you very much.
I am forwarding your response also to the mailing list.

--Daniel


El dc, ago 05 2009 a les 16:32, Carsten Dominik va escriure:
> On Aug 5, 2009, at 12:39 PM, Daniel Clemente wrote:
>
>>
>> Hi,
>>
>> El dt, ago 04 2009 a les 23:15, Carsten Dominik va escriure:
>>> General mechanism for local variable settings
>>> ==============================================
>>> …
>>>
>>> A line like:
>>>
>>>  #+BIND: variable value
>>>
>>>
>>> will bind the variable to value.  For example, the line
>>> …
>>
>>
>> 1. That's very useful and makes .org file distribution much easier since
>> configuration is self-contained. Thanks.
>>
>> 2. I find that it doesn't work. For instance, this buffer
>>
>> ---------
>> #+BIND: org-export-with-section-numbers nil
>>
>> * one
>> something
>> ---------
>>
>> and this one:
>> ---------
>> #+BIND: org-export-with-section-numbers t
>>
>> * one
>> something
>> ---------
>>
>>  Export the same content, with section numbers. Only with this:
>> #+OPTIONS: num:nil
>>  can I export without section numbers.
>>
>>  Running org 6.29a on latest Emacs from CVS from today. I get no other error
>> messages.
>
> This was a bug, fixed, thanks.
>
>>
>> 3. I found it created one problem with custom time dates. I can't export this
>> buffer:
>> --------
>> #+STARTUP: customtime
>> #+BIND: org-time-stamp-custom-formats '("<%d.m%m.%Y>" . "<%d.m%m.%Y %H:%M>")
>> # (setq org-time-stamp-custom-formats '("<%d.m%m.%Y>" . "<%d.m%m.%Y %H:%M>"))
>
> in #+BIND, the value should not be quoted, it will not be evaluated like it
> would in
> a setq form.  So you need:
>
> #+BIND: org-time-stamp-custom-formats ("<%d.m%m.%Y>" . "<%d.m%m.%Y %H:
> %M>")
>
>>
>> a date:
>>
>> <2006-03-25 sáb>
>> --------
>>
>>  It fails with:
>>
>> Debugger entered--Lisp error: (wrong-type-argument arrayp quote)
>>  substring(quote 1 -1)
>>  (concat (if inactive "[" "<") (substring tf 1 -1) (if inactive "]" ">"))
>>  (format-time-string (concat (if inactive "[" "<") (substring tf 1 -1) (if
>> inactive "]" ">")) (apply (quote encode-time) time))
>> …
>>  org-translate-time(#("<2006-03-25 s\x00e1\ b>" 0 1 (fontified t) 1 2
>> (fontified t display #("25.m03.2006" 0 11 ...)) 2 3 (fontified t  org-dwidth t
>> org-dwidth-n 3 display #("25.m03.2006" 0 11 ...)) 3 15  (fontified t display
>> #("25.m03.2006" 0 11 ...)) 15 16 (fontified t  rear-nonsticky (mouse-face
>> highlight keymap invisible intangible  help-echo org-linked-text))))
>>
>>
>>  It fails only if I have that #+BIND line.
>>  You may eval or not the (setq), as needed; it's there only to test.
>>
>>
>>
>> 4. Being able to change any variable is dangerous. „Local variables“ in Emacs
>> have a confirmation dialog which asks whether you really  want to change them;
>> org may need something similar if it  reimplements local variables.
>>   Restricting changes to variables whose name is org-.* probably doesn't
>> prevent code execution, and anyway the good thing about # +BIND: is being able
>> to change anything. So maybe a confirmation  dialog can be used, or a switch.
>
> Yes, #+BIND might in principle open the possibility to execute
> code and in this way is a security risk.  Org-mode files as virus vectors.
> There are other, similar issues with executable code in org-eval.el,
> and with shell links, for example.
>
> I am not sure what the right course of a action is here.
>
> The most important thing is of course to only open Org files from
> trusted sources in Emacs.
>
> I guess we could use a switch . . . I have now implemented one.
> You need to confirm using BIND for each buffer that wants it,
> or you can configure the variable org-export-allow-BIND to
> allow them always, on your own risk.
>
> - Carsten