You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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 likecommand --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.The text was updated successfully, but these errors were encountered: