From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#7700: 24.0.50; C-y binding withing Isearch mode Date: Mon, 27 Dec 2010 22:15:41 +0000 Message-ID: <20101227221541.GA5299@muc.de> References: <20101223171434.GA3971@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1293488612 17376 80.91.229.12 (27 Dec 2010 22:23:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 27 Dec 2010 22:23:32 +0000 (UTC) Cc: 7700@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 27 23:23:27 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PXLTS-0004NV-85 for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Dec 2010 23:23:26 +0100 Original-Received: from localhost ([127.0.0.1]:56721 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PXLTR-000313-6j for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Dec 2010 17:23:25 -0500 Original-Received: from [140.186.70.92] (port=36431 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PXLTM-00030q-HI for bug-gnu-emacs@gnu.org; Mon, 27 Dec 2010 17:23:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PXLTK-0008Kb-S9 for bug-gnu-emacs@gnu.org; Mon, 27 Dec 2010 17:23:20 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PXLTK-0008KW-QL for bug-gnu-emacs@gnu.org; Mon, 27 Dec 2010 17:23:18 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PXL1y-0003rQ-DE; Mon, 27 Dec 2010 16:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Dec 2010 21:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7700 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7700-submit@debbugs.gnu.org id=B7700.129348685214767 (code B ref 7700); Mon, 27 Dec 2010 21:55:02 +0000 Original-Received: (at 7700) by debbugs.gnu.org; 27 Dec 2010 21:54:12 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PXL19-0003q8-BD for submit@debbugs.gnu.org; Mon, 27 Dec 2010 16:54:11 -0500 Original-Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PXL16-0003pv-Nk for 7700@debbugs.gnu.org; Mon, 27 Dec 2010 16:54:09 -0500 Original-Received: (qmail 11904 invoked by uid 3782); 27 Dec 2010 22:00:56 -0000 Original-Received: from acm.muc.de (pD9E239AF.dip.t-dialin.net [217.226.57.175]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 27 Dec 2010 23:00:54 +0100 Original-Received: (qmail 5781 invoked by uid 1000); 27 Dec 2010 22:15:41 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 27 Dec 2010 16:55:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:42880 Archived-At: Hi Stefan, On Sat, Dec 25, 2010 at 02:52:49PM -0500, Stefan Monnier wrote: > >>>> I suggest instead that any standard forward movement command while in > >>>> isearch forward mode should select the text to grab WITHOUT any > >>>> prefix key. > >> That might be a good choice, but: > >> - we lack experimental evidence for that. > >> - it would probably be too big a change to have that as a default behavior. > > IMHO, that proposal would make text grabbing in Isearch (a) More > > powerful (you could use every movement command to grab text), and (b) > > easier/simpler (you already know the movement commands). > Compared to the use of a prefix, there is an important difference: the > prefix tells isearch that the next command is a movement command, so it > can be used with *any* command (and can lead to surprises if the command > is not a movement command), whereas in the absence of a prefix, isearch > would need to know which commands are "movement commands", and this > knowledge would always tend to be partial, so it will fail with > some commands. > > The only drawback I can see is to give up the possibility of exit > > Isearch mode with a movement command, but IMO, this loss is > > insignificant compared with the benefits. > Depends significantly on your usage pattern. I know such a change to > the default behavior would cause screams and never ending arguments. > So we'd fist have to see this change in action for a while to > demonstrate that the benefit is worth the cost of transitioning. I would like to express my strong opposition to all these wild and visionary schemes which would radically alter isearch. We don't need them; isearch works very well as it currently is. All this talk about encumbering standard commands with prefix keys "telling isearch that the next command is a movement command", vi-style, has drowned out the proper topic of this thread (a minimal change to `isearch-key-map'), and has become tedious and depressing horribly quickly (IMAO). Experience shows that threads like this one go nowhere very slowly, sometimes with 50 or 100 contributions. They waste time, and make participation in the list very tedious. Can we not develop the discipline not to allow threads like this one to explode out of control? I think it would be best if proposed developments like this are implemented rather than endlessly discussed. We shouldn't really be discussing big UI changes unless somebody has implemented them and enthusiastically recommends them. In the mean time, I would still not be against moving isearch-yank-line to some key other than C-y. How about this idea? > Stefan -- Alan Mackenzie (Nuremberg, Germany).