Fork me on GitHub

@teng What do you have that bound to? Send form before caret to REPL?


@guy Do you have any less or sass plugins, or anything like that? I seem to recall that those can cause problems sometimes.


yes thats right, Less plugin. I got it working eventually. Thank you though for replying ❤️


@souenzzo Thanks! That is indeed new.


@kenny It is extensible, but currently only by me - any requests?


Dang. I was hoping for open extensibility. We wrap a lot of the re-frame API functions (as suggested by the re-frame docs) so the navigate to keyword would not work for our wrapped function.


So you should be able to use “Resolve as…” for that.


I’ll see if I can get the fix into the next build to allow that to be specified for any function, otherwise you can work around it by hacking a config file.


Oh cool. As long as there is some sort of hack to get it to work that would be awesome.


@ikitommi So with defmethod, you can navigate to the defmulti from the symbol rather than the keyword - did you need something else from that?


@cfleming oh, that. I think that’s a great way to do this. And actually, despite we are registering the defmethods with qualified keywords as dispatch values, the actual calls to defmulti are done with a map or such, so there isn’t (usually) a case that one need to navigate from the defmulti invocation parameter to the actual defmethod.

(defmulti kikka :type)

(defmethod kikka ::kukka [_])
(defmethod kikka ::kokko [_])

;; it's just a map, not a plain keyword, so no need to navigate from `kikka` to the actual implementation...
(let [m {:type ::kukka}]
  (kikka m))


thanks, all good 🙂


One could use identity instead of :type in the example, in case on could navigate from (kikka ::kukka) to the actual ::kukka defining defmethod but I think that’s not a common case.


Oh, I see - to navigate from the data itself to the multimethod impl handling that data.


That actually might be quite nice, since you could use “Show implementation” to quickly see the handling code from a use of the data.


@maik.teske Sadly JS interop is just hard to resolve correctly. I’m planning to improve it shortly, and there’s also an issue slated to be fixed soon to allow adjusting the severity of that warning:


I’ve seen that NPE reported but not been able to reproduce it, I’ll try right-clicking js/document, thanks.


@dmarjenburgh That is definitely a bug, yes. Does invalidating caches fix it?


I feel like ctrl+clicking on a :require alias should show you all the usages of that alias in the current ns instead of taking you to the actual ns. If you ctrl+click on the ns itself, then you'd be brought to that ns. For example, clicking myns below would show you all the usages of the myns alias in the current ns.

(ns some.ns
  (:require [my.ns :as myns]))
Would this behavior make sense to add? It'd be a breaking change so it'd probably need a settings option.


wrong channel


@cfleming Thanks for the clarification. I'll just disable the highlighting of unresolved references for now. regarding reproducing the NPE with the following snippet:

(.getElementById js/document "app")
press CTRL and hover over .getElementById until "show usages of symbol 'getElementById'" pops up and while keeping pressed CTRL move the mouse to the right and hover over 'document'. The NPE gets thrown when the new 'document ' pop up is shown


@cfleming added an example.


@cfleming Now I must write: ((fn [] a)) …to print out a.