nit: consider implementing these 2 separately. getTextBoundaryAt always searches for both boundaries instead of the one in the specified direction.

When there is a CRLF you shouldn't break after CR

Do you mean the CR should come before the LF in this switch?

huh the unicode website is offline. You should not break after CR if it's followed by a LF.

Aren't 0x2028 and 0x2029 also supposed to be on this list?

Done, thanks for catching that!

Should these comments use three slashes? I guess as it is right now, users on the docs site will see the docs for TextBoundary.getTextBoundaryAt, and these comments won't show up anywhere. Is that intentional?

Nit: "returning" => "returned"

"the line terminator" => "both line terminators" or "the line terminator in both directions"

Right, it includes both, one at each end?

About my first comment, actually I think the docs site will show both the current docs and inherited docs? See: https://master-api.flutter.dev/flutter/dart-core/List/first.html

So I guess if you did add triple slashes here, the docs site would show both. Just letting you know in case you choose to do it.

I'm okay with triple slashes here, but I noticed the other TextBoundary subclasses do not have any additional documentation, so maybe I should just leave it as double slash? Do you have any thoughts @LongCatIsLooong ?

Nit: If you think it would be useful, maybe test one or more edge cases of getTextBoundaryAt, like what happens if you pass it a series of newline characters.

I think you've updated this to include a bunch of good edge cases now 👍

Use indices to iterate since you'll need them anyways? I think that will make the implementation way simpler.

Would this work:

if (position < 0) { 
  return null;
} 
if (position >= _text.length) { 
  return getLeadingTextBoundaryAt(_text.length - 1);
}
assert(_text.isNotEmpty);
int index = position;

if (index > 0 && codeUnits[index] == LF && codeUnits[index - 1] == CR) index -= 2;
else if (isNewline(codeUnits[index])) index -= 1;
while (index > 0 && !isNewline(codeUnits[index])) { 
  index -= 1;
}
return max(index, 0);

This fails for something like abcd efg hi\r\n\n\n\n\n\n\n\n\n\n\n\njklmno\npqrstuv, given position 18. The expected output is 18 for the leading boundary, but we get 17 instead because we skip the new line at the initial position. Still trying to figure out some solution for this.

Thank you for that code! Helped simplify the logic a bunch.

yeah I think the while part needs to be fixed (had an off-by-one moment there):

while (index > 0) { 
  if (isNewline(codeUnits[index])) { 
    return index + 1;
  }
  index -= 1; 
}
return max(index, 0);

By definition this finds the largest index < position. So position > _text.length shouldn't return null (same for the other method).

Wouldn't we be unable to iterate through the text if the given position is not contained within the text? Or in that case do we set the position to the end of the text and start iterating from there?

Eot is also considered a paragraph break I think. The convention is to return the largest index regardless of the bounds, but I don't know if there're significant benefits over returning null when the index is OOB.

I think if someone where to use ParagraphBoundary a stand-alone class with a text of 'hello world'. If they use 100 for the position given to getLeadingBoundaryAt and getTrailingBoundaryAt, then they would expect null bounds since position 100 does not exist within the text.

  /// Returns the offset of the closest text boundary before or at the given
  /// `position`, or null if no boundaries can be found.
  ///
  /// The return value, if not null, is usually less than or equal to `position`.
  int? getLeadingTextBoundaryAt(int position);

This is the definition so by that definition it should return the closest offset, "returning null if OOB" currently is not a promise the interface makes, I think it's OK to make that change but to keep it consistent all subclasses would need to change their behavior. But there doesn't seem to be a huge benefit that you gain from switching from one to another?

Oh okay that makes sense. Sorry I was misunderstanding before, I am fine with keeping the definition with how it is. I have updated the implementation to reflect this.

Pretty much from how I understand it, the implementation should only return null when position is OOB in the direction that we are searching for a boundary.

getLeadingTextBoundaryAt should return null if position is OOB when iterating through the text in the backwards direction. position < 0.
getTrailingTextBoundaryAt should return null if position is OOB when iterating in the forward direction. position >= _text.length. This matches what I see from DocumentBoundary/CharacterBoundary though LineBoundary.getTrailingTextBoundaryAt uses end >= 0 ? end : null;.

I also added the two cases below, What do you think?

When getLeadingTextBoundaryAt is given a position that is OOB in the forwards direction, then the closest text boundary would be the end of the text.

When getTrailingTextBoundaryAt is given a position that is OOB in the backwards direction, then the closest text boundary is the beginning of the text 0.

What if the text is empty?

I'm unsure if we should be returning null or 0 in the case (I'm leaning towards 0 since that would have getTextBoundaryAt return a collapsed TextRange at 0). Do you have any opinions on this?

I went with 0 for the reason above.

nit: index -= 1 for consistency (also this is the preferred style according to the style guide). Same for the code below.

yeah I think the while part needs to be fixed (had an off-by-one moment there):

while (index > 0) { 
  if (isNewline(codeUnits[index])) { 
    return index + 1;
  }
  index -= 1; 
}
return max(index, 0);

Nit: Up to you if you think this is any more clear, but you could turn this test into group('paragraph boundary', ... and then make each independent case below into its own small test.

I think you've updated this to include a bunch of good edge cases now 👍