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

[Eli Zaretskii]

> Date: Mon, 29 Jun 2015 15:26:53 -0700 (PDT)
> From: Drew Adams <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, address@hidden,
>         address@hidden, address@hidden, address@hidden,
>         address@hidden
> 
> I have nothing against *also* offering a dialog-box interface, but
> that should not be the main approach or the goal.

Why not?  Is this some kind of principle, or are there specific
arguments related to this specific feature?

> 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.

IMO, showing this in echo area doesn't scale: it could work for a few
options, but not when there are a dozen of them.

A help window is free from this limitation, but it's not different
from the dialog-type UI that you rejected, so I'm not sure what I'm
missing here.

> 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.

Again, I don't see how this will scale to a situation where we have a
dozen optional modifiers.  Will we show one letter for each, and hope
the user will remember what each one of them means?  There simply
isn't enough space on the mode line for that.

> 3. Toggling of individual state attributes.  One suggestion is to
>    use the lighter (minor mode) menu for this.

IMO, a menu is inappropriate for turning on or off several independent
option.

> In sum, I'd suggest that we stick close to the traditional Emacs
> design: provide keyboard toggle keys, pop up info windows, etc.

The creeping featurism in isearch way exceeds any other feature I know
of; perhaps it's high time we admit that it no longer fits within
"traditional Emacs design", and some new ideas are required.