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 10:54:57 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87mwjvfrfy.fsf@flea.lifelogs.com> References: <87fvqtg02v.fsf@flea.lifelogs.com> <8761rkaa5e.fsf@flea.lifelogs.com> <87txf0390n.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> 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 1387554884 26831 80.91.229.3 (20 Dec 2013 15:54:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Dec 2013 15:54: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 16:54:47 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 1Vu2PV-0000fv-IS for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 16:54:45 +0100 Original-Received: from localhost ([::1]:50290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu2PU-0007S1-Ui for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 10:54:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu2Oj-00065F-Mj for emacs-devel@gnu.org; Fri, 20 Dec 2013 10:54:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vu2Od-0002rz-Gi for emacs-devel@gnu.org; Fri, 20 Dec 2013 10:53:57 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:53898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu2Od-0002ra-5x for emacs-devel@gnu.org; Fri, 20 Dec 2013 10:53:51 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vu2Ob-0008ND-F0 for emacs-devel@gnu.org; Fri, 20 Dec 2013 16:53:49 +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 16:53:49 +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 16:53:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 97 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:1r3dTtrdvVRuqcU3OCO1tgYMqv0= 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:166664 Archived-At: On Fri, 20 Dec 2013 09:32:11 -0500 Stefan Monnier wrote: >>>> If theres another point to this debate, please forgive me, because >>>> I have missed it. >>> Personally, I'm trying to understand what it is that Ted is suggesting. >> I've explained it so many times I'm starting to wonder if my English is >> the problem. SM> It's never really control of language, but each word can mean many SM> different things, and we seem to have very different assumptions and SM> contexts, hence the difficulty. Yes, I see that. Sorry for any confusion I've brought to the discussion, and thanks for separating the various areas. SM> The way I see it, the subject under discussion can be divided into various SM> mostly orthogonal elements: SM> - when does the completion code get invoked: SM> - upon hitting TAB SM> - after typing the first N chars of a completable element SM> - when entering minibuffer SM> - ... I am not looking to improve this, it's quite good already. 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. 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. See the parallel discussion with Dmitry about the possible approaches here, including icons and tables with annotations and so on. SM> - what operations can be performed while the list of candidates is displayed: SM> - keep on editing as if the list was not displayed SM> - select among candidates with the mouse SM> - select with up/down SM> - ... The current defaults for this are not consistent and were the original reason for starting the thread. The default here is tricky, since we have the in-buffer vs. in-minibuffer split to consider. I agree with Dmitry that auto-narrowing the candidates is important by default; the up/down selection is important too but must not interfere with buffer motion when completing in a buffer of course. If we can find something consistent that works as a default in all the invocation contexts, I think that would offer the biggest benefit to Emacs usability. SM> - how/when to update the list of completions and to pop it down. That should be entirely internal to the API and not exposed, I think. SM> - what Lisp function to call to display the list of elements. SM> We currently don't really have something clear here. IIUC this is the SM> API part you care about (the rest is mostly behavior rather than API). Yes, this is the API that should get called by any package (internal or external) that wants to ask the user to interactively select completion candidates or just one item from a list. >> 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, SM> It doesn't conflict at all. The current UI doesn't update *Completions* SM> on-the-fly, but it very much could (and pretty easily too). OK, that's great. >> 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. SM> I don't see why it should appear in the API. It looks like a user SM> preference instead. See below for a very crude approximation. Yes, I think you're right, but I can't think of a case where I don't want auto-narrowing, so I suggest always turning it on. Ted