Stephen J. Turnbull wrote:
Mike Kupfer writes:
> I get a list of functions and variables matching "gnus.*group", along
> with the first line of the docstring, if any. I expect that first line
> to match the source. But in some cases the first letter of the
> docstring is missing.
That sounds like an out-of-date DOC-file, but presumably Gnus doesn't
use the DOC-file.
Right, the DOC file does not contain definitions for any Gnus
There's an old feature for "dynamic" extraction of
libraries; is there any change you have that enabled? It would have
the same effect if the running Gnus were out-of-date with respect to
the files one disk.
If you mean byte-compile-dynamic-docstrings, yes, that's set to t (the
default). Setting it to nil prior to loading Gnus doesn't help.
Finally, since your whole Gnus package seems to be shadowed, I have
wonder if that's related.
Well, I hid my ~/.xemacs and restarted XEmacs, and I'm still seeing the
problem. So I think the shadows are unrelated.
I tried M-x apropos, and I see related behavior for the same set of
variables. For example, Hyper Apropos shows
* gnus-activate-foreign-newsgroups - If nil, Gnus will not check foreign newsgroups at
* gnus-adaptive-word-no-group-words - f t, don't adaptively score words included in
the group name.
M-x apropos shows
User Option: *If nil, Gnus will not check foreign newsgroups at startup.
Plist: 4 properties
User Option: If t, don't adaptively score words included in the group name.
Plist: 4 properties
Hmm. Looking at the source, I see that the docstring for
gnus-activate-foreign-newsgroups starts with a "*", and the docstring
for gnus-adaptive-word-no-group-words does not.
So here's my guess at the problem: gnus-adaptive-word-no-group-words is
being treated as a user variable because it's defined by defcustom. So
Hyper Apropos is assuming that the docstring starts with "*" and
helpfully deleting the docstring's first character before displaying it.
Does that sound plausible? If yes, what's the right fix?
XEmacs-Beta mailing list