Autocompletion inconsistencies

[bjones1]

1. In a new document, type the string software test testing tester.
2. Type soft and press tab. This autocompletes to software.
3. Type test and press tab. Nothing happens. IHMO, this should autocomplete to the first entry on the list, tester. I recognize that there's a difference between having only one possible completion vs. having several, but I think requiring extra keystrokes (down arrow, then tab) detracts from the usefulness and consistency (tab is always complete first entry) of this feature.

[andreikop]

I copied bash behavior. Tab completes as much as possible, but never inserts wrong variant, so you never have to roll back the changes.

I don't want user to press Up/Down, I want user to type few more letters to narrow down the completion list.

We might try to invent something like:

• Tab inserts first available completion, but doesn't commit the text modification
• Enter commits text modification
• Key is processed as if completion window is not visible

How do other modern editors handle this case?

[bjones1]

I use Spyder; it always autocompletes with whatever its best guess is when you press tab. So, that's what I'm used to. The theory: you pressed tab, so you must have wanted whatever variant the GUI drop-down showed. In contrast, bash doesn't have a GUI way of displaying its variant to insert, so it doesn't do anything. IMHO, I think the Spyder behavior makes good use of a GUI to add value (autocomplete earlier, based on giving the user feedback on what will happen).