From: "Bruce V. Chiarelli" <mano155@gmail.com>
To: "Bruce V. Chiarelli" <mano155@gmail.com>, emacs-orgmode@gnu.org
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 [thread overview]
Message-ID: <CALGAe2Joi-cHAAvC4xYNtC41qA4ih1pNSYaa9oDtZMotZMKNvQ@mail.gmail.com> (raw)
In-Reply-To: <87a8dkfsou.fsf@nicolasgoaziou.fr>
2016-10-31 8:23 GMT-07:00 Nicolas Goaziou <mail@nicolasgoaziou.fr>:
> Hello,
>
> "Bruce V. Chiarelli" <mano155@gmail.com> 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
next prev parent reply other threads:[~2016-10-31 22:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-30 21:08 Tasks don't repeat correctly if system-time-locale is set to certain languages Bruce V. Chiarelli
2016-10-31 15:23 ` Nicolas Goaziou
2016-10-31 22:47 ` Bruce V. Chiarelli [this message]
2016-11-01 0:04 ` Nicolas Goaziou
2016-11-01 0:29 ` Bruce V. Chiarelli
2016-11-01 8:43 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALGAe2Joi-cHAAvC4xYNtC41qA4ih1pNSYaa9oDtZMotZMKNvQ@mail.gmail.com \
--to=mano155@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).