Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-08-12

Channels

#lsp
<
2021-08-12
>
Noah Bogart13:08:30

feature request: rename symbols in let blocks

ericdallo14:08:22

yeah, that should work, do you have a simple code block repro?

Noah Bogart14:08:27

seems like it doesn’t work in test files

Noah Bogart14:08:53

hmm, no, that’s not right. i don’t know what’s going on

ericdallo15:08:41

:thinking_face:

dpsutton13:08:51

that works for me

lread18:08:09

Hello beloved clojure-lsp magicians! I’m experiencing an oddity with clojure-lsp (using latest under Calva). I’ve selected verbose for Clojure: Trace:Server for some hints. When I launch vscode and navigate to Output->Clojure Language Client I see the initial message: 

[Trace - 2:06:48 PM] Sending request 'initialize - (0)'.
Params: {
    "processId": 90837,
    "clientInfo": {
        "name": "vscode",
        "version": "1.59.0"
    },
<... deleted by me for brevity... >
    "workspaceFolders": [
        {
            "uri": "file:///Users/lee/proj/oss/lread/test-doc-blocks",
            "name": "test-doc-blocks"
        }
    ]
}
Followed by: 
Aug 12, 2021 2:06:49 PM org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer fireError
SEVERE: An error occurred while processing an incoming message.
java.lang.NullPointerException
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleRequest(RemoteEndpoint.java:279)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:190)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:194)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:94)
	at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:113)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(Thread.java:829)
	at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:553)
	at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)
After a little of this and that, I found that things start work fine after I delete my bb.edn file (on fresh start of vscode). I expect there is something ickity in my bb.edn file (or maybe something it references?), but not sure what yet. Note that clojure-lsp is working fine with rewrite-clj and its bb.edn file. Can try to provide more info/repro if this symptom is new to you.

all-clear 2
ericdallo18:08:29

hey! Could you check if that bug is related with this issue? https://github.com/clojure-lsp/clojure-lsp/issues/507

ericdallo18:08:55

If so, It was fixed on master but I didn't release a version of clojure-lsp yet 😅

lread18:08:05

Thanks so much @UKFSJSM38! That was it! For some reason I had :paths [script] in my bb.edn, changing to :paths ["script"] fixes!

ericdallo18:08:01

Sweet 🙂 Next clojure-lsp version will handle correctly both 🤞

❤️ 2
borkdude21:08:11

Hmm, :paths [script] probably isn't valid in the deps.edn world either, you should always be using strings here

ericdallo21:08:40

I thought the same, but from clojure-lsp side, it's better to avoid crashes like that I think

ericdallo21:08:59

it was easy to allow that as well, so why not

borkdude22:08:49

perhaps clj-kondo can warn about this, feel free to post an issue, we have a linter for deps.edn which we could probably re-use for large parts of bb.edn as well

ericdallo22:08:23

looks a good linter for deps.edn indeed

lread10:08:07

It turns out I made this mistake in cljdoc's bb.edn as well... so a linter would help protect the world from me anyways! simple_smile

borkdude10:08:58

issue please :) + optional PR. this isn't difficult to implement I think

borkdude11:08:23

btw, I still owe you a PR for rewrite-clj, I have it in my queue and will get to it, don't worry :)

lread12:08:52

Coolio! I can take a crack at the clj-kondo issue + PR.

simonkatz21:08:20

In Emacs, my lsp-ui sideline is slow to update (takes around 2 seconds) after executing a command using M-x ..., but almost instant when I execute the same command using the keyboard. For example, M-x next-line is slow, but down-arrow is fast. The video at https://user-images.githubusercontent.com/823295/129270365-7a455f7d-e18c-489a-b816-547aa3a0612c.mp4 shows this. Do other people have the same behaviour?

ericdallo21:08:02

That's really odd indeed, never saw this kind of bug

ericdallo21:08:36

I'd suggest you open an issue with that gif in lsp-ui, but before that, I'd try via lsp-start-plain.el

ericdallo21:08:21

To confirm it's not a issue with your emacs configuration

simonkatz21:08:07

Great! I’ll look at that tomorrow. Good to know about lsp-start-plain.

simonkatz11:08:30

FWIW, I looked into this and it turns out to be a general issue with post-command hooks in Emacs. Not a problem in lsp-ui itself. Reported at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50042

ericdallo12:08:33

Oh good to hear it