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/)]
Hi Samuel, Samuel Wales writes: > then you asked for more details so i tried to supply what i could. > > if that is not useful, apologies for the noise. no need to apologize! Information is always useful. We may have been miscommunicating: in general, when I ask for details it means that I'd like to have enough information to reproduce the bug myself. Sometimes a formal MCE does the job, sometimes informal recollection does too. I'll keep your patch in mind for further investigation when I have some time. Thanks, -- Bastien
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/)]
Hi Gustavo, Gustavo Barros writes: > Otherwise just: > >> set this aside for now. I'll set this aside for now, but I've noted to revisit the issue later on to see if I can find a related bug---all information in this thread will be useful to revisit this, thanks again! -- Bastien
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/)]
On 2/16/20, Bastien wrote: > I'm willing to spend as much time as needed on a MCE, but I'm waiting > for this MCE before interpreting comments on code and possible bugs. i see. fyi i was not specifically trying to report a bug or supply an mce. instead, i was hoping only to contribute to understanding of the code that is currently mystifying in this thread with a concrete 1-line fix that wfm that i hoped would jog somebody's ideas to fix any issues that are under discussion, such as the trailing slashes. then you asked for more details so i tried to supply what i could. if that is not useful, apologies for the noise. i was not in a position to get into the details, and am not, but i wanted to mention something that might help. as it has been many years, and for various reasons, i will not be able to create an mce for you at this time. in addition, even if such did not apply, i have since changed my org refile settings and ido settings, and cannot use master or recent maint. i hope that i have not disrupted the thread. my fix fixed trailing slashes and duplicates, is all. -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
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/)]
Hi Bastien, On Sun, Feb 16 2020, Bastien wrote: Hi Gustavo, Gustavo Barros writes: But the fact that 'completing-read-default' returns the refile location with a double trailing slash makes me think there is still something to be fixed in 'org-refile-get-location'. if you're not tired of the hunt, please tell us when you find what needs to be fixed--since there is no bug attached to this, I'll set this aside for now. I'm afraid I have broken proper sequence of this thread unintentionally. This strip you quote comes from a message I eventually sent 14/Feb 12:33, right after a message of yours at 12:29 in which you concluded: From what I understand, this is not a bug in Org. I hope you can fix this somehow, maybe upstream. The fact is that I was writing mine when yours came, and I didn't see yours until later. And when I did, the reply was: I don't claim a problem persists in Org, and I was just trying to be thorough in the testing you requested. And did so with pleasure. So... From what I understand, this is not a bug in Org. ... if you are satisfied, I'm happy with that too. Thank you very very much! So, with the messages in proper order, I was taken the issue as settled. If, however, you do think in my message of 12:29 I hit something which might be relevant, I'd be happy to pursue this further. I'm "not tired of the hunt", but I fear the issue might well be out of my league, so there is a real risk of me wasting your time and increasing the noise on the list. Besides, as reported before, it appears not to impact functionality. But, if knowing that, you would like me to do so, I'll be glad to try. In this case, let me know. Otherwise just: set this aside for now. And thanks again! Best, Gustavo.
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/)]
Hi Samuel, sorry to insist, but what I really need is a *fiable and easy* way to reproduce a bug. Other comments (like code analysis) are only useful when I do have a reproducible bug. I'm willing to spend as much time as needed on a MCE, but I'm waiting for this MCE before interpreting comments on code and possible bugs. Thanks for your understanding, -- Bastien
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/)]
i found a note that says that there isa nother disticnitont hat was causing the bugs: a distinction between the current file and non-current file. it wreaks havoc to make that distinction. * REF this works around the bugs =this is in my personal patches vvv Modified lisp/org.el diff --git a/lisp/org.el b/lisp/org.el index ec74314..695305c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -11737,7 +11737,7 @@ this is used for the GOTO interface." (tbl (mapcar (lambda (x) (if (and (not (member org-refile-use-outline-path - '(file full-file-path))) + '(nil file full-file-path))) (not (equal filename (nth 1 x (cons (concat (car x) extra " (" (file-name-nondirectory (nth 1 x)) ")") also, the line after the + line is clearly related to the duplicate olpath and pointless current file vs. other file distinction. the workaround works because there is no olpath and no filename now, so flex matching cannot screw with assuming the default as easily. ideally, however, we would show the filename but not match on it in ido. ^^^ -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
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/)]
your quote is from a many years old report. i was providing it in case it was useful historically. -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
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/)]
non-leaf olpaths are not usefully considered to be directories in my opinion. all olpaths should be equal in status. On 2/16/20, Samuel Wales wrote: > 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 > -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
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/)]
Hi Samuel, Samuel Wales writes: > If you can't reproduce witn your ido settings, I'll try to > provide an MCE at some point. I don't use ido-mode, so I don't have any ido setting and It's difficult for me to both understand and chase the bug. I suggest you start by checking the bug is still here in latest maint *and* latest master, then (only then) propose a MCE. Thanks! -- Bastien
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/)]
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
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/)]
Hi Gustavo, Gustavo Barros writes: > But the fact that > 'completing-read-default' returns the refile location with a double > trailing slash makes me think there is still something to be fixed in > 'org-refile-get-location'. if you're not tired of the hunt, please tell us when you find what needs to be fixed--since there is no bug attached to this, I'll set this aside for now. Thanks, -- Bastien
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/)]
Hi Bastien, On Fri, Feb 14 2020, Bastien wrote: I hope you can fix this somehow, maybe upstream. Unfortunately, I'm afraid I don't understand this enough, and what 'ivy-completing-read' was supposed to do, to be able to provide a pertinent report there. I personally don't have a problem locally. I had a workaround thus far, and with your fix, I won't even need that. As previously reported, the issue initially raised is indeed fixed, and things work as expected. I don't claim a problem persists in Org, and I was just trying to be thorough in the testing you requested. And did so with pleasure. So... From what I understand, this is not a bug in Org. ... if you are satisfied, I'm happy with that too. Thank you very very much! Best, Gustavo.
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/)]
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. If you - or other ivy users - have time to investigate and report, please do so. As I said before, there is much that eludes me in 'org-refile-get-location', but I'm trying to pin this down further by getting some inspection points and trying at least to grasp where it happens. In particular, I set one inspection point exactly after the completing-read function is called to store the value of local variable "answ" which is the return value of the completing-read function. That is, right after: #+begin_src emacs-lisp (setq answ (funcall cfunc prompt tbl nil (not new-nodes) nil 'org-refile-history (or cdef (concat (car org-refile-history) extra #+end_src The value of "answ" right after this step is then: - with 'ivy-mode' off, that is with 'completing-read-default' as 'completing-read-function': "test.org/Top heading 1//" (that is with a *double trailing slash*). - with 'ivy-mode' on, that is with 'ivy-completing-read' as 'completing-read-function': "test.org/Top heading 2/" In both cases the last trailing slash seems (as far as I understand it) to be then trimmed off by 'org-refile--get-location' with: #+begin_src emacs-lisp (replace-regexp-in-string "/$" "" refloc) #+end_src Why 'ivy-completing-read' does not return the end double slash while 'completing-read-default' does, I have no idea. But the fact that 'completing-read-default' returns the refile location with a double trailing slash makes me think there is still something to be fixed in 'org-refile-get-location'. Best, Gustavo.
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/)]
Hi Gustavo, thanks for investigating further. From what I've seen, ivy-mode does not set the org-refile-history variable correctly, always setting the car of this variable to "^" after ivy-completing-read is called. >From what I understand, this is not a bug in Org. I hope you can fix this somehow, maybe upstream. Thanks, -- Bastien
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/)]
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.
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/)]
Hi Gustavo, Gustavo Barros writes: > I've tested it again, and I believe it is working as intended. Thanks for confirming. > 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. 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. If you - or other ivy users - have time to investigate and report, please do so. Thanks, -- Bastien
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/)]
Hi Samuel, Samuel Wales writes: > dunno if this is useful (probably not), but i found the following was > necessary to fix ido. What was the problem when refiling with ido? > i didn't really understand it, but it fixed it. I have tested the patch, but I'd like to understand and reproduce the bug before accepting the fix. Thanks, -- Bastien
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/)]
again not sure if relevant and probably not, but it seemed to me that the problem was related to something thinking that unix paths were being completed, and directories were treated differently from non-directories. whatever i did fixed it. took years to find and fix.
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/)]
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.
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/)]
Hi Bastien, On Thu, Feb 13 2020, Bastien wrote: Am I missing something, or wouldn't it be more appropriate `https://code.orgmode.org/bzg/org-mode.git' in the manual? Indeed, applied, thanks! Thanks!
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/)]
dunno if this is useful (probably not), but i found the following was necessary to fix ido. i didn't really understand it, but it fixed it. Date: 2014-05-19 19:57:44 -0700 === remove the parens from ido completion of olpaths Modified lisp/org.el diff --git a/lisp/org.el b/lisp/org.el index 69a288add..b2d8ec755 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -11942,7 +11942,7 @@ this function appends the default value from (tbl (mapcar (lambda (x) (if (and (not (member org-refile-use-outline-path - '(file full-file-path))) + '(nil file full-file-path))) (not (equal filename (nth 1 x (cons (concat (car x) extra " (" (file-name-nondirectory (nth 1 x)) ")") -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
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/)]
Hi Gustavo, Gustavo Barros writes: > 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. Thanks! -- Bastien
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/)]
Hi Gustavo, Gustavo Barros writes: > Am I missing something, or wouldn't it be more appropriate > `https://code.orgmode.org/bzg/org-mode.git' in the manual? Indeed, applied, thanks! -- Bastien
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/)]
Hi Bastien, On Wed, Feb 12 2020, Bastien wrote: this should be fixed in Org master branch, thanks for the detailed report. If you can confirm the fix, even better. By the way, I almost forgot, a small "side-report" on this. In going to test this from master, I followed the instructions in the manual (web version https://orgmode.org/manual/Installation.html) and those instruct users to: $ git clone g...@code.orgmode.org:bzg/org-mode.git I tried it, but lacked the password... Am I missing something, or wouldn't it be more appropriate `https://code.orgmode.org/bzg/org-mode.git' in the manual? Best, Gustavo.
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/)]
Hi Bastien, thank you very much for looking into this. On Wed, Feb 12 2020, Bastien wrote: this should be fixed in Org master branch, thanks for the detailed report. If you can confirm the fix, even better. 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? To be more precise, in terms of the ECM of the initial bug report, when refiling "Entry 2" the default target is "test.org/", when I would expect it to be "test.org/Top heading 1". Best, Gustavo.
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/)]
Hi Gustavo, this should be fixed in Org master branch, thanks for the detailed report. If you can confirm the fix, even better. Best, -- Bastien
[O] 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/)]
Hi Org list, `org-refile-get-target', when using `org-refile-use-outline-path' appends an "extra" slash at the end of every path, but candidates are stored in `org-refile-history' without that extra slash. As the default candidate passed to `completing-read' is the car of `org-refile-history' (the last refile target), the default candidate is provided in duplicity (once with the trailing slash and once without it). This is the case independent of the completion framework in use, but the difference is less prominent with the default `completing-read-default' and more so with, e.g., `ivy-completing-read'. Steps to reproduce: - Start 'emacs -Q' - Do an initial setup: #+begin_src emacs-lisp (package-initialize) (setq org-refile-targets '(("~/org/test.org" :maxlevel . 2))) (setq org-refile-use-outline-path 'file) (setq org-outline-path-complete-in-steps nil) (ivy-mode) ;; as mentioned, Ivy just makes things clearer, the issue is independent of it #+end_src - Open file "~/org/test.org", with contents: #+begin_src org ,* Top heading 1 ,* Top heading 2 ,** Entry 1 ,** Entry 2 #+end_src - Go to heading "Entry 1", refile it to "Top heading 1" - Go to heading "Entry 2", and call `org-refile' - Observe the available candidates, and notice "test.org/Top heading 1" is there twice, once as the default candidate, without a trailing slash, and also on the paths list, with the slash. Best regards, Gustavo Barros. Emacs : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-09-30 Package: Org mode version 9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/) current state: == (setq org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-refile-targets '(("~/org/test.org" :maxlevel . 2)) org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook org-show-all append local] 5] #[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes org-eldoc-load) org-outline-path-complete-in-steps nil org-archive-hook '(org-attach-archive-delete-maybe) org-confirm-elisp-link-function 'yes-or-no-p org-agenda-before-write-hook '(org-agenda-add-entry-text) org-metaup-hook '(org-babel-load-in-session-maybe) org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn ENTRY)"] org-babel-pre-tangle-hook '(save-buffer) org-tab-first-hook '(org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php) ("C" . c) ("C++" . c++) ("asymptote" . asy) ("bash" . sh) ("beamer" . latex) ("calc" . fundamental) ("cpp" . c++) ("ditaa" . artist) ("dot" . fundamental) ("elisp" . emacs-lisp) ("ocaml" . tuareg) ("screen" . shell-script) ("shell" . sh) ("sqlite" . sql)) org-occur-hook '(org-first-headline-recenter) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-speed-command-hook '(org-speed-command-activate org-babel-speed-command-activate) org-refile-use-outline-path 'file org-confirm-shell-link-function 'yes-or-no-p org-link-parameters '(("id" :follow org-id-open) ("eww" :follow eww :store org-eww-store-link) ("rmail" :follow org-rmail-open :store org-rmail-store-link) ("mhe" :follow org-mhe-open :store org-mhe-store-link) ("irc" :follow org-irc-visit :store org-irc-store-link :export org-irc-export) ("info" :follow org-info-open :export org-info-export :store org-info-store-link) ("gnus" :follow org-gnus-open :store org-gnus-store-link) ("docview" :follow org-docview-open :export org-docview-export :store org-docview-store-link) ("bibtex" :follow org-bibtex-open :store org-bibtex-store-link) ("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete org-bbdb-complete-link :store org-bbdb-store-link) ("w3m" :store org-w3m-store-link) ("file+sys") ("file+emacs") ("elfeed" :follow elfeed-link-open :store elfeed-link-store-link) ("doi" :follow org--open-doi-link) ("elisp" :follow org--open-elisp-link) ("file" :complete org-file-complete-link) ("ftp" :follow (lambda (path) (browse-url (concat "ftp:" path ("help" :follow org--open-help-link) ("http" :follow (lambda (path) (browse-url (concat "http:" path ("https" :follow (lambda (path