Re: rl_complete(0, '?') should never insert into the line buffer

[Chet Ramey]

On 5/23/24 4:41 PM, Pip Cet wrote:
> On Thu, May 23, 2024 at 3:48 PM Chet Ramey <chet.ramey@case.edu> wrote:
> Please forgive me for reordering your email a little, but I think it's
> best if we start with this:
>
> > The appropriate fix is to separate the behavior of
> > `possible-completions' and consecutive invocations of `complete' so that
> > using M-? doesn't result in a completion being inserted.
> > That will be
> > in the next version of bash/readline, and it's in the respective devel
> > git branches now. I'm not sure that's going to help your particular use
> > case, though.
>
> If M-? is fixed never to insert text, that addresses this bug. 

That's what I'm talking about. The behavior of consecutive TABs to insert a
single completion if one exists even after the previous TAB failed to
generate any possible completions stays, but M-? doesn't insert anything.


> There
> appears to be a separate and very recent readline bug which makes TAB
> after a failed completion list completions rather than insert a unique
> completion, but I hadn't even noticed that one

You're going to have to be more specific; see below.

> > Consider the case that this is designed to address:
>
> Can you expand that example a little? I think there's a
> misunderstanding here somewhere, and I strongly suspect it's on my
> part.
>
> Here are the two interpretations I have of what you describe, using
> bash and default key bindings:
>
> 1. user is in a directory with no x* files.
> 2. user enters c a t > x TAB
> 3. no completions appear
> 4. user goes to another window and creates "xyz"
> 5. user enters TAB again
> 6. The command line now reads "cat>xyz"
>
> That interpretation works with and without the code in question, using
> my system version of readline and bash.

OK, we'll go through the history. Through bash-5.0, step 5 above would have
resulted in readline listing the single possible completion `xyz', leaving
the command line unchanged. I changed this in bash-5.1, so a second TAB
gets you the behavior in step 6 above.

In bash-5.1, hitting M-? in step 5 above also results in readline inserting
'yz' into the line. This is the behavior you identified as a bug.

In bash-5.2, hitting M-? in step 5 lists the single possible completion and
leaves the command line unchanged. This is the appropriate behavior (but
see below).


> It appears to fail with the
> current master branch of readline, but that's a separate bug entirely.

It depends on what you mean by `fail' with the version of
bash-5.2/readline-8.2 I distribute. Again, see below.

> The other one is:
>
> 1. user is in a directory with no x* files.
> 2. user enters c a t > x TAB
> 3. no completions appear
> 4. user goes to another window and creates "xyz"
> 5. user enters M-?
> 6. The command line now reads "cat>xyz"

This was the bash-5.1/readline-8.1 behavior, changed in bash-5.2.


> > Since the last readline command was
> > attempted completion,
> > the default behavior is to list possible completions,
>
> the behavior of TAB or M-? ? The code I referenced does not depend in
> any way on what the last readline command was, it just checks the last
> completion command, which may have been a while ago, failed.

You should look at the caller. That second TAB doesn't get you the call to
rl_complete_internal with the '?' argument unless the last readline
function invoked was rl_complete, which ensures that checking whether or
not the last completion failed is using current data.

The problem even in bash-5.2 is that, under most circumstances, M-? doesn't 
reset or check that and can potentially insert "yz" into the line. That is
what is fixed in the devel branch and bash-5.3-alpha.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/