From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [PATCH] Do not indent option keywords Date: Fri, 10 May 2013 20:30:10 +0200 Message-ID: <87mws24ril.fsf@Rainer.invalid> References: <8738twge3b.fsf@Rainer.invalid> <87txmbgaeg.fsf@Rainer.invalid> <41207E77-189F-40AB-909D-3581EFA38288@gmail.com> <874nebfie5.fsf@Rainer.invalid> <84E4FC16-3269-4639-B880-3D99FF80FC4B@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:59693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uas5L-00020q-VL for emacs-orgmode@gnu.org; Fri, 10 May 2013 14:30:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uas5K-0002Rf-Ov for emacs-orgmode@gnu.org; Fri, 10 May 2013 14:30:27 -0400 Received: from plane.gmane.org ([80.91.229.3]:57757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uas5K-0002RI-JD for emacs-orgmode@gnu.org; Fri, 10 May 2013 14:30:26 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Uas5G-0005eS-Pg for emacs-orgmode@gnu.org; Fri, 10 May 2013 20:30:22 +0200 Received: from pd9eb5dfd.dip0.t-ipconnect.de ([217.235.93.253]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 May 2013 20:30:22 +0200 Received: from Stromeko by pd9eb5dfd.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 May 2013 20:30:22 +0200 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: emacs-orgmode@gnu.org Carsten Dominik writes: > Well, which are the ones you think should never become indented? > OPTIONS, TITLE, of maybe you mean the whole suite of keywords? OPTIONS, TITLE, PROPERTY for sure. But as I said, someone else may actually want them to indent, so making sure they don't drop their font-lock-properties when indented is a better idea. >> I think we should make an effort to shift most if not all the regex >> stuff in org.el into org-element. There's far too much duplication with >> subtle differences sprinkled all over the place to get match data to >> work with and it's almost hopeless to try and find all such uses for a >> single element. > > What do you mean? Do you meant to use the org-elemnt parser > and base also font-lock on it? Yes, but I'm not sure it is fully up to the task yet. But it ought to be, since there is no point in defining the syntax of the same piece of Org in more than one place. > Or do you mean all the definitions of regexp constants. That too. Although as you note, this is fraught with peril. But if we'd see it through, then the result would be a lot less troublesome to maintain. Look at all the places in org.el where a match for headline tags is constructed for instance… > This sounds desirable - but it also sounds like an extremely daunting > task with possibilities for problems in side effects of regexp > matching that will be difficult to find and might only show after a > long time. I guess we could start such a process one regexp at a > time. Please see http://thread.gmane.org/gmane.emacs.orgmode/69065/focus=71563 for a patch that attempts to implement some of this for node properties. It doesn't yet do away with the regex in org.el since there's no obvious convention for org-element to produce match data that can be used by the caller -- but if there was, then the regex could move into org-element I'd think. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds