Subject: bug#10118: Fwd: GNU bugs information: logs for bug#10118

From: Stefan Monnier <[email-masked]>
Date: Tue, 05 Mar 2024 11:51:55 -0500

>>> I've been thinking a bit about this, and I'd like to propose this
>>> solution:
>>>
>>> 1. Never downcase the text yanked into the search ring, because we
>>> must remember the original text supplied by the user.  This implies
>>> that the variable `search-upper-case' will not care about the value
>>> `not-yanks' anymore.
>>>
>>> 2. When `search-upper-case' is non-nil, upper case chars will make the
>>> search case-sensitive, but only when typed right from the keyboard,
>>> i.e., not when grabbing text from another place (kill ring, buffer or
>>> whatever).  This way, the search will be case-insensitive by default
>>> (quite reasonable), and will only switch to case-sensitive under
>>> explicit request from the user (either by _typing_ an upper case char
>>> or "M-c").
>>>
>>> WDYT?
>>
>> Sounds good to me!
>
> Then UI won't be WYSIWYG.  There will be upper-case characters
> in the isearch message, but the search will ignore them.

What I proposed wasn't WYSIWYG either, because the string was displayed
as lower-case until we switch off case-folding at which point it
"magically" reveals its latent capitalization.

I can think of some ways to try and visually indicate what's going on
(e.g. using colors on the upper-case-but-case-folded chars, or an
additional flag in the prompt).  Not sure what's the better option.

        Stefan