Better formatting for the Inspect dialog

[cdsmith]

Unfortunately, @kammitama5 adding properties to the inspect dialog, while useful, made it a bit ugly and harder to read.

Some ideas for cleaning this up:

• Source formatting. I'd like to format these more in the form they appear in the program itself. For example, instead of lettering { text = 'Hashim' }, I'd want to see lettering("Hashim") when in CodeWorld mode, or lettering "Hashim" when in Haskell mode. For transformations, we could do something like translated(..., 4, 7) (in CodeWorld mode), or translated 4 7 (in Haskell mode). This means we need to do something mode-dependent here, either by passing in a formatter, or just detecting the mode inside the program.
• Contextual tool tips. Unfortunately, the previous idea loses descriptions of the meaning of the arguments. I am afraid this is a fundamental tension - the wordier the result, the less likely it is to be useful at a glance; but the terser, the less likely to be informative. But we can at least add the description in a tool-tip. So when you hover over the 4 above, a tooltip could pop up saying "horizontal = 4".
• Smarter ellipsization. Instead of ellipsizing the entire string, we could start by ellipsizing each of the arguments separately. Since this takes less away from the usability, we could be a bit more aggressive at ellipsizing, making the labels shorter (and, therefore, the structure more clear). When arguments are ellipsized, we can still attempt to show more of the argument in the tool-tip.
• Type specific formatting. When rendering a color, we should consider rendering it in the same hue and saturation as the color itself (but not lightness, because it must remain readable). In tool tips, we can go even further. The tool tip for a color should show a swatch, as well as the RGBA and HSL values. The tool tip for a point can show the point on a coordinate plane. A list of points should probably have separate tool tips for its member points.

[cdsmith]

Another important improvement would be to distinguish between & and pictures. They can remain the same constructor, but would need to be represented differently if expressions are displayed in source form.

At the same time, we can also do better at not collapsing & chains with explicit pictures calls. That is, today, a & pictures [b, c, d] will result in Pictures ... [a, b, c, d]. This isn't a faithful representation of the source code. If we knew that [b, c, d] was an explicit application of pictures, then we could avoid fusing an & onto it, and end up with Pictures ... [a, Pictures ... [b, c, d]], as expected.

This isn't a complete solution. We'd still fail at this example:

face = eyes & nose & mouth
eyes = leftEye & rightEye

I'd hope to see Pictures ... [Pictures ... [leftEye, rightEye], nose, mouth], but instead we get a flat list. This is a harder problem to solve, though.

[cdsmith]

The current source formatting should be almost entirely compatible with HTML, unless there are string literals that look like HTML markup. So one plan could be to switch the client to interpret labels as HTML, first, and then switch the codeworld-api library to start emitting better markup, including the tooltips and type-specific formatting. This seems better than inventing a whole new language for argument lists just to support formatting.

[cdsmith]

I've now fixed the issue with & versus pictures. Checking for overlap in the call stack let me do a much better job than I even expected, so expressions like a & b where b = b1 & b2 are properly grouped. (This case is detected because the SrcLoc of the right-hand side is not contained within the SrcLoc of the top-level & expression.)

[cdsmith]

Remaining tasks:

• Contextual tool tips. Unfortunately, the previous idea loses descriptions of the meaning of the arguments. I am afraid this is a fundamental tension - the wordier the result, the less likely it is to be useful at a glance; but the terser, the less likely to be informative. But we can at least add the description in a tool-tip. So when you hover over the 4 above, a tooltip could pop up saying "horizontal = 4".
• Smarter ellipsization. Instead of ellipsizing the entire string, we could start by ellipsizing each of the arguments separately. Since this takes less away from the usability, we could be a bit more aggressive at ellipsizing, making the labels shorter (and, therefore, the structure more clear). When arguments are ellipsized, we can still attempt to show more of the argument in the tool-tip.
• Type specific formatting. When rendering a color, we should consider rendering it in the same hue and saturation as the color itself (but not lightness, because it must remain readable). In tool tips, we can go even further. The tool tip for a color should show a swatch, as well as the RGBA and HSL values. The tool tip for a point can show the point on a coordinate plane. A list of points should probably have separate tool tips for its member points.