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

[Tom <adatgyujto@gmail.com>]

Matt Lundin <mdl <at> imapmail.org> writes:

> 
> I still cannot reproduce it.
>

I tried your test file which was different from the test file
I suggested in the second mail and I couldn't reproduce the problem
with it either.

So I looked into this and turns out the problem occurs only if
after the state change the new day abbreviation in the timestamp
is shorter than the previous one.

In your case Sat switches to Sun, both 3 characters length.
No problem.

But in my case Szo changes to V which is two characters shorter:


--8<---------------cut here---------------start------------->8---
* TODO test1
SCHEDULED: <2011-04-02 Szo +1d>
* TODO test2 
SCHEDULED: <2011-04-03 V .+1w>
--8<---------------cut here---------------end--------------->8---


Why is it a problem?

Because org-timestamp-change starts with storing the current
cursor position which is the end of the timestamp:

15400 (defun org-timestamp-change (n &optional what updown)
15401   "Change the date in the time stamp at point.
15402 The date will be changed by N times WHAT.  WHAT can be `day', `month',
15403 `year', `minute', `second'.  If WHAT is not given, the cursor position
15404 in the timestamp determines what will be changed."
15405   (let ((pos (point))
...

http://repo.or.cz/w/org-mode.git/blob/HEAD:/lisp/org.el#l15405



and later it simply restores the position with:

15468       (goto-char pos)

http://repo.or.cz/w/org-mode.git/blob/HEAD:/lisp/org.el#l15468


The problem is in my case the new day abbreviation is two char
shorter, so the whole line is shorter, therefore the goto-char
puts the cursor in the next line (instead of at the end of the
timestamp) which triggers the bound problem I described in the
first mail:

http://article.gmane.org/gmane.emacs.orgmode/40502



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.