bug#11565: delayed init variables don't get documentation properties

bug#11565: delayed init variables don't get documentation properties

[Glenn Morris]

Package: emacs
Version: 24.1.50

Current trunk:

emacs -Q
C-h v Info-default-directory-list
  -> Not documented as a variable.

The doc string is in the DOC file though.

I think this is because:

1) it's a preloaded defcustom using custom-initialize-delay

2) custom-initialize-delay keeps variables unbound until they are
initialized. There's a comment about this in the source: "This seemed to
be at least as good as setting it to an arbitrary value like nil".

3) Snarf-documentation (semi-recently; bug#11036) ignores unbound
variables, on the assumption that they are for other platforms (eg
w32-specific).


I guess either we undo 3), or change 2) so that it sets the variable to
nil. The latter seems ok to me ...?

bug#11565: delayed init variables don't get documentation properties

[Stefan Monnier]

> I guess either we undo 3), or change 2) so that it sets the variable to
> nil.  The latter seems ok to me ...?

Undoing the var-part of 3 sounds fine to me.


        Stefan

bug#11565: delayed init variables don't get documentation properties

[Glenn Morris]

Stefan Monnier wrote:

>> I guess either we undo 3), or change 2) so that it sets the variable to
>> nil.  The latter seems ok to me ...?
>
> Undoing the var-part of 3 sounds fine to me.

There's a downside to doing that, in that bug#11036 will be reopened.
What's the downside to making custom-initialize-delay temporarily bind
variables to nil?

Another option: Snarf-documentation to check if variables are bound, or
members of custom-delayed-init-variables.

bug#11565: delayed init variables don't get documentation properties

[Glenn Morris]

PS this issue will presumably go away if you go through with
http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00474.html

and stop keeping the docs of preloaded lisp files in DOC.

bug#11565: delayed init variables don't get documentation properties

[Stefan Monnier]

>>> I guess either we undo 3), or change 2) so that it sets the variable to
>>> nil.  The latter seems ok to me ...?
>> Undoing the var-part of 3 sounds fine to me.
> There's a downside to doing that, in that bug#11036 will be reopened.

It doesn't strike me as a serious problem.

> What's the downside to making custom-initialize-delay temporarily bind
> variables to nil?

The downside is that I don't know the consequences ;-)

> Another option: Snarf-documentation to check if variables are bound, or
> members of custom-delayed-init-variables.

Yuck.

> PS this issue will presumably go away if you go through with
> http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00474.html

That's likely to happen, indeed.


        Stefan