From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Beck Subject: Re: [RFC] Change some defcustoms into defcont Date: Tue, 22 Oct 2013 22:00:45 +0200 Message-ID: <87mwm1hy8i.fsf@sophokles.streitblatt.de> 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 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYi8Y-0005f0-IN for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 16:01:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYi8S-0007HD-NX for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 16:01:06 -0400 Received: from mo6-p00-ob.rzone.de ([2a01:238:20a:202:5300::1]:53189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYi8S-0007Gy-6P for emacs-orgmode@gnu.org; Tue, 22 Oct 2013 16:01:00 -0400 In-Reply-To: (Torsten Wagner's message of "Tue, 22 Oct 2013 20:28:37 +0200") 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: Torsten Wagner Cc: Nicolas Goaziou , Org Mode List , Carsten Dominik Torsten Wagner writes: > 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. Well, I like the idea of an importer. Not so much because of keywords, but because org should work on text files and text files often work with different conventions (I still have muse files around and old org files where I used *this* for emphasis.) > 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. This I would call export. > 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. The problem is, the exporter can only be used if org-element can parse the syntax, which is exactly what Nicolas wants to get rid of. Org-element clearly isn't intend to be a general parser. So an importer/preprocessor/old->new converter would have to be either a simple search and replace mechanism or do all the heavy lifting itself. Hm, if I'd have, say, an xml of lisp representation of the buffer (i.g. (ELEMENT (OPTIONS) ((ELEMENT (OPTIONS) ...)))), is there a way to hand that of to org-element or the exporter? -- Florian Beck