TimeWarrior: Order on the command line

[Thomas Lauf]

Hello Team!

TimeWarrior has a very flexible command line which means I can e.g. tag
an interval by

timew tag @1 foo bar baz

but also like this

timew foo bar baz tag @1
timew foo tag baz @1 bar

which is nice on one hand but leads to ambiguities. What if I have tags
that are identical to TimeWarrior commands (or something else, see TI-55)?

For example

timew start stop @1 tag

would be interpreted as "start tracking with tags 'stop' 'tag'"
(ignoring the id) and not as "tag interval @1 with 'start' 'stop'". The
latter interpretation however is "more right" as it does not ignore the
id...

One reason might be that the CLI identifies arguments by what they are
and not (always) by where they appear. "tag", "stop", "start" are
commands, because they have been registered as commands. So they can
appear anywhere on the command line and the first one wins.

Currently I am somehow inclined to put a "Commands first" rule into
Timewarrior and to make the command line parsing take the command
context more into account (maybe let it fail if it cannot use all
arguments?).

I am highly anticipating the new command definition document...

Regards
Thomas

--
Dr. Thomas Lauf * thoma...@tngtech.com * +49 174 3180 086
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterföhring
Geschäftsführer: Henrik Klagges, Christoph Stock, Dr. Robert Dahlke
Sitz: Unterföhring * Amtsgericht München, HRB 135082

[Dirk Deimeke]

On 2017-04-12 09:34, Thomas Lauf wrote:

Hi Thomas,

> Currently I am somehow inclined to put a "Commands first" rule into
> Timewarrior and to make the command line parsing take the command
> context more into account (maybe let it fail if it cannot use all
> arguments?).

This is a good idea in my opinion.

I second that.

Cheers

Dirk

--
https://d5e.org/

[Tomas Babej]

To me, adopting the order from task seems most consistent, that is:

timew <filter> <command> <args>
timew @1 stop tag.added.at.closing.as.one.of.the.recent.bugs.suggested

Tomas

[Dirk Deimeke]

On 2017-04-12 12:11, Tomas Babej wrote:

Hi Tomas,

> To me, adopting the order from task seems most consistent, that is:
> timew <filter> <command> <args>
> timew @1 stop tag.added.at.closing.as.one.of.the.recent.bugs.suggested

+1

Dirk

--
https://d5e.org/

[Paul Beckingham]

> Currently I am somehow inclined to put a "Commands first" rule into
> Timewarrior and to make the command line parsing take the command
> context more into account (maybe let it fail if it cannot use all
> arguments?).

"Commands first" makes parsing easier. Making parsing easier has not been a priority for Taskwarrior, and instead readability of the command line was considered the goal. For example, both of these are valid for Taskwarrior:

$ task /pattern/ list
$ task list /pattern/

I like supporting both, because I think it allows the user to construct a command that makes most sense in that users native tongue. But that’s Taskwarrior. I could also say that the command line parsing is so strange and difficult, that I’ve rewritten it several times, and have now resorted to creating a dynamic grammar-based parser (rat) to do the job in future releases. I didn’t want to have to do that, but as the concept of a date grows from YYYY-MM-DD and “tomorrow” to more strange things like “Wednesday after Easter”, “next summer”, or “3rd Tuesday in June”, and that of time from HH:MM:SS to “30mins ago”, the cli parsing just gets so much more complex and ambiguous. Consider /usr/bin/ and /from/to/.

Timewarrior does not need to follow the same path, although if we prefer consistency, it should. My original thoughts for Timewarrior were that it is not Taskwarrior, and does not need to be constrained by it.

If Timewarrior follows the same wandering path that Taskwarrior took, then it will have series of releases where sometimes the command line gets more expressive, and others where is gets more restrictive. It would be nice to avoid all those changes.

And here we are. Time to choose. I’m neutral on this topic.


> I am highly anticipating the new command definition document…

Thomas, I think you meant to say “I highly anticipate writing part of the new command definition document”. :-)

Yes this needs to be written, and I imagine it will be the outcome of this conversation, plus a few iterations. The idea was that we should probably develop some guidelines for the command line, and make the individual commands more consistent. The 1.0.0 release command syntax was only partially consistent.

It was also not that user friendly, and we’re beginning to address that now (continue by @id, for example).

We also need to specify whether we can address an interval by its tags, start time, @id, or all of the above. Once that is chosen, the syntax gets a little more well defined.

We will also need to specify whether there metadata in the future, and how it will appear on the command line, even if we don’t implement it now. Also consolidate several commands: tag/untag do not need to be separate; perhaps they should be, perhaps not. Also shorten, lengthen move are all related. Lots to figure out.

P

[Federico Hernandez]

+2

--
You received this message because you are subscribed to the Google Groups "taskwarrior-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taskwarrior-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Federico Hernandez]

I guess I would opt for keeping both tools in sync regarding possibilities on the command line. Just for consistency reasons and making it mentally easier of using both.

/F 

[Thomas Lauf]

Hi Paul!

On 12.04.2017 15:08, Paul Beckingham wrote:
> Thomas, I think you meant to say “I highly anticipate writing part of
> the new command definition document”. :-)
>
> Yes this needs to be written, and I imagine it will be the outcome of
> this conversation, plus a few iterations. The idea was that we
> should probably develop some guidelines for the command line, and
> make the individual commands more consistent. The 1.0.0 release
> command syntax was only partially consistent.
>

Ok, attached is a quick sketch. It is written from my point of view, so
I want to stress out that everything is open for debate.

> We also need to specify whether we can address an interval by its
> tags, start time, @id, or all of the above. Once that is chosen, the
> syntax gets a little more well defined.

Looking at my personal use cases I would address an interval by its id.
Tags can be ambiguous and the start time is mostly more to write (12:03
vs. @4, or 20170301T1330 vs @134) and can be ambiguous too.

I wonder if the :ids hint should be omitted and the summary command
always prints the ids. I rarely use the command without...

> We will also need to specify whether there metadata in the future,
> and how it will appear on the command line, even if we don’t
> implement it now. Also consolidate several commands: tag/untag do
> not need to be separate; perhaps they should be, perhaps not. Also
> shorten, lengthen move are all related. Lots to figure out.

Agreed, let's get it done! :)

Regards,

[Paul Beckingham]

Hi Thomas,

>> Yes this needs to be written, and I imagine it will be the outcome of
>> this conversation, plus a few iterations. The idea was that we
>> should probably develop some guidelines for the command line, and
>> make the individual commands more consistent. The 1.0.0 release
>> command syntax was only partially consistent.
>>
> Ok, attached is a quick sketch. It is written from my point of view, so
> I want to stress out that everything is open for debate.

I have take your rfc file and committed it under the timew.git/doc directory, with a few minor additions from me. This is great, let’s iterate on this until we have what we want. Thanks for getting this started.

P