Dear Nicolas, On Oct 21, 2013, at 5:15 PM, Nicolas Goaziou <n.goaz...@gmail.com> wrote:
> Carsten Dominik <carsten.domi...@gmail.com> writes: > >> The documentation of defconst says: >> >>> Define SYMBOL as a constant variable. >>> This declares that neither programs nor users should ever change the >>> value. This constancy is not actually enforced by Emacs Lisp, but >>> SYMBOL is marked as a special variable so that it is never lexically >>> bound. >> >> So it is pretty clear about the intent of such a definition, which is >> to never change it - even though it does not enforce it. > > I must have been clear as mud, because that's exactly what I'm > suggesting since the beginning of this thread: set "DEADLINE" and al. in > stone, and never change them again. You also said things like > That's exactly the point of the defconst: you can still modify the > variable, but it sends a strong message to the user. Also, it's not > about deprecation: code base should still rely on these variables. so maybe I picked one interpretation over the other. > > I have been pointing out, though, that it would not break previous > changes if they were done with `setq', according to how defconst are > handled. But I never intended to make it a feature, nor did I suggest > that was desirable. > >> As you have said, we still want to allow users in principle to change >> these variables. > > No, I haven't said such a thing. I said, verbatim, "In principle, they > mustn't be changed", which means quite the contrary. > >> They have been defcustoms in the past, some people will have changed >> them. Their setup will break when they switch to a new version. > > Indeed. But that's easy to fix programmatically. > >> That is why I object to changing their status. I think it causes >> unnecessary breakage, and we can prevent this by keeping them >> defcustom. Nothing is really gained by changing their status. > > It fixes at least a bug, prevents headaches by simplifying maintenance, > makes Org syntax more portable and more cache friendly. I wouldn't call > that "nothing". Yes, sorry. By "nothing" I mean nothing we cannot achieve with documentation and a :set method. Since we will still rely on the variables, the advantage for maintenance is something I do not see. Cache friendliness I see, but I would think that if someone changes these variables, they will not keep changing them. > > Anyway, I have well understood that you don't want to change their > status. So be it. OK, thank you. Regards - Carsten