All nrepl tickets closed, now managed at https://github.com/nrepl/nrepl

I agree that middlewares should be able to participate, and that it should be declarative.
Short of having special semantics for reporting middlewares instead of ops, what I did for `cider-nrepl` is to declare a dummy op named `pprint-middleware`, even though currently there's no pprint dedicated op.

See https://github.com/clojure-emacs/cider-nrepl/blob/11152eeb55509b2dd5eb7225526e68773cb78d78/src/cider/nrepl/middleware/pprint.clj#L59

I've thought about this a bit. I would like to avoid exposing transient implementation details (e.g. the namespace/var name of particular middlewares) to clients like this. Doing so just makes it easy for complications to occur later (e.g. what happens when that name changes due to a project reorg, or when there's N pprint middlewares, rather than just one?).

I think it's reasonable to expect middlewares to participate in the reporting of available operations in the describe response. Even things like a pprint middleware should offer an operation or two to toggle whether or not it's active. I'd be interested in any counterexamples to this general expectation…?

Hi Chas, do you have ideas on how to expose middlewares?
Should it be through a new op, mimicking what `describe` does, but for installed middlewares?
Should it leverage the existing `describe` middleware but with an additional (backwards-compatible) key (e.g. key = "type" value = "op" or "middleware") ?