
Rules for Autocomplete - piinbinary
http://jeremymikkola.com/posts/2019_03_19_rules_for_autocomplete.html
======
gwbas1c
Here's two autocomplete mistakes that really irritate me:

\- Autocomplete on enter: Chrome does this, if I type in
[https://example.com](https://example.com) (enter), it makes the mistake of
autocompleting to
[https://example.com/some_page_I_visited_yesterday](https://example.com/some_page_I_visited_yesterday)

\- Arguing: Some applications that I use have autocomplete spell checkers that
continue to aggressively try to "correct" technical terms, uncommon names, or
company jargon that's not known. (For example, I'll cancel an autocomplete,
then go back and add some punctuation, and it'll just "fix" the word again.)

\- Autocomplete when the text field looses focus is a form of arguing.

\- Learning typos, or incorrect learning: Libre Office started doing this. It
learned some names, then it somehow learned a missed space after a common word
and started continually trying to autocomplete "Electricvehicle" every time I
put a space after the word "electric."

One thing that will help, in certain contexts, is the ability to unlearn or
disable suggestions that frequently are canceled.

~~~
skykooler
Unlearning is a great option. I have in Firefox a persistent autocompletion
for a URL that I typo'd once, which still shows before the one I've been to a
thousand times (because it's first alphabetically, I suppose?)

~~~
bradyd
You can use Shift+Delete on an entry to remove it from the autocomplete list.

~~~
skykooler
Not easily on a Mocbook Pro, which doesn't have a Delete key. Shift+Backspace
doesn't work.

~~~
tompic823
On MacBooks the combination of Fn+Backspace mimics Delete. So
Shift+Fn+Backspace to remove a suggestion.

------
ricardobeat
A few good guidelines, but the author states this as generic autocomplete
'rules', and I feel a lot of bias and assumptions coming from programming and
terminal contexts.

> If there are no subsequence/substring matches, it can optionally fall back
> to approximate matches. This is rarely necessary to provide

Supporting proximity matches is critical for anything dealing with city names,
landmarks, events, person or commercial names, etc, where typos and mixed
language input are a normal occurrence. This applies to almost every
e-commerce site out there.

> Matches should be sorted alphabetically

This is countered by a few other of his own rules, such as 'prefix matches
come first', 'exact matches come first'. Again, in some applications the best
behaviour might be sorting by distance, recent use, relevance, popularity,
ratings. Sorting is entirely domain-specific.

> If an option is highlighted, never change it, even if new data is loaded

I don't get this one. If I have the second item selected, and search for a
completely new term, should the item remain wedged in the new results at the
same position?

~~~
jakobegger
>> If an option is highlighted, never change it, even if new data is loaded

>I don't get this one. If I have the second item selected, and search for a
completely new term, should the item remain wedged in the new results at the
same position?

I think the author means "never change it without user input". The problem is
that Autocomplete is often slow, so developers load suggestions
asynchronously, and may update suggestions shown to the user after better
suggestions have been loaded.

If a suggestion was already highlighted at that point, the system should not
change it, to avoid the case where the user tries to commit a suggestion, but
the system changes it just before the user hits the key to commit the
suggestion.

~~~
ricardobeat
Oh yes, I can relate to that - iOS system search is always pulling the rug on
me and making me click random apps / web search results. This can be solved by
clearly indicating that new results are loading, or deactivating the current
items.

------
perlgeek
So, here is the thing. Modern browsers (at least Firefox and Chromium, haven't
tried the others in a while) have AWESOME autocomplete widgets for their URL
bars.

They incorporate multiple data sources (URLs and page titles from history,
bookmarks, the search engine's keyword autocompletion, probably more), build
statistical models (when I start typing "y" I want to go to Youtube 95% of the
time, so suggest that first), don't clobber my paste buffer even though they
pre-select some text, and so on. Awesome all around.

Could we _PLEASE_ get this exact same widget with pluggable data sources
available as a HTML <input> element or similar?

Every time I build a web app, I feel that the user experience could be so much
better if I had such an awesome autocomplete widget available. None of the
javascript implementations come even close.

~~~
no_gravity
There are two problems with adding widgets to browsers:

1: Once they are in, you have to support them forever. Or you will break the
few websites that use them.

2: Almost nobody uses them. Try 10 popular websites and chances are you will
not see a single native dropdown. You might not even see something as simple
as a native radio button.

I think it's better to get the basics right instead of building more and more
'userland' type of functionality into the browser itself.

~~~
perlgeek
> 2) Almost nobody uses them. Try 10 popular websites and chances are you will
> not see a single native dropdown.

I'd argue that's because the native widgets haven't changed much since I've
started using computers around 1994 (probably longer), and simply aren't up to
the modern standards anymore.

If there was a native widget that worked better than any of the current
javascript-enhanced widget and could be styled to fit the website around it,
lots of people would use it. Maybe not the top 50 web pages in world, but lots
of developers with lower budgets would.

~~~
no_gravity

        that's because the native widgets haven't changed much
    

So why aren't they updated?

If browser makers can't maintain something as simple as a radio button, they
will probably not be able to maintain more complex widgets.

Browser engines are already so complex that even a giant like Microsoft gave
up on maintining one. And Firefox is spending over $200m in software
development per year to keep up.

~~~
coldtea
> _If browser makers can 't maintain something as simple as a radio button,
> they will probably not be able to maintain more complex widgets._

Who said they "can't maintain it"? They just wont, which is different.
Besides, it is up to HTMLWG/W3C to expand on those widgets, and they have done
nothing...

> _Browser engines are already so complex that even a giant like Microsoft
> gave up on maintining one._

Not because of them having radio buttons and form controls. Those we had since
Mosaic... Even Lynx supports those.

It's all the other craziness (from 3D, to MIDI, to sound APIs, to 2-3 layout
engines, to crazy CSS features).

~~~
hug
It’s not even that they won’t, it’s that _the radio button doesn’t do the
thing you want it to_. The radio button works, perfectly, as much as it ever
did. There are no issues, regressions, or any such thing.

It is perfectly maintained as the exact UI element it should be.

------
NationOfJoe
Great list. Easy to follow. I will be using this next time i write an auto
complete

My only objection would be

> Autocompletion to the nearest ambiguous prefix. If I type “g” and that
> matches both “Google” and “GoodReads”, this operation would fill in the two
> “o”s, allowing me to then type either “g” or “d” to select the option I
> want.

Dont change the input as i am typing otherwise you qill get 4 o's. Show it as
an option and allow me to choose the help with right arrow or something

~~~
cstrat
I think I have seen this implemented before and when it inserts the extra 'oo'
it automatically ignores extra 'o's that might be typed. It allows for users
to actually type Google, but also allows users to type 'Ggle' and get the same
response.

~~~
pests
The article mentions this being on some activation like tab or similar like
bash uses. Automatic completion could work with two levels of highlighting.
Example with []/{} showing active/suggestive:

    
    
      "[G]" <- Typed
      "[G]{oo}" <- Displayed in input, with Google/GoodReads as options
      "[Goo]" <- Tab Pressed
      "[GoodReads"] <- R Pressed
      "[Google"] <- g pressed
      "[Gx]" <- Any other character x
    

Then things like Chrome's url bar will fill in the complete first suggestion
with a way to clear it which gives UX like:

    
    
      "[G]" <- Typed
      "[G]{oogle}" <- Displayed
      "[G]" <- Backspace pressed

~~~
HeyImAlex
Usually I've seen right arrow as the activation key.

------
ghayes
One rule I always consider important:

> If I type the next letter of the top match, it should remain the top match.

I find these types of inductive rules might be a better way to express how
autocomplete should work (given a limited universe of suggestions).

~~~
cstrat
> If I type the next letter of the top match, it should remain the top match.

How would this not always be the case anyway given the other rules in place?

~~~
pfranz
You're right in that this example violates, "When one option is the prefix of
another, put the shortest one first." But a personal peeve of mine is Apple
Spotlight. When I type d-a-s it autocompletes to dash.app, as soon as I type
d-a-s-h it autocompletes to dashboard.app. Since it's built-in I felt limited
in what I could do about it. Thanks to this post I looked up how to suppress
it from Spotlight since I dont use Dashboard.

~~~
sojournerc
you might like this - [https://www.alfredapp.com/](https://www.alfredapp.com/)
\- replaces spotlight, is faster, and fuzzy search seems better

~~~
pfranz
I'll check it out again. I only use the most basic functionality of launching
apps (I stretched out and started using the calculator a few months ago!).
Years ago I looked at what was out there and used Quicksilver, but as soon as
Spotlight started working for launching apps I stopped looking for anything
else.

I can't imagine anything faster than Spotlight other than the few times where
it's reindexing.

------
spectre256
It's important to note that this set of rules is for use with a small
(<10000), known, possibly hand crafted set of results.

> Exact matches always come first.

One place this very first rule doesn't work is autocomplete for geocoding.

If you are typing "London":

\- There is a village called Lon, Pakistan [1]

\- There is also a village called Lond, Pakistan [2]

\- There are numerous places called Londo all over the world [3]

So its necessary to determine that some places are more likely to be typed
than others (population is a commonly available number that can help, but
doesn't always work), or autocomplete becomes useless.

[1][https://spelunker.whosonfirst.org/id/1209616309/](https://spelunker.whosonfirst.org/id/1209616309/)

[2][http://www.geonames.org/1370290/lond.html](http://www.geonames.org/1370290/lond.html)

[3][http://www.geonames.org/advanced-
search.html?q=londo&country...](http://www.geonames.org/advanced-
search.html?q=londo&country=&featureClass=P&continentCode=)

~~~
hug
I see no reason this doesn’t work for Lon and Lond and London.

It turns out that people in London, England have to type 2 more letters, a
task that I am sure is not beyond them.

~~~
afiori
> It turns out that people in London, England

Together with all the other millions of people that write London around the
world.

According to google trends London is searched about 20-30 times more often
than Lon.

Sorting Lon before London (in absence of more information) seems a bad choice.

~~~
lenocinor
And I wonder how much the Lon search results are inflated by this same
phenomenon? It may be a lot worse than 20-30 times.

------
yoz-y
> If an option is highlighted, never change it, even if new data is loaded.

I'd change this to "never change the positions of already visible elements
when the person is not typing". Typing something, then trying to click/tap on
a result that disappears and gets replaced by something else is infuriating.

~~~
dperfect
Spotlight in macOS is terrible when it comes to this sort of thing, and it's
been that way forever. I can't count how many times I've tried to launch an
app with Spotlight only to realize that macOS has conveniently replaced the
highlighted top hit (that I wanted) with something else between the time my
brain said "go" and my pinky hit "return".

~~~
macleginn
The thing is, it does never really stop:
[https://i.imgur.com/UVPpYYO.png](https://i.imgur.com/UVPpYYO.png)

------
alphaoide
> Besides exact matches, prefix matches come first.

Google Maps used to do this, and when I entered "9831 Main St, Funky Town"
once and a day later I would not remember the street number. Entering "Main"
would not give me what I wanted.

Google Maps does what I want now AFAICT and entering "Main" will return "9831
Main St, Funky Town" first.

~~~
phendrenad2
I feel like little QoL things like this are what keep Google at the top of the
world. It seems that Google's real business is search after all.

------
dlkf
> Matches should be sorted alphabetically

This should only be done in lieu of information about frequencies. If I type
"repub" into Google, "republic of korea" appears before "republic of ireland"
because it's more popular with users in my demographic (and we know that they
are not simply doing reverse alphabetization because "republic of gamers"
appears after both).

Sorting should happen in this order:

\- whether it's a prefix

\- empirical frequency

\- the number of tokens in suggestion

\- alphabetization

With that said, achieving all of this at the same time is pretty difficult -
especially within the prescribed sub-100ms response time.

> If there are no subsequence/substring matches, it can optionally fall back
> to approximate matches. This is rarely necessary to provide.

I completely disagree with this. Fuzzy matching is extremely powerful. People
routinely get things wrong, particularly on mobile devices, and you don't want
the suggestions to disappear the second I make a mistake.

------
jwr
> Autocompletion to the nearest ambiguous prefix. If I type “g” and that
> matches both “Google” and “GoodReads”, this operation would fill in the two
> “o”s, allowing me to then type either “g” or “d” to select the option I want

This is terrible, unless I misunderstood. It would mean that if I typed
"Google" without looking at autocompletions, I would end up with "Goooogle".

I keep fighting the in-browser auto-completion boxes which try to be too smart
and annoy me to no end. Whatever auto-completion you provide, your first
priority should be "do no harm": if the user typed something that should be
considered as Holy Scripture.

~~~
theobon
This should only happen for user requested auto-completion. For example typing
"g" <tab> "g" <tab> would result in Google in the provided example.

This is very beneficial in code completion or navigating file directories. It
is horrible when typing an email (though maybe when searching email contact).
Definitely needs to be context aware.

------
epr
"The user should never have to take extra steps to not use autocomplete"

Failure to follow this rule is possibly the most egregious of sins one may
commit, and is unfortunately very common. You have to wonder if people doing
this ever even test it themselves.

------
benatkin
I was pretty sure I'd see this:

> If an option is highlighted, never change it, even if new data is loaded.

They're quite deliberate in favoring showing new things in response to
additional keystrokes over results that have already been displayed and not
selected with fewer keystrokes.

This annoys me, but I type faster than I read even when I'm searching. I don't
think most people do so it makes sense to not keep showing the same result
after more keystrokes.

Plus I think it just looks smarter, and surfaces more results. So if you're
using the autocomplete of Spotify, you see more songs than you would if it
kept showing the same result.

I think they're trading function and usability for showing the user more
stuff, and making the app look more intelligent.

For an example of what I'm talking about, if I type "ha" into spotify, "Happy
Now" is the third result. If I type "p" so it's "hap", it becomes the sixth
result. Sometimes it pushes it all the way to past the end of the screen.

------
OmarIsmail
Agree with a lot of these, particularly the ones that prevent misclicks
(changing the data "underneath you" when you have something else selected, or
"enter" doing something unexpected).

However, strongly disagree with the sorting and preference guidelines. In
general the autocomplete should match the intention of what the user is trying
to accomplish which is going to vary widely depending on context. Sometimes
that's the shortest lexical thing, sometimes geo matters, sometimes recency of
usage matters, etc.

~~~
gmueckl
To be fair, the introduction says that these guidelines shoukd be changed on a
case by case basis if common sense dictates that. The ruleset as described is
generic - and also slightly opinionated.

------
albertgoeswoof
I would love autocomplete in URLs I haven’t visited before. Eg my browser
should be able to query foo.com for all its available urls and let me search /
filter through them via autocomplete.

So I could type

foo.com/sig

And I see/tab through the route for foo.com/sign-in or signup or whatever the
server has available.

We’d need an agreed endpoint for browsers to query (.well-known/routes?) and
some implementations to automatically / easily generate the routes, but it
doesn’t seem unfeasible

~~~
exocet_uk
We already have sitemap.xml that could be used for this purpose

~~~
albertgoeswoof
You're right actually. Building a web extension for this would be pretty cool.
I'll take that on when I get some free time.

~~~
matt4077
sitemaps easily run into the gigabytes for larger sites. I just checked
[https://www.nytimes.com/sitemaps/www.nytimes.com/sitemap.xml...](https://www.nytimes.com/sitemaps/www.nytimes.com/sitemap.xml.gz)
and it contains 2000 urls of individual weekly sitemaps of 1 or 2MB each. And
that's just part of their sitemap structure.

------
ykampittaja
An anecdote on MacOS Spotlight and learning algorithms: I never started Chrome
browser with it, because it was already running and never shut down. Then I
(once!) started the chess game with Spotlight. Fast forward half a year, and
Firefox had became my preferred browser. Chrome was no longer running always.
However, Every Single Time I now try to start Chrome using Spotlight this
happens: Type 'C', press enter and Chess starts up. Shut down Chess, carefully
type 'Ch' and wait for Chrome to appear on the list.

It is hard to learn predictive input when you cannot know if the predicted end
result was actually what the user wanted.

------
egypturnash
* If the user types a word that is both a common dictionary word and part of the name listed in a contact, do not auto-capitalize it. You are not helping when you auto-capitalize this.

------
rgoulter
_The matching should probably be case insensitive unless there are two options
that differ only by case. In that case (pun intended), prefer the one that
more closely matches the user’s input._

I find "smart case" is a nice solution here. The filtering should only be
case-sensitive if the input has an uppercase letter.

------
geewee
Particularly twitter is a huge sinner in regards to autocomplete. When
searching, autocomplete for profiles comes much faster than the autocomplete
for search terms. Often bad timing makes me hover a profile and then right
when I click the search terms autocomplete finishes and changes the data
underneath me.

~~~
sbr464
Came here to mention this also. I have a 200meg internet connection, and this
get's me every time. I wonder how bad it is on a slow connection?

------
saagarjha
Agree with some of them, but not all:

> Matches should be sorted alphabetically.

Not always. Sorting is usually a good idea, though.

> When one option is the prefix of another, put the shortest one first.

Except this means that uncommon, short prefixes will always show up first. I
guess "San Francisco" isn't going to have a great time :(

~~~
mehrdadn
What's frustrating with San Francisco is when you're in the US, type it in,
and see San Francisco, Agusan del Sur; San Francisco, Cebu; San Francisco,
Quezon; etc. pop up before the one in California... like what are the chances
that you're in the US and referring to those instead of the one that's
actually in the US?

~~~
floatingatoll
Matches should be sorted by a weighted score that takes both geographical
distance, prioritizing San Jose over San Jose appropriately rather than
blindly sorting them adjacent.

~~~
darkpuma
Exactly, some rules are meant to be broken. If the user is believed to be in
northern California and types 'San ', then "San Francisco" should _probably_
be higher up the list than "San Diego" despite that not being alphabetical
order.

Determining whether or not the autocompletion should work like this is a
matter of common sense applied by the developer, there is no hard and fast
rule. In some hypothetical circumstances it may make more sense to sort by
population size, rather than geographic proximity (let alone alphabetically.)

------
adrianmsmith
Great list. I would add:

* Don’t automatically add the suggestion as selected text in the search box. Because pressing delete will delete (only) the auto-completed text, not the last character you typed (which is what you’d expect if you’re typing fast). The Chrome URL bar is an offender here.

------
benj111
Mobile phones are barely mentioned here.

On a physical keyboard you can be confident that key presses were intended,
that assumption doesn't really hold on a phone.

If I type 'thr', 'the' is a possibly legitimate word that should be getting
suggested at some point.

------
coding123
When the results change, they ability to use things that took over a position
should be disabled for 100ms.

------
kazinator
The biggest autocomplete annoyance I find in some implementations is that they
spring into action the moment you type a single character, and then do so much
processing (in apparently the same thread) that they horribly slow down the
entry of subsequent characters! You make mistakes due to the lag, and the
whole experience is just shit. The run prompt in Microsoft Windows is like
this.

Like, hold your horses for three or four seconds so I can type more, then you
have less to search for. Prioritize my typing response time over the
background search, damn it!

(Really, explicit auto-complete is best, like in command lines ("Tab
completion")).

The second biggest gripe is autocomplete choices that dispatch the command.
Sometimes you see an autocomplete item that is close to what you want, except
for a small edit or addition. Nope, you can't just have that completion in
your edit buffer for further refinement: that item is actually just an item in
a dynamically constructed pop-up menu, bound to do the dispatch action.

Third gripe: caching invalid entries, such as misspellings, and offering them
in future auto-completions! Browsers do this: you misspelled a domain name
three weeks ago, so the resulting URL couldn't possibly load, but now it's
still coming up as a completion item!

------
ggm
here's my pet peeve: its the omnibox in google chrome. it _only_ chooses
prefix-lengthening matches

if I am on guardian.co.uk/au I can find sub-spaces _under_ this.

I also visit guardian.co.uk/uk but I cannot be told about it by google omnibox
rules. But, URL forms are syntactically bound, the /... is well understood to
identify a base-URL and sister URLs. The stringmatch logic should show me at
least some of my sisters alongside the longer-prefixes under the au...
sequence.

~~~
maaaats
The conspiracytheorist in me thinks Chrome's address bar is intenionally
crippled to make you do a Google search instead. It's so so different from how
well it works in Firefox.

It also breaks the rule in the article about not selecting the suggestion for
you. When I start typing in Chrome it fills my whole bar with a suggested url
that matches. I end up pressing esc to remove the last highlighted/completed
part, but that ends up clearing the whole field. I do this multiple times a
day, drives me nuts.

~~~
isatty
Alright - use Firefox! It's a great browser and one that doesn't treat you as
the product.

~~~
maaaats
I do use Firefox as my private browser, but at work I switch between multiple
browsers and various test environments. So I have lots of almost identical
urls where Chrome completes something I don't want to be completed, or
pretends it doesn't understand what I'm looking for.

------
lucb1e
> The tab key should always accept the current autocomplete option

I was with them right until here. Tab is a well-known button that has one
function: going to the next selectable element. Not do something funky with
your autocomplete list. If I want to tab to the "go" button that is after the
autocomplete list, then I expect tab to take me there. How else would I do it?
I'm not visually impaired, but I hate having to move over to the mouse to
leave your input field (feels like Flash Player all over again).

Of course, if I selected an item and then press tab, then the value of the
suggestion should be used together with sending my focus on its way.

An earlier item should solve this, so you don't need to use tab to use the
suggestion:

> The action to make use of [your input] must be a different key than the
> action to [make use of the autocomplete]

(If I understood that correctly in the first place, the sentence is a little
convoluted.) But to hijack a perfectly useful button? That's a no-go. I'm not
even sure what other keys you could use: space should usually be a space,
enter would go using your input (unless you selected a suggestion with the
down arrow maybe), so what's left that does not have an alternate function,
caps lock? Sysrq? Or something like shift+enter?

------
megous
One thing that is also annoying is that some autocomplete list implmenetations
will select an option on mouseover even if mouse didn't move.

So if you place a cursor somewhere below the input, when you type, the list
will open with non-first item selected, which breaks the muscle memory in a
very annoying way (i know that after typing a few letter what the first item
will be, so I confirm selection by habbit immediately).

------
sethammons
> The tab key should always accept the current autocomplete option, if there
> is one (whether it is highlighted in a dropdown or suggested inline).

Someone please let Slack know. I type "@dustin" and see one of five Dustins,
the one I want is highlighted, so I press tab and it selects the next Dustin
and usually I press "tab enter" to then submit my comment and now I've pinged
the wrong person.

------
TuringTest
> The user should never have to take extra steps to not use autocomplete

This! I hate it when I type a word, hit enter, and the widget search for a
totally different search term that happens to begin with that word as its
prefix. Firefox and Chrome, I'm looking at you.

And no, "press Backspace to search for what you actually typed" is not a good
solution.

------
edsrzf
This is pretty interesting and useful. Now where are the details about how to
get ElasticSearch to behave this way? :)

~~~
speedplane
> Now where are the details about how to get ElasticSearch to behave this way?

The rules posted in the article make a lot of sense, but they also require a
ton of backend work. To do prefix matches quickly, you need to create a new
index of your content. Then to handle the relevance rules described, you need
to be able to query both indices and merge the results in a meaningful way. No
obvious way to do this with ES.

------
sidkhanooja
Goodreads is the most flagrant violator of most, if not all, of these rules.
Searching for a book, author or a user is a PITA, and has been that way for a
long, long time.

The best autocompletion I've seen is on Wikipedia - no frills, and extremely
accurate. If only all services were like this.

------
fiatjaf
In case you're looking for some JS autocomplete libraries you can inspect the
kind of results they give on [https://fiatjaf.github.io/search-
comparison/](https://fiatjaf.github.io/search-comparison/)

------
sethammons
Autocomplete is really frustrating on my phone.

Spelling. It should use key distance. Typing "hrapg" should suggest "graph."

Grammar. The tense of the verb is never suggested correctly. Just previous, as
I typed suggested, it gave me suggest until I got passed the whole word.

Responsiveness. If I type "early," I start with "ea" and I notice "early" as a
suggestion. I type "r" as I reach up with my other thumb to select "early,"
but before I can even stop myself, "ear" now suggests "" (the ear emoji) and I
inadvertently click it.

Editing. If I deleted a word at the beginning of a sentence, the new word is
needing to be capitalized. I click the word, and that suggestion doesn't
appear.

~~~
Spone
I think your referring to auto-correct, rather than "autocomplete".

------
cimmanom
My pet peeve - the Safari URL bar that will start autocompleting based on page
title, but won't let you edit the URL it completes to without visiting said
URL. (It only lets you edit the title it's matching)

------
IshKebab
> The user should never have to take extra steps to not use autocomplete.

This is so annoying in VSCode. Often it has a really dumb autocompleter (if
the language is hard to autocomplete for - Rust or Python for example), so
there are _always_ autocomplete options no matter what you type.

Also, pressing enter is the way you pick an option. Which means if you are
typing something quickly followed by a newline like this:

    
    
      // This is a comment.[press enter]
    

You will actually get some nonsense like this:

    
    
      // This is a comment.operator+=()
    

Very frustrating.

------
interfixus
I have written several autocompleters, both for desktop- and web-apps. Put in
a good amount of thought and coding, and I do believe they worked reasonably
well, and would have scored alright on this list.

One thing, though: Context. Expectations will vary, depending on who is using
the particular input field and for what. Searching a customer base? Match
first on names, then further down on addresses, emails and whatnot. Or
whatever.

------
aristus
> If there are no subsequence/substring matches, it can optionally fall back
> to approximate matches. This is rarely necessary to provide.

> Matches should be sorted alphabetically.

But pay attention to other languages / alphabets. From 2009:

[https://alistapart.com/article/accent-folding-for-auto-
compl...](https://alistapart.com/article/accent-folding-for-auto-complete)

------
gcarvalho
I just want VSCode to stop "fixing" "import numpy as np" to "import numpy as
numpy" when I press enter.

~~~
jamie_ca
Disable the "Editor: Accept Suggestion on Enter" option. There's also a
setting "on Commit Character" which would approve the suggestion on semicolon
(javascript).

Took me a while to find them, but life is so much nicer without needing to
manually correct stuff.

------
renlo
Kibana 5 has (had?) one of the more annoying autocompletes I’ve seen, where
when you press enter it searches for the first autocomplete result instead of
what you actually typed in. Makes it so I always need to use the mouse to
press the seach button.

I’m not sure if they fixed this in newer versions but jeez is that bad UX

------
rixrax
Please add to the list: Auto detect language! It’s super frustrating when you
try to write to your German friend and autocorrect just keeps mutilating
perfectly good German words into gibberish (e.g. it’s trying to autocorrect to
English etc. default language).

~~~
pests
This is talking about search auto-completion and not spelling auto-correct.

~~~
rixrax
Whoopsie. Caught cold turkey I admit. But for what it’s worth, for text editor
and text message spelling autocorrect, auto detect would be nice, even if off-
topic.

~~~
pests
Actually autocomplete for each word might not be too bad. Just get a unique
prefix or few letters in order and that's all you need.

------
airstrike
Interestingly enough, some of us were debating this elsethread

[https://news.ycombinator.com/item?id=19432965](https://news.ycombinator.com/item?id=19432965)

------
vince14
Do databases like MySQL/PostgreSQL support searching the reverse index? I was
looking for a solution but haven't really found one to show autocomplete
results.

------
foota
One thing I didn't see here that's a big pet peeve of mine, if you're typing
and the first option changes despite the first matching prefix not changing.

------
antoinevg
Desktop Safari breaks a number of these, most notably and annoyingly:

    
    
        "When one option is the prefix of another, put the shortest one first."

------
motakuk
For most of businesses it's too pricy to write a good one. Also it's too pricy
to have a bad one.

Consider using SaaS like Constructor.IO, algolia.com etc.

------
theandrewbailey
I've always thought that Markov chains would work well for autocomplete, or is
that how most autocomplete engines are implemented already?

------
fareesh
Twitter has some really bad autocomplete UI where invariably I am tapping
something and a new result gets tapped instead.

------
Beefin
Any good JS libraries that conform to suggestions noted?

------
vipulved
These are almost completely wrong. The goal of AC is to get to “what I meant
to type” and good AC systems are designed with priors (eg frequency), common
spelling mistakes, etc in mind.

------
grifball
what if I want to search for something with a comma in it?

