emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Usability suggestion : completion for M-:


From: Drew Adams
Subject: RE: Usability suggestion : completion for M-:
Date: Sat, 22 Mar 2008 22:54:37 -0700

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]