Re: [VETO] Support package-prefix and fix mail-locking in configure

>>>>> "ms" == Michael Sperber <[email protected]> writes:

    ms> We've been going around that question for years: I did try to
    ms> say just that in the XEmacs manual, but somehow it's too
    ms> unclear for people to understand.  So I really need help in
    ms> finding out specifically where the documentation I wrote falls
    ms> down.  A good start would be why the above paragraph didn't
    ms> answer your question.

Well, for one thing, it's not the way I think about the packages.  I
can parse it, and with a fair amount of work apply it.  But it doesn't
make sense and I have to go through the same effort every time.  It's
unnatural to me, and I think it's unnatural for almost all XEmacs
developers and users.

To go into excruciatingly detailed introspection and analogy:

I would argue that that is why GNU Emacs is such a mess, both in terms
of the myriads of configurable locations and the cruft that
experienced users' `load-path's accumulate, and the non-structure of
its LISP source hierarchy: Emacs is NOT "one", it is a collection of
many more or less equal applications, and even the core editor hardly
is more important than say Gnus or VM.  People perceive it as a
collection of applications, not as a hierarchy of libraries, and they
want to be able to point it to "my packages" and "your packages" and
the "system packages".

To me, the package hierarchy is _not_ part of the XEmacs "installation
hierarchy", and its root is the parent of xemacs-packages, not the
great-grandparent.  I do _not_ necessarily expect to find an xemacs
binary in xemacs-packages/../../bin/xemacs, but I do expect to find
one in $installation_hierarchy_root/bin/xemacs.  Yes, I agree that it
is convenient to have that as the standard installed configuration,
and I strongly recommend it to users with no good reason to do
otherwise.  But that's a packaging convenience; it's _not_ the way I
think about the packages, any more than I think of XEmacs as being
part of GCC, and would be shocked if somebody suggested installing
XEmacs into /usr/lib/gcc-lib/packages/XEmacs/ because it's a "GCC
application".  A bizarre example, but that is about the degree of
difficulty I have with keeping "xemacs-packages is a GRAND-child of
the root" in mind.

In fact, several important package developers (in particular Paul
Kinnucan of JDEE and T V Raman of Emacspeak) take this idea a step
further, and think of the parent of their package's top directory as a
root (in a somewhat different, but related, sense).  They feel
sufficiently strongly about this that they refuse to participate in
maintenance of XEmacs packages of their applications.  Who knows what
their "real" reasons are, but the "perverse" XEmacs package hierarchy
is at the top of the list of the reasons given by both Raman and
Kinnucan.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.