|
From: | Gustavo Barros |
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 |
User-agent: | mu4e 1.2.0; emacs 26.3 |
Hi Bastien, On Thu, Feb 13 2020, Bastien wrote:
I tested it and indeed the duplicate candidate is gone. However, thelast 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.
[Prev in Thread] | Current Thread | [Next in Thread] |