2015-11-13 18:05:50 -05:00
|
|
|
;;; org-id.el --- Global identifiers for Org entries -*- lexical-binding: t; -*-
|
2009-01-06 04:47:36 -05:00
|
|
|
;;
|
2024-01-01 20:47:10 -05:00
|
|
|
;; Copyright (C) 2008-2024 Free Software Foundation, Inc.
|
2008-02-26 11:43:55 -05:00
|
|
|
;;
|
2021-05-07 10:50:57 -04:00
|
|
|
;; Author: Carsten Dominik <carsten.dominik@gmail.com>
|
2008-02-26 11:43:55 -05:00
|
|
|
;; Keywords: outlines, hypermedia, calendar, wp
|
2021-09-26 03:44:29 -04:00
|
|
|
;; URL: https://orgmode.org
|
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
|
2017-09-13 18:52:52 -04:00
|
|
|
;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
|
2008-02-26 11:43:55 -05:00
|
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
|
|
;;
|
|
|
|
;;; Commentary:
|
|
|
|
|
2016-08-23 16:13:56 -04:00
|
|
|
;; This file implements globally unique identifiers for Org 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.
|
|
|
|
|
2024-01-05 07:31:27 -05:00
|
|
|
;; Identifiers consist of a prefix (given by the variable
|
2008-09-11 10:56:37 -04:00
|
|
|
;; `org-id-prefix') and a unique part that can be created by a number
|
2024-01-05 07:31:27 -05:00
|
|
|
;; 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 guarantees
|
|
|
|
;; globally unique identifiers, even if several people are creating
|
|
|
|
;; IDs at the same time in files that will eventually be used
|
2010-05-16 10:48:51 -04:00
|
|
|
;; together.
|
|
|
|
;;
|
|
|
|
;; By default Org uses UUIDs as global unique identifiers.
|
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
|
|
|
;;
|
|
|
|
|
2010-07-16 17:22:01 -04:00
|
|
|
;;; Code:
|
|
|
|
|
2022-08-04 09:53:05 -04:00
|
|
|
(require 'org-macs)
|
|
|
|
(org-assert-version)
|
|
|
|
|
2008-02-26 11:43:55 -05:00
|
|
|
(require 'org)
|
2023-08-03 09:52:04 -04:00
|
|
|
(require 'org-element-ast)
|
2020-04-15 22:01:14 -04:00
|
|
|
(require 'org-refile)
|
2018-11-26 18:04:41 -05:00
|
|
|
(require 'ol)
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2008-05-15 04:28:38 -04:00
|
|
|
(declare-function message-make-fqdn "message" ())
|
2017-10-22 10:40:54 -04:00
|
|
|
(declare-function org-goto-location "org-goto" (&optional _buf help))
|
2022-01-30 02:17:38 -05:00
|
|
|
;; Declared inside `org-element-with-disabled-cache' macro.
|
|
|
|
(declare-function org-element--cache-active-p "org-element.el" (&optional called-from-cache-change-func-p))
|
2008-05-15 04:28:38 -04:00
|
|
|
|
2008-02-27 08:32:17 -05:00
|
|
|
;;; Customization
|
|
|
|
|
2008-02-26 11:43:55 -05:00
|
|
|
(defgroup org-id nil
|
2016-10-11 12:00:08 -04:00
|
|
|
"Options concerning global entry identifiers in Org mode."
|
2008-02-26 11:43:55 -05:00
|
|
|
:tag "Org ID"
|
|
|
|
:group 'org)
|
|
|
|
|
2012-09-23 05:58:49 -04:00
|
|
|
(defcustom org-id-link-to-org-use-id nil
|
|
|
|
"Non-nil means storing a link to an Org file will use entry IDs.
|
2019-05-23 02:58:55 -04:00
|
|
|
\\<org-mode-map>
|
2012-09-23 05:58:49 -04:00
|
|
|
The variable can have the following values:
|
|
|
|
|
|
|
|
t Create an ID if needed to make a link to the current entry.
|
|
|
|
|
|
|
|
create-if-interactive
|
|
|
|
If `org-store-link' is called directly (interactively, as a user
|
|
|
|
command), do create an ID to support the link. But when doing the
|
|
|
|
job for capture, only use the ID if it already exists. The
|
|
|
|
purpose of this setting is to avoid proliferation of unwanted
|
|
|
|
IDs, just because you happen to be in an Org file when you
|
|
|
|
call `org-capture' that automatically and preemptively creates a
|
|
|
|
link. If you do want to get an ID link in a capture template to
|
|
|
|
an entry not having an ID, create it first by explicitly creating
|
2016-09-29 16:22:56 -04:00
|
|
|
a link to it, using `\\[org-store-link]' first.
|
2012-09-23 05:58:49 -04:00
|
|
|
|
|
|
|
create-if-interactive-and-no-custom-id
|
|
|
|
Like create-if-interactive, but do not create an ID if there is
|
2012-09-26 13:55:50 -04:00
|
|
|
a CUSTOM_ID property defined in the entry.
|
2012-09-23 05:58:49 -04:00
|
|
|
|
|
|
|
use-existing
|
|
|
|
Use existing ID, do not create one.
|
|
|
|
|
|
|
|
nil Never use an ID to make a link, instead link using a text search for
|
|
|
|
the headline text."
|
|
|
|
:group 'org-link-store
|
|
|
|
:group 'org-id
|
2012-09-29 17:46:02 -04:00
|
|
|
:version "24.3"
|
2012-09-23 05:58:49 -04:00
|
|
|
:type '(choice
|
|
|
|
(const :tag "Create ID to make link" t)
|
|
|
|
(const :tag "Create if storing link interactively"
|
|
|
|
create-if-interactive)
|
|
|
|
(const :tag "Create if storing link interactively and no CUSTOM_ID is present"
|
|
|
|
create-if-interactive-and-no-custom-id)
|
|
|
|
(const :tag "Only use existing" use-existing)
|
|
|
|
(const :tag "Do not use ID to create link" nil)))
|
|
|
|
|
2023-11-19 09:52:05 -05:00
|
|
|
(defcustom org-id-link-consider-parent-id nil
|
|
|
|
"Non-nil means storing a link to an Org entry considers inherited IDs.
|
|
|
|
|
|
|
|
When this option is non-nil and `org-id-link-use-context' is
|
|
|
|
enabled, ID properties inherited from parent entries will be
|
|
|
|
considered when storing an ID link. If no ID is found in this
|
|
|
|
way, a new one may be created as normal (see
|
|
|
|
`org-id-link-to-org-use-id').
|
|
|
|
|
|
|
|
For example, given this org file:
|
|
|
|
|
|
|
|
* Parent
|
|
|
|
:PROPERTIES:
|
|
|
|
:ID: abc
|
|
|
|
:END:
|
|
|
|
** Child 1
|
|
|
|
** Child 2
|
|
|
|
|
|
|
|
With `org-id-link-consider-parent-id' and
|
|
|
|
`org-id-link-use-context' both enabled, storing a link with point
|
|
|
|
at \"Child 1\" will produce a link \"<id:abc::*Child 1>\". This
|
|
|
|
allows linking to uniquely-named sub-entries within a parent
|
|
|
|
entry with an ID, without requiring every sub-entry to have its
|
|
|
|
own ID."
|
|
|
|
:group 'org-link-store
|
|
|
|
:group 'org-id
|
|
|
|
:package-version '(Org . "9.7")
|
|
|
|
:type 'boolean)
|
|
|
|
|
|
|
|
(defcustom org-id-link-use-context t
|
|
|
|
"Non-nil means enables search string context in org-id links.
|
|
|
|
|
|
|
|
Search strings are added by `org-id-store-link' when both the
|
|
|
|
general option `org-link-context-for-files' and the org-id option
|
|
|
|
`org-id-link-use-context' are non-nil."
|
|
|
|
:group 'org-link-store
|
|
|
|
:group 'org-id
|
|
|
|
:package-version '(Org . "9.7")
|
|
|
|
:type 'boolean)
|
|
|
|
|
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
|
|
|
|
2020-09-11 03:42:53 -04:00
|
|
|
(defcustom org-id-ts-format "%Y%m%dT%H%M%S.%6N"
|
2021-04-19 16:44:37 -04:00
|
|
|
"Timestamp format for IDs generated using `ts' `org-id-method'.
|
|
|
|
The format should be suitable to pass as an argument to `format-time-string'.
|
|
|
|
|
|
|
|
Defaults to ISO8601 timestamps without separators and without
|
|
|
|
timezone, local time and precision down to 1e-6 seconds."
|
2020-09-23 22:46:39 -04:00
|
|
|
:type 'string
|
|
|
|
:package-version '(Org . "9.5"))
|
2020-09-11 03:42:53 -04:00
|
|
|
|
2010-05-16 10:48:51 -04:00
|
|
|
(defcustom org-id-method 'uuid
|
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
|
|
|
"The method that should be used to create new IDs.
|
|
|
|
|
|
|
|
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
|
|
|
|
2010-05-16 10:48:51 -04:00
|
|
|
uuid Create random (version 4) UUIDs. If the program defined in
|
|
|
|
`org-id-uuid-program' is available it is used to create the ID.
|
2019-08-01 17:05:08 -04:00
|
|
|
Otherwise an internal functions is used.
|
|
|
|
|
2021-04-19 16:44:37 -04:00
|
|
|
ts Create ID's based on timestamps as specified in `org-id-ts-format'."
|
2008-09-11 10:56:37 -04:00
|
|
|
:group 'org-id
|
|
|
|
:type '(choice
|
|
|
|
(const :tag "Org's internal method" org)
|
2019-08-01 17:05:08 -04:00
|
|
|
(const :tag "external: uuidgen" uuid)
|
2021-04-19 16:44:37 -04:00
|
|
|
(const :tag "Timestamp with format `org-id-ts-format'" ts)))
|
2008-09-11 10:56:37 -04:00
|
|
|
|
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
|
2010-01-21 10:15:40 -05: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
|
2019-02-16 14:20:09 -05:00
|
|
|
the relevant RFCs. This is relevant only if `org-id-method' is
|
2019-08-01 17:05:08 -04:00
|
|
|
`org' or `ts'. When uuidgen is used, the domain will never be added.
|
2019-02-16 14:20:09 -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
|
|
|
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
|
2010-01-21 10:15:40 -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)
|
|
|
|
|
2021-11-09 01:51:18 -05:00
|
|
|
(defcustom org-id-locations-file (locate-user-emacs-file ".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
|
|
|
"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
|
|
|
|
2019-08-01 17:00:19 -04:00
|
|
|
(defcustom org-id-locations-file-relative nil
|
2021-09-16 06:32:43 -04:00
|
|
|
"Determine if `org-id-locations' should be stored as relative links.
|
2019-08-01 17:00:19 -04:00
|
|
|
Non-nil means that links to locations are stored as links
|
|
|
|
relative to the location of where `org-id-locations-file' is
|
|
|
|
stored.
|
|
|
|
|
|
|
|
Nil means to store absolute paths to files.
|
|
|
|
|
|
|
|
This customization is useful when folders are shared across
|
|
|
|
systems but mounted at different roots. Relative path to
|
|
|
|
`org-id-locations-file' still has to be maintained across
|
|
|
|
systems."
|
|
|
|
:group 'org-id
|
|
|
|
:type 'boolean
|
|
|
|
:package-version '(Org . "9.3"))
|
|
|
|
|
2008-02-27 08:32:17 -05:00
|
|
|
(defvar org-id-locations nil
|
2011-06-01 01:54:56 -04:00
|
|
|
"List of files with IDs in those files.")
|
2023-08-03 09:52:04 -04:00
|
|
|
(defvar org-id--locations-checksum nil
|
|
|
|
"Last checksum corresponding to ID files and their modifications.")
|
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
|
|
|
|
|
|
|
(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
|
2016-08-23 16:13:56 -04:00
|
|
|
any Org file currently visited by Emacs.
|
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
|
|
|
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
|
2010-01-21 10:15:40 -05:00
|
|
|
"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
|
|
|
|
2013-11-15 00:53:59 -05: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
|
|
|
|
2020-04-16 01:07:38 -04:00
|
|
|
(defvar org-id-overriding-file-name nil
|
|
|
|
"Tell `org-id-get' to use this as the file name when creating an ID.
|
|
|
|
This is useful when working with contents in a temporary buffer
|
|
|
|
that will be copied back to the original.")
|
|
|
|
|
2008-05-15 04:28:38 -04:00
|
|
|
;;;###autoload
|
2023-11-19 09:52:05 -05:00
|
|
|
(defun org-id-get (&optional epom create prefix inherit)
|
|
|
|
"Get the ID of the entry at EPOM.
|
|
|
|
|
|
|
|
EPOM is an element, marker, or buffer position. If EPOM is nil,
|
|
|
|
refer to the entry at point.
|
|
|
|
|
|
|
|
If INHERIT is non-nil, ID properties inherited from parent
|
|
|
|
entries are considered. Otherwise, only ID properties on the
|
|
|
|
entry itself are considered.
|
|
|
|
|
|
|
|
When CREATE is nil, return the ID of the entry if found,
|
|
|
|
otherwise nil. When CREATE is non-nil, create an ID if none has
|
|
|
|
been found, and return the new ID. PREFIX will be passed through
|
|
|
|
to `org-id-new'."
|
|
|
|
(let ((id (org-entry-get epom "ID" (and inherit t))))
|
2023-05-10 08:19:25 -04:00
|
|
|
(cond
|
|
|
|
((and id (stringp id) (string-match "\\S-" id))
|
|
|
|
id)
|
|
|
|
(create
|
|
|
|
(setq id (org-id-new prefix))
|
|
|
|
(org-entry-put epom "ID" id)
|
|
|
|
(org-with-point-at epom
|
|
|
|
(org-id-add-location id
|
2020-04-16 01:07:38 -04:00
|
|
|
(or org-id-overriding-file-name
|
2023-05-10 08:19:25 -04:00
|
|
|
(buffer-file-name (buffer-base-buffer)))))
|
|
|
|
id))))
|
2008-02-26 11:43:55 -05:00
|
|
|
|
2013-11-15 00:53:59 -05:00
|
|
|
;;;###autoload
|
2008-02-26 11:43:55 -05:00
|
|
|
(defun org-id-get-with-outline-path-completion (&optional targets)
|
2013-02-07 02:42:15 -05:00
|
|
|
"Use `outline-path-completion' to retrieve the ID of an entry.
|
|
|
|
TARGETS may be a setting for `org-refile-targets' to define
|
|
|
|
eligible headlines. When omitted, all headlines in the current
|
|
|
|
file are eligible. This function 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)
|
2011-03-02 13:46:37 -05:00
|
|
|
(spos (org-refile-get-location "Entry"))
|
2020-12-11 05:27:23 -05:00
|
|
|
(pom (and spos (move-marker (make-marker) (or (nth 3 spos) 1)
|
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
|
|
|
|
2013-11-15 00:53:59 -05:00
|
|
|
;;;###autoload
|
2015-11-13 18:05:50 -05:00
|
|
|
(defun org-id-get-with-outline-drilling ()
|
2008-02-27 08:32:17 -05:00
|
|
|
"Use an outline-cycling interface to retrieve the ID of an entry.
|
2017-10-22 10:40:54 -04:00
|
|
|
This only finds entries in the current buffer, using `org-goto-location'.
|
2008-02-27 08:32:17 -05:00
|
|
|
It returns the ID of the entry. If necessary, the ID is created."
|
2017-10-22 10:40:54 -04:00
|
|
|
(let* ((spos (org-goto-location))
|
2008-02-26 11:43:55 -05:00
|
|
|
(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))
|
2016-06-23 04:00:00 -04:00
|
|
|
(pop-to-buffer-same-window (marker-buffer m))
|
2008-02-27 08:32:17 -05:00
|
|
|
(goto-char m)
|
2008-04-28 04:48:49 -04:00
|
|
|
(move-marker m nil)
|
2022-01-16 02:07:25 -05:00
|
|
|
(org-fold-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
|
2012-04-21 09:46:02 -04:00
|
|
|
(org-id-update-id-locations nil t)
|
2008-02-27 08:32:17 -05:00
|
|
|
(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
|
|
|
|
2013-11-15 00:53:59 -05:00
|
|
|
;;;###autoload
|
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
|
2010-05-16 10:48:51 -04:00
|
|
|
((memq org-id-method '(uuidgen uuid))
|
|
|
|
(setq unique (org-trim (shell-command-to-string org-id-uuid-program)))
|
|
|
|
(unless (org-uuidgen-p unique)
|
|
|
|
(setq unique (org-id-uuid))))
|
2008-09-11 10:56:37 -04:00
|
|
|
((eq org-id-method 'org)
|
2013-01-26 16:27:51 -05:00
|
|
|
(let* ((etime (org-reverse-string (org-id-time-to-b36)))
|
2021-05-15 03:57:45 -04:00
|
|
|
(postfix (when org-id-include-domain
|
|
|
|
(require 'message)
|
|
|
|
(concat "@" (message-make-fqdn)))))
|
2008-09-11 10:56:37 -04:00
|
|
|
(setq unique (concat etime postfix))))
|
2019-08-01 17:05:08 -04:00
|
|
|
((eq org-id-method 'ts)
|
2020-09-11 03:42:53 -04:00
|
|
|
(let ((ts (format-time-string org-id-ts-format))
|
2021-05-15 03:57:45 -04:00
|
|
|
(postfix (when org-id-include-domain
|
|
|
|
(require 'message)
|
|
|
|
(concat "@" (message-make-fqdn)))))
|
2019-08-01 17:05:08 -04:00
|
|
|
(setq unique (concat ts postfix))))
|
2008-09-11 10:56:37 -04:00
|
|
|
(t (error "Invalid `org-id-method'")))
|
|
|
|
(concat prefix unique)))
|
2008-04-28 04:48:49 -04:00
|
|
|
|
2021-09-27 20:35:12 -04:00
|
|
|
(defun org-id-int-to-b36-one-digit (integer)
|
|
|
|
"Convert INTEGER between 0 and 61 into a single character 0..9, A..Z, a..z."
|
2008-04-28 04:48:49 -04:00
|
|
|
(cond
|
2021-09-27 20:35:12 -04:00
|
|
|
((< integer 10) (+ ?0 integer))
|
|
|
|
((< integer 36) (+ ?a integer -10))
|
2008-10-01 03:25:18 -04:00
|
|
|
(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)
|
2021-09-27 20:35:12 -04:00
|
|
|
"Convert 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
|
|
|
|
2021-09-27 20:35:12 -04:00
|
|
|
(defun org-id-int-to-b36 (integer &optional length)
|
|
|
|
"Convert an INTEGER to a base-36 number represented as a string.
|
|
|
|
The returned string is padded with leading zeros to LENGTH if necessary."
|
|
|
|
(let ((s "")
|
|
|
|
(i integer))
|
2008-04-28 04:48:49 -04:00
|
|
|
(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))
|
|
|
|
|
2021-09-27 20:35:12 -04:00
|
|
|
(defun org-id-b36-to-int (string)
|
|
|
|
"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))))
|
2021-09-27 20:35:12 -04:00
|
|
|
string)
|
2008-04-28 04:48:49 -04:00
|
|
|
r))
|
|
|
|
|
2008-10-01 03:25:18 -04:00
|
|
|
(defun org-id-time-to-b36 (&optional time)
|
2019-08-04 12:57:27 -04:00
|
|
|
"Encode TIME as a 12-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'."
|
2019-08-04 12:57:27 -04:00
|
|
|
;; FIXME: If TIME represents N seconds after the epoch, then
|
|
|
|
;; this encoding assumes 0 <= N < 110075314176 = (* (expt 36 4) 65536),
|
|
|
|
;; i.e., that TIME is from 1970-01-01 00:00:00 to 5458-02-23 20:09:36 UTC.
|
2019-08-18 11:22:36 -04:00
|
|
|
(setq time (org-time-convert-to-list nil))
|
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)
|
2019-08-05 20:37:47 -04:00
|
|
|
(org-id-int-to-b36 (nth 2 time) 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,
|
2019-08-04 12:57:27 -04:00
|
|
|
and TIME is a Lisp time value (HI LO USEC)."
|
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)))
|
2013-01-26 16:27:51 -05:00
|
|
|
(setq time (org-reverse-string time))
|
2008-10-01 03:25:18 -04:00
|
|
|
(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
|
|
|
|
2013-05-19 00:54:44 -04:00
|
|
|
;;;###autoload
|
2012-04-21 09:46:02 -04:00
|
|
|
(defun org-id-update-id-locations (&optional files silent)
|
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.
|
2022-08-03 22:21:59 -04:00
|
|
|
This will scan all agenda files, all associated archives, all open Org
|
|
|
|
files, and all files currently mentioned in `org-id-locations'.
|
2021-09-27 20:35:12 -04:00
|
|
|
When FILES is given, scan also these files.
|
|
|
|
If SILENT is non-nil, messages are suppressed."
|
2008-02-27 08:32:17 -05:00
|
|
|
(interactive)
|
2020-05-14 16:48:17 -04:00
|
|
|
(unless org-id-track-globally
|
|
|
|
(error "Please turn on `org-id-track-globally' if you want to track IDs"))
|
|
|
|
(let* ((files
|
|
|
|
(delete-dups
|
|
|
|
(mapcar #'file-truename
|
2020-07-14 13:07:14 -04:00
|
|
|
(cl-remove-if-not
|
|
|
|
;; Default `org-id-extra-files' value contains
|
|
|
|
;; `agenda-archives' symbol.
|
|
|
|
#'stringp
|
|
|
|
(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)
|
|
|
|
;; All files known to have IDs.
|
|
|
|
org-id-files
|
2022-08-03 22:21:59 -04:00
|
|
|
;; All Org files open in Emacs.
|
|
|
|
(mapcar #'buffer-file-name (org-buffer-list 'files t))
|
2020-07-14 13:07:14 -04:00
|
|
|
;; Additional files from function call.
|
|
|
|
files)))))
|
2020-05-14 16:48:17 -04:00
|
|
|
(nfiles (length files))
|
|
|
|
(id-regexp
|
|
|
|
(rx (seq bol (0+ (any "\t ")) ":ID:" (1+ " ") (not (any " ")))))
|
2023-08-03 09:52:04 -04:00
|
|
|
(seen-ids (make-hash-table :test #'equal))
|
2020-05-14 16:48:17 -04:00
|
|
|
(ndup 0)
|
2023-08-03 09:52:04 -04:00
|
|
|
(i 0)
|
|
|
|
(checksum
|
|
|
|
(mapcar
|
|
|
|
(lambda (f)
|
|
|
|
(when (file-exists-p f)
|
|
|
|
(list f (file-attribute-modification-time (file-attributes f)))))
|
2023-08-04 03:54:16 -04:00
|
|
|
(sort (copy-sequence files) #'string<))))
|
2023-08-03 09:52:04 -04:00
|
|
|
(unless (equal checksum org-id--locations-checksum) ; Files have changed since the last update.
|
|
|
|
(setq org-id-locations nil)
|
|
|
|
(with-temp-buffer
|
2022-05-06 23:34:10 -04:00
|
|
|
(delay-mode-hooks
|
|
|
|
(org-mode)
|
|
|
|
(dolist (file files)
|
|
|
|
(when (file-exists-p file)
|
|
|
|
(unless silent
|
|
|
|
(cl-incf i)
|
|
|
|
(message "Finding ID locations (%d/%d files): %s" i nfiles file))
|
|
|
|
(insert-file-contents file nil nil nil 'replace)
|
|
|
|
(let ((ids nil)
|
2023-08-03 09:52:04 -04:00
|
|
|
node
|
2022-05-06 23:34:10 -04:00
|
|
|
(case-fold-search t))
|
|
|
|
(org-with-point-at 1
|
|
|
|
(while (re-search-forward id-regexp nil t)
|
2023-08-03 09:52:04 -04:00
|
|
|
(setq node (org-element-at-point))
|
|
|
|
(when (org-element-type-p node 'node-property)
|
|
|
|
(push (org-element-property :value node) ids)))
|
2022-05-06 23:34:10 -04:00
|
|
|
(when ids
|
|
|
|
(push (cons (abbreviate-file-name file) ids)
|
|
|
|
org-id-locations)
|
|
|
|
(dolist (id ids)
|
|
|
|
(cond
|
2023-08-03 09:52:04 -04:00
|
|
|
((not (gethash id seen-ids)) (puthash id t seen-ids))
|
2022-05-06 23:34:10 -04:00
|
|
|
(silent nil)
|
|
|
|
(t
|
|
|
|
(message "Duplicate ID %S" id)
|
2023-08-03 09:52:04 -04:00
|
|
|
(cl-incf ndup)))))))))))
|
|
|
|
(setq org-id-files (mapcar #'car org-id-locations))
|
|
|
|
(org-id-locations-save)
|
|
|
|
;; Now convert to a hash table.
|
|
|
|
(setq org-id-locations (org-id-alist-to-hash org-id-locations))
|
|
|
|
(setq org-id--locations-checksum checksum)
|
|
|
|
(when (and (not silent) (> ndup 0))
|
|
|
|
(warn "WARNING: %d duplicate IDs found, check *Messages* buffer" ndup))
|
|
|
|
(message "%d files scanned, %d files contains IDs, and %d IDs found."
|
|
|
|
nfiles (length org-id-files) (hash-table-count org-id-locations)))
|
2020-05-14 16:48:17 -04:00
|
|
|
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'."
|
2009-12-10 06:19:41 -05:00
|
|
|
(when (and org-id-track-globally 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
|
|
|
(let ((out (if (hash-table-p org-id-locations)
|
|
|
|
(org-id-hash-to-alist org-id-locations)
|
|
|
|
org-id-locations)))
|
2019-08-01 17:00:19 -04:00
|
|
|
(when (and org-id-locations-file-relative out)
|
|
|
|
(setq out (mapcar
|
|
|
|
(lambda (item)
|
|
|
|
(if (file-name-absolute-p (car item))
|
|
|
|
(cons (file-relative-name
|
|
|
|
(car item) (file-name-directory
|
|
|
|
org-id-locations-file))
|
|
|
|
(cdr item))
|
|
|
|
item))
|
|
|
|
out)))
|
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
|
|
|
(with-temp-file org-id-locations-file
|
2013-04-21 23:30:54 -04:00
|
|
|
(let ((print-level nil)
|
|
|
|
(print-length nil))
|
|
|
|
(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
|
2017-11-04 17:40:02 -04:00
|
|
|
(insert-file-contents org-id-locations-file)
|
2019-08-01 17:00:19 -04:00
|
|
|
(setq org-id-locations (read (current-buffer)))
|
|
|
|
(let ((loc (file-name-directory org-id-locations-file)))
|
|
|
|
(mapc (lambda (item)
|
|
|
|
(unless (file-name-absolute-p (car item))
|
|
|
|
(setf (car item) (expand-file-name (car item) loc))))
|
|
|
|
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
|
|
|
(error
|
2022-11-21 09:16:08 -05:00
|
|
|
(message "Could not read `org-id-locations' from %s, setting it to 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
|
|
|
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
|
2020-04-16 01:07:38 -04:00
|
|
|
(unless file
|
2021-05-15 03:57:45 -04:00
|
|
|
(error "`org-id-get' expects a file-visiting buffer"))
|
2019-08-01 16:41:43 -04:00
|
|
|
(let ((afile (abbreviate-file-name file)))
|
2020-04-16 01:07:38 -04:00
|
|
|
(when (and org-id-track-globally id)
|
2019-08-01 16:41:43 -04:00
|
|
|
(unless org-id-locations (org-id-locations-load))
|
|
|
|
(puthash id afile org-id-locations)
|
|
|
|
(unless (member afile org-id-files)
|
|
|
|
(add-to-list 'org-id-files afile)))))
|
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
|
|
|
|
2011-03-05 20:44:33 -05:00
|
|
|
(unless noninteractive
|
|
|
|
(add-hook 'kill-emacs-hook 'org-id-locations-save))
|
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
|
|
|
|
|
|
|
(defun org-id-hash-to-alist (hash)
|
2021-09-27 20:35:12 -04:00
|
|
|
"Turn an org-id HASH into an alist.
|
2021-05-15 03:57:45 -04:00
|
|
|
This is to be able to write it to a 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
|
|
|
(let (res x)
|
|
|
|
(maphash
|
|
|
|
(lambda (k v)
|
2019-08-01 16:41:43 -04:00
|
|
|
(if (setq x (assoc 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)
|
2021-09-27 20:35:12 -04:00
|
|
|
"Turn an org-id location LIST into a hash table."
|
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
|
|
|
(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)
|
2021-05-15 03:57:45 -04:00
|
|
|
"Update any ids in TXT and assign BUFFER-OR-FILE to them."
|
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
|
|
|
|
(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)
|
2021-05-15 03:57:45 -04:00
|
|
|
"Query the id database for the file in which ID is located."
|
2008-02-26 11:43:55 -05:00
|
|
|
(unless org-id-locations (org-id-locations-load))
|
2010-02-26 13:51:15 -05:00
|
|
|
(or (and org-id-locations
|
|
|
|
(hash-table-p org-id-locations)
|
|
|
|
(gethash id org-id-locations))
|
2020-02-23 08:29:38 -05:00
|
|
|
;; Fall back on current 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
|
|
|
(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.
|
2020-10-06 06:11:58 -04:00
|
|
|
|
2008-02-26 11:43:55 -05:00
|
|
|
If that files does not exist, or if it does not contain this ID,
|
|
|
|
return nil.
|
2020-10-06 06:11:58 -04:00
|
|
|
|
2008-02-26 11:43:55 -05:00
|
|
|
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."
|
2020-10-06 06:11:58 -04:00
|
|
|
(cond
|
|
|
|
((not file) nil)
|
|
|
|
((not (file-exists-p file)) nil)
|
|
|
|
(t
|
|
|
|
(let* ((visiting (find-buffer-visiting file))
|
2023-08-17 05:48:52 -04:00
|
|
|
(buffer (or visiting
|
|
|
|
(if markerp (find-file-noselect file)
|
2023-10-16 04:23:39 -04:00
|
|
|
(org-get-buffer-create " *Org ID temp*" t)))))
|
2020-10-06 06:11:58 -04:00
|
|
|
(unwind-protect
|
|
|
|
(with-current-buffer buffer
|
2023-08-17 05:48:52 -04:00
|
|
|
(unless (derived-mode-p 'org-mode) (org-mode))
|
|
|
|
(unless (or visiting markerp)
|
|
|
|
(buffer-disable-undo)
|
2023-08-18 04:10:12 -04:00
|
|
|
;; FIXME: In Emacs 27, `insert-file-contents' seemingly
|
|
|
|
;; does not trigger modification hooks in some
|
|
|
|
;; scenarios. This is manifested in test failures due
|
|
|
|
;; to element cache losing track of the modifications.
|
|
|
|
(org-element-cache-reset)
|
|
|
|
(insert-file-contents file nil nil nil 'replace))
|
2020-10-06 06:11:58 -04:00
|
|
|
(let ((pos (org-find-entry-with-id id)))
|
|
|
|
(cond
|
|
|
|
((null pos) nil)
|
|
|
|
(markerp (move-marker (make-marker) pos buffer))
|
|
|
|
(t (cons file pos)))))
|
2023-08-17 05:48:52 -04:00
|
|
|
;; Clean temporarily buffer if we don't need to keep it.
|
|
|
|
(unless (or visiting markerp)
|
|
|
|
(with-current-buffer buffer (erase-buffer))))))))
|
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
|
|
|
|
|
2023-11-19 09:52:05 -05:00
|
|
|
(defun org-id--get-id-to-store-link (&optional create)
|
|
|
|
"Get or create the relevant ID for storing a link.
|
|
|
|
|
|
|
|
Optional argument CREATE is passed to `org-id-get'.
|
|
|
|
|
|
|
|
Inherited IDs are only considered when
|
|
|
|
`org-id-link-consider-parent-id', `org-id-link-use-context' and
|
|
|
|
`org-link-context-for-files' are all enabled, since inherited IDs
|
|
|
|
are confusing without the additional search string context.
|
|
|
|
|
|
|
|
Note that this function resets the
|
|
|
|
`org-entry-property-inherited-from' marker: it will either point
|
|
|
|
to nil (if the id was not inherited) or to the point it was
|
|
|
|
inherited from."
|
|
|
|
(let* ((inherit-id (and org-id-link-consider-parent-id
|
|
|
|
org-id-link-use-context
|
|
|
|
org-link-context-for-files)))
|
|
|
|
(move-marker org-entry-property-inherited-from nil)
|
|
|
|
(org-id-get nil create nil inherit-id)))
|
2008-11-17 04:27:44 -05:00
|
|
|
|
2010-07-21 12:37:34 -04:00
|
|
|
;;;###autoload
|
2008-11-17 04:27:44 -05:00
|
|
|
(defun org-id-store-link ()
|
2021-02-06 14:27:01 -05:00
|
|
|
"Store a link to the current entry, using its ID.
|
|
|
|
|
2023-11-19 09:52:05 -05:00
|
|
|
The link description is based on the heading, or if before the
|
|
|
|
first heading, the title keyword if available, or else the
|
|
|
|
filename.
|
|
|
|
|
|
|
|
When `org-link-context-for-files' and `org-id-link-use-context'
|
|
|
|
are non-nil, add a search string to the link. The link
|
|
|
|
description is then based on the search string target.
|
|
|
|
|
|
|
|
When in addition `org-id-link-consider-parent-id' is non-nil, the
|
|
|
|
ID can be inherited from a parent entry, with the search string
|
|
|
|
used to still link to the current location."
|
2008-11-17 04:27:44 -05:00
|
|
|
(interactive)
|
2023-11-19 09:52:05 -05:00
|
|
|
(when (and (buffer-file-name (buffer-base-buffer))
|
|
|
|
(derived-mode-p 'org-mode))
|
|
|
|
;; Get the precise target first, in case looking for an id causes
|
|
|
|
;; a properties drawer to be added at the current location.
|
|
|
|
(let* ((precise-target (and org-link-context-for-files
|
|
|
|
org-id-link-use-context
|
|
|
|
(org-link-precise-link-target)))
|
|
|
|
(link (concat "id:" (org-id--get-id-to-store-link 'create)))
|
|
|
|
(id-location (or (and org-entry-property-inherited-from
|
|
|
|
(marker-position org-entry-property-inherited-from))
|
|
|
|
(save-excursion (org-back-to-heading-or-point-min t) (point))))
|
2010-11-02 18:04:10 -04:00
|
|
|
(case-fold-search nil)
|
|
|
|
(desc (save-excursion
|
2023-11-19 09:52:05 -05:00
|
|
|
(goto-char id-location)
|
2021-02-06 14:27:01 -05:00
|
|
|
(cond ((org-before-first-heading-p)
|
|
|
|
(let ((keywords (org-collect-keywords '("TITLE"))))
|
|
|
|
(if keywords
|
2021-02-07 20:05:51 -05:00
|
|
|
(cadr (assoc "TITLE" keywords))
|
2021-02-06 14:27:01 -05:00
|
|
|
(file-name-nondirectory
|
|
|
|
(buffer-file-name (buffer-base-buffer))))))
|
|
|
|
((looking-at org-complex-heading-regexp)
|
|
|
|
(if (match-end 4)
|
|
|
|
(match-string 4)
|
|
|
|
(match-string 0)))
|
|
|
|
(t link)))))
|
2023-11-19 09:52:05 -05:00
|
|
|
;; Precise targets should be after id-location to avoid
|
|
|
|
;; duplicating the current headline as a search string
|
|
|
|
(when (and precise-target
|
|
|
|
(> (nth 2 precise-target) id-location))
|
|
|
|
(setq link (concat link "::" (nth 0 precise-target)))
|
|
|
|
(setq desc (nth 1 precise-target)))
|
2018-11-26 18:04:41 -05:00
|
|
|
(org-link-store-props :link link :description desc :type "id")
|
2010-11-02 18:04:10 -04:00
|
|
|
link)))
|
2008-11-17 04:27:44 -05:00
|
|
|
|
2023-11-19 09:52:05 -05:00
|
|
|
;;;###autoload
|
|
|
|
(defun org-id-store-link-maybe (&optional interactive?)
|
|
|
|
"Store a link to the current entry using its ID if enabled.
|
|
|
|
|
|
|
|
The value of `org-id-link-to-org-use-id' determines whether an ID
|
|
|
|
link should be stored, using `org-id-store-link'.
|
|
|
|
|
|
|
|
Assume the function is called interactively if INTERACTIVE? is
|
|
|
|
non-nil."
|
|
|
|
(when (and (buffer-file-name (buffer-base-buffer))
|
|
|
|
(derived-mode-p 'org-mode)
|
|
|
|
(or (eq org-id-link-to-org-use-id t)
|
|
|
|
(and interactive?
|
|
|
|
(or (eq org-id-link-to-org-use-id 'create-if-interactive)
|
|
|
|
(and (eq org-id-link-to-org-use-id
|
|
|
|
'create-if-interactive-and-no-custom-id)
|
|
|
|
(not (org-entry-get nil "CUSTOM_ID")))))
|
|
|
|
;; 'use-existing
|
|
|
|
(and org-id-link-to-org-use-id
|
|
|
|
(org-id--get-id-to-store-link))))
|
|
|
|
(org-id-store-link)))
|
|
|
|
|
|
|
|
(defun org-id-open (link _)
|
|
|
|
"Go to the entry indicated by id link LINK.
|
|
|
|
|
|
|
|
The link can include a search string after \"::\", which is
|
|
|
|
passed to `org-link-search'.
|
|
|
|
|
|
|
|
For backwards compatibility with IDs that contain \"::\", if no
|
|
|
|
match is found for the ID, the full link string including \"::\"
|
|
|
|
will be tried as an ID."
|
|
|
|
(let* ((option (and (string-match "::\\(.*\\)\\'" link)
|
|
|
|
(match-string 1 link)))
|
|
|
|
(id (if (not option) link
|
|
|
|
(substring link 0 (match-beginning 0))))
|
|
|
|
m cmd)
|
|
|
|
(org-mark-ring-push)
|
|
|
|
(setq m (org-id-find id 'marker))
|
|
|
|
(when (and (not m) option)
|
|
|
|
;; Backwards compatibility: if id is not found, try treating
|
|
|
|
;; whole link as an id.
|
|
|
|
(setq m (org-id-find link 'marker))
|
|
|
|
(when m
|
|
|
|
(setq option 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
|
|
|
(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)
|
2023-11-19 09:52:05 -05:00
|
|
|
(when option
|
|
|
|
(save-restriction
|
|
|
|
(unless (org-before-first-heading-p)
|
|
|
|
(org-narrow-to-subtree))
|
|
|
|
(org-link-search option nil nil
|
|
|
|
(org-element-lineage (org-element-at-point) 'headline t))))
|
2022-01-16 02:07:25 -05:00
|
|
|
(org-fold-show-context)))
|
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
|
|
|
|
2023-11-19 09:52:05 -05:00
|
|
|
(org-link-set-parameters "id"
|
|
|
|
:follow #'org-id-open
|
|
|
|
:store #'org-id-store-link-maybe)
|
2008-11-17 04:27:44 -05:00
|
|
|
|
2008-02-26 11:43:55 -05:00
|
|
|
(provide 'org-id)
|
|
|
|
|
2012-10-02 02:50:46 -04:00
|
|
|
;; Local variables:
|
|
|
|
;; generated-autoload-file: "org-loaddefs.el"
|
|
|
|
;; End:
|
|
|
|
|
2008-02-26 11:43:55 -05:00
|
|
|
;;; org-id.el ends here
|