emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Feature request: IDs on anything
@ 2009-03-06  1:28 Samuel Wales
  2009-03-06  9:32 ` Carsten Dominik
  2009-03-06 14:23 ` Eric Schulte
  0 siblings, 2 replies; 6+ messages in thread
From: Samuel Wales @ 2009-03-06  1:28 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Feature request: IDs on anything
  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
  2009-03-06 14:23 ` Eric Schulte
  1 sibling, 1 reply; 6+ messages in thread
From: Carsten Dominik @ 2009-03-06  9:32 UTC (permalink / raw)
  To: Samuel Wales; +Cc: emacs-orgmode

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.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Feature request: IDs on anything
  2009-03-06  1:28 Feature request: IDs on anything Samuel Wales
  2009-03-06  9:32 ` Carsten Dominik
@ 2009-03-06 14:23 ` Eric Schulte
  2009-03-06 16:27   ` Carsten Dominik
  1 sibling, 1 reply; 6+ messages in thread
From: Eric Schulte @ 2009-03-06 14:23 UTC (permalink / raw)
  To: Samuel Wales; +Cc: emacs-orgmode

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Feature request: IDs on anything
  2009-03-06 14:23 ` Eric Schulte
@ 2009-03-06 16:27   ` Carsten Dominik
  0 siblings, 0 replies; 6+ messages in thread
From: Carsten Dominik @ 2009-03-06 16:27 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Feature request: IDs on anything
  2009-03-06  9:32 ` Carsten Dominik
@ 2010-08-10 23:20   ` Samuel Wales
  2010-08-10 23:44     ` Samuel Wales
  0 siblings, 1 reply; 6+ messages in thread
From: Samuel Wales @ 2010-08-10 23:20 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: emacs-orgmode

I wrote this a long time ago in response to Carsten's reply
to Eric in the first link below.

===

  1) http://thread.gmane.org/gmane.emacs.orgmode/11896
     extensible syntax with an application in id markers
     (which themselves have an application in many things,
     including graph theoretic constructs such as planning
     tours)
  2) http://thread.gmane.org/gmane.emacs.orgmode/10204/focus=10240
     extensible syntax and parsing risk

===

Yes, ID markers are merely link /targets/.  :)

The :link option (which the user can decide to put in or
leave out) turns them into link /sources/ (clickable and
RET-able elements) also.  This allows bidirectional links by
having two ID markers link to each other.[fn:46] A future
post will describe an application.

Perhaps you are thinking of new link features beyond :link?
These are possible, but they are not part of my proposal.

For example, you know how in a browser the links change
color if you have visited them in the last n days?  It
usually seems to be blue links turning red.  That helps you
keep track of things.

If it is ever desired, we can implement this in org.  We add
an option, :last-followed, which contains a timestamp for
the last time you followed the link.  When that timestamp is
within the last n days, org changes the color of the ID
marker's label to red.  (Or it can make it more red the
longer it's been.  Or show how many days it's been.)

I'm *not* saying this feature is necessary, of course (it
isn't).  The point is just that the syntax is robust against
the future, including ideas like this.

P.S.

You don't have to use an ID marker if you never want to
point to it.  If you still wanted fancy link features, then
you could implement something like this instead of using ID
markers.

  $[link http://google.com
         :last-followed [2009-02-27 Fri 02:00]
         :label "click here for evil search engine"
         :export-label "click here for nice search engine"]

(I threw in an export label just for fun.)

But I'm only proposing ID markers (and extensible syntax).

[fn:46] :link enables bidirectional links, rings, DAGs,
tours (e.g. for tutorials), multiple planning sequences,
Bayes nets, decision trees that span the outline's ontology
structure, and adventure games.  In graph-theoretic terms,
an ID marker that uses the :link option is an =arc=;
wherever you place it becomes a =node=.  Arcs can be
unidirectional or bidirectional.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Feature request: IDs on anything
  2010-08-10 23:20   ` Samuel Wales
@ 2010-08-10 23:44     ` Samuel Wales
  0 siblings, 0 replies; 6+ messages in thread
From: Samuel Wales @ 2010-08-10 23:44 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: emacs-orgmode

On 2010-08-10, Samuel Wales <samologist@gmail.com> wrote:
> I wrote this a long time ago in response to Carsten's reply
> to Eric in the first link below.

I guess it was a response to Eric.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-08-10 23:44 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2009-03-06 16:27   ` Carsten Dominik

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).