bug#50459: 28.0.50; Python shell completion is incompatible with flex, orderless, etc.

[Augusto Stoffel <arstoffel@gmail.com>]

On Thu,  9 Sep 2021 at 07:49, Gregory Heytings <gregory@heytings.org> wrote:

>>> You shouldn't use (setq completion-styles '(flex)), you should use
>>> (add-to-list 'completion-styles 'flex).  Otherwise the default
>>> completion styles are not used anymore.
>>
>> This doesn't change the issue described in the subject line.  I
>> would still not see any flex completions if I did what you suggest.
>>
>
> Because the flex completion mechanism returns no completions, and the
> next completion mechanism is called.  What kind of flex completions
> would you expect to see after x.t TAB in your example?

For sure 'x.count' should be a candidate, just like in Elisp 'set' shows
up as a possible completion after typing '(t TAB'.

Whether or not your example should allow 'fix.it' as a completion is up
to debate.

>
>>
>> Granted, completion wouldn't be totally broken.  But I don't mind
>> letting the brokenness manifest itself.  Therefore I use (setq
>> completion-styles '(orderless)).
>>
>
> It's not broken, it works as designed.  Instead of asking each user of
> the completion mechanism to implement a specific function for
> substring / flex completion, these mechanisms tell them "please return
> all possible completions, I'll do the filtering job for you".

Right, this is not a problem with the flex style, it's a problem with
the Python completion table.  More specifically, with its notion of "all
completions".