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: Tue, 19 Nov 2013 16:07:08 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87li0kdrsz.fsf@flea.lifelogs.com> References: <87fvqtg02v.fsf@flea.lifelogs.com> <877gc5fm30.fsf@flea.lifelogs.com> <87k3g47m7b.fsf@yandex.ru> <528B6F11.7070607@yandex.ru> <87y54ke8v3.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 1384895207 28513 80.91.229.3 (19 Nov 2013 21:06:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Nov 2013 21:06:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 19 22:06:51 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 1VisVX-0003Dt-3F for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2013 22:06:51 +0100 Original-Received: from localhost ([::1]:51676 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VisVW-000524-JX for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2013 16:06:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VisVO-00051x-Qn for emacs-devel@gnu.org; Tue, 19 Nov 2013 16:06:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VisVI-0006RN-BL for emacs-devel@gnu.org; Tue, 19 Nov 2013 16:06:42 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:47523) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VisVI-0006QU-4f for emacs-devel@gnu.org; Tue, 19 Nov 2013 16:06:36 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VisVH-000362-Cg for emacs-devel@gnu.org; Tue, 19 Nov 2013 22:06:35 +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 ; Tue, 19 Nov 2013 22:06:35 +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 ; Tue, 19 Nov 2013 22:06:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 82 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:2bZ8bwEX93ySvuXtZza9e+US49Q= 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:165403 Archived-At: On Tue, 19 Nov 2013 12:50:38 -0500 Stefan Monnier wrote: SM> The main issue is then to figure out how/when to switch to this SM> new mode. E.g. when the user hits `up' right after the *Completions* SM> buffer got displayed/updated? >> Maybe the trigger should be another `TAB'? That's what I would press, >> intuitively. SM> Another TAB currently means "scroll the *Completions* buffer". SM> I'm not sure if we want to get rid of that feature. ... SM> (tho I think the way this new mode should work, it should not SM> switch to the *Completions* window, but instead just change key-bindings SM> in the minibuffer to highlight/select an entry in *Completions*). Agreed, although then the *Completions* buffer should at least get better highlighting. >> The second problem is that there are no alternatives to the default >> match selection UI. Your company-mode integration would help there. >> Please let me know when it's ready for testing. SM> There's nothing special there: just the company-capf in the latest SM> company package. OK, thanks. >> Remember you can also see the completion candidates buffer without the >> minibuffer, if you e.g. do `complete-symbol' in a buffer. SM> I think you mean `completion-at-point'. Indeed, that is a lot more SM> tricky, since in such a context, keys can have any number of SM> other bindings, and it's quite normal to hit `up' or `down' with the SM> intention of "move to the other line because I'm done writing this SM> completable element", so hijacking `up' or `down' in this context is SM> more delicate. I agree, and my proposal is to "lock in" the user into the selection mode until it's done. If we do that, it becomes OK to hijack primary motion commands until the selection is made. In effect the buffer should be unavailable during the selection. SM> But I'm not completely sure whether the minibuffer completion UI has to be SM> identical to the in-buffer completion UI. Of course, it's good for them SM> to be identical, all things being equal, but: things like company-mode don't SM> work well in the minibuffer, whereas the separate *Completions* buffer SM> actually works OK in that case (whereas it's much more problematic for SM> in-buffer completion where the *Completions* buffer may be fairly far SM> from point). I understand. I think an abstract popup facility would work in either case, especially if it "locks in" the user as described above. But if something must be improved, it's the in-buffer completion UI IMO. >> The most important thing IMO is to avoid making a new buffer that >> requires `C-x o' and magical bindings. SM> My suggestion is to keep the separate buffer but let the user interact SM> with it without needing to switch to it via C-x o or some such action. SM> That seems doable without too much trouble in the current setup. If we SM> want to avoid the separate buffer altogether, then we're in SM> auto-complete/company-mode territory, which won't happen for 24.4. OK, let's pursue that path for 24.4 and then see if a more radical library or API can be used later. I see the following 24.4 tasks so far: - improve *Completions* buffer highlighting - decide on "locking in" users during candidate selection (so more natural keybindings can be used) or stealing just a few keybindings temporarily - improve minibuffer candidate selection UI keys (depends on "lock in" decision) - improve in-buffer candidate selection UI keys (depends on "lock in" decision) Does that sound reasonable? Ted