[BUG][PATCH] document number of stars limitation with respect to org-clock-sum (was: Re: org-clock-sum cannot handle headings with more than 29 stars)

[Gregor Zattler <telegraph@gmx.net>]

Hi Nick, org developers,
* Nick Dokos <nicholas.dokos@hp.com> [14. Jan. 2012]:
> Gregor Zattler <telegraph@gmx.net> wrote:
>> while preparing a "minimal" example of my problem I finally
>> realised that "61" was the deepest level of indentation of some
>> inline tasks in my org file.  When I wrote them I only remembered
>> inline tasks as with more than x stars and so I provided more
>> than enough :-)
>> 
>> But this also applies to normal headings.  My Minimal org file to
>> demonstrate the bug is now:
>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> * dog
>> ** dog
>> *** dog
>> **** dog
>> ***** dog
>> ****** dog
>> ******* dog
>> ******** dog
>> ********* dog
>> ********** dog
>> *********** dog
>> ************ dog
>> ************* dog
>> ************** dog
>> *************** dog
>> **************** dog
>> ***************** dog
>> ****************** dog
>> ******************* dog
>> ******************** dog
>> ********************* dog
>> ********************** dog
>> *********************** dog
>> ************************ dog
>> ************************* dog
>> ************************** dog
>> *************************** dog
>> **************************** dog
>> ***************************** dog
>> ****************************** ant
>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>> 
>> doing M-x org-clock-display (which in turn execs org-clock-sum)
>> will fail.  It will not fail, with the last line removed.
>> 
>> I searched a bit in the sources (max.*level") but did not find
>> documentation regarding the maximum number of stars in org
>> files.  Perhaps it has to be documented or "lmax" raised in the sources.
>> 
>> Thanks for your help though, I first changed lmax as you proposed
>> and it fixed the problem.

>> * Nick Dokos <nicholas.dokos@hp.com> [12. Jan. 2012]:
>>> Nick Dokos <nicholas.dokos@hp.com> wrote:
>>>> Gregor Zattler <telegraph@gmx.net> wrote:
>>>>> Debugger entered--Lisp error: (args-out-of-range [49569 49569 49569 39957 3=
>>>>> 9957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] 61)
>>>>>   aref([49569 49569 49569 39957 39957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0=
>>>>>  0 0 0 0 0 0] 61)
>>>> 
>>>> This tries to get the 61st element of a vector that has at most 30 or so
>>>> elements, hence the complaint. But of course, that's hardly
>>>> enlightening.  However, the backtrace shows that this code is inside the
>>>> function org-clock-sum (in org-clock.el).  And if you look at that
>>>> function, you see (where I have elided large swathes of code):
>>>> 
>>>>   (let* (...
>>>> 	 (lmax 30)
>>>> 	 (ltimes (make-vector lmax 0))
>>>> 	 ...
>>>> 
>>>> So ltimes is a vector with *exactly* 30 elements. I would change that 30
>>>> to 100 or so (something greater than 61 in any case) and retest. If that
>>>> fixes it, then we know the culprit and then we can dedice which is the
>>>> unreasonable one: the code or your subtree :-)
>>> Or maybe that 61 is way off base. After all, there are only 5 non-trivial
>>> entries in the vector.
>>> 
>>> The code that sets the level seems suspect to me:
>>> 
>>> 	  (let* ((headline-forced
>>> 		  (get-text-property (point)
>>>                                      :org-clock-force-headline-inclusion))
>>>                  (headline-included
>>>                   (or (null headline-filter)
>>>                       (save-excursion
>>>                         (save-match-data (funcall headline-filter))))))
>>> 	    (setq level (- (match-end 1) (match-beginning 1)))
>>> 
>>> What do match-beginning/match-end return if headline-filter is nil?
>>> The save-match-data is not done, so we get the results of whatever
>>> random  search was done last before this code executed.
>> 
>> 
> 
> So I guess that despite my suspicions this code works (although I need
> to understand how).  As for the failure, your example is of course
> highly unlikely in the above form[fn:1], but much more likely in the
> inline task case that bit you originally. But since expanding the vector
> to 100 elements or so fixes the problem and seems to be both cheap and
> expedient, I'd vote for that fix to go in and be done with it (perhaps
> with a footnote in the clock section of the manual to identify the
> limit).

Since I don't know if the hardcoded lmax value `30' serves other
purposes too I don't change it but document the fact in
org-inlinetask.el and the manual.


Ciao, Gregor