This new field allows blocks to specify how they want to be laid out:
- If `Fixed` they can take up all the width they want and they will impact
the scroll width of the editor. This is useful for diagnostic messages and
allows scrolling the editor further to the right to visualize the entire message.
- If `Flex` they can extend all the way to the scroll width without impacting it
any further. This is useful for the rename editor that we insert as a block
decoration when hitting `F2`.
- If `Sticky`, they will be as wide as the editor element and won't participate
in the horizontal scrolling of the editor. This is useful for headers in general,
where we want e.g. the filename and the jump button to always be visible
independently of how much the user has scrolled to the right.
* Add a `hard_tabs` setting that causes indentation to be performed
using a tab instead of multiple spaces.
* Change Buffer's indentation-related APIs to return an `IndentSize`
struct with a length and a kind, instead of just a single u32.
* Use hard tabs by default in Go.
Previously, we would accept edits containing out-of-order ranges. When
generating such ranges in our randomized tests, many invariants started
breaking causing e.g. undo/redo to misbehave and operation application
to panic.
In theory, we should never pass inverted ranges, but this commit changes
the above functions to swap the start and the end when that occurs to avoid
breaking the entire system and panicking.
We temporarily let it grow when the message size exceed the limit,
but restore the buffer's capacity shortly after. This ensures that,
for each connection in its entire lifetime, we only ever use 1MB.
In some cases, we need to render during layout. Previously, we were rendering with a LayoutContext in some cases, but this commit adds the ability to retrieve a render context with a given handle and we use that feature in UniformList.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
