Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Tom Ryder <tom@sanctum.geek.nz>
Newsgroups: gnu.bash.bug
Subject: Re: [PATCH] Fix custom program's completions when initial word is set
Date: Sun, 25 Nov 2018 23:04:18 +1300
Lines: 82
Approved: bug-bash@gnu.org
Message-ID: <mailman.4585.1543147539.1284.bug-bash@gnu.org>
References: <20181123124854.4208-1-bluca@debian.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf"
Cc: bug-bash@gnu.org
To: Luca Boccassi <bluca@debian.org>
Envelope-to: bug-bash@gnu.org
Content-Disposition: inline
In-Reply-To: <20181123124854.4208-1-bluca@debian.org>
User-Agent: Mutt/1.10.1+2 (7e6b35c6) (2018-07-16)
Precedence: list
Xref: csiph.com gnu.bash.bug:14852


--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline

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...

-- 
Tom Ryder <https://sanctum.geek.nz/>

--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-Corrections-for-initial-word-completion-logic.patch"

>From f096da9756ed4d0cd8a6ef5cee02c67377891439 Mon Sep 17 00:00:00 2001
From: Tom Ryder <tom@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


--J2SCkAp4GZ/dPZZf--