From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toby Cubitt Subject: Re: [PATCH] Separate clocksum format for durations >= 1 day Date: Tue, 6 Nov 2012 20:26:45 +0100 Message-ID: <20121106192645.GA9405@c3po> References: <87k3ty7hot.fsf@gmail.com> Reply-To: Toby Cubitt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([208.118.235.92]:55647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TVonE-0005h5-M3 for emacs-orgmode@gnu.org; Tue, 06 Nov 2012 14:26:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TVon8-0007gz-1k for emacs-orgmode@gnu.org; Tue, 06 Nov 2012 14:26:36 -0500 Received: from sanddollar.geekisp.com ([216.168.135.167]:31080) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1TVon7-0007gj-SZ for emacs-orgmode@gnu.org; Tue, 06 Nov 2012 14:26:29 -0500 Content-Disposition: inline In-Reply-To: <87k3ty7hot.fsf@gmail.com> 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 On Tue, Nov 06, 2012 at 06:41:06PM +0100, Nicolas Goaziou wrote: > Toby Cubitt writes: > > > 4. We replace the existing muddle with two defcustoms, one selecting > > regular or decimal (or user-defined function), and one specifying a > > list of standard format strings that the function can choose between, > > depending on the duration. > > > > No custom format required, no format string parsing required. > > I'm talking about the other parsing: from the displayed duration to > a number of minutes. It cannot be done if we allow user-defined > functions. I doubt it can be done now, since we already allow user-defined format strings. Where are displayed durations formatted with org-time-clocksum-format et al. parsed back to a number of minutes in the current code? If there is anywhere, it's surely broken because a user-supplied `org-time-clocksum-format' or `org-time-clocksum-fractional-format' could already format the duration in arbitrarily bizarre ways as things are currently. > Also, I'd rather have one defcustom than two for a simple thing like > duration display. There are currently three, four with my original patch. Reducing this to two whilst simultaneously increasing customizability and ensuring a uniform format doesn't seem so bad :) We're trying to allow two fundamentally different things here: 1. Change the values that are computed and displayed (e.g. condition on < 1 day vs. >= 1 day; use fractional minutes or not). 2. Customize the way those values are formatted ("3:15" vs. "3h 15min"). It seems fairly natural to separate these into two defcustoms, rather than try to somehow mash two rather different types of customization into one. The same logic was presumably lurking behind the separation of org-time-clocksum-use-fractional and org-time-clocksum-[fractional-]format. If we want to allow the kind of flexibility you were proposing, then pre-canned options (or user-defined function) are a good fit to 1. and format strings are the natural choice for 2. If all we want to do is allow the existing regular or fractional formats to be conditioned on the duration, a 100% backwards-compatible alternative could be to allow org-time-clocksum-[fractional-]format to be either a single format string (as currently) or a list of format strings. In the latter case, the first element would be used for durations < 1 day, the second for durations >= 1 day (extending to months/years/decades in the obvious way if desired). The benefits of this over my original patch are: (a) it avoids introducing any new defcustoms or changing the existing ones in a backwards-incompatibility way; (b) it could easily be generalised if desired (now or in future) to condition the format on further duration ranges. The disadvantages are: (i) it doesn't have the flexibility of user-defined format functions; (ii) it doesn't simplify the existing defcustoms. > So, I still suggest to provide an unique, although conditional, display > for duration. If you still want to allow customization, make sure it can > be parsed back (or better, provide the parser). I'm not fundamentally > against format strings. You mean abandon any sort of customizable format string (since that inherently can't be parsed back in general), and use a hard-coded conditional "hh:mm" or "dd hh:mm" format? (Possibly retaining one customisation option, org-time-clocksum-use-fractional, to switch this to "hh.mm" or "dd hh.mm"?) That would give me the format I want, but it's a feature regression. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: tsc25@cantab.net web: www.dr-qubit.org