From mboxrd@z Thu Jan 1 00:00:00 1970 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: Fri, 14 Feb 2020 10:41:13 -0300 Message-ID: <878sl5ffra.fsf@gmail.com> References: <87lftw1k2n.fsf@gmail.com> <875zgb7520.fsf@gnu.org> <87sgjfgsoy.fsf@gmail.com> <87a75nexqy.fsf@gnu.org> <877e0qw14d.fsf@gmail.com> <87h7zttrjo.fsf@bzg.fr> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:55420) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2bDc-00016Z-V9 for emacs-orgmode@gnu.org; Fri, 14 Feb 2020 08:41:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2bDb-0007qq-TB for emacs-orgmode@gnu.org; Fri, 14 Feb 2020 08:41:20 -0500 In-reply-to: <87h7zttrjo.fsf@bzg.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: Bastien Cc: emacs-orgmode@gnu.org Hi Bastien, On Fri, Feb 14 2020, Bastien wrote: > 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. That was pretty much my thought too. > If you - or other ivy users - have time to investigate and report, > please do so. I've tried, when I originally reported, and now again, to pin this further down. Alas, there is much in 'org-refile-get-location' I don't understand (in the sense of not understanding why certain things are being done). I also have much to learn with respect to 'completing-read'. But I can provide an ECM to reproduce it. - Start 'emacs -Q' - Do an initial setup: #+begin_src emacs-lisp (add-to-list 'load-path "~/src/org-mode/lisp"); current master (setq org-refile-targets '(("~/org/test.org" :maxlevel . 2))) (setq org-refile-use-outline-path 'file) (setq org-outline-path-complete-in-steps nil) #+end_src - Open file "~/org/test.org", with contents: #+begin_src org ,* Top heading 1 ,* Top heading 2 ,** Entry 1 ,** Entry 2 #+end_src - Now, do some refile operations here. Inspecting 'org-refile-history' will give us: #+begin_src emacs-lisp ("test.org/Top heading 2/" "test.org/Top heading 2/" "test.org/Top heading 1/" "test.org/Top heading 1/") #+end_src - Now, we reset 'org-refile-history' and start 'ivy-mode': #+begin_src emacs-lisp (setq org-refile-history nil) (add-to-list 'load-path ".emacs.d/elpa/ivy-20200211.1338"); current Melpa (require 'ivy) (ivy-mode) #+end_src - After some refile operations, the value of 'org-refile-history' is: #+begin_src emacs-lisp ("test.org/Top heading 2" "test.org/Top heading 2" "test.org/Top heading 1" "test.org/Top heading 1") #+end_src The difference is, as previously reported, the presence/absence of the trailing slash (the "extra" in terms of 'org-refile-get-location'). As far as I can tell, it is inconsequential to the working of the refile operation, but it did intrigue me. Environment: Org mode version 9.3.6 (release_9.3.6-298-g0fa69d @ /home/gustavo/src/org-mode/lisp/); GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-11-11; ivy-20200211.1338 HTH, Gustavo.