I think it’s possible to get completion from both LSP and CIDER at the same time, but I haven’t (yet) been able to get that to work. I’m in the same position, I want completion of loaded keywords. @U5H74UNSF gave some quite compelling keywords for why this is nice in https://www.youtube.com/watch?v=KKvancXJJJg, from Babashka conf last summer.

@U07FCNURX any repro I could try?

@UKFSJSM38 In my case I just added a new namespace, added a bunch of keywords in a plain vector on the top level, and added a require from user.clj. I later also added it to (def my-kws ,,,) to see if that made a difference. I have now started using the keywords in my code, referencing the def , but still no completion for the keywords. Restarting lsp didn't do anything either.

It's basically this:

@U07FCNURX we on purpose complete simple keywords (not namespaced ones) with only the available on current namespace, otherwise we would provide tons of keywords from the whole project

does cider provides all of them? or only the required ns that have keywords inside?

Turning off lsp-completion-mode falls back to CIDER, which does complete these. That being said, I understand your rationale. I'm not sure what is best in total.

I often use dabbrev-expand for stuff like that. (by default M-/ or C-M-/ to give you a selection you can narrow with vertico or whatever). It'll complete a word from any open buffer. It's well embedded in my muscle memory now, and works in zsh to complete arbitrary words from your history too.

Yes, I use hippie-expand in the same way, but the language specific expansions have a better hit-rate.

can't argue with that 😉

we could offer keywords in completion of the required ns, I think that's ok, I'd like just to avoid providing all keywords of a project which probably is not a good idea or what user wants most of the time

I just find it helpful to stop typos

I mean, when completing, we offer keywords only of the ns that are required

if we're taking feature requests, I'd quite like it to complete all fully qualified keywords (including ones expressed as ::thing in another namespace) and ideally include any aliases in the current namespace (so :some/thing will become ::s/thing` if I have an alias defined in the current ns)

does any of that make sense?

I think we already support that

any simple code snippet so I can understand better your idea?

Sure. Given these two namespaces, I currently get these completions (`lsp-version` returns LSP :: lsp-mode , Emacs 28.3, gnu/linux)

I'm wondering if I could get completions that look like this

:as-alias
  :require
  :scratch.other/keyword -> ::o/keyword
  :scratch/kw            -> ::kw
  missing                -> :fully-quallified/keyword
  missing                -> :scratch.other/keyword

so any keyword with a namespace across my project gets completed and if there is an alias locally in the buffer it's used in the completion text.

does that make sense?

hmm ... I'm not sure that all those completions are coming from lsp-mode ...

Hm, interesting, we are not returning indeed the ones from clojure-sample.bar ns:

your missings matches mine, I think we could improve that on LSP

ok ... I take it back ... trying to complete from k rather than :k gives me a different list

I think it's me expecting the : in the keyword to not be part of the matching algorithm (or something) 🤷

although it might be nice if :scratch/kw was ::kw in the scratch ns - or both options were available? ... idk ... feel free to tell me that it's not a priority, like I say, dabbrev-expand usually saves me from a couple of keystrokes 😉 and lsp-mode has been a great addition to my workflow. Many thanks Eric.

yeah, having both options would be nice but more complex to handle, I'd say is not a high prior, keyword completion is the hardest part of clojure-lsp completion logic, I'm constantly trying to improve it so feel free to leave an issue :)

👍 ... many thanks - I'll do that later, got to go now

lsp uses static analysis via clj-kondo you can unflag this symbol as follows:

{:linters {:unresolved-symbol {:exclude [roughly]}}}

@U04V15CAJ Feels like cheating, should I wrap the method with a function so that linter works for the function and method name would be excluded but would never be used in the code. Sorry, I am a bit inexperienced with this.

what you mean wrap with a function, can you give an example?

assert-exprs are a bit weird in that they don't create top-level symbols

See how matcher-combinators got around it: https://github.com/nubank/matcher-combinators/blob/master/src/cljc/matcher_combinators/test.cljc

then you'd require [matcher-combinators.test :refer [match?]] to get the symbol to "resolve"

@U04V15CAJ Well, something like this seems to work so far, where I change the name of the method and add a roughly function:

(defmethod t/assert-expr 'roughly-m [msg form]
  `(let [op1# ~(nth form 1)
         op2# ~(nth form 2)
         tolerance# (if (= 4 ~(count form)) ~(last form) 2)
         decimals# (/ 1. (Math/pow 10 tolerance#))
         result# (< (Math/abs (- op1# op2#)) decimals#)]
     (t/do-report 
       {:type (if result# :pass :fail)
        :message ~msg
        :expected (format "%s should be roughly %s with %s tolerance" 
                          op1# op2# decimals#)
        :actual result#})
     result#))

(defn roughly [op1 op2 tol] (roughly-m op1 op2 tol))

@U08BJGV6E, ahhh, I looked into it, its a bit over my head 🙂, I just do not have enough experience to do what is right.

basically you'd do your original defmethod

and additionally (declare roughly)

and then in the test ns you'd (:require [my-assertion.ns :refer [roughly]])

That seems to work, but I do like the function wrapper as I shared above, it provide syntax checking for me.

expectations uses a macro: https://github.com/clojure-expectations/clojure-test/blob/f21b9366f5c263bc2658a44b3726d96329a49362/src/expectations/clojure/test.cljc#L48-L51

ah, I like that - kinda like the one core.async uses

so you'd have your assert-expr roughly and then (defmacro roughly [op1 op2 tol] (throw (IllegalArgumentException. "Use roughly only in an (is ...) call, please")))`

that'll get you both syntax highlighting, docstrings, clj-kondo and lsp happiness, while also alerting you to misuses when not wrapped in an is call

and by throwing at macroexpansion time you're catching the usage error early, right?

That's not how Sean or I wrote it, but that might work! i haven't tried it

would be very nice if that is how it works

I mean, as opposed to it being a function which would throw when it got called

this would expand to a call to (throw ...), it wouldn't call throw during macro expansion

Oh yes my bad. Why is it a macro then?

Just curious

to make the stack trace point to the spot where it's called

if it's a plain function,t hen the stack trace will say "can't use it!" but point to the function's definition which is unhelpful in a large test suite

then you have to look at the stack trace to find out the offending line

Gotcha

I use eglot as my lsp client, and if I create an eldoc buffer(M-x eldoc or M-x eldoc-buffer), the documention all goes there

I'm using lsp-mode right now, maybe Eglot could be worth trying.

I should have written lsp-mode in my original post, it slipped my mind. Sorry.

if lsp-mode also uses eldoc to display the docs then the same eldoc buffer stuff should work

Great! Your comments made me find (setq lsp-eldoc-render-all t) which seems to be what I want. Thank you!

ooh, thanks. I like that