HDTenEightyP/NetNews huggingface dataset:
From: Jack.Smoke@bbs.oit.unc.edu (Jack Smoke)
Newsgroups: alt.callahans
Subject: Smoke tells a story
Date: 12 Oct 92 15:27:46 GMT
Organization: Extended Bulletin Board Service

Evening falls.  The feast has ended.  THe adults sneak off back
to the bar, leaving Smoke surrounded by children of many ages,
clamoring for another story.
	Smoke sighs.  "I did not think I would be one of the 
old  men at such a young age."  He takes Phee, the youngest child,
on his lap, and begins to speak.
	"I will tell you how the Rabbit escaped from the Wolves.
	This is what the old men told me when I was a boy.  Some
Wolves once caught Rabbitt, and were going to eat him.  He asked
permission to show them the dance he was practicing before they ate
him.  Now, wolves are great dancers, and allways want to learn the 
latest dance.  They knew that Rabbitt was a great song leader, and 
so they agreed and made a circle arround him while he got ready.
He patted his feet, and began to dance in a circle, singing:
	Tlage'situn' gali'sgi'sida'ha -
	Ha'nia lil! lil! Ha'nia lil! lil!

Which, in English, means:
	On the edge of the field I dance about - 
	Ha'nia lil! lil! Ha'nia lil! lil!

	'Now,' said the Rabbit, 'When I sing 'on the edge of the field,'
I dance that way' - and he danced over in that direction -
'and when I sing 'lil! lil!' you stamp your feet, hard.'
	The wolves thought this was a fine dance.  Rabbitt began
another time to sing this same song, and he danced a little nearer
the field.  The wolves all stamped their feet.  Rabbitt sang louder 
and louder.  Each time the Wolves stamped harder and harder.  
On the Fourth time, when the Wolves were thinking only of the song, and
stamping as hard as they could, Rabbitt made one great leap over the heads
of the   wolves, and ran away through the high grass.
The Wolves followed, of course.  Rabbitt ran into a hollow tree and up
inside the stump.  One of the Wolves put his head inside after him,
but Rabbit spat in his eye, and so he had to take his head out again.
The other wolves were afraid to try, so they went away, leaving Rabbitt
still in the old tree."

--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80
Newsgroups: alt.callahans
From: rlm7337@tamsun.tamu.edu (Incarnadine)
Subject: Re: Another Introduction
Organization: Castle BBS
Date: Fri, 9 Oct 1992 16:46:59 GMT

In article <1992Oct8.003657.14209@ra.msstate.edu> jmpierce@whale.st.usm.edu (Jimmy Malcolm Pierce) writes:
>In article <2ad35744.kf8nh@kf8nh.UUCP> "Brandon S. Allbery" <allbery@ncoast.org> writes:
>>(P.S.  Not to mention that "nuclear" is pronounced the way it's spelled, and
>>*I* sure as heck don't spell it "nucular".  ...sigh, now I'm started on
>>linguistic flames.  When will I learn????)
>
>  <chuckle> "Have you ever been to Texas ? Back when I was a Theatrical Design
>Major, my theater voice instructor commented that she had heard people say such
>things over the year as 'winder' for 'window' , but Texans instead of adding
>a letter or two would add syllables !!! She told us that in Texas the word
>s**t has three syllables ! Its a good thing I lost my Texas accent, well its
>softened somewhat, otherwise most people would find my talking hard to
>understand..." Dreamy Jim.
> 
>-- 
> Jim Pierce Bach. of Sci. in Applied Computer Science
> jmpierce@whale.st.usm.edu  Disclaimer: Standard.
>  "Is it the weekend yet ?" me :-)

hee...
dunno if anyone pays attention to addresses, but I am a certified Texan myself..
and I know some people who could say s**t with three sylables.  I use two 
myself...conservation and all.

Incarnadine, who now has a sig, but can't figure out how to add it onto posts..
*grumble*
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Thu, 8 Oct 1992 07:48:34 EDT
From: djh@CIS.Prime.COM (David Hughes)
Subject: Function Keys unmapped by VM and dired
Date: Thu, 8 Oct 1992 11:48:35 GMT
Newsgroups: alt.lucid-emacs.bug
There is a problem in lemacs 19.3 running on a Sparc which I *know* did not
exists in lemacs 19.2 :

I use global-set-key to set (amongst others) the keys
  kp_subtract, kp_add, kp_enter, kp_decimal and insert to various functions.

However, when I enter VM or dired these keys become 'undefined' although the
other globally defined function keys retain their global settings. This does
not happen with lemacs 19.2. As a workaround, I have had to add the following
lines in my .emacs

(define-key vm-mode-map 'kp_subtract 'recenter)
(define-key vm-mode-map 'kp_add      'drag-up-display)
(define-key vm-mode-map 'kp_enter    'drag-down-display)
(define-key vm-mode-map 'kp_decimal  'forward-word)
(define-key vm-mode-map 'insert      'backward-word)

(define-key dired-mode-map 'kp_subtract 'recenter)
(define-key dired-mode-map 'kp_add      'drag-up-display)
(define-key dired-mode-map 'kp_enter    'drag-down-display)
(define-key dired-mode-map 'kp_decimal  'forward-word)
(define-key dired-mode-map 'insert      'backward-word)

This horrible! Why are kp_subtract, kp_add, kp_enter, kp_decimal and insert
getting zapped anyway?

--
Regards, David
Newsgroups: alt.lucid-emacs.bug
From: jsparkes@bcars68a.bnr.ca (Jeff Sparkes)
Subject: Re: window manager "quit" nukes emacs
Organization: Bell-Northern Research Ltd., Ottawa
Date: Wed, 14 Oct 1992 18:31:50 GMT

In article <9210121825.AA06429@thalidomide.lucid> jwz@lucid.com (Jamie Zawinski) writes:

>In message <1992Oct12.143716.615@bmerh85.bnr.ca> Hamish Macdonald wrote:
>>
>> Hmm... Lucid Emacs still doesn't advertise its willingness to accept
>> this message (by including WM_DELETE_WINDOW in WM_PROTOCOLS), so Mwm
>> *won't* send it a WM_DELETE_WINDOW message.  
>
>xprop says:
>
>WM_PROTOCOLS(ATOM): protocols  _MOTIF_WM_MESSAGES, WM_DELETE_WINDOW, WM_TAKE_FOCUS
>
>	-- Jamie

For me, running tvtwm and lemacs 19.3 under sunos 4.1.1, I only get:
WM_PROTOCOLS(ATOM): protocols  WM_TAKE_FOCUS

and this is all I get using mwm too..

--
--
Jeff Sparkes jsparkes@bnr.ca	Bell-Northern Research, Ottawa (613)765-2503
"For better gas mileage, do not drive with the parking brake on."
  - paraphrased from the owners manual of my Integra.
From: bosch@loria.fr (Guido Bosch)
Newsgroups: alt.lucid-emacs.bug
Subject: `x-set-point-and-insert-selection' bug
Date: 8 Oct 92 15:14:08 GMT
Reply-To: Guido BOSCH <bosch@loria.fr>
Distribution: alt
Organization: INRIA-Lorraine / CRIN, Nancy, France

I think this question has already been posted here, but I didn't see
any answer:

Since version 19.3, the function `x-set-point-and-insert-selection'
(middle mouse click) has a strange behavior: I grabs all the text from
the beginning of the current selection up to te cursor position and
copies it to point. This happens only for copy actions within the same
buffer. 

Is there a bug fix available?

Please send me also email, because our News are very delayed these
days

	Guido

--
Guido BOSCH, INRIA-Lorraine/CRIN
Institut National de Recherche en Informatique et en Automatique (INRIA)
Centre de Recherche en Informatique de Nancy (CRIN)
Campus scientifique, B.P. 239            
54506 Vandoeuvre-les-Nancy CEDEX       	
Tel.: (+33) 83.91.24.24
Fax.: (+33) 83.41.30.79                	
email: bosch@loria.fr
From: bosch@loria.fr (Guido Bosch)
Newsgroups: alt.lucid-emacs.bug
Subject: Re: `x-set-point-and-insert-selection' bug
Date: 8 Oct 92 16:23:58 GMT
Distribution: alt
Organization: INRIA-Lorraine / CRIN, Nancy, France
In-reply-to: bosch@loria.fr's message of 8 Oct 92 15:14:08 GMT

In article <BOSCH.92Oct8171408@moebius.loria.fr> bosch@loria.fr (Guido Bosch) writes:

 > Since version 19.3, the function `x-set-point-and-insert-selection'
 > (middle mouse click) has a strange behavior: I grabs all the text from
 > the beginning of the current selection up to te cursor position and
 > copies it to point. This happens only for copy actions within the same
 > buffer. 

 > Is there a bug fix available?

If there wasn't so far, here is one: The problem was that
`x-set-point-and-insert-selection' (in x-mouse.el) sets the point to
the mouse position *before* `x-get-selection' was called, but moving
point also changes the selection. So `x-get-selection' finally grabed
all text between the beginning of the primary selection and the new
point. Here is a fix for `x-set-point-and-insert-selection':


(defun x-set-point-and-insert-selection (event)
  "Sets point where clicked and insert the primary selection or the cut buffer"
  (interactive "e")
  (let ((text (or (condition-case () (x-get-selection) (error ()))
		  (x-get-cutbuffer)
		  (error "No selection or cut buffer available"))))
    (mouse-set-point event)
    (push-mark (point))
    (insert text)
;;  (if zmacs-regions (zmacs-activate-region))
    ))


--
Guido BOSCH, INRIA-Lorraine/CRIN
Institut National de Recherche en Informatique et en Automatique (INRIA)
Centre de Recherche en Informatique de Nancy (CRIN)
Campus scientifique, B.P. 239            
54506 Vandoeuvre-les-Nancy CEDEX       	
Tel.: (+33) 83.91.24.24
Fax.: (+33) 83.41.30.79                	
email: bosch@loria.fr             	
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 7 Oct 1992 20:17:12 EDT
Organization: Servio Corporation
Subject: Changes made to Lucid Emacs for AIX 3.2.1.
Date: Wed, 07 Oct 1992 18:52:39 -0500
From: screamer!harry@uunet.uu.net (Harry Weeks)
Newsgroups: alt.lucid-emacs.bug
From: ebg@atr-hr.atr.co.jp (Ed Gamble)
Newsgroups: alt.lucid-emacs.bug
Subject: Bug in Query-Replace with font-lock-mode on.
Date: 7 Oct 92 05:41:38 GMT
Organization: ATR Auditory and Visual Perception Research Labs., Japan


Lemacs 19.3, Lisp mode with (font-lock-mode 1)

;; buffer contents, for example
(defun foo ()
  )

(defun funny-foo ()
  )
;; end of buffer contents

Try (query-replace "foo" "bar" nil)

;; New buffer contents
 ()
  )

 ()
  )
;; End of new buffer contents


Frequently I also see 'foo' replaced with 'foobar'

Try (undo), (font-lock-mode 0), and then query-replace again...
Now no problem.


- Ed
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 7 Oct 1992 23:44:51 EDT
From: dmason%plg.uwaterloo.ca@lucid.com (Dave Mason)
Subject: pseudo bug in man.el
Date: Wed, 7 Oct 1992 23:44:31 -0400
Newsgroups: alt.lucid-emacs.bug
> From: jbw@bigbird.bu.edu (Joe Wells)
> In article <92Oct6.182437edt.29115@plg.uwaterloo.ca> dmason%plg.uwaterloo.ca@lucid.com (Dave Mason) writes:
> 
>     In our environment, MANPATH components end in /, hence the code in
>    man.el produced things like /usr/man//cat1, /usr/man//cat1, etc.
> 
> This is a sign that there is some Emacs Lisp code that is combining
> directories with filenames the wrong way.  This particular case probably
> came from GNU Emacs.

Much better solution.  Here's the corrected (and tested) patch.

	../Dave

; diff -bc man.elO man.el
*** man.elO     Wed Aug 26 04:18:20 1992
--- man.el      Wed Oct  7 23:38:16 1992
***************
*** 293,299 ****
  (defun Manual-select-subdirectories (dirlist subdir)
    (apply 'append (mapcar '(lambda (dir)
                           (and (file-exists-p dir)
!                               (mapcar '(lambda (name) (concat dir "/" name))
                                         (file-name-all-completions subdir dir))
))
                         dirlist)))

--- 293,299 ----
  (defun Manual-select-subdirectories (dirlist subdir)
    (apply 'append (mapcar '(lambda (dir)
                           (and (file-exists-p dir)
!                               (mapcar '(lambda (name) (expand-file-name name d
ir))
                                         (file-name-all-completions subdir dir))
))
                         dirlist)))
From: ebg@atr-hr.atr.co.jp (Ed Gamble)
Newsgroups: alt.lucid-emacs.bug
Subject: A Few Things
Date: 9 Oct 92 00:25:22 GMT
Organization: ATR Auditory and Visual Perception Research Labs., Japan


Lucid-Emacs 19.3, Sparc, Sunos 4.1.2

1 ) ilisp.el references 'common-lisp-indent-hook,  should read
    'common-lisp-indent-function (Fixed below.) 

    ;;;%%Common LISP
    (defdialect clisp "Common LISP"
      ilisp
      (if (not (fboundp 'common-lisp-indent-function))   ;; <<== Fixed
	  (load "cl-indent"))
      (setq lisp-indent-hook 'common-lisp-indent-function) ;; <<== Fixed
      ....)

2) ilisp-menu.el can't find (require 'simple-menu).  Neither can I.

3) Sound.  Having bound some sounds with, for example,
	 (load-sound-file "..../drip.au" 'undefined-key), I now get
   nice sounds; unfortunately, some error messages are printed as follows:
   audio: sst_open: SETQSIZE, Invalid argument   <<== before the sound
   audio: sst_close: SETREG MMR2, Invalid argument <<== after the sound.

4) With (setq mode-motion-hook 'mode-motion-highlight-sexp) and font-lock:
   often an sexp is not highlighted until the mouse is on the second character
   or on one character beyond the last character in the sexp.

5) Here is a regexp for font-lock mode that will 'properly' highlight 
	(def* (setf foo) (bar baz))

    "^(def[-a-z]+\\s +\\(\\s(\\S)*\\s)\\|\\S(\\S *\\)"

    Although, it won't highlight the setf sexp until the closing paren and
    still (defun foo) highlights the closing paren.

6) Occasionally in ilisp-mode I have lost the comint connection to my running
   lisp, been thrown into the lisp debugger or lost lemacs altogether.  Seems
   to happen when hitting the "I (ignore)" option to a failed
   'compile-lisp-defun command.  Maybe somebody has seen this, otherwise 
    I'll report more fully later



Jamie/Lucid -- keep up the good work.

- Ed
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Thu, 8 Oct 1992 11:15:47 EDT
From: gjditchf%plg.uwaterloo.ca@lucid.com (Glen Ditchfield)
Subject: super-kill kills
Date: Thu, 8 Oct 1992 11:14:47 -0400
Newsgroups: alt.lucid-emacs.bug
When I select some text, 
choose copy from the edit menu,
then select some other text, 
and subsequently choose paste from the edit menu,
the last selected text is pasted in (duplicated) at the cursor,
instead of being replaced by the previous one.

Not sure what the Gospel of the Lispm has to say about this behaviour.

Regards, Frank.

PS. using the pending-del package

x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Thu, 8 Oct 1992 00:38:29 EDT
Date: Wed, 7 Oct 1992 21:38:59 PDT
From: devin%scylla@lucid.com (Matthieu Devin)
Subject: Re: copy&paste behaviour
Newsgroups: alt.lucid-emacs.bug
I think there was a bug in 19.3 related to PASTE not being pending delete.
Make sure that the following is in your copy of pending-del.el:

(put 'x-yank-clipboard-selection 'pending-delete t)
Newsgroups: alt.lucid-emacs.bug
From: johnson@natasha.ics.Hawaii.Edu (Philip Johnson)
Subject: Probable bug in SORT
Organization: University of Hawaii, Department of Computer Science
Distribution: alt
Date: Fri, 9 Oct 1992 00:54:57 GMT

The following code works fine under Epoch and Emacs, but
breaks horribly under Lucid:

(defun cached-attribute-sort (attribute node-ID-list lessp-fn)
  "Returns the list NODE-ID-LIST sorted by key ATTRIBUTE with comparison function LESSP-FN."

  (let ((pair-list (mapcar (function (lambda (node-ID)
				       (cons (funcall attribute node-ID) node-ID)))
			   node-ID-list)))
    (setq pair-list (sort pair-list (function (lambda (pair1 pair2)
						(funcall lessp-fn (car pair1) (car pair2))))))

    (mapcar 'cdr pair-list)))

The basic idea is to cons up a list of attribute/ID pairs, sort by
attribute, then return the sorted IDs.(This avoids the overhead of
calling the attribute function on every comparison.)  For some reason,
after sorting a list of these pairs, the attribute has been mangled.

Straightforward application of this code fragment may not reliably reproduce
the error. If more context is required, I can try to supply it. 

Philip Johnson

-----------------------------------------------------------------------
Philip Johnson                                       johnson@hawaii.edu
Assistant Professor
Collaborative Software Development Laboratory
Department of Information and Computer Sciences   
University of Hawaii
2565 The Mall                                            (808) 956-3489
Honolulu, HI 96822                                  Fax: (808) 956-3548
From: rjc@cogsci.ed.ac.uk (Richard Caley)
Newsgroups: alt.lucid-emacs.bug
Subject: Cursor positioning bug?
Date: 15 Oct 92 16:16:53 GMT
Distribution: alt
Organization: Human Communication Research Center


(19.2, Sun, X11R4)

I have some problems with some code which works fine in epoch or
emacs-18. This code does some stuff, then goes to the top of the
buffer and searches repeatedly for different things to get to where it
aught to be. 

Anyway, after all this lemacs ends up showing me the beginning of the
buffer with the cursor at some place which bears no resemblence to any
of the patterns.

It doesn't happen when I use the debugger.

Before I start getting into the details of what is going on, I thought
I'd ask if a bug like this is known in 19.2 and if there is a
workaround.

--
rjc@cogsci.ed.ac.uk			_O_
					 |<
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 7 Oct 1992 22:06:06 EDT
Date: Wed, 7 Oct 1992 19:05:44 PDT
X-Windows: A moment of convenience, a lifetime of regret.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: window manager "quit" nukes emacs
Newsgroups: alt.lucid-emacs.bug
Oops, this used to work.  Here's a fix.

If there is more than one screen, then WM_DELETE_WINDOW deletes the screen.
Otherwise, it exits emacs.

	-- Jamie

===================================================================
RCS file: /cadillac-inferno-5/cvs-master/lemacs/src/event-Xt.c,v
retrieving revision 1.7
diff -c -r1.7 event-Xt.c
*** 1.7	1992/09/18 19:47:33
--- event-Xt.c	1992/10/08 01:34:22
***************
*** 879,885 ****
  			  RevertToParent, event->xclient.data.l[1]);
  	UNBLOCK_INPUT;
        }
!     goto OTHER;
      break;
  
    case MappingNotify:	/* The user has run xmodmap */
--- 879,886 ----
  			  RevertToParent, event->xclient.data.l[1]);
  	UNBLOCK_INPUT;
        }
!     else
!       goto OTHER;
      break;
  
    case MappingNotify:	/* The user has run xmodmap */
From: kingsley@hpwrce.mayfield.hp.com (Kingsley Morse)
Date: Fri, 9 Oct 1992 15:33:36 GMT
Subject: Re: Please Help
Organization: HP Western Response Center
Newsgroups: alt.lucid-emacs.bug

Oops! My apologies for posting my previous "Please Help" survey to this
group. It was an honest mistake and won't happen again.

Kingsley
Newsgroups: alt.lucid-emacs.bug
From: Hamish.Macdonald@x400gate.bnr.ca (Hamish Macdonald)
Subject: Re: window manager "quit" nukes emacs
Organization: Bell Northern Research
	<9210080205.AA19305@thalidomide.lucid>
Date: Mon, 12 Oct 92 14:37:16 GMT

>>>>> On Wed, 7 Oct 1992 19:05:44 PDT,
>>>>> In message <9210080205.AA19305@thalidomide.lucid>,
>>>>> jwz@lucid.com (Jamie Zawinski) wrote:

Jamie> If there is more than one screen, then WM_DELETE_WINDOW deletes
Jamie> the screen.  Otherwise, it exits emacs.

Hmm... Lucid Emacs still doesn't advertise its willingness to accept
this message (by including WM_DELETE_WINDOW in WM_PROTOCOLS), so Mwm
*won't* send it a WM_DELETE_WINDOW message.  It will just break the X
connection.  If Lucid is willing to accept and process these messages,
it should say so, IMHO.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 12 Oct 1992 14:25:08 EDT
Date: Mon, 12 Oct 1992 11:25:00 PDT
X-Windows: The problem for your problem.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: window manager "quit" nukes emacs
	<1992Sep30.154353.27792@src.honeywell.com>
	<9210080205.AA19305@thalidomide.lucid>
Newsgroups: alt.lucid-emacs.bug
In message <1992Oct12.143716.615@bmerh85.bnr.ca> Hamish Macdonald wrote:
>
> Hmm... Lucid Emacs still doesn't advertise its willingness to accept
> this message (by including WM_DELETE_WINDOW in WM_PROTOCOLS), so Mwm
> *won't* send it a WM_DELETE_WINDOW message.  

xprop says:

WM_PROTOCOLS(ATOM): protocols  _MOTIF_WM_MESSAGES, WM_DELETE_WINDOW, WM_TAKE_FOCUS

	-- Jamie
Newsgroups: alt.lucid-emacs.bug
From: Hamish.Macdonald@x400gate.bnr.ca (Hamish Macdonald)
Subject: Re: super-kill kills
Organization: Bell Northern Research
Date: Thu, 08 Oct 92 16:26:20 GMT

>>>>> On Thu, 8 Oct 1992 11:14:47 -0400,
>>>>> In message <92Oct8.111457edt.29117@plg.uwaterloo.ca>,
>>>>> gjditchf%plg.uwaterloo.ca@lucid.com (Glen Ditchfield) wrote:

Glen> My Emacs initialization code contains
Glen> 	(autoload 'super-kill "super-kill" t)
Glen> 	(global-set-key "\C-k" 'super-kill)
Glen> super-kill.el and the uuencoded .elc follow.  When I type C-k, I get a
Glen> segmentation fault and core dump out of lemacs version 19.3 on a Sun 4.
Glen> GDB 4.6 says 
Glen> 	(gdb) where
Glen> 	#0  0xd6998 in strlen ()
Glen> 	#1  0x18748 in echo_prompt () at event-stream.c:1058
Glen> 	#2  0x198ec in Fread_key_sequence () at event-stream.c:1735

Glen> [...]

Glen>   (let* ((key (read-key-sequence nil))
Glen> 	 (c (string-to-char key))
Glen> 	 (n (prefix-numeric-value arg))
Glen> 	 (buf (current-buffer))
Glen> 	 (p1 (point))
Glen> 	 p2 copy-only)

According to the documentation of read-key-sequence:

    One arg, PROMPT, is a prompt string, or nil meaning do not prompt
    specially.

Here is the function.  It looks like it is assuming that the passed
prompt is a valid string, and passing it to echo_prompt.  It should
check if the prompt is Qnil, and pass "" to echo_prompt if it is.  If
it is not Qnil, it should check if propmt is STRINGP, and if not, it
should signal an error.  This is what I will change my copy to do.
Does this sound correct?

DEFUN ("read-key-sequence", Fread_key_sequence, Sread_key_sequence, 1, 1, 0,
  "Read a [...]")
     (prompt)
     Lisp_Object prompt;
{
  Lisp_Object result = Qnil;
  Lisp_Object event = Fallocate_event ();
  int count = specpdl_ptr - specpdl;
  struct gcpro gcpro1;
  GCPRO1 (event);

  QUIT;
  echo_prompt ((char *) XSTRING (prompt)->data);

[...]
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 12 Oct 1992 18:30:47 EDT
Date: Mon, 12 Oct 1992 18:30:37 EDT
From: ex594bw@pts.mot.com (Bob Weiner)
Subject: 'event-window' should consider modeline part of window.
Reply-To: bob_weiner@pts.mot.com
Newsgroups: alt.lucid-emacs.bug
As its documentation states, it returns nil if an event occurs
on a modeline.  But if you look at the Emacs window-edges function,
it includes the modeline within a window's boundaries, so this
behavior seems inconsistent.

There are times when one wants to know the window of a modeline
clicked upon or that a modeline has been clicked upon, but 'event-window'
just returns nil in this case, which I can't see as ever being as helpful.

Hyperbole, for example, needs this functionality for some of its mouse
handling.  One could manually compute the window of the modeline clicked
upon from the event-x and event-y coordinates but since 'event-window'
exists, I think it should handle it.

Thanks,

Bob
From: jbw@bigbird.bu.edu (Joe Wells)
Newsgroups: alt.lucid-emacs.bug
Subject: Re: window manager "quit" nukes emacs
Date: 11 Oct 92 00:36:29 GMT
 <9210080205.AA19305@thalidomide.lucid>
Organization: Boston University Computer Science Department
In-reply-to: jwz@lucid.com's message of 8 Oct 92 02:05:44 GMT

In article <9210080205.AA19305@thalidomide.lucid> jwz@lucid.com (Jamie Zawinski) writes:

   If there is more than one screen, then WM_DELETE_WINDOW deletes the
   screen.  Otherwise, it exits emacs.

Surely there is a way to disable this misfeature so it can't kill your
Emacs, right?  I mean, really, Emacs should never exit at all.

-- 
Joe Wells <jbw@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details