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
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?
I'l
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 needs a :block definitio
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 get
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
resolution of the i
> 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 c
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 agree here.
> Whate
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/ need
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
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 cat
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 out the old sloppy mat
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 pr
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 nothing to do with t
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 `org-at-timestamp-p'
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: clocktable
These are no
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 o
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:
--8<---
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 argument (which is not
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 usi
19 matches
Mail list logo
