From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Toby Cubitt Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Mon, 6 Jan 2014 04:47:57 +0000 Message-ID: <20140106044757.GA1979@c3po> References: Reply-To: Toby Cubitt NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1388983690 2878 80.91.229.3 (6 Jan 2014 04:48:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 04:48:10 +0000 (UTC) Cc: Ted Zlatanov , emacs-devel@gnu.org, Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 06 05:48:17 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W026p-0008RT-GH for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 05:48:15 +0100 Original-Received: from localhost ([::1]:60674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W026p-0007P3-5W for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 23:48:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W026i-0007Ow-RP for emacs-devel@gnu.org; Sun, 05 Jan 2014 23:48:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W026d-0001Be-UI for emacs-devel@gnu.org; Sun, 05 Jan 2014 23:48:08 -0500 Original-Received: from starfish.geekisp.com ([216.168.135.166]:4119) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1W026d-0001BY-OT for emacs-devel@gnu.org; Sun, 05 Jan 2014 23:48:03 -0500 Original-Received: (qmail 13077 invoked by uid 1003); 6 Jan 2014 04:48:02 -0000 Original-Received: from localhost (localhost.geekisp.com [127.0.0.1]) by localhost.geekisp.com (tmda-ofmipd) with ESMTP; Sun, 05 Jan 2014 23:47:58 -0500 Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.dr-qubit.org/gpg-toby-pub.asc User-Agent: Mutt/1.5.22 (2013-10-16) X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) X-Primary-Address: toby@dr-qubit.org X-detected-operating-system: by eggs.gnu.org: OpenBSD 4.x-5.x [fuzzy] X-Received-From: 216.168.135.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167445 Archived-At: On Fri, Jan 03, 2014 at 10:45:37PM -0500, Stefan Monnier wrote: > > Emacs, and what the API should look like, re-purposing (parts of) the > > Company and/or Completion-UI code bases (maybe others too?) will be a big > > head start (assuming no copyright assignment roadblocks). > > Company is in GNU ELPA, so its copyright status is already clear. > I'd be happy to see completion-ui in GNU ELPA as well. > > > Think minibuffer completion, versus filename completion, versus > > predictive completion, versus elisp code completion etc, all of which > > might want to use slightly different UI options. > > Not sure why. Maybe I just don't understand what you mean by "UI > options". Do you have concrete examples in mind? Sure. If you're doing predictive plain-text completion, you probably don't want to display all possible completions all the time. You probably want to limit the list to the 10 or so most likely completions. You might also want to set a minimum prefix length below which Emacs refuses to search for completions (finding all completions of the letter "t" in an English dictionary can take a while...unless you're using Predictive of course, in which case it takes fractions of a second ;-) Whereas for filename completion, you most likely always want to list all the possible completions, and you probably want to show completions even for single-letter prefixes. Another example: the "dynamic completion" UI in Completion-UI is something like `hippie-expand', mimicking the kind of thing you see in IDEs, or LibreOffice, or mobile phones: the best completion candidate is displayed highlighted in the buffer, and typing a space or punctuation character inserts that completion. This a very useful and widely-used UI for predictive plain-text completion. For code completion, this UI is infuriating. You'll almost certainly either want to disable it completely, or at least configure it so that the highlighted completion only gets inserted in the buffer when you explicitly tell it to with a specific key binding. Yet another: For plain-test predictive completion, single-character "hotkey" bindings to quickly select one of the first n completions are quite useful, e.g. you might use the characters 0-9. But these single-character bindings mean you can't type any of those characters whilst you're completing. For filename completion, you'll almost certainly want to disable these bindings. I could go on. But maybe that's enough to convince you that it's useful to be able to configure the UI slightly differently for different kinds of completion. Even if most of the time you'll want to configure the UI globally. In Completion-UI, I have a `defcustom-per-source' macro (a drop-in replacement for `defcustom') that automatically turns a standard defcustom definition into one that can optionally take different values for particular completion sources. So making customization options configurable per-source is zero effort. Hope that helps, Toby -- Dr T. S. Cubitt Royal Society University Research Fellow and Fellow of Churchill College, Cambridge Centre for Quantum Information DAMTP, University of Cambridge email: tsc25@cantab.net web: www.dr-qubit.org