From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs,gmane.emacs.pretest.bugs Subject: bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion Date: Sat, 13 Dec 2008 08:00:22 -0800 Message-ID: <004a01c95d3b$e8485d40$0200a8c0@us.oracle.com> References: <000c01c958d3$1aa53c30$0200a8c0@us.oracle.com><008701c95a6b$8be12b40$0200a8c0@us.oracle.com><001401c95caf$9f0cacd0$0200a8c0@us.oracle.com> Reply-To: Drew Adams , 1512@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1229185485 9915 80.91.229.12 (13 Dec 2008 16:24:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Dec 2008 16:24:45 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, 1512@emacsbugs.donarmstrong.com To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 13 17:25:48 2008 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 1LBXJJ-0004MR-Gf for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Dec 2008 17:25:46 +0100 Original-Received: from localhost ([127.0.0.1]:45666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBXI6-0007Ep-Jr for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Dec 2008 11:24:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBXI0-0007DU-J3 for bug-gnu-emacs@gnu.org; Sat, 13 Dec 2008 11:24:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBXHy-0007Cs-01 for bug-gnu-emacs@gnu.org; Sat, 13 Dec 2008 11:24:24 -0500 Original-Received: from [199.232.76.173] (port=32982 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBXHx-0007Cn-JY for bug-gnu-emacs@gnu.org; Sat, 13 Dec 2008 11:24:21 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:36164) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LBXHx-0002Sf-0j for bug-gnu-emacs@gnu.org; Sat, 13 Dec 2008 11:24:21 -0500 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 mBDGOIW1009971; Sat, 13 Dec 2008 08:24:19 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id mBDGA4OD005957; Sat, 13 Dec 2008 08:10:04 -0800 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 13 Dec 2008 16:10:04 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 1512 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by submit@emacsbugs.donarmstrong.com id=B.12291840453581 (code B ref -1); Sat, 13 Dec 2008 16:10:04 +0000 X-Spam-Bayes: score:0.0000 Tokens: new, 6; hammy, 151; neutral, 209; spammy, 0. spammytokens: hammytokens:0.000-+--emacs, 0.000-+--23.0.60, 0.000-+--23060, 0.000-+--Emacs, 0.000-+--UD:el Original-Received: (at submit) by emacsbugs.donarmstrong.com; 13 Dec 2008 16:00:45 +0000 Original-Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mBDG0fue003568 for ; Sat, 13 Dec 2008 08:00:43 -0800 Original-Received: from mail.gnu.org ([199.232.76.166]:50813 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LBWuO-0004Bk-O0 for emacs-pretest-bug@gnu.org; Sat, 13 Dec 2008 11:00:00 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LBWv0-00087y-8z for emacs-pretest-bug@gnu.org; Sat, 13 Dec 2008 11:00:40 -0500 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:32917) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LBWuz-00087f-Ri for emacs-pretest-bug@gnu.org; Sat, 13 Dec 2008 11:00:38 -0500 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mBDG1RO4006288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Dec 2008 16:01:28 GMT Original-Received: from acsmt706.oracle.com (acsmt706.oracle.com [141.146.40.84]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mBDG0SoT019395; Sat, 13 Dec 2008 16:00:30 GMT Original-Received: from dradamslap1 (/141.144.80.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 13 Dec 2008 08:00:18 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aclc8Dp9z9so6h4KQnS5xCayFNQG5AARZ8NQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt706.oracle.com [141.146.40.84] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4943DC16.0148:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-CrossAssassin-Score: 2 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Sat, 13 Dec 2008 11:24:24 -0500 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:23265 gmane.emacs.pretest.bugs:23497 Archived-At: > I probably spent more time on word-completion than on pretty much any > other part of minibuffer.el, so believe me I've thought about what is > word completion and my understanding of it is embedded in the current > behavior (which is very similar to partial-completion-mode's > behavior). Yes, I was sure you were aware of what "word completion" means (has always meant in Emacs). > I really honestly do not understand how you want to interpret > the above "definition" of word completion in the context of > partial completion. Why "in the context of partial completion"? Emacs word completion is not (has never been) partial completion. That's the point. Emacs word completion (SPC), just like Emacs prefix completion (TAB) has always had, as part of its behavior, the display of a [No match] message when it cannot complete a word at a time or cannot complete a prefix. That's part of what word and prefix completion mean. The same is true for any particular kind of completion: failure to complete using that completion method informs you with a message such as [No match]. It is that which you have removed from the default behavior, by automatically chaining, beyond failure of word and prefix completion, to use partial completion. Reporting a failed word or prefix completion is (has always been) part of the behavior of SPC and TAB. The negative feedback that there are no such completions (word or prefix) is helpful. It lets you correct typos on the fly, as indicated by the examples I gave. The bug report was about both word (SPC) and prefix (TAB) completion, with examples for each. In your mails you consistently ignore TAB and dwell only on word completion. I've addressed both in each of my mails, but you keep dropping TAB. This is not about "interpreting" what "word completion" might mean for Emacs 23. This is about restoring what you call `basic' completion as the default behavior - that is, restoring the pre-Emacs 23 behavior as the default. That means restore it for TAB as well as for SPC. > There are many different ways to interpret it, probably. I'm not looking for new interpretations of "word completion" or its Info description. I'm not looking for new ways that the existing text might mean something different "in the context of partial completion". You take word completion, mix in partial completion, and then ask me about the Info text that described (and still describes) only word completion - asking what it means when partial completion gets mixed in. It was never intended to mean anything "in the context of partial completion". I'm asking you to take partial completion out of the default behavior - to restore the traditional behavior by default. That should be perfectly clear from each of the mails I've sent on this. Pretending to not understand that strains credulity. > But none of them seem to match the behavior you seem to want in > your example. My examples are nothing exotic, and the behavior I "seem to want" as the default behavior for Emacs 23 is simply the behavior of Emacs (20, 21, 22). No automatic fallback to partial completion when basic completion fails. I've made that clear; please stop pretending that you don't hear or understand that. The request is simple: restore the default behavior to the behavior Emacs has always had. > So unless you explain to me what behavior you generally expect > (at least with more examples), The behavior I expect as the default behavior is the behavior that everyone expects: the behavior that Emacs has always had: fail with [No match] when there is no word completion (for SPC) or no prefix completion (for TAB). Do not automatically try, after such completion failure, to use partial completion. > the only answer I can give you is "your word completion seem to > dislike partial completion, "Your word completion"? I don't have my own word completion. _Emacs_ word completion is not partial completion. Never has been. You've taken something that was optional and mixed it in with classic (`basic') behavior, changing the default completion behavior to basic-or-if-that-fails-then-partial. If you claim that that is still somehow "word completion", then it is "your word completion". It is certainly not the word completion that Emacs has always known, and which the manual (still) describes. > so you'll need to disable partial completion", which your > report said you did not consider as a good answer. It's not about my own use. I don't often use vanilla Emacs completion anyway, for my own use (I use Icicles). I'm concerned about vanilla Emacs (-Q), not my use of Emacs. I'm concerned that you have changed the default completion behavior radically, taking something that was optional for a long time (most likely with relatively few users) and making it the default. Just please remove `partial-completion' from the defcustom for `completion-styles'. Normal Emacs behavior will then be restored as the default behavior, and any users who truly want the basic-or-if-that-fails-then-partial completion behavior can customize the option value to (basic partial-completion) to get what they want.