>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> ok. i find packages extremely confusing. almost all documentation i've seen
Ben> has been a total mess. i've spent some time trying to clean the docs up to
be
Ben> clear. this discussion seems to be typical of it. michael, i don't want to
be
Ben> overcritical of you but you need to spend more time thinking of how to make
Ben> clear, concise, introductory documentation.
Sorry, I'm not getting it. This discussion is about *atypical* cases,
namely about running in-place. (As have most others been.) Things
seem to work fine after "make install." I don't see how the
introductory documentation can or should address this issue.
Ben> The documentation in the .el files is unfortunately even worse,
Ben> e.g.:
Ben> (defun paths-construct-info-path (roots early-packages late-packages
Ben> last-packages)
Ben> "Construct the info path."
Ben> ...)
Ben> (defun paths-find-doc-directory (roots)
Ben> "Find the documentation directory."
Ben> ...)
Ben> (defun paths-find-exec-directory (roots)
Ben> "Find the binary directory."
Ben> ...)
Ben> (defun paths-construct-exec-path (roots exec-directory
Ben> early-packages late-packages last-packages)
Ben> "Find the binary path."
Ben> ...)
You need to be a lot more specific about what you think the problem
is, and how it should be remedied. E.g., what kind of documentation
do you envision for a this:
(defun paths-construct-info-path (roots early-packages late-packages last-packages)
"Construct the info path."
...)
I could add:
"Construct the info path.
This is the path where XEmacs will look for info files.
ROOTS is a list of XEmacs roots.
EARLY-PACKAGES is a list of early package hierarchies.
LATE-PACKAGES is a list of late package hierarchies.
LAST-PACKAGES is a list of last package hierarchies."
But this adds verbosity, not information. You say you're confused,
but you don't state a question that you think isn't answered.
Ben> some examples of problems in the docs:
Ben> [1] introductory docs need to have clear cross-references to where to find more
Ben> info. in this case, this might mean a pointer from README.packages to the node
Ben> in xemacs/startup.texi; but no such pointers exist.
I'll freely admit I wrote none of README.packages.
Ben> [2] startup.texi talks generically about "roots" but its definition of
"root" is
Ben> over-general and very confusing.
What exactly are you confused about?
Ben> You need to put in examples -- for example,
Ben> the fact that <root> = /usr/local [typically] appears nowhere in the
document.
I don't think there's a "typical value" for a root. Specifically, the
problems people are having crop up when it's not /usr/local.
Ben> By default, XEmacs expects an early package hierarchy in the
Ben> subdirectory @file{.xemacs/xemacs-packages} of the user's home
Ben> directory.
Ben> but what goes there? do i put subdirectories xemacs-packages, mule-packages,
Ben> and site-packages?
No; I see there's a typo in the docs that make them confusing on that
issue. (It says "An XEmacs package is laid out [...]" where it shoud
say "An XEmacs package hierarchy is laid out [...]") I'll fix it.
Ben> In my case, i have xemacs in-place in /src/xemacs/someworkspace/src/xemacs.exe,
Ben> and my packages typically get installed into /src/xemacs/xemacs-packages,
Ben> /src/xemacs/mule-packages, etc.
Ben> i have to manually set a package-path like
Ben> PACKAGE_PREFIX=\src\xemacs
Ben> PACKAGE_PATH=~\.xemacs;;$(PACKAGE_PREFIX)\site-packages;$(PACKAGE_PREFIX)\mule-p
Ben> ackages;$(PACKAGE_PREFIX)\xemacs-packages
Ben> for native Windows, or
Ben> configure
Ben> ... --package-path=~/.xemacs::/src/xemacs/site-packages:/src/xemacs/xemacs-packa
Ben> ges:/src/xemacs/mule-packages
Ben> for Cygwin.
No, you shouldn't have to do *anything* if you're running in-place.
You asked for this feature. I implemented it. I told you that I'd
implemented it. I'm severely annoyed that you then refused to defend
it when I asked you to, and I intend to take it out again in the near
future.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla