Clojurians Log v2

Another example is evaluating a lambda fn (fn [n] (inc n))

The problem is that the inline evaluation needs to be able to parse the form in order to be able to display it, much like say a formatter. The messages are new because previously it would just silently do the wrong thing instead. Sadly there's no good answer here, except to check the REPL output in those cases.

Ahh, I see. Is there no way to show the value "unparsed" if the read fails? Or the whole printed output as a fallback, like in the repl? This is not a huge thing, but I've gotten used to using just the inline results lately (thanks for that btw 🙏), and the new error message threw me off a bit initially.

I could just show a big unparsed blob in the editor, but I'm not sure that would be more user friendly - it's going to be pretty jarring for the user when they're expecting a nice interactive view.

It's just a tricky case. You'll see in the REPL view that it's not nicely pretty printed either, for the same reason - if it can't be parsed, it can't be formatted. Usually most random objects will work since they'll print with the readable #object format, but I remember that the datomic objects were the original ones that provoked this new message - I guess they customise their printed output.

True, that might not be better in general. Though maybe adding a print of just the part that caused the parsing failure to the error message would make the cause a bit clearer? In my case the unparseable value was nested deeply in a huge map, so It was a little hard to find without the inspector. But I guess determining exactly what that "part" of the input would be, without parsing, is not so straightforward.

No, it's definitely not. I could perhaps try to figure out a best-guess path to the failure - I'll look at that to see if it's possible.

That sounds like a good solution 👍🙏