From: Gregor Zattler <telegraph@gmx.net>
To: emacs-orgmode <emacs-orgmode@gnu.org>
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 [thread overview]
Message-ID: <20120122125019.GA21012@shi.workgroup> (raw)
In-Reply-To: <8789.1326566962@alphaville1>
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
next prev parent reply other threads:[~2012-01-22 12:51 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-10 19:08 Getting rid of split frame with org-capture Thomas Lockney
2011-11-12 15:57 ` Gregor Zattler
[not found] ` <telegraph@gmx.net>
2011-11-13 4:13 ` Nick Dokos
2011-11-13 16:48 ` Tom Prince
2011-11-13 17:57 ` Nick Dokos
2011-11-20 16:16 ` Tom Prince
2011-12-13 23:11 ` Andreas Leha
2011-12-14 16:37 ` Tom Prince
2013-10-04 4:33 ` Alexander Vorobiev
2013-10-04 7:06 ` Alan Schmitt
2011-11-25 16:35 ` Eric S Fraga
2012-01-12 22:12 ` How to debug "org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61" Nick Dokos
2012-01-12 22:56 ` Nick Dokos
2012-01-14 16:16 ` [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) " Gregor Zattler
2012-01-15 15:33 ` How to debug "org-clock-display: Args out of range: [48230 48230 " Stefan Nobis
2012-01-14 18:49 ` [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) " Nick Dokos
2012-01-22 12:50 ` Gregor Zattler [this message]
2012-01-22 13:15 ` [PATCH 2/3] Document max number of stars in headings in manual Gregor Zattler
2012-01-24 16:10 ` [Accepted] [O, " Bastien Guerry
2012-01-22 13:15 ` [PATCH 1/3] Document max number of stars in headings in docstring of org-inlinetask-minlevel Gregor Zattler
2012-01-24 16:10 ` [Accepted] [O, " Bastien Guerry
2012-01-22 13:30 ` [PATCH 3/3] Document max number of stars in clocking section Gregor Zattler
2012-01-24 16:11 ` [Accepted] [O, " Bastien Guerry
2012-01-24 16:16 ` [BUG][PATCH] document number of stars limitation with respect to org-clock-sum Bastien
2012-10-14 5:31 ` Bug: org-read-date: problem with year in dotted european date input [7.9.2 (release_7.9.2-436-g9b11e6 @ /home/grfz/src/org-mode/lisp/)] Nick Dokos
2013-01-24 18:10 ` How to track down "No heading for this item in buffer or region."? Nick Dokos
2013-01-24 18:31 ` Nick Dokos
2011-11-13 20:41 ` Getting rid of split frame with org-capture Nick Dokos
-- strict thread matches above, loose matches on Subject: below --
2012-01-06 0:21 How to debug "org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61" Gregor Zattler
2012-01-06 1:01 ` Bernt Hansen
2012-01-12 21:41 ` Gregor Zattler
2012-01-15 23:07 ` Bernt Hansen
2012-10-11 12:51 how to customise Emacs to recognise 13.10. as 13th of October this year instead of 2010-10-13? Gregor Zattler
2012-10-11 14:13 ` Memnon Anon
2012-10-11 15:20 ` Gregor Zattler
2012-10-12 15:14 ` Bug: org-read-date: problem with year in dotted european date input [7.9.2 (release_7.9.2-436-g9b11e6 @ /home/grfz/src/org-mode/lisp/)] (was: Re: how to customise Emacs to recognise 13.10. as 13th of October this year instead of 2010-10-13?) Gregor Zattler
2012-10-12 16:24 ` Bug: org-read-date: problem with year in dotted european date input [7.9.2 (release_7.9.2-436-g9b11e6 @ /home/grfz/src/org-mode/lisp/)] Nicolas Goaziou
2012-10-13 8:12 ` Gregor Zattler
2012-10-13 10:10 ` Nicolas Goaziou
2012-10-13 18:44 ` Gregor Zattler
2012-10-14 6:01 ` Carsten Dominik
2012-10-14 7:57 ` Nicolas Goaziou
2012-10-15 6:39 ` Carsten Dominik
2012-10-15 11:06 ` Nicolas Goaziou
2013-01-24 12:32 How to track down "No heading for this item in buffer or region."? Gregor Zattler
2013-01-24 12:44 ` Bastien
2013-01-24 16:23 ` Gregor Zattler
2013-01-24 19:07 ` Bastien
2013-01-24 19:24 ` Bastien
2013-01-24 19:35 ` Nick Dokos
2013-01-24 20:29 ` Bastien
2013-01-25 5:20 ` Nick Dokos
2013-01-25 16:11 ` J. David Boyd
2013-01-26 10:51 ` Bastien
2013-01-26 16:45 ` Nick Dokos
2013-01-31 10:43 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120122125019.GA21012@shi.workgroup \
--to=telegraph@gmx.net \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).