For instance, tab completing > $ tl-config -Ra should call the completer for flag -a. It won't find the option completer though since it's trying to identify an option name corresponding to the squashed short options--in this case 'Ra'. Consequently it moves forward with the default completer. In this particular tl-config case this results in completions from the parameter completer which may produce unviable input to the --all-entries option.
Note that tab completing the following works fine: > $ tl-config -R -a
Seen with server build #3632 on RHEL9.
Created attachment 1203 [details] Disable completion for unidentified options This could be solved simply by disabling completion when we detect previous word is an option but we cannot identify a matching option. Might not be too unreasonable since in general it's unambiguous what option to complete for. Attaching a patch suggestion for optcomplete.py which after some quick testing seems to be working as intended.
Created attachment 1204 [details] Allow one option completer from squashed short options Note that the patch suggestion in comment #3 would disable the default completer following two squashed boolean short options, which is not expected completion behavior. Attaching a second patch suggestion here which, starting from a series of squashed short options, would proceed with one option completer if all other short options take no arguments. Did some quick testing with tab completing "$ tl-config -Ra" and it seems to be working.
Our optionparser has logic for splitting combined shortopts. Perhaps we can plug in to that when solving this?
