From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: add non-chord keys to repeat isearch Date: Tue, 9 Jun 2009 11:27:30 -0700 Message-ID: References: <20090609164716.GA11634@muc.de><8D5E1C403AD94F20A406381F2679E64A@us.oracle.com> <20090609174807.GC11634@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1244572072 21915 80.91.229.12 (9 Jun 2009 18:27:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Jun 2009 18:27:52 +0000 (UTC) Cc: 'Emacs-Devel devel' To: "'Alan Mackenzie'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 09 20:27:48 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ME62y-0004yi-TG for ged-emacs-devel@m.gmane.org; Tue, 09 Jun 2009 20:27:46 +0200 Original-Received: from localhost ([127.0.0.1]:44995 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ME62y-00005J-9f for ged-emacs-devel@m.gmane.org; Tue, 09 Jun 2009 14:27:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ME62s-0008Sv-AA for emacs-devel@gnu.org; Tue, 09 Jun 2009 14:27:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ME62n-0008NR-RV for emacs-devel@gnu.org; Tue, 09 Jun 2009 14:27:37 -0400 Original-Received: from [199.232.76.173] (port=50921 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ME62n-0008NO-GA for emacs-devel@gnu.org; Tue, 09 Jun 2009 14:27:33 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:52323) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ME62n-0007Yn-1l for emacs-devel@gnu.org; Tue, 09 Jun 2009 14:27:33 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59IO9mL017063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Jun 2009 18:24:10 GMT Original-Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59IRWke016380; Tue, 9 Jun 2009 18:27:32 GMT Original-Received: from dradamslap1 (/141.144.80.206) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Jun 2009 11:27:26 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnpKliIx+K/TFg6TAq+dEnsiS98+AAAFhJg In-Reply-To: <20090609174807.GC11634@muc.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4A2EA98F.017E:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:111399 Archived-At: > > `M-v' and `C-v' can be used for scrolling (when the option > > is non-nil). And `' and `' can be used for > > repeat search. There's room for all. > > What about people's poor pinkies while operating those key sequences? > ;-) Precisely the point. Which do you repeat 14 times in a row, `scroll-up' or `isearch-repeat-forward'? Using a chord to scroll is not a biggee. Especially since apparently repeating `C-v' in Isearch has no effect. If you can do `C-v' only once in a row, pinky can have no complaint. > Of course, another idea would be to allow C-s (etc.) to get a repeat > count - wouldn't be at all hard to do. C-u C-u C-s could take you a > long, long way. Are you being serious or facetious? When searching, you typically want to see the next search hit to decide whether you want to move on to the one after that. > > [BTW, scrolling during isearch doesn't seem to work beyond a single > > screen height. Is that a bug or a feature? IOW, `C-s C-v C-v': the > > second `C-v' has no effect.] > > It's a feature as far as I'm concerned, a bug to a few > others. In Emacs, point is always in the Window, so this > carries over quite naturally to the whole isearch match > staying in the window, too. The other design > alternative would have been to allow point to scroll to the > top/bottom of the window even when that would put part of the > match outside it. Whatever. IMO, it's not a great design (since we can't rightfully call it a bug). Suppose you want to check occurrences of `foo' in Info, and you're looking for something specific in the context of `foo', but it's not feasible or easy to add that something to the regexp search string, so you just use `C-s foo'. You can easily see a windowful of `foo' hits, thanks to lazy highlighting - very helpful. It's often easy to scan those visually without actually moving point among them. You can pretty easily tell if you see the context of interest somewhere among the hits, most of which are more or less noise. This is what to me would be a typical use case for scrolling during Isearch. And in this use case, there is no reason to limit scrolling to a single scroll. On the contrary; I would want to keep scrolling, letting lazy Isearch highlight indicate the hits, but not bothering to move point among them. > As a matter of interest, you can give a repeat count to scroll that > number of lines. Not a matter of much interest, to me. > > > The same applies to any keys bound to commands which have the > > > `isearch-scroll' non-nil. > > > That's fine, but a specific key binding can override that. We can > > choose to bind `' to `isearch-repeat-backward' even though > > `scroll-up' has non-nil property `isearch-scroll'. Works > > fine. There is no need to sacrifice all keys that might be bound > > globally to `scroll-up'. > > For consistency, the same operation (modulo your above comment) should > have the same key binding(s) inside and outside Isearch Mode. Why? Consistency is most important _within_ a given context. Consistency across contexts is not the be-all-and-end-all. 1. There are plenty of Isearch bindings that differ from their global counterparts. Inconsistency. 2. And `C-w' is bound in Isearch to `isearch-yank-word-or-char', while `S-' is not bound - it just exits Isearch and does its global thing. But `C-w' and `S-' have the same global binding. Inconsistency. > If any (non self-inserting) keys have a standard meaning > throughout "all" computer programs, it's surely and . But in Isearch, they do not have that standard meaning, do they? They either exit Isearch and do their standard thing (so no Isearch meaning) or, if `isearch-allow-scroll' is non-nil, they scroll only one windowful. Inconsistent with the standard behavior. > Another argument in their favour is that anybody who's > scrolling up and down within Isearch is in a mode where there's > no cost in using keys not in the home position. On the contrary, `C-v' is quite handy to repeated `C-s', as well as to typing more search chars. Not so `'. > I quite often scroll up and down in rapid succession (in isearch), Only one windowful, presumably (unless you stop and use a repeat count while you're busily thrashing up and down). > and would find switching between C-v and M-v intolerably awkward. Well, if you can't tolerate it, I guess we'll just have to forego it. ;-) (Like Unicode - http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3501#30.)