From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Edit Links Date: Mon, 14 May 2012 15:25:11 -0400 Message-ID: <3918.1337023511@alphaville> References: <7220.1337006214@alphaville> Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([208.118.235.92]:33292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SU0tV-0002C2-Sk for emacs-orgmode@gnu.org; Mon, 14 May 2012 15:25:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SU0tU-0002s3-2B for emacs-orgmode@gnu.org; Mon, 14 May 2012 15:25:21 -0400 Received: from g4t0016.houston.hp.com ([15.201.24.19]:27434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SU0tT-0002ro-P8 for emacs-orgmode@gnu.org; Mon, 14 May 2012 15:25:19 -0400 In-Reply-To: Message from SW of "Mon, 14 May 2012 14:48:24 -0000." List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: SW Cc: emacs-orgmode@gnu.org SW wrote: > Nick Dokos 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