bug#12988: [PATCH] RE: bug#12988: isearch fails to persistently indicate case sensitivity

[Drew Adams]

> > I think I've mentioned this way before, but perhaps not: In 
> > Isearch+, the mode-line lighter makes clear (continually)
> > whether searching is currently case-sensitive.  Vanilla Emacs
> > could do likewise.
> >
> >  When   case-sensitive, the lighter is `Isearch'.
> >  When case-insensitive, the lighter is `ISEARCH'.
> 
> Clever trick, but not obvious without knowing what does it mean.

I hear you, and Stefan said the same thing.  I think it doesn't take someone
long to figure it out, even with no explanation.  Once you know about it you
look there, but yes, until you do you are not in the habit of looking there.

In Icicles, I use it also to indicate case sensitivity during completion.  So
users see the convention in two places, which reinforces it.

> We need indication for other isearch parameters too,
> e.g. for `isearch-lax-whitespace'.  Do you think
> it would be equally clever to display `I s e a r c h'
> to indicate lax-whitespace mode ;-)

I doubt it.  And I'm not sure that all isearch parameters are created equal. ;-)

On the other hand, I might be persuaded that `I search' vs `Isearch' would not
be too bad, especially if the ` ' were highlighted. ;-)

So in that case:

 Isearch    - case sensitive,   strict whitespace
 ISEARCH    - case insensitive, strict whitespace
 I search   - case sensitive,   lax    whitespace
 I SEARCH   - case insensitive, lax    whitespace

Not too bad for a few chars.

I suggest picking only those isearch parameters that users need most to be aware
of, and if an easy means suggests itself to you for making them aware of those,
then use it.  And it need not be the same mechanism for each indication.

In Icicles, as another example, the minor-mode lighter, `Icy', (optionally)
shows several things at once:

* availability of completion: lighter colored red
* whether completion is lax or strict: overline+underline for strict
* case-sensitivity, as mentioned: Icy or ICY
* whether current command is a multi-command (`+' appended): Icy+
* whether candidates are multi-completions (`||' appended): Icy||
* whether set of cands shown is truncated (`...' appended): Icy...

So you see that in the case of Icicles completion a lot of info is packed into a
few chars of the modeline, in a small field intended anyway to convey info about
this minor mode.

Users are generally quick to discover things, even without reading doc.  Just by
noticing what these symbols seem to correspond to in action, it is pretty easy
to catch on after a while.  And I would suggest that the `Icy' vs `ICY' meaning
is the easiest indicator to guess.

I would certainly argue that `Isearch' vs `ISEARCH' is clearer that what Stefan
proposed as an alternative:

SM> An obvious choice is to use the same letter as the one used
SM> for the corresponding key-binding, e.g. "Isearch/r/c:".

That encoding is NOT obvious to users, IMHO.  But as with all such smoke
signals, eventually some users would figure that one out also.

That said, I would agree, if someone made the remark that if we use the
mode-line lighter to indicate some isearch state, that means that users have two
places to look for state info, and a priori, looking in two places is harder
than looking in one.

A (weak) answer is that if the info conveyed is different in the two places,
it's not so bad - e.g., case-sensitivity in the lighter, mode (regexp/simple) in
the prompt.  But in absolute terms, yes, looking in only one place for all info
is generally better.