case-insensitive if no insensitive dups?

[Drew Adams]

Here's a crazy idea.

Whenever there are no completion candidates that differ only by case, treat
completion as case-insensitive. Even when the governing variables (e.g.
`case-fold-search', `completion-ignores-case') say it needs to be
case-sensitive. IOW, treat the variables as only a worst-case guideline.

Dunno how performant this would be in some cases, or even how feasible it would
be in some cases.

But where possible and performant, it could be handy. In cases where case
couldn't possibly make any difference, users would be able to complete without
bothering with the Shift key. Users could configure the variables, in effect, to
have case sensitivity turn on (only) whenever it makes sense.

On the other hand, a user might sometimes want to be able to test whether
particular case-sensitive candidates are available - s?he might then want to use
case-sensitive matching even when there weren't any alternative candidates with
the same spelling, modulo case.

Perhaps another user option? `completion-ignore-case-unless-dups-flag' or
whatever.

This idea could even be used beyond completion: `case-fold-generously' or
whatever. That is, let matching try to find a case-insensitive match, unless
that leads to some matches that differ only by case.

On the down side, such an approach might sometimes be confusing. Suppose the
first thing you type is `ab', and there are candidates `abcd' and `abcD'.
Assuming case sensitivity is required by the governing variables, it would be
imposed in this case, because of the insensitivity duplicates. If you then hit
`e', however, and there are only the matches `abexyz' and `abeLincoln', then
completion would automatically switch to being case-insensitive.

We could of course choose to never let your input affect things. That is, just
decide once and for all, based on the current domain of candidates, whether it
allows for case-insensitivity. In this case, the fact that your input is `abe'
(or anything else) would have no effect: completion would remain case-sensitive
because of the insensitivity duplicates `abcd' and `abcD'.

That would be quite conservative and much less handy, however. Personally, I'd
opt for allowing the potential confusion of an automatic switch from sensitive
to insensitive, because it would let me complete `*m' to `*Messages*' even if
there were also two buffers `foo' and `FoO'. (There could of course never be a
switch from insensitive to sensitive.)

The performance in the conservative case would be better, because the test would
only be made once (using all domain candidates); it wouldn't be updated for each
character you type (or when you hit `TAB', if there is no incremental
completion).

On the other hand, if the first few characters were allowed to be typed before
making any test, and if your input were used in the test, then performance would
be improved, due to the smaller search space.

To me, that would probably be the way to go: have either a minimum number of
chars (e.g. 1) or a tiny delay, after which your input would be matched against
the candidates to see whether or not matching could be insensitive. If the
minimum were 1 char, then typing `*' would limit the set of buffers to check for
duplicates to just a few. If a delay were used instead, then you might need to
type `*m' a little slowly, to automatically switch to case-insensitive matching
against `*Messages*'.

Just some food for thought.