From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [Out-of-Thread] Re: [RFC] Org syntax (draft) Date: Thu, 21 Mar 2013 22:36:54 +0100 Message-ID: <87wqt05tah.fsf@gmail.com> References: <6449B53A-997D-411D-8E13-AAFAE6D81397@gmail.com> <87mwu0n371.fsf@riseup.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:55878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UInAX-0001Mw-7S for emacs-orgmode@gnu.org; Thu, 21 Mar 2013 17:37:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UInAV-00018l-SW for emacs-orgmode@gnu.org; Thu, 21 Mar 2013 17:37:05 -0400 Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]:36379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UInAV-00018O-M9 for emacs-orgmode@gnu.org; Thu, 21 Mar 2013 17:37:03 -0400 Received: by mail-we0-f170.google.com with SMTP id z2so1196231wey.15 for ; Thu, 21 Mar 2013 14:37:02 -0700 (PDT) In-Reply-To: (Carsten Dominik's message of "Mon, 18 Mar 2013 20:19:42 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: "W. Greenhouse" , emacs-orgmode@gnu.org Hello, Carsten Dominik 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