Decrease owo_colours method suggestions?

[JaydenElliott]

Hey,

When importing any color_eyre type, my code completion (nvim-cmp) starts suggesting 30+ color_eyre::owo_colors methods on nearly every struct in my project (see image below). Is there some way to disable this? It's a quite inconvenient when trying to find other suggestions.

Would like to hear if anyone one else has dealt with this, however, it might be more of a nvim-cmp question, so please close if not relevant to the crate.

[dvdsk]

its actually a known rust-analyzer problem, see: rust-lang/rust-analyzer#17477

[ten3roberts]

Yes

While it is an issue on RA (and does affect other crates for exported dependencies) it is an issue as color-eyre re-exports owo_colors, and therefore all the colors, like blue, cyan, etc.

What can be done is to not export the entire owo_colors crate, as it is not strictly needed for it to work (only for some minor things in ours style configuration API).

For those cases, the user can depend on owo_colors themselves, rather than using the crate via our crate. I've run into crates using this method myself, like gltf that requires you to bring your own base64 crate for the 1 place it is referenced.

@yaahc what do you prefer we do here

[thenorili]

Yes

While it is an issue on RA (and does affect other crates for exported dependencies) it is an issue as color-eyre re-exports owo_colors, and therefore all the colors, like blue, cyan, etc.

What can be done is to not export the entire owo_colors crate, as it is not strictly needed for it to work (only for some minor things in ours style configuration API).

For those cases, the user can depend on owo_colors themselves, rather than using the crate via our crate. I've run into crates using this method myself, like gltf that requires you to bring your own base64 crate for the 1 place it is referenced.

@yaahc what do you prefer we do here

Not re-exporting owo_colors unnecessarily sounds okay to me as a breaking change, we should try to get buy-in from users though. However...

---

There's a very recent response on the linked rust-analyzer issue where someone has implemented a solution from the IDE side and is contemplating a second angle where crate authors could signal for rust-analyzer not to generate completions. They're asking if we'd be interested in using it. @ten3roberts @yaahc

@ dtolnay Yes, this is accurate description. Personally I think we should have both, since this is subjective but some crates may want to default to remove their traits. Implementing a hypothetic #[rust_analyzer::do_not_complete] should be even easier than that PR, and if there is desire (i.e. crate authors will use this) I'm willing to do that, although I'm not sure how to still allow users to opt-in for traits that crate authors opted-out for.

Originally posted by @ChayimFriedman2 in #17477

My take is -- if our only issues are coming from re-exports, it'd be ideal if this trait could be limited to a specific namespace, i.e. owo_colors, instead of suppressing our whole crate. Obviously this is a precluded by not re-exporting owo_colors... Maybe it's more of a question posed to them, whether they would like to suppress their output categorically? @jam1garner how do you feel about this? further context here #17477_

[ChayimFriedman2]

(Chiming in since you cited me)

Both the PR I authored, and the potential #[rust_analyzer::do_not_complete], are talking about traits specifically. Implementing them for any path should be doable but I don't think we should do that. Implementing them only for one path where it is aliased is going to be very unreliable to impossible. I can't tell what exactly you want, but do note that if you want to use the attribute it cannot be you but must be owo_colors since the trait authors will have to put it (technically, I can also make it work on a reexport, but I don't think that's needed).