nocejo / trev

Taskwarrior tasks reviewing script
Other
14 stars 1 forks source link

"pre-loading" prompt: in rc setting #36

Closed linuxcaffe closed 9 years ago

linuxcaffe commented 9 years ago

This idea comes up in considering reviewing a required field, like

review.require-project.filter=+PENDING project.none:
...

with the idea that a user requires tasks to have a project, and is reviewing all tasks that don't have a project assigned, in order to quickly remedy that.

How should a user quickly add a project? It can't be done with "+" or "-" so the user can enter

trev> mod project:something

but what if, for this particular review, text could be "pre-loaded" at the prompt, as in rc setting:

review.require-project.prompt='trev> mod project:'

so that any text following ">" is pre-entered, as though the user had typed it in. The user then only needs to plunk in a value "foo", hit and the next task comes up. If the user doesn't enter a value, then the command 'mod project:' would be issued, which would, in this case, change nothing. (assigning no project to a task with no project) If a user want to do something else to the task in focus, in the middle of a require-project review, then they can backspace over the pre-loaded text, and take some other action, as usual.

nocejo commented 9 years ago

I was exactly thinking that these days: why only marking as pre-determined action? Allowed commands are:

'annotate', 'append',  'denotate', 'edit',  'information', 'log', 'prepend',  'start',
'stop', 'version', 'calendar', 'add', 'delete', 'done', 'modify', 'duplicate', 'undo' 

All of this can be issued at the prompt, affecting the current task. But... Some reviews are done to modify tasks, not just to mark them; then, it has a logic to imagine dedicated reviews centered in actions, not tags. [Well, I have this not really elaborated, but...] What about having 3 or 4 'pre-loaded' --defined in the rc file-- actions for a particular review and issue them as as trev> :1 , trev> :2 ... at choice ?

nocejo commented 9 years ago

A list of selected task will have less sense in that case. Perhaps better a history list , showing what has been done along the review.

linuxcaffe commented 9 years ago

The more I think about this, the more it looks like tasksh behavior vs. trev configs. Sure, once we figure out the tasksh behavior, there should be a rev config for it.

The tasksh command "context" (no, not that context) could be used for this purpose, I think, with a little refinement (like a re-name of the function)

As I see it, there are multiple ways to get the "mod project:" into the prompt

1) something like tasksh-context, which puts sticky stuff at the prompt 2) somehow pre-submit a text-string at the prompt, as though user had typed it 3) somehow incorporate a read-command-string prompt function, to generate a prompt

maybe a fusion of 1) and 2), I've always like the idea of being able to pre-define both shell-prompt-stickys and pre-typed text, with the same command. It hinges around the ">" part of the shell-prompt (configurable) As an example, this imaginary tasksh invocation;

tasksh -p 'task mod> project:'

Which would (in theory) start tasksh with the context-element "mod" and the pre-loaded text "project:", and a prompt;

task mod> project:

The user cold backspace over "project:" but would have to "context-clear" the "mod" part.

I don't mean to go on and on about tasksh, in a trev issue, but they are related. The above could translate to a trevrc config;

review.require-project.prompt='trev modify> project:'

I'm just tossing out "blue-sky" ideas here :)

linuxcaffe commented 9 years ago

@nocejo All of that "blue sky" and I clouded your "better history list" suggestion, which is excellent, and answers the problem, as well (or better)

nocejo commented 9 years ago

I'm working hard to understand the whole extent of your post. :)

linuxcaffe commented 9 years ago

well the first part was all about enhancing the trev prompt config

the next part was that I thought that should be tasksh behavior, more than a simple trev config

the last part was that your suggestion of "improved history" was a more pragmatic approach

once again, sorry for flooding the comments with "blue sky" ideas, when you're already "all over it" I'm gonna close this issue and look forward to using history for the function, for now. thanks!

( I hope closing this one is ok..)

nocejo commented 9 years ago

Your "blue sky" ideas are fine; I hope it will continue to arrive. Just, I was very busy working on multi-step reviews. Now is almost done. Ufff.

Closing OK.