On 2015-10-25, at 17:37, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:

> Marcin Borkowski <mb...@mbork.pl> writes:
>> Since your point is quite valid - and OTOH, I would like to put anything
>> (or almost anything) in =code= markup, for instance (my use case: Emacs
>> keybindings, try =C-x ,= - Org won't recognize it as code!).  I could
>> mess up with org-emphasis-regexp-components in e.g. file local
>> variables, but this is far from clean.
> I cannot think of any bad consequence if we tailor "border" in
> `org-emphasis-regexp-components' to allow everything but white spaces.

I don't know, I guess I would welcome such change!

>> Maybe a good solution would be to allow two syntaxes for markup:
>> "short", like *bold* or =code=, and "long", like \textbf{bold} and
>> \verb|code|.  If it is decided that such LaTeX-like syntax is fine, we
>> could only introduce escaping of backslash and curly braces, which seems
>> a decent compromise.
> I don't think LaTeX-like syntax is good. It doesn't belong to
> lightweight markup. Besides, Org already supports LaTeX macros so it
> would probably be ambiguous.

I see.  It was only a proposal.  Another possibility could be XML's
<code> ... </code>.  Or maybe the whole idea of short and long syntax is
bad.  But I'm afraid that if we want "lightweight markup", we might get
"impossible to mark up certain strings" (like Emacs keystrokes, which
are sometimes rather weird, like =C-x ,= - which is unbound by default,
but possible to use).

> I suggest to keep as close as possible to the existing markup.
> Regards,


Marcin Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Reply via email to