Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
;;; org-id.el --- Global identifiers for Org-mode entries
|
2009-01-06 04:47:36 -05:00
|
|
|
;;
|
|
|
|
;; Copyright (C) 2008, 2009 Free Software Foundation, Inc.
|
2008-02-26 11:43:55 -05:00
|
|
|
;;
|
|
|
|
;; Author: Carsten Dominik <carsten at orgmode dot org>
|
|
|
|
;; Keywords: outlines, hypermedia, calendar, wp
|
|
|
|
;; Homepage: http://orgmode.org
|
2009-11-20 06:34:50 -05:00
|
|
|
;; Version: 6.33d
|
2008-02-26 11:43:55 -05:00
|
|
|
;;
|
2008-05-15 04:28:38 -04:00
|
|
|
;; This file is part of GNU Emacs.
|
2008-02-26 11:43:55 -05:00
|
|
|
;;
|
2008-05-15 04:28:38 -04:00
|
|
|
;; GNU Emacs is free software: you can redistribute it and/or modify
|
2008-02-26 11:43:55 -05:00
|
|
|
;; it under the terms of the GNU General Public License as published by
|
2008-05-15 04:28:38 -04:00
|
|
|
;; the Free Software Foundation, either version 3 of the License, or
|
|
|
|
;; (at your option) any later version.
|
2008-02-26 11:43:55 -05:00
|
|
|
|
|
|
|
;; GNU Emacs is distributed in the hope that it will be useful,
|
|
|
|
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
;; GNU General Public License for more details.
|
|
|
|
|
|
|
|
;; You should have received a copy of the GNU General Public License
|
2008-05-15 04:28:38 -04:00
|
|
|
;; along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
|
2008-02-26 11:43:55 -05:00
|
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
|
|
;;
|
|
|
|
;;; Commentary:
|
|
|
|
|
|
|
|
;; This file implements globally unique identifiers for Org-mode entries.
|
2008-04-28 04:48:49 -04:00
|
|
|
;; Identifiers are stored in the entry as an :ID: property. Functions
|
|
|
|
;; are provided that create and retrieve such identifiers, and that find
|
|
|
|
;; entries based on the identifier.
|
|
|
|
|
2008-09-11 10:56:37 -04:00
|
|
|
;; Identifiers consist of a prefix (default "Org" given by the variable
|
|
|
|
;; `org-id-prefix') and a unique part that can be created by a number
|
|
|
|
;; of different methods, see the variable `org-id-method'.
|
|
|
|
;; Org has a builtin method that uses a compact encoding of the creation
|
|
|
|
;; time of the ID, with microsecond accuracy. This virtually
|
2008-04-28 04:48:49 -04:00
|
|
|
;; guarantees globally unique identifiers, even if several people are
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
;; creating IDs at the same time in files that will eventually be used
|
2008-12-16 09:25:09 -05:00
|
|
|
;; together. As an external method `uuidgen' is supported, if installed
|
2008-09-11 10:56:37 -04:00
|
|
|
;; on the system.
|
2008-02-27 08:32:17 -05:00
|
|
|
;;
|
2008-04-28 04:48:49 -04:00
|
|
|
;; This file defines the following API:
|
2008-02-27 08:32:17 -05:00
|
|
|
;;
|
2008-05-15 04:28:38 -04:00
|
|
|
;; org-id-get-create
|
2008-02-27 08:32:17 -05:00
|
|
|
;; Create an ID for the entry at point if it does not yet have one.
|
|
|
|
;; Returns the ID (old or new). This function can be used
|
|
|
|
;; interactively, with prefix argument the creation of a new ID is
|
|
|
|
;; forced, even if there was an old one.
|
|
|
|
;;
|
2008-02-26 11:43:55 -05:00
|
|
|
;; org-id-get
|
|
|
|
;; Get the ID property of an entry. Using appropriate arguments
|
2008-02-27 08:32:17 -05:00
|
|
|
;; to the function, it can also create the ID for this entry.
|
|
|
|
;;
|
|
|
|
;; org-id-goto
|
|
|
|
;; Command to go to a specific ID, this command can be used
|
|
|
|
;; interactively.
|
|
|
|
;;
|
|
|
|
;; org-id-get-with-outline-path-completion
|
|
|
|
;; Retrieve the ID of an entry, using outline path completion.
|
|
|
|
;; This function can work for multiple files.
|
|
|
|
;;
|
|
|
|
;; org-id-get-with-outline-drilling
|
|
|
|
;; Retrieve the ID of an entry, using outline path completion.
|
|
|
|
;; This function only works for the current file.
|
|
|
|
;;
|
|
|
|
;; org-id-find
|
|
|
|
;; Find the location of an entry with specific id.
|
2008-02-26 11:43:55 -05:00
|
|
|
;;
|
|
|
|
|
|
|
|
(require 'org)
|
|
|
|
|
2008-05-15 04:28:38 -04:00
|
|
|
(declare-function message-make-fqdn "message" ())
|
|
|
|
|
2008-02-27 08:32:17 -05:00
|
|
|
;;; Customization
|
|
|
|
|
2008-02-26 11:43:55 -05:00
|
|
|
(defgroup org-id nil
|
|
|
|
"Options concerning global entry identifiers in Org-mode."
|
|
|
|
:tag "Org ID"
|
|
|
|
:group 'org)
|
|
|
|
|
2009-07-23 20:29:56 -04:00
|
|
|
(defcustom org-id-uuid-program "uuidgen"
|
|
|
|
"The uuidgen program."
|
|
|
|
:group 'org-id
|
|
|
|
:type 'string)
|
2008-09-11 10:56:37 -04:00
|
|
|
|
2008-12-16 11:58:07 -05:00
|
|
|
(defcustom org-id-method
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(condition-case nil
|
|
|
|
(if (string-match "\\`[-0-9a-fA-F]\\{36\\}\\'"
|
2009-08-03 11:30:30 -04:00
|
|
|
(org-trim (shell-command-to-string
|
2009-07-23 20:29:56 -04:00
|
|
|
org-id-uuid-program)))
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
'uuidgen
|
|
|
|
'org)
|
|
|
|
(error 'org))
|
|
|
|
"The method that should be used to create new IDs.
|
|
|
|
|
|
|
|
If `uuidgen' is available on the system, it will be used as the default method.
|
2008-12-16 09:25:09 -05:00
|
|
|
if not, the method `org' is used.
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
An ID will consist of the optional prefix specified in `org-id-prefix',
|
|
|
|
and a unique part created by the method this variable specifies.
|
2008-09-11 10:56:37 -04:00
|
|
|
|
|
|
|
Allowed values are:
|
|
|
|
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
org Org's own internal method, using an encoding of the current time to
|
|
|
|
microsecond accuracy, and optionally the current domain of the
|
|
|
|
computer. See the variable `org-id-include-domain'.
|
2008-09-11 10:56:37 -04:00
|
|
|
|
|
|
|
uuidgen Call the external command uuidgen."
|
|
|
|
:group 'org-id
|
|
|
|
:type '(choice
|
|
|
|
(const :tag "Org's internal method" org)
|
|
|
|
(const :tag "external: uuidgen" uuidgen)))
|
|
|
|
|
2008-10-01 03:25:18 -04:00
|
|
|
(defcustom org-id-prefix nil
|
2008-04-28 04:48:49 -04:00
|
|
|
"The prefix for IDs.
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-04-28 04:48:49 -04:00
|
|
|
This may be a string, or it can be nil to indicate that no prefix is required.
|
|
|
|
When a string, the string should have no space characters as IDs are expected
|
|
|
|
to have no space characters in them."
|
|
|
|
:group 'org-id
|
|
|
|
:type '(choice
|
|
|
|
(const :tag "No prefix")
|
|
|
|
(string :tag "Prefix")))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(defcustom org-id-include-domain nil
|
2008-05-15 03:39:34 -04:00
|
|
|
"Non-nil means, add the domain name to new IDs.
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
This ensures global uniqueness of IDs, and is also suggested by
|
2008-09-11 10:56:37 -04:00
|
|
|
RFC 2445 in combination with RFC 822. This is only relevant if
|
|
|
|
`org-id-method' is `org'. When uuidgen is used, the domain will never
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
be added.
|
|
|
|
The default is to not use this because we have no really good way to get
|
|
|
|
the true domain, and Org entries will normally not be shared with enough
|
|
|
|
people to make this necessary."
|
|
|
|
:group 'org-id
|
|
|
|
:type 'boolean)
|
|
|
|
|
|
|
|
(defcustom org-id-track-globally t
|
2008-12-16 09:25:09 -05:00
|
|
|
"Non-nil means, track IDs through files, so that links work globally.
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
This work by maintaining a hash table for IDs and writing this table
|
|
|
|
to disk when exiting Emacs. Because of this, it works best if you use
|
|
|
|
a single Emacs process, not many.
|
|
|
|
|
|
|
|
When nil, IDs are not tracked. Links to IDs will still work within
|
|
|
|
a buffer, but not if the entry is located in another file.
|
|
|
|
IDs can still be used if the entry with the id is in the same file as
|
|
|
|
the link."
|
2008-05-15 03:39:34 -04:00
|
|
|
:group 'org-id
|
|
|
|
:type 'boolean)
|
|
|
|
|
2008-10-19 14:55:36 -04:00
|
|
|
(defcustom org-id-locations-file (convert-standard-filename
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
"~/.emacs.d/.org-id-locations")
|
|
|
|
"The file for remembering in which file an ID was defined.
|
|
|
|
This variable is only relevant when `org-id-track-globally' is set."
|
2008-02-26 11:43:55 -05:00
|
|
|
:group 'org-id
|
2008-02-27 08:32:17 -05:00
|
|
|
:type 'file)
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-02-27 08:32:17 -05:00
|
|
|
(defvar org-id-locations nil
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
"List of files with IDs in those files.
|
|
|
|
Depending on `org-id-use-hash' this can also be a hash table mapping IDs
|
|
|
|
to files.")
|
|
|
|
|
|
|
|
(defvar org-id-files nil
|
|
|
|
"List of files that contain IDs.")
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-04-28 04:48:49 -04:00
|
|
|
(defcustom org-id-extra-files 'org-agenda-text-search-extra-files
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
"Files to be searched for IDs, besides the agenda files.
|
|
|
|
When Org reparses files to remake the list of files and IDs it is tracking,
|
|
|
|
it will normally scan the agenda files, the archives related to agenda files,
|
|
|
|
any files that are listed as ID containing in the current register, and
|
|
|
|
any Org-mode files currently visited by Emacs.
|
|
|
|
You can list additional files here.
|
|
|
|
This variable is only relevant when `org-id-track-globally' is set."
|
2008-02-27 08:32:17 -05:00
|
|
|
:group 'org-id
|
|
|
|
:type
|
|
|
|
'(choice
|
|
|
|
(symbol :tag "Variable")
|
|
|
|
(repeat :tag "List of files"
|
|
|
|
(file))))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-11-17 04:27:44 -05:00
|
|
|
(defcustom org-id-search-archives t
|
|
|
|
"Non-nil means, search also the archive files of agenda files for entries.
|
2008-12-16 09:25:09 -05:00
|
|
|
This is a possibility to reduce overhead, but it means that entries moved
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
to the archives can no longer be found by ID.
|
|
|
|
This variable is only relevant when `org-id-track-globally' is set."
|
2008-11-17 04:27:44 -05:00
|
|
|
:group 'org-id
|
|
|
|
:type 'boolean)
|
|
|
|
|
2008-02-27 08:32:17 -05:00
|
|
|
;;; The API functions
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-05-15 04:28:38 -04:00
|
|
|
;;;###autoload
|
|
|
|
(defun org-id-get-create (&optional force)
|
2008-02-27 08:32:17 -05:00
|
|
|
"Create an ID for the current entry and return it.
|
|
|
|
If the entry already has an ID, just return it.
|
|
|
|
With optional argument FORCE, force the creation of a new ID."
|
|
|
|
(interactive "P")
|
|
|
|
(when force
|
|
|
|
(org-entry-put (point) "ID" nil))
|
|
|
|
(org-id-get (point) 'create))
|
2008-12-04 09:33:43 -05:00
|
|
|
|
2008-05-15 04:28:38 -04:00
|
|
|
;;;###autoload
|
2008-02-27 08:32:17 -05:00
|
|
|
(defun org-id-copy ()
|
|
|
|
"Copy the ID of the entry at point to the kill ring.
|
|
|
|
Create an ID if necessary."
|
|
|
|
(interactive)
|
2009-06-30 01:24:57 -04:00
|
|
|
(org-kill-new (org-id-get nil 'create)))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-05-15 04:28:38 -04:00
|
|
|
;;;###autoload
|
2008-04-28 04:48:49 -04:00
|
|
|
(defun org-id-get (&optional pom create prefix)
|
2008-02-26 11:43:55 -05:00
|
|
|
"Get the ID property of the entry at point-or-marker POM.
|
|
|
|
If POM is nil, refer to the entry at point.
|
|
|
|
If the entry does not have an ID, the function returns nil.
|
|
|
|
However, when CREATE is non nil, create an ID if none is present already.
|
2008-04-28 04:48:49 -04:00
|
|
|
PREFIX will be passed through to `org-id-new'.
|
2008-02-26 11:43:55 -05:00
|
|
|
In any case, the ID of the entry is returned."
|
2009-09-15 14:10:53 -04:00
|
|
|
(org-with-point-at pom
|
|
|
|
(let ((id (org-entry-get nil "ID")))
|
|
|
|
(cond
|
|
|
|
((and id (stringp id) (string-match "\\S-" id))
|
|
|
|
id)
|
|
|
|
(create
|
|
|
|
(setq id (org-id-new prefix))
|
|
|
|
(org-entry-put pom "ID" id)
|
|
|
|
(org-id-add-location id (buffer-file-name (buffer-base-buffer)))
|
|
|
|
id)
|
|
|
|
(t nil)))))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-05-15 04:28:38 -04:00
|
|
|
;;;###autoload
|
2008-02-26 11:43:55 -05:00
|
|
|
(defun org-id-get-with-outline-path-completion (&optional targets)
|
2008-02-27 08:32:17 -05:00
|
|
|
"Use outline-path-completion to retrieve the ID of an entry.
|
2008-04-28 04:58:29 -04:00
|
|
|
TARGETS may be a setting for `org-refile-targets' to define the eligible
|
2008-02-26 11:43:55 -05:00
|
|
|
headlines. When omitted, all headlines in all agenda files are
|
2008-04-28 04:58:29 -04:00
|
|
|
eligible.
|
2008-02-27 08:32:17 -05:00
|
|
|
It returns the ID of the entry. If necessary, the ID is created."
|
2008-02-26 11:43:55 -05:00
|
|
|
(let* ((org-refile-targets (or targets '((nil . (:maxlevel . 10)))))
|
2008-12-04 09:33:43 -05:00
|
|
|
(org-refile-use-outline-path
|
2008-02-26 11:43:55 -05:00
|
|
|
(if (caar org-refile-targets) 'file t))
|
2009-04-17 11:57:18 -04:00
|
|
|
(org-refile-target-verify-function nil)
|
2008-02-26 11:43:55 -05:00
|
|
|
(spos (org-refile-get-location "Entry: "))
|
2008-12-04 09:33:43 -05:00
|
|
|
(pom (and spos (move-marker (make-marker) (nth 3 spos)
|
2008-02-26 11:43:55 -05:00
|
|
|
(get-file-buffer (nth 1 spos))))))
|
2008-04-28 04:48:49 -04:00
|
|
|
(prog1 (org-id-get pom 'create)
|
|
|
|
(move-marker pom nil))))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-05-15 04:28:38 -04:00
|
|
|
;;;###autoload
|
2008-02-26 11:43:55 -05:00
|
|
|
(defun org-id-get-with-outline-drilling (&optional targets)
|
2008-02-27 08:32:17 -05:00
|
|
|
"Use an outline-cycling interface to retrieve the ID of an entry.
|
2008-02-26 11:43:55 -05:00
|
|
|
This only finds entries in the current buffer, using `org-get-location'.
|
2008-02-27 08:32:17 -05:00
|
|
|
It returns the ID of the entry. If necessary, the ID is created."
|
2008-02-26 11:43:55 -05:00
|
|
|
(let* ((spos (org-get-location (current-buffer) org-goto-help))
|
|
|
|
(pom (and spos (move-marker (make-marker) (car spos)))))
|
2008-04-28 04:48:49 -04:00
|
|
|
(prog1 (org-id-get pom 'create)
|
|
|
|
(move-marker pom nil))))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-05-15 04:28:38 -04:00
|
|
|
;;;###autoload
|
2008-02-27 08:32:17 -05:00
|
|
|
(defun org-id-goto (id)
|
|
|
|
"Switch to the buffer containing the entry with id ID.
|
|
|
|
Move the cursor to that entry in that buffer."
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(interactive "sID: ")
|
2008-02-27 08:32:17 -05:00
|
|
|
(let ((m (org-id-find id 'marker)))
|
|
|
|
(unless m
|
|
|
|
(error "Cannot find entry with ID \"%s\"" id))
|
|
|
|
(switch-to-buffer (marker-buffer m))
|
|
|
|
(goto-char m)
|
2008-04-28 04:48:49 -04:00
|
|
|
(move-marker m nil)
|
2008-12-04 09:33:43 -05:00
|
|
|
(org-show-context)))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-05-15 04:28:38 -04:00
|
|
|
;;;###autoload
|
2008-02-27 08:32:17 -05:00
|
|
|
(defun org-id-find (id &optional markerp)
|
|
|
|
"Return the location of the entry with the id ID.
|
|
|
|
The return value is a cons cell (file-name . position), or nil
|
|
|
|
if there is no entry with that ID.
|
2008-04-28 04:48:49 -04:00
|
|
|
With optional argument MARKERP, return the position as a new marker."
|
2008-12-22 02:13:20 -05:00
|
|
|
(cond
|
|
|
|
((symbolp id) (setq id (symbol-name id)))
|
|
|
|
((numberp id) (setq id (number-to-string id))))
|
2008-02-27 08:32:17 -05:00
|
|
|
(let ((file (org-id-find-id-file id))
|
|
|
|
org-agenda-new-buffers where)
|
|
|
|
(when file
|
|
|
|
(setq where (org-id-find-id-in-file id file markerp)))
|
|
|
|
(unless where
|
|
|
|
(org-id-update-id-locations)
|
|
|
|
(setq file (org-id-find-id-file id))
|
|
|
|
(when file
|
|
|
|
(setq where (org-id-find-id-in-file id file markerp))))
|
|
|
|
where))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-02-27 08:32:17 -05:00
|
|
|
;;; Internal functions
|
|
|
|
|
2008-04-28 04:48:49 -04:00
|
|
|
;; Creating new IDs
|
2008-02-27 08:32:17 -05:00
|
|
|
|
2008-04-28 04:48:49 -04:00
|
|
|
(defun org-id-new (&optional prefix)
|
2008-02-27 08:32:17 -05:00
|
|
|
"Create a new globally unique ID.
|
2008-04-28 04:48:49 -04:00
|
|
|
|
|
|
|
An ID consists of two parts separated by a colon:
|
|
|
|
- a prefix
|
2008-09-11 10:56:37 -04:00
|
|
|
- a unique part that will be created according to `org-id-method'.
|
2008-04-28 04:48:49 -04:00
|
|
|
|
|
|
|
PREFIX can specify the prefix, the default is given by the variable
|
|
|
|
`org-id-prefix'. However, if PREFIX is the symbol `none', don't use any
|
|
|
|
prefix even if `org-id-prefix' specifies one.
|
|
|
|
|
|
|
|
So a typical ID could look like \"Org:4nd91V40HI\"."
|
|
|
|
(let* ((prefix (if (eq prefix 'none)
|
2008-09-11 10:56:37 -04:00
|
|
|
""
|
|
|
|
(concat (or prefix org-id-prefix) ":")))
|
|
|
|
unique)
|
|
|
|
(if (equal prefix ":") (setq prefix ""))
|
|
|
|
(cond
|
|
|
|
((eq org-id-method 'uuidgen)
|
2009-07-23 20:29:56 -04:00
|
|
|
(setq unique (org-trim (shell-command-to-string org-id-uuid-program))))
|
2008-09-11 10:56:37 -04:00
|
|
|
((eq org-id-method 'org)
|
2008-10-01 03:25:18 -04:00
|
|
|
(let* ((etime (org-id-reverse-string (org-id-time-to-b36)))
|
2008-09-11 10:56:37 -04:00
|
|
|
(postfix (if org-id-include-domain
|
|
|
|
(progn
|
|
|
|
(require 'message)
|
|
|
|
(concat "@" (message-make-fqdn))))))
|
|
|
|
(setq unique (concat etime postfix))))
|
|
|
|
(t (error "Invalid `org-id-method'")))
|
|
|
|
(concat prefix unique)))
|
2008-04-28 04:48:49 -04:00
|
|
|
|
2008-10-01 03:25:18 -04:00
|
|
|
(defun org-id-reverse-string (s)
|
|
|
|
(mapconcat 'char-to-string (nreverse (string-to-list s)) ""))
|
|
|
|
|
|
|
|
(defun org-id-int-to-b36-one-digit (i)
|
2008-04-28 04:48:49 -04:00
|
|
|
"Turn an integer between 0 and 61 into a single character 0..9, A..Z, a..z."
|
|
|
|
(cond
|
|
|
|
((< i 10) (+ ?0 i))
|
2008-10-01 03:25:18 -04:00
|
|
|
((< i 36) (+ ?a i -10))
|
|
|
|
(t (error "Larger that 35"))))
|
2008-04-28 04:48:49 -04:00
|
|
|
|
2008-10-01 03:25:18 -04:00
|
|
|
(defun org-id-b36-to-int-one-digit (i)
|
2008-04-28 04:58:29 -04:00
|
|
|
"Turn a character 0..9, A..Z, a..z into a number 0..61.
|
2008-04-28 04:48:49 -04:00
|
|
|
The input I may be a character, or a single-letter string."
|
|
|
|
(and (stringp i) (setq i (string-to-char i)))
|
|
|
|
(cond
|
|
|
|
((and (>= i ?0) (<= i ?9)) (- i ?0))
|
2008-10-01 03:25:18 -04:00
|
|
|
((and (>= i ?a) (<= i ?z)) (+ (- i ?a) 10))
|
|
|
|
(t (error "Invalid b36 letter"))))
|
2008-04-28 04:48:49 -04:00
|
|
|
|
2008-10-01 03:25:18 -04:00
|
|
|
(defun org-id-int-to-b36 (i &optional length)
|
|
|
|
"Convert an integer to a base-36 number represented as a string."
|
2008-04-28 04:48:49 -04:00
|
|
|
(let ((s ""))
|
|
|
|
(while (> i 0)
|
|
|
|
(setq s (concat (char-to-string
|
2008-10-01 03:25:18 -04:00
|
|
|
(org-id-int-to-b36-one-digit (mod i 36))) s)
|
|
|
|
i (/ i 36)))
|
2008-04-28 04:48:49 -04:00
|
|
|
(setq length (max 1 (or length 1)))
|
|
|
|
(if (< (length s) length)
|
|
|
|
(setq s (concat (make-string (- length (length s)) ?0) s)))
|
|
|
|
s))
|
|
|
|
|
2008-10-01 03:25:18 -04:00
|
|
|
(defun org-id-b36-to-int (s)
|
|
|
|
"Convert a base-36 string into the corresponding integer."
|
2008-04-28 04:48:49 -04:00
|
|
|
(let ((r 0))
|
2008-10-01 03:25:18 -04:00
|
|
|
(mapc (lambda (i) (setq r (+ (* r 36) (org-id-b36-to-int-one-digit i))))
|
2008-04-28 04:48:49 -04:00
|
|
|
s)
|
|
|
|
r))
|
|
|
|
|
2008-10-01 03:25:18 -04:00
|
|
|
(defun org-id-time-to-b36 (&optional time)
|
2008-04-28 04:58:29 -04:00
|
|
|
"Encode TIME as a 10-digit string.
|
2008-04-28 04:48:49 -04:00
|
|
|
This string holds the time to micro-second accuracy, and can be decoded
|
|
|
|
using `org-id-decode'."
|
|
|
|
(setq time (or time (current-time)))
|
2008-10-01 03:25:18 -04:00
|
|
|
(concat (org-id-int-to-b36 (nth 0 time) 4)
|
|
|
|
(org-id-int-to-b36 (nth 1 time) 4)
|
|
|
|
(org-id-int-to-b36 (or (nth 2 time) 0) 4)))
|
2008-04-28 04:48:49 -04:00
|
|
|
|
|
|
|
(defun org-id-decode (id)
|
|
|
|
"Split ID into the prefix and the time value that was used to create it.
|
|
|
|
The return value is (prefix . time) where PREFIX is nil or a string,
|
2008-04-28 04:58:29 -04:00
|
|
|
and time is the usual three-integer representation of time."
|
2008-04-28 04:48:49 -04:00
|
|
|
(let (prefix time parts)
|
|
|
|
(setq parts (org-split-string id ":"))
|
|
|
|
(if (= 2 (length parts))
|
|
|
|
(setq prefix (car parts) time (nth 1 parts))
|
|
|
|
(setq prefix nil time (nth 0 parts)))
|
2008-10-01 03:25:18 -04:00
|
|
|
(setq time (org-id-reverse-string time))
|
|
|
|
(setq time (list (org-id-b36-to-int (substring time 0 4))
|
|
|
|
(org-id-b36-to-int (substring time 4 8))
|
|
|
|
(org-id-b36-to-int (substring time 8 12))))
|
2008-04-28 04:48:49 -04:00
|
|
|
(cons prefix time)))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-02-27 08:32:17 -05:00
|
|
|
;; Storing ID locations (files)
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-11-17 04:27:44 -05:00
|
|
|
(defun org-id-update-id-locations (&optional files)
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
"Scan relevant files for IDs.
|
|
|
|
Store the relation between files and corresponding IDs.
|
2008-11-17 04:27:44 -05:00
|
|
|
This will scan all agenda files, all associated archives, and all
|
|
|
|
files currently mentioned in `org-id-locations'.
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
When FILES is given, scan these files instead.
|
2008-12-16 09:25:09 -05:00
|
|
|
When CHECK is given, prepare detailed information about duplicate IDs."
|
2008-02-27 08:32:17 -05:00
|
|
|
(interactive)
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(if (not org-id-track-globally)
|
2009-09-24 04:09:33 -04:00
|
|
|
(error "Please turn on `org-id-track-globally' if you want to track IDs")
|
2009-10-28 05:06:08 -04:00
|
|
|
(let* ((org-id-search-archives
|
|
|
|
(or org-id-search-archives
|
|
|
|
(and (symbolp org-id-extra-files)
|
|
|
|
(symbol-value org-id-extra-files)
|
|
|
|
(member 'agenda-archives org-id-extra-files))))
|
|
|
|
(files
|
|
|
|
(or files
|
|
|
|
(append
|
|
|
|
;; Agenda files and all associated archives
|
|
|
|
(org-agenda-files t org-id-search-archives)
|
|
|
|
;; Explicit extra files
|
|
|
|
(if (symbolp org-id-extra-files)
|
|
|
|
(symbol-value org-id-extra-files)
|
|
|
|
org-id-extra-files)
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
;; Files associated with live org-mode buffers
|
2009-10-28 05:06:08 -04:00
|
|
|
(delq nil
|
|
|
|
(mapcar (lambda (b)
|
|
|
|
(with-current-buffer b
|
|
|
|
(and (org-mode-p) (buffer-file-name))))
|
|
|
|
(buffer-list)))
|
|
|
|
;; All files known to have IDs
|
|
|
|
org-id-files)))
|
|
|
|
org-agenda-new-buffers
|
|
|
|
file nfiles tfile ids reg found id seen (ndup 0))
|
|
|
|
(when (member 'agenda-archives files)
|
|
|
|
(setq files (delq 'agenda-archives (copy-sequence files))))
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(setq nfiles (length files))
|
|
|
|
(while (setq file (pop files))
|
|
|
|
(message "Finding ID locations (%d/%d files): %s"
|
|
|
|
(- nfiles (length files)) nfiles file)
|
|
|
|
(setq tfile (file-truename file))
|
|
|
|
(when (and (file-exists-p file) (not (member tfile seen)))
|
|
|
|
(push tfile seen)
|
|
|
|
(setq ids nil)
|
|
|
|
(with-current-buffer (org-get-agenda-file-buffer file)
|
|
|
|
(save-excursion
|
|
|
|
(save-restriction
|
|
|
|
(widen)
|
|
|
|
(goto-char (point-min))
|
|
|
|
(while (re-search-forward "^[ \t]*:ID:[ \t]+\\(\\S-+\\)[ \t]*$"
|
|
|
|
nil t)
|
|
|
|
(setq id (org-match-string-no-properties 1))
|
|
|
|
(if (member id found)
|
|
|
|
(progn
|
|
|
|
(message "Duplicate ID \"%s\", also in file %s"
|
2009-11-06 03:40:55 -05:00
|
|
|
id (or (car (delq
|
|
|
|
nil
|
|
|
|
(mapcar
|
|
|
|
(lambda (x)
|
|
|
|
(if (member id (cdr x))
|
|
|
|
(car x)))
|
|
|
|
reg)))
|
|
|
|
(buffer-file-name)))
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(when (= ndup 0)
|
|
|
|
(ding)
|
|
|
|
(sit-for 2))
|
|
|
|
(setq ndup (1+ ndup)))
|
|
|
|
(push id found)
|
|
|
|
(push id ids)))
|
|
|
|
(push (cons (abbreviate-file-name file) ids) reg))))))
|
|
|
|
(org-release-buffers org-agenda-new-buffers)
|
|
|
|
(setq org-agenda-new-buffers nil)
|
|
|
|
(setq org-id-locations reg)
|
|
|
|
(setq org-id-files (mapcar 'car org-id-locations))
|
|
|
|
(org-id-locations-save) ;; this function can also handle the alist form
|
|
|
|
;; now convert to a hash
|
|
|
|
(setq org-id-locations (org-id-alist-to-hash org-id-locations))
|
|
|
|
(if (> ndup 0)
|
|
|
|
(message "WARNING: %d duplicate IDs found, check *Messages* buffer" ndup)
|
|
|
|
(message "%d unique files scanned for IDs" (length org-id-files)))
|
|
|
|
org-id-locations)))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
|
|
|
(defun org-id-locations-save ()
|
|
|
|
"Save `org-id-locations' in `org-id-locations-file'."
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(when org-id-track-globally
|
|
|
|
(let ((out (if (hash-table-p org-id-locations)
|
|
|
|
(org-id-hash-to-alist org-id-locations)
|
|
|
|
org-id-locations)))
|
|
|
|
(with-temp-file org-id-locations-file
|
|
|
|
(print out (current-buffer))))))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
|
|
|
(defun org-id-locations-load ()
|
|
|
|
"Read the data from `org-id-locations-file'."
|
|
|
|
(setq org-id-locations nil)
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(when org-id-track-globally
|
|
|
|
(with-temp-buffer
|
|
|
|
(condition-case nil
|
|
|
|
(progn
|
|
|
|
(insert-file-contents-literally org-id-locations-file)
|
|
|
|
(goto-char (point-min))
|
|
|
|
(setq org-id-locations (read (current-buffer))))
|
|
|
|
(error
|
|
|
|
(message "Could not read org-id-values from %s. Setting it to nil."
|
|
|
|
org-id-locations-file))))
|
|
|
|
(setq org-id-files (mapcar 'car org-id-locations))
|
|
|
|
(setq org-id-locations (org-id-alist-to-hash org-id-locations))))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
|
|
|
(defun org-id-add-location (id file)
|
2008-12-16 09:25:09 -05:00
|
|
|
"Add the ID with location FILE to the database of ID locations."
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
;; Only if global tracking is on, and when the buffer has a file
|
2008-12-16 11:58:07 -05:00
|
|
|
(when (and org-id-track-globally id file)
|
2008-11-18 02:59:39 -05:00
|
|
|
(unless org-id-locations (org-id-locations-load))
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(puthash id (abbreviate-file-name file) org-id-locations)
|
|
|
|
(add-to-list 'org-id-files (abbreviate-file-name file))))
|
|
|
|
|
|
|
|
(add-hook 'kill-emacs-hook 'org-id-locations-save)
|
|
|
|
|
|
|
|
(defun org-id-hash-to-alist (hash)
|
|
|
|
"Turn an org-id hash into an alist, so that it can be written to a file."
|
|
|
|
(let (res x)
|
|
|
|
(maphash
|
|
|
|
(lambda (k v)
|
|
|
|
(if (setq x (member v res))
|
2008-12-16 01:56:19 -05:00
|
|
|
(setcdr x (cons k (cdr x)))
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(push (list v k) res)))
|
|
|
|
hash)
|
|
|
|
res))
|
|
|
|
|
|
|
|
(defun org-id-alist-to-hash (list)
|
|
|
|
"Turn an org-id location list into a hash table."
|
|
|
|
(let ((res (make-hash-table
|
|
|
|
:test 'equal
|
|
|
|
:size (apply '+ (mapcar 'length list))))
|
2009-01-26 03:42:33 -05:00
|
|
|
f)
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(mapc
|
|
|
|
(lambda (x)
|
|
|
|
(setq f (car x))
|
|
|
|
(mapc (lambda (i) (puthash i f res)) (cdr x)))
|
|
|
|
list)
|
|
|
|
res))
|
|
|
|
|
|
|
|
(defun org-id-paste-tracker (txt &optional buffer-or-file)
|
|
|
|
"Update any IDs in TXT and assign BUFFER-OR-FILE to them."
|
|
|
|
(when org-id-track-globally
|
|
|
|
(save-match-data
|
|
|
|
(setq buffer-or-file (or buffer-or-file (current-buffer)))
|
|
|
|
(when (bufferp buffer-or-file)
|
|
|
|
(setq buffer-or-file (or (buffer-base-buffer buffer-or-file)
|
|
|
|
buffer-or-file))
|
|
|
|
(setq buffer-or-file (buffer-file-name buffer-or-file)))
|
|
|
|
(when buffer-or-file
|
|
|
|
(let ((fname (abbreviate-file-name buffer-or-file))
|
|
|
|
(s 0))
|
|
|
|
(while (string-match "^[ \t]*:ID:[ \t]+\\([^ \t\n\r]+\\)" txt s)
|
|
|
|
(setq s (match-end 0))
|
|
|
|
(org-id-add-location (match-string 1 txt) fname)))))))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-02-27 08:32:17 -05:00
|
|
|
;; Finding entries with specified id
|
|
|
|
|
2009-01-09 02:33:00 -05:00
|
|
|
;;;###autoload
|
2008-02-26 11:43:55 -05:00
|
|
|
(defun org-id-find-id-file (id)
|
|
|
|
"Query the id database for the file in which this ID is located."
|
|
|
|
(unless org-id-locations (org-id-locations-load))
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(or (gethash id org-id-locations)
|
|
|
|
;; ball back on current buffer
|
|
|
|
(buffer-file-name (or (buffer-base-buffer (current-buffer))
|
|
|
|
(current-buffer)))))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
|
|
|
(defun org-id-find-id-in-file (id file &optional markerp)
|
|
|
|
"Return the position of the entry ID in FILE.
|
|
|
|
If that files does not exist, or if it does not contain this ID,
|
|
|
|
return nil.
|
|
|
|
The position is returned as a cons cell (file-name . position). With
|
2008-04-28 04:48:49 -04:00
|
|
|
optional argument MARKERP, return the position as a new marker."
|
2009-01-26 03:42:33 -05:00
|
|
|
(let (org-agenda-new-buffers buf pos)
|
2008-02-26 11:43:55 -05:00
|
|
|
(cond
|
|
|
|
((not file) nil)
|
|
|
|
((not (file-exists-p file)) nil)
|
|
|
|
(t (with-current-buffer (setq buf (org-get-agenda-file-buffer file))
|
|
|
|
(setq pos (org-find-entry-with-id id))
|
|
|
|
(when pos
|
2008-02-27 08:32:17 -05:00
|
|
|
(if markerp
|
|
|
|
(move-marker (make-marker) pos buf)
|
|
|
|
(cons file pos))))))))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
;; id link type
|
|
|
|
|
|
|
|
;; Calling the following function is hard-coded into `org-store-link',
|
|
|
|
;; so we do have to add it to `org-store-link-functions'.
|
2008-11-17 04:27:44 -05:00
|
|
|
|
|
|
|
(defun org-id-store-link ()
|
2009-08-15 02:16:38 -04:00
|
|
|
"Store a link to the current entry, using its ID."
|
2008-11-17 04:27:44 -05:00
|
|
|
(interactive)
|
|
|
|
(let* ((link (org-make-link "id:" (org-id-get-create)))
|
|
|
|
(desc (save-excursion
|
|
|
|
(org-back-to-heading t)
|
|
|
|
(or (and (looking-at org-complex-heading-regexp)
|
|
|
|
(if (match-end 4) (match-string 4) (match-string 0)))
|
|
|
|
link))))
|
|
|
|
(org-store-link-props :link link :description desc :type "id")
|
|
|
|
link))
|
|
|
|
|
|
|
|
(defun org-id-open (id)
|
|
|
|
"Go to the entry with id ID."
|
|
|
|
(org-mark-ring-push)
|
2009-08-02 09:51:26 -04:00
|
|
|
(let ((m (org-id-find id 'marker))
|
|
|
|
cmd)
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(unless m
|
|
|
|
(error "Cannot find entry with ID \"%s\"" id))
|
2009-08-02 09:51:26 -04:00
|
|
|
;; Use a buffer-switching command in analogy to finding files
|
|
|
|
(setq cmd
|
|
|
|
(or
|
|
|
|
(cdr
|
|
|
|
(assq
|
|
|
|
(cdr (assq 'file org-link-frame-setup))
|
|
|
|
'((find-file . switch-to-buffer)
|
|
|
|
(find-file-other-window . switch-to-buffer-other-window)
|
|
|
|
(find-file-other-frame . switch-to-buffer-other-frame))))
|
2009-08-03 07:28:24 -04:00
|
|
|
'switch-to-buffer-other-window))
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(if (not (equal (current-buffer) (marker-buffer m)))
|
2009-08-02 09:51:26 -04:00
|
|
|
(funcall cmd (marker-buffer m)))
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
(goto-char m)
|
|
|
|
(move-marker m nil)
|
|
|
|
(org-show-context)))
|
|
|
|
|
|
|
|
(org-add-link-type "id" 'org-id-open)
|
2008-11-17 04:27:44 -05:00
|
|
|
|
2008-02-26 11:43:55 -05:00
|
|
|
(provide 'org-id)
|
|
|
|
|
|
|
|
;;; org-id.el ends here
|
|
|
|
|
2008-06-20 08:11:50 -04:00
|
|
|
;; arch-tag: e5abaca4-e16f-4b25-832a-540cfb63a712
|
2008-11-17 04:27:44 -05:00
|
|
|
|
Better implementation of unique entry IDs.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
2008-12-05 17:35:26 -05:00
|
|
|
|