Make DebouncedEvent be Clone, expose is_recursive

[cmyr]

A speculative PR:

These are two very small changes that would be useful to me. Getting #131 onto crates.io would be appreciated, and if you want to include these that would be additionally so; but I do have some workarounds in place already so this is less important.

If you were going to do a bump for crates.io, and could give an up or down vote on #118 first, it could go in at the same time?

Thanks!

[passcod]

The Clone derive is fine, but can you explain your use for the expose?

[cmyr]

I have a wrapper API, and I have (perhaps dubiously, I admit) chosen to expose the recursive functionality via a bool, so that consumers don't need to bring notify::RecursiveMode into scope. 🤷‍♂️

[cmyr]

@passcod I'm backtracking, I think I was being too clever. This is now just the Clone.

[passcod]

Note for when I cut the release: this is a bump-minor.

[michaelfairley]

This doesn't seem to build. 🙁

error[E0277]: the trait bound `Error: std::clone::Clone` is not satisfied
   --> src/lib.rs:415:11
    |
415 |     Error(Error, Option<PathBuf>),
    |           ^^^^^^ the trait `std::clone::Clone` is not implemented for `Error`
    |
    = note: required by `std::clone::Clone::clone`

Add a derive for Clone onto Error results in this, which doesn't seem resolvable:

error[E0277]: the trait bound `std::io::Error: std::clone::Clone` is not satisfied
   --> src/lib.rs:445:8
    |
445 |     Io(io::Error),
    |        ^^^^^^^^^^ the trait `std::clone::Clone` is not implemented for `std::io::Error`
    |
    = note: required by `std::clone::Clone::clone`

[cmyr]

@michaelfairley ugh good catch. I forgot in my workaround I was converting io::Error into a general error.

I don't suppose that's an appropriate approach here. So:

• We could wrap that error in an Arc
• We could revert this and let me figure it out on my own

Honestly, the latter might be the better option?

[cmyr]

@passcod you saw this? I'll put a revert together.

[cmyr]

ah beat me to it, great

[passcod]

Ah, no, Github's own revert tried to also revert #134, when I just wanted to revert this one. If you can fix before the weekend (when I'll definitely cut a release) don't bother with a revert, though.

[cmyr]

Okay, so I will manually remove this change in a new PR?

[passcod]

Hmm, I did the revert. Anyway, you can expect a release this Saturday at the latest.

[cmyr]

@passcod great, thanks for this!