bash-5.0-beta2 breaks ``complete -D''

[Clark Wang]

Hi Chet,

Just tried 5.0-beta2 and it broke my completion rules. It can be reproduced
with the following steps:

# complete -r
# foo() { true; }
# complete -o default -o bashdefault -D -F foo
# cd /<TAB><TAB> <-- Here it does not list dirs under `/'. Works fine
with 4.4.

Please take a look.

-clark

[Tom Ryder]

Post by Clark Wang
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 <***@sanctum.geek.nz> -----

Date: Sun, 25 Nov 2018 23:04:18 +1300
From: Tom Ryder <***@sanctum.geek.nz>
To: Luca Boccassi <***@debian.org>
Cc: bug-***@gnu.org
Subject: Re: [PATCH] Fix custom program's completions when initial word is set

Post by Clark Wang
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 -----