From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#19474: 24.4; icomplete fails to insert character with C-x 8 Date: Tue, 12 Jan 2016 21:39:26 -0800 (PST) Message-ID: <6750b845-f8d2-4418-b98c-e1f3d17a7911@default> References: <87mvsa9jz1.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1452663627 6705 80.91.229.3 (13 Jan 2016 05:40:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jan 2016 05:40:27 +0000 (UTC) Cc: 19474@debbugs.gnu.org To: Alexis , Eric Hanchrow Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 13 06:40:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1aJEAF-0008My-Gx for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Jan 2016 06:40:11 +0100 Original-Received: from localhost ([::1]:35407 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJEAE-0007rj-OO for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Jan 2016 00:40:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJEAA-0007rd-TC for bug-gnu-emacs@gnu.org; Wed, 13 Jan 2016 00:40:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJEA6-0006P7-Pk for bug-gnu-emacs@gnu.org; Wed, 13 Jan 2016 00:40:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59509) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJEA6-0006Op-Ll for bug-gnu-emacs@gnu.org; Wed, 13 Jan 2016 00:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aJEA6-0000xu-Eu for bug-gnu-emacs@gnu.org; Wed, 13 Jan 2016 00:40:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Jan 2016 05:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19474 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19474-submit@debbugs.gnu.org id=B19474.14526635783676 (code B ref 19474); Wed, 13 Jan 2016 05:40:02 +0000 Original-Received: (at 19474) by debbugs.gnu.org; 13 Jan 2016 05:39:38 +0000 Original-Received: from localhost ([127.0.0.1]:47728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJE9i-0000xE-7e for submit@debbugs.gnu.org; Wed, 13 Jan 2016 00:39:38 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:22574) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJE9f-0000wx-Rt for 19474@debbugs.gnu.org; Wed, 13 Jan 2016 00:39:36 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0D5dTp4010880 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 05:39:29 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u0D5dSnF003776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 05:39:28 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u0D5dSfv017720; Wed, 13 Jan 2016 05:39:28 GMT In-Reply-To: <87mvsa9jz1.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:111574 Archived-At: > It seems to me that the issue here is that icomplete expects one > to accept completions via C-j (`minibuffer-force-complete-and-exit`) > rather than RET (which is bound to `minibuffer-exit`). Yes, exactly. > i myself find this behaviour > counterintuitive, and would prefer that RET also be bound to > `minibuffer-force-complete-and-exit`, since i would still be able > to exit the minibuffer via C-g. i wonder if there are people > relying on RET being bound to `minibuffer-exit`? Yes, there are. Icomplete's C-j does not have the same behavior as RET. If Icomplete treated RET the way it treats C-j then that would mean that you could never input anything that matched a completion candidate, without choosing that match. IOW, it would remove the possibility of lax completion. You could not, for example, use `C-x b' to create a new buffer `foo' if there were already a buffer `foobar' - typing `foo RET' would just choose `foobar'. IOW, even in Icomplete mode, RET is used normally in the minibuffer: it accepts the text typed so far or, if a match is required in order to exit and there is only one possible match, it accepts that match. C-j for Icomplete mode is used not to input what you have typed so far but to input the first of the available matches. IOW, it completes and then exits (similar to what `minibuffer-complete-and-exit' does). Completion for `C-x 8 RET' is lax - a match is not required. This is because you can enter something other than a match of one of the char names - you can enter a code point. E.g., you can type `1F4A9 RET' to get your pile of poo. The code point here is not a _match_ for the char name (and only char names are completion candidates - there is no _completion_ against code points). The code point is simply another acceptable input, and it has the same effect (inserts the same char). --- FWIW, if you were to do this in Icicles, with the default settings, you _could_ use RET, for this reason: With the default settings your input for `C-x 8 RET' can match any combination of parts of a 3-part multi-completion: char name, code point, and the char itself. (You can complete the name or the code point, or both. And you can alternatively type the code point or the char to see what the name is.) And with the default settings, if your input matches only a char name or a code point, and if there is only one match, then that char is inserted. (Again, you can complete against the name, the code point, or the char itself, or any combination of these parts.) (If option `icicle-read-char-by-name-multi-completion-flag' is nil, which is not the default value, then the behavior is similar to vanilla Emacs,except that you get Icicles matching against the char name.)