emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: "W. Greenhouse" <wgreenhouse@riseup.net>, emacs-orgmode@gnu.org
Subject: Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)
Date: Thu, 21 Mar 2013 22:36:54 +0100	[thread overview]
Message-ID: <87wqt05tah.fsf@gmail.com> (raw)
In-Reply-To: <B72CDC2B-72F6-43A8-AC70-E6E6295766EC@gmail.com> (Carsten Dominik's message of "Mon, 18 Mar 2013 20:19:42 +0100")

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> First of all, we should not see Org as just another plain text markup
> language (no offense meant, I am sure, and none taken). Because of its
> unique treatment of source code inclusion, source code markup, and
> executability, it is very much unique, I think.

Indeed. Or, to put it differently, an external tool wishing to export an
/any/ Org document has to implement Babel in addition to the parser.

> For example, every users setup has some dependency of parser behavior
> on external variables: todo keywords. The way this is fixed in the
> sense that we can guarantee a stable parsing of such a system is to
> tell people that including the TODO keyword definitions with a #+TODO
> line into the file. So you can have a global setting in a global
> customization variable to make things easy for yourself and get good
> behavior in every new file you open, but you can stabilize a file for
> the parser with in-buffer settings when you need compatibility for
> other users.
>
> There are a few exceptions that Nicolas has pointed out in this
> thread. The COMMENT keyword is one. We could define an in-buffer
> setting for it, or we could just fix it, the pain here would be
> minimal.

I think we should only add in-buffer settings for important parts of Org
syntax (e.g. TODO keywords). A hard-coded value for small details like
COMMENT keyword or EFFORT property is good enough, IMO.

> The reason why the emphasis regexp components were made configurable
> in the first place is because when the feature was introduced, I had
> no idea what would work, and I redesigned this part several times
> over. Emphasis is a very heuristic system, the character that are
> allowed before and after the markers are necessarily a compromise, and
> we will always find people for who the chosen selection will not work.
>
> That is why I would like to argue for keeping this part hackable, even
> if I agree that the official definition should be fixed. Keeping this
> variable a customize variable invites changes also by people who do
> not really know what they are doing. Turning it into a defvar or
> defconst and somewhere document how to hack around the restriction if
> you really need to sounds like a good solution for me.

We can also use a very simple and tolerant regexp (e.g. =[^\000]+=), and
introduce a syntax to escape markers for fine-grained control.

> Nicolas, I would assume that your wish to disallow customization is
> focused on the regexp components, and the marker characters for
> emphasis, but not on the possibility to change the in-buffer face that
> is being used to highlight the stuff in the buffer?

That's correct.


Regards,

-- 
Nicolas Goaziou

  parent reply	other threads:[~2013-03-21 21:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-17 23:02 [Out-of-Thread] Re: [RFC] Org syntax (draft) zeltak
2013-03-18  6:08 ` Carsten Dominik
2013-03-18 10:48   ` Thorsten Jolitz
2013-03-18 13:33   ` zeltak
2013-03-18 15:21     ` W. Greenhouse
2013-03-18 16:05       ` Marcin Borkowski
2013-03-18 19:19       ` Carsten Dominik
2013-03-18 21:24         ` Rasmus
2013-03-19  3:47         ` Aaron Ecay
2013-03-19  9:49         ` Nicolas Richard
2013-03-21 21:36         ` Nicolas Goaziou [this message]
2013-04-12  6:23           ` Bastien
2013-04-12  6:23         ` Bastien
2013-03-19  4:07       ` Samuel Wales
  -- strict thread matches above, loose matches on Subject: below --
2013-03-20 17:47 zeltak
2013-03-07 20:37 Nicolas Goaziou
2013-03-09 23:16 ` Achim Gratz
2013-03-09 23:49   ` Nicolas Goaziou
2013-03-10  4:35     ` Jambunathan K
2013-03-10  7:08       ` Nicolas Goaziou
2013-03-10 10:14         ` Bastien
2013-03-10 15:44           ` Jambunathan K
2013-03-14 16:58             ` Eric S Fraga
2013-03-14 18:26               ` Jambunathan K
2013-03-14 18:51                 ` David Engster
2013-03-14 19:03                   ` [Out-of-Thread] " Jambunathan K
2013-03-14 19:15                     ` David Engster
2013-03-14 19:23                       ` Jambunathan K
2013-03-14 19:29                         ` David Engster
2013-03-14 19:52                           ` Jambunathan K

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=87wqt05tah.fsf@gmail.com \
    --to=n.goaziou@gmail.com \
    --cc=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=wgreenhouse@riseup.net \
    /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).