RE: ASCII-folded search [was: Re: Upcoming loss of usability ...]

[Drew Adams <drew.adams@oracle.com>]

> Just to be clear, when I talk about the possibility of this being
> futurely implemented, I'm referring to the "independent" part, not
> the "multiple" part.
>
> I agree multiple char folding is where this should go,

Great.  Then lets assume that and discuss the UI framework
that should handle it.

> I just don't agree it is important for these multiple options
> to be  visually distinguishable (or independently toggleable)
> during isearch.

Then you should feel the same about indicating case folding.
I don't.  And you should feel the same about distinguishing
case folding from what your implementation of char folding
provides.

In that case, you should want only one indicator, which shows
that search is currently folding *something*, and let users
guess what that something might be.

I think that, *especially* when there are multiple possible
char foldings, seeing which ones are currently in effect is
important/useful.

> May be you can convince me otherwise. But I think that most
> users will never customize the equivalence class used.

Most users never toggle case sensitivity, perhaps.  So what?
I still think it is a good idea to visually indicate (e.g., in
the lighter) whether search is currently case-sensitive.

Anyway, it's not only or especially about user creation of
custom equivalence classes.  (But yes, I think that that too
is important.)

I'm hoping for some predefined sets of common equivalences.

Things like diacritical marks, numerals of different kinds,
smallcaps/caps, smallcaps/lowercase, circled/uncircled,
parenthesized/unparenthesized, arrows & brackets & pointers
& such, quotes & guillmets, fullwidth-latin/latin, non-ascii,
math-symbol groups...

And classes that might make sense for different languages,
just as case insensitivity is useful for latin languages.

Who knows?  I can guess that there will be at least *two*
besides the current one (case-insensitivity).  And given that
possibility, users will want to distinguish them easily.

I'm pretty sure of that.  Just as I'm guessing that you probably
do want to distinguish case folding from your new char folding,
with a visual indication for each.

> From those that do customize it, most will never toggle it
> during interactive searches.

Why do you think that?  Will you never toggle abstracting from
accents/diacriticals?  Do you never toggle case sensitivity?
Why would a user-defined equivalence class be any different in
this regard?

> From those that do toggle it, most of them will prefer an
> "all-or-nothing" toggle/indicator.

Why?  By that logic, you would prefer only one now, for both
case sensitivity and your new (other) char folding.  Don't you
want to see *both* whether search is case sensitive and whether
it is abstracting from diacriticals or whatever?  Why not?

> And then there are the few of the few of the few

There are a lot of users out there, and more and more of them
use Unicode chars that you and I might never use.  Starting
with languages that you and I might never search.

> who wish they could see which equiv-classes are on or off,
> or wish they could toggle them independently during isearch.
> Which is great! But we shouldn't come up with a complex
> interface to satisfy this need if it's just gonna
> confuse a lot of other people.

We should come up with a flexible UI that is as simple as
possible while supporting the assumption of more than two
char foldings (with your addition we will already have two).

We don't need to predefine toggle commands for things that
are not there now.  No one is suggesting that we do that.

But we should make it easy for users to adapt what we do
provide for use with other character-equivalence classes -
both to add toggle commands and to add/modify a visual
indicator for their needs.

We should set the pattern now, based on assuming not just
two equivalence classes (including case sensitivity), but
3 or more.