it would be cool to see someone build a markdown to annotated string converter

It's been a really good way to explore writing custom layouts. I initially used the Table composable for both lists and tables, but when that disappeared I realized most of the behavior was just easier to achieve with custom layouts, and more easily customizable too.

I did find some issues, and I would have written them up but I ran out of time last night lol. One thing from this weekend was some awkwardness with the InlineTextContent API. I haven't made a reproducer yet but passing in a new map doesn't always trigger a relayout of the text. You'll see a bunch of comments where I append zero-width characters to the string to force relayout when the placeholders' sizes change. The reason I ran into that was due to trying to hide the placeholder API altogether. The cheat I'm using now is to use the first composition to measure the inline contents using the Text's layout constraints, then immediately recalculating new Placeholders with the results. This isn't ideal, since there's a frame where they content is all zero-sized and you see it jump into place (it's even visible in that gif). I don't know if that's avoidable though since the content would need to finish measurement + layout before starting text layout, and text layout is required to measure the text node, so there's a circular dependency. Something that does seem fixable though is that Density throws an exception if you try to convert an em TextUnit to pixels. This makes sense in most cases, since ems are relative to font metrics and don't have any meaning outside of a specific font. But when inline content is composed, it is in the context of a specific font. It seems like it should be possible for Compose to merge all the SpanStyles and TextStyles, determine the font, load the font metrics, and pass a special Density ambient to inline composables that had support for em conversions. That said, this is only really an issue if they need to measure things in ems, which is really only necessary if you're trying to calculate the Placeholder lazily as described above.

I found at least one crash too, I think a race condition that I triggered once by clicking on that link in the gif right when the resizing inline content started changing, but I haven't been able to repro.

Definitely the weirdest bug of the weekend was that the property initializer for a property in the companion object defined at the bottom of a sealed class with nested subclasses was seeing the first

object

"case class" in the sealed class as null. Doesn't seem like anything to do with compose, but I've never seen that before.

the inline text content API hasn’t gone through API review yet so there will likely be some changes there