Re: More clocktable breakage

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> Yes, put the cursor on the date or time of one of the timestamps and
> press S-Up or S-Down.  It should increase or decrease the corresponding
> element of the timestamp, but instead you'll get an error message:
>
> org-clocktable-shift: Line needs a :block definition before this command works
>
> which appears because the timestamp wasn't recognized and the
> fallthrough of org-shift* then tries to apply another function that
> deals with the :block argument (which isn't present here and shouldn't
> be).

OK, reproduced.

I fixed the issue by extending `org-at-timestamp-p' optional argument
while preserving backward-compatibility.

The new docstring is:

    Non-nil if point is inside a timestamp.

    By default, the function only consider syntactically valid active
    timestamps.  However, the caller may have a broader definition
    for timestamps.  As a consequence, optional argument EXTENDED can
    be set to the following values

      `inactive'

        Include also syntactically valid inactive timestamps.

      `agenda'

        Include timestamps allowed in Agenda, i.e., those in
        properties drawers, planning lines and clock lines.

      `lax'

        Ignore context.  The function matches any part of the
        document looking like a timestamp.  This includes comments,
        example blocks...

    For backward-compatibility with Org 9.0, every other non-nil
    value is equivalent to `inactive'.

    When at a timestamp, return the position of the point as a symbol
    among `bracket', `after', `year', `month', `hour', `minute',
    `day' or a number of character from the last know part of the
    time stamp.

    When matching, the match groups are the following:
      group 1: year
      group 2: month
      group 3: day number
      group 4: day name
      group 5: hours, if any
      group 6: minutes, if any

I also updated the callers throughout the code base.

>> I start to think that there is no bug in clock tables (but certainly in
>> the cache mechanism, probably related to some `before-change-functions'
>> and `after-change-functions' misuse there).
>
> I'm not using any of those unless they already come with Emacs or Org.

What I meant is the use of `before-change-functions' and
`after-change-functions' is wrong in the caching mechanism, not in your
configuration.

Anyway, it doesn't matter for the problem at hand.

Is your issue solved?

Regards,

-- 
Nicolas Goaziou