How are they defined? I suspect it’s because they’re defined via a macro rather than how they’re referred.

Yep https://github.com/redplanetlabs/specter/blob/master/src/clj/com/rpl/specter.cljc#L679

defnav is a macro

this is the result in a 2kloc integration test. is a bit difficult to see test failures

any workarounds?

Yep, resolve defnav as def: https://cursive-ide.com/userguide/macros.html#customising-symbol-resolution

@U0510KXTU ^^

cool. I didn’t connect the dots…that I can mark the macro used instead of the symbols created by the macro

trying now…

hmm. can’t figure it out. tried resolving ALL as com.rpl.specter/ALL but it won’t accept it

also tried resolving defnav as def. didn’t change either

Resolving defnav as def should definitely do it.

One sec, I’m down in the weeds on another problem right now, will take a look in a bit.

no probs. this is not urgent. just a nice to have

There isn’t at the moment but this is something I’m going to fix very soon.

👍 will be great

cursive it totally the best support for clojure coding so far just saying to make you happy 😉

I am happy 🙂

You can always rebind action keys at Preferences | Keymap - no-one else has mentioned it, I think opinions differ on which actions are essential 🙂

fair point. thanks

actually… i filed a bug about this years ago: https://github.com/cursive-ide/cursive/issues/1892

Whoops, I stand corrected!

It’s a problem though - IntelliJ binds nearly all the keys to actions. For a long time Cursive didn’t bind anything by default and allowed users to set it up themselves, but then users complained about that (much more than they have complained about built-in actions being overridden).

were those complaints before cursive introduced parinfer? if that’s the case then i can totally get behind their complaints since back then paredit was the only option and it would make total sense for cursive to offer the default paredit key bindings out of the box. but with parinfer, especially with version 3, i would expect the paredit key bindings to be optional and can be switched on/off with one check box. it happened a few times to me, where i had to manually remove those key bindings one at a time for our new users because they kept getting surprises and didn’t really know what was happening as they just didn’t know such a thing as paredit and its key bindings.

Well, previously the way it worked was that Cursive didn’t bind any keys at all, and there was a preference pane which users could use to apply different sets of keybindings, i.e. bulk-enable keybindings. It was really confusing for users to understand. The problem with having those bindings be optional is that it involves modifying the keymap, which are immutable by default (if you want to modify some key bindings, you have to create your own keymap based off one of the immutable default ones). Getting users to understand how to configure that when they click a checkbox is tricky.

yes, i remember that. i was among those who were confused. truth be told, i still don’t understand how it worked to this day. 😁 yeah, i’m aware that intellij idea key maps are immutable but if a plugin can bind (dynamically) some keys after installation without changing the current key map then, i thought, they should be able to dynamically unbind those keys as well?

anyhow, this is just a minor inconvenience (some times.) an ideal experience, IMHO, would be: • having a separate checkbox for toggling structural editing/navigation • parinfer by default (with structural editing/navigation off and enabled) for new installation only • if user switches to paredit, turn structural editing/navigation on and leave it disabled • if user switches back to parinfer, turn structural editing/navigation off but leave it enabled for user to toggle it on, if she/he chooses to

Ok, thanks for the thoughtful feedback. I’ll take another look at this and see if I can make that work. I agree that parinfer should be on by default rather than paredit, I’ve been meaning to change that for a long time.

Did they give you any indication of which objects?

Do you have a copy of the memory dump?

BTW was the memory dump you sent them a text file, or the actual hprof dump?

Also, are you using parinfer?

Hi @U0567Q30W, sorry for not responding sooner, I didn’t see your prior messages. I am using parinfer yes. I sent them the hprof dump zipped which came out of their memory dump function. I have two such dumps, happy to share them if you have some way you prefer to receive them? They didn’t give me any details no.

Ok, no worries. I have some dumps myself which show a potential problem with the parinfer code, and I’m trying to figure out what the dumps mean.

To be clear, I’m not certain that the issue is coming from parinfer, just that I am using it =)…

Actually, it would be interesting to see yours. I don’t have a preference, can you send them via a file-sharing service of some kind?

Sure, I suspect that it might be though 🙂

Um sure, give me a moment…

If not I can probably receive them via Keybase

Oh yea, we can use keybase =)…