Bug 129708 - konversation needs irssi-style auto completion
Summary: konversation needs irssi-style auto completion
Status: RESOLVED WORKSFORME
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-23 16:58 UTC by Patrick
Modified: 2006-06-25 14:01 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick 2006-06-23 16:58:19 UTC
Version:            (using KDE KDE 3.5.3)
Installed from:    Gentoo Packages

Hi there,

my up-to-now favourite irc client is irssi, and one of the most important features is the _perfect_ auto completion in irssi.

Here's what it does, for those of you who never used it: It brings up the nickname of the most recent sender first, although he/she's not the first in the list. I'll make an example here:

adrian and alice are in the channel, I'm having a conversation with alice, adrian has been inactive for a while. When I type "a<TAB>", irssi will complete it to alice instead of adrian, although adrian comes first. irssi knows who I'm talking to, and this is what we NEED in konversation :)

Cheers,
Patrick.
Comment 1 Peter Simonsson 2006-06-23 22:16:05 UTC
Implemented in svn trunk... will be in 0.20
Comment 2 Patrick 2006-06-23 22:19:32 UTC
Perfect :D
Comment 3 Eike Hein 2006-06-23 22:37:38 UTC
Peter: Your commit description suggests that the change you made bumps the last completion made to the front of the list for the given completion prefix, while this is about bumping the last active sender on the channel to the front of the list.

Let's say we have three users beginning with the letter "a" in the channel: Aaron, Andrew, Armin.

Prior to your commit, the completion list for "a" would have been strictly alphabetical, i.e. "Aaron, Andrew, Armin".

Going by your commit description, if my last completion was to "Andrew", the list for "a" would now be sorted "Andrew, Aaron, Armin", even when "Armin" was active on the channel recently and "Andrew" has been idle for a while.

If this request is implemented (optional or not), the list for "a" in the above scenario would end up being "Armin, Aaron, Andrew" regardless of my last completion. I.e. this needs to be reopened, or your commit description was false.

Personally, I'm wary of this type of "intelligent" algorithm. My favorite example of this kind of design going wrong are the "Personalized Menus" in recent versions of Microsoft Office, which has application menus only display commonly used items and hides the rest unless a button at the bottom of the menu is clicked. This results in the user ending up unaware of existing functionality, and having a hard time with unpredictably moving around menu items. It's easy to make the same mistake with "intelligent" completion schemes.

If I had to chose between the two outlines above, I'd prefer the one Patrick actually requested. As you note in your commit message, the last completion is always accessible by pressing the Tab key without giving a completion prefix.
Comment 4 Patrick 2006-06-23 22:52:38 UTC
Oh, that's interesting.

Well, I think with such a function, there is no such risk as "the user ending up unaware of existing" ... umm... channel members ;) It's just more convenient, because I have to type less letters to be sure <TAB> will result in the nick I actually wanted to get.

I thought about the implementation: Although I didn't look at the source, I guess there is some class for the users. So these objects would get a new attribute "last_message=timestamp", and this attribute would be the sorting criteria before/after (perhaps before is smarter) the alphabetical sorting is done.
Comment 5 Eike Hein 2006-06-24 16:05:09 UTC
Reopen for now.
Comment 6 Patrick 2006-06-24 16:05:56 UTC
I'm re-opening this, because http://svntalk.pwsp.net/project/Konversation/revision/554350 is not what I was talking about. Thanks for pointing this out, Eike.
Comment 7 Patrick 2006-06-24 16:06:27 UTC
Woo... mid-air collision ;)
Comment 8 Peter Simonsson 2006-06-24 23:59:37 UTC
Hmm... ok as I misunderstood the request I've changed trunk to reflect my current understanding of it... please try it out and then either close the wish or flame me :)
Comment 9 Patrick 2006-06-25 14:01:17 UTC
Thanks for implementing :)