emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] More clocktable breakage


From: Nicolas Goaziou
Subject: Re: [O] More clocktable breakage
Date: Tue, 02 May 2017 18:47:20 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Hello,

Achim Gratz <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]