From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregor Zattler Subject: [BUG] org-clock-sum cannot handle headings with more than 29 stars (was: Re: How to debug "org-clock-display: Args out of range: [48230 48230) 48230 38618 38618 0 0 0 0 0 ...], 61" Date: Sat, 14 Jan 2012 17:16:31 +0100 Message-ID: <20120114161631.GC7727@shi.workgroup> References: <20120106002125.GA32086@shi.workgroup> <8762gp3aqz.fsf@norang.ca> <20120112214110.GB29496@shi.workgroup> <4047.1326406324@alphaville1> <5046.1326408982@alphaville1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([140.186.70.92]:37769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rm6Hw-0003tQ-G5 for emacs-orgmode@gnu.org; Sat, 14 Jan 2012 11:17:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rm6Hv-0008Co-8u for emacs-orgmode@gnu.org; Sat, 14 Jan 2012 11:17:04 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]:59818) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Rm6Hu-0008Cf-So for emacs-orgmode@gnu.org; Sat, 14 Jan 2012 11:17:03 -0500 Content-Disposition: inline In-Reply-To: <5046.1326408982@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, 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. Ciao; gregor * 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.