How does it look with really long text, e.g. one that doesn't fit in one line? Also, how does it look like with text that has many lines, eg. 1000?

Displaying all the content can make it very long, but this can be resolved by reducing the displayed content, such as reducing it to a single line or 100 characters or less. How do you think it should be handled?

How does it look with really long text, e.g. one that doesn't fit in one line? Also, how does it look like with text that has many lines, eg. 1000?

Displaying all the content can make it very long, but this can be resolved by reducing the displayed content, such as reducing it to a single line or 100 characters or less. How do you think it should be handled?

We should show the user as much info as possible. So the popup should wrap the data and should display as much as possible there in multiple lines. Basically, the more data user is able to preview, the better. Also, @sylwiabr, @NedHarding, and @jdunkerley, what if the multiline preview is not enough? Should the preview be scrollable?

I don't think we need a scrollable preview in a tooltip.

My idea is to truncate the string to 50 characters and display ${str.slice(0, 50)}... if it exceeds the limit. What do you think, @wdanilo ?

If we could at least show long string broken into several lines (like 4-5 lines) that would be amazing. Then, sure, let's just skip rest of the string and add ... at the end to show the user that there is more. Ok? :)

This gets so tricky and subtle. What if the string ends in "..."? Its always a good plan to use some other color/symbol to make meta information like the string being truncated separate than the data itself. This is true both in the grid and in the tooltip version of the display, which presumably truncate at different lengths.

Also, it is really important for a user to be able to explore the entirety of the data. The simplest way this can be accomplished is to allow copy to the clipboard to get the full text. But then you are asking the user to switch to external software to analyze their data - so they (the user) might question why they are using enso and not the other program they had to switch to?

And we have to remember, really long values are really common. It is not an exceptional case at all.

I totally agree with @NedHarding, that's why I proposed scrolling the values in popups. Copy-pasting them to another tools looks like a really bad solution, while scroll would solve all issues here.

I mostly agree with @wdanilo - except the tooltip part. Scrollbars and selection for copy/paste are much easier with a persistent control instead of a tooltip. Tooltips have this difficult habit of going away if you move the mouse wrong. To effectively browse a large field and scroll and potentially copy a selection, it would be better served by a text box that is accessed by a double click on a value and then it shows below/right or on top of grid and has to be actively dismissed. This also makes a keyboard interface more intuitive (enter or space) where tooltips are typically mouse only.

Oh, thats exactly what I meant by tooltip. You are right, my terminology was wrong. Thanks for catching it and explaining it so clearly!

@wdanilo I should add - there still needs to be some maximum to avoid crashing the GUI. It is very easy to construct a value with >4GB for instance which we would not want to load in memory. So even with scrolling, we should cap at 1MB or something sane for a text control.

@Nctdt whats the status of this PR? When you can address all the issues?

@Nctdt whats the status of this PR? When you can address all the issues?

I'm sorry, I cannot solve these problems.

@PabloBuchu @Nctdt What are the action points?

If the problems are unsolvable, can we close this PR?

Lets close for now - we have a different approach suggested by @NedHarding which we will implement in the future.