Refactor REPL output to HTML rendering

[eliascotto]

Changed REPL output to render HTML instead of using a textarea. This allow to style the REPL output as changing the package color and also for the future if we want to make output items clickable to inspect them.

I also added the extension name & version output in the REPL to give a better context to the user.

[nobody-famous]

I'll try this when I get the chance. The main reason a textarea was used was for performance. IIRC, loading the Alive test package would take a couple minutes in the REPL even though it actually loads in a couple seconds. The eval thread would finish and then the output would take forever to render in the REPL. That's the main thing I'd check for, that the rendering keeps up with the output.

[eliascotto]

I've tested it with some stuff and when computation output gets large the webview freezes and doesn't render, while the textarea does. That sucks.

(dotimes (i 80000)
  (format t "~3D " (1+ i))
  (when (= (mod (1+ i) 20) 0)
    (terpri)))

Maybe instead of using a textarea we can use a file? We could gain syntax highlight, autocompletion and multiline input. Calva, the Clojure REPL, does a similar thing. It also saves every evaluation output in a inspector window that the user can go and inspect later the content.

[nobody-famous]

My first attempt with the REPL was to use a file and it was horrible. People wanted to edit it in weird ways, yet still have it somehow behave like a command line. It also had similar performance issues where it'd slow down as the file grew. The compromise was the scratch buffer. The built-in terminal in VSCode uses a canvas, which means they're doing their own font rendering. That doesn't seem like it'd be worth the effort. I've thought about just getting rid of the input line on the REPL window and adding everything that the user evaluates to the history.

The inspectors still need some work. They basically work, but I haven't put a lot of time into making them better. I don't remember, exactly, but I think the reason I didn't have REPL output go to an inspector was because I hadn't quite figured out how I wanted to display it.

With Calva, they didn't add Clojure support to VSCode as much as they tried to turn VSCode into Emacs. I feel like they forced the "document as a command line" approach because that's how you'd do it in Emacs. I don't ever do anything with Clojure because I use more than a dozen languages on a regular basis and Calva is the only time it doesn't feel like I'm using VSCode anymore.

[eliascotto]

Hey, thanks for the explanation. I checked the terminal rendering in a canvas and it seems it involved a large amount of work with WebGL, so not a feasible alternative at the moment.

I like using SLY in Emacs and I think it's very well designed platform for Lisp, it's biggest limitation is Emacs itself. Most of the developers today uses VSCode and for a good reason, so I thought about replicating SLY into it would be great, but this rendering performance issues are very limiting.

I've learned Clojure thanks to Calva, since at the time I didn't know Emacs, and I used it professionally without issues. Yes it's a bit of a hack and doesn't feel 100% VSCode but the overall experience it's satisfying and without many freezes and crashes as Emacs+Cider.

[nobody-famous]

Ah, OK. That makes sense. Emacs is still very much tied to a command line mindset, which VSCode isn't. I think that's why there's so much friction trying to replicate Emacs in VSCode. I think the experience with VSCode should be closer to smalltalk, where the editor acts as a gui repl and is like a HUD for the running image. Having old results around and able to inspect is doable, it's just a question of where to put them. The way sly does it is good for the command line driven approach of Emacs, but is fighting the grain with a GUI.