From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: #+bind: org-html-preamble Date: Thu, 04 Apr 2013 15:58:49 +0200 Message-ID: <874nfmv1ly.fsf@bzg.ath.cx> References: <87ip4aqs71.fsf@duenenhof-wilhelm.de> <87vc8awebo.fsf@gmail.com> <878v56qrl2.fsf@duenenhof-wilhelm.de> <87r4iywdrs.fsf@gmail.com> <87sj365v4n.fsf@bzg.ath.cx> <87ip42xvyi.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:39218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNkhC-0005AD-Ah for emacs-orgmode@gnu.org; Thu, 04 Apr 2013 09:59:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNkgm-00072j-GH for emacs-orgmode@gnu.org; Thu, 04 Apr 2013 09:59:18 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:46224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNkgm-00072Q-8c for emacs-orgmode@gnu.org; Thu, 04 Apr 2013 09:58:52 -0400 Received: by mail-wg0-f43.google.com with SMTP id f12so2657892wgh.34 for ; Thu, 04 Apr 2013 06:58:51 -0700 (PDT) In-Reply-To: <87ip42xvyi.fsf@gmail.com> (Nicolas Goaziou's message of "Thu, 04 Apr 2013 15:32:37 +0200") 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: Nicolas Goaziou Cc: Dieter Wilhelm , emacs-orgmode@gnu.org Hi Nicolas, Nicolas Goaziou writes: > Bastien writes: > >> Hi Nicolas, >> >> Nicolas Goaziou writes: >> >>> It is replacing old `org-export-allow-BIND' (note that they do not share >>> the same set of possible values). >> >> Is there a reason for not allowing 'confirm? > > Yes. It is a pain in the neck to implement, and not vital since you can > specify it as a buffer-local variable anyway. But it *was* implemented? If re-using the previous implementation is not a pain in the neck, I'd favor re-using it. >> Also, I'd rather stick to the old name since it is good enough >> and will spare many users with the hassle of finding out how to >> correctly set the new variable, which is very sensitive. > > It isn't sensitive: it defaults to nil. Therefore a user unable to find > it is still safe. Moreover, it will be documented, won't it? See below. >> What do you think? > > I didn't like gratuitous caps in the old name. I prefer the new one. > Other than dubious aesthetics reason, I don't mind its name. I'd like to re-use the old name. I don't like gratuitous caps in variable names too, but here they directly refer to the normal appearance of #+BIND. If we re-introduce the old name, whether it defaults to nil or not will potentially break users configuration, since a 'confirm value will either throw an error or (more dangerously) be interpreted as t. So, if we can re-use the old implementation and the old name, I'm for it as it is more flexible. -- Bastien