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 19:38:17 -0700 Message-ID: <002901c8920f$1cde6200$0200a8c0@us.oracle.com> References: <87fxul194g.fsf@jurta.org><200803290100.m2T10S3j007668@localhost.localdomain><877iflk8zy.fsf@jurta.org><001901c891b9$3e6c95a0$0200a8c0@us.oracle.com> <87y7816odc.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 1206844796 12450 80.91.229.12 (30 Mar 2008 02:39:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Mar 2008 02:39:56 +0000 (UTC) Cc: 'Xavier Maillard' , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 30 04:40:26 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 1JfnT2-00046d-2Q for ged-emacs-devel@m.gmane.org; Sun, 30 Mar 2008 04:40:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JfnSQ-0002bc-4S for ged-emacs-devel@m.gmane.org; Sat, 29 Mar 2008 22:39:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JfnSL-0002bX-UB for emacs-devel@gnu.org; Sat, 29 Mar 2008 22:39:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JfnSI-0002bL-V9 for emacs-devel@gnu.org; Sat, 29 Mar 2008 22:39:36 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JfnSI-0002bI-RW for emacs-devel@gnu.org; Sat, 29 Mar 2008 22:39:34 -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 1JfnSE-000549-Mz; Sat, 29 Mar 2008 22:39:31 -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 m2U2dRlp001740; Sat, 29 Mar 2008 21:39:27 -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 m2U2dRhR016498; Sat, 29 Mar 2008 20:39:27 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3631150651206844683; Sat, 29 Mar 2008 19:38:03 -0700 Original-Received: from dradamslap1 (/141.144.80.200) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 29 Mar 2008 19:38:03 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87y7816odc.fsf@jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciSAhdi6pkpdxo3SP+K3bo94kGAGAAAfUmg 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:93862 Archived-At: > >> 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'). > > I agree that `M-insert' makes sense for inserting the completion from > the *Completions* buffer to the minibuffer. It makes sense to use the same key to go both directions (minibuffer <--> *Completions*), as I mentioned. Why not? > > 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. > > and are used by many other programs that open a pop-up > list of history/completion items. So they are natural key > for most users and especially for newbies. As I said, there is little connection with the meaning of "next" and "previous". That's the point. Slavishly copying other programs is not a sufficient argument, especially when it comes to key bindings. It can be a secondary argument, but it shouldn't be the only or the primary argument. Otherwise, Emacs would quickly resemble the lowest common denominator, or worse. Other programs are for the most part inferior to Emacs wrt key bindings. Emacs generally chooses key bindings in a reasoned way. I gave arguments why down/up should be reserved for successor/predecessor operations, if possible. You've given no argument for using them for something that is unrelated to that, beyond saying that some other programs use them to open a popup list. There is no reason to have two different keys for switching to *Completions*, which is what you are proposing, AFAICT. If there is already a key that switches to *Completions*, then why can't users also use it to switch to *Completions* when it contains the history list? Why do they need another key for that? That's like saying that although we already have `C-f' for forward-char, we should add `C-' for forward-char whenever the buffer contains lines of poetry. > I also suggest using for IDE-like autocompletion that opens > a pop-up window with completion in a program buffer. This is usually > bound to C-SPC in IDE like Eclipse, but C-SPC is already taken for > set-mark-command in Emacs. > > > 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. > > As there exists already a key that open the *Completions* buffer, > it makes sense to do the same for the history list. Makes sense to do what "the same"? Add another key, just for switching to *Completions* whenever it contains a history list? Why not really "do the same for the history list" - treat it exactly the same as every other list in *Completions*? When you say "same" it seems you mean "different". Unless I'm missing something, all you've done is fill *Completions* with a set of completions that come from the history list. That's useful, but there is nothing special about it. Completing previous inputs is no different from completing command names or file names or buffer names or anything else. Why add key bindings unnecessarily (Occam)? You need one minibuffer key binding to let users complete against the history list; that's all. > Below is a patch that implements these ideas. > > > 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. > > You earlier objected to using the same keys that have different > bindings in the minibuffer and outside it (cf. using `TAB' in the > minibuffer). Because the indentation binding of TAB is useful in the minibuffer. I made a specific argument about TAB. You cannot generalize from my opposition to changing the meaning of TAB in the minibuffer to suppose that I oppose the reuse of any keys by giving them different minibuffer bindings. And TAB is a particular case in another sense: it is apparently in demand for everything under the sun. I argued to reserve it for things that are related to its existing meanings. > Since by default M-o is a prefix key for font-lock-fontify > function, I think we should find another key. I chose `M-o' precisely because its global binding is not useful in the minibuffer. (Do you think it is?) This is not about blanket rules; you have to consider the details - TAB is not `M-o'. But I don't care whether you use `M-o' or not. It was just a suggestion. I do care that you not use TAB for that, with or without modifiers. > One candidate I propose is C-M-TAB. When will you guys leave TAB alone? Save M-TAB, S-TAB, C-M-TAB, C-S-TAB, and so on for operations that are more closely related to TAB's existing behaviors (and there are already enough of those!). Yes, you could make an argument that this behavior is slightly related, but tomorrow we will find 23 other possible uses for TAB that are all more closely related. I also suggested that completion against the current history use a recursive minibuffer, and that the choice be inserted into the parent minibuffer for editing. That is useful, especially for minibuffer input that does not involve completion. You don't want to be limited to completing the current input against a previous input. You might want to insert more than one previous input (using completion), and edit the combination. I don't agree with any of the proposed changes, but I have no illusions that my disagreement will make any difference. On n'arrete pas le "progres".