how to customise Emacs to recognise 13.10. as 13th of October this year instead of 2010-10-13?

how to customise Emacs to recognise 13.10. as 13th of October this year instead of 2010-10-13?

[Gregor Zattler]

Dear org-moders,

today (2012-10-11) I yanked "Kommt am 13.10. um 14:00 zum" into
the date/time prompt: the date is recognised as "<2010-10-13 Mi
14:00>" instead of <2012-10-13 Sa 14:00> as I would expect since
I have the following customisations (excerpt):

(custom-set-variables
;[...]
 '(calendar-date-style (quote european))
;[...]
 '(diary-date-forms (quote ((day "\\. ?" month "\\. ?[^0-9]") 
                           (day "\\. ?" month "\\. ?" year "[^0-9]") 
                           (day "/" month "[^/0-9]") 
                           (day "/" month "/" year "[^0-9]") 
                           (backup day " *" monthname "\\W+\\<\\([^*0-9]\\|\\([0-9]+[:aApP]\\)\\)") 
                           (day " *" monthname " *" year "[^0-9]") 
                           (dayname "\\W"))))
;[...]
)

as part of my .init.el.


I thought the first diary date form would match this text but it
doesn't.  Even "Kommt am 13.10.2012 um 14:00 zum" is parsed as 
"<2010-10-13 Mi 14:00>".  I thought the second diary date form
would match this.

Before I realised this I captured several events with wrong dates.

Any Ideas?

Ciao, Gregor

Re: how to customise Emacs to recognise 13.10. as 13th of October this year instead of 2010-10-13?

[Memnon Anon]

Hi Gregor,

> today (2012-10-11) I yanked "Kommt am 13.10. um 14:00 zum" into
> the date/time prompt: the date is recognised as "<2010-10-13 Mi
> 14:00>" instead of <2012-10-13 Sa 14:00> as I would expect since
> I have the following customisations (excerpt):

I just tried, it seems to work just fine here.

Not sure which customization is different. You may want to have a look
at http://memnon.sdf-eu.org/emacs.org and compare.

ELISP> (emacs-version)
"GNU Emacs 24.2.50.1 (i486-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2012-10-09 on dex, modified by Debian"
ELISP> (org-version)
"7.9.2"

Memnon

Re: how to customise Emacs to recognise 13.10. as 13th of October this year instead of 2010-10-13?

[Gregor Zattler]

Hi Memnon,
* Memnon Anon <gegendosenfleisch@googlemail.com> [11. Oct. 2012]:
>> today (2012-10-11) I yanked "Kommt am 13.10. um 14:00 zum" into
>> the date/time prompt: the date is recognised as "<2010-10-13 Mi
>> 14:00>" instead of <2012-10-13 Sa 14:00> as I would expect since
>> I have the following customisations (excerpt):
> 
> I just tried, it seems to work just fine here.
> 
> Not sure which customization is different. You may want to have a look
> at http://memnon.sdf-eu.org/emacs.org and compare.

This is strange: I searched your Emacs.org dor `date' and the
only relevant customisations are IMHO 

(setq european-calendar-style t             ; obsolete!
        calendar-date-style 'european
...

I tried with emacs-snapshot -Q and this single customisation: No
luck. 


> ELISP> (emacs-version)
> "GNU Emacs 24.2.50.1 (i486-pc-linux-gnu, GTK+ Version 3.4.2)
>  of 2012-10-09 on dex, modified by Debian"
> ELISP> (org-version)
> "7.9.2"

Ah, sorry: 

GNU Emacs 24.2.50.1 (i486-pc-linux-gnu, X toolkit, Xaw scroll
bars) of 2012-10-09 on dex, modified by Debian

Org-mode version 7.9.2 (release_7.9.2-434-gc23dea @


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

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]

Dear org-moders,

I now believe I found a bug in org-read-date.  There is a problem
parsing European dotted dates.  In Dates the like DD.MM.YYYY or
DD.MM.YY or DD.MM. `MM' is recognised as year instead of month:

Today is 2012-10-11:

(org-read-date t nil "Kommt am 27.10.2012 um 14:00 Uhr")
gives
"2010-10-27"
expectet outcome is
"2012-10-27"

Same with abbreviated years:
(org-read-date t nil "Kommt am 27.10.12 um 14:00 Uhr")
"2010-10-27"
expectet outcome is
"2012-10-27"

Days are interpreted correctly:
(org-read-date t nil "Kommt am 27. um 14:00 Uhr")
"2012-10-27"

Since I customised german day names this also is correct:
(org-read-date t nil "Kommt am Sonntag um 14:00 Uhr")
"2012-10-14"

The most common way of expressing dates this year is interpreted
wrongly: 
(org-read-date t nil "Kommt am 27.10. um 14:00 Uhr")
"2010-10-27"
expectet outcome is
"2012-10-27"

I read the source of org-read-date but didn't grok it.  The regex
in the section labeled ";; Help matching dotted european dates"
looks good to me, but...

Emacs  : GNU Emacs 24.2.50.1 (i486-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2012-10-09 on dex, modified by Debian
Package: Org-mode version 7.9.2 (release_7.9.2-436-g9b11e6 @ /home/grfz/src/org-mode/lisp/)


I also did these tests with `env -i emacs -d :0.0 -Q':
- GNU Emacs 24.2.50.1 / Org-mode 7.9.2
- GNU Emacs 23.4.1    / Org-mode: 6.33x
--> same results (with the exception of german day names).



Thanks for your attention, Gregor



* Gregor Zattler <telegraph@gmx.net> [11. Oct. 2012]:
> 
> 
> today (2012-10-11) I yanked "Kommt am 13.10. um 14:00 zum" into
> the date/time prompt: the date is recognised as "<2010-10-13 Mi
> 14:00>" instead of <2012-10-13 Sa 14:00> as I would expect since
> I have the following customisations (excerpt):
> 
> (custom-set-variables
> ;[...]
>  '(calendar-date-style (quote european))
> ;[...]
>  '(diary-date-forms (quote ((day "\\. ?" month "\\. ?[^0-9]") 
>                            (day "\\. ?" month "\\. ?" year "[^0-9]") 
>                            (day "/" month "[^/0-9]") 
>                            (day "/" month "/" year "[^0-9]") 
>                            (backup day " *" monthname "\\W+\\<\\([^*0-9]\\|\\([0-9]+[:aApP]\\)\\)") 
>                            (day " *" monthname " *" year "[^0-9]") 
>                            (dayname "\\W"))))
> ;[...]
> )
> 
> as part of my .init.el.
> 
> 
> I thought the first diary date form would match this text but it
> doesn't.  Even "Kommt am 13.10.2012 um 14:00 zum" is parsed as 
> "<2010-10-13 Mi 14:00>".  I thought the second diary date form
> would match this.
> 
> Before I realised this I captured several events with wrong dates.
> 
> Any Ideas?
> 
> Ciao, Gregor
> 

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: 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]

Hello,

Gregor Zattler <telegraph@gmx.net> writes:

> I now believe I found a bug in org-read-date.  There is a problem
> parsing European dotted dates.  In Dates the like DD.MM.YYYY or
> DD.MM.YY or DD.MM. `MM' is recognised as year instead of month:
>
> Today is 2012-10-11:
>
> (org-read-date t nil "Kommt am 27.10.2012 um 14:00 Uhr")
> gives
> "2010-10-27"
> expectet outcome is
> "2012-10-27"

AFAICT `org-read-date' expects a date string alone, not a date string in
the middle of some text.

  (org-read-date t nil "12.10.") => "2012-10-12"


Regards,

-- 
Nicolas Goaziou

Re: 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/)]

[Gregor Zattler]

Hi Nicolas,
* Nicolas Goaziou <n.goaziou@gmail.com> [12. Oct. 2012]:
> Gregor Zattler <telegraph@gmx.net> writes:
> 
>> I now believe I found a bug in org-read-date.  There is a problem
>> parsing European dotted dates.  In Dates the like DD.MM.YYYY or
>> DD.MM.YY or DD.MM. `MM' is recognised as year instead of month:
>>
>> Today is 2012-10-11:
>>
>> (org-read-date t nil "Kommt am 27.10.2012 um 14:00 Uhr")
>> gives
>> "2010-10-27"
>> expectet outcome is
>> "2012-10-27"
> 
> AFAICT `org-read-date' expects a date string alone, not a date string in
> the middle of some text.
> 
>   (org-read-date t nil "12.10.") => "2012-10-12"

For me this is about the date/time prompt when capturing.  I had
a look at org-time-stamp and had the impression that the actual
parsing of the users input is done in org-read-date.  But
obviously my basic elisp knowledge isn't up to such complex
functions.  

Back to square one: Does anybody know How to customise
Emacs/org-mode so that dotted European dates are parsed correctly
at the date/time prompt?

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: 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]

Hello,

Gregor Zattler <telegraph@gmx.net> writes:

> Back to square one: Does anybody know How to customise
> Emacs/org-mode so that dotted European dates are parsed correctly
> at the date/time prompt?

Again, dotted European dates are parsed correctly without customization.
Would you provide a time string that isn't?


Regards,

-- 
Nicolas Goaziou

Re: 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/)]

[Gregor Zattler]

Hi Nicolas, org-mode users and developers,
* Nicolas Goaziou <n.goaziou@gmail.com> [13. Oct. 2012]:
> Gregor Zattler <telegraph@gmx.net> writes:
> 
>> Back to square one: Does anybody know How to customise
>> Emacs/org-mode so that dotted European dates are parsed correctly
>> at the date/time prompt?
> 
> Again, dotted European dates are parsed correctly without customization.
> Would you provide a time string that isn't?

"Naked" dotted european dates without surrounding text are
parsed correctly by org-read-date.

But with date/time prompt I mean the prompt which asks me for a
date/time when invoking org-time-stamp.  Here I'm allowed to
insert Dates like "the event takes place at 27.10. at 14:00 in
the pub".  Org-mode is supposed to parse these, see
[[info:org#The%20date/time%20prompt][info:org#The date/time prompt]].

If I now yank "Kommt am 27.10.2012 um 14:00 zum" in this
date/time prompt, the result is "<2010-10-27 Mi 14:00>" instead
of "<2012-10-27 Sa 14:00>".          ^       ^^
        ^       ^^


I had a look at org-time-stamp which is invoked by "C-c ."  I do
not understand how this function parses dates/times from text.
Therefore I looked for functions with appropriate names which are
called by org-time-stamp.  The only one I could find is
org-read-date.  It obviously parses dates from a string and
identifies parts (day, month, year).  I thought org-read-date
does the heavy lifting with respect to date parsing.  But now I
think you are right and org-read-dates parses "naked dates".  But
where does the parsing of texts which contain dates take place?



Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: 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/)]

[Carsten Dominik]

On 13 okt. 2012, at 20:45, Gregor Zattler <telegraph@gmx.net> wrote:

> Hi Nicolas, org-mode users and developers,
> * Nicolas Goaziou <n.goaziou@gmail.com> [13. Oct. 2012]:
>> Gregor Zattler <telegraph@gmx.net> writes:
>>
>>> Back to square one: Does anybody know How to customise
>>> Emacs/org-mode so that dotted European dates are parsed correctly
>>> at the date/time prompt?
>>
>> Again, dotted European dates are parsed correctly without customization.
>> Would you provide a time string that isn't?
>
> "Naked" dotted european dates without surrounding text are
> parsed correctly by org-read-date.
>
> But with date/time prompt I mean the prompt which asks me for a
> date/time when invoking org-time-stamp.  Here I'm allowed to
> insert Dates like "the event takes place at 27.10. at 14:00 in
> the pub".  Org-mode is supposed to parse these, see
> [[info:org#The%20date/time%20prompt][info:org#The date/time prompt]].

Org used to have the ambition to parse a date in the middle of a text,
and this six what you are seeing in the documentation. However, over
time more and more different requests came in, to parse ISO weeks,
European dates and more.  Also we want to allow incomplete dates like
leaving out a year etc.  I still think Org does a pretty god job
there.  However, to be reasonably predictable we did have o restrict
matching of special dates to the beginning of the string, and this is
what you and Nicolas are now seeing.  If you want this to work
differently, you need to hack your own version of the analyze
function.  For example, you can remove the ^ anchor from the regexp
matching dotted dates. And you can change the regexp to match two
digit years and not only four digit years. But you will then see that
it also parses numbers with decimals which happen to be in the chunk
of text.

Carsten


>
> If I now yank "Kommt am 27.10.2012 um 14:00 zum" in this
> date/time prompt, the result is "<2010-10-27 Mi 14:00>" instead
> of "<2012-10-27 Sa 14:00>".          ^       ^^
>        ^       ^^
>
>
> I had a look at org-time-stamp which is invoked by "C-c ."  I do
> not understand how this function parses dates/times from text.
> Therefore I looked for functions with appropriate names which are
> called by org-time-stamp.  The only one I could find is
> org-read-date.  It obviously parses dates from a string and
> identifies parts (day, month, year).  I thought org-read-date
> does the heavy lifting with respect to date parsing.  But now I
> think you are right and org-read-dates parses "naked dates".  But
> where does the parsing of texts which contain dates take place?
>
>
>
> Ciao, Gregor
> --
> -... --- .-. . -.. ..--.. ...-.-
>

Re: 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]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Org used to have the ambition to parse a date in the middle of a text,
> and this six what you are seeing in the documentation. However, over
> time more and more different requests came in, to parse ISO weeks,
> European dates and more.  Also we want to allow incomplete dates like
> leaving out a year etc.  I still think Org does a pretty god job
> there.  However, to be reasonably predictable we did have o restrict
> matching of special dates to the beginning of the string, and this is
> what you and Nicolas are now seeing.

It may be worth specifying that restriction in the documentation. As
Gregor pointed out

    But it will in fact accept any string containing some date
  and/or time information, and it is really smart about interpreting your
  input.

is misleading.


Regards,

-- 
Nicolas Goaziou

Re: 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/)]

[Carsten Dominik]

I fixed the documentation.

- Carsten

On 14.10.2012, at 09:57, Nicolas Goaziou wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> Org used to have the ambition to parse a date in the middle of a text,
>> and this six what you are seeing in the documentation. However, over
>> time more and more different requests came in, to parse ISO weeks,
>> European dates and more.  Also we want to allow incomplete dates like
>> leaving out a year etc.  I still think Org does a pretty god job
>> there.  However, to be reasonably predictable we did have o restrict
>> matching of special dates to the beginning of the string, and this is
>> what you and Nicolas are now seeing.
> 
> It may be worth specifying that restriction in the documentation. As
> Gregor pointed out
> 
>    But it will in fact accept any string containing some date
>  and/or time information, and it is really smart about interpreting your
>  input.
> 
> is misleading.
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

Re: 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]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> I fixed the documentation.

Thank you.


Regards,

-- 
Nicolas Goaziou

How to track down "No heading for this item in buffer or region."?

[Gregor Zattler]

Hi, 

my agenda shows a line:

"No heading for this item in buffer or region."

how should I track down the problematic part of my org files? 


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: How to track down "No heading for this item in buffer or region."?

[Bastien]

Hi Gregor,

Gregor Zattler <telegraph@gmx.net> writes:

> my agenda shows a line:
>
> "No heading for this item in buffer or region."

It means the agenda contains tasks like

* TODO

with no heading.

> how should I track down the problematic part of my org files? 

You can run this in your Org buffer:

M-: (while (and (re-search-forward org-complex-heading-regexp nil t) (match-string 4))) RET

It will stop at the problematic headlines.

HTH,

-- 
 Bastien

Re: How to track down "No heading for this item in buffer or region."?

[Gregor Zattler]

Hi Bastien,
* Bastien <bzg@altern.org> [24. Jan. 2013]:
> Gregor Zattler <telegraph@gmx.net> writes:
>> my agenda shows a line:
>>
>> "No heading for this item in buffer or region."
> 
> It means the agenda contains tasks like
> 
> * TODO
> 
> with no heading.
> 
>> how should I track down the problematic part of my org files? 
> 
> You can run this in your Org buffer:
> 
> M-: (while (and (re-search-forward org-complex-heading-regexp nil t) (match-string 4))) RET
> 
> It will stop at the problematic headlines.

That really helped to eliminate all empty headlines.  I later
checked via 

egrep -- "^[*]+[[:space:]]*$" 

on my agenda files that there are no further empty headlines.


But alas, the message "No heading for this item in buffer or
region." still appears two times in my agenda -- for today.

When I move the cursor over this lines a message appears in the
echo area:

byte-code: Before first headline at position 64 in buffer org.org [14 times]

The second line of org.org begins at character 64 in the buffer.
It's a timestamp:

#Time-stamp: <2013-01-24 16:30:39 grfz>

Till recently this was no problem since it is a comment line.
Obviously org-mode somehow interprets this timestamp, since the
messages disappeared after I changed the time stamp delimiter from
`<' and `>' respectively to `"'.  I consider this to be a bug
since these time stamps are a standard Emacs feature and this
line is a comment org-mode-wise.


Thanks for your help to clean up my org files and tracking down
the offending lines in my org agenda files. 

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: How to track down "No heading for this item in buffer or region."?

[Bastien]

Gregor Zattler <telegraph@gmx.net> writes:

> #Time-stamp: <2013-01-24 16:30:39 grfz>
>
> Till recently this was no problem since it is a comment line.

This is not a comment line, comment lines start with "[\t ]*# "
(note the space after the #).

-- 
 Bastien

Re: How to track down "No heading for this item in buffer or region."?

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

Hi Gregor,

Gregor Zattler <telegraph@gmx.net> writes:

> But alas, the message "No heading for this item in buffer or
> region." still appears two times in my agenda -- for today.

The attached patch fixes it.

Carsten, was there any special reason for allowing to add
an agenda entry before the first headline?  The following 
patch prevent this.

Thanks,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-agenda-no-heading_maint.patch --]
[-- Type: text/x-patch, Size: 2706 bytes --]

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index f088e59..4236b0a 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -5406,9 +5406,6 @@ Do we have a reason to ignore this TODO entry because it has a time stamp?
 
 \(fn &optional END)" nil nil)
 
-(defconst org-agenda-no-heading-message
-  "No heading for this item in buffer or region.")
-
 (defun org-agenda-get-timestamps (&optional deadline-results)
   "Return the date stamp information for agenda display."
   (let* ((props (list 'face 'org-agenda-calendar-event
@@ -5488,7 +5485,7 @@ Do we have a reason to ignore this TODO entry because it has a time stamp?
 	      category-pos (get-text-property b0 'org-category-position))
 	(save-excursion
 	  (if (not (re-search-backward org-outline-regexp-bol nil t))
-	      (setq txt org-agenda-no-heading-message)
+	      (throw :skip nil)
 	    (goto-char (match-beginning 0))
 	    (if (and (eq t org-agenda-skip-timestamp-if-deadline-is-shown)
 		     (assoc (point) deadline-position-alist))
@@ -5724,7 +5721,7 @@ please use `org-class' instead."
 		  (and (looking-at ".*\n[ \t]*-[ \t]+\\([^-\n \t].*?\\)[ \t]*$")
 		       (match-string 1)))))
 	  (if (not (re-search-backward org-outline-regexp-bol nil t))
-	      (setq txt org-agenda-no-heading-message)
+	      (throw :skip nil)
 	    (goto-char (match-beginning 0))
 	    (setq hdmarker (org-agenda-new-marker)
 		  inherited-tags
@@ -5941,7 +5938,7 @@ See also the user option `org-agenda-clock-consistency-checks'."
 		      warntime (get-text-property (point) 'org-appt-warntime)
 		      category-pos (get-text-property (point) 'org-category-position))
 		(if (not (re-search-backward "^\\*+[ \t]+" nil t))
-		    (setq txt org-agenda-no-heading-message)
+		    (throw :skip nil)
 		  (goto-char (match-end 0))
 		  (setq pos1 (match-beginning 0))
 		  (setq inherited-tags
@@ -6066,7 +6063,7 @@ FRACTION is what fraction of the head-warning time has passed."
 	      (setq category (org-get-category)
 		    category-pos (get-text-property (point) 'org-category-position))
 	      (if (not (re-search-backward "^\\*+[ \t]+" nil t))
-		  (setq txt org-agenda-no-heading-message)
+		  (throw :skip nil)
 		(goto-char (match-end 0))
 		(setq pos1 (match-beginning 0))
 		(if habitp
@@ -6167,7 +6164,7 @@ FRACTION is what fraction of the head-warning time has passed."
 		(setq category (org-get-category)
 		      category-pos (get-text-property (point) 'org-category-position))
 		(if (not (re-search-backward org-outline-regexp-bol nil t))
-		    (setq txt org-agenda-no-heading-message)
+		    (throw :skip nil)
 		  (goto-char (match-beginning 0))
 		  (setq hdmarker (org-agenda-new-marker (point))
 			inherited-tags

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
 Bastien

Re: How to track down "No heading for this item in buffer or region."?

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Hi Gregor,
> 
> Gregor Zattler <telegraph@gmx.net> writes:
> 
> > But alas, the message "No heading for this item in buffer or
> > region." still appears two times in my agenda -- for today.
> 
> The attached patch fixes it.
> 
> Carsten, was there any special reason for allowing to add
> an agenda entry before the first headline?  The following 
> patch prevent this.
> 

I think you'd be better off fixing the lazily assigned text properties
and then you don't need to worry about adding restrictions. In addition,
this fix does not do anything for the following case:

If I slightly modify the previous example 

,----
| # timestamp: <2013-01-24 Thu>
| 
| * TODO foo
| #  SCHEDULED: <2013-01-24 Thu>
`----
  

to try to reproduce Rainer's problem, when I first construct the agenda,
I get *both* the TODO and the no-heading message: text properties are not
active. If I then visit the file (e.g. RET on the TODO item) and construct
the agenda again, neither the TODO nor the no-heading message appears.

Nick

Re: How to track down "No heading for this item in buffer or region."?

[Bastien]

Nick Dokos <nicholas.dokos@hp.com> writes:

> to try to reproduce Rainer's problem, when I first construct the agenda,
> I get *both* the TODO and the no-heading message: text properties are not
> active. If I then visit the file (e.g. RET on the TODO item) and construct
> the agenda again, neither the TODO nor the no-heading message
> appears.

I see -- it was not obvious to me you were trying without opening the
file in a buffer.  With my patch, I can reproduce the error, but only
the TODO (which appears instead of being skipped, not with the
timestamp line.  Yes, seems related to properties.  I'll digg further.

Thanks!

-- 
 Bastien

Re: How to track down "No heading for this item in buffer or region."?

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > to try to reproduce Rainer's problem, when I first construct the agenda,
> > I get *both* the TODO and the no-heading message: text properties are not
> > active. If I then visit the file (e.g. RET on the TODO item) and construct
> > the agenda again, neither the TODO nor the no-heading message
> > appears.
> 
> I see -- it was not obvious to me you were trying without opening the
> file in a buffer.  With my patch, I can reproduce the error, but only
> the TODO (which appears instead of being skipped, not with the
> timestamp line.  Yes, seems related to properties.  I'll digg further.
> 

Not quite: the file *is* opened in a buffer (the agenda code opens all the
files, I presume with find-file-noselect), but the text properties are
not up to date. It's only when I explicitly visit the buffer
that they get updated.

E.g. if you evaluate

--8<---------------cut here---------------start------------->8---
(setq buf (find-file-noselect "/path/to/test.org"))
(with-current-buffer buf
  (setq s (buffer-substring 1 2)))
--8<---------------cut here---------------end--------------->8---

the echo area shows

,----
| #("#" 0 1 (fontified nil))
`----

But if you visit the buffer with C-x b test.org RET and then
evaluate the second form again, you get 

,----
| #("#" 0 1 (fontified t font-lock-fontified t face font-lock-comment-face))
`----

There is a section on lazy properties in the elisp manual but I don't
know how to use the mechanism described there: there are no examples in
current emacs code, some half-hearted experiments failed for unknown
reasons, and googling a bit found only one relevant thread in the emacs
group from 2004 - quoting Stefan Monnier from that thread:

#+BEGIN_QUOTE
  I think the lazy text properties that you refer to (i.e. variable
  buffer-access-fontify-functions) are a sadly perfect example of C code
  implemented before we knew what we needed.  It's implemented,
  documented, and 100% unused.
#+END_QUOTE

AFAICT, nothing has been done in this area since then.

Nick

PS. Here's the trivial test.org again for completeness:

--8<---------------cut here---------------start------------->8---
# timestamp: <2013-01-24 Thu>

* TODO foo
#  SCHEDULED: <2013-01-24 Thu>
--8<---------------cut here---------------end--------------->8---

Re: How to track down "No heading for this item in buffer or region."?

[J. David Boyd]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Bastien <bzg@altern.org> wrote:
>
>> Nick Dokos <nicholas.dokos@hp.com> writes:
>> 
>> > to try to reproduce Rainer's problem, when I first construct the agenda,
>> > I get *both* the TODO and the no-heading message: text properties are not
>> > active. If I then visit the file (e.g. RET on the TODO item) and construct
>> > the agenda again, neither the TODO nor the no-heading message
>> > appears.
>> 
>> I see -- it was not obvious to me you were trying without opening the
>> file in a buffer.  With my patch, I can reproduce the error, but only
>> the TODO (which appears instead of being skipped, not with the
>> timestamp line.  Yes, seems related to properties.  I'll digg further.
>> 
>
> Not quite: the file *is* opened in a buffer (the agenda code opens all the
> files, I presume with find-file-noselect), but the text properties are
> not up to date. It's only when I explicitly visit the buffer
> that they get updated.
>
> E.g. if you evaluate
>
> (setq buf (find-file-noselect "/path/to/test.org"))
> (with-current-buffer buf
>   (setq s (buffer-substring 1 2)))
>
> the echo area shows
>
> ,----
> | #("#" 0 1 (fontified nil))
> `----
>
> But if you visit the buffer with C-x b test.org RET and then
> evaluate the second form again, you get 
>
> ,----
> | #("#" 0 1 (fontified t font-lock-fontified t face font-lock-comment-face))
> `----
>
> There is a section on lazy properties in the elisp manual but I don't
> know how to use the mechanism described there: there are no examples in
> current emacs code, some half-hearted experiments failed for unknown
> reasons, and googling a bit found only one relevant thread in the emacs
> group from 2004 - quoting Stefan Monnier from that thread:
>
> #+BEGIN_QUOTE
>   I think the lazy text properties that you refer to (i.e. variable
>   buffer-access-fontify-functions) are a sadly perfect example of C code
>   implemented before we knew what we needed.  It's implemented,
>   documented, and 100% unused.
> #+END_QUOTE
>
> AFAICT, nothing has been done in this area since then.
>
> Nick
>
> PS. Here's the trivial test.org again for completeness:
>
> # timestamp: <2013-01-24 Thu>
>
> * TODO foo
> #  SCHEDULED: <2013-01-24 Thu>



There was a message in here a while back about something like this.   I
can't find it at the moment, but the author talked about org mode hooks
that aren't being run when a file is loaded or moved to from the agenda,
only when explicitly loaded.   He had a work around for that, but I
don't recall that either....   Sorry for no more help than this

Re: How to track down "No heading for this item in buffer or region."?

[Bastien]

Hi Nick,

Nick Dokos <nicholas.dokos@hp.com> writes:

> Not quite: the file *is* opened in a buffer (the agenda code opens all the
> files, I presume with find-file-noselect), but the text properties are
> not up to date. It's only when I explicitly visit the buffer
> that they get updated.

I updated the commit using the `font-lock-comment-face' for skipping
commented scheduled/deadline lines -- it now uses comment-start-skip
to skip those lines.  No need to put the # at the beginning of the
line, the optimization here is not significant enough IMHO.

Org now relies on the general font-lock mechanism for comments, and
defines comment-start etc.  See `org-setup-comments-handling'. Yes,
the text properties from font-lock are not always present when the
buffer is not visited, you're right... things seem a bit unpredictable
in this area.

Thanks,

-- 
 Bastien

Re: How to track down "No heading for this item in buffer or region."?

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> > Not quite: the file *is* opened in a buffer (the agenda code opens all the
> > files, I presume with find-file-noselect), but the text properties are
> > not up to date. It's only when I explicitly visit the buffer
> > that they get updated.
> 
> I updated the commit using the `font-lock-comment-face' for skipping
> commented scheduled/deadline lines -- it now uses comment-start-skip
> to skip those lines.  No need to put the # at the beginning of the
> line, the optimization here is not significant enough IMHO.
> 
> Org now relies on the general font-lock mechanism for comments, and
> defines comment-start etc.  See `org-setup-comments-handling'. Yes,
> the text properties from font-lock are not always present when the
> buffer is not visited, you're right... things seem a bit unpredictable
> in this area.
> 

I experimented a bit and came up with the following hack (which is
probably too heavy-handed to be acceptable as a genuine fix).

Let's assume that there is a way to force lazy properties (there must be
one since visiting the buffer does force them). Then anywhere where
org-agenda-skip is called, we make sure that the force function is
called beforehand. There's a few code paths that enter here but they are
all (?)  of the form:

   loop over files
      (setq buf  (find-file-noselect file))
      (with-current-buffer buf
           ;;;     
           do things that eventually call org-agenda-skip)

Replacing the ;;; with a call to the forcing function should do
the trick.

So here's my elephant-gun-to-kill-a-mosquito forcing function:

--8<---------------cut here---------------start------------->8---
(defun org-force-lazy-text-properties ()
    (jit-lock-function 1))
--8<---------------cut here---------------end--------------->8---

It seems to work at least for small files. There seem to be limits
to how much fontification it does, so if the file is bigger, it might
miss things. The more likely misfeature however is that it will slow
down the agenda to a crawl. It's an existence proof, not a solution.

Nick

Re: How to track down "No heading for this item in buffer or region."?

[Bastien]

Hi Nick,

Nick Dokos <nicholas.dokos@hp.com> writes:

> (defun org-force-lazy-text-properties ()
>     (jit-lock-function 1))
>
> It seems to work at least for small files. There seem to be limits
> to how much fontification it does, so if the file is bigger, it might
> miss things. The more likely misfeature however is that it will slow
> down the agenda to a crawl. It's an existence proof, not a solution.

Still interesting to know... it leaves other experiments to do in hope
we can still optimize the agenda!  Thanks for sharing this,

-- 
 Bastien

How to debug "org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61"

[Gregor Zattler]

Hi org-mode developers and -users,

I use org-mode to record my working time.  If I wnt to know the
total time worked on a project I do a M-X org-clock-display.

But this suddenly gives me this error message:

org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61

I checked the org file but do not find any irregularities in the
clock tables.  I even deleted all individual `=> HH:MM' time
ranges but this did not help.

This happens with emacs23.3, org-mode 6.33 as with Emacs-snapshot
and newest org-mode so I assume it is something like a syntax
error in my org file.

Any idea where to look for the cause of the error?




Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: How to debug "org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61"

[Bernt Hansen]

Gregor Zattler <telegraph@gmx.net> writes:

> Hi org-mode developers and -users,
>
> I use org-mode to record my working time.  If I wnt to know the
> total time worked on a project I do a M-X org-clock-display.
>
> But this suddenly gives me this error message:
>
> org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61
>
> I checked the org file but do not find any irregularities in the
> clock tables.  I even deleted all individual `=> HH:MM' time
> ranges but this did not help.
>
> This happens with emacs23.3, org-mode 6.33 as with Emacs-snapshot
> and newest org-mode so I assume it is something like a syntax
> error in my org file.
>
> Any idea where to look for the cause of the error?

If you generate a backtrace with uncompiled org source files you should
get an indication of where the problem is.

Regards,
Bernt

Re: How to debug "org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61"

[Gregor Zattler]

Hi Bernt, org-mode developers,
* Bernt Hansen <bernt@norang.ca> [05. Jan. 2012]:
> Gregor Zattler <telegraph@gmx.net> writes:
>> I use org-mode to record my working time.  If I want to know the
>> total time worked on a project I do a M-X org-clock-display.
>>
>> But this suddenly gives me this error message:
>>
>> org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61
>>
>> I checked the org file but do not find any irregularities in the
>> clock tables.  I even deleted all individual `=> HH:MM' time
>> ranges but this did not help.

With something like bisecting I narrowed the problem down to a
few headlines consisting of subheadings, bullet lists, checkboxed
lists a few inline tasks etc.  All in all 253 lines of text.  It
looks totally harmless to me.

>> This happens with emacs23.3, org-mode 6.33 as with Emacs-snapshot
>> and newest org-mode so I assume it is something like a syntax
>> error in my org file.

In both cases I startet Emacs with -Q so this is not a
configuration issue -- besides a few #+STARTUP lines at the
beginning orf the org file.

>> Any idea where to look for the cause of the error?
> 
> If you generate a backtrace with uncompiled org source files you should
> get an indication of where the problem is.

I did as you said but the backtrace is totally opaque to me:

Debugger entered--Lisp error: (args-out-of-range [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)
  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)
  (> (aref ltimes level) 0)
  (or (> t1 0) (> (aref ltimes level) 0))
  (if (or (> t1 0) (> (aref ltimes level) 0)) (progn (when (or headline-included headline-forced) (if headline-included (loop for l from 0 to level do (aset ltimes l (+ (aref ltimes l) t1)))) (setq time (aref ltimes level)) (goto-char (match-beginning 0)) (put-text-property (point) (point-at-eol) :org-clock-minutes time) (if headline-filter (save-excursion (save-match-data (while (> ... 1) (outline-up-heading 1 t) (put-text-property ... ... :org-clock-force-headline-inclusion t)))))) (setq t1 0) (loop for l from level to (1- lmax) do (aset ltimes l 0))))
  (when (or (> t1 0) (> (aref ltimes level) 0)) (when (or headline-included headline-forced) (if headline-included (loop for l from 0 to level do (aset ltimes l (+ (aref ltimes l) t1)))) (setq time (aref ltimes level)) (goto-char (match-beginning 0)) (put-text-property (point) (point-at-eol) :org-clock-minutes time) (if headline-filter (save-excursion (save-match-data (while (> (funcall outline-level) 1) (outline-up-heading 1 t) (put-text-property (point) (point-at-eol) :org-clock-force-headline-inclusion t)))))) (setq t1 0) (loop for l from level to (1- lmax) do (aset ltimes l 0)))
  (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))) (when (or (> t1 0) (> (aref ltimes level) 0)) (when (or headline-included headline-forced) (if headline-included (loop for l from 0 to level do (aset ltimes l (+ (aref ltimes l) t1)))) (setq time (aref ltimes level)) (goto-char (match-beginning 0)) (put-text-property (point) (point-at-eol) :org-clock-minutes time) (if headline-filter (save-excursion (save-match-data (while (> ... 1) (outline-up-heading 1 t) (put-text-property ... ... :org-clock-force-headline-inclusion t)))))) (setq t1 0) (loop for l from level to (1- lmax) do (aset ltimes l 0))))
  (cond ((match-end 2) (setq ts (match-string 2) te (match-string 3) ts (org-float-time (apply (quote encode-time) (org-parse-time-string ts))) te (org-float-time (apply (quote encode-time) (org-parse-time-string te))) ts (if tstart (max ts tstart) ts) te (if tend (min te tend) te) dt (- te ts) t1 (if (> dt 0) (+ t1 (floor (/ dt 60))) t1))) ((match-end 4) (setq t1 (+ t1 (string-to-number (match-string 5)) (* 60 (string-to-number (match-string 4)))))) (t (when (and org-clock-report-include-clocking-task (equal (org-clocking-buffer) (current-buffer)) (equal (marker-position org-clock-hd-marker) (point)) tstart tend (>= (org-float-time org-clock-start-time) tstart) (<= (org-float-time org-clock-start-time) tend)) (let ((time (floor (- ... ...) 60))) (setq t1 (+ t1 time)))) (let* ((headline-forced (get-text-property (point) :org-clock-force-headline-inclusion)) (headline-included (or (null headline-filter) (save-excursion (save-match-data ...))))) (setq level (- (match-end 1) (match-beginning 1))) (when (or (> t1 0) (> (aref ltimes level) 0)) (when (or headline-included headline-forced) (if headline-included (loop for l from 0 to level do (aset ltimes l ...))) (setq time (aref ltimes level)) (goto-char (match-beginning 0)) (put-text-property (point) (point-at-eol) :org-clock-minutes time) (if headline-filter (save-excursion (save-match-data ...)))) (setq t1 0) (loop for l from level to (1- lmax) do (aset ltimes l 0))))))
  (while (re-search-backward re nil t) (cond ((match-end 2) (setq ts (match-string 2) te (match-string 3) ts (org-float-time (apply (quote encode-time) (org-parse-time-string ts))) te (org-float-time (apply (quote encode-time) (org-parse-time-string te))) ts (if tstart (max ts tstart) ts) te (if tend (min te tend) te) dt (- te ts) t1 (if (> dt 0) (+ t1 (floor (/ dt 60))) t1))) ((match-end 4) (setq t1 (+ t1 (string-to-number (match-string 5)) (* 60 (string-to-number (match-string 4)))))) (t (when (and org-clock-report-include-clocking-task (equal (org-clocking-buffer) (current-buffer)) (equal (marker-position org-clock-hd-marker) (point)) tstart tend (>= (org-float-time org-clock-start-time) tstart) (<= (org-float-time org-clock-start-time) tend)) (let ((time (floor ... 60))) (setq t1 (+ t1 time)))) (let* ((headline-forced (get-text-property (point) :org-clock-force-headline-inclusion)) (headline-included (or (null headline-filter) (save-excursion ...)))) (setq level (- (match-end 1) (match-beginning 1))) (when (or (> t1 0) (> (aref ltimes level) 0)) (when (or headline-included headline-forced) (if headline-included (loop for l from 0 to level do ...)) (setq time (aref ltimes level)) (goto-char (match-beginning 0)) (put-text-property (point) (point-at-eol) :org-clock-minutes time) (if headline-filter (save-excursion ...))) (setq t1 0) (loop for l from level to (1- lmax) do (aset ltimes l 0)))))))
  (save-excursion (goto-char (point-max)) (while (re-search-backward re nil t) (cond ((match-end 2) (setq ts (match-string 2) te (match-string 3) ts (org-float-time (apply (quote encode-time) (org-parse-time-string ts))) te (org-float-time (apply (quote encode-time) (org-parse-time-string te))) ts (if tstart (max ts tstart) ts) te (if tend (min te tend) te) dt (- te ts) t1 (if (> dt 0) (+ t1 (floor ...)) t1))) ((match-end 4) (setq t1 (+ t1 (string-to-number (match-string 5)) (* 60 (string-to-number ...))))) (t (when (and org-clock-report-include-clocking-task (equal (org-clocking-buffer) (current-buffer)) (equal (marker-position org-clock-hd-marker) (point)) tstart tend (>= (org-float-time org-clock-start-time) tstart) (<= (org-float-time org-clock-start-time) tend)) (let ((time ...)) (setq t1 (+ t1 time)))) (let* ((headline-forced (get-text-property ... :org-clock-force-headline-inclusion)) (headline-included (or ... ...))) (setq level (- (match-end 1) (match-beginning 1))) (when (or (> t1 0) (> ... 0)) (when (or headline-included headline-forced) (if headline-included ...) (setq time ...) (goto-char ...) (put-text-property ... ... :org-clock-minutes time) (if headline-filter ...)) (setq t1 0) (loop for l from level to (1- lmax) do (aset ltimes l 0))))))) (setq org-clock-file-total-minutes (aref ltimes 0)))
  (let* ((bmp (buffer-modified-p)) (re (concat "^\\(\\*+\\)[ 	]\\|^[ 	]*" org-clock-string "[ 	]*\\(?:\\(\\[.*?\\]\\)-+\\(\\[.*?\\]\\)\\|=>[ 	]+\\([0-9]+\\):\\([0-9]+\\)\\)")) (lmax 30) (ltimes (make-vector lmax 0)) (t1 0) (level 0) ts te dt time) (if (stringp tstart) (setq tstart (org-time-string-to-seconds tstart))) (if (stringp tend) (setq tend (org-time-string-to-seconds tend))) (if (consp tstart) (setq tstart (org-float-time tstart))) (if (consp tend) (setq tend (org-float-time tend))) (remove-text-properties (point-min) (point-max) (quote (:org-clock-minutes t :org-clock-force-headline-inclusion t))) (save-excursion (goto-char (point-max)) (while (re-search-backward re nil t) (cond ((match-end 2) (setq ts (match-string 2) te (match-string 3) ts (org-float-time (apply ... ...)) te (org-float-time (apply ... ...)) ts (if tstart (max ts tstart) ts) te (if tend (min te tend) te) dt (- te ts) t1 (if (> dt 0) (+ t1 ...) t1))) ((match-end 4) (setq t1 (+ t1 (string-to-number ...) (* 60 ...)))) (t (when (and org-clock-report-include-clocking-task (equal ... ...) (equal ... ...) tstart tend (>= ... tstart) (<= ... tend)) (let (...) (setq t1 ...))) (let* ((headline-forced ...) (headline-included ...)) (setq level (- ... ...)) (when (or ... ...) (when ... ... ... ... ... ...) (setq t1 0) (loop for l from level to ... do ...)))))) (setq org-clock-file-total-minutes (aref ltimes 0))) (set-buffer-modified-p bmp))
  org-clock-sum()
  (let (time h m p) (org-clock-sum) (unless total-only (save-excursion (goto-char (point-min)) (while (or (and (equal (setq p ...) (point-min)) (get-text-property p :org-clock-minutes)) (setq p (next-single-property-change (point) :org-clock-minutes))) (goto-char p) (when (setq time (get-text-property p :org-clock-minutes)) (org-clock-put-overlay time (funcall outline-level)))) (setq h (/ org-clock-file-total-minutes 60) m (- org-clock-file-total-minutes (* 60 h))) (when org-remove-highlights-with-change (org-add-hook (quote before-change-functions) (quote org-clock-remove-overlays) nil (quote local))))) (if org-time-clocksum-use-fractional (message (concat "Total file time: " org-time-clocksum-fractional-format " (%d hours and %d minutes)") (/ (+ (* h 60.0) m) 60.0) h m) (message (concat "Total file time: " org-time-clocksum-format " (%d hours and %d minutes)") h m h m)))
  org-clock-display()
  call-interactively(org-clock-display t nil)
  execute-extended-command(nil)
  call-interactively(execute-extended-command nil nil)



Any further ideas what to try next?

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: How to debug "org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61"

[Bernt Hansen]

Gregor Zattler <telegraph@gmx.net> writes:

> Hi Bernt, org-mode developers,
> * Bernt Hansen <bernt@norang.ca> [05. Jan. 2012]:
>> Gregor Zattler <telegraph@gmx.net> writes:
>>> I use org-mode to record my working time.  If I want to know the
>>> total time worked on a project I do a M-X org-clock-display.
>>>
>>> But this suddenly gives me this error message:
>>>
>>> org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61
>>>

<snip>

>> 
>> If you generate a backtrace with uncompiled org source files you should
>> get an indication of where the problem is.

>
> I did as you said but the backtrace is totally opaque to me:
>

<snip>

Hi Gregor,

Apologies for not responding sooner but you didn't send a copy directly
to me (with reply-all) and my gmane access has been down for a week - so
I'm just now catching up on the list traffic.

I see from later posts that Nick has already provided details to figure
out what is going on.

Regards,
Bernt

Getting rid of split frame with org-capture

[Thomas Lockney]

I'm attempting to get some code working that should create a new frame
with *just* org-capture, but when I run it, I keep getting a split
despite various attempts at running delete-other-windows. I'm running
on "GNU Emacs 24.0.90.1 (i386-apple-darwin10.8.0, NS
apple-appkit-1038.36)" so perhaps this is a 24 specific issue. Here's
the code I've currently got:

(defadvice org-capture-finalize (after delete-capture-frame activate)
  "Advise capture-finalize to close the frame if it is the capture frame"
  (if (equal "capture" (frame-parameter nil 'name))
      (delete-frame)))

(defadvice org-capture-destroy (after delete-capture-frame activate)
  "Advise capture-destroy to close the frame if it is the capture frame"
  (if (equal "capture" (frame-parameter nil 'name))
      (delete-frame)))

(defun make-capture-frame ()
  "Create a new frame and run org-capture."
  (interactive)
  (make-frame '((name . "Capture")
                (width . 100)
                (height . 15)))
  (select-frame-by-name "Capture")
  (delete-other-windows)
  (org-capture))

I've also tried this using the org-capture-mode-hook to call
delete-other-windows and I've tried placing delete-other-windows after
the call to org-capture (both of those based on solutions I've seen
posted to this list at various times). Anyone have any clues on this?
I'm stumped, but I'm also fairly inexperienced at programming emacs.

-- 
http://about.me/tlockney

Re: Getting rid of split frame with org-capture

[Gregor Zattler]

Hi Thomas, org-mode community,
* Thomas Lockney <thomas@lockney.net> [10. Nov. 2011]:
> I'm attempting to get some code working that should create a new frame
> with *just* org-capture, 

this is something I also tried hard to achive.

> but when I run it, I keep getting a split
> despite various attempts at running delete-other-windows. I'm running
> on "GNU Emacs 24.0.90.1 (i386-apple-darwin10.8.0, NS
> apple-appkit-1038.36)" so perhaps this is a 24 specific issue. Here's
> the code I've currently got:
> 
> (defadvice org-capture-finalize (after delete-capture-frame activate)
>   "Advise capture-finalize to close the frame if it is the capture frame"
>   (if (equal "capture" (frame-parameter nil 'name))
>       (delete-frame)))
> 
> (defadvice org-capture-destroy (after delete-capture-frame activate)
>   "Advise capture-destroy to close the frame if it is the capture frame"
>   (if (equal "capture" (frame-parameter nil 'name))
>       (delete-frame)))
> 
> (defun make-capture-frame ()
>   "Create a new frame and run org-capture."
>   (interactive)
>   (make-frame '((name . "Capture")
>                 (width . 100)
>                 (height . 15)))
>   (select-frame-by-name "Capture")
>   (delete-other-windows)
>   (org-capture))

I played a bit with your code.  I also use emacs24.  I also get a
split frame.  I think it's org-capture which splits the frame.

I want to run this with emacsclient.  But when there is no
graphical (X11) frame then emacsclient -e '(make-capture-frame)'
does nothing, no frame pops up. 

> I've also tried this using the org-capture-mode-hook to call
> delete-other-windows and I've tried placing delete-other-windows after
> the call to org-capture (both of those based on solutions I've seen
> posted to this list at various times). Anyone have any clues on this?
> I'm stumped, but I'm also fairly inexperienced at programming
> emacs.

me too.  For my capture needs I would like to automatically open a frame for
org-capture and also automatically close it when finishing the
capture.  This should happen regardless of other frames or the
lack of other frames.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: Getting rid of split frame with org-capture

[Nick Dokos]

Gregor Zattler <telegraph@gmx.net> wrote:

> Hi Thomas, org-mode community,
> * Thomas Lockney <thomas@lockney.net> [10. Nov. 2011]:
> > I'm attempting to get some code working that should create a new frame
> > with *just* org-capture, 
> 
> this is something I also tried hard to achive.
> 
> > but when I run it, I keep getting a split
> > despite various attempts at running delete-other-windows. I'm running
> > on "GNU Emacs 24.0.90.1 (i386-apple-darwin10.8.0, NS
> > apple-appkit-1038.36)" so perhaps this is a 24 specific issue. Here's
> > the code I've currently got:
> > 
> > (defadvice org-capture-finalize (after delete-capture-frame activate)
> >   "Advise capture-finalize to close the frame if it is the capture frame"
> >   (if (equal "capture" (frame-parameter nil 'name))
> >       (delete-frame)))
> > 
> > (defadvice org-capture-destroy (after delete-capture-frame activate)
> >   "Advise capture-destroy to close the frame if it is the capture frame"
> >   (if (equal "capture" (frame-parameter nil 'name))
> >       (delete-frame)))
> > 
> > (defun make-capture-frame ()
> >   "Create a new frame and run org-capture."
> >   (interactive)
> >   (make-frame '((name . "Capture")
> >                 (width . 100)
> >                 (height . 15)))
> >   (select-frame-by-name "Capture")
> >   (delete-other-windows)
> >   (org-capture))
> 
> I played a bit with your code.  I also use emacs24.  I also get a
> split frame.  I think it's org-capture which splits the frame.
> 
> I want to run this with emacsclient.  But when there is no
> graphical (X11) frame then emacsclient -e '(make-capture-frame)'
> does nothing, no frame pops up. 
> 
> > I've also tried this using the org-capture-mode-hook to call
> > delete-other-windows and I've tried placing delete-other-windows after
> > the call to org-capture (both of those based on solutions I've seen
> > posted to this list at various times). Anyone have any clues on this?
> > I'm stumped, but I'm also fairly inexperienced at programming
> > emacs.
> 
> me too.  For my capture needs I would like to automatically open a frame for
> org-capture and also automatically close it when finishing the
> capture.  This should happen regardless of other frames or the
> lack of other frames.
> 

AFAICT, this is not possible with the current code. The above is
attacking the problem at the wrong level: you can't change that behavior
from the outside; you need to change the existing code in order to
implement it.

If you wish to hack, the relevant function is
org-capture-place-template: changing the
org-switch-to-buffer-other-window to org-switch-to-buffer-other-frame
(and adding a definition for the latter function in analogy to the
former) would indeed pop up a frame and you can enter your capture and
finalize it - that's the easy part.

But note that org-capture-finalize would need a tweak too in order to
delete the now useless frame.

And of course all of this would need to be done conditionally based
on a new user option, perhaps org-capture-in-new-frame (nil by default).
And don't forget to make it customizable.

Not worth the bother IMO[fn:1], but if you wish to implement it and submit
a patch, I'd be happy to review it.

Nick

Footnotes:

[fn:1] Remember, capture is supposed to be as unobtrusive as possible:
       you just want to squirrel away something for future
       reference. Bells and whistles (which, IMO, this change would be)
       are not the point: you want to get in, record the data and get
       out and back to work as fast as possible. Popping up frames slows
       things down but more importantly jolts you away from what you
       were doing. At least, it would me (I think): that's why I don't
       think it's worth it, but you may very well disagree.

Re: Getting rid of split frame with org-capture

[Tom Prince]

On Sat, 12 Nov 2011 23:13:11 -0500, Nick Dokos <nicholas.dokos@hp.com> wrote:
> Not worth the bother IMO[fn:1], but if you wish to implement it and submit
> a patch, I'd be happy to review it.
> 
> Nick
> 
> Footnotes:
> 
> [fn:1] Remember, capture is supposed to be as unobtrusive as possible:
>        you just want to squirrel away something for future
>        reference. Bells and whistles (which, IMO, this change would be)
>        are not the point: you want to get in, record the data and get
>        out and back to work as fast as possible. Popping up frames slows
>        things down but more importantly jolts you away from what you
>        were doing. At least, it would me (I think): that's why I don't
>        think it's worth it, but you may very well disagree.

It isn't worth *if* capture is invoked from emacs. If capture is invoked
from org-protocol in firefox, then there might not even be a emacs frame
visible.

1) If I don't pass -c to emacsclient, then I need to search all my
   workspaces to find where emacs decided to put the capture frame
2) If I pass do pass -c to emacsclient, then I need to close the frame
   afterwards. And more significantly, I need to close the empty frame
   when I use store-link instead. (I could work around this by using
   seperate protocols for for each)

 Tom

Re: Getting rid of split frame with org-capture

[Nick Dokos]

Tom Prince <tom.prince@ualberta.net> wrote:

> On Sat, 12 Nov 2011 23:13:11 -0500, Nick Dokos <nicholas.dokos@hp.com> wrote:
> > Not worth the bother IMO[fn:1], but if you wish to implement it and submit
> > a patch, I'd be happy to review it.
> > 
> > Nick
> > 
> > Footnotes:
> > 
> > [fn:1] Remember, capture is supposed to be as unobtrusive as possible:
> >        you just want to squirrel away something for future
> >        reference. Bells and whistles (which, IMO, this change would be)
> >        are not the point: you want to get in, record the data and get
> >        out and back to work as fast as possible. Popping up frames slows
> >        things down but more importantly jolts you away from what you
> >        were doing. At least, it would me (I think): that's why I don't
> >        think it's worth it, but you may very well disagree.
> 
> It isn't worth *if* capture is invoked from emacs. If capture is invoked
> from org-protocol in firefox, then there might not even be a emacs frame
> visible.
> 

<OT rant>

org-protocol is below my horizon :-) I had gotten it working a long time
ago, then something happened in ff and broke it, I fixed it, they broke
it again and at some point I gave up: every time I had to fix it, I had
to go back and relearn everything (it's not as if I live and breathe ff
arcana) and do a few hours' worth of research and then try a few dozen
times, tweaking this and that because all the instructions were either
outdated or inconsistent - if "they" are not respectful enough of the
thousands of people that used the feature that they broke and not
cognizant of the pain they produce, I will not use their damn
feature. Similar remarks apply to the "improvements" of Unity and Gnome
3: a plague a' both their houses. All I need the damn desktop to do is
open emacs when I click on the icon and give me enough workspaces for my
needs (which vary). I'd rather do cut-n-paste than waste another second
on org-protocol (mind you, it's not org-protocol's problem: it's the
other side that breaks - but without the other side, org-protocol is
almost useless).

Ah, I feel better now...

</OT rant>

> 1) If I don't pass -c to emacsclient, then I need to search all my
>    workspaces to find where emacs decided to put the capture frame
> 2) If I pass do pass -c to emacsclient, then I need to close the frame
>    afterwards. And more significantly, I need to close the empty frame
>    when I use store-link instead. (I could work around this by using
>    seperate protocols for for each)
> 

Sounds like a worthwhile thing to fix - patches would probably be welcome.

Nick

Re: Getting rid of split frame with org-capture

[Tom Prince]

On Sun, 13 Nov 2011 12:57:21 -0500, Nick Dokos <nicholas.dokos@hp.com> wrote:
> > 1) If I don't pass -c to emacsclient, then I need to search all my
> >    workspaces to find where emacs decided to put the capture frame
> > 2) If I pass do pass -c to emacsclient, then I need to close the frame
> >    afterwards. And more significantly, I need to close the empty frame
> >    when I use store-link instead. (I could work around this by using
> >    seperate protocols for for each)
> > 
> 
> Sounds like a worthwhile thing to fix - patches would probably be
> welcome.

I came up with the following hack, which seems to do what I want:

(defadvice org-protocol-check-filename-for-protocol (around tp/org-protocol-make-frame activate)
  "Advice org-protocol-check-filename-for-protocol to open windows in new frames."
  (flet ((org-switch-to-buffer-other-window (&rest args) ; for org-mks
            (let ((pop-up-frames t))
              (apply 'switch-to-buffer-other-window args)))
         (org-pop-to-buffer-same-window (&rest args)  ; for org-capture
            (let ((pop-up-frames t))
              (apply 'switch-to-buffer-other-window args))))
    (let ((display-buffer-mark-dedicated t))
      ad-do-it)))

Re: Getting rid of split frame with org-capture

[Andreas Leha]

Hi,

@Tom, thanks for this nice snippet!  Very useful, when several emacs
frames are opened.

While it works well on my emacs23, the emacs24 snapshot from
http://emacs.naquadah.org/ crashes, when I select a template.  Is this a
general issue with emacs24?  Ideas to adapt the snippet to work with
emacs24?

Thank in advance,
Andreas

Re: Getting rid of split frame with org-capture

[Tom Prince]

On Wed, 14 Dec 2011 00:11:11 +0100, Andreas Leha <andreas.leha@med.uni-goettingen.de> wrote:
> While it works well on my emacs23, the emacs24 snapshot from
> http://emacs.naquadah.org/ crashes, when I select a template.  Is this a
> general issue with emacs24?  Ideas to adapt the snippet to work with
> emacs24?

What do you mean by crash? Does the emacs process exit? In that case, I
would try reporting the problem to some emacs forum ... I don't think
emacs should be crashing given any elisp code, certainly not this code.

  Tom

Re: Getting rid of split frame with org-capture

[Alexander Vorobiev]

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

I also wanted to have new pop-up org-capture window that would be created
in
response to some shortcut anywhere in Windows and occupied the entire
frame.
Since I haven't found any solutions, I just modified a function I saw in
this thread:

 (defun make-capture-frame ()
         "Create a new frame and run org-capture."
         (interactive)
         (make-frame '((name . "capture")))
         (select-frame-by-name "capture")
         (delete-other-windows)
         (flet ((switch-to-buffer-other-window (buf) (switch-to-buffer
buf)))
           (org-capture)))

The culprit is switch-to-buffer-other-window that ultimately gets called by
org-capture so I just reassign it temporarily to switch-to-buffer.

Then I use AutoHotkey to create a shortcut that would call emacsclient with
the new function. I am experimenting with AutoHotkey to construct
application-dependent org-mode-style links on the clipboard so that I can
use %x parameter in my capture templates to insert them. The current
version
of my AutoHotkey script creates links when in Google Chrome or Excel:

https://github.com/alexvorobiev/autohotkey/blob/master/AutoHotkey.ahk

The shortcut is Win-`

Regards,
Alex



On Wed, Dec 14, 2011 at 10:37 AM, Tom Prince <tom.prince@ualberta.net>wrote:

> On Wed, 14 Dec 2011 00:11:11 +0100, Andreas Leha <
> andreas.leha@med.uni-goettingen.de> wrote:
> > While it works well on my emacs23, the emacs24 snapshot from
> > http://emacs.naquadah.org/ crashes, when I select a template.  Is this a
> > general issue with emacs24?  Ideas to adapt the snippet to work with
> > emacs24?
>
> What do you mean by crash? Does the emacs process exit? In that case, I
> would try reporting the problem to some emacs forum ... I don't think
> emacs should be crashing given any elisp code, certainly not this code.
>
>   Tom
>
>

[-- Attachment #2: Type: text/html, Size: 2869 bytes --]

Re: Getting rid of split frame with org-capture

[Alan Schmitt]

alexander.vorobiev@gmail.com writes:

> I also wanted to have new pop-up org-capture window that would be created
> in
> response to some shortcut anywhere in Windows and occupied the entire
> frame.
> Since I haven't found any solutions, I just modified a function I saw in
> this thread:
>
>  (defun make-capture-frame ()
>          "Create a new frame and run org-capture."
>          (interactive)
>          (make-frame '((name . "capture")))
>          (select-frame-by-name "capture")
>          (delete-other-windows)
>          (flet ((switch-to-buffer-other-window (buf) (switch-to-buffer
> buf)))
>            (org-capture)))
>
> The culprit is switch-to-buffer-other-window that ultimately gets called by
> org-capture so I just reassign it temporarily to switch-to-buffer.

This is working great, thanks a lot!

Alan

Re: Getting rid of split frame with org-capture

[Eric S Fraga]

Nick Dokos <nicholas.dokos@hp.com> writes:


> <OT rant>
>
> org-protocol is below my horizon :-) I had gotten it working a long time
> ago, then something happened in ff and broke it, I fixed it, they broke
> it again and at some point I gave up: every time I had to fix it, I

I so sympathise with you!  I gave up on capture from ff for exactly this
reason.  Keyboard based cut'n'paste does the job with only a couple more
keystrokes in the end (C-l C-c M-tab C-c c n C-y C-c C-c).  Well, with
appropriate number of M-Tabs... YMMV, of course!

> feature. Similar remarks apply to the "improvements" of Unity and Gnome
> 3: a plague a' both their houses. All I need the damn desktop to do is
> open emacs when I click on the icon and give me enough workspaces for my
> needs (which vary). 

which is why I use ratpoison with "C-t e" opening up Emacs... ;-)

> Ah, I feel better now...
>
> </OT rant>

As do I!  Thanks.

Apologies for the noise.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.7 (release_7.7.598.g4e2a)

Re: How to debug "org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61"

[Nick Dokos]

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

Nick


>   (> (aref ltimes level) 0)
>   (or (> t1 0) (> (aref ltimes level) 0))
>   (if (or (> t1 0) (> (aref ltimes level) 0)) (progn (when (or headline-inc=
> luded headline-forced) (if headline-included (loop for l from 0 to level do=
>  (aset ltimes l (+ (aref ltimes l) t1)))) (setq time (aref ltimes level)) (=
> goto-char (match-beginning 0)) (put-text-property (point) (point-at-eol) :o=
> rg-clock-minutes time) (if headline-filter (save-excursion (save-match-data=
>  (while (> ... 1) (outline-up-heading 1 t) (put-text-property ... ... :org-=
> clock-force-headline-inclusion t)))))) (setq t1 0) (loop for l from level t=
> o (1- lmax) do (aset ltimes l 0))))
>   (when (or (> t1 0) (> (aref ltimes level) 0)) (when (or headline-included=
>  headline-forced) (if headline-included (loop for l from 0 to level do (ase=
> t ltimes l (+ (aref ltimes l) t1)))) (setq time (aref ltimes level)) (goto-=
> char (match-beginning 0)) (put-text-property (point) (point-at-eol) :org-cl=
> ock-minutes time) (if headline-filter (save-excursion (save-match-data (whi=
> le (> (funcall outline-level) 1) (outline-up-heading 1 t) (put-text-propert=
> y (point) (point-at-eol) :org-clock-force-headline-inclusion t)))))) (setq =
> t1 0) (loop for l from level to (1- lmax) do (aset ltimes l 0)))
>   (let* ((headline-forced (get-text-property (point) :org-clock-force-headl=
> ine-inclusion)) (headline-included (or (null headline-filter) (save-excursi=
> on (save-match-data (funcall headline-filter)))))) (setq level (- (match-en=
> d 1) (match-beginning 1))) (when (or (> t1 0) (> (aref ltimes level) 0)) (w=
> hen (or headline-included headline-forced) (if headline-included (loop for =
> l from 0 to level do (aset ltimes l (+ (aref ltimes l) t1)))) (setq time (a=
> ref ltimes level)) (goto-char (match-beginning 0)) (put-text-property (poin=
> t) (point-at-eol) :org-clock-minutes time) (if headline-filter (save-excurs=
> ion (save-match-data (while (> ... 1) (outline-up-heading 1 t) (put-text-pr=
> operty ... ... :org-clock-force-headline-inclusion t)))))) (setq t1 0) (loo=
> p for l from level to (1- lmax) do (aset ltimes l 0))))
>   (cond ((match-end 2) (setq ts (match-string 2) te (match-string 3) ts (or=
> g-float-time (apply (quote encode-time) (org-parse-time-string ts))) te (or=
> g-float-time (apply (quote encode-time) (org-parse-time-string te))) ts (if=
>  tstart (max ts tstart) ts) te (if tend (min te tend) te) dt (- te ts) t1 (=
> if (> dt 0) (+ t1 (floor (/ dt 60))) t1))) ((match-end 4) (setq t1 (+ t1 (s=
> tring-to-number (match-string 5)) (* 60 (string-to-number (match-string 4))=
> )))) (t (when (and org-clock-report-include-clocking-task (equal (org-clock=
> ing-buffer) (current-buffer)) (equal (marker-position org-clock-hd-marker) =
> (point)) tstart tend (>=3D (org-float-time org-clock-start-time) tstart) (<=
> =3D (org-float-time org-clock-start-time) tend)) (let ((time (floor (- ... =
> =2E..) 60))) (setq t1 (+ t1 time)))) (let* ((headline-forced (get-text-prop=
> erty (point) :org-clock-force-headline-inclusion)) (headline-included (or (=
> null headline-filter) (save-excursion (save-match-data ...))))) (setq level=
>  (- (match-end 1) (match-beginning 1))) (when (or (> t1 0) (> (aref ltimes =
> level) 0)) (when (or headline-included headline-forced) (if headline-includ=
> ed (loop for l from 0 to level do (aset ltimes l ...))) (setq time (aref lt=
> imes level)) (goto-char (match-beginning 0)) (put-text-property (point) (po=
> int-at-eol) :org-clock-minutes time) (if headline-filter (save-excursion (s=
> ave-match-data ...)))) (setq t1 0) (loop for l from level to (1- lmax) do (=
> aset ltimes l 0))))))
>   (while (re-search-backward re nil t) (cond ((match-end 2) (setq ts (match=
> -string 2) te (match-string 3) ts (org-float-time (apply (quote encode-time=
> ) (org-parse-time-string ts))) te (org-float-time (apply (quote encode-time=
> ) (org-parse-time-string te))) ts (if tstart (max ts tstart) ts) te (if ten=
> d (min te tend) te) dt (- te ts) t1 (if (> dt 0) (+ t1 (floor (/ dt 60))) t=
> 1))) ((match-end 4) (setq t1 (+ t1 (string-to-number (match-string 5)) (* 6=
> 0 (string-to-number (match-string 4)))))) (t (when (and org-clock-report-in=
> clude-clocking-task (equal (org-clocking-buffer) (current-buffer)) (equal (=
> marker-position org-clock-hd-marker) (point)) tstart tend (>=3D (org-float-=
> time org-clock-start-time) tstart) (<=3D (org-float-time org-clock-start-ti=
> me) tend)) (let ((time (floor ... 60))) (setq t1 (+ t1 time)))) (let* ((hea=
> dline-forced (get-text-property (point) :org-clock-force-headline-inclusion=
> )) (headline-included (or (null headline-filter) (save-excursion ...)))) (s=
> etq level (- (match-end 1) (match-beginning 1))) (when (or (> t1 0) (> (are=
> f ltimes level) 0)) (when (or headline-included headline-forced) (if headli=
> ne-included (loop for l from 0 to level do ...)) (setq time (aref ltimes le=
> vel)) (goto-char (match-beginning 0)) (put-text-property (point) (point-at-=
> eol) :org-clock-minutes time) (if headline-filter (save-excursion ...))) (s=
> etq t1 0) (loop for l from level to (1- lmax) do (aset ltimes l 0)))))))
>   (save-excursion (goto-char (point-max)) (while (re-search-backward re nil=
>  t) (cond ((match-end 2) (setq ts (match-string 2) te (match-string 3) ts (=
> org-float-time (apply (quote encode-time) (org-parse-time-string ts))) te (=
> org-float-time (apply (quote encode-time) (org-parse-time-string te))) ts (=
> if tstart (max ts tstart) ts) te (if tend (min te tend) te) dt (- te ts) t1=
>  (if (> dt 0) (+ t1 (floor ...)) t1))) ((match-end 4) (setq t1 (+ t1 (strin=
> g-to-number (match-string 5)) (* 60 (string-to-number ...))))) (t (when (an=
> d org-clock-report-include-clocking-task (equal (org-clocking-buffer) (curr=
> ent-buffer)) (equal (marker-position org-clock-hd-marker) (point)) tstart t=
> end (>=3D (org-float-time org-clock-start-time) tstart) (<=3D (org-float-ti=
> me org-clock-start-time) tend)) (let ((time ...)) (setq t1 (+ t1 time)))) (=
> let* ((headline-forced (get-text-property ... :org-clock-force-headline-inc=
> lusion)) (headline-included (or ... ...))) (setq level (- (match-end 1) (ma=
> tch-beginning 1))) (when (or (> t1 0) (> ... 0)) (when (or headline-include=
> d headline-forced) (if headline-included ...) (setq time ...) (goto-char ..=
> =2E) (put-text-property ... ... :org-clock-minutes time) (if headline-filte=
> r ...)) (setq t1 0) (loop for l from level to (1- lmax) do (aset ltimes l 0=
> ))))))) (setq org-clock-file-total-minutes (aref ltimes 0)))
>   (let* ((bmp (buffer-modified-p)) (re (concat "^\\(\\*+\\)[ 	]\\|^[ 	]*" o=
> rg-clock-string "[ 	]*\\(?:\\(\\[.*?\\]\\)-+\\(\\[.*?\\]\\)\\|=3D>[ 	]+\\([=
> 0-9]+\\):\\([0-9]+\\)\\)")) (lmax 30) (ltimes (make-vector lmax 0)) (t1 0) =
> (level 0) ts te dt time) (if (stringp tstart) (setq tstart (org-time-string=
> -to-seconds tstart))) (if (stringp tend) (setq tend (org-time-string-to-sec=
> onds tend))) (if (consp tstart) (setq tstart (org-float-time tstart))) (if =
> (consp tend) (setq tend (org-float-time tend))) (remove-text-properties (po=
> int-min) (point-max) (quote (:org-clock-minutes t :org-clock-force-headline=
> -inclusion t))) (save-excursion (goto-char (point-max)) (while (re-search-b=
> ackward re nil t) (cond ((match-end 2) (setq ts (match-string 2) te (match-=
> string 3) ts (org-float-time (apply ... ...)) te (org-float-time (apply ...=
>  ...)) ts (if tstart (max ts tstart) ts) te (if tend (min te tend) te) dt (=
> - te ts) t1 (if (> dt 0) (+ t1 ...) t1))) ((match-end 4) (setq t1 (+ t1 (st=
> ring-to-number ...) (* 60 ...)))) (t (when (and org-clock-report-include-cl=
> ocking-task (equal ... ...) (equal ... ...) tstart tend (>=3D ... tstart) (=
> <=3D ... tend)) (let (...) (setq t1 ...))) (let* ((headline-forced ...) (he=
> adline-included ...)) (setq level (- ... ...)) (when (or ... ...) (when ...=
>  ... ... ... ... ...) (setq t1 0) (loop for l from level to ... do ...)))))=
> ) (setq org-clock-file-total-minutes (aref ltimes 0))) (set-buffer-modified=
> -p bmp))
>   org-clock-sum()
>   (let (time h m p) (org-clock-sum) (unless total-only (save-excursion (got=
> o-char (point-min)) (while (or (and (equal (setq p ...) (point-min)) (get-t=
> ext-property p :org-clock-minutes)) (setq p (next-single-property-change (p=
> oint) :org-clock-minutes))) (goto-char p) (when (setq time (get-text-proper=
> ty p :org-clock-minutes)) (org-clock-put-overlay time (funcall outline-leve=
> l)))) (setq h (/ org-clock-file-total-minutes 60) m (- org-clock-file-total=
> -minutes (* 60 h))) (when org-remove-highlights-with-change (org-add-hook (=
> quote before-change-functions) (quote org-clock-remove-overlays) nil (quote=
>  local))))) (if org-time-clocksum-use-fractional (message (concat "Total fi=
> le time: " org-time-clocksum-fractional-format " (%d hours and %d minutes)"=
> ) (/ (+ (* h 60.0) m) 60.0) h m) (message (concat "Total file time: " org-t=
> ime-clocksum-format " (%d hours and %d minutes)") h m h m)))
>   org-clock-display()
>   call-interactively(org-clock-display t nil)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command nil nil)
> 
> 
> 
> Any further ideas what to try next?
> 
> Ciao, Gregor
> --=20
>  -... --- .-. . -.. ..--.. ...-.-
> 

Re: How to debug "org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61"

[Nick Dokos]

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.

Nick

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

[Gregor Zattler]

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

Re: How to debug "org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61"

[Stefan Nobis]

Nick Dokos <nicholas.dokos@hp.com> writes:

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

Hmmm... the above snippet is from org-clock-sum, right? That means it
is part of (while (re-search-backward re nil t) ...) and that's the
search match-beginning/match-end are referring to.

-- 
Until the next mail...,
Stefan.

Re: [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"

[Nick Dokos]

Gregor Zattler <telegraph@gmx.net> wrote:

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

Nick

Footnotes:

[fn:1] I doubt anybody uses > 30-level deep trees, although I would not be
       surprised to hear otherwise :-)

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

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

[PATCH 2/3] Document max number of stars in headings in manual

[Gregor Zattler]

Clocking only works with headings indented with less than `30' stars
(hardcoded `lmax' value in `org-clock-sum').
---
 doc/org.texi |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index b238210..9e873ea 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -1164,7 +1164,8 @@ Headlines define the structure of an outline tree.  The headlines in Org
 start with one or more stars, on the left margin@footnote{See the variables
 @code{org-special-ctrl-a/e}, @code{org-special-ctrl-k}, and
 @code{org-ctrl-k-protect-subtree} to configure special behavior of @kbd{C-a},
-@kbd{C-e}, and @kbd{C-k} in headlines.}.  For example:
+@kbd{C-e}, and @kbd{C-k} in headlines.} @footnote{Clocking only works with
+headings indented less then 30 stars.}.  For example:
 
 @example
 * Top level headline
-- 
1.7.8.3

[Accepted] [O, 2/3] Document max number of stars in headings in manual

[Bastien Guerry]

Patch 1123 (http://patchwork.newartisans.com/patch/1123/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3C20120122131506.GB21012%40shi.workgroup%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [O,2/3] Document max number of stars in headings in manual
> Date: Sun, 22 Jan 2012 18:15:06 -0000
> From: Gregor Zattler <telegraph@gmx.net>
> X-Patchwork-Id: 1123
> Message-Id: <20120122131506.GB21012@shi.workgroup>
> To: emacs-orgmode <emacs-orgmode@gnu.org>
> 
> Clocking only works with headings indented with less than `30' stars
> (hardcoded `lmax' value in `org-clock-sum').
> 
> ---
> doc/org.texi |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/doc/org.texi b/doc/org.texi
> index b238210..9e873ea 100644
> --- a/doc/org.texi
> +++ b/doc/org.texi
> @@ -1164,7 +1164,8 @@ Headlines define the structure of an outline tree.  The headlines in Org
>  start with one or more stars, on the left margin@footnote{See the variables
>  @code{org-special-ctrl-a/e}, @code{org-special-ctrl-k}, and
>  @code{org-ctrl-k-protect-subtree} to configure special behavior of @kbd{C-a},
> -@kbd{C-e}, and @kbd{C-k} in headlines.}.  For example:
> +@kbd{C-e}, and @kbd{C-k} in headlines.} @footnote{Clocking only works with
> +headings indented less then 30 stars.}.  For example:
>  
>  @example
>  * Top level headline
> 

[PATCH 1/3] Document max number of stars in headings in docstring of org-inlinetask-minlevel

[Gregor Zattler]

Clocking only works with headings indented with less than `30' stars
(hardcoded `lmax' value in `org-clock-sum').  Since especially inline
tasks may dupe someone into using more stars, document the limit in
the docsring of `org-inlinetask-min-level'.
---
 lisp/org-inlinetask.el |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el
index a14e404..b8e8437 100644
--- a/lisp/org-inlinetask.el
+++ b/lisp/org-inlinetask.el
@@ -90,6 +90,9 @@
 
 (defcustom org-inlinetask-min-level 15
   "Minimum level a headline must have before it is treated as an inline task.
+Don't set it to something higher than `29' or clocking will break since this 
+is the hardcoded maximum number of stars `org-clock-sum' will work with.
+
 It is strongly recommended that you set `org-cycle-max-level' not at all,
 or to a number smaller than this one.  In fact, when `org-cycle-max-level' is
 not set, it will be assumed to be one less than the value of smaller than
-- 
1.7.8.3

[Accepted] [O, 1/3] Document max number of stars in headings in docstring of org-inlinetask-minlevel

[Bastien Guerry]

Patch 1124 (http://patchwork.newartisans.com/patch/1124/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3C20120122131516.GC21012%40shi.workgroup%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [O, 1/3] Document max number of stars in headings in docstring of
> 	org-inlinetask-minlevel
> Date: Sun, 22 Jan 2012 18:15:16 -0000
> From: Gregor Zattler <telegraph@gmx.net>
> X-Patchwork-Id: 1124
> Message-Id: <20120122131516.GC21012@shi.workgroup>
> To: emacs-orgmode <emacs-orgmode@gnu.org>
> 
> Clocking only works with headings indented with less than `30' stars
> (hardcoded `lmax' value in `org-clock-sum').  Since especially inline
> tasks may dupe someone into using more stars, document the limit in
> the docsring of `org-inlinetask-min-level'.
> 
> ---
> lisp/org-inlinetask.el |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el
> index a14e404..b8e8437 100644
> --- a/lisp/org-inlinetask.el
> +++ b/lisp/org-inlinetask.el
> @@ -90,6 +90,9 @@
>  
>  (defcustom org-inlinetask-min-level 15
>    "Minimum level a headline must have before it is treated as an inline task.
> +Don't set it to something higher than `29' or clocking will break since this 
> +is the hardcoded maximum number of stars `org-clock-sum' will work with.
> +
>  It is strongly recommended that you set `org-cycle-max-level' not at all,
>  or to a number smaller than this one.  In fact, when `org-cycle-max-level' is
>  not set, it will be assumed to be one less than the value of smaller than
> 

[PATCH 3/3] Document max number of stars in clocking section

[Gregor Zattler]

Clocking only works with all headings indented with less than `30'
stars (hardcoded `lmax' value in `org-clock-sum').
---
 doc/org.texi |   14 ++++++++------
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 9e873ea..46aa1e2 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -5917,12 +5917,14 @@ created for this purpose, it is described in @ref{Structure editing}.
 @cindex time clocking
 
 Org mode allows you to clock the time you spend on specific tasks in a
-project.  When you start working on an item, you can start the clock.
-When you stop working on that task, or when you mark the task done, the
-clock is stopped and the corresponding time interval is recorded.  It
-also computes the total time spent on each subtree of a project.  And it
-remembers a history or tasks recently clocked, to that you can jump quickly
-between a number of tasks absorbing your time.
+project.  When you start working on an item, you can start the clock.  When
+you stop working on that task, or when you mark the task done, the clock is
+stopped and the corresponding time interval is recorded.  It also computes
+the total time spent on each subtree@footnote{Clocking only works if all
+headings are indented with less than 30 stars.  This is a hardcoded
+limitation of `lmax' in `org-clock-sum'.} of a project.  And it remembers a
+history or tasks recently clocked, to that you can jump quickly between a
+number of tasks absorbing your time.
 
 To save the clock history across Emacs sessions, use
 @lisp
-- 
1.7.8.3

[Accepted] [O, 3/3] Document max number of stars in clocking section

[Bastien Guerry]

Patch 1125 (http://patchwork.newartisans.com/patch/1125/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3C20120122133050.GD21012%40shi.workgroup%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [O,3/3] Document max number of stars in clocking section
> Date: Sun, 22 Jan 2012 18:30:50 -0000
> From: Gregor Zattler <telegraph@gmx.net>
> X-Patchwork-Id: 1125
> Message-Id: <20120122133050.GD21012@shi.workgroup>
> To: emacs-orgmode <emacs-orgmode@gnu.org>
> 
> Clocking only works with all headings indented with less than `30'
> stars (hardcoded `lmax' value in `org-clock-sum').
> 
> ---
> doc/org.texi |   14 ++++++++------
>  1 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/doc/org.texi b/doc/org.texi
> index 9e873ea..46aa1e2 100644
> --- a/doc/org.texi
> +++ b/doc/org.texi
> @@ -5917,12 +5917,14 @@ created for this purpose, it is described in @ref{Structure editing}.
>  @cindex time clocking
>  
>  Org mode allows you to clock the time you spend on specific tasks in a
> -project.  When you start working on an item, you can start the clock.
> -When you stop working on that task, or when you mark the task done, the
> -clock is stopped and the corresponding time interval is recorded.  It
> -also computes the total time spent on each subtree of a project.  And it
> -remembers a history or tasks recently clocked, to that you can jump quickly
> -between a number of tasks absorbing your time.
> +project.  When you start working on an item, you can start the clock.  When
> +you stop working on that task, or when you mark the task done, the clock is
> +stopped and the corresponding time interval is recorded.  It also computes
> +the total time spent on each subtree@footnote{Clocking only works if all
> +headings are indented with less than 30 stars.  This is a hardcoded
> +limitation of `lmax' in `org-clock-sum'.} of a project.  And it remembers a
> +history or tasks recently clocked, to that you can jump quickly between a
> +number of tasks absorbing your time.
>  
>  To save the clock history across Emacs sessions, use
>  @lisp
> 

Re: [BUG][PATCH] document number of stars limitation with respect to org-clock-sum

[Bastien]

Hi Gregor,

Gregor Zattler <telegraph@gmx.net> writes:

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

Applied, thanks.

-- 
 Bastien

Re: 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]

Gregor Zattler <telegraph@gmx.net> wrote:

> Hi Nicolas, org-mode users and developers,
> * Nicolas Goaziou <n.goaziou@gmail.com> [13. Oct. 2012]:
> > Gregor Zattler <telegraph@gmx.net> writes:
> > 
> >> Back to square one: Does anybody know How to customise
> >> Emacs/org-mode so that dotted European dates are parsed correctly
> >> at the date/time prompt?
> > 
> > Again, dotted European dates are parsed correctly without customization.
> > Would you provide a time string that isn't?
> 
> "Naked" dotted european dates without surrounding text are
> parsed correctly by org-read-date.
> 
> But with date/time prompt I mean the prompt which asks me for a
> date/time when invoking org-time-stamp.  Here I'm allowed to
> insert Dates like "the event takes place at 27.10. at 14:00 in
> the pub".  Org-mode is supposed to parse these, see
> [[info:org#The%20date/time%20prompt][info:org#The date/time prompt]].
> 
> If I now yank "Kommt am 27.10.2012 um 14:00 zum" in this
> date/time prompt, the result is "<2010-10-27 Mi 14:00>" instead
> of "<2012-10-27 Sa 14:00>".          ^       ^^
>         ^       ^^
> 

org-read-date calls org-read-date-analyze which does not recognize
this as any kind of time string format it knows about (all the regexps
it tries fail to match), so it calls parse-time-string. Lo and behold,

(parse-time-string "Kommt am 27.10.2012 um 14:00 zum")

returns

(0 0 14 27 nil 2010 nil nil nil)


> 
> I had a look at org-time-stamp which is invoked by "C-c ."  I do
> not understand how this function parses dates/times from text.
> Therefore I looked for functions with appropriate names which are
> called by org-time-stamp.  The only one I could find is
> org-read-date.  It obviously parses dates from a string and
> identifies parts (day, month, year).  I thought org-read-date
> does the heavy lifting with respect to date parsing.  But now I
> think you are right and org-read-dates parses "naked dates".  But
> where does the parsing of texts which contain dates take place?
> 

org-read-date does fine with "Kommt am 2012-10-27 um 14:00 zum",
because parse-time-string can figure out the iso date, even
though it cannot figure out the dotted european one:

(parse-time-string "Kommt am 2012-10-27 um 14:00 zum")

returns

(0 0 14 27 10 2012 nil nil nil)

Nick

Re: How to track down "No heading for this item in buffer or region."?

[Nick Dokos]

Gregor Zattler <telegraph@gmx.net> wrote:

> When I move the cursor over this lines a message appears in the
> echo area:
> 
> byte-code: Before first headline at position 64 in buffer org.org [14 times]
> 
> The second line of org.org begins at character 64 in the buffer.
> It's a timestamp:
> 
> #Time-stamp: <2013-01-24 16:30:39 grfz>
> 
> Till recently this was no problem since it is a comment line.
> Obviously org-mode somehow interprets this timestamp, since the
> messages disappeared after I changed the time stamp delimiter from
> `<' and `>' respectively to `"'.  I consider this to be a bug
> since these time stamps are a standard Emacs feature and this
> line is a comment org-mode-wise.
> 
> 

It works fine on the slightly old

Org-mode version 7.9.3d (release_7.9.3d-826-gbe0d87.dirty @ /home/nick/elisp/org-mode/lisp/)

with the following file as the only agenda file:

--8<---------------cut here---------------start------------->8---
# timestamp: <2013-01-24 Thu>

* TODO foo
  SCHEDULED: <2013-01-24 Thu>
--8<---------------cut here---------------end--------------->8---

If I get rid of the # or add something else before it, I get the
message you mention, but otherwise it is silent.

Assuming you are running a more recent version than the one above,
the bug may be because of a recent change to org-agenda-skip:
it used to check explicitly for # and skip the entry, but commit
211b137ef46d04b17b46f256696eb5c1c3a1d2be changed it to check a text
property. I guess the text property is not present or it is not checked
correctly.

Nick

Re: How to track down "No heading for this item in buffer or region."?

[Nick Dokos]

Gregor Zattler <telegraph@gmx.net> wrote:

> When I move the cursor over this lines a message appears in the
> echo area:
> 
> byte-code: Before first headline at position 64 in buffer org.org [14 times]
> 
> The second line of org.org begins at character 64 in the buffer.
> It's a timestamp:
> 
> #Time-stamp: <2013-01-24 16:30:39 grfz>
> 
> Till recently this was no problem since it is a comment line.
> Obviously org-mode somehow interprets this timestamp, since the
> messages disappeared after I changed the time stamp delimiter from
> `<' and `>' respectively to `"'.  I consider this to be a bug
> since these time stamps are a standard Emacs feature and this
> line is a comment org-mode-wise.
> 
> 

I am puzzled. The bug is almost certainly related to commit
211b137ef46d04b17b46f256696eb5c1c3a1d2be which changed org-agenda-skip
to check text properties rather than # explicitly. I can attest that
the bug does not show with a version earlier than that commit.

OTOH, it does not show *consistently* with the most recent version.
In a minimal test, I have the following file as the only file in the
agenda list:

--8<---------------cut here---------------start------------->8---
# timestamp: <2013-01-24 Thu>

* TODO foo
  SCHEDULED: <2013-01-24 Thu>
  
--8<---------------cut here---------------end--------------->8---

and when I construct the agenda, I get the no-heading message; but if I
visit the file, and M-x describe-text-properties RET on the # in the
first line, it correctly says that the face is font-lock-comment-face;
constructing the agenda after that does *not* produce the message.

Are text properties assigned lazily perhaps? If so, they will need to be
somehow forced in this case.

Nick

PS. BTW, can you reproduce this behavior or am I tilting at windmills?

Re: Getting rid of split frame with org-capture

[Nick Dokos]

Thomas Lockney <thomas@lockney.net> wrote:

> I'm attempting to get some code working that should create a new frame
> with *just* org-capture, but when I run it, I keep getting a split
> despite various attempts at running delete-other-windows. I'm running
> on "GNU Emacs 24.0.90.1 (i386-apple-darwin10.8.0, NS
> apple-appkit-1038.36)" so perhaps this is a 24 specific issue. Here's
> the code I've currently got:
> 
> (defadvice org-capture-finalize (after delete-capture-frame activate)
>   "Advise capture-finalize to close the frame if it is the capture frame"
>   (if (equal "capture" (frame-parameter nil 'name))
>       (delete-frame)))
> 
> (defadvice org-capture-destroy (after delete-capture-frame activate)
>   "Advise capture-destroy to close the frame if it is the capture frame"
>   (if (equal "capture" (frame-parameter nil 'name))
>       (delete-frame)))
> 
> (defun make-capture-frame ()
>   "Create a new frame and run org-capture."
>   (interactive)
>   (make-frame '((name . "Capture")
>                 (width . 100)
>                 (height . 15)))
>   (select-frame-by-name "Capture")
>   (delete-other-windows)
>   (org-capture))
> 
> I've also tried this using the org-capture-mode-hook to call
> delete-other-windows and I've tried placing delete-other-windows after
> the call to org-capture (both of those based on solutions I've seen
> posted to this list at various times). Anyone have any clues on this?
> I'm stumped, but I'm also fairly inexperienced at programming emacs.
> 

As I pointed out in my reply to Gregor, org-capture will split the frame,
no matter whether you have a new one or not: you need to modify its innards
to change that behavior.

Aside from that, there is a problem here: you name the frame
"Capture", yet you test (equal "capture" ...) - I presume that's a typo?

Nick