From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [PATCH] Separate clocksum format for durations >= 1 day Date: Thu, 08 Nov 2012 01:26:48 +0100 Message-ID: <87wqxxkkhj.fsf@gmail.com> References: <877gpy7bhb.fsf@gmail.com> <20121106203505.GA7335@c3po> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:59943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWG1R-0005qh-BJ for emacs-orgmode@gnu.org; Wed, 07 Nov 2012 19:31:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TWG1Q-0000Fl-BI for emacs-orgmode@gnu.org; Wed, 07 Nov 2012 19:31:05 -0500 Received: from mail-wi0-f169.google.com ([209.85.212.169]:60071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWG1Q-0000Ff-3E for emacs-orgmode@gnu.org; Wed, 07 Nov 2012 19:31:04 -0500 Received: by mail-wi0-f169.google.com with SMTP id hq4so4735238wib.0 for ; Wed, 07 Nov 2012 16:31:03 -0800 (PST) In-Reply-To: <20121106203505.GA7335@c3po> (Toby Cubitt's message of "Tue, 6 Nov 2012 21:35:05 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Toby Cubitt writes: > But that only needs to parse clock strings stored in properties/drawers, > not the ones displayed in overlays (column view) or in the mode-line. Correct. > Are the clock strings stored in properties/drawers formatted using the > existing org-time-clocksum-* defcustoms? I can't easily tell from the > org-clock.el code... > > The only sane answer ought to be "no" (which doesn't mean that it is ;) > It would clearly be better if the clock strings stored in org buffers > used a single fixed format, which could be mangled as desired for display > in overlays and the mode-line. Format string for clock lines is hard-coded (see line 1493 in org-clock.el), which means we don't have to limit ourselves to parse-able format. Back to point 1. Then, I'm fine with format strings. Following your suggestion, what about the following variables: - one to determine format of data: fractional or regular. - one to determine display format. Its value would be a list of 3 format strings associated to days, hours and minutes. Internally, the duration is computed as a list of three integers or nil if data is regular, or a list of one float and two nil if data is fractional. Format strings from the second variable will be concatenated only when value is non-nil. If no format string is found for a given unit, it's value will be converted into a lesser unit. Examples: | var1 | var2 | internal representation | display | |-------------+-----------------------------+-------------------------+-------------| | 'regular | ("%dd " "%d h " "%d min") | (nil 11 35) | 11 h 35 min | | 'fractional | ("%.2fd" "%.2fh" "%.2fmin") | (nil 11.3 nil) | 11.30h | | 'regular | ("%dd " "%d:" "%02d") | (1 3 5) | 1d 3:05 | | 'regular | (nil "%d:" "%02d") | (1 3 5) | 27:05 | We can extend it to years if needed. Regards, -- Nicolas Goaziou