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: Fri, 20 Dec 2013 06:49:29 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87zjnvg2t2.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> <878uvg4ul2.fsf@yandex.ru> <87y53ghe94.fsf@flea.lifelogs.com> <87vbyk3497.fsf@yandex.ru> <87haa4gw69.fsf@flea.lifelogs.com> <87txe4usm1.fsf@yandex.ru> 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 1387540111 4859 80.91.229.3 (20 Dec 2013 11:48:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Dec 2013 11:48:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 20 12:48:37 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 1VtyZH-0006Jl-J5 for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 12:48:35 +0100 Original-Received: from localhost ([::1]:49020 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtyZH-0002Q9-9l for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 06:48:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtyZA-0002Px-4H for emacs-devel@gnu.org; Fri, 20 Dec 2013 06:48:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtyZ4-0003P3-G2 for emacs-devel@gnu.org; Fri, 20 Dec 2013 06:48:27 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:33996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtyZ4-0003Or-8x for emacs-devel@gnu.org; Fri, 20 Dec 2013 06:48:22 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VtyZ1-0006Ak-TF for emacs-devel@gnu.org; Fri, 20 Dec 2013 12:48:19 +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 ; Fri, 20 Dec 2013 12:48:19 +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 ; Fri, 20 Dec 2013 12:48:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 78 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:ugV0LiO5SQGXlrhF5JFMxM3F8ig= 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:166657 Archived-At: On Fri, 20 Dec 2013 05:08:22 +0200 Dmitry Gutov wrote: DG> Ted Zlatanov writes: DG> The hard technical part would be to draw the tooltip in the right place DG> above the frame, make it fast, and offer a good Elisp interface. Then DG> the code, of which there's a lot, can integrate it. DG> ^^^ existing code >> `widget-choose' does this already to some degree, right? Do you see any >> shortcomings in it? DG> 1. It captures all user input. DG> That prohibits from using it for displaying completion candidates during DG> unobtrusive, idle completion. Which is a feature users value. I agree that's a good API option (being able to specify asynchronous vs. synchronous completion) and the widget should support it. DG> 2. It has no support for incremental narrowing (consequence of item 1). DG> You call the completion command, but there are too many candidates! DG> What do you do? You type a few chars and see the list shortened on the fly. DG> `widget-choose' won't let you do that. You'll have to dismiss it, type a DG> couple of chars, display it again, see whether the list of short enough DG> now, and if it isn't, dismiss the widget and try again. Most people will DG> give up now and either type the whole word themselves, or start DG> scrolling the list with the mouse, hunting for the required candidate. Yup, absolutely. The autocomplete web browser widgets (e.g. the jQuery UI one) have that on-the-fly narrowing. This specifically conflicts with the way in-buffer completion works right now, and the in-minibuffer completion kind of works like this if you turn `icomplete-mode' on and hit TAB to see the candidates every time you type a character. IMO this should be an API option. DG> 3. It's displayed near the mouse cursor. DG> Did I miss a way to change that? I'm sure that can be changed to be an API option. Showing the candidates near point is one of the big issues with the current situation, where *Completions* can pop up at the other side of the screen, so I think that's an important element as well. DG> 4. It does not support long lists. I'm not sure it's useful to show a very long list like we do currently. The *Completions* buffer does it with multiple columns and TAB to move to the next page and it's not great visually. For instance showing all the Unicode characters with `C-x 8 RET TAB' shows a huge list this way (you can narrow it with "substring TAB") and would be a good use case. Showing icons for every list element would be a nice option, especially for the Unicode glyphs. It may be better for the API call to allow multiple columns as an option but default to showing just what fits on the screen in a single column, indicating how many more candidates are not shown. Something like this, if only 9 lines fit on the screen (the indicators for "100 more" would be appropriate to the native widget): "[... 100 more ... ] candidate1 candidate2 candidate3 candidate4 candidate5 candidate6 candidate7 [... 100 more ... ]" And then you could handle a case like the Unicode characters by breaking out into a table or something even denser. Ted