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

[Drew Adams]

    > 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.

    Sounds like a bug to me.

No, the bug was me - my bad.

    > 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.

    I was explaining the bug, not describing the ideal or
    documented behavior.

OK, thanks.

    > Beyond the lack of doc - is that really the behavior we want?

    Probably not.

    > Why is loading a source file treated differently from loading
    > a byte-compiled file

    It's not, except that if you say "test" and both "test.el" and
    "test.elc"
    are present, "test.elc" is used.

I meant, if you use argument "test.el", a new "test.el" entry is created,
rather than just updating the existing "test" entry (from "test.elc").

    > - that is, why are there two separate entries in load-history?

    Because you loaded "two different files": "test" and "test.el".
    Depending on the presence or absence of test.elc and test.el the two may
    or may not actually correspond to the same file.

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.

    > 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.

    The load-history entry remembers the exact string you passed to `load',
    rather than the actual name of the file that got loaded.  Whether that's
    right or not I can't say (IIRC XEmacs made the other choice).

That's the point. I think that's strange. At the least it's not documented
well, I think. The doc for `load' tells which file (el or elc) will be
loaded, depending on things like the form of the input string, but I don't
know if the structure and behavior of load-history are well documented. And
the behavior of file-requires, in any case, is not documented.

    > 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.

    Everything that uses load-history is pretty brittle.

My impression too.

Perhaps that is something to be looked at after the release.

I'm interested, in particular, because I have code that updates an
Emacs-Lisp file header to mention what files it ultimately might require
(recursive use of file-requires). It works, but I did run into some brittle
stuff, as you say.

Also, it would be great if load-history would record the type of `require'
that is used by a particular file: soft (non-nil third arg - no error if not
found) or hard (truly required). In my file-header code, I cannot make the
distinction, because the info isn't recorded in load-history. All the code
can do is insert a comment like this:

 ;; Features that might be required by this library:
 ;;
 ;;   `avoid', `frame-cmds', `frame-fns', `misc-fns', `strings',
 ;;   `thingatpt', `thingatpt+'.
 ;;

even though the only truly _required_ features might be `frame-cmds' and
`frame-fns'.

Emacs standard libraries don't use the `(require foo nil t)' idiom much, but
it is helpful in external libraries. I often have a library that would make
another library a bit more useful, but is not strictly required, so I use
such a soft require.