Hello there,

Some people already have suggested and produced some code (see [1,2]) in
order to have an "attach" (or "att", as it was called) link type in
org-mode. I never found a org--complete-link function for these links
on the net, so I tried to write it for myself. In order to do that, I had
to modify org-insert-link so that the org-mode buffer is made current
(instead of *Org Links*) when calling org-link-try-special-completion.
This allows the org--complete-link family of functions to access the actual
org buffer from which org-insert-link was called. A patch in this direction
is at the end of my email. (This is the first time that I use
git-format-patch, I hope I got that right).

With that change, here is some code that adds an "att" link type with 
completion:

(defun org-att-complete-link ()
  "File completion for the \"att\" filetype in `org-mode'."
  (let* ((attach-dir (org-attach-dir nil))
         files file)
    (unless attach-dir
      (error "No attachment dir."))
    (setq files (find-lisp-find-files attach-dir "^[^.].*[^~]$")
          file (org-icompleting-read "Find attachment: "
                                       (mapcar 
                                        (lambda (x) (file-relative-name x 
attach-dir))
                                        files)
                                       nil t))
    (case org-att-complete-how
      ('full (org-attach-expand-link file))
      ('relative (concat "file:" attach-dir file))
      ('attach (concat "att:" file)))))
(defvar org-att-complete-how 'attach
"Determines how org-att-complete-link completes links to attachments.

It can be the symbols :
- `full' :: A \"file:\" link with full path is returned,
- `relative' :: a \"file:\" link containg a path relative to the directory 
where the org-file resides is returned, or
- `attach' :: an \"att:\" link is returned.

`full' is probably best avoided.")

(org-add-link-type "att" 'org-att-open-link)
(defun org-att-open-link (file)
  (org-open-file (org-attach-expand file)))

I hope that this is useful to anybody, and not too sloppy (I'm not
fluent in elisp)

[1] http://lists.gnu.org/archive/html/emacs-orgmode/2011-04/msg00010.html
[2] http://lists.gnu.org/archive/html/emacs-orgmode/2011-02/msg00952.html


The patch for the above mentionned change in org.el follows :

-- 8> --
Subject: [PATCH] Allow org--complete-read family of functions to access
 current-buffer

This allows for link-completion features based on information around the point.
---
 lisp/org.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3dfd073..fc5d709 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9411,6 +9411,7 @@ If the DEFAULT-DESCRIPTION parameter is non-nil, this 
value will
 be used as the default description."
   (interactive "P")
   (let* ((wcf (current-window-configuration))
+        (buffer (current-buffer))
         (region (if (org-region-active-p)
                     (buffer-substring (region-beginning) (region-end))))
         (remove (and region (list (region-beginning) (region-end))))
@@ -9486,7 +9487,7 @@ Use TAB to complete link prefixes, then RET for 
type-specific completion support
                    (and (equal ":" (substring link -1))
                         (member (substring link 0 -1) all-prefixes)
                         (setq link (substring link 0 -1))))
-               (setq link (org-link-try-special-completion link))))
+               (setq link (with-current-buffer buffer 
(org-link-try-special-completion link)))))
        (set-window-configuration wcf)
        (kill-buffer "*Org Links*"))
       (setq entry (assoc link org-stored-links))
-- 
1.7.12

Reply via email to