From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Fri, 20 Dec 2013 15:18:15 +0200 Message-ID: <87txe364q0.fsf@yandex.ru> 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> <87zjnvg2t2.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387545524 4049 80.91.229.3 (20 Dec 2013 13:18:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Dec 2013 13:18:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 20 14:18:50 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 1VtzyY-0005tv-LZ for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 14:18:46 +0100 Original-Received: from localhost ([::1]:49489 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtzyY-0005ZE-7Z for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 08:18:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtzyH-0005IB-5V for emacs-devel@gnu.org; Fri, 20 Dec 2013 08:18:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtzyB-0004Jh-Pc for emacs-devel@gnu.org; Fri, 20 Dec 2013 08:18:29 -0500 Original-Received: from mail-ee0-x234.google.com ([2a00:1450:4013:c00::234]:62110) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtzyB-0004JQ-IS for emacs-devel@gnu.org; Fri, 20 Dec 2013 08:18:23 -0500 Original-Received: by mail-ee0-f52.google.com with SMTP id d17so1053530eek.11 for ; Fri, 20 Dec 2013 05:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=hyFi6IpIgfom2+nO5ggPUdgKTru4A50Q6le1/kZIyXc=; b=x3WGjOMG7Wch7gHhAcmR39spqORZht5EBQiDUsOjiHySWt3Ws+X7+i5CsjFE3yZu1u UsPvVC1phwDfbU1g/bDBs1e9OTBI9OfQCyIXmuoC1dDL+F6PQqGmk1ePcR8zi0W96mET 5J4GyoJt0zwil045XCmMPGjB7ZSJMeiLGjlQL7RNHdfnLVSIHBTbZbl2Bl4qzTTt8u3f BFKoEN+qzIpAeCqnErxafzvpOAMyK1SzPj8XaoceXpkZwWPM+vKZDc+qT7R5aqTXs3Dy uGBrMNX5BrbxOZjRl9Bh4mvBVnQLVhNuhleHdRxaJu/VFgOI2KnLuXdBXAjQ1/PchIF9 nrsw== X-Received: by 10.15.110.8 with SMTP id cg8mr4841665eeb.42.1387545502796; Fri, 20 Dec 2013 05:18:22 -0800 (PST) Original-Received: from axl (93-2-98.netrun.cytanet.com.cy. [93.109.2.98]) by mx.google.com with ESMTPSA id v1sm18543908eef.9.2013.12.20.05.18.20 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 20 Dec 2013 05:18:21 -0800 (PST) In-Reply-To: <87zjnvg2t2.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Fri, 20 Dec 2013 06:49:29 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::234 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:166660 Archived-At: 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. I think synchronous vs. asynchronous is a concern of a backend, and it has nothing to do with the widget. The latter only has to support the mode of operation where it passes through most of the keystrokes (except the ones specifically bound) through to Emacs. Or, better yet, captures none of them and lets the main event loop trigger right commands in the currently active maps, which in turn can modify the contents of the widget. Have you tried reading the company-mode source code? > 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 There's no real conflict, in-buffer completion could be made to work this way. I believe it doesn't right now just because it could be too performance-intensive when using some completion functions. > IMO this should be an API option. The API just has to allow updating the list on the fly. > DG> 4. It does not support long lists. > > Showing icons for every list element would be a nice option, especially > for the Unicode glyphs. Will this require explicit support? Emacs supports inline images. > It may be better for the API call to allow multiple columns as an > option I don't think multiple column display is a good option for a popup, at all. Maybe as a special case, but that could be added later. > 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): Yes. Or a scroll bar. Depending on how "native" the widget will be. Another nice feature would be to allow "columns", but of a different kind. The first column would be the completion options. The second one would be their annotations (all lines up vertically). Maybe add the option of having multiple annotations for the third, fourth, etc, columns.