HDTenEightyP/NetNews huggingface dataset:
From: pwagner@ejv.com (Peter Wagner)
Subject: Can't find gnusgethdrs
Date: Fri, 6 Nov 92 17:08:24 EST
X-Received: by usenet.pa.dec.com; id AA14918; Fri, 6 Nov 92 14:09:56 -0800
X-Received: by inet-gw-2.pa.dec.com; id AA09289; Fri, 6 Nov 92 14:09:48 -0800
X-Received: from forty-two.ejv.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)id AA00435; Fri, 6 Nov 92 17:09:14 -0500
X-Received: from ejvdev4 by ejv.com (4.1/SMI-4.1)id AA07577; Fri, 6 Nov 92 17:08:04 EST
X-Received: from ejvmach59.ejv.com by ejvdev4 (4.1/SMI-4.1)id AA13228; Fri, 6 Nov 92 17:08:24 EST
X-To: gnu.emacs.gnus.usenet



Emacs 18.58, gnus 3.13

I've been using gnus for a couple of months w/o problem.  Recently,
emacs moved to a different directory (I reconfigured accordingly), and
since then I have the following problem: The first time in an editing
session that I load gnus and retrieve articles, everything works fine.
However, if I quit gnus and then reload it and try to retrieve
articles, I get the following error message:

        no such file or directory: gnusgethdrs

The gnusgethdrs executable is definitely on my path.  Anyone have any
ideas as to why it works the first time but not in subsequent gnus
sessions?  I have to quit emacs entirely in order to use gnus again.
Thanks in advance.

        >p

----------------------------------------------------------------------
Peter Wagner					EJV Partners, L.P.
pwagner@ejv.com					One Seaport Plaza 
     					   Floor 19
     					   New York, NY 10292
----------------------------------------------------------------------


Newsgroups: gnu.announce
From: raeburn@cygnus.com (Ken Raeburn)
Subject: new gas version coming...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 13:43:41 GMT

[Apologies if you get duplicates.  This has already been sent to
bug-gcc@prep, bug-gnu-utils@prep, and gas2@cygnus.]

I have recently taken over maintenance of the GNU assembler for the FSF.
It's been a while since the last release, so I'm sending out this note to
let people know that work on the assembler is continuing.
	I aim to have a new version available for general release in early
'93.  It will be a merged version of the FSF gas currently in testing
(1.92.3) and some work that's been ongoing at Cygnus, further refining and
enhancing support for a few of the targets.
	It will also include as many bug fixes and enhancements as I have
time to integrate.
	A new version should be going out to pre-alpha testers/developers
within a couple weeks or so.

A related project I've been working on has been the conversion of the
assembler to use the BFD library used by GDB and binutils; it should
simplify development and maintenance work for the toolchain as a whole once
the conversion is complete.  I don't know yet whether that will be folded
in for this release; it has a way to go before it's ready for general use.
(If anyone is interested in assisting in the development work on this,
please send me mail.)

So keep those bug reports coming in...




Newsgroups: gnu.announce
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Maintainer needed for fax program
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 3 Nov 1992 19:26:37 GMT

The people who wrote the program we have for sending faxes
do not want to keep maintaining it.  Would anyone like to do so?
It does not need major work, but someone needs to install bug
fixes that users send.

Please send me mail if you'd like to take this responsibility.

If you are a good programmer and you have so far used GNU software
without ever contributing, this would be an excellent way to begin
doing your share.

Newsgroups: gnu.epoch.misc
From: vaitkus@ceres.lexmark.com (Keith Vaitkus)
Subject: Help with Epoch Manual and TeX
X-Disclaimer: These views are the poster's and not necessarily those of Lexmark
Organization: Lexmark International
Distribution: na
Date: Thu, 12 Nov 1992 14:23:21 GMT

We just got epoch here, and are trying to compare it to emacs. I have
many questions about epoch, and I figured I could answer them by reading
the enclosed manual. OK. Step one -- print it out.

No one here has ever used TeX. We ran the makefile in the epoch-man/
directory.... *chugchugchug* *ding!* Out comes a epoch.dvi file. TeX
seems to think that it is done at this point, but none of us can
figure out how to _print_ a .dvi file. Can anyone help? Please?


Thanks in advance.
--

---------------------------------------------------------------------------
                                              /\    Keith Vaitkus
                                             //\\   
                                            ///\\\  Lexmark International
                                            \\\///  email: vaitkus@lexmark.com
                                             \\//   voice: (606) 232-4382 
                                              \/

Newsgroups: gnu.epoch.misc
From: eeide%asylum.cs.utah.edu@cs.utah.edu (Eric Eide)
Subject: epoch.el sets global target-buffer
Organization: University of Utah Department of Computer Science
Distribution: gnu
Date: 13 Nov 92 16:49:46

What a strange subject, eh?  What I'm trying to say is that several of the
functions in Epoch 4.2's "epoch.el" set the global variable "target-buffer"
without any apparent need:

  (defun find-file-other-screen (filename)
    "Find file in other screen"
    (interactive "FFind file other screen: ")
    (setq target-buffer (find-file-noselect filename))
    (if (bufferp target-buffer) (find-buffer-other-screen target-buffer))
  )

This looks like sloppy coding (IMHO); the offending functions should just make
a binding for target-buffer as needed:

  (defun find-file-other-screen (filename)
    "Find file in other screen"
    (interactive "FFind file other screen: ")
    (let ((target-buffer (find-file-noselect filename)))
      (if (bufferp target-buffer)
          (find-buffer-other-screen target-buffer))
      ))

Perhaps there's something I'm not seeing, or perhaps this is just historical
accident.

--
-------------------------------------------------------------------------------
Eric Eide          |          University of Utah Department of Computer Science
eeide@cs.utah.edu  | Buddhist to hot dog vendor: "Make me one with everything."
Newsgroups: gnu.epoch.misc
From: tore@bibsyst.no (Tore Morkemo)
Subject: epoch 4.0 patch 1 & 2
Organization: Bibliotek-Systemer A/S
Date: Tue, 10 Nov 1992 10:48:18 GMT

Hi !

To upgrade from 4.0 to 4.2 I need patch 1 & 2 for 4.0. I have diff's
from 4.2p2 and up.

Could ONE of you please mail me these patches or tell me where to find them.

-- 
*-----------------------------------------------------------------------------*
 Tore Morkemo, Bibliotek-Systemer A/S, Box 2093 Stubber|d, 3271 Larvik, Norway
        Tel: +47 34 16 800  Fax: +47 34 16 822  email: tore@bibsyst.no
Newsgroups: gnu.epoch.misc
From: lvi@ida.liu.se (Lars Viklund)
Subject: Epoch bug ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 21:38:48 GMT


Epoch version: 	4.2
Platform:	Sun Sparcstation 1
OS:		SunOS 4.1.2
Compiler:	Sun cc (bundled)

Epoch sometimes crashes when I'm running a particular ST80 application
(a CASE tool). The crash usually (always ?) appears when I have been 
working with Epoch switches to using the CASE tool.

Stack backtrace:

core file = core -- program ``epoch-4.2.1''
SIGIOT 6: abort
$C
_kill() + 8
_abort(0x402000,0x0,0x1f,0x66,0x63,0x9a000) + 54
_x_selection_request(0xf7ffbed0,0x1f,0x14b008,0x1c00001,0x1,0x402000) + 2d0
_internal_socket_read(0xf7ffbffc,0x2000,0xffffff,0x0,0x3,0x0) + 4a0
_XTread_socket(0x0,0xf7ffbffc,0x2000,0x2000,0x20,0x8408) + 8
_input_available_signal(0x17,0x0,0x4) + ac
__sigtramp() + 94
_select(?)
_wait_reading_process_input(0x0,0xffffff,0x1,0x40,0x101000,0x4) + 8
_kbd_buffer_read_command_char(0x109400,0x1097f0,0x109800,0x110008,0x85e,0x41f) + e0
_read_command_char(0x12c,0x12c,0x12c,0x0,0x2d5b,0x2cd3) + 3f4
_read_key_sequence(0xf7ffec90,0x1e,0x0,0x1,0x183b08,0x0) + 94
_command_loop_1(0x103800,0x0,0x0,0x0,0xffffff,0x0) + 230
_internal_condition_case(0x110dc0c,0x1,0x0,0xf7ffed30,0xf7ffed18,0x106000) + 118
_command_loop_2(0x110dc0c,0x110dcfc,0x110dc0c,0x0,0x0,0x0) + 18
_internal_catch(0x110dcfc,0x24adc,0x110dc0c,0x40,0x2,0x0) + b4
_command_loop(0x10,0x10e408,0x10e728,0x80,0x0,0x10e408) + 74
_recursive_edit_1(0x24744,0x110dc0c,0x1,0x0,0x0,0x1) + 50
_Frecursive_edit(0x101000,0x101000,0x105800,0x1063d0,0x0,0x110dc0c) + 8c
_main(0x1,0xf7fff064,0x1,0x1,0x1,0x0) + 56c


--
Lars Viklund                                       | Email: lvi@ida.liu.se
Programming Environments Laboratory                | Phone: +46 13282689
Department of Computer and Information Science     | Fax  : +46 13282666
Linkoping University, S-581 83  LINKOPING, SWEDEN  | Telex: 50966 UNILIN S
Newsgroups: gnu.epoch.misc
From: rv@cs.brown.edu (rodrigo vanegas)
Subject: Re: bug with X window focus switching?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 19:58:31 GMT


>The original intent of the filled cursor was to let you know where the
>focus was. However, no focus events are sent to either emacs or xterm.
>
>The twm icon manager is the one handling the decorations, so it knows
>that it wants to see the window corresponding to the icon manager
>entry to be highlighted. You may consider this a bug in twm if you
>wish, but emacs, epoch, and xterm all have no knowledge of how the
>events are reaching it when it is not currently the window in 'focus'.

I think you've misunderstood my report.  I find that xterm and emacs
*are* aware of the change of focus and reflect this awareness by
having filled or hollow cursors.  Epoch, too, is aware of focus
changes when they occur in by the more direct movement of the mouse
from one region of the screen to another.

Unlike emacs and xterm and a number of other apps where this is
relevant, epoch is not aware of focus changes when they occur as a
result of keyboard input.  I don't know exactly whose fault it is or
what the deal is exactly.  But i do know that emacs and xterm handle
this event appropriately. 

Epoch is the problem this time -- not twm.



rodrigo
From: dansmith@Autodesk.COM (Daniel Smith)
Newsgroups: gnu.epoch.misc
Subject: Got a good Epoch icon for root menus?
Date: 11 Nov 92 19:22:51 GMT
Organization: Autodesk Inc., Sausalito CA, USA


	Howdy, I'm looking for a bitmap that would make a good
Epoch icon, to be used in an mwm or olvwm root menu.  Email would be fine.

				Daniel
-- 
     Daniel Smith, Autodesk, Sausalito, California, (415) 332-2344 x 2580
	      Disclaimer: written by a highly caffeinated mammal
	    dansmith@autodesk.com            dansmith@well.sf.ca.us

Newsgroups: gnu.epoch.misc
From: scotth@oldman.com (Scott Herzinger)
Subject: epoch focus policy
Organization: Wind River Systems
Distribution: na
Date: Sat, 14 Nov 1992 00:13:26 GMT

How does one control focus in epoch? I haven't found anything helpful
in the manual yet. If it's there, please let me know. If it's not, can
someone help? I'm relatively new to epoch.

Window manager is twm, X is R5. Focus normally follows the pointer
from X window to X window. When I launch epoch, it also starts out
that way.

As I move from screen to screen, focus initially follows the pointer.
Eventually, epoch fails to move the focus to the screen that contains
the pointer.  Instead, focus remains on the last screen that I clicked
in. I have to click to move the focus to a different screen. It stays
this way until I quit epoch.

I don't know if the change in focus policy occurs due to a bug, upon
some even, or what. I don't do anything in particular that I've been
able to associate with the change in behavior.

Any suggestions?

Thanks,

Scott		scotth@wrs.com		(510) 814-2079
Newsgroups: gnu.epoch.misc
From: mdb@cisco.com (Mark D. Baushke)
Subject: Re: bug with X window focus switching?
Organization: cisco Systems Inc., Menlo Park, CA, USA
Distribution: gnu
Date: Mon, 9 Nov 1992 13:38:44 GMT

On Tue, 10 Nov 1992 04:01:26 GMT, rv@cs.brown.edu (rodrigo vanegas) said:

rodrigo> I think I have found a bug with Epoch 4.2.  

I do not believe this is a bug.

[indicator]

rodrigo> 4) and, cursor is "filled" or "hollowed".

[method]

rodrigo> 3) and, move the pointer through the entries in the icon
rodrigo> manager using keymappings (defined in .twmrc).

rodrigo> The bug is essentially this: When switching the pointer focus
rodrigo> from or to an epoch window using method number 3, then
rodrigo> indicator number 4 does not change state.

rodrigo> Has anyone had similar problems?

I am able to reproduce your results.

The same behavior occurs with an xterm. I do not consider this a bug.

	-- Mark
From: jeroenm@cwi.nl (Jeroen van Maanen)
Newsgroups: gnu.epoch.misc
Subject: Re: bug with X window focus switching?
Date: 10 Nov 92 16:21:04 GMT
Distribution: gnu

rv@cs.brown.edu (rodrigo vanegas) writes:

[stuff deleted]

>I think you've misunderstood my report.  I find that xterm and emacs
>*are* aware of the change of focus and reflect this awareness by
>having filled or hollow cursors.  Epoch, too, is aware of focus
>changes when they occur in by the more direct movement of the mouse
>from one region of the screen to another.

>Unlike emacs and xterm and a number of other apps where this is
>relevant, epoch is not aware of focus changes when they occur as a
>result of keyboard input.  I don't know exactly whose fault it is or
>what the deal is exactly.  But i do know that emacs and xterm handle
>this event appropriately. 

I can confirm this (I noticed it only the day before yesterday myself)
Epoch doesn't change the state of the cursor where xterm does as the
result of a keypress event. Not that it's too much of a problem though.

--Jeroen

>Epoch is the problem this time -- not twm.



>rodrigo
Newsgroups: gnu.epoch.misc
From: eeide%asylum.cs.utah.edu@cs.utah.edu (Eric Eide)
Subject: Problems with Read-Only Zones in Epoch 4.2
Organization: University of Utah Department of Computer Science
Distribution: gnu
Date: 6 Nov 92 17:04:23

Today I started experimenting with read-only zones in Epoch 4.2 and I
immediately found three bugs!  How discouraging :-(.

  + The documentation refers to the function "epoch::zone-read-only", but the
    real name is "epoch::zone-read-only-p".  The wrapper is misnamed, too.

  + The function epoch::set-zone-read-only changes the value of the current
    buffer's read-only button count, not the count for the zone's buffer.
    (This was quite confusing, as I was entering forms in the *scratch* buffer
    to manipulate a zone in another buffer.  I made my test zone read-only, but
    it didn't actually become read-only until I made another call to
    epoch::move-zone.)

  + I set the style of my read-only zone to include an underline.  I have found
    that when I insert a character immediately before the zone, that new
    character is underlined (but is apparently not in the zone?).  At the next
    event (e.g., hitting the Control key) the underline beneath the new
    character disappears.  Hitting two characters in a row results in the first
    being temporarily underlined; when the second character is inserted the
    underline for the first character disappears.

--
-------------------------------------------------------------------------------
Eric Eide          |          University of Utah Department of Computer Science
eeide@cs.utah.edu  | Buddhist to hot dog vendor: "Make me one with everything."
Newsgroups: gnu.epoch.misc
From: pth@ibm-1.mpa-garching.mpg.de (Peter Huebner)
Subject: where can we get epoch
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 09:05:32 GMT

We learnt that epoch is a X window implementation of emacs. We would
be interested in getting a copy. Please could you send us information
about the conditions to get this program and where we can get.
Please send your answer to pth@ibm-1.mpa-garching.mpg.de.

Yours sincerely, Peter Huebner,
Max-Planck-Institut for Astrophysics 
Newsgroups: gnu.epoch.misc
From: bharat@volt.stp (Bharat Mitbander)
Subject: Epoch4.2 key-binding probs.
Organization: MCC
Date: Mon, 9 Nov 1992 19:41:34 GMT


Hello all - I just upgraded to Epoch4.2 and promptly encountered the
much discussed eightbit-keyboard bug. In my case, the system barfs on
M-<key> definitions in isearch-mode. 

The configuration details are as follows:

        Sparc1 running SunOS4.1.3
        Epoch 4.2 with Marc's patch (of 11 Sep 92) to src/keymap.c applied.
        EIGHTBIT-KEYBOARD *not* defined.

Any hints/patches etc. for circumventing this problem will be highly
appreciated. 

Thanks,
Bharat Mitbander
bharat@mcc.com
Newsgroups: gnu.epoch.misc
From: ko@surya.ATt.COM
Subject: Epoch 4.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 22:29:32 GMT

   Hi,

I just got Epoch 4.0, and I would like to know if it will work on a Sun
sparc running 4.1.1 and OpenWindows3.0. I tried to figure it out from the
documentation, but I am not sure of the answer.

Thanks.


Kostas N. Oikonomou			Internet:  ko@surya.ho.att.com
AT&T Bell Laboratories, Rm 3M-521	uucp:  ...!att!honet7!ko
101 Crawfords Corner Road		Telephone:  +1 908 949 2175
P.O. Box 3030				
Holmdel, NJ  07733-3030			FAX:  +1 908 949 1652
From: shadagop@remus.rutgers.edu (Narayanan Shadagopan)
Newsgroups: gnu.epoch.misc
Subject: Epoch does not build
Keywords: make fatal error
Date: 13 Nov 92 07:32:47 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


I am having a lot of trouble building Epoch-4.2 (as opposed to
Epoch-4.0). Could someone please tell me what is going on with
the following problem:

central.rutgers.edu% make no.ascii
cd etc; make  all
cd src; make  all
make  -f xmakefile  all
cc -c -g -Demacs  -fsoft -I/usr/openwin/include  crt0.c
as: "/tmp/ccom.02073.1.s", line 219: error: redefinition of symbol
"__start"
*** Error code 1
make: Fatal error: Command failed for target `crt0.o'
Current working directory /central/c4/shadagop/epoch-4.2/src
*** Error code 1
make: Fatal error: Command failed for target `doall'
Current working directory /central/c4/shadagop/epoch-4.2/src
*** Error code 1
make: Fatal error: Command failed for target `src'

---

-Nary
-- 
E-mail: shadagop@central.rutgers.edu
Newsgroups: gnu.epoch.misc
From: vaitkus@ceres.lexmark.com (Keith Vaitkus)
Subject: Send Help -- epoch manual in PS form wanted
X-Disclaimer: These views are the poster's and not necessarily those of Lexmark
Organization: Lexmark International
Date: Fri, 13 Nov 1992 15:45:16 GMT

Ok. I give up. I am trying to get a hard-copy of the epoch
manual, and the process has passed my tolerance level for 
difficulty -- Now I must _beg_ for help.

The manual is in TeX format, which is to say it might as well
be in Sanskrit, because none of us can get it to print. We have
gotten the manual into a .dvi format. At that point, I am told,
we need to run dvips on it to get it into postscript format
for our printers to munch on. But I say -- It cant be done!

I have been unable to get a working copy of dvips running -
the make file bombs on the pfd2ftm module complaining that it
cannot find "Courier.afm". Nothing I have tried fixes this,
and it occured to me that there might be an easier solution:

Can someone give me or tell me where to get a copy of the
epoch manual that is already _in_ postscript format?

Now you can call me a quiter for giving up, but all I really
wanted was the manual, and all I seem to be getting is an
ulcer. 


Bless the kind sole that helps the needy, mentally deficient Unix user!

--

---------------------------------------------------------------------------
                                              /\    Keith Vaitkus
                                             //\\   
                                            ///\\\  Lexmark International
                                            \\\///  email: vaitkus@lexmark.com
                                             \\//   voice: (606) 232-4382 
                                              \/
From: shadagop@remus.rutgers.edu (Narayanan Shadagopan)
Newsgroups: gnu.epoch.misc
Subject: Re: Epoch does not build
Summary: machine specification
Keywords: make fatal error
Date: 13 Nov 92 17:05:50 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

In article <Nov.13.02.32.47.1992.8667@remus.rutgers.edu>, I wrote

> I am having a lot of trouble building Epoch-4.2 (as opposed to
> Epoch-4.0). Could someone please tell me what is going on with
> the following problem:
[... deleted]

> make: Fatal error: Command failed for target `src'
> 
> ---
> 
> -Nary
> -- 
> E-mail: shadagop@central.rutgers.edu

I am trying to build Epoch-4.2 on a Sun3/50 running Berkeley Unix 4.1.
I am sorry about not specifying this information in the previous 
posting.

Thanks.

-Nary
-- 
E-mail: shadagop@central.rutgers.edu
Newsgroups: gnu.epoch.misc
From: mdb@cisco.com (Mark D. Baushke)
Subject: Re: bug with X window focus switching?
Organization: cisco Systems Inc., Menlo Park, CA, USA
Distribution: gnu
Date: Mon, 9 Nov 1992 13:50:34 GMT

On Tue, 10 Nov 92 00:41:59 -0500, rv@cs.brown.edu (rodrigo vanegas) said:


>rodrigo> Has anyone had similar problems?

> I am able to reproduce your results.

> The same behavior occurs with an xterm. I do not consider this a bug.


rodrigo> That's funny.  It happens neither to my xterms nor to my emacs.
rodrigo> Is the cursor always filled for you?

The cursor is only filled for me when the pointer is in the same
window as the cursor.

The original intent of the filled cursor was to let you know where the
focus was. However, no focus events are sent to either emacs or xterm.

The twm icon manager is the one handling the decorations, so it knows
that it wants to see the window corresponding to the icon manager
entry to be highlighted. You may consider this a bug in twm if you
wish, but emacs, epoch, and xterm all have no knowledge of how the
events are reaching it when it is not currently the window in 'focus'.

	-- Mark
Newsgroups: gnu.epoch.misc
From: jbpn1@cl.cam.ac.uk (J.B.P. Naylon)
Subject: Epoch startup options
Reply-To: jbpn1@phx.cam.ac.uk
Organization: U of Cambridge Computer Lab, UK
Date: Fri, 13 Nov 1992 17:14:48 GMT

Sorry to ask such a trivial question, but the documentation I can find
doesn't say:  what are the possible startup options for Epoch (i.e. on
the command line).  More specifically, how can I specify the minibuffer
geometry?  Many thanks in advance for replies,

					john

-- 
fnord
From: shadagop@remus.rutgers.edu (Narayanan Shadagopan)
Newsgroups: gnu.epoch.misc
Subject: building Epoch 4.2
Keywords: eight-bit keyboard, define_change_functions
Date: 9 Nov 92 19:34:41 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


I am trying to install the Epoch 4.2, and I have a couple of questions 
about editing the config.h file. At the bottom there are a few undefined
variables such as define_change_functions, eightbit_keyboard, and have_
graphic_zones. What are these variables for and how do I set them? 
Thanks.

-Nary
-- 
E-mail: shadagop@central.rutgers.edu
Newsgroups: gnu.epoch.misc
From: sibley@math.psu.edu (David Sibley)
Subject: cut & paste
Organization: Department of Mathematics, The Pennsylvania State University
Date: Sun, 8 Nov 1992 20:49:16 GMT

We just got Epoch 4.2 here.  There is a small problem with cut &
paste.  With no changes, I can cut & paste between epoch and an xterm.
If I add the bit of lisp code in the Info file (to use the CLIPBOARD),
I can cut & paste between epoch and OpenWindows programs, like
textedit.  But I can't seem to set up for both at once.  Is there some
way to do this?  We would like to set global defaults that will allow
cut & paste in both circumstances.


David Sibley
sibley@math.psu.edu

Newsgroups: gnu.epoch.misc