HDTenEightyP/NetNews huggingface dataset:
I sent this message to the bugs mailing list over the holiday week,
but no one responded ... so I thought I would send it one more time.
Thanks for your patience.

I sucked over the precompiled binaries and the full distribution for
Lucid Emacs v. 19.3 from labrea,  installed these on my Sparc 10/30
(SunOS 4.1.3), attempted to start up lemacs and ...

Fatal error (11).Segmentation fault.

dbxtool claims that this occurs in make_string_internal at line 817 in
file alloc.c (though I'm somewhat suspicious of dbxtool's veracity).

Is this a known problem?  We don't have gcc here (or any ANSI C
compiler for that matter), so I haven't attempted to build the
binaries myself. 

Just to make the puzzle more interesting, lemacs actually came up once?!?!

BTW, We have been running 19.2 lemacs just fine on these self-same
machines. 

--Eric

--
*****************************************************************
*		Eric Jenkins					*
*		Trionix Research Laboratory, Inc.		*
*		8037 Bavaria Rd.				*
*		Twinsburg, OH     44087				*
*								*
*		(216) 425-9055					*
*		(216) 425-9059 (FAX)				*
*		(800) 442-7017					*
*								*
*		eaj@trionix.com					*
*****************************************************************
Newsgroups: alt.lucid-emacs.bug
From: jsparkes@bcars68a.bnr.ca (Jeff Sparkes)
Subject: Re: motion events on mode lines
Organization: Bell-Northern Research Ltd, Ottawa, Ontario, Canada
Date: Thu, 7 Jan 1993 15:59:54 GMT

In article <9301061953.AA24260@thalidomide.lucid> jwz@lucid.com (Jamie Zawinski) writes:
>In message <9301061609.AA09125@moebius.loria.fr> Guido Bosch wrote:
>>
>> Another point is that there should be sth. like a
>> mouse-{leaves,enter}-screen-hook, to be called when the mouse is
>> leaving or entering an Emacs screen.
>
>That's what mouse-enter-hook and mouse-left-hook are.  But be careful not to

Shouldn't they both be the same tense?  It's inconsistent and mildly annoying 
this way.
--
--
Jeff Sparkes jsparkes@bnr.ca	Bell-Northern Research, Ottawa (613)765-2503
You know, a muffin can be *very* filling.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 6 Jan 1993 11:14:58 EST
Date: Wed, 6 Jan 1993 17:09:50 +0100
From: Guido.Bosch%loria.fr@lucid.com (Guido Bosch)
Subject: motion events on mode lines
Reply-To: bosch%loria.fr@lucid.com (Guido Bosch)
Newsgroups: alt.lucid-emacs.bug
Hi,

I made the following patch to the mouse-track function (on button1),
which makes it look less bogus if you click on the modeline:

*** mouse.el~   Fri Sep  4 11:42:50 1992
--- mouse.el    Wed Jan  6 17:02:01 1993
***************
*** 483,489 ****
  See also the `mouse-track-adjust' command, on \\[mouse-track-adjust]."
    (interactive "e")
    (if (eq window-system 'x)
!       (x-focus-screen (window-screen (event-window event))))
    (mouse-track-maybe-own-selection
     (mouse-track-select event nil 'primary-selection)
     'PRIMARY))
--- 483,492 ----
  See also the `mouse-track-adjust' command, on \\[mouse-track-adjust]."
    (interactive "e")
    (if (eq window-system 'x)
!       (x-focus-screen 
!        (window-screen 
!       (or (event-window event)
!           (error "not in a window.")))))
    (mouse-track-maybe-own-selection
     (mouse-track-select event nil 'primary-selection)
     'PRIMARY))

BTW, why do motion events that occur when the mouse is over a windows
modeline don't have an associated window (and thus no buffer)?
Evaluate the following piece of code to check this behavior:

(defun testhandler (event)
  (message"%s" (event-window event)))

(let ((mouse-motion-handler 'testhandler))
  (read-char))  

This is not very handy, because motion handlers that interprete
motion events can't do any particular operations on mode lines, such as
mooving them in order to resize splitted windows. I don't know whether
there is a technical reason for this behavior, but it would be nice if
this could be changed in a further release.

Another point is that there should be sth. like a
mouse-{leaves,enter}-screen-hook, to be called when the mouse is
leaving or entering an Emacs screen.

	Guido
From: hb@csd.uu.se (Henrik B}kman  CSD)
Newsgroups: alt.lucid-emacs.bug
Subject: problems with lemacs 19.3 and motif 1.2.1
Date: 10 Jan 1993 15:41:08 GMT
Organization: Computing Science Department
Distribution: world
NNTP-Posting-Host: woody.csd.uu.se

Hello.

I have some problems with lemacs 19.3 compiled with motif 1.2.1.
The build seems to work ok but when I run it I get

	Program received signal 11, Segmentation fault
	0x1506c0 in _XmGetNavigability ()

(This text is from gdb). A traceback from gdb has this on the
"bottom"

	#0  0x1506c0 in _XmGetNavigability ()
	#1  0x151c58 in _XmNewTravGraph ()
	#2  0x151e48 in _XmNewTravGraph ()
	#3  0x151a68 in _XmNewTravGraph ()
	#4  0x151654 in _XmTraverse ()
	#5  0x14e8b0 in _XmMgrTraversal ()
	#6  0x14fac0 in XmProcessTraversal ()
	#7  0xcc87c in xm_set_keyboard_focus ()
	#8  0xca390 in lw_set_keyboard_focus ()
	#9  0x32348 in x_focus_screen (s=0x324400) at xterm.c:2587

I'm not so good in this motif-stuff so I don't know what the problem
is. Is lemacs 19.3 supported with motif 1.2.1? Has anyone seen this
problem before? What shall I do to find out the problem?

-- 
----------------------------------------------------------------------
Henrik Bakman           Adress: Box 311          Tel: +46 18 181044
System Manager                  751 05 UPPSALA   Fax: +46 18 521270
Computing Science Dep.          SWEDEN           Email: hb@csd.uu.se
Uppsala University
From: c23mts@kocrsv01.delcoelect.com (Mike Scheidler)
Newsgroups: alt.lucid-emacs.bug
Subject: Re: motion events on mode lines
Date: 6 Jan 93 18:00:11 GMT
Reply-To: c23mts@kocrsv01.delcoelect.com
Organization: Delco Electronics Corp.
Originator: c23mts@kocrsw12


In article <9301061609.AA09125@moebius.loria.fr>, Guido.Bosch%loria.fr@lucid.com (Guido Bosch) writes:
> Another point is that there should be sth. like a
> mouse-{leaves,enter}-screen-hook, to be called when the mouse is
> leaving or entering an Emacs screen.


I haven't used them myself, but these hooks are already there:

mouse-enter-hook
  Variable: Function to call when mouse enters a screen.  One arg, the screen.

mouse-left-hook
  Variable: Function to call when mouse leaves screen.  One arg, the screen.

-- 
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
From: haydens@bullwinkle.juliet.ll.mit.edu (Hayden Schultz x3685 g42)
Newsgroups: alt.lucid-emacs.bug
Subject: VM hangs
Date: 4 Jan 93 21:11:18 GMT
Reply-To: haydens@juliet.ll.mit.edu
Distribution: alt.lucid-emacs.bug
Organization: M.I.T. Lincoln Lab - Group 42


I'm running lemacs 19.3 with the extents.c-patch on a sun4 under sunos
4.1.1. VM seems to run much better, but it still lemacs hangs and
occasionally dies.

Everything else seems to work quite well.

Is anyone successfully running VM under lemacs 19.3? On a sun? Anyone
have any suggestions about what I can do to get this to work?

If it would help, I can attach to the hung process in gdb and give the
stack.

	Thanks,

	Hayden Schultz
	haydens@juliet.ll.mit.edu
	MIT Lincoln Lab
	(617) 981-3685
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 12 Jan 1993 06:43:34 EST
Date: Tue, 12 Jan 1993 11:40:52 GMT
From: djh@CIS.Prime.COM (David Hughes)
Subject: Re: Solution to buff-menu.el bug
Newsgroups: alt.lucid-emacs.bug
Lucid Emacs used to have focus-in problems if you are using the built-in window
manager on an NCD X-terminal.  Is it your case?
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Newsgroups: alt.lucid-emacs.bug
Subject: Re: motion events on mode lines
Date: 7 Jan 93 17:09:17 GMT
	<1993Jan7.155954.14355@bcars6a8.bnr.ca>
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.


    JWZ> That's what mouse-enter-hook and mouse-left-hook are.  But be
    JWZ> careful not to

    Jeff> Shouldn't they both be the same tense?  It's inconsistent
    Jeff> and mildly annoying this way.

I agree... Me:"What about mouse-right-hook?"  Sounds like some kind of
boxing-mode.el thing... ;-)
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 12 Jan 1993 18:09:45 EST
Return-Path: <valuk@eniac.seas.upenn.edu>
From: valuk@eniac.seas.upenn.edu (Timothy D Valuk)
Posted-Date: Tue, 12 Jan 93 18:09:18 EST
Subject: can't start lucid
Date: Tue, 12 Jan 1993 18:09:18 EST
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: alt.lucid-emacs.bug
Lucid emacs has apparently been "made" correctly, but when I load it
from an X terminal, I am not allowed to type in the window.  It looks
like it is caught in a quit loop of some kind.  Has anyone else had
this problem?

------------------------------------------------------------------------------
Timothy D. Valuk                                University Of Pennsylvania
CETS Technical Staff		    		
valuk@pender.ee.upenn.edu			Room 057c Moore
valuk@eniac.seas.upenn.edu                      (215) 898-2476
------------------------------------------------------------------------------

Newsgroups: alt.lucid-emacs.bug
From: rct@fulcrum.co.uk (Richard Taylor)
Subject: Re: motion events on mode lines
Organization: Fulcrum Communications
Date: Fri, 8 Jan 1993 10:23:34 GMT


>>That's what mouse-enter-hook and mouse-left-hook are.  But be careful not to
				   ^^^^^^^^^^^^^^^

One mean mouse....

Regards,
============================================================================
Richard Taylor                  DoD #981                 (rct@fulcrum.co.uk)
"All I want is a warm bed and a kind word and unlimited power"  A. Brilliant
============================================================================
Fulcrum Communications Ltd., Fordrough Lane, Birmingham, B9 5LD, ENGLAND.


x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 5 Jan 1993 17:26:48 EST
Date: Tue, 5 Jan 1993 16:26:44 -0500
From: max@ccrl.nj.nec.com (Maximilian Ott)
Subject: Re: Shouldn't the audio part be moved out of lemacs?
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Newsgroups: alt.lucid-emacs.bug
On Tue, 5 Jan 1993, Jamie Zawinski wrote:
> This sort of thing would be ok, if you could hand it sound data instead of
> just a filename, but the system doesn't provide such a program: you'd have to
> write the audio-handling code yourself, which is the hard part.  So why not
> just link it in to emacs directly and avoid the overhead of having to fork a
> process?

You have to read in the sound data at the beginning anyway. So you could
start the audio client by handing over a list of sound files and later
use symbolic names. The client then could preload the sound data.

The big problem I have with the current setup is that on a sun a program
needs exclusive access to the audio port. I'm working on shared
environments where I use the built-in audio port  for audio-conferencing.
During the time another program is using the audio port emacs is "dumb".
(In fact I get a few error messages.) 

Don't get me wrong, it would be preferable to link in a library which
connects to an audio server ala "rplayd". But there is no standard, yet.
Forking a separate process gives you enough flexibility to do whatever you
want without needing to relink emacs everytime. The previously mentioned
"eplay" provides just the most basic service. Nothing different from what
is built in now. But this can be developed further, completely independent
of emacs.

> > Furthermore, lemacs will (hopefully soon) become a full X-client which
> > requires the sound to "travel" as well. 
> 
> I don't know quite what you mean by "full X client," but I think lemacs is
> one...  As you know, X has nothing to say about sound.  (I guess you could
> say it keeps quiet on the issue...)

Sorry about that. I thought that I ran into problems directing the display
to a different machine. (was this in one of the older versions?)

However, the issue of sound and X is another argument for separating the
sound so we can experiment with sound servers until we get that capability
in X. (As I said before "rplay[d]" is a good first step)

Regards,

max

-----
Max Ott                 max@ccrl.nj.nec.com         phone: (609)951-2469
NEC C&C Research        Princeton, NJ, 08540        fax:   (609)951-2499


Newsgroups: alt.lucid-emacs.bug
From: gamin@ireq-robot.hydro.qc.ca (Martin Boyer)
Subject: Re: Solution to buff-menu.el bug
Organization: Le laboratoire de robotique de l'Institut de recherche
	d'Hydro-Quebec
Date: Mon, 11 Jan 1993 23:06:36 GMT

>>>>> Richard Mlynarik writes:

>One should immediately discount any elisp code which includes "(require 'cl)"

And one should immediately discount any unsubstantiated statement.

Many said that the 'cl package has problems -- and they are probably
right, but the main problem is that those who make such claims can't
pinpoint them and can't present examples.  If we are to fix those
problems, please elaborate; 'cl is useful and certainly isn't beyond
salvation.

--
Martin Boyer                            mboyer@ireq-robot.hydro.qc.ca
Institut de recherche d'Hydro-Quebec    mboyer@ireq-robot.uucp
Varennes, QC, Canada   J3X 1S1
+1 514 652-8412
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 11 Jan 1993 12:10:02 EST
Date: Mon, 11 Jan 1993 17:06:09 GMT
From: djh@CIS.Prime.COM (David Hughes)
Subject: Re: Solution to buff-menu.el bug
Newsgroups: alt.lucid-emacs.bug
This bug will be fixed in 19.4; I posted a new version of window.c to this
list a while ago which fixes the problem.  Check the archives, or send me
mail and I'll send it to you.

	-- Jamie
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 11 Jan 1993 21:06:46 EST
Date: Mon, 11 Jan 1993 15:33:05 PST
X-Windows: Power tools for power losers.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: Solution to buff-menu.el bug
	<GAMIN.93Jan11180636@amadeus.ireq-robot.hydro.qc.ca>
Newsgroups: alt.lucid-emacs.bug
I disagree; cl.el is indeed beyond salvation.

Enumerating all its faults would take much longer than I'm willing to 
spend on it...
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 5 Jan 1993 15:59:05 EST
Date: Tue, 5 Jan 1993 12:55:13 PST
X-Windows: A terminal disease.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: Shouldn't the audio part be moved out of lemacs?
	<Pine.3.05.9301051114.B17104-b100000@trillian>
Newsgroups: alt.lucid-emacs.bug
The reason I built the audio code into emacs instead of just forking whatever
"play" program the system provides is that playing sounds is different from
something like ispell in that emacs plays sounds as part of its error-handling
routines.  because of the time-criticalness of this, I don't want emacs to
have to access the file system to play a sound.  Execing "play" would mean at
least two accesses: getting the play executable (actually this would probably
be dozens, since it would have to search the path) and then reading the sound
file.  Getting NFS lossage just because you typed ^G would be very bad news.

> One solution would be to use a interface similar to "ispell". Last night I
> hacked up a simple program "eplay" which waits for the name of a sound
> file, opens the audio port, plays it, closes the audio port and loops back
> to the beginning. 

This sort of thing would be ok, if you could hand it sound data instead of
just a filename, but the system doesn't provide such a program: you'd have to
write the audio-handling code yourself, which is the hard part.  So why not
just link it in to emacs directly and avoid the overhead of having to fork a
process?

> The elisp interface should fit on a single page. (It is a bit messy as it
> seems that the (only?) C-primitive ring_bell[_hook] is called within a few
> built-in defuns: play-sound-file play-sound ding)

But since it's called indirectly from cmd_error, there are interrupt issues
involved: it would be hard to make running arbitrary lisp code from the error
handler work.  You'd have to run that code with interrupts off, and would
probably have GC protection problems as well.

> Furthermore, lemacs will (hopefully soon) become a full X-client which
> requires the sound to "travel" as well. 

I don't know quite what you mean by "full X client," but I think lemacs is
one...  As you know, X has nothing to say about sound.  (I guess you could
say it keeps quiet on the issue...)

	-- Jamie
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 6 Jan 1993 12:01:43 EST
Date: Wed, 6 Jan 1993 16:48:53 GMT
From: djh@CIS.Prime.COM (David Hughes)
Newsgroups: alt.lucid-emacs.bug
Subject: (no subject given!)

Excerpt of message (sent 6 January 93) by Guido Bosch:
> 
> BTW, why do motion events that occur when the mouse is over a windows
> modeline don't have an associated window (and thus no buffer)?
> Evaluate the following piece of code to check this behavior:
> 
> (defun testhandler (event)
>   (message"%s" (event-window event)))
> 
> (let ((mouse-motion-handler 'testhandler))
>   (read-char))  
> 
> This is not very handy, because motion handlers that interprete
> motion events can't do any particular operations on mode lines, such as
> mooving them in order to resize splitted windows. I don't know whether
> there is a technical reason for this behavior, but it would be nice if
> this could be changed in a further release.

Guido - this is something I fixed with djh-imouse...

--
Regards, David
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Fri, 8 Jan 1993 14:07:03 EST
Date: Fri, 8 Jan 1993 19:03:18 GMT
From: djh@CIS.Prime.COM (David Hughes)
Subject: Solution to buff-menu.el bug
Newsgroups: alt.lucid-emacs.bug
In message <199301062158.AA28804@wsrcc.com> Wolfgang S. Rupprecht wrote:
>
> I believe what we really need is the next level hack;-) a network socket
> that emacs opens to the appropriate machine to send the audio data down.
> If done correctly this could even allow for multiple simultaneous audio
> sources.  Is there already such a TCP port and service specified?

Yes, I agree.  I know of at least three implementations of this sort of
thing, but none of them seem to have really caught on yet.  I've got no
problem with including code to talk to these servers.  But I don't have
time to write it myself...

But what Max is asking for is slightly different, though related: he has
written a better device driver and wants an easier way to make emacs use
it.  So he wants a more flexible emacs audio API than "link in a new
definition of the play_sound() function."

	-- Jamie
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 7 Jan 1993 06:33:48 EST
Date: Thu, 7 Jan 1993 13:34:59 GMT
From: ori@marvin.technion.ac.il (Ori Degani)
Subject: Out of Memory?
Newsgroups: alt.lucid-emacs.help
I'm running Lucid Emacs, for not so long on my SGI Indigo..
I was using gdb from inside emacs, (I don't know if thats the prob)
and the machine got stuck, it logged my session out, and in SYSLOG was
the line:
Jan  7 12:43:40 marvin unix: WARNING: Process [Xsgi] pid 3058 killed due to insufficient memory/swap.

Do you know what the problem is?  Is it anything to do with Emacs at all?

Thanks,
Ori
   |  ----      Ori Degani
   |  |___      ori@eddie.technion.ac.il   (Ship Computer on the HOG)
   |  |         ori@marvin.technion.ac.il  (Who else) 
   |  ----      s2973229@techst02.technion.ac.il (Ech..)   

x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 7 Jan 1993 17:59:56 EST
Date: Fri, 8 Jan 1993 09:47:19 EST
From: rwhitby%research.canon.oz.au@lucid.com (Rod Whitby)
Subject: Re: VM, and MAN
	<GRUNWALD.93Jan7105649@mumble.cs.colorado.edu>
Newsgroups: alt.lucid-emacs.help
[OD = ori@marvin.technion.ac.il (Ori Degani)]

OD> Hi, I'm running on SGI's IRIX 4.5, on an Indigo.  My three
OD> problems are these: 1) For some reason the function man doesn't
OD> work (it can't find the manuals) even though I saw the manual
OD> paths are correct ( I think ).

Dirk> I had a similar problem and replaced the supplied 'man' with..
..
Dirk> ; Filename:	tek-man.el
..
Dirk> ; This version by:	Ken Wood, <kwood@austek.oz.au>
Dirk> ; Organisation:		Austek Microsystems Pty Ltd, Australia.
..
Dirk> ; Description:	Enhanced manual browser. Invoke with "M-x man".

I'm the current maintainer of tek-man (I took it over when the company
that Ken and I worked for went out of business).

If you don't want epoch support (and I notice in the included file
that you have commented out the epoch support), then I would suggest
that you try out the "superman" package:

	 GNU Emacs Lisp Code Directory Apropos -- "superman"
"~/" refers to archive.cis.ohio-state.edu:/pub/gnu/emacs/elisp-archive/

superman (1.0)	      17-Jul-1991
     Barry A. Warsaw, <bwarsaw@cen.com>
     ~/misc/superman.tar.Z
     Background Un*x manual page formatter and mode.

It does everything that a non-epoch tek-man does, and everything that
tek-man wanted to do, and more.  It is also more easily extensible.

Let's just say that I have dropped tek-man (which I had a hand in
writing) in favour of superman :-)

My future plans for tek-man are to simply make it a hook addition to
superman (i.e. it will give epoch highlighting and mouse support to
superman).

--------------------------------------------- _--_|\  |
Rod Whitby (rwhitby@research.canon.oz.au)    /      \ |
Canon Information Systems Research Australia \_.--._/ |
1 Thomas Holt Drive, North Ryde, N.S.W., 2113.     v  |
From: rct@fulcrum.co.uk (Richard Taylor)
Newsgroups: alt.lucid-emacs.help
Subject: X resource name for primary selection colour, etc
Date: 4 Jan 93 12:42:10 GMT
Organization: Fulcrum Communications


Somewhere, someone must have listed all the possible X resources, but I
can't find them in the distribution.

I need to know the names of the following resources in Version 19.3:

    primary selection background (was attribute70.attributeBackground)

    search string background (was attribute72.attributeBackground)


We also have a problem that V 19.3 does not die when the user exits. This
occurs on a Sun SunOs 4.1.3. Any ideas?

Please could you reply by email. Thanks in advance,
Regards,
============================================================================
Richard Taylor                  DoD #981                 (rct@fulcrum.co.uk)
"I don't know what I want, but I want it NOW!", Rawlinson of Rawlinson's End
============================================================================
Fulcrum Communications Ltd., Fordrough Lane, Birmingham, B9 5LD, ENGLAND.
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 7 Jan 1993 02:40:01 EST
Date: Thu, 7 Jan 1993 09:41:16 GMT
From: ori@marvin.technion.ac.il (Ori Degani)
Subject: Switching DEL and BS
Newsgroups: alt.lucid-emacs.help
I want to SWITCH the DEL, and BS definitions
      (define-key global-map "\b" 'backward-delete-char-untabify) 
is not good enough because other functions use the DEL key (e.g. isearch)
In the old faq there was something about changint the translation table
but that doesn't work on lemacs.

Thanks, 
ori
   |  ----      Ori Degani
   |  |___      ori@eddie.technion.ac.il   (Ship Computer on the HOG)
   |  |         ori@marvin.technion.ac.il  (Who else) 
   |  ----      s2973229@techst02.technion.ac.il (Ech..)   

Newsgroups: alt.lucid-emacs.help