Fork me on GitHub
Slack Archive

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

2022-11-25

Channels

#lsp
<
2022-11-25
>
practicalli-johnny05:11:43

After renaming a few namespace successfully, I seem to have to restart the clojure-lsp backend so the new namespace and function is recognised in other namespaces. namespaces not appearing in completion and being marked as unknown I assume clj-clojure should automatically add the new namespace and functions pretty much instantly. Is this a known issue? It could be an Emacs LSP UI issue as I am using Emacs (will try this on Neovim too) I'll keep an eye out and see if it keep happening (I'll be refactoring several projects soon) and create a reproducible repo if it does

ericdallo10:11:24

Good catch, maybe this could happen if you rename from the usage and not the definition of a function, so maybe a bug. A repro would help a lot indeed

practicalli-johnny19:11:04

Pretty sure I renamed the ns definition, but will doe some explicit tests this weekend and report back. Maybe I manually changed the function definition. Something to test anyway

ericdallo19:11:49

hum, interesting, yeah, if you find a way to repro that would certainly help, thanks

Martynas Maciulevičius09:11:15

Is there an option to not auto-fix the imports when I add a new import? When I work on a new namespace and add a new import using 1: Add require '[ :as io]' × 1 then unused imports disappear. But actually I used them because I have a bunch of commented-out code that I was testing with. How is this option called if it exists? Example: Take the buffer from below and go to io/copy line and fix problem Add require '[ :as io]' . Then [clojure.core.async :as core-async2] disappears but I want that require to not be removed. I don't really care about sorting of the imports as well as it could be done when I do clean on the namespace. 

(ns basic-http-server.new
  (:require
   [clojure.core.async :as core-async1]
   [clojure.core.async :as core-async2]))

(comment (do
           ;some core.async1 stuff
           core-async1/hi
           ))

#_(do
    ;some core.async2 stuff
    core-async2/hi)

(io/copy)

ericdallo10:11:55

Yes, there is a setting for that

Martynas Maciulevičius20:11:11

I tried it but I think it didn't work. This config also sorts the imports and removes the unused ones (I copied it from the example): 

{; 
 :clean {:automatically-after-ns-refactor false
         :ns-inner-blocks-indentation :next-line
         :ns-import-classes-indentation :next-line
         :sort {:ns false
                :require false
                :import false
                :import-classes {:classes-per-line 3} ;; -1 for all in single line
                :refer {:max-line-length 80}}}}

ericdallo20:11:29

the sort is happening because it's being called the clean-ns which should not if you set :automatically-after-ns-refactor to false, your config looks correct though

sheluchin16:11:24

I think the https://github.com/clojure-lsp/clojure-lsp/blob/2022.11.03-00.14.57/lib/src/clojure_lsp/api.clj#L273-L280 for dump is inaccurate. The result is actually in the shape {:result-code 0 :message "..."} where the :message is the EDN as a string.

ericdallo16:11:52

oh my bad, this makes sense for other commands, actually they add custom fields to the returned map, but I forgot to do this one on dump

ericdallo16:11:18

so we should change to return somethong like: 

{:result-code 0
 :result {...}}

sheluchin16:11:41

Not sure about the way the schema should change to be consistent with other parts of the API, but asking for EDN output should return EDN somewhere. Would you like me to log an issue for this, @UKFSJSM38?

ericdallo16:11:15

yep, agreed, I can fix that, so please open a issue!

sheluchin19:11:06

Would it be within scope for clojure-lsp to include :lib (git or Maven lib name (https://clojure.org/reference/deps_and_cli#find-versions)) as part of the some of the dump data?

ericdallo19:11:50

Good question, is the only way to find that is via clj -X:deps find-versions ?

ericdallo19:11:47

because clojure-lsp only runs clj -Spath to get the classpath to pass to kondo later, nothing more, so we shell out only once

sheluchin20:11:17

find-versions takes this value. You can get a list of these values using clj -X:deps list. I started a https://clojurians.slack.com/archives/C03S1KBA2/p1669404159066839 to try to find out more, in case anyone is curious.

sheluchin00:11:58

@UKFSJSM38 I think that getting a list of top-levels deps from a project could potentially be added to tools.deps (without necessarily downloading each jar). Please see this https://clojurians.slack.com/archives/C03S1KBA2/p1669418060956569?thread_ts=1669414010.064509&amp;cid=C03S1KBA2. I'm just wondering if you think this idea has some value to clojure-lsp.

ericdallo00:11:21

Looks interesting, some concerns and tradeoffs: • say someone download a project and open on editor with clojure-lsp, we want to compute classpath and download deps since clj-kondo needs real code to compute analysis. • on other hand, this may be useful for dump feature and any other API call like format/clean-ns which don't require scan external classpath, so we don't need to actually download any external lib

sheluchin15:12:22

@UKFSJSM38 sorry for the delayed response. I'm still thinking about this thing. I don't think it would be useful for those particular API examples, but it does illustrate that there is certain category of functions that don't require having the external lib code. What I ultimately want is for usages analysis to have a :lib key so that it can be easily understood exactly what the usage is referring to, beyond just the namespace it's from. :to contains the source ns, but without :lib, it's hard to understand exactly where the namespace is coming from to link it a library. Do you have any thoughts on the feasibility of adding this data to LSP's dump output (if you consider it in scope)?

ericdallo16:12:40

yeah, I can see how convenient this is, I wonder though if clj-kondo could add that as clojure-lsp just pass the jars for kondo, which kondo opens the jar to do its analysis, kondo probably have access to the jar pom.xml and other info, maybe we could retrieve that from there? As last resource, we could consider adding to clojure-lsp, but it'd need more effort