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

[Drew Adams]

        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")

    What does (file-requires "test.el") return at that point?  Does it
    mention bar?  I suspect so.  That is arguably a bug; perhaps it should
    treat "test" and "test.el" as the same file.  However, that is not
    easy to do.

Yes, I neglected to mention that. You get "(bar)".

See Stefan's emails and my replies. It would be good to treat them the
same - that is, if you use argument "test.el", the existing load-history
entry for "test" is updated, instead of creating a new "test.el" entry. As I
said:

      If both elc and el are present, and I load elc, the
      load-history entry is "test" (taken from the .elc), but if I
      load "test.el" a separate entry is created, "test.el". If I the
      delete the .elc and load "test", the entry "test" is updated.

      In one case, file "test.el" corresponds to entry "test" and in
      the other case it corresponds to entry "test.el". The
      load-history entry corresponds to the form of the input to the
      function, not to the file that is loaded. Yet load-history and
      file-requires are purported to represent the load history - the
      files and features that were loaded, not the string used to
      represent them when `load' was called.

In general, load-history needs to be improved. I suggested that this is
something to be looked at after the release. I would also like it to
distinguish (require 'foo nil t) from (require 'foo), so we can interrogate
`load-history' to determine actual dependencies.

    Aside from that, I think these doc fixes should be enough.

Not to me. Your changes just mention that the FILE arg could be an "absolute
file name". First, "test.el" is not an absolute file name, in terms of what
most people understand by that (no directory path) - "complete file name,
with extension" is what you mean, I think.

More importantly, I don't think these doc changes will make the behavior
clear.

Here is your doc string for file-requires: ""Return the list of features
required by FILE as it was loaded. FILE can be an absolute file name or a
library name that `load' could find."

How does that suggest that loading FILE as "a library name that `load' could
find" treats it differently from loading FILE as "an absolute file name"?
Users need to know that file-requires returns a result that corresponds to
the last thing _loaded under the same name_. That is, if the FILE arg to
file-requires is a library name (sans file extension), then the result
corresponds to the last load that also referenced the library sans
extension. If the FILE arg to file-requires is a complete file name, with
extension, then the result of file-requires corresponds to the last load
that referenced the library using a file extension.

IOW, users need to know all of these things:

1) Using a file extension and not using it produce two different
load-history entries.

2) If both .elc and .el exist, and you load the library without specifying
an extension, the .elc is loaded, even if it is not up-to-date. This is
stated clearly in the doc-string for `load' - no problem.

3) file-requires looks up the _load entry corresponding to the particular
form of its arg_, so whether or not it has a file extension can make a
difference. It does not look up the load history of the library irrespective
of how it was last accessed (named).

Points #1 and #3 are missing from the doc strings, I believe.

Point #1 should be added to the doc for `load-history', at a minimum. Also,
that doc speaks only of "file name", which is not correct; it must mention
the separate treatment of a "test" arg to `load' and a "test.el" arg to
load. The load-history doc string is not very clear or complete.

Point #3 should be added to the doc for `file-requires', at a minimum.
However, that doc should also refer to `load-history', for clarification of
the separate treatment of libraries, depending on how you refer to them
(point #1).

HTH.