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

[Dmitry Gutov]

On 10.09.2021 17:06, João Távora wrote:
> On Fri, Sep 10, 2021 at 2:28 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> > On 10.09.2021 16:14, João Távora wrote:
> > > - If you're OK with letting the server do the filtering and the
> > >     highlighting, you can make a "backend" style like I did for SLY, for
> > >     example.  It's going to be faster, but `completion-styles` won't be
> > >     honoured.  That's doesn't mean you give up 100% on "flex".  In SLY,
> > >     there is flex implemented on the Common Lisp side, and for Eglot, many
> > >     LSP server do their own flex matching.
> >
> > You can't really do that with python-shell completion.
>
> Probably not unless you write some python, no.  I don't see that
> as being that dirty.

I didn't say it was dirty, just not very fitting for the current 
approach: when you do completion by piping code for evaluation through 
inferior shell, you generally like that code to be simple. And 
reimplementing every completion style in Python seems like anything but.

> > Nor do you need
> > do: the basic pcmpl mechanism should work just fine with it, and for
> > performance the completion table just needs some smarter caching.
>
> Yes, as I said in b), with "sufficiently smart caching" (and infinite
> memory space) you can do everything, indeed.  It's one of the
> famous "two hard problems" though, so good luck.

Completion backends do caching anyways, whether it's on the Emacs side, 
or somewhere inside a language server.

Since completion logic is defined on "our" side here (despite being 
written in Python), caching logic can reside here too.