HDTenEightyP/NetNews huggingface dataset:
From: S.Marshall@sequent.cc.HUll.ac.UK (Simon Marshall)
Subject: Iconifying minibuffer no longer iconifies other screens under X11R5?!
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 11 Apr 1992 13:16:00 GMT

	Hi all.  I'm not sure where this behaviour problem lies.  This
    occurs under epoch-4.0 and 3.2, but with twm of X11R5 (pl10) and olwm of
    OpenWindows (3.0).  Ncd/SunSparc displays.

	We have a mixture of epochs & X11s.  I noticed that when I use epoch
    (3.2 or 4.0) when under X11R5 (pl9 & 10), iconifying the minibuffer did
    not iconify the rest of epoch's screens, whereas it does when under
    X11R4 (pl18).  I figured that this was down to my WM (twm), so I tried
    it with olwm, but the same thing happened.

	So what is going on, and how do I restore the behaviour that epoch
    had under X11R4?  Or am I the only person to have this problem?

	Cheers, Simon. 
_______________________________________________________________________________
Simon Marshall, Dept. of Computer Science, University of Hull, Hull HU6 7RX, UK
  "Football isn't about life and death.  It's more important than that." Bill
Email: S.Marshall@Hull.ac.uk    Phone: +44 482 465181    Fax: 466666   Shankley
Newsgroups: gnu.epoch.misc
From: erf@bedford.PRogress.COM (Eric Feigenson)
Subject: Some other Epoch/OpenLook problems
Reply-To: erf@progress.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 21:53:39 GMT

I just upgraded my Sparc from SunOS 4.1 to 4.1.2 and from OpenLook
version 2 to version 3.  I'm having various problems with ths
configuration, but the most disturbing is that when I start Epoch 3.2
OR 4.0, my system get incredibly bogged down, with my perfmeter pegged
at 100%.  A ps auxw shows me that the two processes that are eating my
machine alive are xnews and epoch.

I am somewhat ignorant of the nasty details of the OS configuration,
so something might be configured wrong.  ANY and ALL suggestions of
why this might be happening (and how to solve them!) would be greatly
appreciated.  Things are so slow right now that I can type about two
lines ahead of what Epoch can echo (and nothing else is running on the
machine!).  When I exit Epoch, the CPU utilization drops back to
normal levels.  Note that all was just fine under OpenLook/OpenWindows
2.0.

Thanks in advance for any/all help!

-EricF

P.S. xnews seems to be always at the top of my ps auxw listing, but it doesn't 
seem to really affect performance.  It's when Epoch gets into the act that
all hell breaks loose.  Xnews seems normally to be at 7.7% of the CPU, but
when Epoch is running it leaps to 30-40%.  Brrrrr...

Newsgroups: gnu.epoch.misc
From: erf@bedford.PRogress.COM (Eric Feigenson)
Subject: More on OpenLook/Epoch problem
Reply-To: erf@progress.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 15:16:14 GMT

First, thanks to everyone who replied to my earlier yelp for help with
Epoch and OpenLook 3.0, SunOS 4.1.2.  I think I've tracked down the problem.

The problem is minibuf.el, which I was using under Epoch 3.2.  If in
load it in my .emacs, then BOTH Epoch 3.2 and 4.0 exhibit the
anti-social behavior I mentioned earlier (i.e., it tries to gobble up
all available cycles, and encourages the X server to do the same).
Minibuf also had a problem in this configuration in that the
minibuffer *always* came to the top, no matter what window on the
desktop the cursor was in.

Does anyone have any explanation for this behavior?  Is there a
revised minibuf.el, perhaps, that works around it?

Thanks in advance!

-EricF

P.S. Recompiling everything under SunOS 4.1.2, rather than 4.1, made
     no difference.

Newsgroups: gnu.epoch.misc
From: williams@herky.cs.uiowa.edu (Kent Williams)
Subject: Re:  Painful epoch-4.0p0 bugs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 03:04:11 GMT

>    The first two bugs are easy to duplicate.  When running as usual
>in minibuffer-per-window mode (with -nm flag) with at least two epoch
>screens, do the following:
>
>   - begin a command such as find-file-other-screen, leaving the prompt
>     in the minibuffer.
>
>   - Move the mouse to another screen, and the minibuffer prompt will
>     follow it into this screen.  
>
>   - Move the mouse again back to the original screen, and click to put
>     the cursor into it
>     (the prompt doesn't follow automatically, which is a small bug in itself)
>
>   - Use C-x o to return to the minibuffer
>
>   - Complete the find-file-other-screen command
>
>    The find-file-other-screen works fine, but the focusing is now
>stuffed; if you move the mouse to another screen, the cursor simply
>moves into the minibuffer of the previous screen.  It is possible to
>click in screens to move the cursor to them, but the only way to
>return to a reasonable state of affairs is by killing epoch and
>starting again.  This combination of circumstances may sound extremely
>rare, but it happens to me about once a day, even when I'm trying to
>remember not to cause it.
>
>    A still nastier bug lies in store if you have lots of windows open
>and decide to soldier on; eventually in unpredictable circumstances
>(quitting a file and closing a screen is one example), epoch will
>start to ring the bell continuously, making it near impossible to kill
>on the Decstation because X comes to almost a complete halt.
>

I have seen this same behavior, on both an SGI and a SUN; so I would guess
this isn't a platform-specific bug.  Hats off to Peter for providing
such a concise description; I never had the patience to actually
figure out what I had done to make this happen, and then to write up a
bug report.

And yes the bell ringing stuff is pretty hideous.  Our worstations are
in a common room, so when epoch loses it's marbles, everyone knows
about it.  The best thing to do is to login from somewhere else and
kill epoch; but there might still be 32K bells left in the buffer
waiting to be echoed.
From: antoy@antares.cs.pdx.edu (Sergio Antoy)
Newsgroups: gnu.epoch.misc
Subject: problem build ascii epoch (solved, possible bug)
Date: 11 Apr 92 03:52:54 GMT
Article-I.D.: antares.ANTOY.92Apr10205254
Reply-To: antoy@cs.pdx.edu
Distribution: gnu
Organization: Portland State University, CS Dept.

I got the following error using build-install to build epoch-4.0.
This is a portion of the output generated during the execution.

+ cd ascii 
+ make 

... [many lines]

cc -g -Demacs   -I/usr/openwin/include  -target sun4 -c  malloc.c
ld  -e __start -Bstatic -L/usr/openwin/lib -o temacs crt0.o dispnew.o scroll.o xdisp.o window.o  term.o cm.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 unexec.o mocklisp.o bytecode.o  process.o callproc.o   doprnt.o tparam.o lastfile.o malloc.o   -ltermcap   -lg -lc 
ld: unexec.o: No such file or directory
*** Error code 4
make: Fatal error: Command failed for target `temacs'

I was able to correct the error by changing line 142 of ascii/xmakefile from

	unexec.o : config.h 

to

	unexec.o : unexec.c config.h 

It looks like a bug.

Sergio Antoy
Dept. of Computer Science
Portland State University
P.O.Box 751
Portland, OR 97207
voice +1 (503) 725-3009
fax   +1 (503) 725-3211
internet antoy@cs.pdx.edu
Newsgroups: gnu.epoch.misc
From: jonas@ericad.ericsson.SE (Jonas Jaernestroem TG/HK)
Subject: Epoch cut+paste questions
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 13:47:10 GMT

   Christopher Love writes:
   >Selecting a region with the mouse implicitly puts the region on the
   >kill ring.  It is redundant to repeat this manually.

   Somebody wrote:
   What if I want to select something with the mouse, cut it, and paste it
   somewhere? I will get the selected text twice. Is there any way around
   this behaviour? Right now, I'm use keyboard commands.

I cannot reproduce this. Killing the region "again" explicitly with C-w
creates a new entry on the kill-ring, *not* appended to the previous entry.

    Marc Andreessen writes:
    I too think it is counter-intuitive for mouse selection to put the
    region on the kill ring as it's currently doing.  Select with mouse
    then C-w then C-y is a fairly common sequence of operations for me.

I've hard to see whats so wrong about putting selected region on the
kill-ring.  Doing that seems to me to be a harmless thing in case you
dont do any subsequent yanking, and very convenient if you *do*
subsequent yank/copy.  

Cut/paste is plain and one of the most frequent actions. I think epoch
should support doing that using *only* the mouse buttons.  Much of the
thrill is gone if cut/paste would require one hand on the mouse and the
other hand fiddling around with good old C-w/M-w. Of course its wise to
retain a certain continuity with "traditional" emacs, but dont let that
stop you from implementing new and more convenient schemes.

Jonas Jaernestroem
Ericsson Telecom, Stockholm Sweden.


Newsgroups: gnu.epoch.misc
From: jonas@ericad.ericsson.SE (Jonas Jaernestroem TG/HK)
Subject: Epoch cut+paste questions
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 20:43:21 GMT

Lupe wrote:
	- Click on the 'C' in "Christopher", above.
	- Click right on the space after "Christopher".
	* "Christopher" gets underlined.
	- Hit C-w.
	* "Christopher" disappears (to the kill ring).
	- Hit C-y.
	* "ChristopherChristopher" appears.

I still cannot reproduce it. As I said in last mail, killing the region
with C-w creates a new entry on the kill-ring, separated from the previous
entry with the same contents created by the mouse-button. So each time you
cut you'll get redundandy in kill-ring but thats harmless.

   Can you please supply information on your Epoch version and the
   platform it is running on?

Epoch 3.2.2, Sun sparc SLC, OS 4.1.1, OpenWindows 2.0
Im an ignorant man on Epoch mouse setup, and I assume Im using the
"standard" setup. My mouse.el is 8398 bytes and probably standard. I
have a newer sun-mouse.el but I doubt it is used by epoch.

   It is counter-intuitive on Open Windows. You have to hit the "Copy" or
   the "Cut" keys to put something marked with the mouse on the
   clipboard. Then you retrieve it with the "Paste" key.  This behaviour
   was inherited from SunView. Normal X (and I believe, Motif) use the
   primary selection for pasting, and the mouse for "pasting".  I have
   changed the mouse keys to the Open Windows settings (Select, Extend,
   Menu (well, it's not used right now).

Im sure you can setup the "cut" "paste" & "copy" keys to do what you
want provided you have the knowledge. In general, Im not sure its
necessary for epoch to comply 100% with the peculiarities of OpenWindows
or SunView. About 90% of the cut/paste operations that I do, I do in
the text editor. If its possible, Im happy to skip an explicit "copy" (M-w)
in this process.

Jonas Jaernestroem Ericsson Telecom Sweden. jonas@ericad.ericsson.se
From: etxkrjg@solsta.ericsson.se (Kristian Jorg  TX/DKL)
Newsgroups: gnu.epoch.misc
Subject: info problem
Keywords: info, epoch, emacs
Date: 14 Apr 92 09:27:53 GMT
Organization: Ericsson


I am using epoch4.0p0 on a SUN IPX, SunOs 4.1.2.

The problem is that my epoch cannot use the info feature. When
I type "C-Hi" The info window pops up OK, the (dir)Top buffer.
When I select any of the nodes below the Info node, I get this
message: "Wrong type argument: char-or-string-p, nil"

I believe that I must have installed epoch wrongly or something...

Any ideas?

--
-----------------------------------+  
Kristian Jorg                      !  
e-mail: etxkrjg@solsta.ericsson.se ! 
-----------------------------------+
From: etxkrjg@solsta.ericsson.se (Kristian Jorg  TX/DKL)
Newsgroups: gnu.epoch.misc
Subject: Re: info problem
Keywords: info, epoch, emacs
Date: 15 Apr 92 15:03:10 GMT
Organization: Ericsson

etxkrjg@solsta.ericsson.se (Kristian Jorg  TX/DKL) writes:

>The problem is that my epoch cannot use the info feature. When
>I type "C-Hi" The info window pops up OK, the (dir)Top buffer.
>When I select any of the nodes below the Info node, I get this
>message: "Wrong type argument: char-or-string-p, nil"

The reason for this was an erroneous info.el from the contrib/hyper
package. I have a patched version of the file now (thanx Chris).


--
-----------------------------------+  
Kristian Jorg                      !  
e-mail: etxkrjg@solsta.ericsson.se ! 
-----------------------------------+
From: etxkrjg@solsta.ericsson.se (Kristian Jorg  TX/DKL)
Newsgroups: gnu.epoch.misc
Subject: Re: Forcing epoch to save all buffers
Date: 15 Apr 92 14:59:12 GMT
Distribution: gnu
Organization: Ericsson

knauer@cs.uiuc.edu (Rob Knauerhase) writes:

>Is there a way to force Epoch, outside Epoch itself, to save all modified
>buffers that are currently being edited?  The reason I ask is that (like a
>good convert) I am currently running an Epoch on the machine in my office.
>Since I don't generally log out, it's running as I type this (in Emacs, dialed
>in from home).

I am not sure this is what you want, but the command "save-some-buffers" saves
all unsaved files.

This has to be run from within epoch though.

--
-----------------------------------+  
Kristian Jorg                      !  
e-mail: etxkrjg@solsta.ericsson.se ! 
-----------------------------------+
Newsgroups: gnu.epoch.misc
From: snow@netcom.com (Tim Szeliga)
Subject: HP missing external for temacs
Date: Wed, 08 Apr 92 20:33:49 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: ca

Got an error compiling epoch-4.0p0
for an hp9000s385 running hpux.8.0 with X11R4.
While loading temacs, it had undefined externals,
_Vxterm
_x_term_init
_syms_of_xfns.

Does anyone know where these can be found 

Drunkenness may be reprehensible in itself,		Tim Szeliga
but as a control over schizophrenia,			snow@netcom.com
as Jung said Joyce used it,				
it may have its merits.
  Richard Ellmann   a long the riverrun

Newsgroups: gnu.epoch.misc
From: joost@cadlab.de (Michael Joosten)
Subject: Bug in epoch::read-pixmap-file : abort()'s if it's not an XPM file
Reply-To: joost@cadlab.uni-paderborn.de
Organization: CADLAB, Paderborn, FRG
Date: Sun, 12 Apr 1992 18:35:56 GMT

Hello, while experimenting a bit with read-pixmap-file epoch-4.0p0 will surely
aboort if you read (mistakenly) a non XPM file, like a bitmap (btw: how to
read a bitmap file?). The reason was that the 'attribute' argument wasn't
properly initialized and thus free() tried to free garbage:

diff -c button.c.bak button.c
*** button.c.bak        Sat Apr 11 22:46:23 1992
--- button.c    Sun Apr 12 17:55:03 1992
***************
*** 149,154 ****
--- 149,160 ----
    attributes.colorsymbols = symbols;
    attributes.numsymbols = 0;

+   attributes.colorTable = (char***)0;
+   attributes.hints_cmt  = (char*)0;
+   attributes.colors_cmt = (char*)0;
+   attributes.pixels_cmt = (char*)0;
+   attributes.pixels     = (Pixel*)0;
+
    BLOCK_INPUT();
    status = XpmReadFileToPixmap(XD_display,cur_Xscreen->xid,

Michael
--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Michael Joosten   |       Tel.  : (+49) (+) 5251-284 120                 |
| CADLAB            |       Fax   : (+49) (+) 5251-284 140                 |
| Bahnhofstr. 32    |       E-Mail: joost@cadlab.de                        |
| D-4790 Paderborn  |        	    ...!uunet!unido!cadlab!joost           | 
| FRG               | Mass mail to: joost@pbinfo.uni-paderborn.de          |
|--------------------------------------------------------------------------|
| CADLAB is a cooperation between Uni-GH Paderborn & SNI AG                |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Newsgroups: gnu.epoch.misc
From: S.Marshall@sequent.cc.HUll.ac.UK (Simon Marshall)
Subject: SUMMARY: how to build temacs (epoch-4.0) on a Sequent.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 16:46:15 GMT

	A couple of days ago I posted in exasperation a problem I've come
    across while building epoch-4.0 on a Sequent Symmetry S81 running DYNIX
    V3.0.17.10.  What was happening was that temacs was dying, but in two
    different ways, depending on whether I compiled with gcc-2.1
    optimisation on or not:

>./temacs -batch -l ../epoch-lisp/inc-vers
>Please set the environment variable TERM; see tset(1).
>Make[1]: *** [epoch] Error 1
>
>	even though TERM was set.  So I ran under gdb-4.4 and found that
>    SIGTRAP was being generated, apparently straight away:

	Jay Vosburgh (thanks yet again) explained that it was due to an
    improper definition of CRT0_DUMMIES.  I found that when compiling
    without optimisation, it seems gcc-2.1 requires two dummies.  With
    optimisation, one dummy is enough.

	There was one other problem; somehow NULL was being passed to
    memcpy().  Looking at the breakdown, I found that the doprnt() being
    used was not the one supplied with epoch-4.0, but the Sequent one!
    Aarrrgh!  I had had to link with /usr/att/lib/libc.a when linking temacs
    together, to pick up memcpy() et al., and the Sequent's doprnt() was
    hiding in there.  So I extracted the relevant bits temacs needed & built
    my own library.  Hey presto!  All was well.

	So there are a number of points.  "How to build temacs on a
    Sequent".  They will no doubt be applicable to other hosts too.

1.  If you build with gcc-2.*, don't forget to link with the gcc library
    (libgcc.a).  You might need to specify where it is, too.

2.  If temacs complains about TERM not being defined (for example, if you
    build with gcc without optimisation), you may need to define
    CRT0_DUMMIES differently in config.h:

#undef CRT0_DUMMIES
#define CRT0_DUMMIES dummy1, dummy2,

    worked for me.  If you're using the newer ATS cc, you need three dummies
    (end with a comma).

3.  If you get complaints about memcpy() et al. not being around, you need
    to link them in (on our Sequent, /usr/att/lib/libc.a).  Beware, on our
    Sequent this also linked in a completely different version of doprnt()
    than which comes with epoch.  My hack was to extract (using ar) the
    relevant files required from the library, and build my own library with
    them.  Then link in this library when building temacs.

	Then have fun.  Thanks again to those who helped.

	Simon. 
_______________________________________________________________________________
Simon Marshall, Dept. of Computer Science, University of Hull, Hull HU6 7RX, UK
  "Football isn't about life and death.  It's more important than that." Bill
Email: S.Marshall@Hull.ac.uk    Phone: +44 482 465181    Fax: 466666   Shankley
Newsgroups: gnu.epoch.misc
From: G.Joly@cs.ucl.ac.uk (Gordon Joly)
Subject: Re: Epoch cut+paste questions
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 15:04:58 GMT


"Non-appearance until redraw" happens with Epoch 3.2 and 4.0p0 (SunOS
4.1.1).

It happens with code cut from xterms into Epoch buffers.

Gordon,
____

Gordon Joly                                       +44 71 387 7050 ext 3703
Internet: G.Joly@cs.ucl.ac.uk        UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly
Computer Science, University College London, Gower Street, LONDON WC1E 6BT
Newsgroups: gnu.epoch.misc
From: bport@arcadien.owlnet.rice.edu (Bradley Jason Porter)
Subject: minibuffer
Organization: Rice University
Date: Thu, 9 Apr 1992 04:43:47 GMT


-- 
I have a problem with moving (with the mouse) in and out of the minibuffer.

For example, if I need to move out of the minibuffer for some reason
or another, the mouse refuses to put the cursor back in the minbuffer on
command.  I have to resort to using M-x other-window.

I am using epoch 3.2 in a X and Unix environment.

I appreciate any help!

________________________________________________________________
Brad Porter		  |      The more you sweat during peace,
			  |       the less you bleed during war.
bport@owlnet.rice.edu     |         		- Sun Tzu
From: rutt@aztec.asd.sgi.com (John Ruttenberg)
Newsgroups: gnu.epoch.misc
Subject: Temporary highlighting code wanted
Date: 9 Apr 92 14:39:03 GMT
Reply-To: rutt@sgi.com
Organization: Silicon Graphics Inc.

I want to be able to highlight a region temporarily, for example to highlight
a misspelled word for ispell.  The code in the contributed hilite program
doesn't make it obvious how to put things back when it's done.  Anyone have
any clues, example, etc?  Thanks.

-- 
                                      John Ruttenberg -- (203) 874-7154
Newsgroups: gnu.epoch.misc
From: S.Marshall@sequent.cc.HUll.ac.UK (Simon Marshall)
Subject: SUMMARY: Problems building epoch-4.0, anyone help (gcc)?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 13:02:41 GMT

	Many thanks to Susan_Hinrichs@edu.cmu.cs.warp.canary for giving me
    the answer; the problem does lie with using gcc, I need to link in the
    gcc library libgcc.a.  I guess I assumed that gcc would do this where
    necessary.  It then builds nicely, although fails elsewhere...  See a
    later post!

	Hope this helps others out.

	Cheers, Simon. 
_______________________________________________________________________________
Simon Marshall, Dept. of Computer Science, University of Hull, Hull HU6 7RX, UK
  "Football isn't about life and death.  It's more important than that." Bill
Email: S.Marshall@Hull.ac.uk    Phone: +44 482 465181    Fax: 466666   Shankley
Newsgroups: gnu.epoch.misc