I think the maxLength setting of the pretty printer is what you are looking for: https://calva.io/pprint/

And we should figure if there is a way we can detect the situation and not completely lock up VS Code when a massive entry like that is arriving. Calva's structural editor simply can't cope beyond some limit, and at some point Calva should probably throw in the towel, instead of stupidly just keep going. We have one such escape hatch today, for long lines, but this is about the structure itself. Ping <!subteam^S03BGSAUPTQ>

Awesome, thanks for the quick reply! With the settings like:

"calva.prettyPrintingOptions": {
    "printEngine": "pprint",
    "enabled": true,
    "width": 120,
    "maxLength": 5,
    "maxDepth": 8
  }

Hmm, I think I may have found a bug though? • option+Enter to evaluate prettyprints and truncates correctly ✅ • If I save the file, and it gets evaluated (because I enabled this option), and the big item is the last thing in the file, it will get printed differently, and with different truncation rules (but at least it does not lock anything up)

That's interesting. I don't know what's going on. Is it truncated at all?

Yup, it's truncated at the end after a while. It also gets printed on a single line

I am guessing that the mechanism for printing the evaluation result of eval'ing a file isn't hooked up to the pretty-printing part

Want me to open an issue? 🙂

Yes, please. And as you already have a good hunch on the root cause, please consider a PR too. 😃

Thanks for the issue! https://github.com/BetterThanTomorrow/calva/issues/1905 Can you add the detail about that the line is truncated to the issue? I think that is extra peculiar...

Also there is Calva: Interrupt Running Evaluations, with default shortcut ctrl-alt-C ctrl-alt-D. I use this all the time when working with recursion. Sometimes I need to type the shortcut several times to actually get ahead of the loop.

Was this meant to be an Share Calva Tricks thing, @eveningsky? 😃

Meant as a way (assuming Code has not completely frozen yet) to avoid waiting several minutes after accidentally evaluating a huge object.

I see. It is too late at this point. What makes VS Code hang here (in the OP case) is happening statically. Calva's structural editing gets overloaded. It is not built to handle these cases. Still. Interrupt evaluation is very good to know about.

1. De-instrumenting is done simply be re-evaluating the function definition in the regular manner, I believe. 2. Not sure if this is the most proper way, but I usually just close the "Calva jack-in" terminal process in VS Code without first using "Disconnect ..."

Two important questions, @UM1PCCLNN. We can improve the Ux here... De-instrumenting: @U03BYUDJLJF is right about de-instrumenting. alt+enter takes care of it. Maybe we should consider a de-instrument command, just so that it is easier to discover... Disconnecting properly: What I do (and subconsciously have intended as ”the way to do it”) is either: 1. I type ctrl+c in the jack-in terminal. 2. (more common) Close the VS Code window, or reuse it. Again, a command for this could make sense. Kill Jack-in process, or something. Making it easier to discover.

thanks for the answers, I understand now.

To be clear, disconnecting is only about disconnecting from the running nrepl process, not about also killing it. But yes, this could be made clearer and/or a command could be added to kill the process (assuming Calva has that control).

for improving things: could the calva-output buffer accept ctrl+c as a command, would that be more intuitive than actually entering the command to terminal

> assuming Calva has that control Yes, Calva has that control.

Ctrl+c in the output window might be more intuitive for some, but for others it might not. Also, on Windows and Linux ctrl+c copies things, except in terminals... I think it makes sense that since you start the REPL via a command, a command could also kill it.

I'm not sure I quite follow the suggestion: > if they could be guaranteed to be valid edn strings then it would be possible to fix anything in the other side Can you elaborate a bit on this?

Afaik calva is bundling up string fragments and pushing them across the repl, then the runtime is evaluating them- first step read-edn. Because not all string fragments are valid edn or valid strings eg the example i gave, read-edn fails in the app runtime with no possible recovery. If the string fragments were escaped/encoded then they would become readable and decodable on the other side, eg instead of sending \"" sending (I think) "\\\"\"" (escaping and wrapping as string literal) then the other side can decode and evaluate, there must be inbuilt fns for this but I can't name them offhand

The example won't evaluate whatever we do, would it? What would you like the result to be from evaluating it?

It's fine not to evaluate, but there's a gap between not being evaluatable and blowing up the whole form irrecoverably. I was hitting this because I wanted to do my command dispatch client side so I was just passing across all the calva special characters for every command-key then dispatching based on the key

So I'd pass $selection even if I wasn't evaluating it, and I couldn't ignore it the command would fail at (REPL) compile time

I think there's a few use cases for passing non-evaluating selections as strings other than dispatch convenience, eg. One could have a bit of broken edn and be trying to debug where it's broken

You might even be shipping non clojure code across like a log file fragment or something

If it has a backslash or unmatched brackets or anything edn won't like then I think it currently can't be done

I still don't quite follow. Maybe you can give me some more examples?

Or, maybe what I need to know is what you want to happen when you select \"" and evaluate that snippet. Same as today? Which is

; Syntax error reading source at (REPL:41:1).
; EOF while reading string

@U63D7UXJB I've switched all my customREPLCommandSnippets to calva/config.edn so I can type actual valid code instead of trying to do code-in-strings. That makes editing them a lot easier. I'm not sure if that would solve this problem too? (since you wouldn't have " around it any more)

See https://github.com/seancorfield/vscode-calva-setup/blob/develop/calva/config.edn

The snippet here is $selection, right? So it won't make a difference if it's configured in EDN or JSON. Though, I think EDN is almost always the better choice for these.

I guess I don't understand what @U63D7UXJB is asking then...

@U04V70XH6 That's cool, I didn't know that was possible but doesn't help me I think, it's not the strings in the snippets that are the problem but the strings of the special characters being invalid EDN. As Pez is saying I think. I think my point is that there are usecases where it's useful to send things to the repl via vscode that are more like data than code, and that means that they might be invalid EDN and not intended for evaluation, so it would be useful to have an option to encode that data as a string, then functions in the runtime than decode it. Especially relevant because Calva is enabling us to send several things at once ($selection, $ns, $etc $etc) Examples: (the one I actually have): (sending all $variables + :key "a" and dispatching REPL-side, then you'll send unevaluatable selections but you just ignore them because eg. your command is something like analyze-namespace and you don't care to evaluate the selection but you don't want it to explode your form) log file data stack traces EDN which is broken and you could try to incrementally parse it and work out why binary data JSON Of course one could paste this stuff into a file, read it and parse it but one could do that for any REPL command, it's just convenience but that's relevant imo

This is what I mean by dispatching commands on the app-side { "name": "Send All a", "key": "a", "snippet": "(jot.calva/app-side-dispatch [:key \"a\" :line \"$line\" :column \"$column\" :file-name \"$file-name\" :ns \"$ns\" :editor-ns \"$editor-ns\" :selection \"$selection\" :current-form \"$current-form\" :enclosing-form \"$enclosing-form\" ])" }, { "name": "Send All x", "key": "x", "snippet": "(jot.calva/app-side-dispatch [:key \"x\" :line \"$line\" :column \"$column\" :file-name \"$file-name\" :ns \"$ns\" :editor-ns \"$editor-ns\" :selection \"$selection\" :current-form \"$current-form\" :enclosing-form \"$enclosing-form\" ])" }, jot/calva.cljc (defmacro app-side-dispatch [kvs] (let [kw-vals (partition-alt keyword? kvs) kw-vals-expanded (mapv (fn [p] (if (= (count p) 1) [(first p) nil] p)) kw-vals) kw->val (into {} kw-vals-expanded) k (:key kvs) macro-command (macro-commands k)] (if macro-command (do (println "macro-command " macro-command) (macro-command kvs))

An unusual use case 🙂 And it's only selections that break strings yes? (since you're trying to pass an arbitrary set of characters in a string) Also, triple backticks makes for more readable code fragments than however you're currently pasting code here (not sure what produces multiple, separate red lines like that?)...

(defmacro app-side-dispatch 
     [kvs]
     (let [kw-vals (partition-alt keyword? kvs)
           kw-vals-expanded
           (mapv
            (fn [p] (if (= (count p) 1)
                      [(first p) nil] p))
            kw-vals)
           kw->val (into {} kw-vals-expanded)
           k (:key kvs)
           macro-command
           (macro-commands k)]
       (if macro-command
         (do
           (println "macro-command " macro-command)
           (macro-command kvs))

Not only selection, also $top-level-form was exploding and some others, and I have the weird partition code because sometimes blanks are passed so maps don't work for passing parameters.

What would be a good API for you to be able to achieve your main use case, @U63D7UXJB? Something like $string-encode $selection , and this would wrap the selection in a string and escape all characters, so \"foo" would be turned into "\\\"foo\"".

Yes! I think that would be great

As with many Calva things, this snippet feature is a bit of a hack. If I squint I do think I see how we could fit this into the hack, but I might be deluding myself. @U02EMBDU2JU, WDYT?

Don't put too much time in if noone else sees the point, I can work without it I was more trying to explain why I thought it was potentially useful

Anyway, @U63D7UXJB, no promises here, but an issue is welcome.

Thanks for your time guys sorry for the rambles

Please file an issue. I want to at least entertain this idea. Even if unusual, the gist of it is pretty general.

Yeah I'm guessing some kind of string-encode function would work to that what ever is inside $selection and create a valid clojure string from it. I'm guessing such a function probably already exists, we'd just have to provide a way of invoking it on the client before passing the whole thing to eval.

I think the actual string encode might be as easy as escaping " and \. The two things tricky that I see here are: 1. The API/syntax for invoking the escaping 2. Fitting it cleanly enough into the existing interpolation. Regarding 1, it needs to be easy to express in EDN. Maybe the idea I posted above actually is OK, more of a pragma (the C kind), than a function... I just had a look at 2, and I think I see a reasonably clean way to do it.

$encode:varname would be the encoded version of $varname perhaps?

I like that. Thanks!

Installed to work with today. Thanks @eveningsky.

😊