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#9591: 24.0.50; buffer name completion Date: Sun, 25 Sep 2011 11:45:05 -0700 Message-ID: References: <87r5356aqu.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1316976392 2437 80.91.229.12 (25 Sep 2011 18:46:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 25 Sep 2011 18:46:32 +0000 (UTC) Cc: 9591@debbugs.gnu.org To: , "'Lars Magne Ingebrigtsen'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 25 20:46:28 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R7tid-00076G-Kn for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Sep 2011 20:46:27 +0200 Original-Received: from localhost ([::1]:32888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7tid-0002pB-67 for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Sep 2011 14:46:27 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7tia-0002p6-Pn for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2011 14:46:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7tiZ-0001fj-St for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2011 14:46:24 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35913) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7tiZ-0001ff-Q7 for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2011 14:46:23 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R7tjC-00021i-4c for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2011 14:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Sep 2011 18:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9591 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9591-submit@debbugs.gnu.org id=B9591.13169763637713 (code B ref 9591); Sun, 25 Sep 2011 18:47:02 +0000 Original-Received: (at 9591) by debbugs.gnu.org; 25 Sep 2011 18:46:03 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R7tiE-00020D-Bm for submit@debbugs.gnu.org; Sun, 25 Sep 2011 14:46:02 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R7tiB-0001zw-Hv for 9591@debbugs.gnu.org; Sun, 25 Sep 2011 14:46:00 -0400 Original-Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8PIjHpg014273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 25 Sep 2011 18:45:19 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8PIjFPk013861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Sep 2011 18:45:16 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8PIj9WJ004065; Sun, 25 Sep 2011 13:45:09 -0500 Original-Received: from dradamslap1 (/10.159.36.251) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 25 Sep 2011 11:45:09 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: Acx7qY/ZS2Nt2UyaSu6Ab+uDPkicNAAAgWmg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A020204.4E7F76BF.015A,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 25 Sep 2011 14:47:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.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:51829 Archived-At: > Partial completion is too powerful. Perhaps some extension of the > builtin completion is desirable by default, but this is too much. 1+ It is not so much that it is too "powerful", but that it can lead to unexpected and wildly off-the-mark completion candidates (as you point out from time to time, apparently with new surprise each time). The other problem, which compounds this problem, is that multiple types of completion/matching are tried, one after the other, in hopes of finding candidates. The default list of matching types includes partial completion. When a whole set of completion types (including partial) is tried in sequence, the result can be even more disorienting than is the result of partial completion on its own. Instead of letting a user know that a given type of matching has come up with `[No match]', and thus letting the user decide what to do about that (e.g. try a different type of matching - or not), it automatically assumes that the user wants to complete the current input at all costs, so it blithely moves on to the next type of matching in the list... To me, it's an overly clever misfeature. The user has no control over this, other than customization of the list of matching types to be used automatically. Such a choice of matching method / completion style should not be just a customization-time option. Better would be to have only one kind of completion used at a time (no automatic sequencing), and let users hit a minibuffer key (i.e., on demand) to change to the next completion type. IOW, let users choose at completion time which completion style(s) to use, on demand. Each time they change methods they can complete anew and find out whether there are matches using that method. The info `[No match]' is often helpful to users. By silently skipping over match failures, quietly moving on to try other, entirely different types of matching, we do users a disservice. Better to give them feedback about match failures, and give them (dynamic) control over which matching mechanism to use at any time.