[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10118: Fwd: GNU bugs information: logs for bug#10118
From: |
Stefan Monnier |
Subject: |
bug#10118: Fwd: GNU bugs information: logs for bug#10118 |
Date: |
Tue, 05 Mar 2024 11:51:55 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>>> 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