From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Allowing completion sources to customize completion display Date: Sat, 25 Nov 2023 08:59:00 +0200 Message-ID: <83r0kee2tn.fsf@gnu.org> References: <831qcghn52.fsf@gnu.org> <08c7660f-ee16-7159-581c-c8b2526a6035@gmail.com> <83il5rfwps.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28935"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jporterbugs@gmail.com, me@eshelyaron.com, emacs-devel@gnu.org, dmitry@gutov.dev, juri@linkov.net To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 25 08:00:19 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 1r6meI-0007MI-EJ for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Nov 2023 08:00:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r6mdO-00088K-Dk; Sat, 25 Nov 2023 01:59:22 -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 1r6mdK-000880-Kw for emacs-devel@gnu.org; Sat, 25 Nov 2023 01:59:18 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r6mdI-0005Eo-KT; Sat, 25 Nov 2023 01:59:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=o2W+zw/WXy4n2yy8ZB0EoITrVy6PrsbIvTDKyKBz6O8=; b=PLRXNqzGoECp KfJOXn/2nO9QMPlGaOwS/wGuf4B4KREGz8KcU0aungTtxwImDmDn/ji3zLPPAJmf6i+TUJLRC9YD6 jPNfkEwTiVU4u2bThLsQ2CRDhHqvUGVAZHRGYjEStV27OCuN8OP3+7FufhZXRqbz3lZ2iFZ8BsSbF zYQNsKJZJ3QT7rQ2yTrden7l2eUOZQJOLGqFre5zBDQnGcFNiFuIYWYLbJCK3u3/YvTlR6RuVhOXq R0o33uy8ca/Y9mUkp+2JGRMdh2+GKpG+4bsprF21sciaYX+snWIkHIZn6/Z2mipMx6lV0dtMxjAbc cOW1CWBvzcZqsUmC9GB5uw==; In-Reply-To: (message from Spencer Baugh on Fri, 24 Nov 2023 12:28:34 -0500) 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:313199 Archived-At: > From: Spencer Baugh > Cc: Jim Porter , me@eshelyaron.com, > emacs-devel@gnu.org, Dmitry Gutov , Juri Linkov > > Date: Fri, 24 Nov 2023 12:28:34 -0500 > > In my example, I was considering two sources, one which returns symbols > and one which usually returns big multi-line strings. And I, as a user, > wanted the default Completions buffer for the first, and inline preview > for the second. > > But basing this on the source is totally wrong. Instead if I, as a > user, think inline preview is better for multi-line completion > candidates, then inline preview should be used for multi-line completion > candidates regardless of where those candidates come from. > > So I, as a user, can just configure my completion UI to detect > multi-line completion candidates and alter the UI in that case. No need > to care about the sources of completion candidates. > > And such configuration options would be straightforward to add to any > completion UI, including the default completion-in-region-function. I'm not sure I understand what you mean by "multi-line completion candidates", but if I do, IMO we should display each supported format of completion candidates in a way that fits that format. IOW, there's no reason to ask the user to configure that; we should instead provide OOTB built-in UI for displaying candidates based on their "type". > Now just separately speculating about what concrete options might be > nice to add at some point to the default completion UI, to get nice > inline preview behavior for multi-line strings... > > Perhaps two options: > > - completions-ghost-preview=t shows, in the buffer or minibuffer, a > grayed-out "ghost" preview of the currently selected completion > candidate. > > - completions-multi-line-suppress=t makes the *Completions* buffer > shrink down to just show completion-header-format and > completion-show-help whenever there's multi-line candidates among the > completions. (So you'd only have the preview from > completions-ghost-preview.) If this is about preview of candidates specifically, using the *Completions* buffer doesn't sound like a good idea to me, since popping a buffer up and down and resizing its window as the user types produces annoying visual effects, and also will slow down the preview, since these operations are relatively expensive. How about showing a multiline "ghost" instead? Or maybe you should produce a few examples of such multiline candidates, so that this discussion is less academic?