From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Lawrence Subject: Re: [RFC] Org Minor Mode? Date: Fri, 11 Apr 2014 10:22:19 -0700 Message-ID: <87lhvbeq7o.fsf@berkeley.edu> References: <87ha61f4rk.fsf@gmail.com> <8738hlkn64.fsf@gmail.com> <87k3aw0zmx.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYfBb-000542-No for emacs-orgmode@gnu.org; Fri, 11 Apr 2014 13:24:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYfBR-0004ME-Py for emacs-orgmode@gnu.org; Fri, 11 Apr 2014 13:24:19 -0400 Received: from plane.gmane.org ([80.91.229.3]:37154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYfBR-0004Lu-Jh for emacs-orgmode@gnu.org; Fri, 11 Apr 2014 13:24:09 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WYfBQ-00019p-Jp for emacs-orgmode@gnu.org; Fri, 11 Apr 2014 19:24:08 +0200 Received: from c-67-164-45-159.hsd1.ca.comcast.net ([67.164.45.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Apr 2014 19:24:08 +0200 Received: from richard.lawrence by c-67-164-45-159.hsd1.ca.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Apr 2014 19:24:08 +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 Cc: Thorsten Jolitz 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