From: Nicolas Goaziou <n.goaziou@gmail.com>
To: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: [parser] subscripts and underlines interacting badly
Date: Thu, 12 Dec 2013 21:47:32 +0100 [thread overview]
Message-ID: <87lhzpx0d7.fsf@gmail.com> (raw)
In-Reply-To: <87ob4lkhmo.fsf@gmail.com> (Aaron Ecay's message of "Thu, 12 Dec 2013 14:42:28 -0500")
Aaron Ecay <aaronecay@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
next prev parent reply other threads:[~2013-12-12 20:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-11 2:30 [parser] subscripts and underlines interacting badly Aaron Ecay
2013-12-11 8:22 ` Nicolas Goaziou
2013-12-11 18:36 ` Aaron Ecay
2013-12-11 20:55 ` Nicolas Goaziou
2013-12-12 7:56 ` Aaron Ecay
2013-12-12 17:33 ` Nicolas Goaziou
2013-12-12 19:42 ` Aaron Ecay
2013-12-12 20:47 ` Nicolas Goaziou [this message]
2013-12-16 3:15 ` Aaron Ecay
2013-12-16 3:24 ` [PATCH] quick patch to org-habit todo state keywords Ted Wiles
2013-12-16 4:27 ` Aaron Ecay
2013-12-17 16:57 ` [parser] subscripts and underlines interacting badly Nicolas Goaziou
2013-12-18 6:57 ` Aaron Ecay
2013-12-18 15:01 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lhzpx0d7.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).