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 08:48:42 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <8738msfqo5.fsf@flea.lifelogs.com> References: <87fvqtg02v.fsf@flea.lifelogs.com> <877gc5fm30.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 1384868894 25439 80.91.229.3 (19 Nov 2013 13:48:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Nov 2013 13:48:14 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 19 14:48:19 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 1Vilf8-0002ZN-Tg for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2013 14:48:19 +0100 Original-Received: from localhost ([::1]:49308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vilf8-0005lk-DD for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2013 08:48:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vilf0-0005lH-CG for emacs-devel@gnu.org; Tue, 19 Nov 2013 08:48:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vilev-0003Wp-3T for emacs-devel@gnu.org; Tue, 19 Nov 2013 08:48:10 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:37303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vileu-0003Wk-Pe for emacs-devel@gnu.org; Tue, 19 Nov 2013 08:48:05 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vilet-0002Tg-V9 for emacs-devel@gnu.org; Tue, 19 Nov 2013 14:48:03 +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 14:48:03 +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 14:48:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 98 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:R5msrdga2Sevpyot28+oOsZfSLw= 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:165377 Archived-At: On Mon, 18 Nov 2013 19:43:04 -0500 Stefan Monnier wrote: SM> I've implemented a bridge between company-mode and SM> completion-at-point-functions ("company-capf"), and moved company-mode's SM> completion tables for Elisp into lisp-mode.el. But there needs SM> to be some further integration work to make sure company-mode works well SM> with existing completion-at-point-functions. SM> But it wouldn't be enabled by default, anyway. The default match selection UI is not easy or intuitive, so that's one problem. I think it can be improved with better key bindings and better formatting in the candidates buffer, but honestly any solution that pops up a whole new buffer is unusable today in 2013. Users are accustomed to at least some kind of selection popup like what company-mode provides. Today's GUI toolkits on all our graphical platforms certainly provide that functionality. 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. >> The completion system is fine. The selection of matches is the problem: >> 1) see a new buffer popup with minimal help text and no highlighting >> 2) left, right, up, down don't work >> 3) realize problem, switch to candidates buffer (mouse click or `C-x o') >> 4) select candidate you want, get popped in original buffer >> That's not simple! It's not intuitive either, forcing me to use the >> mouse unless I've read the manual node referenced above. >> An alternative UI doesn't have to be fancy or graphical, only allow me >> to select from among the candidates immediately, without switching >> buffers, using the intuitive keys. I hope that explains my request better. SM> Oh, that should be reasonably easy. Just add the corresponding SM> key-bindings in minibuffer-local-completion-map, mostly. The main issue SM> is to try and avoid clashing with existing bindings (since there are SM> 2 buffers at play: the minibuffer and the *Completions* buffer), and SM> without C-x o, you're still in the minibuffer where left/right should SM> still mean "cursor movement in the minibuffer". I think these new keybindings should be the default for everyone so yes, care is needed. I don't know the right keys to use. Remember you can also see the completion candidates buffer without the minibuffer, if you e.g. do `complete-symbol' in a buffer. So the minibuffer is not the only context. The most important thing IMO is to avoid making a new buffer that requires `C-x o' and magical bindings. On Tue, 19 Nov 2013 02:47:11 +0200 Juri Linkov wrote: JL> In modern UIs, auto-completion works such a way that after you type text JL> it pops up a drop-down menu with a list of candidates where you can JL> select one by using and arrow keys. JL> How this could map to Emacs? The first difference is that in Emacs JL> the text entry field (the minibuffer) is at the bottom of the screen, JL> so the drop-down menu should pop up upwards using the display-window JL> property `near-minibuffer' (this will display completions nicely aligned JL> with the contents of the minibuffer). JL> Another difficulty is that in the minibuffer and arrow keys JL> are bound to previous-history-element and next-history-element, JL> so they can't be used to select an element from the list of candidates. JL> One solution is to automatically display the list of completions JL> when the user starts typing in the minibuffer and allow and JL> to navigate the list of completions if the minibuffer contents is not empty. JL> Otherwise, and will browse the history. Note, as I mentioned above, that completion candidates can be presented outside the minibuffer context as well. JL> Since this is quite obtrusive change it might require special mode JL> much like ido-mode but closer to auto-completion provided by other JL> GUI applications. I would argue that company-mode has solved the problem to some extent, but I understand it's not a simple change. I hope you and Stefan and others have some idea of what needs to be done. I'm happy to assist but don't have the required knowledge of the internals to write code. On Tue, 19 Nov 2013 11:18:09 +0000 (UTC) Tom wrote: T> [Helm] could also be considered as a possible alternative completion UI. I use and love helm-mode, but it's not truly a completion UI, it's an action selection UI. It lacks context normally, meaning that I can call `help-mini' any time in any buffer and it will be consistent. That's why I didn't propose it, even though it's very useful on its own. The helm-mode code that narrows candidates and presents them in a nice categorized buffer could certainly be considered together with company-mode and the other completion UIs in existence. I don't know if it's usable in isolation from the rest of Helm. Ted