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

we should probably compute additional environment variables for completion handlers #25

Open
binduwavell opened this issue May 29, 2016 · 1 comment

Comments

@binduwavell
Copy link
Collaborator

If someone attempts a completion mid-word it may help a completion author to have lastPartialEnd (the remains of the word that is being completed) in addition to lastPartial.

As an example suppose I've typed N<tab>PE and I'm trying to complete a java exception class name. It would help to know PE in addition to N in order to more accurately guess NullPointerException instead of something like NonNumericException.

I assume that prev is used when someone wants to complete an optional value. Say the shell user has typed command --opt foo<tab>, I assume that prev is used to see if we are attempting to complete values for the opt option. If this is correct, we likely should have a prevPartial in addition to lastPartial to handle user entries like command --opt foo<tab> arg1. prevPartial would provide the word prior to the word at the cursor.

Assume the shell user has entered the following command --opt "multi word<tab> value" arg1 arg2.

In bash and zsh, words will be 2 (i.e. it's actually the argument count and not the word count.) It may be worth providing argument based equivalents for: words, last, prev, partial, lastPartial, lastPartialEnd, prevPartial.

In the previous example, using bash, line will be something like command --opt "multi word value" arg1 arg2. While using zsh, line will be: command --opt multi word value arg1 arg2. Note that with bash, position includes the quotes so in our example position will be 25; while with zsh position does not include the quotes so in our example will be 24 (this is both good and bad :) ) We should consider how to normalize these items.

@mklabs
Copy link
Owner

mklabs commented May 30, 2016

Thanks @binduwavell for amazing feedbacks.

Yep, I agree with all you just said. Though, I'm leaning towards simplifying the API and maybe just provide line, prev and cursor. Would be way more clear, and would reduce the API surface a little bit.

Even though they're documented (maybe badly), for instance, I'm sure you was confused with all these options where as line, prev and cursor are all self explanatory.

I'm not sure which road to take yet.

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

No branches or pull requests

2 participants