Text handling refactor

[PoignardAzur]

Text handling needs in-depth refactoring. As we proceed with the port to Winit, a lot of text-related code is being removed. This issue catalogues what will need to be added back. It might be split into multiple issues later.

debug_widget_text

Every Widget had a feature to display its ID when a flag was set. Will probably be superseeded by the devtools inspector.

Create "text_helpers" module

We should create a "text_helpers" module based on druid's text module. The new modules shouldn't define widgets, only utility methods for text rendering and editing.

Here are some likely submodules:

• backspace
• cursor_movement
• text_action
• pointer_to_cursor

Write Text widget that's editable and selectable

This Text widget should be fully featured and eventually replace the Label widget.

These features will need to be implemented:

• Displaying cursor.
• Displaying selection areas.
• Handling double/triple-click selection.
• Handling IME events.
• Handling arrow keys and modifiers.
• Handling Home, End, etc.

We should also create a follow-up issue for MacOS text-edition keybindings (see this zulip discussion).

Add rich text support

It's not clear yet how we want to proceed. We're starting to consider integration with Taffy, where inline layout is just a part of the broader layout algorithm. This has benefits in terms of being able to embed non-text stuff in your inline layouts (especially non-emoji icons).

Ideally, rich text should be editable: this is especially useful for apps like Discord where the text-input area offers a preview of markdown effects that will be applied to the message being typed.

Add links

We need to re-implement link handling.

Clicking a link should trigger a LinkClicked(String) action at first. We can consider more involved designs later.

Handle very large strings

Druid and current-Masonry use the TextStorage and EditableText traits to abstract over various string-holding types. This has the advantage that it could in theory extend to ropes and other types that can efficiently process text.

This is useful, because we don't want an app to slow to a crawl as soon as the user pastes a 20MB string into a text input box.

However, these traits make the druid code much harder to read and maintain. And in practice most consumers end up using Arc<str> or String, negating the theoretical benefits. We should find a more lightweight solution to the above problem.

Re-add examples

Once text editing is implemented, we should add the textbox and to_do_list examples back.