Re: recursive-load-depth-limit not customizable

[Per Abrahamsen]

eliz@is.elta.co.il (Eli Zaretskii) writes:

> Hyperlinks to definitions in C files, for both functions and
> variables, are not yet supported.  You can try C-h f for any bult-in
> function or C-h v for any bult-in variable: all of them lack
> hyperlinks to the source files.

But 'C-h f' tells me "this is a build-in function".  It would be nice
to get similar information with 'C-h v'.

And you probably meant to say "patches welcome" with regard to the
missing customization type.  Here is a patch:

2001-10-28  Per Abrahamsen  <abraham@dina.kvl.dk>

        * cus-start.el (recursive-load-depth-limit): Added.

*** cus-start.el.~1.38.~        Tue Aug 28 14:02:44 2001
--- cus-start.el        Sun Oct 28 12:11:15 2001
***************
*** 1,6 ****
  ;;; cus-start.el --- define customization properties of builtins
  ;;
! ;; Copyright (C) 1997, 1999, 2000 Free Software Foundation, Inc.
  ;;
  ;; Author: Per Abrahamsen <abraham@dina.kvl.dk>
  ;; Keywords: internal
--- 1,6 ----
  ;;; cus-start.el --- define customization properties of builtins
  ;;
! ;; Copyright (C) 1997, 1999, 2000, 2001 Free Software Foundation, Inc.
  ;;
  ;; Author: Per Abrahamsen <abraham@dina.kvl.dk>
  ;; Keywords: internal
***************
*** 143,149 ****
                                                    (integer :tag "time" 2)
                                                    (other :tag "on")))
             ;; lread.c
! 
  ;; This is not good news because it will use the wrong
  ;; version-specific directories when you upgrade.  We need
  ;; customization of the front of the list, maintaining the standard
--- 143,151 ----
                                                    (integer :tag "time" 2)
                                                    (other :tag "on")))
             ;; lread.c
!            (recursive-load-depth-limit limits (choice (const :tag "off" nil)
!                                                       integer))
!                                                
  ;; This is not good news because it will use the wrong
  ;; version-specific directories when you upgrade.  We need
  ;; customization of the front of the list, maintaining the standard