From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Wagner Subject: Re: [RFC] Change some defcustoms into defcont Date: Tue, 22 Oct 2013 20:28:37 +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> <87zjq1tyxy.fsf@gmail.com> <9ED40360-BFB2-4F8C-BADB-6F0A798C9742@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYgh6-0001Uk-Ib for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 14:28:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYgh4-0003rR-Q5 for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 14:28:40 -0400 Received: from mail-ee0-x230.google.com ([2a00:1450:4013:c00::230]:33352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYgh4-0003pA-FP for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 14:28:38 -0400 Received: by mail-ee0-f48.google.com with SMTP id e50so2963262eek.7 for ; Tue, 22 Oct 2013 11:28:37 -0700 (PDT) In-Reply-To: <9ED40360-BFB2-4F8C-BADB-6F0A798C9742@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: Carsten Dominik Cc: Org Mode List , Nicolas Goaziou Hi, not being a dev and really not being a lisp programmer, I still can see Nicolas attempt to unify the syntax in a way "all and everyone/everything" can rely on it. The question would be what would be more troublesome? Dealing in future with people who by chance changed some of those variables and who suddenly face problems using third party (internal as well as external) tools. E.g., tools like org-ruby came to my mind. More and more projects start to include org-syntax too. For all those it would become difficult to rely on certain keywords. Or is it more problematic that those who changed variables already, might find there system broken / in need of manual adoption after an update? Anyhow, I just had this idea that org-mode could rely on a fixed (as written in stone) set of keywords and that an a new exporter backend will be introduced which simply creates a standard-conform org-mode file. Let's call it ox-legacy ;) Those created files could be send to others to work on it or could be used in conjunction with 3rd party programs. By time, one could think of a org-mode import, which again takes a standard conform org-mode file and translates it back into the individual settings of a specific user. Having an legacy org-mode exporter and importer, could even allow to customize org-mode for different languages, e.g. one could set (setq org-mode-language "german") to get a set of keywords in German. Exporting it into legacy org-mode would translate it back into e.g. English, which then again could be read-in by a user who set (setq org-mode-language "japanese") and who would be able to read the file with a set of Japanese keywords. Just an idea I had following this thread. All the best Torsten On 22 October 2013 12:34, Carsten Dominik wrote: > > On Oct 22, 2013, at 11:52 AM, Nicolas Goaziou wrote: > >> Hello, >> >>> 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 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. >> >>> Yes, sorry. By "nothing" I mean nothing we cannot achieve with >>> documentation and a :set method. >> >> This will not fix the bug. > > Hi Nicolas, > > can you remind me what the bug was? The taskjuggler issue? > > >> >>> Since we will still rely on the variables, the advantage for >>> maintenance is something I do not see. >> >> 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. >> >>> Cache friendliness I see, but I would think that if someone changes >>> these variables, they will not keep changing them. >> >> 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. >> >> 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 > >> >> >> Regards, >> >> -- >> Nicolas Goaziou > >