Feature proposal: l or last for last command

[sunkibaek]

Hi

Thanks for the great program -- I use it everyday at work. It's a great productivity boost.

One things is though I would love to see it has following new command

l or last to run a command executed right before.

That is because sometimes guard does not pick up the change I've made in file or I've made a change that guard is not watching but I would like to see the result of the same command.

I will also see if I can implement this feature myself.

Thanks!

[e2]

Could you give a specific example of what you'd like? I'm not sure what you mean by "command".

[dogweather]

If I understand it right, I've thought about this feature too:

When at the Guard prompt, the user would like Guard to repeat the previous test run. Similar to vim's . repeat command. E.g., maybe Guard ran a test for one particular file. The user would like to tell Guard to run that same test again, with the same options as it just did.

[dogweather]

@sunkibaek is this what you're thinking?

[sunkibaek]

@dogweather
Yes, that's exactly what I had in mind. Thanks for clearing it up -- I wasn't sure how to put it.

[e2]

If there was a command like that, it would work like the existing change command.

So, basically, Guard would have to remember the last set of changes, but ...

... "last set of changes" is ambiguous.

Some commands cause a chain reaction. E.g. foo.coffee -> foo.js -> foo.min.js

So the "last command" would be foo.js -> foo.min.js as a result of foo.js. Of course the user would expect foo.coffee to be marked as changed, but Guard won't know that a modified foo.js is the output result of a modified foo.coffee.

Guard doesn't know why a file was changed (user or by an existing Guard task).

It would be probably easier to create a custom Pry command that touches the last updated file in a given directory (e.g. lib or spec or whatever).

[dogweather]

Interesting, so you're saying that Guard is used as an asset processor? Makes sense. I've only ever used it to run tests, e.g. dog_spec.rb -> bin/rspec dog_spec.rb -> <stdout>. In this use, the only product is user feedback. And so repeating the "previous run" is conceptually easy.

So it seems like this might be something that a 'testing' extension should implement.

[rymai]

Interesting, so you're saying that Guard is used as an asset processor?

@dogweather Exactly!

Guard is a command line tool to easily handle events on file system modifications.

Check-out the list of the existing Guard plugins, there are many plugins not testing-related: https://github.com/guard/guard/wiki/Guard-Plugins :)