Editor widget with text wrapping?

[franklindyer]

Is it possible to create an editable text field widget that supports text wrapping?

The EditDemo shows how str . unlines can be used as the first argument to renderEditor to create a text editing field that scrolls to the right indefinitely. But when I try using strWrap . unlines, I get the following runtime error:

tried to embed an infinite-width or infinite-height widget in 'Both' type viewport ()

I'm not quite sure what this means, but I was able to track down the following subexpression from the definition of renderEditor:

viewport (e^.editorNameL) Both

My guess is that if I were to change Both to Vertical, this error would not occur. But is there an easier way of accomplishing this without editing the library code?

[jtdaugherty]

Hi @franklindyer,

The reason for the error is that viewports require their contents to have contents of a fixed size in the direction of scrolling, so in the case of a Both viewport, the contents must have a fixed size in both dimensions. This is because the viewport renders the whole of its contents before deciding how to manage its scroll state and translate the contents into view, and if the contents are allowed to be infinitely large in the scrolling direction, the viewport won't be able to finish rendering. So that isn't allowed. (A simple case is that of, say, hBorder, which expands infinitely wide as it is given more room. A viewport cannot scroll that horizontally if it doesn't know when to stop drawing the border.)

To answer your main question, though: it probably isn't possible to do what you want for the following reason. Wrapping, at least as it is typically done in Brick, is a draw-time operation. But cursor placement is done before that, in the editor state. And cursor placement requires knowing in advance how the text will look when it is rendered. So the only way I can think of to do what you're asking is to do the wrapping before rendering occurs, i.e., in an event handler. That would allow you to know in advance where the cursor might need to be moved in order to get it in the right place as a consequence of wrapping. (Given that wrapping is a cosmetic change, not a change to the text itself, this amounts to reverse-mapping the cursor position; you'll know the pre-wrapping cursor position, but you need to determine the post-wrapping cursor position and use that instead.)

This might sound feasible, but it does require some possibly problematic assumptions like deciding in the event handler how big you want your text editor to be, which means you cannot take advantage of Brick's UI layout to find out where the editor is as a function of whatever layout combinators got used. (You technically can by querying the renderer to get an extent for where the editor got placed, but that's problematic because it's too late; by then you have to have already rendered the editor once just to find out where it is, so there's a bootstrapping problem.)

I'm not sure if this is helpful, but hopefully this at least sheds some light on the problem.

[franklindyer]

This is very helpful! Thanks for the quick response.