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