[EX-53] task ask

[gothenburgbitfactory]

[EX-53] task ask

[taskwarrior]

Migrated metadata:

Created: 2012-08-21T00:09:48Z
Modified: 2014-07-02T02:47:03Z

[taskwarrior]

David Patrick on 2012-08-23T20:06:39Z says:

task ask is the thin-edge-of-the-wedge of interactivity.

It's most basic usage, task ask with no parameters, would prompt for every field.

The mechanism behind the prompt is an interesting topic for discussion. I think the prompt content is potentially voluminous enough to worry about cluttering the .rc file, so an included ask.prompt.conf file is probably the way to go, and following our existing .rc file conventions. It depends on the chosen software implementation.

That said, imagining the mechanics to be do-able, I'll describe how this feature might become a pillar of taskwarriors interactivity.

Emerging features promise the ability to embed task parameters that can be applied as a group (see VIRTUALS discussion http://taskwarrior.org/boards/6/topics/2414) task ask introduces a chance to indicate "ask the user about this field", with the introduction of a new bit of syntax;

 :?

at run-time, means "prompt the user for this field"

"WAIT" I hear you saying, "you can't use "?" at the shell!"

i know, i know, for use at the cli, the question mark would have to be escaped, like

 :\?

and when a task is added at the CLI, any field can be given a "?" which would be translated as
"this attribute should have a value, and I don't know what it is right now, ask me later".
Those fields would be prime candidates for review.

but when field-values are specified in the rc file, as in VIRTUALS, then the ability to indicate a required/ desired field with an unknown value, like "pri:? proj:? until:?", that would later trigger a verbose prompt for each, will be fantastic.

task ask and the mechanisms behind it could also serve external scripts and proposed features like task review and enhance twshell.

[taskwarrior]

David Patrick on 2012-08-23T20:51:17Z says:

Alright, you've read this far already,
imagine with me that ask has been implemented, and how it might be used in a more advanced way. consider

% tw ask +OVERDUE proj:snafu mod wait:? sched:? due:? until:? annotate reviewed overdue dates

That would start a series of prompts for the date parameters for every overdue task in the Snafu project.
Enter the new value at the prompt, or keep the existing, nul or default values with AND log the action.
bang bang bang, that was quick!

Make the command above into alias review.snafu.overdue and you're good to go!

[taskwarrior]

David Patrick on 2012-08-26T17:17:19Z says:

Whether review ing tasks or projects or time-periods, managing priorities and contexts, or tracking GTD-like plans and goals, the essential back-and-forth of such functions has always been a bit fuzzy and undefined, on purpose.
It has always been agreed and assumed that the level of dialog, the prompts, the input handling, the sequencing of interactivity, would always be out of reach of taskwarrior-core, deliberately. In order to prevent death-by-bloat, more complex interactions have typically been considered candidates for "extensions", and are assumed to be driven by external code run along-side taskwarrior, non-core, the nuts and bolts of interactivity left to External Script authors.

That ain't necessarily so, if we can make interactivity simple enough and generic enough to perform most exchanges with built-in tools.

This particular entry looks to introduce the connection between the concepts task ask and %variables, (Feature #1073) which are a set of "handles" by which the values current %variables can be used in reports and dialogs, and it becoming clear to me how these two Features could be mutually supporting. Let me illustrate with a snippet of a new data element for taskwarrior; the variables.conf file. This file is an exhaustive list of %variables that taskwarrior might use. That is NOT to say that the variables are defined by variables.conf, no, most of them are defined already by tw core process, but interactivity options for each variable can be defined in variables.conf, and that become the basis for the functions of task ask, and supports rich reporting.

Task ask seeks to enable rich interactivity from core elements.
This doesn't mean making task ask do everything, it means being very clear about what it DOES do and what it DOESN'T do.
Instead of inventing a completely new mode of K)ey bindings to d)o A)nything,
ask greatly simplifies the prompt process down to the following;

1. the task ask command can be used like "add" or "mod" but is triggered by the presence of "?" to prompt for the value of any attribute,
   either at the cli (proj:?), as an existing or default value, or from within an alias or a VIRTUAL.

2. To resolve the value of "?", task cross-references the desired field (%project in this case) with the variables.conf file and finds matching entries

 var.%project.desc=the project
 var.%project.ask=What is the project for this task? \n (you can use tab-completion)
 var.%project.shellprompt=proj:>

3. task combines the elements in the twshell, which might look a bit like

 % task ask this is an example task proj:\? pri:l

Taskwarrior shell, use just "quit" to exit 
 What is the project for this task?
   (you can use tab-completion)
   task add this is an example task pri:l proj:>?

notice the last line of that ends with a ">?" that's because it's in the twshell and everything before the ">" is already "loaded" and the cursor sits in over-write mode with the "?" (the just-assigned value) selected. You can enter the real value (by typing, and/or with the help of tab-completion), or clear it with the key or leave it as "?" and just hit and you'll be asked for that value again later.

Instead of the typical d)one, D)elete e)dit or whatever, and associated logic and interactive dialog lunacy, the only actions taken are the display of "ask" text, and the construction of a twshell command-line that serves the function; get the value for "?".
For input, there are no special keybindings (beyond twshell navigation) but as much of the command-line as possible has been filled in, with the cursor positioned logically at the locus of the question. Hitting will list auto-complete options. Hitting will save a new value, if you made changes, or you can leave an existing value (even if it is a "?" or nul) will be followed by the next prompt and the next logically constructed command-string. When the questions posed by that query are answered for that record, the regular task verbosity takes over to save the record, and repeat.

THAT'S IT! core-interactivity DONE!
Combine existing verbosity and proposed in-line calls like "cat" and "echo", and anything is possible.

without binding any new keystrokes, or defining any dialog-specific logic or tests or conditions, or a lick of external code, effective, extensible interactivity could be achieved. There would be no big new usage patterns to learn, and this method just uses and re-enforces existing CLI syntax, twshell use and tab-completion.

• Very- Somewhat simple, totally configurable.

[taskwarrior]

David Patrick on 2012-08-26T20:26:10Z says:

If "task ask" with no attributes will trigger prompts for all attributes of a task record,
and "task ask yetanother task pri:?" will only prompt for the priority:value,
what logic would determine which prompts are triggered ? .. I'm glad I asked ;-)

There seems to be two general conditions under which a prompt would be generated; implicit and explicit.

Implicit use of ask is where any write-command (other than "ask") processes any record with an attribute containing a "?".
At that time, to complete whatever the command was, task will ask in order to obtain the value for that variable, before carrying on.
This is a pro-active and aggressive approach, and will have to be optional behaviour, but the alternative (just explicit use) runs the risk of letting unanswered questions languish as task metadata.

Explicit use is by using the command ask with or without mod in combination with using "?" as the value for an attribute.
In this case, only those fields indicated are "asked", unless NO fields are indicated with "?", in which case ALL fields are "asked" for EXCEPT those fields with other values that are already specified at the command. whew.. does that make sense?

in other words

% tw 142 mod proj:foo

would trigger a prompt only IF any existing attribute of task 142 was value:? (like wait:?)

% tw add sample-task proj:foo due:? until:?

would add the new task with "?" as values for due: and until: to be asked later.

% tw ask sample-task proj:foo due:? until:?

would prompt for the values of due: and until: and add them to new task along with "sample-task proj:foo"

% tw ask +OVERDUE proj:foo mod due:? until:? annotate reviewed overdue dates

Using the ask AND mod command shifts from "add" behaviour to "modify" behaviour,
defining a filter set and fields to ask about, and adding any other mods.
The above command would prompt the user for new due: and until: values, for every project:foo +OVERDUE task,
logging the review as a time-stamped annotation, for each task processed.
It could be called with alias=review.foo.overdue.
(this is actually a model for the core of the review process, including the logging part, obviating reviewed:date)

[taskwarrior]

David Patrick on 2012-08-26T21:58:53Z says:

"?" as default value

Let's say, for the sake of argument, that you felt that most tasks should have a proj: and a pri:,
but you didn't want to assign a specific default value.
In that case, by indicating the default value for those attributes, in .taskrc

default.project=?
default.priority=?

then any time you added a new task, unless you specified those values, you would be prompted for them.

[taskwarrior]

David Patrick on 2013-05-14T02:14:32Z says:

with hooks and scripting, this is an extension, not core

[pbeckingham]

No plans to implement.