We added a new selector#Create() API in #4 that configures the selector via builder calls like .WithMappings({mappings}) instead of watching variables like g:sw_key_mappings for config. We should delete the legacy API soonish. We can disable selector#OpenWindow with a deprecation error.

Lots of selectors open buffers when you interact with items and it would be nice to have broad support for opening those files in current window vs. horiz/vert split vs. new tab. Maybe some kind of modal mappings to say "next operation is :vert", "next operation launches in new tab", etc.?

Calling selector#OpenWindow twice in a row fails:

Error detected while processing function selector#OpenWindow:
line   32:
E95: Buffer with this name already exists

You can just close one selector before trying to open another, but the error is annoying…

Selector uses a lot of global variables for configuration and state:

• g:Sw_SetExtraOptions
• g:Sw_SetSyntax
• g:Sw_SetSyntax_func
• g:sw_key_mappings
• g:sw_max_win_height

We should clean it up to use maktaba flags and/or explicit function arguments from callers.

My understanding of google/vim-maktaba#208 is that we forked most of the guts of this project into Maktaba, as maktaba#selector#Create.

David's comment in google/vim-maktaba#209 finished:

Next step will be to gut the vim-selector implementation once users have had some time to update maktaba and make it delegate to maktaba for all the non-legacy implementation, and then to mark the whole vim-selector plugin deprecated.

I think we still have that to do, here.

Instead of highlighting selector window entries in the fairly awkward form of coming up with syntax highlighting rules, there should be some way to just define the styling you want on the lines you render using vim's "text properties" feature.

For older versions of vim without support for text properties, it could just just silently skip syntax highlighting, or have a built-in fallback to some basic coloring with some predefined syntax highlighting rules.