Eval UX improvements

[yuhan0]

This is the first of a bunch of tweaks on my local copy of Cider that I've been using for almost 2 years now and never got around to submitting. I hope it's alright if I group several related changes together in a single PR, much of the friction comes from having to rebase commits and write multiple changelogs.

• Overlay text takes on the face of the following text - this is especially noticeable with coloured parens and cider-result-overlay-position set to 'at-point'.
  Before (using cider-eval-last-sexp, the text takes on the yellow of the closing paren next to it):
  
  After:
  

• When an error occurs and cider-show-error-buffer is set to nil, an overlay is created with an error indicating face. Currently there is no indication at all of the type or presence of error.
  I've been using this setting for some time now and find it much more responsive and less distracting than a stacktrace buffer popping up and needing to be dismissed. Most of the time a simple error message is enough information, and one can use cider-selector to bring up the stacktrace buffer if needed.

• Similarly with cider-eval-to-comment commands, it helps (especially for teaching purposes) to have the error output to the comment:
  

I don't think tests or user manual updates are needed here?

---

Before submitting the PR make sure the following things have been done (and denote this
by checking the relevant checkboxes):

• The commits are consistent with our contribution guidelines
• You've added tests (if possible) to cover your change(s)
• All tests are passing (eldev test)
• All code passes the linter (eldev lint) which is based on elisp-lint and includes
  • byte-compilation, checkdoc, check-declare, packaging metadata, indentation, and trailing whitespace checks.
• You've updated the changelog (if adding/changing user-visible functionality)
• You've updated the user manual (if adding/changing user-visible functionality)

Thanks!

If you're just starting out to hack on CIDER you might find this section of its
manual extremely useful.

[vemv]

The commits look reasonable to me!

As for the screenshots, have you tried having a variety of exceptions thrown, and seeing how they are rendered?

Some things I would expect for a smooth UX would be:

• The final cause is displayed (might be under a chain of prior causes)
• One or two lines are displayed at most
• Width isn't excessive
• Ideally, any irrelevant info would be trimmed away (e.g. Long is in module java.base...)

It's not a blocker but I'd certainly appreciate that experimentation. If something was needed from cider-nrepl side I could try providing it (maybe as a new k-v entry: shortened-error).

[yuhan0]

The only thing it does is print out the error message exactly as sent to stderr, so naturally it handles all kinds of errors:

A slight visual nit is the trailing newline being rendered as a hanging background-coloured box - if string-trim-right is applied it would look like this:

I personally prefer the former for consistency of the extended faces.

• The final cause is displayed (might be under a chain of prior causes)

This is only a few keystrokes away with cider-selector to bring up the full stacktrace of exceptions - I've found that the majority of errors can be identified by their type and message alone.

• One or two lines are displayed at most

I don't see the advantage in truncating multiline error messages, after all the overlay can be dismissed easily.

• Width isn't excessive

Linebreaks and indentation in the error message might be meaningful, so trying to fill-paragraph would run into undesired formatting. Within the window the width is naturally wrapped around or extended offscreen depending on truncate-line-mode.

• Ideally, any irrelevant info would be trimmed away (e.g. Long is in module java.base...)

Again I think it's best to have as little "magic" as needed here - simply echoing the stderr instead of trying to determine what is relevant / irrelevant to show. (There are already external libraries like expound which simplify / pretty print error messages, which is a separate concern)

[bbatsov]

I love the proposed changes and I don't think that any of them are controversial, so let's just merge this and polish it as we go based on whatever user feedback we receive. Thanks for tackling this! 🙇‍♂️