From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: More clocktable breakage Date: Tue, 02 May 2017 18:47:20 +0200 Message-ID: <87vapjgq93.fsf@nicolasgoaziou.fr> 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> <87tw556kxo.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5axS-00050N-8O for emacs-orgmode@gnu.org; Tue, 02 May 2017 12:47:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5axP-0004WI-5F for emacs-orgmode@gnu.org; Tue, 02 May 2017 12:47:26 -0400 Received: from relay7-d.mail.gandi.net ([2001:4b98:c:538::200]:44816) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d5axO-0004Ur-Rx for emacs-orgmode@gnu.org; Tue, 02 May 2017 12:47:23 -0400 In-Reply-To: <87tw556kxo.fsf@Rainer.invalid> (Achim Gratz's message of "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: Achim Gratz Cc: emacs-orgmode@gnu.org Hello, Achim Gratz writes: > 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. I don't pretend the contrary. I'm just talking about the current state of timestamps. Oh, and it is a really good thing Org now has a formal syntax. > 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. Indeed. >> 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. I'm not sure to understand this. Syntactical things are all about context dependence in Org. Do you mean /context independance/ needs to be dealt with elsewhere? > 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. Could you provide examples about that? In particular "providing timestamps as arguments to any processing functions" sounds odd, in particular from someone who cringes when I suggest to add a second optional argument to a single function. > 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. I do see it, tho. This is analogous to links in comments. If you see something looking like a timestamp (or a link), you can expect some commands to operate on it. This is exactly what is biting us at the moment. The real problem is that, deep into the functions calls triggered by (org-shift*), one of them expects to operate on timestamps at least from category 2 (i.e., it uses `org-at-timestamp-p') while we're in category 3. The solution is not to promote current timestamp to category 2 but to relax requirements from the guilty function, so that it also operates on category 3. Fixing it is easy: we just need to replace `org-at-timestamp-p' with (org-in-regexp org-ts-regexp) at the appropriate place. IIUC, however, we are discussing higher level details, i.e., about predicates for each category, and the developer interface we want to provide. > 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. The second category, according to my previous message, is about agenda. Writing * Entry #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" ... #+END: doesn't mean you want to display "Entry" in the agenda for today. It is but a parameter to the clocktable that happens to use timestamp syntax. It belongs neither to the first category nor the second one. >> 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. Indeed. So that doesn't qualify as a concrete proposal. Regards, -- Nicolas Goaziou