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

Package: xemacs-mule-sumo 2003-11-13-1  [2003-12-17]
Description: XEmacs MULE (MUlti Lingual Emacs) packages
   Proposer: Dr. Volker Zell
     Status: Skipped voting (tied to xemacs). Package available.
   HOLD-UPS: No "good to go" review.

Package: xemacs-sumo 2003-11-13-1 [2003-12-17] Description: XEmacs standard packages Proposer: Dr. Volker Zell Proposal: Status: Skipped voting (tied to xemacs). Package available. HOLD-UPS: No "good to go" review.

Package: xemacs 21.4.14-1 [2003-12-17] Description: A powerful, highly customizable open source text editor and application development system Proposer: Dr. Volker Zell Proposal: Also: xemacs-tags [etags and ctags programs and man pages from the xemacs distribution] Also: xemacs-emacs-common [Programs in common with the emacs package] Status: Attained required 3 votes. Package available. HOLD-UPS: No "good to go" review.

Good to go.

1) rebuilt from -src package, no problems.

2) this package is HUGE (but that's the way XEmacs is...)
    unpacked, xemacs-sumo pkg   is 100MB
              (main) xemacs pkg is  25MB
              xemacs-mule pkg   is  25MB
    (xemacs-emacs-common and xemacs-tags are both < 200k)

setup does not handle running out of disk space gracefully (yes, it happened to me while installing these test packages). setup hangs, and consumes 100% CPU. I painfully cleared enought disk space -- while setup was hung -- to enable setup to complete: but because "an error" occurred during the install, setup did not add the newly-installed package to the installed database. So I had to reinstall it anyway. This is a setup issue, not an xemacs issue.

3) xemacs-emacs-common's setup.hint should be marked "conflicts: emacs"
4) xemacs-tags' setup.hint should be marked "conflicts: ctags"

5) NOT a showstopper: xemacs issues the following message on startup:

Couldn't find an obvious default for the root of the
XEmacs hierarchy.

But that's misleading -- because it DOES find the hierarchy: all of the stuff I 'require in my .xemacs/init.el are successfully loaded. Starting xemacs with '-debug-paths' shows that XEmacs hierarchy.configure-package-path is
("/usr/local/share/xeamcs/site-packages" "/usr/share/xemacs/site-packages" "/usr/share/xemacs/xemacs-packages" "/usr/share/xemacs/mule-packages")

And sure enough, that IS where xemacs-sumo put the packages!

I wonder if this is a case where the cygwin build is mistakenly using windows-style path parsing (early) but then later (when it actually loads the packages) it correctly uses cygwin's path-handling...

This is not a showstopper, because it really just issues a warning; XEmacs still *works*.

6) When running in X-mode ($DISPLAY is set, cygwin-xfree Xserver is running), on exit I get

Warning: XtRemoveGrab asked to remove a widget not on the list

serval times. This isn't so bad. BUT, when running as a normal user, I ALSO get a coredump on exit. When running as Administrator, I get the warning, but no coredump. Also, when running in MSW mode ($DISPLAY unset), exit is successful -- no warnings, no coredumps.

Personally, as this only impacts on exit, I'd druther get XEmacs into the cygwin dist sooner, and fix this in the next release rather than delay this useful package...

7) Address in a later release:

I'd really like for XEmacs to behave the same way rxvt does (since both are X/MSW multiple-personality). Currently, XEmacs:
$DISPLAY unset -- native MSW mode
$DISPLAY set to anything at all -- X mode

RXVT does this:
  $DISPLAY unset                   -- native MSW mode
  $DISPLAY set to ":0"             -- native MSW mode
  $DISPLAY set to anything ELSE(*) -- X mode

(*) this includes ""

Granted, it's a little wierd (why is different from :0") but it's been around for a while. My environment, in particular, uses this distinction, and by default DISPLAY=:0 (which I associate with "MSW mode" thanks to long history with rxvt. So I was surprised when I tried to start XEmacs in "MSW" mode but got X mode, and had to unset DISPLAY to get the right behavior -- even tho RXVT was giving me the "right" behavior all along. ("right" as in "longstanding so I'm used to it")

OTOH, perhaps that might interfere with people who run XEmacs remotely? It would also probably screw up the way gnuclient and gnuattach work. Blech....never mind....

8) Address in a later release:

It would be nice if a postinstall script (modelled after /usr/X11R6/bin/ created shortcuts for xemacs (with icons -- there's one in the xemacs source).

Also, given the DISPLAY issue, two shortcuts: one for MSW-mode and one for X mode

"XEmacs Cygwin-MSW" shortcut points to a batch file (because you can't use -display to override DISPLAY and force it to be unset)
`cygpath -m $CYGWINROOT/bin/xemacs-msw.bat`
This batch file would be generated by the postinstall script, so that the value of CYGWIN_ROOT in the script can be set to $CYGWINROOT. Note that setup.exe sets the latter variable within the environment of the postinstall script before launching the script.

------------- xemacs-msw.bat ------------
@echo off
%CYGWIN_ROOT%\usr\X11R6\bin\run.exe %CYGWIN_ROOT%\bin\xemacs-21.4.14.exe

"XEmacs Cygwin-X" shortcut points to
  `cygpath -m $CYGWINROOT/bin/xemacs-21.4.14.exe` -display

9) Address in a later release:

perhaps a copy of sample.init.el should go into /usr/share/doc/xemacs-${VER}/ ?


IMO, good to go AS IS. (Note that I did not install or test the mule package -- but that's pure lisp, and inspection shows that it's packaged properly.)


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