From: Samuel Wales <samologist@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [dev] Implement "ref" link types
Date: Sun, 19 Feb 2012 13:48:50 -0700 [thread overview]
Message-ID: <CAJcAo8t9h98aT-i-0j_xzoTJ81ocGN6mO5Vp+4BWTzCLVe6j3A@mail.gmail.com> (raw)
In-Reply-To: <87linyvbf7.fsf@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
next prev parent reply other threads:[~2012-02-19 20:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-19 18:08 [dev] Implement "ref" link types Nicolas Goaziou
2012-02-19 19:28 ` Christian Moe
2012-02-19 19:41 ` Nicolas Goaziou
2012-02-19 20:11 ` Toby Cubitt
2012-02-19 20:20 ` Christian Moe
2012-02-19 19:41 ` Samuel Wales
2012-02-19 20:02 ` Nicolas Goaziou
2012-02-19 20:48 ` Samuel Wales [this message]
2012-02-19 20:10 ` Carsten Dominik
2012-02-20 0:51 ` Nicolas Goaziou
2012-02-20 7:09 ` Carsten Dominik
2012-02-20 10:59 ` Nicolas Goaziou
2012-02-20 22:06 ` Nicolas Goaziou
2012-02-21 1:26 ` Thomas S. Dye
2012-02-21 5:14 ` David Maus
2012-02-21 9:18 ` Nicolas Goaziou
2012-02-27 19:38 ` Nicolas Goaziou
2012-02-27 20:38 ` David Maus
2012-03-05 9:37 ` Jambunathan K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJcAo8t9h98aT-i-0j_xzoTJ81ocGN6mO5Vp+4BWTzCLVe6j3A@mail.gmail.com \
--to=samologist@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).