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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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!
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
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
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
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
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
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
26 matches
Mail list logo
