Re: [dev] Implement "ref" link types

[Samuel Wales <samologist@gmail.com>]

On 2012-02-19, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Ok, I found the thread[1] about extensible syntax for links.

Again this isn't just for links and if your syntax does all you ever
anticipate, then I like it.  I am talking about the future and the
difficulty of adding ad-hoc syntax fore new features /later/.

There are a few other threads (just FYI).  I might have them listed someplace.

Overview (also FYI): one concern is syntax creep in Org for new
features.  This affects external parsers and overall complexity and
nonorthogonality, and introduces parsing risk, in which there are many
gotchas -- such as inability to escape, quote, nest, pretty-print,
etc.  ES/US solves all of that in a single, simple way.

If all you're doing is the one set of features now, then your syntax
is great.  But I'm talking about the future.

> I don't think that it would be a good idea to use a completely different
> syntax for just one type of link. Either we change the whole link system

No, it's not for just one type of link.  It applies to new features
also, not just for ref links but for ID markers (links to anything,
even words, using Org ID), very fancy dates that have features that
are too difficult to include in existing date syntax, annotation of
words or paragraphs or elements, maybe fancy detangling, browser-like
link coloring by expiry and cached links, digraphs, undirected graphs
including bidirectional links, super-fancy footnotes, any new feature
we do not currently anticipate for the ref syntax or any other feature
that would create nonorthogonality and complexity in existing syntax,
and many new features we haven't thought of.

It won't replace existing syntax.  It's for new features.

One point is that when we address something (such as nestability) for
one new feature, it works for all others automatically.

> into the extensible syntax proposal, or we don't change it at
> all. I don't mind either way, but that's orthogonal to the problem at
> hand.

Again I think your syntax is great if that is all it is going to do.
All I am doing is raising a possible alternative way of doing it.  If
you don't like it, that's fine.

But my point is that if we only look at the problem at hand, we get
syntax creep -- because new features are not at hand.  Think of how
dates now have to deal with deadlines, repeaters, etc.  That's OK, but
it's going to get harder to add new features to them.  I'm not saying
to replace dates, but for many new features, we might want to try
something more orthogonal and extensible and universal.

>> For example, you might want to put the target anywhere, not just where
>> there are elements.
>
> Org already has targets for that: <<anywhere>> and [[anywhere]].  The

Those do not use the Org ID mechanism, so they are brittle and don't
operate across files in the same way Org IDs can (IIRC -- do they?).

Again it's an example of how the syntax can add features without
making parsing difficult.  This all concerns future features, not
anything today.

Just something to consider.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com