From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Completion preview common Date: Wed, 10 Apr 2024 01:05:52 +0200 Message-ID: References: <75CFBF4C-EA88-4985-A967-BCC896A60EDE@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34518"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eshel Yaron Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 10 01:07:01 2024 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 1ruKYN-0008nT-Oy for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Apr 2024 01:06:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ruKXY-0005af-Lg; Tue, 09 Apr 2024 19:06:08 -0400 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 1ruKXW-0005aM-Hj for emacs-devel@gnu.org; Tue, 09 Apr 2024 19:06:06 -0400 Original-Received: from sonic315-14.consmr.mail.bf2.yahoo.com ([74.6.134.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ruKXR-0005MI-7y for emacs-devel@gnu.org; Tue, 09 Apr 2024 19:06:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1712703959; bh=+mbuoo0WKOIiowewLPtmAVRTo4ehdufE0Pqyibdp9PU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=UKgYS8EUWae0d3DKD1z3Sd1Y2Pcl+Mt6XnrMsJwM/vfN3EzK3jSE/kRFsUsTsH98zvNqUKIUK1BSWH948i2uY43CQxNYVirTV+ejeGMLHGu9sFzaHIPAWUbSYsWSRICPbTpx8PBQEaKE44tO+KjVzCQlyj80jGrl4tQjS9/7HIP964zg3go75LWyaGpwzT6BNt5S3T2MyXcAy8f07aUluhpOx/XzLg5xqHiX7Rvd7u4xT3d8zBcEVoXf7aQUlVWQx440l8WbWWpVNoMUcagUrwlKVf/K1S4gI43S9VZSQvXsiIYP8HFb3gt+i6ab2pmVPqAmfvXJ7KbcsKeV/8Zu1Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1712703959; bh=mTMSiHpIa3EAOeWMgjhuuj7b6lVkIVaoOXp+8K2taWm=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=XcnNk2ZDLmnS0G8zqGVm5nGcoYitcr8zELs9KXUHhtJo9FnAjMXSBlv4jlw9yEBr8DXaGZVxRWlL9b4OANbhmZyUGcLwulis3Ts8mAKg5o2XzTejb+tpmgG1E3DjjZjqqqJ2WZvXTfm5M9E2lr/3JP50+WDyzy5xwV9tQ74TOPcY+JEUi1r3Sv/HIIvx6WpPlT0Tk1MI5IXf+RtTt2uIE+8k1vzBjtI31jl5oPazwN+U54pjT55mRxvUWRowuRwxqc5vfp+Vtki2VpEtxv3Dv52jhhW+lDUYOS8yPkGh7e7Q70rQVDRIEgun8DkmIDYnLQQLskXg0AqVcPATUBzWbA== X-YMail-OSG: lonU5dYVM1mksBTE83Mw0PFc3T1PyrFGCmmilKWbZvO8CdRF63vGA0yGyElcISn PHtJTuqk7Pt4qumUkeU9O1UloJ3mH7_Wi92y6yTw05HSKebeCp7HvjdtPPAPxyoW7gFKhmocITi. T5fsIhxmKVvsT6m02LducbY2UH7Jogt5RsWAS5a_PHLErhSMNrXizHvTIB0_beuwGs0OdVNy7yE9 ym595Oisaixt9RBNLt74_L8H5Jf9njrHLHFKRBzW5Kms8y.rR1KbFXq_QTaPFRKW6xw560y2BI8M 4iOtuc02EgT5K5F763Tx2p8oKLRrZOVggDy.lris30RetBHWsKfhOegoDAb80g4hybF7om6GtI97 fumXRYkyFXWB1ewVjJAEXVMFUgCPlMdp2c8brpnYQfq1XNRg7X_4j5Ffgq5VVpPsUiFwVSgE38pG PlrG0xpiVUmkuOTAf_Tkg08Xt7ewbQvIxHuA7U2oR3xg_u1sfzLOMlkbecFh2PV93Gaddu8w_ScZ NO7kbTAT_7qY8m0BfTIzO_fNWgsES51CxHn56bfshpCBcK1lp_aB1tn6KYbMKQa4ufhKmdvgKGOW 5GHbE_8hk5OoCHppW4Y9i8Ga56FbxBB01fzWwV4qAy80wSzWYpp1dbaAWDAt90faIIu1SxEPJBvu vZU0gIrjf3XtLiW9_8VbDYWqHEXrGNg.xNVUe8rw7.KnKz4DZ6hXUOQdpTJ1zlYUILBrJxcPGMFj t1IZe9WLni4spJsPHyodXirotqt3MjVbBMPnDh6NWCcT2Ux82h6nWmAjzjXKe8M_Qh9XNoH8ZpWF Qs4owX5pYhtucx_4y_cmXOqGadCp3XIII0IX6CxC2v X-Sonic-MF: X-Sonic-ID: 8abeb16a-0b05-4881-8382-65a0a7298245 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Tue, 9 Apr 2024 23:05:59 +0000 Original-Received: by hermes--production-ir2-7bc88bfc75-pvk5t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6e3878819663e34fc67abc4af0467962; Tue, 09 Apr 2024 23:05:53 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-Mailer: WebService/1.1.22205 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.134.124; envelope-from=spacibba@aol.com; helo=sonic315-14.consmr.mail.bf2.yahoo.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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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:317650 Archived-At: Hi: On Tue, Apr 09, 2024 at 08:30:16PM +0200, Eshel Yaron wrote: >Hi, > >Ergus writes: > >> Your idea sounds very sensible. But I don't want to add unneeded >> complexity to the package. To get a complete candidates list I prefer >> to rely on other tools like company or Corfu. And getting the first >> entry in my use case is not very useful. > >The patch you proposed adds an option to show only the longest common >prefix instead of a whole candidate, but the whole candidate includes >the longest common prefix, and so ISTM that it provides strictly more >information. That's why an option that makes Completion Preview mode >only show the longest common prefix strikes me as less useful than >letting you complete only up to that common prefix on demand, while >still previewing a full candidate. If that doesn't fit your bill, >perhaps you can describe the use case with some more detail? > I don't think common preview it is less useful. Indeed what I find totally useless is the insertion of first candidate instead of the common prefix. Why the first? How far we need to rotate until we find the right one? isn't it faster just continue typing instead of next-next-next or insert the first and remove the last letters and re-write the ones I need? Inserting the common prefix is actually a good trick that asserts that the tab-insertion will be correct (but maybe incomplete), because when some candidate is shown it means that it is 100% sure what is valid after point in the whole completion list; but and also matches the muscular memory for bash users. In the minibuffer (and in bash and zsh) the behavior is similar. Generally we only need preview+tab-insert the common part, because the first candidate is not good in most of the cases; actually it is as good and bad than any other candidate (that's why packages that track and sort based on history, and context exist) OTOH to browse candidates is generally better things like corfu, company or auto-complete, so, a list/tooltip to navigate with extra information (a preview of 5-10 candidates, a counter of the total number, a counter with the relative position in the list, similar candidates grouped and sorted in the tooltip). Inserting the common part is useful when typing, to safe time, specially when working with long names prefixes packages (when all the functions and variables have the same prefix). Inserting the first candidate for those is actually annoying because there will be many candidates with same prefix, but different suffix. And rotating candidate is usually slower than just type some more letter. OTOH com-pr-somesufix is faster and intuitive than com.. specially because the user does not even know if the actual candidates list is long or short and how far the candidate may be. >> Certainly we can add many other features, properties, bindings and >> colors, but every feature implies complexity I'll like to avoid >> (specially in a completion feature code). The current package is >> simple, with few bindings and a predictable behavior. Please keep >> that. >> >> I added this change because it didn't imply more than 10 extra lines >> of execution code (ignoring comments); otherwise I would prefer to >> live with it as is. > >While I agree that brevity and simplicity are some of the nice >properties of this library, IMO providing useful features is far more >important then keeping the line count to a minimum. So if there's a >strong use case that we don't currently support, I wouldn't mind adding >10, 100 or 1000 lines of code to accommodate that. > I don't mean that having a more elaborated preview is not useful; what I mean is that it doesn't worth it due to the code complexity and performance impact it generally implies. Many packages have tried this before. The package is useful as is, and in Emacs generally every new feature finds 100 requests for more and more details and configs hard to maintain and sadly mostly under-tested due to the high number of different config combinations needed. So I recommend KISS better and just add more features if they are actually requested by someone. But of course, you are free to implement the whole completion feature. Now you have the equivalents to company-preview-frontend and company-preview-if-just-one-frontend... my patch actually tried to mimic the missing company-preview-common-frontend If you allow me a couple of code comments: 1. Considering how the package works maybe it is useful to let-set: (completion-styles '(basic)) before calling completion-all-completions. Because you only care and handle the candidates where the matches are in the beginning, but with substring, partial-completion, etc the matches could be anywhere, giving a longer list (with many useless) candidates. 2. The `completion-all-completions`' output is a list with propertized string and information of the match location within the string... maybe it worth taking advantage of that information for the insertion or preview. Otherwise it is probably better to use `all-completions` instead. It will be faster and you don't need to de-propertize the substrings to add your own fonts and properties. > >Best, > >Eshel > Best, Ergus