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 12:50:38 -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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1384883456 16642 80.91.229.3 (19 Nov 2013 17:50:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Nov 2013 17:50:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 19 18:51:01 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 1VipRy-0000fq-0p for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2013 18:50:58 +0100 Original-Received: from localhost ([::1]:50849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VipRx-0001dD-Lc for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2013 12:50:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VipRn-0001TP-2m for emacs-devel@gnu.org; Tue, 19 Nov 2013 12:50:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VipRf-0008AL-PD for emacs-devel@gnu.org; Tue, 19 Nov 2013 12:50:47 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:15216) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VipRf-0008AG-GI for emacs-devel@gnu.org; Tue, 19 Nov 2013 12:50:39 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+KWN/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBrEfkA6NYYMpA4hhnBmBXoMV X-IPAS-Result: Av4EABK/CFHO+KWN/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBrEfkA6NYYMpA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="38637361" 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 12:50:38 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 218AC60120; Tue, 19 Nov 2013 12:50:38 -0500 (EST) In-Reply-To: <87y54ke8v3.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Tue, 19 Nov 2013 09:58:40 -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.182 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:165394 Archived-At: > > proportional fonts? > If having fundamental incompatibilities with some modes of operation is the > worst problem we have, I'd say that's pretty good. I do think it's pretty good, indeed. But these problems are serious enough to be a reason not to enable it by default (tho, it's not the only reason, obviously). Note that the new rectangle highlighting suffers from the same problem ;-) But there I have the excuse that "the highlighting just reflects what C-x r k does, so it's weird but it's not the highlighting's fault". DG> In graphical mode, I think we can make a more reliable popup by DG> adapting some code in `tooltip.el'. That would be incompatible with DG> running in terminal, but there are no proportional fonts in terminal DG> either (I think...?) Sounds good. > Works for me, as long as it's standard (so we don't have the current > "reinvention of the wheel" everywhere). Good point. > Sounds good. For usability, it may be better to lock users into the > mode until they press `RET' or `C-g' or `ESC' (as expected). The popup I see in Firefox lets me "keep on typing" without having to hit C-g/ESC or any such thing. 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. Another TAB currently means "scroll the *Completions* buffer". I'm not sure if we want to get rid of that feature. I personally never use "up" and prefer M-p for that. So I tend to think it's OK to hijack `up' and `down' to enter the *completions* when it is displayed (tho I think the way this new mode should work, it should not switch to the *Completions* window, but instead just change key-bindings in the minibuffer to highlight/select an entry in *Completions*). > Do you think this can realistically happen for 24.4? I would be excited > to help test and give feedback, and maybe even help with the code. The freeze is planned for mid-december so there's no much time. OTOH it might not take that much time to write either. Stefan