From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#50459: 28.0.50; Python shell completion is incompatible with flex, orderless, etc. Date: Fri, 10 Sep 2021 15:39:46 +0100 Message-ID: References: <87wnnsl1d1.fsf@gmail.com> <87czpijixk.fsf@gmail.com> <877dfqjfwu.fsf@gmail.com> <87mtolr91a.fsf@gmail.com> <877dfopsoa.fsf@gnus.org> <87zgskejjq.fsf@gmail.com> <87ee9wa7yo.fsf@gmail.com> <8ee6271b-142e-7cc1-3d24-7e5c342ef86b@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9977"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Augusto Stoffel , Lars Ingebrigtsen , Michael Albinus , 50459@debbugs.gnu.org, Gregory Heytings To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 10 16:43:34 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mOhkb-0002PN-Vr for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Sep 2021 16:43:33 +0200 Original-Received: from localhost ([::1]:37792 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mOhkZ-0000Ua-Vt for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Sep 2021 10:43:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44958) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mOhiA-00043Q-Tf for bug-gnu-emacs@gnu.org; Fri, 10 Sep 2021 10:41:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55631) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mOhiA-0003yP-9K for bug-gnu-emacs@gnu.org; Fri, 10 Sep 2021 10:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mOhiA-0000mN-7P for bug-gnu-emacs@gnu.org; Fri, 10 Sep 2021 10:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Sep 2021 14:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50459 X-GNU-PR-Package: emacs Original-Received: via spool by 50459-submit@debbugs.gnu.org id=B50459.16312848062923 (code B ref 50459); Fri, 10 Sep 2021 14:41:02 +0000 Original-Received: (at 50459) by debbugs.gnu.org; 10 Sep 2021 14:40:06 +0000 Original-Received: from localhost ([127.0.0.1]:38944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mOhhG-0000l5-A6 for submit@debbugs.gnu.org; Fri, 10 Sep 2021 10:40:06 -0400 Original-Received: from mail-pg1-f174.google.com ([209.85.215.174]:43631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mOhhE-0000kV-N5 for 50459@debbugs.gnu.org; Fri, 10 Sep 2021 10:40:05 -0400 Original-Received: by mail-pg1-f174.google.com with SMTP id r2so1984863pgl.10 for <50459@debbugs.gnu.org>; Fri, 10 Sep 2021 07:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tlStJC2a4hpfSpTY1ftjB3T96uhLq7mpPBp0jE4h25s=; b=WoJEY7GPWwhNpfDe3dNe/H3OjVPo7pwHQIj62cVOpxC9pkZIRIu/A51NGKvz8W231O A+EHX38+h41jlWD+KdNYT/4QudvcS/XsVCLsjHeA6y55iK0EG14Qh+z0l131L5nVGass dOewcL+7ZEOzl8nvJmV7tfDYuG3nIg3DY4mKozRaMRVyYxip25i5xAJqf+x0ECV5/x7p f4QQFBmjNnOBRhVMlPVYRCUKH5fCnXrMhvBrc1UokQRKCmAhQAWz1u9bVRy+1huowvMm cPuCFv78kLEeGUgRckAWjpUnps/pdRX23Mm8E5F2ut2A3y8NdxABdLWpjnc0xvsd3BQ6 IGyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tlStJC2a4hpfSpTY1ftjB3T96uhLq7mpPBp0jE4h25s=; b=5I7fIuOXDzrIniswXPGK0JfVFm4aH9aX2Jrgrz+6aEsZfb+8KnhOmBOz5UdMTNLRqq GHZjC6bzj2JfRxo6HAS9JLdsu5YxhkP+z+vLaVa6IwxlPTinnn1rB4iJ+Q3U/AN3PZoJ qPU6NA1jSxRSA7hVbMOhfPX3q0Swq0p6hKP1mO8IY94+NF7/3jH/VrdF9tEJODs+2Gti M43d99sqru6bv0fdiW8DT1hOM4T4ZKKad35dwml8KEibLc4PpISbBe4PPFuyGM2hfZe9 03tRHUq4Tb0TTTRvSIzgpUJLXvN+HzwvyRkn+VmMxNi5Tw6SfW8wNgokMIYNXTRMnfdZ yKEw== X-Gm-Message-State: AOAM530S8nfEJJMZynK5VqP0wQsSZjLiMjtDuNfsnc0K0kfrELIZ7h7L Y8/31TRjvtmCcSW+AL9XFQaKuhZUj8nmftZhAew= X-Google-Smtp-Source: ABdhPJx5hORhNMLmJO9AVHbh3PGtVguoRlO5GEZfiaJqENLSfGbb0YMsaGSklfibzqIGsF/9aLxomGUrD586Flf0rM8= X-Received: by 2002:a63:4c5c:: with SMTP id m28mr7497253pgl.67.1631284797578; Fri, 10 Sep 2021 07:39:57 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:214018 Archived-At: On Fri, Sep 10, 2021 at 3:22 PM Dmitry Gutov wrote: > > On 10.09.2021 17:06, Jo=C3=A3o T=C3=A1vora wrote: > > On Fri, Sep 10, 2021 at 2:28 PM Dmitry Gutov wrote: > >> > >> On 10.09.2021 16:14, Jo=C3=A3o T=C3=A1vora 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 SL= Y, > >>> 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. I was just volunteering an opinion on how to solve _most_ of the problem (hence I wrote "don't give up 100%") Never did I suggest to implement "every completion style". SLY implements only two in Common Lisp. They're pretty sufficient for most users it seems. Most language servers seem to implement flex, some only prefix, some may be configurable I suppose. > Completion backends do caching anyways, whether it's on the Emacs side, > or somewhere inside a language server. There are many types of caching, as I tried to explain. Inter-capf-invocation caching (if you can understand what I mean) is possible, but is probably harder to get right than the "intra" version. I'm really just stating the obvious: the more removed you are from the source of truth, the harder it becomes to cache. But also, it's true that are definitely valuable, if implemented correctly or if a degree of inaccuracy is tolerated. Fast and accurate is hard. Jo=C3=A3o T=C3=A1vora