From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Subject: Re: [BUG] Changing TODO states sometimes modifies the schedulingof the next heading Date: Sun, 3 Apr 2011 17:49:04 +0000 (UTC) Message-ID: References: <878vvrv4l7.fsf@fastmail.fm> <877hbbjngq.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=36186 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q6RQR-000862-5A for emacs-orgmode@gnu.org; Sun, 03 Apr 2011 13:49:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q6RQP-0005d1-DL for emacs-orgmode@gnu.org; Sun, 03 Apr 2011 13:49:22 -0400 Received: from lo.gmane.org ([80.91.229.12]:60144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q6RQP-0005cp-23 for emacs-orgmode@gnu.org; Sun, 03 Apr 2011 13:49:21 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q6RQN-0002M8-06 for emacs-orgmode@gnu.org; Sun, 03 Apr 2011 19:49:19 +0200 Received: from 94-21-240-2.pool.digikabel.hu ([94.21.240.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Apr 2011 19:49:18 +0200 Received: from adatgyujto by 94-21-240-2.pool.digikabel.hu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Apr 2011 19:49:18 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Matt Lundin 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.