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 14:14:23 +0100 Message-ID: <87ee9wa7yo.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> 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="14141"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 50459@debbugs.gnu.org, Lars Ingebrigtsen , Michael Albinus , Gregory Heytings To: Augusto Stoffel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 10 15:15:36 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 1mOgNU-0003QJ-59 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Sep 2021 15:15:36 +0200 Original-Received: from localhost ([::1]:51686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mOgNS-0005Zf-1Y for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Sep 2021 09:15:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46182) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mOgMw-0005Z0-Gd for bug-gnu-emacs@gnu.org; Fri, 10 Sep 2021 09:15:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53938) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mOgMw-0002ke-8t for bug-gnu-emacs@gnu.org; Fri, 10 Sep 2021 09:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mOgMw-0006aV-4N for bug-gnu-emacs@gnu.org; Fri, 10 Sep 2021 09:15: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 13:15: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.163127967725252 (code B ref 50459); Fri, 10 Sep 2021 13:15:02 +0000 Original-Received: (at 50459) by debbugs.gnu.org; 10 Sep 2021 13:14:37 +0000 Original-Received: from localhost ([127.0.0.1]:37246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mOgMW-0006ZD-Vk for submit@debbugs.gnu.org; Fri, 10 Sep 2021 09:14:37 -0400 Original-Received: from mail-wm1-f48.google.com ([209.85.128.48]:43549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mOgMS-0006Yw-Fx for 50459@debbugs.gnu.org; Fri, 10 Sep 2021 09:14:35 -0400 Original-Received: by mail-wm1-f48.google.com with SMTP id n7-20020a05600c3b8700b002f8ca941d89so1367347wms.2 for <50459@debbugs.gnu.org>; Fri, 10 Sep 2021 06:14:32 -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=1qGfUO8INha7qUjNEKrk7//XVXUy7RK3ku4+lStyv+M=; b=cUQE8Nx4DYwAi2ZNwUjWau/gQTEdOxDo8ws8tFABgdaAywhtuXhZwRaFHb6lc9ueQw 99zcJzr+VfhUFbqEHJ+7cpRfgb7XzHjV08V0C+NE0lmYd9skjUjqnEsY/ainyyb12cEn r9CIcZQhFoMm3bgtHUwnsvft4Rpi9bJvG3DNfJfiECPugsS7gIUHLWZdFIci6ABI1YBX WVz93xnXVw97YYyHaxJAF0DheUgUd6FB7DOM/lW67IiMMzRnixLrMXf+Zh3LmrpbvwqO p0i5D/HXeeg3whRW80LLoRwutnWb5VnEra6NPq0PrNe+UqD5GEH1R+FqywT/8Zr+F80R 0lIA== 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=1qGfUO8INha7qUjNEKrk7//XVXUy7RK3ku4+lStyv+M=; b=S1eFyquTClVbrV+uEpKGbo7Nn1wt8j8fboEebema6/+fkZ0slh6fM3bWVRoqZetcVD fLG3yBfU9DCDYkonOJ5CDWRJHL9GwNG1xIAIJE7Ut2r19l58KWnwOmbrvGbioYILwjCl frjAXZLBHbEleJHZ8kD9WeWO/ZKV0J6a10NqrkV2MfxqQro4sIhDCAPTblBGSeRjBU77 svG0nqfzpPMdqYRFwBdczs+QEqhBYJELJQS6C9WvlmzhWBtXQWdMTWu1NUj1DM0NiqYL tp2Dxgdlvc3Zhiz43qBXdc7lLuD77QtTBpXgVG+ckkOlqqOy5Z5L0aOaCxJ44Zc/2Dm7 f/ZQ== X-Gm-Message-State: AOAM531pbnsj1fQvHBvxVcyV1KZ3Lx4whMwr8F4jz6JlbiUD1u0mT6TX H8F8CYtjX183X81op/SBWR0= X-Google-Smtp-Source: ABdhPJxN7q/HFK6a3qOxSwzKV2enBziMjR4a17fUBuzNE/vhGNRxQuvE0Nsot1gzxRmy8sW5wGu1+Q== X-Received: by 2002:a7b:c4d2:: with SMTP id g18mr8439054wmk.135.1631279666433; Fri, 10 Sep 2021 06:14:26 -0700 (PDT) Original-Received: from krug ([62.48.174.238]) by smtp.gmail.com with ESMTPSA id c14sm4353590wme.6.2021.09.10.06.14.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Sep 2021 06:14:25 -0700 (PDT) In-Reply-To: <87zgskejjq.fsf@gmail.com> (Augusto Stoffel's message of "Fri, 10 Sep 2021 13:50:33 +0200") 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:214007 Archived-At: Augusto Stoffel writes: > On Fri, 10 Sep 2021 at 13:37, Lars Ingebrigtsen wrote: > >> Augusto Stoffel writes: >> >>> To alleviate this, the completion-at-point function could implement some >>> sort of caching. The difficult question is when to invalidate the >>> cache. I've attached one possiblility as a draft patch. If the >>> approach seems reasonable, then I'll format it properly. >> >> Would it be possible to do caching at a lower level instead of in >> python-mode? > > I'm not an expert in this either, but I think the caching mechanism > would be pretty particular to the circumstances of each completion > table, so it indeed belongs here. Maybe Jo=C3=A3o can say more? I'm sorry, I'm quite overloaded lately and can't read this long thread. I've been participating in a few discussions about this and all I can add here are generic comments, like the intepretation that I make from the docstring of completion-at-point-functions Special hook to find the completion table for the entity at point. Each function on this hook is called in turn without any argument and should return either nil, meaning it is not applicable at point, or a function of no arguments to perform completion (discouraged), or a list of the form (START END COLLECTION . PROPS), where: START and END delimit the entity to complete and should include point, ^^^^^^^^^^^^^^^^^^^^^^=20=20=20=20=20 COLLECTION is the completion table to use to complete the entity, and ^^^^^^^^^^^^^^^^^^^ PROPS is a property list for additional information. As I've underlined, it's _that_ entity, not some other entity that the "backend" aka "capf" should complete. So: a) while the entity is "the same" (START and END are the same and POINT is somewhere in between) then the backend can do caching inside COLLECTION (Eglot does caching between calls to try-completion, all-completions, and others, for example). b) if the entity changes because the buffer has been changed, by any means -- including the means of an completion UI -- then the completion UI should re-invoke the capf to get a the new entity to complete and the new COLLECTION to complete it. Emacs's default completion UIs do this, and so does Company, if I'm not mistaken. If the backend is super smart and can be faster about responding to this new capf invocation validly given the previous respose that's fine. But my point is this other caching is much more difficult to do accurately because of buffer changes and assumptions about the filtering strategy. For example, a cache that assumes that adding a character to the end of entity will always produce a subset of previously obtained completions will fail if the completion style is some kind of "regexp-based" thing, or if that character is '.', for example But it might work decently in some situations. Anyway, another generic point that I've been trying to make is that filtering/completion-styling should be done as close to the source of completions as possible. In Elisp this is easy to do (completions are basically lists of strings or the big cheap-to-access obarray). If the source of the completions is removed from Emacs by some latency, the experience is never going to be as good as Elisp. - If you want to fully honour `completion-styles` which is an Elisp facility, you need to know most complete set of completions possible at all necessary times. That's going to be slow (but read my final paragraph). - 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. In any case, it is generally possible to design responsive backends systems that let the user interact with Emacs while the "slow requests" are ongoing, by having these backends cancel themselves when input is available. This uses while-no-input and sit-for. See jsonrpc.el's jsonrpc-request for an example. I've been using these kinds of systems very successfully over the past 4-5 years with SLY, Eglot as backends and Company UI as a frontend. Hope this helped, Jo=C3=A3o