Aaron Ecay <aarone...@gmail.com> 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
> such a patch." Is that so?
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
situation, then I don't see why I wouldn't accept it. But I'd rather not
consider it as a definitive answer to the problem (and include it as
a part of a standard Org syntax implementation).
> 1. You have a plan to get rid of org-use-sub-superscripts. You might also
> want to get rid of `org-export-with-sub-superscripts' (depending on how
> one interprets your remark that the variable "do[es]n't make much sense
> anyway"). Also, other parts of org (e.g. the parser) cannot change to
> harmonize with these variables. This means that these variables are de
> facto deprecated, and org is headed to a future where sub/superscripts
> are non-optional and non-configurable.
and non-intrusive, too, which isn't the case at the moment.
You cannot get rid of subscript in LaTeX (well, you probably can, but
I guess most users don't). Why could you in Org?
> 2. The current (non-optional, non-configurable) implementation of
> X-scripts by the parser has specifically identifiable defects,
> such as the one I mentioned whereby '_foo_, perhaps naturally
> interpreted as underlining (among other reasons because of how it
> is highlighted by org) is "really" a subscript.
The current implementation, with its defects, is still configurable.
`org-export-with-sub-superscripts' works as advertised, AFAIK.
> 3. These inconsistencies cannot (or ought not) be addressed except by
> some notional change to org syntax, which only you can (ought) make,
> and which you’re not willing to discuss except in negative terms
> ("don’t do it that way").
I'm not really able to change Org syntax without Carsten's consent.
Anyway, I'd like any syntax change to be really discussed. Org has
a long history of great ideas implemented without any consistent syntax
in mind. Examples include @<tag>, Babel's #+header line with ":prop
value" (even though every other part of Org used "key=value"),
configurable emphasis markers and list item bullets, "comment" and
"quote" keywords (even though Archive is a tag)...
Also, changing Org syntax isn't limited to a mere patch over
org-element.el. Remember that most of Org doesn't use this library
(hint).
Back to the topic. As you know, I'm not really open to per-user Org
syntax. But I will consider any syntactical change that would solve the
problem at hand.
> I hope you realize why this situation might be frustrating to a user and
> attempted contributor.
I don't want to be frustrating.
I try to make as clear as possible what I see as important and where
I would like to head to. I even suggested topics to work on (e.g.
escaped characters).
There's also optimization to do on cache, if you're motivated.
> PS I guess you might be frustrated too. You mentioned your previous
> proposal about changing the regex which recognized X-scripts. I read
> the thread at the time, and didn’t say anything because I didn’t have a
> strong opinion one way or the other; it simply looked like a reasonable,
> incremental change and you were getting positive feedback. I’ve re-read
> the thread, and FWIW I think you should install the change, if you have
> not done so. I again don’t have an opinion on the question about
> grouping with parentheses which was left hanging at the end of the
> thread. Coming from a latex background, it would never occur to me to
> use parentheses to bracket an X-script. So it would not bother me if
> you removed parenthesis-grouping as it seems you want to do.
It is not applied. I am waiting for Carsten's green light about
parenthesis-grouping removal.
> PPS Also FWIW and again coming from a latex background, I think that
> "bare" X-scripts such as a_b are always somewhat suspect. I would be
> happy if org required brackets for X-scripts, always. I think this
> would simplify the parsing problem a lot. But I don’t know if this
> could have support enough to be implemented.
You are right, it would simplify parsing. But it is very handy for note
taking. I wouldn't suggest to remove it.
Regards,
--
Nicolas Goaziou
