RE: Displaying the state of isearch toggles [was Re: ASCII-folded search]

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

> > But such a dialog box should not be the only way to change
> > individual attribute values.
> 
> I still don't understand why not.  We do use something similar in
> Customize buffers.

Why should it be the only way?  Why shouldn't you be able to hit
a key, as you do now, to toggle case sensitivity?  Why should you
be required to open a dialog box and make a change there, just to
toggle case sensitivity?

I see nothing wrong with providing users, as we have long done
for case sensitivity, with some simple toggle keys.  Nothing
obliges us to provide a toggle/cycle key for each search attribute.
But nothing should prevent us from providing any that we think are
useful/important.

The Customize UI is OK for what it is used for.  It is hardly a
model that we should adopt as the *only* way to modify search
behavior on the fly.

> > That can be done quickly using toggle commands and/or toggle menu
> > items.
> 
> How is menu different from a dialog (to which you objected, AFAIU)?

I did not object, as I've said multiple times now.  Are you
listening?  It's not all-or-none, one-or-the-other, black-or-white.

Ask yourself why we have an `Options' menu in addition to Customize?
Or why we have the key binding `C-\' in addition to menu item
Options > Multilingual Environment > Toggle Input Method?

> > Being able to change multiple search attributes at once, as in
> > a dialog box is useful.  So is being able to quickly change any
> > of them individually.
> 
> The dialog doesn't require that you change all of them, so I don't
> see any contradiction.

You are inventing claims of contradiction.  You seem to want to see
things in black&white terms, all or nothing.

Being able to hit `M-c' during Isearch is a quick way to toggle
case sensitivity.  That doesn't mean that you shouldn't be able
to use a dialog box instead to do that, if you prefer.  Why make
addition of the latter exclude the possibility of the former?

> > When you say "non-orthogonal", presumably you are suggesting that
> > changing one attribute automatically either changes some others
> > or restricts some others.  Which such search attributes did you
> > have in mind?
> 
> Searching for regexps, words, and symbols are at least somewhat
> exclusive.  Similarly the various folding options.

See what I wrote.  Regexp, word, and symbol search (and other
possibilities perhaps to come) are exclusive, just as case-folding
on and case-folding off are exclusive.  Because they are exclusive,
they can be cycled as values of the same search attribute.

So OK, they are not orthogonal.  But yes, because of the way in
which they are not orthogonal choosing one or the other is simple.
We don't _require_ a dialog box to handle this non independence.

Your question wrt using a dialog box was this: "Are there good
alternatives, when there are so many non-orthogonal options?"

Groups such as {Regexp, word, symbol} do not present a conundrum
that requires a dialog box as its solution.

But again, I repeat that it is not about choosing between two
exclusive alternatives: dialog box vs something else.  We can
have a dialog box for heavy lifting (and also for light lifting,
for those who prefer it), and we can also have alternatives for
light lifting - e.g., toggling or cycling a search attribute.