[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Aaron Ecay
Subject: Re: [O] [RFC] [PATCH] allow bind keywords to set safe values
Date: Sat, 07 Nov 2015 12:40:06 +0000
User-agent: Notmuch/0.20.2+65~gbd5504e (http://notmuchmail.org) Emacs/ (x86_64-unknown-linux-gnu)

Hi Thomas,

2015ko azaroak 6an, "Thomas S. Dye"-ek idatzi zuen:
> Aloha Aaron,
> Aaron Ecay <address@hidden> 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/address@hidden>.  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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]