From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bastien <bzg@gnu.org>
Subject: 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/)]
Date: Fri, 14 Feb 2020 11:02:51 +0100
Message-ID: <87h7zttrjo.fsf@bzg.fr>
References: <87lftw1k2n.fsf@gmail.com> <875zgb7520.fsf@gnu.org>
 <87sgjfgsoy.fsf@gmail.com> <87a75nexqy.fsf@gnu.org>
 <877e0qw14d.fsf@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org>
Received: from eggs.gnu.org ([2001:470:142:3::10]:58198)
 by lists.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <bzg@gnu.org>) id 1j2XoD-0001Xv-7C
 for emacs-orgmode@gnu.org; Fri, 14 Feb 2020 05:02:54 -0500
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org
Sender: "Emacs-orgmode"
 <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org>
To: Gustavo Barros <gusbrs.2016@gmail.com>
Cc: emacs-orgmode@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