>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> >You're adding new stuff, so you're increasing complexity.
Ben> No. I may be slightly increasing code complexity but I'm greatly
Ben> simplifying the situation from the perspective of a user. See previous
Ben> comment.
I disagree. You're adding a user-visible option without removing
another one. You're doing this without any real indication from the
user community that you're solving an imminent problem.
Ben> An unfamiliar user should not have to use a hard, lower-level
Ben> interface. They want an easy, high-level one.
An unfamiliar user should use neither of these options. The familar
users don't seem to have a big problem.
Ben> Symlinks are a hack anyway
I disagree. Symlinks are a pretty good mechanism for expressing
sharing in environments that have them.
[--late-package-path]
Ben> I would be fine with this if it's possible to specify a single directory,
Ben> the directory containing xemacs-packages, mule-packages and the like (and
Ben> have it automatically ignore mule-packages if we're a non-MULE
Ben> build).
This may be OK if you used the existing infrastructure (in
`packages-compute-package-locations') for figuring these things out;
what you did was hard-wire things unnecessarily.
Ben> Don't forget, in wanting to cater to the minority, that the vast majority of
Ben> users will put their packages in one place and have no site packages. They
Ben> will want to say "You told me to put the packages under
Ben> /usr/local/lib/xemacs, but for one reason or another they can't go there so
Ben> I want to specify a directory in place of /usr/local/lib/xemacs". I want
Ben> something that will do that. How about:
I think that the vast majority of users don't need to tinker with the
package path at all. And they shouldn't unless there's a strong
overriding reason to do so.
Ben> [a] Have a --late-package-path option that lets you specify the exact
Ben> locations of all package hierarchies.
Ben> [b] Also have a --late-package-prefix option that lets you specify the
Ben> directory under which the package hierarchies are located. This is ignored
Ben> if --late-package-path is given, and otherwise creates a --late-package-path
Ben> using `xemacs-packages', `site-packages', `infodock-packages' (maybe),
and
Ben> `mule-packages' (if compiled with Mule support). This is less general than
Ben> --late-package-path but is much easier to use for the uninitiated, which
Ben> Will be 90% of new users out there.
That would be fine, if nobody else disagrees with ditching
--package-path. I think the way to do this with the least possible
friction would be if you let me do it. If nobody disagrees, I could
get to work on the weekend or next week. If I don't get it done by
the end of next week, you can take over. Does that sound acceptable?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla