From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel J. Sinder" Subject: Re: org-archive-done Date: Sun, 18 Jun 2006 00:59:18 -0700 Message-ID: <449507D6.3040703@gmail.com> References: <874pyomawm.fsf@ibbu.nl> <4491EAC7.7080304@gmail.com> <44933E3A.9010100@gmail.com> <44946A6F.7020508@gmail.com> <94a84102394ede474f74017dc38b3f6b@science.uva.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FrsBq-00043E-QO for emacs-orgmode@gnu.org; Sun, 18 Jun 2006 03:59:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FrsBo-000432-5R for emacs-orgmode@gnu.org; Sun, 18 Jun 2006 03:59:25 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FrsBn-00042z-VR for emacs-orgmode@gnu.org; Sun, 18 Jun 2006 03:59:24 -0400 Received: from [208.97.132.118] (helo=randymail-a1.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FrsLp-0004lE-JZ for emacs-orgmode@gnu.org; Sun, 18 Jun 2006 04:09:45 -0400 In-Reply-To: <94a84102394ede474f74017dc38b3f6b@science.uva.nl> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: emacs-orgmode 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