On Tuesday, November 20, 2012, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net javascript:; writes:
Instead of changing org-hours-to-clocksum-string, it's probably
preferable to make org-minutes-to-clocksum-string more robust, so it
copes correctly with floating point arguments.
On Sat, Nov 17, 2012 at 11:02 AM, Toby Cubitt ts...@cantab.net wrote:
On Sat, Nov 17, 2012 at 03:42:24PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
I've replaced the cons cells with additional plist properties, as you
suggested. The resulting customization ui
On Tue, Nov 20, 2012 at 11:12:10AM -0500, Mike McLean wrote:
On Sat, Nov 17, 2012 at 11:02 AM, Toby Cubitt ts...@cantab.net wrote:
On Sat, Nov 17, 2012 at 03:42:24PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
I've replaced the cons cells with additional plist
Toby Cubitt ts...@cantab.net writes:
Instead of changing org-hours-to-clocksum-string, it's probably
preferable to make org-minutes-to-clocksum-string more robust, so it
copes correctly with floating point arguments.
The attached patch does this. Sorry for letting this slip through.
Toby Cubitt ts...@cantab.net writes:
Here's an updated patch. Now both org-time-clocksum-format and
org-time-clocksum-fractional-format can be plists, as discussed.
That was quick. Thank you.
In the org-time-clocksum-format case, I made the values cons cells which
specify both a format
On Sat, Nov 17, 2012 at 09:48:09AM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
Here's an updated patch. Now both org-time-clocksum-format and
org-time-clocksum-fractional-format can be plists, as discussed.
That was quick. Thank you.
In the
Toby Cubitt ts...@cantab.net writes:
I've replaced the cons cells with additional plist properties, as you
suggested. The resulting customization ui still isn't wonderful in my
opinion. But it does the job, and I'm not sure how much scope there is
for improving it further. If you see a way,
On Sat, Nov 17, 2012 at 03:42:24PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
I've replaced the cons cells with additional plist properties, as you
suggested. The resulting customization ui still isn't wonderful in my
opinion. But it does the job, and I'm not sure
On Wed, Nov 14, 2012 at 05:20:14PM +0100, Toby Cubitt wrote:
On Wed, Nov 14, 2012 at 05:09:38PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
I can easily allow org-time-clocksum-fractional-format to be a list of
formats. But 1d 3.4h doesn't seem very useful to me.
Toby Cubitt ts...@cantab.net writes:
Thanks for your work. Some comments below.
The second patch:
- further extends org-time-clocksum-format to allow separate month and
year components (where a month is taken to be 30 days, a year to be 365
days).
I suggest to add week instead of month,
On Wed, Nov 14, 2012 at 04:04:05PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
Thanks for your work. Some comments below.
The second patch:
- further extends org-time-clocksum-format to allow separate month and
year components (where a month is taken to be 30
Toby Cubitt ts...@cantab.net writes:
I can easily allow org-time-clocksum-fractional-format to be a list of
formats. But 1d 3.4h doesn't seem very useful to me. Probably it should
work a bit differently: format the time as a fractional quantity, using
the largest time unit which will give a
On Wed, Nov 14, 2012 at 05:09:38PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
I can easily allow org-time-clocksum-fractional-format to be a list of
formats. But 1d 3.4h doesn't seem very useful to me. Probably it should
work a bit differently: format the time as a
Attached is a new two-patch series implementing finer-grained control
over the format of clocksum durations (only in overlays and the
mode-line; the format of the CLOCK entries stored in org files remains
unchanged and hard-coded, as before).
The first patch:
- defines a new
Toby Cubitt ts...@cantab.net writes:
Minor point: I would order the format strings minutes, hours, days. In
case we ever want to extend to months or years, that way we can simply
extend the list and it will be completely backwards compatible.
Using a plist can circumvent the problem, too. I'm
On Thu, Nov 08, 2012 at 01:26:48AM +0100, Nicolas Goaziou wrote:
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.
Good. That's what I thought.
Then, I'm fine with format strings.
Toby Cubitt ts...@cantab.net 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-*
On Mon, Nov 05, 2012 at 11:45:24PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
This is not far from your own suggestion to provide different functions
depending on which output is desired, I just happen to think that these
functions would all be so similar that they
Toby Cubitt ts...@cantab.net writes:
I still think functions are the way to go. Three options in the
defcustom:
- One to provide regular time (i.e 14:40 or 3d 18:32)
- One to provide decimal time with the highest unit available (i.e.
18,75 h or 2,5 d).
- One free slot for an
On Tue, Nov 06, 2012 at 11:57:25AM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
I still think functions are the way to go. Three options in the
defcustom:
- One to provide regular time (i.e 14:40 or 3d 18:32)
- One to provide decimal time with the highest
Toby Cubitt ts...@cantab.net writes:
How do I produce the format 5 h 32 min with your defcustom, without
requiring the user to define their own function? (Assuming that 'regular
produces the current default 5:32 format.)
Why without defining their own function? My proposal was to use
On Tue, Nov 06, 2012 at 01:29:02PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
How do I produce the format 5 h 32 min with your defcustom, without
requiring the user to define their own function? (Assuming that 'regular
produces the current default 5:32 format.)
Toby Cubitt ts...@cantab.net 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
Nicolas Goaziou writes:
Again, these are strange and very limiting rules. What if I want to have
5 h 32 min? And 5,3 days?
You provide a format string like you do now.
Achim didn't specify how he conceives the FMT argument.
I thought that's obvious: the canned formats (the ones you'd want to
On Tue, Nov 06, 2012 at 06:41:06PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net 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
Toby Cubitt ts...@cantab.net writes:
I doubt it can be done now, since we already allow user-defined format
strings.
I'm more focused on what we will be able to do.
Where are displayed durations formatted with org-time-clocksum-format et
al. parsed back to a number of minutes in the current
On Tue, Nov 06, 2012 at 07:42:54PM +0100, Achim Gratz wrote:
Nicolas Goaziou writes:
Again, these are strange and very limiting rules. What if I want to have
5 h 32 min? And 5,3 days?
You provide a format string like you do now.
That means if you want a format that's conditional on the
On Tue, Nov 06, 2012 at 08:55:12PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
I doubt it can be done now, since we already allow user-defined format
strings.
I'm more focused on what we will be able to do.
Where are displayed durations formatted with
Toby Cubitt writes:
On Tue, Nov 06, 2012 at 07:42:54PM +0100, Achim Gratz wrote:
Nicolas Goaziou writes:
Again, these are strange and very limiting rules. What if I want to have
5 h 32 min? And 5,3 days?
You provide a format string like you do now.
That means if you want a format that's
Hello,
Toby Cubitt ts...@cantab.net writes:
Personally, I find the time duration 123:15 much harder to parse
mentally than 5d 3:15.
The attached patch adds a new customization option
`org-time-clocksum-days-format'. When non-nil, this is used instead of
`org-time-clocksum-format' for
On Mon, Nov 05, 2012 at 10:14:27AM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
Personally, I find the time duration 123:15 much harder to parse
mentally than 5d 3:15.
The attached patch adds a new customization option
`org-time-clocksum-days-format'. When
Nicolas Goaziou writes:
As you suggest, I think a better plan is to replace all of them with
a single `org-time-clocksum-display-function'. Its expected value would
be a function accepting 2 arguments: hours and minutes, as numbers and
it should return a string.
Actually, it seems an even
On Mon, Nov 05, 2012 at 11:47:12AM +0100, Achim Gratz wrote:
Nicolas Goaziou writes:
As you suggest, I think a better plan is to replace all of them with
a single `org-time-clocksum-display-function'. Its expected value would
be a function accepting 2 arguments: hours and minutes, as
Toby Cubitt writes:
A format string isn't sufficient. It requires the number of time
components (days, hours, minutes, etc.) to be fixed in advance. Whereas a
function can decide whether to display e.g. days+hours or hours+minutes
depending on whether the time is longer or shorter than 24h.
On Mon, Nov 05, 2012 at 12:13:25PM +0100, Achim Gratz wrote:
Toby Cubitt writes:
A format string isn't sufficient. It requires the number of time
components (days, hours, minutes, etc.) to be fixed in advance. Whereas a
function can decide whether to display e.g. days+hours or hours+minutes
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
On Mon, Nov 05, 2012 at 01:20:48PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
[snip]
[...] 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
Hello,
Toby Cubitt ts...@cantab.net writes:
I'd prefer to see some agreement before I waste time coding something
that won't get accepted.
Then let's wait for Achim (Cc'ed) to illustrate what he has in mind,
because his proposal is too vague yet to permit discussion about it.
Regards,
--
Nicolas Goaziou writes:
Then let's wait for Achim (Cc'ed) to illustrate what he has in mind,
because his proposal is too vague yet to permit discussion about it.
What I had in mind was to remove org-time-clocksum-format and replace
the associated format calls with a formatting function that has
On Mon, Nov 05, 2012 at 06:40:20PM +0100, Achim Gratz wrote:
Nicolas Goaziou writes:
Then let's wait for Achim (Cc'ed) to illustrate what he has in mind,
because his proposal is too vague yet to permit discussion about it.
What I had in mind was to remove org-time-clocksum-format and
Toby Cubitt ts...@cantab.net writes:
This is not far from your own suggestion to provide different functions
depending on which output is desired, I just happen to think that these
functions would all be so similar that they should be rolled into a
single function that can produce different
Personally, I find the time duration 123:15 much harder to parse
mentally than 5d 3:15.
The attached patch adds a new customization option
`org-time-clocksum-days-format'. When non-nil, this is used instead of
`org-time-clocksum-format' for clocksum durations longer than 1 day. It
gets passed
42 matches
Mail list logo
