If the user types:
gcfile.c
And positions the cursor of 'f', a programmable completion enabled on
initial word (-I) will fail to run. This is because the parsing gives
priority first to the _minimal programmable completion that does
nothing, and then if that is disabled it gives the next priority to
command completion, unlike what happens when completing a full word,
stopping the initial word completion from working.
To reproduce:
cat > repro<<EOF
_repro()
{
echo "completed"
}
EOF
source repro
complete -I -F _repro
lsfile
^ tab with cursor on 'f', nothing happens
complete -r -F _minimal
lsfile
^ tab with cursor on 'f', command completion happens
To fix this issue, if iw_compspec is defined (initial word completion
is enabled) allow to complete a prefix of the entered text and skip
command completion.
Signed-off-by: Luca Boccassi <bl...@debian.org>
---
Dear maintainer,
This is the simplest and cleanest solution I could find. I'm happy to
test alternative bug fixes if necessary.
Thanks!
bashline.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/bashline.c b/bashline.c
index 0d39714f..83ef3fa8 100644
--- a/bashline.c
+++ b/bashline.c
@@ -1580,8 +1580,11 @@ attempt_shell_completion (text, start, end)
else if (e > s && was_assignment == 0 && have_progcomps)
{
prog_complete_matches = programmable_completions (n, text, s, e,
&foundcs);
- /* command completion if programmable completion fails */
- in_command_position = s == start && STREQ (n, text); /* XXX */
+ /* command completion if programmable completion fails.
+ Initial word completion can be done on prefix: gcfile.c -> gcc
file.c
+ when tabbing with cursor on 'f' and needs to have precedence over
cmd completion. */
+ in_command_position = s == start && (iw_compspec || STREQ (n, text));
/* XXX */
+ foundcs = foundcs && !iw_compspec;
}
/* empty command name following command separator */
else if (s >= e && n[0] == '\0' && text[0] == '\0' && start > 0 &&
--
2.19.1
