[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: |
Fri, 16 Dec 2005 11:53:40 -0700 |
User-agent: |
Mozilla Thunderbird 0.9 (X11/20041105) |
Richard M. Stallman 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?
I wasn't sure exactly what it does, but it certainly omits many
standard frame parameter names. I don't think whether the selected
frame has a setting for a particular frame parameter ought to affect
whether I can complete its name.
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 think that is the best thing to do. Or else get that from the
manual too.
OK, the attached version addresses all the points that have been raised:
* It defines a global list of documented frame parameters, which is
initialized from the manual (using info, not Info-goto-node), and
which can be augmented with user-defined parameters.
* The global list is actually an alist mapping parameters to their doc
strings, so the doc strings are only extracted once from the manual
and cached there.
* Completion uses the union of the documented frame parameters and any
other parameters set in the selected frame. The symbol at point is
only provided as a default if it's a member of that union.
* The Info xrefs and indentation have been removed from the doc string,
and it's been reformatted (filled) to account for that.
* Like variables, undocumented frame parameters are described as "not
documented" and there's no link to the manual.
Enjoy!
--
Kevin
describe-frame-parameter.el
Description: application/emacs-lisp
- RE: address@hidden: links in Help bufferaren'talwayscorrect], (continued)
- 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
- Re: address@hidden: links in Help buffer aren'talwayscorrect],
Kevin Rodgers <=