[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: char equivalence classes in search - why not symmetric?
From: |
Drew Adams |
Subject: |
RE: char equivalence classes in search - why not symmetric? |
Date: |
Fri, 11 Sep 2015 09:31:33 -0700 (PDT) |
> > Yes, that is the difference in our views. Sure, "with one
> > character", but the flip side is that if you happen to have
> > é in your search string, however it got there (e.g. by
> > pasting), then with your preferred behavior you *cannot*
> > use your search string to search for "any kind of e".
>
> You are right, for what I originally proposed. It would be like the
> current situation with case folding, that you can't paste in a search
> string with capital letters and search for it in a case-independent way.
Exactly. You cannot. But you can still (thankfully)
explicitly toggle afterward using `M-c', to turn case
folding back on.
> However, in the case of case folding, we solve that by downcasing
> text when pasting it into search strings. We could de-accent strings
> too when pasting them.
Actually, Emacs does *not* do that in the general case for
pasting copied text.
emacs -Q ; `case-fold-search' is t
Copy uppercase A from some text to the kill ring.
In a buffer that has both lowercase and uppercase a's:
C-s M-e C-y ; Paste the uppercase A. It appears uppercase.
C-s ; Only uppercase A's are found.
It does what you describe only when you yank text at point
(e.g., using `C-M-y' or `C-w'). The use case I've been
insisting on is copying some text from anywhere (e.g.,
from a web browser outside Emacs). That text can contain
any chars.
But anyway, I can agree that what you describe (automatic
downcasing and removal of accents) might be a reasonable
possibility to consider.
But what if a user then wants unfolded search, after such
pasting? S?he then needs to toggle anyway.
I don't prefer such a design because it is another automatic
switching of "mode" (folding ON/OFF). It happens behind the
user's back, trying to second-guess what is best for all users
in all contexts: DWIM (do something hardcoded, which someone
thought at design time everyone will want at runtime).
You don't like using a toggle key, which I can understand.
Without toggling, which makes intention explicit/clear, you
must rely on these things:
1. The mode setting the folding behavior (ON/OFF) appropriately
- e.g., Info turns it ON locally, regardless of a user's
customization of global `case-fold-search'. (This is good.)
2. DWIM: uppercase or accented char in the search string turns
folding on. Pasting into the search string strips pasted
text of uppercase and accents. (Good for you, bad for me.)
If that doesn't fit what a user wants in a given context (e.g.,
if s?he wants to search case-sensitively in Info) then s?he
needs to toggle anyway.
I suspect that you might exaggerate the inconvenience, even
for yourself, of having to explicitly toggle when you want
to change state/mode. I use a version of Isearch that
requires such toggling, and in practice I rarely toggle!
Why do I rarely need to toggle? Perhaps because:
* I usually want case-sensitive search.
* The cases where I do not are usually covered by #1:
the mode (e.g. Info) DTRT locally.
At any rate, perhaps we could agree that users can prefer
different behaviors? And let Emacs give them the choice?
At customization time at a minimum, and in some cases via
an on-the-fly toggle key?
(If you don't need such a toggle then you certainly don't
need to worry about memorizing it. ;-))
- Re: char equivalence classes in search - why not symmetric?, (continued)
- Re: char equivalence classes in search - why not symmetric?, Richard Stallman, 2015/09/09
- RE: char equivalence classes in search - why not symmetric?, Drew Adams, 2015/09/09
- Re: char equivalence classes in search - why not symmetric?, Richard Stallman, 2015/09/09
- RE: char equivalence classes in search - why not symmetric?, Drew Adams, 2015/09/09
- Re: char equivalence classes in search - why not symmetric?, Richard Stallman, 2015/09/11
- Re: char equivalence classes in search - why not symmetric?, Stefan Monnier, 2015/09/11
- RE: char equivalence classes in search - why not symmetric?, Drew Adams, 2015/09/11
- Re: char equivalence classes in search - why not symmetric?, Juri Linkov, 2015/09/11
- RE: char equivalence classes in search - why not symmetric?, Drew Adams, 2015/09/11
- Re: char equivalence classes in search - why not symmetric?, Richard Stallman, 2015/09/12
- RE: char equivalence classes in search - why not symmetric?,
Drew Adams <=
- Re: char equivalence classes in search - why not symmetric?, Richard Stallman, 2015/09/11
- RE: char equivalence classes in search - why not symmetric?, Drew Adams, 2015/09/11
- Re: char equivalence classes in search - why not symmetric?, Richard Stallman, 2015/09/12
- RE: char equivalence classes in search - why not symmetric?, Drew Adams, 2015/09/12
- RE: char equivalence classes in search - why not symmetric?, Drew Adams, 2015/09/08
- Re: char equivalence classes in search - why not symmetric?, Juri Linkov, 2015/09/08
- Re: char equivalence classes in search - why not symmetric?, Richard Stallman, 2015/09/09
- Re: char equivalence classes in search - why not symmetric?, Eli Zaretskii, 2015/09/08
- RE: char equivalence classes in search - why not symmetric?, Drew Adams, 2015/09/08
- Re: char equivalence classes in search - why not symmetric?, Juri Linkov, 2015/09/08