Re: [O] More clocktable breakage

Nicolas Goaziou writes: > Is your issue solved? I can confirm the issue is solved. Thanks again. 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

Re: [O] More clocktable breakage

Nicolas Goaziou writes: > I fixed the issue by extending `org-at-timestamp-p' optional argument > while preserving backward-compatibility. Thanks. That seems like a much better soultion than what we've had before and some of what we've discussed before getting there. > Is your issue solved?

Re: [O] More clocktable breakage

Hello, Achim Gratz 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

Re: [O] More clocktable breakage

Nicolas Goaziou writes: > OK. I inserted it in a fresh Org buffer. Is there any command to call on > it now? 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

Re: [O] More clocktable breakage

Hello, Achim Gratz writes: > I've told you from the beginning that it was a file at work and that it > would take some time to dig down to the problem since it did work at > home when I tried to create said ECM. I know, but I was hoping a few weeks would be enough, since the

Re: [O] More clocktable breakage

> As I asked 5 weeks ago (!), could you provide an ECM demonstrating the > issue so that I can fix it, in the light of our discussion? I've told you from the beginning that it was a file at work and that it would take some time to dig down to the problem since it did work at home when I tried to

Re: [O] More clocktable breakage

Hello, Achim Gratz writes: > No, I meant context of application, rather than context in the > syntactical sense. Org-element-* deals with syntax, nothing else. > Whether you need strict syntactical interpretation or something else > gets decided someplace else. OK. Then we

Re: [O] More clocktable breakage

Nicolas Goaziou writes: >> 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/

Re: [O] More clocktable breakage

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

Re: [O] More clocktable breakage

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

Re: [O] More clocktable breakage

Hello, Achim Gratz writes: > That's what I've been asking the whole time: when you changed that > predicate, you've basically cut off some of its consumers. It looks > like bad factoring to me to then splitting the same predicate based on > some argument. I'd rather pull

Re: [O] More clocktable breakage

Nicolas Goaziou writes: > Another idea is to add an optional argument to `org-at-timestamp-p' to > allow "sloppy" matching (or strict matching, it doesn't really matter) > and skip checks when it is required. So all functions requiring this > predicate can make use of it, as long as they call it

Re: [O] More clocktable breakage

Achim Gratz writes: > and org-at-block-p only matches in the first line of a dynamic block, [...] > N.B.: The regex used in org-at-block-p is overbroad since it matches the > whole block, I think it should use org-at-dblock-start-re instead. This old and buggy function has

Re: [O] More clocktable breakage

Nicolas Goaziou writes: #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 Thu 12:00>" #+END: clocktable > > These are not timestamps. Even though they look like timestamps, you > wouldn't want them to appear in the agenda. So

Re: [O] More clocktable breakage

Achim Gratz writes: > Achim Gratz writes: >> Nicolas Goaziou writes: >>> At the moment, I cannot reproduce it. I tried M-up in the following >>> document: >>> >>> #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend >>> "<2006-08-10 Thu 12:00>" >>> #+END:

Re: [O] More clocktable breakage

Achim Gratz writes: > Nicolas Goaziou writes: >> At the moment, I cannot reproduce it. I tried M-up in the following >> document: >> >> #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 >> Thu 12:00>" >> #+END: clocktable > > The breakage happens in this clause in

Re: [O] More clocktable breakage

Nicolas Goaziou writes: > At the moment, I cannot reproduce it. I tried M-up in the following > document: > > #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 > Thu 12:00>" > #+END: clocktable The breakage happens in this clause in org-at-timestamp-p:

Re: [O] More clocktable breakage

Hello, Achim Gratz writes: > I've just noticed that in my the clocktables at work I can't adjust the > start and end ranges anymore with up/down. Apparently the timestamps > are not recognized anymore and the it falls through to some code that > tries to adjust the :block

[O] More clocktable breakage

I've just noticed that in my the clocktables at work I can't adjust the start and end ranges anymore with up/down. Apparently the timestamps are not recognized anymore and the it falls through to some code that tries to adjust the :block argument (which is not present in that table since it's