When I evaluate (k/run :unit) in a lein REPL, I get:

metamorph.core=> (k/run :unit)

;; stuff ...

Ran 1 tests containing 1 assertions.
0 failures, 0 errors.
[(F)(FFF)(.)]
Randomized with --seed 391347173

FAIL in metamorph.core-test/a-test (core_test.clj:11)
FIXME, I fail.
Expected:
  0
Actual:
  -0 +1

(k/run :unit)
[
(
F
)
(
.
)
(
F
F
F
)
]

Randomized with --seed 1752511405

FAIL in metamorph.core-test/a-test (core_test.clj:11)
FIXME, I fail.
Expected:
  0
Actual:
  -0 +1

For some reason, everything is the same except for the [(F)(FFF)(.)] summary, which in Calva gets split over newlines. Given that the rest looks fine it doesn't seem newline encoding related? I was wondering if people who use Kaocha with Calva have seen this issue and hopefully fixed it.

Could it be a pretty printing issue? What does it look like with pretty printing disabled? That said, it does look like there is more to it than this...

Turning the pretty print toggle on or off doesn't change the output here (I tried per your suggestion)

Thanks for testing that! Can you check the nREPL message log and see what's coming back there?

Do you mean the terminal output of the jacked in REPL?

(I'm only vaguely familiar with the underlying technology)

There is a command in Calva that turns on nREPL message logging. It will open a VS Code Output channel and show what's going back and forth between Calva and the nREPL server.

Ahh, nice, I see it 🙂. This is sent:

-> sent
{
  id: '136',
  op: 'eval',
  session: 'abc677b9-dbad-4955-b137-7e4c12c174a7',
  code: '(k/run :unit)',
  'nrepl.middleware.print/options': { 'right-margin': 120, length: 50 },
  'nrepl.middleware.print/print': 'cider.nrepl.pprint/pprint',
  file: '/home/bartkl/Programming/alliander-opensource/metamorph/.calva/output-window/output.calva-repl',
  line: 191,
  column: 1,
  stdout: [Function: stdout],
  stderr: [Function: stderr],
  pprint: true
}

And then I receive those characters one by one (I can cite some or all of those if you want as well)

(and of course, pprint: false in case I disable that)

Receiving the characters one by one will result in them being printed on separate lines, for sure.

Did you say you've tested this in emacs?

Yes indeed. I guess the question is why we do receive them one by one then. No, not in Emacs, although I can try (I have an Emacs installation here). I did try in a lein REPL from a Bash shell (same project), and there this issue doesn't occur.

I know Emacs has an nREPL message log (that's where Calva's log is inspired from). Maybe line has one as well.

I'm just trying to understand what's going on.

I appreciate it! I'm going to try and see how I can see the nREPL log from lein

You receive them one by one because kaocha sends them one by one: https://github.com/lambdaisland/kaocha/blob/f97d9fd375d7fe1a8642d2905ccaa651c6650c38/src/kaocha/report.clj#L124-L166

at the command line, print doesn't include a newline, but it looks like calva might be adding the newline to all new calls to stdout?

Not to stdout, it shouldn't add this:

(doseq [x (range 10)]
  (print x))

0123456789
nil

And actually my test wasn't all that useful:

{
  id: '85',
  out: '0123456789',
  session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf'
}

What if you do (doseq [x (range 10)] (print x) (flush))?

Thanks. That exposes the problem.

0
1
2
3
4
5
6
7
8
9
nil

-> sent
{
  id: '94',
  op: 'eval',
  session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf',
  code: '(doseq [x (range 10)] (print x) (flush))',
  file: 'Untitled-2',
  line: 8,
  column: 1,
  stdout: [Function: stdout],
  stderr: [Function: stderr],
  pprint: true
}

<- received
{ id: '94', out: '0', session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf' }

<- received
{ id: '94', out: '1', session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf' }

<- received
{ id: '94', out: '2', session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf' }

<- received
{ id: '94', out: '3', session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf' }

<- received
{ id: '94', out: '4', session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf' }

<- received
{ id: '94', out: '5', session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf' }

<- received
{ id: '94', out: '6', session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf' }

<- received
{ id: '94', out: '7', session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf' }

<- received
{ id: '94', out: '8', session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf' }

<- received
{ id: '94', out: '9', session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf' }

<- received
{
  id: '94',
  ns: 'user',
  session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf',
  value: 'nil'
}

<- received
{
  id: '94',
  session: 'c60041db-6d03-4be6-8d47-4f4bc78b0fdf',
  status: [ 'done' ]
}

I think that could be fixed in Calva. Just need to figure about some implications. When should we be adding the newline and when shouldn't we...

Good progress! Is the log still desired?

Ah, I get it now. That's subtle

I now want an issue on Calva. 😃 You can include the log there. Perhaps use a <detail><summary>.

I'm going to submit it right away, thanks all for helping out

Not sure what you mean by <detail><summary> . Are those each HTML tags I can use for markup in the GitHub issue?

Yes, and I might remember the HTML wrongly. 😃 But I know Github Markdown does not strip it.

Found it (https://gist.github.com/scmx/eca72d44afee0113ceb0349dd54a84a2)! You were close 🙂. Didn't know about this. Nice.

https://github.com/BetterThanTomorrow/calva/issues/1826

Wanna hava a go at the issue, @U03BYUDJLJF? It'll take you to fun and slightly messy parts of the Calva code base, 😃

Not sure if I'm up for that job (I'm still a novice), but perhaps I can try 🙂. If I can get some guidance here and there

At the very least I can promise you to follow the code guidelines neatly 😉, I'm somewhat of a perfectionist. But again, my Clojure XP level might be a little sub-par for this

(I'll continue the discussion on GitHub)

The #announcements posts mentioned: https://clojurians.slack.com/archives/C06MAR553/p1660083974123739

Thanks @U0ETXRFEW and all you Calva users for doing some additional testing. It really helps make sure clojure-lsp is solid.

Known issue with this build of clojure-lsp: documentation is missing from completion items. https://github.com/clojure-lsp/clojure-lsp/issues/1181

^ should be fixed by this build: https://clojurians.slack.com/archives/C032YH7P0R2/p1660239808828519

Thanks for reporting. FYI, while gifs and videos are great, it would have been great with the text as well. It's much easier to paste it and reproduce, than having to re-type and possible do it wrong and such.

Oops! Sorry 😄

(comment
  (zip-walk (fn [zl zr] 
              (let [nl (z/node zl)
                    nr (z/node zr)]
                (if (plain? nl)
                  (prn "self:" (= nl nr))
                  (prn "tag:" (= (:tag nl) (:tag nr))))
                zl))
            (xml-zip (transform [:div "hello" {:el :some-el}]))
            (xml-zip (transform [:div "world"]))))

seems like it happens pretty much in any place, though. Weirdly enough, when you backspace, it puts the cursor on the previous line correctly :thinking_face:

I can't immediately reproduce:

weird, will check my Calva settings in a bit and see if it's anything I might have tweaked

in your GIF though, shouldn't there be 1 extra space to match the next line's indentation?

Yeah, that's weird. I can't repro that either now...

Hahah, the logical conclusion is that every time I ask about a problem, it gets fixed automatically

For the record: The indentation does not work by matching the indent of the next line. I guess you didn't mean it that way, but just to be clear.

What's your setting for calva.fmt.newIndentEngine?

tried with both "calva.fmt.newIndentEngine": true, and "calva.fmt.newIndentEngine": false, but no difference, same issue with both

That's super extra interesting.

here is another problem area:

(defn html-zip
  "Returns a zipper for HTML DOM elements, given a root element."
  [root]
  (z/zipper #(= (.-nodeType %) html-node-type-element) 
            #(array-seq (.-childNodes %)) 
            (fn [node children]
              (throw (js/Error. "html-zip: don't know how to create new nodes")))
            root))

Maybe you have some other extension that interferes? Can you try with only Calva active?

What's the problem you're experiencing with the second text?

yeah, trying now 😄

let me remove my entire settings file too

AHA, that fixes it

let me find the setting now

"calva.fmt.formatAsYouType": false, :man-facepalming:

I feel like I have tripped you up! I wonder when you would ever not want format as you type... Especially since there is already a VS Code setting for that. Can you file an issue about this?

"[clojure]": {
    "editor.formatOnType": false,
  },

they both seem to do the same thing

I can't exactly remember what behaviour I encountered that caused me to turn these off

Does the calva.fmt one switch off formatting if the other one is enabled?

I remember vaguely to have removed that setting, but maybe that was in a branch never released....

yes, it does override the VSCode one

https://github.com/BetterThanTomorrow/calva/issues/1827

The only reason I can see is if you have some other Clojure formatter. But the setting is not worth the confusion it causes (even if you had disabled it twice, haha).