From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Augusto Stoffel Newsgroups: gmane.emacs.bugs Subject: bug#50459: 28.0.50; Python shell completion is incompatible with flex, orderless, etc. Date: Fri, 10 Sep 2021 21:27:29 +0200 Message-ID: <8735qc44f2.fsf@gmail.com> 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> <15c15c3c-5f29-373f-83fc-fc736b45f7ea@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="14789"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Michael Albinus , Lars Ingebrigtsen , 50459@debbugs.gnu.org, Gregory Heytings , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 10 21:28:11 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 1mOmC2-0003bq-S6 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Sep 2021 21:28:10 +0200 Original-Received: from localhost ([::1]:53594 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mOmC1-00042s-MY for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Sep 2021 15:28:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mOmBu-00041T-Kc for bug-gnu-emacs@gnu.org; Fri, 10 Sep 2021 15:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55904) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mOmBu-0007EI-Cx for bug-gnu-emacs@gnu.org; Fri, 10 Sep 2021 15:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mOmBu-0002V8-AC for bug-gnu-emacs@gnu.org; Fri, 10 Sep 2021 15:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Augusto Stoffel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Sep 2021 19:28: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.16313020589576 (code B ref 50459); Fri, 10 Sep 2021 19:28:02 +0000 Original-Received: (at 50459) by debbugs.gnu.org; 10 Sep 2021 19:27:38 +0000 Original-Received: from localhost ([127.0.0.1]:39217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mOmBW-0002UO-8u for submit@debbugs.gnu.org; Fri, 10 Sep 2021 15:27:38 -0400 Original-Received: from mail-wr1-f41.google.com ([209.85.221.41]:36825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mOmBU-0002U9-PU for 50459@debbugs.gnu.org; Fri, 10 Sep 2021 15:27:37 -0400 Original-Received: by mail-wr1-f41.google.com with SMTP id g16so4129882wrb.3 for <50459@debbugs.gnu.org>; Fri, 10 Sep 2021 12:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Iuur4mdtLiLkGdgxMZilegc/kW8tJiBYZoaxKmADtmI=; b=gJrgh9U39I7L3gEbxGbPlTk84chzbLTmVuxJhtvAgW1D0npsjRYpgrNZRDvx2SqbmG 2dzVWSumdnwn3bX+QHk4QfHUIDCzJn1LzjTDXgPF8Rev0K3pna2z7UQilQOU0N/2RbwR 5XwOcuOAgRlFBz1YrS8dZlglEuT75xY7wdOSo26l9dwvl/9+9GIybEnsO8gAR0tKtqAa Ktu2OeoO7hAUYlj9q0H3s8SDjRzXPr8Zu+ivkVBWHsVAl8r6dDzeE9EoBC/+NBOuPR03 +onWNC6l+zzXzhOEIzKOZCS2J16xhZq29CUnlJPcfA0XccaLmDE5rZeulliiKDAzafM6 WcRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Iuur4mdtLiLkGdgxMZilegc/kW8tJiBYZoaxKmADtmI=; b=j7n6REQrHgbUaEUXKXp0omP5pr5sq+1pu2s3+L8yvPDFEH9XStOnjC8Q3OFslFcNTT RtV1RPRLl9CaEj2OxkEXNWY27h4Z6anOhgiKz/26JhdWpp/0RfkW1dbTG3XoZliBO5oJ Jv1ulSCR7+FE4B01Cuo0zso4uTbWcDNpKhbWmOP/4lEL4iNa++MXdLji9o/+uii19HeP Yc61n/pDs2PS0Xf6lzoEdg0v1m92hOoC/Vu135CoGmbipsaK/oOKhwUV3oF61AkD1mNQ TEPFTrNjecdvdUNKobuo3IE8nSFd/qb9csgSCtAfqUci5R5b+7Lj02Y2dDEiDrou1qev kHfw== X-Gm-Message-State: AOAM530X+GsasdXIuXHExGARqeBEtw8Vjk0VN+HgdiBBpJWqx0PiyB2v R6++zPsr/VRFsz4mbEM89Tk= X-Google-Smtp-Source: ABdhPJzFjxdIZ5BEX4diLE1DT4IQnasPdRBnVQBqBWa7nTQ70hatWSDA6kZ2BldUSqWWnnaXVXLqSA== X-Received: by 2002:adf:d231:: with SMTP id k17mr11544295wrh.389.1631302050920; Fri, 10 Sep 2021 12:27:30 -0700 (PDT) Original-Received: from ars3 ([2a02:8109:8ac0:56d0::b1d]) by smtp.gmail.com with ESMTPSA id u23sm4888250wmc.24.2021.09.10.12.27.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Sep 2021 12:27:30 -0700 (PDT) In-Reply-To: <15c15c3c-5f29-373f-83fc-fc736b45f7ea@yandex.ru> (Dmitry Gutov's message of "Fri, 10 Sep 2021 17:43:05 +0300") 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:214037 Archived-At: On Fri, 10 Sep 2021 at 17:43, Dmitry Gutov wrote: > On 10.09.2021 17:39, Jo=C3=A3o T=C3=A1vora wrote: >>> 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" versio= n. > > The proposed patch provides the "intra" version. I just wanted to emphasize that the approach of evaluating code and asking an interpreter for completions is obviously a dead end. I guess it is still the best available at the moment for the REPL, so it makes sense to ensure it's reasonably correct and doesn't hang your comint. But further optimizations are not really worth the effort. The LSP stuff is much more interesting, and there the caching question is pretty hairy...