emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug: org-refile-get-target offers default candidate in duplicity [9.


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, 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]