[VT-124] vit [args] should be persistent

[tbabej]

David Patrick on 2015-08-13T20:58:39Z says:

vit can be launched with arguments, works great. For example;

vit rc.context=work

will launch vit with the work context active.

but the thing is, any subsequent action discards the original arguments, so by changing reports, I will lose the context setting.

I think it would be better if any arguments used in launching vit, remained persistent for that vit session, or until Ctrl L is used to refresh the screen. That way, a vit session could remain focused on whatever arguments were used to launch it.

[tbabej]

Migrated metadata:

Created: 2015-08-13T20:58:39Z
Modified: 2015-08-15T19:56:05Z

[tbabej]

Scott Kostyshak on 2015-08-13T23:35:15Z says:

Good point. We'll have to think this through. One concern that comes to mind is that VIT would have to parse the command and figure out which part of the command is the filter and which part should remain persistent. I'm not sure this is easy, as Taskwarrior commands come in many ways.

[tbabej]

David Patrick on 2015-08-14T01:00:08Z says:

I think that if invoked with args, ALL of it should be presistent, filter, configs the works. Then any subsequent filter elements, while the app is running, should get added to those, but the original set remains until quit or ^L reload.

[tbabej]

Scott Kostyshak on 2015-08-14T05:32:50Z says:

But what happens when you change the filter? The other elements should stay right? But that is the problem -- it is hard to figure out what the other elements are by parsing the taskwarrior command. One way would be to ask Taskwarrior by help, e.g. by using --debug which shows what the filter is parsed as I think. I don't know if this should be done though.

[tbabej]

David Patrick on 2015-08-14T23:22:17Z says:

My thinking is that launching vit with arguments could (should?) mean "constrain this vit session to these variables", and that defines a BASE_FILTER set, which is used for that session. Any filters applied during the session (including those that might override) are applied on top of the base set.

This would allow a given vit instance to have a specified function.

We've had this conversation before, and I still think it would be useful.

[tbabej]

Scott Kostyshak on 2015-08-15T01:18:22Z says:

Let's add some structure. Suppose I start VIT as:

vit test rc.abbreviation.minimum=4

Then I press 'f'. (1) What should be shown on the Vit prompt? (2) What should be the underlying Taskwarrior command that is run after the filter is changed (say I want to change to the filter 'def')?

[tbabej]

David Patrick on 2015-08-15T18:14:18Z says:

OK, good questions! Right now, when I launch with the suggested attributes, vit starts with a list of 5 tasks, and

task test rc.abbreviation.minimum=4 

at the top line. When I hit "f" I see

Filter: rc.abbreviation.minimum=4

if I backspace that out, and change it to 'pro:tw', it behaves as desired, it reduces the list to 2, and the top line says;

task test proj:tw 

good so far! but If I change the report to ls, BOOM the filter's gone!

.. and BAM! I just realized how this long-standing feature-request could be worked around with a vitrc configuration change.. at leas, in my case.

opening a new issue, closing this one soon.

[tbabej]

Scott Kostyshak on 2015-08-15T19:56:05Z says:

Great! I look forward to the vitrc config change (let's link to the new issue from this one). I hope to get more active in VIT development in a couple months. I just moved and started a new job so still getting set up with that.

Thanks as always for your great feedback DJP.