Hello, Carsten Dominik <carsten.domi...@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
