That's exactly how it should work.

The only thing I'd change is to use a custom exception instead of Errno::ENOENT, like Guardfile::Generator::NoSuchPlugin which takes the plugin name as an argument. This custom exception would be derived from Guardfile::Generator::Error, so catchingGuardfile::Generator::Error would handle future errors.

Kind of like here: https://github.com/guard/guard/blob/771-non-zero-exit-code-when-plugin-unavailable/lib/guard/cli/environments/valid.rb#L35

Ideally, the _ui calls would be moved too, so the generator just throws the exception with the plugin name, the exception itself generates the message (including a newline), and the handler would make the _ui call with the message. A spec would be written for the custom exception (formatting the message), just for coverage and so a typo doesn't blow up things when the exception does happen.

Anyway, I'm fine with just replacing Errno::ENOENT with a custom exception class.

Thanks for the feedback @e2 and sorry for not replying earlier! I will update the PR asap! ;)

@rymai - don't worry about it :) I'm the one who hasn't done much in Guard for a long time.

(Though I mostly wanted to make sure Listen 3.x works for people without issues first - especially in Spring, so I avoided changing "too much")

Here you go @e2!

It feels good to work on Guard again, I hope I'll have more time to contribute from now on.

Awesome! Makes me want to get back to contributing a bit more too ;)