Closed linuxcaffe closed 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 ?
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.
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 :)
@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)
I'm working hard to understand the whole extent of your post. :)
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..)
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.
This idea comes up in considering reviewing a required field, like
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
but what if, for this particular review, text could be "pre-loaded" at the prompt, as in rc setting:
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.