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: C-r and C-s in minibuffer should search completion Date: Sat, 29 Mar 2008 09:23:37 -0700 Message-ID: <001901c891b9$3e6c95a0$0200a8c0@us.oracle.com> References: <87fxul194g.fsf@jurta.org><200803290100.m2T10S3j007668@localhost.localdomain> <877iflk8zy.fsf@jurta.org> 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 1206807976 8042 80.91.229.12 (29 Mar 2008 16:26:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Mar 2008 16:26:16 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "'Juri Linkov'" , "'Xavier Maillard'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 29 17:26:46 2008 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 1JfdtE-0004BE-DG for ged-emacs-devel@m.gmane.org; Sat, 29 Mar 2008 17:26:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jfdsc-0004dN-VW for ged-emacs-devel@m.gmane.org; Sat, 29 Mar 2008 12:26:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JfdsZ-0004bS-KE for emacs-devel@gnu.org; Sat, 29 Mar 2008 12:26:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JfdsY-0004aG-Ow for emacs-devel@gnu.org; Sat, 29 Mar 2008 12:26:03 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JfdsY-0004a7-Kl for emacs-devel@gnu.org; Sat, 29 Mar 2008 12:26:02 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JfdsU-0002Mk-Fi; Sat, 29 Mar 2008 12:25:58 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m2TGP2cb006273; Sat, 29 Mar 2008 11:25:02 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m2T7YmoO015685; Sat, 29 Mar 2008 10:25:01 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3631065921206807808; Sat, 29 Mar 2008 09:23:28 -0700 Original-Received: from dradamslap1 (/141.144.80.200) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 29 Mar 2008 09:23:28 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <877iflk8zy.fsf@jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciRmy66ZZPdEZd4RFmZ3uXjcXPv1QAFZ7uA X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:93812 Archived-At: > Normally is bound to previous-history-element, but in some > minibuffers it is bound to switch-to-completions. Yes, that is poor design, IMO. Not the fact that it has a different meaning in different minibuffer maps (completion vs no completion), but the fact that the `prior' key is naturally associated with the `next' key, and Emacs does not exploit that association - it breaks it. > Maybe we should avoid this inconsistency by using > another key for switch-to-completions? FWIW, Icicles uses `C-insert' for this. And hitting it again takes you back to the minibuffer (and copies the completion at point in *Completions* to the minibuffer` for editing). That key won't work for emacs -nw, but `M-insert' presumably would (in the form of `ESC insert'). (Icicles uses `insert' itself for something else. And Emacs likewise should perhaps reserve `insert' for something that needs to be quick. Switching buffers need not be so quick as to deserve a single key.) > What about binding switch-to-completions to because typing > simply starts moving to the next item in a list of defaults > and completions. And also to bind a new command switch-to-history > (that will display a list of history items in a separate window) > to because simply moves to the previous history item. Your association is a bit far-fetched, IMO - you are stretching things to fit your proposal, rather than proposing something that seems natural. There is little connection between the idea of having `down' and `up' move to the next and previous items in a series and the idea of switching windows/buffers. Other things being equal: Keys that form natural pairs, such as `down'/`up', `next'/`prior', and `home'/`end' should be reserved for things that perform some sort of succession (i.e., next or previous) behavior. Or for some sort of bracketing (e.g. grouping) behavior, such as start-something...end-something. Or for some sort of complementary behavior (e.g. `insert'/`delete'). The same is true for other such natural pairs of keys: (), [], {}, <>. Succession is a natural choice for pairs, such as `next'/`prior', whose names suggest succession. Opposite behavior can be a natural choice for pairs, such as `insert'/`delete', whose names suggest that. Finally, why use a separate window for history items? Why not simply use *Completions* and let users complete against history items? IOW, use the normal completion mechanism, with everything that it provides. That is what I suggested when I mentioned `M-o', which is the key that Icicles uses for this. You can use `M-o' from any minibuffer, not just during completion. It uses a recursive minibuffer to let you choose from the current input history (using completion) - your choice is inserted in the minibuffer, where you can edit it for the original minibuffer reading.