HDTenEightyP/NetNews huggingface dataset:
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: [mickeyf@vnet.ibm.com: epoch: get Sun Copy, paste keys to work]
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 10:06:38 GMT

Forwarded note...

------------------------------------------------------------------------------
Return-Path: <mickeyf@vnet.ibm.com>
Date: Wed, 2 Sep 92 09:27:59 PDT
From: "Mickey Ferguson" <mickeyf@vnet.ibm.com>
To: MICKEYF@vnet.ibm.com, MARCA@ncsa.uiuc.edu
Subject: epoch: get Sun Copy, paste keys to work

Well, I'd like to get the mouse and the function keys working.  Right now,
the mouse buttons don't work as they should (my definition of 'should' :).
The left button highlights (underlines) the text (this is fine), but then
the right button extends the highlight portion.  For the rest of my windows
it is the middle button that does this.  And then the middle button is the
one which inserts the copied region.  Strange...

OK, now to some specific questions which might help solve my problems.  Do
you know the function which is invoked for each of the mouse operations?
If so, I could use the proper functions to remap the Copy, Paste, and Cut
keys, since the mouse functions do some of the operations I'm looking for,
but I don't know what they are called...

Mickey Ferguson -- Rolm -- FergusoM at scrvm2 -- mickeyf@vnet.ibm.com
------------------------------------------------------------------------------

Newsgroups: gnu.epoch.misc
From: nhi@deveel.aero.org (Nhi Casey)
Subject: batch mode
Organization: The Aerospace Corporation; El Segundo, CA
Date: Tue, 1 Sep 1992 17:39:48 GMT


Hi,

I'm having trouble compiling .el files from the UNIX command.

I tried:

/usr/local/bin/epoch -batch -f batch-byte-compile myfile.el

and got:

Fatal error (11).Segmentation fault (core dumped)

myfile.el worked with the M-x byte-compile-file command no problem.

Any help would be appreciated.

Nhi Casey
nhi@deveel.aero.org
Newsgroups: gnu.epoch.misc
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: cannot build on sparc w/sunos4.1.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 11:47:09 GMT

A couple potential trouble spots:

(1) ascii/config.h-dist is, by default, configured for BSD 4.2 running
    on a VAX; if you didn't change it to SunOS/sparc, that would be
    bad.

(2) The missing lisp libraries are because the toplevel Makefile
    points to /usr/local/lib/epoch by default, but you haven't put the
    Epoch source code in that location.  That's fine, as long as you
    make sure the libraries end up there by the end of installation.

Otherwise, I don't see this problem under SunOS 4.1.2, and haven't
heard about it before, and nothing has changed in that part of the
code for quite a while...

Marc

--
Marc Andreessen
Epoch Development Team
University of Illinois at Urbana-Champaign
marca@ncsa.uiuc.edu
From: shankar@sgi.com (Shankar Unni)
Newsgroups: gnu.epoch.misc
Subject: Patch for "unexmips.c" (SGI & MIPS)
Date: 28 Aug 92 02:25:24 GMT
Organization: Silicon Graphics, Inc.


Here is a patch for "unexmips.c" to make it work with the latest
release of SGI compilers (the 3.10 compilers) on the Irix 4.0.5
platform. This should continue to work with the old 2.* compilers as
well as the MIPS compilers.

The reasons for this patch:

 (a) The order of sections seems to have been changed in the latest
     release. Since we can't rely on the order, we need to linearly scan
     the section list in the header for each section we are interested
     in. Thus, we need to adjust the s_[vp]addr for rdata_section.

 (b) The symbol-table is no longer at the end of the file - it now seems
     to be between the text and data sections.  Thus, we need to adjust
     the scnptr for rdata_section, too.

============================== snip snip ==============================
*** unexmips.c.orig	Fri Aug  7 14:36:00 1992
--- unexmips.c	Thu Aug 27 19:10:46 1992
***************
*** 152,158 ****
--- 152,164 ----
        exit(1);
      }
  
+ /*
+  * The headers are no longer in text-init-rdata-data order. Therefore we 
+  * have to do a linear search for each section in the section list.
+  */
  #define CHECK_SCNHDR(ptr, name, flags) \
+   i = 0; ptr = NULL; \
+   while(i < hdr.fhdr.f_nscns && !ptr) { \
    if (strcmp(hdr.section[i].s_name, name) == 0) { \
      if (hdr.section[i].s_flags != flags) { \
        fprintf(stderr, "unexec: %x flags where %x expected in %s section.\n", \
***************
*** 159,171 ****
  	      hdr.section[i].s_flags, flags, name); \
      } \
      ptr = hdr.section + i; \
-     i += 1; \
    } \
!   else { \
!     ptr = NULL; \
!     }
  
-   i = 0;
    CHECK_SCNHDR(text_section,  _TEXT,  STYP_TEXT);
    CHECK_SCNHDR(init_section,  _INIT,  STYP_INIT);
    CHECK_SCNHDR(rdata_section, _RDATA, STYP_RDATA);
--- 165,174 ----
  	      hdr.section[i].s_flags, flags, name); \
      } \
      ptr = hdr.section + i; \
    } \
!   i += 1; \
!   }
  
    CHECK_SCNHDR(text_section,  _TEXT,  STYP_TEXT);
    CHECK_SCNHDR(init_section,  _INIT,  STYP_INIT);
    CHECK_SCNHDR(rdata_section, _RDATA, STYP_RDATA);
***************
*** 198,203 ****
--- 201,212 ----
  
    hdr.aout.bss_start = hdr.aout.data_start + hdr.aout.dsize;
    rdata_section->s_size = data_start - DATA_START;
+ 
+   /* adjust start and virtual addresses of rdata_section, too */
+   rdata_section->s_vaddr = DATA_START;
+   rdata_section->s_paddr = DATA_START;
+   rdata_section->s_scnptr = text_section->s_scnptr + hdr.aout.tsize;
+ 
    data_section->s_vaddr = data_start;
    data_section->s_paddr = data_start;
    data_section->s_size = brk - data_start;
============================== snip snip ==============================

--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-390-2072
Newsgroups: gnu.epoch.misc
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: epoch 4.0p1 coredumps in query-replace
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 1 Sep 1992 21:14:31 GMT

--> On Wed, 2 Sep 92 08:17:59 GMT, browning@willard.nas.nasa.gov
--> (David S. Browning) said:

  /david/ [Epoch 4.0p1 on an SGI IRIS under IRIX 4.0.1.]

  /david/ I recall there being some discussion a while back about
  /david/ epoch crashing and dumping core during a query-replace after
  /david/ several strings were replaced.  I also thought somebody
  /david/ asked for copies of the victims core files (or stack traces)
  /david/ to help track down the bug.  Was that true?  Is this bug
  /david/ still a problem, or has it been fixed in 4.2?  (I'm
  /david/ reluctant to change and rewrite my .el files given the \M-
  /david/ vs. \e- debacle.)

Debacle.  I like that.  :-}

4.2 fixes the \M- problem, so you'd be safe to upgrade.

I use query-replace quite a bit and I've never had this particular
coredump (on the same platform), but I'll take a look...

Thanks,

Marc

--
Marc Andreessen
Epoch Development Team
University of Illinois at Urbana-Champaign
marca@ncsa.uiuc.edu

Newsgroups: gnu.epoch.misc
From: peterf@zuben.csis.dit.csiro.au (Peter A Fletcher)
Subject: Local minibuffer prompt bug in epoch-4.2
Organization: CSIRO Division of Information Technology
Date: Mon, 31 Aug 1992 23:17:59 GMT

Hello!

    I have posted this bug before for epoch4.0 and epoch4.1, but it
still exists in epoch4.2 so I'm posting it again (although I don't
know if my posting actually reached anyone before).

    I use epoch with a local minibuffer.  Quite often when a prompt
should appear in the minibuffer, the cursor appears at the begiining
of a blank minibuffer line; a backspace puts the cursor on top of the
final character in the line.

    This problem is more disconcerting when epoch is expecting a (y/n)
answer and the prompt does not appear, because the cursor stays in the
buffer and there is no way to tell what epoch is doing.

-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
-------------------------------------------------------------------------------
Xref: sparky gnu.epoch.misc:840 comp.windows.x:15731
From: kelem@xilinx.com (Steve Kelem)
Newsgroups: gnu.epoch.misc,comp.windows.x
Subject: epoch 4.1 crashes X11R4
Date: 26 Aug 92 23:02:40 GMT
Organization: Xilinx Inc.

I'm running epoch 4.1 on a Sparc 2, OS 4.1.1 with X11R4 under motif.
I have two windows, the Minibuffer and a working window, arranged vertically
the working window against the top of the screen, the Minibuffer against the
bottom of the screen and a little space in between the two.

Every once in a while, while I'm typing in epoch, a rectangular area,
containing both epoch windows, AND THE BACKGROUND IN BETWEEN THE TWO WINDOWS,
is erased and the keyboard and mouse are rendered ineffective.  After 10 or 20
seconds the X window system disappears and I'm logged off of the Sun.
A core dump of XSun is left in my home directory.

adb prints the following call trace:
core file = core -- program ``Xsun''
SIGSEGV 11: segmentation violation
$c
_cfbFillBoxSolid(0x0,0xf770f120,0xfffffe86,0xfffffe87,0x0,0xffffffff) + 2a0
_cfbPaintWindow(0xdd7f8,0xc1b90,0x0,0x0,0x0,0x1) + 16c
_miSpritePaintWindowBackground(0xdd7f8,0xc1b90,0x0,0xffffffff,0x1a3,0xbd0e8) +
7
4
_miClearToBackground(0xdd7f8,0xc1b90,0x200,0x2d0,0xfff2,0x0) + 140
_miSpriteClearToBackground(0xdd7f8,0x2,0x200,0x2d0,0xfff2,0x0) + 120
_ProcClearToBackground(0xe2298,0xf4,0x24,0x574,0xdd7f8,0x10c304) + a0
_Dispatch(0xf7ffe998,0x0,0x10000,0xb8d4c,0xe2298,0x10) + 1c4
_main(0x2,0xf7ffec64,0x1,0xae400,0x4,0x1) + 4ac


Does anyone know what the problem is here?
Thanks,
/7\'7  Steve Kelem	(408)879-5347		kelem@xilinx.com
\\ `   Xilinx					FAX: (408)559-7114
//     2100 Logic Drive
\\/.\  San Jose, California 95124
-- 
/7\'7  Steve Kelem	(408)879-5347		kelem@xilinx.com
\\ `   Xilinx					FAX: (408)559-7114
//     2100 Logic Drive
\\/.\  San Jose, California 95124
Newsgroups: gnu.epoch.misc
From: browning@willard.nas.nasa.gov (David S. Browning)
Subject: epoch 4.0p1 coredumps in query-replace
Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
Date: Wed, 2 Sep 92 08:17:59 GMT
Reply-To: browning@willard.nas.nasa.gov

[Epoch 4.0p1 on an SGI IRIS under IRIX 4.0.1.]

I recall there being some discussion a while back about epoch crashing
and dumping core during a query-replace after several strings were
replaced.  I also thought somebody asked for copies of the victims
core files (or stack traces) to help track down the bug.  Was that
true?  Is this bug still a problem, or has it been fixed in 4.2?  (I'm
reluctant to change and rewrite my .el files given the \M- vs. \e-
debacle.)

I ask because it just happened to me -- luckily the autosave had
everything but the query-replace, which I repeated without incident.

To give you a taste, here's a bit from the dbx session.
Unfortunately, it was compiled with (MIPS) cc -O, not -g, so this
stack trace may be utter garbage.  (Well, its clearly garbage, but
maybe its not SUPPOSED to be garbage.)


WILLARD-3> dbx bin/epoch
dbx version 2.10 11/15/91 2:02
Type 'help' for help.
Reading symbolic information of `bin/epoch' . . .
Process name from core dump: epoch
Process died at pc 0x495658 of signal : Segmentation fault
[using memory image in core]
(dbx) where
>  0 .kill.kill(0xf7b, 0xb, 0x0, 0x0, 0x1278, 0x49b95c) ["sys/kill.s":14, 0x495654]
   1 fatal_error_signal(0xb, 0xb, 0x0, 0x0, 0x7fffb440, 0x1342) ["emacs.c":191,0x426b94]
   2 try_layout_id(0x1415c308, 0xb, 0x0, 0x0, 0x2, 0x4) ["xdispepoch.c":1986, 0x41de24]
   3 try_layout_id(0x1028e63c, 0xb, 0x0, 0x0, 0x4bb, 0x803c3d0) ["xdispepoch.c":1777, 0x41d594]
   4 <past end of a.out text>(0xf7b, 0xb, 0x0, 0x0, 0xffffffff, 0xffffffff) [0x1006c5ac]

warning: address 0xfffffffc for 4 bytes is not in the core file

warning: address 0xfffffffc for 4 bytes is not in the core file
(dbx) q


-- David

|============================================================================|
| Internet:  browning@willard.nas.nasa.gov          Phone:  (415) 604-4321   |
| UUCP:      uunet!ames!nas.nasa.gov!browning                                |
|----------------------------------------------------------------------------|
|"the nice thing about true hopelessness is that you don't have to try again"|
| -- jules shear                                                             |
|============================================================================|
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Newsgroups: gnu.epoch.misc
Subject: Epoch coredump reports
Date: 27 Aug 92 02:57:31 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Please continue to report Epoch coredumps that aren't fixed by
4.1/4.2; I may think I've fixed them when I actually haven't, so I
wouldn't mind knowing....

Marc

--
Marc Andreessen
Epoch Development Team
University of Illinois at Urbana-Champaign
marca@ncsa.uiuc.edu
Newsgroups: gnu.epoch.misc
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: FAQ volunteer?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 25 Aug 1992 15:07:54 GMT

Anyone wanna volunteer to maintain the Epoch FAQ (and keep it up to
date)?  Pay's lousy, but benefits are fantastic.

Marc

--
Marc Andreessen
Epoch Development Team
University of Illinois at Urbana-Champaign
marca@ncsa.uiuc.edu

Newsgroups: gnu.epoch.misc
From: Rick.Riolo@um.cc.umich.edu
Subject: problem making epcoh 4.0 on rs6000/os 3.1.6
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 23:21:28 GMT

 I had a couple of problems installing epoch 4.0 on an rs6000 running
 aix 3.1.6 (with x11r4).  One I patched by ok, probably, the other I have
 not solved:
 
 1. in sysdep.c, there is
      extern TEXT_END;
    and another extern with DATA_END.  But in m-ibmrs6000.h, those are
    defined as 0, so those extern's fail.  I just commented them out
    and got past the compilation error.
 
 2. when doing the following link, near the end of xmakefile (I think),
    the following happens:
 
         cc -Wl,-bnso,-bnodelcsect,-bI:/lib/syscalls.exp   -o temacs  window.o
  term.o x11term.o x11fns.o xevent.o screen.o xdefault.o xresource.o property.o
  selection.o xutil.o mouse.o button.o xdispepoch.o dispepoch.o      emacs.o
  keyboard.o macros.o keymap.o sysdep.o   buffer.o filelock.o insdel.o marker.o
  minibuf.o fileio.o dired.o filemode.o   cmds.o casefiddle.o indent.o search.o regex.o
  undo.o    alloc.o data.o doc.o editfns.o callint.o        eval.o fns.o print.o
  lread.o    abbrev.o syntax.o unexaix.o mocklisp.o bytecode.o       process.o
  callproc.o    doprnt.o lastfile.o alloca.o  hftctl.o -lX11     -lrts
0706-317 ERROR: Unresolved or undefined symbols detected:
                  Symbols in error (followed by references) are
                  dumped to the load map.
 .XSetWMNormalHints
 .XGetWMNormalHints
 
 As you can see, it can't find those 2 X routines.  They indeed do not seem to be
 on this system, nor in the man pages.  (XSetWMHints is there, as is
 XSetNormalHints,
 but not the combined form!).
 
 As I mentioned above, I used m-ibmrs6000.h, and s-aix3-1.h, and
 just make install-aix to do it.
 
 thanks very much for any help you can give.
   - r 
Newsgroups: gnu.epoch.misc
From: rscott@phoenix.stpaul.ncr.com (R. Scott Cummings)
Subject: lisp/term files not in epoch-4.1.tar.Z or epoch-diff-4.1-4.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 4 Sep 1992 05:20:48 GMT


Hi!

Did I do something to make the lisp/term/ files disappear from
my epoch-4.1 files?  Or were they really not there in the first place?  

I was trying to use the ascii 'epoch' after installing 4.1
and the arrow keys that used to work stopped working until I noticed the
lisp/term/vt100.el file was gone.

I did find these files in the epoch-4.2.tar.Z file.

Regards,
Scott
From: bradm@anchor.ems.cdc.com (Brad Miller)
Newsgroups: gnu.epoch.misc
Subject: Re: Ownership of files modified by emacs
Date: 4 Sep 92 07:14:30 GMT
	<1992Sep3.180851.16145@news.iastate.edu>
Distribution: usa
Organization: Empros Systems International
In-reply-to: keinert@iastate.edu's message of 3 Sep 92 18:08:51 GMT

>>>>> On 3 Sep 92 18:08:51 GMT, keinert@iastate.edu (Fritz Keinert)
>>>>> said:

FK> In article <BRADM.92Sep2160916@anchor.anchor.ems.cdc.com> bradm@anchor.anchor.ems.cdc.com (Brad Miller) writes:
>On a somewhat related note, I am using epoch 4.2 on an SGI runing IRIX 4.0.1.
>When I save a file, such as a shell script, it is no longer executable.
>
>Is there something I can configure to fix this, or is this a bug??

FK> I have noticed the same with epoch 4.1 on a DECstation 2100 running
FK> Ultrix 4.2. It does not always happen, but most of the time.

Well, The post regarding changing the backup-by-copying variable does in
fact fix this problem as well.

Brad
--
--------------------------------------------------------------------------------
Brad Miller                    |              e-mail:   bradm@ems.cdc.com      |
Empros Systems International   |              v-mail:   (612) 553-4886         |
2300 Berkshire Lane N.         |Disclaimer: "I see no reason to contradict     |
Plymouth, MN  55441            |             myself at all"  George H.W. Bush  |
--------------------------------------------------------------------------------
From: tada@athena.mit.edu (Michael J Zehr)
Newsgroups: gnu.epoch.misc
Subject: Epoch on Sequent
Date: 2 Sep 92 16:41:42 GMT
Organization: Massachusetts Institute of Technology

I'm trying to help a colleague compile epoch 4.0 on a sequent 200 and
he's having all sorts of problems with things like system header files,
no alloca routine, etc.  Has someone solved this problem already?
Should we start by getting 4.2 instead?

Thanks for any help,
michael j zehr
Newsgroups: gnu.epoch.misc
From: johnson@dtc.hp.com (Phil Johnson)
Subject: Epoch doesn't notice I've iconified a screen
Date: Thu, 27 Aug 1992 23:33:47 GMT
Organization: HP Design Technology Center, Santa Clara, CA


When I use a window manager key binding to iconify an Epoch screen, Epoch
doesn't seem to notice that this has happened.  As a consequence, the focus
(current buffer) stays with the buffer whose screen I just iconified, rather
than switching to the one which is now beneath the mouse.  I have to use
switch-screen (C-z o) to manually recapture the focus (or, I can move the
mouse out of the window and back in).

If I use C-z i to iconify the screen, Epoch behaves correctly.  However, my
fingers are already trained to use the Motif window manager key binding which
I've become used to.

Is there a hook or something which I can use to switch the current screen to
the one under the mouse after an iconify event?  Any suggestions would be a
big help!  Thanks.

				Phil Johnson
				HP Design Technology Center
				Santa Clara, CA

(I'm using Epoch 4.1 with the Motif Window Manager (actually, the HP VUE
window manager, which is a superset of mwm.))
From: keinert@iastate.edu (Fritz Keinert)
Newsgroups: gnu.epoch.misc
Subject: Re: Ownership of files modified by emacs
Date: 3 Sep 92 18:08:51 GMT
Article-I.D.: news.1992Sep3.180851.16145
Distribution: usa
Organization: Iowa State University, Ames, IA

In article <BRADM.92Sep2160916@anchor.anchor.ems.cdc.com> bradm@anchor.anchor.ems.cdc.com (Brad Miller) writes:
>On a somewhat related note, I am using epoch 4.2 on an SGI runing IRIX 4.0.1.
>When I save a file, such as a shell script, it is no longer executable.
>
>Is there something I can configure to fix this, or is this a bug??

I have noticed the same with epoch 4.1 on a DECstation 2100 running
Ultrix 4.2. It does not always happen, but most of the time.

I reported this bug before; apparently, it has not been fixed yet.
-- 
Fritz Keinert                             phone:  (515) 294-5223
Department of Mathematics                 fax:    (515) 294-5454
Iowa State University                     e-mail: keinert@iastate.edu
Ames, IA 50011
Newsgroups: gnu.epoch.misc
From: jerry@math.ep.utexas.EDU (Jerry)
Subject: Re: Bug in save-zones.el
Organization: Department of Mathematical Sciences--University of Texas at El Paso
Distribution: gnu
Date: Sat, 29 Aug 1992 22:10:27 GMT

Aksnes Knut-Havard on August 29 wrote:
-> save-zones.el does not compile due to a missing ) at the end of the file
-> --

Here's a patch (the missing paren does not go at the very end):

-Jerry

*** save-zones.el.orig	Fri Apr 24 15:32:26 1992
--- save-zones.el	Sat Aug 29 16:04:42 1992
***************
*** 159,165 ****
  	(if (search-forward start nil t)
  	  (progn
  	    (beginning-of-line)
! 	    (setq beg (- (point) 1)
  	    (if (search-forward finish nil t)
  	      (progn
  		(setq end (point))
--- 159,165 ----
  	(if (search-forward start nil t)
  	  (progn
  	    (beginning-of-line)
! 	    (setq beg (- (point) 1))
  	    (if (search-forward finish nil t)
  	      (progn
  		(setq end (point))
Newsgroups: gnu.epoch.misc
From: gerdh@ims.COM (Gerd Hoeren)
Subject: Re: Bug Report - Epoch kills other windows
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 4 Sep 1992 17:08:30 GMT

|> Message  7:
|> From epoch-m@cs.uiuc.edu Fri Sep  4 09:20:19 1992
|> Subject: Bug Report - Epoch kills other windows
|> To: epoch@cs.uiuc.edu
|> Date: Fri, 4 Sep 1992 12:29:44 +0200 (MET DST)
|> X-Organisation: Geco-Prakla Delft
|> X-Address: 	Poortweg 14, P.O. Box 148, 2600 AC  Delft,  The Netherlands
|> X-Phone: 	+31 15-682215		Fax: +31 15-617881
|> X-Telex: 	38356 degeo nl
|> Mime-Version: 1.0
|> Content-Type: text/plain; charset=US-ASCII
|> Content-Length: 690
|>

Frank.Ooms@delft.geco.slb.com writes:
|> When you copy text from i.e. an xterm window into an epoch window
|> using the X cut and paste, and then close down the epoch window with
|> (save-buffers-kill-emacs) the other window gets destroyed as well.

We've noticed this is only a problem if you run the Openwin (xnews) server.
Running Epoch with the MIT server does not have this problem.  (Note
that the X server and not the window manager matters here.)

It must be some bug in the server, but it would sure be nice if Epoch
found a way to work around it since other X applications don't exhibit
this problem.


--------------------------------------
Gerd Hoeren
  Integrated Measurement Systems, Inc.
  Voice: (503) 626-7117
  Fax:   (503) 644-6969
  Email: gerdh@ims.com
--------------------------------------

Newsgroups: gnu.epoch.misc
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Bug Report - Epoch kills other windows
Organization: Gnus Not Usenet
Distribution: gnu
Date: Fri, 4 Sep 1992 06:31:02 GMT

--> On Fri, 4 Sep 1992 12:29:44 +0200 (MET DST), Frank Ooms
--> <Frank.Ooms@delft.geco.slb.com> said:

  /frank/ When you copy text from i.e. an xterm window into an epoch
  /frank/ window using the X cut and paste, and then close down the
  /frank/ epoch window with (save-buffers-kill-emacs) the other window
  /frank/ gets destroyed as well.
  /frank/ (1) Version of Epoch (see the variable epoch::version).  4.2
  /frank/ (2) Platform and operating system (including version of OS).
  /frank/     SunOS 4.1.2, Openwindows 3., Motif Window Manager 1.1.4
  /frank/ (3) Compiler.
  /frank/     Sun CC 1.1

This comes up from time to time... does anyone seriously want to
contest my opinion that this has to be purely an OpenWindows bug?
It's never reported under any other configuration.

Marc

--
Marc Andreessen
Epoch Development Team
University of Illinois at Urbana-Champaign
marca@ncsa.uiuc.edu

Newsgroups: gnu.epoch.misc