Fork me on GitHub
#cider
<
2018-03-17
>
wusticality14:03:10

quick question - whenever I run cider-apropos-documentation, it shows the docstring in the buffer but hitting RET just shows Symbol clojure.core/defn not resolved - any ideas?

bozhidar16:03:21

Have you compiled the current buffer?

bozhidar16:03:30

@mikerod I’m not sure I understand the problem. What do you expect to see?

mikerod16:03:23

@bozhidar it should be compiled yeah

mikerod16:03:27

It just wasn’t a useful diff

mikerod16:03:45

It just showed me my un-eval’ed code (expected) vs evaluated forms (actual)

mikerod16:03:58

maybe that’s it is all its meant to do, but it was like 2 big maps

mikerod16:03:13

so my expected buffer was nothing but what I already had in the code

mikerod16:03:28

the actual was 2 big evaluated maps in the = form. I guess just like standard clojure.tset

mikerod16:03:10

I was thinking maybe something more like humane-test clj lib where I think it does something like a data diff on big things like that. It’s fine. I just wasn’t sure what this feature was for and couldn’t find any examples out there demonstrating it being used

bozhidar16:03:06

Hmm, didn’t @xiongtx already do this in 0.17?

bozhidar16:03:30

I tested this locally now and the output has just values for me.

mikerod18:03:01

I can dig a bit more

xiongtx19:03:36

I cannot reproduce @mikerod's strange outcome. Is there a minimal reproducible repo? Also make sure you're using latest CIDER to reproduce, and that you don't have anything in your .lein/profile.clj that could be modifying the test output. There is, however, a 🐛 w/ the interaction b/t cider-test-ediff and the diffing functionality. With all comparisons besides = (which we treat specially), the expected and actual are something like:

expected: (> 1 2)
actual: (not (> 1 2))
The cider-test-ediff logic will look for the second form in actual, expecting the first to always be not. W/ =, however, we've modified the expected and actual. E.g. for (= 1 2 3):
expected: 1
actual: (2 3)
This means that cider-test-ediff doesn't work properly in case of =. However, this seems to have nothing to do w/ @mikerod's result.

xiongtx19:03:03

@bozhidar It seems that the cider-test-ediff functionality is really only designed w/ (= a b) in mind. It doesn't handle (= a b c), (> a b), etc. gracefully. W/ (> 1 2), for example, it will display (> 1 2) in both buffers, which isn't very useful.

xiongtx19:03:45

Oh, I'm able to reproduce @mikerod's result by using

(def a 1)
(def b 2)

(deftest foo-test
  (is (> a b)))
Given this, it's not clear that cider-test-ediff was ever useful :face_with_rolling_eyes:. From clojure.test's own documentation: https://github.com/clojure/clojure/blob/clojure-1.9.0/src/clj/clojure/test.clj#L40-L42 > The "expected:" line shows you the original expression, and the "actual:" shows you what actually happened.

xiongtx19:03:49

@mikerod You should be able to see the diff in the *cider-test-report* buffer directly if you are using latest CIDER. That's what https://github.com/clojure-emacs/cider/pull/2172 added.

xiongtx20:03:50

@mikerod https://github.com/clojure-emacs/cider/pull/2241 should now ediff the proper values. Give it a try.

mikerod20:03:13

@xiongtx Sorry for the delayed response. I am actually still using Cider 0.16.0. My case was with = and 2 maps. I never messed with it enough yet to have a minimal repro. I will look at what you have linked here and I’ll see if I can give it a shot. The one thing that was holding me back from Cider 0.17 was that it broke with cljs or something (I just heard, didn’t experience), so I delayed since I’m still using it with a good amount of both clj and cljs.

mikerod21:03:40

Thanks for taking a look at it by the way!

gonewest81822:03:35

Indentation in cider-test.el is the error — but on my iPhone it’s difficult to see exactly what the complaint is.

xiongtx22:03:05

Don't know what indentation error there is--`indent-defun` isn't changing anything.

gonewest81823:03:50

The diffs in Emacs 25+ are a little more instructive.

gonewest81823:03:27

It wants the conditions aligned with cond rather than indented 2 spaces. I’m getting the same indenting in the *scratch* buffer.

xiongtx23:03:07

I'm using default Emacs Lisp indentation. cond should be indented 2 spaces.

(cond
  (foo bar)
  (baz quux))

gonewest81823:03:01

If that’s the case then I wonder how am I not getting the default, and neither is elisp-lint… ?

xiongtx00:03:46

Ah, sorry. I had lisp-indent-function set to common-lisp-indent-function.

xiongtx00:03:14

However, the CL version looks nicer, and matches that of clj :man-shrugging:

gonewest81801:03:36

I definitely see the appeal.

bozhidar02:03:46

But we should stick to the mainstream Elisp indentation conventions - otherwise a lot of people would have trouble while contributing.

wusticality22:03:56

curious if anyone has any ideas on my issue

wusticality23:03:36

selecting any documentation via cider-apropos et al just says the symbol is unresolved

xiongtx23:03:45

Try cider-refresh.

gonewest81823:03:22

Do you mean the symbol whose documentation you are selecting is unresolved?

gonewest81823:03:40

So, for instance if I cider-apropos I get this

gonewest81823:03:13

clojure.core/cond
  Macro: Takes a set of test/expr pairs.
clojure.core/cond->
  Macro: Takes an expression and a set of test/form pairs.
clojure.core/cond->>
  Macro: Takes an expression and a set of test/form pairs.
clojure.core/condp
  Macro: Takes a binary predicate, an expression, and a set of
  clauses.
clojure.core/reader-conditional
  Function: Construct a data representation of a reader conditional.
clojure.core/reader-conditional?
  Function: Return true if the value is the data representation of a
  reader conditional
clojure.core/second
  Function: Same as (first (next x))
clojure.tools.reader.impl.utils/second'
  Function: (not documented)
cljs-tooling.util.misc/cond-let
  Macro: An implementation of cond-let that is as similar as possible
  to if-let.

gonewest81823:03:21

And selecting, e.g. the first entry gets me the docs for “cond”. But you are saying, you select the first entry and you get “Symbol clojure.core/cond not resolved” …. is that accurate?