Org-mode Habit with Varying Description

Org-mode Habit with Varying Description

[Daya Atapattu]

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

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

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

Re: Org-mode Habit with Varying Description

[Bastien]

Hi Daya,

Daya Atapattu <atapattud@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: Org-mode Habit with Varying Description

[Daya Atapattu]

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

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 <bzg@gnu.org> wrote:

> Hi Daya,
>
> Daya Atapattu <atapattud@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
>

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

Re: Org-mode Habit with Varying Description

[Jorge A. Alfaro-Murillo]

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: Org-mode Habit with Varying Description

[Pete Ley]

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: Org-mode Habit with Varying Description

[Melleus]

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: Org-mode Habit with Varying Description

[Brady Trainor]

Daya Atapattu <atapattud@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: Org-mode Habit with Varying Description

[Eric Abrahamsen]

Pete Ley <peteley11235@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

Re: Org-mode Habit with Varying Description

[Samuel Loury]

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

Hi,
Eric Abrahamsen <eric@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

[-- Attachment #2: Type: application/pgp-signature, Size: 472 bytes --]

Re: Org-mode Habit with Varying Description

[Michael Brand]

Hi Daya

On Mon, Oct 20, 2014 at 4:33 PM, Daya Atapattu <atapattud@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" (YYYY 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 YYYY) 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: Org-mode Habit with Varying Description

[Eric Abrahamsen]

Samuel Loury <konubinix@gmail.com> writes:

> Hi,
> Eric Abrahamsen <eric@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

Re: Org-mode Habit with Varying Description

[Pete Ley]

> 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: Org-mode Habit with Varying Description

[Eric Abrahamsen]

Pete Ley <peteley11235@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: Org-mode Habit with Varying Description

[Nicolas Goaziou]

Hello,

Eric Abrahamsen <eric@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: Org-mode Habit with Varying Description

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Eric Abrahamsen <eric@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: Org-mode Habit with Varying Description

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Eric Abrahamsen <eric@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: Org-mode Habit with Varying Description

[Nicolas Goaziou]

Eric Abrahamsen <eric@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: Org-mode Habit with Varying Description

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Eric Abrahamsen <eric@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: Org-mode Habit with Varying Description

[Nicolas Goaziou]

Eric Abrahamsen <eric@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