From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Do not indent option keywords
Date: Fri, 10 May 2013 20:30:10 +0200 [thread overview]
Message-ID: <87mws24ril.fsf@Rainer.invalid> (raw)
In-Reply-To: 84E4FC16-3269-4639-B880-3D99FF80FC4B@gmail.com
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
prev parent reply other threads:[~2013-05-10 18:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-09 19:14 [PATCH] Do not indent option keywords Achim Gratz
2013-05-09 20:34 ` Achim Gratz
2013-05-10 6:26 ` Carsten Dominik
2013-05-10 6:39 ` Achim Gratz
2013-05-10 17:57 ` Carsten Dominik
2013-05-10 18:30 ` Achim Gratz [this message]
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=87mws24ril.fsf@Rainer.invalid \
--to=stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/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).