bug#11106: 24.0.94; enhancement request: have autoload treat faces like it does options

[Stefan Monnier <monnier@iro.umontreal.ca>]

> No special problem for #1.  It's not completely clear to me how an
> option is handled, but clearly the defcustom is not simply copied to
> the autoloads file.

Indeed, but it's supposed to be an internal detail (i.e. an optimization).

>> I can't assume it, since you're trying to explain to me why that would
>> be useful.
> No, I was not trying to explain why autoloading faces can be useful in
> general.

Then you were not trying to answer my question (which was not "in
general" but at least in one scenario, by the way).

> As to the assumption of usefulness in general, since that is
> apparently a stumbling block for you: Why, in your opinion, can (real)
> autoloading be useful for a command but not for an option or a face?

Because the user can invoke commands, but not faces (with very few
exceptions).

> IOW, why do we have function `autoload' for functions?  Why not just
> use autoload cookies and have them simply copy a function's defun to
> the autoloads file (i.e., not handle functions specially)?

Because a function usually depends on its surrounding code, so copying
its body without its surroundings would not result in a usable function.
Because such autoloaded functions are simply entry points to the package
and it's convenient to be able to auto-load the package without having to
`require' it explicitly.

> The same reason applies to options and functions: real autoloading has a use,
> independent of the use of predefinition.

I don't see how faces generally depend on their surrounding code.
I don't see how the use of a face will often lead to the use of the rest
of the package where it's defined.

[ I stopped here, sorry, too long. ]


        Stefan