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: Tue, 7 Jul 2009 22:53:29 -0700 Message-ID: <30EDDB5AC92A422E87D113B0A49C500E@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> 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 1247033987 24688 80.91.229.12 (8 Jul 2009 06:19:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jul 2009 06:19:47 +0000 (UTC) To: "'Juri Linkov'" , <3746@emacsbugs.donarmstrong.com>, "'Dan Nicolaescu'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 08 08:19:39 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 1MOQVG-0000ok-DF for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Jul 2009 08:19:38 +0200 Original-Received: from localhost ([127.0.0.1]:47729 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOQVF-0001dH-MN for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Jul 2009 02:19:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOQTI-0000j8-3R for bug-gnu-emacs@gnu.org; Wed, 08 Jul 2009 02:17:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOQTC-0000fc-AJ for bug-gnu-emacs@gnu.org; Wed, 08 Jul 2009 02:17:35 -0400 Original-Received: from [199.232.76.173] (port=44183 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOQTB-0000fW-Vk for bug-gnu-emacs@gnu.org; Wed, 08 Jul 2009 02:17:30 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:50121) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MOQTB-0004bu-EI for bug-gnu-emacs@gnu.org; Wed, 08 Jul 2009 02: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 n686HQcx016656; Tue, 7 Jul 2009 23:17:27 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n68604x0012974; Tue, 7 Jul 2009 23:00:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 08 Jul 2009 06:00:04 +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.124703241112101 (code B ref 3746); Wed, 08 Jul 2009 06:00:04 +0000 Original-Received: (at 3746) by emacsbugs.donarmstrong.com; 8 Jul 2009 05:53:31 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n685rPSN012082 for <3746@emacsbugs.donarmstrong.com>; Tue, 7 Jul 2009 22:53:26 -0700 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n685sc86006757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jul 2009 05:54:39 GMT Original-Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n685t498010614; Wed, 8 Jul 2009 05:55:04 GMT Original-Received: from dradamslap1 (/141.144.124.151) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Jul 2009 22:53:15 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87skh8ynnm.fsf@mail.jurta.org> Thread-Index: Acn/bO8d1H7YwRfvS4yQ7kYhvdOgjQAHLGSg 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.0A010203.4A54344C.00F8:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Wed, 08 Jul 2009 02: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:29244 Archived-At: > So when point is on the shell prompt then run Isearch on > the shell history, otherwise run Isearch on the shell buffer. Why? I don't really want to get involved in this thread. I will say though that the approach just quoted is a good example of the weakness of DWIM. A better approach, generally, is to give users explicit control, without such a dependence on fine-grained context or mode. IOW, in this case, have the two different kinds of search be initiated by a user differently, using two different commands/keys. That's the typical, simple, straightforward Emacs approach. The DWIM approach, far from always making things easier for users, complicates the mental models they need to use to make sense of their interactions with the program. They need to be aware (not necessarily consciously) of much more contextual state. The behavior is more complex, not less. That's not to say that users can't make use of it or that they need to be consciously thinking about complex contextual issues all the time. Like riding a bike or driving a car, this can soon become unconscious and natural (provided they use it a lot). 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. If the two behaviors and their triggering contexts are complementary and quite separate, then it can sometimes be worth it. But just combining behaviors on the same key binding whenever there is some degree of context difference is not justified, on its own. Just because Isearch on the history and Isearch on the buffer have no target overlap is not in itself a sufficient reason to combine them on the same key. Put another way, is it really worth it in this case to make the command behavior more complex, just to avoid having two key bindings? What reasons can you give? One can look throughout Emacs and find plenty of commands/keys that _could_ be combined, pushing the decision of which command to apply from the user into the combo-command, according to context. But very few commands merit such combination. I'm sure you could combine some commands/keys in almost any major mode - from Dired to *Buffer List* to view-mode to almost anything. There are commands that make sense only in certain contexts and so could be combined. But _why_ do that? You could make `U' in Dired do something different when no files are marked. You could perhaps combine that with `#' to do something when there are no auto-save files. But why? You get the idea: Combining different commands on the same key, to take advantage of their applicability in different contexts, makes the UI more complex; it forces users to consider the context. All that's gained is a keystroke or two. Generally, it's not worth it. Some argue that having lots of commands and lots of key bindings is also complex. Yes, but then the different features are more separate, explicit, independent. They are not linked by state/mode changes. States and modes are among the most complex UI critters for users to tame, and they are largely invisible/virtual. Each time there is a DWIM proposal like this, I'd like to see a little extra justification - justification for the combination itself: why one complex command instead of two simple commands? If this isn't supported by argument each time, we might well find ourselves soon in a maze of DWIM, with people emulating such tricky combination more and more. Programmers like to be clever, and DWIM is a cute cleverness trap. Like trying to eke out extra functionality from fewer bytes of assembler code, apparent cleverness can have a price in ease of change, ease of use, and ease of understanding.