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, 16 Dec 2013 17:15:49 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87haa8moh6.fsf@flea.lifelogs.com> References: <87fvqtg02v.fsf@flea.lifelogs.com> <877gc5fm30.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> 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 1387232101 17012 80.91.229.3 (16 Dec 2013 22:15:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Dec 2013 22:15:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 16 23:15:07 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 1VsgRO-0002Yj-Bd for ged-emacs-devel@m.gmane.org; Mon, 16 Dec 2013 23:15:06 +0100 Original-Received: from localhost ([::1]:58416 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsgRN-00062t-NC for ged-emacs-devel@m.gmane.org; Mon, 16 Dec 2013 17:15:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsgRF-0005zo-JA for emacs-devel@gnu.org; Mon, 16 Dec 2013 17:15:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsgR9-00022K-QT for emacs-devel@gnu.org; Mon, 16 Dec 2013 17:14:57 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:36377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsgR9-00022E-K1 for emacs-devel@gnu.org; Mon, 16 Dec 2013 17:14:51 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VsgR1-0002Hf-RD for emacs-devel@gnu.org; Mon, 16 Dec 2013 23:14:43 +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, 16 Dec 2013 23:14:43 +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, 16 Dec 2013 23:14:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 63 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:+ppZJLJ/QokfhS/oUGf5MPXyHSQ= 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:166519 Archived-At: On Mon, 16 Dec 2013 13:35:47 -0500 Stefan Monnier wrote: >> ;; It is difficult to know when to exit completion-in-region-mode (i.e. hide >> ;; the *Completions*). SM> [...] >> If there was a special popup to show a list of items, [...], it would >> abstract these difficulties and cut some nasty code out of >> minibuffer.el. SM> No, it wouldn't. The problem needs to be solved either way. SM> `company-mode' solves this problem not by popping up a special GUI SM> element, but by defining which operations can be performed while this SM> element is displayed, and which operations cause the element SM> to disappear. And completion-in-region-mode does the same, tho using SM> the *Completions* buffer rather than a special GUI element, and making SM> different choices about which operations can be performed while the SM> completions are displayed and which operations make the SM> completions disappear. 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? 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. The choices about available operations during selections and which operations should cancel or complete the selection should be entirely inside an API like `widget-choose' and *standard*. I think the trigger to bring the selection UI up is the only thing that should be up to the client. In the case of `completion-in-region-mode', do you see how it would remove a large chunk of code that deals with post-change and key customizations? Or am I just not getting it? >> For the UI case of "I'm in the minibuffer and want to complete >> something" I would rather wait for the general list popup to be >> available with `widget-choose' than add the special down/up keybindings >> that we discussed. SM> Again, this has nothing to do with whether the list is displayed in SM> a *Completions* buffer or on a shoestring. The questions are "when SM> should the list be displayed", and after that, "when should we enter the SM> special mode where the user can navigate in this list". This was a separate UI case and I think we agreed (broadly) earlier on these questions. I am saying I'd rather wait to implement this until I have a standard Emacs-wide API to display a list of candidates, so I am not writing blocks of code to work around the currently implemented *Completions* UI. From `completion-in-region-mode' and reading the other code around minibuffer.el I believe it will be hard to write maintainable code to do this otherwise. >> I think the change is too risky for the short time we have this week. SM> I'm not sure which change you're thinking of, but I probably agree. I meant the change to implement the second UI case, the one to make up/down bring up the candidate selection UI as we discussed. Ted