Summary: The situation for reading babyl files in xemacs is hosed, for *multiple* reasons. It has been hosed for years. I have spent a couple of days tracking down the current state of affairs, and describe the problems, where they occur in the code, and discuss fixes. Please, oh, please fix xemacs -- if I can't access my 20-year-supply/multi-gigabytes of old babyl-format email, I can't switch over to xemacs... In what I say below, I am talking about a vanilla, out-of-the-box xemacs setup: - Red Hat 8.0 xemacs rpms for XEmacs 21.4 (patch 8): % rpm -qa | fgrep xemacs wl-xemacs-2.8.1-8 mew-xemacs-2.2-5 xemacs-el-21.4.8-16 w3m-el-xemacs-1.3.1-1 xemacs-info-21.4.8-16 xemacs-21.4.8-16 flim-xemacs-1.14.3-7 - xemacs started with "xemacs -q" - I append to the end of this msg a long report generated by m-x report-xemacs-bug if you want all the gory detail. Before diving into the bug reporting, let me note why babyl mail support matters. I am aware that vm is a better, more modern mail reader, and that babyl format is an old format that one might want to abandon. In fact, that is exactly what I am trying to do. But I have been using emacs since 1982; I now have *gigabytes* of mail sitting around in babyl format. - Yes, the right thing to do is to shift over to a modern mailbox format for new mail, and start using vm. - But the *wrong* thing to do is to somehow convert all my old mail files from babyl to a modern format. + It would be very difficult to track down all these old files. + They should be left alone. As I'll indicate below, vm's babyl-handling has been implemented with a bogus understanding of the format. I have had previous trials with vm corrupt some of my babyl files. Over the last 20 years, some of my old babyl files have been corrupted slightly for other reasons, and this might cause even correct conversion code to wreck these mailboxes on conversion. It is best to leave the old files in their old format. - The right thing to do is simply to continue to interact with old babyl files *in their existing format* (while shifting over to something more modern for new mail). Unfortunately, I can find *no means of correctly handling babyl files in xemacs*. Both vm & rmail have problems. This is really frustrating for me. I have, for years, wanted to shift from FSF emacs to Xemacs, but my enormous archives of old mail prevent me from being able to do so. I sent in a bug report on this two years ago -- with a detailed explanation of the issue and relevant code -- but things haven't changed. Below, I describe the problems with (xemacs) rmail, tm, and vm. Then I append - a spec for babyl files, - some sample code that addresses some of the problems, and - the detailed state-of-my-emacs report generated by M-x report-xemacs-bug C'mon guys. Save me from gnumacs... -Olin ------------------------------------------------------------------------------- * Problems with rmail & tm -------------------------- Xemacs rmail comes with mime-handling enabled via tm. This - blows up on babyl messages that *aren't* mime messages - blows up on babyl messages that *are* mime messages, in a different way. So if you run xemacs rmail on an rmail file, you are guaranteed to lose. Some of tm's mime-handling capability is provided by a file mel.el. It turns out that there are *two such files* in the xemacs system: /usr/lib/xemacs/xemacs-packages/lisp/flim/mel.el /usr/lib/xemacs/xemacs-packages/lisp/tm/mel.el They are not functionally identical. Package-loading finds & loads the first. It blows up. The second works. flim/mel.el defines MIME-DECODE-REGION as follows (defun mime-decode-region (start end encoding) "Decode region START to END of current buffer using ENCODING. ENCODING must be string." (interactive (list (region-beginning)(region-end) (completing-read "Encoding: " (mime-encoding-alist 'mime-decode-region) nil t "base64"))) (funcall (mel-find-function 'mime-decode-region encoding) start end)) However, when you invoke the whole tm mime-viewing system on a *non-mime* message, the ENCODING parameter is nil. When MIME-DECODE-REGION looks up the handler for the nil encoding, it gets nil back from MEL-FIND-FUNCTION, and the funcall bombs out. There are a couple of ways to fix this: - Add a guard to MIME-DECODE-REGION to skip the funcall if the function is nil, something like this: (defun mime-decode-region (start end encoding) "Decode region START to END of current buffer using ENCODING. ENCODING must be string." (interactive (list (region-beginning)(region-end) (completing-read "Encoding: " (mime-encoding-alist 'mime-decode-region) nil t "base64"))) (let ((handler (mel-find-function 'mime-decode-region encoding))) (if handler (funcall handler start end)))) This is what tm/mel.el does (though it uses a simpler lookup mechanism). - Arrange for MEL-FIND-FUNCTION to return a noop handler when you look up nil. - Arrange for the mime-message parser in tm/tm-parse.el to return a proper encoding value when it is asked to parse a non-mime message, instead of nil. - Arrange for rmail to invoke mime viewing *only* when a msg is a mime msg. The first of these options is the most robust, I would say. We're not done, though. Suppose we implement fix #1, and leave all else as-is, out-of-the-box (i.e., mime handling enabled for rmail). - If we try to read a babyl file we still blow up, because by the time rmail calls rmail-set-message-counters, via this chain rmail-set-message-counters rmail-maybe-set-message-counters rmail-first-unseen-message rmail the mime hackery has switched the current buffer to the mime-preview buffer, which isn't a babyl-format buffer... so the search for babyl's message-delimiters (newline/control-underbar) bombs out. This is a general problem, as I'll show below. At this point, I lost confidence that the rmail/tm interface could be fixed without serious rethinking. Rmail commands assume the current buffer is a babyl buffer. Unfortunately, tm makes these alternate "preview" buffers... and then imports the keymap of the original mail buffer, which contains these rmail commands that assume we're running in a babyl buffer. Boom. This code has been in xemacs for years. But you can blow it up with really, really simple examples. (See below for a simple demo.) After several days of wandering around this code, I must say that it seems like a huge mess. A particular problem is the level of documentation in the source files. I wanted to send you all working, fixed code, instead of this detailed problem report, but the packages involved are so large, complex, and poorly documented that I ran out of time. Sorry 'bout that. I have to go do some work to keep my day job, now. Suppose we turn off the mime-viewing default in rmail. Then it seems to work. But we now have no way to view mime messages -- and MIME has been essentially non-optional for a couple of years now. Tons of mime mail out there. If you don't handle mime, you don't really have a workable email solution. To see this lossage in action, download this twelve-line babyl file: http://www.cc.gatech.edu/~shivers/tmp/broken-rmail Then say xemacs -q c-u m-x rmail broken-rmail You will lose with a funcall to nil. Now try with the functioning mel.el file xemacs -q m-x load-file /usr/lib/xemacs/xemacs-packages/lisp/tm/mel.el c-u m-x rmail broken-rmail You will lose with a failed search for "\n^_", as rmail tries to count babyl messages in a mime preview buffer that doesn't contain babyl-format anything. Fixes: One of two things needs to be done - Fix the rmail/tm interaction - Provide rmail mime support from an alternate, non-tm package I have stumbled over an emacs-mime.info node describing an alternate mime-handling system that appears to packaged with gnus. Perhaps rmail could be shifted over to that? While I'm at it, I note that tm seems to have two manuals, tm-view & tm. They appear to have been written in texinfo, then converted to html. You can find the html manuals on xemacs.org, for example. But... - The html versions have broken navigation links, so you can't actually navigate the manuals (unless you guess the right url's and manually edit them, which can be done). - I can't find info or texinfo versions *anywhere*. What's up w/these mystery manuals? ------------------------------------------------------------------------------- * Problems with vm ------------------ Okay, let's consider abandoning xemacs's non-functional rmail+tm system and trying to read babyl files with vm. VM's babyl code was written with an incomplete spec for babyl files, in terms of the 0/1 header bit. There's a spec that comes with xemacs, in xemacs-packages/etc/BABYL written by Eugene Ciccarelli in 1983. Unfortunately, ECC's writeup leaves out some important info that I got in a later spec provided to me by Robert Krawitz in 1987. "Classic" gnu-emacs rmail hews to this extra information; xemacs' rmail & vm don't, and so break on old, perfectly reasonable babyl files. Here's the scoop. The initial line of a babyl message begins with either a 1 or a 0. When the "1,," flag is set, the msg headers are said to be "pruned" -- the stuff that lives before the "*** EOOH ***" are the complete, original headers, and the stuff that comes after the the EOH marker are the headers as the user would like to see them -- filtered. When the flag is a 0, i.e. "0,,", then there's only one set of headers -- the full set of headers is *after* the "*** EOOH ***" line. (Well... that's almost true. Gnu emacs seems to keep the "Summary-line:" and "Mail-From:" rmail-internal headers back behind the EOOH line; go figure. Please ignore this fact for now.) If you toggle full-header display on, then - If the header bit is "0,," do nothing. The user is already seeing them. - If the header bit is "1,," then nuke any headers after the "*** EOOH ***" line, move the "*** EOOH ***" line to before the saved headers that are currently above it, and flip the bit to "0,,". (Remember this action, because we're going to see in a moment that it messes up VM.) If you toggle full-header display off, then - If the header bit is "1,," do nothing. You're already doing that. - If the header bit is "0,,", then save a copy of the headers up above the "*** EOOH ***" line, and filter the headers down below it. In all cases, you *never* show anything above the "*** EOOH ***" line. No matter what you do with the "t" command, you never, ever show - the opening control-L - the "1,," or "0,," line - the hidden headers section - or the "*** EOOH ***" line These things are part of the babyl-format internals. I append a nice writeup of the babyl format I saved away a long time ago. See in particular notes [1] & [2]. I also append the relevant code from rmail.el, which seems reasonably clear. In other words... babyl supports a *completely different* model than vm's for hiding "behind the scenes" mail headers, using this 0/1 toggle. (I have tried to understand vm's header-hiding code, in vm-page.el, but couldn't figure it out. It is, in any event, different...) VM does a couple of things wrong. First, when the header bit is 1, it keeps its message-state info in headers that live *below* the EOOH line. Wrong. If the user toggles the header bit from 1 to 0, a compliant babyl system would throw all that stuff away, nuking the user-visible headers. You have to keep important info in the "original headers" section. Where do you find the original headers? Well, it depends. - If the header bit is 0, the original headers are *after* the EOOH line. - If the header bit is 1, the original headers are *before* the EOOH line. A simple way to handle this would be to have vm always force the message to header-bit-0 state before displaying the msg or operating on the header. This makes the message nice and simple, and you can then use vm's standard header-hiding display mechanism to handle that feature. Otherwise, you have to deal w/the fact that the "true" headers, in header-bit-1 mode, aren't part of the contiguous text that comprises the entire msg -- they're hiding up above both the EOOH line and the user-visible, filtered headers. Alternately, you could handle it the way rmail handles *it's* internal headers (Summary-line:" and "Mail-From:"), which is that it always hides them up above the EOOH line. I think this is probably the wrong thing to do. The second thing vm does wrong is the way it shows you the hidden headers if you toggle the headers with t. It currently shows you the *entire babyl message*, in its raw glory. That is, vm displays - the opening contol-L - the following "1,," line - the hidden headers section - the "*** EOOH ***" line - the following user-visible headers & msg This is not an email message! It's the underlying storage for one. The recipe for toggling the header bit is simple -- I wrote it out above, and will append emacs lisp code from rmail for handling it. A third, small thing I couldn't figure out is that vm refuses to let me incorporate mail in "system format" into a babyl folder using c-u g. It complains that the source file isn't babyl and beeps. ??? This is a standard thing one does. ------------------------------------------------------------------------------- From: rlk(a)think.COM (Robert Krawitz) Subject: Re: RMAIL/Babyl format Date: 30 Nov 87 15:56:46 GMT Let's see if I remember my BNF for babyl files; this corresponds to version 5: File:= <header> <message>* ; Some say there must be at least one message. Header:= Babyl Options:\n <header-option>* |^_ Header-option:= <header-token> ; See note [5] : * <value> header-token:= [^\000-\017:\177-\377]* ; Not these characters [tab is OK] header-value:= ditto, if a list, each element separated by a comma and a space. message:= \^L\n [01], ; See note [1] below ( <attribute>,)* ; Note space before and comma after token , ( <label>,)* ; ditto, see note [4] below \n <header>* ; See note [1] and [2] below *** EOOH ***\n <header>* ; See note [2] below \n <body> \^_ attribute:= unseen | last | ; Not all programs implement this. It ; generally only gets used internally, and ; isn't written out to a file. ; end. It shouldn't be written out to a file. deleted | recent | ; Not all programs implement this. It refers ; to a message in the last batch of new mail; ; thus it probably shouldn't be written out to ; a file during a normal save although it ; makes sense to write it out in an emergency save. filed | answered | forwarded | redistributed | badheader | ; Not all programs implement this filed ; Not all programs implement this label:= [^\000-\020,\177-\377]* ; No control chars, ; whitespace, commas, rubout, or high bit set header:= [^\000-\020:\177-\377]*: <header-line> <header-line>* header-line:= [ \t][^\n]*\n ; Continuation lines must be indented body:= (.*\n)* ; See note [3] below [1] A zero means that the headers have not been cleaned up, reprocessed, toggled, or whatever. In this case there should be no headers before the EOOH line. A one means that the headers have been reprocessed. In this case, the original headers will typically be before the EOOH line and the reformatted or whatever subset of headers that the user should see will be after it. Note that in this case it's permissible to garbage collect all headers before the EOOH line. No one's defined what it means to garbage collect SOME of the headers before this line, or what that means. [2] It's apparently permissible to add headers of the program's own choosing before the EOOH line. Or at least, Rmail does so (it caches a summary line) and nothing seems to object. There's no particular guarantee that something else won't step all over it, though. Headers after the EOOH line can be reformatted as the program wishes (e. g. indent the header lines to the same distance, canonicalize machine names) for display to the user. It's generally best for programs that read a babyl file to look at the headers before the EOOH line if they exist, since these should be untouched by the user. Remember, the user can edit anything after the EOOH line. [3] A \^_ at the beginning of a line should be quoted somehow. The normal way seems to be to decompose it into 2 characters: a ^ and a _. Strictly speaking, it doesn't always have to be, since the following text would have to be parsable as a message, but some programs don't try to use that much intelligence. Oh well. [4] Labels, or keywords as they are often called, are generally defined by the user, although it's not entirely impermissible for a program to use these for its own purpose (e. g. a keyword named RemindMe might be used to automatically find important messages). Some people also want these used to cache other state implemented by certain programs; this use is undefined. Note that all keywords used should be inserted in a header-option named Keywords:. Can a keyword have the same name as an attribute? Who knows? It's probably not a good idea, since some programs use the concept of <labels> = <keywords> + <attributes>. Sigh. [5] Some tokens are standardized in meaning. Common tokens are Mail inboxes, babyl file version number, which is currently 5, labels used in messages, window format for Zmail, anything else you want to be associated with a file. Be warned that labels should be a complete list of all user-defined keywords used in the file, so if you add a new label to a message, you should add it to this list. You should also have a Babyl version: 5 file attribute (look in a babyl file for details). Anyone know if there actually is a "formal" standard? This was done quickly from memory and a Zmail manual, but there are at least three programs around that use Babyl files (zmail, babyl, and emacs/rmail) and someone at SIPB was going to write a command-based mail reader similar to Unix Mail but operating on babyl files, and someone (of course not me :-)) should probably write xbabyl :-) References: ITS/Tops-20 INFO file on babyl (who wrote it? ECC? GZ?) Zmail manual (the MIT version was written by RMS; ECC wrote the section on Babyl file format) /Bob... ------------------------------------------------------------------------------- ;;;; *** Rmail Message Formatting and Header Manipulation *** (defun rmail-reformat-message (beg end) (goto-char beg) (forward-line 1) (if (/= (following-char) ?0) (error "Bad format in RMAIL file.")) (let ((buffer-read-only nil) (delta (- (buffer-size) end))) (delete-char 1) (insert ?1) (forward-line 1) (let ((case-fold-search t)) (while (looking-at "Summary-line:\\|Mail-From:") (forward-line 1))) (if (looking-at "\\*\\*\\* EOOH \\*\\*\\*\n") (delete-region (point) (progn (forward-line 1) (point)))) (let ((str (buffer-substring (point) (save-excursion (search-forward "\n\n" end 'move) (point))))) (insert str "*** EOOH ***\n") (narrow-to-region (point) (- (buffer-size) delta))) (goto-char (point-min)) (if rmail-ignored-headers (rmail-clear-headers)) (if rmail-message-filter (funcall rmail-message-filter)))) (defun rmail-clear-headers () (if (search-forward "\n\n" nil t) (save-restriction (narrow-to-region (point-min) (point)) (let ((buffer-read-only nil)) (while (let ((case-fold-search t)) (goto-char (point-min)) (re-search-forward rmail-ignored-headers nil t)) (beginning-of-line) (delete-region (point) (progn (re-search-forward "\n[^ \t]") (forward-char -1) (point)))))))) (defun rmail-toggle-header () "Show original message header if pruned header currently shown, or vice versa." (interactive) (rmail-maybe-set-message-counters) (narrow-to-region (rmail-msgbeg rmail-current-message) (point-max)) (let ((buffer-read-only nil)) (goto-char (point-min)) (forward-line 1) (if (= (following-char) ?1) (progn (delete-char 1) (insert ?0) (forward-line 1) (let ((case-fold-search t)) (while (looking-at "Summary-Line:\\|Mail-From:") (forward-line 1))) (insert "*** EOOH ***\n") (forward-char -1) (search-forward "\n*** EOOH ***\n") (forward-line -1) (let ((temp (point))) (and (search-forward "\n\n" nil t) (delete-region temp (point)))) (goto-char (point-min)) (search-forward "\n*** EOOH ***\n") (narrow-to-region (point) (point-max))) (rmail-reformat-message (point-min) (point-max))))) ------------------------------------------------------------------------------- * Voluminous state-of-emacs report generated by M-x report-xemacs-bug --------------------------------------------------------------------- This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. Please describe as succinctly as possible: - What happened. - What you thought should have happened. - Precisely what you were doing at the time. Please also include any C or lisp back-traces that you may have. ================================================================ Dear Bug Team! ================================================================ System Info to help track down your bug: --------------------------------------- uname -a: Linux astest 2.4.9-e.8smp #1 SMP Fri Jul 19 15:38:30 EDT 2002 i686 unknown unknown GNU/Linux ./configure 'i386-redhat-linux-gnu' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--datadir=/usr/share' '--libdir=/usr/lib' '--mandir=/usr/share/man/man1' '--infodir=/usr/share/info' '--with-gpm=no' '--with-sound=native' '--with-pop' '--mail-locking=lockf' '--with-clash-detection' '--debug=no' '--error-checking=none' '--with-mule=yes' '--with-database=berkdb' '--with-ldap=yes' '--with-hesiod=no' '--with-canna=yes' '--with-wnn=yes' '--with-widgets=motif' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=motif' '--with-xim=xlib' '--with-msw=no' '--with-xfs=yes' '--pdump' XEmacs 21.4.8 "Honest Recruiter" configured for `i386-redhat-linux'. Compilation / Installation: Source code location: /usr/src/build/141167-i386/BUILD/xemacs-21.4.8 Installation prefix: /usr Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -O2 -march=i386 -mcpu=i686 Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Using Motif native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Compiling in support for PostgreSQL. - Using PostgreSQL header file: libpq-fe.h - Using PostgreSQL V7 bindings. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. - Using XFontSet to provide bilingual menubar. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. Mail: Compiling in support for POP mail retrieval. Compiling in support for "lockf" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for dynamic shared object modules. Using the new portable dumper. Load-Path Lisp Shadows: ---------------------- (/usr/lib/xemacs/xemacs-packages/lisp/flim/md5 /usr/lib/xemacs/xemacs-packages/lisp/gnus/md5 /usr/lib/xemacs/xemacs-packages/lisp/flim/smtpmail /usr/lib/xemacs/xemacs-packages/lisp/mail-lib/smtpmail /usr/lib/xemacs/xemacs-packages/lisp/gnus/smime /usr/lib/xemacs/xemacs-packages/lisp/semi/smime /usr/lib/xemacs/xemacs-packages/lisp/semi/signature /usr/lib/xemacs/xemacs-packages/lisp/tm/signature /usr/lib/xemacs/xemacs-packages/lisp/semi/mime-setup /usr/lib/xemacs/xemacs-packages/lisp/tm/mime-setup /usr/lib/xemacs/xemacs-packages/lisp/flim/mel-u /usr/lib/xemacs/xemacs-packages/lisp/tm/mel-u /usr/lib/xemacs/xemacs-packages/lisp/flim/mel-q /usr/lib/xemacs/xemacs-packages/lisp/tm/mel-q /usr/lib/xemacs/xemacs-packages/lisp/flim/mel-g /usr/lib/xemacs/xemacs-packages/lisp/tm/mel-g /usr/lib/xemacs/xemacs-packages/lisp/flim/mel /usr/lib/xemacs/xemacs-packages/lisp/tm/mel /usr/lib/xemacs/xemacs-packages/lisp/gnus/utf7 /usr/lib/xemacs/xemacs-packages/lisp/wl/utf7 /usr/lib/xemacs/xemacs-packages/lisp/apel/alist /usr/share/xemacs-21.4.8/lisp/alist) Installed XEmacs Packages: ------------------------- ((zenirc:version 1.13 :type regular) (xslt-process :version 1.1 :type regular) (xslide :version 1.02 :type regular) (xemacs-devel :version 1.47 :type single-file) (xemacs-base :version 1.66 :type regular) (w3 :version 1.25 :type regular) (vm :version 7.07 :type regular) (viper :version 1.34 :type regular) (view-process :version 1.11 :type regular) (vhdl :version 1.15 :type regular) (vc-cc :version 1.21 :type regular) (vc :version 1.33 :type regular) (tramp :version 1.05 :type regular) (tpu :version 1.12 :type regular) (tooltalk :version 1.13 :type regular) (tm :version 1.34 :type regular) (time :version 1.11 :type regular) (textools :version 1.12 :type regular) (text-modes :version 1.48 :type single-file) (texinfo :version 1.2 :type regular) (supercite :version 1.19 :type regular) (strokes :version 1.08 :type regular) (speedbar :version 1.23 :type regular) (sounds-wav :version 1.1 :type regular) (sounds-au :version 1.1 :type regular) (slider :version 1.13 :type regular) (sieve :version 1.07 :type regular) (sh-script :version 1.15 :type regular) (sgml :version 1.08 :type regular) (semantic :version 1.12 :type regular) (scheme :version 1.11 :type regular) (rmail :version 1.13 :type regular) (reftex :version 1.25 :type regular) (psgml :version 1.28 :type regular) (ps-print :version 1.04 :type regular) (prog-modes :version 1 .6 :type single-file) (pcomplete :version 1.01 :type regular) (pcl-cvs :version 1.63 :type regular) (pc :version 1.25 :type single-file) (os-utils :version 1.28 :type single-file) (net-utils :version 1.27 :type single-file) (mmm-mode :version 1.0 :type regular) (misc-games :version 1.15 :type single-file) (mine :version 1.14 :type regular) (mh-e :version 1.14 :type regular) (mailcrypt :version 2.11 :type regular) (mail-lib :version 1.47 :type regular) (jde :version 1.35 :type regular) (ispell :version 1.24 :type regular) (ilisp :version 1.27 :type regular) (igrep :version 1.08 :type regular) (idlwave :version 1.25 :type regular) (ibuffer :version 1.08 :type regular) (hm--html-menus :version 1.18 :type regular) (haskell-mode :version 1.04 :type regular) (gnus :version 1.62 :type regular) (gnats :version 1.15 :type regular) (games :version 1.13 :type regular) (fsf-compat :version 1.11 :type single-file) (frame-icon :version 1.09 :type regular) (forms :version 1.14 :type regular) (footnote :version 1.15 :type regular) (eudc :version 1.36 :type regular) (eterm :version 1.13 :type regular) (ess :version 1.02 :type regular) (eshell :version 1.03 :type regular) (emerge :version 1.09 :type regular) (elib :version 1.1 :type single-file) (eieio :version 1.02 :type regular) (efs :version 1.29 :type regular) (edt :version 1.12 :type regular) (edit-utils :version 1.89 :type single-file) (ediff :version 1.41 :type regular) (edebug :version 1.14 :type regular) (dired :version 1.12 :type regular) (dictionary :version 1.11 :type regular) (debug :version 1.15 :type regular) (crisp :version 1.12 :type regular) (cookie :version 1.14 :type regular) (clearcase :version 1.04 :type regular) (cc-mode :version 1.28 :type regular) (calendar :version 1.18 :type regular) (calc :version 1.23 :type regular) (c-support :version 1.16 :type single-file) (build :version 1.06 :type regular) (bbdb :version 1.21 :type regular) (auctex :version 1.32 :type regular) (ada :version 1.1 :type regular) (mule-ucs :version 1.04 :type regular) (mule-base :version 1.42 :type regular) (lookup :version 1.12 :type regular) (locale :version 1.18 :type regular) (leim :version 1.18 :type regular) (latin-unity :version 1.05 :type regular) (egg-its :version 1.26 :type regular) (edict :version 1.13 :type regular)) Features: -------- (mail-abbrevs xemacsbug shadow sendmail rfc822 zenirc-autoloads xslt-process-autoloads xslide-autoloads xemacs-devel-autoloads xemacs-base-autoloads wl-autoloads w3-autoloads vm-autoloads viper-autoloads view-process-autoloads vhdl-autoloads vc-cc-autoloads vc-autoloads tramp-autoloads tpu-autoloads tooltalk-autoloads tm-autoloads time-autoloads textools-autoloads text-modes-autoloads texinfo-autoloads supercite-autoloads strokes-autoloads speedbar-autoloads sounds-wav-autoloads sounds-au-autoloads slider-autoloads sieve-autoloads sh-script-autoloads sgml-autoloads semi-autoloads semantic-autoloads scheme-autoloads rmail-autoloads reftex-autoloads psgml-autoloads ps-print-autoloads prog-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads pc-autoloads os-utils-autoloads net-utils-autoloads mmm-mode-autoloads misc-games-autoloads mine-autoloads mh-e-autoloads mailcrypt-autoloads mail-lib-autoloads jde-autoloads ispell-autoloads ilisp-autoloads igrep-autoloads idlwave-autoloads ibuffer-autoloads hm--html-menus-autoloads haskell-mode-autoloads gnus-autoloads gnats-autoloads games-autoloads fsf-compat-autoloads frame-icon-autoloads forms-autoloads footnote-autoloads flim-autoloads eudc-autoloads eterm-autoloads ess-autoloads eshell-autoloads emerge-autoloads elib-autoloads eieio-autoloads efs-autoloads edt-autoloads edit-utils-autoloads ediff-autoloads edebug-autoloads dired-autoloads dictionary-autoloads debug-autoloads crisp-autoloads cookie-autoloads clearcase-autoloads cc-mode-autoloads calendar-autoloads calc-autoloads c-support-autoloads build-autoloads bbdb-autoloads auctex-autoloads apel-autoloads ada-autoloads mule-ucs-autoloads mule-base-autoloads lookup-autoloads locale-autoloads leim-autoloads latin-unity-autoloads egg-its-autoloads edict-autoloads lisp-autoloads loadhist auto-show fontl-hooks x-iso8859-1 canna-leim slovenian czech romanian ccl mule-help code-cmds gutter-items menubar-items x-menubar mode-motion mouse itimer auto-save lisp-mode easymenu iso8859-1 page buff-menu lib-complete cus-file derived frame text-props obsolete cus-start custom widget cl-extra mini-cl cl cl-19 packages backquote very-early-lisp postgresqlv7 postgresql CANNA file-coding wnn mule lucid-scrollbars cut-buffer lucid-menubars motif-dialogs x c-balloon-help tty-frames tty toolbar native-sound scrollbar unix-processes multicast network-streams subprocesses modules menu-accelerator-support menubar berkeley-db md5 xemacs xim gutter tiff png gif jpeg xpm xbm lisp-float-type linux dialog devices window-system base64) Recent keystrokes: ----------------- misc-user Recent messages (most recent first): ----------------------------------- Parsing /home/shivers/.mailrc... Loading xemacsbug...done Loading xemacsbug... Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/w3m-init.el...done Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/w3m-init.el... Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/psgml-init.el...done Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/psgml-init.el... Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/mew-init.el...done Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/mew-init.el... Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/aspell-init.el...done Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/aspell-init.el...