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: Nicolas Goaziou
Subject: Re: [O] [parser] subscripts and underlines interacting badly
Date: Thu, 12 Dec 2013 21:47:32 +0100

Aaron Ecay <address@hidden> 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



reply via email to

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