HDTenEightyP/NetNews huggingface dataset:
From: peterf@emerald.csis.dit.csiro.au (Peter A Fletcher)
Subject: 'maximum buffer size exceeded' message with big copy-region-as-kill
Organization: CSIRO Division of Information Technology
Date: Fri, 21 Aug 1992 01:09:51 GMT

Hello!

    I'm using epoch4.1 with a Decstation 5200 Ultrix4.2 and 32M of memory, and epoch has
a little problem.

    If I copy-region-as-kill a lot of text (~1000 lines), then try find-file-other-screen,
epoch says 'maximum buffer size exceeded'.  If I try again, it works.

-peter.
--
Peter Fletcher,            Internet : peterf@csis.dit.csiro.au
PhD Student                Physical : CSIRO Division of Information Technology,
Phone    : +61-6-2750914              ANU, Acton, Canberra ACT AUSTRALIA
-------------------------------------------------------------------------------
Newsgroups: gnu.epoch.misc
From: bob@almeria.inria.fr (Renaud Marlet)
Subject: boundaries of zones-in-region
Organization: INRIA, Sophia-Antipolis (Fr)
Distribution: gnu
Date: Tue, 18 Aug 1992 13:49:50 GMT


If a region starts at some point PS and ends at some point PE, then
unintuitively (zone-in-region (point-min) PS t) includes it. One the
other hand, the converse is ok: (zone-in-region PE (point-max) t) does
not include it. What is correct?

Renaud

(Sorry if you read this message twice)
Newsgroups: gnu.epoch.misc
From: huub@cwi.nl (Huub Bakker)
Newsgroups: gnu.epoch.misc
Subject: (epoch::delete-screen <screen>)
Keywords: bug?
Date: 14 Aug 92 07:04:03 GMT
Reply-To: Huub.Bakker@cwi.nl
Organization: CWI, Centre for Mathematics & Computer Science

The following strange thing happens here. If I call (epoch::delete-screem
<screen>) the screen I want to delete disapears from my display. OK, that's
what I wanted. But the value returned by this function is nil. Something has
been wrong. Creation of a new screen will give a screen number higher than the
number of the deleted one. Is Epoch thinking the screen still exists?
Do I anything wrong or is this a bug in Epoch?

Thanks, Huub.

We are running Epoch 4.0.3 on SGI running Iris 4.0.1.

-- 
CWI, P.O. Box 4079 			Huub Bakker (huub@cwi.nl)
1009 AB Amsterdam
The Netherlands
Tel. 31 20 5924080
Newsgroups: gnu.epoch.misc
From: blk@mitre.org (Brian L. Kahn)
Subject: Re: Bug report - Epoch 4.1 keybindings
Organization: The MITRE Corp. Bedford, MA
	<JWZ.92Aug12134411@thalidomide.lucid.com>
Date: Thu, 13 Aug 1992 15:56:51 GMT


I think that Jamie (jwz@lucid.com) has a good point about the 8bit
patch.  Converting key combinations to a single 8bit character seems
like regression to a less expressive keyboard interpretation.  

Eight bit fonts are clearly a desirable thing, but why does the input
need to be munged?  Are we emulating some strange terminals?

Emacs has a tradition of interpretting "\ev" and "\M-v" to be
identical.  I suggest it is time to make this interpretation optional.
How about honoring the widely accepted interpretation of EMACS as
Escape-Meta-Alt-Control-Shift, and let those of us with Alt and Meta
keys use them directly in the key bindings?  I believe that lemacs
does this easily.  I've got enough bindings that I don't need to
disrupt the association between meta and escape, but I can see why
others might want to.

If we bind the Meta key the same as the ESC key by default, then \ev
and \M-v still work the same, as expected.  If someone wants to use
the meta key for inserting 8bit characters, bind meta to a map filled
by self-insert-key-8bit and everyone is happy.  Yes?  No?


BTW, it is nice to see Jamie contributing here, even though lemacs is
in some sense competitive with epoch.  I personally like the lemacs
input model very much, and I think it would be good if epoch and
emacs-19 go that direction.

--
B<   Brian Kahn   blk@security.mitre.org   "may the farce be with you"

Newsgroups: gnu.epoch.misc
From: ckd@eff.org (Christopher Davis)
Subject: C-g handling delayed?
Organization: Electronic Frontier Foundation Tech Central
Date: Wed, 12 Aug 1992 17:06:54 GMT

C-g seems to be noticably slower in 4.1 to stop long processes (say,
processing a newsgroup of 1400 articles in GNUS) or even so slow as to
make no difference (I can't seem to abort a GNUS startup except by
killing epoch from twm).

This is relative to 4.0p0, so I don't know when it broke.
--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
            ``Ed Gruberman, you fail to grasp Ti Kwan Leep.
            Approach me that you might see.'' -- The Master
Newsgroups: gnu.epoch.misc
From: kaplan@marula.cs.uiuc.edu (Simon Kaplan)
Subject: 4.1 meta, blinking etc bugs
Organization: University of Illinois at Urbana-Champaign
Distribution: gnu
Date: Wed, 12 Aug 1992 13:52:27 GMT

I'm going to make a 4.2 distribution later today or tomorrow.  It will 
basically be 4.1 with the display and meta patches applied.  There will
also be a new hook for making the scrollbar interface to the widget server
work properly.

Our apologies for these problems.  Unfortunately Marc A. is on vacation,
and this has caused the delay in getting these problems fixed.  Thanks to
those who contributed patches.

Simon Kaplan
--
Simon Kaplan					ConversationBuilder Project
Human-Computer Interaction Lab			
Department of Computer Science			kaplan@cs.uiuc.edu 
University of Illinois at Urbana-Champaign	uiucdcs!kaplan@uunet.uu.net
1304 W. Springfield Ave				phone: +1 217 244 0392
Urbana Illinois 61801, USA			fax:   +1 217 333 3501
Newsgroups: gnu.epoch.misc
Subject: Displaying 8-bit input
From: goodhear@husc9.Harvard.EDU (Eric Goodheart)
Date: 21 Aug 92 16:13:27 EDT
Distribution: world
Organization: Harvard University Science Center
Keywords: Epoch 4.1

Does epoch 4.1 allow one to display 8-bit characters?  

Please respond by e-mail.

Thanks in advance,

Eric

Newsgroups: gnu.epoch.misc
From: bob@almeria.inria.fr (Renaud Marlet)
Subject: Re: 8 bits characters blink
Organization: INRIA, Sophia-Antipolis (Fr)
Distribution: gnu
Date: Wed, 12 Aug 1992 15:40:27 GMT


I got mixed up with different versions and patches. The bug does exist for
version 4.1 (8 bits characters blink when the mouse pointer goes from one
window to another), but the patch I sent does not correct it. Apparently,
Chris's previous patch is indeed included in epoch4.1 but something must
have changed and it does not work anymore. I can't understand why.

Forget it then. Sorry about that.

Renaud
Newsgroups: gnu.epoch.misc
From: Jamie Zawinski <jwz@lucid.com>
Subject: Re: Bug report - Epoch 4.1 keybindings
Organization: Lucid, Inc., Menlo Park, CA
X-Windows: Dissatisfaction guaranteed.
Date: Wed, 12 Aug 92 20:44:16 GMT

I don't think that the patches Epoch is using for 8-bit support can be made
to work sensibly without a serious redesign.  I would consider any of the
following changes to be unacceptable, because they would break so much
existing code:

  -  "\M-x" not producing a string of the single character \370
  -  "\ex" not producing a string of the two characters \033 \170
  -  define-key interpreting the strings "\370" and "\033\170" differently
  -  lookup-key interpreting the strings "\370" and "\033\170" differently

In GNU Emacs, keymaps are tables indexed by 7-bit ASCII codes.  "Meta"
characters, which are sometimes implemented by turning on the high bit of 
an ASCII code, are stored in a sub-keymap which is indexed under the "escape"
character.

What these patches do is make keymaps be indexed by 8-bit codes *as well as*
the old method of using a sub-map indexed by escape.  This is paradoxical.
You can't have it both ways.

In Lucid Emacs, we have reimplemented keymaps so that they are not indexed by
7-bit or 8-bit codes, but rather by the symbolic names for the keys.  (This
change is largely transparent to the user, since define-key and lookup-key
still work in emacs18 compatible ways.)  If your keyboard generates a
character, you can bind a command to it, whether that character has an ASCII
equivalent or not.  Meta-x and oslash are distinct; Meta-oslash is also
distinct.

It is a mistake to think of the "meta" key as setting the high bit on a
character.  That is an implementation detail.  It is misguided for software
which has access to the keyboard beyond what ASCII provides (that is, all X
software) to interpret a "meta" chord as meaning "insert a non-ASCII
character."  That's what the "Alt Gr" key (which X knows as Mode_shift) is
for.  
	-- Jamie

(PS: Lucid Emacs 19.2 -- labrea.stanford.edu: pub/gnu/lucid/)
From: carroll@cs.uiuc.edu (Alan M. Carroll)
Newsgroups: gnu.epoch.misc
Subject: Re: (epoch: :delete-screen <screen>)
Date: 14 Aug 92 21:20:51 GMT
Distribution: gnu
Organization: Technophiles Inc. - Engineers with Attitude

In article <9208140703.AA01731@madelief.cwi.nl>, huub@cwi.NL (Huub Bakker) writes:
> Creation of a new screen will give a screen number higher than the
> number of the deleted one. Is Epoch thinking the screen still exists?

Everything is fine. Screen numbers always increase, they are never
re-used.

-- 
Alan M. Carroll          "Weren't there yams involved, too?" - J. Ockerbloom
Epoch Development Team   
Urbana Il.               "I hate shopping with the reality-impaired" - Susan
Newsgroups: gnu.epoch.misc
From: MEHRDAD@glum.DEv.cf.ac.UK
Subject: EPOCH on VMS
Organization: Gnus Not Usenet
Distribution: gnu
Date: Thu, 13 Aug 1992 14:58:00 GMT

I am running VMS-5.5 and MOTIF, is there a version of Epoch ported to this
configuration ? If yes, where can I find it?

Please reply directly, I do not subscribe to this news group.

	Many Thanks

		Mehrdad
From: c23mts@kocrsv01.delcoelect.com (Mike Scheidler)
Newsgroups: gnu.epoch.misc
Subject: Preferred pronunciation for Epoch?
Date: 14 Aug 92 21:24:49 GMT
Reply-To: c23mts@kocrsv01.delcoelect.com
Organization: Delco Electronics Corp.
Originator: c23mts@kocrsw12


I'm preparing to give a presentation on the virtues of Epoch to some of my
colleagues, and was wondering how people (especially Epoch's developers)
pronounce the name of this tool.  My dictionary lists both "eh-puk" and
"ee-pok" as acceptable.

Is this FAQ material?

Thanks,

-- 
 Mike Scheidler                    INTERNET:  c23mts@kocrsv01.delcoelect.com
 Software Technology               UUCP:      deaes!c23mts
 Delco Electronics Corporation     PHONE:     (317) 451-0642
 Kokomo, IN 46904                  GMNET:     8-322-0642
Newsgroups: gnu.epoch.misc
From: bob@almeria.inria.fr (Renaud Marlet)
Subject: 8 bits characters blink
Organization: INRIA, Sophia-Antipolis (Fr)
Distribution: gnu
Date: Wed, 12 Aug 1992 13:05:43 GMT


I reported 3 months ago a bug in the display of 8 bits characters (version
4.0p1). It was corrected by Chris Love in version 4.0p2. But that damned
bug is back in version 4.1... Here is the patch that Chris designed.

Renaud


----patch follows----
*** xdispepoch.c.orig	Tue May 12 09:58:19 1992
--- xdispepoch.c	Tue May 12 09:59:03 1992
***************
*** 2739,2745 ****
  	    {
  	      if (overwrite_count && numchars < overwrite_count)
  		c = *overwrite_string++;
! 	      if ((cb->ch != c) || (cb->style != style) || replot_lines)
  		{
  		  ADD_CHAR(c,1);
  		  Changed = Changed ? Changed : prev;
--- 2739,2746 ----
  	    {
  	      if (overwrite_count && numchars < overwrite_count)
  		c = *overwrite_string++;
! 	      if (((unsigned char) cb->ch != c) || (cb->style != style) || 
!                   replot_lines)
  		{
  		  ADD_CHAR(c,1);
  		  Changed = Changed ? Changed : prev;
----patch ends----
Newsgroups: gnu.epoch.misc
From: vincenzes@apollo.hp.com
Subject: Epoch 4.1 and C-z bindings
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 08:05:41 GMT


I started running epoch-4.1 on my HP-UX 720 system and the C-z key bindings were 
not there.  Seems that epoch-lisp/epoch.el has changed from 4.0: define-prefix-command
and define-key are used to set up named maps rather than just a bunch of 
global-set-key calls.

Now epoch.el does
   (global-set-key "\C-z" 'epoch-cmds-prefix)

but the define-key for map entries is done on a variable, not the symbol. E.g.:
   (define-key epoch-cmds-map "r" (definteractive (raise-screen)))

The variable is set to (symbol-function 'epoch-cmds-prefix) BEFORE the map is
set up, thus the map that 'epoch-cmds-prefix points to is never set up.

Putting the following in my .emacs file "fixes" things
    (fset 'epoch-cmds-prefix epoch-cmds-map)
    (fset 'other-screen-prefix other-screen-map)

Is this a bug?  Is there a better way of setting the C-z prefix to the correct map?

Mark Vincenzes
Newsgroups: gnu.epoch.misc
From: lystad@m2.dseg.ti.com (Garr Lystad)
Subject: Re: Bug report - Epoch 4.1 keybindings
Organization: TI DSEG, Spring Creek, Plano, Tx.
	<JWZ.92Aug12134411@thalidomide.lucid.com>
	<LYSTAD.92Aug13103616@m2.dseg.ti.com>
	<BLK.92Aug13105651@vanity.mitre.org>
	<JWZ.92Aug13130655@thalidomide.lucid.com>
Reply-To: Garr.Lystad@m2.dseg.ti.com
Date: Fri, 14 Aug 1992 15:05:55 GMT

Possibly my previous comments were too verbose.  The essence of my
thoughts on input characters is just this:

1. As Jamie said "...emacs knows where your *fingers* are."  I'd like
   keymaps to provide a binding flexibility that reflects that
   knowledge.
2. For compatibility, keymaps should be capable of being arranged so
   that ESC gets you to the same place as a meta modifier bit.
3. I'd like to be able to call read-char, or something, and have my
   code know where the user's fingers are too.
4. I'd like mouse buttons to be treated pretty much as other keys, as
   far as keymaps and read-char are concerned.  Button up or down
   information should be included in distinguishing button strokes,
   unlike other keystrokes.  And something analogous to last-command-char
   should be provided for commands to get positional information for
   the last-command-char if it was a 'mouse character'. 

Well, that's my wish list.

  --  Garr
Newsgroups: gnu.epoch.misc
From: mthome@bbn.com
Subject: Patches to 8-bit mods help, but aren't enough
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 06:13:27 GMT

	The two patches which were posted recently to the 8-bit
modifications to epoch do, indeed fix the case where you bind a
function to a \M- sequence with an elisp file at load-time.  What
neither addresses is the remaining problem where bindings in .elc
files compiled by unpatched, non-8-bit, or earlier versions of
emacs/epoch continue to get the bad bindings.
	The good news is that I haven't had Epoch 4.1 crash yet.

Suggestions gratefully accepted...
	-mik (mthome@bbn.com)
Newsgroups: gnu.epoch.misc
From: stud01@cc4.kuleuven.ac.be (Barbe Albert)
Distribution:  na
Date: Wednesday, 12 Aug 1992 17:57:55 +02
Organization: K.U.Leuven - Academic Computing Center
Subject: Re: Motion and screen focus

In article 1992AUG8.012223.13563@TERA.COM, RICHK@TERA.COM writes:
>
> I am running 4.0p2 on a decstation, Ultrix 4.1, X11R4 and twm. I have
> this problem with epoch3.2 as well. When I start up epoch, the mouse is
> tracked so that the epoch cursor is active in the epoch window where the
> mouse is. After using things for awhile this goes away and I have to click
> into a screen to get the epoch cursor to become active. I can see from the
> way that twm highlights the title bar, that twm knows the mouse is in that
> window, but epoch doesnt realize this until I press a mouse button. I've
> scanned motion.el and mouse.el but they both seem to deal with other topics.
> Can anyone help me on this. It is driving me *crazy*. Thanks
> 	richard
>
>
I have the same problem. Everything goes well for a while , and then suddenly
I have to click in an epoch window to make it active.
I am running epoch 4.0p2 on aix PS/2 and aix370 with X11R5 and gwm .
--
------------------------------------------------------------------------
Barbe Albert       stud01@cc4.kuleuven.ac.be   (AIX/370)
                   FHGAA98@cc1.kuleuven.ac.be  (VM/CMS)
Newsgroups: gnu.epoch.misc
From: jbw@cs.bu.edu (Joe Wells)
Subject: Re: useless files in Epoch distribution...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 16 Aug 1992 15:17:30 GMT

>>>>> "Mike" == Mike Gallaher <mg@bds.bds.com> writes:

  Joe> * BABYL, CCADIFF, DIFF, GOSDIFF, ONEWS, OONEWS
  Joe>   These files are useful documentation.

Mike> Is anyone really using CCA Emacs anymore?  Or Gosling 264 Emacs
Mike> (or unipress 1.0)?  I don't think it's useful to describe how
Mike> Gnu emacs differs from ancient versions of Emacs that no one
Mike> even remembers anymore.

These files tell you a lot about the design decisions that were involved
in GNU Emacs.  I think it is very useful.  I learned a lot about Emacs by
reading them.

BTW, CCA Emacs is still being sold.  I'm not sure about Unipress.

-- 
Joe Wells <jbw@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details
Newsgroups: gnu.epoch.misc
Distribution: world
Followup-To: 
From: meyerm@hp700.trg.saic.com (Michael Meyer)
Reply-To: meyerm@hp700.trg.saic.com
Organization: Science Applications International Corp.
Subject: Incorrect title on initial epoch window
Keywords: 
Date: Tue, 18 Aug 1992 16:34:02 GMT

Just built epoch 4.1 on an HP730 and all is well (caveats to previously
mentioned 4.1 bugs), except for one little aesthetic glitch.  Pardon my
ignorance, but is the initial window in epoch supposed to be named
*scratch* even if epoch is invoked with a filename argument.  Mine is.

Is this a glitch or a feature, or am I doing something wrong?  In any
event how do I get epoch to title the window automatically with the name
of the file that I used as argument?

aTdHvAaNnKcSe

-- Mike

P.S.  All subsequent windows ARE titled correctly with the filename supplied
to the Control-x-f command.

___________________________________________________________________________
Michael S. Meyer                             meyerm@hp700.trg.saic.com
Technology Research Group                               619-546-6097  voice
Science Applications International Corporation          619-546-6777    fax
San Diego, CA
___________________________________________________________________________
Newsgroups: gnu.epoch.misc
From: voss@cs.uiuc.edu (Bill Voss)
Subject: Xemacs style keybindings (by request)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 15 Aug 1992 11:52:30 GMT

	Someone (I forget who) recently asked me to post my bindings, so
here they are.  Use, improve, abuse, whatever...

					Bill Voss

	When I switched from Xemacs to Epoch I wanted Epoch to look as
much like Xemacs as possible.  To that end I wrote a tiny little shell
script:

#!/bin/sh
/local/all/epoch -nm ${@} &

which I bound to my window manager's "e" key, and added to the menus
where emacs had previously appeared.

	I also added some simple bindings, and wrote a tiny little elisp
function.  The guiding idea was that I should normally be able to forget
if I was running Xemacs, or Epoch.  Thus the old Xemacs bindings should
appear to work unchanged, especially the old C-xC-c binding.  However,
having C-xC-c shut down all of Epoch was unacceptable.  I also needed
easy to remember Epoch bindings to popup new windows.  So I changed
C-xC-c to only shut down the current window, and made C-zC-c shut down
the entire Epoch process.  I also duplicated the old C-xC-f and C-xb
bindings with Epoch versions C-zC-f and C-zb which open new windows.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; From my ~/.emacs file.  Tested under Epoch 4.0.1
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This function simulates the old Xemacs \C-x\C-c binding.
;;
(defun my-epoch-delete-or-exit ()
  (interactive)
;;
;;  If there is only one screen open, behave like Xemacs and shut down.
;;
  (if (eq (current-screen) (next-screen))
      (save-buffers-kill-emacs)
    (progn
;;
;;  If there are multiple screens open, just save the file in this
;;  screen, and shut this screen down.
;; BUG:  This really should handle the possiblity of multiple
;; BUG:  files open in a single screen, and not just one file.
;;
      (if (buffer-modified-p)
	  (progn 
	    (if (y-or-n-p (if buffer-file-name
			      (format "Save file %s? "
				      buffer-file-name)
			    (format "Save buffer %s? " (buffer-name))))
		(save-buffer))
	    (message "")))   ;; Work around for Echo Area Bug.
      (delete-screen))))
;;
;; I don't want Epoch to give itself airs, so don't auto-raise
;; also add my personal bindings.
;;
(if (boundp 'epoch::version)
    (progn
      (setq auto-raise-screen nil)
      (global-set-key "\C-z\C-f" 'find-file-other-screen)
      (global-set-key "\C-zf" 'find-file-other-screen)
      (global-set-key "\C-z\C-b" 'find-buffer-other-screen)
      (global-set-key "\C-zb" 'find-buffer-other-screen)
      (global-set-key "\C-z\C-c" 'save-buffers-kill-emacs)
      (global-set-key "\C-z\C-d" 'remove-screen)
      (global-set-key "\C-x\C-c" 'my-epoch-delete-or-exit)
      )
  )
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Newsgroups: gnu.epoch.misc
From: lystad@m2.dseg.ti.com (Garr Lystad)
Subject: SGI C-g clobbers event-handler bug
Organization: TI DSEG, Spring Creek, Plano, Tx.
Reply-To: Garr.Lystad@m2.dseg.ti.com
Distribution: gnu
Date: Fri, 14 Aug 1992 17:16:29 GMT

I have found that when running a lengthy tag search on a Silicon
Graphics Indigo machine and I do a C-g to abort, that the search does not
abort and after it finishes the variable epoch::event-handler has the
value nil.  I do not touch the mouse during all this.

I've looked at what seems to be the relevant code and sort of guess
that the 

   if (x_in_handler_hook && !EQ(Vx_event_handler_abort,Qnil))
      Vx_event_handler = Qnil;  

in signal is responsible for the assignment, though I don't see how
the test passes. 

I tried all this on a sun also, but the tag-search aborts, and all is
well.

Distantly related to the above: 

In looking to see who touched epoch::event-handler I happened to look
at epoch::wait-for-event.  Wouldn't an unwind-protect be appropriate
there to protect epoch::event-handler?

(defun epoch::wait-for-event (event-type function)
  "Wait for EVENT, calling FUNCTION as handler when it occurs, then return."
  (setq epoch::old-handler epoch::event-handler) 	; save old handler
  (setq epoch::wait-event event-type)
  (setq epoch::wait-function function)
  (setq epoch::event-handler 'epoch::wait-handler)
  (while epoch::wait-event
    (epoch::dispatch-events)
    (sit-for 1) )
  (setq epoch::event-handler epoch::old-handler) )

  --  Garr

p.s.  Is this the right place to report bugs?
Newsgroups: gnu.epoch.misc
From: rick@cadillac.siemens.com (Rick Taft)
Subject: bug-report -> meta problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 18 Aug 1992 19:48:43 GMT

	 Epoch version 4.1 compiled on
	 Sun SPARCstation 1  (sun os 4.1) with the
	 /bin/cc C compiler that comes with the machine;
	 Running X11R5 and mwm

	 Nothing out of the ordinary.

	 EIGHTBIT_KEYBOARD is NOT defined.

	 Problem:  The using the meta-key hangs epoch.  Typing any key
	 while meta is held down (e.g., trying to move foreward by a
	 word with <meta>-f) causes epoch ignore all subsequent typing
	 and to ignore selecting "Close" from mwm's window menu.  (I
	 have to use the kill command.)

	 Using the escape key works as it should.

	 Meta works fine under the same configuration with epoch
	 4.0p2.

	 Any suggestions?

	 -Rick Taft
			   rick@siemens.com
		   Siemens Corporate Research, Inc.
	     755 College Road East, Princeton, NJ  08540
			    (609) 734-3324
Newsgroups: gnu.epoch.misc
From: lahtinen@gideon.fmi.fi (Kimmo Lahtinen)
Subject: epoch and ISC 3.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 09:04:57 GMT

I have build epoch 4.1 to ISC 3.0 and it works but sometimes it
refuses to start (about once in 5 times). I think the problem is
in the s-isc2-2.h. I modified it somewhat, but I am not sure if it
is correct, so could someone mail me a correct file. Actually I think
it would be nice to have it also in distribution.

Also I am wondering why gnus run so slooow. 

-- 
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Kimmo Lahtinen                      E-Mail : lahtinen@gideon.fmi.fi       
Finnish Meteorological Institute    Phone  : +358 0 758 1322
Possessed by a Spirit               G3 Fax : +358 0 758 1396