Didier Verna writes:
Stephen J. Turnbull wrote:
> I may be missing something, but I think we should avoid suppressing
> these warnings if possible.
I didn't mean that we should supress them by default. But in my case
for instance, I know very well that my Gnus, BBDB, AUC-TeX and whatever
else are shadowing the SUMO installation. Supressing a specific warning
class would make things easier in such cases.
I don't think there should be any warnings at all in that case. The
question is, is the answer for XEmacs to handle package hierarchies
differently, or is it for users to install them in more appropriate
places? AIUI, the OP occurred because site-package hierarchies don't
shadow xemacs-package hierarchies, so if you have
~/.xemacs/site-packages/lisp/gnus/auto-autoloads.el
/usr/local/share/xemacs/xemacs-packages/lisp/gnus/auto-autoloads.el
you will get an *error* that is converted to a warning. It is easily
*fixed* by simply
mv ~/.xemacs/{site,xemacs}-packages/lisp/gnus/auto-autoloads.el
so that the user xemacs-packages shadows the system xemacs-packages,
and /usr/local/share/xemacs/xemacs-packages/lisp/gnus/ doesn't end up
in load-path at all. (AIUI, this is one reason why site-packages and
user hierarchies are better than site-lisp and catchall personal
load-path entries.)
I think it's very natural to put a personal Gnus in
.xemacs/site-packages, so I'm not going to say that's "wrong", but I
also think it's easy enough to teach people to override SUMOs by using
~/.xemacs/xemacs-packages, not ~/.xemacs/site-packages. I don't have
a strong preference personally (but I'll think about it if y'all
decide to leave it up to me ;-).
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta