emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Eric Schulte" <schulte.eric@gmail.com>
To: Samuel Wales <samologist@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Feature request: IDs on anything
Date: Fri, 06 Mar 2009 06:23:14 -0800	[thread overview]
Message-ID: <87ab7y3f3h.fsf@gmail.com> (raw)
In-Reply-To: <20524da70903051728m4005f584p6b7b247e3b29936e@mail.gmail.com> (Samuel Wales's message of "Thu, 5 Mar 2009 18:28:39 -0700")

Hi,

Lots of interesting ideas, and cool syntax options.  My one proposed
modification would be to only allow linking down to the table or list
level, and then use existing reference syntax combined with the link to
reference a particular cell or range inside of a table, or a particular
element of a list.  Maybe something like

  $[id B7423F4D-2E8A-471B-8810-C40F074717E9 range: @1$3..@3$3]

Is this wholly new link syntax, or did I miss something?

Thanks -- eric

Samuel Wales <samologist@gmail.com> writes:

> Now seems like an ideal time to post this.
>
> I have been thinking that it would be useful to be able to slap org IDs on
> anything.  This includes plain list items, table cells, and
> specific words in long sections of text.[1]  Links to
> these markers will never be broken and will go to their
> exact locations.
>
> I am calling them =ID markers=.  The syntax looks like
> this.[2]
>
>   $[id B7423F4D-2E8A-471B-8810-C40F074717E9]
>
> Here is an example:
>
>   - this is a plain list
>     - example $[id B7423F4D-2E8A-471B-8810-C40F074717E9]
>     - the above can safely be linked to
>
> You can label markers to make them prettier:
>
>   $[id B7423F4D-2E8A-471B-8810-C40F074717E9 :label "foo"]
>     this is a marker labeled "foo" (similarly to how links
>     are labeled).
>
>   $[id B7423F4D-2E8A-471B-8810-C40F074717E9 :label ""]
>     now the marker is invisible unless you set links to be
>     visible or go to and edit the marker.[3]
>
> A key aspect of this feature is that it is extensible[2]
> in various[4] ways.
>
>
> I have more notes, including applications, but also want to
> gauge interest in the basic idea.
>
> Is this appealing?
>
>
> Footnotes:
>
> [1] This might also work for Charles Cave's thread, "My
> Python solution [...]", which seeks IDs or the equivalent in
> headlines.
>
> ID markers should work in non-org files (provided that org
> is told about their existence via a user variable).  Thus,
> you can safely link to source code.
>
> [2] This syntax is motivated in a thread on the org
> mailing list (
> [http://www.google.com/search?num=100&hl=en&ie=UTF-8&oe=UTF-8&q=%22extensible+syntax%22+%22parsing+risk%22+%22samuel+wales%22&btnG=Search]
> ) named "extensible syntax".  Some benefits:
>
>   1.  You can add /new/ org features.
>       - This is done by reserving a new first element.
>       - For example, the keyword for the ID marker feature
>         is "id".
>       - If you want to add a new org feature for, say,
>         changing the color of a region of text, you would
>         use the keyword "color".
>         - You can do this with no new lexing code or syntax
>           debugging.
>   2.  You can extend /existing/ features.
>       - This is done with a keyword argument (plist key).
>       - For example, ID markers accept a :label keyword.
>       - To make the label be different in the exported text,
>         the key would be :export-label.
>       - To turn an ID marker into a link, the key would
>         be :link and its argument would be the link itself.
>         - I will motivate this and its applications in
>           another thread.  It enables the user to create
>           arbitrary graph-theoretic structures, including
>           bidirectional links and tours through a table, by
>           pointing ID markers to one another.  More later.
>       - No new lexing code or syntax debugging is necessary.
>
> A bonus: in principle, the facility can be opened up to the
> users, who can then experiment with new features in their
> .emacs files (without modifying org code) then spring them
> on the rest of us.  :) However, this is not essential to the
> idea.
>
> [3] I am not sure, but it is possible that running M-x
> visible-mode would also work.  Or perhaps a standard org
> command could do it.
>
> [4] For example, to make the label be different in the
> exported text, it could look like this:
>
>   $[id B7423F4D-2E8A-471B-8810-C40F074717E9
>        :label "foo"
>        :export-label "bar"]
>     the exported version is labeled "bar", while your source
>     is still nicely labeled "foo".
>
>   $[id B7423F4D-2E8A-471B-8810-C40F074717E9
>        :label "foo"
>        :export-label ""]
>     now it is invisible when exported.  but it can still be
>     pointed to.
>
> Or to make it easy to remember ID markers with a short
> number:
>
>   $[id B7423F4D-2E8A-471B-8810-C40F074717E9 :label :file-unique]
>     this is a marker labeled with a small, automatically
>     generated number that is only guaranteed to be unique
>     for the current file.
>
> My point in this footnote isn't that these are needed
> subfeatures, but that with extensible syntax we can do this
> kind of thing.

  parent reply	other threads:[~2009-03-06 14:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-06  1:28 Feature request: IDs on anything Samuel Wales
2009-03-06  9:32 ` Carsten Dominik
2010-08-10 23:20   ` Samuel Wales
2010-08-10 23:44     ` Samuel Wales
2009-03-06 14:23 ` Eric Schulte [this message]
2009-03-06 16:27   ` Carsten Dominik

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=87ab7y3f3h.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=samologist@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).