isPlaceholder could be true for an InlineSpan that's not a WidgetSpan right? But only WidgetSpans are tagged in the rich text implementation?

yes, this will ignore any other placeholder subclass, since we don't know what how they would contribute to the semantics...

It's not clear to me why we can skip the delegate if there's a recognizer. Don't we still have the same problem with the placeholder nodes in this case?

If there is gesture recognizer, every continuous strings are separated into its own nodes so there won't be merging issue. and the assemblesemanticsnode is smart enough to insert each semanticsnode of widgetspans in the right places. So there is no need to use the childconfigurationdelegate API. As we discussed offline, if we do want to replace assemblesmeanticsnode with the childconfigurationdelegate API we need a way to set stable id and geometry

Makes sense. Thanks for the explanation.

How are _buildChildSemanticsConfigurationsResultAndFillCache and _buildChildSemanticsConfigurationsResultAndFillCache kept in sync to make sure they end up producing the same ChildSemanticsConfigurationsResult?

added assert

This doesn't really address the maintainability problem. If we ever have to fix anything in this logic, one would have to do it twice. Plus, the (complicated) assert doesn't really inspire confidence that the two are actually equal. For example, in some cases it just assumes configs are equal when the labels match.

ah yes, I tried to combine this two functions in the previous commit, but the code looks like a trainwreck.

so I guess what you meant earlier is to make it more readable than to separate them out cache version and non-cache version?

Yes, sorry if I wasn't clear...

This one actually surprised me a little bit. I sort of expected there would be three sibling nodes: "before", "inner", and "after".

I am not sure how we are going to support that, let's say we solve the unique id and geometry issue that synthetic SemanticsConfiguration can be explicit. How would it know when they should be explicit and not merge together. for example, how do they tell they need to merge in this case

[
              const TextSpan(text: 'before '),
              WidgetSpan(
                alignment: PlaceholderAlignment.baseline,
                baseline: TextBaseline.alphabetic,
                child: Semantics(label: 'inner'),
              ),
              const TextSpan(text: ' after'),
]

but not merge in this case

[
              const TextSpan(text: 'before '),
              WidgetSpan(
                alignment: PlaceholderAlignment.baseline,
                baseline: TextBaseline.alphabetic,
                child: Semantics(label: 'inner', container: true),
              ),
              const TextSpan(text: ' after'),
]

Maybe some tests that combines these cases with recognizers?

We already have test that does that, e.g testWidget('inline widgets generate semantic nodes'). The issue this pr trying to solve is that when there is only plain textspan and widgetspans that want to merge together.

Makes sense. Thanks for the explanation.

Should this be calling _buildChildSemanticsConfigurationsResultFromCache instead?

Should this just return result instead of calling _buildChildSemanticsConfigurationsResultAndFillCache again?

This doesn't really address the maintainability problem. If we ever have to fix anything in this logic, one would have to do it twice. Plus, the (complicated) assert doesn't really inspire confidence that the two are actually equal. For example, in some cases it just assumes configs are equal when the labels match.

belongs -> belonging

nit: I think dart should allow you to mark this as final instead of late since every branch of the if below it assigns it exactly once.