Pending Packages List, 2004-01-23

Charles Wilson
Tue Jan 27 07:22:00 GMT 2004

> Package: xemacs-mule-sumo 2003-11-13-1  [2003-12-17]
> Description: XEmacs MULE (MUlti Lingual Emacs) packages
>    Proposer: Dr. Volker Zell
>    Proposal:
>      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/share/xemacs/site-packages" "/usr/share/xemacs/xemacs-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 


More information about the Cygwin-apps mailing list