This style (named 'fill-column' I believe) has always seemed barely legible to me - I need some paragraphs to make sense of stuff :) So I was considering it CIDER could cleanly (non-mutatively) and optionally replace those with a nicer formatting: some extra newlines here, some backticks (for code formatting) there.

I never liked the minibuffer randomly exploding, so I pretty much disable those with (eldoc-echo-area-use-multiline-p nil)

(nivekuil) re: exploding, I usually keep the eldoc buffer open in a separate frame/monitor precisely because of that

I like how completion and lsp-mode / lsp-ui displays the docs in a floating window so my eyes don't have to jump around. I think lsp adds some additional rendering which may help some doc strings (although most doc strings are very terse) I usually use clojure-docs or an internet search if it's more than a brief reminder of something

There are certainly plenty of choices for rendering the docstring - I'm not too concerned about that. I'm most curious about the formatting of the clojure.core docstrings themselves - even if terse, can't they look slightly unreadable because of the lack of newlines? There's this style which has gained popularity. I'm not sure I like it 100%, but at least it's a standard that I could easily point at. https://asciidoctor.org/docs/asciidoc-recommended-practices/#one-sentence-per-line

> This style > Note that this optimizes for writing, leveraging the fact that markdown/asciidoc only starts a paragraph after an empty line (so, at read time/after rendering, it'll look like one single paragraph)

That's fair, for Clojure docstrings though, there generally isn't a distinction between write-time and read-time - CIDER and the like will just render the string literally. I could see however how it can be slightly confusing to use a document indended for purpose X to be used as reference for purpose Y.

Unfortunately, cores's docstrings are a bit all over the place in terms of uniformity. Note that some do have paragraphs, such as https://github.com/clojure/clojure/blob/6975553804b0f8da9e196e6fb97838ea4e153564/src/clj/clojure/core.clj#L6770-L6792 I probably wouldn't mind having it reflown to a wider (120?) width, but even that may not be always an improvement 😕

(NB: I completely get what you're saying. e.g. a great example of how hard it can get https://github.com/clojure/clojure/blob/6975553804b0f8da9e196e6fb97838ea4e153564/src/clj/clojure/core.clj#L6890-L6899

Yeah. It probably would be nearly impossible to programatically improve these (well, without using GPT somewhere in the stack ;p) I had in mind to create, say, an .edn file mapping the existing docstrings to hand-crafted improved docstrings. Typically the improvements would be whitespace-only. It sounds something small enough to do for clojure.core and a few others.