From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [RFC] Change some defcustoms into defcont Date: Tue, 22 Oct 2013 09:50:49 +0200 Message-ID: References: <871u3g5nwx.fsf@gmail.com> <87mwm33sv1.fsf@gmail.com> <87a9i2522c.fsf@gmail.com> <7839A647-8D17-47A9-A65D-5FD7110ED082@gmail.com> <874n8avenk.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYWk1-0004j4-67 for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 03:51:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYWjs-00032X-OV for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 03:51:01 -0400 Received: from mail-ea0-x229.google.com ([2a00:1450:4013:c01::229]:61891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYWjs-00032S-HZ for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 03:50:52 -0400 Received: by mail-ea0-f169.google.com with SMTP id k11so4019173eaj.14 for ; Tue, 22 Oct 2013 00:50:51 -0700 (PDT) In-Reply-To: <874n8avenk.fsf@gmail.com> 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: Org Mode List Dear Nicolas, On Oct 21, 2013, at 5:15 PM, Nicolas Goaziou = wrote: > Carsten Dominik writes: >=20 >> The documentation of defconst says: >>=20 >>> 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. >>=20 >> 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. >=20 > 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. >=20 > 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. >=20 >> As you have said, we still want to allow users in principle to change >> these variables. >=20 > No, I haven't said such a thing. I said, verbatim, "In principle, they > mustn't be changed", which means quite the contrary. >=20 >> They have been defcustoms in the past, some people will have changed >> them. Their setup will break when they switch to a new version. >=20 > Indeed. But that's easy to fix programmatically. >=20 >> 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. >=20 > 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. >=20 > Anyway, I have well understood that you don't want to change their > status. So be it. OK, thank you. Regards - Carsten=