From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.devel Subject: Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Date: Wed, 14 Dec 2005 18:11:12 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1134610139 24450 80.91.229.2 (15 Dec 2005 01:28:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2005 01:28:59 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 15 02:28:57 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EmhuG-0000w0-Ly for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2005 02:27:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Emhus-0000FA-Oz for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2005 20:28:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Emhi5-00024k-Cr for emacs-devel@gnu.org; Wed, 14 Dec 2005 20:15:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Emhi3-00024N-RX for emacs-devel@gnu.org; Wed, 14 Dec 2005 20:15:04 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Emhi3-00024I-GX for emacs-devel@gnu.org; Wed, 14 Dec 2005 20:15:03 -0500 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1EmhkD-0007kc-9p for emacs-devel@gnu.org; Wed, 14 Dec 2005 20:17:17 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Emhfp-0005IO-Nl for emacs-devel@gnu.org; Thu, 15 Dec 2005 02:12:45 +0100 Original-Received: from 207.167.42.60 ([207.167.42.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Dec 2005 02:12:45 +0100 Original-Received: from ihs_4664 by 207.167.42.60 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Dec 2005 02:12:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 43 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 207.167.42.60 User-Agent: Mozilla Thunderbird 0.9 (X11/20041105) X-Accept-Language: en-us, en In-Reply-To: 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:47754 Archived-At: Drew Adams wrote: > describe-frame-parameter seems to work usefully, but it has one > problem: its completion list is incomplete. > > Do you mean because it iterates only over the parameters of the selected > frame? > > It might also include user-defined parameters that won't be documented in > Info. Perhaps it should instead iterate over an explicit list of all of the > Info-documented (built-in) frame parameters. I'm sure that's what he means. But by analogy, `M-x describe-variable' doesn't complete on void symbols, and it is well understood that an unset frame parameter's value is effectively void: frame-parameter actually returns nil, but it means the parameter has no effect. So why provide completion on all documented frame parameters? So that the user can simply type ? at the prompt to see the entire list of frame parameters. That would be really useful, if there was also a set-frame-parameter command. And if there were a define-frame-parameter function and/or defframeparam macro that would maintain a global list (or obarray) of frame parameters, it would allow `M-x describe-frame-parameter' and `M-x set-frame-parameter' to reliably complete over both documented and user-defined frame parameters. > Perhaps too, the doc string should mention that it only works on documented > built-in frame parameters, not user-defined parameters. That seems like the right thing to do, unless we define a global list (or obarray) of frame parameters to complete over. > I noticed too that in emacs -q, M-x describe-frame-parameter RET > cursor-color gives an error because Info-find-node is not defined > (autoloaded). Good point. I think that since Info-goto-node displays the *Info* buffer, it should be declared as an (interactive) command, and therefore that it should be autoloaded. -- Kevin Rodgers