From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Sun, 22 Dec 2013 18:15:55 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <877gawbhp0.fsf@flea.lifelogs.com> References: <87fvqtg02v.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> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387754098 15866 80.91.229.3 (22 Dec 2013 23:14:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Dec 2013 23:14:58 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 23 00:15:04 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 1VusEi-00067P-7A for ged-emacs-devel@m.gmane.org; Mon, 23 Dec 2013 00:15:04 +0100 Original-Received: from localhost ([::1]:59687 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VusEh-0007ES-Ex for ged-emacs-devel@m.gmane.org; Sun, 22 Dec 2013 18:15:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VusEY-0007Du-2y for emacs-devel@gnu.org; Sun, 22 Dec 2013 18:14:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VusES-0004tm-7M for emacs-devel@gnu.org; Sun, 22 Dec 2013 18:14:54 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:60999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VusER-0004th-TJ for emacs-devel@gnu.org; Sun, 22 Dec 2013 18:14:48 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VusEQ-0005sd-6h for emacs-devel@gnu.org; Mon, 23 Dec 2013 00:14:46 +0100 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Dec 2013 00:14:46 +0100 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Dec 2013 00:14:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 114 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:W5Kg4l98hHFq80R5DiGuI/ggyXE= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:166743 Archived-At: On Sat, 21 Dec 2013 21:05:24 -0500 Stefan Monnier wrote: 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. SM> Here I lost you. Currently, the kind of operation can be: SM> - list candidates (completion-help-at-point) SM> - insert a few chars (completion-at-point) SM> - cycle through candidates (completion-at-point with SM> completion-cycle-threshold, or minibuffer-force-complete). SM> AFAIK the users often like to have the choice between the three. SM> Tho admittedly, TAB is the main entry point. I was thinking of these as the effect of the operation, and the operation is "completion DWIM." The semantics here are a minefield and there is a huge range of customizations available. >> IOW this should be the place where Emacs standardizes to only one >> completion/selection API, possibly through the >> `completion-*' functions. SM> And here I lost you as well: I thought this section was about commands SM> and behaviors, whereas "API" to me means "functions" (as in "called from SM> Elisp"). I mean TAB (and its equivalent in-buffer keybinding) should be bound to a single Elisp function, and the effect (list candidates, complete immediately the single candidate, or cycle candidates depending on the user preferences) should be consistent in any invocation context. 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. SM> Hmm... Could you explain which parts are not consistent? "Select with up/down" is not consistent between in-minibuffer and in-buffer completion. You can always go into the *Completions* buffer and then use up/down, but up/down immediately have different effects otherwise. I think they should do the same thing, enter a special popup as Dmitry and I described. "Keep on editing" acts differently as well. Mouse selection works the same way, I think. >> 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; SM> That should be easy to implement (tho admittedly, currently this will SM> require 2 different implementations for in-buffer and in minibuffer). SM> For the in-buffer case, it might be as simple as adding a call to SM> completion-help-at-point at the right place. OK, so do we agree on this specific improvement? "Whether in the minibuffer or in a buffer, typing more characters should narrow the list of candidates without having to press TAB or other special keys." >> 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. SM> Usually, if it works for in-buffer, it works as well in the SM> minibuffer case. Good point. But why not simply enter an auto-narrowing popup in both contexts? The user has explicitly requested completion, right? I keep thinking that if in both contexts we locked the user into a selection popup, the up/down and motion issues would be easily solved. It would also allow `C-1' through `C-9' (or some similar keys) to be used to immediately select a candidate by position, like `widget-choose' does it. 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. SM> "Internal to the API" is completely meaningless to me. If it's not SM> exposed, then it's not in the API (i.e. it's only in the SM> chosen UI's implementation). Right, sorry. It should be internal to the 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. SM> I still don't quite understand what you want here. Are you thinking of SM> a function like x-popup-menu or display-completion-list? Yes, `display-completion-list' but hacked to use `widget-choose' at least in graphical mode and to auto-narrow. This should work with (interactive) calls, of course, as a common use case. So let's say I'm inside gnutls.el and want to ask the user to select a client certificate to present to the remote server. I have a list of 3 such certificates. I would say `(display-completion-list list-of-certificates)' and expect the result to be nil or an element of the list. Does that usage make sense? Ted