Use of boxes for rendering types in JSON output

[nwolverson]

I think this applies to both compiler JSON output and psc-ide output - types are always rendered to a string using boxes.

E.g. psc-ide completion or type info, or type annotation suggestion.

In some cases this may be desirable if this is simply displayed in a fixed-width form, but often we would want either something suitable for display (e.g. tooltip) or insertion into code itself. For the latter, any side by side rendering breaks things, and the excessive space is an annoyance; for the former, I've mostly been ignoring all spaces, but again side by side rendering means this is incorrect.

My feeling is for the specific JSON fields here (i.e. not actual error message content which may be embedded) we should have an alternative simplistic/linear formatting. Something structural seems over-complicated and hard to consume

[garyb]

#1645 has some similiar discussion. It's better than it was there, but yeah, it can be an issue.

If you look at that ridiculous type I used as an example though, I don't really think a single line presentation is going to help there 😉

[nwolverson]

No, specifically some types are resulting in side by side rendering (an example here nwolverson/atom-ide-purescript#112 which I also linked to the related issue #2039). The point is this formatting is for a fixed-width font terminal and is not just bad but incorrect if you ignore the spacing.

[garyb]

Oh, sure, I saw that, but I'd consider that output to be broken - I'm not sure it's specifically boxes related, although it does occur due to the way it's being used. You should be able to take all the newlines out from any of these kind of things and have them as valid syntax.

[nwolverson]

OK, if the assumption is that every pretty-printed type should be valid syntax to be pasted into your code - I guess it's fine that it appears in the JSON output - it's easy enough to remove undesired whitespace vs adding it. I'll close this on that basis.

(I usually kill 90% of the space in the compiler's type output but maybe that's my preference)

[garyb]

every pretty-printed type should be valid syntax

Maybe I'm wrong in that, but I think anything else would be rather surprising. 😄