Hi Bastien,
On Fri, Feb 14 2020, Bastien wrote:
I've revisited org-refile-get-location given your new information on
ivy-completing-read but I'm not able to see something wrong in the
current implementation of org-refile-get-location. At the same time,
I don't see why ivy-completing-read would handle arguments differently
than completing-read-default, so _perhaps_ org-refile-get-location
still does something wrong.
If you - or other ivy users - have time to investigate and report,
please do so.
As I said before, there is much that eludes me in
'org-refile-get-location', but I'm trying to pin this down further by
getting some inspection points and trying at least to grasp where it
happens.
In particular, I set one inspection point exactly after the
completing-read function is called to store the value of local variable
"answ" which is the return value of the completing-read function. That
is, right after:
#+begin_src emacs-lisp
(setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history
(or cdef (concat (car org-refile-history)
extra))))
#+end_src
The value of "answ" right after this step is then:
- with 'ivy-mode' off, that is with 'completing-read-default' as
'completing-read-function': "test.org/Top heading 1//" (that is with a
*double trailing slash*).
- with 'ivy-mode' on, that is with 'ivy-completing-read' as
'completing-read-function': "test.org/Top heading 2/"
In both cases the last trailing slash seems (as far as I understand it)
to be then trimmed off by 'org-refile--get-location' with:
#+begin_src emacs-lisp
(replace-regexp-in-string "/$" "" refloc)
#+end_src
Why 'ivy-completing-read' does not return the end double slash while
'completing-read-default' does, I have no idea. But the fact that
'completing-read-default' returns the refile location with a double
trailing slash makes me think there is still something to be fixed in
'org-refile-get-location'.
Best,
Gustavo.
