Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

[Bastien <bzg@gnu.org>]

Hi Gustavo,

Gustavo Barros <gusbrs.2016@gmail.com> writes:

> I've tested it again, and I believe it is working as intended.

Thanks for confirming.

> I observe, however, a difference of behavior between
> "completing-read-default" and "ivy-completing-read" in the workings of 
> "org-refile-get-location". Namely, with "completing-read-default" the
> chosen target is stored in "org-refile-history" with a trailing slash 
> (the "extra" part), while with "ivy-completing-read" it is stored
> without the trailing slash.
>
> I have no idea why this is so and also don't know if this stems from
> Org's end. As far as I can tell, functionality of the feature with 
> respect to this bug report is working as intended: no duplicate
> candidates, and history is honored. But the difference surprised me
> and if you think it might be important, I can provide an ECM for it.
> Otherwise, I think this can well closed as fixed.

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.

Thanks,

-- 
 Bastien