[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12988: [PATCH] RE: bug#12988: isearch fails to persistentlyindicate
From: |
Drew Adams |
Subject: |
bug#12988: [PATCH] RE: bug#12988: isearch fails to persistentlyindicate case sensitivity |
Date: |
Sat, 1 Dec 2012 08:38:20 -0800 |
> It can go wherever.
>
> But key thing is there is this switchboard with a bunch of
> switches one for kitchen, one for hall etc. Then you walk
> to each of them and toggle them.
>
> So there are basically two commands - one to walk to next
> switch and one to toggle it. Switch themselves report whether
> they are ON/OFF and IN-FOCUS/OUT-OF-FOCUS. Choice of switches
> themselves become immaterial.
>
> If one wants a new control then all one has to think about is what
> character or glyph it will take and add it to the switchboard.
Yes, I understood that. I think it's a very good idea.
I also think the prompt is the best place for it.
Highlighting the current switches in some way is important to the usability of
it, I think.
It's perhaps worth pointing out that this can also obviate the use of the prompt
prefix "Regexp". And if we included other state indicators, such as
wrap/overwrap, it would obviate using their more verbose prompt indicators as
well.
That does not mean that we should remove the more verbose prompt hints - only
that we could. Best would be to let users optionally remove/add the redundant
more-verbose indicators (and optionally remove/add the new feature).
FWIW, in Isearch+ I highlight the prompt hints "Regexp", "Wrapped", and
"overwrapped", and I highlight the `Isearch' mode-line lighter using the same
face as each of those prompt qualifiers.
I mention that only to say that I think such a cue helps a user recognize the
state change - in particular wrt wrapping. (Have you ever continued searching a
few times after overwrapping without meaning to, because you did not immediately
notice the "overwrapped" hint?)
With such state indicators abbreviated a la your suggestion, highlighting the
appropriate state chars would be quite helpful, IMO.
Such a highlight lets a user notice the state change without requiring that s?he
actually look at the state indicator. IOW, it's an easy-to-perceive cue.
But such highlighting too should be customizable by users, of course. At least
by customizing their faces (including to `default', to selectively turn it off).