emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] org-git-link does not support locational information withi


From: Samuel Wales
Subject: Re: [Orgmode] org-git-link does not support locational information within file
Date: Fri, 11 Feb 2011 10:58:23 -0700

Hi Bastien,

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.

> 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.

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.)

In the case of git links, we can add as many new git features as we
want without breaking anything.  The syntax can follow git's syntax
without having to figure out how to translate it or delimit it or work
out special cases.

I have more notes on this but cannot supply them now.

Some previous posts:

  http://www.mail-archive.com/address@hidden/msg28464.html
  http://thread.gmane.org/gmane.emacs.orgmode/11896
  http://thread.gmane.org/gmane.emacs.orgmode/10204/focus=10240

Perhaps this is something to consider.

Samuel

-- 
The Kafka Pandemic:
http://thekafkapandemic.blogspot.com/2010/12/welcome-to-kafka-pandemic-two-forces_9182.html
I support the Whittemore-Peterson Institute (WPI)
===
I want to see the original (pre-hold) Lo et al. 2010 NIH/FDA/Harvard MLV paper.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]