Re: autoload and auto-compression-mode

[Luc Teirlinck]

Eli Zaretskii wrote:

   First, what happened to indentation here?  The extra spaces are funny.

I just kept the indentation style that was already present (it is also
used in several other docstrings).

   Second, there's a spurious period at the end of the last sentence.

I removed that one.

   And finally, I'm sorry to say that this description still leaves me
   confused.  Why do we need 2 lists, and why one of them is a literal
   list, while the other is returned by a function?

The answers are in the discussions earlier in this thread.  There are
three lists, one of Elisp suffixes, one of file representation
suffixes and one which is a computed combination of both.  The last
one needs to be computed on the fly, because any of the two other
lists could have changed in the meantime, and hence needs to be
returned by a function.  The two others do not need to be computed on
the fly and hence can be stored in a variable.  There are various
alternatives to this approach, including the current situation, but
Richard rejected those.  Anyway, it is not the task of a docstring to
explain and motivate design decisions.

   These two doc strings should at least tell that the details of how
   these lists are used are described in the doc string of `load' (if
   that's the intent).  Just saying that `load' and the unnamed ``related
   functions'' use does not immediately invites me to look there for a
   detailed description.

Since there are currently still discussions underway about how whether
load-file-rep-suffixes should be used just for load or for some other
file operations as well, I believe that we should delay any further
worries about these two docstrings until these issues are resolved.
Maybe if the Elisp manual is properly updated, there could be a link
to the Elisp manual in those two docstrings, where these two variables
can be discussed in the proper context, which is more difficult in
docstrings which are supposed to be relatively compact.

Sincerely,

Luc.