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: completion-auto-help Date: Thu, 10 Nov 2005 17:30:56 -0800 Message-ID: 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 1131672727 8371 80.91.229.2 (11 Nov 2005 01:32:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 Nov 2005 01:32:07 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 11 02:32:06 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EaNl9-0001Uz-Kj for ged-emacs-devel@m.gmane.org; Fri, 11 Nov 2005 02:31:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EaNl8-00009Z-NG for ged-emacs-devel@m.gmane.org; Thu, 10 Nov 2005 20:31:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EaNkx-00009K-JJ for emacs-devel@gnu.org; Thu, 10 Nov 2005 20:31:07 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EaNkw-000097-27 for emacs-devel@gnu.org; Thu, 10 Nov 2005 20:31:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EaNkv-000094-Vt for emacs-devel@gnu.org; Thu, 10 Nov 2005 20:31:06 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EaNkv-0000oG-Rv for emacs-devel@gnu.org; Thu, 10 Nov 2005 20:31:06 -0500 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 jAB1V3O9028653 for ; Thu, 10 Nov 2005 18:31:03 -0700 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAB1V2Ke013932 for ; Thu, 10 Nov 2005 18:31:02 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jAB1V2K6013925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 10 Nov 2005 18:31:02 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= 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:45713 Archived-At: 1. Question: The doc string for `completion-auto-help' says this: Non-nil means automatically provide help for invalid completion input. The Elisp manual says this about it: If this variable is non-`nil', the completion commands automatically display a list of possible completions whenever nothing can be completed because the next character is not uniquely determined. In neither case are different non-nil values distinguished. So, I don't understand this code in complete.el: (if (or (eq completion-auto-help t) (and completion-auto-help (eq last-command this-command)) (eq mode 'help)) The second arg to `or' can only be evaluated if `completion-auto-help' is not `t', and that second arg tests whether it is non-nil. Am I missing something - is there some special treatment somewhere for non-nil, non-t value? (That's what the second arg seems to be doing.) I see no other occurrences of `completion-auto-help' anywhere in the Lisp code that distinguish different non-nil values. 2. New feature proposal - How about allowing for an "always-display-*Completions*' behavior: - t means what it means now - nil means what it means now - other means this: Display *Completions* right from the beginning (empty minibuffer input). Display it as long as the minibuffer contents match more than one completion. IOW, with this value, the user would not need to hit `TAB' to display *Completions*. (S)he would see the list of completions whenever there are more than one. There is currently no way to make `completing-read', `read-file-name' etc. display *Completions* from the outset.