From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: all-completions DTWT for "" and non-nil HIDE-SPACES Date: Fri, 12 May 2006 17:26:51 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1147480040 13646 80.91.229.2 (13 May 2006 00:27:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 13 May 2006 00:27:20 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 13 02:27:16 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FehyS-0005Wa-1m for ged-emacs-devel@m.gmane.org; Sat, 13 May 2006 02:27:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FehyR-0000Kg-Gt for ged-emacs-devel@m.gmane.org; Fri, 12 May 2006 20:27:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FehyD-0000Id-5l for emacs-devel@gnu.org; Fri, 12 May 2006 20:26:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FehyC-0000IR-Hq for emacs-devel@gnu.org; Fri, 12 May 2006 20:26:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FehyC-0000IO-CP for emacs-devel@gnu.org; Fri, 12 May 2006 20:26:56 -0400 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1Fei02-0001kp-RD for emacs-devel@gnu.org; Fri, 12 May 2006 20:28:51 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k4D0Qs9d021245 for ; Fri, 12 May 2006 18:26:54 -0600 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-74-209.vpn.oracle.com [141.144.74.209]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k4D0QrUG000682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 12 May 2006 18:26:53 -0600 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:54353 Archived-At: > The doc string for all-completions says that if the first arg > doesn't start with a space then a non-nil 4th arg means ignore > candidates that start with a space. "Start with a space" means > that the first character is a space. > This is undefined (ambiguous) if the string has no first > character (doesn't start at all; is empty). I don't follow. An empty string clearly does not start with a space. What does it start with? All of the alligators on the moon are red. True or false? Every character that the empty string starts with is a space, no? Or is every such character a non-space? or a balloon? To me, "start with a space" doesn't mean much for a string that does not start at all. If it has no first character, then it doesn't start with either a space or a non-space. The real question, however, is what the `all-completions' functionality should be for an empty string. If the first character of a string determines some behavior, and the string can be empty, then the empty-string behavior needs also to be defined (and documented). That is, it needs to be defined separately from the first-character behavior - they are disjoint cases. > I think the functionality should be changed I don't agree. That would change the behaviour of buffer completions: If you type TAB in the empty minibuffer when being prompted for a buffer you don't want buffers starting with a space in the list of completions. That's true, but TAB is not bound to `all-completions'. I want to fix `all-completions'; I don't want to change minibuffer completion. What you correctly point out is that I was wrong in my assumption that no existing code depends on this (bugged, IMO) behavior. A quick look at the C code tells me that `all-completions' is used only once (by Fminibuffer_completion_help), and then only with a non-nil value for HIDE-SPACES. I could be wrong (I don't speak C well), but I think I'm right. IOW, the C code does not use the possibility of providing different values for HIDE-SPACES at all. The definition of `all-completion' wrt HIDE-SPACES should not depend on a single use of it. If that were to be the case, then we might as well eliminate the HIDE-SPACES argument and always give it the non-nil behavior. `all-completions' is supposed to be more general than that. If we make the fix to `all-completions' that I propose, then, yes, Fminibuffer_completion_help would need to be redefined to not simply call all-completions with a non-nil HIDE-SPACES arg. It would itself need to treat "" so as to avoid completions that start with a space. That behavior is part of _its_ logic, not part of `all-completions' logic. IOW, I'm suggesting that `all-completions' should return all of the completions (including those that start with space) when given "", but Fminibuffer_completion_help (hence also `minibuffer-complete', and `minibuffer-complete-word', which call Fminibuffer_completion_help) should keep the behavior it has now. It just wouldn't be able to rely on providing a non-nil HIDE-SPACES to `all-completions' - it would have to treat the "" case itself since it doesn't want all completions in the case of no typed input. My concern is using `all-completions' from Lisp. The unique use of `all-completions' in the C code could be made to work with the fix I suggested. Since I was wrong about C code depending on the current behavior, perhaps I'm also wrong about Lisp code depending on it. The fix would require first checking all calls to `all-completions' that provide an explicit HIDE-SPACES arg. I just spent a few minutes doing that, and guess what? (drum roll...) I found zero (0) uses of an explicit HIDE-SPACES arg! The only place I found this used anywhere in the Emacs code is in the C code, and then only in a single call by Fminibuffer_completion_help. `all-completions' should be for Lisp programmers, not just for Fminibuffer_completion_help. The (all-completions "" ...) idiom should DTRT: return _all_ completions. I don't see any reason not to fix this now.