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: Tue, 17 Dec 2013 15:59:33 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87eh5bkxca.fsf@flea.lifelogs.com> References: <87fvqtg02v.fsf@flea.lifelogs.com> <528B6F11.7070607@yandex.ru> <87y54ke8v3.fsf@flea.lifelogs.com> <87li0kdrsz.fsf@flea.lifelogs.com> <878uwi8t3r.fsf@mail.jurta.org> <83ob5ee7ow.fsf@gnu.org> <87d2ltl2if.fsf@mail.jurta.org> <8338moevm3.fsf@gnu.org> <8761rkaa5e.fsf@flea.lifelogs.com> <87txf0390n.fsf@flea.lifelogs.com> <87y53komex.fsf@flea.lifelogs.com> <87haa8moh6.fsf@flea.lifelogs.com> <874n67n450.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 1387315012 28788 80.91.229.3 (17 Dec 2013 21:16:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Dec 2013 21:16:52 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 17 22:16:57 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 1Vt20f-0007Xx-7E for ged-emacs-devel@m.gmane.org; Tue, 17 Dec 2013 22:16:57 +0100 Original-Received: from localhost ([::1]:35586 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vt20e-0005MZ-JB for ged-emacs-devel@m.gmane.org; Tue, 17 Dec 2013 16:16:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vt1iv-0002w1-3T for emacs-devel@gnu.org; Tue, 17 Dec 2013 15:58:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vt1ip-0003N2-9a for emacs-devel@gnu.org; Tue, 17 Dec 2013 15:58:37 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:55007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vt1ip-0003Mo-3W for emacs-devel@gnu.org; Tue, 17 Dec 2013 15:58:31 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vt1im-0000JE-RU for emacs-devel@gnu.org; Tue, 17 Dec 2013 21:58:28 +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 ; Tue, 17 Dec 2013 21:58:28 +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 ; Tue, 17 Dec 2013 21:58:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 52 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:perQ8QWVzEmg2f3AmIxB+aDbduQ= 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:166558 Archived-At: On Tue, 17 Dec 2013 13:29:30 -0500 Stefan Monnier wrote: >> Right, it wouldn't care about the invocation context, the "dismiss on >> input when called in a buffer context" behavior would be an option. For >> those who like it, it can stay. I don't think it should be the default. SM> I'm not sure why you see it as something the user wouldn't like. Because it's not familiar. SM> More specifically, why would you want to force the user to use special SM> commands to leave the "completion choice mode"? SM> I must be missing something. I am asking for more familiar behavior. It's a standard "select from a list of things" popup, sometimes with autocomplete. Those have been around for a long time and have well-established UI conventions, so we don't have to invent our own. In today's standard autocompleted lists, you finish the interaction by either down{n}+RET to select, ESC to cancel, or with input that clears the candidate list (so none match). These are not special commands. The user is not captive to the UI. Do you need examples of how popular and standard this behavior is today? Do they matter to you? Generally the candidates are displayed on a layer above the application with transparency to indicate they are transient. >> Otherwise yes, `completing-read' could be the list-selection API. SM> I think "list-selection" is a restrictive way to think about it: hitting SM> TAB to complete doesn't necessarily mean "the user wants to select SM> a completion candidate". It can also mean "the user wants to complete SM> "fo" to "fooba" and then complete this identifier by adding something SM> else that's not in any of the completion candidates. Right, so perhaps it can do all of that. But surely list selection is a basic use case it should cover without trying to read minds? >> Could `completing-read' call `widget-choose' regardless of the >> invocation point and show a graphical popup or a simple text buffer? >> Even in the minibuffer I think that would look OK. SM> We wouldn't use completing-read, for API reasons. But indeed, the SM> minibuffer.el code is slowly moving towards using the same completion SM> mechanism as in other buffers (completion-at-point). OK, I understand. It seems that you already have a direction in mind so I only hope you make it closer to what's standard today, and that it's exposed as an API. Ted