Clojurians Log v2

I've been wondering lately what to do with suitable (the cljs completion library), as it has been broken for shadow-cljs for ages and disable in cider-nrepl because of this. See https://github.com/rksm/clj-suitable/issues/15 Ideally familiar with shadow-cljs should fix this issue, but as one year has passed and no one has stepped forward I'm not holding my breath. I can also disable this conditionally for shadow-cljs only or I can potentially remove it completely from CIDER and go back to the way things were before suitable. (e.g. I can put the generic completion code in Orchard and drop the fancy suitable stuff). As I don't use ClojureScript at all, I don't want to invest a lot of time in this, but it definitely frustrates me that things are the way they are. If someone here wants to help out with the clj-suitable issue that'd be greatly appreciated! If not - I'm leaning towards removing it from CIDER completely to simplify my life. The first option looks like less work for someone familiar with shadow, the second is what I know how to do. 😄

@bozhidar would it not be possible to have to his a completely separate opt-in library? I mean have a default auto-complete middleware and if loaded the suitable lib could just place itself in front of that and intercept/handle the messages like piggieback does?

doesn't change the problem but might ease your maintenance burden by keeping it out of your way

It is possible but it seems like an overkill at this point, especially since we moved the basic completion code for ClojureScript there as well. It seems to me it'd be much better to just update suitable for the shadow changes.

ah ok, didn't know that. thought there was a fallback solution

It has two completion sources - one that uses the cljs compiler state and always works and another one that inspects the runtime state and got broken.

This is what was historically in cider-nrepl https://github.com/rksm/clj-suitable/blob/master/src/main/suitable/compliment/sources/cljs.cljc

Now that nREPL has a completion op built-in some completion should ideally come from piggieback and shadow directly, but I'm guessing it will take us a while to get there.

are there some docs for the nrepl messages going over the network for this?

always easier to look at the protocol than trying to reverse engineer the code

well realistically I don't have time to dig into this anyways but I'd be happy to help out answering questions if anyone needs help regarding the shadow-cljs parts

happy to add more official API methods if needed as well. don't go digging deep into internals like suitable did. I make no guarantees they won't break again.

The new ops that were added are https://nrepl.org/nrepl/0.8/ops.html#completions and https://nrepl.org/nrepl/0.8/ops.html#lookup

And here are some examples https://metaredux.com/posts/2020/06/15/nrepl-0-8-evolving-the-protocol.html

The basic idea was that if more essential ops were supported out of the box fewer people would need additional setup/middleware.

If shadow's middleware exposed those ops then shadow users would get some extra mileage without the need for cider-nrepl to be around.

(and at some point I'll likely stuff something similar in piggieback)

Hi! I'm also having https://clojurians.slack.com/archives/C0617A8PQ/p1617373864130200 very same problem (`Symbol's function definition is void: seq-contains-p` when running cider-jack-in/`cider-connect`). I deleted the .emacs.d folder and reinstalled prelude, but it didn't help. I'm using Emacs 26.1 . Any idea what else could I try ?

@bingen.galartza You need to update the seq.el package to its most recent version.

In my package list I see both seq 2.20 and 2.22 (which I guess is the latest). The first one is built-in and the seconds is installed by Prelude. Should I delete the old version? I'm quite a newbie with Emacs internals

Not sure that you can delete a built-in package, but I guess you can try.

Ok, thanks, I will investigate

I've reverted CIDER to use the deprecated seq-contains just now. It seems it's better to have a deprecation message than to deal with all this breakage.

Cool, thanks a lot

Working like a charm. Thanks again

Not a problem. It broke CIDER's CI (lint error), so I replaced with member in the end. At least I remembered why I had changed the deprecated function in the first place. 😄

Emacs for life! 😍:the_horns::skin-tone-4:

we 🪨