Re: [O] [BUG] Changing TODO states sometimes modifies the schedulingof the next heading

[Bastien]

Hi Tom,

Tom adatgyu...@gmail.com writes:

 I'm a bit suprised it took so long until someone fixed the problem
 though it was a major bug (changing scheduling of items unintentionally),
 the problem was well analyzed and the solution was simple.

Apparently not.  

And the problem only hit people using locales other than english, 
maybe that explains why there was not that many complaints.

Anyway, we will provide a solution for this.

Thanks for your patience,

-- 
 Bastien

Re: [O] [BUG] Changing TODO states sometimes modifies the schedulingof the next heading

[Tom]

Nicolas Goaziou n.goaziou at gmail.com writes:
 
 Would you mind telling me if the following patch fixes your problem?
 If so, I'll apply it to the code base.
 

Yes, it seems to work with the test file I mentioned previously in
the thread.

I'm a bit suprised it took so long until someone fixed the problem
though it was a major bug (changing scheduling of items unintentionally),
the problem was well analyzed and the solution was simple.

Anyway, thanks for the fix. Now I can remove my defadvice workaround
from my setup as it apparently is no longer needed.

Re: [O] [BUG] Changing TODO states sometimes modifies the schedulingof the next heading

[Nicolas Goaziou]

Hello,

Tom adatgyu...@gmail.com writes:

 Bottom line: the problem does not occur in the English locale,
 because there all day abbreviations are 3 chars long, so the
 above described simple way of restoring the cursor position
 always works. But this is not true for all locales, so org
 shouldn't rely on that.

Would you mind telling me if the following patch fixes your problem?
If so, I'll apply it to the code base.

Regards,

-- 
Nicolas Goaziou
From 6ab4222325f304d89bb161085956bc3c2d1d7617 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Wed, 20 Jul 2011 10:18:31 +0200
Subject: [PATCH] Fix bug with TODO states changes modifying scheduling of
 next headline

* lisp/org.el (org-timestamp-change): some locales don't use the same
  length for date abbreviations. Set a marker at origin in case length
  of new timestamp is different.

Thanks to Tom for analyzing this.
---
 lisp/org.el |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index fee13b7..c08ab75 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15567,7 +15567,7 @@ With prefix ARG, change that many days.
 The date will be changed by N times WHAT.  WHAT can be `day', `month',
 `year', `minute', `second'.  If WHAT is not given, the cursor position
 in the timestamp determines what will be changed.
-  (let ((pos (point))
+  (let ((pos (copy-marker (point)))
 	with-hm inactive
 	(dm (max (nth 1 org-time-stamp-rounding-minutes) 1))
 	org-ts-what
@@ -15631,6 +15631,7 @@ in the timestamp determines what will be changed.
 	(org-insert-time-stamp time with-hm inactive nil nil extra))
   (org-clock-update-time-maybe)
   (goto-char pos)
+  (move-marker pos nil)
   ;; Try to recenter the calendar window, if any
   (if (and org-calendar-follow-timestamp-change
 	   (get-buffer-window *Calendar* t)
-- 
1.7.6