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

[Morgan Willcock <morgan@ice9.digital>]

Eshel Yaron <me@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, and would indicate when a
completion was available to use.

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.

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

-- 
Morgan Willcock