RE: Usability suggestion : completion for M-:

[Drew Adams]

> >> >> 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.