promptkit
promptkit copied to clipboard
erikgeiser
Multiple Selections
Just a fanciful idea that would work so well for my personal project. I was wondering if you would be keen to consider that a possibility in the near future or if it’s possible to implement with what currently exists? 🙂 Thanks anyways
I've thought about that too. My priorities are currently fixing bubbletea such that multiple prompts don't lose input events, achieving proper test coverage, adding CI and general polish. Then I guess I can look into implementing this.
@erikgeiser Do you have any particular requirements for this feature? Would also love to have this and maybe could find the time to contribute
First of all, sorry for the late reply and thank you for the kind offer @karatekaneen. I had this issue on the back burner because I currently don't have a need for multi selections myself.
Initially, I had a multi-selection mode for the existing selection prompt in mind but I guess they are subtly different enough to warrant their own kind of prompt (e.g. multiselection) even if that results in some code duplication. So as a starting point you could take much of the code could from selection and adapt it. Ideally, the result should feel in line with the other prompts, of course. The code should also be tested and documented (again, look at the other prompts for reference).
There is another issue, though. I was planning on refactoring selection to use generics for the next tagged version (see the branch generics). Obviously, this library will then require Go 1.18. Do you already run Go 1.18? If yes, multiselection should also utilize generics similar to selection on the generics branch. If not we'd have to discuss when and how we can merge the PR so you can at least have a tagged version with your own changes that you can actually use.
Thank you for the response.
Will have a look at the selection package and see if it makes sense to extend it or create a new package. Will probably take a while though but I'll open a draft when I get there and we can discuss things that come up if needed.
Regarding the generics and 1.18 I heard somewhere (think it was here) that almost all go devs upgrade almost immediately because of the full backwards compatability promise so I think it is pretty safe to run the latest version.
I think it's best if you actually create a new package, but you can obviously take a lot of the code from selection package.
Yes, I also think most of the people that manage their Go installation themselves are already on 1.18 but some of the Linux folks have to take whatever the distros ship which can be years behind the current versions. However, they have to deal with the consequences themselves in my opinion. I just wanted to ask because it would be weird to suggest implementing a feature you need with generics if you weren't running 1.18 yourself.
One minor issue is that the linters are currently broken on the generics branch since I enabled Go 1.18. I hadn't had the time to figure out why but I guess it's a bug in golangci-lint. This is also the reason I've been hesitant to merge the branch.
Sorry for the late reply. Maybe I'll take a look at implementing this again, but I can't promise that it will be anytime soon.