Re: Usability suggestion : completion for M-:

[Juri Linkov]

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