[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: char equivalence classes in search - why not symmetric?
From: |
Stephen J. Turnbull |
Subject: |
RE: char equivalence classes in search - why not symmetric? |
Date: |
Wed, 02 Sep 2015 05:10:33 +0900 |
Drew Adams writes:
> > Because having both input characters mean the same thing
> > uselessly deprives the user of expressive power.
>
> Examples/arguments/reasons, please. IOW, prove it.
With "a" and "A" as distinct entities I can express either of two
things in one character. If I equivalence them, I can only express
one thing. 2 > 1. Q.E.D.
On the contrary, "we could have an option" is not a reason for having
the option. We now have a working approach which has the advantage of
being modeless while not imposing an excessive efficiency burden. By
that I mean capitalized words are relatively uncommon, and therefore
not likely to constitute a huge number of unwanted "hits" in an
isearch for an entirely lowercase string.
I'm not *sure* the same efficiency will be true for "accent folding",
but you cannot possibly be sure it's false. The current approach is
good enough for now, and experience will accumulate over time. Wait
for it.
> You can always toggle char folding, just as you can toggle
> case folding.
Modal behavior in user commands is generally avoided in Emacs where it
isn't absolutely necessary.
Bottom line, burden of proof is on *you*.
> IMO,
You repeatedly mention your opinion in the same message where you ask
others to prove things. Yet your opinion is not evidence for anything
except your opinion.
> Let users decide whether matching is symmetric or asymmetric.
I say to them: "Use the source, Luke!"
- RE: char equivalence classes in search - why not symmetric?, (continued)