From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Morgan Willcock Newsgroups: gmane.emacs.bugs Subject: bug#73234: 30.0.91; completion-preview-mode doesn't trigger for case-insensitive capf Date: Sat, 14 Sep 2024 21:46:08 +0100 Message-ID: <87o74q7ylr.fsf@ice9.digital> References: <875xqzicit.fsf@ice9.digital> <871q1m36jw.fsf@ice9.digital> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10548"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 73234@debbugs.gnu.org To: Eshel Yaron Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 14 22:47:15 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1spZfn-0002Yw-Dy for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Sep 2024 22:47:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spZfT-0000S0-Lm; Sat, 14 Sep 2024 16:46:55 -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 1spZfQ-0000Ro-B2 for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2024 16:46:53 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1spZfP-0003E2-Mc for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2024 16:46:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=FXWw0xC5YOUS01Zmm8cOimZR4tGyCUE7UPLCYV/uBOA=; b=gI1dL7USai/yfcHGHNItOb/HpcJcBVY8MD9TcxWQBZTXaM2o40GL2zlPfudPRHWB5R6I2ZMMyUe4qECd6BQ//d+Z+gVkGbXbrZ1wS6Mh5xl4MhD1qJgVZ4pQXEaJx+0IK0p15XuR2nQFck/BbfjMF9YJp73MpnDBenzu8lb6ixSpQC+MQ78eoFwklSzxgvq9mFD156YSxjpEugYJVI5JOwvDFfucb25gzVMOsrlb6o4lmkmffBo/RKwxjjOpEX/j2YyT8dITvhpvBtBYppr81/cVs9+hu9S4PG9d1n/DjjcnSE5XPm0E+c7l5LZ/0vDjP0Yyt6EjdJVH7Her0OLCJg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1spZfa-0006i0-6v for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2024 16:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Morgan Willcock Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2024 20:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73234 X-GNU-PR-Package: emacs Original-Received: via spool by 73234-submit@debbugs.gnu.org id=B73234.172634679525746 (code B ref 73234); Sat, 14 Sep 2024 20:47:02 +0000 Original-Received: (at 73234) by debbugs.gnu.org; 14 Sep 2024 20:46:35 +0000 Original-Received: from localhost ([127.0.0.1]:47844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spZf9-0006hC-39 for submit@debbugs.gnu.org; Sat, 14 Sep 2024 16:46:35 -0400 Original-Received: from relay7-d.mail.gandi.net ([217.70.183.200]:46599) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spZf2-0006gV-5Z for 73234@debbugs.gnu.org; Sat, 14 Sep 2024 16:46:34 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 4F21120003; Sat, 14 Sep 2024 20:46:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ice9.digital; s=gm1; t=1726346770; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FXWw0xC5YOUS01Zmm8cOimZR4tGyCUE7UPLCYV/uBOA=; b=Ti+hRST2eltOGjIbR2TuqCu0tlksLmcllk3PbsSJB6nkACEjN9p49rl/x3+fNS2Cjdqqe8 pD/Gk7MytCoMWOsRZj50/Uqxh/RVeBfy4tmej7C7Zt0xDe18eemlzp1M50fIiJhiLaBzOe CXTwE74RH0bbTYm0z9ovBWewmcKUh8BkZAVMVPXngWk8hVBnHRaWTOvEq16e6m5GKXuYmj 0f6FVTuIoklriKlo2dqBGlJQlaI7iPYq5geuwbcksvw3mm/og5a/W+47HDsAzJYmY57x/D Y6JC5R3NEZhEdKMNVZ5PjIac0gsUtDAKro37YvURj8mcYFeGBb860Yq+SNSLdw== In-Reply-To: (Eshel Yaron's message of "Sat, 14 Sep 2024 18:23:46 +0200") X-GND-Sasl: morgan@ice9.digital X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:291805 Archived-At: Eshel Yaron writes: >>> We could display the completion preview also when you type a prefix that >>> differs from a candidate prefix only in case (and in fact we already do, >>> when completion-ignore-case is non-nil), but the question is what to do >>> when you accept/insert this completion. Namely, changing the prefix >>> from "tes" to "Tes" when you accept the completion suggestion adds >>> complications both in terms of implementation and in terms of UX, and >>> I'm not sure that this added complexity would be justified. >> >> My expectation was that a "completion preview" is using exactly the same >> criteria as the default completion mechanism, > > This expectation is (at least presently) not warranted. Completion > Preview mode draws from the same pool of completions as > completion-at-point (it uses the same completion-at-point-functions), > but as a different frontend it makes different use of these completions. > Namely, Completion Preview mode is for prefix completion. This is the > purpose of this feature. We can discuss generalizing Completion Preview > mode to incorporate other kinds (or styles) of completion, that does > require some non-trivial considerations, though. > > In the benefit of other users, could you please share what led you to > have this expectation? Perhaps we can improve the documentation to > avoid such confusions. It was just the name. I assumed it to be a preview of the same completions which are in normal use, rather than a separate mechanism. >> and would indicate when a completion was available to use. > > That it does, for prefix completions. There are gaps in my knowledge here, but is there something about a prefix completion which means that it has to force a case-sensitive match, or is there something else about the preview interface which imposes the restriction? If the completion at point function is case-insensitive at which point in the process is that case-insensitivity being lost? >> The difference in the behaviour also means completion-preview-mode >> cannot reliably be used as the entry-point (by repeatedly calling >> completion-preview-complete) for the completion interface. > > That's not the goal of this command, so that's OK, I think :) Yes, I appreciate that the aim is just to show the preview, but it does actually function as an entry point if the input produces multiple matches. (It works less well with the default completion interface because it is fairly easy to leave the completion buffer open, but the default behaviour of Corfu aligns with it quite well because the Corfu frame automatically closes.) > Completion Preview mode is not intended to replace completion-at-point, > you can use C-M-i with the preview enabled, and get the same results > that would without it. I think my main point is that I wouldn't necessarily know to press C-M-i because of the lack of preview. >>> Do you have, or know of, a concrete use case with a completion table >>> that behaves like your test-completion-at-point-function? >> >> I think it would be rare to see one explicitly set to be >> case-insensitive, but I found the issue because I use a Cape capf >> transformer to wrap an existing capf backend: >> >> https://elpa.gnu.org/packages/doc/cape.html#Capf-transformers >> >> It is feasible to do that for any language where the syntax is >> case-insensitive. > > If case is not important, and you're fine with completing "tes" in your > example to "testSymbol", then setting completion-ignore-case to non-nil > should get you there, IIUC. I found out the hard way that completion-ignore-case isn't something that can be set as buffer-local: https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00302.html I wouldn't want to set case-insensitivity globally. > Another option, if case is insignificant, is to use a completion table > that adopts the case of the input and returns completion candidates > adjusted accordingly, instead of ignoring the case of the input and > returning candidates that match up to case differences. We do something > like that in ispell-completion-at-point, for example, and it works well > with Completion Preview mode. Do you mean this would need changes to the completion at point function rather than to completion-preview-mode? >> Here is an example of it being done: >> >> https://git.sr.ht/~mew/kixtart-mode/tree/v1.3.2/item/doc/kixtart-mode.texi#L804 >> >> (I wrote this mode and its manual, but anyone using cape-capf-case-fold >> is likely to see the same problem.) > > Thanks, but this points to example code in the documentation of a > package I'm not familiar with, so it's hard to discern its significance. > (The manual looks really nice BTW!) I don't think there are any restrictions on where cape-capf-case-fold can be used, but fundamentally the only goal is to insert the completion in the same form that it was returned from the completion at point function, but not require the user to match the case. Or to put it another way, because completion-ignore-case cannot be buffer-local, cape-capf-case-fold is the only feasible way I've seen to make a case-insensitive language easier to complete. > If my suggestions above don't help with your use case, would you like to > try and propose a patch that does? I would be willing to give it a go, but I think I am missing some fairly critical knowledge about why the same completion at point function is in use but the match result is different. Thank you for the quick and detailed reply, Morgan -- Morgan Willcock