fix: Disable inter-layer grouping by default #2580
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
The group of consecutive non-empty layers is now disabled by default and can be turned on with
experimental_layer_grouping
. The reason for this is that it causes more problems than it solves at the moment, and we need a global push for a new convention inside the Neovim community on how to group layers for it to work.NOTE: That the grouping inside a single layer is still done, which makes it possible to find the outline that needs shadowing for example.
I'm not personally convinced that grouping across layers is a good idea, as far as I see it, everything that currently use two layers and needs this kind of grouping can be done in one layer instead. For example, to draw a window with border, you can do it with four windows on the same layer (content, top, bottom, left, right). Most plugins should use native borders for that anyway. And I think this problem only really concerns NUI, and it's probably easier to refactor that than to change the whole echos system.
But if we decide to take the grouping approach, we need to have a plan how to communicate it and push it through, and also be absolutely sure that it solves our problems before requiring a lot of plugins, and even user configurations to change.
Did this PR introduce a breaking change?
A breaking change includes anything that breaks backwards compatibility either at compile or run time.