From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: "Backend completion style" as a first-class library. Re: Eglot, project.el, and python virtual environments Date: Tue, 22 Nov 2022 23:53:22 +0000 Message-ID: References: <87zgcq68zp.fsf@ericabrahamsen.net> <878rkale3l.fsf@dfreeman.email> <4c5f4b07-3df6-d700-83f8-9a9d1b684afc@yandex.ru> <84781346-5b88-2be5-38bb-02696fcf1364@yandex.ru> <87o7t2vj19.fsf@dfreeman.email> <877czqtyfy.fsf@dfreeman.email> <87zgcml7g7.fsf@gmail.com> <2ba04533-097a-a1da-ff3f-2c9506fd488e@yandex.ru> <875yf9bbzb.fsf@gmail.com> <87wn7oa0aw.fsf@gmail.com> <7a5b76fd-fb15-8c1e-ea29-bf11f7e0d2ae@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000095ba2305ee17dc32" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3977"; mail-complaints-to="usenet@ciao.gmane.io" To: Stefan Monnier , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 23 00:52:59 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oxd4U-0000pn-Nq for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Nov 2022 00:52:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxd3s-00046r-Px; Tue, 22 Nov 2022 18:52:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oxd3r-00046h-4p for emacs-devel@gnu.org; Tue, 22 Nov 2022 18:52:19 -0500 Original-Received: from mail-oi1-x236.google.com ([2607:f8b0:4864:20::236]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxd3p-0006qj-7Y for emacs-devel@gnu.org; Tue, 22 Nov 2022 18:52:18 -0500 Original-Received: by mail-oi1-x236.google.com with SMTP id h132so17519046oif.2 for ; Tue, 22 Nov 2022 15:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=+QME6QZOyHVTheq1zBSFVDvYb/ztbKS2ttLqDMEfsMw=; b=L9A/J5Z1NY9/V+y5GQ5l7xdBdfcphTgzh+382u+kxu6wcIzJbE/S3RCdAb0N3FOnKE 6guj6lrDcDxUU2N2iHynSHKDoJ8a+UtI6BjEWJN48TRHMOiOCgjHngdKWPN8A8aoyxN/ kV/+2rPK1vSvegnrr4gtj3QakOPSBVFKSrupKeHgRaz/+8Ru3DA9SntwXN6aNKUxs/OL SNCLABUMKF2D2W0gDOZ5ECdLytjW+NIWSIFjswx56cf3NdG+izSDgDgUDXc+Psobg3ki NkRSduleAgF4sQA4xxqt5UBi6qVT3lwcX6ht5wnXcppDn9t9Yy4j5Ar4FSQ+81oulRYD 67xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+QME6QZOyHVTheq1zBSFVDvYb/ztbKS2ttLqDMEfsMw=; b=JjrWPcAB1KmKmKZlScNemyLMBzTCgP70kx78j/h54EfsgNsv1HjH6EPuMUJiEWVQkI 1ta0AuQKxUii2iNMRF5M9t9CXHkrVHNlzuTrDZfbtwrN1gpVjP4idSr9df24ApDy7FnA o08BpkyHz33ZWxrQUMn9yg5jRrngpOQ9MHPoRYtTmxFzy71vJNmyRvHsWEpX6jyt5CN7 AIZjZgLc/if6Q6qQc7laORFB56EwIgrU6hN/3WPsVBr1r+Yn8DpK5nzqpSjmMSOYSz7a 81cFXK13mS9nSD3TiLH6C56VWksfjjwD0SquNWT71HlYfC5xsrx2fNR7KFlk+VY33MB+ vvkQ== X-Gm-Message-State: ANoB5pns+Um0b6L65wvfJ22XtsbZyP36HfxcTLFDipFKSepE2iCp09px sJs5XnUvIvW0IORXYjnIGwXbjEpx+LZ42sLbM6FJm7FINkxYfg== X-Google-Smtp-Source: AA0mqf7JY/ucdQtvfY50Hn1j2NS+XbAlVUhAl5UMZek2MMbU7XTGMRfck02Ihhod+wWInlDgrNkSNoxG9BJny8GAWcI= X-Received: by 2002:a05:6808:68b:b0:359:ca6a:7fc0 with SMTP id k11-20020a056808068b00b00359ca6a7fc0mr4496992oig.215.1669161136009; Tue, 22 Nov 2022 15:52:16 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::236; envelope-from=joaotavora@gmail.com; helo=mail-oi1-x236.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300363 Archived-At: --00000000000095ba2305ee17dc32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 22, 2022 at 9:34 PM Jo=C3=A3o T=C3=A1vora wrote: > It does makes sense to start simple, but ignoring scale rarely yields > the "desired behaviour" unless that behavior is waiting forever. > Speaking of "ignoring scale", I've been meaning to propose here that the "Backend completion style" you once wrote, Stefan, be added to Emacs and to GNU Elpa as a separate :core package. This style is very useful: I've used it successfully in three separate occasions: Eglot, SLY and the voidtools everything file indexer completion table (https://github.com/joaotavora/eel/blob/master/eel.el) It's true that it stings a bit to bring in a completion style whose purpose is to negate the use of all other fancy styles and let the external backend do some unknown idiosyncratic pattern matching for us. But it ends up working so well in practice... As data sets grow larger, I think we have to come to terms that Emacs is just not very performant in managing very large collections of strings, and other special-purpose external tools implemented in other languages are just faster, not to mention the cases where you _have_ to interact with those tools for other reasons anyway and you just can't afford to transfer the whole dataset to Emacs as a big list of strings. IOW, I think Emacs's styles are pretty good for its own Elisp Lisp machine (until about a couple of hundred thousand symbols) and for managing small collections, but for anything larger we need other techniques. So the idea is to create a `lisp/progmodes/backend-completion.lisp` with the generalized contents of what is now the ";;; Backend completion" section of eglot.el. WDYT, Stefan et al? Jo=C3=A3o --00000000000095ba2305ee17dc32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 22, 2022 at 9:34 PM Jo=C3=A3o= T=C3=A1vora <joaotavora@gmail.c= om> wrote:
It does makes sense to start = simple, but ignoring scale rarely yields
the= "desired behaviour" unless that behavior is waiting forever.

Speaking of "ignoring scale&q= uot;, I've been meaning to propose here that
the "Backen= d completion style" you once wrote, Stefan, be added
to Emac= s and to GNU Elpa as a separate :core package.

Thi= s style is very useful: I've used it successfully in three separate
occasions:=C2=A0 Eglot, SLY and the voidtools everything file i= ndexer

It's true that it stings a bit to brin= g in a completion style whose purpose
is to negate the use of all= other fancy styles and let the external
backend do some unk= nown idiosyncratic pattern matching for us.
But it ends up workin= g so well in practice...

As data sets grow larger, I th= ink we have to come to terms that
Emacs is just not very performan= t in managing very large collections
of strings, and other s= pecial-purpose external tools implemented in other
languages= are just faster, not to mention the cases where you _have_
= to interact with those tools for other reasons anyway and you just can'= t
afford to transfer the whole dataset to Emacs as a big list of = strings.

IOW, I think Emacs's styles are p= retty good for its own Elisp Lisp
machine (until about a couple o= f hundred thousand symbols) and
for managing small collectio= ns, but for anything larger we need
other techniques.

So the idea is to create a `lisp/progmodes/backend-comple= tion.lisp` with
the=C2=A0 generalized contents of what is now the= ";;; Backend completion"
section of eglot.el.=C2= =A0 WDYT, Stefan et al?

Jo=C3=A3o
--00000000000095ba2305ee17dc32--