This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Pending Packages List, 2004-01-23

>>>>> "Charles" == Charles Wilson writes:

    Charles> Good to go.


    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


    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
("/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 ""

    Charles> Granted, it's a little wierd (why is 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/ 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}/ ?


    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?)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]