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:00:40 +0000 Message-ID: <20140106040040.GA7934@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 1388980862 11716 80.91.229.3 (6 Jan 2014 04:01:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 04:01:02 +0000 (UTC) Cc: Dmitry Gutov , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 06 05:01:09 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 1W01ND-0006eH-Lo for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 05:01:07 +0100 Original-Received: from localhost ([::1]:60530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W01ND-0002d6-CJ for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 23:01:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W01N3-0002Zc-UF for emacs-devel@gnu.org; Sun, 05 Jan 2014 23:01:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W01My-00062H-Cw for emacs-devel@gnu.org; Sun, 05 Jan 2014 23:00:57 -0500 Original-Received: from sanddollar.geekisp.com ([216.168.135.167]:16640) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1W01My-00061z-7j for emacs-devel@gnu.org; Sun, 05 Jan 2014 23:00:52 -0500 Original-Received: (qmail 26576 invoked by uid 1003); 6 Jan 2014 04:00:51 -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:00:44 -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.167 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:167436 Archived-At: On Fri, Jan 03, 2014 at 10:39:00PM -0500, Stefan Monnier wrote: > >> I suspect that :exit-function is "enough", tho it might require some > >> ugly unreliable hacks to get at the needed data. Please try it out and > >> M-x report-emacs-bug requesting the extra features/data to be able to > >> "do it right". > > I still don't see how, if by "enough" you mean enough to emulate the > > current Predictive functionality without effectively bypassing the > > `completion-at-point' mechanism and running Predictive/Completion-UI code > > instead. > > I don't know enough about Predictive to be able to answer. Predictive needs to know what was the final text that got inserted in the buffer after the whole completion process finished. Expanding a string to the longest common prefix doesn't count as finished as far as Predictive is concerned. > :exit-function is called when the completion ends and gives access to > the choice made by the user, so it is sufficient to provide some kind > of feedback about which was the right choice. If :exit-function is called with STATUS = `finished` if and only if the STRING that was inserted in the buffer was one of the candidates returned by the `completion-at-point-functions' hook, I think that would be sufficient for Predictive. I couldn't easily understand from the docstring or from skimming the code whether that's what it does. I'll try playing around with it more fully to see what happens as soon as I have a spare moment. But for that I need to hack together a completion function and :exit-function to test with. > But there might indeed be issues about exactly when the :exit-function > is called, for example, or how/when the choices are presented. Certainly a richer completion UI would probably require some changes and additions to `completion-extra-properties'. > > `completion-at-point' is designed around "tab-completion", and > > that just isn't a good match for predictive completion (or a popup.el > > style UI, for that matter). > > completion-at-point-functions is largely designed for the purpose of > completion-at-point, but it is not restricted to that; so do not confuse > the two. I don't think I was confused about the relation between completion-at-point and completion-at-point-functions. I was confused about what exactly completion-at-point does, but I think I understand now. I was wrong about it not being a good match for the popup.el UI, which could quite easily replace the *Completions* buffer. Just to be clear, by "tab-completion" I meant the style of completion that expands a string to the longest common prefix if possible and stops, or displays a list of possible completions if there's no common prefix. Which is exactly what `completion-at-point' does. This style isn't a good fit to predictive completion, since arguably the whole point of predictive completion is to guess the most likely completions from all the possible candidates, and make it as easy as possible to quickly select one of those. Expanding to a longest common prefix and then stopping has no place in this. Anyway, this is a digression. It would already be possible to define Predictive as a `completion-at-point' function. The current `completion-at-point' *user-interface* isn't a particularly good fit to Predictive, so the result would be crippled compared to predictive-mode. But this thread is all about improving that UI. I see no reason why, with a richer Emacs completion UI, Predictive couldn't work just fine with `completion-at-point'. Best, 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