From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Re: Feature request: Periodic events based on count of specific weekdays Date: Sat, 21 Nov 2009 08:08:06 +0100 Message-ID: References: <87ws214lpo.fsf@benfinney.id.au> <87fx8p434f.fsf@benfinney.id.au> <87bpjc4u4i.fsf@benfinney.id.au> <87vdh6gmpc.fsf_-_@benfinney.id.au> <77D21500-F2A5-45AA-9490-660C4AA7EF07@gmail.com> <87r5rsdcuk.fsf@benfinney.id.au> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NBk57-0005AC-M4 for emacs-orgmode@gnu.org; Sat, 21 Nov 2009 02:08:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NBk53-00059d-U6 for emacs-orgmode@gnu.org; Sat, 21 Nov 2009 02:08:29 -0500 Received: from [199.232.76.173] (port=54477 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBk53-00059Z-NX for emacs-orgmode@gnu.org; Sat, 21 Nov 2009 02:08:25 -0500 Received: from mail-ew0-f224.google.com ([209.85.219.224]:38308) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NBk53-0001Ko-3N for emacs-orgmode@gnu.org; Sat, 21 Nov 2009 02:08:25 -0500 Received: by ewy24 with SMTP id 24so374674ewy.26 for ; Fri, 20 Nov 2009 23:08:23 -0800 (PST) In-Reply-To: <87r5rsdcuk.fsf@benfinney.id.au> 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: Ben Finney Cc: emacs-orgmode@gnu.org Hi Ben, On Nov 20, 2009, at 11:56 PM, Ben Finney wrote: > Carsten Dominik writes: > >> extending the date format would be a significant amount of work. The >> current time/date format is already complex to handle internally, >> mainly because it was build not with a clean design but step by step. > > I don't know anything about elisp. But isn't that an indication that =20= > it > might be time to re-work the design so it's easier to maintain? Oh yes! If I were to start over, I would definitely implement the date/tim syntax in a way that is more easily expandable, and that is parsed by a single function so changes would only affect a small part of the code. This is very desirable. In fact, *many* parts in Org-mode could/should be rewritten from scratch, in a much cleaner way. Unfortunately it does not mean that this will get done, by me, any time soon. I could delve into the technical difficulties this change would have, but maybe this is not if interest here. > >> My feeling is that date specifications like this are seldomly used, > > I'm surprised at this assertion. I have not formulated precisely enough here. I believe that everyone =20= has one or a few of these types of appointments. What I mean is that it is not a frequent task to have to set up one of these, compared to how often you write down an appointment or a deadline. I, for example, set up many appointments per day, but second-tuesday-of-the-month type events only once every half year or so. > Just about every club or social > organisation, etc., that I've heard of that meets monthly, does so by > meeting =93on the second Tuesday of the month=94 or equivalent monthly > specification. It's surely not seldom in my experience. > > It may be the case that not many *programs* implement this; but has =20= > that > ever been a reason to avoid mapping a real-world need into Org mode > before? :-) :-) definitely not. > >> and as far as readability is concerned, for these few events you =20 >> could >> just (as suggested by Matt) write a note explaining what the entry >> does. > > Unfortunately, I can't see how to do that *and* have the rest of the =20= > Org > mode timestamp specification; I'm wanting to have all the current > features of Org timestamp specification plus day-of-week-based =20 > periodic > events. You are right that you cannot get the full functionality of Org-mode time stamps with diary-like ones. However, the main restriction I see is the special behavior of TODO entries which go through a repeat. On the other hand, diary-sexp entries allow you to make arbitrarily complex time stamps - any specific syntax would always be more limited. > For example, I can't see how to get an sexp timestamp to =20 > simultaneously > have a =93second Tuesday of the month=94 period and a time-of-day > specification. I also can't see how to get these specifications to > display like other Org timestamps in agenda and other generated views. * 13:00-15:00 Group meeting at the cafeteria First or third Wednesday of month from 1 to 3 in the afternoon <%%(or (diary-float t 3 1) (diary-float t 3 3))> > So, while I appreciate that the current timestamp parser design might > make implementation difficult, I don't think the current features of > either Org timestamp specification or sexp specification will meet =20 > this > goal. That's why I'm asking for this feature request. The request is duly noted and in my list of possible tasks to pick up, but I fear that the chances to get to it soon are slim. - Carsten > > I'm happy to discuss different specifications; the latest one I =20 > proposed > was for discussion, and I'm not wedded to it. Is there a different > syntax that would make parsing easier, while still adding the feature > I've described? No, the syntax is easy to parse, but there are many different places in Org which would have to learn to deal with these. > > --=20 > \ =93I distrust those people who know so well what God wants =20 > them | > `\ to do to their fellows, because it always coincides with =20 > their | > _o__) own desires.=94 =97Susan Brownell Anthony, =20= > 1896 | > Ben Finney > >