Usability suggestion : completion for M-:

Usability suggestion : completion for M-:

[paul r]

Hello,

Emacs seems to have a consistent behaviour regarding TAB and
completion, i.e : Almost everywhere, TAB triggers completion when :
- indentation does not make sens
- tabulation char is unlikely to make sens

For exemple, TAB triggers completion in find-file. I think TAB should
be bound to lisp-complete-symbol in M-x eval-expression, aka M-: .

Hope everybody agree and this will be widely considered as a simple
yet positive change.

Paul

Re: Usability suggestion : completion for M-:

[Lennart Borgman (gmail)]

paul r wrote:
> Hello,
> 
> Emacs seems to have a consistent behaviour regarding TAB and
> completion, i.e : Almost everywhere, TAB triggers completion when :
> - indentation does not make sens
> - tabulation char is unlikely to make sens
> 
> For exemple, TAB triggers completion in find-file. I think TAB should
> be bound to lisp-complete-symbol in M-x eval-expression, aka M-: .
> 
> Hope everybody agree and this will be widely considered as a simple
> yet positive change.


At least I agree, I even have this in my .emacs

   (define-key read-expression-map (kbd "TAB") #'lisp-complete-symbol)

RE: Usability suggestion : completion for M-:

[Drew Adams]

> Emacs seems to have a consistent behaviour regarding TAB and
> completion, i.e : Almost everywhere, TAB triggers completion when :
> - indentation does not make sens
> - tabulation char is unlikely to make sens
> 
> For exemple, TAB triggers completion in find-file. I think TAB should
> be bound to lisp-complete-symbol in M-x eval-expression, aka M-: .
> 
> Hope everybody agree and this will be widely considered as a simple
> yet positive change.

FWIW, I prefer that it reflect the Emacs-Lisp bindings. 

If M-TAB (or ESC TAB) is good enough for emacs-lisp-mode, it's good enough
for `M-:' too.

Just one opinion.

Re: Usability suggestion : completion for M-:

[paul r]

> FWIW, I prefer that it reflect the Emacs-Lisp bindings.
>
>  If M-TAB (or ESC TAB) is good enough for emacs-lisp-mode, it's good enough
>  for `M-:' too.
>
fair enought, I think M-Tab can be kept as an alternative keystroke.
But the point that nowaday, most of windows manager intercept M-Tab
for switching windows should maybe push us to provide alternative to
M-TAB where possible and intuitive.

Re: Usability suggestion : completion for M-:

[Lennart Borgman (gmail)]

paul r wrote:
>> FWIW, I prefer that it reflect the Emacs-Lisp bindings.
>>
>>  If M-TAB (or ESC TAB) is good enough for emacs-lisp-mode, it's good enough
>>  for `M-:' too.
>>
> fair enought, I think M-Tab can be kept as an alternative keystroke.
> But the point that nowaday, most of windows manager intercept M-Tab
> for switching windows should maybe push us to provide alternative to
> M-TAB where possible and intuitive.

To be more precise they intercept Alt-Tab and Emacs META is often bound 
to Alt.

Re: Usability suggestion : completion for M-:

[Chong Yidong]

"paul r" <paul.r.ml@gmail.com> writes:

> Emacs seems to have a consistent behaviour regarding TAB and
> completion, i.e : Almost everywhere, TAB triggers completion when :
> - indentation does not make sens
> - tabulation char is unlikely to make sens
>
> For exemple, TAB triggers completion in find-file. I think TAB should
> be bound to lisp-complete-symbol in M-x eval-expression, aka M-: .
>
> Hope everybody agree and this will be widely considered as a simple
> yet positive change.

ISTR this being discussed on this list at some point in the past, but
don't remember the details.

At first glance, it seems like a definite win to rebind TAB to symbol
completion.  Any anyone point out a usage pattern where the old
binding of TAB is preferable?

RE: Usability suggestion : completion for M-:

[Drew Adams]

> > Emacs seems to have a consistent behaviour regarding TAB and
> > completion, i.e : Almost everywhere, TAB triggers completion when :
> > - indentation does not make sens
> > - tabulation char is unlikely to make sens
> >
> > For exemple, TAB triggers completion in find-file. I think 
> > TAB should be bound to lisp-complete-symbol in M-x 
> > eval-expression, aka M-: .
> >
> > Hope everybody agree and this will be widely considered as a simple
> > yet positive change.
> 
> ISTR this being discussed on this list at some point in the past, but
> don't remember the details.
> 
> At first glance, it seems like a definite win to rebind TAB to symbol
> completion.  Any anyone point out a usage pattern where the old
> binding of TAB is preferable?

FWIW, I would prefer to see M-: take on more of the character of a pop-up
emacs-lisp-mode buffer: TAB, C-M-q, C-j, ..., but with RET still causing
eval (alternative design: C-c C-c to eval). And when you hit C-j the
minibuffer would grow in height. In that scenario, M-TAB, not TAB, would
continue to be the Lisp symbol completer.

And I'd like to see M-: pretty-print the result (as in pp-eval-expression),
but that suggestion has already been rejected.

Re: Usability suggestion : completion for M-:

[paul r]

> ISTR this being discussed on this list at some point in the past, but
>  don't remember the details.

I can't remember this, so I apologize if my suggestion has been
discussed many times.
Here is my own choice of behaviour for TAB key :
 - unless point is at the end of line, indent-according-to-mode
 - if point is at EOL :
   - unless line is indented according to mode, indent according to mode
   - if line is indented according to mode, complete

Classic use case would be : I'm typing a line, I start a new line,
type some code, hit TAB to have my line properly indented, carry on
typing, hit tab again to complete my symbol.

I've been using it for 3 years now, and I still like this behaviour a lot.

Re: Usability suggestion : completion for M-:

[Juri Linkov]

>> Emacs seems to have a consistent behaviour regarding TAB and
>> completion, i.e : Almost everywhere, TAB triggers completion when :
>> - indentation does not make sens
>> - tabulation char is unlikely to make sens
>>
>> For exemple, TAB triggers completion in find-file. I think TAB should
>> be bound to lisp-complete-symbol in M-x eval-expression, aka M-: .
>>
>> Hope everybody agree and this will be widely considered as a simple
>> yet positive change.
>
> ISTR this being discussed on this list at some point in the past, but
> don't remember the details.
>
> At first glance, it seems like a definite win to rebind TAB to symbol
> completion.  Any anyone point out a usage pattern where the old
> binding of TAB is preferable?

I think the only problem preventing this change is one completion message
that overwrites the minibuffer when TAB doesn't find a completion.
I propose the patch below similar to the patch I proposed for the
shell command minibuffer completion.

When this is fixed, it makes sense to allow TAB to complete a lisp
symbol part of the eval-expression minibuffer in the same way as TAB
will allow completion of command name and file name parts of the
shell-command minibuffer.

Index: lisp/emacs-lisp/lisp.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/emacs-lisp/lisp.el,v
retrieving revision 1.84
diff -c -r1.84 lisp.el
*** lisp/emacs-lisp/lisp.el	5 Mar 2008 20:54:56 -0000	1.84
--- lisp/emacs-lisp/lisp.el	15 Mar 2008 21:35:47 -0000
***************
*** 667,673 ****
  	     (completion (try-completion pattern obarray predicate)))
  	(cond ((eq completion t))
  	      ((null completion)
! 	       (message "Can't find completion for \"%s\"" pattern)
  	       (ding))
  	      ((not (string= pattern completion))
  	       (delete-region beg end)
--- 667,675 ----
  	     (completion (try-completion pattern obarray predicate)))
  	(cond ((eq completion t))
  	      ((null completion)
! 	       (if (window-minibuffer-p (selected-window))
! 		   (minibuffer-message (format " [No completions of \"%s\"]" pattern))
! 		 (message "Can't find completion for \"%s\"" pattern))
  	       (ding))
  	      ((not (string= pattern completion))
  	       (delete-region beg end)

Index: lisp/simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.906
diff -c -r1.906 simple.el
*** lisp/simple.el	14 Mar 2008 17:42:16 -0000	1.906
--- lisp/simple.el	15 Mar 2008 21:35:59 -0000
***************
*** 1012,1017 ****
--- 1012,1018 ----
  ;; Initialize read-expression-map.  It is defined at C level.
  (let ((m (make-sparse-keymap)))
    (define-key m "\M-\t" 'lisp-complete-symbol)
+   (define-key m "\t" 'lisp-complete-symbol)
    (set-keymap-parent m minibuffer-local-map)
    (setq read-expression-map m))
  
-- 
Juri Linkov
http://www.jurta.org/emacs/

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? 

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.

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.

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.

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.

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.

Re: Usability suggestion : completion for M-:

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>>> 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? 

Two things:

- M-TAB does not work when the window manager eats it breakfast
- TAB is rather commonly used for completion (for example when reading 
file names in Emacs, in shells, hacks to use TAB for completions in 
Emacs are seen as positive by some Emacs users)

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/

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.

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? 
> 
> Two things:
> 
> - M-TAB does not work when the window manager eats it breakfast

I said, "M-TAB or ESC TAB". 

> - TAB is rather commonly used for completion (for example 
> when reading file names in Emacs, in shells, hacks to use
> TAB for completions in Emacs are seen as positive by some Emacs users)

Did you read what I wrote? TAB can be used for some other, better completion
in M-: than symbol completion - completion that would be consistent with
other minibuffer completion (complete the whole input, then RET to enter).

An alternative use of TAB for M-: (besides completion) would be to let it do
what it does in Emacs-Lisp mode: indent. I prefer that binding, and I prefer
also adding other Lisp mode bindings to M-:. C-M-q would indent, C-j would
indent (and grow the minibuffer height), and so on.

Re: Usability suggestion : completion for M-:

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> To evaluate a Lisp sexp, you can today (1) use M-:, (2) use *scratch*, or
> (3) use an Emacs-Lisp buffer.

There is also ielm, which is very convenient.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Usability suggestion : completion for M-:

[paul r]

Drew Adams said :

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

In this spirit, a dedicated thread for your multiline-enhanced M-: could help.

>  To evaluate a Lisp sexp, you can today (1) use M-:, (2) use *scratch*, or
>  (3) use an Emacs-Lisp buffer.

(4) enter it straight in current buffer and hit C-x C-e after closing
paren. (1) and (4) are the only solution I see to evaluate in the
context of the current buffer.

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

I'd like to share your opinion, but my brain just needs completion as
much as possible.

> Fine. Allow me to be the exception. We can do better. M-: can be better
>  still.

Agree, but in the meantime, binding TAB to tabulation character
instead of symbol completion in the current one-line minibuffer is
inconsistent with the behaviour of others minibuffer prompts. When we
have a fully bodied multiline indentable M-:, things can change. It's
not like if binding TAB on something or another is a big deal. Finaly,
multiline M-: could co-exist as an other mode with its own bindings,
I'd still like to have TAB bound to complete symbol in the current
one-line M-: as long as it will live. And this thead is about current
form of M-:

Re: Usability suggestion : completion for M-:

[paul r]

Drew Adams wrote :
> I said, "M-TAB or ESC TAB".

M-TAB is not an option in *most* of recent systems. And, honestly, who
wants to complete with Esc-Tab ? Drew, could you please try to
temporarily use *only* ESC-TAB, and tell us how usable you find it.

Re: Usability suggestion : completion for M-:

[Ralf Angeli]

* paul r. (2008-03-16) writes:

> Drew Adams wrote :
>> I said, "M-TAB or ESC TAB".
>
> M-TAB is not an option in *most* of recent systems.

You can use `M-C-i' as an alternative.

-- 
Ralf

Re: Usability suggestion : completion for M-:

[Lennart Borgman (gmail)]

Andreas Schwab wrote:
> "Drew Adams" <drew.adams@oracle.com> writes:
> 
>> To evaluate a Lisp sexp, you can today (1) use M-:, (2) use *scratch*, or
>> (3) use an Emacs-Lisp buffer.
> 
> There is also ielm, which is very convenient.


Ah, thanks. I never noticed ielm.

It uses TAB for completion ...

Re: Usability suggestion : completion for M-:

[Lennart Borgman (gmail)]

Drew Adams wrote:
> I said, "M-TAB or ESC TAB". 

I noticed, but I find ESC TAB quite a bit inconvenient for such a common 
operation as completion.

>> - TAB is rather commonly used for completion (for example 
>> when reading file names in Emacs, in shells, hacks to use
>> TAB for completions in Emacs are seen as positive by some Emacs users)
> 
> Did you read what I wrote? TAB can be used for some other, better completion
> in M-: than symbol completion - completion that would be consistent with
> other minibuffer completion (complete the whole input, then RET to enter).

Sorry, I missed that part.

Do you mean adding closing parenthesis? Then it could be combined I believe.

Re: Usability suggestion : completion for M-:

[Lennart Borgman (gmail)]

Drew Adams wrote:
> 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?

I have complained a lot of times about the use of M-TAB in Emacs as long 
as META is actually Alt (which it is by default on for example w32). I 
am sure you have noticed that, or?

Re: Usability suggestion : completion for M-:

[Andreas Schwab]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Ah, thanks. I never noticed ielm.
>
> It uses TAB for completion ...

It works like a shell.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Usability suggestion : completion for M-:

[Drew Adams]

> > Fine. Allow me to be the exception. We can do better.
> > M-: can be better still.
> 
> Agree, but in the meantime, binding TAB to tabulation character
> instead of symbol completion in the current one-line minibuffer is
> inconsistent with the behaviour of others minibuffer prompts.

On the contrary. TAB in the minibuffer either (1) self-inserts (when not
using completing-read or read-file-name) or (2) completes the entire
minibuffer input in such a way that you can hit RET to enter the completed
input. 

That's the case now for all minibuffer input. What you propose is
inconsistent with that. You are proposing something new: (3) complete only
part of the input, so that RET after TAB won't necessarily make sense.

That's OK, _if_ there are mitigating reasons - blind, systematic consistency
is not a goal in itself. But please recognize that the current TAB bindings
are consistent, and your proposal breaks that consistency. 

Why do that, especially if, as you admit, it is just a temporary hack: "in
the meantime"? In-the-meantime changes can become fixed by neglect, for no
special reason, rather than being just temporary exceptions to the rule. The
result of lots of such changes would be ad-hoc inconsistency throughout the
UI.

If the right thing to do is (as you apparently agree) to improve M-: so that
it is more like Lisp modes, with TAB assuming its indenting role (or perhaps
a hybrid indenting role), then we should not DTWT "in the meantime".

RE: Usability suggestion : completion for M-:

[Drew Adams]

> > I said, "M-TAB or ESC TAB". 
> 
> I noticed, but I find ESC TAB quite a bit inconvenient for 
> such a common operation as completion.

So use C-M-i. Or bind some other key. TAB, if you like. I don't see a
general argument for changing the default behavior.

> >> - TAB is rather commonly used for completion (for example 
> >> when reading file names in Emacs, in shells, hacks to use
> >> TAB for completions in Emacs are seen as positive by some 
> >> Emacs users)
> > 
> > Did you read what I wrote? TAB can be used for some other, 
> > better completion in M-: than symbol completion - completion
> > that would be consistent with other minibuffer completion
> > (complete the whole input, then RET to enter).
> 
> Sorry, I missed that part. Do you mean adding closing
> parenthesis? Then it could be combined I believe.

The possibility along these lines that I mentioned is to use TAB the same
way you use it in a Lisp buffer. And to, in general, make it easier to use
M-: for an arbitrary Lisp sexp. That means having TAB, C-M-q, etc. have
their normal Lisp mode bindings. What's good for Lisp mode is good for M-:,
and that includes TAB.

RE: Usability suggestion : completion for M-:

[Drew Adams]

> > 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?
> 
> I have complained a lot of times about the use of M-TAB in 
> Emacs as long as META is actually Alt (which it is by default
> on for example w32). I am sure you have noticed that, or?

No, I didn't notice your complaints about M-TAB; sorry. But I see them now,
as well as your complaint about ESC TAB.

Do you also have a problem using C-M-i?

At any rate, if you want to discuss this for Lisp mode in general, why not
start a separate thread - it has nothing to do with M-: in particular.

RE: Usability suggestion : completion for M-:

[Drew Adams]

> > I said, "M-TAB or ESC TAB".
> 
> M-TAB is not an option in *most* of recent systems. And, honestly, who
> wants to complete with Esc-Tab ? Drew, could you please try to
> temporarily use *only* ESC-TAB, and tell us how usable you find it.

FYI, I have been using *only* ESC TAB "temporarily" for over 2 decades. I
guess I don't see a problem with it (for me), so far. ;-)

And as Ralf pointed out, you can use `C-M-i' as a chord alternative. 

What is so hard about these bindings? On my standard US PC keyboard, there
is only one key between ESC and TAB. It's true that C-M-i is a 3-key chord
that might require you to stretch a little or use two hands, but is this
really a big deal? 

Is it a big deal for _most_ people, so we should change the default?
(Individuals can always rebind keys.) I doubt it, or we would have changed
the binding long ago.

And I see from Emacs Wiki that you yourself have recently gone to the
trouble of, in effect, making TAB TAB complete a symbol (whenever the code
is already indented) - "using the second tab key press for what is bound to
Alt-Tab". If ESC TAB is so bothersome to you, is TAB TAB really that much
better? (Yes, I realize that your TAB TAB is configurable to do alternative
things, but that is what it seems to do out of the box.)

Why add a third binding for lisp-complete-symbol? Why take away the
possibility of using TAB for something more in line with its use for other
minibuffer input?

And, again, if a different or additional binding is needed for
lisp-complete-symbol, that pertains to Lisp modes generally, not
specifically to M-:.

Re: Usability suggestion : completion for M-:

[paul r]

 Drew Adams <drew.adams@oracle.com>:

>  Why do that, especially if, as you admit, it is just a temporary hack: "in
>  the meantime"? In-the-meantime changes can become fixed by neglect, for no
>  special reason, rather than being just temporary exceptions to the rule. The
>  result of lots of such changes would be ad-hoc inconsistency throughout the
>  UI.

I think this "Agree" was not clear enough. I agree on the idea that
M-: could *certainly* be made better, just like any other part of
emacs. You seem to have some ideas on that topic, and if you write a
M-x eval-expression-full-bodied , I will for sure give it a fair try.
I have no doubt on your skills to produce wise and good quality code.

But the point is that *today*, only eval-expression exists, and I
think Tab for completion makes more sens that Tab for self-insert,
and, above all, is more intuitive. And this thread is all about
binding *by default* Tab to give it a more intuitive behaviour in
fresh emacs install. But I think I stated that enough now, and you
clearly stated your position as well, so it could help to have other
people advice on that point, concerning the *current implementation*
of M-:

Re: Usability suggestion : completion for M-:

[paul r]

Drew Adams wrote :
> On the contrary. TAB in the minibuffer either (1) self-inserts (when not
>  using completing-read or read-file-name) or (2) completes the entire
>  minibuffer input in such a way that you can hit RET to enter the completed
>  input.

In other words, TAB does completion in minibuffer whenever possible.
And, in lisp modes, TAB does NOT self-insert.
For those reasons, I advocate dropping self-insert in favor of
complete-symbol for Tab in M-: , for usability, consistency, and
intuitiveness.

Re: Usability suggestion : completion for M-:

[Bastien]

"paul r" <paul.r.ml@gmail.com> writes:

> But I think I stated that enough now, and you clearly stated your
> position as well, so it could help to have other people advice on 
> that concerning the *current implementation* of M-:

Since you're calling for other people advice, here is mine.

Like Drew, I am a bit skeptical about this change and I agree it will
introduce some inconsistency.  

My main concerns are these ones: 

1) if people get used to press TAB instead of M-TAB after M-: then they
   will be surprised that pressing TAB does not complete expressions in
   Lisp modes;

2) Having TAB complete expressions after M-: will make people confuse
   commands and expressions, since TAB will then have the same effect
   after M-: and M-w; 

3) I wouldn't drop the possibility to self-insert tabs with the TAB key
   after M-: -- at least not so easily.  

The fact that ielm uses TAB in order to complete expression is not an
argument to use it in the minibuffer.  In ielm, the TAB key is bound to
`comint-dynamic-complete' and M-TAB is bound to `lisp-complete-symbol'.
"comint" is short for "command-interpreter-in-a-buffer".  So in ielm.el
the TAB key has the same meaning than it has in shell.el -- and it is
consistent to have both TAB and M-TAB here.

I have the impression that the only *true* motivation for performing
completion with TAB after M-: is that M-TAB is stolen by many window
managers.  If so, did people know that M-C-i could be used for
completion?  If they didn't know about this key, I think it's better to
test it a bit before proposing another one.

My 2 cents,

-- 
Bastien

Re: Usability suggestion : completion for M-:

[Bastien Guerry]

Juri Linkov <juri@jurta.org> writes:

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

Er... that drops the first concern I raised in the previous email. 

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

+1

-- 
Bastien

Re: Usability suggestion : completion for M-:

[David De La Harpe Golden]

Bastien wrote:

> I have the impression that the only *true* motivation for performing
> completion with TAB after M-: is that M-TAB is stolen by many window
> managers.

And it IS also remappable in most window managers (possible exception
being windoze, though for all I know you can remap it there too), I
habitually reset window-manager M-TAB to super-TAB, because I'm so used
to emacs having M-TAB. :-)

Re: Usability suggestion : completion for M-:

[Stefan Monnier]

>> But I think I stated that enough now, and you clearly stated your
>> position as well, so it could help to have other people advice on 
>> that concerning the *current implementation* of M-:

For what it's worth, I'm a bit annoyed by Emacs's inconsistent use of
TAB: in minibuffers, TAB behaves like in terminals to mean "complete",
where in normal buffers it usually means "indent".

But of course, "indent" can also make sense in minibuffers, and
"complete" also makes a lot of sense in normal buffers.

I have used for many years commands that do both bound to TAB: typically
my TAB first tries to indent, and if the indentation code didn't make any
change then TAB tries to complete.

It works OK as far as DWIMish things are concerned, but it has some
rough corners:
- if the indentation code always makes changes (e.g. because it cycles
  through several possible indentation points), then completion is
  never used.
- if the completion code only gets called when you repeat TAB, then
  well... you have to repeat TAB to get to completion.
- if not, then you get surprising results when you do TAB C-n TAB C-n
  ... intending to reindent a chunk of code and once of the lines
  happens to be properly indented already and you end up
  completing instead.

So it's not a satisfactory solution.


        Stefan

Re: Usability suggestion : completion for M-:

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

On Sun, 16 Mar 2008 22:52:51 -0400
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> >> But I think I stated that enough now, and you clearly stated your
> >> position as well, so it could help to have other people advice on 
> >> that concerning the *current implementation* of M-:
> 
> For what it's worth, I'm a bit annoyed by Emacs's inconsistent use of
> TAB: in minibuffers, TAB behaves like in terminals to mean "complete",
> where in normal buffers it usually means "indent".
> 
> But of course, "indent" can also make sense in minibuffers, and
> "complete" also makes a lot of sense in normal buffers.
> 
> I have used for many years commands that do both bound to TAB:
> typically my TAB first tries to indent, and if the indentation code
> didn't make any change then TAB tries to complete.
> 
> It works OK as far as DWIMish things are concerned, but it has some
> rough corners:
> - if the indentation code always makes changes (e.g. because it cycles
>   through several possible indentation points), then completion is
>   never used.

Can you post the code ? I have a similar setup, but I can't remember
running into that particular problem before.

The biggest issue I noticed with overloaded commands is that Emacs
commands will inspect this-command. An overloaded command
needs to adjust these sorts of variables so other code isn't adversely
affected. Some parts of Emacs definitely don't appreciate the current
command being a lambda either.

> - if the completion code only gets called when you repeat TAB, then
>   well... you have to repeat TAB to get to completion.
> - if not, then you get surprising results when you do TAB C-n TAB C-n
>   ... intending to reindent a chunk of code and once of the lines
>   happens to be properly indented already and you end up
>   completing instead.
> 
> So it's not a satisfactory solution.

I definitely have a different implementation that sounds more robust.
I hit tab repeatedly and the result is always the same in regards to
the behavior selected.
 
> 
>         Stefan
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Usability suggestion : completion for M-:

[paul r]

2008/3/17, Stefan Monnier <monnier@iro.umontreal.ca>:

> For what it's worth, I'm a bit annoyed by Emacs's inconsistent use of
>  TAB: in minibuffers, TAB behaves like in terminals to mean "complete",
>  where in normal buffers it usually means "indent".

As a person relatively new to emacs, I can remember that those various
uses of TAB made my first steps a bit more difficult. Now in my
config, TAB is rebound for almost every mode I use, see below.

>  I have used for many years commands that do both bound to TAB: typically
>  my TAB first tries to indent, and if the indentation code didn't make any
>  change then TAB tries to complete.

I'm really surprised to see how many people here have done their own
implementation of this behaviour. FWIW, here is mine, fairly naive,
but functional.

(defun indent-for-tab-or-expand (expand-fct)
  "Indent line if not yet, otherwise call parameter function."
  (interactive)
  (let ((ppos (point)))
    (indent-for-tab-command)
    (if (and (looking-at "$") (not (looking-back "^\\s-*")) (eq ppos (point)))
	(call-interactively expand-fct))))

(defun indent-for-tab-or-dabbrev-expand ()
  "Indent line if not yet, otherwise call dabbrev-expand."
  (interactive)
  (indent-for-tab-or-expand 'dabbrev-expand))

(defun indent-for-tab-or-hippie-expand ()
  "Indent line if not yet, otherwise call hippie-expand."
  (interactive)
  (indent-for-tab-or-expand 'hippie-expand))


regards,

-- paul

Re: Usability suggestion : completion for M-:

[Stefan Monnier]

>> - if the indentation code always makes changes (e.g. because it cycles
>> through several possible indentation points), then completion is
>> never used.

> Can you post the code ? I have a similar setup, but I can't remember
> running into that particular problem before.

Because you don't use code written in languages where indentation is
significant, maybe? (e.g. Haskell and Python)

> The biggest issue I noticed with overloaded commands is that Emacs
> commands will inspect this-command. An overloaded command
> needs to adjust these sorts of variables so other code isn't adversely
> affected. Some parts of Emacs definitely don't appreciate the current
> command being a lambda either.

That's just a minor implementation issue, which wouldn't both us, since
we have control over the rest of the code as well.

>> - if the completion code only gets called when you repeat TAB, then
>> well... you have to repeat TAB to get to completion.
>> - if not, then you get surprising results when you do TAB C-n TAB C-n
>> ... intending to reindent a chunk of code and once of the lines
>> happens to be properly indented already and you end up
>> completing instead.
>> 
>> So it's not a satisfactory solution.

> I definitely have a different implementation that sounds more robust.
> I hit tab repeatedly and the result is always the same in regards to
> the behavior selected.
 
What's the behavior?  When does it indent and when does it complete?


        Stefan

Re: Usability suggestion : completion for M-:

[Richard Stallman]

    For what it's worth, I'm a bit annoyed by Emacs's inconsistent use of
    TAB: in minibuffers, TAB behaves like in terminals to mean "complete",
    where in normal buffers it usually means "indent".

There aren't enough convenient keys, so we have to do this overloading.

    But of course, "indent" can also make sense in minibuffers,

It can make sense, but it is not very useful in minibuffers.  We
wouldn't recommend writing nontrivial Lisp code in a minibuffer, for
instance.

    "complete" also makes a lot of sense in normal buffers.

Yes, so we use M-TAB for that.

It isn't perfectly elegant, but I think it is the best solution
available given the constraints of the keyboard.

    I have used for many years commands that do both bound to TAB: typically
    my TAB first tries to indent, and if the indentation code didn't make any
    change then TAB tries to complete.

I think that would be unpredictable and therefore inconvenient.

Re: Usability suggestion : completion for M-:

[paul r]

Richard Stallman <rms@gnu.org>:
>     For what it's worth, I'm a bit annoyed by Emacs's inconsistent use of
>     TAB: in minibuffers, TAB behaves like in terminals to mean "complete",
>     where in normal buffers it usually means "indent".
>
>
> There aren't enough convenient keys, so we have to do this overloading.
>

How necessary is it today to have *by default* C-i bound to TAB (and
C-m bound to RET). This is a real honnest question, I'm wondering if
some terms have hard-bound C-i etc. Please note that I really like
C-m, because RET is just to far away from my right hand. But TAB and
C-i are equaly accessible. In case it is not hard-bound on some
systems emacs runs on, how about using one for indent and the other
for completion ? That could allow to have a consistent behaviour
across modes.

-- paul

Re: Usability suggestion : completion for M-:

[Richard Stallman]

    How necessary is it today to have *by default* C-i bound to TAB (and
    C-m bound to RET).

I thin both indentation and completion are important enough to be on
TAB, not C-i.

In any case, we should not change such a thing without polling the users.

Re: Usability suggestion : completion for M-:

[Stefan Monnier]

>     How necessary is it today to have *by default* C-i bound to TAB (and
>     C-m bound to RET).

> I thin both indentation and completion are important enough to be on
> TAB, not C-i.

> In any case, we should not change such a thing without polling the users.

Since under ttys, TAB and C-i are usually indistinguishable, I'd rather
not being them to different commands, since that would only work
on GUIs.


        Stefan

Re: Usability suggestion : completion for M-:

[paul r]

> Since under ttys, TAB and C-i are usually indistinguishable, I'd rather
>  not being them to different commands, since that would only work
>  on GUIs.

That what I was wondering. That makes C-i unavailable. This is in a
way similar to the "unavailability" of M-Tab in many environments.
FWIW, I notice C-Tab is delivered as :
 - C-Tab under X
 - Tab under xterm and similar
 - Tab under TTY

-- paul

Re: Usability suggestion : completion for M-:

[Andreas Schwab]

"paul r" <paul.r.ml@gmail.com> writes:

>> Since under ttys, TAB and C-i are usually indistinguishable, I'd rather
>>  not being them to different commands, since that would only work
>>  on GUIs.
>
> That what I was wondering. That makes C-i unavailable.

It is not unavailable, it is just indistinguishable from TAB.  You can
type C-i and get the expected result.

> This is in a way similar to the "unavailability" of M-Tab in many
> environments.

This is quite different.  In these enviroments Emacs does not see the
key at all.

> FWIW, I notice C-Tab is delivered as :
>  - C-Tab under X
>  - Tab under xterm and similar
>  - Tab under TTY

This is even another case.  Here the modifier is ignored, but the base
key is still received.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Usability suggestion : completion for M-:

[Drew Adams]

> From: Drew Adams Sent: Thursday, March 13, 2008 4:50 PM
>
> I would prefer to see M-: take on more of the
> character of a pop-up emacs-lisp-mode buffer:
> TAB, C-M-q, C-j,..., but with RET still causing
> eval...  And I'd like to see M-: pretty-print the
> result (as in pp-eval-expression)

FWIW, this is now the behavior in Icicles,
in case you want to see what it's like.

Re: Usability suggestion : completion for M-:

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> I think the only problem preventing this change is one completion message
> that overwrites the minibuffer when TAB doesn't find a completion.
> I propose the patch below similar to the patch I proposed for the
> shell command minibuffer completion.
>
> When this is fixed, it makes sense to allow TAB to complete a lisp
> symbol part of the eval-expression minibuffer in the same way as TAB
> will allow completion of command name and file name parts of the
> shell-command minibuffer.

The discussion seems to have been badly sidetracked.

The patch looks good.  Please install it.

Re: Usability suggestion : completion for M-:

[Juri Linkov]

>> I think the only problem preventing this change is one completion message
>> that overwrites the minibuffer when TAB doesn't find a completion.
>> I propose the patch below similar to the patch I proposed for the
>> shell command minibuffer completion.
>>
>> When this is fixed, it makes sense to allow TAB to complete a lisp
>> symbol part of the eval-expression minibuffer in the same way as TAB
>> will allow completion of command name and file name parts of the
>> shell-command minibuffer.
>
> The discussion seems to have been badly sidetracked.
>
> The patch looks good.  Please install it.

The first part of the patch is installed now.  But I still see
no unanimous consensus on what command to bind to TAB in
read-expression-map.  Currently it inserts just a tab character,
and this is useless in the minibuffer.

I think we could add a new command `lisp-indent-or-complete'
that will complete a Lisp symbol if the character preceding point
is symbol-constituent, or indent line or region otherwise.
And bind TAB in read-expression-map to this command.

Note that I don't propose to bind TAB in emacs-lisp-mode to this
command by default.  So no changes in emacs-lisp-mode (though it will
be available to easily rebind TAB in .emacs to everyone who likes this
behavior).

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Usability suggestion : completion for M-:

[Drew Adams]

> I think we could add a new command `lisp-indent-or-complete'
> that will complete a Lisp symbol if the character preceding point
> is symbol-constituent, or indent line or region otherwise.
> And bind TAB in read-expression-map to this command.
> 
> Note that I don't propose to bind TAB in emacs-lisp-mode to this
> command by default.  So no changes in emacs-lisp-mode (though it will
> be available to easily rebind TAB in .emacs to everyone who likes this
> behavior).

If you change the binding of TAB (in the minibuffer or in emacs-lisp-mode or
anywhere else) to such a DWIM command, please at least compare existing such
commands before picking one. Some have been posted here, some more are on the
wiki, and perhaps someone will come up with a better idea yet. Please discuss it
first. (No, I don't have one that I prefer; I might prefer none of them.)

In particular, I don't think it's a great idea to try to complete a symbol just
because the cursor follows text that _could_ be completed to a symbol. If you
second-guess the user this way (that's what DWIM does), then you should at least
do it only if the preceding symbol-constituent chars do not _already_ constitute
a completed symbol.

You don't want to introduce symbol completion when point follows `delete', for
instance. Don't look for completions, just indent the line - assume that's what
the user wants in such a case. In general, I would suggest indenting, not
completing a symbol, when there is a doubt about the user's possible intention.

I'm not a big fan of DWIM, in general, or at least not of some the DWIM I've
seen so far. It tends to be short-sighted, treating some use cases well but not
others, and taking away user control. When making DWIM features the default,
it's good to provide options to at least let users get around any unintentional
design short-sightedness.

Re: Usability suggestion : completion for M-:

[Paul R]

"paul r" <paul.r.ml@gmail.com> writes:

> Hello,
>
> Emacs seems to have a consistent behaviour regarding TAB and
> completion, i.e : Almost everywhere, TAB triggers completion when :
> - indentation does not make sens
> - tabulation char is unlikely to make sens
>
> For exemple, TAB triggers completion in find-file. I think TAB should
> be bound to lisp-complete-symbol in M-x eval-expression, aka M-: .
>
> Hope everybody agree and this will be widely considered as a simple
> yet positive change.
>
> Paul

This thread ended whithout consensus, leading to statu quo :)
If I can try to sum-up positions :

 * Drew believe that the whole M-: should evolve to something more
   like a interactive scratch in the context of current buffer, and
   that if TAB does not complete in scratch, it should not complete in
   M-:
 * Some other people believe TAB should complete in M-:, because M-:
   happens in minibuffer, and other prompts in minibuffer are usually
   completed by TAB
 * In any case : everybody agree inserting a tabulation caracter does
   not make sens, because 1) it not the behaviour in *scratch*; 2) it
   is not the behaviour in minibuffer prompts; 3) it is almost useless
   in this case.

I do not think we should let this default binding in its current
state, because it is confusing. Even if there is no absolute consensus
in this thread, I think this default should be changed.

-- Paul

RE: Usability suggestion : completion for M-:

[Drew Adams]

>  * Drew believe that the whole M-: should evolve to something more
>    like a interactive scratch in the context of current buffer, and
>    that if TAB does not complete in scratch, it should not complete in
>    M-:

To be specific, I said this:

> I would prefer to see M-: take on more of the
> character of a pop-up emacs-lisp-mode buffer:
> TAB, C-M-q, C-j,..., but with RET still causing
> eval...  And I'd like to see M-: pretty-print the
> result (as in pp-eval-expression)

No need to "evolve to something more like" - it's easy enough to do. This is the
behavior in Icicles, for instance.

(defvar icicle-read-expression-map nil
  "Icicle mode version of `read-expression-map'.
Several Emacs-Lisp mode key bindings are used.")
(unless icicle-read-expression-map
  (let ((map (make-sparse-keymap)))
    (define-key map "\M-\t" 'lisp-complete-symbol)
    (define-key map "\t" 'lisp-indent-line)
    (define-key map "\e\C-q" 'indent-sexp)
    (define-key map "\e\t" 'lisp-complete-symbol)
    (define-key map "\e\C-x" 'eval-defun)
    (define-key map "\e\C-q" 'indent-pp-sexp)
    ;;(define-key map "\177" 'backward-delete-char-untabify)
    (set-keymap-parent map minibuffer-local-map)
    (setq icicle-read-expression-map map)))

(defun icicle-pp-eval-expression (expression) ; `M-:' in Icicle mode.
  "Evaluate an Emacs-Lisp expression and pretty-print its value."
  (interactive
   (list (read-from-minibuffer "Eval: " nil
           icicle-read-expression-map t 'read-expression-history)))
  (pp-eval-expression expression))

Re: Usability suggestion : completion for M-:

[Juri Linkov]

>>  * Drew believe that the whole M-: should evolve to something more
>>    like a interactive scratch in the context of current buffer, and
>>    that if TAB does not complete in scratch, it should not complete in
>>    M-:
>
> To be specific, I said this:
>
>> I would prefer to see M-: take on more of the
>> character of a pop-up emacs-lisp-mode buffer:
>> TAB, C-M-q, C-j,..., but with RET still causing
>> eval...  And I'd like to see M-: pretty-print the
>> result (as in pp-eval-expression)

I think it would make sense to change M-: to use the same behavior
as M-! has, i.e. when the number of lines of the result is more than
some threshold then pop-up a buffer in another window with the result.

-- 
Juri Linkov
http://www.jurta.org/emacs/