feat: "spacers"

[l-kershaw]

This PR adds a new type of layout_element, a "spacer", which (if there is additional space on screen once everything else is drawn) fills the remaining space.

Multiple spacers can be used at once to give a "vertically centered" layout (one spacer at the top, one at the bottom).
You can also put a spacer in the middle to have a top aligned block and a bottom aligned block.

The spacers are adjustable by changing their val, which changes the ratio of their size in relation to the other spacers.

---

I think I have managed to get it to work with everything else (e.g. cursor_jumps) properly but would be good to have other people testing.

[goolord]

why does this have to maintain state and move around cursor jumps? if i'm understanding the purpose of this widget correctly couldn't you just do arithmetic to calculate a percentage of the window height and then call layout_element.padding?

[goolord]

The spacers are adjustable by changing their val, which changes the ratio of their size in relation to the other spacers.

ah, this is why. 🤔

[l-kershaw]

The reason is that you need to do this after all of the other layout_elements have been rendered, so that you know how much space is left.

I suppose you could combine this into the padding element with a ratio key or something, but you would still need to store state somewhere to do things at the end.

[l-kershaw]

I'm happy to change methodology if you would prefer a different setup (e.g. I wasn't 100% happy with the naming "spacer" but couldn't think of anything better).

[goolord]

well, as far as vim goes drawing blank lines at the end of an unmodifiable buffer is pretty pointless, but if you used a spacer in the middle then yeah you would need to go back and adjust the space drawn at the beginning

[l-kershaw]

Yeh, I thought about the blank lines at the end being pointless, but I also thought that doing an extra check in the loop would make the implementation more confusing, and since it was doing no harm, I left it as is.

[goolord]

can we iterate over the layout before layout_element is called and stick any of the arithmetic needed in the state? should allow us to not have to move around cursor jumps

[goolord]

keeping rendering happening from top to bottom sequentially just makes the state space of the program easier to think about

[l-kershaw]

I agree that rendering from top to bottom makes things easier to think about 👍

We would just need to be careful about calculating sizes of elements before we render them.
For example, if a user provides a function for a text element, should we evaluate the function in the sizing part or the rendering part?

It's probably doable, but would just need some careful thought.

[l-kershaw]

@goolord
I've refactored stuff so that we only render in one pass, and we don't mess about with the cursor_jumps once they are calculated.
I need to sort out the merge conflicts, but this PR should now have the same functionality as before, with an easier to follow state space.

Any thoughts?

[goolord]

seems better, i will give this a closer look when i have time