From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Usability suggestion : completion for M-: Date: Sun, 16 Mar 2008 02:17:40 +0200 Organization: JURTA Message-ID: <874pb7ikt7.fsf@jurta.org> References: <87ejaei4iz.fsf@stupidchicken.com> <87hcf7r7vl.fsf@jurta.org> <003001c886f5$366f4330$0600a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205627031 9418 80.91.229.12 (16 Mar 2008 00:23:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Mar 2008 00:23:51 +0000 (UTC) Cc: cyd@stupidchicken.com, paul.r.ml@gmail.com, emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 16 01:24:19 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 1Jagfi-0002ku-If for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2008 01:24:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jagf6-0005qB-Tt for ged-emacs-devel@m.gmane.org; Sat, 15 Mar 2008 20:23:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jagf2-0005mO-Hy for emacs-devel@gnu.org; Sat, 15 Mar 2008 20:23:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jagex-0005a2-Fw for emacs-devel@gnu.org; Sat, 15 Mar 2008 20:23:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jagex-0005Zb-9P for emacs-devel@gnu.org; Sat, 15 Mar 2008 20:23:31 -0400 Original-Received: from relay01.kiev.sovam.com ([62.64.120.200]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jagex-0000wr-2V for emacs-devel@gnu.org; Sat, 15 Mar 2008 20:23:31 -0400 Original-Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1Jagep-0009z3-KY; Sun, 16 Mar 2008 02:23:26 +0200 In-Reply-To: <003001c886f5$366f4330$0600a8c0@us.oracle.com> (Drew Adams's message of "Sat, 15 Mar 2008 16:35:10 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) X-Scanner-Signature: b11a0dd960b728cbee92fea3b4ac1d10 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2421 [Mar 14 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 11 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.8-5.1 (or MacOS X 10.2-10.3) 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:92709 Archived-At: >> >> I think TAB should be bound to lisp-complete-symbol >> >> in M-x eval-expression, aka M-: . >> >> I think the only problem preventing this change is... >> When this is fixed, it makes sense to allow TAB to >> complete a lisp symbol... > > Uh, why? What's wrong with M-TAB or ESC TAB for Lisp symbol completion, > exactly as in a Lisp buffer? If it's good enough for there, and it's always > been good enough for here (minibuffer) in the past, why change it? Why did you get the wrong impression about changing it? No, TAB is an additional key, not a replacement for M-TAB. So M-TAB will still complete symbols in the minibuffer. > You complete a lot more symbols in a Lisp buffer than in the minibuffer with > M-:, and ESC TAB hasn't been a problem in a Lisp buffer, so far. This is a problem at least for some users. That's why I've rebound TAB in a Lisp buffer to a function that completes a symbol when point is at the end of the symbol (and indents the line otherwise). Since indenting is useless in the minibuffer, TAB could only complete symbols here. > As I mentioned, I would rather see M-: take on _more_ of the character of > Emacs-Lisp mode, not less. If you want to spend energy improving M-:, then > let it act like a pop-up emacs-lisp-mode buffer, but with RET causing eval. > And let the value be pretty-printed. When that is realized, you will see the > utility of TAB to indent, just as in Emacs-Lisp mode. I think there is no sense to implement the full functionality of Emacs-Lisp mode in the minibuffer. For complex multi-line Lisp input/output, it is much more convenient to switch to the *scratch* buffer, and do editing here than trying to edit multi-line expressions in the minibuffer. > There are several ways in which M-: might be improved, but I don't see > dedicating TAB to lisp-symbol completion to be one of them. That's a YAGNI, > IMO. The reason I supported adding a new keybinding TAB in addition to the existing keybinding M-TAB is because after installing a patch that implements shell-like command completion with TAB, it will be natural to expect the same TAB completion for more minibuffer commands to complete part of the minibuffer (not the entire minibuffer input). > Just one opinion - I'm not crazy about this change, but I don't feel > strongly about it. It doesn't matter to me for my own use, because I use > Icicles anyway, but I think it's better for Emacs users to always think of > ESC TAB as the symbol-completion key. I don't see anything gained by this > change. Many people have expressed interest in this addition, and no one reported that it can break something. > If you are looking for something for TAB to complete against in M-:, let it > be the items in `read-expression-history'. That, at least, is consistent > with other minibuffer completion: the entire minibuffer input is what is > completed, and then entered. Symbol completion is a different animal. I think it is not very useful to complete whole Lisp expressions. More useful would be to use dabbrev-expand (M-/) to complete symbols from `read-expression-history' in the minibuffer. However, for other history lists, this would be very useful. But instead of TAB we should find another key because TAB is used for completion in other minibuffers. Could you propose a different key to complete history lists in *all* minibuffers? -- Juri Linkov http://www.jurta.org/emacs/