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. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug