From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: [c]ompute property value ? Date: Mon, 16 Jul 2007 11:30:21 +0200 Message-ID: <87myxwn1aq.fsf@bzg.ath.cx> References: <87644m1ned.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IAMuU-0003DR-PT for emacs-orgmode@gnu.org; Mon, 16 Jul 2007 05:30:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IAMuS-0003D3-6y for emacs-orgmode@gnu.org; Mon, 16 Jul 2007 05:30:30 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IAMuS-0003D0-21 for emacs-orgmode@gnu.org; Mon, 16 Jul 2007 05:30:28 -0400 Received: from hu-out-0506.google.com ([72.14.214.224]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IAMuR-0000IK-Lk for emacs-orgmode@gnu.org; Mon, 16 Jul 2007 05:30:27 -0400 Received: by hu-out-0506.google.com with SMTP id 23so455258huc for ; Mon, 16 Jul 2007 02:30:26 -0700 (PDT) In-Reply-To: (Carsten Dominik's message of "Mon\, 16 Jul 2007 08\:50\:05 +0200") 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: emacs-orgmode@gnu.org Carsten Dominik writes: > The problem is that the summary type is a property of the > column view format, not of the property itself. Yes, i inferred that from the fact that the summary type is automatically updated when changing the property value from the column view. > So it is not entirely obvious how and with what scope this command > should be interpreted - even though I think we should have it. So far as C-c C-x C-c does the updating job by computing the summary, i guess we just need a function that replaces the values of the properties when they exist (in parent and children). Such a function should be interactive and might called by `write-file-hooks'. > Another issue is that even though column view show the summary values, > they are not by default inserted into the properties list of the > parent node. If the parent node does have the property, its value > is updated. If it does not have it, the property will not > be added. I thought this would be useful to avoid the property > drawer filling with stuff you might not want there. Very right. > So for the summing command you propose, we need to decide > how to handle this question. Maybe with a prefix > argument, force the creation of the property in the parent > nodes? A prefix argument sounds good to me. Certainly all these questions are not #1 priority. As you said, proprities are new and it might be wise to wait for more people to interact with them... Cheers, -- Bastien