From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: `isearch-allow-scroll' - a misnomer and a bad design Date: Thu, 22 Sep 2011 01:35:02 +0900 Message-ID: <87r539c0qx.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20110911103940.GA3246@acm.acm> <3C4B7E318EB04AE4B7DB9FD0E4C67629@us.oracle.com> <20110911173012.GA3088@acm.acm> <20110912093651.GA3249@acm.acm> <20110913142732.GB3081@acm.acm> <7E2EE144B11D413583E1E659CDE15186@us.oracle.com> <8739g0vyuy.fsf@mail.jurta.org> <4E6FF63A.4070604@gmail.com> <2F1337889F394491BA778ACA46799812@us.oracle.com> <874o07m3ay.fsf@maru.md5i.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1316622961 9418 80.91.229.12 (21 Sep 2011 16:36:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 21 Sep 2011 16:36:01 +0000 (UTC) Cc: md5i@md5i.com, dan.colascione@gmail.com, emacs-devel@gnu.org, juri@jurta.org, Stefan Monnier , dmoncayo@gmail.com, acm@muc.de, yandros@mit.edu, drew.adams@oracle.com To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 21 18:35:55 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R6Pm6-0005I6-3G for ged-emacs-devel@m.gmane.org; Wed, 21 Sep 2011 18:35:54 +0200 Original-Received: from localhost ([::1]:42374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6Pm5-0005PE-29 for ged-emacs-devel@m.gmane.org; Wed, 21 Sep 2011 12:35:53 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6Plz-0005NG-To for emacs-devel@gnu.org; Wed, 21 Sep 2011 12:35:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6Ply-0001hn-MN for emacs-devel@gnu.org; Wed, 21 Sep 2011 12:35:47 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:54821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6Ply-0001fV-3j; Wed, 21 Sep 2011 12:35:46 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9D87D9707AE; Thu, 22 Sep 2011 01:35:17 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 90FD312029B; Thu, 22 Sep 2011 01:35:02 +0900 (JST) In-Reply-To: X-Mailer: VM 8.2.0a1 under 21.5 (beta31) "ginger" 6c76f5b7e2e3 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:144165 Archived-At: Richard Stallman writes: > > FWIW: Several people have expressed this idea, with which I agree. > > C-u should do nothing by itself (and that includes not exiting > > Isearch, of course). Its only effect should be to provide a prefix > > argument to the next command, to extend its behavior. > > I tend to agree. > > This reasoning is based on thinking of Isearch as a kind of a mode, > but that's exactly what we should avoid. Why? That's like saying, "thinking of Shovel as a kind of a digging implement" is exactly what we should avoid! I am not saying we should have gratuitious modality in Emacs. I'm saying that if we have unavoidable modality, we should not kid ourselves. In the present Isearch implementation, I see no way to disabuse users of the naive intuition that one "enters" and "exits" Isearch. The minibuffer activates and deactivates, and so does an idiosyncratic form of highlighting in the buffer. The behavior of the minibuffer is itself changed, since the cursor does *not* jump to the minibuffer as it normally does. Normally self-inserting characters become motion commands. If that last is not modal, what is? In any case, my own intuition happens to be the opposite of yours. I see the *current* behavior of C-u as being very much affected by the modality of Isearch, and it bothers me. When I type C-u in any other situation, Emacs quietly waits until I type something else. It does not immediately make any perceptible change to the Emacs environment. But when using Isearch, C-u visibly disturbs state, ie, the state of the search. >From this point of view, the whole point of Alan's changes (and of Drew's suggestion as well) is to *reduce* the modality of isearch. With Alan's option *on*, scrolling commands now work as they do elsewhere in Emacs: the visible portion of the buffer at hand changes, without disturbing the state of the buffer or the search. With Drew's option *on*, C-u now works as it does elsewhere in Emacs, providing additional context to the next command, without disturbing the state of the buffer or the search. It seems to me that both of these changes make Emacs as a whole less modal, not more so. And I agree that making Emacs less modal is a good thing. As for the other bindings in isearch-mode, I agree that even the relatively few we have now do increase the modality of Isearch, and I'm of mixed feelings about almost all of them (especially C-w and C-y, which are both most useful to me personally, but also require the most effort of me to overcome muscle memory). However, I see such bindings as a very different issue from the more subtle changes of which Alan and Drew wish to avail themselves.