From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [RFC] Org Minor Mode? Date: Sat, 19 Apr 2014 12:25:32 +0200 Message-ID: <878ur1ty3n.fsf@gmail.com> References: <87ha61f4rk.fsf@gmail.com> <8738hlkn64.fsf@gmail.com> <87k3aw0zmx.fsf@bzg.ath.cx> <87lhvbeq7o.fsf@berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbSRY-00023z-Jc for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 06:24:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WbSRT-00030q-IJ for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 06:24:20 -0400 Received: from plane.gmane.org ([80.91.229.3]:43894) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbSRT-00030k-8w for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 06:24:15 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WbSRR-0007gh-54 for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 12:24:13 +0200 Received: from e178190076.adsl.alicedsl.de ([85.178.190.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Apr 2014 12:24:13 +0200 Received: from tjolitz by e178190076.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Apr 2014 12:24:13 +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 Samuel Wales 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 wrote: >> Hi Thorsten, >> >> Bastien writes: >> >>> Nicolas Goaziou writes: >>> >>>> Thorsten Jolitz 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