Hi there, awesome tool. I saw that you check for local tools like notify-send and osascript to produce notifications. There is actually already a crate for that :D This is what it would look like.

cheers

I often work with emacs, and this app reacts to the creation of temporary files like .#lib.rs, or lib.rs~.

It would be nice to only look for modification of not-hidden *.rs files inside src and tests directories, or make it configurable, maybe with regex or glob patterns.

Tracking issue: #7

• Add glob matching with defaults patterns:
  • Cargo.toml
  • Cargo.lock
  • src/**/*.rs
  • tests/**/*.rs
  • build.rs
• Add --include option to add custom patterns.

error: failed to run custom build command for `libdbus-sys v0.2.1`

Caused by:
  process didn't exit successfully: `/tmp/cargo-installU1WHBF/release/build/libdbus-sys-35ee7a2ded76b9a6/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=DBUS_1_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=DBUS_1_STATIC
  cargo:rerun-if-env-changed=DBUS_1_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Failure { command: "\"pkg-config\" \"--libs\" \"--cflags\" \"dbus-1\" \"dbus-1 >= 1.6\"", output: Output { status: ExitStatus(ExitStatus(256)), stdout: "", stderr: "Package dbus-1 was not found in the pkg-config search path.\nPerhaps you should add the directory containing `dbus-1.pc'\nto the PKG_CONFIG_PATH environment variable\nNo package 'dbus-1' found\nPackage dbus-1 was not found in the pkg-config search path.\nPerhaps you should add the directory containing `dbus-1.pc'\nto the PKG_CONFIG_PATH environment variable\nNo package 'dbus-1' found\n" } }', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/libdbus-sys-0.2.1/build.rs:6:70
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `cargo-testify v0.3.0`, intermediate artifacts can be found at `/tmp/cargo-installU1WHBF`

Structopt provides custom derives to parse the commandline arguments into a config struct, hence it abstracts away a lot of parsing, which makes the code less verbose.

Moving to structopt makes the config and error modules obsolete.

Further this PR also currently removes the tests which were located in reactor.rs, because the removal of the config module removes components used in those tests. Further the tests were testing a small wrapper around the glob-crate, hence they might not be incredibly useful. These tests can be recreated to fit into the new structure if you want them back.

Since this library is using clap directly, the definition of the arguments and subcommands is IMO verbose. Further one has to manually convert the hashmap of arguments into their respective types. Hence I was thinking about rewriting the CLI relevant code to rather use structopt instead.

Before doing this I was wondering if this is something that you see as relevant, or if it is a reason behind using clap directly?

structopt - This crate allows you to define a struct, and build a CLI from it! No more "stringly typed" and it uses clap behind the scenes! (Note: There is work underway to pull this crate into mainline clap). -- README.md of clap

There is a process ongoing which will make the structopt-way of defining arguments possible directly in clap, hence it seems as though the community is moving towards a singular way of defining arguments. When this change happens, it will probably be easy to migrate back to clap, using the new structopt code.