Add support for tab completion about matterhorn HOT 16 CLOSED

I discussed this with @glguy and he showed me how word completion works in irc-core.

I also looked into the state of trie libraries on hackage. Here are my conclusions:

• current state of trie libraries is a bit lackluster for our particular use case
• tries are overkill for the amount of words we'll be searching
• Data.Set has nice functions like lookupGT that can be used to find matches

In other words, I think we should do something simple like irc-core and do it directly in the matterhorn code base and not worry about fancy data structures or anything like that. Probably most of the fiddly bits will end up in the UI/UX for this feature.

On that note, glguy mentioned that we might want to consider some of the following things:

• our source of words may update between requests for completion. For instance, the user is trying to tab-complete channel names while someone else is adding a new channel.
• we may want to support forward and reverse search when looking for matches. For example, irc-core uses tab and shift+tab for completion and they cycle in a different order.
• Recently used completion order: most users prefer the search order to be based on what they completed recently. This is helpful if you're switching between a few channels or talking to a few other people.

from matterhorn.

Awesome!

from matterhorn.

Another thing to consider is context sensitive tab completion. Users, networks, filenames, and commands all make sense to tab complete in different contexts. Some commands even make sense to have different contexts by parameter. Other commands might do something even more specialized. For example I have /topic tab completing to the current to channel topic when you tab complete with just /topic on its own.

from matterhorn.

That's a good point. We mused about feeding argument metadata from #2 to improve completion lists/behavior.

from matterhorn.

I've added basic support for tab completion (2dc8a58). It could be a fair bit nicer than it is. Here are some remaining tasks and bugs:

• after finishing a tab completion pressing space and then tab causes it to complete where it left off in the cycle but at the new cursor position. This is minor but feels weird.
• We don't do any automatic embellishment of the completions. For example, it might be nice to put a space or a ':' (context dependent) after a completion without disrupting the cycle. Right now it puts the cursor at the end of the suggested word.
• I haven't spent any time refactoring and cleaning up yet.
• No support yet for context sensitive completions
• prioritized completions are possible, but no tracking is done yet of recent completions. It's just a matter of tracking it.
• We may be sniffing the wrong evens in onEvent (we need to change the completion state in some cases)

That said, please try it out and let me know what you think. I haven't looked for edge cases yet.

from matterhorn.

This is awesome! I'm not sure if this is covered by your list, but I'd like to add:

• Only complete if there is one completion. If there is more than one, show the alternatives. Completing the first alternative and entering a cycle means users can mistakenly enter the wrong completions (this goes hand-in-hand with showing the alternatives).
• Show completion options in an overlay (say, just above the editor, in place of the horizontal border there)

from matterhorn.

Regarding one behavior you mentioned about continuing to complete even after the user starts doing other typing, a way to fix that (and a way to enable other behaviors such as the overlay I mentioned) is to make it so that Tab causes a state transition out of the main event handler. Once you've hit Tab you're in completion mode where more Tab and Shift-Tab keystrokes and editing keystrokes have special meaning. When the user hits Space in this mode, you have a chance to exit the mode and do any kind of cleanup you want (such as resetting the completion state). This "mode" might just be a flag to set in the application state but you get the idea.

from matterhorn.

Only complete if there is one completion.

Okay, in that case this should be configurable. I prefer the current way when it's combined with prioritized completions.

from matterhorn.

Another approach I can think of that might make us both happy is to give the first completion but show the alternatives so that you know you didn't get the only one. Giving a completion without showing alternatives makes it impossible to tell that you got the right one without hitting Tab again. So I think once we have an alternative-showing overlay, my concern will go away, you'll get the behavior you want, and we won't need configuration (which I'd very much like to avoid for this feature).

from matterhorn.

@dagit you might be interested in aisamanra@3b9fb73 since you had put a comment in the block that I changed.

from matterhorn.

I just recently made some changes to the way commands work—in particular, commands now embed a type that represents the arguments they take. As of now, all those types are variations on Text, but we could embed information about what type they're going to be eventually interpeted as—say, usernames or channel names—and we could in turn use that for extra autocomplete information.

…this might also be a ridiculous amount of overkill. But it's possible!

from matterhorn.

I think that'll be helpful for context-sensitive completion.

from matterhorn.

I just extended this to do something I proposed early on, which is to show alternatives when there is more than one (0a634fb).

from matterhorn.

I'm in favor of calling this "good enough" for our minimal client purposes. Any opposition or other thoughts?

from matterhorn.

Good point. I would like to improve it further and refactor it, but it is
getting the job done.

from matterhorn.

Okay. In that case it sounds like it might be good to create new tickets for specific improvements and close this one.

from matterhorn.