* Michael Sperber: A somewhat related feature wish: I'd love to be able to download a new sumo, unzip it into c:/tmp/sumo, and start XEmacs with "--only-look-for-packages-under=c:/tmp/sumo". No matter how XEmacs was built. That way I could try out a new sumo, while still having an XEmacs instance running with my old setup to do any "must be done NOW" work. -- René

Michael Sperber <sperber(a)informatik.uni-tuebingen.de&gt; writes: Works nicely for me on Windows when I need it! -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Ben> Symlinks are a hack anyway ms> I disagree. Symlinks are a pretty good mechanism for ms> expressing sharing in environments that have them. OK. You disagree. Please remember that disagreement is a symmetric relation, and therefore any "solution" based on symlink-oriented thinking is going to be at best suspect, and quite likely unacceptable, to Ben. ms> [--late-package-path] Ben> I would be fine with this if it's possible to specify a Ben> single directory, the directory containing xemacs-packages, Ben> mule-packages and the like (and have it automatically ignore Ben> mule-packages if we're a non-MULE build). ms> This may be OK if you used the existing infrastructure (in ms> `packages-compute-package-locations') for figuring these ms> things out; what you did was hard-wire things unnecessarily. Mike, it _was_ necessary, and _you_ are primarily responsible for that. For starters, `packages-compute-package-locations' is designed to make this as difficult and opaque as possible, as you surely know. package-compute-package-locations is very much an internal API (it has a docstring, but is otherwise mentioned nowhere in the distribution, except for two invocations), and the whole setup is documented as a black box. The only documented ways to affect its behavior are --prefix, --package-path, and EMACSPACKAGEPATH---and those don't even appear explicitly in the docstring! The actual search algorithms aren't even located in the same file. You really have no ground to complain that when Ben used what was apparently the recommended interface he "unnecessarily" hard-coded things. That's _your_ design, not his! As far as I can see, your agenda for years has been a fixed and frozen hierarchy with a single root, and all pieces of XEmacs in their well-known and eternally unchangeable places relative to that single root. Your love for symlinks is one manifestation: the idea is to use the symlinks to fool XEmacs into thinking the packages are in their Proper Places when in fact they're located in /root/alone/knows/lib/. Now, I don't believe that you have deliberately concealed this, but AFAICT the majority of XEmacs developers and users have a two-root intuition. There is the core root, and there is the package root (which according to the intuition actually might be multiple, but is singular for normal installations). This divergence of intuitions results in a complete failure of communication, because the minority intuition is the basis for the actual design, but it is spelled out nowhere. Ben> They will want to say "You told me to put the packages under Ben> /usr/local/lib/xemacs, but for one reason or another they Ben> can't go there so I want to specify a directory in place of Ben> /usr/local/lib/xemacs". ms> I think that the vast majority of users don't need to tinker ms> with the package path at all. I agree with this, strongly. This is simply not a feature that posters to c.e.x or xemacs-beta ask for. Ben> [a] Have a --late-package-path option that lets you specify Ben> the exact locations of all package hierarchies. [b] Also Ben> have a --late-package-prefix option that lets you specify the Ben> directory under which the package hierarchies are located. [...] Those are horrible names. Since configure almost by definition doesn't need to be backward-compatible, just use --package-path and --package-prefix (or --packages-path and --packages-root, which I like better). ms> That would be fine, if nobody else disagrees with ditching ms> --package-path. I think the way to do this with the least ms> possible friction would be if you let me do it. If nobody ms> disagrees, I could get to work on the weekend or next week. ms> If I don't get it done by the end of next week, you can take ms> over. Does that sound acceptable? To be honest, that sounds disastrous to me. I think this is recipe for more of the same, and merely postpones the friction to a later date. Since nobody but the cognoscenti use or ask for this stuff at the moment, I don't see any hurry to implement this, or (upon cooler reflection) to remove Ben's --package-prefix. (I still think it's a kludge that Ben of all people would be ashamed of ;-), but it's pretty harmless.) I really really want a rationale document _first_, explaining what the "ideal" XEmacs installation looks like, and why it looks that way, and to what degree a "normal" installation may vary from the idea. I suspect many developers will be surprised by parts of it. Among other things, I'm currently playing with the idea of reviving the "last-packages" hierarchy for use by packages-in-source distribution. In general, I really think that there needs to be an published and documented API for manipulating XEmacs's idea of the package root, for use by installers and developers. -- 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.

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.

OK, I'm going to inject my two cents in here, although I haven't read all the latest messages entirely. But I understand very clearly what Stephen is saying, and I agree with it. [1] Conceptually there should be two kinds of roots: Core roots, and package roots. [2] A core root is a directory under which you find bin/xemacs.exe, info/*, man/*, etc; or src/xemacs.exe, etc. in a run-from-source configuration. [3] A package root is a directory under which you find `xemacs-packages', `mule-packages', etc. [4] Generally there should be one core root (I can't think of an obvious case where there should be more than one), but potentially many package roots. [5] The core root is determined at runtime by some sort of magic. [6] The set of package roots is determined at runtime by combining some standard locations with any package roots specified using --package-prefix, in the following order, where earlier in the list means earlier in the load-path: [1] ~/.xemacs [2] [maybe] an environment variable EMACSPACKAGEPREFIX [3] --package-prefix [4] CORE-ROOT/lib/xemacs-VERSION [5] CORE-ROOT/lib/xemacs [Note that parallelism between --prefix, which specifies the core root, and --package-prefix, which specifies the package roots.] [7] --package-path and EMACSPACKAGEPATH should be removed, as should the confusing concepts of "early", "late", and "last", which are false generality. [8] The code should be [a] modified to work as above, [b] documented, since most of the routines are not documented at all, [c] cleaned of all unnecessary goop, of which there is quite a lot. [9] The docs should be rewritten to reflect the above description.

I agree, I just didn't want to suggest something more radical for fear that Mike would disagree. I think --package-roots or something of that sort would be better than --package-prefix; before I realized what --prefix did I had a very hard time figuring out how to specify where to install XEmacs, since --prefix is a pretty damn opaque name. I was looking for --install-location or something obvious. Although maybe no one has asked for this kind of stuff, I think that's because most people just give up before trying to install packages themselves since it's too complicated and not well documented. I have a feeling this turns off a fair number of people, who may just go use GNU Emacs because everything comes with it automatically.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Hi Stephen, does the installshield kit with all packages at http://ftp.xemacs.org/pub/xemacs/binaries/win32/installshield/xemacs-21.5... not help? Best regards, Adrian -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

We need to fix this and release the installshield versions more often. At the very least, we need an installshield version of the latest 21.4 at all times. xemacs-21.5.17.exe APA> not help? Of course it helps a fair amount (although _I_ forgot about it, so I have to wonder how many users know about it :-( ), but our "kitchen sink" installers have a well-deserved reputation for being stale and occasionally broken. If I were were as diligent as norbert is in releasing betas, 21.5.17 would be about 5 releases behind; sometime in the next few days it will be two behind, anyway. -- 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.

Stephen> Maybe we do, but I have neither the will nor the software to Stephen> make one. Suggestions? The will is hard to do anything about :-) but as for software isn't there free software for creating installers? I don't know if there are difficult problems lurking when it comes to installers for different flavor of windows but naively, couldn't the process of making an installer almost be automated? Yours -- %% Mats

Ar an naoiú lá de mí na Nollaig, scríobh Ben Wing: Most Unix users use their OS packages--RPMs, BSD ports, etc--so they never worry about --prefix or --package-root, because they never get exposed to it. The distribution packagers tend to ship with a hefty selection of XEmacs packages, and it’s relatively rare that users want to install more. And if you’re sysadmin for a large site where many people are using XEmacs, you should install the Sumo packages anyway, because you can’t predict which subset of them your users will want. So any changes made here will provoke questions from a relatively small proportion of the userbase; people who are either sysadmins or distribution package maintainers, but who have trouble reading the basic documentation. What people might worry about could be installing per-user lisp code and packages, and frankly at the moment I’m unclear as to how exactly I would do that. Un-archive a Sumo tarball and a mule-packages tarball under ~/.xemacs/ ? Possibly. Since I’ve root on my local machine, I un-archive them under /usr/local/lib/xemacs, but that’s not something I can tell $random_user on comp.emacs.xemacs to do, so I’ve avoided suggesting installing packages there. I would disagree; installing Sumo tarball is uncomplicated and documented, for anyone with admin access to the system. Reading http://www.emacswiki.org/cgi-bin/wiki/EmacsAndXEmacs , a recurring issue with people who switched to GNU Emacs is the font-lock implementation. Packages aren’t mentioned, except in XEmacs’ favour. Lisp code not running on XEmacs is a problem. -- “Ah come on now Ted, a Volkswagen with a mind of its own, driving all over the place and going mad, if that’s not scary I don’t know what is.”