RE: file-requires does not reflect source file changes, even after file is loaded

[Drew Adams]

    > `file-requires' doc string says only this: "Return the list
    of features
    > required by FILE." First problem: it doesn't even say
    anything about the
    > form of the FILE argument (string, not symbol).

    Features are represented by symbols, but files are never represented by
    symbols in Emacs, only by strings.

Fair enough.  Then we should either 1) apply that generally, and remove all
mention of the type of a file argument from all doc strings, or 2) mention
the type in this doc string too, as it is mentioned in others.

It is even more important to mention it in this function than in most,
because 1) feature names are often file names (sans extension), 2) the input
arg is a file name, and 3) the output is a list of features. IOW, this can
all be confusing, and explicit mention of the FILE argument type wouldn't
hurt.

BTW, the list of features returned from this function is a list of
_strings_, not symbols, so features are apparently also sometimes
represented by strings.

    > 1. Put files test.el , foo.el, and bar.el in load-path. Put
    `provide's in
    > foo and bar. Put (require 'foo) in test.el. Byte-compile test.el.

    > 2. load-library loadhist (so you can use `file-requires')

    > 3. load-library test

    > 4. M-: (file-requires "test") shows ("foo")

    > 5. Edit test.el so it requires bar instead of foo.

    > 6. load-library test.el (source file, not .elc)

    > 7. M-: (file-requires "test") still shows ("foo")

    The issue is not "byte-compiled vs non-byte-compiled", but just that the
    load-history has 2 entries: one for "test" (corresponding to
    test.elc) and
    one for "test.el".  If you do (file-requires "test") you'll get the info
    about the first, while if you do (file-requires "test.el")
    you'll the info
    about the second.

Your answer is in terms of how file-requires is implemented (and the
structure of load-history). The behavior (what it does, not how it does it)
should be documented in the doc string. Thanks for the explanation, though.

Beyond the lack of doc - is that really the behavior we want? Why is loading
a source file treated differently from loading a byte-compiled file - that
is, why are there two separate entries in load-history? And why is the entry
for test.el different, depending on whether or not a test.elc exists?

    If instead of "load-library test.el" you
    remove the .elc
    file and then do "load-library test" (which will load the test.el file)
    you'll get the answer you want.

Yes, I mentioned that: when there is no .elc the .el is used. I suppose this
means that in that case the load-history entry is not test.el, but test - or
else some code massages things and deals with this as a special case.

    Similar problems show up if you do M-x load-library RET test
    RET and later on
    do M-x load-library RET /path/to/test RET.

The latter behavior is well documented in the load doc string - that is, the
preference for .elc, the use of explicit .el as arg, etc.

But nothing is said in the file-requires doc string about the its behavior.
The doc string doesn't even mention load-history. If the behavior is to stay
as it is, then the file-requires doc string should have an explanation,
analogous (though this is not the same thing) to the explanation about .el
and .elc in the doc string of load.