Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to complete words #2

Open
piotrmurach opened this issue Sep 16, 2017 · 9 comments
Open

Add ability to complete words #2

piotrmurach opened this issue Sep 16, 2017 · 9 comments

Comments

@piotrmurach
Copy link
Owner

piotrmurach commented Sep 16, 2017

@jemc My initial stub at high level api would be something along these lines:

LIST = ['delete', 'update', 'search']

reader = TTY::Reader.new

reader.completion_append_character = " "
reader.completion_proc = -> (word) { LIST.grep(/^#{Regexp.escape(word)/) }

reader.on(:tab) { reader.complete } # searches for matches
reader.on(:completion) { |matches| prompt.diplsay_matches(matches) }
# => displays selection if more than one match found
@piotrmurach
Copy link
Owner Author

More detailed api would include:

reader.completion_append_character # Character appended to completed words 
reader.completion_items  # maximum number of matched items, by default 100
reader.match_hidden_files # by default matching current directory files, by default true
reader.complete_with_tilde_expansion # expand tilde, by default false
reader.word_break_characters # The basic list of characters that signal a break between words
reader.completion_duplicates # disallow duplicates in matches, by default true

@jemc
Copy link
Contributor

jemc commented Sep 16, 2017

@piotrmurach - I spent some time playing with this last night, and began to think that it's hard to design an API that makes sense to add to the TTY::Reader, but is also powerful/flexible enough to do the kind of python-prompt-toolkit-like "fancy prompt" I'm going for:

fancy prompt

So, for now what I'm doing is creating my own high-level library for "fancy prompting" that uses the low-level APIs of TTY::Cursor, TTY::Reader.read_keypress, and TTY::Screen. So far I've created some abstractions that I think are pretty nice and general, while still being powerful enough for "fancy" purposes, but I'm not sure they would really fit with any of your existing libraries (save maybe for tty-prompt). You've created a lot of nice, clean low-level tools, and I don't particularly want to muddy them up unnecessarily, when I can just build on top of them instead.

I'll definitely keep you in the loop about what I'm doing, and when I've got everything tidied up to something I'm relatively happy with, we can maybe brainstorm together and see if there's any abstractions you want to import into one or more of your libraries.

I haven't checked the code into GitHub yet, but just for fun, here's a little teaser of what I came up with so far:
fancyness

@piotrmurach
Copy link
Owner Author

This looks great! I excited about the behaviour as well.

As far as complexity goes I think it's still can be split between tty-reader and tty-prompt. The tty-reader would be responsible for all the logic for finding a match and nothing else. This logic as I've shown you can be quite complex. However, once implemented will make tty-reader a truly versatile component that can be part of REPL or terminal editor or something else. Sky is the limit.

When it comes to tty-prompt, it would call reader.read_keypress and listen for :tab events which would in turn invoke matches = reader.complete and render matches in a table similar to yours. I was even thinking about using tty-table for this part of display.

Anyhow, I'm looking forward to your implementation.

@doriantaylor
Copy link

doriantaylor commented Jan 14, 2021

Whatever happened to this? [removed the remaining content as not related to the issue or helpful]

@zzyzwicz
Copy link

Is there a chance this issue will eventually be solved?
Anything one can do to assist?

@piotrmurach
Copy link
Owner Author

@zzyzwicz As I recall I had a somewhat ready implementation for basic completions implemented. Will need to review it and remind myself where I left it off. I also wish this to be implemented as this is an important feature. I will try to look at this tomorrow as I already have plenty to do today. I know it's been a long wait but we will get there!

@zzyzwicz
Copy link

Happy to see this progressing.
I had a look at Add ability to complete words and would like to suggest to further distinguish between word completion and word proposal.
Assuming the definition of word completion is to (also partially) complete a word up to that letter to which completion is unambigious, and word proposal is to provide with all possible completions,
then this approach rather does word proposal.
In my opinion and also with most command lines i know and work with, the first trigger to complete a word does word completion and only subsequent triggers on a not fully completed word do word proposal.
Would be great if tty-reader could also follow this approach?

@piotrmurach
Copy link
Owner Author

@zzyzwicz Thanks for the feedback! 💯 agreed.

@doriantaylor
Copy link

I see you've implemented completion but version 0.10 is still sitting unreleased? Is there something wrong with it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants