Hi, I've written a module, that allows flexible notifications for todo items with deadline: http://pmrb.free.fr/work/OS/org-notify.el Feedback is welcome! -- Peter
Peter Münster <pmlists@free.fr> wrote:
> Hi,
>
> I've written a module, that allows flexible notifications for todo items
> with deadline: http://pmrb.free.fr/work/OS/org-notify.el
>
> Feedback is welcome!
>
I've only taken a quick glance, but the question that immediately came
to my mind was: what does this do that appt.el (and its org interface)
does not? Note that I don't know the answer: I just have the
question :-)
BTW, there are some FAQs that address such appointment things (check the
"Appointments/Diary" section of the FAQ). Maybe you can take a look and
then come back and tell us how your package stacks up.
Thanks,
Nick
On Thu, Feb 23 2012, Nick Dokos wrote: > what does this do that appt.el (and its org interface) does not? Sorry, I've totally forgotten to write about my motivation, to create such an org-notify module. Here a summary: - different warning periods for different todo-types - fine grained warning periods (smallest unit is second) - continue notifications, when deadline is overdue - easy modification of timestamps (just one click, to say "let's do it tomorrow") - switch from "todo" to "done" by clicking on the notification window - configurable notification types (email, notifications-notify, beep, etc.) - configurable notification period - configurable notification duration - crescendo notifications (be more aggressive, when time gets closer to deadline) There was a little thread about this subject: http://thread.gmane.org/gmane.emacs.orgmode/48832 Example usage: (org-notify-add 'appt '(:time "-1s" :period "20s" :duration 10 :actions (org-notify-action-message org-notify-action-ding)) '(:time "15m" :period "2m" :duration 100 :actions org-notify-action-notify) '(:time "2h" :period "5m" :actions org-notify-action-message) '(:time "1d" :actions org-notify-action-email)) This means for todo-items with `notify' property set to `appt': 1 day before deadline, send a reminder-email, 2 hours before deadline, start to send messages every 5 minutes, then, 15 minutes before deadline, start to pop up notification windows every 2 minutes. The timeout of the window is set to 100 seconds. Finally, when deadline is overdue, send messages and make noise. -- Peter
Peter Münster <pmlists@free.fr> wrote:
> On Thu, Feb 23 2012, Nick Dokos wrote:
>
> > what does this do that appt.el (and its org interface) does not?
>
> Sorry, I've totally forgotten to write about my motivation, to create
> such an org-notify module.
>
> Here a summary:
> - different warning periods for different todo-types
> - fine grained warning periods (smallest unit is second)
> - continue notifications, when deadline is overdue
> - easy modification of timestamps (just one click, to say
> "let's do it tomorrow")
> - switch from "todo" to "done" by clicking on the notification window
> - configurable notification types (email, notifications-notify, beep,
> etc.)
> - configurable notification period
> - configurable notification duration
> - crescendo notifications (be more aggressive, when time gets closer to
> deadline)
>
> There was a little thread about this subject:
> http://thread.gmane.org/gmane.emacs.orgmode/48832
>
>
> Example usage:
> (org-notify-add 'appt
> '(:time "-1s" :period "20s" :duration 10
> :actions (org-notify-action-message
> org-notify-action-ding))
> '(:time "15m" :period "2m" :duration 100
> :actions org-notify-action-notify)
> '(:time "2h" :period "5m"
> :actions org-notify-action-message)
> '(:time "1d" :actions org-notify-action-email))
>
> This means for todo-items with `notify' property set to `appt': 1 day before
> deadline, send a reminder-email, 2 hours before deadline, start to send
> messages every 5 minutes, then, 15 minutes before deadline, start to pop up
> notification windows every 2 minutes. The timeout of the window is set to
> 100 seconds. Finally, when deadline is overdue, send messages and make
> noise.
>
Thanks! That's very helpful. I'll take a look in my copious (cough!)
spare time.
Nick
=?utf-8?Q?Peter_M=C3=BCnster?= <pmlists@free.fr> wrote:
> On Thu, Feb 23 2012, Nick Dokos wrote:
>
> > what does this do that appt.el (and its org interface) does not?
>
> Sorry, I've totally forgotten to write about my motivation, to create
> such an org-notify module.
>
> Here a summary:
> - different warning periods for different todo-types
> - fine grained warning periods (smallest unit is second)
> - continue notifications, when deadline is overdue
> - easy modification of timestamps (just one click, to say
> "let's do it tomorrow")
> - switch from "todo" to "done" by clicking on the notification window
> - configurable notification types (email, notifications-notify, beep,
> etc.)
> - configurable notification period
> - configurable notification duration
> - crescendo notifications (be more aggressive, when time gets closer to
> deadline)
>
> There was a little thread about this subject:
> http://thread.gmane.org/gmane.emacs.orgmode/48832
>
>
> Example usage:
> (org-notify-add 'appt
> '(:time "-1s" :period "20s" :duration 10
> :actions (org-notify-action-message
> org-notify-action-ding))
> '(:time "15m" :period "2m" :duration 100
> :actions org-notify-action-notify)
> '(:time "2h" :period "5m"
> :actions org-notify-action-message)
> '(:time "1d" :actions org-notify-action-email))
>
> This means for todo-items with `notify' property set to `appt': 1 day before
> deadline, send a reminder-email, 2 hours before deadline, start to send
> messages every 5 minutes, then, 15 minutes before deadline, start to pop up
> notification windows every 2 minutes. The timeout of the window is set to
> 100 seconds. Finally, when deadline is overdue, send messages and make
> noise.
>
A quick first impression: orgntf-process seems expensive. It seems
to take 100% of one core (I've got a quad-core processor) for three or
four seconds every fifty seconds. Unfortunately, the core is the same one
that's running emacs, so emacs stops responding for those three or four
seconds. I have disabled org-notify for now.
Nick
On Sat, Feb 25 2012, Nick Dokos wrote: > A quick first impression: orgntf-process seems expensive. It seems > to take 100% of one core (I've got a quad-core processor) for three or > four seconds every fifty seconds. Unfortunately, the core is the same one > that's running emacs, so emacs stops responding for those three or four > seconds. I have disabled org-notify for now. How many lines do you have in your org-files? (I've about 200 and execution time is about 100ms.) I call now "(org-element-parse-buffer 'heading)", I hope it's faster for you. Is it faster, when the file is byte-compiled? Other ideas: - I could divide orgntf-process into several tasks, so that things run more smoothly. - You could call (org-notify-start -60), so the process will be called, when idle for one minute. The file has a new home: https://github.com/p-m/org-notify There is now `orgntf-verbose' to see execution time of `orgntf-todo-list'. Thanks for testing! -- Peter
Peter Münster <pmlists@free.fr> wrote: > On Sat, Feb 25 2012, Nick Dokos wrote: > > > A quick first impression: orgntf-process seems expensive. It seems > > to take 100% of one core (I've got a quad-core processor) for three or > > four seconds every fifty seconds. Unfortunately, the core is the same one > > that's running emacs, so emacs stops responding for those three or four > > seconds. I have disabled org-notify for now. > > How many lines do you have in your org-files? > (I've about 200 and execution time is about 100ms.) > Roughly 7000 - I just added a task to clean things up, so it's now 7002 :-) > I call now "(org-element-parse-buffer 'heading)", I hope it's faster for > you. Is it faster, when the file is byte-compiled? > > Other ideas: > - I could divide orgntf-process into several tasks, so that things run > more smoothly. > - You could call (org-notify-start -60), so the process will be called, > when idle for one minute. > This sounds promising - I'll try this out in the next iteration. > The file has a new home: https://github.com/p-m/org-notify > There is now `orgntf-verbose' to see execution time of > `orgntf-todo-list'. > OK - I'll try it out when I get a chance. Thanks, Nick
Peter Münster <pmlists@free.fr> wrote:
> On Sat, Feb 25 2012, Nick Dokos wrote:
>
> > A quick first impression: orgntf-process seems expensive. It seems
> > to take 100% of one core (I've got a quad-core processor) for three or
> > four seconds every fifty seconds. Unfortunately, the core is the same one
> > that's running emacs, so emacs stops responding for those three or four
> > seconds. I have disabled org-notify for now.
>
> How many lines do you have in your org-files?
> (I've about 200 and execution time is about 100ms.)
>
> I call now "(org-element-parse-buffer 'heading)", I hope it's faster for
> you. Is it faster, when the file is byte-compiled?
>
> Other ideas:
> - I could divide orgntf-process into several tasks, so that things run
> more smoothly.
> - You could call (org-notify-start -60), so the process will be called,
> when idle for one minute.
>
> The file has a new home: https://github.com/p-m/org-notify
> There is now `orgntf-verbose' to see execution time of
> `orgntf-todo-list'.
>
> Thanks for testing!
Profiling results after byte compiling both org-notify.el and org-element.el
(the rest of org is uncompiled code):
,----
| org-element-parse-elements 891 3.8462059999 0.0043167295
| orgntf-process 1 1.594772 1.594772
| orgntf-time-measure 1 1.594763 1.594763
| orgntf-todo-list 1 1.59444 1.59444
| org-element-parse-buffer 15 1.5755259999 0.1050350666
| org-element-current-element 876 1.5125120000 0.0017266118
| org-element-headline-parser 876 1.4775100000 0.0016866552
| org-entry-properties 1752 0.7201820000 0.0004110627
| org-element-parse-secondary-string 876 0.4682000000 0.0005344748
| org-element-parse-objects 942 0.4317159999 0.0004582972
| org-element-get-next-object-candidates 1151 0.4044249999 0.0003513683
| org-back-to-heading 3504 0.1251230000 3.570...e-05
| org-element-time-stamp-successor 969 0.1206909999 0.0001245521
| org-heading-components 876 0.0532400000 6.077...e-05
| org-element-latex-or-entity-successor 1884 0.0469810000 2.493...e-05
| org-end-of-subtree 876 0.0365460000 4.171...e-05
| org-match-string-no-properties 4167 0.0302490000 7.259...e-06
| org-element-link-successor 998 0.0220160000 2.206...e-05
| org-get-limited-outline-regexp 1676 0.0199100000 1.187...e-05
| org-element-sub/superscript-successor 953 0.0132220000 1.387...e-05
| org-truely-invisible-p 876 0.0127170000 1.451...e-05
| org-get-property-block 876 0.0118430000 1.351...e-05
| org-element-map 15 0.010387 0.0006924666
| org-element-inline-src-block-successor 942 0.0066240000 7.031...e-06
| org-element-text-markup-successor 942 0.0061229999 6.499...e-06
| org-at-heading-p 1767 0.0058330000 3.301...e-06
| org-element-macro-successor 876 0.0053859999 6.148...e-06
| org-get-category 1752 0.0051480000 2.938...e-06
| org-element-link-parser 63 0.0046710000 7.414...e-05
| org-element-inline-babel-call-successor 942 0.0045489999 4.829...e-06
| org-element-statistics-cookie-successor 922 0.0031339999 3.399...e-06
| org-refresh-category-properties 10 0.0029679999 0.0002967999
| org-element-property 5073 0.0028890000 5.694...e-07
| org-skip-whitespace 891 0.0027629999 3.101...e-06
| org-element-radio-target-successor 876 0.0026729999 3.051...e-06
| org-outline-level 876 0.0018010000 2.055...e-06
| org-element-time-stamp-parser 93 0.0016429999 1.766...e-05
| orgntf-make-todo 876 0.0015790000 1.802...e-06
| org-agenda-files 1 0.001418 0.001418
| org-link-unescape 59 0.001049 1.777...e-05
| org-element-type 1752 0.0009170000 5.234...e-07
| org-reduced-level 876 0.0006700000 7.648...e-07
| org-link-expand-abbrev 59 0.0004410000 7.474...e-06
| org-link-unescape-compound 23 0.0003170000 1.378...e-05
| org-element-contents 891 0.0002970000 3.333...e-07
| org-trim 53 0.000235 4.433...e-06
| org-element-statistics-cookie-parser 46 0.0001809999 3.934...e-06
| org-float-time 2 0.000103 5.15e-05
| org-element-subscript-parser 7 6.3e-05 9e-06
| org-char-to-string 23 1.800...e-05 7.826...e-07
| org-no-properties 11 1.6e-05 1.454...e-06
`----
So orgntf-todo-list takes the lion's share of the time but
most of it is the 15 calls to org-element-parse-buffer (I have
15 files in my org-agenda-files list).
BTW, I think the first line of the profile must be a remnant
from before, although I did do an elp-reset-all.
Nick
Hello,
Peter Münster <pmlists@free.fr> writes:
> On Sat, Feb 25 2012, Nick Dokos wrote:
>
>> A quick first impression: orgntf-process seems expensive. It seems
>> to take 100% of one core (I've got a quad-core processor) for three or
>> four seconds every fifty seconds. Unfortunately, the core is the same one
>> that's running emacs, so emacs stops responding for those three or four
>> seconds. I have disabled org-notify for now.
>
> How many lines do you have in your org-files?
> (I've about 200 and execution time is about 100ms.)
>
> I call now "(org-element-parse-buffer 'heading)", I hope it's faster for
> you. Is it faster, when the file is byte-compiled?
I didn't look at the code but you probably mean
(org-element-parse-buffer 'headline) if you're only interested in
headline data.
Regards,
--
Nicolas Goaziou
On Sun, Feb 26 2012, Nick Dokos wrote:
> So orgntf-todo-list takes the lion's share of the time but
> most of it is the 15 calls to org-element-parse-buffer
Ok, then I could process only one file at a time. This would divide the
processing time by 15, in your case. But perhaps others would have the
7000 lines in one file only, then it would not work...
So, it is worth the effort?
Thanks for the profiling!
--
Peter
On Sun, Feb 26 2012, Nicolas Goaziou wrote:
> I didn't look at the code but you probably mean
> (org-element-parse-buffer 'headline) if you're only interested in
> headline data.
Yes, it's "headline" in the code... :)
--
Peter
On Sun, Feb 26 2012, Peter Münster wrote:
> On Sun, Feb 26 2012, Nick Dokos wrote:
>
>> So orgntf-todo-list takes the lion's share of the time but
>> most of it is the 15 calls to org-element-parse-buffer
>
> Ok, then I could process only one file at a time. This would divide the
> processing time by 15, in your case. But perhaps others would have the
> 7000 lines in one file only, then it would not work...
> So, is it worth the effort?
The effort was quite small, so I've done it. :)
--
Peter