emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH] Do not indent option keywords


From: Achim Gratz
Subject: Re: [O] [PATCH] Do not indent option keywords
Date: Fri, 10 May 2013 20:30:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]