Hi Julien,
One more patch for the suggestion searching, this time to add experimental "autocomplete" searching.
It works like this: * If there is only one matching result, then the rest of the search term is automatically filed in. * If the top two searches agree on the next X letters, then the next X letters are automatically filled in.
In both cases, any automatically filled in text is kept highlighted / selected. This way, the user can either: * Press the right arrow key if the autocomplete is correct (thus accepting the autocomplete). * Or keep typing normally, thus overwriting the highlighted autocomplete.
In other words, you shouldn't in theory lose anything from the autocomplete, but you may well gain (in that we can be lazier because of it). For example, you can specify the word "australia", and instead of the usual 9 key presses, you can do it with 4 ("au", right arrow, "a"); "Los Angeles Aqueduct" instead of the usual 20 key presses is just 9 ("los a" + right arrow + " aq"); and so forth.
Patch (against 0.2) is here: http://files.nickj.org/MediaWiki/WSuggest-js-autocomplete-diff.txt
Currently there are two known problems with the autocomplete functionality (hence the 'experimental' status): * The main one is if the user types fast, the highlighting/selection will stuff up. For example, if you type "new" quickly, then it autocompletes to "new York" (which is fine), but the " York" bit is not highlighted (which is definitely not fine). I'm currently not sure why this happens (maybe a race condition between the sequential query requests?) - but if anyone knows how to prevent this, please sing out and/or send patches! * Gets redirects wrong (fills in too much detail). For example if the user types "formula we" it will autocomplete to "Formula Weight → Atomic mass", which simply won't work. It's possible to have the JavaScript search for " → " and stop any string at that point, but it feels a bit ugly, so I have omitted that. Might it be slightly neater to have sendRes return 5 fields instead of 4? E.g. "sendRes(query, res, freqs, urls, redirectTargets)", where the new "redirectTargets" field would be an array that contained a NULL/empty entry when there was no redirect, or the redirect target when it was a redirect? That way 'res' could contain just the article's name, and the redirect target functionality could be kept in a logically separate field.
All the best, Nick.