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