From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: More clocktable breakage Date: Mon, 01 May 2017 10:27:47 +0200 Message-ID: <87tw556kxo.fsf@Rainer.invalid> References: <877f39nr05.fsf@Rainer.invalid> <87d1d0p2qx.fsf@nicolasgoaziou.fr> <87tw5bumck.fsf@Rainer.invalid> <87shkt4tuf.fsf@Rainer.invalid> <8737ct1xyr.fsf@nicolasgoaziou.fr> <87fugt4npu.fsf@Rainer.invalid> <87pofxzctf.fsf@nicolasgoaziou.fr> <87wpa4fjio.fsf@Rainer.invalid> <878tmixsvo.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d56gZ-0007kH-9i for emacs-orgmode@gnu.org; Mon, 01 May 2017 04:28:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d56gW-00054G-4x for emacs-orgmode@gnu.org; Mon, 01 May 2017 04:27:59 -0400 Received: from [195.159.176.226] (port=36601 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d56gV-000541-UT for emacs-orgmode@gnu.org; Mon, 01 May 2017 04:27:56 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d56gN-00088b-QA for emacs-orgmode@gnu.org; Mon, 01 May 2017 10:27:47 +0200 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: emacs-orgmode@gnu.org Nicolas Goaziou writes: > Sadly, what a "timestamp" is depends on what function is asking. AFAICT, > there are three categories of "timestamps". Well, taking a further setp back, before Org started to have a formal syntax anything that looked like a timestamp was treated as one. The different categories of timestamps really arise from the fact that we now have syntactical timestamps and non-syntactical ones. This in turn requires that each function dealing with timestamps needs to specify what exactly it wants to deal with, but as this discussion amply shows, that isn't quite as straightforward as one would think. > Let's consider the following examples: > > (1) > SCHEDULED: <2017-04-30 dim.> > > (2) > CLOCK: [2017-04-30 dim. 08:10]--[2017-04-30 dim. 08:11] => 0:01 > > (3) > : <2017-04-30 dim.> > > (4) > :PROPERTIES: > :DATE: <2017-04-30 dim.> > :END: > > (5) > # <2017-04-30 dim.> > > (6) > > #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" > > The first category is the "strict" one, which follows Org syntax > definition. None of the examples above belong to that category. > `org-element-context' should be the relative predicate, which means that > it probably shouldn't return a timestamp object on planning lines, as it > does at the moment. I'd say anything org-element-* should exclusively return syntactical things. Context dependence needs to be dealt with elsewhere. > The second category, which is a super-set of the previous one, is > "agenda" one. Historically, Org allowed to insert timestamps in property > drawers, e.g., as in (4), and use them in the agenda. So basically, this > category contains "every timestamp that would appear as a plain > timestamp in the agenda if it were active". `org-at-timestamp-p' is > currently the relative predicate for that category. Note that the > category also contains (2) if inactive timestamps are meant to be > displayed in the agenda. I would call that meta-syntax or maybe quoted syntax: you are looking at a proper timestamp, to be used somewhere else where a timestamp is needed, but in a context that doesn't specify a timestamp itself. There are many analogous cases elsewhere in Org, so it may be a fruitful endeavour to consider this in a more general fashion. Providing timestamps as arguments to any processing functions (built into Org or otherwise) carries the requirement that they should syntactically be correct as a timestamp (so they can be converted into a timestamp object at the place of use), so all functions to insert and edit a timestamp need to work at those places. > The last category, a super-set of the "agenda" one, is the "convenience" > category. Basically, it contains every occurrence of what looks like > a timestamp, but isn't necessarily one. Obviously, every example given > above fits in there, as in every case, you can ignore that Org has > a context-dependant grammar and pretend you are on a timestamp. There is > no predicate relative to that category, but `org-at-timestamp-p' > docstring suggests to use (org-in-regexp org-ts-regexp). If I'd follow that road, I could edit what looks like a timestamp everywhere, regardless of context. I don't know if that's the right thing to do and I don't even expect consensus among the Org user base. I personally see no need to do that. > So, about the predicates, I guess we could move the second one into > "org-agenda.el" and rename it `org-agenda-at-timestamp-p'. However, > using `org-at-timestamp-p' for the last category seems a bit > far-stretched to me, since it doesn't always match timestamps. In > particular, (3) and (5) sound counter-intuitive to me and I wouldn't > like it from a developer standpoint. `org-at-timestamp' is also not > really needed for the first category, since there is already > `org-element-context'. Agreed. That's why I'm hesitant to change the org-at-timestamp-p to (org-in-regexp org-ts-regexp) in the edit functions. What I don't agree with (if I've read you correctly) is the implied assertion that the clocktable example is in the last category. Or maybe it is at the moment, but it ought to be in the second one. I consider only examples (3) and (5) to be in the "last" category. > Yet, `org-at-timestamp-p' is something users are going to look after. > Different names may also introduce confusion (remember `org-at-regexp-p' > and `org-in-regexp-p'?). So, even if it looks like bad factoring to you, > a single predicate, or even two if we set "agenda" apart, with > a docstring explaining the different categories and how to select them > may also be a good natural choice. Hence my suggestion. Since org-at-timestamp-p already has an argument, adding a second one doesn't look appealing to me, especially when the first one would often be nil. Maybe it's possible to change the definition of that argument (which would need the equivalence between t meaning 'inactive). > WDYT? Do you have any other concrete proposal? I really only need the clocktables to work again, which they'd be if they were in the second category, I gather. I've monkeypatched org-at-timestamp-p with an ((org-at-block-p)) clause so I'm good for now, but per our discussion this wouldn't be an acceptable solution. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada