From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: org-git-link does not support locational information within file Date: Sat, 12 Feb 2011 12:17:24 +0100 Message-ID: <87ipwptmwl.fsf@altern.org> References: <877hdh2m7a.fsf@univie.ac.at> <87zkq2trqx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=49634 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PoFJK-00033A-AL for emacs-orgmode@gnu.org; Sat, 12 Feb 2011 08:14:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PoFJI-00023s-SK for emacs-orgmode@gnu.org; Sat, 12 Feb 2011 08:14:50 -0500 Received: from mail-fx0-f41.google.com ([209.85.161.41]:38164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PoFJI-00022I-Mt for emacs-orgmode@gnu.org; Sat, 12 Feb 2011 08:14:48 -0500 Received: by mail-fx0-f41.google.com with SMTP id 12so3847492fxm.0 for ; Sat, 12 Feb 2011 05:14:48 -0800 (PST) In-Reply-To: (Samuel Wales's message of "Fri, 11 Feb 2011 10:58:23 -0700") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Samuel Wales Cc: Gregor Kappler , emacs-orgmode@gnu.org Hi Samuel, Samuel Wales writes: > I think your reluctance to change the syntax is understandable. Then > again, I'm a proponent of simple syntax. That is one reason I like > Lisp. So do I. My other concern is backward compatibility, and burden any change about this may put on third-part tools (like the python parsers and so on.) >> org-git-link.el is quite readable, and I'd welcome ideas on how to >> extend it to fulfill your wishes without extending Org's link syntax >> too much... > > It can be done without extending Org's link syntax at all. How? I managed to hack something with git links looking like git:/file/::master{...}::textsearchstring When I say it doesn't stick to the simple stored link syntax, I mean it requires additional "::". Which is not a big deal _per se_, and maybe I'll end up implementing this. > I think questions of syntax are important. Over time, syntaxes get > complicated, and we need more features, but fear to add them. > Sometimes we end up stuck in the middle, with complicated regexps, not > always factored, not quite sure how it will export or whether it can > be nested or combined or what other syntaxes it will work with or how > search will find it, but also lacking a feature somebody wants. > Adding a feature can sometimes raise questions of how to quote or > escape literal strings that look exactly like the special syntax for > the feature. I wrote about this in a post called parsing risk with > greater care than I can apply here. > > For new features, I think it would be good to consider extensible > syntax, which is a specific, documented proposal for a universal > syntax in which you can add things without breaking other things. A > very small amount of code is necessary to add a new subfeature to a > feature, and it is even possible to open it up to users. The parsing > and semantics are worked out once, and apply to all uses of extensible > syntax for all future features and subfeatures. You can have > confidence that the feature or subfeature you are adding will not have > syntax problems. > > (By the way, extensible syntax is a specific proposal for org that > enables many different possible future features, not the general idea > of extending syntax. Important not to be confused about that. If you > want to add to link syntax, you are not doing extensible syntax. But > you can use extensible syntax to implement /any type of link you want > with any subfeatures you want including git features/. For example, I > supplied an example that allows link coloring according to whether the > link was visited recently. And I have been wanting another where you > can have bidirectional links using Org-IDs so that you can move both > ends of the link anywhere you want -- and automatic labels. All of > this is feasible with a single syntax, so we don't have to pull our > hair out over unintended consequences.) Nice thoughts, I share the spirit of it. > Some previous posts: > > http://www.mail-archive.com/emacs-orgmode@gnu.org/msg28464.html I've reread this. The proposed syntax is clean, but implementing this is certainly a daunting task, and discussing the theorical benefits of such a change is not high on my todo list right now... > Perhaps this is something to consider. It is -- there are enough brains here to let the discussion grow in a useful way, and this list is not a place where we close doors :) Thanks, -- Bastien