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: Tue, 27 Sep 2011 10:45:09 -0700 Message-ID: References: <87oby720v7.fsf@escher.home> 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 1317145584 1974 80.91.229.12 (27 Sep 2011 17:46:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2011 17:46:24 +0000 (UTC) Cc: rms@gnu.org, 9591@debbugs.gnu.org To: "'Eli Zaretskii'" , "'Stephen Berman'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 27 19:46:19 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 1R8bjW-0000qa-RQ for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Sep 2011 19:46:19 +0200 Original-Received: from localhost ([::1]:49200 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8bjW-0007tx-9D for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Sep 2011 13:46:18 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58814) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8bjS-0007sP-56 for bug-gnu-emacs@gnu.org; Tue, 27 Sep 2011 13:46:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8bjQ-0001dx-OF for bug-gnu-emacs@gnu.org; Tue, 27 Sep 2011 13:46:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8bjQ-0001dn-Mh for bug-gnu-emacs@gnu.org; Tue, 27 Sep 2011 13:46:12 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R8bkE-0004pH-Eu for bug-gnu-emacs@gnu.org; Tue, 27 Sep 2011 13: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: Tue, 27 Sep 2011 17: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.131714557118454 (code B ref 9591); Tue, 27 Sep 2011 17:47:02 +0000 Original-Received: (at 9591) by debbugs.gnu.org; 27 Sep 2011 17:46:11 +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 1R8bjP-0004nb-J5 for submit@debbugs.gnu.org; Tue, 27 Sep 2011 13:46:11 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R8bjN-0004nT-LU for 9591@debbugs.gnu.org; Tue, 27 Sep 2011 13:46:10 -0400 Original-Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8RHjGVv005134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Sep 2011 17:45:18 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8RHjG2q011246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Sep 2011 17:45:16 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8RHjAOG003490; Tue, 27 Sep 2011 12:45:10 -0500 Original-Received: from dradamslap1 (/10.159.55.150) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Sep 2011 10:45:10 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acx8KF+F9BpiHO+lQfeuTMCaePvltQBDatJQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090208.4E820BAE.0128,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 27 Sep 2011 13: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:51929 Archived-At: > I find arguments about defaults a waste of time. Echoes of those who claim political discourse and politics in general are a waste of time... 1. This thing about user surprise/confusion and lack of control is very much about the default behavior. Someone who explicitly chooses something like partial completion presumably knows what s?he's in for. Not necessarily so, someone using the default settings. You might not like discussing defaults (who does?), or you might think that doing so is a waste of time (sometimes it is), but arguing against discussing what the default behavior should be is simply an argument defending the status quo without giving any reason. This is a very old story... > I customized completion-category-overrides to nil and > completion-styles to `(emacs22), and the result is the > kind of completion that Richard wanted and expected. 2. That a given user such as Richard can customize away the default automatic chaining of completion methods is not the point. The question (I raise) is whether the default behavior should be to chain methods together. This was a *big* change in default behavior, beyond just the differences provided by any of the individual fancy matching methods (e.g. partial completion matching). It was hardly discussed (discussion was more or less discouraged, IMO). 3. My point in mentioning a user-controlled, on-demand approach (as, e.g., in Icicles) is that: 3a. Users can still define the list of methods to try - exactly as is the case now in Emacs (e.g. `completion-styles'). 3b. Users can have Emacs *not* automatically chain these methods together. They can have Emacs use only the first (or perhaps the last-used) method, by default. 3c. Users can nevertheless switch to the next method in the list - on demand. 4. We could also let an individual item in the methods list (`completion-styles') be itself a list of methods, as an alternative to a single method. When such a list item is chosen, its methods *would* be chained together automatically. IOW, let users decide whether and how much to use automatic chaining. In sum: A. Pick as the default behavior a single, simple/basic completion method, one with few surprises. B. Let users, as now, customize the list of available methods. C. Let users switch to the next method in their list on demand, by hitting a key. D. Let users choose (opt in) to have Emacs automatically chain among some methods, by using a list of those methods as an entry of the methods-list option (`completion-styles'). For example (`completion-styles' values): (basic emacs22 partial-completion) would you give basic completion by default, and let you cycle to Emacs 22 completion on demand (only), and then to partial completion and then back to basic..., by hitting a key in the minibuffer. ((basic partial-completion emacs22)) would give you the current, automatic-chaining behavior by default, and would not provide for any alternative (no other entry to cycle to, manually) (basic (basic partial-completion emacs22)) would give you basic completion by default, and would let you switch to the current default behavior of automatic chaining among basic, partial, and emacs22 on demand. And so on. Such an approach would give users control and flexibility. They could choose whether and when switching between methods should be on-demand vs automatic. But the important thing is for us to choose the default behavior wisely. IMO, the default should *not* use chaining and should probably not be partial completion. Avoiding these would present users with fewer surprises and gotchas, but they could still get all the bells and whistles available now - and more - if they want. P.S. As for polling the users, Richard said almost 3 years ago that they should be polled for this: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1757#40