From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Tue, 19 Nov 2013 19:28:28 -0500 Message-ID: References: <87fvqtg02v.fsf@flea.lifelogs.com> <877gc5fm30.fsf@flea.lifelogs.com> <87k3g47m7b.fsf@yandex.ru> <528B6F11.7070607@yandex.ru> <87y54ke8v3.fsf@flea.lifelogs.com> <87li0kdrsz.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1384907325 3811 80.91.229.3 (20 Nov 2013 00:28:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Nov 2013 00:28:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 20 01:28: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 1Vivey-0006Cd-OE for ged-emacs-devel@m.gmane.org; Wed, 20 Nov 2013 01:28:48 +0100 Original-Received: from localhost ([::1]:52219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vivey-000695-2O for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2013 19:28:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Viven-00068t-QU for emacs-devel@gnu.org; Tue, 19 Nov 2013 19:28:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Viveg-0004Hb-HJ for emacs-devel@gnu.org; Tue, 19 Nov 2013 19:28:37 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:22074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Viveg-0004HX-DA for emacs-devel@gnu.org; Tue, 19 Nov 2013 19:28:30 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+KWN/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBrEfkA6NYYMpA4hhnBmBXoMVgUgk X-IPAS-Result: Av4EABK/CFHO+KWN/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBrEfkA6NYYMpA4hhnBmBXoMVgUgk X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="38674891" Original-Received: from 206-248-165-141.dsl.teksavvy.com (HELO pastel.home) ([206.248.165.141]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 19 Nov 2013 19:28:29 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id EAC3260424; Tue, 19 Nov 2013 19:28:28 -0500 (EST) In-Reply-To: <87li0kdrsz.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Tue, 19 Nov 2013 16:07:08 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:165408 Archived-At: > Agreed, although then the *Completions* buffer should at least get > better highlighting. Not sure what you want here. AFAIK the only thing missing is to highlight the selected entry (which is already done when selecting with the mouse, but not when selecting with the keyboard). 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. Once you're in that mode, we can use any number of key-bindings, there's no problem there. The issue is how to let the use *enter* that mode, where `up' or `down' can be used in the minibuffer, but maybe not for in-buffer completion. Once we're in that mode, up, down, and pretty much anything else can be hijacked just fine. > - decide on "locking in" users during candidate selection (so more > natural keybindings can be used) or stealing just a few keybindings > temporarily "just a few" can be many keybindings. My preference is simply to let the user exit that mode "seamlessly" without having to use a special exit key-binding. But that doesn't mean that we should feel restricted in which keys can be used in that special mode. > Does that sound reasonable? Yes. Stefan