Re: #+bind: org-html-preamble

[Bastien <bzg@altern.org>]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Bastien <bzg@altern.org> writes:
>
>> Hi Nicolas,
>>
>> Nicolas Goaziou <n.goaziou@gmail.com> 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