unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juri Linkov'" <juri@jurta.org>,
	"'Chong Yidong'" <cyd@stupidchicken.com>
Cc: emacs-devel@gnu.org
Subject: RE: Usability suggestion : completion for M-:
Date: Sat, 22 Mar 2008 22:54:37 -0700	[thread overview]
Message-ID: <001301c88caa$610f49e0$0600a8c0@us.oracle.com> (raw)
In-Reply-To: <87fxuiyzan.fsf@jurta.org>

> 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	other threads:[~2008-03-23  5:54 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-13 17:30 Usability suggestion : completion for M-: paul r
2008-03-13 18:04 ` Lennart Borgman (gmail)
2008-03-13 21:16 ` Drew Adams
2008-03-13 21:32   ` paul r
2008-03-13 21:45     ` Lennart Borgman (gmail)
2008-03-13 23:32 ` Chong Yidong
2008-03-13 23:49   ` Drew Adams
2008-03-21  5:21     ` Drew Adams
2008-03-14  8:52   ` paul r
2008-03-15 21:36   ` Juri Linkov
2008-03-15 23:35     ` Drew Adams
2008-03-15 23:43       ` Lennart Borgman (gmail)
2008-03-16  8:12         ` Drew Adams
2008-03-16 11:00           ` paul r
2008-03-16 11:21             ` Ralf Angeli
2008-03-16 16:52             ` Drew Adams
2008-03-16 12:27           ` Lennart Borgman (gmail)
2008-03-16 16:50             ` Drew Adams
2008-03-16  0:17       ` Juri Linkov
2008-03-16  8:11         ` Drew Adams
2008-03-16 10:48           ` Andreas Schwab
2008-03-16 12:22             ` Lennart Borgman (gmail)
2008-03-16 13:36               ` Andreas Schwab
2008-03-16 10:56           ` paul r
2008-03-16 16:49             ` Drew Adams
2008-03-16 18:42               ` paul r
2008-03-16 19:56                 ` Bastien
2008-03-16 20:22                   ` David De La Harpe Golden
2008-03-17  2:52                   ` Stefan Monnier
2008-03-17  4:07                     ` Mike Mattie
2008-03-17 13:32                       ` Stefan Monnier
2008-03-17  9:32                     ` paul r
2008-03-17 19:16                     ` Richard Stallman
2008-03-18  9:19                       ` paul r
2008-03-19  2:53                         ` Richard Stallman
2008-03-19 16:28                           ` Stefan Monnier
2008-03-19 18:16                             ` paul r
2008-03-19 19:25                               ` Andreas Schwab
2008-03-16 18:49               ` paul r
2008-03-16 12:31           ` Lennart Borgman (gmail)
2008-03-16 16:50             ` Drew Adams
2008-03-16 20:06         ` Bastien Guerry
2008-03-22 21:14     ` Chong Yidong
2008-03-23  2:30       ` Juri Linkov
2008-03-23  5:54         ` Drew Adams [this message]
2008-04-09 20:42 ` Paul R
2008-04-09 21:20   ` Drew Adams
2008-04-10 23:12     ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001301c88caa$610f49e0$0600a8c0@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=juri@jurta.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).