On Fri, Nov 30, 2018 at 05:21:32PM +0800, Clark Wang wrote:
Just tried 5.0-beta2 and it broke my completion rules. It can be
reproduced with the following steps: ...
Hello Clark; I noticed the same thing; I addressed it in an earlier
message with the attached patch as a suggested fix, modifying a patch
from Luca Boccassi.
<https://lists.gnu.org/archive/html/bug-bash/2018-11/msg00097.html>
----- Forwarded message from Tom Ryder <t...@sanctum.geek.nz> -----
Date: Sun, 25 Nov 2018 23:04:18 +1300
From: Tom Ryder <t...@sanctum.geek.nz>
To: Luca Boccassi <bl...@debian.org>
Cc: bug-bash@gnu.org
Subject: Re: [PATCH] Fix custom program's completions when initial word is set
On Fri, Nov 23, 2018 at 12:48:54PM +0000, Luca Boccassi wrote:
The fix is to only override foundcs if both iw_compspec is not null
and we are not in command position.
Thank you for this patch. I first ran into the issue with 5.0-beta2 another
way: I noticed that my default completion spec with -D as suggested by the
Bash manual page was no longer working:
_completion_loader()
{
. "/etc/bash_completion.d/$1.sh" >/dev/null 2>&1 && return 124
}
complete -D -F _completion_loader -o bashdefault -o default
In 5.0-beta2, after running this code, for any command with no completion
specs defined in /etc/bash_completion.d, completing an argument does nothing.
Your second patch does not correct that, but it looks like that's because a
non-zero `foundcs` is coerced to 1 in it, when there are other meaningful
values for the integer as the first parameter for
`pcomp_set_readline_variables(int, int)`.
The attached patch is my own attempt, which seems to correct my issues as well
as the one you raised in this post. Long-time user, first-time poster...
----- End forwarded message -----
--
Tom Ryder <https://sanctum.geek.nz/>
>From f096da9756ed4d0cd8a6ef5cee02c67377891439 Mon Sep 17 00:00:00 2001
From: Tom Ryder <t...@sanctum.geek.nz>
Date: Sun, 25 Nov 2018 22:43:07 +1300
Subject: [PATCH] Corrections for initial word completion logic
5.0-beta2 includes a correction for the new -I option to the `complete`
builtin:
<http://lists.gnu.org/archive/html/bug-bash/2018-11/msg00035.html>
However, some custom command completion was broken by this due to an
incomplete check for the exceptional midword condition, for which a fix
was offered here:
<http://lists.gnu.org/archive/html/bug-bash/2018-11/msg00088.html>
This patch adjusts the latter fix by preventing coercion of a value of
foundcs that happens to be *greater* than 1 for this block, which also
fixes default completion with -D.
---
bashline.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/bashline.c b/bashline.c
index d56cd79d..b3592e31 100644
--- a/bashline.c
+++ b/bashline.c
@@ -1583,7 +1583,8 @@ attempt_shell_completion (text, start, end)
/* command completion if programmable completion fails */
/* If we have a completion for the initial word, we can prefer that */
in_command_position = s == start && (iw_compspec || STREQ (n, text));
/* XXX */
- foundcs = foundcs && (iw_compspec == 0);
+ if (iw_compspec && in_command_position)
+ foundcs = 0;
}
/* empty command name following command separator */
else if (s >= e && n[0] == '\0' && text[0] == '\0' && start > 0 &&
--
2.19.2
