Environment variable with the last added or edited task ID

[DDzwiedziu]

So one could do:

$ task add 'yadda yadda'
Created task 1.
$ echo $TASKLASTTASKID # Or $TASKLASTTASKUUID / $TASKLASTTASKSUUID
1
$ task $TASKLASTTASKID annotate 'bla bla'
Annotating task deadbeef 'yadda yadda'.
Annotated 1 task.

Or adding a last command that would execute commands on that last task.

$ task last annotate 'bla bla'
Annotating task deadbeef 'yadda yadda'.
Annotated 1 task.

Edit: I my mind the last task to be edited this way was the last task modified, yet using add in the first proto-example might suggested that I've meant the last task sorted by ID.

[djmitche]

The first formulation is tricky because task doesn't control the shell's environment. But, the second seems interesting. The hard part is coming up with a shorthand that is not ambiguous. For example, last is a built-in report so task last annotate 'bla bla' runs the last report for tasks containing annotate bla bla.

[smemsh]

So "last" just means the one with highest entry time? hmm, we could use task 0 to mean that maybe? It currently seems to match tasks without an ID. But maybe someone relies on that.

I use timewarrior to get the "last task," as the last one worked on is more interesting than the last one created.

[djmitche]

No, last is a report name. The parser for command-line arguments is pretty quirky. For me task 0 returns nothing, but does seem to parse, whereas

⸩ t -
The expression could not be evaluated.

so maybe - could be a synonym for the largest task index?

[DDzwiedziu]

so maybe - could be a synonym for the largest task index?

I was thinking rather about the last task modified. Maybe using add first in my example-in-spe wasn't the best idea.

And yes, new shorthands are hard, and I don't have good ideas about this, especially for a project that isn't mine (I have bad ones if you want).

[smemsh]

No, last is a report name.

Yep, I meant "what is 'last'" as in, confirming the semantic desired here. It sounds like OP likes it to correspond to modified rather than entry field, and you suggest highest numbered task id... hm, all three could be interesting for someone.

[0 parses but yields nothing, - fails to parse]

I think it's returning ones that got collected. ie ones without an ID. Maybe you never garbage collect?

 $ task 0 export | jq length
396

 $ taskgc

 $ task 0 export | jq length
398

[smemsh]

We might also consider adding a "current task" pointer somewhere. I know we don't really have state currently, there's "context" but that edits config files to store state, which I always thought was not right (it breaks scm of the rcfile, for one...news does this too). There could be a special record in the db (maybe task 0, we could special-case that task number) which stores some state or something.