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#3746: M-r in comint mode should use isearch Date: Thu, 9 Jul 2009 08:01:43 -0700 Message-ID: <84007A40B39D4D1F97E2E01F3B07B59F@us.oracle.com> References: <200907031326.n63DQfPA027629@godzilla.ics.uci.edu><87zlblpajc.fsf@mail.jurta.org><200907051503.n65F3fDv003169@godzilla.ics.uci.edu><87ab3hxprg.fsf@mail.jurta.org><200907070121.n671LmLt029754@godzilla.ics.uci.edu><87skh8ynnm.fsf@mail.jurta.org><30EDDB5AC92A422E87D113B0A49C500E@us.oracle.com> <87zlbf1kr0.fsf@mail.jurta.org> Reply-To: Drew Adams , 3746@emacsbugs.donarmstrong.com 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 1247154305 20196 80.91.229.12 (9 Jul 2009 15:45:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jul 2009 15:45:05 +0000 (UTC) Cc: 3746@emacsbugs.donarmstrong.com, 'Dan Nicolaescu' To: "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 09 17:44:58 2009 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.50) id 1MOvnr-0000DA-E0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Jul 2009 17:44:56 +0200 Original-Received: from localhost ([127.0.0.1]:48152 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOvnq-0000ai-MJ for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Jul 2009 11:44:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOvNO-0003Zx-Kh for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2009 11:17:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOvNK-0003XN-1x for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2009 11:17:34 -0400 Original-Received: from [199.232.76.173] (port=42415 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOvNJ-0003XI-Rk for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2009 11:17:29 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:44164) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MOvNJ-000281-Ck for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2009 11:17:29 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n69FHQGo021552; Thu, 9 Jul 2009 08:17:27 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n69FA6GJ020183; Thu, 9 Jul 2009 08:10:06 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 09 Jul 2009 15:10:06 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 3746 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 3746-submit@emacsbugs.donarmstrong.com id=B3746.124715171618569 (code B ref 3746); Thu, 09 Jul 2009 15:10:06 +0000 Original-Received: (at 3746) by emacsbugs.donarmstrong.com; 9 Jul 2009 15:01:56 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n69F1poP018562 for <3746@emacsbugs.donarmstrong.com>; Thu, 9 Jul 2009 08:01:52 -0700 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n69F3BKx019164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Jul 2009 15:03:13 GMT Original-Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n69F3VZ2018328; Thu, 9 Jul 2009 15:03:32 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Jul 2009 08:01:41 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87zlbf1kr0.fsf@mail.jurta.org> Thread-Index: AcoAJAEOj3uQLgqFSCySdrfFKr5P1AAgSLOQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010205.4A560656.00AB:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Thu, 09 Jul 2009 11:17:34 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list 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:29277 Archived-At: > > The general objection is rather Occam's razor: _Why_ add > > such complexity? What is gained? Occasionally the added > > convenience of having a single key to use makes a DWIM > > command worth it. But usually not. > > This case is an exception. I leave that to your judgment; I can't speak to that. > C-r is the most frequent key I use in bash running in xterm because > it is very convenient to search for old commands in the shell history. > I suppose the same is true for other users. > > Using a different key in Emacs for the same functionality > will cause too much trouble. Just imagine when you have a habit > typing C-r to search on the shell history, typing it in the Emacs > shell buffer will not do what you mean. This recalls that > Emacs has a different key M-r. Then switching back to xterm > and typing M-r: Ahh, that M-r is valid only in Emacs, > but in xterm it is C-r. Arrrgh! > > I think having two different keys for the same functionality > (C-r and M-r for Isearch on the history) is worse than having > the same key for different contexts (the shell prompt or the > rest of the shell buffer). The alternative is not necessarily to have two completely different keys. The typical, traditional, and simpler approach is to use the same key but still allow two behaviors and keep the behavior distinction under explicit user control: Initiate one of the two behaviors using `C-u'. Depending on context is far more complicated. And depending on context doesn't necessarily mean fewer keystrokes (even though you never need to hit `C-u'): If the cursor is not in the right place for the particular behavior you want, then you must first move it there. I'm not sure that anything significant is gained by the approach you propose, except added complexity. `C-r' for history search and `C-u C-r' for normal search seems reasonable, to me. But it's your call, of course.