Fork me on GitHub
#cider
<
2019-04-15
>
benedek11:04:58

morning, i have this faint memory (maybe was just dreaming about it?!) that there was some talk/plans already to integrate kaocha with cider? can anyone point me to a blog post, github issue or the like? (posted this in #kaocha too)

bozhidar15:04:29

We might have discussed this, but certainly no work has been done in this direction.

bozhidar15:04:04

Unfortunately the list of our ideas greatly outpaces our ability to deliver upon them. 😄

benedek16:04:52

not sure if this is worthy to work on anymore… or if this is the right direction even.. anyways… may just give this a proper a go to see where it leads…

bozhidar16:04:39

@benedek Looking at clj-kondo, I’ve been thinking it’d be much easier (and way more portable) to just use rewrite-clj to generate the AST.

bozhidar16:04:16

It won’t be as precise as using tools.jvm, but it’s so much simpler and doesn’t involve evaluating the code.

bozhidar16:04:35

I think something like this should be the direction for us, as everything else is too complicated IMO.

bozhidar16:04:31

Btw, on the client-side now we also have the option to use the native elisp parseclj library.

benedek16:04:42

yeah i might end up writing an analyzer but does feel like an easy option ;)

benedek16:04:56

i use rewrite-clj in mranderson now but still a long way from there to an analyzer which can give is global and local vara

benedek17:04:17

seen borkdude's tweets and announcements about clj-kondo will check it out more in depth

bozhidar17:04:46

I’ve yet to check the exact AST format, but I assume we can figure out most locals and globals with simple heuristics. I’d rather have a simple runtime-independent solution that works well most of the time, than a very complex solution that works all of the time.

benedek17:04:47

we agree on that one

benedek17:04:27

bit like joker i suppose in the sense that you explicitly need to teach it your custom macros if they add defs

benedek17:04:34

if i understand right

bozhidar17:04:31

Yeah, but I think that’s perfectly fine.

bozhidar17:04:56

It’s the only way to avoid having to expand the macros anyways.

bozhidar17:04:15

(or you can annotate macros with some metadata, which would be my preferred approach)

dpsutton17:04:22

Coworker of mine made an lsp server

bozhidar17:04:47

What did he use for the static analysis?

dpsutton17:04:16

Not sure. Let me dig it up

dpsutton17:04:35

Clj-rewrite it seems from looking at the reps

benedek17:04:20

ok so there may be quite a bit of proof out there proving that it can be done

benedek17:04:30

is this public repo @dpsutton?

dpsutton17:04:00

Yes. On mobile but GitHub user is snoe

dpsutton17:04:07

Closure lsp

benedek19:04:34

this is really interesting @dpsutton thanks for mentioning it.

dpsutton19:04:13

I use it at work. It’s been very nice. Refactoring, reference navigation, etc

benedek19:04:37

it says it has find usages etc on tin.

benedek19:04:02

really impressed so far

benedek19:04:27

i will deffo try it

benedek19:04:48

you don’t really need cider as a fronted for such a thing, right?

dpsutton19:04:33

Its lacking eldoc which I rely on a lot but otherwise pretty good

benedek19:04:33

i mean lsp-mode is the frontend i assume

dpsutton19:04:58

There are some config info for emacs in the reader

benedek19:04:51

yup seen that

benedek19:04:38

this is really exciting actually. this is a direct competitor of cider — if such a thing exists in open source terms 😉

dpsutton19:04:36

It needs a good layer to wrap up the refactoring commands

dpsutton19:04:54

It has some threading rewriting stuff

bozhidar20:04:09

LSP is likely going to be become a big deal for every language in the years to come.

bozhidar20:04:03

For Lisps is a bit weird to running tooling outside the REPL (at least for me it’s weird), but LSP makes a lot of sense in general.

dpsutton20:04:07

yes. and also might drastically lower the barrier for newcomers. CIDER is fantastic but if someone just grabs an lsp-aware editor and is up and running that is a good thing for sure

bozhidar20:04:54

Yeah, although I guess this would mean less people on Emacs as well. 🙂

ghadi20:04:58

snoe/lsp can benefit from being dynamic instead of driven by file analysis

👍 1
richiardiandrea20:04:18

agree with the Ghadi lsp is just a protocol after all

bozhidar20:04:49

Well, it you can implement it in terms of a running REPL, that’s true.

richiardiandrea20:04:58

I guess that if it even makes sense, there could be a REPL-driven mode with static analysis backup

richiardiandrea20:04:34

well...I don't know what could happen if the two clash though 😄

dominicm21:04:24

I disagree that tooling should be "good enough". I want tooling that is reliable so I don't have to swear every time I cut a finger on a sharp edge. "Great, now my completion doesn't work because I'm using a macro".

ghadi21:04:29

the LSP server should be embedded within the repl application

ghadi21:04:57

not separate. Other langs need the separation, but we don't

👍 1
dpsutton21:04:28

the author, case, is my coworker and is more than happy to have contributors

ghadi21:04:58

cool! @dpsutton thank him for me

dpsutton21:04:14

i will pass that along. do you use it?

bozhidar21:04:24

Well, at some point I suggested an LSP server which simply proxies to an nREPL server (or whatever). That’s how I would have done it, but in general for me LSP doesn’t really add much value to our existing setup.

ghadi21:04:40

no, but we looked at it in relation to REBL

richiardiandrea21:04:55

@bozhidar yes that's the way to go imho

dpsutton21:04:01

i think he will be quite pleased to hear that

bozhidar21:04:28

There are 0 technical limitations to doing the static analysis directly from a REPL-powered tool, I just never liked tools analyzer and the need to evaluate the source files to build the AST.

ghadi21:04:06

you can override the need to evaluate in tools.analyzer

ghadi21:04:48

what do we need to analyze, btw? get position context for better autocompletion?

bozhidar21:04:38

@ghadi No, we need some AST for things like find usages, replace var, etc.

bozhidar21:04:29

It’s also useful for linting purposes - e.g. getting arity warnings without the need to run a separate lint tool, etc.

bozhidar21:04:37

Generally find & replace are the most important usages as far as I’m concerned. Unfortunately they can’t be reliably implemented without analyzing the entire project.

bozhidar21:04:40

Anyways, I really hope we’ll do more on the static analysis front one way or another soon.

bozhidar21:04:44

As for LSP - that’s not something I’m particularly interested myself (at least with respect to Clojure), but I’m happy to see progress on that front and I hope someone will do an nREPL backed LSP server implementation at some point.