Hello,
Aaron Ecay writes:
> The attached patch implements this. It also updates the fontification
> to match (by calling out to the parser, so there are potential
> performance issues although with the cache it will hopefully not be an
> issue in practice), and notes the new heuristic in the ma
2013ko abenudak 17an, Nicolas Goaziou-ek idatzi zuen:
>
> Hello,
>
> Aaron Ecay writes:
>
>> Since the present syntax is inadequate for representating these
>> sequences, the new syntax will have to break backwards compatibility
>> somehow in order to fix the problem. So there’s no long-term h
Hello,
Aaron Ecay writes:
> Since the present syntax is inadequate for representating these
> sequences, the new syntax will have to break backwards compatibility
> somehow in order to fix the problem. So there’s no long-term harm in
> having a short-term kludge that will eventually disappear.
2013ko abenudak 12an, Nicolas Goaziou-ek idatzi zuen:
> No, it just means that I didn't put much thought into it. It also means
> that I would prefer something more natural (and simpler) than such an
> ad-hoc rule.
>
> If you work on it and really think it is an improvement over existing
> situati
Aaron Ecay writes:
> 2013ko abenudak 12an, Nicolas Goaziou-ek idatzi zuen:
>>
>> We could give priority to underline when there are no curly brackets,
>> priority to subscript otherwise. It sounds overly complicated though.
>
> Your last sentence sounds very close to "don’t do it; I won’t accept
Hi Nicolas,
2013ko abenudak 12an, Nicolas Goaziou-ek idatzi zuen:
>
> We could give priority to underline when there are no curly brackets,
> priority to subscript otherwise. It sounds overly complicated though.
Your last sentence sounds very close to "don’t do it; I won’t accept
such a patch."
Hello,
Aaron Ecay writes:
> 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.
We could give priority to underline when there are no curly brackets,
priority to subscript ot
2013ko abenudak 11an, Nicolas Goaziou-ek idatzi zuen:
>
> Aaron Ecay 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:
>
>
Aaron Ecay 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}
But that's not the real problem: whenever we change under
Hi Nicolas,
Thanks for your comments.
2013ko abenudak 11an, Nicolas Goaziou-ek idatzi zuen:
> Actually, this is not really a parser problem but a syntax one.
> underline and subscript are ambiguous, and therefore ill-defined,
> because, in some situations, both can match at the same location.
I
Hello,
Aaron Ecay writes:
> I have encountered two related misbehaviors in the parser/exporter.
>
> The first manifests if you type the following line into an org-mode
> buffer and execute M-: (org-element-context) with point on the ‘f’; the
> result is a subscript object, whereas I would have e
Hello,
I have encountered two related misbehaviors in the parser/exporter.
The first manifests if you type the following line into an org-mode
buffer and execute M-: (org-element-context) with point on the ‘f’; the
result is a subscript object, whereas I would have expected an
underline:
'_foo_
12 matches
Mail list logo
