I have an exploratory project I've been working on...

# feed

[Adam Brown]

I have an exploratory project I've been working on, off and on, for a couple months, that I think has finally hit a minimum viable state:

Compose Text Editor

I've been trying to implement Spell Checking in a Compose TextField for a long time now, but the limitations of BasicTextField have ultimately made that impossible.

So a few months ago I thought I'd just explore how hard it would be to re-implement a Text Editor from scratch in Compose. Turns out, ya, it's pretty hard 😂 But I have a working version now that might be useful to some!

You can try a wasmJS demo of it here.

Features:
• Semi-efficient text handling for long form text
• Arbitrary text styling
• Extended styling system: RichSpanStyle allows for fully custom drawing
• Markdown support
• Spell Checking!!! 🥳
• Desktop/JVM, Android, wasmJs support (other targets should be possible too)
Now hopefully Compose proper will get a rich text capable component, that is also suitable for long-form text, and I can just deprecate this project. But until then, there's ComposeTextEditorLibrary.

https://github.com/Wavesonics/ComposeTextEditorLibrary

[Dave Leeds]

Wow @Adam Brown that's fantastic! So the text data behind the text box actually includes the markdown characters (e.g., underscores, asterisks, and back ticks)?

Also - are you planning to add a license to the project?

[Adam Brown]

oh yeah, I'll add a license tonight.

it uses AnnotatedString under the hood, but can parse to and from markdown

[Adam Brown]

@Dave Leeds added an MIT license!

[Dave Leeds]

Awesome, thanks so much @Adam Brown! 🎉

[Jorge Martín]

I tested the library during the weekend a bit and it seems really promising, especially for one of the use cases in our Android app where we need a rich text editor but we want to intercept and handle what's added to the textfield ourselves (we're using a Compose wrapped EditText with a custom InputConnection for this).

However, there are a couple of issues I found and I think they're all related to not using the TextInputService / PlatformTextInputModifierNode:

• Since no text input session is started on focus, at least on my test in the emulator, the IME keyboard won't be displayed so I can only type using the HW keyboard.
• Although it's mentioned in the README, RTL languages won't work, and I think it's again because text input is done through the onKeyPreview modifier instead of using the text input service or the text input modifier and intercepting the EditCommand s received from the IME. Alternatively, I tried using a special case for the case when the KeyEvent action is MULTIPLE and keycode is UNKNOWN in Android code to be able to get the characters contents of the KeyEvent and it worked, kind of, although it's not the right solution.
• The best way to solve this would be implementing 'composition' so Chinese/Japanese/Korean languages where merging characters is important would work, and it would also allow suggestions other languages to work, so the text field would work way closer to any other in the system.
• As mentioned in the previous point, no IME integration means no suggestions, so no way to quickly fix typos in mobile.
So IMO if you want to continue this experiment you should probably try to make it work through the mentioned input service / modifier node since otherwise, at least in platforms where the IME is important, you're fighting the platform (been there, done that, I wouldn't recommend it to anyone 😅).

This is not a complaint about the library, the work done trying to make each part of the text editor customisable is amazing, but since I had previous experience working on something related I thought I could try to give you some suggestions about which path is more likely to succeed in the long term.

[Adam Brown]

Ha yes! I actually have a branch I'm exploring a refactor in to use TextInputService

My primary target was Desktop, so I didn't notice the problems with not using it until late in testing.