This change makes sure that Guard implementation can just
`throw :task_has_failed` without knowing whether the enclosing
group has enabled :halt_on_fail.
The problem with throw/catch is, that when you throw a :symbol,
you'll have to catch it, otherwise you get a 'uncatched throw' error.
When the Guard group has not enabled :halt_on_fail, we catch the throw
when execute the supervised task.
- Renamed some Guard methods to be shorter and more consistent.
- Extract methods from execute_supervised_task_for_all_guards for less complexity.
- Added more specs for extracted methods.
- Added more docs on how marking of deleted/moved files works.
- Refactor Guard to be unaware of the :watch_all_modifications options for simplicity.
This enables defining inline guard handlers to override ones present in gems,
e.g. you could define an inline Guard::RSpec handler and have guard use that
instead of first trying to load 'guard/rspec' from the 'guard-rspec' gem.
Also gets rid of the ill-named method `try_to_load_gem`. Handlers are simply
found in the $LOAD_PATH and don't have to necessarily come from gems.
I basically went through all specs and applied the following rules:
* Use `describe` for methods and `context` for contexts.
* All class methods starts with `.` and instance methods with `#`.
* Removed all `it should`, because the specs _have to_.
* Applied a consistant naming on all listener specs.
* Make fixture usage more fail save by giving generous sleep times.
* Make all behaviour description non-technical and easy to understand.
The goal of this excercise was to have a documentation that is easy
readable and describes the behaviour and not the implementation.
Try it out by using the RSpec documentation format!
Every guard task are now executed through
supervised_task method.
If a guard failed to achieve its task(raise error)
a message is logged and the guard is fired.
The stop method now always quit the application
at the end.
Specs added. The documentation specify that if a
throw an exception, it will be dismissed.
