[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: char equivalence classes in search - why not symmetric?
From: |
Juri Linkov |
Subject: |
Re: char equivalence classes in search - why not symmetric? |
Date: |
Wed, 02 Sep 2015 01:45:45 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) |
> I'm sorry: I thought it was obvious. For case folding, there are three
> sets of characters that might be considered a match: [a], [A], and [aA].
> The default Emacs behavior is to make "a" mean [aA] and "A" mean [A].
> For the (relatively rare) case in which [a] is desired, one can turn
> case-fold-search off (e.g., with M-c). Then you gain [a] and lose [aA]
> as a choice (you can't have all three from just two characters!).
Or in a brief table:
‘C-s a’ matches [aA]
‘C-s a M-c’ matches [a]
‘C-s A’ matches [A]
‘C-s A M-c’ matches [aA]
Substituting ‘A’ into ‘ä’ (other equivalent chars omitted for brevity):
‘C-s a’ matches [aä]
‘C-s a M-'’ matches [a]
‘C-s ä’ matches [ä]
‘C-s ä M-'’ matches [aä]
I see no problem implementing the same.
BTW, could this scheme be applied to whitespace matching as well?
‘C-s SPC’ matches [SPC TAB]
‘C-s SPC M-s SPC’ matches [SPC]
‘C-s TAB’ matches [TAB]
‘C-s TAB M-s SPC’ matches [SPC TAB]
> How did that upper-case letter get there? Commands like C-w are careful
> not to add uppercase letters if there aren't already some. So the user
> must have typed it explicitly, and so they were paying attention to case
> and have no need for a case-insensitive search. The only harm is if
> they are inconsistent in their typing -- during something as brief as
> isearch.
Yanking a string with upper-case letters into Isearch does more harm
by converting them into lower-case. I believe yanking a string
should not strip diacritics either.
Re: char equivalence classes in search - why not symmetric?, Davis Herring, 2015/09/01
RE: char equivalence classes in search - why not symmetric?, Stephen J. Turnbull, 2015/09/01