Allow disabled `TextInput` to still be interacted with

[Koranir]

Resolves #1880

Follows Firefox's text selection usage (i.e. no blinking cursor, arrow keys don't do anything unless shift is pressed, cursor click position is remembered).

Draft for the following reasons:

• Should the placeholder text be selectable?
• Should this apply to TextEditors as well?
• Currently, the allowed operations when disabled are copy and select all in addition to the selection primitives. Should there be more?

[habics]

• Should this apply to TextEditors as well?

Yes please, imo TextEditor is a TextInput on steroids, it should have all the behavior of TextInput plus more features. There are many befits to have this behavior for TextEditor as well, for example using it to display long informational text that can be copied without editing it.

[Koranir]

• Should this apply to TextEditors as well?

Yes please, imo TextEditor is a TextInput on steroids, it should have all the behavior of TextInput plus more features. There are many befits to have this behavior for TextEditor as well, for example using it to display long informational text that can be copied without editing it.

Now that I've taken a closer look at the TextEditor architecture, it seems impossible to add this, as the TextEditor's state is held by the user. This means that the user has to provide a way to manipulate the state via the set_action method, but that would enable the text input instead.

(Actually, it seems like the end user can just discard actions by the TextEditor that would modify the file contents, so it would pretty much be the same as a normal display.)

What would be more appropriate would be to have a separate TextDisplay or similar widget that provides copy/paste capabilities and maybe some additional customisation options.

[habics]

@Koranir I understand, thank you for taking a closer look.