Re: [RFC] [PATCH] allow bind keywords to set safe values

[Aaron Ecay <aaronecay@gmail.com>]

Hi Thomas,

2015ko azaroak 6an, "Thomas S. Dye"-ek idatzi zuen:
> 
> Aloha Aaron,
> 
> Aaron Ecay <aaronecay@gmail.com> writes:
> 
>> Hello all,
>> 
>> BIND keywords should be used for controlling export, rather than the
>> usual emacs method of setting file local variables
>> <http://mid.gmane.org/87eglcbv7g.fsf@selenimh.access.network>.  But,
>> BIND keywords are currently disabled by default.  We can’t turn these on
>> by default, as maliciously crafted documents could do nasty things to a
>> user’s emacs.  The attached patch permits many interesting usages of
>> BIND keywords by allowing them to set variables by default, as long as
>> the value thus set is safe (as implemented by emacs’s default file local
>> variable code).
> 
> The prescription that BIND keywords should be used over local variables
> caught me by surprise.  Nicolas' post about a vague recollection that
> some local variables might not be picked up during export seems an odd
> motivation for the prescription.  I've used local variables to control
> export for a long time without running into this problem.
> 
> I'm not complaining, just commenting on an unusual sequence of events on
> the mailing list.  
> 
> I'm happy to migrate my local variables to BIND if that is what I should
> do.

The export process is complicated, involving at least one clone being
made of the org buffer.  If it’s async export, the clone is made in
another emacs process.

There’s a concern that some time in this process, local variable lines
could be lost.  This could happen because:
- hack-local-variables doesn’t get called when it should
- the lines themselves are deleted (because of being in a COMMENT or
  noexport subtree)
BIND keywords don’t rely on hack-local-variables, and would typically be
located in the preamble of the document.  So they should be immune to
these factors.  There’s also an issue with #+INCLUDE keywords, which
will bring in BINDs from the included file, but (AFAICS) not local
variable lines.

I tried to take a look at the export code.  I’m 99% certain that any
local variables with the org- prefix will be successfully maintained at
all relevant steps of the export process.  But the code is complex, and
I couldn’t reach 100% certainty.  It would be better (more reassuring)
if someone could reach that level of certainty.  Then we could tell
people that it doesn’t matter whether they use BIND or a local variable
(which is what I wish I could say to you now).

If you’ve used local variables and are happy with how they have worked I
think nothing bad will happen if you leave them as is.  But that’s just,
like, my opinion man.

> 
> That said, it would be great if one could use EXPORT_BIND to control
> export at the subtree export level.  I'm keeping separate HTML and LaTeX
> export projects in the same file fairly often now and it can be
> difficult (for me) to structure the whole file properly so both exports
> work as expected.

This is an excellent idea IMO.

> 
> BTW, many thanks for your recent interest in and work on Babel.  It is
> an important part of my work flow and I've been uneasy since Eric
> orphaned the project a while back.  I hope you find the work there
> rewarding enough to keep up.

I’ll do my best!  Thanks for the kind words.

-- 
Aaron Ecay