Morgan Smith writes:
> ... The current logic simply looks at the previous '(+
> org-habit-preceding-days org-habit-following-days)' log records which by
> default would be 28. First of all, why are we looking into the future
> at all? I don't think the habits graph currently supports looking
Ihor Radchenko writes:
>
> I am not against such feature. However, using clocking will break an
> assumption that a single log record corresponds to a single habit
> completion. This assumption is implied across org-habit code.
>
Oh that's a good point. I'll have to go back through the code
Morgan Smith writes:
> The second patch allows a habit to be considered done if time was logged
> to it. Imagine you have an org habit like shaving. Chances are, if you
> spend time doing it, it's done. I like to set LOGGING to nil for these
> kinds of habits since it's redundant to have all
> Morgan Smith writes:
> Hello,
> Colin Baxter writes:
>> Please do not alter the default behaviour. When writing a paper
>> or a book I use and need both logging and state changes, and I
>> would prefer not to have to spend time changing my setup.
> Don't worry,
Hello,
Colin Baxter writes:
> Please do not alter the default behaviour. When writing a paper or a
> book I use and need both logging and state changes, and I would prefer
> not to have to spend time changing my setup.
Don't worry, this shouldn't change the default behavior in the
slightest.
> Morgan Smith writes:
> Hello! There are two patches here. The first one is a simple bug
> fix that doesn't really have anything to do with the second patch.
> It just happens to be in the same spot of the code.
> The second patch allows a habit to be considered done if
Hello!
There are two patches here. The first one is a simple bug fix that
doesn't really have anything to do with the second patch. It just
happens to be in the same spot of the code.
The second patch allows a habit to be considered done if time was logged
to it. Imagine you have an org habit
