From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#2957: 23.0.92; ucs-insert: Completion does not work correctly with Unicode Character Name Input Date: Sat, 11 Apr 2009 09:57:36 -0400 Message-ID: References: Reply-To: Stefan Monnier , 2957@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1239459869 16415 80.91.229.12 (11 Apr 2009 14:24:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Apr 2009 14:24:29 +0000 (UTC) Cc: Ashutosh Mehra , 2957@emacsbugs.donarmstrong.com To: Andreas Schwab Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 11 16:25:48 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Lse9M-0006t5-6P for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Apr 2009 16:25:40 +0200 Original-Received: from localhost ([127.0.0.1]:56958 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lse7x-0004TP-Of for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Apr 2009 10:24:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lse7i-0004NW-CV for bug-gnu-emacs@gnu.org; Sat, 11 Apr 2009 10:23:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lse7d-0004L7-MF for bug-gnu-emacs@gnu.org; Sat, 11 Apr 2009 10:23:57 -0400 Original-Received: from [199.232.76.173] (port=34787 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lse7d-0004Ky-6i for bug-gnu-emacs@gnu.org; Sat, 11 Apr 2009 10:23:53 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:55138) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lse7c-0004RF-4n for bug-gnu-emacs@gnu.org; Sat, 11 Apr 2009 10:23:52 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3BENnOI012999; Sat, 11 Apr 2009 07:23:50 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n3BE56SB008367; Sat, 11 Apr 2009 07:05:06 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 11 Apr 2009 14:05:06 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 2957 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 2957-submit@emacsbugs.donarmstrong.com id=B2957.12394582666146 (code B ref 2957); Sat, 11 Apr 2009 14:05:06 +0000 Original-Received: (at 2957) by emacsbugs.donarmstrong.com; 11 Apr 2009 13:57:46 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3BDvgIi006140 for <2957@emacsbugs.donarmstrong.com>; Sat, 11 Apr 2009 06:57:44 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcFAJU+4ElLd+7D/2dsb2JhbACBUcgeg3wGhRU X-IronPort-AV: E=Sophos;i="4.40,171,1238990400"; d="scan'208";a="36898709" Original-Received: from 75-119-238-195.dsl.teksavvy.com (HELO pastel.home) ([75.119.238.195]) by ironport2-out.teksavvy.com with ESMTP; 11 Apr 2009 09:57:36 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A664E83B6; Sat, 11 Apr 2009 09:57:36 -0400 (EDT) In-Reply-To: (Andreas Schwab's message of "Sat, 11 Apr 2009 11:41:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Sat, 11 Apr 2009 10:23:57 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:27078 Archived-At: >> BUG DESCRIPTION: >> When I type the following: >> C-x 8 RET greek letter alpha >> and press TAB, I get several choices for the greek letter alpha >> variants. But I'm unable to type anything into the minibuffer (neither >> SPC nor any character) -- Emacs just doesn't accept the input. I understand that SPC would signal an error, but any normal character should be inserted in the minibuffer just fine. Do you really mean that you can't type anything in the minibuffer, or just that anything you type will later lead to a completion failure or to the error you mention: >> If I press RET at this point, I get the error message "ucs-insert: >> Not a Unicode character code: nil". That looks like a (minor) bug indeed. > This is a problem with partial-completion. > (completing-read "Type a SPC b TAB: " > '("a 1 b" "a 1 b c" "a 1 b d" "a 2 b" "a 2 b c" "a 2 b d")) > The minibuffer contents become "a SPC SPC b", indicating that a word is > missing between "a" and "b". Either partial-completion should move > point back to where the word is missing or accept SPC as input. Actually, it's a problem with minibuffer-complete-word which sometimes wants partial completion and sometimes doesn't. The patch below provides an alternative way to choose between using partial-completion and not, which is finer-grained and should fix the above problem without reintroducing the problems it tried to fix, Stefan === modified file 'lisp/minibuffer.el' --- lisp/minibuffer.el 2009-03-19 04:24:15 +0000 +++ lisp/minibuffer.el 2009-04-11 13:51:07 +0000 @@ -780,13 +780,13 @@ ;; If completion finds next char not unique, ;; consider adding a space or a hyphen. (when (= (length string) (length (car comp))) - (let ((exts '(" " "-")) + ;; Mark the added char with the `completion-word' property, so it + ;; can be handled specially by completion styles such as + ;; partial-completion. + (let ((exts (mapcar (lambda (str) (propertize str 'completion-word t)) + '(" " "-"))) (before (substring string 0 point)) (after (substring string point)) - ;; Disable partial-completion for this. - (completion-styles - (or (remove 'partial-completion completion-styles) - completion-styles)) tem) (while (and exts (not (consp tem))) (setq tem (completion-try-completion @@ -1598,7 +1598,13 @@ (p 0) (p0 p)) - (while (setq p (string-match completion-pcm--delim-wild-regex string p)) + (while (and (setq p (string-match completion-pcm--delim-wild-regex + string p)) + ;; If the char was added by minibuffer-complete-word, then + ;; don't treat it as a delimiter, otherwise "M-x SPC" + ;; ends up inserting a "-" rather than listing + ;; all completions. + (not (get-text-property p 'completion-word string))) ;; Usually, completion-pcm--delim-wild-regex matches a delimiter, ;; meaning that something can be added *before* it, but it can also ;; match a prefix and postfix, in which case something can be added