emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Feature request: IDs on anything


From: Carsten Dominik
Subject: Re: [Orgmode] Feature request: IDs on anything
Date: Fri, 6 Mar 2009 10:32:55 +0100

Hi Samuel,

I do remember the earlier discussion we had about this.  I
can see how using IDs for more localized linking could be
useful, and how this kind of extensible syntax could be useful.

I do have my doubts how IDs in source coude files would work,
because I am not sure how Org should be able to keep track of
source code files as they are moving around or even copied
(maybe these days, if people use versioning, this is not
such a big issue, but I know that many people maintain
versions of code by copying).  I cannot think of a reliable
way to make this work, besides, maybe,  API calls to some
global indexing tool.

I also cannot see how this would be used for individual
table fields, conflicts with spreadsheet formulas would
easily arise and be very complex.

But would like to learn more about your ideas for applications.

- Carsten

On Mar 6, 2009, at 2:28 AM, Samuel Wales wrote:

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.

--
Myalgic encephalomyelitis denialism is causing death (decades early;
Jason et al. 2006) and severe suffering (worse than nearly all other
diseases studied; e.g. Schweitzer et al. 1995) and *grossly*
corrupting science.
http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm


_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode





reply via email to

[Prev in Thread] Current Thread [Next in Thread]