GNU bug report logs - #73234
30.0.91; completion-preview-mode doesn't trigger for case-insensitive capf

Previous Next

Full log

View this message in rfc822 format

From: Eshel Yaron <me <at> eshelyaron.com>
To: Morgan Willcock <morgan <at> ice9.digital>
Cc: 73234 <at> debbugs.gnu.org
Subject: bug#73234: 30.0.91; completion-preview-mode doesn't trigger for case-insensitive capf
Date: Sat, 14 Sep 2024 18:23:46 +0200

Morgan Willcock <morgan <at> ice9.digital> writes:

> Eshel Yaron <me <at> eshelyaron.com> writes:
>
> Hi Eshel,
>
>> 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.

> and would indicate when a completion was available to use.

That it does, for prefix completions.

> 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 :)
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.

>> 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.

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.

> 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!)

If my suggestions above don't help with your use case, would you like to
try and propose a patch that does?


Eshel

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.