emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* FR: Using properties to customize global settings on a per-entry basis
@ 2007-09-29  3:50 John Wiegley
  2007-10-03 13:27 ` Carsten Dominik
  0 siblings, 1 reply; 11+ messages in thread
From: John Wiegley @ 2007-09-29  3:50 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FR: Using properties to customize global settings on a per-entry basis
  2007-09-29  3:50 FR: Using properties to customize global settings on a per-entry basis John Wiegley
@ 2007-10-03 13:27 ` Carsten Dominik
  2007-10-03 17:57   ` John Wiegley
  0 siblings, 1 reply; 11+ messages in thread
From: Carsten Dominik @ 2007-10-03 13:27 UTC (permalink / raw)
  To: John Wiegley; +Cc: emacs-orgmode


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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FR: Using properties to customize global settings on a per-entry basis
  2007-10-03 13:27 ` Carsten Dominik
@ 2007-10-03 17:57   ` John Wiegley
  2007-10-04  7:26     ` Carsten Dominik
  0 siblings, 1 reply; 11+ messages in thread
From: John Wiegley @ 2007-10-03 17:57 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FR: Using properties to customize global settings on a per-entry basis
  2007-10-03 17:57   ` John Wiegley
@ 2007-10-04  7:26     ` Carsten Dominik
  2007-10-04 11:24       ` Bastien
  0 siblings, 1 reply; 11+ messages in thread
From: Carsten Dominik @ 2007-10-04  7:26 UTC (permalink / raw)
  To: John Wiegley; +Cc: emacs-orgmode


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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FR: Using properties to customize global settings on a per-entry basis
  2007-10-04  7:26     ` Carsten Dominik
@ 2007-10-04 11:24       ` Bastien
  2007-10-05  8:02         ` Carsten Dominik
  0 siblings, 1 reply; 11+ messages in thread
From: Bastien @ 2007-10-04 11:24 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FR: Using properties to customize global settings on a per-entry basis
  2007-10-04 11:24       ` Bastien
@ 2007-10-05  8:02         ` Carsten Dominik
  2007-10-05 12:13           ` Bastien
  2007-10-05 20:34           ` John Wiegley
  0 siblings, 2 replies; 11+ messages in thread
From: Carsten Dominik @ 2007-10-05  8:02 UTC (permalink / raw)
  To: Bastien; +Cc: org-mode list


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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FR: Using properties to customize global settings on a per-entry basis
  2007-10-05  8:02         ` Carsten Dominik
@ 2007-10-05 12:13           ` Bastien
  2007-10-05 12:28             ` Rainer Stengele
  2007-10-05 20:34           ` John Wiegley
  1 sibling, 1 reply; 11+ messages in thread
From: Bastien @ 2007-10-05 12:13 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FR: Using properties to customize global settings on a per-entry basis
  2007-10-05 12:13           ` Bastien
@ 2007-10-05 12:28             ` Rainer Stengele
  0 siblings, 0 replies; 11+ messages in thread
From: Rainer Stengele @ 2007-10-05 12:28 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FR: Using properties to customize global settings on a per-entry basis
  2007-10-05  8:02         ` Carsten Dominik
  2007-10-05 12:13           ` Bastien
@ 2007-10-05 20:34           ` John Wiegley
  2007-10-06  3:06             ` bzg
  2007-10-06  6:52             ` Carsten Dominik
  1 sibling, 2 replies; 11+ messages in thread
From: John Wiegley @ 2007-10-05 20:34 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FR: Using properties to customize global settings on a per-entry basis
  2007-10-05 20:34           ` John Wiegley
@ 2007-10-06  3:06             ` bzg
  2007-10-06  6:52             ` Carsten Dominik
  1 sibling, 0 replies; 11+ messages in thread
From: bzg @ 2007-10-06  3:06 UTC (permalink / raw)
  To: John Wiegley; +Cc: emacs-orgmode

>>> 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FR: Using properties to customize global settings on a per-entry basis
  2007-10-05 20:34           ` John Wiegley
  2007-10-06  3:06             ` bzg
@ 2007-10-06  6:52             ` Carsten Dominik
  1 sibling, 0 replies; 11+ messages in thread
From: Carsten Dominik @ 2007-10-06  6:52 UTC (permalink / raw)
  To: John Wiegley; +Cc: emacs-orgmode


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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2007-10-06  7:03 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-29  3:50 FR: Using properties to customize global settings on a per-entry basis John Wiegley
2007-10-03 13:27 ` Carsten Dominik
2007-10-03 17:57   ` John Wiegley
2007-10-04  7:26     ` Carsten Dominik
2007-10-04 11:24       ` Bastien
2007-10-05  8:02         ` Carsten Dominik
2007-10-05 12:13           ` Bastien
2007-10-05 12:28             ` Rainer Stengele
2007-10-05 20:34           ` John Wiegley
2007-10-06  3:06             ` bzg
2007-10-06  6:52             ` Carsten Dominik

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).