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 05:49:47 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <874n67n450.fsf@flea.lifelogs.com> References: <87fvqtg02v.fsf@flea.lifelogs.com> <87k3g47m7b.fsf@yandex.ru> <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> 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 1387277336 22311 80.91.229.3 (17 Dec 2013 10:48:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Dec 2013 10:48:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 17 11:49:01 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 1VssCy-0005et-5k for ged-emacs-devel@m.gmane.org; Tue, 17 Dec 2013 11:49:00 +0100 Original-Received: from localhost ([::1]:60669 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VssCx-0007WU-Qn for ged-emacs-devel@m.gmane.org; Tue, 17 Dec 2013 05:48:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VssCp-0007Vi-LR for emacs-devel@gnu.org; Tue, 17 Dec 2013 05:48:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VssCi-000115-JX for emacs-devel@gnu.org; Tue, 17 Dec 2013 05:48:51 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:53986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VssCi-00010x-Ci for emacs-devel@gnu.org; Tue, 17 Dec 2013 05:48:44 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VssCf-0005QK-LX for emacs-devel@gnu.org; Tue, 17 Dec 2013 11:48:41 +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 11:48:41 +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 11:48:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 54 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:QvNSBEq6nDJ8ZkPZy7qDL1XQ9MI= 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:166541 Archived-At: On Mon, 16 Dec 2013 21:10:02 -0500 Stefan Monnier wrote: >> I am trying to say that Emacs itself, outside of the >> window/frame/etc. logic, should have code to "show a list of choices and >> pick one." An API to list selection, from the minibuffer or from a >> buffer, with consistent key bindings and no dependence on the context in >> which it was invoked. This seems to be what `widget-choose' could do >> with some polish, and that's where I'd put effort. Do you agree? SM> I could agree, but do note that one of the main design goals of SM> completion-in-region-mode was that the mode is exited as a side-effect SM> of the user's normal editing. IOW, the user is free to ignore the list SM> of completions and do whatever else she wants to do, rather than having SM> to somehow indicate explicitly "oh, never mind, I won't choose any of SM> these options". Yes, I understand. But this is at odds with the way that `completing-read' and `widget-choose' and most modern UIs work. The user has explicitly invoked a completion command, right? Or is `completion-in-region-mode' ever called implicitly? SM> But IIUC the "choice" API you suggest would allow something like SM> completion-in-region-mode as one possible UI. 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. >> To me, It seems crazy that there is no standard way to do this and >> that so many packages, internal and external, have invented their own >> UI to do it. SM> There is one, which is completing-read. But this one size doesn't SM> fit all. Maybe there is some other one size which does, but maybe not. `completing-read' moves the focus of the user from point to the minibuffer IIUC, and then makes the entire interaction minibuffer-centric. That seems to be the fundamental reason why we invented `completion-in-region-mode', to avoid that context switch. Otherwise yes, `completing-read' could be the list-selection API. 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. Or maybe `completing-read' could be called for in-buffer completion if the minibuffer could somehow be moved closer to point? Imagine if the minibuffer could slide up to point during the completion (perhaps by simply growing it upwards until it reaches point), then there wouldn't be a disorienting focus switch. Ideally the entire minibuffer would slide up and look the same otherwise, but that's probably going to be hard to implement. Ted