Re: tlug: Mew on (X)Emacs the way to go?

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "mc" == Michael Casinghino <michael@example.com> writes:

    mc> If I use procmail to filter my messages as they arrive, how
    mc> can I be alerted that I have new mail?  I don't want to have
    mc> to remember to add a filename to my G/L/A/asmail file
    mc> everytime I make a new folder.

Alas, I don't see how to avoid that.  Under [X]Emacs, VM and Gnus (in
varying degrees, Gnus is better) support custom, so you just need to
remember the name of the variable (in VM it's vm-spool-files, in Gnus
I don't know what it is but I bet I could find it in the customize
menu, VM doesn't support custom that well).

The problem is that not all files (at least in my case) are spool
files (ie, receive new mail).  (In fact, under VM, the spool files and 
the archive files are completely separate.)

    mc> Also, what is the best way to
    mc> sort the mail mess in my home directory?  Should I `cat >>'
    mc> all the files onto one big file and run procmail on it?

Well, for one thing, that will fail miserably on RMail.

What I did was to simply read each such file as a VM folder and use
VM's native auto-folder-save, sorting, and threading abilities to
empty them into appropriate archive files.  This ought to work under
Gnus as well.  Dunno mew, mutt, or mh, they probably don't grok RMail.

    mc> RFC - This is from the XEmacs FAQ:
    mc> What is the status of Asian-language support, aka MULE?

    mc> The MULE support works OK but still needs a fair amount of
    mc> work before it's really solid.

Bunch of bloody perfectionists, we are.  "Really solid" to Ben Wing
means you can't blow a hole in it with a 16 inch naval gun.

The biggest problem with Mule on XEmacs at the moment is that due to
the assumption that 8 bit character sets are ISO-8859-1, it's hard for
Slavs, Arabs, and Israelis to use their native TTYs.  X is fine,
however.  There are some issues with columnization in the format
function (GNU Emacs makes the assumption that kanji are two columns
wide; XEmacs gives that up for lost since we allow proportional fonts
anyway).  We don't support Ethiopic, and Vietnamese is not compiled in
by default because it blows away the head maintainer's X server (and
sometimes Linux with it).  Anything there you can't live with?

    mc> Why should I switch from GNU Emacs to XEmacs?

Multimedia.  How does inline audio and graphics in your text editor
grab you?  Sorry, video is not possible at the present time, nor is
tactile or olefactory output.  (Now you know why Bill Clinton doesn't
use XEmacs.)  At the present time we support XBM, XPM, BMP (Windose
only, IIRC), GIF (this changes daily depending on Unisys posture, but
it looks like it will stay although all GIF images have been
eliminated from the XEmacs distribution itself), JPEG, PNG, TIFF, au,
and wav (Windose only, IIRC).  There is also special support on some
Un*x platforms like IRIX (SGI), but I'm not familiar with that.

Packages.  XEmacs is supported by more add-on packages than GNU Emacs.
(Because we're number two, we _must_ maintain compatibility with the
GNU Emacs API.  RMS does not pay us the same compliment, usually.)  In
particular, Custom, VM, and w3.el all work much better on XEmacs than
on GNU Emacs (partly because of graphics support, but there are API
aspects as well).

Package system.  Starting from XEmacs 21, we support packages
separately from the core XEmacs.  These packages are installable and
(soon) uninstallable, with separate version numbering and so on.
Doesn't yet have the functionality of RPM, but we're getting there.

Front end processors.  XEmacs is committed to supporting all free
FEPs; we currently support ISO8859, compose, Wnn (4 and 6), Canna,
SJ3, SKK (in buffer dictionary and external server), and LEIM (except
for Japanese, Ethiopic, and Devanagari) methods.  GNU Emacs supports
only LEIM, although the others are available as add-ons.

Games.  Tetris and Minesweeper in an Emacs Windows, with full sound
and graphical effects.  Doom is scheduled to be ported by the year
2025.  :-)

Menus, toolbars, and other widgets.  Just not possible in GNU Emacs,
yet.  Odds are against soon, but those odds are being quoted by XEmacs 
people who know how hard it was to make XEmacs's redisplay engine and
are assuming RMS will write the rumored new Emacs redisplay from
scratch.

Documentation.  We have a moderately complete internals manual, and
full documentation of Mule.  Emacs seems to have that in the works,
but it's still buggy (ie, if you don't already know how Mule works,
you will very likely misunderstand many of the statements in the
prerelease version of the Emacs 20 Lisp manual).  Open development
process: although there's not much happening in Mule development on
XEmacs right now, what discussion does occur is on the xemacs-beta
mailing list.  I've been really disappointed in the content of the
mule*@example.com mailing lists, they are mostly the equivalent of
emacs.mule.{bugs,help} rather than emacs.mule.devel.  (It could be the
same, but I do know that at least one new mailing list devoted to mule
development issues---using UTF-8 for internal encoding---died within
a few dozen hours of being started.)

    mc-didn't-ask> Why stick with GNU Emacs?

Leading-edge Mule development.  GNU probably has better Mule support,
although I've been unable to see it.  There are some things in the GNU 
Mule API that make me retch, but they may be necessary without a
complete redesign of Mule.  GNU definitely has more languages, and GNU 
will lead in that for the foreseeable future.  GNU probably guesses
encodings of files better than XEmacs, but they're both quite good.

GNU will probably have a new Lisp engine before XEmacs does.  XEmacs
will probably use either a freeware Common Lisp engine or a freeware
Scheme engine, but not likely Guile (the XEmacs developers are more or
less in agreement that Guile combines the misfeatures of Common Lisp
with the misfeatures of Scheme).  GNU will of course use Guile.

Political correctness.  RMS thinks the development split is evil and
reduplicative.  We do too, of course.  :-)

More stable NT port ;-)

Loads faster.

Runs (somewhat) faster (allegedly; the only app I have speed
complaints about is VM, and that didn't run at all on GNU Emacs last I 
tried).

Run-time (buffer-local!) choice of character-per-byte or Mule
(multi-byte) textual representation.

And those are just the advantages I know about; there are probably
others.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences        Tel/fax: +1 (298) 53-5091
---------------------------------------------------------------
Next Meeting: 10 October, 12:30 Tokyo Station Yaesu central gate
Next Nomikai: 20 November, 19:30  Tengu TokyoEkiMae 03-3275-3691
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp