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: Usability suggestion : completion for M-: Date: Sun, 16 Mar 2008 01:11:17 -0700 Message-ID: <000501c8873d$4ff68550$0600a8c0@us.oracle.com> References: <87ejaei4iz.fsf@stupidchicken.com> <87hcf7r7vl.fsf@jurta.org><003001c886f5$366f4330$0600a8c0@us.oracle.com> <874pb7ikt7.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 1205655135 28672 80.91.229.12 (16 Mar 2008 08:12:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Mar 2008 08:12:15 +0000 (UTC) Cc: cyd@stupidchicken.com, paul.r.ml@gmail.com, emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 16 09:12:43 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 1Janz0-0005Xx-Vx for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2008 09:12:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JanyR-0007Vf-56 for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2008 04:12:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JanyL-0007Uo-AV for emacs-devel@gnu.org; Sun, 16 Mar 2008 04:12:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JanyK-0007UU-Lb for emacs-devel@gnu.org; Sun, 16 Mar 2008 04:12:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JanyK-0007UR-Fn for emacs-devel@gnu.org; Sun, 16 Mar 2008 04:12:00 -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 1JanyK-00084I-2C for emacs-devel@gnu.org; Sun, 16 Mar 2008 04:12:00 -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 m2G8BtRV012866; Sun, 16 Mar 2008 03:11:55 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m2G8BsAM024383; Sun, 16 Mar 2008 02:11:54 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3614346981205655066; Sun, 16 Mar 2008 01:11:06 -0700 Original-Received: from dradamslap1 (/141.144.88.54) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Mar 2008 01:11:05 -0700 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciG/AjxXfUEloWeR2Wu7kTEGL/OXwANdy+A In-Reply-To: <874pb7ikt7.fsf@jurta.org> 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:92720 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. I'm in favor of saving TAB for something more useful, and keeping M-TAB (ESC TAB) for symbol completion. If that binding is good enough for a Lisp buffer, where you have a greater need to complete symbols than in M-:, then it should be good enough for M-: also. No need to add an additional TAB binding to do the same thing. TAB can be useful for something else. > > 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. Oh really? Then why aren't we discussing that problem? I haven't heard people complain about TAB's (or M-TAB's) binding in Emacs-Lisp mode. Is that perhaps the real issue lurking under the surface here? > 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). So why don't you propose that for discussion, instead of this discussion? The logic for that is as valid for Lisp modes generally as it is for M-:. > Since indenting is useless in the minibuffer, TAB could only complete > symbols here. I don't agree that indenting is useless in the minibuffer. Indenting helps you see if an input sexp is correct. I would like to see M-: take on more of the character of a Lisp buffer, including indenting to help you see the structure of a sexp you input. That's no different from checking corresponding parens using show-paren-mode or blink-matching-paren. To evaluate a Lisp sexp, you can today (1) use M-:, (2) use *scratch*, or (3) use an Emacs-Lisp buffer. Each has its advantages. The advantage of M-: is that it is quick and direct. But there is no reason for M-: to sacrifice some of the other aids that Emacs-Lisp mode provides. Why not enhance it, so that it is like a pop-up Lisp buffer that evaluates a single sexp when you hit RET - but that still gives you the usual Lisp aids such as indentation via TAB, C-j, and C-M-q? > > 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. Switching to *scratch* is more convenient for multi-line Lisp precisely _because_ the things mentioned are missing from M-: today - that's a self-fulfilling prophecy. Let M-: have more Lisp mode features and it will become more convenient for evaling a single sexp (simple or complex) than is switching to *scratch*. C-j would grow the minibuffer height as needed, and RET would eval the sexp. Nothing inconvenient about M-: for multi-line input, if those features are added. Using *scratch* or another Lisp buffer would still provide other advantages (e.g. eval multiple sexps, easy to edit and re-eval), but M-: would have the advantage of being quick. Each has its place. Today, M-: is too rudimentary, crippling its use for multi-line input. M-: is for a single sexp. A single sexp can be complex. It is not unusual to paste Lisp fragments into M-: to construct a sexp to eval. But today you don't have indentation keys such as TAB and C-M-q to help you see the structure. Because of that, as soon as the structure gets complex, you move to a Lisp buffer. Why not let M-: give you what you need in the first place? > > 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). I'm not convinced that represents progress, personally. > > 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. Fine. Allow me to be the exception. We can do better. M-: can be better still. > > 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. Complete, then edit, obviously. This is completion against the history, so it is, in effect, reuse. The analogous behavior in *scratch* would be to edit the sexp and re-eval it. Surely you recognize the usefulness of editing and re-evaling a sexp. Well, that's all that this is about. > More useful would be to use dabbrev-expand (M-/) to complete symbols > from `read-expression-history' in the minibuffer. That's yet another feature possibility. That too could make sense, in the context of a M-: that is more full-bodied. > 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? Yes, I could. The key that Icicles uses for this is M-o: http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_History_Enhancements#toc4 In sum, I say enhance M-: to do more to support Lisp input, keeping TAB for indentation (or possibly your indent/complete hybrid). Let it be an on-the-fly Lisp buffer where you enter a single sexp, RET evals it, and the result is pretty-printed. And adopt the Icicles behavior for M-o: complete against the current input history (in all minibuffers). There are now several things that have been discussed in this thread, only some of which are pertinent only for M-:. With your suggestion of a TAB command that indents or symbol-completes, the original suggestion of this thread goes away. Your suggestion is not specific to M-:, but should be discussed in the context of any Lisp buffer (and M-:). And my suggestion of M-o for minibuffer history completion is another feature that is not M-: specific. The only suggestions that are M-: specific are (1) my suggestion to beef up M-:, to make it more like an on-the-fly Lisp buffer, (2) your suggestion to let M-/ complete symbols in M-: against symbols from the history, and (3) the original suggestion to bind TAB to lisp-complete-symbol. #3, IMO, is better replaced by your suggestion for a hybrid TAB command, provided we do that also in Lisp buffers. FWIW, in addition to your implementation of the hybrid command, there are several implementations of that suggestion on Emacs Wiki: http://www.emacswiki.org/cgi-bin/wiki/TabCompletion. I don't know whether such a hybrid TAB command is preferable to today's simpler indenting TAB, but whether it is or not should be discussed in the context of Lisp mode generally, not just M-:. It should be accepted for M-: only if it is also accepted for the Lisp modes.