From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#12988: [PATCH] RE: bug#12988: isearch fails to persistently indicate case sensitivity Date: Wed, 28 Nov 2012 16:06:42 -0800 Message-ID: <4EF04423864F4A009C7B1CFAE5C53AD5@us.oracle.com> References: <1353809123.37107.YahooMailClassic@web141102.mail.bf1.yahoo.com><87ip8u6m77.fsf@mail.jurta.org><0DE2FE5504D24DB884020513B403F9C4@us.oracle.com> <871ufdiaup.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1354147632 19359 80.91.229.3 (29 Nov 2012 00:07:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Nov 2012 00:07:12 +0000 (UTC) Cc: 'Kelly Dean' , 12988@debbugs.gnu.org To: "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 29 01:07:23 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tdrez-00013T-VX for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Nov 2012 01:07:22 +0100 Original-Received: from localhost ([::1]:50250 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tdreo-0004PJ-Ju for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Nov 2012 19:07:10 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tdrel-0004PE-Ky for bug-gnu-emacs@gnu.org; Wed, 28 Nov 2012 19:07:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tdrek-0002rO-CG for bug-gnu-emacs@gnu.org; Wed, 28 Nov 2012 19:07:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tdrek-0002rH-8P for bug-gnu-emacs@gnu.org; Wed, 28 Nov 2012 19:07:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Tdrgc-0004v8-Ji for bug-gnu-emacs@gnu.org; Wed, 28 Nov 2012 19:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Nov 2012 00:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12988 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12988-submit@debbugs.gnu.org id=B12988.135414772818892 (code B ref 12988); Thu, 29 Nov 2012 00:09:02 +0000 Original-Received: (at 12988) by debbugs.gnu.org; 29 Nov 2012 00:08:48 +0000 Original-Received: from localhost ([127.0.0.1]:44263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdrgN-0004uf-NH for submit@debbugs.gnu.org; Wed, 28 Nov 2012 19:08:48 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:34095) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TdrgL-0004uW-5p for 12988@debbugs.gnu.org; Wed, 28 Nov 2012 19:08:46 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAT06k2h019217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2012 00:06:47 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAT06jgU026465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 00:06:45 GMT Original-Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAT06iZg028044; Wed, 28 Nov 2012 18:06:44 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Nov 2012 16:06:44 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <871ufdiaup.fsf@mail.jurta.org> Thread-Index: Ac3NwFxTlTkNrrEkQJWrPlHNkKdJsAAACBkQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:67573 Archived-At: > > 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.