emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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

  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).