Re: [O] Edit Links

[Nick Dokos]

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