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: Wed, 26 Mar 2008 00:01:55 -0700 Message-ID: <003501c88f0f$473ef990$0200a8c0@us.oracle.com> References: <87prtiik0l.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 1206515007 16607 80.91.229.12 (26 Mar 2008 07:03:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Mar 2008 07:03:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" , "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 26 08:03:57 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 1JePfu-00017I-8Q for ged-emacs-devel@m.gmane.org; Wed, 26 Mar 2008 08:03:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JePfJ-00050V-43 for ged-emacs-devel@m.gmane.org; Wed, 26 Mar 2008 03:03:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JePfF-00050Q-Lm for emacs-devel@gnu.org; Wed, 26 Mar 2008 03:03:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JePfE-000501-2M for emacs-devel@gnu.org; Wed, 26 Mar 2008 03:03:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JePfE-0004zy-0X for emacs-devel@gnu.org; Wed, 26 Mar 2008 03:03:12 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JePfD-0005Jv-DO for emacs-devel@gnu.org; Wed, 26 Mar 2008 03:03:11 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JePfC-0008Ay-JH for emacs-devel@gnu.org; Wed, 26 Mar 2008 03:03:10 -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 m2Q73889030596; Wed, 26 Mar 2008 02:03:08 -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 m2PHSFuW030753; Wed, 26 Mar 2008 01:03:07 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3626497961206514902; Wed, 26 Mar 2008 00:01:42 -0700 Original-Received: from dradamslap1 (/141.144.64.173) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Mar 2008 00:01:42 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AciO6ZSA5dJcd9jSTs+jQUo2YgEdBQAIsxKQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by mx20.gnu.org: Linux 2.4-2.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:93497 Archived-At: > Actually, now that I take a closer look. Why do we have both C-s/C-r > and M-r/M-s? They seem redundant. They are not redundant now, and I hope we don't make them redundant or combine them. C-s searches the text in the minibuffer. M-s searches the input history. M-s is a regexp search; C-s is not (but C-M-s is). I'm sure you know that, so I probably misunderstand your proposal. > This is not good when the completion table is a function that takes > a long time, because then you have to wait for the completion table to > be built before you can get the actual real DEF. > > Better would be to call the function only after we consumed > minibuffer-default. Or maybe only do it when the completion-table is > not a function. I really do not see any gain by confounding history-list search with completion-table search (and now with minibuffer-text search also?). I think the proposed amalgam is a mistake. What problem is it trying to solve? [What is useful, however, is adding a key to _complete_ against the current history - in all minibuffer maps. I suggested M-o for that.]