emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [parser] subscripts and underlines interacting badly


From: Aaron Ecay
Subject: Re: [O] [parser] subscripts and underlines interacting badly
Date: Thu, 12 Dec 2013 02:56:23 -0500
User-agent: Notmuch/0.17~rc1+1~g05e8895 (http://notmuchmail.org) Emacs/24.3.50.1 (i686-pc-linux-gnu)

2013ko abenudak 11an, Nicolas Goaziou-ek idatzi zuen:
>
> Aaron Ecay <address@hidden> writes:
>
>> I have found one case where both match, but an underline is intended.
>> Are there any reverse cases, i.e. where both match but a subscript is
>> intended?
>
> I don't know. Perhaps something as convoluted as:
>
>   A'_{a_-1}

Oh, yes.  Very clever.  Unfortunately, it means that a fix, even a
temporary one, cannot be just to prioritize underline over subscript as
I proposed.  =/


> As a short term solution, it can be implemented (it's probably just
> a matter of reordering successors calls). But in the long run, we really
> need to define properly both syntax.

I agree.  Do you think it is possible to solve the problem while
preserving the fact that underscore is used for both subscript and
underline?  It seems very difficult.

When I think about the question, I think probably what is needed is a
representation where object boundaries are delimited by one well-defined
pair of delimiters, like {} in latex or <> in html (well, in html they
delimit tags, but the principle is the same: only one pair).  Then we
don’t have to worry about escape syntax for many characters, or
characters with multiple possible interpretations (or how many lines
org-emph-re is allowed to match across, or ...).

But that is just one idea I have had.  You must have thought about it
more, so maybe you have others.

>
> I'm strongly against behavioral parts in Org syntax (even though the
> ship probably has sailed long ago). Org mode is bound to Emacs, but Org
> format should be platform independent.

Org syntax can be un-configurable even if org-element.el implements a
(configurable) superset of it.  Given that the use-subscript variable
exists (and without taking into account more systemic solutions as
discussed above), I’m arguing that it is cleaner to implement it in
org-element, rather than in two separate places (in the regex-based
old-style parsing code in org.el and in ox.el; there’s also one
reference to the variable in org-table.el(!))

Phrased in other terms, it makes no sense (in the context of Org-Mode,
not platonic Org Syntax) for org-element to insist that "a_b" is a
subscript, if org-use-sub-superscripts =
org-export-with-sub-superscripts = nil.

Thanks,

--
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]