Re: [O] Org-mode Habit with Varying Description
Eric Abrahamsen e...@ericabrahamsen.net writes: Okay, thanks. Since this is part of a function, I guess I should assume the (progn... behavior above, assume `org-element-at-point' is going to return a paragraph, and then work up from there to see if I'm in a log-list. Is that right? That's the idea, yes. Regards, -- Nicolas Goaziou
Re: [O] Org-mode Habit with Varying Description
Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: Right now it looks like the central cond statement in `org-add-log-setup' is as close as we've got to a canonical definition of where a heading's log list is to be found. Should I just write my own version of this, or would you be open to refactoring `org-add-log-setup' so the finding part is a separate function that can be reused elsewhere? Done, as `org-log-beginning'. Note that it will return a non-nil value even if there is no log list in the entry. Regards, -- Nicolas Goaziou
Re: [O] Org-mode Habit with Varying Description
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: Right now it looks like the central cond statement in `org-add-log-setup' is as close as we've got to a canonical definition of where a heading's log list is to be found. Should I just write my own version of this, or would you be open to refactoring `org-add-log-setup' so the finding part is a separate function that can be reused elsewhere? Done, as `org-log-beginning'. Note that it will return a non-nil value even if there is no log list in the entry. Very cool, thanks a lot! Eric
Re: [O] Org-mode Habit with Varying Description
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: Right now it looks like the central cond statement in `org-add-log-setup' is as close as we've got to a canonical definition of where a heading's log list is to be found. Should I just write my own version of this, or would you be open to refactoring `org-add-log-setup' so the finding part is a separate function that can be reused elsewhere? Done, as `org-log-beginning'. Note that it will return a non-nil value even if there is no log list in the entry. I was just fooling with this a bit, and am noticing some odd (to me) behavior. If I start with emacs -Q, then (goto-char (org-log-beginning)) takes me to the start of a :LOGBOOK: drawer, and (org-element-at-point) returns the drawer. That works no matter whether the log drawer is folded or not. But if the headline is folded, (org-element-at-point) returns the headline. Starting emacs with my usual customizations, it's even weirder than that. If I start with the subtree visible but the log drawer folded, then this (starting with point in the middle of the headline): (progn (goto-char (org-log-beginning)) (org-element-at-point)) Gives me paragraph. But eval'ing the two lines above consecutively (without the progn), gives me the drawer. If the logbook drawer is unfolded, I get paragraph every time. Anyway, I don't know what the expected behavior is, and I don't know how outline visibility is supposed to impact document parsing. But this seems strange... All I've customized is: (setq org-log-into-drawer t) Thanks, eric
Re: [O] Org-mode Habit with Varying Description
Eric Abrahamsen e...@ericabrahamsen.net writes: I was just fooling with this a bit, and am noticing some odd (to me) behavior. If I start with emacs -Q, then (goto-char (org-log-beginning)) takes me to the start of a :LOGBOOK: drawer, and (org-element-at-point) returns the drawer. That works no matter whether the log drawer is folded or not. But if the headline is folded, (org-element-at-point) returns the headline. Starting emacs with my usual customizations, it's even weirder than that. If I start with the subtree visible but the log drawer folded, then this (starting with point in the middle of the headline): (progn (goto-char (org-log-beginning)) (org-element-at-point)) Gives me paragraph. But eval'ing the two lines above consecutively (without the progn), gives me the drawer. If the logbook drawer is unfolded, I get paragraph every time. Anyway, I don't know what the expected behavior is, and I don't know how outline visibility is supposed to impact document parsing. But this seems strange... All I've customized is: (setq org-log-into-drawer t) This is unrelated to `org-log-beginning'. Point cannot be left in an invisible area. E.g., the same applies to (forward-line 2) (point) vs (progn (forward-line 2) (point)) Anyway, that's a red herring. Regards, -- Nicolas Goaziou
Re: [O] Org-mode Habit with Varying Description
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Eric Abrahamsen e...@ericabrahamsen.net writes: I was just fooling with this a bit, and am noticing some odd (to me) behavior. If I start with emacs -Q, then (goto-char (org-log-beginning)) takes me to the start of a :LOGBOOK: drawer, and (org-element-at-point) returns the drawer. That works no matter whether the log drawer is folded or not. But if the headline is folded, (org-element-at-point) returns the headline. Starting emacs with my usual customizations, it's even weirder than that. If I start with the subtree visible but the log drawer folded, then this (starting with point in the middle of the headline): (progn (goto-char (org-log-beginning)) (org-element-at-point)) Gives me paragraph. But eval'ing the two lines above consecutively (without the progn), gives me the drawer. If the logbook drawer is unfolded, I get paragraph every time. Anyway, I don't know what the expected behavior is, and I don't know how outline visibility is supposed to impact document parsing. But this seems strange... All I've customized is: (setq org-log-into-drawer t) This is unrelated to `org-log-beginning'. Point cannot be left in an invisible area. E.g., the same applies to (forward-line 2) (point) vs (progn (forward-line 2) (point)) Anyway, that's a red herring. Okay, thanks. Since this is part of a function, I guess I should assume the (progn... behavior above, assume `org-element-at-point' is going to return a paragraph, and then work up from there to see if I'm in a log-list. Is that right? Eric
Re: [O] Org-mode Habit with Varying Description
Pete Ley peteley11...@gmail.com writes: All I've got now are a function that finds the logbook, and another that parses the log items and normalizes them: extracts the TODO states/timestamps/key-values and sets them as properties on the items themselves. Then you've got a pretty good basis from which to do reporting. Hooking into note-taking and todo state-change logging to prompt for values should be easy. I don't know yet how to approach the reporting part, mostly because I haven't sat down and thought about how this would be most useful. It will also require reading org-clock and org-habit in detail -- clearly reporting to a table like they do is the right way to go. How to get the most out of the data? I was thinking of having COLUMN_FORMULA and TABLE_FORMULA properties on the heading. When you report from the heading, each key in the logbook data creates a table column. Each column formula property creates another column, populated by that formula (presumably calculated from the data columns). Then the table formula gets slapped on to the bottom of it, and the whole thing runs. So if you had a heading like this: * TODO Anneal galoshes :LOGBOOK: GALOSHES: 15; CLOCK: [2014-10-15 Wed 09:07]--[2014-10-15 Wed 17:10] = 8:03 GALOSHES: 13; CLOCK: [2014-10-14 Tue 08:50]--[2014-10-14 Tue 16:30] = 7:40 GALOSHES: 14; CLOCK: [2014-10-13 Mon 09:30]--[2014-10-13 Mon 17:06] = 7:36 :END: You'd end up with a table with two data columns. Then you could have a COLUMN_FORMULA property that created a third column, displaying galoshes annealed per hour. And a TABLE_FORMULA property that did... something... with all that information. In a sense, it's a bit like column view, except using logbook data rather than property values. This sounds pretty great. I'd like to see the functions you have anyway, seems like something the community might find useful. I know I could find a few use cases for it. Hmm, the underlying code has changed since I started working on this. Nicolas, can I ask your advice here? I need to rewrite an earlier function which returned a heading's log list, or returned nil. I'd be happy with a function that returned the starting point of the log list, or nil. Right now it looks like the central cond statement in `org-add-log-setup' is as close as we've got to a canonical definition of where a heading's log list is to be found. Should I just write my own version of this, or would you be open to refactoring `org-add-log-setup' so the finding part is a separate function that can be reused elsewhere? Thanks, Eric
Re: [O] Org-mode Habit with Varying Description
All I've got now are a function that finds the logbook, and another that parses the log items and normalizes them: extracts the TODO states/timestamps/key-values and sets them as properties on the items themselves. Then you've got a pretty good basis from which to do reporting. Hooking into note-taking and todo state-change logging to prompt for values should be easy. I don't know yet how to approach the reporting part, mostly because I haven't sat down and thought about how this would be most useful. It will also require reading org-clock and org-habit in detail -- clearly reporting to a table like they do is the right way to go. How to get the most out of the data? I was thinking of having COLUMN_FORMULA and TABLE_FORMULA properties on the heading. When you report from the heading, each key in the logbook data creates a table column. Each column formula property creates another column, populated by that formula (presumably calculated from the data columns). Then the table formula gets slapped on to the bottom of it, and the whole thing runs. So if you had a heading like this: * TODO Anneal galoshes :LOGBOOK: GALOSHES: 15; CLOCK: [2014-10-15 Wed 09:07]--[2014-10-15 Wed 17:10] = 8:03 GALOSHES: 13; CLOCK: [2014-10-14 Tue 08:50]--[2014-10-14 Tue 16:30] = 7:40 GALOSHES: 14; CLOCK: [2014-10-13 Mon 09:30]--[2014-10-13 Mon 17:06] = 7:36 :END: You'd end up with a table with two data columns. Then you could have a COLUMN_FORMULA property that created a third column, displaying galoshes annealed per hour. And a TABLE_FORMULA property that did... something... with all that information. In a sense, it's a bit like column view, except using logbook data rather than property values. This sounds pretty great. I'd like to see the functions you have anyway, seems like something the community might find useful. I know I could find a few use cases for it.
Re: [O] Org-mode Habit with Varying Description
Hi, Eric Abrahamsen e...@ericabrahamsen.net writes: I've been (very gradually) working on something I'm calling org-log, for just this sort of situation -- a library that would possibly go underneath org-habit and maybe even org-clock. It would look like: * Read book :LOGBOOK: - Note taken on [2014-10-20 Mon 10:33] \\ PAGES: 49 - Note taken on [2014-10-20 Mon 10:32] \\ PAGES: 150 :END: When adding notes (or state-change log notes) the user would be prompted to record values for the key(s) already existing in the logbook (in this case, PAGES). Multiple key-value pairs would be possible. Generic tables could be created for a heading, with more specialized tables with user-defined column formulas and all that. Add unit manipulation/calculation from the calc-units package, and I think this could be a nice extension to Org. I originally started thinking of this while translating a novel. I had a certain number of characters to translate, and a certain deadline. What I wanted was a single heading where I logged my progress, and a reporting facility that said given today's date and how many characters you've already done, you'll need to average XXX characters per day to hit the deadline. I envisioned a gnuplot table that showed actual-characters-per-day against the shifting average-characters-per-day. That is a very interesting idea. Do you think we could see your actual work? -- Konubinix GPG Key: 7439106A Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A pgpfBBpIgK_2X.pgp Description: PGP signature
Re: [O] Org-mode Habit with Varying Description
Hi Daya On Mon, Oct 20, 2014 at 4:33 PM, Daya Atapattu atapat...@gmail.com wrote: I like to schedule studying a book: It would be scheduled as Read pages 100-125. Then the next day it should read Read pages 126-150. The description of the habit varies; org-mode picks that up sequentially from a list. Once I was using this simple solution for a continuous burn down task, adapted to your example: * Burn down %%(when (and (not (org-date 2014 10 20)) (calendar-date-equal date (calendar-current-date))) (message Read book until page %d 19:00 (* 25 (- (calendar-absolute-from-gregorian date) (calendar-absolute-from-gregorian '(10 15 2014)) Note that %%( has to start on the first column and that the rest could be moved partially or as a whole into a function call for easier maintenance. 19:00 is an optional time of day. 2014 10 20 ( MM DD) is a poor man's DONE (which I use mainly for diary-float) and has to be set manually to today after the part of today has been done to let the task disappear from the agenda view of today. 10 15 2014 (MM DD ) is the start date. Can also be used as an end date for a countdown by swapping the subtraction operands. calendar-date-equal is used to show it only for the day of today in an agenda view showing also tomorrow etc. Instead of using the number to print with %d it can easily be used to do a lookup in a variable containing a list of whatever which can not be computed directly like e. g. the headings of the book chapters. Inspired by Worg Add sunrise/sunset times to the agenda, currently http://orgmode.org/worg/org-hacks.html#sec-2-10 Michael
Re: [O] Org-mode Habit with Varying Description
Samuel Loury konubi...@gmail.com writes: Hi, Eric Abrahamsen e...@ericabrahamsen.net writes: I've been (very gradually) working on something I'm calling org-log, for just this sort of situation -- a library that would possibly go underneath org-habit and maybe even org-clock. It would look like: * Read book :LOGBOOK: - Note taken on [2014-10-20 Mon 10:33] \\ PAGES: 49 - Note taken on [2014-10-20 Mon 10:32] \\ PAGES: 150 :END: When adding notes (or state-change log notes) the user would be prompted to record values for the key(s) already existing in the logbook (in this case, PAGES). Multiple key-value pairs would be possible. Generic tables could be created for a heading, with more specialized tables with user-defined column formulas and all that. Add unit manipulation/calculation from the calc-units package, and I think this could be a nice extension to Org. I originally started thinking of this while translating a novel. I had a certain number of characters to translate, and a certain deadline. What I wanted was a single heading where I logged my progress, and a reporting facility that said given today's date and how many characters you've already done, you'll need to average XXX characters per day to hit the deadline. I envisioned a gnuplot table that showed actual-characters-per-day against the shifting average-characters-per-day. That is a very interesting idea. Do you think we could see your actual work? Actual work?! Perhaps I gave the wrong impression :) All I've got now are a function that finds the logbook, and another that parses the log items and normalizes them: extracts the TODO states/timestamps/key-values and sets them as properties on the items themselves. Then you've got a pretty good basis from which to do reporting. Hooking into note-taking and todo state-change logging to prompt for values should be easy. I don't know yet how to approach the reporting part, mostly because I haven't sat down and thought about how this would be most useful. It will also require reading org-clock and org-habit in detail -- clearly reporting to a table like they do is the right way to go. How to get the most out of the data? I was thinking of having COLUMN_FORMULA and TABLE_FORMULA properties on the heading. When you report from the heading, each key in the logbook data creates a table column. Each column formula property creates another column, populated by that formula (presumably calculated from the data columns). Then the table formula gets slapped on to the bottom of it, and the whole thing runs. So if you had a heading like this: * TODO Anneal galoshes :LOGBOOK: GALOSHES: 15; CLOCK: [2014-10-15 Wed 09:07]--[2014-10-15 Wed 17:10] = 8:03 GALOSHES: 13; CLOCK: [2014-10-14 Tue 08:50]--[2014-10-14 Tue 16:30] = 7:40 GALOSHES: 14; CLOCK: [2014-10-13 Mon 09:30]--[2014-10-13 Mon 17:06] = 7:36 :END: You'd end up with a table with two data columns. Then you could have a COLUMN_FORMULA property that created a third column, displaying galoshes annealed per hour. And a TABLE_FORMULA property that did... something... with all that information. In a sense, it's a bit like column view, except using logbook data rather than property values. I'm just thinking out loud -- I'm probably not the right one to make this as useful as it can be. But I don't see any reason why we shouldn't do this! Eric
[O] Org-mode Habit with Varying Description
Is there a way to create a habit that picks-up the description from a list? I like to schedule studying a book: It would be scheduled as Read pages 100-125. Then the next day it should read Read pages 126-150. The description of the habit varies; org-mode picks that up sequentially from a list. Is that possible? Regards, - Daya
Re: [O] Org-mode Habit with Varying Description
Hi Daya, Daya Atapattu atapat...@gmail.com writes: Is there a way to create a habit that picks-up the description from a list? I like to schedule studying a book: It would be scheduled as Read pages 100-125. Then the next day it should read Read pages 126-150. The description of the habit varies; org-mode picks that up sequentially from a list. Is that possible? No. Also, a habit with a varying description is not really a habit anymore. You really have several recurring tasks, each is different. -- Bastien
Re: [O] Org-mode Habit with Varying Description
Thanks for the response, Bastien. I guess, short of writing some elisp code, I will have to reschedule each evening for next day.I can't schedule in advance, because I miss some days. - Daya On Mon, Oct 20, 2014 at 10:52 AM, Bastien b...@gnu.org wrote: Hi Daya, Daya Atapattu atapat...@gmail.com writes: Is there a way to create a habit that picks-up the description from a list? I like to schedule studying a book: It would be scheduled as Read pages 100-125. Then the next day it should read Read pages 126-150. The description of the habit varies; org-mode picks that up sequentially from a list. Is that possible? No. Also, a habit with a varying description is not really a habit anymore. You really have several recurring tasks, each is different. -- Bastien
Re: [O] Org-mode Habit with Varying Description
Daya Atapattu writes: Is there a way to create a habit that picks-up the description from a list? I like to schedule studying a book: It would be scheduled as Read pages 100-125. Then the next day it should read Read pages 126-150. The description of the habit varies; org-mode picks that up sequentially from a list. Maybe you want to take a look at TODO dependencies (info (org) TODO dependencies) set `org-enforce-todo-dependencies' to t, and do something like #+BEGIN_EXAMPLE * TODO Read book :PROPERTIES: :ORDERED: t :END: ** TODO Pages 1-150 ** TODO Pages 151-300 #+END_EXAMPLE Then when closing one of the sub headlines, schedule the next one. Best, -- Jorge.
Re: [O] Org-mode Habit with Varying Description
As Bastien said, this doesn't really fit the idea of a habit, but I think there is a reasonable non-elisp way of tweaking it to fit. Maybe it would help. What if you had something like this: * Read book :LOGBOOK: - Note taken on [2014-10-20 Mon 10:33] \\ 151-300 - Note taken on [2014-10-20 Mon 10:32] \\ 1-150 :END: :PROPERTIES: :STYLE:habit :END: I do this sometimes for things like this. The heading doesn't need to change as it can just be a reminder to read book and you can keep track of what you've read in the notes with C-c C-z. Optionally, if you have multiple books and you're reading different amounts of each one each day, you can just write how much you plan to read under the heading for each one, e.g. * Read book 100 pages each day * Read book 2 50 pages each day
Re: [O] Org-mode Habit with Varying Description
Why don't you set your habit as a read 25 pages and use a piece of paper or some card as a bookmark to remember where you finished? E-book readers provide the functionality of remembering where you stopped last time as I know. The title of the book is written on the book itself and e-book readers always open the last one so no need to remember it.
Re: [O] Org-mode Habit with Varying Description
Daya Atapattu atapat...@gmail.com writes: Is there a way to create a habit that picks-up the description from a list? I like to schedule studying a book: It would be scheduled as Read pages 100-125. Then the next day it should read Read pages 126-150. The description of the habit varies; org-mode picks that up sequentially from a list. Is that possible? Regards, - Daya I was scheduling all my TODOs for the day and using agenda view to clock my progress through them. But I've been skimming once again through org-mode users' descriptions of how they use org-mode, and one mentioned only to use scheduling for things like appointments. So my advice will step around your use of habits, although I do this without recently haing adopted org-habits into my workflow, so maybe I am missing something. So instead of scheduling, I would have you tag these headlines, or similarly set them under a tree with a CATEGORY, and simly toggle their TODO state as you want to work on them. Here is an example of a custom-command: #+BEGIN_SRC emacs-lisp (setq org-agenda-custom-commands '((B Books ((tags-todo -nofilter)) ((org-agenda-category-filter-preset '(+read)) ;; or ;; (org-agenda-tags-filter-preset '(+read)) )) #+END_SRC So if you think you will keep the reading notes in a few concentrated places, then CATEGORY should do, whereas if you think you would have related headlines strewn about, the tag-filter may be better. Here is an example org-file: #+BEGIN_SRC org #+TODO: TODO(t) NEXT | DONE #+TAGS: read(r) other * book reading :PROPERTIES: :CATEGORY: read :VISIBILITY: children :END: ** DONE pages 100-125 :read: ** NEXT pages 125-150 :read: ** TODO pages 150-175 :read: #+END_SRC If you'd like to experiment with an additional agenda view for clocking, try #+BEGIN_SRC emacs-lisp (agenda (org-agenda-span 'day) (org-agenda-log-mode-items '(closed clock state)) (org-agenda-start-with-log-mode t) (org-agenda-skip-scheduled-if-done t)) #+END_SRC You may want to tweak so that you can get a view of total clocked or just a view of those days where you read. It's not org-habits, but it could still potentially show you your progress in way that can motivate. -- Brady
Re: [O] Org-mode Habit with Varying Description
Pete Ley peteley11...@gmail.com writes: As Bastien said, this doesn't really fit the idea of a habit, but I think there is a reasonable non-elisp way of tweaking it to fit. Maybe it would help. What if you had something like this: * Read book :LOGBOOK: - Note taken on [2014-10-20 Mon 10:33] \\ 151-300 - Note taken on [2014-10-20 Mon 10:32] \\ 1-150 :END: :PROPERTIES: :STYLE:habit :END: I've been (very gradually) working on something I'm calling org-log, for just this sort of situation -- a library that would possibly go underneath org-habit and maybe even org-clock. It would look like: * Read book :LOGBOOK: - Note taken on [2014-10-20 Mon 10:33] \\ PAGES: 49 - Note taken on [2014-10-20 Mon 10:32] \\ PAGES: 150 :END: When adding notes (or state-change log notes) the user would be prompted to record values for the key(s) already existing in the logbook (in this case, PAGES). Multiple key-value pairs would be possible. Generic tables could be created for a heading, with more specialized tables with user-defined column formulas and all that. Add unit manipulation/calculation from the calc-units package, and I think this could be a nice extension to Org. I originally started thinking of this while translating a novel. I had a certain number of characters to translate, and a certain deadline. What I wanted was a single heading where I logged my progress, and a reporting facility that said given today's date and how many characters you've already done, you'll need to average XXX characters per day to hit the deadline. I envisioned a gnuplot table that showed actual-characters-per-day against the shifting average-characters-per-day. I didn't make my deadline. I don't blame Org for that, but I think I would have stood a better chance if org-log existed. :) Eric I do this sometimes for things like this. The heading doesn't need to change as it can just be a reminder to read book and you can keep track of what you've read in the notes with C-c C-z. Optionally, if you have multiple books and you're reading different amounts of each one each day, you can just write how much you plan to read under the heading for each one, e.g. * Read book 100 pages each day * Read book 2 50 pages each day
