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 > > >
