From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregor Zattler Subject: [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) Date: Sun, 22 Jan 2012 13:50:19 +0100 Message-ID: <20120122125019.GA21012@shi.workgroup> References: <20120106002125.GA32086@shi.workgroup> <8762gp3aqz.fsf@norang.ca> <20120112214110.GB29496@shi.workgroup> <4047.1326406324@alphaville1> <5046.1326408982@alphaville1> <20120114161631.GC7727@shi.workgroup> <8789.1326566962@alphaville1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([140.186.70.92]:47267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rowsv-00084H-9x for emacs-orgmode@gnu.org; Sun, 22 Jan 2012 07:51:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rowst-00070t-UK for emacs-orgmode@gnu.org; Sun, 22 Jan 2012 07:51:01 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]:50395) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Rowst-00070a-Gf for emacs-orgmode@gnu.org; Sun, 22 Jan 2012 07:50:59 -0500 Content-Disposition: inline In-Reply-To: <8789.1326566962@alphaville1> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode Hi Nick, org developers, * Nick Dokos [14. Jan. 2012]: > Gregor Zattler 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 [12. Jan. 2012]: >>> Nick Dokos wrote: >>>> Gregor Zattler 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