Expose inner error context to allow removing pieces of context, for consistency

[5HT2]

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

Clap Version

master

Describe your use case

Currently, error messages provided by clap::Error rely on numerous private APIs when being constructed, which force you to rely on writing an entirely new Context formatter, instead of being able to access the inner styles directly, as with other similar use cases.

A similar proposed enhancement, #5065, already goes into in-depth discussion about possible alternatives and solutions at the moment, suggests making Error::set_source accessible, which is incredibly beneficial for solving most of my problems when it comes to making error prints pretty, however, it still doesn't address being able to trim unnecessary help flags from errors, which would either require exposing specific inner methods, or simply exposing a public API to remove from the inner error context, which would be complimenting Error::insert

Describe the solution you'd like

Currently, I feel like the most straightforward and flexible solution here would be a public API method exposing .inner.context.remove(), akin to the current Error::insert exposing .inner.context.insert(), defined here:

clap/clap_builder/src/error/mod.rs

Lines 197 to 202 in 2ab48b2

	/// Insert a piece of context
	#[inline(never)]
	#[cfg(feature = "error-context")]
	pub fn insert(&mut self, kind: ContextKind, value: ContextValue) -> Option<ContextValue> {
	self.inner.context.insert(kind, value)
	}

One could imagine how similar this public API would be, and how fitting it would be for the sake of completeness in the library, as it's a very non-roundabout way to go about allowing prettier Error outputs without hardcoding even more public methods to expose, to access the inner styles and help flags.

-    /// Insert a piece of context
+    /// Remove a piece of context
=    #[inline(never)]
=    #[cfg(feature = "error-context")]
-    pub fn insert(&mut self, kind: ContextKind, value: ContextValue) -> Option<ContextValue> {
+    pub fn remove(&mut self, kind: ContextKind) -> Option<ContextValue> {
-        self.inner.context.insert(kind, value)
+        self.inner.context.remove(&kind)
=    }

Alternatives, if applicable

I've already gone over them, including exposing specifically the inner prettier and inner help flag params, this solution is cleaner.

Additional Context

🚀

[epage]

Whats helpful in discussing potential solutions (plural is intentional) is an understanding of the problem. Could you provide more details on what problems you are having with the errors being generated by clap?

[5HT2]

I don't find all parts of the generated error context useful, from an end user perspective, and occasionally the default inner help flags end up bloating the error output of my libraries, which I would rather be able to trim selectively on my end.

Given the fact that you can't access the inner pretty nor the inner help flags directly, it would be inconvenient to just expose all of them via a public API, and it makes more sense to be able to trim them via an opposite equivalent to the existing Error::insert function.

[epage]

I don't find all parts of the generated error context useful, from an end user perspective, and occasionally the default inner help flags end up bloating the error output of my libraries, which I would rather be able to trim selectively on my end.

Could you give more concrete examples

Given the fact that you can't access the inner pretty nor the inner help flags directly, it would be inconvenient to just expose all of them via a public API, and it makes more sense to be able to trim them via an opposite equivalent to the existing Error::insert function.

Currently, our primary way of customizing is through custom formatters. If there are APIs missing for those, it is a bug. However, I can understand the extra work it is to replace the formatter completely, rather than customizing the values.

Better understanding what routes we want to support is dependent on knowing what people are trying to accomplish.