Hi Alex,
Alex Kosorukoff a...@3form.com writes:
sorry, I accidentally sent my previous patch. This is the one that
belongs here.
See my other reply for this bug and let me know if it's fixed.
Thanks,
--
Bastien
Bastien:
did you mean the reply on the Capture Abort thread? This is a different
bug, unrelated to that the Capture Abort one. In this case capture doesn't
abort, but returns to a different place in buffer than the one it was
invoked from.
Thanks,
Alex
On Fri, May 23, 2014 at 5:30 AM, Bastien
Hi Alex,
Alex Kosorukoff a...@3form.com writes:
did you mean the reply on the Capture Abort thread? This is a
different bug, unrelated to that the Capture Abort one. In this case
capture doesn't abort, but returns to a different place in buffer
than the one it was invoked from.
Indeed,
Bastien:
yes, I can reproduce the bug using capmove.el with the latest master. It is
less salient in the small file that capmove makes, but very obvious in big
files where you get to a completely different place after capture finished.
Description of the steps:
1. open the same org file in two
Hi Alex,
Alex Kosorukoff a...@3form.com writes:
Description of the steps:
1. open the same org file in two frames
2. make sure the positions in those frames are different
3. try to capture something from one of those frames
4. after capture finished, the positions in those frames become the
Hello:
this is another small patch to org-capture.el to make sure that after
completion it returns to the same place from where it was invoked. This way
users won't loose track of where they were before capturing something. The
minimal setup to reproduce the case where capture fails to return to
sorry, I accidentally sent my previous patch. This is the one that belongs
here.
On Thu, May 1, 2014 at 7:00 PM, Alex Kosorukoff a...@3form.com wrote:
Hello:
this is another small patch to org-capture.el to make sure that after
completion it returns to the same place from where it was
