I can't speak to why this is clamping occurs. However, if you could further explain what you are trying to achieve I may offer a solution. What do you mean by scrolling a Flex or Grid? Would creating an internal scrolling mechanism by updating a Grid to contain different rows achieve what you are looking for?

Would creating an internal scrolling mechanism by updating a Grid to contain different rows achieve what you are looking for?

Smart, I didn't think about. It's actually doable, but a bit hacky. It would probably require displaying only specific subset of elements instead of everything.

What I want to achieve is basically a multi-line list (scrollable, not necessary selectable), containing multi-line textViews. Similar to a webpage.

And yet changing grid's or flex's position would be much more elegant.

Early on, I was thinking of a class Scrollable which may contain another primitive which would only be displayed partially and could be scrolled using keyboard shortcuts. With Grid you do get a similar behaviour but scrolling is then per item, now per row in the terminal.

Such a Scrollable may still be something I'll add in the future but given the backlog I have on here, you may not want to bet on it becoming available very soon.

I see. That Scrollable class would be really useful.
Scrolling per item gives quite different behavior on bigger items, and also cuts box borders: last line sometimes looks like this

└───────────────┘

instead of

├───────────────┤

and therefore gives impression that there isn't anything more to scroll while there are still more items.
And I suppose just allowing opt out clamping isn't a good idea? The problem is that there is no way to achieve that in a custom primitive level, without rewriting the base box.

Ok. So the clamping in Box was initially just a way to simply optimize the drawing of primitives. There was no aesthetic reason for it and I agree it actually makes some cases look worse.

I removed it with the latest commit.

This meant that I needed to add screen boundary checking to all primitives. (Theoretically, it's not necessary because tcell ignores writes outside of the screen.) I wanted to have some basic optimization.

Please note that, say, a large TextView may still be slow to scroll because all the reindexing happens independently of the screen dimensions. tview is not yet ready for huge primitives.

Wow that was quick, thanks. Noted about the big buffers.