HDTenEightyP/NetNews huggingface dataset:
From: kakazu@racerx.cit.cornell.edu (Gary Kakazu)
Subject: Trouble building 18.59 on Sun os 4.1.1
Reply-To: Gary Kakazu <kakazu@cornell.edu>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 17:48:34 GMT

I had trouble building 18.59 on a sparc running sun os 4.1.1 using gcc
2.3.1 with the XWINDOW option.  Now, I got a workable executable to build
so I really shouldn't be complaining, but this question is more for my
curiosity than anything else.  The problem is illustrated below:


racerx:[~/temp/emacs-18.59] make all
cd etc; make  all
cd src; make  all
make  -f xmakefile  all
./temacs -batch -l inc-vers
Loading inc-vers...
New Emacs version will be 18.59.2
./temacs -batch -l loadup.el dump
Loading loadup.el...
Loading subr...
Loading loaddefs.el...
Loading simple...
Loading help...
Loading files...
Loading indent...
Loading window...
Loading paths.el...
Loading startup...
Loading lisp...
Loading page...
Loading register...
Loading paragraphs...
Loading lisp-mode...
Loading text-mode...
Loading fill...
Loading c-mode...
Loading isearch...
Loading replace...
Loading abbrev...
Loading buff-menu...
Loading version.el...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Loading site-init...
Cannot open load file: mouse

*** Error code 255

I got around the problem by commenting out the second reference to
site-init in loadup.el, since I didn't use a site-init file.  I'm wondering
where it got the notion to load the file mouse.

Gary 
--
Cub Fan, Homebrew man
Gary Kakazu				kakazu@cornell.edu
Network Programmer			(607) 255-1679
Cornell Information Technologies

Newsgroups: gnu.emacs.bug
From: edwardw@pandc.rta.oz.AU (Ed Wilkinson,x6895, Topic Contractor,6604539)
Subject: emacs for Fujitsu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 19 Dec 1992 00:17:02 GMT

I've hacked Gnumacs for a Fujitsu running UTS/M V22L20. The following diffs
are neither pretty or efficient, but it's all I have time for at the
moment. If I get a free period later I'll try to integrate them better.

--8<-- cut here --

*** emacs.c	Tue Dec  8 11:41:12 1992
--- ../emacs.c	Tue Dec  8 11:35:52 1992
***************
*** 62,68 ****
--- 62,70 ----
  #endif
  
  #ifdef USG5
+ #ifndef F_SETLKW
  #include <fcntl.h>
+ #endif
  #endif
  
  #ifdef BSD
*** process.c	Tue Dec  8 11:40:56 1992
--- ../process.c	Tue Dec  8 11:35:24 1992
***************
*** 1742,1748 ****
  	     checked, so this error will stop recurring.  */
  	    FD_ZERO (&Available);     /* Cannot depend on values returned.  */
  #else /* not AIX */
! 	    abort ();
  #endif /* not AIX */
  	  else
  	    error("select error: %s", sys_errlist[xerrno]);
--- 1742,1749 ----
  	     checked, so this error will stop recurring.  */
  	    FD_ZERO (&Available);     /* Cannot depend on values returned.  */
  #else /* not AIX */
! 	    /*abort ();*/
! 	    FD_ZERO (&Available);     /* Cannot depend on values returned.  */
  #endif /* not AIX */
  	  else
  	    error("select error: %s", sys_errlist[xerrno]);
*** sysdep.c	Tue Dec  8 11:41:08 1992
--- ../sysdep.c	Tue Dec  8 11:35:46 1992
***************
*** 2065,2071 ****
  
  #endif /* POSIX_SIGNALS */
  \f
! #ifndef BSTRING
  
  void
  bzero (b, length)
--- 2065,2071 ----
  
  #endif /* POSIX_SIGNALS */
  \f
! /*#ifndef BSTRING*/
  
  void
  bzero (b, length)
***************
*** 2132,2138 ****
    return 0;
  #endif /* not VMS */
  }
! #endif /* not BSTRING */
  \f
  #ifdef BSD4_1
  long random ()
--- 2132,2138 ----
    return 0;
  #endif /* not VMS */
  }
! /*#endif /* not BSTRING */
  \f
  #ifdef BSD4_1
  long random ()


--8<-- cut here --

Hope they are of use.

	Ed

Ed Wilkinson	RTA, Sydney, Australia		edwardw@xwdev.pandc.rta..oz.au


Newsgroups: gnu.emacs.bug
From: bip@sekas.DE (Paul Bininda)
Subject: rmail spool file parsing problem
Organization: SEKAS, Munich, Germany
Distribution: gnu
Date: Tue, 15 Dec 1992 10:55:53 GMT

Emacs Version: 18.58.2
OS: HP-UX 8.0


Problem 1:

When retrieving mail from the spool file (/usr/mail/<username>) rmail
did not separate the mail messages but instead stuffed them all into
one message in the RMAIL buffer. I traced this problem to the
following piece of code in rmail.el

	  (if (re-search-forward
	       "^From \\([^ ]*\\(\\|\".*\"[^ ]*\\)\\)  ?\\([^ ]*\\) \\([^ ]*\\) *\\([0-9]*\\) \\([0-9:]*\\)\\( ?[A-Z]?[A-Z][A-Z]T\\| ?[-+]?[0-9][0-9][0-9][0-9]\\|\\) 19\\([0-9]*\\) *\\(remote from [^\n]*\\)?\n" nil t)

This regular expression is used to find the headers in the spool file.
Right in the middle is a piece, that is supposed to match the time
zone "[A-Z]?[A-Z][A-Z]T". This assumes, that the time zone ends with a
"T".  But we are in Germany and our time zone name (in native
language) is MEZ.


Solution 1 -> Problem 2:

I thought, that I could fix Problem 1 quick and dirty by changing the
above to "[A-Z]?[A-Z][A-Z][TZ]" or "[A-Z]?[A-Z][A-Z]Z". Either of
these got rmail into an endless loop when retrieving mail from the
spool file.  What is going on there? Do I have to change something
else as well?


Solution 2:

I gave up and changed the time zone in the system .profile from MEZ to
MET (swallowing my nationalistic pride :-) ). Now everything works,
until someone has the bright idea of changing it back in his own
.profile.

Any ideas on a better solution? How do other Germans handle this?

--
                                          -----  Paul Bininda   
                                          -----  bip@sekas.de


Newsgroups: gnu.emacs.bug
From: baxter@slcs.slb.com
Subject: Emacs 18.59 confused by hundreds of ^S (incremental search)?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 16 Dec 1992 17:08:00 GMT

GNU EMacs 18.59.1 of Wd Dec 9 1992 on woody (berkeley-unix)
  [really.. Sun OS 4 on Sparc2]

I have an apparantly repeatable problem.

I have a large *shell* buffer (4.5Mb) which was running a
compute-bound Unix process producing intermittent output; the only
other buffers were *scratch* and *Buffer List*.  I went to the top of
the *shell* buffer, and did "^S***" to find "***", an indicator
produced by the Unix process.  Having found the first instance, I went
to the next instance by typing "^S".  Such instances are 10's of lines
apart, and Emacs must update a significant fraction of the screen for
each instance found.  I repeated *just* "^S" about 400 times in rapid
succession (I was interested in how many occurrences there were of the
indicator; yeah, I could have built a macro to count, but one gets
started on one approach and just carries through if it is a one time
event).  At this point, instead of displaying the next instance, Emacs
said "Back to top level" in the command line area at the bottom of the
screen.  In fact, most keys (including "C-g" and "C-h l", "Meta-x")
responded "Back to top level". Only a few other keys worked (C-l, C-f
and C-b).  I figured I had lost Emacs completely to weirdness.  After
a few minutes of trying lots of things, surprise, surprise, suddenly
everything is back to normal. It is interesting that (display-time),
which I always start via my .emacs file, did not update the time on
the status line during the "weirdness" period.

The problem seems to be repeatable; get a big buffer with irregular
text structure, "^S" to find a relatively common string, and then
simply lean on the "^S" key and let auto-repeat generate lots of
continue-incremental-search requests.  I don't know how to reliably repeat the
recovery from the wierdness, but my few successful experiments hint
that the computing process finally producing some more output to be
displayed in the shell window is probably the key.  I also once
got the message "Garbage Collecting", and that seem to un-confuse Emacs.

Guessing: Perhaps the Emacs display logic gets behind, so ^Ss aren't
processed fast enough, and I consequently overflow an input buffer
with ^Ss?  Is there is a timeout involved somewhere?









Newsgroups: gnu.emacs.bug
From: rich@merl.com
Subject: [young@icad.COM: Emacs 18.58 intermittent Find File hang?]
Organization: Mitsubishi Electric Research Laboratories, Inc.
	Cambridge, Massachusetts, USA
Distribution: gnu
Date: Thu, 17 Dec 1992 03:52:08 GMT

Does the information below help?  Can this bug be fixed?

		Thanks, -Chuck.

Date: Wed, 16 Dec 92 16:39:22 EST
From: young@icad.COM (Jonathan H. Young)
To: rich@merl.com
Subject: Emacs 18.58 intermittent Find File hang?

   From: rich@merl.com
   Date: 8 Dec 92 04:50:47 GMT

     Every few days, always when I have just hit the final <cr> after the
   file name argument to Find File (C-X C-f), my Emacs job freezes.  It
   will not respond to any further keyboard or mouse input; I finally
   have to kill it (I have waiting as long as 15 minutes to see if it
   will unfreeze itself, but it doesn't).  The rest of the environment on
   the workstation works fine.  If I try to read the same file from the
   shell or find the same file again with a new copy of Emacs, it works
   fine.

     The last two times this happened the file name I typed happened
   to begin with a tilda (e.g., ~someuser/foo.bar).  I don't know if
   this is a pattern or not.

     I realize that this could be a problem with NFS or any number of
   other things, but Emacs seems to be the only program showing
   a problem of this kind right now.

Howdy, neighbor!

I believe this is the same problem I have seen, but I don't know of a
fix yet.  We run 18.58 on many machines, but I have only observed the
problem on Sun 4s (Sparcstations, IPXs, etc) *after a YP server
crash*, after typing ~<user>/filename.  The problem arises in the YP
library user lookup code -- someone is passing in a NULL pointer and
the library loops.

My advice is to expect emacs to be flaky after a YP server crash.

				--- Jonathan



Newsgroups: gnu.emacs.bug
From: baklarz@skat.usc.edu (Mark Baklarz)
Subject: Bug in emacs - 18.58.13
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 22:47:05 GMT

  This isn't a big problem, more for just your information.  It was noticed
by one of our consultants.  We've told users not to resize their windows to
1 line.  
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
If you invoke emacs in an xterm (no-window emacs, not x11emacs) and
you resize the window to one row, you get a cute error.

	Fatal error (6).IOT trap (core dumped)

Then emacs dies and you are back at the system prompt.  This also happens 
with sunview emacstool.  Running an X11 Emacs window limits you to 5 lines 
minimum, so the problem isn't seen.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  We are running SunOS 4.0.3 - 4.1.3 on Sun3's and Sun4's.
  We have Gnu emacs 18.54.27 and 18.58.13
  We see it fail with X11R5/Openwindows and xterm resized to 1 line, and
                      Sunview and shelltool resized to 1 line.

  It seems to show the same error in all cases tried.

Mark Baklarz - University of Southern California BITNET:  baklarz@uscvm
                University Computing Services    INTERNET:baklarz@usc.edu
                 Unix Technical Support Group    UUCP:    ...!uunet!usc!baklarz

Newsgroups: gnu.emacs.bug
From: zappo@titan.ucc.umass.edu (Eric Ludlam v 2.1a)
Subject: vt100 arrow keys suggestion
Organization: University Computing Services
Distribution: gnu
Date: Tue, 15 Dec 1992 15:10:05 GMT

Howdy,

  I've been doing a fair amount of emacs programming on vt300's and
vt400's over the past few months, and I have the following suggestion
for dealing with the vt100 style arrow keys.  The files vt100.el and
vt200.el both use keypad.el which sets up a "keypad" of letters bound
to functions.  This works great for standard editing where \C-f is
always bound to forward-char.

  Now lets say you want to rebind \C-f and company to do movement in a
game, ie move some piece or marker around.  Suddenly the arrow keys
get all confused and move the cursor instead of moving the piece or
marker.  This is annoying.

  My suggestion is the following.  Emacs has this way kool ability to
allow you to put a string into a keybinding slot which acts as a
macro.  As a result, I have the following redefinitions in my .emacs
file:

(define-key global-map "\e[A" "\C-p")
(define-key global-map "\e[B" "\C-n")
(define-key global-map "\e[C" "\C-f")
(define-key global-map "\e[D" "\C-b")
(define-key global-map "\eOA" "\C-p")
(define-key global-map "\eOB" "\C-n")
(define-key global-map "\eOC" "\C-f")
(define-key global-map "\eOD" "\C-b")

  This way, in cases (such as view-mode, dired-mode, games etc, the
arrows are always bound to whatever the \C-f keys are bound to.  In
any professional release, these definitions would be under CSI-map or
somesuch, but the action of using strings makes some modes easier to
deal with.  This, of course, will cause problems when moving to such
emulators as vip or EDT modes, but in general I think this seems kool.

  Anyways this is just a suggestion to any who'd care listen.

  -Eric
--
 +---------------------------+--------------------------------------------+
 | Eric M. Ludlam            | Student Supervisor of Mainframe Consulting |
 | zappo@titan.ucc.umass.edu |         University Computing Services      |
 | zappo@gnu.ai.mit.edu      |  University of Massachusetts, Amherst MA   |
 +---------------------------+--------------------------------------------+

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: modified rmail should display ** in mode line
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 12 Dec 1992 23:07:10 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

just like ordinary buffers.  Sometimes I forget to write them out
and this causes me some hassle.

Newsgroups: gnu.emacs.bug
From: piet@cs.ruu.NL (Piet van Oostrum)
Subject: Re: advice.el - Problem with new byte compiler
Reply-To: piet@cs.ruu.nl (Piet van Oostrum)
Organization: Dept of Computer Science, Utrecht University, The Netherlands
Distribution: gnu
Date: Wed, 16 Dec 1992 15:33:01 GMT

I am trying to use advice.el while I have the new optimizing byte compiler
installed 
;; By Jamie Zawinski <jwz@lucid.com> and Hallvard Furuseth <hbf@ulrik.uio.no>.

(defconst byte-compile-version "2.07; 15-jul-92.")

I then get a warning from byte-compile-lambda, because it does a (memq
'free-vars byte-compile-warnings) where byte-compile-warnings contains t
rather than a list. I suppose byte-compile-lambda is not supposed to be
externally callable. Changing the call to byte-compile-lambda into
byte-compile helps but then any defadvice call in an elisp file disappears
when byte-compiled!!
-- 
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806   Uucp:   uunet!mcsun!ruuinf!piet
Telefax:   +31 30 513791   Internet:  piet@cs.ruu.nl   (*`Pete')

Newsgroups: gnu.emacs.bug
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: Re: name-last-kbd-macro accepts SPC as terminator
Organization: Martin Marietta Western Internal Systems, Technical Operations
Distribution: gnu
Date: Tue, 15 Dec 1992 19:24:15 GMT

In article <9212102239.AA03344@banach> jerry@math.ep.utexas.EDU (Jerry) writes:
>  M-x name-last-kbd-macro RET
>
>followed by
>
>  macro-name-not-finished-because SPC
>
>and the last macro will be given the unfinished (?) name.  I had
>generated a number of macros, giving them all similar names, e.g.,
>latex-macro-1, latex-macro-2, etc.  Upon doing
>
>  M-x name-last-kbd-macro RET lat SPC    (to complete, oops)
>
>and my macro was named "lat" instead.  Is there no way to require a
>newline to terminate a prompted input when using the (interactive
>"SPrompt:") construct?

No.  Here's an excerpt from the elisp manual 'Interactive Codes' info
node:

|`S'
|     An interned symbol whose name is read in the minibuffer.  Any
|     whitespace character terminates the input.  (Use `C-q' to
|     include whitespace in the string.)  Other characters that
|     normally terminate a symbol (e.g., parentheses and brackets) do
|     not do so here.  Prompt.

That interpretation of whitespace also prevents completion of the macro
name from being done.

>---------------- offending function from macros.el ------------------------
>
>
>(defun name-last-kbd-macro (symbol)
>  "Assign a name to the last keyboard macro defined.
>One arg, a symbol, which is the name to define.
>The symbol's function definition becomes the keyboard macro string.
>Such a \"function\" cannot be called from Lisp, but it is a valid command
>definition for the editor command loop."
>  (interactive "SName for last kbd macro: ")
>  (or last-kbd-macro
>      (error "No keyboard macro defined"))
>  (and (fboundp symbol)
>       (not (stringp (symbol-function symbol)))
>       (error "Function %s is already defined and not a keyboard macro."
>	      symbol))
>  (fset symbol last-kbd-macro))

Perhaps it would be more useful if the interactive form were replaced
by:

(interactive
 (list (completing-read "Name for last kbd macro: "
			obarray
			(function
			 (lambda (symbol-name)
			   (let ((symbol (intern symbol-name)))
			     (and (fboundp symbol)
				  (stringp (symbol-function symbol))))))
                        nil ; allow a new name
                        )))
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!

Newsgroups: gnu.emacs.bug
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: try-completion and all-completions documentation
Reply-To: kevin@traffic.den.mmc.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 18:40:25 GMT

Neither the function documentation strings (in Emacs version 18.58) nor
the Emacs Lisp manual entries (version 1.03) document the fact that as
implemented in minibuf.c, the second argument to try-completion and
all-completions may be a non-list function object (e.g. a symbol).  In
that case, the result of try-completion or all-completions is obtained
by calling that functional argument (ALIST) with 3 arguments: the
completion function's first argument STRING, its third argument PRED,
and nil.

No test is performed to insure that the second argument is actually a
functional object; it is called simply because it is neither a list nor
a vector.

In the documentation strings, the second argument is called ALIST; in
the lisp manual it is called ALIST-OR-OBARRAY.

In the documentation strings, the third argument is called PRED; in
the lisp manual it is called PREDICATE.
--
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!

Newsgroups: gnu.emacs.bug
From: macdonal@xerox.com (Dale MacDonald)
Subject: dired not following symbolic links in 18.58
Reply-To: macdonal@xerox.com
Organization: Xerox Corporation, Webster NY
Distribution: gnu
Date: Thu, 17 Dec 1992 00:13:10 GMT

Emacs version: 18.58.10
OS: SunOS 4.1.{1,2,3}

Since moving to 18.58 dired no longer follows symbolic links. All attempts to follow one, either by C-xC-v and giving a name which happens to be a link, or by trying to open or view a link already being displayed in dired.  
(This is particularly annoying around here since ~/ happens to be a symlink.)

Anyone else see this?

---
================================================
Dale MacDonald		|
Xerox PARC		|  Convert a melodic element into a rhythmic element



Newsgroups: gnu.emacs.bug
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: Re: try-completion and all-completions documentation
Reply-To: kevin@traffic.den.mmc.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 18:50:20 GMT

I wrote:

>Neither the function documentation strings (in Emacs version 18.58) nor
>the Emacs Lisp manual entries (version 1.03) document the fact that as
>implemented in minibuf.c, the second argument to try-completion and
>all-completions may be a non-list function object (e.g. a symbol). In
>that case, the result of try-completion or all-completions is obtained
>by calling that functional argument (ALIST) with 3 arguments: the
>completion function's first argument STRING, its third argument PRED,
>and nil.

Sorry, this is not true.  The lisp manual does mention that the second
argument may be a function; in try-completion's entry, the description
of that case follows -- for whatever reason -- the description of the
third argument.  There is also a reference to the following node, which
describes 'Programmed Completion' in detail.  Also, the third argument
passed to the function arg is nil only in the case of try-completion;
all-completions passes t instead.

Mea culpa,

Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!

Newsgroups: gnu.emacs.bug
From: eirik@elf.tn.cornell.edu (Eirik Fuller)
Subject: zero repeat count in search-forward
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Dec 1992 07:05:51 GMT

The documentation for search-forward makes no explicit mention of what
happens if the repeat count is zero.  Whether or not the documentation
is changed to mention this case, I think it would be useful to change
the behavior.  The present behavior is mysterious; it seems like an
unforeseen consequence of the way more usual cases are implemented.

What seems to be happening is this:  if the cursor is near enough the
beginning of the buffer, it stays put and search-forward returns nil.
Otherwise, it moves backward some distance which seems to have nothing
to do with the contents of the buffer, and search-forward returns t.

What I think should happen with a zero repeat count is that
search-forward should leave the cursor where it is and return t,
whether or not the search pattern occurs anywhere in the buffer.  It
seems a conditional early return in search.c:search_command is a
suitable way of doing this.  I don't have diffs for that, but I'm
willing to make some, test them, and send them in if there's any need
for that.

This is more than a philosophical question to me; I was forced by this
mysterious behavior to complicate some elisp code I was writing.

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: C-l in gdb mode
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 19:49:02 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

I think c-l in gdb mode, when there is a prefix argument,
should just do `recenter' with that argument.

Newsgroups: gnu.emacs.bug
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: Re: C-l in gdb mode
Organization: Martin Marietta Western Internal Systems, Technical Operations
Distribution: gnu
Date: Mon, 14 Dec 1992 17:37:03 GMT

In article <9212111949.AA02963@napa.TELEBIT.COM> phr@napa.telebit.com (Paul Rubin) writes:
>In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)
>
>I think c-l in gdb mode, when there is a prefix argument,
>should just do `recenter' with that argument.

I agree that the argument to recenter shouldn't have been disabled, but
I also think that the source code redisplay shouldn't be disabled.
Here's what I use:

;; gdb-recenter allows you to control the display with
;; its prefix arg:

(defun gdb-recenter (&optional arg)
  "*Recenter the display and display the current frame.  The optional
ARG \(prefix argument, if called interactively\) is passed to \\[recenter]."
  (interactive "P")
  (recenter arg)
  (gdb-display-frame))

(setq gdb-mode-hook
      (function (lambda ()
		  (define-key gdb-mode-map "\C-l" (function gdb-recenter)))))
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!

Newsgroups: gnu.emacs.bug