From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Completion preview common Date: Tue, 09 Apr 2024 20:30:16 +0200 Message-ID: References: <75CFBF4C-EA88-4985-A967-BCC896A60EDE@aol.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12474"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 09 20:31:17 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 1ruGFY-00033y-FW for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Apr 2024 20:31:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ruGEq-0004LY-Ci; Tue, 09 Apr 2024 14:30:32 -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 1ruGEg-0004JB-2o for emacs-devel@gnu.org; Tue, 09 Apr 2024 14:30:24 -0400 Original-Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ruGEd-0001oy-TY for emacs-devel@gnu.org; Tue, 09 Apr 2024 14:30:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1712687418; bh=eVwJdisYP022kYjjDf7B7j3qzeRDYIF0fK73U9w7LNE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hT+Kpu+COuW7xUiKqbeaAb9FBUUah8v2tE79JfOaZCSor8+Eo3ej1OySdAdpMZhMm Acd8b1LiSjgHglO5+xpMZFt/+tQSrvfAFgP9FDYbDckQJQiNv2fQNEBch+2+0suj9v AD9u864qjyKy2t4rOfBYZmHWm470yIXCtT7iPbUb5kxpdfXwRgyKOB4nstojdBN52m 1YpakKCjXtgp/EUT5q9nG0ZxxBjg4aQ1MqRi3Tqm6LqVnVGGRcr8eMYkn9wyubEJeq 9b1sdKgPkGUmbQYrBNexEX0DyhVl9CvngDqxpRonD+GAJPtdHaDVEXz801x4qi+7tC wuk/pCEW4C2bQ== In-Reply-To: <75CFBF4C-EA88-4985-A967-BCC896A60EDE@aol.com> (Ergus's message of "Mon, 08 Apr 2024 01:39:01 +0200") X-Hashcash: 1:20:240409:spacibba@aol.com::FG2qkr6IoQRRPWPd:07sf X-Hashcash: 1:20:240409:emacs-devel@gnu.org::eqKmftej05xt0Ze2:4aEj Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.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, SPF_HELO_PASS=-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:317648 Archived-At: 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? > 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. Best, Eshel