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 23:58:06 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <8738lmg5r5.fsf@flea.lifelogs.com> References: <87fvqtg02v.fsf@flea.lifelogs.com> <87y53komex.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> <87mwjvfrfy.fsf@flea.lifelogs.com> <87wqiyop4s.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1387601898 28088 80.91.229.3 (21 Dec 2013 04:58:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Dec 2013 04:58:18 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 21 05:58:24 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 1VuEdq-0002t2-6v for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 05:58:22 +0100 Original-Received: from localhost ([::1]:52826 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuEdp-0004CZ-Qf for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 23:58:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuEdh-0004CU-DD for emacs-devel@gnu.org; Fri, 20 Dec 2013 23:58:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuEdb-0008SZ-Ak for emacs-devel@gnu.org; Fri, 20 Dec 2013 23:58:13 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:37403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuEdb-0008SQ-0e for emacs-devel@gnu.org; Fri, 20 Dec 2013 23:58:07 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VuEdU-0002gN-UQ for emacs-devel@gnu.org; Sat, 21 Dec 2013 05:58:00 +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 ; Sat, 21 Dec 2013 05:58:00 +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 ; Sat, 21 Dec 2013 05:58:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 94 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:kOfCe2VpeFBf8Y6PlIHYNXQECuw= 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:166681 Archived-At: On Sat, 21 Dec 2013 12:32:19 +0900 "Stephen J. Turnbull" wrote: SJT> Ted Zlatanov writes: SM> - what completion operations take place: SM> - insert a few chars at point SM> - bring up a list of candidates SM> - ... >> >> I think this should be unified as much as possible into a single >> operation that takes place in any context, outside of the user's >> control. IOW this should be the place where Emacs standardizes to only >> one completion/selection API, possibly through the `completion-*' >> functions. SJT> Please explain what you mean by "unify". If you mean SJT> one-size-fits-all, I think that would be horrible. There are SJT> completion contexts where I don't want a list at all (dabbrev), and SJT> others where I really, really do (browser completion of long URLs from SJT> long histories). The context will be respected either by being a parameter or being inferred from the invocation, or both. The idea is to have a single API call for all contexts, not to make the operation's effect the same in all contexts. SJT> If you simply mean there should be one function to invoke the SJT> completion system, or a small number of such functions, with a "small" SJT> number of parameters, I agree. Right, exactly. SJT> I think this points out the need for a dispatching architecture, SJT> where the completion function exposed in the API ends up SJT> dispatching to several handlers: construct the candidate list, SJT> filter it, prioritize it, optionally present it to the user, and SJT> optionally edit the target text ("auto-complete" suggests that edit SJT> will always happen, but it's not always what is desired of a SJT> completion mechanism -- eg, something I've occasionally wished for SJT> is a "uniquifying completer", so that I don't accidentally SJT> duplicate identifiers -- "you can check out but you can never SJT> leave" until the item is unique in scope :-). See the company-mode frontend/backend split, for instance. This is a common design. I don't have a strong opinion about the whole data flow, I just want to improve the frontend right now, but perhaps these opportunities will appear if the project takes off. SM> - how to display the list of candidates: SM> - in a separate buffer SM> - at point, via clever overlay tricks SM> - at point, via a special frame SM> - at point, via a x-popup-menu SM> - ... >> >> This should probably be customizable, but the default IMO should be >> different between graphical and text mode, the way that `widget-choose' >> does it. SJT> If you architect the system as dispatching handlers to perform certain SJT> tasks in sequence, you can postpone this decision (and, in fact, most SJT> of the decisions you are discussing here, prematurely IMHO). It seems SJT> to me that the custom "selectors" for instancing faces (or whatever SJT> the "keys" in a defface are called) would be a good choice for SJT> specifying completion "list display" handlers. Then you can start SJT> with "one size fits all" with a selector of t and easily SJT> generalize. I think postponing these design decisions would not be optimal, but I understand the temptation and will listen to advice when we get to that point. SJT> The only nasty task in this architecture would be if it becomes SJT> necessary to split a handler into two. However, AFAICT from your SJT> immediate agreement to the agenda Stefan set here, the three of us SJT> (you, Stefan, me) agree 100% on what the options involved are, and I SJT> suspect we could also agree quite quickly on what tasks deserve SJT> separate handlers (some of the options probably need coordinated SJT> decisions to avoid screwing each other up, so should not be in SJT> separate handlers). I still need a clear agreement from Stefan before proceeding. Then I will try to get a team together and work outside of the normal Emacs commit flow so we can iterate quickly. SJT> That's only 3 people, but I think it's good evidence that agreement SJT> is going to be widespread, given how disparate our opinions have SJT> been on everything else in this thread. Discussions of UI improvements are one of the rare occasions where everyone has at least one strong opinion. I think this one has been quite smooth, I've only thrown one keyboard out the window and AFAIK I'm not yet in Stefan's killfile ;) Ted