This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Pending Packages List, 2004-01-23
>>>>> "Charles" == Charles Wilson writes:
Charles> Good to go.
Thanks
Charles> =================================
Charles> 3) xemacs-emacs-common's setup.hint should be marked "conflicts: emacs"
Charles> 4) xemacs-tags' setup.hint should be marked "conflicts: ctags"
Did we agree on this ? I cannot find any mention on it on
o http://cygwin.com/setup.html
Charles> =================================
Charles> 5) NOT a showstopper: xemacs issues the following message on startup:
Charles> WARNING:
Charles> Couldn't find an obvious default for the root of the
Charles> XEmacs hierarchy.
Charles> But that's misleading -- because it DOES find the hierarchy: all of
Charles> the stuff I 'require in my .xemacs/init.el are successfully
Charles> loaded. Starting xemacs with '-debug-paths' shows that XEmacs
Charles> hierarchy.configure-package-path is
Charles> ("/usr/local/share/xeamcs/site-packages"
Charles> "/usr/share/xemacs/site-packages" "/usr/share/xemacs/xemacs-packages"
Charles> "/usr/share/xemacs/mule-packages")
Charles> And sure enough, that IS where xemacs-sumo put the packages!
Charles> I wonder if this is a case where the cygwin build is mistakenly using
Charles> windows-style path parsing (early) but then later (when it actually
Charles> loads the packages) it correctly uses cygwin's path-handling...
Charles> This is not a showstopper, because it really just issues a warning;
Charles> XEmacs still *works*.
I don't understand this either. The strange thing is when I start xemacs
from the temporary installation directory it works. Debugging paths gives:
/usr/local/src/xemacs-21.4.14/.inst/usr/bin/xemacs -debug-paths -q
emacs-roots:
("/usr/local/src/xemacs-21.4.14/.inst/usr/" "/usr/")
.. snip ..
Charles> =================================
Charles> 6) When running in X-mode ($DISPLAY is set, cygwin-xfree Xserver is
Charles> running), on exit I get
Charles> Warning: XtRemoveGrab asked to remove a widget not on the list
I noticed this too when starting from an xterm/rxvt window, but usually
I start XEmacs once a day or even days and then from ~/.xinitrc when starting up X so
the warnings don't show up in front my eyes :-)
Charles> serval times. This isn't so bad. BUT, when running as a normal user,
Charles> I ALSO get a coredump on exit. When running as Administrator, I get
Charles> the warning, but no coredump. Also, when running in MSW mode
I always run as Administrator so I didn't notice this.
Charles> =================================
Charles> 7) Address in a later release:
Charles> I'd really like for XEmacs to behave the same way rxvt does (since
Charles> both are X/MSW multiple-personality). Currently, XEmacs:
Charles> $DISPLAY unset -- native MSW mode
Charles> $DISPLAY set to anything at all -- X mode
Charles> RXVT does this:
Charles> $DISPLAY unset -- native MSW mode
Charles> $DISPLAY set to ":0" -- native MSW mode
Charles> $DISPLAY set to anything ELSE(*) -- X mode
Charles> (*) this includes "127.0.0.1:0"
Charles> Granted, it's a little wierd (why is 127.0.0.1:0.0 different from :0")
Charles> but it's been around for a while. My environment, in particular, uses
Charles> this distinction, and by default DISPLAY=:0 (which I associate with
Charles> "MSW mode" thanks to long history with rxvt. So I was surprised when
Charles> I tried to start XEmacs in "MSW" mode but got X mode, and had to unset
Charles> DISPLAY to get the right behavior -- even tho RXVT was giving me the
Charles> "right" behavior all along. ("right" as in "longstanding so I'm used
Charles> to it")
Charles> OTOH, perhaps that might interfere with people who run XEmacs
Charles> remotely? It would also probably screw up the way gnuclient and
Charles> gnuattach work. Blech....never mind....
I would rather stick with the behaviour as it is. I think naturally if
you want MSW mode just unset DISPLAY.
Charles> =================================
Charles> 8) Address in a later release:
Charles> It would be nice if a postinstall script (modelled after
Charles> /usr/X11R6/bin/XFree86-bin-icons.sh) created shortcuts for xemacs
Charles> (with icons -- there's one in the xemacs source).
Will do this for the next release.
Charles> =================================
Charles> 9) Address in a later release:
Charles> perhaps a copy of sample.init.el should go into
Charles> /usr/share/doc/xemacs-${VER}/ ?
Yup.
Charles> =================================
Charles> IMO, good to go AS IS. (Note that I did not install or test the mule
Charles> package -- but that's pure lisp, and inspection shows that it's
Charles> packaged properly.)
I use it all day long.
Charles> Chuck
Thanks for the review Charles
(btw. will you switch now to this version as mentioned in another thread?)
Ciao
Volker