Support suggestions and autocompletion in textinput

[toadle]

Continuation of discussion from here: #140

[toadle]

@maaslalani In my implementation here: #140 there was an id in the Model of textinput to check if we complete the right textinput. That is now completely gone from the model. Do we still need that?

[maaslalani]

This is awesome @toadle! Thank you so much!

[toadle]

@maaslalani You think we can get this merged?

There was one thing that I was still thinking about: If there are several suggestions populated

• "Hello World"
• "Hello You"
• "Foo bar"

and you currently have "Hello" typed in, you can switch through all three. Ending up in the last situation where there is nothing to complete when having "Foo bar" selected, because "Hello" can not be completed to "Foo bar".

Should the autocomplete work in a way where the input also looks for the next possible suggestion if the current one can not be used to complete? Effectively switching the current selected suggestion.

The otherwise to do it would be to always switch the possible suggestions externally.

I kind of have the feeling that it should cause it'll be more useful that way. But I also would like to get this merged ;-)

[toadle]

Anyway, forget my last comment. I just fixed it here: 2d16f32

Should be good to go. I hope we can merge this, so that it doesn't get stale again :-)

[toadle]

Little preview:

[meowgorithm]

@toadle so what you're saying is that you're building a bubble tea integration called toadle-copilot, right?

[toadle]

@meowgorithm Unsure if pun or not :-)?!

[meowgorithm]

@toadle Totally joking around. This looks awesome!

[toadle]

@maaslalani What do you say?

[maaslalani]

Going to try and get this merged today! Thanks so much for all your work @toadle.

[toadle]

@maaslalani I saw that you removed the Msg to set suggestions in the recent commit. Please remember that suggestions most likely will get stemmet asynchronously by the result of another cmd. We discussed that over on the other PR. Would you still set them via a func-call then?

[maaslalani]

@maaslalani I saw that you removed the Msg to set suggestions in the recent commit. Please remember that suggestions most likely will get stemmet asynchronously by the result of another cmd. We discussed that over on the other PR. Would you still set them via a func-call then?

Yep, I will add the asynchronous setting back since many people may get their autocompletion data from an API or external source. But we should definitely also allow setting the suggestions statically since a lot of people may already have the values beforehand when creating the textinput bubble.

[maaslalani]

Hey @toadle looks like this PR will need some adjustments to get double width runes working: I can handle that soon!

[toadle]

@maaslalani OK, that double-width rune thing is weird. I tried to fix that myself just now but always end up with the same problem. I'll also have a look if I can fix that.

I pushed a little other change where I expose a function that can help customize to complete behaviour (e.g. if you want to complete just up to the next "space" or "-"). I think it'd be good to have that - I can think of several use-cases.

[toadle]

@maaslalani Finally understood how []rune vs. string works in Go. Refactored everything to work with []rune - much better now. Should work fine with "charm热爱开源" and sorts now.

[maaslalani]

Amazing @toadle! I will take a look and merge this soon 🎉
Thanks again for all your work!

[maaslalani]

@toadle after doing a bit of testing it's definitely possible to use the SetSuggestions stuff with custom commands on the developer end. So I say we merge this as is.

For example, a user can do the following:

type setSuggestionsMsg []string

func loadSuggestions() tea.Msg {
	time.Sleep(5 * time.Second) // Fetch from a data source.
	return setSuggestionsMsg(pokemon[0])
}

// ... Update method.
	case setSuggestionsMsg:
		m.textInput.SetSuggestions(msg)

Since the user can implement a basic Cmd for asynchronous data / completion fetching I think this is enough to enable this functionality for now. If necessary / requested we can add a first class API for async completion but I think the current way is more customizable for the developer.

[maaslalani]

Also tested with double width runes and everything is working great!

[toadle]

@maaslalani If that works too i think it is also fine to have it work like this. In my tests it somehow did not work, but my implementation already differs quite substantially from the one here. So the error might be in my side.