Hi Carsten, Thank you for your very insightful thoughts. I would like to make one note.
2013ko martxoak 18an, Carsten Dominik-ek idatzi zuen: > Now to the discussion with Z about additional emphasis definitions > which he/she uses for custom highlighting of stuff. Right now this > relies on modifying the emph-alist variable. However, for the purpose > of in-buffer only highlighting, it is not necessary to go through > parser-sensitive code. You can do this simply with additions to > font-lock, for example using font-lock-add-keywords or something like > this, see also Thorsten's post. If someone wants, I can provide an > example for Z's case, and we could encapsulate such behavior into a > little library in contrib, to make it easy to configure such behavior. > Compromising the parser for this application is not necessary. I use org to write articles which discuss words in foreign languages. These need to be distinctively typeset (in italics), and sometimes need to be set in a special font with coverage for exotic characters. I would find it very useful to be able to define special emphasis environments for these words. Using macros feels too much like writing LaTeX (which I use org to avoid having to write directly, as much as possible...) I see the goal of the syntactic standardization as making it easier to operate with non-emacs tools; as Nicolas said: > My point of view is the following: Org (as a format) definition > shouldn't depend on Emacs. It should be totally parseable by any > language (which is not the case actually, since syntax relies on > variables defined in Emacs). IOW, we should work to make it a real > plain-text markup format. Personally, I am OK with articles I have written for export never being able to be read by non-emacs tools (as opposed to other uses of org as a database/schedule/agenda, where the ability to access the information in other programs/programming languages would be useful). I sympathize with the goal of making the format accessible to other tools, but I also think the ability to have within emacs additional flexibility wrt. formatting (for both display and export) is worth preserving. -- Aaron Ecay
