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: completion-auto-help Date: Fri, 11 Nov 2005 11:32:35 -0800 Message-ID: References: <87y83vngw6.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1131737612 25118 80.91.229.2 (11 Nov 2005 19:33:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 Nov 2005 19:33:32 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 11 20:33:24 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EaeeF-000761-Nx for ged-emacs-devel@m.gmane.org; Fri, 11 Nov 2005 20:33:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EaeeF-0004sJ-4f for ged-emacs-devel@m.gmane.org; Fri, 11 Nov 2005 14:33:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Eaedc-0004FS-8E for emacs-devel@gnu.org; Fri, 11 Nov 2005 14:32:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Eaedb-0004DI-35 for emacs-devel@gnu.org; Fri, 11 Nov 2005 14:32:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Eaeda-0004D6-VM for emacs-devel@gnu.org; Fri, 11 Nov 2005 14:32:38 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Eaeda-0005Fq-UI for emacs-devel@gnu.org; Fri, 11 Nov 2005 14:32:39 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jABJiBHJ001552 for ; Fri, 11 Nov 2005 13:44:11 -0600 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jABJWapb024974 for ; Fri, 11 Nov 2005 12:32:36 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jABJWanq024959 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 11 Nov 2005 12:32:36 -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) In-Reply-To: <87y83vngw6.fsf-monnier+emacs@gnu.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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:45766 Archived-At: > If it is only a user who sets such a value, then shouldn't the non-nil, > non-t behavior be documented for the user option? I don't see that, as I > mentioned. It's not documented, because there's no place to document it: completion-auto-help is part of the basic completion facilities, whereas the added behavior is only provided in complete.el which is a separate package. That doesn't sound right, somehow. Is the non-nil behavior you describe behavior provided only by complete.el? Or is it part of the basic completion facilities? If the latter, then the doc string should be changed to mention the non-nil, non-t case. If the former, then complete.el is changing the behavior of the general user option (instead of, for example, using a new user option). That's OK I guess, but it should document that - at the very least in the Commentary of the library. Better, would be for complete.el to update the doc string of `completion-auto-help', describing the complete.el-specific behavior. > I proposed `eager' _without_ the automatic update after each > keystroke, in order to allow that as an additional (separate) > option. I think that would be better. Some people (or some > functions) might like to display the list of candidates right > from the beginning, as a kind of menu, but prefer to update > it only upon demand (via `TAB'), not automatically at each > keystroke. Some people might find the automatic list updating > to be distracting (I find it very helpful, personally). I'd wait to see people complaint about one of the two behaviors before providing both. I'm complaining - see my second email on this. The ability to display *Completions* from the start would typically be used in situations where the number of candidates is not that large - in particular, where *Completions* is treated much as a menu. In that context, auto-update is not distracting, and can be very helpful. However, displaying a long list from the start, and updating it with every keystroke, can be distracting. You'll say, "Don't use `eager' in that case". But I don't think the use cases are so cut and dried. Automatic update is useful even without initial display. It means you need not keep hitting `TAB' to see what the candidates are. Initial display is likely to be useful even without automatic update (but I don't have a great use case here). > gets called inside `completing-read', upon insertion, but I > see no way to get `completing-read' to display *Completions* > without any user action. IIRC you can do it from minibuffer-setup-hook. I've tried that. This is not about minibuffer setup, and it's not about completion-list setup (for which there is also a hook). This is about _completion_ setup. I believe that what's needed is a hook that kicks in as soon as completing-read (and read-file-name...) displays its prompt (just before or after). That hook doesn't exist.