I actually didn’t even know that ::keys and ::a/keys in destructuring was a thing - https://clojure.org/guides/destructuring makes no mention of it.

@tony.kay https://github.com/cursive-ide/cursive/issues/2178

😄

@tony.kay Actually… those cases should already be handled, and there are even tests for them. I’ll check what’s going on there.

@tony.kay Right, so I have a test that:

(let [{::keys [foo bar]} item] ...)

(let [{:keys [:other/baz ::bar]} item] ...)

Which is not exactly the transformation you wanted, but is correct.

Are you not seeing anything like that happening?

That does work, I just tested it. Also:

(ns cursive-2178.core
  (:require [clojure.string :as str]))

(let [{::str/keys [a b]} nil])

(let [{:keys [:other/baz ::str/b]} nil])

If I rename ::str/a to :other/baz

have there been recent fixes?

I just got an update notice

(I had forgotten those destructuring options even existed, but I did fix them back in the day)

No

That hasn’t changed since my memory fade-off point, since I had forgotten they were supported 🙂

so you cannot repro?

I can make failing cases for you if you want

Yes please!

ok, just a few

OH…these are CLJC files, if that matters

Hmm, I wonder

Let me check

(ns com.fulcrologic.fulcro.b
  (:require
    [clojure.spec.alpha :as s]))

(s/def ::y number?)

-----

(ns com.fulcrologic.fulcro.a
  (:require
    [com.fulcrologic.fulcro.b :as b]
    [clojure.spec.alpha :as s]))

(s/def ::x int)

(defn f [{::keys   [x]
          ::b/keys [y]}])

both cljc files

try renaming ::y in b

Also, while we’re talking CLJC…doc string lookup fails in IDE if you’re in a CLJS file that uses a func from a CLJC file

even though the function is obviously available

Yeah, I can see that rename failing.

I’ll debug that, thanks.

welcome…thanks for looking into it

Ohhhh

I see what the problem is.

That keyword is used with s/def, which means that they get treated as if they were definitions.

But the destructuring should still work.

@tony.kay ^^^

Ugh, that’s tricky.

destructuring works, but renaming does not

I see…so treating them like definitions is sort of like the problem of moving functions among nses

Yeah, I mean the renaming should update destructurings.

Find usages is also affected I think.

Yes, it is, now that you say it

In fact, there’s an issue about that one - https://github.com/cursive-ide/cursive/issues/1908

These frankenkeywords are getting tricky.

I bet

Also, if you c/p some code around, Cursive isn’t smart enough to find that ::alias/keyword can be required. So the only real way to check whether you missed a require for a aliased keyword is trying to load into the repl

Is anyone else having an issue where IntelliJ/Cursive keeps recategorizing resource directories as source directories? I’m trying to isolate the problem, and thought I’d ask.

@lennart.buit Yes, it would be nice if Cursive auto-prompted in that case, you’re right.

@kingmob No-one else has reported that, no. Are you manually categorising them as resource dirs? i.e. by right clicking in the project view?

@cfleming Yes, but it never lasts. It didn’t use to be a problem, but I can’t figure out what change caused it.

So when you sync your lein/deps project, Cursive will re-mark all the directories to what the project file specifies them as. Clojure doesn’t really make the distinction between source and resource folders, there was an issue about this ages ago, I’ll see if I can dig it up.

Why do you need it marked as a resource folder?

…because miscategorized dirs offend my librarian ancestors? 😄

It’s not that big a deal, it’s more like an itch that won’t go away.

Here it is: https://github.com/cursive-ide/cursive/issues/241

Thx!

Basically, Lein and IntelliJ treat resource folders in different ways. The tl;dr is you should just leave it as Cursive sets it 🙂

Your librarian ancestors will just have to turn in their graves.

I must now slit my wrists with a sharp bookmark.

In all seriousness, thanks for checking, @cfleming!

That is as it should be, yes.