Structured links to headings with endless depth

Structured links to headings with endless depth

[ST]

Hi,

after reading the manual I didn't find a way to construct structured
links referring to headings with endless depth, like:

having an file.org:

* 1
** 1
** 2
*** 1
<---link here

with the link:
[[path/to/file.org::*1:2:1]]

Is this possible or should I file it as feature request?

PS: It should work also with link abbreviations:
#+LINK: file path/to/file.org::*%s
[[file:1:2:1]]

Thank you!

Re: Structured links to headings with endless depth

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

On Monday, 12 Mar 2018 at 12:09, ST wrote:
> Hi,
>
> after reading the manual I didn't find a way to construct structured
> links referring to headings with endless depth, like:

I'm not entirely sure what your use case is but could you use a target,
i.e. something like <<target>>, to indicate where you want to link to?
Cf. section 4.2 of org manual on internal links.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-191-g90607d

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: Structured links to headings with endless depth

[ST]

Adding an extra <<target>> is not an option, as it will make the text
less readable, and there is no need in this, as the headings tree
structure is already there:

* 1
** 1
** 2
*** 1

Why should I turn it into the following

* 1
** 1
** 2
*** 1
<<1>>

and then link with [[file:1]]?!... This both:
a) adds unnecessary information into the text making it less readable
b) those who read the org file as simple text without the ability to
click the link will not know where it goes... while the link
[[file:1:2:1]] makes it quite clear even without clicking it.

Example use case: scriptures with well known structure, e.g. the Bible. 


On Mon, 2018-03-12 at 10:29 +0000, Eric S Fraga wrote:
> On Monday, 12 Mar 2018 at 12:09, ST wrote:
> > Hi,
> >
> > after reading the manual I didn't find a way to construct structured
> > links referring to headings with endless depth, like:
> 
> I'm not entirely sure what your use case is but could you use a target,
> i.e. something like <<target>>, to indicate where you want to link to?
> Cf. section 4.2 of org manual on internal links.
> 

Re: Structured links to headings with endless depth

[Christian Moe]

ST writes:

> Adding an extra <<target>> is not an option, as it will make the text
> less readable, and there is no need in this, as the headings tree
> structure is already there:

Adding targets, CUSTOM_IDs or IDs are all options. You may not like them.

> * 1
> ** 1
> ** 2
> *** 1
>
> Why should I turn it into the following
>
> * 1
> ** 1
> ** 2
> *** 1
> <<1>>

With a fixed structure, you wouldn't; you'd use e.g. <<1:2:1>>.

> and then link with [[file:1]]?!... This both:
> a) adds unnecessary information into the text making it less readable

Let's not exaggerate the readability cost. And it does add information.

> b) those who read the org file as simple text without the ability to
> click the link will not know where it goes... while the link
> [[file:1:2:1]] makes it quite clear even without clicking it.

But so does the link [[1:2:1]] to the target <<1:2:1>>.

also, c): Adding a target like <<1:2:1>> to a section preserves
information about the location of that section in the source document if
you later cut that part out and insert it somewhere else. This
information is not contained in your headlines.

> Example use case: scriptures with well known structure, e.g. the Bible.

Fair enough.

But typical Org use will quickly break links like that, since Org shines
as an organizer for drafting and easily restructuring text. I don't
think Org needs a link type that would encourage people to make easily
breakable links.

I acknowledge that a separate target or CUSTOM_ID for every verse in the
Bible seems a bit heavy; if that's what you need, it might be better
solved by a custom link type.

Yours,
Christian

>
> On Mon, 2018-03-12 at 10:29 +0000, Eric S Fraga wrote:
>> On Monday, 12 Mar 2018 at 12:09, ST wrote:
>> > Hi,
>> >
>> > after reading the manual I didn't find a way to construct structured
>> > links referring to headings with endless depth, like:
>>
>> I'm not entirely sure what your use case is but could you use a target,
>> i.e. something like <<target>>, to indicate where you want to link to?
>> Cf. section 4.2 of org manual on internal links.
>>

Re: Structured links to headings with endless depth

[ST]

Thank you for your reply.

I'm not that experienced in writing in lisp. Is it difficult to create
such custom link type? What is the closest link type that you would
recommend to take as starting point (link on code, if possible)?

Thank you!


On Mon, 2018-03-12 at 14:08 +0100, Christian Moe wrote:
> ST writes:
> 
> > Adding an extra <<target>> is not an option, as it will make the text
> > less readable, and there is no need in this, as the headings tree
> > structure is already there:
> 
> Adding targets, CUSTOM_IDs or IDs are all options. You may not like them.
> 
> > * 1
> > ** 1
> > ** 2
> > *** 1
> >
> > Why should I turn it into the following
> >
> > * 1
> > ** 1
> > ** 2
> > *** 1
> > <<1>>
> 
> With a fixed structure, you wouldn't; you'd use e.g. <<1:2:1>>.
> 
> > and then link with [[file:1]]?!... This both:
> > a) adds unnecessary information into the text making it less readable
> 
> Let's not exaggerate the readability cost. And it does add information.
> 
> > b) those who read the org file as simple text without the ability to
> > click the link will not know where it goes... while the link
> > [[file:1:2:1]] makes it quite clear even without clicking it.
> 
> But so does the link [[1:2:1]] to the target <<1:2:1>>.
> 
> also, c): Adding a target like <<1:2:1>> to a section preserves
> information about the location of that section in the source document if
> you later cut that part out and insert it somewhere else. This
> information is not contained in your headlines.
> 
> > Example use case: scriptures with well known structure, e.g. the Bible.
> 
> Fair enough.
> 
> But typical Org use will quickly break links like that, since Org shines
> as an organizer for drafting and easily restructuring text. I don't
> think Org needs a link type that would encourage people to make easily
> breakable links.
> 
> I acknowledge that a separate target or CUSTOM_ID for every verse in the
> Bible seems a bit heavy; if that's what you need, it might be better
> solved by a custom link type.
> 
> Yours,
> Christian
> 
> >
> > On Mon, 2018-03-12 at 10:29 +0000, Eric S Fraga wrote:
> >> On Monday, 12 Mar 2018 at 12:09, ST wrote:
> >> > Hi,
> >> >
> >> > after reading the manual I didn't find a way to construct structured
> >> > links referring to headings with endless depth, like:
> >>
> >> I'm not entirely sure what your use case is but could you use a target,
> >> i.e. something like <<target>>, to indicate where you want to link to?
> >> Cf. section 4.2 of org manual on internal links.
> >>

Re: Structured links to headings with endless depth

[Nicolas Goaziou]

Hello,

ST <smntov@gmail.com> writes:

> I'm not that experienced in writing in lisp. Is it difficult to create
> such custom link type? What is the closest link type that you would
> recommend to take as starting point (link on code, if possible)?

I'm not answering your question, but I suggest to use a CUSTOM_ID
instead. This is readily available.

Regards,

-- 
Nicolas Goaziou

Re: Structured links to headings with endless depth

[ST]

Hello,

Ss Christian has pointed out - introduce a separate CUSTOM_ID for text
with fixed structure and rather short verses is too heavy.

I do need to write a custom link type, if this use case is not of common
interest for the orgmode community.

Thank you,


On Mon, 2018-03-12 at 15:10 +0100, Nicolas Goaziou wrote:
> Hello,
> 
> ST <smntov@gmail.com> writes:
> 
> > I'm not that experienced in writing in lisp. Is it difficult to create
> > such custom link type? What is the closest link type that you would
> > recommend to take as starting point (link on code, if possible)?
> 
> I'm not answering your question, but I suggest to use a CUSTOM_ID
> instead. This is readily available.
> 
> Regards,
> 

Re: Structured links to headings with endless depth

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

This is a tricky problem to generally solve. I think this does it
approximately well enough. It is lightly tested and works by exactly
matching headlines at subsequent levels. It will be problematic if you have
headlines with : in them, and it assumes there is a level 1 headline to
start in.

#+BEGIN_SRC emacs-lisp
(defun xpath-follow (path)
  (let* ((fields (split-string path "::"))
(fname (car fields))
(paths (split-string (cadr fields) ":"))
(level 0)
(current-point (point))
cp hls n found)
    (org-mark-ring-push)
    (find-file fname)
    (save-restriction
      (while paths
(setq cp (pop paths))
(incf level)
(setq hls (org-element-map (org-element-parse-buffer) 'headline
    (lambda (hl)
      (when (eq level (org-element-property :level hl))
hl))))
(setq n (-find-index (lambda (hl)
       (string= cp (org-no-properties
    (org-element-property :raw-value hl))))
     hls))
(if (not n)
    (progn
      (goto-char current-point)
      (user-error "%s not found" cp))
  (goto-char (org-element-property :begin (nth n hls)))
  (org-narrow-to-subtree))))))

(org-link-set-parameters
 "xpath"
 :follow 'xpath-follow)
#+END_SRC


John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Mon, Mar 12, 2018 at 8:08 AM, ST <smntov@gmail.com> wrote:

> Hello,
>
> Ss Christian has pointed out - introduce a separate CUSTOM_ID for text
> with fixed structure and rather short verses is too heavy.
>
> I do need to write a custom link type, if this use case is not of common
> interest for the orgmode community.
>
> Thank you,
>
>
> On Mon, 2018-03-12 at 15:10 +0100, Nicolas Goaziou wrote:
> > Hello,
> >
> > ST <smntov@gmail.com> writes:
> >
> > > I'm not that experienced in writing in lisp. Is it difficult to create
> > > such custom link type? What is the closest link type that you would
> > > recommend to take as starting point (link on code, if possible)?
> >
> > I'm not answering your question, but I suggest to use a CUSTOM_ID
> > instead. This is readily available.
> >
> > Regards,
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 4258 bytes --]

Re: Structured links to headings with endless depth

[Michael Brand]

Hi John

On Wed, Mar 14, 2018 at 4:49 AM, John Kitchin <jkitchin@andrew.cmu.edu> wrote:
> (defun xpath-follow (path)

Thank you for this solution. I plan to adapt it to match the link path
only to a portion of a headline branch by ignoring the higher and
lower levels not given in the link path for my use case:

,    (arbitrarily more levels upwards)
,      * [...]
,        * <composer>
,          * <work>
,            * TODO <movement>
,              * <interpreter> :5:
,                - The tag 5 is my rating of this audio recording.
,                - The audio recording is stored under the file path
,                  [...]/<composer>/<work>/<movement>/<interpreter>/<sth>.mp3
,
,    * TODO [...]
,      - The theme is very similar to this prelude
,        [[/:<composer_1>/<work_1>/<movement_1>]].
,    * [...]
,      - [...] like in this piano concert
,        [[/:<composer_2>/<work_2>]].

Michael

Re: Structured links to headings with endless depth

[Michael Brand]

[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]

Hi all

On Wed, Mar 14, 2018 at 7:58 AM Michael Brand
<michael.ch.brand@gmail.com> wrote:

> ,    (arbitrarily more levels upwards)
> ,      * [...]
> ,        * <composer>
> ,          * <work>
> ,            * TODO <movement>
> ,              * <interpreter> :5:
> ,                - The tag 5 is my rating of this audio recording.
> ,                - The audio recording is stored under the file path
> ,                  [...]/<composer>/<work>/<movement>/<interpreter>/<sth>.mp3
> ,
> ,    * TODO [...]
> ,      - The theme is very similar to this prelude
> ,        [[/:<composer_1>/<work_1>/<movement_1>]].
> ,    * [...]
> ,      - [...] like in this piano concert
> ,        [[/:<composer_2>/<work_2>]].

Despite all the valuable recommendations in this thread I implemented
something simple for my very specific use case of a music database
where I want self-explaining links with the already existing and
complete heading structure and don't want to add any ID, CUSTOM_ID or
<<target>>. See this example:

#+begin_src org
,#+STARTUP: oddeven showeverything

Specs for outline path of links to a heading, any combinations allowed
including none:
- "/" delimits headings of adjacent levels.
- A leading "/" requires matching the top level heading.
- "//" delimits heading levels with 0 to n discarded heading levels
between them.

Demo examples:
- Goes to tag 1: [[*Chopin/Prelude]]
- Goes to tag 2: [[*/Prelude]]
- Goes to tag 3: [[*d/c//b/a]]
- Goes to tag 4: [[*d/c/b/a]]
,* Foo
,** Bach
,*** Prelude
,** Chopin
,*** Prelude :1:
,* Prelude :2:
,* d
,** c
,*** Bar
,**** Baz
,***** b
,****** a :3:
,*** b
,**** a :4:
#+end_src

Limitations of this simplified implementation:
- Export of links with a path to a heading is not supported.
- Links to a heading with "/" that existed before are broken.
- There may be other issues for your use case already discussed in the
current thread (
http://lists.gnu.org/archive/html/emacs-orgmode/2018-03/msg00231.html
).

Due to the limitations this implementation is for private use only and
not meant to be commited upstream although the format of the attached
patches might imply that.

Michael

[-- Attachment #2: 0001-org-get-heading-New-parameter-no-cookie.patch --]
[-- Type: text/x-patch, Size: 2633 bytes --]

From 3a594dfa9967ed4fd70aae04559dde757fb21b1b Mon Sep 17 00:00:00 2001
From: Michael Brand <michael.ch.brand@gmail.com>
Date: Mon, 6 May 2019 18:17:52 +0200
Subject: [PATCH 1/2] org-get-heading: New parameter no-cookie

* lisp/ol.el (org-link-search): Remove regexps for comment and cookie.
* lisp/org.el (org-get-heading:): New parameter no-cookie used above.
---
 lisp/ol.el  | 10 ++--------
 lisp/org.el | 11 +++++++++--
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index a6f76a39f..f5bd63e96 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1108,18 +1108,12 @@ of matched result, which is either `dedicated' or `fuzzy'."
 		  (format "%s.*\\(?:%s[ \t]\\)?.*%s"
 			  org-outline-regexp-bol
 			  org-comment-string
-			  (mapconcat #'regexp-quote words ".+")))
-		 (cookie-re "\\[[0-9]*\\(?:%\\|/[0-9]*\\)\\]")
-		 (comment-re (format "\\`%s[ \t]+" org-comment-string)))
+			  (mapconcat #'regexp-quote words ".+"))))
 	     (goto-char (point-min))
 	     (catch :found
 	       (while (re-search-forward title-re nil t)
 		 (when (equal words
-			      (split-string
-			       (replace-regexp-in-string
-				cookie-re ""
-				(replace-regexp-in-string
-				 comment-re "" (org-get-heading t t t)))))
+			      (split-string (org-get-heading t t t t t)))
 		   (throw :found t)))
 	       nil)))
       (beginning-of-line)
diff --git a/lisp/org.el b/lisp/org.el
index 94713a7e5..48f7874ac 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6938,12 +6938,14 @@ So this will delete or add empty lines."
     (insert (make-string n ?\n))
     (move-to-column column)))
 
-(defun org-get-heading (&optional no-tags no-todo no-priority no-comment)
+(defun org-get-heading (&optional
+			no-tags no-todo no-priority no-comment no-cookie)
   "Return the heading of the current entry, without the stars.
 When NO-TAGS is non-nil, don't include tags.
 When NO-TODO is non-nil, don't include TODO keywords.
 When NO-PRIORITY is non-nil, don't include priority cookie.
 When NO-COMMENT is non-nil, don't include COMMENT string.
+When NO-COOKIE is non-nil, don't include cookie string.
 Return nil before first heading."
   (unless (org-before-first-heading-p)
     (save-excursion
@@ -6958,7 +6960,12 @@ Return nil before first heading."
 			   (replace-regexp-in-string
 			    (eval-when-compile
 			      (format "\\`%s[ \t]+" org-comment-string))
-			    "" h))
+			    ""
+			    (if no-cookie
+				(replace-regexp-in-string
+				 "\\[[0-9]*\\(?:%\\|/[0-9]*\\)\\]"
+				 "" h)
+			      h)))
 			  (h h)))
 	      (tags (and (not no-tags) (match-string 5))))
 	  (mapconcat #'identity
-- 
2.20.1


[-- Attachment #3: 0002-org-link-search-Search-for-outline-path.patch --]
[-- Type: text/x-patch, Size: 4394 bytes --]

From fee37436abbe4a7d6b79161b9230f02de6e7d54d Mon Sep 17 00:00:00 2001
From: Michael Brand <michael.ch.brand@gmail.com>
Date: Mon, 6 May 2019 18:19:44 +0200
Subject: [PATCH 2/2] org-link-search: Search for outline path

* lisp/ol.el (org-link-search): Externalize matching logic to new function
  org-link--heading-path-match-p.
  (org-link--heading-path-split):
  (org-link--heading-path-match-p): New function.
---
 lisp/ol.el | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 66 insertions(+), 3 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index f5bd63e96..b79efdf6b 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1034,7 +1034,16 @@ of matched result, which is either `dedicated' or `fuzzy'."
 	 (origin (point))
 	 (normalized (replace-regexp-in-string "\n[ \t]*" " " s))
 	 (starred (eq (string-to-char normalized) ?*))
-	 (words (split-string (if starred (substring s 1) s)))
+	 (heading-path (and starred (substring normalized 1)))
+	 (words (split-string
+		 (if starred
+		     (replace-regexp-in-string "^.*/" "" heading-path)
+		   s)))
+	 (path-rest
+	  (and starred
+	       (cdr (org-link--heading-path-split
+		     (replace-regexp-in-string "^/" "" heading-path)))))
+	 (path-rooted-p (and starred (eq ?/ (string-to-char heading-path))))
 	 (s-multi-re (mapconcat #'regexp-quote words "\\(?:[ \t\n]+\\)"))
 	 (s-single-re (mapconcat #'regexp-quote words "[ \t]+"))
 	 type)
@@ -1112,8 +1121,8 @@ of matched result, which is either `dedicated' or `fuzzy'."
 	     (goto-char (point-min))
 	     (catch :found
 	       (while (re-search-forward title-re nil t)
-		 (when (equal words
-			      (split-string (org-get-heading t t t t t)))
+		 (when (org-link--heading-path-match-p
+			words path-rest path-rooted-p)
 		   (throw :found t)))
 	       nil)))
       (beginning-of-line)
@@ -1163,6 +1172,60 @@ of matched result, which is either `dedicated' or `fuzzy'."
       (org-show-context 'link-search))
     type))
 
+(defun org-link--heading-path-split (path)
+  "Split the PATH string and enumerate the headings by contiguous groups.
+For example \"f/e//d/c/b//a\"
+=> ((\"a\" . 0) (\"b\" . 0) (\"c\" . 1) (\"d\" . 2) (\"e\" . 0) (\"f\" . 1))"
+  (apply #'append
+	 (mapcar (lambda (contiguous)
+		   (let* ((headings (reverse (split-string contiguous "/")))
+			  (enum (number-sequence 0 (1- (length headings)))))
+		     (mapcar* #'cons headings enum)))
+		 (reverse (split-string path "//")))))
+
+(defun org-link--heading-path-match-p (current path-rest path-rooted-p)
+  "Match heading hierarchy at point with CURRENT and PATH-REST.
+
+CURRENT is `split-string' of the string for the requested lowest
+level heading.
+
+PATH-REST is the `cdr' of `org-link--heading-path-split' of the
+path string originally still including the current heading.
+PATH-REST can be nil or contains the upper level headings in
+groups indicated by an enumeration starting at 0. Every 0
+indicates the beginning of a new group. Examples for PATH-REST
+values: ((\"a\" . 1) (\"b\" . 2)) which is the `cdr'
+of ((\"current\" . 0) (\"a\" . 1) (\"b\" . 2)) indicates that
+there is one group which means that it matches the Org hierarchy
+b/a/current but not b/x/a/current or b/a/x/current. ((\"a\" .
+1) (\"b\" . 0)) indicates that there are two groups separated
+between a and b which means that it matches b/a/current,
+b/x/a/current, b/x/x/a/current etc. with any number of discarded
+headings x between the groups but not b/a/x/current. ((\"a\" .
+0) (\"b\" . 1)) indicates that there are two groups separated
+between current and a which means that it matches for example
+b/a/x/current.
+
+Non-nil PATH-ROOTED-P means that the first level heading in the
+buffer must be part of the match."
+       (save-excursion
+	 (and (equal current (split-string (org-get-heading t t t t t)))
+	      (or (not path-rest)
+		  (every (lambda (heading)
+			   (let (match)
+			     (while (and (org-up-heading-safe)
+					 (not (setq match
+						    (equal (split-string
+							    (car heading))
+							   (split-string
+							    (org-get-heading
+							     t t t t t)))))
+					 (zerop (cdr heading))))
+			     match))
+			 path-rest))
+	      (or (not path-rooted-p)
+		  (eq 1 (org-outline-level))))))
+
 (defun org-link-heading-search-string (&optional string)
   "Make search string for the current headline or STRING."
   (let ((s (or string
-- 
2.20.1

Re: Structured links to headings with endless depth

[Ihor Radchenko]

Dear Michael,

> ... I want self-explaining links with the already existing and
> complete heading structure and don't want to add any ID, CUSTOM_ID or
> <<target>>. See this example:

I am wondering why you are strictly against ID properties.

The IDs can be set automatically. The property drawer can be hidden (see
https://stackoverflow.com/questions/17478260/completely-hide-the-properties-drawer-in-org-mode)
and will not clutter you org file.

An arbitrary id link can be self-explaining if you add a proper link
description: [[id:your_id][composer_1/work_1/movement_1]]. Moreover it
is not fragile against refiling or duplicate entries.

Best,
Ihor


Michael Brand <michael.ch.brand@gmail.com> writes:

> Hi all
>
> On Wed, Mar 14, 2018 at 7:58 AM Michael Brand
> <michael.ch.brand@gmail.com> wrote:
>
>> ,    (arbitrarily more levels upwards)
>> ,      * [...]
>> ,        * <composer>
>> ,          * <work>
>> ,            * TODO <movement>
>> ,              * <interpreter> :5:
>> ,                - The tag 5 is my rating of this audio recording.
>> ,                - The audio recording is stored under the file path
>> ,                  [...]/<composer>/<work>/<movement>/<interpreter>/<sth>.mp3
>> ,
>> ,    * TODO [...]
>> ,      - The theme is very similar to this prelude
>> ,        [[/:<composer_1>/<work_1>/<movement_1>]].
>> ,    * [...]
>> ,      - [...] like in this piano concert
>> ,        [[/:<composer_2>/<work_2>]].
>
> Despite all the valuable recommendations in this thread I implemented
> something simple for my very specific use case of a music database
> where I want self-explaining links with the already existing and
> complete heading structure and don't want to add any ID, CUSTOM_ID or
> <<target>>. See this example:
>
> #+begin_src org
> ,#+STARTUP: oddeven showeverything
>
> Specs for outline path of links to a heading, any combinations allowed
> including none:
> - "/" delimits headings of adjacent levels.
> - A leading "/" requires matching the top level heading.
> - "//" delimits heading levels with 0 to n discarded heading levels
> between them.
>
> Demo examples:
> - Goes to tag 1: [[*Chopin/Prelude]]
> - Goes to tag 2: [[*/Prelude]]
> - Goes to tag 3: [[*d/c//b/a]]
> - Goes to tag 4: [[*d/c/b/a]]
> ,* Foo
> ,** Bach
> ,*** Prelude
> ,** Chopin
> ,*** Prelude :1:
> ,* Prelude :2:
> ,* d
> ,** c
> ,*** Bar
> ,**** Baz
> ,***** b
> ,****** a :3:
> ,*** b
> ,**** a :4:
> #+end_src
>
> Limitations of this simplified implementation:
> - Export of links with a path to a heading is not supported.
> - Links to a heading with "/" that existed before are broken.
> - There may be other issues for your use case already discussed in the
> current thread (
> http://lists.gnu.org/archive/html/emacs-orgmode/2018-03/msg00231.html
> ).
>
> Due to the limitations this implementation is for private use only and
> not meant to be commited upstream although the format of the attached
> patches might imply that.
>
> Michael
> From 3a594dfa9967ed4fd70aae04559dde757fb21b1b Mon Sep 17 00:00:00 2001
> From: Michael Brand <michael.ch.brand@gmail.com>
> Date: Mon, 6 May 2019 18:17:52 +0200
> Subject: [PATCH 1/2] org-get-heading: New parameter no-cookie
>
> * lisp/ol.el (org-link-search): Remove regexps for comment and cookie.
> * lisp/org.el (org-get-heading:): New parameter no-cookie used above.
> ---
>  lisp/ol.el  | 10 ++--------
>  lisp/org.el | 11 +++++++++--
>  2 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/lisp/ol.el b/lisp/ol.el
> index a6f76a39f..f5bd63e96 100644
> --- a/lisp/ol.el
> +++ b/lisp/ol.el
> @@ -1108,18 +1108,12 @@ of matched result, which is either `dedicated' or `fuzzy'."
>  		  (format "%s.*\\(?:%s[ \t]\\)?.*%s"
>  			  org-outline-regexp-bol
>  			  org-comment-string
> -			  (mapconcat #'regexp-quote words ".+")))
> -		 (cookie-re "\\[[0-9]*\\(?:%\\|/[0-9]*\\)\\]")
> -		 (comment-re (format "\\`%s[ \t]+" org-comment-string)))
> +			  (mapconcat #'regexp-quote words ".+"))))
>  	     (goto-char (point-min))
>  	     (catch :found
>  	       (while (re-search-forward title-re nil t)
>  		 (when (equal words
> -			      (split-string
> -			       (replace-regexp-in-string
> -				cookie-re ""
> -				(replace-regexp-in-string
> -				 comment-re "" (org-get-heading t t t)))))
> +			      (split-string (org-get-heading t t t t t)))
>  		   (throw :found t)))
>  	       nil)))
>        (beginning-of-line)
> diff --git a/lisp/org.el b/lisp/org.el
> index 94713a7e5..48f7874ac 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -6938,12 +6938,14 @@ So this will delete or add empty lines."
>      (insert (make-string n ?\n))
>      (move-to-column column)))
>  
> -(defun org-get-heading (&optional no-tags no-todo no-priority no-comment)
> +(defun org-get-heading (&optional
> +			no-tags no-todo no-priority no-comment no-cookie)
>    "Return the heading of the current entry, without the stars.
>  When NO-TAGS is non-nil, don't include tags.
>  When NO-TODO is non-nil, don't include TODO keywords.
>  When NO-PRIORITY is non-nil, don't include priority cookie.
>  When NO-COMMENT is non-nil, don't include COMMENT string.
> +When NO-COOKIE is non-nil, don't include cookie string.
>  Return nil before first heading."
>    (unless (org-before-first-heading-p)
>      (save-excursion
> @@ -6958,7 +6960,12 @@ Return nil before first heading."
>  			   (replace-regexp-in-string
>  			    (eval-when-compile
>  			      (format "\\`%s[ \t]+" org-comment-string))
> -			    "" h))
> +			    ""
> +			    (if no-cookie
> +				(replace-regexp-in-string
> +				 "\\[[0-9]*\\(?:%\\|/[0-9]*\\)\\]"
> +				 "" h)
> +			      h)))
>  			  (h h)))
>  	      (tags (and (not no-tags) (match-string 5))))
>  	  (mapconcat #'identity
> -- 
> 2.20.1
>
> From fee37436abbe4a7d6b79161b9230f02de6e7d54d Mon Sep 17 00:00:00 2001
> From: Michael Brand <michael.ch.brand@gmail.com>
> Date: Mon, 6 May 2019 18:19:44 +0200
> Subject: [PATCH 2/2] org-link-search: Search for outline path
>
> * lisp/ol.el (org-link-search): Externalize matching logic to new function
>   org-link--heading-path-match-p.
>   (org-link--heading-path-split):
>   (org-link--heading-path-match-p): New function.
> ---
>  lisp/ol.el | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 66 insertions(+), 3 deletions(-)
>
> diff --git a/lisp/ol.el b/lisp/ol.el
> index f5bd63e96..b79efdf6b 100644
> --- a/lisp/ol.el
> +++ b/lisp/ol.el
> @@ -1034,7 +1034,16 @@ of matched result, which is either `dedicated' or `fuzzy'."
>  	 (origin (point))
>  	 (normalized (replace-regexp-in-string "\n[ \t]*" " " s))
>  	 (starred (eq (string-to-char normalized) ?*))
> -	 (words (split-string (if starred (substring s 1) s)))
> +	 (heading-path (and starred (substring normalized 1)))
> +	 (words (split-string
> +		 (if starred
> +		     (replace-regexp-in-string "^.*/" "" heading-path)
> +		   s)))
> +	 (path-rest
> +	  (and starred
> +	       (cdr (org-link--heading-path-split
> +		     (replace-regexp-in-string "^/" "" heading-path)))))
> +	 (path-rooted-p (and starred (eq ?/ (string-to-char heading-path))))
>  	 (s-multi-re (mapconcat #'regexp-quote words "\\(?:[ \t\n]+\\)"))
>  	 (s-single-re (mapconcat #'regexp-quote words "[ \t]+"))
>  	 type)
> @@ -1112,8 +1121,8 @@ of matched result, which is either `dedicated' or `fuzzy'."
>  	     (goto-char (point-min))
>  	     (catch :found
>  	       (while (re-search-forward title-re nil t)
> -		 (when (equal words
> -			      (split-string (org-get-heading t t t t t)))
> +		 (when (org-link--heading-path-match-p
> +			words path-rest path-rooted-p)
>  		   (throw :found t)))
>  	       nil)))
>        (beginning-of-line)
> @@ -1163,6 +1172,60 @@ of matched result, which is either `dedicated' or `fuzzy'."
>        (org-show-context 'link-search))
>      type))
>  
> +(defun org-link--heading-path-split (path)
> +  "Split the PATH string and enumerate the headings by contiguous groups.
> +For example \"f/e//d/c/b//a\"
> +=> ((\"a\" . 0) (\"b\" . 0) (\"c\" . 1) (\"d\" . 2) (\"e\" . 0) (\"f\" . 1))"
> +  (apply #'append
> +	 (mapcar (lambda (contiguous)
> +		   (let* ((headings (reverse (split-string contiguous "/")))
> +			  (enum (number-sequence 0 (1- (length headings)))))
> +		     (mapcar* #'cons headings enum)))
> +		 (reverse (split-string path "//")))))
> +
> +(defun org-link--heading-path-match-p (current path-rest path-rooted-p)
> +  "Match heading hierarchy at point with CURRENT and PATH-REST.
> +
> +CURRENT is `split-string' of the string for the requested lowest
> +level heading.
> +
> +PATH-REST is the `cdr' of `org-link--heading-path-split' of the
> +path string originally still including the current heading.
> +PATH-REST can be nil or contains the upper level headings in
> +groups indicated by an enumeration starting at 0. Every 0
> +indicates the beginning of a new group. Examples for PATH-REST
> +values: ((\"a\" . 1) (\"b\" . 2)) which is the `cdr'
> +of ((\"current\" . 0) (\"a\" . 1) (\"b\" . 2)) indicates that
> +there is one group which means that it matches the Org hierarchy
> +b/a/current but not b/x/a/current or b/a/x/current. ((\"a\" .
> +1) (\"b\" . 0)) indicates that there are two groups separated
> +between a and b which means that it matches b/a/current,
> +b/x/a/current, b/x/x/a/current etc. with any number of discarded
> +headings x between the groups but not b/a/x/current. ((\"a\" .
> +0) (\"b\" . 1)) indicates that there are two groups separated
> +between current and a which means that it matches for example
> +b/a/x/current.
> +
> +Non-nil PATH-ROOTED-P means that the first level heading in the
> +buffer must be part of the match."
> +       (save-excursion
> +	 (and (equal current (split-string (org-get-heading t t t t t)))
> +	      (or (not path-rest)
> +		  (every (lambda (heading)
> +			   (let (match)
> +			     (while (and (org-up-heading-safe)
> +					 (not (setq match
> +						    (equal (split-string
> +							    (car heading))
> +							   (split-string
> +							    (org-get-heading
> +							     t t t t t)))))
> +					 (zerop (cdr heading))))
> +			     match))
> +			 path-rest))
> +	      (or (not path-rooted-p)
> +		  (eq 1 (org-outline-level))))))
> +
>  (defun org-link-heading-search-string (&optional string)
>    "Make search string for the current headline or STRING."
>    (let ((s (or string
> -- 
> 2.20.1
>

Re: Structured links to headings with endless depth

[Michael Brand]

Hi Ihor

On Tue, May 7, 2019 at 5:27 AM Ihor Radchenko <yantar92@gmail.com> wrote:

> I am wondering why you are strictly against ID properties.

To me this looks like a misunderstanding. I use the ID often but my
weighting of the different advantages is not the same in all cases.
Some situations where no ID can be seen as an advantage: Looking at
the raw view (for example visible-mode during ediff), looking at the
raw file (when in the other world outside of Org mode), the time it
can take to not find an ID in all the ID files when the target file or
ID is not accessible, etc. There must be good reasons why some more
users than just me sometimes prefer the format B over A:

#+name: A
#+begin_src org
- [[id:8e5c5d87-291e-469b-a8e4-15704610c82c][The heading name]]
,* The heading name
  :PROPERTIES:
  :ID:       8e5c5d87-291e-469b-a8e4-15704610c82c
  :END:
#+end_src

#+name: B
#+begin_src org
- [[*The heading name]]
,* The heading name
#+end_src

Michael

Re: Structured links to headings with endless depth

[Ihor Radchenko]

> There must be good reasons why some more
> users than just me sometimes prefer the format B over A:

Fair enough. Thanks for the clarification.

Best,
Ihor


Michael Brand <michael.ch.brand@gmail.com> writes:

> Hi Ihor
>
> On Tue, May 7, 2019 at 5:27 AM Ihor Radchenko <yantar92@gmail.com> wrote:
>
>> I am wondering why you are strictly against ID properties.
>
> To me this looks like a misunderstanding. I use the ID often but my
> weighting of the different advantages is not the same in all cases.
> Some situations where no ID can be seen as an advantage: Looking at
> the raw view (for example visible-mode during ediff), looking at the
> raw file (when in the other world outside of Org mode), the time it
> can take to not find an ID in all the ID files when the target file or
> ID is not accessible, etc. There must be good reasons why some more
> users than just me sometimes prefer the format B over A:
>
> #+name: A
> #+begin_src org
> - [[id:8e5c5d87-291e-469b-a8e4-15704610c82c][The heading name]]
> ,* The heading name
>   :PROPERTIES:
>   :ID:       8e5c5d87-291e-469b-a8e4-15704610c82c
>   :END:
> #+end_src
>
> #+name: B
> #+begin_src org
> - [[*The heading name]]
> ,* The heading name
> #+end_src
>
> Michael

Re: Structured links to headings with endless depth

[ST]

John, thank you for this solution!

I posted this question also here:

https://emacs.stackexchange.com/q/39384/18760

So if you wish, you may add your solution also there.

Somebody there, posted also a possible solution however the syntax is
pretty heavy:

[[org-heading:/path/to/file.org::*1:2:1]]

There is a workaround using links abbreviations, but still it is a
workaround...

I think this kind of linking is useful for many general cases. Christian
has expressed concerns that such links are easily breakable which is
true but only for documents that are in draft phase (or those which are
supposed to be restructured on regular basis - like ToDo lists). However
documents that has been published, like books or scientific papers, and
will no longer change - will benefit greatly from such linking option.
Imagine you have a scientific paper in your archive that you have
already published and removed write access from it in order not to
change it accidentally. You do want to reference certain
chapter:section:subsection from it in your new paper, which you are
currently writing, but creating a target <<chapter:section:subsection>>
in the old paper is no longer an option...

So may I ask as a feature request, to please add, following link type as
standard to the org-mode:

[[path/to/file.org::chapter:section:subsection:etc:optional target]]

- chapter/section/subsection could be also just numbers
- optional target target might be <<optional target target>>
- there is no need to add '*' (like
[[path/to/file.org::*chapter:section]] to the link, as ':' after '::'
imply that headings are referred.

Thank you!

On Tue, 2018-03-13 at 20:49 -0700, John Kitchin wrote:
> This is a tricky problem to generally solve. I think this does it
> approximately well enough. It is lightly tested and works by exactly
> matching headlines at subsequent levels. It will be problematic if you
> have headlines with : in them, and it assumes there is a level 1
> headline to start in.
> 
> 
> #+BEGIN_SRC emacs-lisp
> (defun xpath-follow (path)
>   (let* ((fields (split-string path "::"))
> (fname (car fields))
> (paths (split-string (cadr fields) ":"))
> (level 0)
> (current-point (point))
> cp hls n found) 
>     (org-mark-ring-push)
>     (find-file fname)
>     (save-restriction
>       (while paths
> (setq cp (pop paths))
> (incf level)
> (setq hls (org-element-map (org-element-parse-buffer) 'headline
>     (lambda (hl)
>       (when (eq level (org-element-property :level hl))
> hl))))
> (setq n (-find-index (lambda (hl)
>        (string= cp (org-no-properties
>     (org-element-property :raw-value hl))))
>      hls))
> (if (not n)
>     (progn
>       (goto-char current-point)
>       (user-error "%s not found" cp))
>   (goto-char (org-element-property :begin (nth n hls)))
>   (org-narrow-to-subtree))))))
> 
> 
> (org-link-set-parameters
>  "xpath"
>  :follow 'xpath-follow)
> #+END_SRC
> 
> 
> 
> John
> 
> -----------------------------------
> Professor John Kitchin 
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
> 
> 
> 
> On Mon, Mar 12, 2018 at 8:08 AM, ST <smntov@gmail.com> wrote:
>         Hello,
>         
>         Ss Christian has pointed out - introduce a separate CUSTOM_ID
>         for text
>         with fixed structure and rather short verses is too heavy.
>         
>         I do need to write a custom link type, if this use case is not
>         of common
>         interest for the orgmode community.
>         
>         Thank you,
>         
>         
>         On Mon, 2018-03-12 at 15:10 +0100, Nicolas Goaziou wrote:
>         > Hello,
>         >
>         > ST <smntov@gmail.com> writes:
>         >
>         > > I'm not that experienced in writing in lisp. Is it
>         difficult to create
>         > > such custom link type? What is the closest link type that
>         you would
>         > > recommend to take as starting point (link on code, if
>         possible)?
>         >
>         > I'm not answering your question, but I suggest to use a
>         CUSTOM_ID
>         > instead. This is readily available.
>         >
>         > Regards,
>         >
>         
>         
>         
> 
> 

Re: Structured links to headings with endless depth

[Nicolas Goaziou]

Hello,

> I think this kind of linking is useful for many general cases. Christian
> has expressed concerns that such links are easily breakable which is
> true but only for documents that are in draft phase (or those which are
> supposed to be restructured on regular basis - like ToDo lists). However
> documents that has been published, like books or scientific papers, and
> will no longer change - will benefit greatly from such linking option.
> Imagine you have a scientific paper in your archive that you have
> already published and removed write access from it in order not to
> change it accidentally. You do want to reference certain
> chapter:section:subsection from it in your new paper, which you are
> currently writing, but creating a target <<chapter:section:subsection>>
> in the old paper is no longer an option...
>
> So may I ask as a feature request, to please add, following link type as
> standard to the org-mode:
>
> [[path/to/file.org::chapter:section:subsection:etc:optional target]]
>
> - chapter/section/subsection could be also just numbers
> - optional target target might be <<optional target target>>
> - there is no need to add '*' (like
> [[path/to/file.org::*chapter:section]] to the link, as ':' after '::'
> imply that headings are referred.
>
> Thank you!

Again, even in the case you are talking about, CUSTOM_ID is better, for
at least two reasons:
- it leads to much simpler links: [[file.org::#my-id]]
- it translates nicely to "id" tag in HTML.

I understand this was not so useful in your use case (only headlines, no
contents), but, it is still valid as a general mechanism.

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

Re: Structured links to headings with endless depth

[ST]

On Wed, 2018-03-14 at 14:26 +0100, Nicolas Goaziou wrote:
> Hello,
> 
> > I think this kind of linking is useful for many general cases. Christian
> > has expressed concerns that such links are easily breakable which is
> > true but only for documents that are in draft phase (or those which are
> > supposed to be restructured on regular basis - like ToDo lists). However
> > documents that has been published, like books or scientific papers, and
> > will no longer change - will benefit greatly from such linking option.
> > Imagine you have a scientific paper in your archive that you have
> > already published and removed write access from it in order not to
> > change it accidentally. You do want to reference certain
> > chapter:section:subsection from it in your new paper, which you are
> > currently writing, but creating a target <<chapter:section:subsection>>
> > in the old paper is no longer an option...
> >
> > So may I ask as a feature request, to please add, following link type as
> > standard to the org-mode:
> >
> > [[path/to/file.org::chapter:section:subsection:etc:optional target]]
> >
> > - chapter/section/subsection could be also just numbers
> > - optional target target might be <<optional target target>>
> > - there is no need to add '*' (like
> > [[path/to/file.org::*chapter:section]] to the link, as ':' after '::'
> > imply that headings are referred.
> >
> > Thank you!
> 
> Again, even in the case you are talking about, CUSTOM_ID is better, for
> at least two reasons:
> - it leads to much simpler links: [[file.org::#my-id]]

Why [[file.org::#1:2:1]] is nicer than [file.org::1:2:1]]?

> - it translates nicely to "id" tag in HTML.

You can generate the "id" tag in HTML like this 1-2-1 (if HTML dislikes
1:2:1 tag)

> 
> I understand this was not so useful in your use case (only headlines, no
> contents), but, it is still valid as a general mechanism.

Isn't a good idea to add such a built in link type in the long term?

Thank you!

Re: Structured links to headings with endless depth

[Nicolas Goaziou]

ST <smntov@gmail.com> writes:

> Why [[file.org::#1:2:1]] is nicer than [file.org::1:2:1]]?

Because you can write something more meaningful than "1:2:1" when using
a CUSTOM_ID.

>> - it translates nicely to "id" tag in HTML.
>
> You can generate the "id" tag in HTML like this 1-2-1 (if HTML dislikes
> 1:2:1 tag)

CUSTOM_ID is built-in, without implementing anything.

> Isn't a good idea to add such a built in link type in the long term?

IMO, Org has enough internal link types. 

In particular, this one brings little value compared to CUSTOM_ID. It is
fragile wrt re-ordering, refiling, capture... It may be a headache to
export, too, because "1.2.1" may mean something entirely different once
non-exportable trees have been pruned.

No offence intended, but it really sounds like a false good idea.

Re: Structured links to headings with endless depth

[ST]

On Wed, 2018-03-14 at 19:32 +0100, Nicolas Goaziou wrote:
> ST <smntov@gmail.com> writes:
> 
> > Why [[file.org::#1:2:1]] is nicer than [file.org::1:2:1]]?
> 
> Because you can write something more meaningful than "1:2:1" when using
> a CUSTOM_ID.
> 
> >> - it translates nicely to "id" tag in HTML.
> >
> > You can generate the "id" tag in HTML like this 1-2-1 (if HTML dislikes
> > 1:2:1 tag)
> 
> CUSTOM_ID is built-in, without implementing anything.
> 
> > Isn't a good idea to add such a built in link type in the long term?
> 
> IMO, Org has enough internal link types. 
> 
> In particular, this one brings little value compared to CUSTOM_ID. It is
> fragile wrt re-ordering, refiling, capture... It may be a headache to
> export, too, because "1.2.1" may mean something entirely different once
> non-exportable trees have been pruned.

Sure, numbers were just a short abstract example. This can very well be:
fruits:apples:jonagold

> 
> No offence intended, but it really sounds like a false good idea.

You definitely have more experience with org (I'm just learning), so you
indeed know better :)

Re: Structured links to headings with endless depth

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 6255 bytes --]

I don't think this should be in org-mode, it is still too fragile in many
ways.

For example, what if you have a colon in your headlines, e.g. "A chapter
about Romans 15:13".  That will will mess up the suggested approach that
splits on ":".

What if you have duplicate headlines in a hierarchy, how would you specify
the nth one?

What if you have some convention to start at level 2 headlines? what would
you do then?

What about include files?

What if you skip a level for some reason? What should the path look like
then?

If you can't put custom_ids in, the next best solution for a static file
might be to just jump to line numbers, and use a path-like link
description. That will allow you to jump to a precise line with a link that
looks like the path to that line.

[[file:some/file.org::43][1:2:3]]

Here is a function that will copy a link to the kill ring from the current
point so it is easy to paste somewhere. That link will fold so it looks
like 1:2:3 visually.

#+BEGIN_SRC emacs-lisp
(defun copy-link-with-path ()
  (interactive)
  (let ((line)
(fname (buffer-file-name))
(path-components '()))
    (save-excursion
      (org-back-to-heading)
      (setq line (line-number-at-pos))
      (push (nth 4 (org-heading-components)) path-components)

      (while (org-up-heading-safe)
(when (looking-at "*")
  (push (nth 4 (org-heading-components)) path-components)))
      (kill-new (format "[[file:%s::%s][%s]]"
fname
line
(s-join ":" path-components))))))
#+END_SRC





John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Wed, Mar 14, 2018 at 3:10 AM, ST <smntov@gmail.com> wrote:

> John, thank you for this solution!
>
> I posted this question also here:
>
> https://emacs.stackexchange.com/q/39384/18760
>
> So if you wish, you may add your solution also there.
>
> Somebody there, posted also a possible solution however the syntax is
> pretty heavy:
>
> [[org-heading:/path/to/file.org::*1:2:1]]
>
> There is a workaround using links abbreviations, but still it is a
> workaround...
>
> I think this kind of linking is useful for many general cases. Christian
> has expressed concerns that such links are easily breakable which is
> true but only for documents that are in draft phase (or those which are
> supposed to be restructured on regular basis - like ToDo lists). However
> documents that has been published, like books or scientific papers, and
> will no longer change - will benefit greatly from such linking option.
> Imagine you have a scientific paper in your archive that you have
> already published and removed write access from it in order not to
> change it accidentally. You do want to reference certain
> chapter:section:subsection from it in your new paper, which you are
> currently writing, but creating a target <<chapter:section:subsection>>
> in the old paper is no longer an option...
>
> So may I ask as a feature request, to please add, following link type as
> standard to the org-mode:
>
> [[path/to/file.org::chapter:section:subsection:etc:optional target]]
>
> - chapter/section/subsection could be also just numbers
> - optional target target might be <<optional target target>>
> - there is no need to add '*' (like
> [[path/to/file.org::*chapter:section]] to the link, as ':' after '::'
> imply that headings are referred.
>
> Thank you!
>
> On Tue, 2018-03-13 at 20:49 -0700, John Kitchin wrote:
> > This is a tricky problem to generally solve. I think this does it
> > approximately well enough. It is lightly tested and works by exactly
> > matching headlines at subsequent levels. It will be problematic if you
> > have headlines with : in them, and it assumes there is a level 1
> > headline to start in.
> >
> >
> > #+BEGIN_SRC emacs-lisp
> > (defun xpath-follow (path)
> >   (let* ((fields (split-string path "::"))
> > (fname (car fields))
> > (paths (split-string (cadr fields) ":"))
> > (level 0)
> > (current-point (point))
> > cp hls n found)
> >     (org-mark-ring-push)
> >     (find-file fname)
> >     (save-restriction
> >       (while paths
> > (setq cp (pop paths))
> > (incf level)
> > (setq hls (org-element-map (org-element-parse-buffer) 'headline
> >     (lambda (hl)
> >       (when (eq level (org-element-property :level hl))
> > hl))))
> > (setq n (-find-index (lambda (hl)
> >        (string= cp (org-no-properties
> >     (org-element-property :raw-value hl))))
> >      hls))
> > (if (not n)
> >     (progn
> >       (goto-char current-point)
> >       (user-error "%s not found" cp))
> >   (goto-char (org-element-property :begin (nth n hls)))
> >   (org-narrow-to-subtree))))))
> >
> >
> > (org-link-set-parameters
> >  "xpath"
> >  :follow 'xpath-follow)
> > #+END_SRC
> >
> >
> >
> > John
> >
> > -----------------------------------
> > Professor John Kitchin
> > Doherty Hall A207F
> > Department of Chemical Engineering
> > Carnegie Mellon University
> > Pittsburgh, PA 15213
> > 412-268-7803
> > @johnkitchin
> > http://kitchingroup.cheme.cmu.edu
> >
> >
> >
> > On Mon, Mar 12, 2018 at 8:08 AM, ST <smntov@gmail.com> wrote:
> >         Hello,
> >
> >         Ss Christian has pointed out - introduce a separate CUSTOM_ID
> >         for text
> >         with fixed structure and rather short verses is too heavy.
> >
> >         I do need to write a custom link type, if this use case is not
> >         of common
> >         interest for the orgmode community.
> >
> >         Thank you,
> >
> >
> >         On Mon, 2018-03-12 at 15:10 +0100, Nicolas Goaziou wrote:
> >         > Hello,
> >         >
> >         > ST <smntov@gmail.com> writes:
> >         >
> >         > > I'm not that experienced in writing in lisp. Is it
> >         difficult to create
> >         > > such custom link type? What is the closest link type that
> >         you would
> >         > > recommend to take as starting point (link on code, if
> >         possible)?
> >         >
> >         > I'm not answering your question, but I suggest to use a
> >         CUSTOM_ID
> >         > instead. This is readily available.
> >         >
> >         > Regards,
> >         >
> >
> >
> >
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 9027 bytes --]

Re: Structured links to headings with endless depth

[ST]

On Wed, 2018-03-14 at 07:15 -0700, John Kitchin wrote:
> I don't think this should be in org-mode, it is still too fragile in
> many ways. 
> 
> 
> For example, what if you have a colon in your headlines, e.g. "A
> chapter about Romans 15:13".  That will will mess up the suggested
> approach that splits on ":".

My bad, I didn't mean to add this specific solution, but rather improve
it till it is no longer fragile. I appealed to those who are responsible
for adding new feature requests (as described on the website) to
consider this idea (and maybe find other more stable ways to implement
it). I'm not sure who they are...

> 
> What if you have duplicate headlines in a hierarchy, how would you
> specify the nth one?

Normally there shouldn't be identical headlines on the same level (on
different levels [[My_Book::2:2:2]] is perfectly fine). Should this
happen - take first occurrence.

> 
> What if you have some convention to start at level 2 headlines? what
> would you do then?
> 
> 
> What about include files?
> 
> 
> What if you skip a level for some reason? What should the path look
> like then?

Then your structure is not well-defined and you should not use such
links.

Thank you!

> 
> 
> 
> On Wed, Mar 14, 2018 at 3:10 AM, ST <smntov@gmail.com> wrote:
>         John, thank you for this solution!
>         
>         I posted this question also here:
>         
>         https://emacs.stackexchange.com/q/39384/18760
>         
>         So if you wish, you may add your solution also there.
>         
>         Somebody there, posted also a possible solution however the
>         syntax is
>         pretty heavy:
>         
>         [[org-heading:/path/to/file.org::*1:2:1]]
>         
>         There is a workaround using links abbreviations, but still it
>         is a
>         workaround...
>         
>         I think this kind of linking is useful for many general cases.
>         Christian
>         has expressed concerns that such links are easily breakable
>         which is
>         true but only for documents that are in draft phase (or those
>         which are
>         supposed to be restructured on regular basis - like ToDo
>         lists). However
>         documents that has been published, like books or scientific
>         papers, and
>         will no longer change - will benefit greatly from such linking
>         option.
>         Imagine you have a scientific paper in your archive that you
>         have
>         already published and removed write access from it in order
>         not to
>         change it accidentally. You do want to reference certain
>         chapter:section:subsection from it in your new paper, which
>         you are
>         currently writing, but creating a target
>         <<chapter:section:subsection>>
>         in the old paper is no longer an option...
>         
>         So may I ask as a feature request, to please add, following
>         link type as
>         standard to the org-mode:
>         
>         [[path/to/file.org::chapter:section:subsection:etc:optional
>         target]]
>         
>         - chapter/section/subsection could be also just numbers
>         - optional target target might be <<optional target target>>
>         - there is no need to add '*' (like
>         [[path/to/file.org::*chapter:section]] to the link, as ':'
>         after '::'
>         imply that headings are referred.
>         
>         Thank you!
>         
>         On Tue, 2018-03-13 at 20:49 -0700, John Kitchin wrote:
>         > This is a tricky problem to generally solve. I think this
>         does it
>         > approximately well enough. It is lightly tested and works by
>         exactly
>         > matching headlines at subsequent levels. It will be
>         problematic if you
>         > have headlines with : in them, and it assumes there is a
>         level 1
>         > headline to start in.
>         >
>         >
>         > #+BEGIN_SRC emacs-lisp
>         > (defun xpath-follow (path)
>         >   (let* ((fields (split-string path "::"))
>         > (fname (car fields))
>         > (paths (split-string (cadr fields) ":"))
>         > (level 0)
>         > (current-point (point))
>         > cp hls n found)
>         >     (org-mark-ring-push)
>         >     (find-file fname)
>         >     (save-restriction
>         >       (while paths
>         > (setq cp (pop paths))
>         > (incf level)
>         > (setq hls (org-element-map (org-element-parse-buffer)
>         'headline
>         >     (lambda (hl)
>         >       (when (eq level (org-element-property :level hl))
>         > hl))))
>         > (setq n (-find-index (lambda (hl)
>         >        (string= cp (org-no-properties
>         >     (org-element-property :raw-value hl))))
>         >      hls))
>         > (if (not n)
>         >     (progn
>         >       (goto-char current-point)
>         >       (user-error "%s not found" cp))
>         >   (goto-char (org-element-property :begin (nth n hls)))
>         >   (org-narrow-to-subtree))))))
>         >
>         >
>         > (org-link-set-parameters
>         >  "xpath"
>         >  :follow 'xpath-follow)
>         > #+END_SRC
>         >
>         >
>         >
>         > John
>         >
>         > -----------------------------------
>         > Professor John Kitchin
>         > Doherty Hall A207F
>         > Department of Chemical Engineering
>         > Carnegie Mellon University
>         > Pittsburgh, PA 15213
>         > 412-268-7803
>         > @johnkitchin
>         > http://kitchingroup.cheme.cmu.edu
>         >
>         >
>         >
>         > On Mon, Mar 12, 2018 at 8:08 AM, ST <smntov@gmail.com>
>         wrote:
>         >         Hello,
>         >
>         >         Ss Christian has pointed out - introduce a separate
>         CUSTOM_ID
>         >         for text
>         >         with fixed structure and rather short verses is too
>         heavy.
>         >
>         >         I do need to write a custom link type, if this use
>         case is not
>         >         of common
>         >         interest for the orgmode community.
>         >
>         >         Thank you,
>         >
>         >
>         >         On Mon, 2018-03-12 at 15:10 +0100, Nicolas Goaziou
>         wrote:
>         >         > Hello,
>         >         >
>         >         > ST <smntov@gmail.com> writes:
>         >         >
>         >         > > I'm not that experienced in writing in lisp. Is
>         it
>         >         difficult to create
>         >         > > such custom link type? What is the closest link
>         type that
>         >         you would
>         >         > > recommend to take as starting point (link on
>         code, if
>         >         possible)?
>         >         >
>         >         > I'm not answering your question, but I suggest to
>         use a
>         >         CUSTOM_ID
>         >         > instead. This is readily available.
>         >         >
>         >         > Regards,
>         >         >
>         >
>         >
>         >
>         >
>         >
>         
>         
> 
> 

Re: Structured links to headings with endless depth

[ST]

PS: It doesn't have to be Bible. Links in form of citations, like
[[MyBook:Chapter 1:Section 5:Subsection 3]]

Is quite useful in general. Where

#+LINK: MyBook path/to/MyBook.org::*%s

It is both readable as raw text and clickable.

Maybe it will be a good idea to be able to also add a <<target>> at the
end of the tree, like: 

[[MyBook:Chapter 1:Section 5:Subsection 3:target]]

* Chapter 1
...
** Section 5
...
*** Subsection 3
...
<<target>>
...

-----------------------------

Adding an extra <<target>> is not an option, as it will make the text
less readable, and there is no need in this, as the headings tree
structure is already there:

* 1
** 1
** 2
*** 1

Why should I turn it into the following

* 1
** 1
** 2
*** 1
<<1>>

and then link with [[file:1]]?!... This both:
a) adds unnecessary information into the text making it less readable
b) those who read the org file as simple text without the ability to
click the link will not know where it goes... while the link
[[file:1:2:1]] makes it quite clear even without clicking it.

Example use case: scriptures with well known structure, e.g. the Bible. 


On Mon, 2018-03-12 at 10:29 +0000, Eric S Fraga wrote:
> On Monday, 12 Mar 2018 at 12:09, ST wrote:
> > Hi,
> >
> > after reading the manual I didn't find a way to construct structured
> > links referring to headings with endless depth, like:
> 
> I'm not entirely sure what your use case is but could you use a target,
> i.e. something like <<target>>, to indicate where you want to link to?
> Cf. section 4.2 of org manual on internal links.
>