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 12:34:34 +0200 Message-ID: <9ED40360-BFB2-4F8C-BADB-6F0A798C9742@gmail.com> References: <871u3g5nwx.fsf@gmail.com> <87mwm33sv1.fsf@gmail.com> <87a9i2522c.fsf@gmail.com> <7839A647-8D17-47A9-A65D-5FD7110ED082@gmail.com> <874n8avenk.fsf@gmail.com> <87zjq1tyxy.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]:44868) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYZIV-0003rx-4F for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 06:34:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYZIM-0002x4-I6 for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 06:34:47 -0400 Received: from mail-ea0-x22b.google.com ([2a00:1450:4013:c01::22b]:40131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYZIM-0002wn-Ae for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 06:34:38 -0400 Received: by mail-ea0-f171.google.com with SMTP id n15so4104638ead.16 for ; Tue, 22 Oct 2013 03:34:37 -0700 (PDT) In-Reply-To: <87zjq1tyxy.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 , Carsten Dominik On Oct 22, 2013, at 11:52 AM, Nicolas Goaziou = wrote: > Hello, >=20 >> You also said things like >>=20 >>> 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. >>=20 >> so maybe I picked one interpretation over the other. >=20 > I don't see any contradiction. You can modify a defconst, but the = strong > message is "you are not supposed to do that". I didn't suggest = modifying > these variables was expected. Anyway, I acknowledge I wasn't very = clear. >=20 >> Yes, sorry. By "nothing" I mean nothing we cannot achieve with >> documentation and a :set method. >=20 > This will not fix the bug. Hi Nicolas, can you remind me what the bug was? The taskjuggler issue? >=20 >> Since we will still rely on the variables, the advantage for >> maintenance is something I do not see. >=20 > As a developer, you have to keep in mind that the string might be > changed. Sometimes, it's easy to forget you cannot hardcode it, e.g. > when writing a search regexp. I have done a similar mistake in > ox-taskjuggler.el, where I expect the effort property to be named > ":EFFORT:". More things to remember, more potential bugs, more > maintenance efforts. >=20 >> Cache friendliness I see, but I would think that if someone changes >> these variables, they will not keep changing them. >=20 > Of course. I shouldn't have talked about cache since it makes me sound > like a lazy person. I can work around the cache problem. >=20 > Again my main concern was to move to a proper, Emacs-independent, > /minimal/ core syntax, i.e., to define the "Org format". For example, = at > the moment, external tools cannot rely on "SCHEDULED:" string to write > even a basic Org file, because "SCHEDULED:" doesn't clearly belong to > the syntax and, therefore, might be incompatible with some > configurations. Yes, as I said, I do see all these problems, but I also feel the = responsibility to break as few as possible existing configurations. If you want, I can take a shot at documenting this properly. - Carsten >=20 >=20 > Regards, >=20 > --=20 > Nicolas Goaziou