emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Bastien <bastien.guerry@wikimedia.fr>
Cc: Gregor Kappler <gregor.kappler@univie.ac.at>, emacs-orgmode@gnu.org
Subject: Re: org-git-link does not support locational information within file
Date: Fri, 11 Feb 2011 10:58:23 -0700	[thread overview]
Message-ID: <AANLkTikySw5h3iS-koj1jj0Cf0Ab9NKsouvbGAogUFQx@mail.gmail.com> (raw)
In-Reply-To: <87zkq2trqx.fsf@gnu.org>

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/emacs-orgmode@gnu.org/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	other threads:[~2011-02-11 17:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03 15:04 org-git-link does not support locational information within file Gregor Kappler
2011-02-11 17:17 ` Bastien
2011-02-11 17:58   ` Samuel Wales [this message]
2011-02-11 18:05     ` Samuel Wales
2011-02-12 11:17     ` Bastien
2011-02-12 20:44       ` Samuel Wales
2011-02-13 12:20   ` Achim Gratz
2011-02-15 20:11   ` Gregor Kappler
2011-02-13  8:14 ` Leo Alekseyev
2011-02-15 20:15   ` Gregor Kappler

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=AANLkTikySw5h3iS-koj1jj0Cf0Ab9NKsouvbGAogUFQx@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=bastien.guerry@wikimedia.fr \
    --cc=emacs-orgmode@gnu.org \
    --cc=gregor.kappler@univie.ac.at \
    /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).