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: Mon, 23 Dec 2013 07:28:39 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87pponagzs.fsf@flea.lifelogs.com> References: <87fvqtg02v.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> <877gawbhp0.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 1387801660 18302 80.91.229.3 (23 Dec 2013 12:27:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Dec 2013 12:27:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 23 13:27: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 1Vv4bo-0002Oh-Uv for ged-emacs-devel@m.gmane.org; Mon, 23 Dec 2013 13:27:45 +0100 Original-Received: from localhost ([::1]:33262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vv4bo-00016O-Bu for ged-emacs-devel@m.gmane.org; Mon, 23 Dec 2013 07:27:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vv4bf-00016I-NP for emacs-devel@gnu.org; Mon, 23 Dec 2013 07:27:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vv4bZ-00059k-Rg for emacs-devel@gnu.org; Mon, 23 Dec 2013 07:27:35 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:53571) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vv4bZ-00059P-Gu for emacs-devel@gnu.org; Mon, 23 Dec 2013 07:27:29 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vv4bX-00028x-Jj for emacs-devel@gnu.org; Mon, 23 Dec 2013 13:27:27 +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 13:27:27 +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 13:27:27 +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:7HuiTj5vVzITGqHo2mkbPGdxmkM= 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:166766 Archived-At: On Sun, 22 Dec 2013 20:59:49 -0500 Stefan Monnier wrote: >> 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> Not sure what you feel is missing here. `completion-at-point' is SM> basically it, AFAICT. But it's OK if different UIs provide other SM> commands (or other ways, since completion can also happen as SM> a side-effect of normal commands, as is the case with auto-complete and SM> company-mode). SM> The important point is that the completion command to use shouldn't SM> depend on the "backend" (e.g. on the current major mode), and AFAIK SM> we're almost there (the new completion code in Emacs-23 and subsequent SM> bit-by-bit updates of major modes to make use of SM> completion-at-point-functions was dedicated to this task). SM> Can't remember what are the remaining exceptions, other than Eshell. OK, is there a way to make a verification and testing plan for this? If there was some automation around completion support, it would certainly speed things up, but we need at least a list of currently non-compliant modes in Emacs. How do you look for the exceptions, by searching for old functions or testing manually? SM> Hmm... Could you explain which parts are not consistent? >> "Select with up/down" is not consistent between in-minibuffer and >> in-buffer completion. SM> AFAIK it is consistent: neither in minibuffer nor in in-buffer up/down SM> is bound to a completion-related command. It's not what you want, but SM> it's consistent w.r.t the completion UI. Using `up' in the minibuffer goes back in the history currently, which invalidates the current completion candidates, so it does have some effect. But I agree it's not directly completion-related. >> "Keep on editing" acts differently as well. SM> Details? Minor. >> 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." SM> If you add the qualifier "when the completion list is displayed", SM> I think I agree, yes (I actually hesitated to add that feature when SM> wrote the new minibuffer.el code, but then decided to keep it for later, SM> sine there was plenty of other behavioral changes introduced at that SM> time already). You might want to make it configurable, but I think SM> enabling it by default would be OK. 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? SM> Didn't I just agree in the previous paragraph? OK. >> 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> As I already said in earlier discussions, it might very well be SM> acceptable to hijack those keys. But only experience can confirm it. So auto-narrowing (customizable) and a graphical popup (customizable as a frontend choice) are OK. Hijacking keys is to be tested further and a demo is needed. All this will happen with `completion-at-point'. SM> The API design should presumably make it possible to use company-mode's SM> overlay-based popups, or widget-choose's popup, or good ol' SM> *Completions* buffer. As with company-mode, this can be a frontend choice (affecting `display-completion-list', and see below for the suggested `display-list' function). How about a defcustom `completion-ui-frontend' with some choices? SM> It should maybe also make it possible for the caller to provide some SM> data that might influence which kind of popup to use (in case the SM> kind of popup to use might depend on the context: not sure if that's SM> really necessary), tho the ultimate choice should be with the user's SM> config, of course. For the user, a new defcustom `completion-ui-preferences'? And for the caller, some kind of plist/alist passed to `completion-at-point' that merges cleanly with `completion-ui-preferences'? s/completion-ui/something-else/ as you see fit. >> 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? SM> No. That would seem to call for a completely different API meant to SM> generalize completing-read rather than display-completion-list. I would like that, too, so choosing from a list of elements can use all the improvements suggested here for `display-completion-list'. Could this be a new `display-list' function, used to display both completion selection (through `display-completion-list') and list selection? Ted