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

[Drew Adams]

> >    We want to be able to show such things either (a) on demand or
> >    (b) directly-&-always.  And we want to give users a way to
> >    toggle each attribute individually (toggle if binary, cycle if
> >    multi-valued).
> 
> Do we want to go down this path?

IMO, no.  I made that point when I said that that is the kind of
UI that other apps use, and which can allow you to unambiguously
search, for example, for `foo' only within a code segment (e.g.
inline code) and not within the accompanying text - or vice versa.

We should (and we do) provide the same power from the keyboard,
with interactive search.  (I have nothing against *also* offering
a dialog-box interface, but that should not be the main approach
or the goal.)

What I meant in the text cited is that we can indicate the exact
current search state and let users modify it interactively:

1. On demand info (e.g., pop up a help window when you hit a key -
   either one window with all the info or separate help echoes for
   different keys).

   Currently, for example, you can hit `M-c` to see the echo message
   telling you the (new) state wrt case sensitivity.  So `M-c M-c`
   is a no-op that tells you the current state.  That's a rudimentary
   way to see the case-sensitivity state, but it works, and is quick.

   With multiple state qualities (and we already have a few), it can
   be more useful to provide a state-info key that shows you more
   info on demand.

2. Persistent feedback showing the current state.  This is possible
   for at least some of the more important state qualities.  I gave
   some examples using the mode-line lighter.  We can easily show
   case, regexp, wrapping, and overwrapping now - you can see an
   example in Isearch+.

3. Toggling of individual state attributes.  One suggestion is to
   use the lighter (minor mode) menu for this.  For those who
   want to use the keyboard and not bother with a menu, we can
   provide toggle keys - put them all on the same prefix key, for
   instance.  (And of course the menu would show the keys bound
   to the same actions.)

   Another suggestion wrt individual toggles was to have a one-char
   button for each in the mode line.  This would not be my choice,
   I think, but it is another possibility.

In sum, I'd suggest that we stick close to the traditional Emacs
design: provide keyboard toggle keys, pop up info windows, etc.
And I'd suggest using the lighter to (a) indicate some state and
(b) provide a menu that gives you more info and lets you change
state.