From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gustavo Barros <gusbrs.2016@gmail.com>
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: Thu, 13 Feb 2020 19:53:06 -0300
Message-ID: <877e0qw14d.fsf@gmail.com>
References: <87lftw1k2n.fsf@gmail.com> <875zgb7520.fsf@gnu.org>
 <87sgjfgsoy.fsf@gmail.com> <87a75nexqy.fsf@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org>
Received: from eggs.gnu.org ([2001:470:142:3::10]:42863)
 by lists.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <gusbrs.2016@gmail.com>) id 1j2NM9-0008Jw-Sm
 for emacs-orgmode@gnu.org; Thu, 13 Feb 2020 17:53:15 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <gusbrs.2016@gmail.com>) id 1j2NM7-0006x8-OG
 for emacs-orgmode@gnu.org; Thu, 13 Feb 2020 17:53:13 -0500
In-reply-to: <87a75nexqy.fsf@gnu.org>
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: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org

Hi Bastien,

On Thu, Feb 13 2020, Bastien wrote:

>> I tested it and indeed the duplicate candidate is gone. However, the
>> last refile target no longer seems to be offered as the default for a 
>> subsequent refile operation. Was that intentional?
>
> Nope, an oversight -- fixed in master.

Thank you very much.

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

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.

Once again, thanks a lot for the fix.

Best,
Gustavo.