From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Carlos Pita Newsgroups: gmane.emacs.bugs Subject: bug#51575: 28.0.60; Many issues with icomplete-in-buffer Date: Sun, 7 Nov 2021 20:10:20 -0300 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30251"; mail-complaints-to="usenet@ciao.gmane.io" To: 51575@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 08 00:12:57 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 1mjrLM-0007c4-0k for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Nov 2021 00:12:56 +0100 Original-Received: from [::1] (port=34208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mjrLK-0004WK-Ol for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Nov 2021 18:12:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38574) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mjrJW-0002FE-LR for bug-gnu-emacs@gnu.org; Sun, 07 Nov 2021 18:11:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43667) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mjrJW-0002NV-BP for bug-gnu-emacs@gnu.org; Sun, 07 Nov 2021 18:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mjrJW-0006nA-3z for bug-gnu-emacs@gnu.org; Sun, 07 Nov 2021 18:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Nov 2021 23:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51575 X-GNU-PR-Package: emacs Original-Received: via spool by 51575-submit@debbugs.gnu.org id=B51575.163632664126080 (code B ref 51575); Sun, 07 Nov 2021 23:11:02 +0000 Original-Received: (at 51575) by debbugs.gnu.org; 7 Nov 2021 23:10:41 +0000 Original-Received: from localhost ([127.0.0.1]:55213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mjrJB-0006mZ-Dw for submit@debbugs.gnu.org; Sun, 07 Nov 2021 18:10:41 -0500 Original-Received: from mail-wm1-f45.google.com ([209.85.128.45]:43914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mjrJ8-0006mL-RK for 51575@debbugs.gnu.org; Sun, 07 Nov 2021 18:10:40 -0500 Original-Received: by mail-wm1-f45.google.com with SMTP id 67-20020a1c1946000000b0030d4c90fa87so10424616wmz.2 for <51575@debbugs.gnu.org>; Sun, 07 Nov 2021 15:10:38 -0800 (PST) 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; bh=Iv5yoM0LwNMWLiZIuK+JRdzvdibIfuHoLxYvnTqLH3Q=; b=ZBb+5GfzOIYKadgqvsTCfe9pLLC2xQwCIAVes84kb8cMrA0oItIwBEoS+tC5NIPL9J aEDCaJp2uo8fW8ejwwtACwvwhmFAGONjZAn5/zdcpl7jS2Bmwyoh/B1+5yW1D3yf8sCH XC4/XxZiUyp4KtQsI7TxTe3Lhdhm1hNSLt/h8syXQ86PnCyT5IZ16RxDVBP7+TL78n48 FpKPvPmRCdzWykVrQ7BEPmOz1fWr7wW4s28E5M2a+xBIIE+AAEeroqGSCFIVJw1pI5dr gWv9vRQTnmi9PzLN6goYdlU9hGBY216tHDzHpQE9bdeX19xvpr7c8vKnPr4ol6+xMdpO ubdA== 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; bh=Iv5yoM0LwNMWLiZIuK+JRdzvdibIfuHoLxYvnTqLH3Q=; b=tUDdz9iXGhv0tEdfEaz5UGj+V3j6qlwqPmdVKvCa8WCQLR08DFIGeobBxAgwp4F62W kJiEeWj8cDJc4STtHG1O9zlYVpEjELjcCLmdXXxH5Fo6Z6GGWSwHOvIcu1C6eBWDoWSl gp18bRcR5+1FbZNvpv1uHz1U4gUVgC+S/g/zQBMlkHXs0EvtN8hBqN/EugH1T3py7MK8 mUYO+k6luU+lPmIkj0bco+HOvaK9JG1KAPeNJnau+1PdogO8yuhs6RoDanYfso+lFUQC VBOvfABmOY4h8AyPOdn7FTPsgI477v8i4CHje3vL74MXIAE6EuWICRoFQKFOc+HeXH5V bLaw== X-Gm-Message-State: AOAM532xGsAnVvRDesWquksioKi6S8pqB5wDEWHWNRrDQJiFuyfQfjpQ yfOuDO4ZWrkAxu1Bqf4OMMoimSOKcAwf1bgAWJW6Tq+LsJrFwQ== X-Google-Smtp-Source: ABdhPJzljXWGDszMJJvtDuFvGM65woJ3lwGNb6R3nsgL4RMxQACyEn/axyayRLEgeEtviyZHSzjUzLIISKDfMtPMys4= X-Received: by 2002:a1c:7c12:: with SMTP id x18mr49486149wmc.95.1636326632553; Sun, 07 Nov 2021 15:10:32 -0800 (PST) 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:219301 Archived-At: > Maybe this is a legacy option that should be made obsolete, but it's a > pity that vanilla emacs provides so many alternatives for > completing-read but none for completion-at-point. > [...] simply showing the standard minibuffer icomplete > interface at the bottom would be a lot (like for example selectrum > does). I've learned some new facts that may be relevant to this: - The consult package [1] provides this functionality for any completing-read solution, including icomplete/fido (and also vertico [2] and selectrum [3], although selectrum also provides a builtin alternative). - IDE-like packages that use LSP-servers to get completions are popular these days and their completions are based on the contents of the buffer (I guess the server works at the file level), so any solution that moves the edition to the minibuffer will fail to update the buffer and therefore won't play well with the LSP-server. So in-minibuffer is simple to implement and there are external implementations that are compatible with icomplete, but it's not LSP-friendly. OTOH, emacs includes what AFAICS is a broken attempt to implement something like in-buffer icomplete, which perhaps will be harder to get right. External packages that do similar stuff are: - corfu [4]: minimalistic, restricted to core protocols as everything in the new "completion stack" (vertico, consult, etc), uses child frames and fallbacks to the default completion on TUI. - company [5]: extends core protocols with its own ones, although there is a trend to move most backends under the capf (completion at point) one, uses overlays that are mostly ok but have some rough edges like inserting gaps into the line number area. - company-box [6] and company-posframe [7]: different frontends for company that use child frames instead of overlays. I'm still not able to assess how far the current implementation is from being functional, but I believe it's reasonable to keep any builtin solution simple, even if that means to leave the LSP in-buffer case to third parties. Next in complexity is a corfu-like implementation, which is still small and minimalistic. The decision between child frames (that don't support TUI) and overlays (that are somewhat of a hack) is a tough call though. Best regards, Carlos --- [1] https://github.com/minad/consult [2] https://github.com/minad/vertico [3] https://github.com/raxod502/selectrum [4] https://github.com/minad/corfu [5] http://company-mode.github.io/ [6] https://github.com/sebastiencs/company-box [7] https://github.com/tumashu/company-posframe