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

[Chet Ramey]

On 5/22/24 8:03 AM, Pip Cet wrote:

x x BACKSPACE x x

with automatic completions before and after the BACKSPACE, will result
in the line buffer showing "xyz xx". The expected output is "xxx".

It's this code in complete.c:

     case '?':
       /* Let's try to insert a single match here if the last completion failed
      but this attempt returned a single match. */
       if (saved_last_completion_failed && matches[0] && *matches[0] &&
matches[1] == 0)
     {
       insert_match (matches[0], start, matches[1] ? MULT_MATCH :
SINGLE_MATCH, &quote_char);
       append_to_match (matches[0], delimiter, quote_char, nontrivial_lcd);
       break;
     }

The code in question seems extremely questionable to me: '?' is meant
to LIST completions (non-destructively), not insert a completion.
Again, with most applications, it's valid and useful to continue
typing in something that doesn't match a completion.

Consider the case that this is designed to address: a user attempts word
completion, and finds that the completion doesn't produce any matches.
They then go off to another window and fix whatever the problem was, and
come back and try completion again. Since the last readline command was
attempted completion, the default behavior is to list possible completions,
but in this case, listing a single completion that the user knows is there
is pretty hostile. It's better to just insert the single completion, since
there is one, and go on.

Let's just remove this special case: it's undocumented, violates the
distinction between text-modifying and non-destructive calls of
rl_complete, it's useless for applications where non-completed words
are still valid input, and it complicates things.

No, it's valuable. 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.


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

OpenPGP_signature.asc
Description: OpenPGP digital signature