Re: [O] Sticky agenda branch merged

[Rainer Stengele]

Hi Max,

I'll try later.

What I just found:

being in a sticky agenda and trying "v r" I get this error which was not there 
before the merge:
org-agenda-check-type: Not allowed in nil-type agenda buffers.
Actually "v c" directly before entering "v r" gave results!

Thanks,
Rainer

Am 17.04.2012 17:32, schrieb Max Mikhanosha:
> Hi Rainer, 
> 
> At Tue, 17 Apr 2012 15:23:00 +0200,
> Rainer Stengele wrote:
>>
>> Am 17.04.2012 14:29, schrieb Max Mikhanosha:
>>> At Tue, 17 Apr 2012 12:09:40 +0200,
>>> Rainer Stengele wrote:
>>>> Am 16.04.2012 11:47, schrieb Max Mikhanosha:
>>>>> I had just pushed a merge of max-sticky-agenda branch to master, let
>>>>> me know if there are any problems, also feel free to hack/iterate on
>>>> I see a strange behaviour when clocking in with C-c C-x C-i.
>>>> Sometimes (!) there is no new CLOCK: entry created.
>>>> The TODO state changes as expected, but no new CLOCK: line is created, 
>>>> even when clocking out.
>>>> Looks like this happens when the initial TODO state is set.
>>>>
>>>> Maybe I missed a change in the behaviour?
>>> Rainer, I can't reproduce this, can you give me a few more details?
>>>
>>> 1. Are you doing C-c C-x C-i from agenda, or from an Org File?
>>
>> from org file
>>
>>>
>>> 2. I don't understand the "TODO state changes as expected" part, I
>>> thought clock-in command has no effect on todo state, ie it simply
>>> adds CLOCK line to logbook drawer. Is there some extra configuration I
>>> need to change to enable this bit?
>>
>> I have set "org-clock-in-switch-to-state" to "INARBEIT" state in my state 
>> sequence
>>
>> #+SEQ_TODO: TODO INARBEIT WARTEN | MOVED DONE CANCELED DELEGATED
>>
>> As soon as I am in state "INARBEIT" and doing a clockin, the CLOCK: line 
>> appears.
>>>
>>> 3. Are sticky agendas enabled?
>>
>> YES!
>>>
>>> 4. If its from agenda, and its sticky, is it freshly generated, or was
>>>    it refreshed with "g" or "r" key?
>> it is not from agenda
>>>
>>> 5. If its from sticky agenda, can you reproduce it without enabling sticky 
>>> agendas?
>> Let me see: no, problem occurs with or without sticky agendas
>>>
> 
> So far this looks to me as its unrelated to sticky changes, could you
> by any chance try commit 3bd1c2e9bff539c94f92f1ec919f8f0f1640f8c0
> which is 1 before sticky merge , and see if same scenario is broken
> there?
> 
> The git commands to do it (ignore if your git-fu is strong)
> 
> git checkout 3bd1c2e9bff539c94f92f1ec919f8f0f1640f8c0
> ... test ..
> git checkout master
> ... back to normal ..
> 
> Regards,
>  Max
> 
> 
>