From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: [RFC] [PATCH] allow bind keywords to set safe values Date: Sat, 07 Nov 2015 12:40:06 +0000 Message-ID: <87lhaat23d.fsf@gmail.com> References: <8737wjuhif.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv2my-0001L5-R0 for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 07:40:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zv2mv-0007Ej-Kf for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 07:40:12 -0500 Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:33301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv2mv-0007Ed-EI for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 07:40:09 -0500 Received: by wmec201 with SMTP id c201so38161691wme.0 for ; Sat, 07 Nov 2015 04:40:08 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Thomas S. Dye" Cc: orgmode Hi Thomas, 2015ko azaroak 6an, "Thomas S. Dye"-ek idatzi zuen: >=20 > Aloha Aaron, >=20 > Aaron Ecay writes: >=20 >> Hello all, >>=20 >> BIND keywords should be used for controlling export, rather than the >> usual emacs method of setting file local variables >> . But, >> BIND keywords are currently disabled by default. We can=E2=80=99t turn = these on >> by default, as maliciously crafted documents could do nasty things to a >> user=E2=80=99s emacs. The attached patch permits many interesting usage= s of >> BIND keywords by allowing them to set variables by default, as long as >> the value thus set is safe (as implemented by emacs=E2=80=99s default fi= le local >> variable code). >=20 > 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. >=20 > I'm not complaining, just commenting on an unusual sequence of events on > the mailing list.=20=20 >=20 > 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=E2=80=99s async export, the clone is made in another emacs process. There=E2=80=99s a concern that some time in this process, local variable li= nes could be lost. This could happen because: - hack-local-variables doesn=E2=80=99t get called when it should - the lines themselves are deleted (because of being in a COMMENT or noexport subtree) BIND keywords don=E2=80=99t rely on hack-local-variables, and would typical= ly be located in the preamble of the document. So they should be immune to these factors. There=E2=80=99s 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=E2=80=99m 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=E2=80=99t reach 100% certainty. It would be better (more reassuri= ng) if someone could reach that level of certainty. Then we could tell people that it doesn=E2=80=99t matter whether they use BIND or a local vari= able (which is what I wish I could say to you now). If you=E2=80=99ve used local variables and are happy with how they have wor= ked I think nothing bad will happen if you leave them as is. But that=E2=80=99s = just, like, my opinion man. >=20 > 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. >=20 > 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=E2=80=99ll do my best! Thanks for the kind words. --=20 Aaron Ecay