Edit Links

Edit Links

[SW]

I inserted a link to a file with "C-c l", "file" and then navigated to the file
using autocompletion of the path and file names. Movinvg over that link and
pressing "C-c l" prompts me with the path to the file. Edits in this path will
not longer support autocompletion now. I have searched both generally and here
for phrases relating to editing links but have not found anything.

Re: Edit Links

[Nick Dokos]

SW <sabrewolfy@gmail.com> wrote:

> I inserted a link to a file with "C-c l", "file" and then navigated to the file
> using autocompletion of the path and file names. Movinvg over that link and
> pressing "C-c l" prompts me with the path to the file. Edits in this path will
> not longer support autocompletion now. I have searched both generally and here
> for phrases relating to editing links but have not found anything.
> 

I don't really follow what you are trying to do but I wonder if you are describing
your situation correctly. There are two relevant keybindings:

o ``C-c l'' is the suggested global keybinding to org-store-link: what
  it does is squirrel away the information of where you are at the time
  so that it can be used *later* to insert a link - so all this does is
  remember the metadata of the link.

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.

I suspect you are using the second. If so, it should prompt you in the
minibuffer for a link. You enter something like

file:/home/sw/.emacs RET

and then it prompts you for a description - you enter the description of
the link, something like

my .emacs file RET

Org will then insert a link like this:

[[file:/home/sw/.emacs][my .emacs file]]

into your file. It might *appear* different (what you see is just the
description, usually in some highlight color and underlined), but
nevertheless that's what the buffer contains (if you don't believe me,
just cat the file).

To follow the link, you just click on it (or do it in various other
ways, depending on your setup; e.g. pressing C-c C-o on it should also
follow the link).

Hope this clarifies things, but if you have questions, don't hesitate to
ask.  However, try to make your question detailed enough so that we
don't have to guess what you are trying to do.

Nick

Re: Edit Links

[SW]

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

Re: Edit Links

[Nick Dokos]

SW <sabrewolfy@gmail.com> 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