Have a method to prevent space from being added after an invalid one-result completion
If I have a completion setup like this: complete -F complete_something something And then get complete_something to assign a single directory-only result to COMPREPLY, I'd like the completion mechanism to not add a space just so the user would know immediately that it isn't a valid completion. I hope a feature method or mechanism can be added as well to make this possible. Running `compopt [+-]o nospace something` at the end of complete_something doesn't help as it doesn't seem respected right away. I also can't use `-o nospace` by default as I also complete predictable non-file stuff. I thought about excluding directories with no file children or grandchildren as a workaround but this would be slow, use unnecessarily large IO, and bring inconvenience to the user. It would be better to show them an empty directory than let them wonder why it's not appearing in the completions. -- konsolebox
Re: Have a method to prevent space from being added after an invalid one-result completion
Nevermind I found a way. The trick is to enable nospace by default and add space manually to only result when result is 1 and is valid. -- konsolebox
Re: Space vs. non-space separators in COMP_WORDBREAKS
On 12/16/21 6:56 PM, konsolebox wrote:
If I have a function like
function _complete_something {
printf -v __ '%q ' "$@"
logger -p debug -t something "Args: $__"
logger -p debug -t something "$(declare -p COMP_WORDS)"
}
And in COMP_WORDBREAKS I have '=' included in the assignment.
It's in the default value of rl_completer_word_breaks.
And I execute this command:
complete -F _complete_something something
After I type something like this
something --option=/something[TAB]
I'll also get = in one of the arguments.
This seems to mean that separators specified in COMP_WORDBREAKS that
aren't spaces are also passed as an
argument and stored in COMP_WORDS. This surprised me a bit, and I
think it would be helpful if this behavior gets documented as well.
Well, the documentation says the line gets broken into words the way
readline does it, and readline uses the characters in
rl_completer_word_breaks as delimiters but doesn't remove them from
the list. It just uses them as word separators to bound the word to be
completed.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Space vs. non-space separators in COMP_WORDBREAKS
On Sat, Dec 18, 2021, 00:49 Chet Ramey, wrote: > Well, the documentation says the line gets broken into words the way > readline does it, and readline uses the characters in > rl_completer_word_breaks as delimiters but doesn't remove them from > the list. It just uses them as word separators to bound the word to be > completed. But that doesn't explain why the spaces are removed and I can't find anywhere in the documentation of readline that explains it. I would have to study the code itself to know why. Right now I can only guess that maybe word splitting happens in two phases where in the first one natural word splitting is used and spaces are removed, and in the second phase the separator is respected but is still recorded as another word. This makes the default value of COMP_WORDBREAKS (in the context of bash if bash does the first phase) or rl_completer_word_break_characters (in the context of readline) misleading to the way words are split and retained because it includes the space as part of the value. Where the value was originally initialized doesn't matter. I also looked at other readline variables that may have influence on how a separator is kept like rl_special_prefixes but none of them seems to have anything to do with the space character. -- konsolebox
Re: Space vs. non-space separators in COMP_WORDBREAKS
On 12/17/21 2:00 PM, konsolebox wrote: On Sat, Dec 18, 2021, 00:49 Chet Ramey, wrote: Well, the documentation says the line gets broken into words the way readline does it, and readline uses the characters in rl_completer_word_breaks as delimiters but doesn't remove them from the list. It just uses them as word separators to bound the word to be completed. But that doesn't explain why the spaces are removed and I can't find anywhere in the documentation of readline that explains it. I would have to study the code itself to know why. Because nobody wants empty arguments to deal with, but it's useful to know where readline splits the words when it finds the word it wants to be completed. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Space vs. non-space separators in COMP_WORDBREAKS
On Fri, Dec 17, 2021 at 7:13 PM Chet Ramey wrote: > > On 12/17/21 2:00 PM, konsolebox wrote: > > On Sat, Dec 18, 2021, 00:49 Chet Ramey, wrote: > >> Well, the documentation says the line gets broken into words the way > >> readline does it, and readline uses the characters in > >> rl_completer_word_breaks as delimiters but doesn't remove them from > >> the list. It just uses them as word separators to bound the word to be > >> completed. > > > > But that doesn't explain why the spaces are removed and I can't find > > anywhere in the documentation of readline that explains it. I would > > have to study the code itself to know why. > > Because nobody wants empty arguments to deal with, but it's useful to > know where readline splits the words when it finds the word it wants to > be completed. > Ok but anyway, shouldn't this be mentioned in the manual? It's pretty much intuitive that if space is removed (which is the first one easily noticed), so should other separators specified in COMP_WORDBREAKS. In my opinion it would have been better if separators were stored in another variable than COMP_WORDS instead, where the index is the index in COMP_WORDS of the word that follows the separator or sequence of separators minus one. -- konsolebox
