From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [RFC] Change some defcustoms into defcont Date: Mon, 21 Oct 2013 13:56:10 +0200 Message-ID: <7839A647-8D17-47A9-A65D-5FD7110ED082@gmail.com> References: <871u3g5nwx.fsf@gmail.com> <87mwm33sv1.fsf@gmail.com> <87a9i2522c.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYE5s-0004hB-2g for emacs-orgmode@gnu.org; Mon, 21 Oct 2013 07:56:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYE5j-0001ew-Lo for emacs-orgmode@gnu.org; Mon, 21 Oct 2013 07:56:20 -0400 Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]:32859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYE5j-0001ek-DW for emacs-orgmode@gnu.org; Mon, 21 Oct 2013 07:56:11 -0400 Received: by mail-wg0-f43.google.com with SMTP id b13so6435385wgh.10 for ; Mon, 21 Oct 2013 04:56:10 -0700 (PDT) In-Reply-To: <87a9i2522c.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 Hi Nicolas, On 21.10.2013, at 12:51, Nicolas Goaziou wrote: > Carsten Dominik writes: > >> On 21.10.2013, at 10:56, Nicolas Goaziou wrote: > >>> 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. >> >> This is where I disagree. I think the Emacs implementation of defconst >> is broken, and retained in this way only for backward compatibility. > > I won't judge Elisp implementation. AFAIC, defining a variable as > a defconst means : "change it at your own risk", which is exactly my > point. 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. As you have said, we still want to allow users in principle to change these variables. They have been defcustoms in the past, some people will have changed them. Their setup will break when they switch to a new version. 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. - Carsten > > Anyway, FWIW, even a defvar would suffice. > >> If we still allow users to edit this in principle, > > We have no way to prevent them from modifying it. In principle, they > mustn't be changed, but it's Free software. > >> I do not think we should make these variables defconst. If editing is >> not even depreciated, there is even less reason to make this change. >> How about we add a sentence like this: >> >> Changing this variable may cause compatibility problems with other users >> trying to edit your file in Emacs. > > It's not only about compatibility problems. As I pointed out, modifying > these variable can break your own Org. > > Using a defcustom is ambiguous here. On the one hand, we say "You can > modify this variable, we even help you to do so" and on the other hand > "Upon changing this variable, horrible things can happen". > > Let's, at least, not help users shoot themselves in the foot. > > > Regards, > > -- > Nicolas Goaziou