From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Who uses Icomplete-mode? Re: [Emacs-diffs] master b0e318d 2/2: Score flex-style completions according to match tightness Date: Mon, 18 Mar 2019 12:44:05 -0400 Message-ID: References: <20190213212413.868.40960@vcs0.savannah.gnu.org> <20190213212415.148B9209D7@vcs0.savannah.gnu.org> <0ba3ca47-c7d6-a608-536e-94784ba3384b@yandex.ru> <4f4e9ccd-b152-2b37-cad2-6c96b0a64d84@yandex.ru> <646c8d35-89a7-b12f-8a78-b05e6d8f781c@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="2055"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 18 18:43:10 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h5wI0-0000Od-VU for ged-emacs-devel@m.gmane.org; Mon, 18 Mar 2019 18:43:09 +0100 Original-Received: from localhost ([127.0.0.1]:45155 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5wHz-0005TJ-Sg for ged-emacs-devel@m.gmane.org; Mon, 18 Mar 2019 13:43:07 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5wB4-0000VW-Eh for emacs-devel@gnu.org; Mon, 18 Mar 2019 13:35:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5wB3-0000mN-BR for emacs-devel@gnu.org; Mon, 18 Mar 2019 13:35:58 -0400 Original-Received: from [195.159.176.226] (port=57598 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h5wB2-0000hm-Rg for emacs-devel@gnu.org; Mon, 18 Mar 2019 13:35:57 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1h5vN6-0015ii-3q for emacs-devel@gnu.org; Mon, 18 Mar 2019 17:44:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:gdicVTxZf6IzZtvg3NV4re6p8bY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:234335 Archived-At: > Which brings me to a question I've been meaning to ask: who > here uses Icomplete-mode and just how attached are you to its > interface? I don't use it all the time, but I often like to use it. > - A less cryptic left side hint as to what the "current" matched > thing is (in ido.el it's pretty obvious, in icomplete.el not so much) Not sure what you mean by that > - A way to have RET exit the minibuffer with the current thing, (define-key icomplete-minibuffer-map [?\C-m] 'icomplete-force-complete-and-exit) should do the trick. > except when finding files, where it should just enter the directory This is the one "feature" of Ido which drove me completely mad. I might have gotten used to some of the other parts of the Ido UI but this one just makes no sense to me: I much prefer typing / than RET to enter the directory (and with partial-completion style this works nicely). > (though there should always be a binding for exiting the minibuffer > with whatever the current input is). (define-key icomplete-minibuffer-map [?\C-j] 'exit-minibuffer) ? > - A way to delete buffers and kill files effectively without leaving > the minibuffer prompt. Hmm... I thought you coded this up already, but I don't see it in icomplete.el. Did I dream it? This is sliding towards Helm territory and is difficult to provide in a clean generic way (icomplete-mode is supposed to work for all completions), but it might make sense to offer "category-specific" key bindings and commands, yes. > - Eliminate the need for icomplete-compute-delay, using while-no-input > or maybe threads. Looks like you have your work cut out ! > Some of these can be achieved through customization, and some > would probably need more work. Moreover, if there aren't a lot of > people overly attached to the current interface, we could choose > some new defaults. I like the fact that the key-bindings are pretty much the same with and without icomplete, so I'm not looking forward to changing the default RET binding in icomplete-mode. But that's my opinion as icomplete user, so if I'm in the minority I can live with it. > Otherwise, I'd propose a new icomplete-ido-emulation-mode with > some less horrible name. That might actually be a good approach (especially if it's built as just "icomplete-mode with different defaults" so the new features can also be used from icomplete-mode modulo simple customizations), also because it will be new and so could attract new users more effectively than "icomplete-mode has slightly different default behavior". Stefan