Mike Kupfer writes:
Sean MacLennan wrote:
> Does xemacs -vanilla show no lisp shadows?
If we're still talking about the "auto-autoloads already loaded"
error-morphed-to-warning, this isn't going to help figure it out. The
shadow-finding code has to ignore auto-autoloads, because there's one
in *every* package by design. Same for custom-load, except that not
all packages have one of those (most do).
That said, the output is "interesting" (thus the [issue] tag).
6 Emacs Lisp load-path shadowings were found"
Use M-x list-load-path-shadows for nicer output.
This is a bug. (Verified in my straight-from-hg package source tree.)
I don't know whose offhand. Since libraries are uniquely identified
to `load' by their file names, it is an error to have two libraries in
sibling packages with the same name.
sformat.el has a 0-line diff, but working.el has a 151-line diff! So
this is actually broken (since 2003?):
2003-09-24 David Ponce <david(a)dponce.com>
* sformat.el, working.el: Move to common.
* Makefile: Re-generate.
* Project.ede (tools):
Remove sformat.el and working.el from target sources.
Ben did this, arguing that menu-building is a core function. I see
his point. It can't be added to 21.1 or 21.4 in the same way, thus
the duplication. But it's not a problem, it should be handled by
`package-suppress' (don't ask until you've donned acid-resistent
clothing -- highly corrosive!) IMO, this is a bug in shadow.el, which
should probably participate in the package-suppress protocol (I would
say by warning about it).
Not a core function, but this was done (by Adrian?) so that users
don't have to have packages available to submit a build report. Makes
sense. Ditto on the package-suppress, I think.
I think Aidan or Mats did this. APEL's deprecated but these functions
are very useful. Ditto package-suppress.
Ben, again. Ditto package-suppress.
XEmacs-Beta mailing list