Re: org-git-link does not support locational information within file

[Bastien <bastien.guerry@wikimedia.fr>]

Hi Samuel,

Samuel Wales <samologist@gmail.com> 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