From: Thorsten Jolitz <tjolitz@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [RFC] Org Minor Mode?
Date: Sat, 19 Apr 2014 12:25:32 +0200 [thread overview]
Message-ID: <878ur1ty3n.fsf@gmail.com> (raw)
In-Reply-To: CAJcAo8vxzL+ZmmYKGVRYr5Xw-HdFTmi68LhErs0bfSrGxg_gXg@mail.gmail.com
Samuel Wales <samologist@gmail.com> writes:
Hi Samuel,
> another option is to create annotation mechanisms that are so
> compelling that you don't need org in non-org files.
>
> your lists and tasks would stay in your org agenda files, but your
> external files would be able to show (via overlays) and link to the
> annotations in org. in turn, your annotations in org would be able to
> send you to the spot in your extenal files that they refer to.
>
> we have a ton of annotation mechanisms in emacs and org, but they can
> perhaps be made more compelling in this way.
I think there probably do exist quite a lot of individual customized
systems to connect Org planning files to associated source code files,
and this is definitely a viable use pattern.
But I think a simpler more direct approach is possible - simply an
outline-minor-mode on steroids (=> org-minor-mode). If I structure my
source file with headlines like an org file, do visibility-cycling,
structure editing etc. like in Org-mode - why not add TODO's and
priorities and tags and properties to my headlines? The functionality to
do that is already there in Org-mode, and the syntax-elements used would
be exactly the same. Except the comment-syntax involved ...
> On 4/11/14, Richard Lawrence <richard.lawrence@berkeley.edu> wrote:
>> Hi Thorsten,
>>
>> Bastien <bzg@gnu.org> writes:
>>
>>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>>
>>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>>
>>>>> What do you think - is there any chance that Org-mode switches from
>>>>> static hardcoded regexp strings (all over the place) to dynamic
>>>>> regexps calculated at runtime (using libraries like drx.el or rx.el)?
>>>>
>>>> I hope not. The syntax should stabilize, not drift away.
>>>
>>> Agreed. Maybe there are some hardcoded regexps that we can factor
>>> out, but dynamically building those fundamental regexp is a deadend.
>>
>> I agree with what Nicolas and Bastien have said, but I wanted to say
>> that I think there is an interesting idea in Thorsten's post that
>> shouldn't be dismissed out of hand.
>>
>> Org provides a set of UI concepts (tree-like structure, visibility
>> cycling, tree filtering, task state tracking, building an agenda from
>> multiple sources, ...) that map nicely onto a lot of other situations,
>> and would be really handy to have access to even when the syntax of the
>> underlying file is incompatible with Org's syntax.
>>
>> There are two ways to think about Org syntax, which I think should be
>> distinguished here. One is as the grammar of a .org file: basically, a
>> set of rules that allow a sequence of characters to be parsed into an
>> AST. The other way to think about Org syntax is the way Lisp
>> programmers sometimes talk about syntax: as the AST itself, the
>> collection of Lisp data types and their interrelationships that define a
>> valid Org document.
>>
>> If Org were to evolve to the point where the UI concepts were
>> implemented purely as transformations on an AST -- on Org syntax in the
>> second sense -- then the way would be clear for making those concepts
>> available in editing modes where the grammar of the underlying file is
>> incompatible with Org syntax in the first sense. A programming mode
>> could, say, parse comments into an Org AST, then expose that AST to the
>> functions implementing Org's UI concepts. Et voila: you get visibility
>> cycling, task state tracking, agendas...in your source code comments.
>>
>> One sort of use case where I think this idea could really shine is in
>> dealing with email. Obviously, the grammar of the underlying mail files
>> (say, in a Maildir) will never be compatible with Org syntax in the
>> first sense. But Org handles so many of the concepts that apply to
>> email (threading messages into hierarchies, visibility cycling, tagging,
>> sorting by date or priority, thinking of messages as tasks to be dealt
>> with, dealing with attachments) in such a nice way that I find myself
>> sorely missing Org whenever I read mail in a client that doesn't
>> implement them as nicely -- which is all of them. If it were possible
>> to build a parser for message files that transformed them into an Org
>> AST, the mail client of my dreams would be in reach.
>>
>> I have no idea if evolving Org in this direction is feasible or even
>> really desireable. It may be that the two notions of Org syntax are
>> tightly coupled in principle, so that the idea of producing an Org AST
>> from an alternative underlying file format will never make sense. But I
>> think that would be surprising.
>>
>> This evolution would clearly require more work than just abstracting out
>> the regular expressions that implement much of Org's syntax in the first
>> sense, and I think Bastien and Nicolas are right that we don't want
>> either notion of Org syntax to become less stable. Still, I think
>> there's a lot of interesting possibilities we could explore if Org's
>> implementations of the two notions of syntax were to become less tightly
>> coupled.
>>
>> Best,
>> Richard
>>
>>
>>
--
cheers,
Thorsten
next prev parent reply other threads:[~2014-04-19 10:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 17:55 [RFC] Org Minor Mode? Thorsten Jolitz
2014-04-10 19:19 ` Nicolas Goaziou
2014-04-11 10:07 ` Bastien
2014-04-11 17:22 ` Richard Lawrence
2014-04-13 16:28 ` Thorsten Jolitz
2014-04-19 5:37 ` Samuel Wales
2014-04-19 10:25 ` Thorsten Jolitz [this message]
2014-04-13 16:07 ` Thorsten Jolitz
2014-04-18 13:27 ` Bastien
2014-04-13 16:00 ` Thorsten Jolitz
2014-04-18 13:29 ` Bastien
2014-04-18 15:54 ` Thorsten Jolitz
2014-04-19 5:23 ` Bastien
2014-04-19 10:11 ` Thorsten Jolitz
2014-04-19 12:57 ` Bastien
2014-04-24 21:06 ` Ilya Shlyakhter
2014-04-25 8:00 ` Thorsten Jolitz
2014-04-29 12:24 ` Bastien
2014-04-29 18:44 ` Ilya Shlyakhter
2014-05-06 9:06 ` Bastien
2014-04-24 21:16 ` Ilya Shlyakhter
2014-04-25 7:49 ` Thorsten Jolitz
2014-05-06 9:20 ` Bastien
2014-05-27 9:20 ` Thorsten Jolitz
2014-05-28 21:47 ` Bastien
2014-05-28 22:19 ` Thorsten Jolitz
2014-05-29 0:01 ` Bastien
2014-05-29 17:47 ` Thorsten Jolitz
2014-05-29 18:57 ` Bastien
2014-05-30 8:52 ` Thorsten Jolitz
2014-05-30 12:13 ` Bastien
2014-05-30 13:41 ` Thorsten Jolitz
2014-05-30 13:54 ` Bastien
2014-05-30 14:15 ` Thorsten Jolitz
2014-05-30 14:22 ` Bastien
2014-05-30 14:38 ` Thorsten Jolitz
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=878ur1ty3n.fsf@gmail.com \
--to=tjolitz@gmail.com \
--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).