From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [bug] org-agenda-write does not handle date stamps without day of week Date: Tue, 20 Mar 2012 06:54:33 +0100 Message-ID: <90243EDA-E2F2-4A70-B446-CB2FFD4AA1CB@gmail.com> References: <2012-03-05T15-36-35@devnull.Karl-Voit.at> <2012-03-16T17-12-15@devnull.Karl-Voit.at> <5033.1331920331@alphaville> <2012-03-16T19-40-36@devnull.Karl-Voit.at> <4859.1331966740@alphaville> <30E4D375-690C-4798-B341-51268082B826@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:42464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9s1x-0003DV-6D for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 01:54:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9s1u-0000bd-Rf for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 01:54:48 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:42835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9s1u-0000bL-FO for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 01:54:46 -0400 Received: by wibhm17 with SMTP id hm17so3906726wib.0 for ; Mon, 19 Mar 2012 22:54:44 -0700 (PDT) In-Reply-To: <30E4D375-690C-4798-B341-51268082B826@gmail.com> 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: news1142@Karl-Voit.at, nicholas.dokos@hp.com, emacs-orgmode@gnu.org I have just pushed the new version of this regexp into master. Karl, let me know if it fixes the issues you where having with writing agendas. - Carsten On 19.3.2012, at 10:12, Carsten Dominik wrote: >=20 > On 17.3.2012, at 07:45, Nick Dokos wrote: >=20 >> Karl Voit wrote: >>=20 >>> * Nick Dokos wrote: >>>> Karl Voit wrote: >>>>=20 >>>> For me, it was a "no time to work on org - stash it"... >>>=20 >>> OK. I just wanted to make sure that it *is* on someone's todo list >>> :-) >>>=20 >>>>> * Karl Voit wrote: >>>>>>=20 >>>>>> * <2012-03-05 08:00-09:00> Wrong: ends up as full day event >>>>=20 >>>> org-agenda-write calls org-export-icalendar which calls = org-print-icalendar-entries >>>> which loops over all the entries and parses them, decomposing them = into timestamps. >>>> Each timestamp is then passed to org-parse-time-string. It's this = one that cannot >>>> handle non-standard formats: it uses a regexp and assumes that all = the matched parts >>>> are going to be in fixed places: >>>>=20 >>>> As to how to fix it, there are several possibilities: >>>>=20 >>>> 1. fix your scripts that produce time stamps to include = day-of-week. >>>=20 >>> Sorry, deriving DOW from an arbitrary timestamps from arbitrary data >>> sources is either pretty time consuming (calendar calculations) or >>> simply hard to calculate. >>>=20 >>> Outside Org-mode, DOW is seldom part of time-stamp data :-( >>>=20 >>>> 2. change the callers of org-parse-time-string to make sure that = DOW is included. >>>> There are roughly three dozen callers, so 2. is possible but a = pain. >>>=20 >>> Ack. >>>=20 >>>> 3. change just one caller: org-print-icalendar-entries to make sure = that DOW is included. >>>> 3. is simple but ugly as sin,=20 >>>=20 >>> Ouch, ack :-) >>>=20 >>>> 4. change org-parse-time-string to handle a missing DOW. >>>> 4. is the best way to handle it within org. >>>=20 >>> Full ack. >>>=20 >>>> I vote for 1. where *you* have to do all the work ;-) >>>=20 >>> YMMD :-) >>>=20 >>> If my brain would be compatible to ELISP, I'd send a patch. >>> Promised. >>>=20 >>> But I'll take my chance and wait for someone else (you?) >>> implementing 4. to resolve this issue for everybody. I really >>> appreciate every second you guys invest in maintaining Org-mode! >>>=20 >>=20 >> I don't know about you, but whenever I engage in hand-to-hand combat >> with a complicated regexp, I come out bruised, muddied and a lot = worse >> for wear. In any case, I'm attaching an org file with my = investigations. >> It contains a description and a code block for testing. >>=20 >> I hope that the attachment will come through unscathed: it contains >> regexps, and munging a regexp that looks like hen scratchings in the >> first place through uncooperative mailers is not something to be >> relished. >>=20 >> BTW, I'm not advocating a change: I'll leave it to Karl to do that if = he >> really wants to and to the maintainers to decide whether it's worth >> doing. But it can be done (more or less). And maybe somebody will = come >> up with a better way than the proof-of-concept that I'm attaching = here. >=20 > Hi Nick and Karl, >=20 > since we did make a change to Org a while ago to allow date stamps > without the name of the day, I think it is only consequent to also do > it for this case. Must have slipped our attention back then. > The only thing we must ensure is that this regexp matches fast > as it is used a lot. >=20 > Nick's proposal works, except for the fact that is also matches when > the time is directly attached to day name. Maybe it is cleaner to > not match in this case. >=20 > If we are going to make the day name optional, then it is better to > include matching of the whitespace after the date into the day-name > part of the regexp. >=20 > I am attaching Nick's file again, with a third proposal for an > updated regexp. >=20 > As far as speed is concerned, this regexp will, if there is name > and time, match directly and straight. If the date name is > missing, it will notice on the first digit belonging to > the time and switch without backtracking (well, minimal > backtracking when there are multiple spaces) to the regexp > section for the time of day. Rematching the spaces after the > date will be the only overhead. >=20 > Cheers >=20 > - Carsten >=20 > >=20 >=20 >=20 >>=20 >> Nick >>=20 >> PS. BTW, if you look at the attachment, it helps if you have a wide = window, >> something like 165 characters wide. >>=20 >> >=20