Various UX improvements to Cider Inspector

[yuhan0]

These are a few tweaks that I've made to the cider-inspector workflow, all based on improving the general user experience. Can split into multiple PRs if preferred.

---

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 (make test)
• All code passes the linter (make 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)

[yuhan0]

Some additional rationale for these changes:

I do most of my evaluation from code buffers and comment forms instead have the REPL buffer open, so I'm usually not aware of the default (cider-current-ns) - this means that d in a cider-inspector buffer ends up making defs in unexpected namespaces without any indication of where it went. I made cider-inspect automatically switch the repl ns in my personal config but that's probably not suited for everyone.

Also I found myself accidentally inspecting map keywords annoyingly often when trying to navigate between values, and it occurred that I would never want to inspect values like numbers and nils, just like the debugger skips over uninteresting values when stepping through code.

Lastly this is perhaps more subjective, but I do cider-eval and cider-inspect-last-result quite frequently when trying to understand the shape of some large function outputs. Having the visible inspector buffer automatically update while keeping focus on the code buffer has been a nice improvement to the flow of repl-based dev.

[bbatsov]

I'm fine with the proposed changes, but it'd be nice if they also got some coverage in the docs, so users would actually discover them. Right now the inspector has almost no documentation (https://docs.cider.mx/cider/debugging/misc.html#_inspecting_values) - it'd be nice if we expanded this into a dedicate page for it. I plan to do something similar for macroexpansion and profiling soon.

[bbatsov]

Thanks!

[yuhan0]

Thanks, I hope that setting those features on by default would be a welcome breaking change to most users :)

About the docs, It looks like my newly added debugger.adoc xref link is not working at https://docs.cider.mx/cider/debugging/inspector.html.

Could there be a short How-to writeup on contributing to the Asciidoc-based documentation? I didn't want to figure out from scratch how to set up the entire Antora toolchain, in order to render my changes and see that I didn't mess up the xref syntax or break something in the process.

On an unrelated note I was also surprised to see the entire family of cider-eval-* commands wasn't documented anywhere - probably deserves its own page?

[bbatsov]

About the docs, It looks like my newly added debugger.adoc xref link is not working at https://docs.cider.mx/cider/debugging/inspector.html.

Just fixed this. You had missed the directory prefix for the page.

Could there be a short How-to writeup on contributing to the Asciidoc-based documentation? I didn't want to figure out from scratch how to set up the entire Antora toolchain, in order to render my changes and see that I didn't mess up the xref syntax or break something in the process.

You don't really need to know much about Antora to work with it. I think this can get you pretty far https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/ :-) We can always add something to the manual, but AsciiDoc and Antora are documented so well that it seemed redundant to me.

On an unrelated note I was also surprised to see the entire family of cider-eval-* commands wasn't documented anywhere - probably deserves its own page?

Agreed. A lot of great features are not documented. :-)