From f690ec33f4bf5a37301321c3caa57edba85211bd Mon Sep 17 00:00:00 2001 From: "Richard M. Stallman" Date: Sun, 17 Dec 2006 22:23:07 +0000 Subject: [PATCH] (Named Features): Explain subfeatures better. --- lispref/loading.texi | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/lispref/loading.texi b/lispref/loading.texi index eb576f8fbbc..150e20275b1 100644 --- a/lispref/loading.texi +++ b/lispref/loading.texi @@ -726,8 +726,14 @@ The argument @var{feature} must be a symbol. @code{provide} returns @var{feature}. If provided, @var{subfeatures} should be a list of symbols indicating -a set of specific subfeatures provided by this version of @var{feature}. -You can test the presence of a subfeature using @code{featurep}. +a set of specific subfeatures provided by this version of +@var{feature}. You can test the presence of a subfeature using +@code{featurep}. The idea of subfeatures is that you use them when a +package (which is one @var{feature}) is complex enough to make it +useful to give names to various parts or functionalities of the +package, which might or might not be loaded, or might or might not be +present in a given version. @xref{Network Feature Testing}, for +an example. @smallexample features -- 2.39.5