Perhaps remove the doc comment reference to [int] as it's a generic type? Can follow the style of TextBoundary (or even CharacterBoundary which only has class level doc comments...).

I guess these magic numbers could be avoided with constants (also needed in isLineTerminator).

Same as above on constants.

Looking at TextPainter, the list of what's considered a newline is different: no 0xD on its own, plus 0x2028/0x2029.

  static bool _isNewline(int codePoint) {
    switch (codePoint) {
      case 0x000A:
      case 0x0085:
      case 0x000B:
      case 0x000C:
      case 0x2028:
      case 0x2029:
        return true;
      default:
        return false;
    }
  }

Hmm I got the list from here https://www.unicode.org/standard/reports/tr13/tr13-5.html. I added 0x2028 and 0x2029 I had left out.

Why do iOS and Mac fall through to the same behavior as Windows if the comments above seem to describe their behavior differently?

To me it looked like iOS/macOS/Windows increased their tap count infinitely but they handled taps past 3 differently.

iOS and macOS don't handle anything past a third tap. The selection is retained at the paragraph that was selected on the triple tap.

Windows alternates between double click and triple click when going past the third tap. Alternating between selecting the word or paragraph at the position.

Let me know if I can clarify this further.

I think it's ok as-is. I looked through the code to see how consecutiveTapCount is used and it makes sense that these all return null but later have different behavior.

I think it makes more sense now after introducing an effectiveConsecutiveTapCount.

Ah I guess some tests that previously tapped very soon after a double tap might behave differently now. We should watch out for this breaking Google tests or anything else. Though it looks like Google tests are currently passing 👍

Yeah, how it worked previously is that the double tap timer on TextSelectionGestureDetector would reset the count to 0 after every double tap for every platform. So some test behavior changed a bit, but google tests look good so far.

Is your plan to do this in another PR?

I'm hoping that I can fix it in this one. But if the fix becomes overly complex then I'll probably make it into another PR.

Just wanted to draw attention to this again in case you forgot about it.

It's a bummer that we have to duplicate all of these tests for Cupertino and Material, but I guess they won't work on EditableText because of the code changes in text_selection.dart.

Someday we need to make it easier to share these kinds of tests!

Agreed, it would definitely help with velocity if we only had to write these tests once.

It's nice that this test still works (with minor changes) and makes a lot of sense with the addition of triple tap.

nit: maybe it's easier to write the if clauses, if the local variable is for "effective tap count".

or maybe move the logic to the static method you created later in this file that turns the raw tap count to the effective tap count.

Sorry i'm not sure I follow, can you elaborate? The static method I created later in the file is meant to tell the gesture recognizer what its ceiling is for the consecutive tap count before it resets it to 0.

is it possible to repurpose _getDefaultMaxConsecutiveTap so it takes the raw consecutive tap count and returns the "effective" tap count? For instance for windows the conversion would look like input < 2 ? input : 2 + input % 2 and for other platforms it's max(input, 3).

In this scenario if we are repurposing _getDefaultMaxConsecutiveTap are we then setting the ceiling for consecutive tap count on the recognizer to null for all platforms?

In that case I think we can do this.

  static int _getEffectiveConsecutiveTapCount(int rawCount) {
    switch(defaultTargetPlatform) {
      case TargetPlatform.android:
      case TargetPlatform.fuchsia:
      case TargetPlatform.linux:
        return rawCount <= 3 ? rawCount : 0 + (rawCount % 3 == 0 ? 3 : rawCount % 3);
      case TargetPlatform.iOS:
      case TargetPlatform.macOS:
        return math.min(rawCount, 3);
      case TargetPlatform.windows:
        return rawCount < 2 ? rawCount : 2 + rawCount % 2;
    }
  }

Definitely makes the if cases much better! Thanks for the code and suggestion!