org-archive-done

org-archive-done

[nielsgiesen]

How about a function org-archive-done, that archives any tree in the
buffer labelled DONE?

One might refine this to archive trees absolutely done, so that---even
when a heading is labelled DONE---it looks to its subtrees to check
whether they have no label which states the opposite.

Also, I think it only nice/useful for top-level headings, not below.

Perhaps an optional argument could be given as to the time elapsed
since a tree was DONE.

Regards,

Niels Giesen

Re: org-archive-done

[Carsten Dominik]

Yes, I think this would be a good idea.  I'll put it on my list.

- Carsten

On Jun 14, 2006, at 9:52, nielsgiesen@ibbu.nl wrote:

>
> How about a function org-archive-done, that archives any tree in the
> buffer labelled DONE?
>
> One might refine this to archive trees absolutely done, so that---even
> when a heading is labelled DONE---it looks to its subtrees to check
> whether they have no label which states the opposite.
>
> Also, I think it only nice/useful for top-level headings, not below.
>
> Perhaps an optional argument could be given as to the time elapsed
> since a tree was DONE.
>
> Regards,
>
> Niels Giesen
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: org-archive-done

[Daniel J. Sinder]

nielsgiesen@ibbu.nl wrote:
> How about a function org-archive-done, that archives any tree in the
> buffer labelled DONE?
> 
> One might refine this to archive trees absolutely done, so that---even
> when a heading is labelled DONE---it looks to its subtrees to check
> whether they have no label which states the opposite.
> 
> Also, I think it only nice/useful for top-level headings, not below.
> 

I like the idea proposed by Niels, but I'd want to be able to call
it for a tree too, not just the top-level of a whole file.  In other
words, I'd like to prune any chosen tree to archive DONE items under
it.  Perhaps an example is best...

--- .org file before archiving ---
* Tasks
** TODO Task 1
** DONE Task 2
** TODO Project A
*** TODO Task A1
*** DONE Task A2
** DONE Project B
*** DONE Task B1
*** DONE Task B2

--- .org file after archive of top-level tree ---
* Tasks
** TODO Task 1
** TODO Project A
*** TODO Task A1
*** DONE Task A2

--- _archive file after archive of top-level tree ---
* Tasks
** DONE Task 2
** DONE Project B
*** DONE Task B1
*** DONE Task B2

Dan

Re: org-archive-done

[Carsten Dominik]

Hi Daniel,

thanks for taking the time to discuss this through.

On Jun 17, 2006, at 22:47, Daniel J. Sinder wrote:

> OK, so now we've come full circle -- this is very nearly the current 
> behavior, except instead of archiving the whole subtree, it would only 
> archive DONE entries from within the subtree.  I think this is perhaps 
> the best solution (and easiest to implement, right?).

Yes it is, and I think this is what I will implement.

However,..

> I have just one final thought....and it's just a thought because I 
> don't understand how org-mode is implemented....
> What if, instead of archiving *moving* subtrees, it left them in place 
> but *hid* them in a semi-permanent way.  By that I mean, they'd be 
> hidden just like the collapsing org-mode normally does, but they would 
> never expand, unless a special show-archived-subtrees variable was 
> non-nil.

this is a very interesting and original idea!  I really like it.  It 
would mean that subitems that are done remain in place, but don't use 
space on the screen.  I am not sure if I like the term "archiving" for 
this.  "Locking" seems to be better.

The implementation could for example be TAG based:  All subtrees with a 
TAG :LOCKED: will never open when attacked with TAB (visibility 
cycling).  This can be done using org-cycle-hook.

Proof of concept:

(defvar org-locked-subtrees t
   "Non-nil means, allow locked subtrees.")

(defun org-hide-locked-subtrees (state)
   "Re-hide all locked subtrees after a visibility state change."
   (interactive)
   (when (and org-locked-subtrees
              (not (memq state '(overview folded))))
     (save-excursion
       (let* ((globalp (memq state '(contents all)))
              (beg (if globalp (point-min) (point)))
              (end (if globalp (point-max) (org-end-of-subtree) 
(point))))
         (goto-char beg)
         (while (re-search-forward ":LOCKED:" nil t)
           (and (org-on-heading-p) (hide-subtree))
           (org-end-of-subtree))))))

(add-hook 'org-cycle-hook 'org-hide-locked-subtrees 'append)

Then all that is needed is

- an easy way to toggle org-locked-subtrees (to allow looking at
   locked trees occasionally)
- and easy way to toggle the LOCKED tag
- An automatic locker that goes through the subitems of a given
   level N heading, locking all subtrees that do not have any
   open TODO items.

This is great.  I'll do something like this.  Thanks.

- Carsten

> P.S. Thank you very much for org mode.  I find I'm using it more and 
> more:  README files, task lists, etc.  I've recently even impressed my 
> technical leader at work (Qualcomm, San Diego) with how organized I 
> am, mostly due to org-mode.

You're welcome.  I am glad it is so useful.

Re: org-archive-done

[Daniel J. Sinder]

Carsten Dominik wrote:
> On Jun 17, 2006, at 22:47, Daniel J. Sinder wrote:
>> I have just one final thought....and it's just a thought because I 
>> don't understand how org-mode is implemented....
>> What if, instead of archiving *moving* subtrees, it left them in place 
>> but *hid* them in a semi-permanent way.  By that I mean, they'd be 
>> hidden just like the collapsing org-mode normally does, but they would 
>> never expand, unless a special show-archived-subtrees variable was 
>> non-nil.
> 
> this is a very interesting and original idea!  I really like it.  It 
> would mean that subitems that are done remain in place, but don't use 
> space on the screen.  I am not sure if I like the term "archiving" for 
> this.  "Locking" seems to be better.

I'm glad you like this (and that it seems straightforward to 
implement).  My only questions is this:  If locking is an 
alternative (not replacement) to archiving, will locked items also 
be kept out of agendas and exports, like when archiving?  My vote 
would be "yes".

Dan

Re: org-archive-done

[Carsten Dominik]

On Jun 18, 2006, at 9:59, Daniel J. Sinder wrote:

> Carsten Dominik wrote:
>> On Jun 17, 2006, at 22:47, Daniel J. Sinder wrote:
>>> I have just one final thought....and it's just a thought because I 
>>> don't understand how org-mode is implemented....
>>> What if, instead of archiving *moving* subtrees, it left them in 
>>> place but *hid* them in a semi-permanent way.  By that I mean, 
>>> they'd be hidden just like the collapsing org-mode normally does, 
>>> but they would never expand, unless a special show-archived-subtrees 
>>> variable was non-nil.
>> this is a very interesting and original idea!  I really like it.  It 
>> would mean that subitems that are done remain in place, but don't use 
>> space on the screen.  I am not sure if I like the term "archiving" 
>> for this.  "Locking" seems to be better.
>
> I'm glad you like this (and that it seems straightforward to 
> implement).  My only questions is this:  If locking is an alternative 
> (not replacement) to archiving, will locked items also be kept out of 
> agendas and exports, like when archiving?  My vote would be "yes".

OK, good point, this needs a bit more thinking.  Which shifts it past 
the 4.38 release.

Thanks

- Carsten



--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: org-archive-done

[Carsten Dominik]

I have a basic implementation of this.  Would you like to pretest it a 
bit, to get the worst bugs out before I put this out?

- Carsten

On Jun 18, 2006, at 9:59, Daniel J. Sinder wrote:

> Carsten Dominik wrote:
>> On Jun 17, 2006, at 22:47, Daniel J. Sinder wrote:
>>> I have just one final thought....and it's just a thought because I 
>>> don't understand how org-mode is implemented....
>>> What if, instead of archiving *moving* subtrees, it left them in 
>>> place but *hid* them in a semi-permanent way.  By that I mean, 
>>> they'd be hidden just like the collapsing org-mode normally does, 
>>> but they would never expand, unless a special show-archived-subtrees 
>>> variable was non-nil.
>> this is a very interesting and original idea!  I really like it.  It 
>> would mean that subitems that are done remain in place, but don't use 
>> space on the screen.  I am not sure if I like the term "archiving" 
>> for this.  "Locking" seems to be better.
>
> I'm glad you like this (and that it seems straightforward to 
> implement).  My only questions is this:  If locking is an alternative 
> (not replacement) to archiving, will locked items also be kept out of 
> agendas and exports, like when archiving?  My vote would be "yes".
>
> Dan
>
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477