[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/25.0.50.2 (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