From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bruce V. Chiarelli" Subject: Re: Tasks don't repeat correctly if system-time-locale is set to certain languages Date: Mon, 31 Oct 2016 15:47:51 -0700 Message-ID: References: <87a8dkfsou.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1LMx-0006h6-FQ for emacs-orgmode@gnu.org; Mon, 31 Oct 2016 18:47:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1LMw-0001pl-9R for emacs-orgmode@gnu.org; Mon, 31 Oct 2016 18:47:55 -0400 Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233]:36771) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c1LMw-0001oh-1h for emacs-orgmode@gnu.org; Mon, 31 Oct 2016 18:47:54 -0400 Received: by mail-wm0-x233.google.com with SMTP id p190so174975702wmp.1 for ; Mon, 31 Oct 2016 15:47:53 -0700 (PDT) In-Reply-To: <87a8dkfsou.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: "Bruce V. Chiarelli" , emacs-orgmode@gnu.org 2016-10-31 8:23 GMT-07:00 Nicolas Goaziou : > Hello, > > "Bruce V. Chiarelli" writes: > >> I've noticed some unusual behavior with repeating entries when the >> system-time-locale variable is set. Specifically: >> >> It is Sunday, today, October 30th. I did not mark this task, which is >> a habit, yesterday. >> >> -- If I have (setq system-time-locale "hu_HU.utf8"), Hungarian, then >> marking this task DONE >> >> * TODO Anki basic reviews :habit:study: >> SCHEDULED: <2016-10-29 szo .+1d> >> >> v----becomes----v >> >> * TODO Anki basic reviews :habit:study: >> SCHEDULED: <2016-10-30 v .+1d> >> >> Which is not correct. I marked it DONE today, so it should repeat tomorrow. >> >> -- If I have (setq system-time-locale "es_MX.utf8"), Mexican Spanish, >> then doing the same thing: >> >> * TODO Anki basic reviews :habit:study: >> SCHEDULED: <2016-10-29 szo .+1d> >> >> v----becomes----v >> >> * TODO Anki basic reviews :habit:study: >> SCHEDULED: <2016-10-31 lun .+1d> >> >> Which *is* correct. I have tried this with an unset >> system-time-locale, and with it set to fa_IR, es_MX, en_GB, and hu_HU. >> So far, hu_HU is the only one that behaves incorrectly. Note that it >> doesn't seem to matter which language the day-of-the-week abbreviation >> is already in, since every time I tried this, I reverted the file back >> to the Hungarian line. Changing the date to <2016-10-29 Sat .+1d> >> before marking it also had no effect. >> >> Of course, I could just set the date locale to "C" or unset it, but >> there's still a bug somewhere. > > I tend to think this is not a bug in Org mode, since it correctly work > with other locales, and we do not control locales. I thought so too, to be honest, but I got my hands dirty and I think I've figured out where the actual problem lies. I did the bisect earlier, and the breaking change was right when the code to handle native language day names was added as part of Org 8.0. I got a bit disorganized and lost the exact commit, but I can try to find it if need be. Anyway, I started the lisp debugger to trace what was happening and found the real problem. I hope someone can confirm. org-todo calls org-auto-repeat-maybe, which sees the ".+" style repeater. It calls org-timestamp-change to move the timestamp up to today. Point is left at the closing bracket. So far, so good. org-timestamp-change sets origin-cat to 'after and origin to (point). It then changes the timestamp to today as advertized. Now these lines get evaluated (goto-char (cond ;; `day' category ends before `hour' if any, or at ;; the end of the day name. ((eq origin-cat 'day) (min (or (match-beginning 7) (- (match-end 5) 2)) origin)) ((eq origin-cat 'hour) (min (match-end 7) origin)) ((eq origin-cat 'minute) (min (1- (match-end 8)) origin)) ((integerp origin-cat) (min (1- (match-end 0)) origin)) ;; `year' and `month' have both fixed size: point ;; couldn't have moved into another part. (t origin)))) The since origin-cat is 'after, matching nothing else, we get (goto-char origin). This seems to be where the problem lies. When "<2016-10-29 szo .+1>" becomes "<2016-10-31 h .+1>" (today), origin is now two characters ahead of where it should be, now on the next line in fact. So it returns fine at first, but when org-auto-repeat maybe calls org-timestamp-change a second time to move the date into the future, it throws the error "Not at a timestamp" and does nothing else. I wasn't seeing this error until I was in the debugger, since org-auto-repeat-maybe puts an "Entry repeats: ..." message in the echo area. Oddly enough, that message shows the correct date since org-last-changed-timestamp gets updated properly. -BC > Anyway, could you try bisecting and tell us when the bug was born? > > Regards, > > -- > Nicolas Goaziou