Hmm yeah, with the "Autocomplete" prefix on the name of the enum, this gets kind of long.

I think it's OK to leave that prefix off, and make it just OptionsViewOpenDirection. My reasoning is:

• Those other types around it that have that prefix are typedefs, not enums. So there's basically no cost in the niceness of the API from making their names long, because calling code won't typically mention them.

• On the other side, the risk from having a less specific name is that it effectively lives in a single shared namespace with the other public names in the framework, and so it might collide in the future with some name we want elsewhere, or sound confusingly like something that'd appear elsewhere in the framework.

  But I think "options view open direction" is already specific enough that that's not a big worry: if there's something else that might be thought of as an "options view" and it has an "open direction", then I think it'd have to have enough in common with RawAutocomplete that basically the same set of values for the "open direction" will make sense for that other thing as for RawAutocomplete. Namely the "options view" can go above, or go below, or better yet in the future would be able to automatically go where it fits but the app should decide whether to prefer above or below.

  So if there ever is such a collision, I think we can cheerfully use the same enum for both. We'd just revise its docs to be worded more generally, and to mention both uses under "See also:".

That reasoning makes sense; will do.

Just thinking out loud, instead of OptionsViewOpenDirection we could expose targetAnchor and followerAnchor directly... But 1. that's harder for users to understand and 2. I can't think of a reason for anyone to want that kind of control outside of these two cases.

They could hypothetically use that kind of control to position the options on top of the field when it doesn't fit above/below, but that case probably requires more changes to Autocomplete to really be doable (as mentioned in #129748 by @gnprice). We'd probably need a custom RenderObjectWidget or something to do the positioning, similar to how the text selection context menus are positioned. Without that, it would be pretty crazy trying to position the options using the anchors.

So I think I'm on board with OptionsViewOpenDirection as-is. It can grow to support new features like options that move to stay on the screen, and it's also simple to use now.

The _ parameter should instead give the full type and name according to the styleguide: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#avoid-anonymous-parameter-names

Also see the position of your closing parentheses related to this: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#if-you-have-a-newline-after-some-opening-punctuation-match-it-on-the-closing-punctuation

Nit: Another place where the formatting is off from the styleguide standard. Here and in the other tests in this file.

I'm happy to change it if you prefer, but I think in this case, this more compact form is actually consistent with the style guide. Do you have the same section in mind as last time (this one)? It says:

If you have a newline after some opening punctuation, match it on the closing punctuation.

Note "newline after [the] opening punctuation". In this case, my expect( isn't followed by a newline. There's a newline between the two arguments, but that doesn't force adding newlines near the ( and ), does it? Under the "GOOD" heading, there's a case like the code in this revision:

// BAD:
  foo(
    bar, baz);
  foo(
    bar,
    baz);
  foo(bar,
    baz
  );

// GOOD:
  foo(bar, baz);
  foo(
    bar,
    baz,
  );
  foo(bar,
    baz);

in particular

  foo(bar,
    baz);

. In the code here, in place of foo, bar, and baz, we have expect, tester.getBottomLeft(find.byType(TextField)), and offsetMoreOrLessEquals(tester.getTopLeft(find.text('a'))), respectively.

Ah sorry you're right, that's explicitly allowed!