Re: Feature request: IDs on anything

From: Carsten Dominik <dominik@science.uva.nl>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Feature request: IDs on anything
Date: Fri, 6 Mar 2009 17:27:41 +0100	[thread overview]
Message-ID: <6CA4A475-5A74-4199-B883-5420EFA6B5B1@uva.nl> (raw)
In-Reply-To: <87ab7y3f3h.fsf@gmail.com>

On Mar 6, 2009, at 3:23 PM, Eric Schulte wrote:

> 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?

My understanding was that this is an anchor, not a link.
Only with a link property, it would become a link.

- Carsten

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