From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Howard Newsgroups: gmane.emacs.devel Subject: Re: Emacs 30: Completion Preview Feedback Date: Mon, 16 Sep 2024 07:39:10 -0800 Message-ID: <878qvrd2w1.fsf@librehacker.com> References: <87zfobck1k.fsf@librehacker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5456"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs Devel Mailing List To: Eshel Yaron Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 16 17:40:18 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 1sqDpq-0001Cg-AP for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Sep 2024 17:40:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sqDpA-0007JK-QY; Mon, 16 Sep 2024 11:39:36 -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 1sqDp8-0007J5-IP for emacs-devel@gnu.org; Mon, 16 Sep 2024 11:39:34 -0400 Original-Received: from mx.kolabnow.com ([212.103.80.155]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sqDov-0007Ry-M6 for emacs-devel@gnu.org; Mon, 16 Sep 2024 11:39:33 -0400 Original-Received: from localhost (unknown [127.0.0.1]) by mx.kolabnow.com (Postfix) with ESMTP id 6732D342D8B7; Mon, 16 Sep 2024 17:39:15 +0200 (CEST) Authentication-Results: ext-mx-out011.mykolab.com (amavis); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=kolabnow.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kolabnow.com; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:date:date:references:in-reply-to:subject:subject :from:from:received:received:received; s=dkim20240523; t= 1726501154; x=1728315555; bh=uDimGjEhEEfdy0aU4USNOxQ/TwH20cxo1WW D7XojlZg=; b=CvtDTQ75DpYgMv6hvkPhcn7eJsFluASFrIhS1V3IDp8o1lftEB/ saeFY4XPzEjE6T/0husUYMNqwUImSx2HNhkRHpjthWUzUusCOLg3YJD+8xTrAoc4 ZIrhxI22j0mSdNearxPC/Ijd3Vqt0hLh6A6d28wvPZwXKBmeqbBuHLuFaLgN/ryG Az3nMWcn9kpp+R1nQ0gBoPxMmC2hbGAQxKh3RO1j9t5YEA5uVPA5Jednnhyr284C S+C2+rq/sLYOteHT4F0r4Rrqo1Oj5rl7Zpo3DoxE0NFTngC4JsppQlCcFRtxzdD0 yRQjIGLxnhFnX0XY/cbGaQalgLfxtWfkpqw== X-Virus-Scanned: amavis at mykolab.com Original-Received: from mx.kolabnow.com ([127.0.0.1]) by localhost (ext-mx-out011.mykolab.com [127.0.0.1]) (amavis, port 10024) with ESMTP id eMy9D489MfBp; Mon, 16 Sep 2024 17:39:14 +0200 (CEST) Original-Received: from int-mx011.mykolab.com (unknown [10.9.13.11]) by mx.kolabnow.com (Postfix) with ESMTPS id 05821342D8B6; Mon, 16 Sep 2024 17:39:13 +0200 (CEST) Original-Received: from ext-subm010.mykolab.com (unknown [10.9.6.10]) by int-mx011.mykolab.com (Postfix) with ESMTPS id AC74C369D502; Mon, 16 Sep 2024 17:39:13 +0200 (CEST) In-Reply-To: (Eshel Yaron's message of "Sat, 14 Sep 2024 09:35:03 +0200") Received-SPF: none client-ip=212.103.80.155; envelope-from=christopher@librehacker.com; helo=mx.kolabnow.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NONE=0.001, T_SPF_HELO_TEMPERROR=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:323667 Archived-At: > That makes sense, and we can add an option for enabling such a behavior, > but there are some subtleties to consider: imagine that there are two > completion candidates, "mapc" and "mapcan", and that the completion > table sorts "mapcan" before "mapc". In this case typing "map" triggers > the completion preview, showing the longer suffix, "can". You may not > be aware of the existence of a shorter candidate at this point. Now if > you type "c", then the prefix matches the shorter candidate "mapc", yet > it might be unexpected (and undesirable) if the preview would disappear. > > What do you think would be the most useful behavior in such cases? > Hi, as I ponder this, my preferences lean more and more toward not having *= any* non-exact matches. It seems like no matter how it was done, matches th= at are only "possible" matches are going to generate a lot of noise around = point, which is annoying to me. If I really want possible matches, I can al= ways just hit to get them to come up in Helm. So, I guess that makes it a moot issue for me, since I plan to just leave (= completion-preview-exact-match-only t) in any case. Regarding the specific question you asked =E2=80=94 I suppose it might depe= nd a bit on the source and handling of completions. More specifically, if t= he preview was based on history and heuristics, it might be handy to have t= he preview showing me the option which I have most frequently used in the p= ast. If the preview is something meaningless like alphabetic order, I would= just as soon have the preview disappear once I have an exact match on some= thing. It might be nice (or even more distracting? not sure...) if there wa= s some kind of indicator that let me instantly know if what I had typed was= in fact an exact match by itself. --=20 Christopher Howard