GNOME Bugzilla – Bug 575670
Tab completion doesn't work when completing a shared prefix
Last modified: 2011-08-29 10:12:28 UTC
When typing in #telepathy, I typed 'p' and hit tab to see if 'pierlux' was around. Empathy didn't do anything when I hit tab, so I assumed he wasn't there. Turns out he was there, but so were four other people whose nicks begin with 'p'. Rather than cycling through each one in turn, or presenting me with the list of matches, Empathy didn't do anything when I hit tab. I think the "list of matches" approach to tab-completion is probably the best. Suppose a room contains "foobar", "foobaz", and "fox". Then: * "f<tab>" should complete to "fo" and show me a list of "foobar", "foobaz", "fox" just above the input. * "foo<tab>" should complete to "fooba" and show me "foobar", "foobaz" just above the input. For super bonus points, the matched prefix could be emboldened in each possible completion. I imagine this would look kind of like the text completion on Maemo.
Instead of printing the nicknames in the channel, why not scroll the member's list to the correct position? :)
Because it might be collapsed.
We could still do both, IMHO.
This seems like a good self-contained task to get involved with Empathy; marking as gnome-love!
admins, please close this bug, it is not valid anymore (at least on Jaunty Telepathy)
my bad, it still occurs, it just dont occur when you have a single person with the starting letter.
Created attachment 138769 [details] [review] Should fix the autocomplete problems and make it work very closely to xchat's one. This patch should fix completely the auto complete problems. One thing i noticed though is that gtk_text_iter_backward_word_start doesnt work as expected. If you have a nick like DJ|Gnome, it see only the word "Gnome" instead of the full word (separated by spaces). But i guess thats a fix for pango/gtk+ guys.
I'm not sure the gtk_text_iter_backward_word_start() problem is a Gtk bug; it just has a different definition of word than the one you want to use. Egxactly which definition of work is appropriate is tricky because it varies between protocols, so you can end up with false positives or false negatives. But at any rate, it seems like we need to pick a set of characters and implement the iteration ourselves.
Yeah, i thought about that before submitting the patch but wanted to hear a second/third word first. Clearly in IRC we just need to separate words by space, since it doesnt support spaced nicknames. Protocols like MSN is a bit "impossible" since people can use those lengthy huge nicknames (wich is weirdo, but they do). Should i write one function doing it with space, attach to the patch and re-send?
Review of attachment 138769 [details] [review]: Hi Romulo thanks a lot for your patch. Please forgive the late review of your patch; we've been pretty busy... + GList *lastCompleted; We use camel_case style for variables so it should be last_completed; Your patch contains trailing space; please remove then (git diff will show them in red). + if (priv->lastCompleted) We use if (ptr != NULL) + // Free unused data please don't use C++ style comments + if (!strncmp(nick, name, strlen(name))) use tp_strdiff if (iter && iter->next) { // This is not the last iterator This looks weird to me. I'd use: if (g_slist_length (iter) > 1) + if (len >= 6) { Why 6? Please use a #define instead of hard coding a magic number GString* nickNames = g_string_new (NULL); should be nick_names As Daf said, you should probably implement your own iterator.
Oh, and I pushed your patch to a git branch. Feel free to start from it if you want: http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/tab-completion-575670
(In reply to comment #10) > if (iter && iter->next) { > // This is not the last iterator > This looks weird to me. I'd use: if (g_slist_length (iter) > 1) Item 2 of http://burtonini.com/blog/computers/list-2009-07-16-16-11 comes to mind in defence of the original.
Closing as a dup of bug #599779 as this one has been fixed with a simpler patch. *** This bug has been marked as a duplicate of bug 599779 ***