Re: [RFC] Change some defcustoms into defcont

[Florian Beck <fb@miszellen.de>]

Torsten Wagner <torsten.wagner@gmail.com> 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