Incompatible change in latest push

Incompatible change in latest push

[Carsten Dominik]

Hi,

after a request, I just added a new variable
`org-log-state-notes-insert-after-drawers' with default nil.
This means that state change notes are now by default
inserted again *before* any drawers.  This was the
original behavior, which changed temporarily in version 6.08.

Sorry for the unsteadyness.

- Carsten

Re: Incompatible change in latest push

[James TD Smith]

Hi Carsten,

On 2008-10-16 06:55:02(+0200), Carsten Dominik wrote:
> Hi,
>
> after a request, I just added a new variable
> `org-log-state-notes-insert-after-drawers' with default nil.
> This means that state change notes are now by default
> inserted again *before* any drawers.  This was the
> original behaviour, which changed temporarily in version 6.08.

I'm trying to figure out why anyone would want this behaviour. I first noticed
it when the clock and properties drawers in some of my org entries seemed to
disappear. After working out what was going on I decided it was a bug and wrote
a patch to fix it.

It makes no sense to me for the drawers in an entry to be swallowed up by state
change notes. The drawers are not part of the entry, not the note, and should
remain outside of the note. While having the drawers in the notes does not stop
org from finding them, it does mean that you can't tell at a glance if an entry
has clocked times or properties set as the relevant drawers will be hidden in
one of the notes and not visible when the entry is first opened.

For example, say you have a task as below:

,----
| * TODO Test
|   SCHEDULED: <2008-10-16 Wed +1d>
|   :PROPERTIES:
|   :LOGGING:  lognoterepeat
|   :EFFORT:   2:00
|   :OtherProperty: fish
|   :END:
`----

When the entry is initially opened it appear as below:

,----
| * TODO Test
|   SCHEDULED: <2008-10-16 Wed +1d>
|   :PROPERTIES:...
`----

If filing notes before drawers is enabled, the first time this is marked done
the properties drawer will be included in the note, so the next time the user
looks at it they will see this:

,----
| * TODO Test
|   SCHEDULED: <2008-10-17 Wed +1d>
|   - State "DONE"       [2008-10-16 Thu 10:45]...
`----
 
I imagine new org users will find it confusing when adding a note to an entry
makes their drawers appear to vanish. It confused me and I've been using org for
quite a while.

I have no problem with keeping this a configurable option so anyone who wants
the old behaviour can have it, but I think the default should be t.

James

--
|-<James TD Smith>-<email/ahktenzero@mohorovi.cc>-|

Re: Incompatible change in latest push

[Carsten Dominik]

Hi James,


If I follow your example, this is what I get:

* TODO Test
   SCHEDULED: <2008-10-17 Fri +1d>
   - State "DONE"       [2008-10-16 Thu 13:14]
   :PROPERTIES:
   :LOGGING:  lognoterepeat
   :EFFORT:   2:00
   :OtherProperty: fish
   :END:


which looks OK to me.  The property drawer is not part of the item,
because it is indented like the bullet itself.

I guess what you are referring to might be this:  Do you have set
org-cycle-include-plain-lists?  Then indeed, if you fold
the note item with TAB, the property drawer disappears under
the item.  This is a "bug" in the implementation of plain list
folding which really should only extend to the end of the item.
However, the implementation currently used simply makes the
plain list item an outline heading just like a line starting
with stars.

Is this what you are referring to, or do I misunderstand?

- Carsten

On Oct 16, 2008, at 12:02 PM, James TD Smith wrote:

> Hi Carsten,
>
> On 2008-10-16 06:55:02(+0200), Carsten Dominik wrote:
>> Hi,
>>
>> after a request, I just added a new variable
>> `org-log-state-notes-insert-after-drawers' with default nil.
>> This means that state change notes are now by default
>> inserted again *before* any drawers.  This was the
>> original behaviour, which changed temporarily in version 6.08.
>
> I'm trying to figure out why anyone would want this behaviour. I  
> first noticed
> it when the clock and properties drawers in some of my org entries  
> seemed to
> disappear. After working out what was going on I decided it was a  
> bug and wrote
> a patch to fix it.
>
> It makes no sense to me for the drawers in an entry to be swallowed  
> up by state
> change notes. The drawers are not part of the entry, not the note,  
> and should
> remain outside of the note. While having the drawers in the notes  
> does not stop
> org from finding them, it does mean that you can't tell at a glance  
> if an entry
> has clocked times or properties set as the relevant drawers will be  
> hidden in
> one of the notes and not visible when the entry is first opened.
>
> For example, say you have a task as below:
>
> ,----
> | * TODO Test
> |   SCHEDULED: <2008-10-16 Wed +1d>
> |   :PROPERTIES:
> |   :LOGGING:  lognoterepeat
> |   :EFFORT:   2:00
> |   :OtherProperty: fish
> |   :END:
> `----
>
> When the entry is initially opened it appear as below:
>
> ,----
> | * TODO Test
> |   SCHEDULED: <2008-10-16 Wed +1d>
> |   :PROPERTIES:...
> `----
>
> If filing notes before drawers is enabled, the first time this is  
> marked done
> the properties drawer will be included in the note, so the next time  
> the user
> looks at it they will see this:
>
> ,----
> | * TODO Test
> |   SCHEDULED: <2008-10-17 Wed +1d>
> |   - State "DONE"       [2008-10-16 Thu 10:45]...
> `----
>
> I imagine new org users will find it confusing when adding a note to  
> an entry
> makes their drawers appear to vanish. It confused me and I've been  
> using org for
> quite a while.
>
> I have no problem with keeping this a configurable option so anyone  
> who wants
> the old behaviour can have it, but I think the default should be t.
>
> James
>
> --
> |-<James TD Smith>-<email/ahktenzero@mohorovi.cc>-|
>
>
>
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Incompatible change in latest push

[Bernt Hansen]

Thanks for restoring the old behaviour.

This was confusing me a bit -- I have lots of tasks where the clock
drawer is way down in the body of the task after lots of repeated 'DONE'
notes (for some of my cyclic tasks).  I was used to the latest DONE note
being at the top and all of a sudden it looked to me like the logging of
the repeated task stopped working - but in fact the entry was placed
after my :CLOCK: drawer somewhere in the middle of the task and was much
harder to find.

There is no rule that I'm aware of that the drawer needs to be at the
top of the task.  My drawers have moved down for some tasks over the
years because other things were inserted at the top of the task by org
during regular note taking.

I do not have org-cycle-include-plain-lists set.

I want the latest state change note at the top of the task. When I set
a task to WAITING and enter some note with the reason for it waiting
it's easy to find the reason when opening the task during my weekly
review.

Thanks for explaining this :)

Regards,
Bernt (no longer confused)


Carsten Dominik <dominik@science.uva.nl> writes:

> Hi James,
>
>
> If I follow your example, this is what I get:
>
> * TODO Test
>   SCHEDULED: <2008-10-17 Fri +1d>
>   - State "DONE"       [2008-10-16 Thu 13:14]
>   :PROPERTIES:
>   :LOGGING:  lognoterepeat
>   :EFFORT:   2:00
>   :OtherProperty: fish
>   :END:
>
>
> which looks OK to me.  The property drawer is not part of the item,
> because it is indented like the bullet itself.
>
> I guess what you are referring to might be this:  Do you have set
> org-cycle-include-plain-lists?  Then indeed, if you fold
> the note item with TAB, the property drawer disappears under
> the item.  This is a "bug" in the implementation of plain list
> folding which really should only extend to the end of the item.
> However, the implementation currently used simply makes the
> plain list item an outline heading just like a line starting
> with stars.
>
> Is this what you are referring to, or do I misunderstand?
>
> - Carsten
>
> On Oct 16, 2008, at 12:02 PM, James TD Smith wrote:
>
>> Hi Carsten,
>>
>> On 2008-10-16 06:55:02(+0200), Carsten Dominik wrote:
>>> Hi,
>>>
>>> after a request, I just added a new variable
>>> `org-log-state-notes-insert-after-drawers' with default nil.
>>> This means that state change notes are now by default
>>> inserted again *before* any drawers.  This was the
>>> original behaviour, which changed temporarily in version 6.08.
>>
>> I'm trying to figure out why anyone would want this behaviour. I
>> first noticed
>> it when the clock and properties drawers in some of my org entries
>> seemed to
>> disappear. After working out what was going on I decided it was a
>> bug and wrote
>> a patch to fix it.
>>
>> It makes no sense to me for the drawers in an entry to be swallowed
>> up by state
>> change notes. The drawers are not part of the entry, not the note,
>> and should
>> remain outside of the note. While having the drawers in the notes
>> does not stop
>> org from finding them, it does mean that you can't tell at a glance
>> if an entry
>> has clocked times or properties set as the relevant drawers will be
>> hidden in
>> one of the notes and not visible when the entry is first opened.
>>
>> For example, say you have a task as below:
>>
>> ,----
>> | * TODO Test
>> |   SCHEDULED: <2008-10-16 Wed +1d>
>> |   :PROPERTIES:
>> |   :LOGGING:  lognoterepeat
>> |   :EFFORT:   2:00
>> |   :OtherProperty: fish
>> |   :END:
>> `----
>>
>> When the entry is initially opened it appear as below:
>>
>> ,----
>> | * TODO Test
>> |   SCHEDULED: <2008-10-16 Wed +1d>
>> |   :PROPERTIES:...
>> `----
>>
>> If filing notes before drawers is enabled, the first time this is
>> marked done
>> the properties drawer will be included in the note, so the next time
>> the user
>> looks at it they will see this:
>>
>> ,----
>> | * TODO Test
>> |   SCHEDULED: <2008-10-17 Wed +1d>
>> |   - State "DONE"       [2008-10-16 Thu 10:45]...
>> `----
>>
>> I imagine new org users will find it confusing when adding a note to
>> an entry
>> makes their drawers appear to vanish. It confused me and I've been
>> using org for
>> quite a while.
>>
>> I have no problem with keeping this a configurable option so anyone
>> who wants
>> the old behaviour can have it, but I think the default should be t.
>>
>> James
>>
>> --
>> |-<James TD Smith>-<email/ahktenzero@mohorovi.cc>-|
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Remember: use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Incompatible change in latest push

[James TD Smith]

On 2008-10-16 08:28:29(-0400), Bernt Hansen wrote:
> Thanks for restoring the old behaviour.
> 
> This was confusing me a bit -- I have lots of tasks where the clock
> drawer is way down in the body of the task after lots of repeated 'DONE'
> notes (for some of my cyclic tasks).  I was used to the latest DONE note
> being at the top and all of a sudden it looked to me like the logging of
> the repeated task stopped working - but in fact the entry was placed
> after my :CLOCK: drawer somewhere in the middle of the task and was much
> harder to find.

Ah, I didn't think of that. Sorry. I had been manually moving my drawers back to
the top of the entry since I noticed them moving. Adding the note after the
CLOCK drawer when the drawer is not at the start of the entry is completely
wrong; the note insertion code should only skip drawers if they are immediately
after the scheduling keywords. 

I'll work on a patch which will fix this.

> There is no rule that I'm aware of that the drawer needs to be at the
> top of the task.  My drawers have moved down for some tasks over the
> years because other things were inserted at the top of the task by org
> during regular note taking.

I'm not so much concerned with the drawers being at the top of the entry as
their being in a well-defined place in it. Org inserts them at the start of the
entry, so I'm used to them being there, and as I have
`org-cycle-include-plain-lists' set, it prevents them from being hidden. 

Isn't it inconvenient having the clock drawer somewhere in the middle of an
entry, for example if you want to adjust clock times? 

James

--
|-<James TD Smith>-<email/ahktenzero@mohorovi.cc>-|
 

Re: Re: Incompatible change in latest push

[Carsten Dominik]

On Oct 16, 2008, at 4:23 PM, James TD Smith wrote:

> On 2008-10-16 08:28:29(-0400), Bernt Hansen wrote:
>> Thanks for restoring the old behaviour.
>>
>> This was confusing me a bit -- I have lots of tasks where the clock
>> drawer is way down in the body of the task after lots of repeated  
>> 'DONE'
>> notes (for some of my cyclic tasks).  I was used to the latest DONE  
>> note
>> being at the top and all of a sudden it looked to me like the  
>> logging of
>> the repeated task stopped working - but in fact the entry was placed
>> after my :CLOCK: drawer somewhere in the middle of the task and was  
>> much
>> harder to find.
>
> Ah, I didn't think of that. Sorry. I had been manually moving my  
> drawers back to
> the top of the entry since I noticed them moving. Adding the note  
> after the
> CLOCK drawer when the drawer is not at the start of the entry is  
> completely
> wrong; the note insertion code should only skip drawers if they are  
> immediately
> after the scheduling keywords.


This sounds like a reasonable proposal, and I would
accept a patch that interpretes the new variable in this way.  I will  
then
also reconsider the default setting, not sure what is the best way yet.

- Carsten

Re: Re: Incompatible change in latest push

[Sebastian Rose]

James TD Smith wrote:
> I'm not so much concerned with the drawers being at the top of the entry as
> their being in a well-defined place in it.

I agree. I use custom drawers as well, placed somewhere in the text
of a note (e.g. :EMAIL:, :REMAIL: contain the mail traffic with my
customer concerning the particular task) and prefer to have the
'standard' drawers on top. That is, the only well-defined place in an
entry - well, and the end.

But it's just a matter of taste IMO and I'm fine with the configurable
variable `org-log-state-notes-insert-after-drawers'. I'll set it to `t'.


Cheers,

  Sebastian

Re: Incompatible change in latest push

[Bernt Hansen]

James TD Smith <ahktenzero@mohorovi.cc> writes:

> On 2008-10-16 08:28:29(-0400), Bernt Hansen wrote:
>> There is no rule that I'm aware of that the drawer needs to be at the
>> top of the task.  My drawers have moved down for some tasks over the
>> years because other things were inserted at the top of the task by org
>> during regular note taking.
>
> I'm not so much concerned with the drawers being at the top of the entry as
> their being in a well-defined place in it. Org inserts them at the start of the
> entry, so I'm used to them being there, and as I have
> `org-cycle-include-plain-lists' set, it prevents them from being
> hidden. 

Requiring the entries to be in a well-defined place isn't going to work
well for people who edit org files outside of Emacs (unless you can
handle the case when the drawers are not in the correct place).  Org
files are just plain text and you can (I don't) edit thing with whatever
tools you like.

>
> Isn't it inconvenient having the clock drawer somewhere in the middle of an
> entry, for example if you want to adjust clock times? 

Not at all.  I rarely actually open the clock drawers.  From a clock
line in the agenda I can go directly to the clock entry inside the
drawer and it's just a convenience for me that the clock entries are all
nicely tucked away in the clock drawer.  I don't really care where the
drawer is physically in the task.  I use the clock data for clock
reports (mostly in the agenda with 'R')

The problem is the clock drawer is created sometime later after the task
is created.  Exactly when (or if) the clock drawer is created is
controlled by a variable org-clock-into-drawer (with a default of 2
meaning create the clock drawer when the 2nd clock line is created)

If you have a new task and clock it in you get a clock line by default
(not in a clock drawer).  Then if you change the state of the task with
logging that goes in front of the clock line... then the next time you
clock in that task it creates the clock drawer to include both clock
lines.  In this case the task looks like this:

Example:

- create new org file with test task

,----[ test.org ]
| * TODO New Task
`----

- clock in the task
- change task to waiting (enter note)
- clock out task
- clock in the task again (creates clock drawer)
- change task to TODO
- change task to DONE
- clock out task

(I have org-log-states-order-reversed set true so the most recent is at
the top.)

,----[ test.org ]
| * DONE New task
|   CLOSED: [2008-10-16 Thu 11:23]
|   - State "DONE"       [2008-10-16 Thu 11:23]
|   - State "TODO"       [2008-10-16 Thu 11:23]
|   - State "WAITING"    [2008-10-16 Thu 11:22] \\
|     for something
|     :CLOCK:
|     CLOCK: [2008-10-16 Thu 11:22]--[2008-10-16 Thu 11:23] =>  0:01
|   CLOCK: [2008-10-16 Thu 11:20]--[2008-10-16 Thu 11:22] =>  0:02
|   :END:
| 
`----

-Bernt