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 09:59:26 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87r497fu0h.fsf@flea.lifelogs.com> References: <87fvqtg02v.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> <87zjnvg2t2.fsf@flea.lifelogs.com> <87txe364q0.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 1387551515 15766 80.91.229.3 (20 Dec 2013 14:58:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Dec 2013 14:58:35 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 20 15:58:41 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 1Vu1XD-0007WH-Iy for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 15:58:39 +0100 Original-Received: from localhost ([::1]:50018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu1XD-0003Mh-5T for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 09:58:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu1X5-0003MQ-Ut for emacs-devel@gnu.org; Fri, 20 Dec 2013 09:58:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vu1X0-00026L-Kq for emacs-devel@gnu.org; Fri, 20 Dec 2013 09:58:31 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:58377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu1X0-000267-An for emacs-devel@gnu.org; Fri, 20 Dec 2013 09:58:26 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vu1Wr-0007Ep-OW for emacs-devel@gnu.org; Fri, 20 Dec 2013 15:58:17 +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 15:58:17 +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 15:58:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 89 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:T6bAhssVluRwxoKsrwJfrajj3uU= 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:166663 Archived-At: On Fri, 20 Dec 2013 15:18:15 +0200 Dmitry Gutov wrote: DG> Ted Zlatanov writes: >> I agree that's a good API option (being able to specify asynchronous >> vs. synchronous completion) and the widget should support it. DG> I think synchronous vs. asynchronous is a concern of a backend, and it DG> has nothing to do with the widget. The latter only has to support the DG> mode of operation where it passes through most of the keystrokes (except DG> the ones specifically bound) through to Emacs. Or, better yet, captures DG> none of them and lets the main event loop trigger right commands in the DG> currently active maps, which in turn can modify the contents of the DG> widget. DG> Have you tried reading the company-mode source code? (that reminds me I should write a CFEngine-specific completion backend for company-mode, like I did for general completion in cfengine.el :) I've explored anything/Helm and company-mode and a few others. They all have pluses and minuses. I do like how company-mode separates frontends from backends and agree with you about where synchronous vs. asynchronous as a choice belongs. But I don't know if a standard Emacs completion/selection API like what we're discussing would have such a separation, or if it would be better to keep it simpler. >> 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 DG> There's no real conflict, in-buffer completion could be made to work DG> this way. I believe it doesn't right now just because it could be too DG> performance-intensive when using some completion functions. Perhaps, I don't know the history and there may be some reasonable concerns with performance and code complexity. But I agree this is how it *should* work in general, since it's already how the in-minibuffer completion works as I mentioned (modulo the extra TABs to show the narrowed selection). >> IMO this should be an API option. DG> The API just has to allow updating the list on the fly. That's not a simple thing, since Emacs doesn't have data notifications, does it? It would have to be a callback? But those have performance penalties and may need to be queued... For large lists we have to consider all this. DG> 4. It does not support long lists. >> >> Showing icons for every list element would be a nice option, especially >> for the Unicode glyphs. DG> Will this require explicit support? Emacs supports inline images. If the list display is purely done in Emacs, it could work (although IIRC tooltips have special rules about graphics depending on the platform). If it's a native widget, they sometimes have a special slot for icons. I don't know for sure what's the right approach here but it seems that displaying the list in a purely Emacsian popup, as opposed to a native widget, would be the better choice for cross-platform consistency and functionality. >> It may be better for the API call to allow multiple columns as an >> option DG> I don't think multiple column display is a good option for a popup, at DG> all. Maybe as a special case, but that could be added later. OK, I don't have a strong opinion here. >> 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): DG> Yes. Or a scroll bar. Depending on how "native" the widget will be. DG> Another nice feature would be to allow "columns", but of a different DG> kind. The first column would be the completion options. The second one DG> would be their annotations (all lines up vertically). Maybe add the DG> option of having multiple annotations for the third, fourth, etc, DG> columns. Right, so for example the symbol completion could show the docstring and current value (for defcustoms). I agree this is a very useful extra. Ted