[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Edit Links
From: |
Nick Dokos |
Subject: |
Re: [O] Edit Links |
Date: |
Mon, 14 May 2012 15:25:11 -0400 |
SW <address@hidden> wrote:
> Nick Dokos <nicholas.dokos <at> hp.com> writes:
>
> > o ``C-c C-l'' is an org-mode keybinding to org-insert-link: it takes the
> > saved information that org-store-link squirreled away and creates a
> > link at your current location.
>
> Apologies. Yes, I am inserting a link with ``C-c C-l``, navigating to the file
> and then entering a description. When navigating to the file, autocompletion
> with ``TAB`` works.
>
> My query relates to editing that link, if, for example, I have moved the file
> in
> points to. Moving over the link and pressing ``C-c C-l`` again opens the
> mini-buffer populated with "file:/home/user/example.txt". However, when
> editing
> this link now, there is no autocompletion with ``TAB``.
>
>
Thanks! I can indeed reproduce your findings. The behavior comes from
this snippet of code (part of org.el:org-insert-link):
--8<---------------cut here---------------start------------->8---
...
(cond
(link-location) ; specified by arg, just use it.
((org-in-regexp org-bracket-link-regexp 1)
;; We do have a link at point, and we are going to edit it.
(setq remove (list (match-beginning 0) (match-end 0)))
(setq desc (if (match-end 3) (org-match-string-no-properties 3)))
(setq link (read-string "Link: "
(org-link-unescape
(org-match-string-no-properties 1)))))
((or (org-in-regexp org-angle-link-re)
(org-in-regexp org-plain-link-re))
;; Convert to bracket link
(setq remove (list (match-beginning 0) (match-end 0))
link (read-string "Link: "
(org-remove-angle-brackets (match-string 0)))))
((member complete-file '((4) (16)))
;; Completing read for file names.
(setq link (org-file-complete-link complete-file)))
(t
;; Read link, with completion for stored links.
(with-output-to-temp-buffer "*Org Links*"
(princ "Insert a link.
Use TAB to complete link prefixes, then RET for type-specific completion
support\n")
...
--8<---------------cut here---------------end--------------->8---
The default case is the last one, where the link is read interactively
from the minibuffer with TAB completion on link prefixes, followed by
RET for the type-specific completion support.
When you are editing an existing link, we get into the second cond
clause (the one with the comment " ;; We do have a link at point, and we
are going to edit it.") and that one uses a straight read-string with no
completion.
I suspect that's an oversight. Not sure how easy it is to fix (my hunch
is that it should be easy to transplant the completion code into the
second case, but I don't know for sure).
It seems like a worthy candidate for attention if only for consistency's
sake, but the maintainers will have the last word on that. They might be
more easily persuaded however, if you provide a patch to fix it ;-)
Nick