Debug console architecture

[isidorn]

This item is intended as a discussion for the future of the debug console. Currently we use the tree to represent all elements in the debug console. This has worked well thus far but has certain limitations. The benefit of using the tree is that we can easily render complex elements - the ones that have children. The tree also allows us to lazily fetch the children of each element and is virtualised.

Motivation for the change

#1957
#4338
#4326
#2163
#6845
#228
#10680
#26641

Option 1: use the editor and simulate the tree using editor decorations

pro: find, selection, word wrap, performance
con: have to simulate the tree by using editor decorations / indentation, not enough flexibility (for possibly future requests of rendering custom things in the debug console).

Note: editor could be enhanced to render custom images, but customly rendered output which the user can interact with is tricky.

Option 2: use the editor but render a tree per complex object in a custom editor widget

pro: most similar to what we currently have with some benefits on top (able to find/copy outside of complex objects)
con: find and selection will not work inside the tree, thus making it hard to copy / find contents inside complex objects

Option 3: render the debug console not using existing widgets

pro: gives most flexibility
con: no virtualisation, slow for a large number of elements, have to rewrite find widget, word wraping

Chrome debug console is a good example of this. They can render multiple complex elements side by side and expand / collapse them.

@weinand @alexandrudima please edit / modify as you see fit. I might have missed some of the pro/cons that we discussed, I just simply wrote what we have talked about this afternoon.

[bpasero]

Can we not start with option 1 and introduce more widgets once we have usecases for it?

[roblourens]

I'm interested in this too, and I'm not sure what you mean by 'plain HTML' in 3, and the Chrome devtools console is virtualized. Does this just mean, a new implementation that isn't based on the existing editor or tree?

[isidorn]

@bpasero I am also leaning towards that
@roblourens we did little experimenting yesterday and we got the impression that the chrome devtools console is not virtualised as it gets very slow scrolling performance for medium-large number of elements. Yes, that means a new implementation not based on existing editor or tree basically

[isidorn]

@weinand let me know once you settle on your preference.
As already mentioned I am keen on experimenting with Option 1 in September. After the initial investigation we will probably find additional issues and we'll be able to assess better.

[weinand]

@isidorn how do you envision the tree will look like? The current folding UI looks and feels quite different than the tree. Ending up with something like this, would not work for me.
So before replacing the tree with the editor you should do an isolated experiment that proves that the editor can be used for rendering a tree and that the interaction behaviour is acceptable.

[isidorn]

@weinand our plan is not to use folding, but add click listeners on the line and use unicode characters for expand / collapse simbols. @alexandrudima and me did a very quick and dirty visual experiment on how this would look like and in the end it looked something like the chrome dev tools tree. We used the unicode characters ► and ▼for collapsed and expanded.
It would be drastically diferent to our other trees and more like a lot of text that can be expanded / collapsed. Though I think that is preferable in a REPL.

Here's a very rough first version of our experiment.
Also fyi @joaomoreno - might be interested in our tree / editor experiment.

[joaomoreno]

Looks really cool @isidorn