Carsten Dominik <carsten.domi...@gmail.com> writes: > 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.
To some extend I disagree, I think. Well, a contrib library is of course OK, but I think it's not the right way to go about it. . . Would it be possible to make it easier to make 'custom' highlights? In a previous thread a [cite:key] syntax was suggested. Perhaps, a better way for custom emphasis would be [type:value] allowing for custom functions for each type. E.g. [TYPE:value] would run function a function org-type-keys-TYPE which returns value formatted with a special face. Perhaps this is more cumbersome and perhaps it is no more 'structured' than using customized emphases. –Rasmus -- El Rey ha muerto. ¡Larga vida al Rey!
