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

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

[Dani Moncayo]

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> To: Juri Linkov <juri <at> jurta.org>
> Cc: 10118 <at> debbugs.gnu.org
> Subject: Re: bug#10118: C-w folds case too eagerly
> Date: Thu, 01 Dec 2011 14:45:17 -0500
>
> > > % emacs -Q
> > > TOTORO TOTO M-b
> > > C-r C-w RO
> > >
> > > this fails to find "TOTORO" because we end up looking for "totoRO"
> > > (without ignoring case) rather than "TOTORO".
>
> > Sorry, I don't know how to solve this puzzle.  The value `not-yanks'
> > of `search-upper-case' explicitly tells Isearch to downcase the word
> > pulled from the buffer.
>
> I know, but I think it's wrong.  I think that rather than downcase it,
> it should only cause the case to stay ignored.  The behavior I'd expect
> is something like:
>
> - C-r C-w leads to "I-search: toto", which hides the uppercase nature of
>   the yanked string, but doesn't actually throw it away.
> - then typing "RO" leads to "I-search: TOTORO", where TOTO's uppercase
>   nature is made explicit.

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?

-- 
Dani Moncayo

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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


        Stefan

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

[Juri Linkov]

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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