Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)

[Nicolas Goaziou <n.goaziou@gmail.com>]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> First of all, we should not see Org as just another plain text markup
> language (no offense meant, I am sure, and none taken). Because of its
> unique treatment of source code inclusion, source code markup, and
> executability, it is very much unique, I think.

Indeed. Or, to put it differently, an external tool wishing to export an
/any/ Org document has to implement Babel in addition to the parser.

> For example, every users setup has some dependency of parser behavior
> on external variables: todo keywords. The way this is fixed in the
> sense that we can guarantee a stable parsing of such a system is to
> tell people that including the TODO keyword definitions with a #+TODO
> line into the file. So you can have a global setting in a global
> customization variable to make things easy for yourself and get good
> behavior in every new file you open, but you can stabilize a file for
> the parser with in-buffer settings when you need compatibility for
> other users.
>
> There are a few exceptions that Nicolas has pointed out in this
> thread. The COMMENT keyword is one. We could define an in-buffer
> setting for it, or we could just fix it, the pain here would be
> minimal.

I think we should only add in-buffer settings for important parts of Org
syntax (e.g. TODO keywords). A hard-coded value for small details like
COMMENT keyword or EFFORT property is good enough, IMO.

> The reason why the emphasis regexp components were made configurable
> in the first place is because when the feature was introduced, I had
> no idea what would work, and I redesigned this part several times
> over. Emphasis is a very heuristic system, the character that are
> allowed before and after the markers are necessarily a compromise, and
> we will always find people for who the chosen selection will not work.
>
> That is why I would like to argue for keeping this part hackable, even
> if I agree that the official definition should be fixed. Keeping this
> variable a customize variable invites changes also by people who do
> not really know what they are doing. Turning it into a defvar or
> defconst and somewhere document how to hack around the restriction if
> you really need to sounds like a good solution for me.

We can also use a very simple and tolerant regexp (e.g. =[^\000]+=), and
introduce a syntax to escape markers for fine-grained control.

> Nicolas, I would assume that your wish to disallow customization is
> focused on the regexp components, and the marker characters for
> emphasis, but not on the possibility to change the in-buffer face that
> is being used to highlight the stuff in the buffer?

That's correct.


Regards,

-- 
Nicolas Goaziou