From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: Re: [RFC] Org Minor Mode? Date: Fri, 18 Apr 2014 22:37:57 -0700 Message-ID: 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; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbNyS-0005j3-6a for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 01:38:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WbNyQ-0003NP-Al for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 01:38:00 -0400 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:59710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbNyQ-0003ND-0J for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 01:37:58 -0400 Received: by mail-wi0-f173.google.com with SMTP id z2so190055wiv.0 for ; Fri, 18 Apr 2014 22:37:57 -0700 (PDT) In-Reply-To: <87lhvbeq7o.fsf@berkeley.edu> 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: Richard Lawrence Cc: Thorsten Jolitz , emacs-orgmode@gnu.org 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. 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 > > > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.