Re: [O] An org-attach link type [7.9.1 (7.9.1-elpa @ /home/youngfrog/.emacs.d/elpa/org-20120903/)]

[Viktor Rosenfeld]

Hi Nicolas,

I played around with your function and it's pretty nifty, but I had to make
a few changes to get it working:

- I have to load the "cl" module, otherwise the "case" function is void.
- I had to replace "find-lisp-find-files" with "directory-files" because
  the former does not exist on my Emacs installation. I use GNU Emacs
  24.2.1 on OS X compiled from MacPorts.
- I don't need to map the returned files to their relative paths.
- I couldn't find a difference between the 'relative and 'full options.
  "org-attach-expand-link" always returns the path as specified in the
  ATTACH_DIR property or constructed from the ID, but never the full
  (absolute) path unless it is explicitly specified. In other words, it
  does the same thing as your code for the 'relative options. I've
  removed both options and replaced it with a 'file option that calls
  "org-attach-expand-link".
- I use "attach" instead of "att" as a link prefix in my files and had
  to change the names of the functions. Sorry about that, but I did not
  want to fix all my links.

Code is below. I'm using Org-mode 7.9.1.

Cheers,
Viktor

#+BEGIN_SRC emacs-lisp
(defvar org-attach-complete-how 'attach
  "Determines how org-attach-complete-link completes links to attachments.

It can be the symbols :
- `file' :: A \"file:\" link is returned including the attachment directory.
- `attach' :: An \"attach:\" link is returned.")

(require 'cl)

(defun org-attach-complete-link ()
  "File completion for the \"attach\" filetype in `org-mode'."
  (let* ((attach-dir (org-attach-dir nil))
         files file)
    (unless attach-dir
      (error "No attachment dir."))
    (setq files (directory-files attach-dir nil "^[^.].*[^~]$" nil)
          file (org-icompleting-read "Find attachment: " files))
    (case org-attach-complete-how
      ('file (org-attach-expand-link file))
      ('attach (concat "attach:" file)))))
#+END_SRC

Nicolas Richard wrote:

> 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
>