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: Allowing completion sources to customize completion display Date: Thu, 23 Nov 2023 09:25:19 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5952"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 23 09:25:50 2023 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 1r651y-0001Lh-O2 for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Nov 2023 09:25:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r651b-0005l8-Rn; Thu, 23 Nov 2023 03:25:27 -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 1r651Z-0005kb-BZ for emacs-devel@gnu.org; Thu, 23 Nov 2023 03:25:25 -0500 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 1r651X-0003vj-68 for emacs-devel@gnu.org; Thu, 23 Nov 2023 03:25:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1700727921; bh=Gzp6lEsmcDaPx1593PMPa267UL0uJn4t9KuoiKw81xM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LFEcdgyZHpo5Qm2RTRISTTWdbnSIWcxBO2+XUvOrWmXGTYOM9YPaAn+Q/167w9bZa iEHMdoqOQ3dlp1XaSb/HsT8K83+4Z+TzCivN0S1J4EmWbNeCfC/tDCOgOVNa7DWc8i ZD3l5K8ENa6emOHRQDH2+Tk+CRCKy95/VIGLW+piDeSwvc0twbRqerHoTBYiq8pW+Q YcHQHynKIuwBujrx/jWbhirre/zHZNuppW+JSmkJ+Rwht+I8cKe3x96e4Na49cylmM yuvb395vO9Ak99FMt1SLh54sZAknApHZICqbYEbnnRreYAmeWhC4R3GjIQA0DN06M1 zyWt+9DZ0wC0A== In-Reply-To: (Spencer Baugh's message of "Wed, 22 Nov 2023 18:05:04 -0500") 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, T_SCC_BODY_TEXT_LINE=-0.01 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:313146 Archived-At: Spencer Baugh writes: > If I have multiple sources for completion active at once, I might prefer > different completion sources to be displayed differently. > > ... > > But the same completion-in-region-function and UI has to be used > regardless of whether I'm getting symbol-completion or block-completion > - I don't see a way to change completion-in-region-function based on the > source. > > Maybe we should add one? FWIW I had similar thoughts just the other day. Allowing capfs to request a certain selection UI makes sense in some situations, because sometimes the most appropriate UI may depend on the results of a specific capf. For example, say we have a legacy completion command, e.g. `ispell-complete-word`, that we want to port to a capf. But the legacy completion command comes with its bespoke completion selection UI, so it might be desirable to have the new capf mimic the legacy UI during the transition phase, without affecting other capfs, so other capfs still use the regular UI when they take effect. OTOH, IMO it's better to keep the UI as consistent and predictable as possible, so I would avoid using such a capability too liberally. > Some possibilities: > - Maybe completion table metadata could just include a > completion-in-region-function to use? > > - Maybe completion-category-overrides could change > completion-in-region-function based on the category? > > - Maybe something else entirely? How about something like the following? That seems simple enough and gives individual capfs full discretion to specify their selection UI. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 5c12d9fc914..ff5472040d3 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2823,7 +2823,10 @@ completion-at-point (lambda () ;; We're still in the same completion field. (let ((newstart (car-safe (funcall hookfun)))) - (and newstart (= newstart start)))))) + (and newstart (= newstart start))))) + (completion-in-region-function + (or (plist-get plist :completion-in-region-function) + completion-in-region-function))) (completion-in-region start end collection (plist-get plist :predicate)))) ;; Maybe completion already happened and the function returned t.