Fork me on GitHub
#cursive
<
2019-08-23
>
caleb.macdonaldblack02:08:45

@cfleming I can do that but the exception is not useful. It tells me the line of the the code i sent to the repl. Not the line that threw the exception.

caleb.macdonaldblack02:08:22

Specifically I'm having this issue with the send <code> to REPL command.

caleb.macdonaldblack02:08:59

Actually sorry I do have the information I need in that exception.

caleb.macdonaldblack02:08:09

Thank you for the help

misha11:08:21

is there a (good) way to resolve these in .cljs files?

cfleming01:08:48

I’m going to be working on this shortly. I’m not sure yet how good I can make it, but the first thing I’m going to do is make the inspection less shouty.

👍 4
kenny23:08:04

It'd be super awesome if comment forms were a tad smarter. For example, if Cursive sees this

(comment
  (require '[compute.test-components.static-data :as static-data])

  (static-data/create-dunder-mifflin c)
  )
It could provide autocomplete for static-data/....

cfleming01:08:17

Good idea! That’s probably fairly easy.

👍 4
cfleming02:08:32

Thinking about this a little further, it’s hard to know how far to take it. Would you want def items from comments to show up in project structure, for example?

👍 4
cfleming02:08:10

Perhaps in project structure they should show up under a comment element there, and perhaps be rendered differently.

kenny02:08:55

Ooo def’s would be super cool too!

kenny02:08:29

Showing them under a comment element makes sense. I haven’t really used the project structure thing though.

cfleming02:08:48

I’m just worried about them being confused with proper code defs. For example, would you want them to show up in Go To Symbol…?

kenny02:08:01

Maybe one comment “context” per ns?

kenny02:08:58

Or if that’s too confusing, only within a single comment block.

kenny02:08:41

You definitely shouldn’t be able to resolve those things outside of the comment block though.

cfleming02:08:05

That’s what I thought. Unfortunately that’s tricky.

cfleming02:08:16

I’ll think about it.

kenny02:08:46

Tricky part is not resolving outside the comment?

cfleming02:08:07

Yeah, scoping where those symbols are visible.

steveb8n06:08:47

Could you do it the other way as well? I've noticed that autocomplete inside comments works differently from outside i.e. not at all. I've started embracing the fiddle file idea and this discourages it a bit

cfleming11:08:27

@U0510KXTU Autocomplete should work inside comment blocks. However highlighting is disabled there, because often comment block fragments are invalid code, or rely on a context that doesn’t exist at the time. So if you have some invalid code the autocomplete won’t work correctly there.

steveb8n12:08:36

Thanks. I'll watch for that.

kenny19:08:46

I did just encounter an interesting scenario, however. Yesterday I had an active REPL and was writing some stuff in a comment block. Everything was working. Today I opened a fresh REPL, load the ns and get a syntax error. I had code like this:

(comment
  (require '[compute.test-components.static-data :as static-data])

  (def data-comp (component/start (static-data/new-data-component {})))

  (def client (::static-data/client data-comp))
  )
The syntax error was talking about how ::static-data/client could not be resolved. Some more thoughts: - Allowing symbols to be resolved in within a comment block seems okay as long as they are highlighted as a warning saying "not available at runtime" or something like that. - Keywords in a comment block that use the reader shortcut should be highlighted as a error. Perhaps even having an alt+enter suggestion to create an alias in the actual namespace.