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: Fri, 12 Apr 2024 08:18:57 +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="16146"; 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 Fri Apr 12 08:20:10 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 1rvAGf-0003w8-5R for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Apr 2024 08:20:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvAFd-0006nd-Ma; Fri, 12 Apr 2024 02:19:05 -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 1rvAFb-0006mQ-Ch for emacs-devel@gnu.org; Fri, 12 Apr 2024 02:19:03 -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 1rvAFZ-0003I7-Q1 for emacs-devel@gnu.org; Fri, 12 Apr 2024 02:19:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1712902739; bh=r+plwin7FD7CRFNZ3uxFKn6NxRIcctpreaygix06Av8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=foysxfyXwnhXwLpRYjpArC6r4xWBcbKKezRmIOdB/7mcRHgZD1vh8Zm1xah2I6yoi 5NFcIW8Fc5aLSvKDz8gpV2H826cnrLn+z972ztft+nPrKiiC7UgkoOFLsXlc7GBXjm CRGlddfd/f00M4jExPtgHk6Dns/efPa6eke3wzaXK7snOKNPWwOMuPYec8wwrKb3n4 XSjm0hIU7Bohzl7NhbS6CwZ2G4S3l2pzPEsTJo3Fyl44sX5DBCtuELJr6K8T+npqJQ tvbNS1cw9qIaCrlpc/K0ilKhUbdTcoXXFP/q1E3hgtYM0ZopSJfZ/s6Z5MRbAUbauV cqgDvqAMtqqbQ== In-Reply-To: (Ergus's message of "Wed, 10 Apr 2024 17:54:15 +0200") X-Hashcash: 1:20:240412:spacibba@aol.com::BIUM3REadmHZnFgC:0hpq X-Hashcash: 1:20:240412:emacs-devel@gnu.org::mrb0ga+f/B/NDy1a:rOW 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:317686 Archived-At: Ergus writes: > On Wed, Apr 10, 2024 at 01:55:36PM +0200, Eshel Yaron wrote: >> >>I understand the value of inserting the common prefix as you describe >>it. This is what the command completion-preview-insert-common-prefix >>that I proposed up-thread does. It lets you insert (complete up to) the >>longest common prefix even if the preview shows (also) the first suffix. >> > Indeed. The problem is that in my patch the user knows what's gonna be > inserted. While otherwise we need to as some highlight to the candidate > to let the user more or less know. > > To allow this second part the change implies modifications in all the > functions chain to somehow export the prefix when shown + 1 extra > command to insert only the common prefix + a user side rebind of > tab. That change seems much more complicated (compared to my patch) Right. I think we're on the same page. There's a tradeoff between keeping the library as simple as possible on the one hand, and providing the best UX on the other. I've implemented my suggested approach, including highlighting the longest common prefix. This indeed required more changes than the patch you proposed, but nothing too complicated so far. I plan to experiment with this some more and settle on an implementation (perhaps closer to your patch, if I run into unexpected issues with this approach) in a couple of weeks. >>> 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. >> >>I'll try it out and see if it makes for a significant performance >>improvement. Otherwise, I think it's better not to override >>completion-styles in case someone has some exotic completion style with >>specific behavior that they rely on. IOW, I'd rather avoid making any >>assumptions about completion-styles. >> > The assumption is actually good considering that your package handles > candidates like (prefix)suffix inserting suffix; but it shouldn't handle > correctly pre(prefix)suffix where `pre` is not inserted (or even > previewed) Yes, in most cases the basic style is exactly what we need here. In my testing, let-binding completion-styles as you suggested indeed led to a significant performance (speed) improvement in comparison with using e.g. the 'substring' completion style. I'll push such a change soon. > If the user has some `flex` like style set by default it will just add > even more noise; when what you care is just the prefix right? Specifically the flex style also influences sorting, so it's overriding it is not totally innocent. But in practice I think it should be fine. Thanks, Eshel