bug-gnu-emacs
[Top][All Lists]
Advanced

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]