GNU bug report logs -
#12988
isearch fails to persistently indicate case sensitivity
Previous Next
Reported by: Kelly Dean <kellydeanch <at> yahoo.com>
Date: Sun, 25 Nov 2012 02:08:01 UTC
Severity: wishlist
Tags: wontfix
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #95 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> 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).
This bug report was last modified 3 years and 27 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.