Modify both start and end time in same command?

[sebastiancarlos]

Currently, the signature of modify is:

timew modify (start|end) <id> <date>

So, to change the start and end, you need to issue two commands:

$ timew modify start @1 <date>
$ timew modify end @1 <date>

Another command, track, already has a way of setting both start and end at the same time, but it creates a new interval:

timew track <range> <tags>

So, how about adding a new form of the modify command that allows setting both the start and end of an existing interval?

timew modify (start|end) <id> <date>
timew modify <id> <range>

[lauft]

@sebastiancarlos Good idea! 👍🏻

I added a new sub-command range to the modify command for this, while I was implementing something related:

timew modify range <id> <range>

You can have a look at it in 👉🏻 branch feature/sub-commands

Note that this implementation will now modify the designated interval into an open interval if only a single datetime (and not a range) is given, i.e.

timew modify range @1 <datetime>

is possible and converts interval @1 into an open interval, starting at <datetime>. Not that I use that all the time, but it might be a valid use case...

I was also thinking about making range the default sub-command, i.e. enabling timew modify @1 <range> as you proposed, but this would then mean that timew modify bogus @1 <range> would be treated the same. One might accept this, or add a feature to the CLI checking for unconsumed command line arguments (like bogus) to have an error message in this case.

A nice side effect of the implementation is that the modify command now searches for the sub-command, which means you can now also do e.g.

timew modify <id> start <datetime>

i.e. the sub-command does not need to immediately follow the command.

[sebastiancarlos]

@lauft Sounds great, thanks! I'll give it a try.

I was also thinking about making range the default sub-command, i.e. enabling timew modify @1 <range> as you proposed, but this would then mean that timew modify bogus @1 <range> would be treated the same. One might accept this, or add a feature to the CLI checking for unconsumed command line arguments (like bogus) to have an error message in this case.

I’m not familiar with the codebase, but my suggestion would be:

• Making range the default sub-command, which I think is an improvement even if bogus arguments will be ignored.
• Eventually, enhancing the CLI to notify users about unrecognized arguments all across the board.

Thanks again!