Fork me on GitHub
Slack Archive

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

2019-12-13

Channels

#cursive
<
2019-12-13
>
malesch08:12:42

In the debugger's "Evaluate Expression..." I am not automatically in the namespace of the breakpoint (in clojure.core instead) and therefore have to always prefix the namespace to resolve symbols e.g. to call local functions. Earlier I think this worked fine. Is there a setting to control this? I played around e.g. with "Evaluate form in REPL naemspace" but what unfortunately didn't help.

cfleming20:12:32

Yes, my apologies, this is annoying and I haven’t had a chance yet to try to figure it out.

michaelrkytch05:02:57

Was there any resolution for this issue?

p-himik09:12:08

It seems that it's impossible to use clojure.core/comment as a target of "Resolve %symbol% as..." But that would allow Cursive to not highlight some symbols introduced by macros as unresolved (e.g. if I create a let-like macro that accepts a keyword before the bindings).

cfleming20:12:20

@U2FRKM4TW You should be able to do that using the Specify… option, I think? If not, it’s possible that support is hard coded, I’d have to check.

p-himik21:12:26

@U0567Q30W Nope, comment is not there

p-himik21:12:36

There's a downside to using comment though. If my macro defines something, it will be left unresolved outside of the macro definition.

cfleming21:12:34

Ok, I’ll take a look at that.

p-himik21:12:16

"Language Intentions" is a really great feature - I've added quite a few PostgreSQL fragments there, and sometimes it really helps. It doesn't really matter (for me, at least) that in order to achieve it, I have to write some Java code fragments that use completely undocumented functions. As long as I have the relevant IDEA source code and some examples, it's fine.

cfleming21:12:52

Yeah, that’s my intention with the symbol resolution too, except the code would be Clojure and hopefully actually documented.

👍 4
cfleming21:12:26

I haven’t used that feature though, so I’ll look at how they’ve implemented it.

Drew Verlee19:12:15

Whats the best way to share formatting rules on a per project basis across intelliJ and spacesemacs (Which i understand is governed by clojure mode + cljm format rules). I imagine its a manual effort involving 1. having standard rules 2. having each project kept a configurations (.dir-locals and the cursive equivelent) I think clojure-mode allows for formatting rules to be attached to the clojure vars themeselves (for macros) is cursive utalizing the same thing? I'm very tired of having every small code change in a project massive change 100's of lines!

andy.fingerhut20:12:18

Because both of those editors reformat every line even if you do not edit those lines? If so, wow. I'd hope they could be configured not to.

andy.fingerhut20:12:43

Or maybe you mean touching one line of a function often leads one to reindent/format that entire function?

Drew Verlee20:12:50

I'm using spacemacs. If I edit a part of a hashmap, it reformates all of it. I can't accurately describe all the interactions, but they certainly aren't per line.

andy.fingerhut20:12:40

I'm pretty vanilla using Clojure-mode in Emacs with almost nothing else turned on. Tab auto-indents if I press it, but modifies no other lines other than where the cursor is.

cfleming20:12:47

In IntelliJ (which I should also document) the solution to the sharing is to use a Project scheme under Preferences | Editor | Code Style | Clojure.

cfleming20:12:02

Cursive doesn’t utilise the formatting spec in the var metadata yet, no, but it should hopefully be possible to match the formatting. If it’s not, I’d like to hear about the cases where you can’t.

cfleming20:12:09

re: how much gets formatted, Cursive will generally only auto-format single forms, and then you can choose to reformat more widely. The exceptions are things like maps and let-bindings if you’ve chosen to align the value.