Hello, Toby Cubitt <ts...@cantab.net> writes:
> Looking through the code, it seems the clocksum format options are used > in two places: org-colview.el and org-clock.el. For some reason, only the > latter honours `org-time-clocksum-use-fractional'. In my patch, only the > former honoured the new `org-time-clocksum-days-format'. Some > rationalisation of all these options is clearly needed. That's the purpose of the patch: only one function to rule them all. > Most users are probably happy with the defaults. So the question is how > best to allow the small minority who want to tweak the clocksum format to > do so. Allow a free function and provide default ones. > A couple of questions: > > 1. Is there any real need to allow the org-colview and org-clock formats > to be customized independently? Making them the same would simplify > things and probably be clearer for users. I think they should be formatted the same way. It's important to have a consistent format for such things. > 2. What are the different formats that users are likely to want? The list > can't be very long. I can think of: "hh:mm", "hh.mm" (fractional), > "dd hh:mm" (separate days), "dd hh.mm", and possibly "MM dd hh:mm" and > "YY MM dd hh:mm". Just provide what is actually possible to have along with your day count. It will make a good enough default offer. > If the above covers everything we want, then what about getting rid of > every customization option except `org-time-clocksum-format', and parsing > the format string itself to decide how many and what arguments to pass to > it? > > More precisely, if the format string contains ":", "." or "," then the > smallest time component is minutes; otherwise it's hours. Pass as many > time components as necessary to fill all the "%" expandos in the format > string, from largest to smallest, with either hours or minutes as the > smallest. If the format string contains "." or "," then pass the number > of minutes as a fraction ("," is used as the decimal separator in many > European languages). That would be over-engineering it. > This would simplify things, and make the format string just "do the right > thing" in all the cases I listed above. On the other hand, it won't allow > unusual formats that don't fit the above scheme (but they're not possible > now, anyway). > > Thoughts? I think it's too much complicated: it requires to know about strange formatting rules. I suggest to keep it simple: just specify a function with fixed arguments to do the job and provide default functions to handle most common cases. Regards, -- Nicolas Goaziou