From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Sat, 21 Dec 2013 21:05:24 -0500 Message-ID: References: <87fvqtg02v.fsf@flea.lifelogs.com> <87txf0390n.fsf@flea.lifelogs.com> <87y53komex.fsf@flea.lifelogs.com> <87haa8moh6.fsf@flea.lifelogs.com> <874n67n450.fsf@flea.lifelogs.com> <87eh5bkxca.fsf@flea.lifelogs.com> <87d2kuzzqj.fsf@uwakimon.sk.tsukuba.ac.jp> <87a9fylusq.fsf@flea.lifelogs.com> <878uvizrwz.fsf@uwakimon.sk.tsukuba.ac.jp> <8761qmkyn1.fsf@flea.lifelogs.com> <87zjnyxdpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87k3f2j7xv.fsf@flea.lifelogs.com> <2518D79A-B9E4-45DF-A403-8330145DFD17@gmail.com> <87eh58j0x3.fsf@flea.lifelogs.com> <87mwjvfrfy.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387677940 22701 80.91.229.3 (22 Dec 2013 02:05:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Dec 2013 02:05:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 22 03:05:45 2013 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 1VuYQL-0007Lp-3h for ged-emacs-devel@m.gmane.org; Sun, 22 Dec 2013 03:05:45 +0100 Original-Received: from localhost ([::1]:56302 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuYQK-0007tR-K9 for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 21:05:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42008) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuYQA-0007sz-6Y for emacs-devel@gnu.org; Sat, 21 Dec 2013 21:05:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuYQ1-00011s-SG for emacs-devel@gnu.org; Sat, 21 Dec 2013 21:05:34 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:51554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuYQ1-00011o-Mf for emacs-devel@gnu.org; Sat, 21 Dec 2013 21:05:25 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id rBM25M1c007699; Sat, 21 Dec 2013 21:05:23 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 27513AE1E4; Sat, 21 Dec 2013 21:05:24 -0500 (EST) In-Reply-To: <87mwjvfrfy.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Fri, 20 Dec 2013 10:54:57 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4799=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4799> : inlines <347> : streams <1094923> : uri <1631657> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:166720 Archived-At: SM> - what completion operations take place: SM> - insert a few chars at point SM> - bring up a list of candidates SM> - ... > I think this should be unified as much as possible into a single > operation that takes place in any context, outside of the user's > control. Here I lost you. Currently, the kind of operation can be: - list candidates (completion-help-at-point) - insert a few chars (completion-at-point) - cycle through candidates (completion-at-point with completion-cycle-threshold, or minibuffer-force-complete). AFAIK the users often like to have the choice between the three. Tho admittedly, TAB is the main entry point. > IOW this should be the place where Emacs standardizes to only one > completion/selection API, possibly through the > `completion-*' functions. And here I lost you as well: I thought this section was about commands and behaviors, whereas "API" to me means "functions" (as in "called from Elisp"). SM> - what operations can be performed while the list of candidates is displayed: SM> - keep on editing as if the list was not displayed SM> - select among candidates with the mouse SM> - select with up/down SM> - ... > The current defaults for this are not consistent and were the original > reason for starting the thread. Hmm... Could you explain which parts are not consistent? > The default here is tricky, since we have the in-buffer > vs. in-minibuffer split to consider. I agree with Dmitry that > auto-narrowing the candidates is important by default; That should be easy to implement (tho admittedly, currently this will require 2 different implementations for in-buffer and in minibuffer). For the in-buffer case, it might be as simple as adding a call to completion-help-at-point at the right place. > the up/down selection is important too but must not interfere with > buffer motion when completing in a buffer of course. If we can find > something consistent that works as a default in all the invocation > contexts, I think that would offer the biggest benefit to > Emacs usability. Usually, if it works for in-buffer, it works as well in the minibuffer case. SM> - how/when to update the list of completions and to pop it down. > That should be entirely internal to the API and not exposed, I think. "Internal to the API" is completely meaningless to me. If it's not exposed, then it's not in the API (i.e. it's only in the chosen UI's implementation). SM> - what Lisp function to call to display the list of elements. SM> We currently don't really have something clear here. IIUC this is the SM> API part you care about (the rest is mostly behavior rather than API). > Yes, this is the API that should get called by any package (internal or > external) that wants to ask the user to interactively select completion > candidates or just one item from a list. I still don't quite understand what you want here. Are you thinking of a function like x-popup-menu or display-completion-list? Stefan