FR: Using properties to customize global settings on a per-entry basis

FR: Using properties to customize global settings on a per-entry basis

[John Wiegley]

I love using "#+STARTUP: lognotestate" for noting down when and why a task
changes state.

However, I have several tasks which recur daily, or once every two days.  The
size of these tasks is starting to get crazy, since there are empty "DONE"
messages continually accruing.

I'd like either a) an option to disable lognotestate for recurring tasks, or
b) the ability to change the logging state for a particular entry using
properties.

John

Re: FR: Using properties to customize global settings on a per-entry basis

[Carsten Dominik]

On Sep 29, 2007, at 5:50, John Wiegley wrote:

> I love using "#+STARTUP: lognotestate" for noting down when and why a 
> task
> changes state.
>
> However, I have several tasks which recur daily, or once every two 
> days.  The
> size of these tasks is starting to get crazy, since there are empty 
> "DONE"
> messages continually accruing.
>
> I'd like either a) an option to disable lognotestate for recurring 
> tasks, or
> b) the ability to change the logging state for a particular entry using
> properties.

OK, how about a general mechanism like this:  If there is a property
:org-log-done:, it will be used instead of the current value of
org-log-done during TODO state changeing, like

* repetitive entry
   :PROPERTIES:
      :org-log-done: nil
   :END:

This kind of thing could be applied in more contexts - even though we 
will have
to select each context where we like this explicitly - it always needs 
some coding.


- Carsten

Re: FR: Using properties to customize global settings on a per-entry basis

[John Wiegley]

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

> OK, how about a general mechanism like this:  If there is a property
> :org-log-done:, it will be used instead of the current value of
> org-log-done during TODO state changeing, like
>
> * repetitive entry
>   :PROPERTIES:
>      :org-log-done: nil
>   :END:

Sounds like a great way to do it!

John

Re: FR: Using properties to customize global settings on a per-entry basis

[Carsten Dominik]

On Oct 3, 2007, at 19:57, John Wiegley wrote:

> Carsten Dominik <dominik@science.uva.nl> writes:
>
>> OK, how about a general mechanism like this:  If there is a property
>> :org-log-done:, it will be used instead of the current value of
>> org-log-done during TODO state changeing, like
>>
>> * repetitive entry
>>   :PROPERTIES:
>>      :org-log-done: nil
>>   :END:
>
> Sounds like a great way to do it!

The alternative would be a LOGGING property where you could set the same
keywords as in the STARTUP line.  What is better?

- Carsten

Re: FR: Using properties to customize global settings on a per-entry basis

[Bastien]

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

>>> * repetitive entry
>>>   :PROPERTIES:
>>>      :org-log-done: nil
>>>   :END:
>>
>> Sounds like a great way to do it!
>
> The alternative would be a LOGGING property where you could set the same
> keywords as in the STARTUP line.  What is better?

I think using LOGGING is a bit better.  

BTW, this is documented in (info "(Org)In-buffer settings") :

| logging          | record a timestamp when an item is marked DONE      |
| nologging        | don't record when items are marked DONE             |
| lognotedone      | record timestamp and a note when DONE               |
| lognotestate     | record timestamp and a note when TODO state changes |
| logrepeat        | record a note when re-instating a repeating item    |
| nologrepeat      | do not record when re-instating repeating item      |
| lognoteclock-out | record timestamp and a note when clocking out       |

But the docstring of `org-log-done' doesn't mention all these options.

And (info "(Org)Progress Logging") should mention all these option
somewhere, or at least link back to the in-buffer settings back.

-- 
Bastien

Re: FR: Using properties to customize global settings on a per-entry basis

[Carsten Dominik]

On Oct 4, 2007, at 13:24, Bastien wrote:

> Carsten Dominik <dominik@science.uva.nl> writes:
>
>>>> * repetitive entry
>>>>   :PROPERTIES:
>>>>      :org-log-done: nil
>>>>   :END:
>>>
>>> Sounds like a great way to do it!
>>
>> The alternative would be a LOGGING property where you could set the 
>> same
>> keywords as in the STARTUP line.  What is better?
>>
>
> I think using LOGGING is a bit better.

So what do I do?  More votes?

>
> BTW, this is documented in (info "(Org)In-buffer settings") :
>
> | logging          | record a timestamp when an item is marked DONE    
>   |
> | nologging        | don't record when items are marked DONE           
>   |
> | lognotedone      | record timestamp and a note when DONE             
>   |
> | lognotestate     | record timestamp and a note when TODO state 
> changes |
> | logrepeat        | record a note when re-instating a repeating item  
>   |
> | nologrepeat      | do not record when re-instating repeating item    
>   |
> | lognoteclock-out | record timestamp and a note when clocking out     
>   |
>
> But the docstring of `org-log-done' doesn't mention all these options.

logrepeat and nologrepeat actually refer to a different variable, 
org-log-repeat.
I have improved the docs there.

> And (info "(Org)Progress Logging") should mention all these option
> somewhere, or at least link back to the in-buffer settings back.

They are all mentioned now, in the right places.

Thanks.

- Carsten

Re: FR: Using properties to customize global settings on a per-entry basis

[Bastien]

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

>> I think using LOGGING is a bit better.
>
> So what do I do?  More votes?
>
>> | logging          | record a timestamp when an item is marked DONE
>> | nologging        | don't record when items are marked DONE
>> | lognotedone      | record timestamp and a note when DONE
>> | lognotestate     | record timestamp and a note when TODO state
>> | logrepeat        | record a note when re-instating a repeating item
>> | nologrepeat      | do not record when re-instating repeating item
>> | lognoteclock-out | record timestamp and a note when clocking out

Well.. if we can access all these options thru a single :LOGGING:
property, that's another argument for it, no? For instance, using a
property :org-log-done: wouldn't let us use nologrepeat, for example.

-- 
Bastien

Re: FR: Using properties to customize global settings on a per-entry basis

[Rainer Stengele]

Bastien schrieb:
> Carsten Dominik <dominik@science.uva.nl> writes:
> 
>>> I think using LOGGING is a bit better.
>> So what do I do?  More votes?
>>
>>> | logging          | record a timestamp when an item is marked DONE
>>> | nologging        | don't record when items are marked DONE
>>> | lognotedone      | record timestamp and a note when DONE
>>> | lognotestate     | record timestamp and a note when TODO state
>>> | logrepeat        | record a note when re-instating a repeating item
>>> | nologrepeat      | do not record when re-instating repeating item
>>> | lognoteclock-out | record timestamp and a note when clocking out
> 
> Well.. if we can access all these options thru a single :LOGGING:
> property, that's another argument for it, no? For instance, using a
> property :org-log-done: wouldn't let us use nologrepeat, for example.
> 

I'd also like to vote for :LOGGING:

rainer

Re: FR: Using properties to customize global settings on a per-entry basis

[John Wiegley]

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

>> I think using LOGGING is a bit better.
>
> So what do I do?  More votes?

If you want to start using the facility for generally overriding Lisp values,
then your original proposal is better.  But if this is just going to be for a
few exceptions, LOGGING fits much better with the present scheme and docs.

John

Re: FR: Using properties to customize global settings on a per-entry basis

[bzg]

>>> I think using LOGGING is a bit better.
>>
>> So what do I do?  More votes?
>
> If you want to start using the facility for generally overriding Lisp
> values, then your original proposal is better.  But if this is just going
> to be for a few exceptions, LOGGING fits much better with the
> present scheme and docs.

Granted.

But to some respect Org has its own definition of 'options' (like
startup options) and I think it's clearer for users to be offered
to  use these Org options first.

A general mechanism to set org-log-done for each subtree looks
nice, but then the user will be able to mix org-log-done in its
main config, lognotedone in the startup options, and org-log-done
for some trees.  Good for advanced users, maybe slightly confusing
for others.

(I know it's bad practice to speak for "others" so I won't rely/dwell
on this too much... others can speak for themselves!)

-- 
Bastien

Re: FR: Using properties to customize global settings on a per-entry basis

[Carsten Dominik]

On Oct 5, 2007, at 22:34, John Wiegley wrote:

> Carsten Dominik <dominik@science.uva.nl> writes:
>
>>> I think using LOGGING is a bit better.
>>
>> So what do I do?  More votes?
>
> If you want to start using the facility for generally overriding Lisp 
> values,
> then your original proposal is better.  But if this is just going to 
> be for a
> few exceptions, LOGGING fits much better with the present scheme and 
> docs.

Generally overriding Lisp values would be a great feature, but I feel 
that this
implementation seems to promise that you can set any lisp value there.  
This would
lead to a large overhead, because every command would have to locally 
parse
before execution.  Also there would be uncertainties because many 
commands
act on several items etc.
I am not yet convinced that this is useful enough - so for the
time being I will stick with the LOGGING property.

Thanks for all comments!

- Carsten