Clojurians Log v2
dev-tooling 2024-04-21
Does this op has a purpose? https://github.com/clojure-emacs/cider-nrepl/blob/31a3d02e13ae1daff0637330c27d83f5943a8486/src/cider/nrepl/middleware/inspect.clj#L146 I can't find the reference to it in CIDER, it doesn't seem to have a corresponding keybindings. If this is an oversight, what benefit can it have for the user?
Clearing the inspector can make some sense for certain users, although it's true that it's shorter to simply inspect a new value instead. I don't have a strong preference - op could be removed, or the trivial feature could be implemented client-side
This caught my eye because the current behavior of (fresh) would render nil as a value. I'm not sure if this can be valuable because you can't go anywhere from that state.
But there can be value in clearing up the inspector state when the user closes the inspector, I'll try to make a PR out of it.
> I'm not sure if this can be valuable because you can't go anywhere from that state.
You kinda can with cider-inspect-expr-from-inspector
You kinda can with cider-inspect-expr-from-inspectorRight, but the inspector window is not very becoming to do it :)So, like you've said, doing clear first and then cider-inspect-expr-from-inspector doesn't have added value over doing cider-inspect-expr-from-inspector immediately.
Yeah
Perhaps instead of nil we could show a friendly screen, I doubt many (certainly not me 😄) know all commands, for instance
Also, @vemv, do you happen to remember what exact cider-nrepl issue was solved by this? https://github.com/clojure-emacs/orchard/blob/a6956c75b3ccff90436e60890886f887547c4c16/src/orchard/inspect.clj#L176
From time to time, client-side I see nil and nothing else.
Probably that's what happens when the inspector is nil
So the (fresh) call seems reasonable to keep around
Since it's an external issue, I think it makes sense to handle it on cider-nrepl side (ensure that inspector is a non-nil object before passing to orchard.inspect functions).
Otherwise, such treatment is needed for all public functions, not just down.
Are there big known consumers of Orchard besides cider-nrepl? I thought Calva is one, but it seems to use cider-nrepl directly. Trying to understand how careful should I be about backward compatibility of those public functions that are not a part of the intended API.
Haystack
Today's deletion seemed fine
But generally we try hard to avoid breaking changes. The vast majority of times there's a reasonable alternative.
It's also a good exercise/habit - if we don't regularly strive to avoid breakage, we normalize breaking stuff. It's a slippery slope that ends up firing back sooner or later
I totally agree with you, and I generally try to introduce deprecations instead and keep them for a while. But it is still nice to know where to check first whether some obscure functions are used.