From: Viktor Rosenfeld <listuser36@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: An org-attach link type [7.9.1 (7.9.1-elpa @ /home/youngfrog/.emacs.d/elpa/org-20120903/)]
Date: Sat, 22 Sep 2012 09:14:24 +0200 [thread overview]
Message-ID: <20120922071424.GA942@kenny.fritz.box> (raw)
In-Reply-To: <5059DC5B.3080203@yahoo.fr>
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
>
next prev parent reply other threads:[~2012-09-22 7:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-19 14:53 An org-attach link type [7.9.1 (7.9.1-elpa @ /home/youngfrog/.emacs.d/elpa/org-20120903/)] Nicolas Richard
2012-09-22 7:14 ` Viktor Rosenfeld [this message]
2012-09-22 8:58 ` Nicolas Richard
2012-09-22 17:52 ` Viktor Rosenfeld
2012-09-22 9:20 ` Bastien
2012-09-27 16:25 ` Nicolas Richard
2012-09-28 6:43 ` Bastien
2012-09-27 16:27 ` Nicolas Richard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120922071424.GA942@kenny.fritz.box \
--to=listuser36@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).