From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "paul r" Newsgroups: gmane.emacs.devel Subject: Re: Usability suggestion : completion for M-: Date: Sun, 16 Mar 2008 11:56:40 +0100 Message-ID: References: <87ejaei4iz.fsf@stupidchicken.com> <87hcf7r7vl.fsf@jurta.org> <003001c886f5$366f4330$0600a8c0@us.oracle.com> <874pb7ikt7.fsf@jurta.org> <000501c8873d$4ff68550$0600a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1205665021 22342 80.91.229.12 (16 Mar 2008 10:57:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Mar 2008 10:57:01 +0000 (UTC) Cc: Juri Linkov , cyd@stupidchicken.com, emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 16 11:57:29 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JaqYN-00062P-8e for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2008 11:57:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaqXn-0004sD-PU for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2008 06:56:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JaqXj-0004q0-Gw for emacs-devel@gnu.org; Sun, 16 Mar 2008 06:56:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JaqXi-0004pB-Mo for emacs-devel@gnu.org; Sun, 16 Mar 2008 06:56:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaqXi-0004oz-Gf for emacs-devel@gnu.org; Sun, 16 Mar 2008 06:56:42 -0400 Original-Received: from fg-out-1718.google.com ([72.14.220.158]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JaqXi-0003W4-1b for emacs-devel@gnu.org; Sun, 16 Mar 2008 06:56:42 -0400 Original-Received: by fg-out-1718.google.com with SMTP id d23so6172410fga.30 for ; Sun, 16 Mar 2008 03:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=RaTqkSHRi6OnL7MDU1vSBaMNsHrvDsGMrfn8lbgudtc=; b=KsxegY3ilHnMr9Qsjb7P+35taZ8Nnq/vNjjhppiDwdHcgqxsXQ9SxXYH6Yhs6fT2O2NUrN/WUO6nXwi9Ba0sGh69Bb3fjBb9H2QP1klCx60kxivzn9GGgHG4OejzQpdtPAYwp+OGVrEAByV2hAi+UcDLjEPLrbNRhU2Gzib02E8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RS99x+X9sdgm/4omYfQSepiufAojJLw3rO3Yf/F/Nfv1bWbmDfHZH5X6aA1Oqns7NDGb1igTQnShzmD9pGmkI0rgvRYLe+hppSotGv6NTb12UUc3wTEHrgIHpvYTotCuz4OhBItqzZwO/DPoNGI+KjZv1fKngWAr2KD09gDUK0A= Original-Received: by 10.82.146.10 with SMTP id t10mr32987121bud.6.1205665000091; Sun, 16 Mar 2008 03:56:40 -0700 (PDT) Original-Received: by 10.82.176.6 with HTTP; Sun, 16 Mar 2008 03:56:40 -0700 (PDT) In-Reply-To: <000501c8873d$4ff68550$0600a8c0@us.oracle.com> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:92728 Archived-At: 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-: