Indirect buffers, org-store-link, and org-insert-link

Indirect buffers, org-store-link, and org-insert-link

[Maxim Nikulin]

#+TITLE: Indirect buffers, ~org-store-link~, and ~org-insert-link~

#+begin_abstract
It is inconvenient to work with links pointing to =CUSTOM_ID= anchors
when indirect buffers are involved. Either file name is added to link
or appropriate link target is not stored at all.
#+end_abstract

* Introduction

I have tried to use indirect buffers (=C-u C-c C-x C-b=)
to quickly jump between 2 or 3 location in an org file.
The intention was to add some details to notes
and to cross-link them using =CUSTOM_ID= properties.
Unfortunately behavior of ~org-store-link~ and ~org-insert-link~
functions is not perfect in such use case.
~org-goto~ interface =C-u C-c C-j= is not a suitable
alternative to avoid indirect buffers especially when frame
is split into to windows and ~org-occur~ is invoked
to find something.

* Regular buffer link target
   :PROPERTIES:
   :CUSTOM_ID: reg_buf_target
   :END:

Save link to this section using
=M-x (org-store-link)=

* Link stored from regular buffer inserted to regular buffer

Insert link with =C-u C-u C-u C-c C-l=,
choose the one with =#= (it is the last one and
inserted by default) and clear link description

Actual result is just as the expected one:

: [[#reg_buf_target]]

I would like to get similar links while working with
indirect buffers containing parts of this file.

Store link once more if it was inserted without triple prefix

* Indirect buffer

Open an indirect buffer for this subtree
~M-x (org-tree-to-indirect-buffer)~
and switch to it

** Link inserted to indirect buffer
    :PROPERTIES:
    :CUSTOM_ID: indirect_buf_target
    :END:

Insert link stored from the regular buffer.
Actual result:
: [[file:indirect-link.org::#reg_buf_target]]
Expected result: no file name since link inserted
to the same file
: [[#reg_buf_target]]

Run =M-x org-store-link= to push link to this header.

** Link copied from indirect buffer and inserted to indirect buffer

=C-u C-u C-u C-c C-l= to insert link to previous section

Actual result: only link to header text is available for insertion.

Expected result: there is no problem to choose and to insert link as
: [[#indirect_buf_target]]

Close indirect buffer.

* Link stored in indirect buffer and inserted to regular buffer

Obviously, since a link with =CUSTOM_ID= anchor was not created
inside indirect buffer, it is impossible to create here a link as

: [[#indirect_buf_target]]

using completion menu.

* Version

#+begin_src emacs-lisp
   (concat (emacs-version)
	  "\n" (org-version nil 't))
#+end_src

#+RESULTS:
: GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
:  of 2020-03-26, modified by Debian
: Org mode version 9.3.7 (release_9.3.7-716-g312a64 @ 
/home/test/src/emacs/org-mode/lisp/)

Is it possible to mark indirect buffers (add some
properties, etc.) in such way that there will be
no problems to obtain and compare file name
in ~org-store-link~ and ~org-insert-link~ functions?

P.S. Maybe links to header text were fixed in 
https://orgmode.org/list/8162z2tf8n.fsf_-_@gmail.com/

[PATCH[ Re: Indirect buffers, org-store-link, and org-insert-link

[Maxim Nikulin]

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

It seems I have managed to fix store/insert link for indirect buffers by 
applying changes similar to
https://orgmode.org/list/8162z2tf8n.fsf_-_@gmail.com/
to another couple of code fragments.

Due to monkey-typing approach I am unsure that I have not broken 
something else.


[-- Attachment #2: indirect-buffer-links.patch --]
[-- Type: text/x-patch, Size: 2218 bytes --]

From 3d42f1e659b2c797629e6c041b38ae67dbe099a1 Mon Sep 17 00:00:00 2001
From: Max Nikulin <manikulin@gmail.com>
Date: Fri, 28 Aug 2020 14:49:03 +0000
Subject: [PATCH] ol.el: Fix store and insert link in indirect buffer

* lisp/ol.el(org-store-link): Store link with CUSTOM_ID anchor
in indirect buffer.
(org-insert-link): Do not add file name to search and CUSTOM_ID
links pointed to the same file when called from indirect buffer.

When a subtree was open in an indirect buffer, wrong argument
of `abbreviate-file-name' prevented storing link to a CUSTOM_ID
anchor. Internal link to a header line or to a CUSTOM_ID anchor
was created with file name instead of concise form.
This is a follow up of 784e5f1488.

TINYCHANGE
---
 lisp/ol.el | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index 76a9aca2b..951bb74e7 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1699,8 +1699,10 @@ non-nil."
 	  (push (list link desc) org-stored-links)
 	  (message "Stored: %s" (or desc link))
 	  (when custom-id
-	    (setq link (concat "file:" (abbreviate-file-name
-					(buffer-file-name)) "::#" custom-id))
+	    (setq link (concat "file:"
+			       (abbreviate-file-name
+				(buffer-file-name (buffer-base-buffer)))
+			       "::#" custom-id))
 	    (push (list link desc) org-stored-links)))
 	(car org-stored-links)))))
 
@@ -1841,13 +1843,14 @@ Use TAB to complete link prefixes, then RET for type-specific completion support
     ;; Check if we are linking to the current file with a search
     ;; option If yes, simplify the link by using only the search
     ;; option.
-    (when (and buffer-file-name
+    (when (and (buffer-file-name (buffer-base-buffer))
 	       (let ((case-fold-search nil))
 		 (string-match "\\`file:\\(.+?\\)::" link)))
       (let ((path (match-string-no-properties 1 link))
 	    (search (substring-no-properties link (match-end 0))))
 	(save-match-data
-	  (when (equal (file-truename buffer-file-name) (file-truename path))
+	  (when (equal (file-truename (buffer-file-name (buffer-base-buffer)))
+		       (file-truename path))
 	    ;; We are linking to this same file, with a search option
 	    (setq link search)))))
 
-- 
2.17.1

Re: [PATCH[ Re: Indirect buffers, org-store-link, and org-insert-link

[Bastien]

Hi Maxim,

Maxim Nikulin <manikulin@gmail.com> writes:

> It seems I have managed to fix store/insert link for indirect buffers
> by applying changes similar to
> https://orgmode.org/list/8162z2tf8n.fsf_-_@gmail.com/
> to another couple of code fragments.

This seems okay, I applied it, thanks!

You are now close to the limit of contributions we can accept without
a formal copyright assignment.

Would you like to fill in this form for future contributions?

https://orgmode.org/request-assign-future.txt

Thanks a lot!

-- 
 Bastien