Hi Samuel,
Samuel Wales <samolog...@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
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
