emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Aaron Ecay <aaronecay@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>,
	"emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: [parser] subscripts and underlines interacting badly
Date: Thu, 12 Dec 2013 14:42:28 -0500	[thread overview]
Message-ID: <87ob4lkhmo.fsf@gmail.com> (raw)
In-Reply-To: <87txeevus8.fsf@gmail.com>

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."  Is that so?


[...]


>
> Again, `org-use-sub-superscripts' is, at the moment, a visual-only
> variable. My plan is to move it out, not in.

Just to be sure I understand:

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.
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.
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 hope you realize why this situation might be frustrating to a user and
attempted contributor.

Thanks,
Aaron

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.

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.

--
Aaron Ecay

  reply	other threads:[~2013-12-12 19:42 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 [this message]
2013-12-12 20:47             ` Nicolas Goaziou
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=87ob4lkhmo.fsf@gmail.com \
    --to=aaronecay@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=n.goaziou@gmail.com \
    /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).