This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-23
Channels
- # announcements (7)
- # babashka (40)
- # babashka-sci-dev (74)
- # beginners (74)
- # calva (31)
- # cider (11)
- # clj-kondo (22)
- # cljs-dev (1)
- # cljsrn (1)
- # clojure (70)
- # clojure-brasil (3)
- # clojure-dev (12)
- # clojure-europe (39)
- # clojure-nl (2)
- # clojure-norway (15)
- # clojure-uk (9)
- # clojurescript (69)
- # community-development (2)
- # conjure (1)
- # core-async (3)
- # cursive (1)
- # data-science (1)
- # datalevin (13)
- # datomic (17)
- # emacs (42)
- # events (1)
- # fulcro (16)
- # graphql (9)
- # helix (1)
- # holy-lambda (14)
- # honeysql (2)
- # hugsql (3)
- # hyperfiddle (5)
- # kaocha (10)
- # lsp (41)
- # luminus (5)
- # malli (7)
- # meander (3)
- # membrane (47)
- # off-topic (23)
- # podcasts (2)
- # polylith (34)
- # rdf (4)
- # re-frame (2)
- # releases (2)
- # remote-jobs (1)
- # ring (16)
- # shadow-cljs (111)
- # spacemacs (6)
- # test-check (2)
- # tools-deps (19)
Is there a reason move-coll-entry-up/down
uses a the full range of the loc in show-document-after-edit
? I believe the intent is to keep the cursor position as you repeat, but in vim because the range is more than one char it selects the range and breaks repeatability. I think a change like (assoc cursor-position :end-row (:row cursor-position) :end-col (:col cursor-position))
would be ok if i have the intent correct.
hum, I think that was intentional, looks like vim has a different behavior, @U07M2C8TT knows more about that feature
@U0BUV7XSA that’s an accident and your proposed fix looks good. Thanks for tracking that down
And yes, the intent is to maintain position, not to select a range
Thanks! It was a fun introduction to clojure-lsp development. Now I’m addicted. :)
Hi folks. Consider this situation, in which the point is just after the last s
character and str
is not required.
If I ask for the code actions with the point in that position, I don’t get the require suggestion. If I mock back one char, I get it.
Is this expected?
(I’m not using evil mode)
> If I ask for the code actions with the point in that position What position exactly?
well, clojure-lsp should provide that in any place of that line, you should see the code action to add the require even not inside that paren, if in the same line
If the point is not above the chars marked by flymake, I get those actions:
Move to let
Cycle privacy
Clean namespace
Thread last all
Extract function
Thread first all
Move coll entry up
Move coll entry down
Create test for 'clojure-service-request?'
> clojure-lsp should provide that in any place of that line out of curiosity, if there were two possible additions of requires, what would be the expected behaviour if I ask for code actions in a position that is not over any of them?
> out of curiosity, if there were two possible additions of requires, what would be the expected behaviour if I ask for code actions in a position that is not over any of them? do you have a example? it's not clear to me
(str/foo a b) (+ 1 2|)
with the cursor as |
, clojure-lsp should suggest add clojure.string require
even if not on that form, but on same line> do you have a example? it’s not clear to me example:
(str/foo) (set/baz) foo|
where the cursor is |
, and neither str
or set
are required yet. If I ask for code actions with the point in |
, should it suggest requires for both str
and set
?When you have time, do you mind sending me lsp-mode
logs please?
For a sample namespace like
(ns foo)
(str/foo) bar
and with the point somewhere in bar
, for exampleOr, if you know the answer w/o looking at the logs, should the client send the whole line as range?
lsp-mode send this range:
{
"start": {
"line": 2,
"character": 12
},
"end": {
"line": 2,
"character": 12
}
}
this is the full request:
{
"textDocument": {
"uri": "file:///home/greg/dev/clojure-lsp/lib/src/clojure_lsp/foo.clj"
},
"range": {
"start": {
"line": 2,
"character": 12
},
"end": {
"line": 2,
"character": 12
}
},
"context": {
"diagnostics": [
{
"range": {
"start": {
"line": 2,
"character": 1
},
"end": {
"line": 2,
"character": 8
}
},
"severity": 2,
"code": "unresolved-namespace",
"source": "clj-kondo",
"message": "Unresolved namespace str. Are you missing a require?",
"tags": []
},
{
"range": {
"start": {
"line": 2,
"character": 10
},
"end": {
"line": 2,
"character": 13
}
},
"severity": 1,
"code": "unresolved-symbol",
"source": "clj-kondo",
"message": "Unresolved symbol: bar",
"tags": []
}
]
}
}
I just checked that the range sent by eglot
is correct:
:range
(:start
(:line 2 :character 13)
:end
(:line 2 :character 13))
for this file
(ns foo)
(str/foo) bar
On the other hand, if the point is over the highlighted error, it works:
(:jsonrpc "2.0" :id 2189 :method "textDocument/codeAction" :params
(:textDocument
(:uri "file:///Users/<redacted>/foo.clj")
:range
(:start
(:line 2 :character 7)
:end
(:line 2 :character 7))
:context
(:diagnostics
[(:range
(:start
(:line 2 :character 1)
:end
(:line 2 :character 8))
:severity 2 :code "unresolved-namespace" :source "clj-kondo" :message "Unresolved namespace str. Are you missing a require?" :tags
[])])))
Oh, I think I found the difference between eglot
and lsp-mode
requests (just installed it).
In the textDocument/codeAction
request, the range
is indeed identical, but lsp-mode
has an additional context
key with the following contents:
"context": {
"diagnostics": [
{
"range": {
"start": {
"line": 2,
"character": 1
},
"end": {
"line": 2,
"character": 8
}
},
"severity": 2,
"code": "unresolved-namespace",
"source": "clj-kondo",
"message": "Unresolved namespace str. Are you missing a require?",
"tags": []
}
]
}
Yeah, it’s not sending it. I confirmed it with the logs. Thanks for the help, I just started a discussion in eglot
repo
Fixed by https://github.com/joaotavora/eglot/commit/03fc783c4b701fc8c19096b7167b73bd5d8f63a8 It’s not considering the whole line, but the thing at point. I think it makes sense as well.