From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales 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: Sun, 16 Feb 2020 17:06:44 -0700 Message-ID: References: <87lftw1k2n.fsf@gmail.com> <875zgb7520.fsf@gnu.org> <87sgjfgsoy.fsf@gmail.com> <87a75nexqy.fsf@gnu.org> <87blq1trjo.fsf@bzg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:59108) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3Tw4-0005ZI-FQ for emacs-orgmode@gnu.org; Sun, 16 Feb 2020 19:06:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3Tw2-00016A-UF for emacs-orgmode@gnu.org; Sun, 16 Feb 2020 19:06:52 -0500 In-Reply-To: <87blq1trjo.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, Gustavo Barros On 2/14/20, Bastien wrote: > What was the problem when refiling with ido? idk if the following will be useful but here goes. bear in mind this was a while back. this is partly from memory. i don't know if the fix fixed all of them, but it definitely seemed to, at least with my ido settings. i tried ido settings. but i recall thinking none of them worked. it took years to fix it. my computer use is limited. - the default was screwed up (more below) causing misfiling - there was distracting, inconsistent (sometimes appearing and sometimes not), and possibly redundant (i.e. extra olpaths in list) information in parentheses - similar, except with trailing slashes (this one might have had redundancy and inconsistency properties, the latter perhaps caused by the former, as in: you don't know which version of the olpath you will get in the default) the mechanism seemed to be designed for fs paths, not olpaths. fs paths have a directory/nondirectory distinction, and this might have been related. that distinction is bad for olpaths. i do not deal with files when refiling. even if i did, there would still be no need for olpath directories for ido/ivy refiling. my olpaths when refiling are bare header lines. i think some but not all, olpaths got trailing slashes appended. i realize that's all vague. however, the fix made refiling change from dangerous and iffy and annoying to safer, more reliable, and fast (ido-clever-paths and ido-hacks also helped). i will not be able to retrace the problem less vaguely. as for the issues with the default, i reported at least one to the mailing list in some detail. it provides repro instructions. i suspect trailing slash also caused a default problem. please note that i am using an old version of maint because i can't fix a capture bug that was introduced a while back. it has perhaps been fixed since then, dunno. here is the report, for what it is worth: vvv ido and org-refile are a superb combination that enhances Org significantly. It is a killer feature IMO. However, in my usage there is a substantial risk of misfiling: 1) If I start from a fresh Emacs, "myorg" is sufficient to select "computer/emacs/org/myorg/". Good. 2) If I refile something to "computer/emacs/org/myorg/strategy and examples/various todo kw and maybe some tags/", "various" is enough to select it. Note that this is below "myorg". Good. 3) (Just as an aside, if I then refile something else to the same entry, I don't even need to enter "various". It is the default. Good.) 4) Now suppose I want to refile something to "myorg". I enter "myorg" but I get "various". Detail on this subtle issue is below: My expectation is that if "myorg" selects "myorg" once, it should always do so no matter what my refile history is. This expectation is violated. It violates a sort of referential transparency. The same narrowing inputs should produce the same narrowed outputs (in my expectation at least). I suspect the reason for the behavior is the defaulting in 3, which is useful. However, the false defaulting in 4 is not useful in any obvious way. Proposed solution: I think that as soon as the user starts selecting something, the default should be discarded. With my expectation, it is never necessary to check the offered olpaths except as a confirmation. With the current behavior, checking is always necessary because in edge cases, there will be a guaranteed misfile. Here is why: the only reason that default showed up at all is that the narrowing input matched both headlines. Otherwise the default would have been discarded. So it is an edge case that allowed the offer to misfile. In other cases, the correct default would be provided. If I wanted "various", RET would be sufficient. User checking is significantly more error-prone because one olpath is a substring of the other. Likewise, the requirement to navigate in the list is burdensome as 4 is never useful as far as I can tell. I tried looking at ido variables and got lost. If you can't reproduce witn your ido settings, I'll try to provide an MCE at some point. Thanks. Samuel ^^^ -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html