[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: links in Help buffer aren'talwayscorrect]
From: |
Kevin Rodgers |
Subject: |
Re: address@hidden: links in Help buffer aren'talwayscorrect] |
Date: |
Wed, 14 Dec 2005 18:11:12 -0700 |
User-agent: |
Mozilla Thunderbird 0.9 (X11/20041105) |
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
- address@hidden: links in Help buffer aren't always correct], Richard Stallman, 2005/12/12
- Re: address@hidden: links in Help buffer aren't always correct], Kevin Rodgers, 2005/12/13
- RE: address@hidden: links in Help buffer aren't alwayscorrect], Drew Adams, 2005/12/13
- Re: address@hidden: links in Help buffer aren't alwayscorrect], Kevin Rodgers, 2005/12/13
- Re: address@hidden: links in Help buffer aren't alwayscorrect], Kevin Rodgers, 2005/12/14
- Re: address@hidden: links in Help buffer aren't alwayscorrect], Richard M. Stallman, 2005/12/14
- RE: address@hidden: links in Help buffer aren'talwayscorrect], Drew Adams, 2005/12/14
- Re: address@hidden: links in Help buffer aren'talwayscorrect],
Kevin Rodgers <=
- RE: address@hidden: links in Help bufferaren'talwayscorrect], Drew Adams, 2005/12/14
- Re: address@hidden: links in Help buffer aren'talwayscorrect], Stefan Monnier, 2005/12/14
- Re: address@hidden: links in Help buffer aren'talwayscorrect], Richard M. Stallman, 2005/12/15
- Re: address@hidden: links in Help buffer aren'talwayscorrect], Eli Zaretskii, 2005/12/14
- bad mailer Subject meddling (was: links in Help buffer aren't always correct), Drew Adams, 2005/12/15
- Re: bad mailer Subject meddling (was: links in Help buffer aren't always correct), Alfred M\. Szmidt, 2005/12/15
- Re: bad mailer Subject meddling (was: links in Help buffer aren't always correct), Richard M. Stallman, 2005/12/16
- Re: bad mailer Subject meddling (was: links in Help buffer aren't always correct), Eli Zaretskii, 2005/12/16
- Re: bad mailer Subject meddling (was: links in Help buffer aren't always correct), Eli Zaretskii, 2005/12/15
- Re: address@hidden: links in Help buffer aren'talwayscorrect], Richard M. Stallman, 2005/12/15