RFC: zwp_text_input_v3: Fix text deletion
This change tries to fix text deletion in absence of set_surrounding_text support.
Deleting text using byte ranges is only possible when set_surrounding_text is available and properly supported. However, it's not mandated, and mandating it would increase the difficulty threshold of implementing the protocol.
The solution to that is to redefine text deletion requests to use a unit that can be requested without knowing the contents. The ideal unit would be some a "character", however Unicode doesn't offer a good definition of one. To avoid this, the request has been overloaded to let the client decide what a "character" is when surrounding text is not supported, and let the compositor do that when it is, by deleting using Unicode codepoint count.
To accommodate for giving the compositor such responsibility, a minimal requirement is placed on the amount of text in set_surrounding_text.
I had a few concepts of how to do this, and I admit that overloading lengths to mean 2 things depending on context is unfortunate, but it'd also be annoying to have 2 events and morph zwp_text_input based on supported features. With "character" close to "codepoint", I think in most cases, a misunderstanding is going to do the intended thing anyway, and, well, figuring out what's wrong when it's not is going to be bad either way.
There's another pitfall in that this is now the only request that doesn't use bytes. I think all should be moved to codepoints in the next major revision to avoid this.
EDIT: There's an incongruency in who's in control between set_surrounding and delete_surrounding. Delete is built for the compositor being the one who decides what a "character" is, but it must do it based on set_surrounding, where the best requirement I could come up with is "and client sends one more «character» intended for deleting", so the client retains some of the decision. This may lead to the compositor being forced to delete "half" of what it considers a character if it wants to delete anything at all.