Goals get automatically ordered by length

[bjornasm]

I have a weird issue where my goals are ordered by increasing time:

>Enter goal ('help' to learn): 10m;1m;10m;1m;loop2

followed by i to show info shows:

  > 1. time: feb. 28, 01:29:01 (pending: 00h 00m 58s), goal: 1m                                                                                 
    2. time: feb. 28, 01:29:01 (pending: 00h 00m 58s), goal: 1m                                                                                 
    3. time: feb. 28, 01:38:01 (pending: 00h 09m 58s), goal: 10m                                                                                
    4. time: feb. 28, 01:38:01 (pending: 00h 09m 58s), goal: 10m                                                                                
       sprint 1/2   

so instead of having several 10m long sprints with 1min inbetweet, it seems to knock off the shortest ones first.

However if I follow the example:

25m;30m;55m;1h;1h25m;1h30m;1h55m;2h25m;loop2

It correctly follows the order from the input, as it is increasing in time:

  > 1. time: feb. 28, 01:54:34 (pending: 00h 24m 58s), goal: 25m                                                                                
    2. time: feb. 28, 01:59:34 (pending: 00h 29m 58s), goal: 30m                                                                                
    3. time: feb. 28, 02:24:34 (pending: 00h 54m 58s), goal: 55m                                                                                
    4. time: feb. 28, 02:29:34 (pending: 00h 59m 58s), goal: 1h                                                                                 
    5. time: feb. 28, 02:54:34 (pending: 01h 24m 58s), goal: 1h25m                                                                              
    6. time: feb. 28, 02:59:34 (pending: 01h 29m 58s), goal: 1h30m                                                                              
    7. time: feb. 28, 03:24:34 (pending: 01h 54m 58s), goal: 1h55m                                                                              
    8. time: feb. 28, 03:54:34 (pending: 02h 24m 58s), goal: 2h25m     

However if I add a shorter time at the end, it ends up to be sorted:
25m;30m;55m;1h;1h25m;1h30m;1h55m;2h25m;25m;loop2

Trial and error

The following input ends up to be sorted by time as well:

 10m;1h;10m;1h;loop2 (mix hours and minutes)
 10m;1m;10m;1m (no loops)
 10m;1m;10m;1m;10m;1m;10m; (longer sequence)
 7m;6m;5m;4m;3m;2m;1m (no recurring sequence)

Have I misunderstood anything?

EDIT:
Seems like its this line responsible for the sorting:

arttime/share/arttime/src/arttime.zsh

Line 1024 in 369f47a

goalarraysorted=("${(o)goalarray[@]}")

I suppose this must be intended and supporting some kind of use case that I don't have (I really cant see how anyone would input these in a different order than what they want) - but maybe there should be a flag to load the time sequences exactly as input?

[poetaman]

Hi again @bjornasm!

Firstly, what you intend to achieve can be achieved with arttime's timer specification syntax. Here's how it will look like:

>Enter goal ('help' to learn): 10m;11m;21m;22m;loop2

instead of

>Enter goal ('help' to learn): 10m;1m;10m;1m;loop2

All the times in a timer specification are considered relative to "now" (current time), that is when the user enters timer spec. What you are expecting is that each time in the list is relative to the previous time. I'll explain below why I chose the former over latter syntax to begin with, but the good news is that I have had plans to enhance timer syntax such that a user can choose either style. The source of misunderstanding is on me, I should add a statement or two in the documentation to clarify that it's an unordered list of times relative to current time.

The design space for time manager is broad, and depends in-part on the UI choice/constraints. With arttime, I made the design choice that timers should be specified as a delimiter separated list of times using shell's line-editor to leverage it's scroll, search, etc features (press g followed by Ctrl-r to search previous goals, or Ctrl-l for menu search). The list can contain absolute times like 4PM or relative times like 10m. The current syntax accepts unordered list of times relative to current time: 10PM; 10m; 3PM; (so sorting is necessary), and we can extend the syntax to accept ordered time where each time is a delta from previous time (where sorting naturally won't be done). Then we can express what you want like with something like this:

>Enter goal ('help' to learn): o 10m; 1m; 10m; 1m; loop2 or o; 10m; 1m; 10m; 1m; loop2.

Am open to other syntax suggestions. One way would be have a different delimiter like:

>Enter goal ('help' to learn): 10m > 1m > 10m > 1m > loop2

Unfortunately most readable delimiters would be taken up by some locale for time specification or require pressing shift on the standard keyboard, making the former syntax extension a better bet. Let me know if you can think of another better syntax for specifying ordered vs unordered.

[bjornasm]

Thank you for a great answer! Does:

>Enter goal ('help' to learn): 10m;11m;21m;22m;loop2

translate to:

>Enter goal ('help' to learn): 10m;11m;21m;22m;32m;33m;43m;44m

(just that I got it right). Maybe something about that the times are all relative to now could be explicitly stated in the documentation (or maybe most people understood that)? Anyways, good to hear that I can use it as I hoped!

Good question regarding the syntax, should a plus sign be avoided due to terminal behavior?

>Enter goal ('help' to learn):10m+1m+10m+1m

Since then we technically have 22 min of timers I think the + sign is quite nice. If not, the o; would also work imo, as it could be inferred as "tomato/pomodoro mode", meaning specifying break length.