I have M-. bound to xref-find-definitions (is that the default?)
Half-formed question/thought from today. When I M-. on a callsite of a protocol function I am taken to the line with the defprotocol that defines that function. I realized I have muscle memory for 1) isearch-forward and type the name of the function, 2) grep (well, really ag ) for the symbol (protocol function name), 3) parse the search output for likely candidates for the currently relevant implementation
Would it be possible for CIDER to instead show me a list of implementations of that protocol function (from various objects) and let me choose, and take me right to the implementation? Exploring larger, and heavily (and properly) abstracted code bases this could save time.
Feel free to propose exactly that - it'd be fine with me to do something like this. And probably for find-references as well, given all of the limitations of the current built-in approach.
Btw, the general idea behind this hacky solution wasn't bad IMO https://github.com/clojure-emacs/cider-nrepl/pull/568 Someone might consider working in this direction, as it's probably the simplest option.
Honestly for that level of hackiness, one can just grep the project - should be a speedy op in a well-tuned Emacs.
(It's not some sort of purism, it's just that it won't work so frequently that it's more honest / useful to not say we provide features we really can't atm)
SLIMEβs find-references (for Clojure) for many years was essentially a sophisticated grep and many people found it pretty useful, so this taught me that probably discarding imperfect solutions hastily is not the best approach. But I agree - skilful usage of grep can get you pretty far.
FWIW I have this in my init.el:
(keymap-set eglot-mode-map "M-i" 'eglot-find-implementation)
So what I usually do is M-. to go to the protocol, then M-i to find implementations of that, and jump there.
Not sure if CIDER supports something similar. (`lsp-mode` probably does, if you prefer that to eglot though.)ah, hadn't thought about lsp - that could be an interesting avenue to explore ... I guess my question (and I'm not sure it even makes sense) is more like, does CIDER know all the implementations of a given protocol?
@stig328 What does eglot do that cider doesnt? I'm curious
Run clj-kondo, for starters... π FWIW I use eglot with clojure-lsp AND cider. We have many Clojure code bases and I prefer to be able to navigate the source (with xref, etc) without having to launch CIDER.
For this particular case, eglot (via clojure-lsp) knows more than cider since finding out the impls of a protocol generally can only be known via static analysis and not runtime analysis I'd like CIDER to opportunistically grab info from the .clj-kondo dir (present in every other project) for a free lunch :)
I'm about 2 months into clojure and currently working on a 16k+ codebase. I'm scared or what clj-kondo would reveal, so i'm staying away for now π. maybe in my next project
> For this particular case, eglot (via clojure-lsp) knows more than cider since finding out the impls of a protocol generally can only be known via static analysis and not runtime analysis Thank you, that answers my question very directly. I appreciate your deep knowledge and insight and time.
Cheers. FWIW we have a ticket for it https://github.com/clojure-emacs/orchard/issues/204 - would be a matter of someone to volunteer
Thank you, @vemv I have subscribed to notifications there.
@olajeremy123 It's worth getting clj-kondo set up even if you don't hook it up to CI. At least you can let it help you not committing new atrocities. (Though I recommend just biting the bullet and fixing the issues, at least for the rules you care about.)
Automating the grep/ag workflow I described in my original post here (to integrate it better w/ my other beloved CIDER workflows) would be nice. The precise underlying mechanism isn't that important (and can obviously be improved over time).