From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 02:17:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA26267 for xemacs-beta-people; Sat, 15 Jun 1996 02:17:21 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA26264 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 02:17:19 -0500 (CDT)
Received: from darkside (gate.dimensionx.com [198.68.165.10]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA26699 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 02:17:08 -0500 (CDT)
Received: (from smap@localhost) by darkside (SMI-8.6/8.6.9) id AAA02583 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 00:14:36 -0700
Received: from server.dimensionx.com(198.68.166.10) by darkside via smap (V1.3)
	id sma002581; Sat Jun 15 00:14:32 1996
Received: from mole.dimensionx.com by dimensionx.com (SMI-8.6/SMI-SVR4)
	id AAA09894; Sat, 15 Jun 1996 00:14:47 -0700
Received: (from wing@localhost) by mole.dimensionx.com (8.7.3/8.7.3) id AAA25969 for xemacs-beta@cs.uiuc.edu; Sat, 15 Jun 1996 00:10:01 -0800
Date: Sat, 15 Jun 1996 00:10:01 -0800
From: Ben Wing <wing@dimensionx.com>
Message-Id: <199606150810.AAA25969@mole.dimensionx.com>
To: xemacs-beta@cs.uiuc.edu
Subject: buffers menu improvements

I actually started trying to use the buffers menu for the first time, and
got annoyed that the default "most-recently-used" order makes it hard to
quickly locate buffers by name.  So I decided to provide an option to do
alphabetical sorting, and ended up doing a whole lot of improvements to
the buffers menu, including providing a general framework for customizing
it.  I'd like the beta list's input on this -- e.g. improvements in the
form of different customizing functions, suggestions for the defaults, etc.
The new defaults are set currently to sort the buffers menu by major mode
and then by name, and to group the buffers by major mode with separators
between them.  If you set `buffers-menu-submenus-for-groups-p' to non-nil,
then you will instead have one submenu per major mode group, with each
submenu listing the buffers in that mode.

Enjoy ...

*** /usr/local/lib/xemacs-19.14-b24/lisp/x11/x-menubar.el	Mon May 27 14:33:49 1996
--- x-menubar.el	Sat Jun 15 00:01:51 1996
***************
*** 641,670 ****
  
  ;;; The Buffers menu
  
- ;; this version is too slow
- (defun slow-format-buffers-menu-line (buffer)
-   "Returns a string to represent the given buffer in the Buffer menu.
- nil means the buffer shouldn't be listed.  You can redefine this."
-   (if (string-match "\\` " (buffer-name buffer))
-       nil
-     (save-excursion
-      (set-buffer buffer)
-      (let ((size (buffer-size)))
-        (format "%s%s %-19s %6s %-15s %s"
- 	       (if (buffer-modified-p) "*" " ")
- 	       (if buffer-read-only "%" " ")
- 	       (buffer-name)
- 	       size
- 	       mode-name
- 	       (or (buffer-file-name) ""))))))
- 
- (defun format-buffers-menu-line (buffer)
-   "Returns a string to represent the given buffer in the Buffer menu.
- nil means the buffer shouldn't be listed.  You can redefine this."
-   (if (string-match "\\` " (setq buffer (buffer-name buffer)))
-       nil
-     buffer))
- 
  (defvar buffers-menu-max-size 20
    "*Maximum number of entries which may appear on the \"Buffers\" menu.
  If this is 10, then only the ten most-recently-selected buffers will be
--- 641,646 ----
***************
*** 676,685 ****
--- 652,763 ----
  of each buffer line.  If this is false, then there will be only one command:
  select that buffer.")
  
+ (defvar buffers-menu-submenus-for-groups-p nil
+   "*If true, the buffers menu will contain one submenu per group of buffers,
+ if a grouping function is specified in `buffers-menu-grouping-function'.")
+ 
  (defvar buffers-menu-switch-to-buffer-function 'switch-to-buffer
    "*The function to call to select a buffer from the buffers menu.
  `switch-to-buffer' is a good choice, as is `pop-to-buffer'.")
  
+ (defvar buffers-menu-omit-function 'buffers-menu-omit-invisible-buffers
+ "*If non-nil, a function specifying the buffers to omit from the buffers menu.
+ This is passed a buffer and should return non-nil if the buffer should be
+ omitted.  The default value `buffers-menu-omit-invisible-buffers' omits
+ buffers that are normally considered \"invisible\" (those whose name
+ begins with a space).")
+ 
+ (defvar buffers-menu-format-buffer-line-function 'format-buffers-menu-line
+   "*The function to call to return a string to represent a buffer in the
+ buffers menu.  The function is passed a buffer and should return a string.
+ The default value `format-buffers-menu-line' just returns the name of
+ the buffer.  Also check out `slow-format-buffers-menu-line' which
+ returns a whole bunch of info about a buffer.")
+ 
+ (defvar buffers-menu-sort-function
+   'sort-buffers-menu-by-mode-then-alphabetically
+   "*If non-nil, a function to sort the list of buffers in the buffers menu.
+ It will be passed two arguments (two buffers to compare) and should return
+ T if the first is \"less\" than the second.  One possible value is
+ `sort-buffers-menu-alphabetically'; another is
+ `sort-buffers-menu-by-mode-then-alphabetically'.")
+ 
+ (defvar buffers-menu-grouping-function
+   'group-buffers-menu-by-mode-then-alphabetically
+   "*If non-nil, a function to group buffers in the buffers menu together.
+ It will be passed two arguments, successive members of the sorted buffers
+ list after being passed through `buffers-menu-sort-function'.  It should
+ return non-nil if the second buffer begins a new group.  The return value
+ should be the name of the old group, which may be used in hierarchical
+ buffers menus.  The last invocation of the function contains nil as the
+ second argument, so that the name of the last group can be determined.
+ 
+ The sensible values of this function are dependent on the value specified
+ for `buffers-menu-sort-function'.")
+ 
+ (defun buffers-menu-omit-invisible-buffers (buf)
+   "For use as a value of `buffers-menu-omit-function'.
+ Omits normally invisible buffers (those whose name begins with a space).")
+   (not (null (string-match "\\` " (buffer-name buf)))))
+ 
+ (defun sort-buffers-menu-alphabetically (buf1 buf2)
+   "For use as a value of `buffers-menu-sort-function'.
+ Sorts the buffers in alphabetical order by name, but puts buffers beginning
+ with a star at the end of the list."
+   (let* ((nam1 (buffer-name buf1))
+ 	 (nam2 (buffer-name buf2))
+ 	 (star1p (not (null (string-match "\\`*" nam1))))
+ 	 (star2p (not (null (string-match "\\`*" nam2)))))
+     (if (not (eq star1p star2p))
+ 	(not star1p)
+       (string-lessp nam1 nam2))))
+ 
+ (defun sort-buffers-menu-by-mode-then-alphabetically (buf1 buf2)
+   "For use as a value of `buffers-menu-sort-function'.
+ Sorts first by major mode and then alphabetically by name, but puts buffers
+ beginning with a star at the end of the list."
+   (let* ((nam1 (buffer-name buf1))
+ 	 (nam2 (buffer-name buf2))
+ 	 (star1p (not (null (string-match "\\`*" nam1))))
+ 	 (star2p (not (null (string-match "\\`*" nam2))))
+ 	 (mode1 (symbol-value-in-buffer 'major-mode buf1))
+ 	 (mode2 (symbol-value-in-buffer 'major-mode buf2)))
+     (cond ((not (eq star1p star2p)) (not star1p))
+ 	  ((and star1p star2p (string-lessp nam1 nam2)))
+ 	  ((string-lessp mode1 mode2) t)
+ 	  ((string-lessp mode2 mode1) nil)
+ 	  (t (string-lessp nam1 nam2)))))
+ 
+ ;; this version is too slow on some machines.
+ (defun slow-format-buffers-menu-line (buffer)
+   "For use as a value of `buffers-menu-format-buffer-line-function'.
+ This returns a string containing a bunch of info about the buffer."
+   (format "%s%s %-19s %6s %-15s %s"
+ 	  (if (buffer-modified-p buffer) "*" " ")
+ 	  (if (symbol-value-in-buffer 'buffer-read-only buffer) "%" " ")
+ 	  (buffer-name buffer)
+ 	  (buffer-size buffer)
+ 	  (symbol-value-in-buffer 'mode-name buffer)
+ 	  (or (buffer-file-name buffer) "")))
+ 
+ (defun format-buffers-menu-line (buffer)
+   "For use as a value of `buffers-menu-format-buffer-line-function'.
+ This just returns the buffer's name."
+   (buffer-name buffer))
+ 
+ (defun group-buffers-menu-by-mode-then-alphabetically (buf1 buf2)
+   "For use as a value of `buffers-menu-grouping-function'.
+ This groups buffers by major mode.  It only really makes sense if
+ `buffers-menu-sorting-function' is
+ `sort-buffers-menu-by-mode-then-alphabetically'."
+   (cond ((string-match "\\`*" (buffer-name buf1))
+ 	 (and (null buf2) "*Misc*"))
+ 	((or (null buf2)
+ 	     (string-match "\\`*" (buffer-name buf2))
+ 	     (not (eq (symbol-value-in-buffer 'major-mode buf1)
+ 		      (symbol-value-in-buffer 'major-mode buf2))))
+ 	 (symbol-value-in-buffer 'mode-name buf1))
+ 	(t nil)))
  
  (defun buffer-menu-save-buffer (buffer)
    (save-excursion
***************
*** 696,732 ****
  (defsubst build-buffers-menu-internal (buffers)
    (let (name line)
      (mapcar
!      (if complex-buffers-menu-p
! 	 #'(lambda (buffer)
! 	     (if (setq line (format-buffers-menu-line buffer))
! 		 (delq nil
! 		   (list line
! 		       (vector "Switch to Buffer"
! 			       (list buffers-menu-switch-to-buffer-function
! 				     (setq name (buffer-name buffer)))
! 			       t)
! 		       (if (eq buffers-menu-switch-to-buffer-function
! 			       'switch-to-buffer)
! 			   (vector "Switch to Buffer, Other Frame"
! 				   (list 'switch-to-buffer-other-frame
  					 (setq name (buffer-name buffer)))
  				   t)
! 			 nil)
! 		       (if (and (buffer-modified-p buffer)
! 				(buffer-file-name buffer))
! 			   (vector "Save Buffer"
! 				   (list 'buffer-menu-save-buffer name) t)
  			     ["Save Buffer" nil nil]
! 			   )
! 		       (vector "Save As..."
! 			       (list 'buffer-menu-write-file name) t)
! 		       (vector "Delete Buffer" (list 'kill-buffer name) t)))))
!        #'(lambda (buffer)
! 	   (if (setq line (format-buffers-menu-line buffer))
! 	       (vector line
! 		       (list buffers-menu-switch-to-buffer-function
! 			     (buffer-name buffer))
! 		       t))))
       buffers)))
  
  (defun buffers-menu-filter (menu)
--- 774,812 ----
  (defsubst build-buffers-menu-internal (buffers)
    (let (name line)
      (mapcar
!      #'(lambda (buffer)
! 	 (if (eq buffer t)
! 	     "---"
! 	   (setq line (funcall buffers-menu-format-buffer-line-function
! 			       buffer))
! 	   (if complex-buffers-menu-p
! 	       (delq nil
! 		     (list line
! 			   (vector "Switch to Buffer"
! 				   (list buffers-menu-switch-to-buffer-function
  					 (setq name (buffer-name buffer)))
  				   t)
! 			   (if (eq buffers-menu-switch-to-buffer-function
! 				   'switch-to-buffer)
! 			       (vector "Switch to Buffer, Other Frame"
! 				       (list 'switch-to-buffer-other-frame
! 					     (setq name (buffer-name buffer)))
! 				       t)
! 			     nil)
! 			   (if (and (buffer-modified-p buffer)
! 				    (buffer-file-name buffer))
! 			       (vector "Save Buffer"
! 				       (list 'buffer-menu-save-buffer name) t)
  			     ["Save Buffer" nil nil]
! 			     )
! 			   (vector "Save As..."
! 				   (list 'buffer-menu-write-file name) t)
! 			   (vector "Delete Buffer" (list 'kill-buffer name)
! 				   t)))
! 	     (vector line
! 		     (list buffers-menu-switch-to-buffer-function
! 			   (buffer-name buffer))
! 		     t))))
       buffers)))
  
  (defun buffers-menu-filter (menu)
***************
*** 736,750 ****
  efficiency reasons.  You can control how many buffers will be shown by
  setting `buffers-menu-max-size'.  You can control the text of the menu
  items by redefining the function `format-buffers-menu-line'."
!   (let ((buffers (buffer-list)))
      (and (integerp buffers-menu-max-size)
  	 (> buffers-menu-max-size 1)
  	 (> (length buffers) buffers-menu-max-size)
  	 ;; shorten list of buffers
  	 (setcdr (nthcdr buffers-menu-max-size buffers) nil))
!       (setq buffers (delq nil (build-buffers-menu-internal buffers)))
!       (append menu buffers)
!       ))
  
  
  
--- 816,868 ----
  efficiency reasons.  You can control how many buffers will be shown by
  setting `buffers-menu-max-size'.  You can control the text of the menu
  items by redefining the function `format-buffers-menu-line'."
!   (let ((buffers (delete-if buffers-menu-omit-function (buffer-list))))
      (and (integerp buffers-menu-max-size)
  	 (> buffers-menu-max-size 1)
  	 (> (length buffers) buffers-menu-max-size)
  	 ;; shorten list of buffers
  	 (setcdr (nthcdr buffers-menu-max-size buffers) nil))
!     (if buffers-menu-sort-function
! 	(setq buffers (sort buffers buffers-menu-sort-function)))
!     (if (and buffers-menu-grouping-function
! 	     buffers-menu-submenus-for-groups-p)
! 	(let (groups groupnames current-group)
! 	  (mapl
! 	   #'(lambda (sublist)
! 	       (let ((groupname (funcall buffers-menu-grouping-function
! 					 (car sublist) (cadr sublist))))
! 		 (setq current-group (cons (car sublist) current-group))
! 		 (if groupname
! 		     (progn
! 		       (setq groups (cons (nreverse current-group)
! 					  groups))
! 		       (setq groupnames (cons groupname groupnames))
! 		       (setq current-group nil)))))
! 	   buffers)
! 	  (setq buffers
! 		(mapcar*
! 		 #'(lambda (groupname group)
! 		     (cons groupname (build-buffers-menu-internal group)))
! 		 (nreverse groupnames)
! 		 (nreverse groups))))
!       (if buffers-menu-grouping-function
! 	  (progn
! 	    (setq buffers
! 		  (mapcon
! 		   #'(lambda (sublist)
! 		       (cond ((funcall buffers-menu-grouping-function
! 				       (car sublist) (cadr sublist))
! 			      (list (car sublist) t))
! 			     (t (list (car sublist)))))
! 		   buffers))
! 	    ;; remove a trailing separator.
! 	    (and (>= (length buffers) 2)
! 		 (let ((lastcdr (nthcdr (- (length buffers) 2) buffers)))
! 		   (if (eq t (cadr lastcdr))
! 		       (setcdr lastcdr nil))))))
!       (setq buffers (build-buffers-menu-internal buffers)))
!     (append menu buffers)
!     ))
  
  
  

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 03:07:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26707 for xemacs-beta-people; Sat, 15 Jun 1996 03:07:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26703 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 03:07:29 -0500 (CDT)
Received: from lipp.aa.net (lipp@lipp.aa.net [204.157.220.241]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA29997 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 03:07:25 -0500 (CDT)
Received: (from lipp@localhost) by lipp.aa.net (8.6.11/8.6.9) id BAA00170; Sat, 15 Jun 1996 01:04:36 -0700
Date: Sat, 15 Jun 1996 01:04:36 -0700
Message-Id: <199606150804.BAA00170@lipp.aa.net>
From: Damon Lipparelli <lipp@aa.net>
To: wmperry@spry.com
Cc: Chuck Thompson <cthomp@cs.uiuc.edu>, xemacs-beta@xemacs.org
Subject: Re: another beta delay
In-Reply-To: <199606141625.JAA07241@monolith.spry.com>
References: <199606141540.KAA20000@charles.cs.uiuc.edu>
	<199606141625.JAA07241@monolith.spry.com>
Reply-To: Damon Lipparelli <lipp@aa.net>
X-Mailer: VM 5.95 (beta) [ XEmacs 19.14 (beta24) ]

>>>>> William Perry <wmperry@monolith.spry.com> writes:

    > Chuck Thompson writes:
    >> beta25 will come out Sunday, June 16.  Unfortunately, my allergies
    >> have been limiting my productive work time.  Rumors that I've been
    >> in a funk due to the final score of game 4 of the NBA finals are
    >> completely unfounded.

    >  Checked into betty ford yet?  I hear they have lots of bulls fans
    > since wednesday.

    >> On the good side, I'm taking Monday and Tuesday off from my
    >> regularly scheduled job to make sure 19.14 is ready to go.

    >   You'll need it to recover from the losses this weekend. :)

    > -Bill P.

    > PS: Just yanking your chain - I say 70-30 chance the series ends
    > tonight.

Ye of little faith....  I say 80-20 chance the series goes to seven games.

-lipp


---

PIZZA!!

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 09:00:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA00722 for xemacs-beta-people; Sat, 15 Jun 1996 09:00:31 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA00719 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 09:00:30 -0500 (CDT)
Received: from eik (eik.ii.uib.no [129.177.16.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA00220 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 09:00:28 -0500 (CDT)
Received: from trost.ii.uib.no (trost) by eik with SMTP id AA13437
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Sat, 15 Jun 1996 16:00:26 +0200
Received: by trost.ii.uib.no; (5.65/1.1.8.2/08Jun94-0756AM)
	id AA12987; Fri, 14 Jun 1996 16:01:11 +0200
Sender: ketil@ii.uib.no
To: xemacs-beta@xemacs.org
Subject: ^G granularity?
From: Ketil Z Malde <ketil@ii.uib.no>
Date: 14 Jun 1996 16:01:08 +0200
Message-Id: <KETIL-egwx1a32or.fsf@trost.ii.uib.no>
Lines: 14
X-Mailer: Gnus v5.2.1/XEmacs 19.14


One thing I really hate is that C-g (keyboard interrupt) is nearly
useless.  All it seems to do, is wait for XEmacs to finish everything,
and then ring the bell.  Really!  If and when I use C-g, it is to STOP
XEmacs from doing what it's doing -- what's the point if it ignores me
until it's finished?

And occasionally, the refilling of a message in Gnus would hang -- C-g
should stop it, IMHO, but I have to send an INT to the process.

Chances of doing anything about this?

~kzm


From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 09:29:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA00748 for xemacs-beta-people; Sat, 15 Jun 1996 09:29:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA00745 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 09:29:31 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA00275 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 09:29:29 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA22946; Sat, 15 Jun 1996 09:29:25 -0500 (CDT)
Message-Id: <199606151429.JAA22946@charles.cs.uiuc.edu>
To: Bill Dubuque <wgd@martigny.ai.mit.edu>
cc: wing@666.com, jhod@po.iijnet.or.jp, xemacs-beta@xemacs.org
Subject: Re: defstruct, reusability, etc [was: Mule, etc...] 
In-reply-to: Your message of "Fri, 14 Jun 1996 13:08:55 EDT."
             <199606141709.MAA29579@xemacs.cs.uiuc.edu> 
Date: Sat, 15 Jun 1996 09:29:24 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Bill> Surely it would be cleaner to pass a structure rather than
    Bill> 17 args!  Doesn't the latest CL.EL provide a decent
    Bill> DEFSTRUCT implementation?

That won't help you with C side functions.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 09:44:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA00801 for xemacs-beta-people; Sat, 15 Jun 1996 09:44:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA00798 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 09:44:27 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA01582 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 09:44:24 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA12395; Sat, 15 Jun 1996 08:44:02 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA26318; Sat, 15 Jun 1996 08:44:00 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA03948; Sat, 15 Jun 1996 08:43:45 -0600
Date: Sat, 15 Jun 1996 08:43:45 -0600
Message-Id: <199606151443.IAA03948@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: ketil@ii.uib.no
Cc: xemacs-beta@xemacs.org
Subject: Re: ^G granularity?
In-Reply-To: <KETIL-egwx1a32or.fsf@trost.ii.uib.no>
References: <KETIL-egwx1a32or.fsf@trost.ii.uib.no>
Reply-To: turner@lanl.gov

Ketil Z. Malde writes:
 > 
 > One thing I really hate is that C-g (keyboard interrupt) is nearly
 > useless.  All it seems to do, is wait for XEmacs to finish everything,
 > and then ring the bell.  Really!  If and when I use C-g, it is to STOP
 > XEmacs from doing what it's doing -- what's the point if it ignores me
 > until it's finished?
 > 
 > And occasionally, the refilling of a message in Gnus would hang -- C-g
 > should stop it, IMHO, but I have to send an INT to the process.
 > 
 > Chances of doing anything about this?

C-g seems to have lots of problems, and I can tell you that it's a real 
source of frustration for new users.  I usually just tell them "do C-g
a bunch of times then see if that gets you out of whatever was going
on"...

-John

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 10:22:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA00888 for xemacs-beta-people; Sat, 15 Jun 1996 10:22:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA00885 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 10:22:41 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA09745 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 10:22:40 -0500 (CDT)
Received: from marvin.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA19719; Sat, 15 Jun 1996 17:22:36 +0200
Received: from localhost by marvin.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA10717; Sat, 15 Jun 1996 17:22:35 +0200
Message-Id: <9606151522.AA10717@marvin.informatik.uni-tuebingen.de>
To: xemacs-beta@cs.uiuc.edu
Subject: Several configure arguments to --site-libaries etc.?
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
Date: Sat, 15 Jun 1996 17:22:34 +0200
From: "Michael Sperber [Mr. Preprocessor]" <sperber@informatik.uni-tuebingen.de>


Is it possible?  I have x-faces, jpeg, xpm etc. all in different
places.  I've tried space-separated, comma-separated, several
--site-libraries, all to no avail.

Cheers =8-} Mike


From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 10:25:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA00900 for xemacs-beta-people; Sat, 15 Jun 1996 10:25:26 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA00897 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 10:25:24 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA09764 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 10:25:26 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA23081; Sat, 15 Jun 1996 10:25:07 -0500 (CDT)
Message-Id: <199606151525.KAA23081@charles.cs.uiuc.edu>
To: "Michael Sperber [Mr. Preprocessor]" <sperber@informatik.uni-tuebingen.de>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Several configure arguments to --site-libaries etc.? 
In-reply-to: Your message of "Sat, 15 Jun 1996 17:22:34 +0200."
             <9606151522.AA10717@marvin.informatik.uni-tuebingen.de> 
Date: Sat, 15 Jun 1996 10:25:06 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Michael> Is it possible?  I have x-faces, jpeg, xpm etc. all in
    Michael> different places.  I've tried space-separated,
    Michael> comma-separated, several --site-libraries, all to no
    Michael> avail.


--site-libraries='/path/one /path/two /path/etc'



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 11:10:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA01029 for xemacs-beta-people; Sat, 15 Jun 1996 11:10:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA01026 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 11:10:41 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA11721 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 11:10:36 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA21857; Sat, 15 Jun 1996 18:09:19 +0200
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA18656; Sat, 15 Jun 1996 18:09:17 +0200
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@cs.uiuc.edu
Cc: dkeller@VNET.IBM.COM
Subject: AIX 4.1.4 fix
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 15 Jun 1996 18:09:13 +0200
Message-Id: <y9lhgsdaw2e.fsf@modas.informatik.uni-tuebingen.de>
Lines: 42
X-Mailer: Gnus v5.2.12/XEmacs 19.14


Boy-oh-boy,

all it takes it to take out the AIX-4-#ifdefs from ibmrs6000.h.  I
thought they couldn't possibly be brain damage---they are.

Cheers =8-} Mike

PS:  So, I guess, I have a successful build on AIX 4.1.4 ...

*** src/m/ibmrs6000.h~	Fri Jun  7 02:18:18 1996
--- src/m/ibmrs6000.h	Sat Jun 15 17:27:35 1996
***************
*** 148,172 ****
     random input files.  */
  /* Avoid gcc 2.7.x collect2 bug by using /bin/ld instead.  */
  #if __GNUC__ == 2 && __GNUC_MINOR__ == 7
- #ifdef AIX4
- #define LD_SWITCH_MACHINE -B/bin/ -Wl,-bnodelcsect
- #else /* not AIX4 */
  #ifdef AIX_SMT_EXP
  #define LD_SWITCH_MACHINE -B/bin/ -Wl,-bnso,-bnodelcsect,-bI:/lib/syscalls.exp,-bI:$(srcdir)/m/ibmrs6000.inp,AIX_SMT_EXP
  #else
  #define LD_SWITCH_MACHINE -B/bin/ -Wl,-bnso,-bnodelcsect,-bI:/lib/syscalls.exp,-bI:$(srcdir)/m/ibmrs6000.inp
  #endif
- #endif /* not AIX4 */
  #else /* not gcc 2.7.x */
- #ifdef AIX4
- #define LD_SWITCH_MACHINE -Wl,-bnodelcsect
- #else /* not AIX4 */
  #ifdef AIX_SMT_EXP
  #define LD_SWITCH_MACHINE -Wl,-bnso,-bnodelcsect,-bI:/lib/syscalls.exp,-bI:$(srcdir)/m/ibmrs6000.inp,AIX_SMT_EXP
  #else
  #define LD_SWITCH_MACHINE -Wl,-bnso,-bnodelcsect,-bI:/lib/syscalls.exp,-bI:$(srcdir)/m/ibmrs6000.inp
  #endif
- #endif /* not AIX4 */
  #endif /* __GNUC__ == 2 && __GNUC_MINOR__ == 7 */
  
  #endif /* USG5_4 */
--- 148,164 ----



From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 12:07:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA01125 for xemacs-beta-people; Sat, 15 Jun 1996 12:07:51 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA01122 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 12:07:49 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA09511 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 12:07:45 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA23222; Sat, 15 Jun 1996 12:04:01 -0500 (CDT)
Message-Id: <199606151704.MAA23222@charles.cs.uiuc.edu>
To: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>
cc: "Jareth \"JHod\" Hein" <jhod@po.iijnet.or.jp>,
        XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: More Mule-ing 
In-reply-to: Your message of "Thu, 13 Jun 1996 11:41:48 CDT."
             <199606131641.LAA00838@nvwls.cc.purdue.edu> 
Date: Sat, 15 Jun 1996 12:04:00 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Joseph> On a side note, is XEmacs going to be the successor to
    Joseph> MULE?

Not officially.



		-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 14:35:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA01565 for xemacs-beta-people; Sat, 15 Jun 1996 14:35:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA01562 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 14:35:40 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14472 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 14:35:38 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id NAA17697; Sat, 15 Jun 1996 13:35:38 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id NAA27104; Sat, 15 Jun 1996 13:35:36 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id NAA04222; Sat, 15 Jun 1996 13:35:20 -0600
Date: Sat, 15 Jun 1996 13:35:20 -0600
Message-Id: <199606151935.NAA04222@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: 19.14b24: More on Gnus 5.2
Reply-To: turner@lanl.gov

19.14b24, Solaris 2.5, CDE 1.0.1, SunPro C 4.0
Motif dialogs, Lucid scrollbars & menus

---

At home I generally just use tip over a modem and crank up xemacs on a
tty (no need for PPP for what I usually do from home).

Anyway, I had been loading delbackspace, but ran into a conflict with
Gnus 5.2 in that after loading delbackspace, neither BS nor DEL would
work correctly.  I'd get this backtrace:

Signalling: (buffer-read-only #<buffer "*Summary *Summary comp.emacs.xemacs*">)
  call-interactively(backward-delete-char-untabify)

When I ran without loading delbackspace, no problem.

Anyway, it's not really a big deal, since not loading delbackspace
somehow fixed some XON/XOFF flow control problems I was having; now
C-s works again.  So I'll probably just stop using delbackspace.  But
thought I'd mention this anyway.

As an aside, I'd like some advice on migrating from adaptive scoring
to more manual control.  Actually, this might be a good entry for the
Gnus FAQ, since I imagine many people might do what I did.  That is,
turn on adaptive scoring just to see how it did and get a feel for the
whole idea of scoring, then decide they want more control.

Thanks in advance.

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 19:26:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA02237 for xemacs-beta-people; Sat, 15 Jun 1996 19:26:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA02234 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 19:26:39 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA17492 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 19:26:41 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id RAA03841; Sat, 15 Jun 1996 17:25:51 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b24: More on Gnus 5.2
References: <199606151935.NAA04222@gielgud.lanl.gov.xdiv>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: John Turner's message of 15 Jun 1996 12:35:20 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 15 Jun 1996 17:25:49 -0700
Message-ID: <m2enng61de.fsf@deanna.miranova.com>
Lines: 17
X-Mailer: Gnus v5.2.19/XEmacs 20.0

>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:

John> As an aside, I'd like some advice on migrating from adaptive
John> scoring to more manual control.  Actually, this might be a good
John> entry for the Gnus FAQ, since I imagine many people might do
John> what I did.  That is, turn on adaptive scoring just to see how
John> it did and get a feel for the whole idea of scoring, then decide
John> they want more control.

The longest question in the FAQ is devoted to (manual) score file
suggestions.  What else would you like to see?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 19:54:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA02307 for xemacs-beta-people; Sat, 15 Jun 1996 19:54:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA02304 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 19:54:15 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA17699 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 19:54:14 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA11473; Sat, 15 Jun 1996 17:52:48 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA28845; Sat, 15 Jun 1996 17:52:47 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA06741; Sat, 15 Jun 1996 17:52:46 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA13031; Sat, 15 Jun 1996 17:52:37 -0700
Date: Sat, 15 Jun 1996 17:52:37 -0700
Message-Id: <199606160052.RAA13031@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Ben Wing <wing@666.com>
Cc: andyp@parallax.co.uk (Andy Piper),
        XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: Re: arggh - b24 keypad keys no longer work
In-Reply-To: <199606140533.FAA01470@nene.boundless.com>
References: <199606130735.IAA03933@wrath.parallax.co.uk>
	<199606130808.BAA02841@xemacs.eng.sun.com>
	<199606140533.FAA01470@nene.boundless.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

Ben> Martin Buchholz writes:
>> Well, in fact b25 won't change that. kp_1 through kp_9 seems to be the
>> defactoest standard in the industry, so I thought the Sun keyboard
>> should try to be as similar to the other keyboards around.  As to what
>> kp_1 through kp_9 are bound to, I don't think they should be numbers
>> (self-insert) by default, but I've been shouted down about this.  I do
>> feel strongly that the keypad keys should be mapped to different
>> keysyms than the other similar keys, for ease of users' rebinding.
>> Having two home keys seems sort of useless to me.  A keyboard is a
>> terrible thing to waste.  I'm still rooting for a user's
>> 
>> (global-set-key 'kp_7 'beginning-of-buffer)
>> 
>> to work on many X servers and keyboards (and for that binding to be
>> the default for XEmacs).
>> 
>> This really is one area where you can't please anybody (not even myself).

Ben> I haven't figured out the difference between the various Sun
Ben> keyboards, but if there exist *any* configurations that are at all
Ben> likely to be out there for which there are no keypad-ish keys
Ben> that do PgUp/PgDn, then this absolutely must be changed.

OK.  I give in.  I've rewritten x-win-wun.el yet again, and added a
function x-keysym-on-keyboard-p to help with the rebinding.  I checked
Solaris on intel and powerpc (where there are real 101-pc keyboards)
and the keypad key keysysms are home etc., if numlock is off, kp_7
etc., if numlock is on.  b25 will have f27->home on Type 4 keyboards,
f27->kp_home (with the same default binding as home) on Type 5
f27->keyboards.

Naive users who press a key labelled home will always get beginning-of-line.

If anyone tries to write a key rebinding package for other OS'es that
support different keyboards, x-keysym-on-keyboard-p will likely be
useful.  It seems to be the best keyboard-guessing tool that is also portable.

Martin

Ben> (Isn't this what type 4 keyboards do?  I think it's unacceptable if
Ben> someone with a type 4 keyboard can't do PgUp/PgDn in any other way
Ben> than C-v and M-v.  One of the nicest things about XEmacs over FSF
Ben> Emacs [and Lucid Emacs 19.9 and earlier!] is that it comes by default
Ben> with the keypad keys doing the things they're supposed to do, even
Ben> on Suns.  It's a really bad thing if you change this.)

Ben> For type 5 keyboards (those are the ones with their own set of
Ben> non-numeric-keypad keys for PgUp/PgDn, right?), it's fine for
Ben> the numeric keypad to do numbers, but if that screws the type 4
Ben> keyboard users in the process, then it should be changed.


From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 20:04:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA02358 for xemacs-beta-people; Sat, 15 Jun 1996 20:04:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA02355 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 20:04:24 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA20360 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 20:04:25 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id SAA11985; Sat, 15 Jun 1996 18:03:52 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id SAA28958; Sat, 15 Jun 1996 18:03:51 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA06815; Sat, 15 Jun 1996 18:03:50 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA13045; Sat, 15 Jun 1996 18:03:42 -0700
Date: Sat, 15 Jun 1996 18:03:42 -0700
Message-Id: <199606160103.SAA13045@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Kyle Jones <kyle_jones@wonderworks.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Toolbar thought grenade
In-Reply-To: <NAAatyi23307.199606131701@crystal.WonderWorks.COM>
References: <199606131430.JAA00625@nvwls.cc.purdue.edu>
	<NAAatyi23307.199606131701@crystal.WonderWorks.COM>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Kyle" == Kyle Jones <kyle_jones@wonderworks.com> writes:

Kyle> Joseph J. Nuspl, Jr. writes:
>> 
>> How about associating a keymap with a toolbar button, then you could
>> assign different functions to different types of button clicks on it,
>> i.e. left click on [Open file] does what it normally does, right click
>> opens the file in a new frame.

Kyle> KABOOM.  Sounds like a great idea to me.

I was maybe expecting the right mouse button on a toolbar button to
bring up a relevant popup menu.  This is consistent with the rest of
XEmacs.

Martin

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 20:47:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA02417 for xemacs-beta-people; Sat, 15 Jun 1996 20:47:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA02414 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 20:47:29 -0500 (CDT)
Received: from netcom2.netcom.com (root@netcom2.netcom.com [192.100.81.108]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA23229 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 20:47:32 -0500 (CDT)
Received: from netcom20.netcom.com (wing@netcom20.netcom.com [192.100.81.133]) by netcom2.netcom.com (8.6.13/Netcom)
	id SAA22267; Sat, 15 Jun 1996 18:47:22 -0700
Date: Sat, 15 Jun 1996 18:47:22 -0700
Message-Id: <199606160147.SAA22267@netcom2.netcom.com>
From: wing@666.com (Ben Wing)
To: sperber@informatik.uni-tuebingen.de, xemacs-beta@cs.uiuc.edu
Subject: Re:  Several configure arguments to --site-libaries etc.?
Cc: steve@miranova.com

This should probably go in the FAQ.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 20:47:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA02410 for xemacs-beta-people; Sat, 15 Jun 1996 20:47:06 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA02407 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 20:47:05 -0500 (CDT)
Received: from netcom2.netcom.com (root@netcom2.netcom.com [192.100.81.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA21557 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 20:47:03 -0500 (CDT)
Received: from netcom20.netcom.com (wing@netcom20.netcom.com [192.100.81.133]) by netcom2.netcom.com (8.6.13/Netcom)
	id SAA22246; Sat, 15 Jun 1996 18:47:04 -0700
Date: Sat, 15 Jun 1996 18:47:04 -0700
Message-Id: <199606160147.SAA22246@netcom2.netcom.com>
From: wing@666.com (Ben Wing)
To: ketil@ii.uib.no, xemacs-beta@xemacs.org
Subject: Re:  ^G granularity?

C-g does work for most people in most circumstances.  If it doesn't,
there are only two explanations:

1) the code is wrapped with a binding of `inhibit-quit' to t.
   Ctrl-Shift-G should still work, I think.

2) SIGIO is broken on your system, but BROKEN_SIGIO isn't defined.

To test #2, try executing

(while t)

from the *scratch* buffer.  If C-g doesn't interrupt, then you're
seeing #2.

ben

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 21:09:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA02491 for xemacs-beta-people; Sat, 15 Jun 1996 21:09:48 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA02488 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 21:09:47 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA23400 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 21:09:49 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id TAA14837; Sat, 15 Jun 1996 19:08:44 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id TAA29810; Sat, 15 Jun 1996 19:08:43 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA07154; Sat, 15 Jun 1996 19:08:42 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id TAA13207; Sat, 15 Jun 1996 19:08:33 -0700
Date: Sat, 15 Jun 1996 19:08:33 -0700
Message-Id: <199606160208.TAA13207@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Ben Wing <wing@666.com>
Cc: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>, xemacs-beta@cs.uiuc.edu
Subject: Re: bring back the old GNUS toolbar! 
In-Reply-To: <199606140520.FAA01313@nene.boundless.com>
References: <199606130751.IAA03953@wrath.parallax.co.uk>
	<199606131459.JAA00657@nvwls.cc.purdue.edu>
	<199606140520.FAA01313@nene.boundless.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

Ben> It has occurred to me a number of times that we ought to junk
Ben> all of the XPM stuff and move to the GIF format.  This is not so
Ben> much a space issue as one of reliability -- XPM is notoriously
Ben> unreliable and incompatible from one version to another, and is
Ben> also not that standard, requiring typically that you download
Ben> and install XPM yourself, which is a bit of a pain since the
Ben> configure/build process of XPM is not really streamlined.
Ben> What a nightmare!

The obvious question is why we don't supply XPM with XEmacs the way we
do GIF?  

Ben> The advantage of using the GIF format is that it's completely
Ben> standard

Isn't GIF under a bit of a legal cloud due to the patent issues?

Ben> and we provide all of the GIF decoding code ourselves, so things will
Ben> work reasonably even if the naive (or lazy) person trying to build
Ben> XEmacs doesn't bother to obtain various add-on libraries.

Martin

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 21:18:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA02505 for xemacs-beta-people; Sat, 15 Jun 1996 21:18:36 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA02502 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 21:18:35 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA21564 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 21:18:33 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id TAA15222; Sat, 15 Jun 1996 19:18:06 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id TAA29909; Sat, 15 Jun 1996 19:18:04 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA07230; Sat, 15 Jun 1996 19:18:03 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id TAA13220; Sat, 15 Jun 1996 19:17:54 -0700
Date: Sat, 15 Jun 1996 19:17:54 -0700
Message-Id: <199606160217.TAA13220@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: MORIOKA Tomohiko <morioka@jaist.ac.jp>
Cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: More Mule-ing 
In-Reply-To: <199606141248.VAA11840@mikan.jaist.ac.jp>
References: <199606140446.EAA00832@nene.boundless.com>
	<199606141248.VAA11840@mikan.jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "MT" == MORIOKA Tomohiko <ISO-2022-JP> writes:

MT>   By the way, some mule features were cut off. Especially I want to
MT> use program-coding-system.

What is program-coding-system supposed to do?  XEmacs has:
process-input-coding-system
process-output-coding-system

I successfully use these to see EUC-encoded command output in shell buffers.

MT>   In addition, function name of
MT> `{encode|decode}-coding-{region|string}' seems strange. (And it does
MT> not work yet)

I have successfully used these functions to Japanize a GNUS article:
      
(defun decode-current-buffer (coding-system)
  (let ((read-only buffer-read-only))
   (if read-only (toggle-read-only))
    (decode-coding-region (point-min) (point-max) coding-system)
    (if read-only (toggle-read-only))))
 
                   
(defun decode-buffer-iso-2022 ()
  (interactive)
  (decode-current-buffer 'iso-2022-jp))
 
(defun gnus-article-decode-iso2022 ()
  (save-excursion
    (set-buffer gnus-article-buffer)
    (goto-char (point-min))
    (while (search-forward "\e" nil t)
      (backward-char)
      (decode-coding-region (point) (point-end-of-line) 'iso-2022-jp))))
 
(add-hook 'gnus-article-prepare-hook 'gnus-article-decode-iso2022)

Martin

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 21:19:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA02516 for xemacs-beta-people; Sat, 15 Jun 1996 21:19:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA02513 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 21:19:23 -0500 (CDT)
Received: from nene.boundless.com (wing.vip.best.com [204.156.158.108]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA23487 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 21:19:25 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id TAA03517; Sat, 15 Jun 1996 19:17:52 GMT
Date: Sat, 15 Jun 1996 19:17:52 GMT
Message-Id: <199606151917.TAA03517@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>, xemacs-beta@cs.uiuc.edu
Subject: Re: bring back the old GNUS toolbar! 
In-Reply-To: <199606160208.TAA13207@xemacs.eng.sun.com>
References: <199606130751.IAA03953@wrath.parallax.co.uk>
	<199606131459.JAA00657@nvwls.cc.purdue.edu>
	<199606140520.FAA01313@nene.boundless.com>
	<199606160208.TAA13207@xemacs.eng.sun.com>

Martin Buchholz writes:
 > >>>>> "Ben" == Ben Wing <wing@666.com> writes:
 > 
 > Ben> It has occurred to me a number of times that we ought to junk
 > Ben> all of the XPM stuff and move to the GIF format.  This is not so
 > Ben> much a space issue as one of reliability -- XPM is notoriously
 > Ben> unreliable and incompatible from one version to another, and is
 > Ben> also not that standard, requiring typically that you download
 > Ben> and install XPM yourself, which is a bit of a pain since the
 > Ben> configure/build process of XPM is not really streamlined.
 > Ben> What a nightmare!
 > 
 > The obvious question is why we don't supply XPM with XEmacs the way we
 > do GIF?  

The GIF decoding files were rather small and unmaintained, while XPM
is larger and maintained.  Chuck has been always hesitant to make
changes to standard packages, esp. non-Emacs-specific, and include
them with XEmacs.

 > Ben> The advantage of using the GIF format is that it's completely
 > Ben> standard
 > 
 > Isn't GIF under a bit of a legal cloud due to the patent issues?

I don't think there's any problem with decoding GIFs, only encoding
them.  This is the same as with `compress' -- gzip decompresses
files compressed with `compress'.

ben

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 21:22:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA02523 for xemacs-beta-people; Sat, 15 Jun 1996 21:22:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA02520 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 21:22:07 -0500 (CDT)
Received: from nene.boundless.com (wing.vip.best.com [204.156.158.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA21567 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 21:22:04 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id TAA03531; Sat, 15 Jun 1996 19:20:37 GMT
Date: Sat, 15 Jun 1996 19:20:37 GMT
Message-Id: <199606151920.TAA03531@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: 19.14b24: More on Gnus 5.2
In-Reply-To: <199606151935.NAA04222@gielgud.lanl.gov.xdiv>
References: <199606151935.NAA04222@gielgud.lanl.gov.xdiv>

John Turner writes:
 > 19.14b24, Solaris 2.5, CDE 1.0.1, SunPro C 4.0
 > Motif dialogs, Lucid scrollbars & menus
 > 
 > ---
 > 
 > At home I generally just use tip over a modem and crank up xemacs on a
 > tty (no need for PPP for what I usually do from home).
 > 
 > Anyway, I had been loading delbackspace, but ran into a conflict with
 > Gnus 5.2 in that after loading delbackspace, neither BS nor DEL would
 > work correctly.  I'd get this backtrace:
 > 
 > Signalling: (buffer-read-only #<buffer "*Summary *Summary comp.emacs.xemacs*">)
 >   call-interactively(backward-delete-char-untabify)
 > 
 > When I ran without loading delbackspace, no problem.

I just fixed this.  delbackspace needs to know about modes that
legitimately bind delete, and it didn't know about the GNUS modes.
(Yes, this is a hack, but there's no way around it.  Most modes
evilly bind delete to `backward-delete-char-untabify' or something
like that, and need to be overridden.)

 > Anyway, it's not really a big deal, since not loading delbackspace
 > somehow fixed some XON/XOFF flow control problems I was having; now
 > C-s works again.  So I'll probably just stop using delbackspace.  But
 > thought I'd mention this anyway.

Is this reproducible?  If so, it needs to go on the BUGS list.

ben

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 21:35:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA02543 for xemacs-beta-people; Sat, 15 Jun 1996 21:35:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA02540 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 21:35:43 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA21571 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 21:35:41 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id TAA15917; Sat, 15 Jun 1996 19:35:14 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id TAA00046; Sat, 15 Jun 1996 19:35:12 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA07303; Sat, 15 Jun 1996 19:35:11 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id TAA13243; Sat, 15 Jun 1996 19:35:03 -0700
Date: Sat, 15 Jun 1996 19:35:03 -0700
Message-Id: <199606160235.TAA13243@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: 19.14 Solaris 2.x binary in pkgadd format?
In-Reply-To: <199606141638.KAA02892@gielgud.lanl.gov.xdiv>
References: <199606141638.KAA02892@gielgud.lanl.gov.xdiv>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:

John> Would also be good to make sure it gets to major sites that distribute
John> Solaris 2.x executables in pkgadd format, like:

John> http://smc.vnet.net/solaris_2.5.html

John> I just took a look, and although lots of stuff other than the typical
John> GNU stuff is there (like xv, xanim, TeX, etc.), XEmacs is not.

I currently build packages for 20.0 in pkgadd format, so I have the
technology... I ought to create packages for 19.14 when it comes out.

John> I know 19.13 made it onto the Wintertime CD (in pkgadd format).  Will
John> 19.14 be out in time to make it onto the Summertime CD?  (see:

John> http://www.alli.fi/~ben/wintertime.html

John> if you don't know what I'm talking about.)

John> Sorry I can't volunteer to do this, since I don't know anything about
John> how to create pkgs.  I just know that I like to find stuff pkgd this
John> way, and I know others do as well.

Martin

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 22:44:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA02681 for xemacs-beta-people; Sat, 15 Jun 1996 22:44:35 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA02678 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 22:44:34 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA24211 for <xemacs-beta@cs.uiuc.edu>; Sat, 15 Jun 1996 22:44:37 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA23982; Sat, 15 Jun 1996 22:40:55 -0500 (CDT)
Message-Id: <199606160340.WAA23982@charles.cs.uiuc.edu>
To: Robert Lipe <robertl@arnet.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: How do 19.14 and 19.20 sources track? 
In-reply-to: Your message of "Wed, 12 Jun 1996 17:05:46 CDT."
             <9606121705.aa10457@caddy.arnet.com> 
Date: Sat, 15 Jun 1996 22:40:54 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Robert> 	Most of the development is happening in 20.0, right?

Ben and Martin primarily work in 20.0 workspaces.  I do most of my
development work in a 19.14 workspace.


    Robert> 	Most of the patches to 20.0 are getting smooshed into
    Robert> 		19.14, right?

Almost every change which is not Mule specific goes into both
versions.  There are some additional changes which are not directly
Mule related but are necessary to make the support work and introduce
incompatibilities which are only in 20.0.


    Robert> 	The difference is in the bytecode and internationalization
    Robert> 		stuff, right?

Those are the major differences between 19.14 and 20.0.  There are a
few othrs.  There will be more.


    Robert> 	Are the 19.14 and 19.20 distributions really substantially
    Robert> 		the same source tree?

They are completely separate source trees, but I closely track the
differences between them.


    Robert> 	Should we, the commoners, budget time to build and
    Robert> 		test both versions?

If you have time, sure, but I don't expect anyone to build and use
more than one version.


    Robert> 	When submitting patches to the list, are we expected to 
    Robert> 		provide them against both trees?

No, I can handle applying patches which were generated against one
version to both versions.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 23:46:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA02781 for xemacs-beta-people; Sat, 15 Jun 1996 23:46:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA02778 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 23:46:42 -0500 (CDT)
Received: from nene.boundless.com (wing.vip.best.com [204.156.158.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA22223 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 23:46:38 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id VAA04292; Sat, 15 Jun 1996 21:45:13 GMT
Date: Sat, 15 Jun 1996 21:45:13 GMT
Message-Id: <199606152145.VAA04292@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: Bill Dubuque <wgd@martigny.ai.mit.edu>
Cc: jhod@po.iijnet.or.jp, xemacs-beta@xemacs.org
Subject: defstruct, reusability, etc [was: Mule, etc...]
In-Reply-To: <199606141708.KAA06961@infinity.c2.org>
References: <199606140411.EAA00510@nene.boundless.com>
	<199606141708.KAA06961@infinity.c2.org>

Bill Dubuque writes:
 >   Date: Fri, 14 Jun 1996 04:11:59 GMT
 >   From: Ben Wing <wing@666.com>
 > 
 >    > working on getting WNN functional. Question: is there something
 >    > inherently bad about having SUBR_MAX_ARGS greater than 8? I bumped it up
 >    > to 17 (!) and made the requisite changes in lisp.h and eval.c but as
 >    > this is my first real dive into the internals, am not sure if this will
 >    > cause problems. The reason I want 17 arg lisp functions is simply to be
 >    > able to set all the relevant WNN server values in one call. It can
 >    > certainly be broken up, but then you run into the possibility of only
 >    > getting things partially setup, etc. Comments, anyone?
 > 
 > Surely it would be cleaner to pass a structure rather than 17 args!
 > Doesn't the latest CL.EL provide a decent DEFSTRUCT implementation?
 > 
 > Its a shame that much elisp code reinvents the wheel for fear
 > of autoloading a few more bytes. In the long run this probably
 > adds to the image size since many packages could share def's
 > (say in CL) rather than duplicating them (not to mention the
 > increase of code complexity due to lack of abstraction). But 
 > reusability seems to be a foreign word to some elisp developers.

XEmacs 19.14 has all the CL functions autoloaded by default, and
is dumped with cl.el.

ben

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 15 23:52:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA02792 for xemacs-beta-people; Sat, 15 Jun 1996 23:52:31 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA02789 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 15 Jun 1996 23:52:31 -0500 (CDT)
Received: from nene.boundless.com (wing.vip.best.com [204.156.158.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA22226 for <xemacs-beta@xemacs.org>; Sat, 15 Jun 1996 23:52:27 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id VAA04327; Sat, 15 Jun 1996 21:51:08 GMT
Date: Sat, 15 Jun 1996 21:51:08 GMT
Message-Id: <199606152151.VAA04327@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: More Mule-ing 
In-Reply-To: <9606141534.AA04809@prosun.first.gmd.de>
References: <31C03173.1894221@po.iijnet.or.jp>
	<199606131641.LAA00838@nvwls.cc.purdue.edu>
	<199606140446.EAA00832@nene.boundless.com>
	<9606141534.AA04809@prosun.first.gmd.de>

BTW your mailer put a bad address <sh@herr> in your From: line.

 > Just one warning about this stuff: some lisp-modules depend on
 > something like
 >   (cond ((fboundp 'make-overlay)
 > to decide, how to mark/highlight regions: overlays or extents. If
 > make-overlay is defined, some nice XEmacs features might be
 > disabled. Just make a  
 >   egrep "boundp.*overlay" <xemacs-dir>/lisp/*/*.el
 > to check which modules are affected.

Very true.  Better than defining the overlay functions (unless you
do a full-blown overlay emulation package) is to just fix Quail.
Given that the provided substitutions are so easy, just use a
global-substitution function like 'perl -pi.bak'.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 00:08:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA02859 for xemacs-beta-people; Sun, 16 Jun 1996 00:08:07 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA02856 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 00:08:06 -0500 (CDT)
Received: from nene.boundless.com (wing.vip.best.com [204.156.158.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA22230 for <xemacs-beta@xemacs.org>; Sun, 16 Jun 1996 00:08:02 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id WAA04408; Sat, 15 Jun 1996 22:06:26 GMT
Date: Sat, 15 Jun 1996 22:06:26 GMT
Message-Id: <199606152206.WAA04408@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
Cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: More Mule-ing 
In-Reply-To: <199606141248.VAA11840@mikan.jaist.ac.jp>
References: <199606140446.EAA00832@nene.boundless.com>
	<199606141248.VAA11840@mikan.jaist.ac.jp>

ISO-2022-JP writes:
 >   I like some mule features of XEmacs with Mule. For example,
 > character data type, wide character type string. However why function
 > names were changed? I think it seems bad choice. A lot of Mule
 > application does not work.

I changed the names because

1) The original MULE function names were badly named -- inconsistent
   with each other, and inconsistent with general Emacs conventions.
2) The functionality of the functions has been changed (usually
   cleaned up).  For many of the functions, I didn't like the
   functionality in the original MULE because it was inconvenient
   or not properly abstracted.
3) Some of the functions are no longer necessary at all -- e.g.
   all of the weird shit to deal with misaligned buffer positions.

For #2, for example, lots and lots of MULE functions used the concept
of a "leading char", which is properly an internal implementation
detail.  Exposing this made MULE byte-code unportable and generally
made it difficult or impossible to make later changes
e.g. incorporating Unicode.

As another example, a lot of data in MULE was represented kludgily
using properties attached to symbols, instead of creating new data
types.

In general, MULE exposed the internal representation of characters and
various other things to the Lisp coder, which is bad.  Many MULE
applications depended on this, and so naturally they will break in
XEmacs/Mule, which no longer exposes this implementation and in
general tries to properly abstract the data types.

 >   By the way, some mule features were cut off. Especially I want to
 > use program-coding-system.

They weren't intentionally cut off so much as never implemented.
When Sun decided to stop funding me, I hadn't gotten a lot of the
process encoding/decoding stuff completely working.  The functionality
present at that point got basically frozen, and will remain that way
until Martin or somebody else fixes it.

 >   In addition, function name of
 > `{encode|decode}-coding-{region|string}' seems strange. (And it does
 > not work yet)

I agree that those names are odd, but they are the names that RMS
insisted on in the merged FSF-Emacs/MULE.  This was one of my attempts
to have some compatibility with this beast.

However, I do like some of the RMS-mandated things about this:
i.e. the splitting of `code-convert-region' into an encoding and
a decoding function, and the reversal of the meanings of "encode"
and "decode" from the original MULE.

BTW none of the interfaces in XEmacs/MULE are frozen.  If you'd
like to see some interface changes, then by all means suggest them.
Similarly, if there's some missing functionality that you'd like
to see, and you have the time to implement it, then all by means
please do!

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 00:17:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA02878 for xemacs-beta-people; Sun, 16 Jun 1996 00:17:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA02875 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 00:17:56 -0500 (CDT)
Received: from nene.boundless.com (wing.vip.best.com [204.156.158.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA22233 for <xemacs-beta@xemacs.org>; Sun, 16 Jun 1996 00:17:52 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id WAA04469; Sat, 15 Jun 1996 22:16:26 GMT
Date: Sat, 15 Jun 1996 22:16:26 GMT
Message-Id: <199606152216.WAA04469@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: MORIOKA Tomohiko <morioka@jaist.ac.jp>,
        XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: More Mule-ing 
In-Reply-To: <199606160217.TAA13220@xemacs.eng.sun.com>
References: <199606140446.EAA00832@nene.boundless.com>
	<199606141248.VAA11840@mikan.jaist.ac.jp>
	<199606160217.TAA13220@xemacs.eng.sun.com>

Martin Buchholz writes:
 > >>>>> "MT" == MORIOKA Tomohiko <ISO-2022-JP> writes:
 > 
 > MT>   By the way, some mule features were cut off. Especially I want to
 > MT> use program-coding-system.
 > 
 > What is program-coding-system supposed to do?  XEmacs has:
 > process-input-coding-system
 > process-output-coding-system
 > 
 > I successfully use these to see EUC-encoded command output in shell
buffers.

Ah ...  forgive me if I'm a bit out-of-date w.r.t. what's in
XEmacs/Mule.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 01:29:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA02983 for xemacs-beta-people; Sun, 16 Jun 1996 01:29:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA02975 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 01:29:04 -0500 (CDT)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA22288 for <xemacs-beta@xemacs.org>; Sun, 16 Jun 1996 01:29:02 -0500 (CDT)
Received: from eistla.ifi.uio.no (4867@eistla.ifi.uio.no [129.240.94.29]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <IAA06108@ifi.uio.no> ; Sun, 16 Jun 1996 08:29:03 +0200
Received: (from larsi@localhost) by eistla.ifi.uio.no ; Sun, 16 Jun 1996 08:29:02 +0200
To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
Cc: xemacs-beta@xemacs.org
Subject: Re: Gnus 5
References: <199606142043.QAA11665@anthem.CNRI.Reston.Va.US>
In-Reply-To: "Barry A. Warsaw"'s message of Fri, 14 Jun 1996 16:43:01 -0400
Lines: 51
X-Mailer: Gnus v5.2.20/Emacs 19.29
Date: 16 Jun 1996 08:16:49 +0200
Message-ID: <x63f3w46jy.fsf@eyesore.no>
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>

"Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us> writes:

> 1. There should be a "T !" command to tick the thread.

`-1 T k' ticks the thread.  I could bind `T !' to tick the thread as
well, if you want that.  Ticking a (sub-)thread isn't something I've
ever done, so I'm not sure whether this is a very useful command,
though. 

> 2. I had a weird thing happen early on.  I read an article in a thread
>    that was interesting and ticked it.  Then I used ^ to see it's
>    parent, and I ticked the parent.  But when I quit the group and
>    reselected it, the parent was not shown.  The article had an `O'
>    flag (ancient mark) but "M c" didn't clear it.  The articles have
>    since expired and I haven't been able to reproduce this.

The problem is that some backends (and even some nntp servers)
actually say what the article number of the article fetched by
Message-ID is, while others don't.  If they don't, Gnus can't retain
marks for the article.  Perhaps Gnus should beep the users if they try
to set a mark on an "unmarkable" article?  Probably.  Fix in Gnus
5.2.20. 

> 3. Section 3.15 of the manual talks about gnus-split-methods.  When it
>    talks about the "match" being a symbol, it does not mention that
>    the function is called with a single argument: the newsgroup.

Yup; thanks.

> 4. (anal-retentive-mode 1) ==> It's "Supercite" *not* "SuperCite".  I
>    found the wrong spelling in both the Gnus manual and in the Message
>    manual.

Oops.  I've now corrected the spelling in the manuals.

> 5. I personally bound "h" in gnus-summary-mode-map to
>    gnus-summary-show-all-headers, but what I'd really like is a toggle
>    function instead.

`t' toggles showing the headers...  (In fact, all the "hiding"
functions are toggles.

> This is nice because if I return a directory (since that's as far as
> my split method could guess), then it sticks a trailing / on the file
> name and lets me do completion in a more natural way.

Thanks for the patch; I've applied it to Gnus v5.2.20.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 01:29:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA02988 for xemacs-beta-people; Sun, 16 Jun 1996 01:29:06 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA02980 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 01:29:05 -0500 (CDT)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA27246 for <xemacs-beta@cs.uiuc.edu>; Sun, 16 Jun 1996 01:29:07 -0500 (CDT)
Received: from eistla.ifi.uio.no (4867@eistla.ifi.uio.no [129.240.94.29]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <IAA06113@ifi.uio.no> for <xemacs-beta@cs.uiuc.edu> ; Sun, 16 Jun 1996 08:29:03 +0200
Received: (from larsi@localhost) by eistla.ifi.uio.no ; Sun, 16 Jun 1996 08:29:02 +0200
To: xemacs-beta@cs.uiuc.edu
Subject: Re: bring back the old GNUS toolbar!
References: <199606130751.IAA03953@wrath.parallax.co.uk>
	<199606131459.JAA00657@nvwls.cc.purdue.edu>
	<199606140520.FAA01313@nene.boundless.com>
In-Reply-To: Ben Wing's message of Fri, 14 Jun 1996 05:20:27 GMT
Lines: 28
X-Mailer: Gnus v5.2.20/Emacs 19.29
Date: 16 Jun 1996 07:59:06 +0200
Message-ID: <x6688s47dh.fsf@eyesore.no>
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>

Ben Wing <wing@666.com> writes:

> It has occurred to me a number of times that we ought to junk
> all of the XPM stuff and move to the GIF format.

The GIF format is nice and standard, but there are two things that I
*really* like about XPM:

1) I can edit XPM files using XEmacs.  For instance, yesterday
I was fiddling with some smiley icons (for the new smiley.el package)
and decided that it would be nice to add a circle around all the
smiley faces.  I whipped up a small elisp function to do so in, what,
10 minutes?  If these had been GIFs, I don't know what I'd do.
Probably not bothered to do anything.

2) `xpm-color-symbols'.  Letting users customize colors of XPMs is
trivial (cf. `gnus-xmas-logo-color-style').  Can you do similar things
with GIFs?  (I haven't actually looked through the manual; perhaps
it's easy to fiddle with GIF colors as well?)

Of course, if XEmacs had a mode for editing GIFs, using GIFs as the
standard picture format would make sense.  As it is now, however, one
has to leave (*sob*) XEmacs and (*gasp*) start a different program to
edit GIFs.  This Will Not Do!  :-)

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 01:29:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA02985 for xemacs-beta-people; Sun, 16 Jun 1996 01:29:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA02977 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 01:29:04 -0500 (CDT)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA22289 for <xemacs-beta@xemacs.org>; Sun, 16 Jun 1996 01:29:02 -0500 (CDT)
Received: from eistla.ifi.uio.no (4867@eistla.ifi.uio.no [129.240.94.29]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <IAA06116@ifi.uio.no> ; Sun, 16 Jun 1996 08:29:04 +0200
Received: (from larsi@localhost) by eistla.ifi.uio.no ; Sun, 16 Jun 1996 08:29:03 +0200
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: 19.14b24: Gnus comments, problems
References: <199606122200.QAA28196@gielgud.lanl.gov.xdiv>
In-Reply-To: John Turner's message of Wed, 12 Jun 1996 16:00:57 -0600
Lines: 24
X-Mailer: Gnus v5.2.20/Emacs 19.29
Date: 16 Jun 1996 08:24:12 +0200
Message-ID: <x6wx182rn7.fsf@eyesore.no>
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>

John Turner <turner@xdiv.lanl.gov> writes:

> - C-o used to save the name of the file last saved to.  Now it seems
>   to always get reset to the group name (which is what I have set for
>   the default). 

This has been fixed in Gnus 5.2.19.

> - Posting followup resulted in:
[...]
> Signalling: (wrong-type-argument stringp nil)
>   string-to-char(nil)
>   expand-file-name(nil)
>   rationalize-file-buffer-names(nil #<buffer "*sent followup to Salim Fadhley on alt.religion.emacs*">)
>   rename-buffer("*sent followup to Salim Fadhley on alt.religion.emacs*" t)
>   message-do-send-housekeeping()

I've had several similar bug reports, and it seems to be triggered by
a package called something like, uhm, "unique-rename"?  Is that a
package distributed by XEmacs?

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 03:57:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA07016 for xemacs-beta-people; Sun, 16 Jun 1996 03:57:34 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA07013 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 03:57:32 -0500 (CDT)
Received: from nene.boundless.com (wing.vip.best.com [204.156.158.108]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA28212 for <xemacs-beta@cs.uiuc.edu>; Sun, 16 Jun 1996 03:57:32 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA05589; Sun, 16 Jun 1996 01:56:07 GMT
Date: Sun, 16 Jun 1996 01:56:07 GMT
Message-Id: <199606160156.BAA05589@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: bring back the old GNUS toolbar!
In-Reply-To: <x6688s47dh.fsf@eyesore.no>
References: <199606130751.IAA03953@wrath.parallax.co.uk>
	<199606131459.JAA00657@nvwls.cc.purdue.edu>
	<199606140520.FAA01313@nene.boundless.com>
	<x6688s47dh.fsf@eyesore.no>

Lars Magne Ingebrigtsen writes:
 > Ben Wing <wing@666.com> writes:
 > 
 > > It has occurred to me a number of times that we ought to junk
 > > all of the XPM stuff and move to the GIF format.
 > 
 > The GIF format is nice and standard, but there are two things that I
 > *really* like about XPM:
 > 
 > 1) I can edit XPM files using XEmacs.  For instance, yesterday
 > I was fiddling with some smiley icons (for the new smiley.el package)
 > and decided that it would be nice to add a circle around all the
 > smiley faces.  I whipped up a small elisp function to do so in, what,
 > 10 minutes?  If these had been GIFs, I don't know what I'd do.
 > Probably not bothered to do anything.
 > 
 > 2) `xpm-color-symbols'.  Letting users customize colors of XPMs is
 > trivial (cf. `gnus-xmas-logo-color-style').  Can you do similar things
 > with GIFs?  (I haven't actually looked through the manual; perhaps
 > it's easy to fiddle with GIF colors as well?)

Agreed ...  I just wish the damn XPM writers could learn to write
better code.

Also, it's a pain that everyone who wants to use XPM has to download
it and install it themselves.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 08:40:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA07681 for xemacs-beta-people; Sun, 16 Jun 1996 08:40:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA07678 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 08:40:38 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA23415 for <xemacs-beta@xemacs.org>; Sun, 16 Jun 1996 08:40:34 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id WAA10985; Sun, 16 Jun 1996 22:40:30 +0900 (JST)
Message-Id: <199606161340.WAA10985@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: More Mule-ing 
In-reply-to: Your message of "Sat, 15 Jun 1996 19:17:54 MST."
             <199606160217.TAA13220@xemacs.eng.sun.com> 
Mime-Version: 1.0 (SEMI mime-edit 0.26)
Content-Type: multipart/mixed;
 boundary="Multipart_Sun_Jun_16_22:40:24_1996-1"
Content-Transfer-Encoding: 7bit
Date: Sun, 16 Jun 1996 22:40:29 JST
Sender: morioka@jaist.ac.jp

--Multipart_Sun_Jun_16_22:40:24_1996-1
Content-Type: text/plain; charset=US-ASCII

>>>>> In <199606160217.TAA13220@xemacs.eng.sun.com> 
>>>>>	Martin Buchholz <mrb@eng.sun.com> wrote:

Martin> >>>>> "MT" == MORIOKA Tomohiko <ISO-2022-JP> writes:

MT>   By the way, some mule features were cut off. Especially I want
MT> to use program-coding-system.

Martin> What is program-coding-system supposed to do?  XEmacs has:
Martin> process-input-coding-system
Martin> process-output-coding-system

  These features requires to modify programs for mule. Some programs
uses fixed coding-systems, so if process-coding-systems are defined
for programs, it is not required to set process-coding-system. It is
a concept of program-coding-system. It is very convenient.


Martin> I successfully use these to see EUC-encoded command output in
shell buffers. 

MT>   In addition, function name of
MT> `{encode|decode}-coding-{region|string}' seems strange. (And it
MT> does not work yet)

  In my environment (sparc-sun-sunos4shr, SUN OS 4.1.3_U1), when
decode-coding-region or decode-coding-string are called, fatal error
occurs and XEmacs is broken down. Following is backtrace:


--Multipart_Sun_Jun_16_22:40:24_1996-1
Content-Type: text/plain; charset=US-ASCII

Lisp backtrace follows:

  decode-coding-region(1 142 iso-2022-jp)
  eval((decode-coding-region (point-min) (point-max) (quote iso-2022-jp)))
  # bind (expr)
  eval-interactive((decode-coding-region (point-min) (point-max) (quote iso-2022-jp)))
  # bind (stab standard-output opoint eval-last-sexp-arg-internal)
  eval-last-sexp(t)
  # bind (standard-output)
  #<compiled-function (from "lisp-mode.elc") nil "...(20)" [standard-output terpri eval-last-sexp t] 2 807640 nil>()
  call-interactively(eval-print-last-sexp)
  # (condition-case ... . error)
  # (catch top-level ...)


--Multipart_Sun_Jun_16_22:40:24_1996-1
Content-Type: text/plain; charset=US-ASCII


Martin> I have successfully used these functions to Japanize a GNUS
Martin> article:

  If you use tm-gnus, you can use MIME charset and default
coding-system for newsgroups (for non-MIME messages).

  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---
--Multipart_Sun_Jun_16_22:40:24_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 09:40:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA07798 for xemacs-beta-people; Sun, 16 Jun 1996 09:40:35 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA07795 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 09:40:34 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA25535 for <xemacs-beta@xemacs.org>; Sun, 16 Jun 1996 09:40:31 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA01135; Sun, 16 Jun 1996 08:40:24 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA29302; Sun, 16 Jun 1996 08:40:23 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA05150; Sun, 16 Jun 1996 08:40:08 -0600
Date: Sun, 16 Jun 1996 08:40:08 -0600
Message-Id: <199606161440.IAA05150@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: larsi@ifi.uio.no
Cc: xemacs-beta@xemacs.org
Subject: Re: 19.14b24: Gnus comments, problems
In-Reply-To: <x6wx182rn7.fsf@eyesore.no>
References: <199606122200.QAA28196@gielgud.lanl.gov.xdiv>
	<x6wx182rn7.fsf@eyesore.no>
Reply-To: turner@lanl.gov

Lars Magne Ingebrigtsen writes:
 > John Turner <turner@xdiv.lanl.gov> writes:
 > 
 > > - C-o used to save the name of the file last saved to.  Now it seems
 > >   to always get reset to the group name (which is what I have set for
 > >   the default). 
 > 
 > This has been fixed in Gnus 5.2.19.

Great.  Thanks.

 > > - Posting followup resulted in:
 > [...]
 > > Signalling: (wrong-type-argument stringp nil)
 > >   string-to-char(nil)
 > >   expand-file-name(nil)
 > >   rationalize-file-buffer-names(nil #<buffer "*sent followup to Salim Fadhley on alt.religion.emacs*">)
 > >   rename-buffer("*sent followup to Salim Fadhley on alt.religion.emacs*" t)
 > >   message-do-send-housekeeping()
 > 
 > I've had several similar bug reports, and it seems to be triggered by
 > a package called something like, uhm, "unique-rename"?  Is that a
 > package distributed by XEmacs?

Ahh... uniquify.

It renames buffers by tacking on a piece of the path to keep them
unique rather than just tacking on <2>, <3>, etc.  I like the idea,
but it's not perfect, and does seem to cause problems pretty often...

I'll try w/o uniquify and see if that fixes things...

-John


From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 11:00:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA07940 for xemacs-beta-people; Sun, 16 Jun 1996 11:00:43 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA07937 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 11:00:42 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA08285 for <xemacs-beta@cs.uiuc.edu>; Sun, 16 Jun 1996 11:00:43 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA24889; Sun, 16 Jun 1996 11:00:39 -0500 (CDT)
Message-Id: <199606161600.LAA24889@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: edit-toolbar version 1.0 
In-reply-to: Your message of "14 Jun 1996 14:11:30 PDT."
             <m2d932yttp.fsf@deanna.miranova.com> 
Date: Sun, 16 Jun 1996 11:00:38 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Peter> I threw this together last night... to try it out load the
    Peter> file and type M-x edit-toolbar RET.  I should note that it
    Peter> requires XEmacs 19.14.

    Steven> This is a *wonderful* function!  Is it too late to put
    Steven> this in 19.14 Chuck?


We definitely need something like this.  However, I'm going to wait to
add it to the distribution until it is more generic.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 11:54:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA08085 for xemacs-beta-people; Sun, 16 Jun 1996 11:54:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA08082 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 11:54:50 -0500 (CDT)
Received: from pez.carroll.com (pez.carroll.com [199.224.10.48]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA10119 for <xemacs-beta@cs.uiuc.edu>; Sun, 16 Jun 1996 11:54:49 -0500 (CDT)
Received: (from pez@localhost) by pez.carroll.com (8.7.1/8.7.1) id NAA27973; Sun, 16 Jun 1996 13:02:14 -0400
Date: Sun, 16 Jun 1996 13:02:14 -0400
Message-Id: <199606161702.NAA27973@pez.carroll.com>
From: Peter Pezaris <pez@dwwc.com>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: edit-toolbar version 1.0
In-Reply-To: <m2d932yttp.fsf@deanna.miranova.com>
References: <199606140021.UAA08401@pez.carroll.com>
	<m2d932yttp.fsf@deanna.miranova.com>
Reply-To: pez@dwwc.com


    Peter> I'm very interested if anyone has any suggestions for
    Peter> improvement.

    Steven> 1.  Do something similar for the default menu-bar.

This is hard.  Unfortunately the menu is a much more complicated
beast than the toolbar.  Although some of the principals are the
same, edit-menubar is going to be much more complicated than
edit-toolbar.

    Steven> Make it work for any toolbar.

This will be done in version 1.1 (sometime early this week).

    Steven> The code automatically inserted into .emacs needs to be
    Steven> defensive against bombing when X Windows is not active,
    Steven> or if it should run up against an XEmacs without
    Steven> toolbars something like this:

Fixed in 1.1.  Thanks.

-Pez

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 14:17:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA08367 for xemacs-beta-people; Sun, 16 Jun 1996 14:17:12 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA08364 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 14:17:11 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA11298 for <xemacs-beta@cs.uiuc.edu>; Sun, 16 Jun 1996 14:17:11 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id MAA09789; Sun, 16 Jun 1996 12:16:25 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: More Mule-ing
References: <199606161340.WAA10985@mikan.jaist.ac.jp>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: =?ISO-2022-JP?B?GyQoQjxpMiwbKEIgGyQoQkNOSScbKEI=?= / MORIOKA
 Tomohiko's message of 16 Jun 1996 06:40:29 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=ISO-2022-JP
Date: 16 Jun 1996 12:16:23 -0700
Message-ID: <m2spbv36go.fsf@deanna.miranova.com>
Lines: 31
X-Mailer: Gnus v5.2.19/XEmacs 20.0

>>>>> "Tomohiko" == $(B<i2,(B $(BCNI'(B / MORIOKA Tomohiko <morioka@jaist.ac.jp> writes:

Martin> I have successfully used these functions to Japanize a GNUS
Martin> article:

Tomohiko>   If you use tm-gnus, you can use MIME charset and default
Tomohiko> coding-system for newsgroups (for non-MIME messages).

tm-gnus does a *spectacular* job, and it works out of the box.  I like
very much seeing converted ISO-2022-JP.  For those of you who haven't
seen a ``real'' 20.0 screen yet, I've put some snapshots up on the
Web:

Gnus summary buffer of the tm english mailing list
	http://www.miranova.com/~steve/mule1.gif

Gnus/tm-view of an article in fj.comp.security showing mixed English
and Japanese
	http://www.miranova.com/~steve/mule2.gif

A file from the tm distribution showing font-locking and mixed language
	http://www.miranova.com/~steve/mule3.gif

I'm not too happy with the way email addresses with special encoding
are handled wrt citation, but that can be fixed.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 14:27:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA08380 for xemacs-beta-people; Sun, 16 Jun 1996 14:27:12 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA08377 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 14:27:11 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA11376 for <xemacs-beta@cs.uiuc.edu>; Sun, 16 Jun 1996 14:27:11 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id MAA09837; Sun, 16 Jun 1996 12:26:19 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: More Mule-ing
References: <199606161340.WAA10985@mikan.jaist.ac.jp>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: =?ISO-2022-JP?B?GyQoQjxpMiwbKEIgGyQoQkNOSScbKEI=?= / MORIOKA
 Tomohiko's message of 16 Jun 1996 06:40:29 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 16 Jun 1996 12:26:18 -0700
Message-ID: <m2pw6z3605.fsf@deanna.miranova.com>
Lines: 33
X-Mailer: Gnus v5.2.19/XEmacs 20.0

(Sorry about the previous message.  Let me try it again).

>>>>> "Tomohiko" == MORIOKA Tomohiko <morioka@jaist.ac.jp> writes:

Martin> I have successfully used these functions to Japanize a GNUS
Martin> article:

Tomohiko>   If you use tm-gnus, you can use MIME charset and default
Tomohiko> coding-system for newsgroups (for non-MIME messages).

tm-gnus does a *spectacular* job, and it works out of the box.  I like
very much seeing converted ISO-2022-JP.  For those of you who haven't
seen a ``real'' 20.0 screen yet, I've put some snapshots up on the
Web:

Gnus summary buffer of the tm english mailing list
	http://www.miranova.com/~steve/mule1.gif

Gnus/tm-view of an article in fj.comp.security showing mixed English
and Japanese
	http://www.miranova.com/~steve/mule2.gif

A file from the tm distribution showing font-locking and mixed language
	http://www.miranova.com/~steve/mule3.gif

I'm not too happy with the way email addresses with special encoding
are handled wrt citation, but that can be fixed.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 14:42:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA08433 for xemacs-beta-people; Sun, 16 Jun 1996 14:42:02 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA08430 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 14:42:01 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA11526 for <xemacs-beta@cs.uiuc.edu>; Sun, 16 Jun 1996 14:42:02 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id MAA00899; Sun, 16 Jun 1996 12:41:31 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA18124; Sun, 16 Jun 1996 12:41:30 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA13604; Sun, 16 Jun 1996 12:41:28 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA16770; Sun, 16 Jun 1996 12:41:27 -0700
Date: Sun, 16 Jun 1996 12:41:27 -0700
Message-Id: <199606161941.MAA16770@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: More Mule-ing
In-Reply-To: <m2pw6z3605.fsf@deanna.miranova.com>
References: <199606161340.WAA10985@mikan.jaist.ac.jp>
	<m2pw6z3605.fsf@deanna.miranova.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Steve" == Steven L Baur <steve@miranova.com> writes:

Steve> tm-gnus does a *spectacular* job, and it works out of the box.  I like
Steve> very much seeing converted ISO-2022-JP.  For those of you who haven't
Steve> seen a ``real'' 20.0 screen yet, I've put some snapshots up on the
Steve> Web:

I agree that tm is something we need to integrate into XEmacs.  I
wasn't suggesting that my quick hack to get gnus working was what
XEmacs should actually use.

I am suprised at how many XEmacs/Mule things actually work, without me
or Ben ever having invested effort in making them happen.

Martin

Steve> Gnus summary buffer of the tm english mailing list
Steve> 	http://www.miranova.com/~steve/mule1.gif


From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 14:57:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA08482 for xemacs-beta-people; Sun, 16 Jun 1996 14:57:16 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA08479 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 14:57:14 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA05860 for <xemacs-beta@xemacs.org>; Sun, 16 Jun 1996 14:57:11 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id MAA01778; Sun, 16 Jun 1996 12:56:41 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA18413; Sun, 16 Jun 1996 12:56:40 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA13685; Sun, 16 Jun 1996 12:56:38 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA16787; Sun, 16 Jun 1996 12:56:37 -0700
Date: Sun, 16 Jun 1996 12:56:37 -0700
Message-Id: <199606161956.MAA16787@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: MORIOKA Tomohiko <morioka@jaist.ac.jp>
Cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: XEmacs/Mule on SunOS 4
In-Reply-To: <199606161340.WAA10985@mikan.jaist.ac.jp>
References: <199606160217.TAA13220@xemacs.eng.sun.com>
	<199606161340.WAA10985@mikan.jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "MT" == MORIOKA Tomohiko  writes:

MT>   In my environment (sparc-sun-sunos4shr, SUN OS 4.1.3_U1), when
MT> decode-coding-region or decode-coding-string are called, fatal error
MT> occurs and XEmacs is broken down. Following is backtrace:

I am rather surprised that any Japanese users are still using SunOS 4.
A lot of work has been done by Sun to internationalize Solaris, and
Solaris 2.5 seems to be a pretty solid OS otherwise.

I am also surprised that XEmacs/Mule works well on SunOS 4.

Martin

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 15:26:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA08572 for xemacs-beta-people; Sun, 16 Jun 1996 15:26:39 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA08569 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 15:26:38 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA11874 for <xemacs-beta@cs.uiuc.edu>; Sun, 16 Jun 1996 15:26:39 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id OAA06127; Sun, 16 Jun 1996 14:21:35 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id OAA00316; Sun, 16 Jun 1996 14:21:33 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id OAA05396; Sun, 16 Jun 1996 14:21:17 -0600
Date: Sun, 16 Jun 1996 14:21:17 -0600
Message-Id: <199606162021.OAA05396@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b24: More on Gnus 5.2
In-Reply-To: <m2enng61de.fsf@deanna.miranova.com>
References: <199606151935.NAA04222@gielgud.lanl.gov.xdiv>
	<m2enng61de.fsf@deanna.miranova.com>
Reply-To: turner@lanl.gov

Steven L. Baur writes:
 > >>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:
 > 
 > John> As an aside, I'd like some advice on migrating from adaptive
 > John> scoring to more manual control.  Actually, this might be a good
 > John> entry for the Gnus FAQ, since I imagine many people might do
 > John> what I did.  That is, turn on adaptive scoring just to see how
 > John> it did and get a feel for the whole idea of scoring, then decide
 > John> they want more control.
 > 
 > The longest question in the FAQ is devoted to (manual) score file
 > suggestions.  What else would you like to see?

I've definitely looked at the FAQ.  You must be referring to Q2.4,
which has all.SCORE examples.  You're right, it's great, but it
doesn't really address migrating from adaptive to manual.  Here are a
couple of things I wonder about:

- Is using adaptive along with manual a good idea (or even possible)?
  My impression right now is that although adaptive was a nice place
  to visit, I wouldn't really want to live there.

- If I move to manual, what do I do with all these .ADAPT files?  Just
  delete them?  Edit them and grab pieces for all.SCORE?  I'm thinking
  just delete them.

- One thing I haven't been sure of is whether scoring changes I make
  while reading a group (I s s, L s s, etc.) are permanent.  It seems
  they are not.

I'm just sort of overwhelmed by all the options, etc.  I'll just keep
reading the info and FAQ and asking dumb questions (and I'll try to
keep the dumb questions to gnu.emacs.gnus rather than here).

-John

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 16:41:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA08824 for xemacs-beta-people; Sun, 16 Jun 1996 16:41:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA08821 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 16:41:03 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA12539 for <xemacs-beta@cs.uiuc.edu>; Sun, 16 Jun 1996 16:41:04 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id OAA12036; Sun, 16 Jun 1996 14:40:13 -0700
Sender: steve@miranova.com
To: turner@lanl.gov
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b24: More on Gnus 5.2
References: <199606151935.NAA04222@gielgud.lanl.gov.xdiv>
	<m2enng61de.fsf@deanna.miranova.com>
	<199606162021.OAA05396@gielgud.lanl.gov.xdiv>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: John Turner's message of 16 Jun 1996 13:21:17 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 16 Jun 1996 14:40:11 -0700
Message-ID: <m2g27v2zt0.fsf@deanna.miranova.com>
Lines: 72
X-Mailer: Gnus v5.2.19/XEmacs 20.0

>>>>> "John" == John Turner <turner@xdiv.LANL.GOV> writes:

John> Steven L. Baur writes:

>> The longest question in the FAQ is devoted to (manual) score file
>> suggestions.  What else would you like to see?

John> I've definitely looked at the FAQ.  You must be referring to
John> Q2.4, which has all.SCORE examples.  You're right, it's great,
John> but it doesn't really address migrating from adaptive to manual.
John> Here are a couple of things I wonder about:

This part I don't understand.  There is no need to migrate from
adaptive scoring to manual scoring.  If you don't want adaptive
scoring, turn it off and rm all your .ADAPT files.

John> - Is using adaptive along with manual a good idea (or even
John>   possible)?

This is a matter of taste.  I use both, I suspect most people use both
as well.

John>   My impression right now is that although adaptive was a nice
John>   place to visit, I wouldn't really want to live there.

O.K.  Then don't use it.  I too have been somewhat disappointed with
adaptive scoring, but am not yet ready to give up on it.  The problem
may be that it just doesn't scale up properly.  The worst messages
tend to be ones that you have no history on (ie. multi-posted spam
from a one-shot account), these can sometimes be the best messages if
they are coming from infrequent, but clueful posters.

As an alternative, there's GroupLens ratings for selected groups, and
we've recently been discussing a protocol for extending the NoCEM
concept to mailing lists.

John> - If I move to manual, what do I do with all these .ADAPT files?
John>   Just delete them?  Edit them and grab pieces for all.SCORE?
John>   I'm thinking just delete them.

Yup.  You might want to grab pieces where you've scored down
particularly obnoxious posters, but that's up to you.

John> - One thing I haven't been sure of is whether scoring changes I
John>   make while reading a group (I s s, L s s, etc.) are permanent.
John>   It seems they are not.

It depends on what you ask for.  One of the letters in the alphabet
soup score function keymap controls duration.  The default is
temporary, to keep score file sizes down.  This is controlled by the
variable gnus-score-default-duration (temporary, permanent, or
immediate). The expiration period is controlled by the variable
gnus-score-expiry-days.

John> I'm just sort of overwhelmed by all the options, etc.  

I understand.  It is for this reason I signed up to do the Gnus FAQ.

John> I'll just keep reading the info and FAQ and asking dumb
John> questions (and I'll try to keep the dumb questions to
John> gnu.emacs.gnus rather than here).

I would also recommend browsing past archives of the Gnus developers
mailing list.  Last October and November had discussion of many of the
features added to 5.2.
	http://www.miranova.com/gnus-list/

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 20:08:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA09487 for xemacs-beta-people; Sun, 16 Jun 1996 20:08:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA09484 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 20:08:40 -0500 (CDT)
Received: from GS213.SP.CS.CMU.EDU (GS213.SP.CS.CMU.EDU [128.2.209.183]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA13916 for <xemacs-beta@xemacs.org>; Sun, 16 Jun 1996 20:08:35 -0500 (CDT)
Received: by GS213.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA43125; Sun, 16 Jun 1996 21:08:35 -0400
Date: Sun, 16 Jun 1996 21:08:35 -0400
Message-Id: <9606170108.AA43125@GS213.SP.CS.CMU.EDU>
From: Darrell Kindred <dkindred+@cmu.edu>
To: xemacs-beta@xemacs.org
Cc: Jens Lautenbacher <jens@lemcbed.lem.uni-karlsruhe.de>
Subject: file-appears-in-wrong-frame bug w/ patch
References: <9605311230.AA00571@lemcbed.lem.uni-karlsruhe.de>

This is a must-fix bug IMO, assuming that the file-selection dialog
box remains the default for mouse-activated file-prompting operations.

The bug:

   xemacs -q, C-x 5 2.  Make sure both frames remain visible.
   Then, in the *new* frame, choose "Open File" from the "File"
   menu.  Choose a file.  It appears in the wrong frame.

This bug was also noted earlier, but I don't think it's in the bug list:

  Jens Lautenbacher <jens@lemcbed.lem.uni-karlsruhe.de> wrote:
   > c) There are to many parts where the find-file popup menu is used. If
   >    I have two frames open, insert file will prompt for a file with the
   >    popup menu, but the file will be inserted in the wrong frame into
   >    the (of course wrong) window. Also mime-edit from tm doesn't work
   >    nicely with the popup menu. Maybe it should only be used if the
   >    open button in the toolbar is pressed? Maybe configurable?

The patch below causes delete-frame to select the parent frame if
possible.  Sound right?

- Darrell

*** src/console.h.orig	Wed May 15 21:20:51 1996
--- src/console.h	Sun Jun 16 20:24:13 1996
***************
*** 109,114 ****
--- 109,115 ----
    void (*set_icon_name_from_char_method) (struct frame *f, char *title);
    void (*set_frame_pointer_method) (struct frame *f);
    void (*set_frame_icon_method) (struct frame *f);
+   Lisp_Object (*get_frame_parent_method) (struct frame *f);
  
    /* redisplay methods */
    int (*left_margin_width_method) (struct window *);
*** src/frame.c.orig	Sun Jun  9 11:48:39 1996
--- src/frame.c	Sun Jun 16 20:24:13 1996
***************
*** 1293,1301 ****
      {
        Lisp_Object next;
  
!       /* find another visible frame; if none, just take any frame.
           First try the same device, then the same console. */
!       next = next_frame (frame, Qvisible, device);
        if (NILP (next) || EQ (next, frame))
  	next = next_frame (frame, Qvisible, console);
        if (NILP (next) || EQ (next, frame))
--- 1293,1305 ----
      {
        Lisp_Object next;
  
!       /* If this is a popup frame, select its parent if possible.
! 	 Otherwise, find another visible frame; if none, just take any frame.
           First try the same device, then the same console. */
! 
!       next = DEVMETH_OR_GIVEN (d, get_frame_parent, (f), Qnil);
!       if (NILP (next) || EQ (next, frame) || ! FRAME_LIVE_P (XFRAME (next)))
! 	next = next_frame (frame, Qvisible, device);
        if (NILP (next) || EQ (next, frame))
  	next = next_frame (frame, Qvisible, console);
        if (NILP (next) || EQ (next, frame))
*** src/frame-x.c.orig	Sun Jun  9 11:48:43 1996
--- src/frame-x.c	Sun Jun 16 20:24:13 1996
***************
*** 1762,1767 ****
--- 1762,1789 ----
    XSync (XtDisplay (FRAME_X_TEXT_WIDGET (f)), 0);
  }
  
+ static Lisp_Object
+ x_get_frame_parent (struct frame *f)
+ {
+   Widget parentwid = 0;
+   Arg av[1];
+ 
+   XtSetArg (av[0], XtNtransientFor, &parentwid);
+   XtGetValues (FRAME_X_SHELL_WIDGET (f), av, 1);
+   /* find the frame whose wid is parentwid */
+   if (parentwid)
+     {
+       Lisp_Object frmcons;
+       DEVICE_FRAME_LOOP (frmcons, XDEVICE (FRAME_DEVICE (f)))
+ 	{
+ 	  Lisp_Object frame = XCAR (frmcons);
+ 	  if (FRAME_X_SHELL_WIDGET (XFRAME (frame)) == parentwid)
+ 	    return frame;
+ 	}
+     }
+   return Qnil;
+ }
+ 
  DEFUN ("x-window-id", Fx_window_id, Sx_window_id, 0, 1, 0 /*
  Get the ID of the X11 window.
  This gives us a chance to manipulate the Emacs window from within a
***************
*** 2181,2186 ****
--- 2203,2209 ----
    CONSOLE_HAS_METHOD (x, frame_iconified_p);
    CONSOLE_HAS_METHOD (x, set_frame_pointer);
    CONSOLE_HAS_METHOD (x, set_frame_icon);
+   CONSOLE_HAS_METHOD (x, get_frame_parent);
  }
  
  void

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 20:45:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA09579 for xemacs-beta-people; Sun, 16 Jun 1996 20:45:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA09576 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 20:45:04 -0500 (CDT)
Received: from netcom2.netcom.com (root@netcom2.netcom.com [192.100.81.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA13936 for <xemacs-beta@xemacs.org>; Sun, 16 Jun 1996 20:45:02 -0500 (CDT)
Received: from netcom20.netcom.com (wing@netcom20.netcom.com [192.100.81.133]) by netcom2.netcom.com (8.6.13/Netcom)
	id SAA22857; Sun, 16 Jun 1996 18:45:03 -0700
Date: Sun, 16 Jun 1996 18:45:03 -0700
Message-Id: <199606170145.SAA22857@netcom2.netcom.com>
From: wing@666.com (Ben Wing)
To: dkindred+@cmu.edu, xemacs-beta@xemacs.org
Subject: Re:  file-appears-in-wrong-frame bug w/ patch
Cc: jens@lemcbed.lem.uni-karlsruhe.de

Yes, this patch looks great.  Add it.

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 22:41:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA09894 for xemacs-beta-people; Sun, 16 Jun 1996 22:41:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA09891 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 22:41:53 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA16669 for <xemacs-beta@xemacs.org>; Sun, 16 Jun 1996 22:41:49 -0500 (CDT)
Message-Id: <199606170341.WAA16669@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: one last beta25 delay
Date: Sun, 16 Jun 1996 22:41:47 -0500
From: Chuck Thompson <cthomp@xemacs.org>

The release workspaces are building one last time.  Everything is
almost ready.  You can blame Ben and the Bulls for this one last
delay.  Ben because I needed one last patch from him, the Bulls
because they delayed me actually applying the patch Ben did send.

The champagne has been drunk.
The cigars have been smoked.
The music was funk.
And I am so stoked.
The rhymes must end.
Beta 25's 'round the bend.
The Bulls have won four.
The finals were war.
Soon 19.14 will be no more.
Cause it will be out the door.

beta25 will definitely be out in the morning, folks.  It's ready.  Its
just that I'm not.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 16 23:52:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA09977 for xemacs-beta-people; Sun, 16 Jun 1996 23:52:52 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA09974 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 16 Jun 1996 23:52:51 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA25105 for <xemacs-beta@cs.uiuc.edu>; Sun, 16 Jun 1996 23:52:53 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id WAA14623; Sun, 16 Jun 1996 22:52:42 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id WAA01326; Sun, 16 Jun 1996 22:52:40 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id WAA06511; Sun, 16 Jun 1996 22:52:24 -0600
Date: Sun, 16 Jun 1996 22:52:24 -0600
Message-Id: <199606170452.WAA06511@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b24: More on Gnus 5.2
In-Reply-To: <m2g27v2zt0.fsf@deanna.miranova.com>
References: <199606151935.NAA04222@gielgud.lanl.gov.xdiv>
	<m2enng61de.fsf@deanna.miranova.com>
	<199606162021.OAA05396@gielgud.lanl.gov.xdiv>
	<m2g27v2zt0.fsf@deanna.miranova.com>
Reply-To: turner@lanl.gov

Steven L. Baur writes:

 > John> - One thing I haven't been sure of is whether scoring changes I
 > John>   make while reading a group (I s s, L s s, etc.) are permanent.
 > John>   It seems they are not.
 > 
 > It depends on what you ask for.  One of the letters in the alphabet
 > soup score function keymap controls duration.  The default is
 > temporary, to keep score file sizes down.  This is controlled by the
 > variable gnus-score-default-duration (temporary, permanent, or
 > immediate). The expiration period is controlled by the variable
 > gnus-score-expiry-days.

Yeah, I saw this soon after sending that last msg and once again felt
like an idiot.

 > John> I'm just sort of overwhelmed by all the options, etc.  
 > 
 > I understand.  It is for this reason I signed up to do the Gnus FAQ.
 > 
 > John> I'll just keep reading the info and FAQ and asking dumb
 > John> questions (and I'll try to keep the dumb questions to
 > John> gnu.emacs.gnus rather than here).
 > 
 > I would also recommend browsing past archives of the Gnus developers
 > mailing list.  Last October and November had discussion of many of the
 > features added to 5.2.
 > 	http://www.miranova.com/gnus-list/

Haven't yet, but will.

Thanks for all your help.  I'm getting there.

-John

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 01:56:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA10187 for xemacs-beta-people; Mon, 17 Jun 1996 01:56:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA10184 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 01:56:14 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA26307 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 01:56:12 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA19751; Mon, 17 Jun 1996 08:56:03 +0200
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA22774; Mon, 17 Jun 1996 08:56:03 +0200
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@cs.uiuc.edu
Subject: realpath is broken on AIX 4
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 17 Jun 1996 08:56:02 +0200
Message-Id: <y9lu3wa9awt.fsf@modas.informatik.uni-tuebingen.de>
Lines: 20
X-Mailer: Gnus v5.2.12/XEmacs 19.14


It doesn't work on non-existing whiles.  That breaks gnus, for
instance.

Patch follows.

Cheers =8-} Mike

*** src/s/aix4.h~	Sun Jun  2 02:12:29 1996
--- src/s/aix4.h	Mon Jun 17 08:27:00 1996
***************
*** 6,8 ****
--- 6,11 ----
  
  /* AIX 4 does not have HFT any more.  */
  #undef AIXHFT
+ 
+ /* realpath is broken */
+ #undef HAVE_REALPATH


From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 03:11:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA13786 for xemacs-beta-people; Mon, 17 Jun 1996 03:11:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA13764 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 03:11:45 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA27034 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 03:11:43 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id JAA32120; Mon, 17 Jun 1996 09:13:01 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id JAA15742; Mon, 17 Jun 1996 09:12:54 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id JAA05669; Mon, 17 Jun 1996 09:16:15 +0100
Date: Mon, 17 Jun 1996 09:16:15 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606170816.JAA05669@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu, larsi@ifi.uio.no
Subject: Re: bring back the old GNUS toolbar!
X-Sun-Charset: US-ASCII


> 1) I can edit XPM files using XEmacs.  For instance, yesterday
> I was fiddling with some smiley icons (for the new smiley.el package)
> and decided that it would be nice to add a circle around all the
> smiley faces.  I whipped up a small elisp function to do so in, what,
> 10 minutes?  If these had been GIFs, I don't know what I'd do.
> Probably not bothered to do anything.
> 
> 2) `xpm-color-symbols'.  Letting users customize colors of XPMs is
> trivial (cf. `gnus-xmas-logo-color-style').  Can you do similar things
> with GIFs?  (I haven't actually looked through the manual; perhaps
> it's easy to fiddle with GIF colors as well?)
> 
> Of course, if XEmacs had a mode for editing GIFs, using GIFs as the
> standard picture format would make sense.  As it is now, however, one
> has to leave (*sob*) XEmacs and (*gasp*) start a different program to
> edit GIFs.  This Will Not Do!  :-)

I agree.

andy

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 04:07:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA14057 for xemacs-beta-people; Mon, 17 Jun 1996 04:07:53 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA14054 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 04:07:52 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA18787 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 04:07:48 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA23219; Mon, 17 Jun 1996 02:02:30 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA22570; Mon, 17 Jun 1996 11:01:58 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA11845; Mon, 17 Jun 1996 11:01:07 +0200
Date: Mon, 17 Jun 1996 11:01:07 +0200
Message-Id: <9606170901.AA11845@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: wing@666.com (Ben Wing)
Cc: ketil@ii.uib.no, xemacs-beta@xemacs.org
Subject: Re:  ^G granularity?
In-Reply-To: <199606160147.SAA22246@netcom2.netcom.com>
References: <199606160147.SAA22246@netcom2.netcom.com>
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

wing@666.com (Ben Wing) writes, in <199606160147.SAA22246@netcom2.netcom.com>:

>C-g does work for most people in most circumstances.  If it doesn't,
>there are only two explanations:

A while ago I noticed that C-g was being ignored under Digital UNIX.  As
suggested, I defined BROKEN_SIGIO, and `(while t)' is now interruptible.

        Steve


*** src/s/decosf3-1.h.dist	Sat Oct 14 00:25:44 1995
--- src/s/decosf3-1.h	Mon Jun 17 08:57:51 1996
***************
*** 28,30 ****
--- 28,32 ----
  #define HAVE_SELECT
  #define HAVE_UNION_WAIT
  #undef HAVE_WAITPID
+ 
+ #define BROKEN_SIGIO

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 06:26:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA14212 for xemacs-beta-people; Mon, 17 Jun 1996 06:26:20 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA14208 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 06:26:18 -0500 (CDT)
Received: from netcom2.netcom.com (root@netcom2.netcom.com [192.100.81.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA18831 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 06:26:14 -0500 (CDT)
Received: from netcom11.netcom.com (wing@netcom11.netcom.com [192.100.81.121]) by netcom2.netcom.com (8.6.13/Netcom)
	id EAA01967; Mon, 17 Jun 1996 04:26:18 -0700
Date: Mon, 17 Jun 1996 04:26:18 -0700
Message-Id: <199606171126.EAA01967@netcom2.netcom.com>
From: wing@666.com (Ben Wing)
To: carney@gvc.dec.com
Subject: Re:  ^G granularity?
Cc: ketil@ii.uib.no, xemacs-beta@xemacs.org

Hmm ...  this could also mean that XEmacs' SIGIO code is incorrect for
OSF 3.1.  Maybe some OSF/Unix-IO-guts guru could take a look at this?

ben

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 07:45:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA14469 for xemacs-beta-people; Mon, 17 Jun 1996 07:45:38 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA14466 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 07:45:37 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA01025 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 07:45:36 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id HAA25083 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 07:45:04 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id HAA20656 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 07:45:03 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id IAA17451 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 08:40:20 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: I_SETSIG message
Date: Mon, 17 Jun 1996 08:40:17 -0400
Message-ID: <810.835015217@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

I still get this message on the console:

	syslog:  ioctl:  I_SETSIG failed 22

XEmacs is working just fine.  This only happens when I exit xemacs
(gasp!).  It's just annoying but certainly not fatal.

Ray

P.S.  This is Solaris 2.5, X11R6.1, gcc 2.7.2, sound=both, no Motif.



From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 08:47:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA14583 for xemacs-beta-people; Mon, 17 Jun 1996 08:47:07 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA14580 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 08:47:06 -0500 (CDT)
Received: from eik (eik.ii.uib.no [129.177.16.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA27329 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 08:47:01 -0500 (CDT)
Received: from due.ii.uib.no (due) by eik with SMTP id AA28580
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Mon, 17 Jun 1996 15:44:53 +0200
Received: by due.ii.uib.no; (5.65/1.1.8.2/08Jun94-0756AM)
	id AA22571; Mon, 17 Jun 1996 15:44:45 +0200
Sender: ketil@ii.uib.no
To: carney@gvc.dec.com
Cc: wing@666.com (Ben Wing), xemacs-beta@xemacs.org
Subject: Re: ^G granularity?
References: <199606160147.SAA22246@netcom2.netcom.com>
	<9606170901.AA11845@fornet.gvc.dec.com>
From: Ketil Z Malde <ketil@ii.uib.no>
In-Reply-To: Stephen Carney's message of Mon, 17 Jun 1996 11:01:07 +0200
Date: 17 Jun 1996 15:44:43 +0200
Message-Id: <KETIL-eg688qee9g.fsf@due.ii.uib.no>
Lines: 19
X-Mailer: Gnus v5.2.1/XEmacs 19.14


Ben Wing explains:

>> C-g does work for most people in most circumstances.  If it doesn't,
>> there are only two explanations:

To which Stephen Carney <carney@gvc.dec.com> comments:

> A while ago I noticed that C-g was being ignored under Digital UNIX.
> As suggested, I defined BROKEN_SIGIO, and `(while t)' is now
> interruptible.

Sure enough, this is Digital Unix, and the (while t) test fails
miserably.  I'll compile the next beta with BROKEN_SIGIO, and see if it
works for me too. 

~kzm



From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 10:05:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA14804 for xemacs-beta-people; Mon, 17 Jun 1996 10:05:27 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA14801 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 10:05:26 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA08665 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 10:05:25 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id QAA11422 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 16:06:35 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id QAA29182 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 16:06:27 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id QAA12447; Mon, 17 Jun 1996 16:09:48 +0100
Date: Mon, 17 Jun 1996 16:09:48 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606171509.QAA12447@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: Theory on wierd buffer selection.
X-Sun-Charset: US-ASCII

Do you think that the wierd buffer selection has something to do 
with the file dialog box. For instance pick cvs-update from the
menubar, you get a file dialog, select a directory, pop-to-buffer
or whatever then tries to display on the current frame which is
the file dialog - which has disappeared, so it picks one at random.

Not having looked at the code I can't really verify this, but
wondered whether the theory made any sense?

andy

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 10:16:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA14834 for xemacs-beta-people; Mon, 17 Jun 1996 10:16:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA14831 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 10:16:43 -0500 (CDT)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA01787 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 10:16:37 -0500 (CDT)
Received: from eistla.ifi.uio.no (4867@eistla.ifi.uio.no [129.240.94.29]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <RAA23338@ifi.uio.no> ; Mon, 17 Jun 1996 17:16:26 +0200
Received: (from larsi@localhost) by eistla.ifi.uio.no ; Mon, 17 Jun 1996 17:16:24 +0200
To: turner@xdiv.lanl.gov (John Turner)
Cc: xemacs-beta@xemacs.org
Subject: Re: GNUS crash
References: <199606100538.XAA20844@gielgud.lanl.gov.xdiv>
In-Reply-To: turner@xdiv.lanl.gov's message of Sun, 9 Jun 1996 23:38:27 -0600
Lines: 25
X-Mailer: Gnus v5.2.20/Emacs 19.29
Date: 17 Jun 1996 17:06:24 +0200
Message-ID: <x6wx16cvwu.fsf@eyesore.no>
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>

turner@xdiv.lanl.gov (John Turner) writes:

> - In GNUS, reading article, I a ?, substring and regexp string show
>   up twice.

Yup.  Fix in Gnus v5.2.20.

>   I saw this first on a tty.  When I tried under X, it was reproduced,
>   but also showed something else.  The buffer created by the ? is
>   slightly too small, so the scrollbar shows that there is stuff
>   above the visual portion.

The help function does a `(shrink-window-if-larger-than-buffer)' as
the last thing.  Does that function produce odd results?

>   Trying to use the scrollbar, however, results in
> 
>   Key read has no ASCII equivalent #<misc-user-event (scrollbar-vertical-drag (#<window on "*Score Help*" 0x1b7d> . 90))>

`(setq debug-on-error t)', repeat the bug and mail me the backtrace.


From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 09:35:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA14694 for xemacs-beta-people; Mon, 17 Jun 1996 09:35:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA14691 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 09:35:23 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA07978 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 09:35:21 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Mon, 17 Jun 1996 16:24:23 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id QAA21992; Mon, 17 Jun 1996 16:23:52 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id QAA00511;
          Mon, 17 Jun 1996 16:22:20 +0200
Date: Mon, 17 Jun 1996 16:22:20 +0200
Message-Id: <199606171422.QAA00511@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de>
To: Ben Wing <wing@dimensionx.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: buffers menu improvements
In-Reply-To: <199606150810.AAA25969@mole.dimensionx.com>
References: <199606150810.AAA25969@mole.dimensionx.com>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q(\V9 
        +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy 
        ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x 
        zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B: 
        s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Ben" == Ben Wing <wing@dimensionx.com> writes:

    Ben> I actually started trying to use the buffers menu for the
    Ben> first time, and got annoyed that the default
    Ben> "most-recently-used" order makes it hard to quickly locate
    Ben> buffers by name.  So I decided to provide an option to do
    Ben> alphabetical sorting, and ended up doing a whole lot of
    Ben> improvements to the buffers menu, including providing a
    Ben> general framework for customizing it.  I'd like the beta
    Ben> list's input on this -- e.g. improvements in the form of
    Ben> different customizing functions, suggestions for the
    Ben> defaults, etc.  The new defaults are set currently to sort
    Ben> the buffers menu by major mode and then by name, and to group
    Ben> the buffers by major mode with separators between them.  If
    Ben> you set `buffers-menu-submenus-for-groups-p' to non-nil, then
    Ben> you will instead have one submenu per major mode group, with
    Ben> each submenu listing the buffers in that mode.

You should take also a look on the following code (2 files), which
I've written to customize the Buffer-menu-mode (not the menu
"Buffers"), because it has similar disadvantages as the buffers
menu. It provides the following features

;;;	An extension for the file buff-menu.el. The functions in this
;;;	file changes the displaying behavior of the function
;;;	list-buffers.  The default behavior is the same as without
;;;	this file. There are 3 variables to change it.
;;;
;;;	The variable `Buffer-menu-mouse-select-this-window' determines
;;;	in which window a mouse selected buffer will be displayed. If
;;;	it is set to t, then the current window (the one with the
;;;	buffer-menu) is used. Otherwise the whole screen is used.
;;;
;;;	The variable `Buffer-menu-in-the-current-window' determines in
;;;	which window the buffer menu will be displayed. If it is set
;;;	to t, then the window with an existing buffer menu or the
;;;	current window will be used. Otherwise the window with an
;;;	existing buffer menu or another window (this can also split
;;;	the screen) will be used.
;;;
;;;	The variable `Buffer-menu-in-alphabetic-order' determines, if
;;;	the buffers in the buffer menu will be sorted in historic or
;;;	in alphabetic order.
;;; 




---- Begin of hm-buffer-menu.el ----
;;; $Id: hm-buffer-menu.el,v 1.10 1996/04/10 21:13:40 muenkel Exp $
;;;
;;; Copyright (C) 1994, 1995, 1996 Heiko Muenkel
;;; email: muenkel@tnt.uni-hannover.de
;;;
;;;  This program is free software; you can redistribute it and/or modify
;;;  it under the terms of the GNU General Public License as published by
;;;  the Free Software Foundation; either version 2, or (at your option)
;;;  any later version.
;;;
;;;  This program is distributed in the hope that it will be useful,
;;;  but WITHOUT ANY WARRANTY; without even the implied warranty of
;;;  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;;  GNU General Public License for more details.
;;;
;;;  You should have received a copy of the GNU General Public License
;;;  along with this program; if not, write to the Free Software
;;;  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
;;;
;;; 
;;; Description:
;;;
;;;	An extension for the file buff-menu.el. The functions in this
;;;	file changes the displaying behavior of the function
;;;	list-buffers.  The default behavior is the same as without
;;;	this file. There are 3 variables to change it.
;;;
;;;	The variable `Buffer-menu-mouse-select-this-window' determines
;;;	in which window a mouse selected buffer will be displayed. If
;;;	it is set to t, then the current window (the one with the
;;;	buffer-menu) is used. Otherwise the whole screen is used.
;;;
;;;	The variable `Buffer-menu-in-the-current-window' determines in
;;;	which window the buffer menu will be displayed. If it is set
;;;	to t, then the window with an existing buffer menu or the
;;;	current window will be used. Otherwise the window with an
;;;	existing buffer menu or another window (this can also split
;;;	the screen) will be used.
;;;
;;;	The variable `Buffer-menu-in-alphabetic-order' determines, if
;;;	the buffers in the buffer menu will be sorted in historic or
;;;	in alphabetic order.
;;; 
;;; Installation: 
;;;   
;;;     Put this file in one of your lisp load directories (for example
;;;     lisp/packages)
;;;
;;;	Put the following command in your .emacs
;;;		(require 'hm-buffer-menu)
;;;		(setq Buffer-menu-in-the-current-window t)
;;;		(setq Buffer-menu-in-alphabetic-order t)
;;;		(setq Buffer-menu-mouse-select-this-window t)
;;;

(require 'buff-menu)

(defvar Buffer-menu-mouse-select-this-window nil
  "*Determines, where a buffer selected with the mouse will be displayed.
The current window is used, if this is t.")

(defvar Buffer-menu-in-the-current-window nil
  "*The buffer menu is displayed in the current window, if this is non-nil.
If there is already a window displaying a buffer menu, then that window
will be used regardless of the value of this variable.")

(defvar Buffer-menu-in-alphabetic-order nil
  "*The buffers are displayed in alphabetic order, if this is non-nil.")

(defun Buffer-menu-mouse-select-this-window (event)
  "Similar to 'Buffer-menu-mouse-select'. 
but selects the buffer in the current window."
  (interactive "e")
  (mouse-set-point event)
  (Buffer-menu-this-window))

(defun Buffer-menu-mouse-select-buffer (event)
  "Select buffer in the other or the current window.
That depends on the value of `Buffer-menu-mouse-select-in-this-window'."
  (interactive "e")
  (if Buffer-menu-mouse-select-this-window
      (Buffer-menu-mouse-select-this-window event)
    (Buffer-menu-mouse-select event)))

(define-key Buffer-menu-mode-map 
  'button2 
  'Buffer-menu-mouse-select-buffer)

(defmacro with-output-to-temp-buffer-in-window (arg1 &rest args)
  (let ((buffer (get-buffer arg1))
	(old-standard-output standard-output)
	(return-value nil))
    (if buffer
	(save-excursion
	  (set-buffer buffer)
	  (toggle-read-only)
	  (erase-buffer))
      (setq buffer (generate-new-buffer arg1)))
    (setq standard-output buffer)
    (setq return-value (eval (cons 'progn args)))
    (setq standard-output old-standard-output)
    (if (get-buffer-window buffer)
	(pop-to-buffer buffer)
      (let ((old-pop-up-windows pop-up-windows))
					;    (display-buffer buffer)
					;    (set-buffer buffer)
					;    (pop-to-buffer buffer nil)
	(setq pop-up-windows nil)
	(switch-to-buffer buffer t)
	(setq pop-up-windows old-pop-up-windows)))
    (goto-char (point-min))
    (forward-line 2)
    return-value))


(defun list-buffers-internal (output &optional predicate)
  (let ((current (current-buffer))
        (buffers (if Buffer-menu-in-alphabetic-order
		     (sort (buffer-list) 
			   '(lambda (buffer1 buffer2)
			      (string< (buffer-name buffer1) 
				       (buffer-name buffer2))))
		   (buffer-list))))
    (save-excursion
      (set-buffer output)
      (setq buffer-read-only nil)
      (erase-buffer)
      (buffer-disable-undo output)
      (insert list-buffers-header-line)

      (while buffers
        (let* ((col1 19)
               (buffer (car buffers))
               (name (buffer-name buffer))
	       this-buffer-line-start)
          (setq buffers (cdr buffers))
          (cond ((null name))           ;deleted buffer
                ((and predicate
                      (not (if (stringp predicate)
                               (string-match predicate name)
                               (funcall predicate buffer))))
                 nil)
                (t
                 (set-buffer buffer)
                 (let ((ro buffer-read-only)
                       (id list-buffers-identification))
                   (set-buffer output)
		   (setq this-buffer-line-start (point))
                   (insert (if (eq buffer current)
                               (progn (setq current (point)) ?\.)
                               ?\ ))
                   (insert (if (buffer-modified-p buffer)
                               ?\* 
                               ?\ ))
                   (insert (if ro
                               ?\%
                               ?\ ))
                   (if (string-match "[\n\"\\ \t]" name)
                       (let ((print-escape-newlines t))
                         (prin1 name output))
                       (insert ?\  name))
                   (indent-to col1 1)
                   (cond ((stringp id)
                          (insert id))
                         (id
                          (set-buffer buffer)
                          (condition-case e
                              (funcall id output)
                            (error
                             (princ "***" output) (prin1 e output)))
                          (set-buffer output)
                          (goto-char (point-max)))))
		 (put-nonduplicable-text-property this-buffer-line-start
						  (point)
						  'buffer-name name)
		 (put-nonduplicable-text-property this-buffer-line-start
						  (point)
						  'highlight t)
                 (insert ?\n)))))

      (Buffer-menu-mode)
      (if (not (bufferp current))
          (goto-char current)))))

(defun list-buffers (&optional files-only)
  "Display a list of names of existing buffers.
Inserts it in buffer *Buffer List* and displays that.
Note that buffers with names starting with spaces are omitted.
Non-null optional arg FILES-ONLY means mention only file buffers.

The M column contains a * for buffers that are modified.
The R column contains a % for buffers that are read-only."
  (interactive (list (if current-prefix-arg t nil)))
  (let ((with-output-to-temp-buffer-macro
	 (if Buffer-menu-in-the-current-window
	    'with-output-to-temp-buffer-in-window
	   'with-output-to-temp-buffer)))
    (eval 
     (list with-output-to-temp-buffer-macro "*Buffer List*"
	   '(save-excursion
	      (list-buffers-internal standard-output
				     (if (memq files-only '(t nil))
					 #'(lambda (b)
					     (let ((n (buffer-name b)))
					       (cond ((and (/= 0 (length n))
							   (= (aref n 0) ?\ ))
						      ;;don't mention if 
						      ;;starts with " "
						      nil)
						     (files-only
						      (buffer-file-name b))
						     (t
						      t))))
				       files-only)))))
    ))

(provide 'hm-buffer-menu)

---- End of hm-buffer-menu.el ----
---- Begin of hm-buffer-menu-options.el ----
;;; $Id: hm-buffer-menu-options.el,v 1.4 1996/03/02 16:36:18 muenkel Exp $
;;;
;;; Copyright (C) 1994, 1995, 1996 Heiko Muenkel
;;; email: muenkel@tnt.uni-hannover.de
;;;
;;;  This program is free software; you can redistribute it and/or modify
;;;  it under the terms of the GNU General Public License as published by
;;;  the Free Software Foundation; either version 2, or (at your option)
;;;  any later version.
;;;
;;;  This program is distributed in the hope that it will be useful,
;;;  but WITHOUT ANY WARRANTY; without even the implied warranty of
;;;  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;;  GNU General Public License for more details.
;;;
;;;  You should have received a copy of the GNU General Public License
;;;  along with this program; if not, write to the Free Software
;;;  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
;;;
;;; 
;;; Description:
;;;
;;;	This file installs an Options submenu to toggle and save the
;;;	options for the Buffer Menu mode. It is only useful in the
;;;	XEmacs version 19.14 or higher.
;;; 
;;;	It needs also the following file:
;;;		hm-buffer-menu.el
;;;
;;; Installation: 
;;;   
;;;	Put this file in one of your load path directories and the
;;;	following in your ~/.emacs:
;;;		(require 'hm-buffer-menu-options)
;;;

(require 'hm-buffer-menu)

(add-submenu '("Options")
	     '("Buffer Menu"
	       ["Alphabetic Order" 
		(setq Buffer-menu-in-alphabetic-order 
		      (not Buffer-menu-in-alphabetic-order))
		:style toggle
		:selected Buffer-menu-in-alphabetic-order
		]
	       ["Menu In Current Window"
		(setq Buffer-menu-in-the-current-window
		      (not Buffer-menu-in-the-current-window))
		:style toggle
		:selected Buffer-menu-in-the-current-window
		]
	       ["Mouse Select This Window"
		(setq Buffer-menu-mouse-select-this-window
		      (not Buffer-menu-mouse-select-this-window))
		:style toggle
		:selected Buffer-menu-mouse-select-this-window
		]
	       )
	     "Frame Appearance"
	     )

(if (not (memq 'Buffer-menu-mouse-select-this-window options-menu-saved-forms))
    (setq options-menu-saved-forms
	  (purecopy
	   (append
	    options-menu-saved-forms
	    '(Buffer-menu-mouse-select-this-window
	      Buffer-menu-in-the-current-window
	      Buffer-menu-in-alphabetic-order)))))

(provide 'hm-buffer-menu-options)

---- End of hm-buffer-menu-options.el ----

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 11:12:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA15287 for xemacs-beta-people; Mon, 17 Jun 1996 11:12:59 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA15284 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 11:12:58 -0500 (CDT)
Received: from ns1.eds.com (ns1.eds.com [192.85.154.78]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA11670 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 11:12:59 -0500 (CDT)
Received: by ns1.eds.com (hello)
	id MAA21303; Mon, 17 Jun 1996 12:12:58 -0400
Received: from kocrsw12.delcoelect.com (kocrsw12.delcoelect.com [144.250.106.18]) by kocrsv04.delcoelect.com (8.7.5/8.7.3) with SMTP id LAA27655 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 11:12:57 -0500 (EST)
Received: from kocrsw12 by kocrsw12.delcoelect.com (SMI-8.6/SMI-SVR4)
	id LAA03831; Mon, 17 Jun 1996 11:12:56 -0500
X-Mailer: exmh version 1.6.6 3/24/96
To: xemacs-beta@cs.uiuc.edu
Subject: b25 build report on sun solaris 2.4
X-Face: 4tk3bJx]I+QTZ|=]*1+Z){9+;5u_hK*NBeZK6[+B+iB%bVuOJ%^uK~fIG}O-}%WLX*D^aW>
 Gv8E3Xtz0\N&fQl^:pj<K{xM`:d>pPt:9lF-YXB%O)?@rd?*/jE!s94`?]:jJ#C5RDP:;Mr.3lwo`0
 {vIT+<{%IRwe]vLd]7>\X|*z{TUX_t;?TPcOLBMIv8_V92!Vk(*DJVU~0M[`5D^PAWLniO1?YYWArM
 U*j9o+>?1MWi.lO?F-?aVt:qQ8OaG?R}B:I!7S_+KuzxZ.f9M@$z#n\bG2$Q2{od
Date: Mon, 17 Jun 1996 11:12:56 -0500
Message-ID: <3829.835027976@kocrsw12>
From: Mike Scheidler <c23mts@eng.delcoelect.com>

I ftp'd in to the beta site this morning and watched as Chuck's upload of
b25 was finishing.  It built with no problems and seems to run fine.

./configure --prefix=/usr/std --with-xpm --site-includes=/usr/std/include
  --site-libraries=/usr/std/lib --with-sound=native
  --native-sound-lib=/usr/std/lib/libaudio.a --with-dialogs=athena
  --with-xface=yes --srcdir=/users/c23mts/xemacs-19.14
  --site-runtime-libraries=/usr/std/lib --dynamic --cflags=-O
  --error-checking=none

--
Mike Scheidler                     INTERNET:  c23mts@eng.delcoelect.com
Software Development Tools         UUCP:      deaes!c23mts
Delco Electronics Corporation      PHONE:     (317) 451-0319
Kokomo, IN 46904-9005              GMNET:     8-322-0319





From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 11:28:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA15344 for xemacs-beta-people; Mon, 17 Jun 1996 11:28:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA15341 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 11:28:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA08238 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 11:28:31 -0500 (CDT)
Message-Id: <199606171628.LAA08238@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.14 beta25
Date: Mon, 17 Jun 1996 11:28:27 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/beta/xemacs-19.14.  Next release is
pre-release 1 out Wednesday, June 19.  It will come out late morning,
early afternoon.  Final release will be available to beta testers by
the end of Thursday.



			-Chuck


-- w3 2.3.67
-- url 1.0.34
-- ediff 2.61
-- vm 5.96
-- viper 2.89
-- gnus 5.2.19
-- browse-url 0.36
-- corrected modeline overwriting being triggered by using ispell
-- fixed crash in tty-mode with edit-faces (again)
-- infinite loop when using surrogate minibuffer fixed
-- corrected handling of buffer arg to call-process
-- SCO 5 patches from J. Kean Johnston
-- patch from Bill Perry to eliminate using temporary files when
   handling PNG files
-- Sunsoft-provided CDE-friendly icon now default XEmacs icon.
-- apropos.el sync'ed with FSF Emacs 19.31 - Fixes the
   `Nothing to follow here' problem.
-- set-process-filter no longer crashes if the process is dead.
-- x-compose.el now works again on Solaris.
-- New function x-keysym-on-keyboard-p helps determine keyboard
   characteristics for key rebinding:

  x-keysym-on-keyboard-p: (KEYSYM &optional DEVICE)
    -- a built-in function.
  Return true if KEYSYM names a key on the keyboard of DEVICE.
  More precisely, return true if pressing a physical key
  on the keyboard of DEVICE without any modifier keys generates KEYSYM.
  Valid keysyms are listed in the files /usr/include/X11/keysymdef.h and in
  /usr/lib/X11/XKeysymDB, or whatever the equivalents are on your system.

-- Sun key rebinding changed yet again to use function-key-map.
   Type 4 keyboards have r35 mapped to `next'.
   Type 5 keyboards already have `next', so map r35 to `kp_next'.
-- (Mule) Some menubar items will be translated by default in a
   Japanese locale.
-- Sun key rebinding changed again to use function-key-map.
-- inheritance loops in face property specifications no longer cause
   XEmacs to crash.
-- minibuffer-setup-hook no longer clobbered by read-file-name.
-- extra icons in Info mode removed.
-- XEmacs info top level sub-headers synched up with lower-level headers.
-- gnuclient prompts you with a dialog box when asking questions.
-- the yes/no dialog box now has sane options: yes, no, yes all, no all,
   and cancel.
-- make-face-bold, make-face-italic, et al. do a better job than before --
   they know about inheritors like [bold] and [italic], and will use
   one if their normal X frobbing isn't successful.
-- better handling of bad menu filter functions.
-- buffers-menu improvements.
-- query-replace now disables case-folding if uppercase letters are
   in the search string, like isearch does. (To turn both of these off,
   set `search-caps-disable-folding' to non-nil.)
-- C-h ? ? works.
-- Chuck -- you need to re-byte-compile finder.el to fix C-h p under 20.0.
   It wouldn't hurt to recompile everything.
-- weird bug with markers and standard-output fixed.
-- save-options now saves to a file `.xemacs-options' instead of directly
   to .emacs.  .emacs is set to load .xemacs-options.  The file is
   loaded with `load-options-file', which will allow eventually for
   automatic updating of out-of-date options files.
-- Pretty-much everything in that spawn-of-hell file terminfo.c
   is commented out now for most systems, since we didn't actually
   need any of it!

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 11:39:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA15369 for xemacs-beta-people; Mon, 17 Jun 1996 11:39:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA15366 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 11:39:25 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA10197 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 11:39:21 -0500 (CDT)
Message-Id: <199606171639.LAA10197@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 20.0 beta25
Date: Mon, 17 Jun 1996 11:39:19 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/beta/xemacs-20.0.  Next release is
pre-release 1 out Wednesday, June 19.


			-Chuck


-- w3 2.3.67
-- url 1.0.34
-- ediff 2.61
-- vm 5.96
-- viper 2.89
-- gnus 5.2.19
-- browse-url 0.36
-- corrected modeline overwriting being triggered by using ispell
-- fixed crash in tty-mode with edit-faces (again)
-- infinite loop when using surrogate minibuffer fixed
-- corrected handling of buffer arg to call-process
-- SCO 5 patches from J. Kean Johnston
-- patch from Bill Perry to eliminate using temporary files when
   handling PNG files
-- Sunsoft-provided CDE-friendly icon now default XEmacs icon.
-- canna support integrated (Thanks to Moroika Tomohiko).
-- apropos.el sync'ed with FSF Emacs 19.31 - Fixes the
   `Nothing to follow here' problem.
-- set-process-filter no longer crashes if the process is dead.
-- x-compose.el now works again on Solaris.
-- New function x-keysym-on-keyboard-p helps determine keyboard
   characteristics for key rebinding:

  x-keysym-on-keyboard-p: (KEYSYM &optional DEVICE)
    -- a built-in function.
  Return true if KEYSYM names a key on the keyboard of DEVICE.
  More precisely, return true if pressing a physical key
  on the keyboard of DEVICE without any modifier keys generates KEYSYM.
  Valid keysyms are listed in the files /usr/include/X11/keysymdef.h and in
  /usr/lib/X11/XKeysymDB, or whatever the equivalents are on your system.

-- Sun key rebinding changed yet again to use function-key-map.
   Type 4 keyboards have r35 mapped to `next'.
   Type 5 keyboards already have `next', so map r35 to `kp_next'.
-- (Mule) Some menubar items will be translated by default in a
   Japanese locale.
-- Sun key rebinding changed again to use function-key-map.
-- inheritance loops in face property specifications no longer cause
   XEmacs to crash.
-- minibuffer-setup-hook no longer clobbered by read-file-name.
-- extra icons in Info mode removed.
-- XEmacs info top level sub-headers synched up with lower-level headers.
-- gnuclient prompts you with a dialog box when asking questions.
-- the yes/no dialog box now has sane options: yes, no, yes all, no all,
   and cancel.
-- make-face-bold, make-face-italic, et al. do a better job than before --
   they know about inheritors like [bold] and [italic], and will use
   one if their normal X frobbing isn't successful.
-- better handling of bad menu filter functions.
-- buffers-menu improvements.
-- query-replace now disables case-folding if uppercase letters are
   in the search string, like isearch does. (To turn both of these off,
   set `search-caps-disable-folding' to non-nil.)
-- C-h ? ? works.
-- Chuck -- you need to re-byte-compile finder.el to fix C-h p under 20.0.
   It wouldn't hurt to recompile everything.
-- weird bug with markers and standard-output fixed.
-- save-options now saves to a file `.xemacs-options' instead of directly
   to .emacs.  .emacs is set to load .xemacs-options.  The file is
   loaded with `load-options-file', which will allow eventually for
   automatic updating of out-of-date options files.
-- Pretty-much everything in that spawn-of-hell file terminfo.c
   is commented out now for most systems, since we didn't actually
   need any of it!

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 11:56:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA15452 for xemacs-beta-people; Mon, 17 Jun 1996 11:56:58 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA15449 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 11:56:57 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA13973 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 11:56:57 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.6.12/8.6.9) with ESMTP id LAA03952 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 11:56:38 -0500
Message-Id: <199606171656.LAA03952@nvwls.cc.purdue.edu>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Toolbar thought grenade 
In-reply-to: Your message of "Fri, 14 Jun 1996 08:37:01 +0100."
             <199606140737.IAA12072@wrath.parallax.co.uk> 
Date: Mon, 17 Jun 1996 11:56:34 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


>>>>> "Andy" == Andy Piper <andyp@parallax.co.uk> writes:

    Andy> In a similar vein I was planning to try and add
    Andy> drag-and-drop support (using CDE) to and from toolbar
    Andy> buttons so that you could, for instance, drag the file icon
    Andy> so that the current buffer was loaded into the drop target,
    Andy> or drag a file onto the debugger button to start debugging
    Andy> it.

Yet another thought grenade... drag and drop events added to keymaps?

++------------------------------------------------------------------++
|| Joseph J. Nuspl Jr. :: Usenet :: X.500 :: Anon ftp :: OED :: PDN ||
|| "I'm a people person", the Cannibal from the 26-May-1996 Dilbert ||
++------------------------------------------------------------------++

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 13:32:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA15814 for xemacs-beta-people; Mon, 17 Jun 1996 13:32:24 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA15811 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 13:32:23 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA18064 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 13:32:19 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA27707; Mon, 17 Jun 1996 13:32:14 -0500 (CDT)
Message-Id: <199606171832.NAA27707@charles.cs.uiuc.edu>
To: Dan Rich <drich@cisco.com>
cc: xemacs-beta@xemacs.org
Subject: Re: 19.14b25 crashes on SunOS 4.1.3 
In-reply-to: Your message of "Mon, 17 Jun 1996 11:26:35 PDT."
             <199606171826.LAA23875@sandman.cisco.com> 
Date: Mon, 17 Jun 1996 13:32:14 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

C backtrace, C backtrace, C backtrace, C backtrace

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 13:25:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA15778 for xemacs-beta-people; Mon, 17 Jun 1996 13:25:11 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA15775 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 13:25:10 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA17982 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 13:25:05 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id LAA23875; Mon, 17 Jun 1996 11:26:35 -0700
Date: Mon, 17 Jun 1996 11:26:35 -0700
Message-Id: <199606171826.LAA23875@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: xemacs-beta@xemacs.org
Subject: 19.14b25 crashes on SunOS 4.1.3

I just built 19.14b25 for SunOS 4.1.3_U1, and I am seeing crashes
every time I try and exit with C-x C-c.  Any ideas from the info below?

Here's the config:
	./configure  --site-libraries=/local/lib
	--site-includes=/local/include --with-xpm --with-xface
	--with-sound=native --with-gif --with-jpeg --with-png
	--prefix=/local/beta --dynamic

And the lisp backtrace of the crash:
Lisp backtrace follows:

  last-nonminibuf-frame()
  # bind (window old-frame target-frame explicit-frame)
  byte-code("  !\"
                      

#
\"!)  
              \n=

                    != !\"
                                 !!\"! !\"@;!\":@;@!\"! !\")AA)    \n\"
                   
                     =
                           !\"\"!#\!\"!#\"\A\"\")$@;!\"\!\":@;@!\"\A\"\")A9) & !
                           \"
                                !\"(\n
                                       = \"= !! \"= ./\\W/\\.01\\W1\\0\n  \"!!!\n!
                                     
                                         !\"
                                                !.Y
                                                     !0Y
                                                          !
                                                             !
                                                                !<=>\n!
                                                                             !\"
   =@
       !
          !/\\Y
                 !
                  !!!& !A
                                    !A
                                       !<>
                                          =B
                                            !B
                                               !<=
                                                  ><C<!A@C
                                                            !A@UD<!D
                                                                      !VE<!
                                                                              !\\F>!Z>#+\n!
                 ! GHI
                        !J
                           !!+
                              \"
                                 !," [nil explicit-frame target-frame old-frame window last-nonminibuf-frame selected-frame get-buffer buffer bufferp wrong-type-argument pre-display-buffer-function not-this-window-p override-frame display-buffer-function throw done buffer-dedicated-frame dedi frame-live-p window-buffer selected-window display-buffer-1 buffer-name same-window-buffer-names assoc switch-to-buffer same-window-regexps tem car string-match pop-up-frames 0 get-buffer-window special-display-function special-display-buffer-names special-display-regexps frame-selected-window pop-up-frame-function set-window-buffer pop-up-windows frame-property minibuffer only window-dedicated-p frame-root-window split-height-threshold window-min-height split-width-threshold window-min-width unsplittable get-largest-window visible t window-frame window-height window-width window-leftmost-p window-rightmost-p split-window other lower upper get-lru-window window-parent window-previous-ch!
 ild window-next-child window-pixel-edges window-pixel-height enlarge-window 2 save-selected-window-window ((byte-code "   !    !" ... 2)) select-window record-buffer] 7)
  # (catch done ...)
  # bind (override-frame not-this-window-p buffer)
  display-buffer(#<buffer "*Warnings*">)
  # bind (buffer)
  display-warning-buffer()
  # (condition-case ... . error)
  # bind (inhibit-quit)
  # (condition-case ... . error)
  # (catch top-level ...)
Abort (core dumped)


And from gdb:
drich@sandman|749> gdb src/xemacs core 
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.15.1 (sparc-sun-sunos4.1), 
Copyright 1995 Free Software Foundation, Inc...
Core was generated by `xemacs'.
Program terminated with signal 6, Abort.
Reading symbols from /usr/local/X11R6/lib/libXaw.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libXpm.so.4.3...done.
Reading symbols from /usr/local/X11R6/lib/libXmu.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libXt.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libSM.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libICE.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libXext.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libX11.so.6.1...done.
Reading symbols from /usr/lib/libc.so.1.9.8...done.
Reading symbols from /usr/lib/libdl.so.1.0...done.
#0  0xef5ef138 in kill ()
(gdb) where
#0  0xef5ef138 in kill ()
#1  0x4c7c0 in fatal_error_signal (sig=6) at emacs.c:193
#2  <signal handler called>
#3  0xef5ef138 in kill ()
#4  0x4e67c in assert_failed (file=0xaadf0 "frame.c", line=806, 
    expr=0xad9c8 "RECORD_TYPEP (console, lrecord_device) || MARKED_RECORD_P (console)") at emacs.c:1787
#5  0xadaa0 in Flast_nonminibuf_frame (console=272632704) at frame.c:806
#6  0x54fc4 in primitive_funcall (fn=0xada0c <Flast_nonminibuf_frame>, 
    nargs=1, args=0xefffe478) at eval.c:3484
#7  0x55148 in funcall_subr (subr=0x24ba70, args=0xefffe478) at eval.c:3526
#8  0x54448 in funcall_recording_as (recorded_as=270842480, nargs=0, 
    args=0xefffe580) at eval.c:3204
#9  0x5459c in Ffuncall (nargs=1, args=0xefffe580) at eval.c:3253
#10 0x1c120 in Fbyte_code (bytestr=808146392, vector=1076582680, 
    maxdepth=2840046) at bytecode.c:450
#11 0x54ff0 in primitive_funcall (fn=0x1b9f8 <Fbyte_code>, nargs=3, 
    args=0xefffe800) at eval.c:3488
#12 0x55148 in funcall_subr (subr=0x2475a0, args=0xefffe800) at eval.c:3526
#13 0x53fb8 in Feval (form=539710920) at eval.c:3064
#14 0x50f94 in internal_catch (tag=272147108, func=0x5376c <Feval>, 
    arg=539710920, threw=0x0) at eval.c:1347
#15 0x1c588 in Fbyte_code (bytestr=808146280, vector=1076581804, 
    maxdepth=2839929) at bytecode.c:645
#16 0x5562c in funcall_lambda (fun=271276704, nargs=1, arg_vector=0xefffec70)
    at eval.c:3636
#17 0x54538 in funcall_recording_as (recorded_as=271276704, nargs=1, 
    args=0xefffec6c) at eval.c:3223
#18 0x5459c in Ffuncall (nargs=2, args=0xefffec6c) at eval.c:3253
#19 0x1c120 in Fbyte_code (bytestr=807925484, vector=1076360992, 
    maxdepth=2619154) at bytecode.c:450
#20 0x5562c in funcall_lambda (fun=271054692, nargs=0, arg_vector=0xefffef60)
    at eval.c:3636
#21 0x54538 in funcall_recording_as (recorded_as=271054692, nargs=0, 
    args=0xefffef5c) at eval.c:3223
#22 0x5459c in Ffuncall (nargs=1, args=0xefffef5c) at eval.c:3253
#23 0x56064 in call0 (fn=271853620) at eval.c:3979
#24 0x5715c in catch_them_squirmers_call0 (function=271853620) at eval.c:4496
#25 0x514ac in condition_case_1 (handlers=271745124, 
---Type <return> to continue, or q <return> to quit---
    bfun=0x57150 <catch_them_squirmers_call0>, barg=271853620, 
    hfun=0x56770 <caught_a_squirmer>, harg=271745028) at eval.c:1672
#26 0x572fc in call0_trapping_errors (warning_string=0x0, function=271853620)
    at eval.c:4520
#27 0x1150b8 in redisplay () at redisplay.c:5599
#28 0x68f0c in Fnext_event (event=273832404, prompt=271745028)
    at event-stream.c:2030
#29 0x25fa4 in Fcommand_loop_1 () at cmdloop.c:533
#30 0x25bf4 in command_loop_1 (dummy=271745028) at cmdloop.c:462
#31 0x514ac in condition_case_1 (handlers=271745124, 
    bfun=0x25b50 <command_loop_1>, barg=271745028, hfun=0x24c98 <cmd_error>, 
    harg=271745028) at eval.c:1672
#32 0x24dc8 in command_loop_3 () at cmdloop.c:224
#33 0x24df0 in command_loop_2 (dummy=271745028) at cmdloop.c:235
#34 0x50f94 in internal_catch (tag=271822244, func=0x24de4 <command_loop_2>, 
    arg=271745028, threw=0x0) at eval.c:1347
#35 0x25284 in initial_command_loop (load_me=151012) at cmdloop.c:#36 0x4d844 in main_1 (argc=1, argv=0xeffff70c, envp=0xeffff714)
    at emacs.c:1317
#37 0x4dcd0 in main (argc=1, argv=0xeffff70c, envp=0xeffff714) at emacs.c:1439
(gdb) 


From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 13:55:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA15958 for xemacs-beta-people; Mon, 17 Jun 1996 13:55:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA15955 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 13:55:36 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA19537 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 13:55:29 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id MAA28370; Mon, 17 Jun 1996 12:55:23 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id MAA06877; Mon, 17 Jun 1996 12:55:14 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id MAA01990; Mon, 17 Jun 1996 12:54:52 -0600
Date: Mon, 17 Jun 1996 12:54:52 -0600
Message-Id: <199606171854.MAA01990@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: 19.15b25 build success, VM problem
Reply-To: turner@lanl.gov

19.14b25, Solaris 2.5, CDE 1.0.1, SunPro C 4.0
Motif dialogs, Lucid scrollbars & menus

---

Got entire dist, did gmake all-elc.

Built fine, but VM produces:

Signalling: (invalid-function (macro . #<compiled-function (from "vm-misc.elc") nil "...(2)" [(and vm-mail-buffer (or (buffer-name vm-mail-buffer) (error "Folder buffer has been killed.")) (set-buffer vm-mail-buffer))] 1>))
  vm-select-folder-buffer()
  #<compiled-function (from "vm-startup.elc") (folder &optional read-only) "...(29)" [vm-session-initialization vm-select-folder-buffer vm-check-for-killed-summary folder vm-last-visit-folder vm-folder-directory default-directory expand-file-name vm read-only] 3 "Visit a mail file.\nVM will parse and present its messages to you in the usual way.\n\nFirst arg FOLDER specifies the mail file to visit.  When this\ncommand is called interactively the file name is read from the\nminibuffer.\n\nPrefix arg or optional second arg READ-ONLY non-nil indicates\nthat the folder should be considered read only.  No attribute\nchanges, messages additions or deletions will be allowed in the\nvisited folder." (save-excursion (vm-session-initialization) (vm-select-folder-buffer) (let ... ...))>("/home/turner/Mail/News/vm" nil)
  call-interactively(vm-toolbar-visit-command)
  release-and-activate-toolbar-button(#<buttonup-event button1up>)
  call-interactively(release-and-activate-toolbar-button)

In this particular case I had clicked on Visit on the toolbar, the new
frame had popped up, I had moved around some in the directory tree,
and this happened when I finally clicked on the desired folder.

Got something similar when I tried Compose from the toolbar or m from
the keyboard.

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 14:31:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA16140 for xemacs-beta-people; Mon, 17 Jun 1996 14:31:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA16137 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 14:31:41 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA23078 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 14:31:38 -0500 (CDT)
Message-Id: <199606171931.OAA23078@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.14 beta25 Solaris binary kit
Date: Mon, 17 Jun 1996 14:31:35 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now available at ftp.xemacs.org:/pub/beta/xemacs-19.14



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 14:31:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA16133 for xemacs-beta-people; Mon, 17 Jun 1996 14:31:23 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA16130 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 14:31:22 -0500 (CDT)
Received: from pat.idt.unit.no (pat.idt.unit.no [129.241.103.5]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA20328 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 14:31:22 -0500 (CDT)
Received: from ynde.idt.unit.no (1466@ynde.idt.unit.no [129.241.200.28]) by pat.idt.unit.no (8.6.12/8.6.12) with ESMTP id VAA01541 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 21:31:01 +0200
Received: (palat@localhost) by ynde.idt.unit.no (8.6.12/8.6.12) id VAA28586; Mon, 17 Jun 1996 21:30:57 +0200
To: xemacs-beta@cs.uiuc.edu
Subject: b25 compile problems with solaris2.4
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Sudeep Kumar Palat <palat@idt.unit.no>
Date: 17 Jun 1996 21:30:53 +0200
In-Reply-To: Chuck Thompson's message of Sat, 15 Jun 1996 10:25:06 -0500
Message-ID: <yv97mt6qlci.fsf@ynde.idt.unit.no>
Lines: 46


Attempts to compile b25 failed on solaris 2.4, gcc 2.7.2:

gcc -c -Demacs -DHAVE_CONFIG_H  -I.        -I/home/ynde/palat/Xemacs/xemacs-19.14-b25/src                  -I/home/ynde/palat/Bin  -I/store/include -I/usr/openwin/include/desktop         -I/usr/dt/include  -I/home/ynde/palat/Xemacs/xemacs-19.14-b25/src/../lwlib    -g -O  glyphs-x.c
glyphs-x.c:1880: parse error before `png_ptr'
glyphs-x.c: In function `png_read_from_memory':
glyphs-x.c:1885: `png_ptr' undeclared (first use this function)
glyphs-x.c:1885: (Each undeclared identifier is reported only once
glyphs-x.c:1885: for each function it appears in.)
glyphs-x.c:1887: `length' undeclared (first use this function)
glyphs-x.c:1889: `data' undeclared (first use this function)
make[1]: *** [glyphs-x.o] Error 1


Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /home/ynde/palat/Xemacs/xemacs-19.14-b25
  What installation prefix should install use?            ${srcdir}
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /store/include
  Where do we find X Windows libraries?                   /store/lib
  Additional header files:                                /home/ynde/palat/Bin
  Additional libraries:                                   /home/ynde/palat/Bin
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  (Using -lgz instead of -lz.)
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

sudeep

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 15:15:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA16436 for xemacs-beta-people; Mon, 17 Jun 1996 15:15:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA16433 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 15:15:48 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA24016 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 15:15:46 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id PAA16095 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 15:15:15 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id PAA01508 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 15:15:13 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id QAA05931 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 16:10:29 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: 19.14 b25 crash on Solaris 2.5
Date: Mon, 17 Jun 1996 16:10:28 -0400
Message-ID: <22798.835042228@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

Patched up from b24 for Solaris 2.5 using gcc 2.7.2, X11R6.1,
sound=both, jpeg, sparcworks, Lucid and Athena.

I get the same crash as Dan does.  C backtrace looks similar.  100%
repeatable.  Start with xemacs -q -no-site-file.  Do M-x mh-rmail,
then M-r (if you don't have any new mail).  Press "." to display any
mail message.  Boom.


The lisp backtrace looks just like Dan's. Here's my C backtrace:

#0  0xeebf3e30 in kill ()
#1  0x7bb88 in fatal_error_signal (sig=6) at /home/unix/toy/apps/xemacs-19.14/src/emacs.c:193
#2  <signal handler called>
#3  0xeebf3e30 in kill ()
#4  0x7d5b4 in assert_failed (file=0x1f5790 "/home/unix/toy/apps/xemacs-19.14/src/frame.c", 
    line=806, expr=0x1f5978 "RECORD_TYPEP (console, lrecord_device) || MARKED_RECORD_P (console)")
    at /home/unix/toy/apps/xemacs-19.14/src/emacs.c:1787
#5  0xd2c40 in Flast_nonminibuf_frame (console=272529280)
    at /home/unix/toy/apps/xemacs-19.14/src/frame.c:806
#6  0x83524 in primitive_funcall (fn=0xd2bac <Flast_nonminibuf_frame>, nargs=1, args=0xefffd1a8)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3484
#7  0x836a8 in funcall_subr (subr=0x23bdbc, args=0xefffd1a8)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3526
#8  0x82a08 in funcall_recording_as (recorded_as=270777788, nargs=0, args=0xefffd2c0)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3204
#9  0x82b50 in Ffuncall (nargs=1, args=0xefffd2c0)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3253
#10 0x54f44 in Fbyte_code (bytestr=808082128, vector=1076518416, maxdepth=2775782)
    at /home/unix/toy/apps/xemacs-19.14/src/bytecode.c:450
#11 0x83550 in primitive_funcall (fn=0x5481c <Fbyte_code>, nargs=3, args=0xefffd558)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3488
#12 0x836a8 in funcall_subr (subr=0x2379f0, args=0xefffd558)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3526
#13 0x82574 in Feval (form=539646656) at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3064
#14 0x7f72c in internal_catch (tag=272204500, func=0x81d24 <Feval>, arg=539646656, threw=0x0)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:1347
#15 0x553ac in Fbyte_code (bytestr=808082016, vector=1076517540, maxdepth=2775665)
    at /home/unix/toy/apps/xemacs-19.14/src/bytecode.c:645
#16 0x83b80 in funcall_lambda (fun=271212440, nargs=3, arg_vector=0xefffda14)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3636
#17 0x82af8 in funcall_recording_as (recorded_as=271212440, nargs=3, args=0xefffda10)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3223
#18 0x82b50 in Ffuncall (nargs=4, args=0xefffda10)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3253
#19 0x54f44 in Fbyte_code (bytestr=808065560, vector=1076501100, maxdepth=2759247)
    at /home/unix/toy/apps/xemacs-19.14/src/bytecode.c:450
#20 0x83b80 in funcall_lambda (fun=271194808, nargs=2, arg_vector=0xefffdccc)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3636
#21 0x82af8 in funcall_recording_as (recorded_as=271194808, nargs=2, args=0xefffdcc8)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3223
#22 0x82b50 in Ffuncall (nargs=3, args=0xefffdcc8)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3253
#23 0x54f44 in Fbyte_code (bytestr=808000988, vector=1076436516, maxdepth=2694638)
    at /home/unix/toy/apps/xemacs-19.14/src/bytecode.c:450
#24 0x83b80 in funcall_lambda (fun=271130168, nargs=1, arg_vector=0xefffdf7c)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3636
#25 0x82af8 in funcall_recording_as (recorded_as=271130168, nargs=1, args=0xefffdf78)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3223
#26 0x82b50 in Ffuncall (nargs=2, args=0xefffdf78)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3253
#27 0x54f44 in Fbyte_code (bytestr=809789888, vector=1079086848, maxdepth=4934449)
    at /home/unix/toy/apps/xemacs-19.14/src/bytecode.c:450
#28 0x83b80 in funcall_lambda (fun=273204068, nargs=1, arg_vector=0xefffe234)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3636
#29 0x82af8 in funcall_recording_as (recorded_as=273204068, nargs=1, args=0xefffe230)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3223
#30 0x82b50 in Ffuncall (nargs=2, args=0xefffe230)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3253
#31 0x54f44 in Fbyte_code (bytestr=809789744, vector=1079006592, maxdepth=4933843)
    at /home/unix/toy/apps/xemacs-19.14/src/bytecode.c:450
#32 0x83b80 in funcall_lambda (fun=273204036, nargs=0, arg_vector=0xefffe550)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3636
#33 0x82af8 in funcall_recording_as (recorded_as=273204036, nargs=0, args=0xefffe54c)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3223
#34 0x82b50 in Ffuncall (nargs=1, args=0xefffe54c)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3253
#35 0x844a8 in apply1 (fn=273204036, arg=271781892)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:3963
#36 0x57210 in Fcall_interactively (function=273548852, record_flag=271781892, keys=271781892)
    at /home/unix/toy/apps/xemacs-19.14/src/callint.c:389
#37 0x814bc in Fcommand_execute (cmd=273548852, record=271781892, keys=271781892)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:2628
#38 0x9a0e0 in execute_command_event (command_builder=0x375c80, event=273550708)
    at /home/unix/toy/apps/xemacs-19.14/src/event-stream.c:3474
#39 0x9b300 in Fdispatch_event (event=273550708)
    at /home/unix/toy/apps/xemacs-19.14/src/event-stream.c:3759
#40 0x5c968 in Fcommand_loop_1 () at /home/unix/toy/apps/xemacs-19.14/src/cmdloop.c:542
#41 0x5c5b8 in command_loop_1 (dummy=271781892)
    at /home/unix/toy/apps/xemacs-19.14/src/cmdloop.c:462
#42 0x7fc0c in condition_case_1 (handlers=271781988, bfun=0x5c514 <command_loop_1>, 
    barg=271781892, hfun=0x5b6b0 <cmd_error>, harg=271781892)
    at /home/unix/toy/apps/xemacs-19.14/src/eval.c:1672
#43 0x5b7b0 in command_loop_3 () at /home/unix/toy/apps/xemacs-19.14/src/cmdloop.c:224
#44 0x5b7d8 in command_loop_2 (dummy=271781892)
    at /home/unix/toy/apps/xemacs-19.14/src/cmdloop.c:235
#45 0x7f72c in internal_catch (tag=271859108, func=0x5b7cc <command_loop_2>, arg=271781892, 
    threw=0x0) at /home/unix/toy/apps/xemacs-19.14/src/eval.c:1347
#46 0x5bc6c in initial_command_loop (load_me=374732)
    at /home/unix/toy/apps/xemacs-19.14/src/cmdloop.c:273
#47 0x7cb38 in main_1 (argc=3, argv=0xefffed5c, envp=0x1eac00)
    at /home/unix/toy/apps/xemacs-19.14/src/emacs.c:1317
#48 0x7cf54 in main (argc=3, argv=0xefffed5c, envp=0xefffed6c)
    at /home/unix/toy/apps/xemacs-19.14/src/emacs.c:1439
(gdb) 

Ray

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 15:26:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA16527 for xemacs-beta-people; Mon, 17 Jun 1996 15:26:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA16524 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 15:26:50 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA24266 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 15:26:50 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id NAA29623; Mon, 17 Jun 1996 13:25:59 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: 20.0-b25 loses on Linux 2.0 w/ PNG
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Jun 1996 13:25:50 -0700
Message-ID: <m2lohmb2k1.fsf@deanna.miranova.com>
Lines: 70
X-Mailer: Gnus v5.2.19/XEmacs 20.0

The inline PNG stuff bombs at link:

glyphs-x.o: In function `png_read_from_memory':
/i/xemacs-20.0-b25/src/glyphs-x.c:1884: undefined reference to `png_get_io_ptr'
glyphs-x.o: In function `png_instantiate':
/i/xemacs-20.0-b25/src/glyphs-x.c:2044: undefined reference to `png_set_read_fn'
make[1]: *** [temacs] Error 1
make[1]: Leaving directory `/i/xemacs-20.0-b25/src'
make: *** [src] Error 2

After making this patch to get it to compile:

*** src/glyphs-x.c.orig	Sun Jun 16 12:37:13 1996
--- src/glyphs-x.c	Mon Jun 17 13:06:25 1996
***************
*** 1877,1883 ****
    int index;			/* Where are we?  */
  };
  
! static void png_read_from_memory(png_structp png_ptr, png_bytep data,
  				 png_uint_32 length)
  {
     png_uint_32 check;
--- 1877,1883 ----
    int index;			/* Where are we?  */
  };
  
! static void png_read_from_memory(png_struct *png_ptr, png_byte *data,
  				 png_uint_32 length)
  {
     png_uint_32 check;

I am using libgr-2.0.5 for PNG support, and haven't had problems with
this previously.  This was also from a full distribution, not patched up.


Configured for `i486-unknown-linux2.0.0'.

  Where should the build process find the source code?    /i/xemacs-20.0-b25
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  (Using -lgz instead of -lz.)
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 15:58:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA16614 for xemacs-beta-people; Mon, 17 Jun 1996 15:58:11 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA16611 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 15:58:10 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA26017 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 15:58:07 -0500 (CDT)
Message-Id: <199606172058.PAA26017@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: last-nonminibuf-frame patch
Date: Mon, 17 Jun 1996 15:58:07 -0500
From: Chuck Thompson <cthomp@xemacs.org>

Repeat after myself:  Never put in big patches right before a release
and not test them.


		-Chuck



*** /tmp/geta25985	Mon Jun 17 15:55:06 1996
--- frame.c	Mon Jun 17 15:54:57 1996
***************
*** 803,809 ****
  {
    Lisp_Object result;
  
!   XSETDEVICE (console, decode_console (console));
    /* Just in case the machinations in delete_frame_internal() resulted
       in the last-nonminibuf-frame getting out of sync, make sure and
       return the selected frame if it's acceptable. */
--- 803,809 ----
  {
    Lisp_Object result;
  
!   XSETCONSOLE (console, decode_console (console));
    /* Just in case the machinations in delete_frame_internal() resulted
       in the last-nonminibuf-frame getting out of sync, make sure and
       return the selected frame if it's acceptable. */

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 15:58:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA16609 for xemacs-beta-people; Mon, 17 Jun 1996 15:58:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA16606 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 15:58:04 -0500 (CDT)
Received: from big.aa.net (root@big.aa.net [204.157.220.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA26012 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 15:58:00 -0500 (CDT)
Received: from sym.primuscorp.com ([204.137.132.34]) by big.aa.net (8.6.12/8.6.9) with ESMTP id NAA30902 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 13:57:10 -0700
X-Intended-For: <xemacs-beta@xemacs.org>
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id NAA00653 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 13:58:03 -0700
Received: from pris by horus (SMI-8.6/SMI-SVR4)
	id NAA27651; Mon, 17 Jun 1996 13:57:26 -0700
Received: by pris (5.x/SMI-SVR4)
	id AA05955; Mon, 17 Jun 1996 13:57:34 -0700
Date: Mon, 17 Jun 1996 13:57:34 -0700
Message-Id: <9606172057.AA05955@pris>
From: Damon Lipparelli <lipp@primuscorp.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 19.14-b25: success under Solaris 2.4
Reply-To: Damon Lipparelli <lipp@primuscorp.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.14 (beta25) ]

./configure --verbose --with-gcc --cflags=-O4 --with-gnu-make --site-includes=/usr/local/include --site-libraries=/usr/local/sun4/lib --prefix=/users/lipp/xemacs-beta/19.x --exec-prefix=/users/lipp/xemacs-beta/19.x/sun4 --with-menubars=lucid --with-xpm --with-xface --with-jpeg --with-gif --with-png --with-tooltalk --with-sparcworks --with-sound=none --debug=no --error-checking=none

Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /users/lipp/src/xemacs-beta/19.x/xemacs-19.14-b25
  What installation prefix should install use?            /users/lipp/xemacs-beta/19.x
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/sun4/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in support for CDE.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.

First crack at a "production" build (fully optimized, no debug).

So far, looks great.
-lipp

---

I'm receiving a coded message from EUBIE BLAKE!!

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 16:06:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA16659 for xemacs-beta-people; Mon, 17 Jun 1996 16:06:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA16656 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 16:06:07 -0500 (CDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.80.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25026 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 16:06:07 -0500 (CDT)
Received: from deimos.sun (deimos [141.12.63.54]) by sonne.darmstadt.gmd.de (8.7.3/8.7.3) with SMTP id XAA11350 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 23:05:32 +0200 (MET DST)
Received: by deimos.sun (5.x/SMI-SVR4)
	id AA22234; Mon, 17 Jun 1996 23:01:24 +0200
Date: Mon, 17 Jun 1996 23:01:24 +0200
Message-Id: <9606172101.AA22234@deimos.sun>
From: rol@darmstadt.gmd.de (Roland Rieke)
To: xemacs-beta@cs.uiuc.edu
Subject: b25 crash on linux 2.0 and solaris 2.4
Content-Type: text


b25 patched up from b24 crashes with th following function:
------------------------------------------------------------
(defun pth-get-from-i-shell (command regexp)
   (let ((res ()))
     (save-window-excursion
       (with-output-to-temp-buffer "*Very very temporary*"
         (let ((buf (get-buffer "*Very very temporary*")))
           (call-process shell-file-name nil buf nil "-ic" command)
           (set-buffer buf)
           (goto-char 1)
           (while (re-search-forward regexp () t)
             (setq res (cons (buffer-substring (match-beginning 1) 
                                               (match-end 1))
                             res)))))
       (kill-buffer (current-buffer))
       (nreverse res))))

(defvar bash-shell-funcs
  (mapcar 'list (pth-get-from-i-shell "set" "^\\([^ =\t\n}]+\\)=()[^}]*}"))
  "List of subshell variable names")
-------------------------------------------------------------------
Backtrace on Linux (solaris 2.4 crashes in the same line of frame.c:

Fatal error: assertion failed, file frame.c, line 806, RECORD_TYPEP (console, lrecord_device) || MARKED_RECORD_P (console)

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb `which xemacs` core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  last-nonminibuf-frame()
  # bind (window old-frame target-frame explicit-frame)
  byte-code("  !!\"##\"!!)!\"	  \n= != !\"!!\"! !\"@;!\":@;@!\"! !\")AA)	 \n\" =!\"\"!#\"!\"!#\"\"A\"\")$@;!\"\"!\":@;@!\"\"A\"\")A9) & !\"!\"(\n= \"= !! \"= ./\\W/\\.01\\W1\\0\n  \"!!!\n!!\"!.Y!0Y!!!<=>\n!!\" =@
  # (catch done ...)
  # bind (override-frame not-this-window-p buffer)
  display-buffer(#<buffer "*Very very temporary*">)
  # bind (pre-display-buffer-function buffer)
  show-temp-buffer-in-current-frame(#<buffer "*Very very temporary*">)
  # bind (standard-output)
  (with-output-to-temp-buffer "*Very very temporary*" (let (...) (call-process shell-file-name nil buf nil "-ic" command) (set-buffer buf) (goto-char 1) (while ... ...)))
)
  # (unwind-protect ...)
  (save-window-excursion (with-output-to-temp-buffer "*Very very temporary*" (let ... ... ... ... ...)) (kill-buffer (current-buffer)) (nreverse res))
)
  # bind (res)
  (let ((res nil)) (save-window-excursion (with-output-to-temp-buffer "*Very very temporary*" ...) (kill-buffer ...) (nreverse res)))
)
  # bind (regexp command)
  pth-get-from-i-shell("set" "^\\([^ =	\n}]+\\)=()[^}]*}")
  (mapcar (quote list) (pth-get-from-i-shell "set" "^\\([^ =	\n}]+\\)=()[^}]*}"))
)
  (defvar bash-shell-funcs (mapcar (quote list) (pth-get-from-i-shell "set" "^\\([^ =	\n}]+\\)=()[^}]*}")) "List of subshell variable names")
)
  # bind (current-load-list standard-input load-file-name)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  load-internal("~/.emacs" t t t)
  # bind (nosuffix nomessage noerror file)
  load("~/.emacs" t t t)
  # bind (init-file-user)
  load-user-init-file("")
  byte-code("	!" [load-user-init-file init-file-user nil init-file-had-error] 2)
  # (condition-case ... . ((error (byte-code "!\"ć" ... 3))))
  # bind (debug-on-error debug-on-error-from-init-file debug-on-error-should-be-set debug-on-error-initial)
  load-init-file()
  # bind (command-line-args-left)
  command-line()
  # (unwind-protect ...)
  normal-top-level()
  # (condition-case ... . error)
  # (catch top-level ...)
IOT trap/Abort


From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 17:52:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA17117 for xemacs-beta-people; Mon, 17 Jun 1996 17:52:49 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA17114 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 17:52:47 -0500 (CDT)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA27135 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 17:52:43 -0500 (CDT)
Received: from drich-pc.cisco.com (dhcp-h21-207.cisco.com [171.68.192.207]) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id PAA19448; Mon, 17 Jun 1996 15:50:25 -0700
Message-Id: <2.2.32.19960617225216.006ca0bc@diablo.cisco.com>
X-Sender: drich@diablo.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 17 Jun 1996 15:52:16 -0700
To: Chuck Thompson <cthomp@cs.uiuc.edu>
From: Dan Rich <drich@cisco.com>
Subject: Re: 19.14b25 crashes on SunOS 4.1.3 
Cc: xemacs-beta@xemacs.org

At 01:32 PM 6/17/96 -0500, Chuck Thompson wrote:
>C backtrace, C backtrace, C backtrace, C backtrace

You mean the one that was right after the lisp backtrace?

Dan Rich <drich@cisco.com>    | http://reality.sgi.com/employees/drich/
Webmaster                     | "Danger, you haven't seen the last of me!"
Cisco Systems, Inc.           |   "No, but the first of you turns my stomach!"
(408) 527-3195                |           -- The Firesign Theatre's Nick Danger


From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 18:20:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA17302 for xemacs-beta-people; Mon, 17 Jun 1996 18:20:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA17299 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 18:20:57 -0500 (CDT)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA27173; Mon, 17 Jun 1996 18:20:52 -0500 (CDT)
Received: from drich-pc.cisco.com (dhcp-h21-207.cisco.com [171.68.192.207]) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id QAA25769; Mon, 17 Jun 1996 16:19:08 -0700
Message-Id: <2.2.32.19960617232058.006b134c@diablo.cisco.com>
X-Sender: drich@diablo.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 17 Jun 1996 16:20:58 -0700
To: Chuck Thompson <cthomp@xemacs.org>, xemacs-beta@xemacs.org
From: Dan Rich <drich@cisco.com>
Subject: Re: last-nonminibuf-frame patch

At 03:58 PM 6/17/96 -0500, Chuck Thompson wrote:
>Repeat after myself:  Never put in big patches right before a release
>and not test them.

This patch fixes the crash I reported earlier.

Dan Rich <drich@cisco.com>    | http://reality.sgi.com/employees/drich/
Webmaster                     | "Danger, you haven't seen the last of me!"
Cisco Systems, Inc.           |   "No, but the first of you turns my stomach!"
(408) 527-3195                |           -- The Firesign Theatre's Nick Danger


From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 20:21:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA17593 for xemacs-beta-people; Mon, 17 Jun 1996 20:21:01 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA17590 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 20:21:00 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA27315 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 20:20:54 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id KAA21161; Tue, 18 Jun 1996 10:19:00 +0900 (JST)
Message-Id: <199606180119.KAA21161@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: Martin Buchholz <mrb@eng.sun.com>
cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: XEmacs/Mule on SunOS 4 
In-reply-to: Your message of "Sun, 16 Jun 1996 12:56:37 MST."
             <199606161956.MAA16787@xemacs.eng.sun.com> 
Mime-Version: 1.0 (SEMI mime-edit 0.26)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 18 Jun 1996 10:18:55 JST
Sender: morioka@jaist.ac.jp

>>>>> In <199606161956.MAA16787@xemacs.eng.sun.com> 
>>>>>	Martin Buchholz <mrb@Eng.Sun.COM> wrote:

Martin> >>>>> "MT" == MORIOKA Tomohiko  writes:

MT>   In my environment (sparc-sun-sunos4shr, SUN OS 4.1.3_U1), when
MT> decode-coding-region or decode-coding-string are called, fatal
MT> error occurs and XEmacs is broken down. Following is backtrace:

Martin> I am rather surprised that any Japanese users are still using
Martin> SunOS 4. A lot of work has been done by Sun to
Martin> internationalize Solaris, and Solaris 2.5 seems to be a pretty
Martin> solid OS otherwise.

  A lot of people in my site love and believe BSD. :-) In my site, Sun
OS 4.1.3 and 4.1.4 are running on SUN workstations. (SUN workstations
bundle Solaris, however it is erased :-)) JLE (Japanese language
extensions) frequently occurs troubles so we usually use non-JLE
version. (We usually use I18N feature of X instead of OS)

  Recently, there are various kinds of applications for Solaris 2.5,
however SunOS 4 is better as historical compatibility for us.

Martin> I am also surprised that XEmacs/Mule works well on SunOS 4.

  I'm surprised. Does not XEmacs/mule support SunOS 4?

  I thins codes about streams don't work well, other features work
well.

  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 21:07:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA17725 for xemacs-beta-people; Mon, 17 Jun 1996 21:07:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA17722 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 21:06:59 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA27442 for <xemacs-beta@xemacs.org>; Mon, 17 Jun 1996 21:06:55 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id LAA23707; Tue, 18 Jun 1996 11:06:54 +0900 (JST)
Message-Id: <199606180206.LAA23707@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: [20.0 b25] crashed (Re: XEmacs/Mule on SunOS 4)
In-reply-to: Your message of "Tue, 18 Jun 1996 10:18:55 JST."
             <199606180119.KAA21161@mikan.jaist.ac.jp> 
Mime-Version: 1.0 (SEMI mime-edit 0.26)
Content-Type: multipart/mixed;
 boundary="Multipart_Tue_Jun_18_11:06:52_1996-1"
Content-Transfer-Encoding: 7bit
Date: Tue, 18 Jun 1996 11:06:54 JST
Sender: morioka@jaist.ac.jp

--Multipart_Tue_Jun_18_11:06:52_1996-1
Content-Type: text/plain; charset=US-ASCII

>>>>> In <199606161956.MAA16787@xemacs.eng.sun.com> 
>>>>>	Martin Buchholz <mrb@Eng.Sun.COM> wrote:

Martin> I am rather surprised that any Japanese users are still using
Martin> SunOS 4. A lot of work has been done by Sun to
Martin> internationalize Solaris, and Solaris 2.5 seems to be a pretty
Martin> solid OS otherwise.

  XEmacs 20.0 with mule become to crash in SunOS 4. :-<

  Lisp backtrace follows:


--Multipart_Tue_Jun_18_11:06:52_1996-1
Content-Type: text/plain; charset=ISO-2022-INT-1


  last-nonminibuf-frame()
  # bind (window old-frame target-frame explicit-frame)
  byte-code("@)IE .-BF G!I!,[2]-G[0]JI\"-)I
#+-MOP
#\"[2]-H[0]Q!S!+-C)
+$@(BS
!,[2]-G[0]JS
\"

	.-FE .-BF \n=,-C@,$A(BTU !=+[2]-H[0]OPVU !\"[2][0],gW!,(J(BYW!\"+-MZ![2]-H[0]OPVU !\"[2][0])I+?@;+(J(B^W!\",$(H(B:+\n!T!+$(0(J(BU G-AHu-window window-parent window-previous-child window-next-child window-pixel-edges window-pixel-height enlarge-window 2 save-selected-window-window ((byte-code "@	!+-DB	![2]-H[0]@[2]-G[0]" ... 2)) select-window record-buffer] 7)$)C
  # (catch done ...)
  # bind (override-frame not-this-window-p buffer)
  display-buffer(#<buffer "*Warnings*">)
  # bind (buffer)
  display-warning-buffer()
  # (condition-case ... . error)
  # bind (inhibit-quit)
  # (condition-case ... . error)
  # (catch top-level ...)

[1]    IOT trap               xemacs -q


--Multipart_Tue_Jun_18_11:06:52_1996-1
Content-Type: text/plain; charset=US-ASCII


  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---
--Multipart_Tue_Jun_18_11:06:52_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 21:59:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA17853 for xemacs-beta-people; Mon, 17 Jun 1996 21:59:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA17850 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 21:59:39 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA06787 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 21:59:35 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA08871; Mon, 17 Jun 1996 19:58:47 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: 20.0-b25/Mule crash on Linux 2.0 w/out PNG
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=ISO-2022-JP
Date: 17 Jun 1996 19:58:45 -0700
Message-ID: <m2ivcpzul6.fsf@deanna.miranova.com>
Lines: 228
X-Mailer: Gnus v5.2.19/XEmacs 20.0

Removing PNG support yielded a clean build, however I got an immediate
crash with Gnus entering this mailing list group:

Fatal error: assertion failed, file lstream.c, line 1471, abort()

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb `which xemacs` core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  decode-coding-region(1 22 junet)
  # (unwind-protect ...)
  # bind (curbuf tempbuf result coding-system str)
  character-decode-string("$(B<i2,(B $(BCNI'(B" junet)
  # bind (cs charset str)
  mime-charset-decode-string("$(B<i2,(B $(BCNI'(B" "ISO-2022-JP")
  # bind (dest str encoding charset)
  mime/decode-encoded-text("ISO-2022-JP" "B" "GyRCPGkyLBsoQiAbJEJDTkknGyhC")
  # bind (charset encoding text word)
  mime/decode-encoded-word("=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?=")
  # bind (dest ew beg end str)
  mime-eword/decode-string("=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>")
  # bind (from subj method header)
  #<compiled-function (from "loadup.el") (header) "...(76)" [header 2 "" 1 gnus-current-select-method method subj from nntp character-decode-string mime/default-coding-system mime-eword/decode-string] 4>([1250 "Re: More Mule-ing " "=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>" "Sun, 16 Jun 1996 22:40:29 JST" "<199606161340.WAA10985@mikan.jaist.ac.jp>" "<199606160217.TAA13220@xemacs.eng.sun.com>" 2415 69 "Xref: deanna.miranova.com xemacs-beta:1250"])
  mapcar(#<compiled-function (from "loadup.el") (header) "...(76)" [header 2 "" 1 gnus-current-select-method method subj from nntp character-decode-string mime/default-coding-system mime-eword/decode-string] 4> ([477 "Re: XEmacs 19.14 beta20 " "Mike Scheidler <c23mts@eng.delcoelect.com>" "Thu, 16 May 1996 14:44:08 -0500" "<25451.832275848@kocrsw12>" "<199605161904.OAA08997@xemacs.cs.uiuc.edu>" 1406 42 "Xref: deanna.miranova.com xemacs-beta:477"] [545 "Re: XEmacs 19.14 beta20 " "Chuck Thompson <cthomp@cs.uiuc.edu>" "Sun, 19 May 1996 13:28:32 -0500" "<199605191828.NAA06220@charles.cs.uiuc.edu>" "<25451.832275848@kocrsw12>" 785 22 "Xref: deanna.miranova.com xemacs-beta:545"] [945 "Re: b23 Success - Linux pre2.0.14" "wing@666.com (Ben Wing)" "Fri, 7 Jun 1996 18:48:34 -0700" "<199606080148.SAA26208@netcom2.netcom.com>" "" 994 28 "Xref: deanna.miranova.com xemacs-beta:945"] [949 "Linux library brokenness (was Re: b23 Success - Linux pre2.0.14)" "Steven L Baur <steve@miranova.com>" "!
!
07 Jun 1996 22:02:56 -0700" "<m2yblynb0f.fsf@deanna.miranova.com>" "<199606080148.SAA26208@netcom2.netcom.com>" 2074 55 "Xref: deanna.miranova.com xemacs-beta:949"] [449 "Re: C-x 4 b focus warp bug" "wing@666.com (Ben Wing)" "Wed, 15 May 1996 03:12:39 -0700" "<199605151012.DAA03234@netcom2.netcom.com>" "" 3572 80 "Xref: deanna.miranova.com xemacs-beta:449"] [455 "Re: C-x 4 b focus warp bug" "Steven L Baur <steve@miranova.com>" "15 May 1996 10:19:54 -0700" "<m2loityhtx.fsf@deanna.miranova.com>" "<199605151012.DAA03234@netcom2.netcom.com>" 4413 105 "Xref: deanna.miranova.com xemacs-beta:455"] [1163 "More Mule-ing" "\"Jareth \\\"JHod\\\" Hein\" <jhod@po.iijnet.or.jp>" "Fri, 14 Jun 1996 00:19:15 +0900" "<31C03173.1894221@po.iijnet.or.jp>" "" 441 12 "Xref: deanna.miranova.com xemacs-beta:1163"] [1167 "Re: More Mule-ing " "\"Joseph J. Nuspl Jr.\" <nuspl@nvwls.cc.purdue.edu>" "Thu, 13 Jun 1996 11:41:48 -0500" "<199606131641.LAA00838@nvwls.cc.purdue.edu>" "<31C03173.1894221@po.iijnet.!
!
or.jp>" 903 22 "Xref: deanna.miranova.com xemacs-beta:1167"] [1250 "Re: More Mule-ing " "=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>" "Sun, 16 Jun 1996 22:40:29 JST" "<199606161340.WAA10985@mikan.jaist.ac.jp>" "<199606160217.TAA13220@xemacs.eng.sun.com>" 2415 69 "Xref: deanna.miranova.com xemacs-beta:1250"] [1257 "XEmacs/Mule on SunOS 4" "Martin Buchholz <mrb@eng.sun.com>" "Sun, 16 Jun 1996 12:56:37 -0700" "<199606161956.MAA16787@xemacs.eng.sun.com>" "<199606160217.TAA13220@xemacs.eng.sun.com> <199606161340.WAA10985@mikan.jaist.ac.jp>" 508 14 "Xref: deanna.miranova.com xemacs-beta:1257"] [1198 "Re: More Mule-ing " "=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>" "Fri, 14 Jun 1996 21:48:53 JST" "<199606141248.VAA11840@mikan.jaist.ac.jp>" "<199606140446.EAA00832@nene.boundless.com>" 1624 43 "Xref: deanna.miranova.com xemacs-beta:1198"] [43 "Installation Report" "\"Ketil.Z\" <ketil@ii.uib.no>" "2!
!
5 Apr 1996 13:31:14 +0200" "<KETIL-eg20lcr14t.fsf@stamme.ii.uib.no>" "" 2307 69 "Xref: deanna.miranova.com xemacs-beta:43"] [1 "welcome to xemacs-beta" "XEmacs Mailing Lists Moderator <xemacs-m@cs.uiuc.edu>" "Mon, 22 Apr 1996 09:32:46 -0500" "<199604221432.JAA03142@teak.cs.uiuc.edu>" "" 4432 104 "Xref: deanna.miranova.com xemacs-beta:1"] [7 "PATCH: various things from the bug list... read on" "William Perry <wmperry@monolith.spry.com>" "Tue, 23 Apr 1996 06:16:14 -0700" "<199604231316.GAA01686@monolith.spry.com>" "" 4520 142 "Xref: deanna.miranova.com xemacs-beta:7"] [40 "Re: Installation Report " "Chuck Thompson <cthomp@cs.uiuc.edu>" "Thu, 25 Apr 1996 07:47:22 -0500" "<199604251247.HAA20180@charles.cs.uiuc.edu>" "<KETIL-eg20lcr14t.fsf@stamme.ii.uib.no>" 583 18 "Xref: deanna.miranova.com xemacs-beta:40"] [79 "XEmacs 19.14 beta18" "Chuck Thompson <cthomp@cs.uiuc.edu>" "Mon, 29 Apr 1996 11:02:22 -0500" "<199604291602.LAA28822@xemacs.cs.uiuc.edu>" "" 2977 72 "Xref: deanna.miranova!
!
.com xemacs-beta:79"] [188 "New version of linuxplay.c in 19.14b18" "Markus Gutschke <gutschk@uni-muenster.de>" "Thu, 2 May 1996 23:45:49 +0200" "<199605022145.XAA03896@cortex.corpus.uni-muenster.de>" "" 2393 57 "Xref: deanna.miranova.com xemacs-beta:188"] [233 "linuxplay.c v1.4" "Markus Gutschke <gutschk@uni-muenster.de>" "Sun, 5 May 1996 23:55:34 +0200" "<199605052155.XAA09674@cortex.corpus.uni-muenster.de>" "" 3639 109 "Xref: deanna.miranova.com xemacs-beta:233"] [320 "19.14b19 crash" "Christopher Davis <ckd@loiosh.kei.com>" "Fri, 10 May 1996 09:44:30 -0400 (EDT)" "<199605101344.JAA09386@loiosh.kei.com>" "" 13881 349 "Xref: deanna.miranova.com xemacs-beta:320"] [336 "auto-show-mode bug w/ patch" "Darrell Kindred <dkindred+@cmu.edu>" "Sat, 11 May 1996 23:05:29 -0400" "<9605120305.AA13652@GS213.SP.CS.CMU.EDU>" "" 1533 46 "Xref: deanna.miranova.com xemacs-beta:336"] [338 "[PATCH] problems with memoize_extent_face_internal()" "Ben Wing <wing@666.com>" "Sat, 11 May 1996 21:55:4!
!
3 GMT" "<199605112155.VAA06104@nene.boundless.com>" "" 692 22 "Xref: deanna.miranova.com xemacs-beta:338"] [459 "Re: b19 ok on Linux without BSD_SOURCE" "Steven L Baur <steve@miranova.com>" "15 May 1996 12:06:23 -0700" "<m2raslycwg.fsf@deanna.miranova.com>" "<199605150128.VAA03378@lorien.cary.nc> <m2g292sly9.fsf@deanna.miranova.com> <7601.832164510@rtp.ericsson.se> <m2ivdxyggr.fsf@deanna.miranova.com> <E0uJl5f-0004TC-00@neal.ctd.comsat.com>" 996 25 "Xref: deanna.miranova.com xemacs-beta:459"] [473 "XEmacs 19.14 beta20" "Chuck Thompson <cthomp@xemacs.org>" "Thu, 16 May 1996 14:04:32 -0500" "<199605161904.OAA08997@xemacs.cs.uiuc.edu>" "" 1144 35 "Xref: deanna.miranova.com xemacs-beta:473"] [474 "XEmacs 20.0 beta20" "Chuck Thompson <cthomp@xemacs.org>" "Thu, 16 May 1996 14:04:59 -0500" "<199605161905.OAA09002@xemacs.cs.uiuc.edu>" "" 1056 32 "Xref: deanna.miranova.com xemacs-beta:474"] [538 "Re: C-x 4 b focus warp bug" "Ben Wing <wing@666.com>" "Sun, 19 May 1996 01:23:01 GMT" "<m2!
!
afz5dnir.fsf@totally-fudged-out-message-id>" "<199605151012.DAA03234@netcom2.netcom.com> <m2loityhtx.fsf@deanna.miranova.com>" 255 7 "Xref: deanna.miranova.com xemacs-beta:538"] [559 "Re: XEmacs 19.14 beta20" "Mark Borges <mdb@cdc.noaa.gov>" "19 May 1996 19:32:18 -0600" "<vkivdsjfj1.fsf@cdc.noaa.gov>" "<199605191828.NAA06220@charles.cs.uiuc.edu>" 5614 149 "Xref: deanna.miranova.com xemacs-beta:559"] [592 "Re: XEmacs 19.14 beta20 " "Markus Gutschke <gutschk@uni-muenster.de>" "Mon, 20 May 1996 10:04:21 +0200" "<m2ivdquiv6.fsf@totally-fudged-out-message-id>" "<25451.832275848@kocrsw12> <199605191828.NAA06220@charles.cs.uiuc.edu>" 1664 45 "Xref: deanna.miranova.com xemacs-beta:592"] [593 "PATCH: Here's the fix for the `shell buffer + csh + filec' problem." "Martin Buchholz <mrb@eng.sun.com>" "Tue, 21 May 1996 03:02:22 -0700" "<199605211002.DAA14196@xemacs.eng.sun.com>" "" 941 31 "Xref: deanna.miranova.com xemacs-beta:593"] [638 "MIME attachment of death" "Steven L Baur <steve@mira!
!
nova.com>" "23 May 1996 16:50:07 -0700" "<m2ivdnrlu8.fsf@deanna.miranova.com>" "" 22246 393 "Xref: deanna.miranova.com xemacs-beta:638"] [659 "PATCH: specify pointer glyph for an extent. " "William Perry <wmperry@monolith.spry.com>" "Mon, 27 May 1996 11:10:32 -0700" "<199605271810.LAA00363@monolith.spry.com>" "" 1735 46 "Xref: deanna.miranova.com xemacs-beta:659"] [686 "XEmacs 19.14 beta21" "Chuck Thompson <cthomp@xemacs.org>" "Tue, 28 May 1996 17:44:12 -0500" "<199605282244.RAA12643@xemacs.cs.uiuc.edu>" "" 1266 33 "Xref: deanna.miranova.com xemacs-beta:686"] [688 "XEmacs 20.0 beta21" "Chuck Thompson <cthomp@xemacs.org>" "Tue, 28 May 1996 18:33:38 -0500" "<199605282333.SAA15212@xemacs.cs.uiuc.edu>" "" 1264 33 "Xref: deanna.miranova.com xemacs-beta:688"] [742 "XEmacs kills a mail process" "\"Lynn D. Newton\" <lnewton@ives.phx.mcd.mot.com>" "Thu, 30 May 1996 10:54:20 -0700" "<199605301754.KAA08122@ives.phx.mcd.mot.com>" "" 5433 125 "Xref: deanna.miranova.com xemacs-beta:742"] [7!
!
53 "19.14 release date / b22 release date" "Chuck Thompson <cthomp@xemacs.org>" "Fri, 31 May 1996 09:48:33 -0500" "<199605311448.JAA27378@xemacs.cs.uiuc.edu>" "" 673 18 "Xref: deanna.miranova.com xemacs-beta:753"] [765 "XEmacs 19.14 beta22" "Chuck Thompson <cthomp@xemacs.org>" "Sat, 01 Jun 1996 23:19:12 -0500" "<199606020419.XAA03263@xemacs.cs.uiuc.edu>" "" 1043 32 "Xref: deanna.miranova.com xemacs-beta:765"] [766 "XEmacs 20.0 beta22" "Chuck Thompson <cthomp@xemacs.org>" "Sat, 01 Jun 1996 23:49:56 -0500" "<199606020449.XAA04200@xemacs.cs.uiuc.edu>" "" 677 21 "Xref: deanna.miranova.com xemacs-beta:766"] [831 "menubar management" "Peter Pezaris <pez@dwwc.com>" "Tue, 4 Jun 1996 00:31:36 -0400" "<199606040431.AAA00362@pez.carroll.com>" "" 620 17 "Xref: deanna.miranova.com xemacs-beta:831"] [847 "Re: menubar management " "Mike Scheidler <c23mts@eng.delcoelect.com>" "Tue, 04 Jun 1996 08:46:43 -0500" "<4702.833896003@kocrsw12>" "<199606040431.AAA00362@pez.carroll.com>" 1140 29 "Xref:!
!
 deanna.miranova.com xemacs-beta:847"] [849 "Re: menubar management " "John Turner <turner@xdiv.lanl.gov>" "Tue, 4 Jun 1996 09:34:25 -0600" "<199606041534.JAA06614@gielgud.lanl.gov.xdiv>" "<199606040431.AAA00362@pez.carroll.com> <4702.833896003@kocrsw12>" 1252 42 "Xref: deanna.miranova.com xemacs-beta:849"] [860 "current-menubar" "\"Barry A. Warsaw\" <bwarsaw@cnri.reston.va.us>" "Tue, 4 Jun 1996 19:29:11 -0400" "<199606042329.TAA00834@anthem.CNRI.Reston.Va.US>" "" 2038 62 "Xref: deanna.miranova.com xemacs-beta:860"] [862 "EDiff/minibuffer nit" "\"Jareth \\\"JHod\\\" Hein\" <jhod@po.iijnet.or.jp>" "Tue, 04 Jun 1996 14:16:14 +0900" "<31B3C69E.2C26C7CF@po.iijnet.or.jp>" "" 836 20 "Xref: deanna.miranova.com xemacs-beta:862"] [865 "current-menubar" "Martin Buchholz <mrb@eng.sun.com>" "Wed, 5 Jun 1996 00:46:39 -0700" "<199606050746.AAA06608@xemacs.eng.sun.com>" "<199606042329.TAA00834@anthem.CNRI.Reston.Va.US>" 3078 93 "Xref: deanna.miranova.com xemacs-beta:865"] [922 "Minor nit wit!
!
h truncated lines/horiz scroll" "Raymond Toy <toy@rtp.ericsson.se>" "Fri, 07 Jun 1996 10:26:34 -0400" "<17291.834157594@rtp.ericsson.se>" "" 523 13 "Xref: deanna.miranova.com xemacs-beta:922"] [924 "Re: Minor nit with truncated lines/horiz scroll" "\"Doug Keller\" <dkeller@VNET.IBM.COM>" "Fri, 7 Jun 1996 11:00:56 -0400" "<9606071500.AA31088@spacedog.fishkill.ibm.com>" "<17291.834157594@rtp.ericsson.se>" 472 21 "Xref: deanna.miranova.com xemacs-beta:924"] [925 "XEmacs 19.14 beta23" "Chuck Thompson <cthomp@xemacs.org>" "Fri, 07 Jun 1996 11:12:09 -0500" "<199606071612.LAA11505@xemacs.cs.uiuc.edu>" "" 1471 36 "Xref: deanna.miranova.com xemacs-beta:925"] [927 "XEmacs 20.0 beta23" "Chuck Thompson <cthomp@xemacs.org>" "Fri, 07 Jun 1996 12:01:30 -0500" "<199606071701.MAA13899@xemacs.cs.uiuc.edu>" "" 1361 34 "Xref: deanna.miranova.com xemacs-beta:927"] [946 "Re: severe auto-show-mode lossage" "wing@666.com (Ben Wing)" "Fri, 7 Jun 1996 19:09:20 -0700" "<199606080209.TAA27980@netcom2.net!
!
com.com>" "" 550 14 "Xref: deanna.miranova.com xemacs-beta:946"] [967 "Linux library brokenness (was Re: b23 Success - Linux pre2.0.14)" "Ben Wing <wing@666.com>" "Sun, 9 Jun 1996 03:56:11 GMT" "<199606090356.DAA02447@nene.boundless.com>" "<199606080148.SAA26208@netcom2.netcom.com> <m2yblynb0f.fsf@deanna.miranova.com>" 1380 37 "Xref: deanna.miranova.com xemacs-beta:967"] [990 "XEmacs 19.14 beta24" "Chuck Thompson <cthomp@xemacs.org>" "Sun, 09 Jun 1996 18:10:11 -0500" "<199606092310.SAA07507@xemacs.cs.uiuc.edu>" "" 1463 35 "Xref: deanna.miranova.com xemacs-beta:990"] [998 "XEmacs 20.0 beta24" "Chuck Thompson <cthomp@xemacs.org>" "Sun, 09 Jun 1996 19:56:30 -0500" "<199606100056.TAA18407@xemacs.cs.uiuc.edu>" "" 1492 37 "Xref: deanna.miranova.com xemacs-beta:998"] [1000 "19.14 release schedule" "Chuck Thompson <cthomp@xemacs.org>" "Sun, 09 Jun 1996 20:12:30 -0500" "<199606100112.UAA21517@xemacs.cs.uiuc.edu>" "" 860 26 "Xref: deanna.miranova.com xemacs-beta:1000"] [1152 "How do 19.!
!
14 and 19.20 sources track?" "Martin Buchholz <mrb@eng.sun.com>" "Thu, 13 Jun 1996 02:10:06 -0700" "<199606130910.CAA03825@xemacs.eng.sun.com>" "<m0uTnsc-00004AC@susan.logware.de> <9606121705.aa10457@caddy.arnet.com>" 1149 40 "Xref: deanna.miranova.com xemacs-beta:1152"] [1177 "More Mule-ing" "Martin Buchholz <mrb@eng.sun.com>" "Thu, 13 Jun 1996 22:19:41 -0700" "<199606140519.WAA11274@xemacs.eng.sun.com>" "<31C03173.1894221@po.iijnet.or.jp>" 3294 90 "Xref: deanna.miranova.com xemacs-beta:1177"] [1181 "Re: Toolbar thought grenade" "andyp@parallax.co.uk (Andy Piper)" "Fri, 14 Jun 1996 08:37:01 +0100" "<199606140737.IAA12072@wrath.parallax.co.uk>" "" 638 17 "Xref: deanna.miranova.com xemacs-beta:1181"] [1183 "Word Processors" "Lars Magne Ingebrigtsen <larsi@ifi.uio.no>" "14 Jun 1996 11:23:32 +0200" "<x6n326pwmi.fsf@eyesore.no>" "" 1051 22 "Xref: deanna.miranova.com xemacs-beta:1183"] [1185 "Re: Word Processors" "Jens Lautenbacher <jens@lemcbed.lem.uni-karlsruhe.de>" "14 Jun 1996 !
!
12:34:56 +0200" "<x2zq66oer3.fsf@lemcbed.lem.uni-karlsruhe.de>" "<x6n326pwmi.fsf@eyesore.no>" 1124 26 "Xref: deanna.miranova.com xemacs-beta:1185"] [1191 "Re: Word Processors" "wing@666.com (Ben Wing)" "Fri, 14 Jun 1996 04:41:26 -0700" "<199606141141.EAA27093@netcom2.netcom.com>" "" 1091 24 "Xref: deanna.miranova.com xemacs-beta:1191"] [1192 "Re: More Mule-ing " "Ben Wing <wing@666.com>" "Fri, 14 Jun 1996 04:46:48 GMT" "<199606140446.EAA00832@nene.boundless.com>" "<31C03173.1894221@po.iijnet.or.jp> <199606131641.LAA00838@nvwls.cc.purdue.edu>" 2332 50 "Xref: deanna.miranova.com xemacs-beta:1192"] [1197 "Re: Word Processors" "andyp@parallax.co.uk (Andy Piper)" "Fri, 14 Jun 1996 14:07:06 +0100" "<199606141307.OAA15574@wrath.parallax.co.uk>" "" 1421 30 "Xref: deanna.miranova.com xemacs-beta:1197"] [1209 "Re: Word Processors" "Wolfgang Grieskamp <wg@cs.tu-berlin.de>" "Fri, 14 Jun 1996 21:15:47 +0200 (MET DST)" "<199606141915.VAA14630@memnon.cs.tu-berlin.de>" "<199606141307.OAA15574!
!
@wrath.parallax.co.uk>" 2575 67 "Xref: deanna.miranova.com xemacs-beta:1209"] [1221 "buffers menu improvements" "Ben Wing <wing@dimensionx.com>" "Sat, 15 Jun 1996 00:10:01 -0800" "<199606150810.AAA25969@mole.dimensionx.com>" "" 12694 316 "Xref: deanna.miranova.com xemacs-beta:1221"] [1235 "Re:  ^G granularity?" "wing@666.com (Ben Wing)" "Sat, 15 Jun 1996 18:47:04 -0700" "<199606160147.SAA22246@netcom2.netcom.com>" "" 399 17 "Xref: deanna.miranova.com xemacs-beta:1235"] [1237 "Re: More Mule-ing " "Martin Buchholz <mrb@eng.sun.com>" "Sat, 15 Jun 1996 19:17:54 -0700" "<199606160217.TAA13220@xemacs.eng.sun.com>" "<199606140446.EAA00832@nene.boundless.com> <199606141248.VAA11840@mikan.jaist.ac.jp>" 1228 40 "Xref: deanna.miranova.com xemacs-beta:1237"] [1241 "Re: How do 19.14 and 19.20 sources track? " "Chuck Thompson <cthomp@cs.uiuc.edu>" "Sat, 15 Jun 1996 22:40:54 -0500" "<199606160340.WAA23982@charles.cs.uiuc.edu>" "<9606121705.aa10457@caddy.arnet.com>" 1339 46 "Xref: deanna.mira!
!
nova.com xemacs-beta:1241"] [1254 "Re: More Mule-ing" "Steven L Baur <steve@miranova.com>" "16 Jun 1996 12:16:23 -0700" "<m2spbv36go.fsf@deanna.miranova.com>" "<199606161340.WAA10985@mikan.jaist.ac.jp>" 1173 32 "Xref: deanna.miranova.com xemacs-beta:1254"] [1273 "b25 build report on sun solaris 2.4" "Mike Scheidler <c23mts@eng.delcoelect.com>" "Mon, 17 Jun 1996 11:12:56 -0500" "<3829.835027976@kocrsw12>" "" 735 19 "Xref: deanna.miranova.com xemacs-beta:1273"] [1274 "XEmacs 20.0 beta25" "Chuck Thompson <cthomp@xemacs.org>" "Mon, 17 Jun 1996 11:39:19 -0500" "<199606171639.LAA10197@xemacs.cs.uiuc.edu>" "" 3221 72 "Xref: deanna.miranova.com xemacs-beta:1274"] [1275 "XEmacs 19.14 beta25" "Chuck Thompson <cthomp@xemacs.org>" "Mon, 17 Jun 1996 11:28:27 -0500" "<199606171628.LAA08238@xemacs.cs.uiuc.edu>" "" 3287 74 "Xref: deanna.miranova.com xemacs-beta:1275"] [1276 "Re: Toolbar thought grenade " "\"Joseph J. Nuspl Jr.\" <nuspl@nvwls.cc.purdue.edu>" "Mon, 17 Jun 1996 11:56:34 -0500" "!
!
<199606171656.LAA03952@nvwls.cc.purdue.edu>" "<199606140737.IAA12072@wrath.parallax.co.uk>" 762 17 "Xref: deanna.miranova.com xemacs-beta:1276"] [1279 "19.15b25 build success, VM problem" "John Turner <turner@xdiv.lanl.gov>" "Mon, 17 Jun 1996 12:54:52 -0600" "<199606171854.MAA01990@gielgud.lanl.gov.xdiv>" "" 2157 30 "Xref: deanna.miranova.com xemacs-beta:1279"] [1280 "XEmacs 19.14 beta25 Solaris binary kit" "Chuck Thompson <cthomp@xemacs.org>" "Mon, 17 Jun 1996 14:31:35 -0500" "<199606171931.OAA23078@xemacs.cs.uiuc.edu>" "" 72 6 "Xref: deanna.miranova.com xemacs-beta:1280"] [1281 "b25 compile problems with solaris2.4" "Sudeep Kumar Palat <palat@idt.unit.no>" "17 Jun 1996 21:30:53 +0200" "<yv97mt6qlci.fsf@ynde.idt.unit.no>" "" 2268 47 "Xref: deanna.miranova.com xemacs-beta:1281"] [1282 "19.14 b25 crash on Solaris 2.5" "Raymond Toy <toy@rtp.ericsson.se>" "Mon, 17 Jun 1996 16:10:28 -0400" "<22798.835042228@rtp.ericsson.se>" "" 6496 108 "Xref: deanna.miranova.com xemacs-beta:1282"!
!
] [1283 "20.0-b25 loses on Linux 2.0 w/ PNG" "Steven L Baur <steve@miranova.com>" "17 Jun 1996 13:25:50 -0700" "<m2lohmb2k1.fsf@deanna.miranova.com>" "" 2560 71 "Xref: deanna.miranova.com xemacs-beta:1283"] [1287 "Re: 19.14b25 crashes on SunOS 4.1.3 " "Dan Rich <drich@cisco.com>" "Mon, 17 Jun 1996 15:52:16 -0700" "<2.2.32.19960617225216.006ca0bc@diablo.cisco.com>" "" 468 10 "Xref: deanna.miranova.com xemacs-beta:1287"] [1288 "Re: last-nonminibuf-frame patch" "Dan Rich <drich@cisco.com>" "Mon, 17 Jun 1996 16:20:58 -0700" "<2.2.32.19960617232058.006b134c@diablo.cisco.com>" "" 496 11 "Xref: deanna.miranova.com xemacs-beta:1288"] [1289 "Re: XEmacs/Mule on SunOS 4 " "=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>" "Tue, 18 Jun 1996 10:18:55 JST" "<199606180119.KAA21161@mikan.jaist.ac.jp>" "<199606161956.MAA16787@xemacs.eng.sun.com>" 1501 37 "Xref: deanna.miranova.com xemacs-beta:1289"]))
  tm-gnus/decode-summary-from-and-subjects()
  run-hooks(gnus-select-group-hook)
  # bind (did-select quit-config new-group no-display kill-buffer no-article show-all group)
  gnus-summary-read-group("nnml:xemacs-beta" nil nil)
  # bind (group number active marked entry group no-article all)
  gnus-group-read-group(nil nil nil)
  # bind (group no-article all)
  gnus-topic-read-group(nil)
  # bind (e)
  gnus-mouse-pick-topic(#<buttondown-event button2>)
  # bind (command-debug-status)
  call-interactively(gnus-mouse-pick-topic)
  # (condition-case ... . error)
  # (catch top-level ...)

#0  0x401e1741 in __kill ()
#1  0x8087495 in fatal_error_signal (sig=6) at emacs.c:193
#2  0xbfffd508 in __ypbindlist ()
#3  0x4020f18d in gsignal ()
#4  0x80f5dcd in make_lisp_buffer_stream_1 (buf=0x86cf800, start=1, end=0, 
    flags=0, mode=0x81d0bb8 "w") at lstream.c:1471
#5  0x80f6040 in make_lisp_buffer_output_stream (buf=0x86cf800, pos=1, flags=0)
    at lstream.c:1535
#6  0x819e7bb in Fdecode_coding_region (start=1, end=22, 
    coding_system=406786220, buffer=405684228)
    at /i/xemacs-20.0-b25/src/./mule-coding.c:2151
#7  0x808d459 in primitive_funcall (fn=0x819e73c <Fdecode_coding_region>, 
    nargs=4, args=0xbfffdae8) at eval.c:3490
#8  0x808d5dc in funcall_subr (subr=0x82b213c, args=0xbfffdae8) at eval.c:3526
#9  0x808cc5c in funcall_recording_as (recorded_as=405803756, nargs=4, 
    args=0xbfffdbc4) at eval.c:3207
#10 0x808cd37 in Ffuncall (nargs=4, args=0xbfffdbc4) at eval.c:3253
#11 0x80618ee in Fbyte_code (bytestr=942200520, vector=1210636032, maxdepth=4)
    at bytecode.c:419
#12 0x808d973 in funcall_lambda (fun=405325920, nargs=2, arg_vector=0xbfffdd10)
    at eval.c:3636
#13 0x808ccf6 in funcall_recording_as (recorded_as=406253180, nargs=3, 
    args=0xbfffdd0c) at eval.c:3223
---Type <return> to continue, or q <return> to quit--- 
#14 0x808cd37 in Ffuncall (nargs=3, args=0xbfffdd0c) at eval.c:3253
#15 0x80618ee in Fbyte_code (bytestr=947528764, vector=1216311488, maxdepth=4)
    at bytecode.c:419
#16 0x808d973 in funcall_lambda (fun=409737892, nargs=2, arg_vector=0xbfffdeb8)
    at eval.c:3636
#17 0x808ccf6 in funcall_recording_as (recorded_as=409752588, nargs=3, 
    args=0xbfffdeb4) at eval.c:3223
#18 0x808cd37 in Ffuncall (nargs=3, args=0xbfffdeb4) at eval.c:3253
#19 0x80618ee in Fbyte_code (bytestr=947549376, vector=1216333376, maxdepth=4)
    at bytecode.c:419
#20 0x808d973 in funcall_lambda (fun=409738404, nargs=3, arg_vector=0xbfffe078)
    at eval.c:3636
#21 0x808ccf6 in funcall_recording_as (recorded_as=409753380, nargs=4, 
    args=0xbfffe074) at eval.c:3223
#22 0x808cd37 in Ffuncall (nargs=4, args=0xbfffe074) at eval.c:3253
#23 0x80618ee in Fbyte_code (bytestr=947549172, vector=1216333440, maxdepth=5)
    at bytecode.c:419
#24 0x808d973 in funcall_lambda (fun=409738372, nargs=1, arg_vector=0xbfffe2e4)
    at eval.c:3636
#25 0x808ccf6 in funcall_recording_as (recorded_as=409753356, nargs=2, 
    args=0xbfffe2e0) at eval.c:3223
#26 0x808cd37 in Ffuncall (nargs=2, args=0xbfffe2e0) at eval.c:3253
#27 0x80618ee in Fbyte_code (bytestr=947548428, vector=1216333568, maxdepth=5)
---Type <return> to continue, or q <return> to quit---
    at bytecode.c:419
#28 0x808d973 in funcall_lambda (fun=409738244, nargs=1, arg_vector=0xbfffe4dc)
    at eval.c:3636
#29 0x808ccf6 in funcall_recording_as (recorded_as=409708156, nargs=2, 
    args=0xbfffe4d8) at eval.c:3223
#30 0x808cd37 in Ffuncall (nargs=2, args=0xbfffe4d8) at eval.c:3253
#31 0x80618ee in Fbyte_code (bytestr=947548224, vector=1216333760, maxdepth=4)
    at bytecode.c:419
#32 0x808d973 in funcall_lambda (fun=410337412, nargs=1, arg_vector=0xbfffe5dc)
    at eval.c:3636
#33 0x808ccf6 in funcall_recording_as (recorded_as=410337412, nargs=2, 
    args=0xbfffe5d8) at eval.c:3223
#34 0x808cd37 in Ffuncall (nargs=2, args=0xbfffe5d8) at eval.c:3253
#35 0x808e20f in call1 (fn=410337412, arg0=1216334464) at eval.c:3998
#36 0x80c5aa0 in mapcar1 (leni=77, vals=0xbfffe64c, fn=410337412, 
    seq=676245388) at fns.c:3321
#37 0x80c5bf7 in Fmapcar (fn=410337412, seq=676245388) at fns.c:3382
#38 0x808d42d in primitive_funcall (fn=0x80c5ba8 <Fmapcar>, nargs=2, 
    args=0xbfffe870) at eval.c:3486
#39 0x808d5dc in funcall_subr (subr=0x81f9d54, args=0xbfffe870) at eval.c:3526
#40 0x808cc5c in funcall_recording_as (recorded_as=405781708, nargs=3, 
    args=0xbfffe86c) at eval.c:3207
#41 0x808cd37 in Ffuncall (nargs=3, args=0xbfffe86c) at eval.c:3253
---Type <return> to continue, or q <return> to quit---
#42 0x80618ee in Fbyte_code (bytestr=947552096, vector=1216333632, maxdepth=3)
    at bytecode.c:419
#43 0x808d973 in funcall_lambda (fun=410240580, nargs=0, arg_vector=0xbfffe9d8)
    at eval.c:3636
#44 0x808ccf6 in funcall_recording_as (recorded_as=409708108, nargs=1, 
    args=0xbfffe9d4) at eval.c:3223
#45 0x808cd37 in Ffuncall (nargs=1, args=0xbfffe9d4) at eval.c:3253
#46 0x808dfa1 in run_hook_with_args_in_buffer (buf=0x850e600, nargs=1, 
    args=0xbfffe9d4, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3832
#47 0x808e01a in run_hook_with_args (nargs=1, args=0xbfffe9d4, 
    cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3845
#48 0x808dcab in Frun_hooks (nargs=1, args=0xbffff2e8) at eval.c:3697
#49 0x808cc11 in funcall_recording_as (recorded_as=405772628, nargs=2, 
    args=0xbffff2e4) at eval.c:3191
#50 0x808cd37 in Ffuncall (nargs=2, args=0xbffff2e4) at eval.c:3253
#51 0x80618ee in Fbyte_code (bytestr=946234476, vector=1212275200, maxdepth=4)
    at bytecode.c:419
#52 0x808d973 in funcall_lambda (fun=409367300, nargs=3, arg_vector=0xbffff588)
    at eval.c:3636
#53 0x808ccf6 in funcall_recording_as (recorded_as=409317524, nargs=4, 
    args=0xbffff584) at eval.c:3223
#54 0x808cd37 in Ffuncall (nargs=4, args=0xbffff584) at eval.c:3253
#55 0x80618ee in Fbyte_code (bytestr=942991008, vector=1213732096, maxdepth=6)
---Type <return> to continue, or q <return> to quit---
    at bytecode.c:419
#56 0x808d973 in funcall_lambda (fun=409319460, nargs=3, arg_vector=0xbffff724)
    at eval.c:3636
#57 0x808ccf6 in funcall_recording_as (recorded_as=408477748, nargs=4, 
    args=0xbffff720) at eval.c:3223
#58 0x808cd37 in Ffuncall (nargs=4, args=0xbffff720) at eval.c:3253
#59 0x80618ee in Fbyte_code (bytestr=946376208, vector=1215135744, maxdepth=4)
    at bytecode.c:419
#60 0x808d973 in funcall_lambda (fun=409710052, nargs=1, arg_vector=0xbffff850)
    at eval.c:3636
#61 0x808ccf6 in funcall_recording_as (recorded_as=409805884, nargs=2, 
    args=0xbffff84c) at eval.c:3223
#62 0x808cd37 in Ffuncall (nargs=2, args=0xbffff84c) at eval.c:3253
#63 0x80618ee in Fbyte_code (bytestr=946375980, vector=1214969888, maxdepth=2)
    at bytecode.c:419
#64 0x808d973 in funcall_lambda (fun=409710020, nargs=1, arg_vector=0xbffff958)
    at eval.c:3636
#65 0x808ccf6 in funcall_recording_as (recorded_as=409806004, nargs=2, 
    args=0xbffff954) at eval.c:3223
#66 0x808cd37 in Ffuncall (nargs=2, args=0xbffff954) at eval.c:3253
#67 0x80644a6 in Fcall_interactively (function=409806004, 
    record_flag=405684228, keys=405684228) at callint.c:931
#68 0x808bb99 in Fcommand_execute (cmd=409806004, record=405684228, 
---Type <return> to continue, or q <return> to quit---
    keys=405684228) at eval.c:2628
#69 0x809e1d2 in execute_command_event (command_builder=0x831f700, 
    event=407896532) at event-stream.c:3478
#70 0x809f25f in Fdispatch_event (event=407896532) at event-stream.c:3813
#71 0x806e197 in Fcommand_loop_1 () at cmdloop.c:542
#72 0x806deab in command_loop_1 (dummy=405684228) at cmdloop.c:462
#73 0x808a816 in condition_case_1 (handlers=405684324, 
    bfun=0x806de40 <command_loop_1>, barg=405684228, 
    hfun=0x806d23c <cmd_error>, harg=405684228) at eval.c:1672
#74 0x806d308 in command_loop_3 () at cmdloop.c:224
#75 0x806d324 in command_loop_2 (dummy=405684228) at cmdloop.c:235
#76 0x808a439 in internal_catch (tag=405761996, 
    func=0x806d31c <command_loop_2>, arg=405684228, threw=0x0) at eval.c:1347
#77 0x806d6fe in initial_command_loop (load_me=405684228) at cmdloop.c:273
#78 0x808802c in Frunning_temacs_p () at emacs.c:1374
#79 0x808839e in main (argc=1, argv=0xbffffc28, envp=0xbffffc30)
    at emacs.c:1496
#80 0x804ea7b in _start ()
(gdb) 

Configured for `i486-unknown-linux2.0.0'.

  Where should the build process find the source code?    /i/xemacs-20.0-b25
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 17 23:12:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA17978 for xemacs-beta-people; Mon, 17 Jun 1996 23:12:59 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA17975 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 17 Jun 1996 23:12:58 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA09499 for <xemacs-beta@cs.uiuc.edu>; Mon, 17 Jun 1996 23:13:00 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA29151; Mon, 17 Jun 1996 23:12:54 -0500 (CDT)
Message-Id: <199606180412.XAA29151@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: 20.0-b25 loses on Linux 2.0 w/ PNG 
In-reply-to: Your message of "17 Jun 1996 13:25:50 PDT."
             <m2lohmb2k1.fsf@deanna.miranova.com> 
Date: Mon, 17 Jun 1996 23:12:53 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Steven> I am using libgr-2.0.5 for PNG support, and haven't had
    Steven> problems with this previously.  This was also from a full
    Steven> distribution, not patched up.

As of libgr-2.0.7 it is still including libpng 0.81.  The latest
version is 0.88.  The non-temp file support needs a version somewhere
between 0.82 and 0.87.  I've changed it to assume at least 0.87 which
is as far back as I can verify.

I would suggest bitching to whoever packages up libgr.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 00:28:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA18088 for xemacs-beta-people; Tue, 18 Jun 1996 00:28:07 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA18085 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 00:28:05 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA10384 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 00:28:07 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id WAA10736; Mon, 17 Jun 1996 22:27:19 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 20.0-b25 loses on Linux 2.0 w/ PNG
References: <199606180412.XAA29151@charles.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of 17 Jun 1996 21:12:53 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Jun 1996 22:27:16 -0700
Message-ID: <m2afy1znpn.fsf@deanna.miranova.com>
Lines: 21
X-Mailer: Gnus v5.2.19/XEmacs 20.0

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

Steven> I am using libgr-2.0.5 for PNG support, and haven't had
Steven> problems with this previously.  This was also from a full
Steven> distribution, not patched up.

Chuck> As of libgr-2.0.7 it is still including libpng 0.81.  The latest
Chuck> version is 0.88.  The non-temp file support needs a version somewhere
Chuck> between 0.82 and 0.87.  I've changed it to assume at least 0.87 which
Chuck> is as far back as I can verify.

Chuck> I would suggest bitching to whoever packages up libgr.

I feel another h_errno in the air :-(.  I'll make sure something gets
into the FAQ.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 01:17:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA18163 for xemacs-beta-people; Tue, 18 Jun 1996 01:17:22 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA18160 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 01:17:21 -0500 (CDT)
Received: from GS213.SP.CS.CMU.EDU (GS213.SP.CS.CMU.EDU [128.2.209.183]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA01036 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 01:17:19 -0500 (CDT)
Received: by GS213.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA29872; Tue, 18 Jun 1996 02:17:17 -0400
Date: Tue, 18 Jun 1996 02:17:17 -0400
Message-Id: <9606180617.AA29872@GS213.SP.CS.CMU.EDU>
From: Darrell Kindred <dkindred+@cmu.edu>
To: xemacs-beta@xemacs.org
Subject: noncritical recover-file patch

This is pretty minor, and exists in FSF 19.29 too.

If an auto-save file exists (say /tmp/#foo#) but the corresponding
file (/tmp/foo) doesn't, then when you open /tmp/foo you get the 
"try M-x recover-file" suggestion.  If you do M-x recover-file then,
it won't work because you can't enter the nonexistent filename
/tmp/foo.

Patch follows.

(BTW, 19.14b25 with Chuck's patch is good so far under Linux 2.0.0,
gcc 2.7.2-no-sr-bug, libc 5.2.18, binutils 2.6.0.10, XFree86 3.1.2
(X11R6), Athena dialog boxes, "lucid" scrollbars & menubar, native
sound, gif support, with xpm 3.4f (patched).)

- Darrell

*** lisp/prim/files.el.orig	Sun Jun 16 15:37:28 1996
--- lisp/prim/files.el	Tue Jun 18 02:06:59 1996
***************
*** 2448,2454 ****
    ;; Actually putting the file name in the minibuffer should be used
    ;; only rarely.
    ;; Not just because users often use the default.
!   (interactive "fRecover file: ")
    (setq file (expand-file-name file))
    (if (auto-save-file-name-p file)
        (error "%s is an auto-save file" file))
--- 2448,2454 ----
    ;; Actually putting the file name in the minibuffer should be used
    ;; only rarely.
    ;; Not just because users often use the default.
!   (interactive "FRecover file: ")
    (setq file (expand-file-name file))
    (if (auto-save-file-name-p file)
        (error "%s is an auto-save file" file))

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 02:01:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA18279 for xemacs-beta-people; Tue, 18 Jun 1996 02:01:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA18276 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 02:01:12 -0500 (CDT)
Received: from GS213.SP.CS.CMU.EDU (GS213.SP.CS.CMU.EDU [128.2.209.183]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA01069 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 02:01:10 -0500 (CDT)
Received: by GS213.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA44086; Tue, 18 Jun 1996 03:01:09 -0400
Date: Tue, 18 Jun 1996 03:01:09 -0400
Message-Id: <9606180701.AA44086@GS213.SP.CS.CMU.EDU>
From: Darrell Kindred <dkindred+@cmu.edu>
To: xemacs-beta@xemacs.org
Subject: buffer-menu sorting

The new buffer-menu grouping/sorting is interesting, but it has the
disadvantage that truncating the menu after some number of entries no
longer really makes sense since the lower entries are no less
"significant" than the upper ones.  Of course we have to truncate
somehow to avoid exceeding screen size, and I can't think of any
non-arbitrary way to do that for alphabetically sorted buffers, so
maybe it's not worth worrying about.  

Perhaps the default buffer menu size could be increased from 15 to 25
or so, so this problem doesn't bite as often.

- Darrell

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 02:50:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA18414 for xemacs-beta-people; Tue, 18 Jun 1996 02:50:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA18411 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 02:50:14 -0500 (CDT)
Received: from darkside (gate.dimensionx.com [198.68.165.10]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA14555 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 02:50:15 -0500 (CDT)
Received: (from smap@localhost) by darkside (SMI-8.6/8.6.9) id AAA14610 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 00:48:07 -0700
Received: from server.dimensionx.com(198.68.166.10) by darkside via smap (V1.3)
	id sma014608; Tue Jun 18 00:47:41 1996
Received: from mole.dimensionx.com by dimensionx.com (SMI-8.6/SMI-SVR4)
	id AAA00722; Tue, 18 Jun 1996 00:47:59 -0700
Received: (from wing@localhost) by mole.dimensionx.com (8.7.3/8.7.3) id AAA00400 for xemacs-beta@cs.uiuc.edu; Tue, 18 Jun 1996 00:42:03 -0800
Date: Tue, 18 Jun 1996 00:42:03 -0800
From: Ben Wing <wing@dimensionx.com>
Message-Id: <199606180842.AAA00400@mole.dimensionx.com>
To: xemacs-beta@cs.uiuc.edu
Subject: [PATCH] revert-buffer on lazy-locked buffer causes full refontification

This also fixes similar problems with insert-file, M-x yank on large
regions, etc.

Normally I'd just include this in the patches for the next beta, but
seeing as how we're so close to release, I'm sending this to the beta
list.

Anyone who uses lazy-lock, PLEASE apply these patches and make sure
it doesn't screw anything up.


diff -cr chuck-foo/lisp/packages/lazy-lock.el xemacs-19.14-b24/lisp/packages/lazy-lock.el
*** chuck-foo/lisp/packages/lazy-lock.el	Sun Apr 14 16:57:37 1996
--- xemacs-19.14-b24/lisp/packages/lazy-lock.el	Tue Jun 18 00:29:06 1996
***************
*** 533,539 ****
    ;; should really be merged with this file; or more likely, lazy-lock
    ;; in its entirety should be merged into font-lock).
    (add-hook 'pre-idle-hook 'lazy-lock-pre-idle-fontify-windows t)
!   (add-hook 'post-command-hook 'lazy-lock-post-command-fontify-stealthily t))
  
  (defun lazy-lock-fontify-region (start end &optional buffer)
    "Fontify between START and END in BUFFER where necessary."
--- 533,569 ----
    ;; should really be merged with this file; or more likely, lazy-lock
    ;; in its entirety should be merged into font-lock).
    (add-hook 'pre-idle-hook 'lazy-lock-pre-idle-fontify-windows t)
!   (add-hook 'post-command-hook 'lazy-lock-post-command-fontify-stealthily t)
!   ;; Fascistically remove font-lock's after-change-function and install
!   ;; our own.  We know better than font-lock what to do.  Otherwise,
!   ;; revert-buffer, insert-file, etc. cause full refontification of the
!   ;; entire changed area.
!   (if lazy-lock-mode
!       (progn
! 	(remove-hook 'after-change-functions 'font-lock-after-change-function
! 		     t)
! 	(make-local-hook 'after-change-functions)
! 	(add-hook 'after-change-functions 'lazy-lock-after-change-function
! 		  nil t))
!     (remove-hook 'after-change-functions 'lazy-lock-after-change-function t)
!     (if font-lock-mode
! 	(add-hook 'after-change-functions 'font-lock-after-change-function
! 		  nil t)))
! )
! 
! ;; use put-nonduplicable-text-property to avoid unfriendly behavior
! ;; when doing undo, etc.  We really don't want syntax-highlighting text
! ;; properties copied into strings or tracked by undo.
! ;;
! ;; #### If start-open and end-open really behaved like they are supposed to,
! ;; we wouldn't really need this.  I kind of fixed them up, but there's still
! ;; a bug -- inserting text into the middle of a region of
! ;; (start-open t end-open t) text should cause it not to inherit, but it
! ;; does.
! 
! (if lazy-lock-running-xemacs-p
!     (defalias 'lazy-lock-put-text-property 'put-nonduplicable-text-property)
!   (defalias 'lazy-lock-put-text-property 'put-text-property))
  
  (defun lazy-lock-fontify-region (start end &optional buffer)
    "Fontify between START and END in BUFFER where necessary."
***************
*** 550,556 ****
    (let ((modified (buffer-modified-p)) (inhibit-read-only t)
  	(buffer-undo-list t)
  	deactivate-mark buffer-file-name buffer-file-truename)
!     (put-text-property (point-min) (point-max) 'fontified t)
      (or modified (set-buffer-modified-p nil))))
  
  ;; Just a cleaner-looking way of coping with Emacs' and XEmacs' `sit-for'.
--- 580,586 ----
    (let ((modified (buffer-modified-p)) (inhibit-read-only t)
  	(buffer-undo-list t)
  	deactivate-mark buffer-file-name buffer-file-truename)
!     (lazy-lock-put-text-property (point-min) (point-max) 'fontified t)
      (or modified (set-buffer-modified-p nil))))
  
  ;; Just a cleaner-looking way of coping with Emacs' and XEmacs' `sit-for'.
***************
*** 651,656 ****
--- 681,692 ----
  	  (setq lazy-lock-pre-idle-frame-modified-tick
  		(frame-modified-tick (selected-frame)))))))
  
+ (defun lazy-lock-after-change-function (beg end old-len)
+   (and lazy-lock-mode
+        (if (= beg end)
+ 	   (font-lock-after-change-function beg end old-len)
+ 	 (lazy-lock-put-text-property beg end 'fontified nil))))
+ 
  ;; DO NOT put this as a pre-idle hook!  The sit-for messes up
  ;; mouse dragging.
  (defun lazy-lock-post-command-fontify-stealthily ()
***************
*** 714,720 ****
  	    ;; or we'll mess up in the presence of deferred font-locking.
  	    (let ((font-lock-always-fontify-immediately t))
  	      (font-lock-after-change-function start end 0))
! 	    (put-text-property start end 'fontified t)
  	    ;; Find the next region.
  	    (setq start (or (text-property-not-all ws we 'fontified t) ws)
  		  end (or (text-property-any start we 'fontified t) we)))
--- 750,756 ----
  	    ;; or we'll mess up in the presence of deferred font-locking.
  	    (let ((font-lock-always-fontify-immediately t))
  	      (font-lock-after-change-function start end 0))
! 	    (lazy-lock-put-text-property start end 'fontified t)
  	    ;; Find the next region.
  	    (setq start (or (text-property-not-all ws we 'fontified t) ws)
  		  end (or (text-property-any start we 'fontified t) we)))
***************
*** 784,790 ****
        ;; or we'll mess up in the presence of deferred font-locking.
        (let ((font-lock-always-fontify-immediately t))
  	(font-lock-after-change-function start end 0))
!       (put-text-property start end 'fontified t)
        (or modified (set-buffer-modified-p nil)))))
  
  (defun lazy-lock-fontify-walk-stealthily ()
--- 820,826 ----
        ;; or we'll mess up in the presence of deferred font-locking.
        (let ((font-lock-always-fontify-immediately t))
  	(font-lock-after-change-function start end 0))
!       (lazy-lock-put-text-property start end 'fontified t)
        (or modified (set-buffer-modified-p nil)))))
  
  (defun lazy-lock-fontify-walk-stealthily ()
***************
*** 848,855 ****
  	  (condition-case nil
  	      (set-face-foreground face fore)
  	    (error (message "Unable to use foreground \"%s\"" fore))))
!       (put-text-property (point-min) (point-max) 'face face)
!       (put-text-property (point-min) (point-max) 'fontified nil)
        (or modified (set-buffer-modified-p nil)))))
  
  ;; Functions for Emacs:
--- 884,891 ----
  	  (condition-case nil
  	      (set-face-foreground face fore)
  	    (error (message "Unable to use foreground \"%s\"" fore))))
!       (lazy-lock-put-text-property (point-min) (point-max) 'face face)
!       (lazy-lock-put-text-property (point-min) (point-max) 'fontified nil)
        (or modified (set-buffer-modified-p nil)))))
  
  ;; Functions for Emacs:
***************
*** 899,905 ****
  			(while (and (re-search-forward "\\s\"" end 'move)
  				    (nth 3 (parse-partial-sexp beg (point) nil nil
  							       state))))
! 			(put-text-property beg (point) 'face font-lock-string-face)
  			(setq state (parse-partial-sexp beg (point)
  							nil nil state))))
  		  ;; Likewise for a comment.
--- 935,942 ----
  			(while (and (re-search-forward "\\s\"" end 'move)
  				    (nth 3 (parse-partial-sexp beg (point) nil nil
  							       state))))
! 			(lazy-lock-put-text-property
! 			 beg (point) 'face font-lock-string-face)
  			(setq state (parse-partial-sexp beg (point)
  							nil nil state))))
  		  ;; Likewise for a comment.
***************
*** 915,922 ****
  				;; so go back to the real end of the comment.
  				(skip-chars-backward " \t"))
  			    (error (goto-char end))))
! 			(put-text-property beg (point) 'face
! 					   font-lock-comment-face)
  			(setq state (parse-partial-sexp beg (point)
  							nil nil state))))
  		  ;; Find each interesting place between here and END.
--- 952,959 ----
  				;; so go back to the real end of the comment.
  				(skip-chars-backward " \t"))
  			    (error (goto-char end))))
! 			(lazy-lock-put-text-property beg (point) 'face
! 						     font-lock-comment-face)
  			(setq state (parse-partial-sexp beg (point)
  							nil nil state))))
  		  ;; Find each interesting place between here and END.
***************
*** 944,951 ****
  				    ;; so go back to the real end of the comment.
  				    (skip-chars-backward " \t"))
  				(error (goto-char end))))
! 			    (put-text-property beg (point) 'face
! 					       font-lock-comment-face)
  			    (setq state (parse-partial-sexp here (point)
  							    nil nil state)))
  			(if (nth 3 state)
--- 981,988 ----
  				    ;; so go back to the real end of the comment.
  				    (skip-chars-backward " \t"))
  				(error (goto-char end))))
! 			    (lazy-lock-put-text-property
! 			     beg (point) 'face font-lock-comment-face)
  			    (setq state (parse-partial-sexp here (point)
  							    nil nil state)))
  			(if (nth 3 state)
***************
*** 953,960 ****
  			      (while (and (re-search-forward "\\s\"" end 'move)
  					  (nth 3 (parse-partial-sexp
  						  here (point) nil nil state))))
! 			      (put-text-property beg (point) 'face
! 						 font-lock-string-face)
  			      (setq state (parse-partial-sexp here (point)
  							      nil nil state))))))
  		    ;; Make sure PREV is non-nil after the loop
--- 990,997 ----
  			      (while (and (re-search-forward "\\s\"" end 'move)
  					  (nth 3 (parse-partial-sexp
  						  here (point) nil nil state))))
! 			      (lazy-lock-put-text-property
! 			       beg (point) 'face font-lock-string-face)
  			      (setq state (parse-partial-sexp here (point)
  							      nil nil state))))))
  		    ;; Make sure PREV is non-nil after the loop
***************
*** 1015,1025 ****
  		;; First set `text-prop' to nil for `font-lock-any-extents-p'.
  		(goto-char end) (forward-line 1) (setq end (point))
  		(goto-char beg) (beginning-of-line) (setq beg (point))
! 		(put-text-property beg end 'text-prop nil)
  		;; Then do the real `font-lock-after-change-function'.
  		(font-lock-after-change-function a-c-beg a-c-end old-len)
  		;; Now set `fontified' to t to stop `lazy-lock-fontify-window'.
! 		(put-text-property beg end 'fontified t))))))))))
  
  (if (and lazy-lock-running-xemacs-p (emacs-version>= 19 12))
      ;; XEmacs 19.12 font-lock.el's `font-lock-fontify-buffer' runs a hook.
--- 1052,1062 ----
  		;; First set `text-prop' to nil for `font-lock-any-extents-p'.
  		(goto-char end) (forward-line 1) (setq end (point))
  		(goto-char beg) (beginning-of-line) (setq beg (point))
! 		(lazy-lock-put-text-property beg end 'text-prop nil)
  		;; Then do the real `font-lock-after-change-function'.
  		(font-lock-after-change-function a-c-beg a-c-end old-len)
  		;; Now set `fontified' to t to stop `lazy-lock-fontify-window'.
! 		(lazy-lock-put-text-property beg end 'fontified t))))))))))
  
  (if (and lazy-lock-running-xemacs-p (emacs-version>= 19 12))
      ;; XEmacs 19.12 font-lock.el's `font-lock-fontify-buffer' runs a hook.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 03:50:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA22045 for xemacs-beta-people; Tue, 18 Jun 1996 03:50:31 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA22042 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 03:50:30 -0500 (CDT)
Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA01127 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 03:50:27 -0500 (CDT)
Received: from djp-fornet.cern.ch (djp-fornet.cern.ch [137.138.36.141]) by server21.digital.fr (8.7.3/8.7) with SMTP id KAA21170; Tue, 18 Jun 1996 10:48:19 +0200 (MET DST)
Received: by djp-fornet.cern.ch; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA13299; Tue, 18 Jun 1996 10:45:31 +0200
Date: Tue, 18 Jun 1996 10:45:31 +0200
Message-Id: <9606180845.AA13299@djp-fornet.cern.ch>
From: Stephen Carney <carney@xemacs.org>
To: xemacs-beta@xemacs.org
Cc: turner@lanl.gov
Subject: XEmacs 19.14-b25 build success on Digital UNIX V3.2D
In-Reply-To: <199606171854.MAA01990@gielgud.lanl.gov.xdiv>
References: <199606171854.MAA01990@gielgud.lanl.gov.xdiv>
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

After starting up VM, and doing `C-x m', I got a similar backtrace as
reported by John Turner.  After deleting the vm .elc's and `make all-elc',
the problem went away.

        Steve


Hardware  : DEC 3000-500
OS        : Digital UNIX V3.2D (41)
Compiler  : gcc-2.7.2
Libraries : X11R5, Motif, XAUTH, XPM, X-Face, DBM, GIF
XEmacs    : 19.14-b25 (full kit)

Configured for `alpha-dec-osf3.2'.
  Where should the build process find the source code?    /kits/install/xemacs/beta
  What installation prefix should install use?            /usr/local/xemacs-beta
  What operating system and machine description files should XEmacs use?
        `s/decosf3-2.h' and `m/alpha.h'
  What compiler should XEmacs be built with?              gcc -g2 -O3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? no
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 03:25:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA21952 for xemacs-beta-people; Tue, 18 Jun 1996 03:25:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA21949 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 03:25:02 -0500 (CDT)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA14918; Tue, 18 Jun 1996 03:25:02 -0500 (CDT)
Received: by venus.Sun.COM (Sun.COM)
	id BAA02877; Tue, 18 Jun 1996 01:24:32 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA13262; Mon, 17 Jun 1996 22:57:31 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA05771; Mon, 17 Jun 1996 22:57:29 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA06913; Mon, 17 Jun 1996 22:57:26 -0700
Date: Mon, 17 Jun 1996 22:57:26 -0700
Message-Id: <199606180557.WAA06913@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Chuck Thompson <cthomp@cs.uiuc.edu>,
        XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: --with-cde=no
Reply-To: Martin Buchholz <mrb@eng.sun.com>

Because XEmacs autodetects CDE, and CDE is typically only available in
shared library form, and CDE is hardly universally available on all
systems, I suggest building the binary packages without support for
CDE for 19.14.  I had to do this myself, so here's a patch for adding
the --with-cde=no option.  Since
``Why can't xemacs find libDtSvc.so?''
is going to be a FAQ anyway, perhaps --with-cde should default to no
for 19.14.

In 19.15, we can maybe use dlopen() and friends.

Anyways, here's a patch for enabling the --with-cde=no option
(includes status change for canna support):

*** /tmp/geta6897	Mon Jun 17 22:49:46 1996
--- configure.in	Sun Jun 16 14:24:00 1996
***************
*** 225,230 ****
--- 225,231 ----
  			(Lucid menubars and scrollbars are the default.
  			 Motif dialog boxes will be used if Motif can be
  			 found.)
+ --with-cde (*)          Compile in support for CDE drag and drop
  --with-xpm (*)		Compile with support for XPM files.
  			It is highly recommended that you obtain XPM
  			(version 3.4g or better) if you don't already
***************
*** 274,285 ****
  --with-epoch		Compile with additional Epoch compatibility.
  --with-i18n3		Compile with I18N level 3 (support for message
  			translation).  This doesn't currently work.
- --with-xim              Compile with support for X input methods.
  --with-mule		Compile with Mule (multi-lingual, including
  			Asian languages) support.
  --with-canna		Compile with support for Canna (an input method
  			used in conjunction with Mule support).
- 			This doesn't work yet.
  --with-wnn		Compile with support for WNN (an input method
  			used in conjunction with Mule support).
  			This doesn't work yet.
--- 275,286 ----
  --with-epoch		Compile with additional Epoch compatibility.
  --with-i18n3		Compile with I18N level 3 (support for message
  			translation).  This doesn't currently work.
  --with-mule		Compile with Mule (multi-lingual, including
  			Asian languages) support.
+ --with-xim              Compile with support for X input methods,
+                         used in conjunction with Mule support.
  --with-canna		Compile with support for Canna (an input method
  			used in conjunction with Mule support).
  --with-wnn		Compile with support for WNN (an input method
  			used in conjunction with Mule support).
  			This doesn't work yet.
***************
*** 633,638 ****
--- 634,655 ----
            eval "${opt}=\"${val}\""
          ;;
  
+         ## Has the user requested CDE support?
+ 	"with_cde" )
+ 	  ## Make sure the value given was either "yes" or "no".
+ 	  case "${val}" in
+ 	    y | ye | yes )	val=yes ;;
+ 	    n | no )		val=no  ;;
+ 	    * )
+ 	      (echo "${progname}: the \`--${optname}' option is supposed to have a boolean value.
+ Set it to either \`yes' or \`no'."
+ 	       echo "${short_usage}") >&2
+ 	      exit 1
+ 	    ;;
+ 	  esac
+           eval "${opt}=\"${val}\""
+         ;;
+ 
          ## Has the user requested XPM support?
  	"with_xpm" )
  	  ## Make sure the value given was either "yes" or "no".
***************
*** 2814,2819 ****
--- 2831,2837 ----
      ] AC_WARN(--with-toolbars ignored:  Not valid without X support) [
      with_toolbars='no'
    fi
+   with_cde='no'
    with_menubars='no'
    with_scrollbars='no'
    with_dialogs='no'
***************
*** 3235,3254 ****
  #
  # See if we can find CDE.
  #
- with_cde='no'
  if test "${window_system}" != "none" ; then
!   internal_cde_lib_found='no'
!   AC_HAVE_LIBRARY(-lDtSvc, internal_cde_lib_found='yes')
!   if test "${internal_cde_lib_found}" = "yes" ; then
!     internal_cde_includes_found='no'
!     for arg in ${DEFS} /usr/include
!     do
!       if test -f `echo "${arg}/Dt/Dt.h" | sed 's/^\-I//'` ; then
!   	internal_cde_includes_found='yes'
        fi
-     done
-     if test "${internal_cde_includes_found}" = "yes" ; then
-       with_cde='yes'
      fi
    fi
  fi
--- 3253,3275 ----
  #
  # See if we can find CDE.
  #
  if test "${window_system}" != "none" ; then
!   if test "${with_cde}" != "no" ; then
!     if test "${with_cde}" != "yes" ; then
!       internal_cde_lib_found='no'
!       AC_HAVE_LIBRARY(-lDtSvc, internal_cde_lib_found='yes')
!       if test "${internal_cde_lib_found}" = "yes" ; then
!         internal_cde_includes_found='no'
!         for arg in ${DEFS} /usr/include
!           do
!             if test -f `echo "${arg}/Dt/Dt.h" | sed 's/^\-I//'` ; then
!   	      internal_cde_includes_found='yes'
!             fi
!           done
!         if test "${internal_cde_includes_found}" = "yes" ; then
!           with_cde='yes'
!         fi
        fi
      fi
    fi
  fi
***************
*** 4376,4382 ****
    echo "  Compiling in Mule (multi-lingual) support."
  fi
  if [ "$with_canna" = "yes" ]; then
!   echo "  Compiling in support for Canna on Mule (doesn't currently work)."
  fi
  if [ "$with_wnn" = "yes" ]; then
    echo "  Compiling in support for WNN on Mule (doesn't currently work)."
--- 4397,4403 ----
    echo "  Compiling in Mule (multi-lingual) support."
  fi
  if [ "$with_canna" = "yes" ]; then
!   echo "  Compiling in support for Canna on Mule."
  fi
  if [ "$with_wnn" = "yes" ]; then
    echo "  Compiling in support for WNN on Mule (doesn't currently work)."

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 04:27:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA22234 for xemacs-beta-people; Tue, 18 Jun 1996 04:27:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA22231 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 04:27:26 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA01148 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 04:27:23 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id SAA23242; Tue, 18 Jun 1996 18:27:24 +0900 (JST)
Message-Id: <199606180927.SAA23242@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: [19.14 b25] crashed
Mime-Version: 1.0 (SEMI mime-edit 0.26)
Content-Type: multipart/mixed;
 boundary="Multipart_Tue_Jun_18_18:27:21_1996-1"
Content-Transfer-Encoding: 7bit
Date: Tue, 18 Jun 1996 18:27:24 JST
Sender: morioka@jaist.ac.jp

--Multipart_Tue_Jun_18_18:27:21_1996-1
Content-Type: text/plain; charset=US-ASCII

  XEmacs 19.14 is crashed.

  It is similar to 20.0 crashing.

Configured for `sparc-sun-sunos4shr'.

  Where should the build process find the source code?    /usr/src/GNU/emacs/xemacs-19.14-b25
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sunos4-0shr.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/local/X11R6/include
  Where do we find X Windows libraries?                   /usr/local/X11R6/lib
  Additional header files:                                /usr/local/include/jpeg
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


--Multipart_Tue_Jun_18_18:27:21_1996-1
Content-Type: text/plain; charset=ISO-2022-INT-1

1996/06/18 (Tue) 18:24 [2]
  is28e1s91:/home/fs109/morioka % xemacs&
[1] 2240
1996/06/18 (Tue) 18:25 [3]
  is28e1s91:/home/fs109/morioka % Fatal error: assertion failed, file frame.c, line 806, RECORD_TYPEP (console, lrecord_device) || MARKED_RECORD_P (console)

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb `which xemacs` core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  last-nonminibuf-frame()
  # bind (window old-frame target-frame explicit-frame)
  byte-code("@)IE .-BF G!I!,[2]-G[0]JI\"-)I
#+-MOP
#\"[2]-H[0]Q!S!+-C)
+$@(BS
!,[2]-G[0]JS
\"

	.-FE .-BF \n=,-C@,$A(BTU !=+[2]-H[0]OPVU !\"[2][0],gW!,(J(BYW!\"+-MZ![2]-H[0]OPVU !\"[2][0])I+?@;+(J(B^W!\",$(H(B:+[0]YW!#\")I+-LOP\"A\"\"[2]-H[0])$)I+G@;+$)C^W!\"+)IOP\"!\"[2]-H[0]:+@;+erp wrong-type-argument pre-display-buffer-function not-this-window-p override-frame display-buffer-function throw done buffer-dedicated-frame dedi frame-live-p window-buffer selected-window display-buffer-1 buffer-name same-window-buffer-names assoc switch-to-buffer same-window-regexps tem car string-match pop-up-frames 0 get-buffer-window special-display-function special-display-buffer-names special-display-regexps frame-selected-window pop-up-frame-function set-window-buffer pop-up-wi!
!
ndows frame-property minibuffer only window-dedicated-p frame-root-window split-height-threshold window-min-height split-width-threshold window-min-width unsplittable get-largest-window visible t window-frame window-height window-width window-leftmost-p window-rightmost-p split-window other lower upper get-lru-window window-parent window-previous-child window-next-child window-pixel-edges window-pixel-height enlarge-window 2 save-selected-window-window ((byte-code "@	!+-DB	![2]-H[0]@[2]-G[0]" ... 2)) select-window record-buffer] 7)$)C
  # (catch done ...)
  # bind (override-frame not-this-window-p buffer)
  display-buffer(#<buffer "*Warnings*">)
  # bind (buffer)
  display-warning-buffer()
  # (condition-case ... . error)
  # bind (inhibit-quit)
  # (condition-case ... . error)
  # (catch top-level ...)

[1]    IOT trap               xemacs

--Multipart_Tue_Jun_18_18:27:21_1996-1
Content-Type: text/plain; charset=US-ASCII

-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---
--Multipart_Tue_Jun_18_18:27:21_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 05:01:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA22316 for xemacs-beta-people; Tue, 18 Jun 1996 05:01:31 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA22313 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 05:01:30 -0500 (CDT)
Received: from netcom2.netcom.com (root@netcom2.netcom.com [192.100.81.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA01171 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 05:01:28 -0500 (CDT)
Received: from netcom11.netcom.com (wing@netcom11.netcom.com [192.100.81.121]) by netcom2.netcom.com (8.6.13/Netcom)
	id DAA27414; Tue, 18 Jun 1996 03:01:31 -0700
Date: Tue, 18 Jun 1996 03:01:31 -0700
Message-Id: <199606181001.DAA27414@netcom2.netcom.com>
From: wing@netcom.com (Ben Wing)
To: dkindred+@cmu.edu, xemacs-beta@xemacs.org
Subject: Re:  buffer-menu sorting

>The new buffer-menu grouping/sorting is interesting, but it has the
>disadvantage that truncating the menu after some number of entries no
>longer really makes sense since the lower entries are no less
>"significant" than the upper ones.  Of course we have to truncate
>somehow to avoid exceeding screen size, and I can't think of any
>non-arbitrary way to do that for alphabetically sorted buffers, so
>maybe it's not worth worrying about.  

Well, the truncation still occurs based on most-recently-used, regardless
of the sorting/grouping.

However, for "submenus-for-groups" it should probably truncate to 25
per submenu, or something.

It's possible to make life easier in the alphabetical world by grouping
alphabetically -- e.g. one submenu for [a-h], another for [i-p],
another for [q-z].  Using the default "by mode" grouping, you'd have
"C", "Java [a-h]", "Java [i-z]", etc.

Of course it would be really snazzy if it automatically put submenus
like this in when the number of items got too large, but didn't do
so otherwise.  An exercise for an enthusiastic Lisp coder no doubt ...

>Perhaps the default buffer menu size could be increased from 15 to 25
>or so, so this problem doesn't bite as often.

Well, the default is in fact at 20, but I agree -- Chuck, could you
make this change?

ben

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 05:50:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA22450 for xemacs-beta-people; Tue, 18 Jun 1996 05:50:12 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA22447 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 05:50:11 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA18027 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 05:50:10 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id LAA27319 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 11:51:21 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id LAA21655 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 11:51:13 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id LAA07778; Tue, 18 Jun 1996 11:54:35 +0100
Date: Tue, 18 Jun 1996 11:54:35 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606181054.LAA07778@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: Func-menu
X-Sun-Charset: US-ASCII

It would be nice if function menu had a `stealth-scan' mode whereby the
buffer was only initially scanned when you switched to it. When I
load up my 150 buffers most of the time is spent by func-menu scanning.

andy

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 06:03:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA22481 for xemacs-beta-people; Tue, 18 Jun 1996 06:03:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA22478 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 06:03:19 -0500 (CDT)
Received: from gatekeeper.abs.alcatel.co.uk (firewall-user@gatekeeper.abs.alcatel.co.uk [194.34.58.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA18259 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 06:02:05 -0500 (CDT)
Received: from unknown(194.36.210.121) by gatekeeper.abs.alcatel.co.uk via smap (g3.0.3)
	id xma008635; Tue, 18 Jun 96 11:54:31 +0100
Received: from ariel.uk.abs by rd.abs.alcatel.co.uk  (4.1/SMI-4.1)
	id AA07830; Tue, 18 Jun 96 11:55:57 BST
Received: by ariel.uk.abs (SMI-8.6/SMI-SVR4)
	id LAA22397; Tue, 18 Jun 1996 11:55:58 +0100
Date: Tue, 18 Jun 1996 11:55:58 +0100
Message-Id: <199606181055.LAA22397@ariel.uk.abs>
From: imac@rd.abs.alcatel.co.uk
To: xemacs-beta@cs.uiuc.edu
Subject: 19.14b25 OK on Solaris

Built 19.14b25 ok on Solaris2.5

Tried the new buffers-menu patch, this is similar in some respects to
the infodock jump-menu, and I like it
Ian

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 06:22:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA22560 for xemacs-beta-people; Tue, 18 Jun 1996 06:22:14 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA22557 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 06:22:13 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA18486 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 06:22:13 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA11700; Tue, 18 Jun 1996 13:22:10 +0200
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA17878; Tue, 18 Jun 1996 13:22:09 +0200
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@cs.uiuc.edu
Subject: AIX gcc patch
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 18 Jun 1996 13:22:08 +0200
Message-Id: <y9ln3215pcv.fsf@modas.informatik.uni-tuebingen.de>
Lines: 21
X-Mailer: Gnus v5.2.19/XEmacs 19.14


I mentioned this about a dozen beta ago but never got around to making
a patch.  Here goes ...

Cheers =8-} Mike

*** src/s/aix3-2.h~	Sun Jun  2 02:11:45 1996
--- src/s/aix3-2.h	Tue Jun 18 12:02:32 1996
***************
*** 18,23 ****
--- 18,27 ----
     dkeller@VNET.IBM.COM */
  #define C_SWITCH_SYSTEM -ma -qmaxmem=-1
  #endif
+ #ifdef __GNUC__
+ /* Otherwise, XEmacs is just too big ... */
+ #define C_SWITCH_SYSTEM -mminimal-toc
+ #endif
  
  #define HAVE_ALLOCA
  /* Adrian Colley <Adrian.Colley@three.serpentine.com> says this is needed.  */

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 06:21:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA22553 for xemacs-beta-people; Tue, 18 Jun 1996 06:21:35 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA22550 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 06:21:34 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA18483 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 06:21:28 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA16817; Tue, 18 Jun 1996 13:21:24 +0200
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA17790; Tue, 18 Jun 1996 13:21:23 +0200
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [19.14 b25] crashed - me too
References: <199606180927.SAA23242@mikan.jaist.ac.jp>
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 18 Jun 1996 13:21:22 +0200
In-Reply-To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of Tue, 18 Jun 1996 18:27:24 JST
Message-Id: <y9lohmh5pe5.fsf@modas.informatik.uni-tuebingen.de>
Lines: 26
X-Mailer: Gnus v5.2.19/XEmacs 19.14

>>>>> "MT" == MORIOKA Tomohiko <ISO-2022-JP> writes:

MT>   XEmacs 19.14 is crashed.

MT>   It is similar to 20.0 crashing.

MT> Configured for `sparc-sun-sunos4shr'.

MT> [ ... ]

MT> [2  (text/plain)]
MT> 1996/06/18 (Tue) 18:24 [2]
MT>   is28e1s91:/home/fs109/morioka % xemacs&
MT> [1] 2240
MT> 1996/06/18 (Tue) 18:25 [3]
MT>   is28e1s91:/home/fs109/morioka % Fatal error: assertion failed, file frame.c, line 806, RECORD_TYPEP (console, lrecord_device) || MARKED_RECORD_P (console)

MT> Fatal error (6).
MT> Your files have been auto-saved.
MT> Use `M-x recover-session' to recover them.

MT> [ ... ]

I see the same problem on AIX 4.1.4.

Cheers =8-} Mike

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 07:01:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA22687 for xemacs-beta-people; Tue, 18 Jun 1996 07:01:01 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA22684 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 07:01:00 -0500 (CDT)
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA18818 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 07:00:59 -0500 (CDT)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0uVzSo-00002AC>; Tue, 18 Jun 96 14:00 MET DST
Message-Id: <m0uVzSo-00002AC@susan.logware.de>
Date: Tue, 18 Jun 96 14:00 MET DST
From: Michael Diers <mdiers@logware.de>
To: XEmacs beta list <xemacs-beta@cs.uiuc.edu>
Subject: Re: [19.14-b25] update-elc.sh doesn't
In-Reply-To: <m0uVz9L-00002AC@susan.logware.de>
References: <m0uVz9L-00002AC@susan.logware.de>

Michael Diers <mdiers@logware.de> wrote:

> I see this both under Linux and FreeBSD: Compiling Gnus...
> /usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs
> -batch -q -no-site-file -l ./dgnushack.el -f dgnushack-recompile 
> *** Error code 255

>    Stop.  Gnus done.

When patching up to b25, doing a

  rm lisp/gnus/*.elc

takes care of the problem with update-elc.sh.

-Michael

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 07:21:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA22777 for xemacs-beta-people; Tue, 18 Jun 1996 07:21:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA22774 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 07:21:15 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA19016 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 07:21:10 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA16177; Tue, 18 Jun 1996 14:21:05 +0200
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA19562; Tue, 18 Jun 1996 14:21:04 +0200
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [19.14 b25] crashed - me too
References: <199606180927.SAA23242@mikan.jaist.ac.jp>
	<y9lohmh5pe5.fsf@modas.informatik.uni-tuebingen.de>
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 18 Jun 1996 14:21:03 +0200
In-Reply-To: sperber@informatik.uni-tuebingen.de's message of 18 Jun 1996 13:21:22 +0200
Message-Id: <y9lenndnw0g.fsf@modas.informatik.uni-tuebingen.de>
Lines: 6
X-Mailer: Gnus v5.2.19/XEmacs 19.14


Of course, Chuck's patch fixed it.  I got the patch before b25 came
out, so I assumed it was relative to b24 ... :-)

Cheers =8-} Mike


From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 07:19:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA22770 for xemacs-beta-people; Tue, 18 Jun 1996 07:19:43 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA22767 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 07:19:42 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA18976; Tue, 18 Jun 1996 07:19:43 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.51 #1)
	id E0uVzkw-0002lg-00; Tue, 18 Jun 1996 08:19:38 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: 20.0-b25 loses on Linux 2.0 w/ PNG 
In-Reply-To: <199606180412.XAA29151@charles.cs.uiuc.edu>
References: <m2lohmb2k1.fsf@deanna.miranova.com>
	<199606180412.XAA29151@charles.cs.uiuc.edu>
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uVzkw-0002lg-00@neal.ctd.comsat.com>
Date: Tue, 18 Jun 1996 08:19:38 -0400

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

    Steven> I am using libgr-2.0.5 for PNG support, and haven't had
    Steven> problems with this previously.  This was also from a full
    Steven> distribution, not patched up.

    Chuck> As of libgr-2.0.7 it is still including libpng 0.81.  The latest
    Chuck> version is 0.88.  The non-temp file support needs a version somewhere
    Chuck> between 0.82 and 0.87.  I've changed it to assume at least 0.87 which
    Chuck> is as far back as I can verify.

    Chuck> I would suggest bitching to whoever packages up libgr.

Your bitch has been received.  I haven't done anything to libgr for a
while now.  After adding the latest tiff stuff and struggling with the
version numbers (change the major number? or not?)  I spoke to that
package's author.  He said that he didn't want to support shared
libtiff, and didn't want to worry about compatibility between
versions.  After this, I began wondering if all these shared libs are
such a good idea anyway.  If you think we should have a new libgr I'll
put one out.  I guess we should also fix the -DBSD problem at the same
time?  It seems that this was the general concensus?

I also have patches from someone to port libgr to a number of other
platforms.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 07:35:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA22829 for xemacs-beta-people; Tue, 18 Jun 1996 07:35:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA22826 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 07:35:37 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA01236 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 07:35:36 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA00096 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 07:35:37 -0500 (CDT)
Message-Id: <199606181235.HAA00096@charles.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: crashes@xemacs.org address
Date: Tue, 18 Jun 1996 07:35:36 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

A number of you have actually noticed the new message that gets
printed when XEmacs dies, requesting that various information be sent
to crashes@xemacs.org.  Good eyes :-)  However, beta testers should
continue to send all reports of problems with beta versions to
xemacs-beta@xemacs.org.  At least for now.  An overhaul of the beta
mailing lists is rapidly approaching.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 06:41:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA22641 for xemacs-beta-people; Tue, 18 Jun 1996 06:41:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA22638 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 06:41:29 -0500 (CDT)
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA18637 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 06:41:19 -0500 (CDT)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0uVz9L-00002AC>; Tue, 18 Jun 96 13:40 MET DST
Message-Id: <m0uVz9L-00002AC@susan.logware.de>
Date: Tue, 18 Jun 96 13:40 MET DST
From: Michael Diers <mdiers@logware.de>
To: XEmacs beta list <xemacs-beta@cs.uiuc.edu>
Subject: [19.14-b25] update-elc.sh doesn't

I see this both under Linux and FreeBSD:

   Compiling Gnus...
   /usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -l ./dgnushack.el -f dgnushack-recompile
   
   *** Error code 255

   Stop.
   Gnus done.

Trace below:

$ gnumake beta
[...]
sh /usr/contrib/pub/src/xemacs-19.14-b25/lib-src/update-elc.sh
 (using ./src/xemacs)
Recompiling in /usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1
          with /usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs...
Deleting .elc files without .el files...done.
Checking the byte compiler...
Compiling files without .elc...

Done.
Compiling VM...making vm-search.el...
scanning sources to build autoload definitions...
compiling vm-autoload.el...

compiling vm-delete.el...

compiling vm-digest.el...

compiling vm-edit.el...

compiling vm-folder.el...

compiling vm-license.el...

compiling vm-mark.el...

compiling vm-menu.el...

compiling vm-message.el...

compiling vm-minibuf.el...

compiling vm-misc.el...

compiling vm-mouse.el...

compiling vm-motion.el...

compiling vm-page.el...

compiling vm-pop.el...

compiling vm-reply.el...

compiling vm-save.el...

compiling vm-search.el...

compiling vm-sort.el...

compiling vm-summary.el...

compiling vm-startup.el...

compiling vm-thread.el...

compiling vm-toolbar.el...

compiling vm-undo.el...

compiling vm-vars.el...

compiling vm-version.el...

compiling vm-virtual.el...

compiling vm-window.el...

building vm.elc (with all modules set to autoload)...
# in case the -f flag doesn't exist (e.g. on HPUX)
chmod +w .autoload
touch -f .autoload || touch .autoload
done.
Compiling EDIFF...

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -l ./ediff-init.el -l ./ediff-diff.el -l ./ediff-wind.el  -l ./ediff-merg.el -l ./ediff-mult.el -l ./ediff-util.el  -l ./ediff.el -f batch-byte-compile ediff-diff.el


/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -l ./ediff-init.el -l ./ediff-diff.el -l ./ediff-wind.el  -l ./ediff-merg.el -l ./ediff-mult.el -l ./ediff-util.el  -l ./ediff.el -f batch-byte-compile ediff-util.el


/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -l ./ediff-init.el -l ./ediff-diff.el -l ./ediff-wind.el  -l ./ediff-merg.el -l ./ediff-mult.el -l ./ediff-util.el  -l ./ediff.el -f batch-byte-compile ediff.el

EDIFF done.
Compiling Viper...

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -f batch-byte-compile viper-util.el


/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -l viper-util.el -l viper-ex.el -l viper-mous.el  -l viper-macs.el -l viper-keym.el -l viper.el -f batch-byte-compile viper-mous.el


/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -l viper-util.el -l viper-ex.el -l viper-mous.el  -l viper-macs.el -l viper-keym.el -l viper.el -f batch-byte-compile viper-ex.el


/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -l viper-util.el -l viper-ex.el -l viper-mous.el  -l viper-macs.el -l viper-keym.el -l viper.el -f batch-byte-compile viper-macs.el


/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -l viper-util.el -l viper-ex.el -l viper-mous.el  -l viper-macs.el -l viper-keym.el -l viper.el -f batch-byte-compile viper-keym.el


/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -l viper-util.el -l viper-ex.el -l viper-mous.el  -l viper-macs.el -l viper-keym.el -l viper.el -f batch-byte-compile viper.el

Viper done.
Compiling Gnus...
/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -l ./dgnushack.el -f dgnushack-recompile

*** Error code 255

Stop.
Gnus done.
Compiling URL...
/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -l ./url-vars.el -l ./docomp.el -f batch-byte-compile url-file.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -l ./url-vars.el -l ./docomp.el -f batch-byte-compile url-nfs.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -l ./url-vars.el -l ./docomp.el -f batch-byte-compile url-irc.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -l ./url-vars.el -l ./docomp.el -f batch-byte-compile url-http.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -l ./url-vars.el -l ./docomp.el -f batch-byte-compile url-misc.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -l ./url-vars.el -l ./docomp.el -f batch-byte-compile url-vars.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -l ./url-vars.el -l ./docomp.el -f batch-byte-compile md5.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -l ./url-vars.el -l ./docomp.el -f batch-byte-compile url.el

Build of url complete...
URL done.
Compiling W3...
Compiling w3.el

Compiling w3-forms.el

Compiling widget-edit.el

Compiling w3-speak.el

Compiling w3-prefs.el

Build of w3 complete...
W3 done.
Compiling Hyperbole...
Hyperbole done.
Compiling OO-Browser...
OO-Browser done.
Compiling EOS...
/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -f batch-byte-compile sun-eos-browser.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -f batch-byte-compile sun-eos-debugger-extra.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -f batch-byte-compile sun-eos-debugger.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -f batch-byte-compile sun-eos-editor.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -f batch-byte-compile sun-eos-init.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -f batch-byte-compile sun-eos-menubar.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -f batch-byte-compile sun-eos-toolbar.el

/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -q -no-site-file -f batch-byte-compile sun-eos-load.el

EOS done.
Compiling Ilisp...
/usr/contrib/pub/build/xemacs-19.14-b25-i386-unknown-freebsd2.1/src/xemacs -batch -l ilisp-mak.el

Ilisp done.
Compiling files with out-of-date .elc...


From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 07:43:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA22883 for xemacs-beta-people; Tue, 18 Jun 1996 07:43:25 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA22880 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 07:43:24 -0500 (CDT)
Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA01249 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 07:43:20 -0500 (CDT)
Received: from herr (herr.first.gmd.de) by prosun.first.gmd.de (4.1/SMI-4.1)
	id AA11504; Tue, 18 Jun 96 14:42:57 +0200
Sender: sh@prosun.first.gmd.de
Message-Id: <31C6A452.794BDF32@first.gmd.de>
Date: Tue, 18 Jun 1996 14:42:58 +0200
From: Stephan Herrmann <sh@prosun.first.gmd.de>
Organization: GMD-FIRST
X-Mailer: Mozilla 2.02 (X11; I; SunOS 4.1.3_U1 sun4m)
Mime-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: b25 : assert in frame.c: VM and others crash on SunOS4.1.3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry for unnessesarily repeating this Bug message.
My mail reader (vm) was broken, so I didn't find Chuck's patch...

Stephan
-- 
--------------------------------------------------------------------------
			  Stephan Herrmann
			  ----------------
	GMD-FIRST				   TU-Berlin
 Gesellschaft f. Mathematik			 FB Informatik
   u. Datenverarbeitung				Softwaretechnik 
     sh@first.gmd.de			    stephan@cs.tu-berlin.de
  Phone: ++49 30 6392 1870
--------------------------------------------------------------------------

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 07:06:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA22709 for xemacs-beta-people; Tue, 18 Jun 1996 07:06:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA22706 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 07:06:39 -0500 (CDT)
Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA01216 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 07:06:07 -0500 (CDT)
Received: from herr (herr.first.gmd.de) by prosun.first.gmd.de (4.1/SMI-4.1)
	id AA10983; Tue, 18 Jun 96 14:06:06 +0200
Sender: sh@prosun.first.gmd.de
Message-Id: <31C69BAF.41C67EA6@first.gmd.de>
Date: Tue, 18 Jun 1996 14:06:07 +0200
From: Stephan Herrmann <sh@prosun.first.gmd.de>
Organization: GMD-FIRST
X-Mailer: Mozilla 2.02 (X11; I; SunOS 4.1.3_U1 sun4m)
Mime-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: b25 : assert in frame.c: VM and others crash on SunOS4.1.3
Content-Type: multipart/mixed; boundary="------------167EB0E72781E494446B9B3D"

This is a multi-part message in MIME format.

--------------167EB0E72781E494446B9B3D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've seen similar reports without C-backtrace, I haven't seen 
any answer to this, so here is my problem: 
various pieces of lisp code cause crashes in frame.c (assertion at line
806).
The simplest way, to reproduce :
  xemacs -q
  call vm via the "mail" button (toolbar).

Included are configuration summary and backtraces.

Hope this helps
Stephan


-- 
--------------------------------------------------------------------------
			  Stephan Herrmann
			  ----------------
	GMD-FIRST				   TU-Berlin
 Gesellschaft f. Mathematik			 FB Informatik
   u. Datenverarbeitung				Softwaretechnik 
     sh@first.gmd.de			    stephan@cs.tu-berlin.de
  Phone: ++49 30 6392 1870
--------------------------------------------------------------------------

--------------167EB0E72781E494446B9B3D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="config.summary"

Configured for `sparc-sun-sunos4.1.3'.

  Where should the build process find the source code?    /export/herr/sh/compile/xemacs-19.14-b25
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sunos4-1-3shr.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /opt/X11R6/include
  Where do we find X Windows libraries?                   /opt/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Compiling in support for ToolTalk.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


--------------167EB0E72781E494446B9B3D
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; filename="vm.dump"

 Fatal error: assertion failed, file frame.c, line 806, RECORD_TYPEP (conso=
le, lrecord_device) || MARKED_RECORD_P (console)

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb `which xemacs` core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  last-nonminibuf-frame()
  # bind (window old-frame target-frame explicit-frame)
  byte-code("=C0 =AE=C6 !=AC=CA\"
                      =AD

#=AB=CF=D0
\"=CA=D3=D3!=AB)=AE=C5 =AE=C6 =

              \n=3D=AC=C0

                   =D4=D5 !=3D=AB=CF=D0=D6=D5 !\"
                                 =AC=E7!=AC=D9!\"=AB!=CF=D0=D6=D5 !\"=BF@;=AB=
=DE!\"=AC:=AB@;=AB=DE@!\"=AB!=CF=D0=D6=D5 !\")A=ACA)   =AC=AC=C5 =AC=E0\n\"=
=AB
                   =AB
                    =D5 =3D=AC=CF=D0=D6
                           !\"\"=AB=FB!#=AB=CF=D0\!\"=D9!#\"=AB=CF=D0\A\"\"=
)$=AB=C7@;=AB=DE!\"=AB=CF=D0\!\":=AB@;=AB=DE@!\"=AB=CF=D0\A\"\")A=AC9)=AC=C5=
 =AC=E5& !=E7
                           \"=CF=D0=D6
                                !\"(=AB\n
                                       =3D=AC=E9=C6 =EA\"=EB=3D=AC=EC=ED=C6=
 !!=FE=E9=C6 =EA\"=EB=3D=AB=C5 ./\\W=AB/\\.01\\W=AB1\\0=E9\n=AC=C6 =AA=C5 =F2=
\"=AB=F3=F4!=AE=F3=E0!=AE=F3=F5!=AA=F3\n!
                                     =AB=A9=E9=F6
                                         !=F2\"=AC=A1=F7
                                                !.Y=AB=F8
                                                     !0Y=AC=F9
                                                          !=AB=FA
                                                             !=AB=FB
                                                                !=C0<=3D>=FF=
\n!=AB=A3=E9=F6
                                                                           =
  !=F2\"=AC
  =D5 =3D=AC@
       !=AC=F7
          !/\\Y=AB=FB
                 !
                  =AC=F3=F4!=AE=F3=E0!=AE=F3=F5!=AE=E5& !A
                                    !=ABA
                                       !<>
                                          =3DB
                                            !=ABB
                                               !<=3D
                                                  ><=AB=B9C<!A@C
                                                            !A@U=AC=A7D<!D
                                                                      !V=AB=
E=F7<!=F7
                                                                           =
   !\\F=A5=F7>!Z=C0>#+=AA=FF\n!=D4
                 !=AB=D5 GHI
                        !J=D4
                           !!+=E7
                              \"=D6
                                 !," [nil explicit-frame target-frame old-f=
rame window last-nonminibuf-frame selected-frame get-buffer buffer bufferp =
wrong-type-argument pre-display-buffer-function not-this-window-p override-=
frame display-buffer-function throw done buffer-dedicated-frame dedi frame-=
live-p window-buffer selected-window display-buffer-1 buffer-name same-wind=
ow-buffer-names assoc switch-to-buffer same-window-regexps tem car string-m=
atch pop-up-frames 0 get-buffer-window special-display-function special-dis=
play-buffer-names special-display-regexps frame-selected-window pop-up-fram=
e-function set-window-buffer pop-up-windows frame-property minibuffer only =
window-dedicated-p frame-root-window split-height-threshold window-min-heig=
ht split-width-threshold window-min-width unsplittable get-largest-window v=
isible t window-frame window-height window-width window-leftmost-p window-r=
ightmost-p split-window other lower upper get-lru-window window-parent wind=
ow-previous-child window-next-child window-pixel-edges window-pixel-height =
enlarge-window 2 save-selected-window-window ((byte-code "=C0   !=AB=C2    =
!=C0" ... 2)) select-window record-buffer] 7)
  # (catch done ...)
  # bind (override-frame not-this-window-p buffer)
  display-buffer(#<buffer "INBOX">)
  # bind (pop-up-windows pop-up-frames buffer)
  vm-display-buffer(#<buffer "INBOX">)
  # bind (w)
  # (unwind-protect ...)
  # bind (vm-sbe-buffer configs commands display buffer)
  vm-display(#<buffer "INBOX"> t nil nil)
  # bind (full-startup folder-buffer first-time totals-blurb preserve-auto-=
save-file)
  byte-code("=C0  !?=C2     !=AB      =AA=DA      =AE=C8      \n\"
                                                    =CC
                                                     !=AB=CD=CE
                                                         \"=AA=C1=CF
                                                              !=AE=BB\n=AB=C8=
\n!=AE=D1=C2=D4=D5
                                                                           =
  \"=D6
                                                                           =
    !=AE       @=ACB)=D4=D9
=AB=EF =F0 =F1 =F2 =F3 =AB=C64=AB=C2=F5 =AB=BE6=AB=BA=F7p!=AE8=AD=F78!9=AC=E1=
=E2  \"=AB=FA=C1!=AA=FA=FB=C1\"=FC =AA=FD9!>=AB=FF@9!!))=ABA B C=ABD =AAE =AB=
Fp=D1=C2$=ABG =ABH=ABI J K=ABL =ABM =AB=AFFp=D1=C2$N =AB
                              =ACO=D1!F=C26C6=AEPQD$)RS!=ABT
                                                  !=AB
                                                    =ABTUV!!=AB
                                                           =ABWX=D1\"Y=AB=BE=
Z=AC=BA%=AC=B6=D4[ =AE\\ \"] =AB=EE=D1!=ABA B =ABD =AAE T
                     !^?=AD=A3_?=AD6`>=ACa?=ADb c ?=ADT
                                           !-" [bufferp folder nil preserve=
-auto-save-file totals-blurb first-time folder-buffer full-startup expand-f=
ile-name vm-primary-inbox vm-folder-directory file file-directory-p error "=
%s is a directory" vm-get-file-buffer default-directory t enable-local-vari=
ables inhibit-local-variables vm-unsaved-message "Reading %s..." find-file-=
noselect item vm-folder-history "Reading %s... done" vm-check-for-killed-su=
mmary buffer-modified-p 0 vm-messages-not-on-disk major-mode vm-mode buffer=
-file-name file-newer-than-file-p make-auto-save-file-name read-only defaul=
t-value vm-folder-read-only buffer-read-only fboundp buffer-disable-undo bu=
ffer-flush-undo x abbrev-mode auto-fill-mode vm-mode-internal vm-assimilate=
-new-messages vm-gobble-visible-header-variables vm-gobble-bookmark vm-gobb=
le-summary vm-gobble-labels vm-start-itimers-if-needed vm-frame-per-folder =
vm-multiple-frames-possible-p this-command vm-get-buffer-window vm-summary-=
buffer w vm-goto-new-frame primary-folder vm-set-hooks-for-frame-deletion s=
elect-window vm-warp-mouse-to-new-frame vm-warp-mouse-to-frame-maybe vm-win=
dow-frame vm-emit-totals-blurb vm-thoughtfully-select-message vm-message-li=
st vm-preview-current-message vm-update-summary-and-mode-line vm-display vm=
-toolbar-support-possible-p vm-use-toolbar vm-toolbar-install-toolbar vm-to=
olbar-update-toolbar vm-use-menus vm-menu-support-possible-p vm-menu-instal=
l-visited-folders-menu vm-should-generate-summary vm-summarize vm startup r=
un-hooks vm-visit-folder-hook message substitute-command-keys "Auto save fi=
le is newer; consider \\[recover-file].  FOLDER IS READ ONLY." throw done v=
m-auto-get-new-mail vm-block-new-mail "Checking for new mail for %s..." buf=
fer-name vm-get-spooled-mail vm-inhibit-startup-message vm-startup-message-=
displayed (vm vm-visit-folder) last-command vm-display-startup-message inpu=
t-pending-p] 7)
  # (catch done ...)
  # bind (read-only folder)
  vm()
  #<compiled-function (from "x-toolbar.elc") nil "...(50)" [toolbar-use-sep=
arate-mail-frame toolbar-mail-command toolbar-mail-frame frame-live-p make-=
frame add-hook vm-quit-hook (lambda nil ...) select-frame raise-frame frame=
-iconified-p deiconify-frame] 3 1192064 nil>()
  call-interactively(toolbar-mail)
  # bind (callback button event)
  release-and-activate-toolbar-button(#<buttonup-event button1up>)
  # bind (command-debug-status)
  call-interactively(release-and-activate-toolbar-button)
  # (condition-case ... . error)
  # (catch top-level ...)


#0  0xef590448 in kill ()
#1  0x4bf90 in fatal_error_signal (sig=3D6) at emacs.c:193
#2  <signal handler called>
#3  0xef590448 in kill ()
#4  0x4de5c in assert_failed (file=3D0xaa288 "frame.c", line=3D806, =

    expr=3D0xace50 "RECORD_TYPEP (console, lrecord_device) || MARKED_RECORD=
_P (console)") at emacs.c:1787
#5  0xacf28 in Flast_nonminibuf_frame (console=3D272398976) at frame.c:806
#6  0x54708 in primitive_funcall (fn=3D0xace94 <Flast_nonminibuf_frame>, =

    nargs=3D1, args=3D0xefffcdf0) at eval.c:3484
#7  0x5488c in funcall_subr (subr=3D0x21bdf8, args=3D0xefffcdf0) at eval.c:=
3526
#8  0x53ba8 in funcall_recording_as (recorded_as=3D270646776, nargs=3D0, =

    args=3D0xefffcef8) at eval.c:3204
#9  0x53cfc in Ffuncall (nargs=3D1, args=3D0xefffcef8) at eval.c:3253
#10 0x1c0b8 in Fbyte_code (bytestr=3D807952204, vector=3D1076388492, =

    maxdepth=3D2645858) at bytecode.c:450
#11 0x54734 in primitive_funcall (fn=3D0x1b990 <Fbyte_code>, nargs=3D3, =

    args=3D0xefffd178) at eval.c:3488
#12 0x5488c in funcall_subr (subr=3D0x217950, args=3D0xefffd178) at eval.c:=
3526
#13 0x53714 in Feval (form=3D539516732) at eval.c:3064
#14 0x5072c in internal_catch (tag=3D271956572, func=3D0x52ec4 <Feval>, =

    arg=3D539516732, threw=3D0x0) at eval.c:1347
#15 0x1c520 in Fbyte_code (bytestr=3D807952092, vector=3D1076387616, =

    maxdepth=3D2645741) at bytecode.c:645
#16 0x54d64 in funcall_lambda (fun=3D271082516, nargs=3D1, arg_vector=3D0xe=
fffd5e8)
    at eval.c:3636
#17 0x53c98 in funcall_recording_as (recorded_as=3D271082516, nargs=3D1, =

    args=3D0xefffd5e4) at eval.c:3223
#18 0x53cfc in Ffuncall (nargs=3D2, args=3D0xefffd5e4) at eval.c:3253
#19 0x1c0b8 in Fbyte_code (bytestr=3D810314164, vector=3D1078602240, =

    maxdepth=3D4888056) at bytecode.c:450
#20 0x54d64 in funcall_lambda (fun=3D272927780, nargs=3D1, arg_vector=3D0xe=
fffd874)
    at eval.c:3636
#21 0x53c98 in funcall_recording_as (recorded_as=3D272927780, nargs=3D1, =

    args=3D0xefffd870) at eval.c:3223
#22 0x53cfc in Ffuncall (nargs=3D2, args=3D0xefffd870) at eval.c:3253
#23 0x1c0b8 in Fbyte_code (bytestr=3D810313780, vector=3D1078718080, =

    maxdepth=3D4887854) at bytecode.c:450
#24 0x54d64 in funcall_lambda (fun=3D272927748, nargs=3D4, arg_vector=3D0xe=
fffdb04)
    at eval.c:3636
#25 0x53c98 in funcall_recording_as (recorded_as=3D272927748, nargs=3D4, =

    args=3D0xefffdb00) at eval.c:3223
#26 0x53cfc in Ffuncall (nargs=3D5, args=3D0xefffdb00) at eval.c:3253
#27 0x1c0b8 in Fbyte_code (bytestr=3D808783484, vector=3D1077081088, =

    maxdepth=3D4287717) at bytecode.c:450
#28 0x54734 in primitive_funcall (fn=3D0x1b990 <Fbyte_code>, nargs=3D3, =

    args=3D0xefffdd80) at eval.c:3488
#29 0x5488c in funcall_subr (subr=3D0x217950, args=3D0xefffdd80) at eval.c:=
3526
#30 0x53714 in Feval (form=3D541052076) at eval.c:3064
#31 0x5072c in internal_catch (tag=3D271956572, func=3D0x52ec4 <Feval>, =

    arg=3D541052076, threw=3D0x0) at eval.c:1347
#32 0x1c520 in Fbyte_code (bytestr=3D808783436, vector=3D1078064064, =

    maxdepth=3D4287338) at bytecode.c:645
#33 0x54d64 in funcall_lambda (fun=3D272927140, nargs=3D0, arg_vector=3D0xe=
fffe1e4)
    at eval.c:3636
#34 0x53c98 in funcall_recording_as (recorded_as=3D272927140, nargs=3D0, =

    args=3D0xefffe1e0) at eval.c:3223
#35 0x53cfc in Ffuncall (nargs=3D1, args=3D0xefffe1e0) at eval.c:3253
#36 0x1c0b8 in Fbyte_code (bytestr=3D808148844, vector=3D1076584364, =

    maxdepth=3D2842493) at bytecode.c:450
#37 0x54d64 in funcall_lambda (fun=3D271278144, nargs=3D0, arg_vector=3D0xe=
fffe4d8)
    at eval.c:3636
#38 0x53c98 in funcall_recording_as (recorded_as=3D271278144, nargs=3D0, =

    args=3D0xefffe4d4) at eval.c:3223
#39 0x53cfc in Ffuncall (nargs=3D1, args=3D0xefffe4d4) at eval.c:3253
#40 0x55738 in apply1 (fn=3D271278144, arg=3D271585284) at eval.c:3963
#41 0x1e9e8 in Fcall_interactively (function=3D272546684, record_flag=3D271=
585284, =

    keys=3D271585284) at callint.c:389
#42 0x54734 in primitive_funcall (fn=3D0x1e0bc <Fcall_interactively>, nargs=
=3D3, =

    args=3D0xefffe6e0) at eval.c:3488
#43 0x5488c in funcall_subr (subr=3D0x217980, args=3D0xefffe6e0) at eval.c:=
3526
#44 0x53ba8 in funcall_recording_as (recorded_as=3D270629248, nargs=3D1, =

    args=3D0xefffe7e8) at eval.c:3204
#45 0x53cfc in Ffuncall (nargs=3D2, args=3D0xefffe7e8) at eval.c:3253
#46 0x1c0b8 in Fbyte_code (bytestr=3D808065108, vector=3D1076500656, =

    maxdepth=3D2758806) at bytecode.c:450
#47 0x54d64 in funcall_lambda (fun=3D271194400, nargs=3D1, arg_vector=3D0xe=
fffea84)
    at eval.c:3636
#48 0x53c98 in funcall_recording_as (recorded_as=3D271194400, nargs=3D1, =

    args=3D0xefffea80) at eval.c:3223
#49 0x53cfc in Ffuncall (nargs=3D2, args=3D0xefffea80) at eval.c:3253
#50 0x1f930 in Fcall_interactively (function=3D272445340, record_flag=3D271=
585284, =

    keys=3D271585284) at callint.c:896
#51 0x525d4 in Fcommand_execute (cmd=3D272445340, record=3D271585284, =

    keys=3D271585284) at eval.c:2628
#52 0x6d4a8 in execute_command_event (command_builder=3D0x341e00, =

    event=3D272953464) at event-stream.c:3474
#53 0x6e7b8 in Fdispatch_event (event=3D272953464) at event-stream.c:3759
#54 0x25f08 in Fcommand_loop_1 () at cmdloop.c:542
#55 0x25b48 in command_loop_1 (dummy=3D271585284) at cmdloop.c:462
#56 0x50c40 in condition_case_1 (handlers=3D271585380, =

    bfun=3D0x25aa4 <command_loop_1>, barg=3D271585284, hfun=3D0x24bfc <cmd_=
error>, =

    harg=3D271585284) at eval.c:1672
#57 0x24d28 in command_loop_3 () at cmdloop.c:224
#58 0x24d50 in command_loop_2 (dummy=3D271585284) at cmdloop.c:235
#59 0x5072c in internal_catch (tag=3D271662500, func=3D0x24d44 <command_loo=
p_2>, =

    arg=3D271585284, threw=3D0x0) at eval.c:1347
#60 0x251e4 in initial_command_loop (load_me=3D150852) at cmdloop.c:273
#61 0x4d00c in main_1 (argc=3D2, argv=3D0xeffff244, envp=3D0x4c400) at emac=
s.c:1317
#62 0x4d498 in main (argc=3D2, argv=3D0xeffff244, envp=3D0xeffff250) at ema=
cs.c:1439

--------------167EB0E72781E494446B9B3D--


From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 09:27:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA23365 for xemacs-beta-people; Tue, 18 Jun 1996 09:27:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA23362 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 09:27:51 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA01470 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 09:27:49 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA20226; Tue, 18 Jun 1996 08:26:24 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA13995; Tue, 18 Jun 1996 08:26:12 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA03236; Tue, 18 Jun 1996 08:25:55 -0600
Date: Tue, 18 Jun 1996 08:25:55 -0600
Message-Id: <199606181425.IAA03236@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: carney@gvc.dec.com
Cc: xemacs-beta@xemacs.org
Subject: Re: XEmacs 19.14-b25 build success on Digital UNIX V3.2D
In-Reply-To: <9606180845.AA13299@djp-fornet.cern.ch>
References: <199606171854.MAA01990@gielgud.lanl.gov.xdiv>
	<9606180845.AA13299@djp-fornet.cern.ch>
Reply-To: turner@lanl.gov

Stephen Carney writes:
 > After starting up VM, and doing `C-x m', I got a similar backtrace as
 > reported by John Turner.  After deleting the vm .elc's and `make all-elc',
 > the problem went away.

Right.  That (as suggested by Chuck) fixed it for me as well.  Sorry I
didn't send something out about it...

-John

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 09:32:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA23393 for xemacs-beta-people; Tue, 18 Jun 1996 09:32:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA23390 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 09:31:58 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA01636 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 09:31:57 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA20951; Tue, 18 Jun 1996 08:29:48 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA14011; Tue, 18 Jun 1996 08:29:31 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA03240; Tue, 18 Jun 1996 08:29:11 -0600
Date: Tue, 18 Jun 1996 08:29:11 -0600
Message-Id: <199606181429.IAA03240@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: wing@netcom.com
Cc: dkindred+@cmu.edu, xemacs-beta@xemacs.org
Subject: Re:  buffer-menu sorting
In-Reply-To: <199606181001.DAA27414@netcom2.netcom.com>
References: <199606181001.DAA27414@netcom2.netcom.com>
Reply-To: turner@lanl.gov

Ben Wing writes:
 > Of course it would be really snazzy if it automatically put submenus
 > like this in when the number of items got too large, but didn't do
 > so otherwise.  An exercise for an enthusiastic Lisp coder no doubt ...

Oops.  I posted before reading all of my new mail this AM...

Great minds and all that, I guess...

-John

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 09:25:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA23304 for xemacs-beta-people; Tue, 18 Jun 1996 09:25:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA23301 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 09:25:01 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA01429 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 09:24:59 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA19846; Tue, 18 Jun 1996 08:24:50 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA13922; Tue, 18 Jun 1996 08:23:34 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA03230; Tue, 18 Jun 1996 08:23:16 -0600
Date: Tue, 18 Jun 1996 08:23:16 -0600
Message-Id: <199606181423.IAA03230@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: dkindred+@cmu.edu
Cc: xemacs-beta@xemacs.org
Subject: Re: buffer-menu sorting
In-Reply-To: <9606180701.AA44086@GS213.SP.CS.CMU.EDU>
References: <9606180701.AA44086@GS213.SP.CS.CMU.EDU>
Reply-To: turner@lanl.gov

Darrell Kindred writes:
 > The new buffer-menu grouping/sorting is interesting, but it has the
 > disadvantage that truncating the menu after some number of entries no
 > longer really makes sense since the lower entries are no less
 > "significant" than the upper ones.  Of course we have to truncate
 > somehow to avoid exceeding screen size, and I can't think of any
 > non-arbitrary way to do that for alphabetically sorted buffers, so
 > maybe it's not worth worrying about.  
 > 
 > Perhaps the default buffer menu size could be increased from 15 to 25
 > or so, so this problem doesn't bite as often.

How about if the number gets bigger than buffers-menu-max-size it
switches over to using sub-menus?

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 09:41:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA23426 for xemacs-beta-people; Tue, 18 Jun 1996 09:41:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA23423 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 09:41:38 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA02702 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 09:41:06 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA23293; Tue, 18 Jun 1996 08:41:06 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA14167; Tue, 18 Jun 1996 08:39:00 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA03248; Tue, 18 Jun 1996 08:38:41 -0600
Date: Tue, 18 Jun 1996 08:38:41 -0600
Message-Id: <199606181438.IAA03248@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: .xemacs-options
Reply-To: turner@lanl.gov

I like it.  One suggestion...  How about making the first line:

;; -*-Mode: Emacs-Lisp;-*- 

or adding it to auto-mode-alist by default so it comes up in
Emacs-Lisp mode...

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 10:27:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA23604 for xemacs-beta-people; Tue, 18 Jun 1996 10:27:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA23601 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 10:27:07 -0500 (CDT)
Received: from gatekeeper.origin-at.co.uk (gatekeeper.origin-at.co.uk [194.130.16.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA29696; Tue, 18 Jun 1996 10:27:06 -0500 (CDT)
Received: from [10.0.1.6] (pc1006.origin-at.co.uk [10.0.1.6]) by gatekeeper.origin-at.co.uk (V8) with SMTP id QAA07884; Tue, 18 Jun 1996 16:14:31 +0100
Message-Id: <1.5.4.16.19960618151951.0ebfbaf4@gatekeeper>
X-Sender: dhughes@gatekeeper
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Jun 1996 16:19:51 +0100
To: cthomp@cs.uiuc.edu, xemacs-beta@cs.uiuc.edu, andyp@parallax.co.uk
From: David Hughes <dhughes@origin-at.co.uk>
Subject: Re: Andy Piper: Func-menu

At 09:27 18/06/96 -0500, Chuck Thompson wrote:

>Date: Tue, 18 Jun 1996 11:54:35 +0100
>From: andyp@parallax.co.uk (Andy Piper)
>Message-Id: <199606181054.LAA07778@wrath.parallax.co.uk>
>To: xemacs-beta@cs.uiuc.edu
>Subject: Func-menu
>X-Sun-Charset: US-ASCII
>
>It would be nice if function menu had a `stealth-scan' mode whereby the
>buffer was only initially scanned when you switched to it. When I
>load up my 150 buffers most of the time is spent by func-menu scanning.


Nice idea; I'll look into this when I get time - it won't make 19.14 though,
so don't hold your breath!

-- David
                    ,,,
                   (@-@)
  +----------oOO----(_)-----------------+
  |             David Hughes            |
  |         Tel: +44 1223 585613        |
  |        dhughes@origin-at.co.uk      |
  |  Origin UK, Science Park, Cambridge |
  +------------------------oOO----------+
                  |  |  |
                  |__|__|
                   || ||
                  ooO Ooo


From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 10:53:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA23743 for xemacs-beta-people; Tue, 18 Jun 1996 10:53:38 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA23740 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 10:53:37 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA00418 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 10:53:38 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id IAA02711; Tue, 18 Jun 1996 08:53:05 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA00567; Tue, 18 Jun 96 11:53:03 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id LAA11915; Tue, 18 Jun 1996 11:52:59 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id LAA11579; Tue, 18 Jun 1996 11:52:57 -0400
Date: Tue, 18 Jun 1996 11:52:57 -0400
Message-Id: <199606181552.LAA11579@detlev.canada.sun.com>
From: Georg Nikodym <georgn@detlev.Canada.Sun.COM>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b25 OK on Solaris
In-Reply-To: <199606181055.LAA22397@ariel.uk.abs>
References: <199606181055.LAA22397@ariel.uk.abs>
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII

>>>>> "i" == imac  <imac@rd.abs.alcatel.co.uk> writes:

 i> Built 19.14b25 ok on Solaris2.5 Tried the new buffers-menu patch,
 i> this is similar in some respects to the infodock jump-menu, and I
 i> like it Ian

I, too, like it.  However, life wouldn't be complete if I didn't have
a nit.  I have use multple shell-mode buffers that I manually rename
to something purpose related like *os-src* (the asterisks prevent
auto-save).  These buffers are lumped in with *Misc* things like
completions, etc...  Can we make shell-mode buffers a special case
that get grouped regardless of the name?

Of course, I could be confused in thinking that the asterisks are
required in the names that I create for shell-mode...

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 11:37:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA23897 for xemacs-beta-people; Tue, 18 Jun 1996 11:37:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA23894 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 11:37:48 -0500 (CDT)
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA02801 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 11:37:45 -0500 (CDT)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0uW3le-00002AC>; Tue, 18 Jun 96 18:36 MET DST
Message-Id: <m0uW3le-00002AC@susan.logware.de>
Date: Tue, 18 Jun 96 18:36 MET DST
From: Michael Diers <mdiers@logware.de>
To: XEmacs beta list <xemacs-beta@cs.uiuc.edu>
Subject: [19.14-b25] FreeBSD 2.1 success

On FreeBSD 2.1, b25 (patched up) builds ok after "rm lisp/gnus/*.elc",
and runs well. Will try to do a fully optimized build later today.

This beta also looks good on Linux 1.2.13. 

I'm reluctant to actually run b25 on SCO OpenSewer 5, pl 2.6637e3542,
as b24 caused a kernel panic when I did that. It builds almost w/o
warnings, though ;-)

-Michael

--
XEmacs 19.14-b25 w/ Chuck's patch
(applied patchkits b16-b25)

FreeBSD 2.1 (4.4BSD), X11R6, gcc 2.6.3;
xpm 3.4f-patched, compface-19900129, jpeg-6, libpng-0.87, zlib-0.95
(these libs statically linked).

Configured for `i386-unknown-freebsd2.1'.

  Where should the build process find the source code?    /usr/contrib/pub/src/xemacs-19.14-b25
  What installation prefix should install use?		  /usr/contrib/pkg/xemacs-19.14-b25
  What operating system and machine description files should XEmacs use?
        `s/freebsd.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/contrib/include
  Additional libraries:                                   /usr/contrib/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 11:38:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA23917 for xemacs-beta-people; Tue, 18 Jun 1996 11:38:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA23914 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 11:38:26 -0500 (CDT)
Received: from sys3.cambridge.uk.psi.net (sys3.cambridge.uk.psi.net [154.32.106.10]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA05390 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 11:38:23 -0500 (CDT)
Received: from arrow by sys3.cambridge.uk.psi.net (8.7.5/SMI-5.5-UKPSINet)
	id RAA29618; Tue, 18 Jun 1996 17:36:30 +0100 (BST)
Received: by arrow (5.x/SMI-SVR4)
	id AA18922; Tue, 18 Jun 1996 17:31:32 +0100
>Received: from dx2.delcam.com by delcam.com; Tue, 18 Jun 96 16:45:41 BST
Received: from delcam by arrow.delcam.com; Tue, 18 Jun 1996 17:31 BST
Received: from dx2.delcam.com by delcam.com; Tue, 18 Jun 96 16:45:41 BST
Received: by dx2.delcam.com; Tue, 18 Jun 96 16:42:16 +0100
Message-Id: <24679.9606181542@dx2.delcam.com>
Date: Tue, 18 Jun 96 16:42:16 +0100
From: Paul Bibilo <peb@delcam.com>
To: xemacs-beta@xemacs.org
Subject: XEmacs-19.14-b25 Success
X-Face:  "+N/{>9S5,OIk<0$%[)LGd}<Mh,R;qNhl+C]O!g9wsh6Q65Wiv,#M#&,MjgG1?&]jTbwsn*
 _yj,NR}PT7"irWSgi|(H5w)Q1C0.dO:qt?=S`eF/EcT!L_1D7eJ&b-J5d#AoLu&}b#'}nq(^pr2+u*
 7'RvZp0xv:q/K&%WDOQ(+H?AJw7[|DcUK{}5S!;I4^9vFe$A2%G_oz3K#2d{m#[MnE,-hxq9Po9v]R
 t]j*0md[y/3R~J
Content-Type: text


I patched from b24.
Added frame.c, lazy-lock.el, files.el patches and
configure  --site-includes=/usr/local/include --site-libraries=/usr/local/lib
--cflags=-O2 --debug=no

Configured for `mips-sgi-irix5.2'.

  Where should the build process find the source code?    /local/ducdev/local/projects/emacs/beta/xemacs-19.14-b25
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/irix5-2.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              cc -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.

Built o.k. with make all-elc

No problems so far.

-- 
Paul Bibilo, Delcam International plc, |  Tel: +44 121 766 5544
Talbot Way, Small Heath, Birmingham,   |  Fax: +44 121 766 5511
England, B10 0HJ.                 _____|_____
#include <disclaimer.h>          | BLAT FOOP |



From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 11:42:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA23956 for xemacs-beta-people; Tue, 18 Jun 1996 11:42:44 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA23953 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 11:42:43 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA02925 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 11:42:44 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id JAA26978; Tue, 18 Jun 1996 09:42:04 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id JAA15285; Tue, 18 Jun 1996 09:41:28 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA10881; Tue, 18 Jun 1996 09:41:22 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id JAA10120; Tue, 18 Jun 1996 09:41:18 -0700
Date: Tue, 18 Jun 1996 09:41:18 -0700
Message-Id: <199606181641.JAA10120@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: georgn@canada.sun.com
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b25 OK on Solaris
In-Reply-To: <199606181552.LAA11579@detlev.canada.sun.com>
References: <199606181055.LAA22397@ariel.uk.abs>
	<199606181552.LAA11579@detlev.canada.sun.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Georg" == Georg Nikodym <georgn@detlev.Canada> writes:

Georg> Of course, I could be confused in thinking that the asterisks are
Georg> required in the names that I create for shell-mode...

I've used shell buffers named `shell-1', `shell-2', etc. for years.  I
think this ought to be the default behaviour, i.e. one should never
have to manually rename a shell-buffer to get a new one.  XEmacs has
never tried to autosave them (likely because there's no associated
filename to save to).

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 11:54:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA24019 for xemacs-beta-people; Tue, 18 Jun 1996 11:54:14 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA24016 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 11:54:13 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA03109 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 11:54:14 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id JAA02379; Tue, 18 Jun 1996 09:53:31 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id JAA17860; Tue, 18 Jun 1996 09:53:00 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA11190; Tue, 18 Jun 1996 09:52:54 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id JAA10132; Tue, 18 Jun 1996 09:52:51 -0700
Date: Tue, 18 Jun 1996 09:52:51 -0700
Message-Id: <199606181652.JAA10132@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: Another vote for...
Reply-To: Martin Buchholz <mrb@eng.sun.com>

Having the XEmacs FAQ available in info form.

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 12:55:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA24371 for xemacs-beta-people; Tue, 18 Jun 1996 12:55:34 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA24368 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 12:55:33 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA04200 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 12:55:34 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.6.12/8.6.9) with ESMTP id MAA10845 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 12:54:12 -0500
Message-Id: <199606181754.MAA10845@nvwls.cc.purdue.edu>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b25 OK on Solaris 
In-reply-to: Your message of "Tue, 18 Jun 1996 09:41:18 MST."
             <199606181641.JAA10120@xemacs.eng.sun.com> 
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 18 Jun 1996 12:54:04 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


>>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:

>>>>> "Georg" == Georg Nikodym <georgn@detlev.Canada> writes:

    Georg> Of course, I could be confused in thinking that the
    Georg> asterisks are required in the names that I create for
    Georg> shell-mode...

    Martin> I've used shell buffers named `shell-1', `shell-2',
    Martin> etc. for years.  I think this ought to be the default
    Martin> behaviour, i.e. one should never have to manually rename a
    Martin> shell-buffer to get a new one.

How about using the pty the shell is on for the buffer name?

Joe


From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 14:10:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA24605 for xemacs-beta-people; Tue, 18 Jun 1996 14:10:47 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA24602 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 14:10:46 -0500 (CDT)
Received: from GS213.SP.CS.CMU.EDU (GS213.SP.CS.CMU.EDU [128.2.209.183]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA08474 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 14:10:44 -0500 (CDT)
Received: by GS213.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA35159; Tue, 18 Jun 1996 15:10:42 -0400
Date: Tue, 18 Jun 1996 15:10:42 -0400
Message-Id: <9606181910.AA35159@GS213.SP.CS.CMU.EDU>
From: Darrell Kindred <dkindred+@cmu.edu>
To: xemacs-beta@xemacs.org
Cc: tytso@mit.edu
Subject: [PATCH] linux ^@ problem fixed

I'm pretty sure I've seen others (maybe Ben?) mention this bug before--
it's been plaguing me for quite a while:

  Under linux, in shell and compile buffers and other things 
  using ptys, sometimes you get a NUL character (^@) at the 
  beginning of each prompt (actually at the beginning of each
  chunk of output returned by a single read()).  This is usually
  just an annoyance in shell buffers, but it screws up the 
  error-parsing in compilation mode.

Anyway, I finally got around to investigating this.  It turns out that
"packet mode" isn't turned off when a pty is closed under linux, so
sometimes the pty XEmacs gets is in packet mode, and each read starts
with the single byte, TIOCPKT_DATA (which is zero).

Coincidentally, it looks like Ted Ts'o (tytso@mit.edu) introduced a
fix for this in Linux kernel pre2.0.13 (two weeks ago), but it caused
rlogin/telnet problems, so he backed it out in pre2.0.14.

The patch below clears packet-mode when a pty is opened, which
eliminates the problem.  I hope we can get this in 19.14.
(BTW, does anyone know if FSF emacs 19.31 suffers from this problem
too?  I don't see anything relevant in the source, but I don't
have it installed on my machine, so I can't be sure.)

- Darrell

*** src/sysdep.c.orig	Sun Jun  9 11:49:10 1996
--- src/sysdep.c	Tue Jun 18 14:20:00 1996
***************
*** 805,810 ****
--- 805,822 ----
    /* change this behavior, but I'm not going to hold my breath.             */
    signal (SIGHUP, SIG_IGN);
  #endif
+ #ifdef TIOCPKT
+   /* In some systems (Linux through 2.0.0, at least), packet mode doesn't
+      get cleared when a pty is closed, so we need to clear it here.
+      Linux pre2.0.13 contained an attempted fix for this (from Ted Ts'o,
+      tytso@mit.edu), but apparently it messed up rlogind and telnetd, so he
+      removed the fix in pre2.0.14.     - dkindred@cs.cmu.edu
+    */
+   {
+     int off = 0;
+     ioctl (fd, TIOCPKT, (char *)&off);
+   }
+ #endif
  }
  #endif /* HAVE_PTYS */
  

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 15:05:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA24811 for xemacs-beta-people; Tue, 18 Jun 1996 15:05:33 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA24808 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 15:05:31 -0500 (CDT)
Received: from ns2.eds.com (ns2.eds.com [199.228.142.78]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA08605 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 15:05:27 -0500 (CDT)
Received: by ns2.eds.com (hello)
	id QAA13396; Tue, 18 Jun 1996 16:05:29 -0400
Received: by nnsp.eds.com (hello)
	id QAA32399; Tue, 18 Jun 1996 16:04:58 -0400 (EDT)
Received: from kocrsw12.delcoelect.com (kocrsw12.delcoelect.com [144.250.106.18]) by kocrsv04.delcoelect.com (8.7.5/8.7.3) with SMTP id PAA07876 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 15:04:57 -0500 (EST)
Received: from kocrsw12 by kocrsw12.delcoelect.com (SMI-8.6/SMI-SVR4)
	id PAA07125; Tue, 18 Jun 1996 15:04:56 -0500
X-Mailer: exmh version 1.6.6 3/24/96
To: xemacs-beta@xemacs.org
Subject: More Sun keymap difficulties in b25
X-Face: 4tk3bJx]I+QTZ|=]*1+Z){9+;5u_hK*NBeZK6[+B+iB%bVuOJ%^uK~fIG}O-}%WLX*D^aW>
 Gv8E3Xtz0\N&fQl^:pj<K{xM`:d>pPt:9lF-YXB%O)?@rd?*/jE!s94`?]:jJ#C5RDP:;Mr.3lwo`0
 {vIT+<{%IRwe]vLd]7>\X|*z{TUX_t;?TPcOLBMIv8_V92!Vk(*DJVU~0M[`5D^PAWLniO1?YYWArM
 U*j9o+>?1MWi.lO?F-?aVt:qQ8OaG?R}B:I!7S_+KuzxZ.f9M@$z#n\bG2$Q2{od
Date: Tue, 18 Jun 1996 15:04:55 -0500
Message-ID: <7123.835128295@kocrsw12>
From: Mike Scheidler <c23mts@eng.delcoelect.com>

The latest round of Sun keymap changes has changed something that has
worked for me for quite awhile.  I have made bindings in my .emacs for
\C-\S-PgUp and \C-\S-PgDn to allow me to cycle through buffers quickly.
Until b25, the following bindings worked:

  (global-set-key '(control shift kp_9) 'bury-buffer)
  (global-set-key '(control shift kp_3) 'next-buffer)

In b25, however, my functions are not called and 'describe-key' only
reports seeing control-kp_9 and control-kp_3, ignoring the shift key event
altogether.  I can make things work again by using the names 'f29' and
'f35' instead of 'kp_9' and 'kp_3', but the ignored shift key seems like a
problem to me.

--
Mike Scheidler                     INTERNET:  c23mts@eng.delcoelect.com
Software Development Tools         UUCP:      deaes!c23mts
Delco Electronics Corporation      PHONE:     (317) 451-0319
Kokomo, IN 46904-9005              GMNET:     8-322-0319





From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 15:19:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA24870 for xemacs-beta-people; Tue, 18 Jun 1996 15:19:31 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA24867 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 15:19:30 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA12110 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 15:19:32 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id NAA04125; Tue, 18 Jun 1996 13:18:37 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA08494; Tue, 18 Jun 96 16:18:14 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id QAA01126; Tue, 18 Jun 1996 16:18:10 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id QAA11666; Tue, 18 Jun 1996 16:18:08 -0400
Date: Tue, 18 Jun 1996 16:18:08 -0400
Message-Id: <199606182018.QAA11666@detlev.canada.sun.com>
From: Georg Nikodym <georgn@detlev.Canada.Sun.COM>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b25 OK on Solaris
In-Reply-To: <199606181641.JAA10120@xemacs.eng.sun.com>
References: <199606181055.LAA22397@ariel.uk.abs>
	<199606181552.LAA11579@detlev.canada.sun.com>
	<199606181641.JAA10120@xemacs.eng.sun.com>
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII

>>>>> "MB" == Martin Buchholz <mrb@Eng> writes:

>>>>> "Georg" == Georg Nikodym <georgn@detlev.Canada> writes:
 Georg> Of course, I could be confused in thinking that the asterisks
 Georg> are required in the names that I create for shell-mode...

 MB> I've used shell buffers named `shell-1', `shell-2', etc. for
 MB> years.  I think this ought to be the default behaviour, i.e. one
 MB> should never have to manually rename a shell-buffer to get a new
 MB> one.  XEmacs has never tried to autosave them (likely because
 MB> there's no associated filename to save to).

Yeah, you're right.  But my point remains, buffers created by shell,
telnet, and rsh, should not be grouped in with buffers like:
*Compile-Log*, *scratch*, *ftp ftp@foo.com*, etc.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 15:46:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA25017 for xemacs-beta-people; Tue, 18 Jun 1996 15:46:09 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA25014 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 15:46:07 -0500 (CDT)
Received: from sasg2.epfl.ch (sasg2.epfl.ch [128.178.1.120]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA08725 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 15:46:05 -0500 (CDT)
Received: by sasg2.epfl.ch (950911.SGI.8.6.12.PATCH825/940406.SGI.AUTO)
	 id WAA22382; Tue, 18 Jun 1996 22:46:04 +0200
Date: Tue, 18 Jun 1996 22:46:04 +0200
Message-Id: <199606182046.WAA22382@sasg2.epfl.ch>
From: Simon Leinen <simon@lia.di.epfl.ch>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.14b25, XEmacs 20.0b25

The new betas have been copied to liaftp.epfl.ch:/pub/gnu/xemacs/beta.

Regards,
-- 
Simon.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 15:55:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA25045 for xemacs-beta-people; Tue, 18 Jun 1996 15:55:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA25042 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 15:55:15 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA12709 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 15:55:16 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id NAA21749; Tue, 18 Jun 1996 13:54:26 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [PATCH] linux ^@ problem fixed
References: <9606181910.AA35159@GS213.SP.CS.CMU.EDU>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Darrell Kindred's message of 18 Jun 1996 12:10:42 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Jun 1996 13:54:22 -0700
Message-ID: <m2enncrfy9.fsf@deanna.miranova.com>
Lines: 22
X-Mailer: Gnus v5.2.20/XEmacs 20.0

>>>>> "Darrell" == Darrell Kindred <dkindred+@cmu.edu> writes:

Darrell> I'm pretty sure I've seen others (maybe Ben?) mention this
Darrell> bug before-- it's been plaguing me for quite a while:

Darrell>   Under linux, in shell and compile buffers and other things 
Darrell>   using ptys, sometimes you get a NUL character (^@) at the 
Darrell>   beginning of each prompt (actually at the beginning of each
Darrell>   chunk of output returned by a single read()).  This is usually
Darrell>   just an annoyance in shell buffers, but it screws up the 
Darrell>   error-parsing in compilation mode.
  
This patch is definitely The Right Thing To Do.  I haven't finished
compiling an XEmacs to test it, but I have tested it with xterm, and
it works like a champ.

Thanks Darrell.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 16:07:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA25109 for xemacs-beta-people; Tue, 18 Jun 1996 16:07:50 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25106 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 16:07:49 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA08767 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 16:07:46 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id OAA23664; Tue, 18 Jun 1996 14:07:07 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA08067; Tue, 18 Jun 1996 14:06:59 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA16539; Tue, 18 Jun 1996 14:06:58 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA10662; Tue, 18 Jun 1996 14:06:54 -0700
Date: Tue, 18 Jun 1996 14:06:54 -0700
Message-Id: <199606182106.OAA10662@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Mike Scheidler <c23mts@eng.delcoelect.com>
Cc: xemacs-beta@xemacs.org
Subject: More Sun keymap difficulties in b25
In-Reply-To: <7123.835128295@kocrsw12>
References: <7123.835128295@kocrsw12>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Mike" == Mike Scheidler <c23mts@eng.delcoelect.com> writes:

Mike> The latest round of Sun keymap changes has changed something that has
Mike> worked for me for quite awhile.  I have made bindings in my .emacs for
Mike> \C-\S-PgUp and \C-\S-PgDn to allow me to cycle through buffers quickly.
Mike> Until b25, the following bindings worked:

Mike>   (global-set-key '(control shift kp_9) 'bury-buffer)
Mike>   (global-set-key '(control shift kp_3) 'next-buffer)

I assume your NumLock key is pressed?  Otherwise you should be getting
kp_prior or prior.

Given the plethora of modifier keys Shift Control Alt Meta, I only
remapped keypad keys with one modifier key pressed.  Do you really
have 5 other keybindings to use with kp_9 that the single-modifier
bindings got exhausted? I figured no one would actually do that.

For complete generality, one could rebind the power set of
(Meta, Alt, Shift, Control, Super, Hyper), so that if someone xmodmaps
the Hyper key into existence, then
(global-set-key '(control hyper meta alt shift kp_9)' 'foo)
will do the Right Thing.

But the real solution is to have some kind of union of the
functionality of keyboard-translate and function-key-map.  The
semantics of function-key-map are correct, but there should be a way
to have it take place at the keysym level like keyboard-translate
instead of at the keystroke level.

Anyways, your particular problem can be fixed by adding something like

(define-key function-key-map [(shift control f35)] [(shift control kp_next)])
(global-set-key [(shift control kp_next)] 'forward-char)

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 16:20:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA25193 for xemacs-beta-people; Tue, 18 Jun 1996 16:20:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25190 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 16:20:39 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA08791 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 16:20:37 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id PAA16222; Tue, 18 Jun 1996 15:20:37 -0600
Received: by suomi (SMI-8.6) id PAA21270; Tue, 18 Jun 1996 15:20:36 -0600
Sender: mdb@cdc.noaa.gov
To: xemacs-beta@xemacs.org
Subject: is window-displayed-height() OK in 19.14-b26 or not?
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 18 Jun 1996 15:20:35 -0600
In-Reply-To: Ben Wing's message of Tue, 14 Nov 1995 23:26:25 GMT
Message-ID: <vkg27s6c7w.fsf@cdc.noaa.gov>
Lines: 39
X-Mailer: Gnus v5.2.19/XEmacs 19.14

I was skimming the bug list WWW page, and noticed the same bug is
listed twice, once under WBNTFFR, and once under "Fixed for beta26". 

Would Be Nice to Fix For Release:
[...]
   * GNUS problem with scroll-on-clipped-lines non-nil:

     When reading a newsgroup in Gnus, sometimes when the last message
     in a group is selected the cursor will jump up a few lines to a
     previous message. If one then hits a space to scroll down further
     in the message it goes to the previous message (where the cursor
     now is).

----------------------------------------

Fixed For Beta 26:
[...]
   * Lars Magne Ingebrigtsen:

     When I do the following:
	(list (progn (split-window)
	     (window-displayed-height)) (progn (sit-for 0)
	(window-displayed-height))) 

     I consistently get that the first value is one greater than the
     second value. This is highly annoying and makes
     `gnus-summary-recenter' do really nasty things with point. Is
     this a bug or should I use some other function?

     Chuck: workaround is to put always put a (sit-for 0) before the call.
----------------------------------------

So, is the workaround (implemented in Gnus-5.2.19 in gnus-xmas.el,
near line 150 in the gnus-xmas-summary-recenter() function) no longer
necessary as of beta26? Although the workaround apparently works 
it is a bit visually annoying (but certainly not a show-stopper).

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 16:12:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA25137 for xemacs-beta-people; Tue, 18 Jun 1996 16:12:22 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25134 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 16:12:21 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA08775 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 16:12:18 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id PAA16018; Tue, 18 Jun 1996 15:12:05 -0600
Received: by suomi (SMI-8.6) id PAA21232; Tue, 18 Jun 1996 15:12:04 -0600
Sender: mdb@cdc.noaa.gov
To: xemacs-beta@xemacs.org
Cc: Kyle Jones <kyle_jones@wonderworks.com>
Subject: [19.14-b25] VM problems
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 18 Jun 1996 15:12:03 -0600
In-Reply-To: Ben Wing's message of Tue, 14 Nov 1995 23:26:25 GMT
Message-ID: <vkhgs86cm4.fsf@cdc.noaa.gov>
Lines: 12
X-Mailer: Gnus v5.2.19/XEmacs 19.14

Tried to invoke vm-mail() and found

----------------------------------------
Signalling: (invalid-function (macro . #<compiled-function (from "vm-misc.elc") nil "...(2)" [(and vm-mail-buffer (or (buffer-name vm-mail-buffer) (error "Folder buffer has been killed.")) (set-buffer vm-mail-buffer))] 1>))
  vm-select-folder-buffer()
  #<compiled-function (from "vm-startup.elc") nil "...(20)" [vm-session-initialization vm-select-folder-buffer vm-check-for-killed-summary vm-mail-internal run-hooks vm-mail-hook vm-mail-mode-hook] 2 "Send a mail message from within VM, or from without." nil>()
  call-interactively(vm-mail)

----------------------------------------

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 16:18:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA25186 for xemacs-beta-people; Tue, 18 Jun 1996 16:18:39 -0500 (CDT)
Received: from c.cs.uiuc.edu (c.cs.uiuc.edu [128.174.252.3]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25183 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 16:18:38 -0500 (CDT)
Received: from netcom2.netcom.com (root@netcom2.netcom.com [192.100.81.108]) by c.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA05926 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 16:18:38 -0500 (CDT)
Received: from netcom19.netcom.com (wing@netcom19.netcom.com [192.100.81.132]) by netcom2.netcom.com (8.6.13/Netcom)
	id OAA24896; Tue, 18 Jun 1996 14:17:24 -0700
Date: Tue, 18 Jun 1996 14:17:24 -0700
Message-Id: <199606182117.OAA24896@netcom2.netcom.com>
From: wing@666.com (Ben Wing)
To: mrb@eng.sun.com, xemacs-beta@cs.uiuc.edu
Subject: Re:  Another vote for...

>Having the XEmacs FAQ available in info form.
>
>Martin

I agree ...

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 16:22:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA25210 for xemacs-beta-people; Tue, 18 Jun 1996 16:22:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25207 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 16:22:38 -0500 (CDT)
Received: from netcom2.netcom.com (root@netcom2.netcom.com [192.100.81.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA08797 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 16:22:36 -0500 (CDT)
Received: from netcom19.netcom.com (wing@netcom19.netcom.com [192.100.81.132]) by netcom2.netcom.com (8.6.13/Netcom)
	id OAA25327; Tue, 18 Jun 1996 14:22:38 -0700
Date: Tue, 18 Jun 1996 14:22:38 -0700
Message-Id: <199606182122.OAA25327@netcom2.netcom.com>
From: wing@666.com (Ben Wing)
To: c23mts@eng.delcoelect.com, mrb@eng.sun.com
Subject: Re:  More Sun keymap difficulties in b25
Cc: xemacs-beta@xemacs.org

>Given the plethora of modifier keys Shift Control Alt Meta, I only
>remapped keypad keys with one modifier key pressed.  Do you really
>have 5 other keybindings to use with kp_9 that the single-modifier
>bindings got exhausted? I figured no one would actually do that.
>
>For complete generality, one could rebind the power set of
>(Meta, Alt, Shift, Control, Super, Hyper), so that if someone xmodmaps
>the Hyper key into existence, then
>(global-set-key '(control hyper meta alt shift kp_9)' 'foo)
>will do the Right Thing.
>
>But the real solution is to have some kind of union of the
>functionality of keyboard-translate and function-key-map.  The
>semantics of function-key-map are correct, but there should be a way
>to have it take place at the keysym level like keyboard-translate
>instead of at the keystroke level.

I agree; bring it up again after 19.14 and I'll see about adding it.
For the moment you might go ahead and bind some common double-combinations,
e.g. (shift control) (meta control) (meta shift) (meta control shift)
and maybe some with 'alt.  The 19.13 code did something of this sort.

ben

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 16:22:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA25202 for xemacs-beta-people; Tue, 18 Jun 1996 16:22:06 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25199 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 16:22:05 -0500 (CDT)
Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA08794 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 16:22:03 -0500 (CDT)
Received: from crystal.WonderWorks.COM by relay2.UU.NET with SMTP 
	(peer crosschecked as: crystal.WonderWorks.com [192.203.206.1])
	id QQaurl13342; Tue, 18 Jun 1996 17:21:56 -0400 (EDT)
Received: by crystal.WonderWorks.COM 
	id RAAaurl20384; Tue, 18 Jun 1996 17:21:48 -0400
Date: Tue, 18 Jun 1996 17:21:48 -0400
Message-Id: <RAAaurl20384.199606182121@crystal.WonderWorks.COM>
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: [19.14-b25] VM problems
In-Reply-To: <vkhgs86cm4.fsf@cdc.noaa.gov>
References: <vkhgs86cm4.fsf@cdc.noaa.gov>

This kind of invalid-function error always means that Emacs
encountered a macro when it expected a function.  This means that
a package was compiled that referenced a macro by name, but the
macro definition was not loaded at comilation time.  The compiler
therefore generated code for a function call and this code later
died in the manner you see below.

Judging from the stacktrace I'd wager that VM wasn't built
properly, e.g. someone didn't use the provided Makefile.

Please note that I am no longer on xemacs-beta, so CC me if you
want me to see any replies.

Mark Borges writes:
 > Tried to invoke vm-mail() and found
 > 
 > ----------------------------------------
 > Signalling: (invalid-function (macro . #<compiled-function (from "vm-misc.elc") nil "...(2)" [(and vm-mail-buffer (or (buffer-name vm-mail-buffer) (error "Folder buffer has been killed.")) (set-buffer vm-mail-buffer))] 1>))
 >   vm-select-folder-buffer()
 >   #<compiled-function (from "vm-startup.elc") nil "...(20)" [vm-session-initialization vm-select-folder-buffer vm-check-for-killed-summary vm-mail-internal run-hooks vm-mail-hook vm-mail-mode-hook] 2 "Send a mail message from within VM, or from without." nil>()
 >   call-interactively(vm-mail)
 > 
 > ----------------------------------------
 > 
 > -- 
 >   -mb-

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 16:29:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA25254 for xemacs-beta-people; Tue, 18 Jun 1996 16:29:15 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25251 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 16:29:14 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA13274 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 16:29:16 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id OAA03189; Tue, 18 Jun 1996 14:28:38 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA12974; Tue, 18 Jun 1996 14:28:26 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA17162; Tue, 18 Jun 1996 14:28:21 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA10715; Tue, 18 Jun 1996 14:28:17 -0700
Date: Tue, 18 Jun 1996 14:28:17 -0700
Message-Id: <199606182128.OAA10715@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: georgn@canada.sun.com
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b25 OK on Solaris
In-Reply-To: <199606182018.QAA11666@detlev.canada.sun.com>
References: <199606181055.LAA22397@ariel.uk.abs>
	<199606181552.LAA11579@detlev.canada.sun.com>
	<199606181641.JAA10120@xemacs.eng.sun.com>
	<199606182018.QAA11666@detlev.canada.sun.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Georg" == Georg Nikodym <georgn@detlev.Canada> writes:

Georg> Yeah, you're right.  But my point remains, buffers created by shell,
Georg> telnet, and rsh, should not be grouped in with buffers like:
Georg> *Compile-Log*, *scratch*, *ftp ftp@foo.com*, etc.

Agreed.  I think of my shell buffers as living a life separate from
the XEmacs that hosts them and even have a shell-ring function that
cycles between them.  But different people have different ideas of
what buffers ought to be grouped together.  Shell buffers should
probably not be a single group until XEmacs makes creating a new shell
buffer as natural as creating a new file buffer.

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 16:33:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA25269 for xemacs-beta-people; Tue, 18 Jun 1996 16:33:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25266 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 16:32:59 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA08800 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 16:32:57 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA01696; Tue, 18 Jun 1996 16:32:59 -0500 (CDT)
Message-Id: <199606182132.QAA01696@charles.cs.uiuc.edu>
To: Mark Borges <mdb@cdc.noaa.gov>
cc: xemacs-beta@xemacs.org
Subject: Re: is window-displayed-height() OK in 19.14-b26 or not? 
In-reply-to: Your message of "18 Jun 1996 15:20:35 MDT."
             <vkg27s6c7w.fsf@cdc.noaa.gov> 
Date: Tue, 18 Jun 1996 16:32:58 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Mark> So, is the workaround (implemented in Gnus-5.2.19 in
    Mark> gnus-xmas.el, near line 150 in the
    Mark> gnus-xmas-summary-recenter() function) no longer necessary
    Mark> as of beta26? Although the workaround apparently works it is
    Mark> a bit visually annoying (but certainly not a show-stopper).

It is no longer necessary and I have in fact already removed it from
the 5.2.20 integration into b26.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 16:54:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA25346 for xemacs-beta-people; Tue, 18 Jun 1996 16:54:41 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25343 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 16:54:40 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA08825 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 16:54:37 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id QAA10197; Tue, 18 Jun 1996 16:50:10 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id QAA27995; Tue, 18 Jun 1996 16:50:09 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id RAA28675; Tue, 18 Jun 1996 17:45:24 -0400
To: wing@netcom.com (Ben Wing)
cc: dkindred+@cmu.edu, xemacs-beta@xemacs.org
References: <199606181001.DAA27414@netcom2.netcom.com> 
Subject: Re: buffer-menu sorting 
In-reply-to: (Your message of Tue, 18 Jun 1996 03:01:31 PDT.)
             <199606181001.DAA27414@netcom2.netcom.com> 
Date: Tue, 18 Jun 1996 17:45:24 -0400
Message-ID: <1851.835134324@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


I tried out the new buffer menus.  I like them, or, rather, I would
like them if I actually used the buffer menu.  Can the same be done
for the buffer list buffer?  I always thought the old method was just
about as good as random sorting.

Of course, I'd still like the buffer list to only show buffers that
have been visited in the current frame.  A project for some other day
perhaps....

Ray

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 17:10:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA25414 for xemacs-beta-people; Tue, 18 Jun 1996 17:10:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA25411 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 17:10:14 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA16709 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 17:10:15 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id PAA24001; Tue, 18 Jun 1996 15:09:28 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: 19.14-b25 Linux 2.0 Success (w/out PNG)
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Jun 1996 15:09:25 -0700
Message-ID: <m23f3s3gtm.fsf@deanna.miranova.com>
Lines: 33
X-Mailer: Gnus v5.2.20/XEmacs 19.14

Patched up from b24.

Configured for `i486-unknown-linux2.0.0'.

  Where should the build process find the source code?    /i/xemacs-19.14-b24
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 18:01:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA25768 for xemacs-beta-people; Tue, 18 Jun 1996 18:01:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA25765 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 18:01:41 -0500 (CDT)
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA19158 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 18:01:42 -0500 (CDT)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0uW9mF-00002AC>; Wed, 19 Jun 96 01:01 MET DST
Message-Id: <m0uW9mF-00002AC@susan.logware.de>
Date: Wed, 19 Jun 96 01:01 MET DST
From: Michael Diers <mdiers@logware.de>
To: XEmacs beta list <xemacs-beta@cs.uiuc.edu>
Subject: [19.14-b25] SCO OpenServer 5 success, sort of
In-Reply-To: <m0uW3le-00002AC@susan.logware.de>
References: <m0uW3le-00002AC@susan.logware.de>

Michael Diers <mdiers@logware.de> wrote:

[...]
> I'm reluctant to actually run b25 on SCO OpenSewer 5, pl
> 2.6637e3542, as b24 caused a kernel panic when I did that. It builds
> almost w/o warnings, though ;-)
[...]

I finally had some success building b25 *statically* for SCO OS5 using
SCO DevSys. Now, xemacs -nw -q -no-site-file comes up ok.

Building dynamically gave me that *&^$% core dump, though. Lucky
escape, however; the kernel proved to be less panicky this time.

I think I had better leave this to Kean and Robert. Maybe the system
I'm on is just profoundly broken.

-Michael


Configured for `i586-unknown-sco3.2v5.0.0'.

  Where should the build process find the source code?    /usr/contrib/pub/src/xemacs-19.14-b25
  What installation prefix should install use?		  /usr/contrib/pkg/xemacs-19.14-b25
  What operating system and machine description files should XEmacs use?
        `s/sco5.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              cc -g 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

$ uname -X [edited]

System = SCO_SV 
Release = 3.2v5.0.0 
KernelID = 95/08/08 
Machine = Pentium 
BusType = ISA 
Users = 15-user 
OEM# = 0 
Origin# = 1 
NumCPU = 1 

$ customquery [edited]

Set                              Release
---                              -------
SCO OpenServer Enterprise System 5.0.0b
SCO OpenServer Development Syste 5.0.0a 
SCO DCE Development System       1.0.3g 
SCO UNIX System V Operating Syst 5.0.0Cl
X Server                         5.2.0p 
Graphics Drivers                 5.2.1a 
Standard X Clients               5.1.0p 
Extended X Clients               5.1.0p 
Desktop                          3.6.0p 
SCO TCP/IP                       2.0.0Cl
SCO NFS                          2.0.0Cl
UNIX Development System componen 5.0.0a 
C++ Development System component 3.1.2m 
Development Tools Desktop compon 1.0.0a 
TCP/IP Development System compon 2.0.0e 
NFS Development System component 2.0.0e 
X11/Motif Development System com 5.2.5h 

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 18:33:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA25906 for xemacs-beta-people; Tue, 18 Jun 1996 18:33:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA25903 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 18:33:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA19066 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 18:33:53 -0500 (CDT)
Message-Id: <199606182333.SAA19066@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: revised release schedule
Date: Tue, 18 Jun 1996 18:33:50 -0500
From: Chuck Thompson <cthomp@xemacs.org>

19.14 beta26 will come out tonight, Tuesday June 18.  20.0 beta26 will
not be released until Saturday to 1) conserve the dwindling CPU cycles
xemacs.cs.uiuc.edu has available and 2) encourage everyone to build
19.14 and find any remaining severe bugs.

*rant on*

I'm not terribly happy with the beta list participation the last week
or so. I don't expect everyone to build every release.  You're all
volunteers after all.  But release time is when everyone should try
extra, extra hard to get a build in.  Stand up and be counted.  At
least send in your configuration with an 'built ok' message.

*rant off*

That feels better.  Now then, the revised schedule:

	19.14 beta26		Tuesday, June 18
	19.14 prerelease	Wednesday, June 19
	19.14 final release	Friday morning, June 21
	20.0 beta26		Saturday, June 22
	19.14 net release	Sunday, June 23



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 19:32:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA26016 for xemacs-beta-people; Tue, 18 Jun 1996 19:32:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA26013 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 19:32:27 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA19462 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 19:32:24 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA20655; Tue, 18 Jun 1996 17:31:20 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA08092; Tue, 18 Jun 1996 16:25:15 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA20063; Tue, 18 Jun 1996 16:25:05 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA10995; Tue, 18 Jun 1996 16:25:01 -0700
Date: Tue, 18 Jun 1996 16:25:01 -0700
Message-Id: <199606182325.QAA10995@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: wing@666.com (Ben Wing)
Cc: c23mts@eng.delcoelect.com, xemacs-beta@xemacs.org
Subject: Re:  More Sun keymap difficulties in b25
In-Reply-To: <199606182122.OAA25322@netcom2.netcom.com>
References: <199606182122.OAA25322@netcom2.netcom.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

Ben> I agree; bring it up again after 19.14 and I'll see about adding it.
Ben> For the moment you might go ahead and bind some common double-combinations,
Ben> e.g. (shift control) (meta control) (meta shift) (meta control shift)
Ben> and maybe some with 'alt.  The 19.13 code did something of this sort.

If you're going to go beyond single modifiers you might as well go all
the way and allow C-M-A-Sh-kp_home.

Chuck, apply this patch if you think it ought to go into 19.14:

*** /tmp/geta10988	Tue Jun 18 16:23:48 1996
--- x-win-sun.el	Tue Jun 18 16:23:16 1996
***************
*** 71,77 ****
                  (define-key function-key-map
                    (append prefix (list k1))
                    (vector (append prefix (list k2)))))
!             '(() (shift) (control) (meta) (alt))))
      (setq mapping (cdr mapping))))
  
  (x11-remap-keysyms-using-function-key-map
--- 71,83 ----
                  (define-key function-key-map
                    (append prefix (list k1))
                    (vector (append prefix (list k2)))))
!             '(() (shift) (control) (meta) (alt)
!               (shift control) (shift alt) (shift meta)
!               (control alt) (control meta) (alt meta)
!               (shift control alt) (shift control meta)
!               (shift alt meta) (control alt meta)
!               (shift control alt meta))
!             ))
      (setq mapping (cdr mapping))))
  
  (x11-remap-keysyms-using-function-key-map

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 20:02:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA26085 for xemacs-beta-people; Tue, 18 Jun 1996 20:02:56 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA26082 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 20:02:55 -0500 (CDT)
Received: from andy.bu.edu (ANDY.BU.EDU [128.197.43.152]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA22256 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 20:02:56 -0500 (CDT)
Received: from andy.bu.edu (localhost [127.0.0.1]) by andy.bu.edu (8.7.4/8.7.3) with ESMTP id VAA27088 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 21:01:24 -0400 (EDT)
Message-Id: <199606190101.VAA27088@andy.bu.edu>
To: xemacs-beta@cs.uiuc.edu
Subject: 20.0-b25 report
Date: Tue, 18 Jun 1996 21:01:24 -0400
From: Andrew Cohen 617-353-6051 <cohen@andy.bu.edu>

20.0-b25 built fine under Solaris 2.5 using SUNPRO C4.0


./configure --with-gcc=no --with-xpm --site-includes="/usr/local/include /usr/dt/include" --site-libraries="/usr/dt/lib /usr/local/lib" --with-tooltalk --with-sparcworks --cflags="-fast -xO4"  --verbose 


no problems running under X,
but almost anything on a tty causes a core dump (this did NOT happen
under b23, and I didn't get a chance to build b24).


For example:


./xemacs -nw -q

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.


  sit-for(0)
  byte-code("  # eb!     " [add-timeout startup-message-timeout #<co
mpiled-function (from "startup.elc") (ignore) "...(5)" [nil ... ...] 3> nil time
out startup-splash-frame sit-for 0 next-command-event unread-command-event] 4)
  # (catch timeout ...)
  # (unwind-protect ...)
  # bind (timeout)
  command-line-1()
  # bind (command-line-args-left)
  command-line()
  # (unwind-protect ...)
  normal-top-level()
  # (condition-case ... . error)
  # (catch top-level ...)

C backtrace follows:
(A real debugger may provide better information)

26979:  ./xemacs -nw -q
 ef1b8604 waitid   (0, 6964, efffcef8, 3)
 ef1da5c8 waitpid  (6964, efffcfe0, 3, ef211018, 48, 0) + 58
 ef1f0fb0 system   (efffd154, 237260, 31590c, 6963, 0, 0) + 1d8
 00084ec4 fatal_error_signal (31590c, 32cc00, 336000, 10360004, 335c00, 32cc00)
+ 168
 ef1b7d44 sigacthandler (6, 0, efffd288, ef211018, 18, 0) + 28
 ef1b95b4 abort    (3160b0, 76f, 3160b8, efffd710, efffd700, 0) + c8
 000900ac signal_1 (10360274, 10360004, 334ad4, 10360004, 1, efffd798) + bc
 00091430 signal_error (10360274, 10360004, 336000, 337800, 334800, 1) + 5c
 00073df0 arith_error (8, 0, efffd8d8, 0, 0, 0) + 34
 ef1b7d44 sigacthandler (8, 0, efffd8d8, 0, 8, 1) + 28
 00168a80 create_text_block (fffffff, efffde7c, 0, 336188, 381ab0, 1) + 578
 00165df8 generate_display_line (3f3e00, efffde7c, 392000, 1, 0, efffded4) + 11c
 0016d734 regenerate_window (ffffffff, 3f3ec4, 1c, 7fffffff, 392000, 3f3eac) + 3
84
 0016f68c redisplay_window (3b0300, 392000, 336188, 3f3e00, 1, 10392000) + ae0
 0016fdf8 redisplay_frame (3b0300, 0, 336188, 3b0800, fffffff, 3b0800) + 14c
 00170138 redisplay_device (3b0800, 336188, 3b0300, fffffff, 0, 0) + 1dc
 00170654 redisplay_without_hooks (5, 10360004, 336188, 3b0800, 39ba14, 39ba24)
+ 2b4
 000b1c18 Fsit_for (330400, 336188, 316f58, 32ce5c, 3349bc, 1) + 340
 0009af58 funcall_recording_as (336188, 24f67c, 330800, 30c260, fffffff, 1025019
c) + cf0
 0005ec20 Fbyte_code (e, 4, 10, 30c260, 252fac, 2c19bc) + 3b4
 00098fc4 Feval    (3, 336188, 3374e0, 24d5b8, efffe584, 3) + 140c
 0008e058 internal_catch (10378e04, 97bb8, 202c197c, 0, 338800, 336000) + bc
 0005f4bc Fbyte_code (26, 336000, 10, 30c260, 252fac, 2c1848) + c50
 0009f03c funcall_lambda (336188, 2bf550, fffffff, 32ce20, 0, 0) + 1a18
 0009b2f8 funcall_recording_as (336188, 24f67c, 24f6ec, 30c260, fffffff, 102bf55
0) + 1090
 0005ec20 Fbyte_code (58, 336000, 10, 30c260, 252fac, 2c1eb4) + 3b4
 0009f03c funcall_lambda (336188, 2bf404, fffffff, 32ce20, bb8, 0) + 1a18
 0009b2f8 funcall_recording_as (336188, 24f67c, 24f6ec, 30c260, fffffff, 102bf40
4) + 1090
 0005ec20 Fbyte_code (3d, 336000, 10, 30c260, 252fac, 2c223c) + 3b4
 0009f03c funcall_lambda (336188, 2bf388, fffffff, 32ce20, effff79c, 0) + 1a18
 00099438 Feval    (32cc00, 336188, 3374e0, 24f67c, 32cc00, fffffff) + 1880
 0008edc0 condition_case_1 (10360064, 97bb8, 203dd02c, 6961c, 10360004, 0) + 118
 00069748 top_level_1 (336000, 69718, effffab8, 0, 334780, effff830) + 30
 0008e058 internal_catch (10372ef4, 69718, 10360004, 0, 2f, 3ac884) + bc
 00069874 initial_command_loop (334000, 336188, 334800, 3ee53c, 360004, 3ac880)
+ 4c
 00085f7c main_1   (35a000, 336000, 10360004, 1, effffcb4, 3) + d58
 00086420 main     (3, effffcb4, effffcc4, 24b000, 1, 0) + a8
 0003f604 _start   (0, 0, 0, 0, 0, 0) + dc


A "real" debugger gives the following info:


(/opt/SUNWspro/bin/dbx) where
=>[1] kill(0x0, 0x6, 0x6964, 0x6963, 0x0, 0x0), at 0xef1f3e30
  [2] fatal_error_signal(0x31590c, 0x32cc00, 0x336000, 0x10360004, 0x335c00, 0x3
2cc00), at 0x84ed4
  ---- called from signal handler with signal 6 (SIGABRT) ------
  [3] kill(), at 0xef1f3e30
  [4] abort(0x3160b0, 0x76f, 0x3160b8, 0xefffd710, 0xefffd700, 0x0), at 0xef1b95
b4
  [5] signal_1(0x10360274, 0x10360004, 0x334ad4, 0x10360004, 0x1, 0xefffd798), a
t 0x900ac
  [6] signal_error(0x10360274, 0x10360004, 0x336000, 0x337800, 0x334800, 0x1), a
t 0x91430
  [7] arith_error(0x8, 0x0, 0xefffd8d8, 0x0, 0x0, 0x0), at 0x73df0
  ---- called from signal handler with signal 8 (SIGFPE) ------
  [8] create_text_block(), at 0x16925c
  [9] generate_display_line(0x3f3e00, 0xefffde7c, 0x392000, 0x1, 0x0, 0xefffded4
), at 0x165df8
  [10] regenerate_window(0xffffffff, 0x3f3ec4, 0x1c, 0x7fffffff, 0x392000, 0x3f3
eac), at 0x16d734
  [11] redisplay_window(0x3b0300, 0x392000, 0x336188, 0x3f3e00, 0x1, 0x10392000)
, at 0x16f68c
  [12] redisplay_frame(0x3b0300, 0x0, 0x336188, 0x3b0800, 0xfffffff, 0x3b0800),
at 0x16fdf8
  [13] redisplay_device(0x3b0800, 0x336188, 0x3b0300, 0xfffffff, 0x0, 0x0), at 0
x170138
  [14] redisplay_without_hooks(0x5, 0x10360004, 0x336188, 0x3b0800, 0x39ba14, 0x
39ba24), at 0x170654
  [15] Fsit_for(0x330400, 0x336188, 0x316f58, 0x32ce5c, 0x3349bc, 0x1), at 0xb1c
18
  [16] funcall_recording_as(0x336188, 0x24f67c, 0x330800, 0x30c260, 0xfffffff, 0
x1025019c), at 0x9af58
  [17] Fbyte_code(0xe, 0x4, 0x10, 0x30c260, 0x252fac, 0x2c19bc), at 0x5ec20
  [18] Feval(0x3, 0x336188, 0x3374e0, 0x24d5b8, 0xefffe584, 0x3), at 0x98fc4
  [19] internal_catch(0x10378e04, 0x97bb8, 0x202c197c, 0x0, 0x338800, 0x336000),
 at 0x8e058
  [20] Fbyte_code(0x26, 0x336000, 0x10, 0x30c260, 0x252fac, 0x2c1848), at 0x5f4b
c
  [21] funcall_lambda(0x336188, 0x2bf550, 0xfffffff, 0x32ce20, 0x0, 0x0), at 0x9
f03c
  [22] funcall_recording_as(0x336188, 0x24f67c, 0x24f6ec, 0x30c260, 0xfffffff, 0
x102bf550), at 0x9b2f8
  [23] Fbyte_code(0x58, 0x336000, 0x10, 0x30c260, 0x252fac, 0x2c1eb4), at 0x5ec2
0
  [24] funcall_lambda(0x336188, 0x2bf404, 0xfffffff, 0x32ce20, 0xbb8, 0x0), at 0
x9f03c
  [25] funcall_recording_as(0x336188, 0x24f67c, 0x24f6ec, 0x30c260, 0xfffffff, 0
x102bf404), at 0x9b2f8
  [26] Fbyte_code(0x3d, 0x336000, 0x10, 0x30c260, 0x252fac, 0x2c223c), at 0x5ec2
0
  [27] funcall_lambda(0x336188, 0x2bf388, 0xfffffff, 0x32ce20, 0xeffff79c, 0x0),
 at 0x9f03c
  [28] Feval(0x32cc00, 0x336188, 0x3374e0, 0x24f67c, 0x32cc00, 0xfffffff), at 0x
99438
  [29] condition_case_1(0x10360064, 0x97bb8, 0x203dd02c, 0x6961c, 0x10360004, 0x
0), at 0x8edc0
  [30] top_level_1(0x336000, 0x69718, 0xeffffab8, 0x0, 0x334780, 0xeffff830), at
 0x69748
  [31] internal_catch(0x10372ef4, 0x69718, 0x10360004, 0x0, 0x2f, 0x3ac884), at
0x8e058
  [32] initial_command_loop(0x334000, 0x336188, 0x334800, 0x3ee53c, 0x360004, 0x
3ac880), at 0x69874
  [33] main_1(0x35a000, 0x336000, 0x10360004, 0x1, 0xeffffcb4, 0x3), at 0x85f7c
  [34] main(0x3, 0xeffffcb4, 0xeffffcc4, 0x24b000, 0x1, 0x0), at 0x86420





From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 20:34:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA26195 for xemacs-beta-people; Tue, 18 Jun 1996 20:34:59 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA26192 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 20:34:58 -0500 (CDT)
Received: from andy.bu.edu (ANDY.BU.EDU [128.197.43.152]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA26278 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 20:35:00 -0500 (CDT)
Received: from andy.bu.edu (localhost [127.0.0.1]) by andy.bu.edu (8.7.4/8.7.3) with ESMTP id VAA02621 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 21:33:29 -0400 (EDT)
Message-Id: <199606190133.VAA02621@andy.bu.edu>
To: xemacs-beta@cs.uiuc.edu
Subject: previous bug report for 20.0-b25
Date: Tue, 18 Jun 1996 21:33:29 -0400
From: Andrew Cohen 617-353-6051 <cohen@andy.bu.edu>

Previously I had reported failure under Solaris2.5 on ttys.

Well, it was pointed out to me that I had compiled without debugging
and a high level of optimization (I was doing some speed tests) and
upon recompiling with

./configure --with-gcc=no --with-xpm --site-includes="/usr/local/include /usr/dt/include" --site-libraries="/usr/dt/lib /usr/local/lib" --with-tooltalk --with-sparcworks --cflags="-fast -g"  --verbose


I no longer have any errors under ttys.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 20:59:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA26273 for xemacs-beta-people; Tue, 18 Jun 1996 20:59:25 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA26270 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 20:59:23 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA20125 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 20:59:10 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id KAA25566; Wed, 19 Jun 1996 10:59:01 +0900 (JST)
Message-Id: <199606190159.KAA25566@mikan.jaist.ac.jp>
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
Subject: [20.0 b25] patch for mule-misc.el
Mime-Version: 1.0 (SEMI mime-edit 0.26)
Content-Type: multipart/mixed;
 boundary="Multipart_Wed_Jun_19_10:58:59_1996-1"
Content-Transfer-Encoding: 7bit
Date: Wed, 19 Jun 1996 10:59:01 JST
Sender: morioka@jaist.ac.jp

--Multipart_Wed_Jun_19_10:58:59_1996-1
Content-Type: text/plain; charset=US-ASCII

  I made a patch for mule-misc.el to fix function
`string-to-char-list', and I propose a function `string-columns',
which returns columns string occupies when displayed, same as
`string-width' of MULE, and define an alias `string-width' for w3.


--Multipart_Wed_Jun_19_10:58:59_1996-1
Content-Type: application/octet-stream
Content-Transfer-Encoding: 7bit

--- mule-misc.el.orig	Thu May 16 21:26:10 1996
+++ mule-misc.el	Wed Jun 19 07:44:08 1996
@@ -44,8 +44,8 @@
 	(idx 0)
 	c l)
     (while (< idx len)
-      (setq c (sref str idx))
-      (setq idx (+ idx (charset-dimension (char-charset c))))
+      (setq c (aref str idx))
+      (setq idx (1+ idx))
       (setq l (cons c l)))
     (nreverse l)))
 
@@ -126,6 +126,18 @@
 	   (null (car buffer-undo-list)) )
       (setq buffer-undo-list (cdr buffer-undo-list)) ))
 
+(defun string-columns (string)
+  "Return number of columns STRING occupies when displayed."
+  (let ((col 0)
+	(len (length string))
+	(i 0))
+    (while (< i len)
+      (setq col (+ col (charset-columns (char-charset (aref string i)))))
+      (setq i (1+ i))
+      )
+    col))
+
+(defalias 'string-width 'string-column)
 
 (defun truncate-string-to-column (str width &optional start-column)
   "Truncate STR to fit in WIDTH columns.

--Multipart_Wed_Jun_19_10:58:59_1996-1
Content-Type: text/plain; charset=US-ASCII


  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---
--Multipart_Wed_Jun_19_10:58:59_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 22:23:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA26535 for xemacs-beta-people; Tue, 18 Jun 1996 22:23:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA26532 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 22:23:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA24419 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 22:23:40 -0500 (CDT)
Message-Id: <199606190323.WAA24419@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.14 beta26
Date: Tue, 18 Jun 1996 22:23:36 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/beta/xemacs-19.14.  Next release is the
prerelease, out Wednesday, June 19 (or possibly Thursday morning).

This pretty much does it for me and bug fixing.  I've got a number of
textual changes to make (such as getting the included faq updated) and
I'm going to do a number of Purify runs.  Patch contributions still
more than welcome for the pre-release.

5 more days.

			-Chuck



-- gnus 5.2.20
-- auto-show-mode is now off by default in edit-faces-mode
-- incorrect echoing when hitting 'f1 in tty mode fixed
-- png build problem fixed
-- terminal.el env requirement removed
-- gdbglobal doesn't turn on everywhere anymore
-- The bug where window-displayed-height didn't always return the
   correct value is fixed.  The same bug was responsible for
   shrink-window-if-larger-than-buffer sometimes failing to work
   correctly.
-- The force option to delete-frame is back.  You can no longer delete
   the last visible or iconic frame unless the second arg to
   delete-frame is non-nil.
-- Darrell Kindred's patch fro the ^@ problem
-- a number of random elisp changes from Jamie
-- --with-cde flag is back
-- revert-buffer no longer causes complete refontification in lazy-lock.
-- some more options on Options menu, for Printing.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 22:33:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA26579 for xemacs-beta-people; Tue, 18 Jun 1996 22:33:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA26576 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 22:33:31 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA24960 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 22:33:28 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id UAA21537; Tue, 18 Jun 1996 20:33:01 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA06914; Tue, 18 Jun 1996 20:32:59 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA23138; Tue, 18 Jun 1996 20:32:57 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA14491; Tue, 18 Jun 1996 20:32:53 -0700
Date: Tue, 18 Jun 1996 20:32:53 -0700
Message-Id: <199606190332.UAA14491@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: MORIOKA Tomohiko <morioka@jaist.ac.jp>
Cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: [20.0 b25] patch for mule-misc.el
In-Reply-To: <199606190159.KAA25566@mikan.jaist.ac.jp>
References: <199606190159.KAA25566@mikan.jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "MT" == MORIOKA Tomohiko <ISO-2022-JP> writes:

MT>   I made a patch for mule-misc.el to fix function
MT> `string-to-char-list', and I propose a function `string-columns',
MT> which returns columns string occupies when displayed, same as
MT> `string-width' of MULE, and define an alias `string-width' for w3.

It seems to me that Ben's work on making Mule more logical has
obsoleted functions like `string-to-char-list'.

(string-to-char-list string)
 is equivalent to
(mapcar 'identity string)

making string-to-char-list so trivial that it perhaps should only be
defined for backward compatibility?

MT> --- mule-misc.el.orig	Thu May 16 21:26:10 1996
MT> +++ mule-misc.el	Wed Jun 19 07:44:08 1996
MT> @@ -44,8 +44,8 @@
MT>  	(idx 0)
MT>  	c l)
MT>      (while (< idx len)
MT> -      (setq c (sref str idx))
MT> -      (setq idx (+ idx (charset-dimension (char-charset c))))
MT> +      (setq c (aref str idx))
MT> +      (setq idx (1+ idx))
MT>        (setq l (cons c l)))
MT>      (nreverse l)))
 
MT> @@ -126,6 +126,18 @@
MT>  	   (null (car buffer-undo-list)) )
MT>        (setq buffer-undo-list (cdr buffer-undo-list)) ))
 
How about this definition for string-columns instead, in the
functional style?

(defun string-columns (string)
 "Return number of columns STRING occupies when displayed.
Uses the charset-columns attribute of the characters in STRING,
which may not accurately represent the actual display width in a
window system."
  (apply '+ (mapcar #'(lambda (c) 
			(charset-columns (char-charset c)))
		    string)))

MT> +(defun string-columns (string)
MT> +  "Return number of columns STRING occupies when displayed."
MT> +  (let ((col 0)
MT> +	(len (length string))
MT> +	(i 0))
MT> +    (while (< i len)
MT> +      (setq col (+ col (charset-columns (char-charset (aref string i)))))
MT> +      (setq i (1+ i))
MT> +      )
MT> +    col))
MT> +
MT> +(defalias 'string-width 'string-column)
 

MT>   Thanks,

Thank you

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 23:05:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA26663 for xemacs-beta-people; Tue, 18 Jun 1996 23:05:33 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA26660 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 23:05:31 -0500 (CDT)
Received: from caddy.arnet.com (caddy.arnet.com [199.86.10.214]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA04176 for <xemacs-beta@cs.uiuc.edu>; Tue, 18 Jun 1996 23:05:32 -0500 (CDT)
Subject: Re: [19.14-b25] SCO OpenServer 5 success, sort of
To: Michael Diers <mdiers@logware.de>
Date: Tue, 18 Jun 1996 23:01:04 -0500 (CDT)
From: Robert Lipe <robertl@arnet.com>
Cc: xemacs-beta@cs.uiuc.edu
In-Reply-To: <m0uW9mF-00002AC@susan.logware.de> from "Michael Diers" at Jun 19, 96 01:01:00 am
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID:  <9606182301.aa05495@caddy.arnet.com>

Michael Diers writes:

> > I'm reluctant to actually run b25 on SCO OpenSewer 5, pl
> > 2.6637e3542, as b24 caused a kernel panic when I did that. It builds
> > almost w/o warnings, though ;-)

Kean and I had a private discussion.   We basically concluded that 
your system was haunted by evil spirits.   Neither one of us
could duplicate or explain the results you had from the last
build you tried, either.

That said, Kean and I are seeing very consistent, but different 
results between our two environments anyway.  

> I finally had some success building b25 *statically* for SCO OS5 using
> SCO DevSys. Now, xemacs -nw -q -no-site-file comes up ok.

Please check something for me.
M-x getenv 
	PATH<enter>

Tell us what you see.

> Building dynamically gave me that *&^$% core dump, though. Lucky
> escape, however; the kernel proved to be less panicky this time.

I pulled the full distribution across this afternoon.  Built
dynamically it worked (bug above noted).  Buit statically, it worked
better (bug above missing).

> I think I had better leave this to Kean and Robert. Maybe the system
> I'm on is just profoundly broken.

Actually, I may have a clue for you.

> $ customquery [edited]

This looks more like a 'swconfig' than a customquery to me.  Is it?

> Set                              Release
> ---                              -------
> SCO OpenServer Enterprise System 5.0.0b

I don't see either of the mandatory patches/supplements
installed.  If you don't have release supplement RS500d and
Net100 installed, run, don't walk, to ftp.sco.com and get them.

Here's another way to see if you have them installed:

$ customquery listpatches | grep ' '
SCO:Unix::5.0.0Cl  rs.Unix500.1.0.a  rs.Unix500.2.0.a
SCO:lli::5.0.0l  rs.lli500.1.0.a
SCO:tcp::2.0.0Cl  rs.tcp200.1.0.a  rs.tcp200.2.0.a
SCO:nfs::2.0.0Cl  rs.nfs200.1.0.a  rs.nfs200.2.0.a
SCO:tcpdev::2.0.0e  rs.tcpdev200.2.0.a

If your customquery doesn't support the listpatches option, then
you don't have 5.0.0d anyway..

As this is probably getting too SCO specific for this crowd, you 
can contact me privately or in the comp.unix.sco groups...



From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 23:47:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA26836 for xemacs-beta-people; Tue, 18 Jun 1996 23:47:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA26833 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 23:47:04 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA01652 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 23:47:01 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id NAA06052; Wed, 19 Jun 1996 13:46:58 +0900 (JST)
Message-Id: <199606190446.NAA06052@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: [20.0 b25] patch for mule-misc.el 
In-reply-to: Your message of "Tue, 18 Jun 1996 20:32:53 MST."
             <199606190332.UAA14491@xemacs.eng.sun.com> 
Mime-Version: 1.0 (SEMI mime-edit 0.26)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 19 Jun 1996 13:46:59 JST
Sender: morioka@jaist.ac.jp

>>>>> In <199606190332.UAA14491@xemacs.eng.sun.com> 
>>>>>	Martin Buchholz <mrb@Eng.Sun.COM> wrote:

Martin> >>>>> "MT" == MORIOKA Tomohiko writes:

MT>   I made a patch for mule-misc.el to fix function
MT> `string-to-char-list', and I propose a function `string-columns',
MT> which returns columns string occupies when displayed, same as
MT> `string-width' of MULE, and define an alias `string-width' for w3.

Martin> It seems to me that Ben's work on making Mule more logical has
Martin> obsoleted functions like `string-to-char-list'.

Martin> (string-to-char-list string)
Martin>  is equivalent to
Martin> (mapcar 'identity string)

Martin> making string-to-char-list so trivial that it perhaps should
Martin> only be defined for backward compatibility?

  Yes. I does not use for my program, and I rewrote canna.el not to
it. It should be deleted or fixed its bug.

  By the way, in Emacs, mapcar is too slow. I love map. It is
beautiful. However I don't use map for library because of speed.
However in XEmacs, mapcar seems fast, so mapcar definition is better.

 
Martin> How about this definition for string-columns instead, in the
Martin> functional style?

Martin> (defun string-columns (string)
Martin>  "Return number of columns STRING occupies when displayed.
Martin> Uses the charset-columns attribute of the characters in STRING,
Martin> which may not accurately represent the actual display width in a
Martin> window system."
Martin>   (apply '+ (mapcar #'(lambda (c) 
Martin> 			(charset-columns (char-charset c)))
Martin> 		    string)))

  It is same reason. In Emacs, apply is too slow. In this case, my
definition seems faster. So I think my definition is better.

  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 18 23:49:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA26847 for xemacs-beta-people; Tue, 18 Jun 1996 23:49:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA26844 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 18 Jun 1996 23:49:26 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA01655 for <xemacs-beta@xemacs.org>; Tue, 18 Jun 1996 23:49:24 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id WAA21382; Tue, 18 Jun 1996 22:49:26 -0600
Received: by suomi (SMI-8.6) id WAA29297; Tue, 18 Jun 1996 22:49:26 -0600
Date: Tue, 18 Jun 1996 22:49:26 -0600
Message-Id: <199606190449.WAA29297@suomi.cdc.noaa.gov>
From: Mark Borges <mdb@cdc.noaa.gov>
To: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: [19.14-b26] solaris-2.5 built OK
Organization: CIRES, University of Colorado
X-Attribution: mb

using cc-4.0. Since the release is pretty close, I decided to crank
the optimization up to -xO3 to see if that causes any problems
here. 

No problems so far after using VM and Gnus for a while on a TTY
device. I even fired up the new XEmacs-killer, w3, and b26 survived
;-).

Configured for `sparc-sun-solaris2.5'.

  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              cc -xO3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 00:01:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA26879 for xemacs-beta-people; Wed, 19 Jun 1996 00:01:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA26876 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 00:01:12 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA01694 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 00:01:08 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id OAA06776; Wed, 19 Jun 1996 14:01:07 +0900 (JST)
Message-Id: <199606190501.OAA06776@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: [20.0 b25] patch for canna.el
Mime-Version: 1.0 (SEMI mime-edit 0.26)
Content-Type: multipart/mixed;
 boundary="Multipart_Wed_Jun_19_14:00:56_1996-1"
Content-Transfer-Encoding: 7bit
Date: Wed, 19 Jun 1996 14:01:09 JST
Sender: morioka@jaist.ac.jp

--Multipart_Wed_Jun_19_14:00:56_1996-1
Content-Type: text/plain; charset=US-ASCII

  canna.el of XEmacs 20.0 beta25 is broken (character encoding is
broken). And I modified canna.el not to use `string-to-char-list'.

  Following is patch:

# Notice that canna.el includes Japanese. Please be careful.


--Multipart_Wed_Jun_19_14:00:56_1996-1
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="canna.el.patch"
Content-Transfer-Encoding: 7bit

--- canna.el-orig	Sun Jun 16 00:22:56 1996
+++ canna.el	Tue Jun 18 09:13:55 1996
@@ -41,8 +41,40 @@
       (char-after (1- (point)))
       )
     )
-(defalias 'overlayp 'extentp)
+(or (fboundp 'overlayp)
+    (defalias 'overlayp 'extentp)
+    )
 
+;; added by MORIOKA Tomohiko <morioka@jaist.ac.jp>, 1996/6/18
+(defvar running-xemacs (string-match "XEmacs" emacs-version))
+
+(if running-xemacs
+    (progn
+      (defun self-insert-string (string)
+	(let ((len (length string))
+	      (i 0)
+	      ;; $BA^F~$NESCf$G(B blink $B$,5/$-$k$H$&$C$H$*$7$$$N$G!"(B
+	      ;; $B0l;~E*$K(B blink $B$rM^;_$9$k!#(B
+	      (blink-matching-paren nil))
+	  (while (< i len)
+	    (self-insert-internal (aref canna-kakutei-string i))
+	    (setq i (1+ i))
+	    )))
+      )
+  (defun self-insert-string (string)
+    (let ((len (length string))
+	  (i 0) chr
+	  ;; $BA^F~$NESCf$G(B blink $B$,5/$-$k$H$&$C$H$*$7$$$N$G!"(B
+	  ;; $B0l;~E*$K(B blink $B$rM^;_$9$k!#(B
+	  (blink-matching-paren nil))
+      (while (< i len)
+	(setq chr (sref canna-kakutei-string i))
+	(self-insert-internal chr)
+	(setq i (+ i (char-bytes chr)))
+	)))
+  )
+
+
 ;; -*-mode: emacs-lisp-*-
 
 (defconst canna-rcs-version "Canna/mule 2.x, based on Canna 2.2/3.2. : canna.el,v x.xx 1994/11/7 00:00:00")
@@ -67,13 +99,13 @@
 (defvar canna-with-fences (not canna-underline))
 
 (defvar canna-initialize-minibuffer-state-when-exit nil
-  "*Non-nil $B$N$H$-$O(B, $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$rH4$1$k;~F|K\8l>uBV$r=i4|2=$9$k(B.")
+  "*Non-nil $B$N$H$-$O(B, $B%_%K%P%C%U%!$rH4$1$k;~F|K\8l>uBV$r=i4|2=$9$k(B.")
 
 (defvar canna-inhibit-hankakukana nil
   "*Non-nil $B$N;~!";z<oJQ49$GH>3Q$+$J$KJQ49$7$J$$(B")
 
 ;;;
-;;; $B%b!<1.11i%$%s$N=$@0(B
+;;; $B%b!<%I%i%$%s$N=$@0(B
 ;;;
 
 (defvar canna:*kanji-mode-string* "[ $B$"(B ]")
@@ -84,7 +116,7 @@
 (defvar mode-line-canna-mode-in-minibuffer canna:*alpha-mode-string*)
 
 (defvar display-minibuffer-mode-in-minibuffer nil) ; same name as TAKANA
-; $B$?$+$J$G$O(B t $B$,09 Jun 1996U%)%k%H$@$1$I!"(Bnil $B$r09 Jun 1996U%)%k%H$K$7$F$*$3$&$+$J!#(B
+; $B$?$+$J$G$O(B t $B$,%G%U%)%k%H$@$1$I!"(Bnil $B$r%G%U%)%k%H$K$7$F$*$3$&$+$J!#(B
 
 (make-variable-buffer-local 'mode-line-canna-mode)
 
@@ -100,7 +132,7 @@
            (not (eq new (minibuffer-window))))
       (save-excursion
         (set-buffer (window-buffer (minibuffer-window)))
-	;; minibuffer$B$N09 Jun 1996U%)%k%H$O%"%k18:57:47!C15 Jun 1996b!<%I(B
+	;; minibuffer$B$N%G%U%)%k%H$O%"%k%U%!%Y%C%H%b!<%I(B
 	(setq mode-line-canna-mode-in-minibuffer canna:*alpha-mode-string*
               canna:*japanese-mode-in-minibuffer* nil	
 	      minibuffer-preprompt nil)))
@@ -201,16 +233,16 @@
 ;;; $B?'$N@_Dj(B
 ;;;
 (defvar canna-use-color nil
-  "*Non-nil $B$G%+%i!<09 Jun 1996#%9@(#)canna.el	1.11l%$$G?'$rIU$1$k(B.
-t $B$N;~$O09 Jun 1996U%)%k%H$N?'$r;HMQ$9$k!#(B
+  "*Non-nil $B$G%+%i!<%G%#%9%W%l%$$G?'$rIU$1$k(B.
+t $B$N;~$O%G%U%)%k%H$N?'$r;HMQ$9$k!#(B
 $B?'$r;XDj$7$?$$;~$O(B, \"$BFI$_$N?'(B\", \"$BJQ49BP>]$N?'(B\", \"$BA*BrBP>]$N?'(B\" $B$N(B
 $B%j%9%H$r@_Dj$9$k(B")
 (defvar canna:color-p nil "$B?'$,;H$($k$+(B")
-(defvar canna:attr-mode nil "$B8=:_$N09 Jun 1996#%9@(#)canna.el	1.11l%$%b!<%I(B")
+(defvar canna:attr-mode nil "$B8=:_$N%G%#%9%W%l%$%b!<%I(B")
 (defvar canna:attr-yomi nil "$BFI$_$N?'B0@-(B")
 (defvar canna:attr-taishou nil "$BJQ49BP>]ItJ,$N?'B0@-(B")
 (defvar canna:attr-select nil
-  "$B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!J,N%;~$N%a%K%e!<$NA*BrBP>]HV9f$N?'B0@-(B")
+  "$B%_%K%P%C%U%!J,N%;~$N%a%K%e!<$NA*BrBP>]HV9f$N?'B0@-(B")
 (defvar canna:attribute-alist		;colored by tagu@ae.keio.ac.jp
   '((yomi (normal . "red") 
 	  (reverse . "moccasin"))
@@ -225,10 +257,10 @@
 (make-variable-buffer-local (defvar canna:*select-overlay* nil))
 
 ;;;
-;;; $B%-!<%^228W%F!<%V%k(B
+;;; $B%-!<%^%C%W%F!<%V%k(B
 ;;;
 
-;; $B18:57:47'%s%9%b!<%I$G$N%m!<%+%k%^231W(B
+;; $B%U%'%s%9%b!<%I$G$N%m!<%+%k%^%C%W(B
 (defvar canna-mode-map (make-sparse-keymap))
 
 (let ((ch 0))
@@ -251,7 +283,7 @@
 (define-key canna-mode-map [kanji]   " ")
 (define-key canna-mode-map [(control space)] [(control @)])
 
-;; $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$K2?$+$rI=<($7$F$$$k;~$N%m!<%+%k%^254W(B
+;; $B%_%K%P%C%U%!$K2?$+$rI=<($7$F$$$k;~$N%m!<%+%k%^%C%W(B
 (defvar canna-minibuffer-mode-map (make-sparse-keymap))
 
 (let ((ch 0))
@@ -275,7 +307,7 @@
 (define-key canna-minibuffer-mode-map [(control space)] [(control @)])
 
 ;;;
-;;; $B%0%m!</export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elk4X?t$N=q$-BX$((B
+;;; $B%0%m!<%P%k4X?t$N=q$-BX$((B
 ;;;
 
 
@@ -353,7 +385,7 @@
 (defun canna:functional-insert-command2 (ch arg)
   "This function actualy isert a converted Japanese string."
   ;; $B$3$N4X?t$OM?$($i$l$?J8;z$rF|K\8lF~NO$N$?$a$N%-!<F~NO$H$7$F<h$j07(B
-  ;; $B$$!"F|K\8lF~NO$NCf4V7k2L$r4^$a$?=hM}$r(BEmacs$B$N/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$KH?1G$5$;$k(B
+  ;; $B$$!"F|K\8lF~NO$NCf4V7k2L$r4^$a$?=hM}$r(BEmacs$B$N%P%C%U%!$KH?1G$5$;$k(B
   ;; $B4X?t$G$"$k!#(B
   (canna:display-candidates (canna-key-proc ch)) )
 
@@ -380,15 +412,7 @@
 		(set-marker canna:*spos-undo-text* (point))
 ;;
 ;; update kbnes
-		(let ((len (length canna-kakutei-string))
-		      (i 0)
-		  ;; $BA^F~$NESCf$G(B blink $B$,5/$-$k$H$&$C$H$*$7$$$N$G!"(B
-		  ;; $B0l;~E*$K(B blink $B$rM^;_$9$k!#(B
-		      (blink-matching-paren nil))
-		  (while (< i len)
-		    (self-insert-internal (aref canna-kakutei-string i))
-		    (setq i (1+ i))
-		    ))
+		(self-insert-string canna-kakutei-string)
 		;; $BL$3NDj$NJ8;z$,$J$/!"3NDjJ8;zNs$N:G8e$,JD$83g8L$N(B
 		;; $BN`$@$C$?$H$-$O(B blink $B$5$;$k!#(B
 		(if (and canna-empty-info
@@ -416,13 +440,7 @@
 	       (t
 ;;
 ;; update kbnes
-		(let ((list (string-to-char-list canna-kakutei-string))
-		  ;; $BA^F~$NESCf$G(B blink $B$,5/$-$k$H$&$C$H$*$7$$$N$G!"(B
-		  ;; $B0l;~E*$K(B blink $B$rM^;_$9$k!#(B
-		      (blink-matching-paren nil))
-		  (while list
-		    (self-insert-internal (car list))
-		    (setq list (cdr list))))
+		(self-insert-string canna-kakutei-string)
 		;; $BL$3NDj$NJ8;z$,$J$/!"3NDjJ8;zNs$N:G8e$,JD$83g8L$N(B
 		;; $BN`$@$C$?$H$-$O(B blink $B$5$;$k!#(B
 		(if (and canna-empty-info
@@ -516,10 +534,10 @@
   (if (stringp canna-mode-string)
       (mode-line-canna-mode-update canna-mode-string))
 
-  ;; $B8uJdI=<($,$J$1$l$P18:57:47'%s%9%b!<%I$+$iH4$1$k!#(B
+  ;; $B8uJdI=<($,$J$1$l$P%U%'%s%9%b!<%I$+$iH4$1$k!#(B
   (cond (canna-empty-info (canna:quit-canna-mode)))
 
-  ;; $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$K=q$/$3$H$,B8:_$9$k$N$G$"$l$P!"$=$l$r%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!(B
+  ;; $B%_%K%P%C%U%!$K=q$/$3$H$,B8:_$9$k$N$G$"$l$P!"$=$l$r%_%K%P%C%U%!(B
   ;; $B$KI=<($9$k!#(B
   (cond (canna-ichiran-string
 	 (canna:minibuffer-input canna-ichiran-string
@@ -538,22 +556,22 @@
 (defun canna:minibuffer-input (str len revpos revlen nfixed)
   "Displaying misc informations for kana-to-kanji input."
 
-  ;; $B:n6H$r%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$K0\$9$N$K:]$7$F!"8=:_$N%&%#%s1.11&$N>pJs$rJ]B8(B
+  ;; $B:n6H$r%_%K%P%C%U%!$K0\$9$N$K:]$7$F!"8=:_$N%&%#%s%I%&$N>pJs$rJ]B8(B
   ;; $B$7$F$*$/!#(B
   (setq canna:*previous-window* (selected-window))
 ;  (select-frame (window-frame (minibuffer-window)))
 
-;; $B<+J,$KMh$kA0$,%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$+$I$&$+$rJQ?t$K$G$b$$$l$F$*$$$?J}$,$$$$$J$"!#(B
+;; $B<+J,$KMh$kA0$,%_%K%P%C%U%!$+$I$&$+$rJQ?t$K$G$b$$$l$F$*$$$?J}$,$$$$$J$"!#(B
 
   (if (not canna:*cursor-was-in-minibuffer*)
       (progn
-	;; $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$r%/%j%"$9$k!#(B
+	;; $B%_%K%P%C%U%!$r%/%j%"$9$k!#(B
 ;	(if (eq canna:*previous-window* (selected-window))
 ;	    (progn
 ;	      (canna:henkan-attr-off (point-min) (point-max))
 ;	      (canna:delete-last-preedit) ))
 
-        ;; $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!%&%#%s1.11&$K8uJd0lMwMQ$N/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$r3d$jEv$F$k!#(B
+        ;; $B%_%K%P%C%U%!%&%#%s%I%&$K8uJd0lMwMQ$N%P%C%U%!$r3d$jEv$F$k!#(B
 	(setq canna:*saved-minibuffer* (window-buffer (minibuffer-window)))
 ;	(set-window-buffer (minibuffer-window)
 ;			   (get-buffer-create canna:*menu-buffer*))
@@ -564,7 +582,7 @@
         ;;                       (window-frame (minibuffer-window)))
 	;; end of modification
 	
-	;; $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$N%-!<%^567W$rJ]B8$7$F$*$/!#(B
+	;; $B%_%K%P%C%U%!$N%-!<%^%C%W$rJ]B8$7$F$*$/!#(B
 	(setq canna:*minibuffer-local-map-backup* (current-local-map))
 	))
   (select-window (minibuffer-window))
@@ -583,7 +601,7 @@
 
   (insert str)
 
-  ;; $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$GH?E>I=<($9$k$Y$-J8;z$N$H$3$m$K%+!<%=%k$r0\F0$9$k!#(B
+  ;; $B%_%K%P%C%U%!$GH?E>I=<($9$k$Y$-J8;z$N$H$3$m$K%+!<%=%k$r0\F0$9$k!#(B
   (cond ((> revlen 0)
 	 (backward-char (- len revpos)) ))
   ;;(message "%s" (selected-frame)) (sit-for 3)
@@ -593,14 +611,14 @@
        (canna:select-attr-on (point) 
 			     (save-excursion (forward-char 1) (point))))
   
-  ;; $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$KI=<($9$k$Y$-J8;zNs$,11kJ8;zNs$J$N$G$"$l$P!"A0$N%&%#(B
-  ;; $B%s1.11&$KLa$k!#(B
+  ;; $B%_%K%P%C%U%!$KI=<($9$k$Y$-J8;zNs$,%L%kJ8;zNs$J$N$G$"$l$P!"A0$N%&%#(B
+  ;; $B%s%I%&$KLa$k!#(B
   (if (or (zerop len) canna-empty-info)
       (progn
 	(setq canna:*cursor-was-in-minibuffer* nil)
 	(use-local-map canna:*minibuffer-local-map-backup*)
 
-	;; $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!%&%#%s1.11&$N/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$r85$KLa$9!#(B
+	;; $B%_%K%P%C%U%!%&%#%s%I%&$N%P%C%U%!$r85$KLa$9!#(B
 	(set-window-buffer (minibuffer-window) canna:*saved-minibuffer*)
 ;	(setq canna:*saved-minibuffer* nil)
 	;; modified by $B<i2,(B $BCNI'(B <morioka@jaist.ac.jp>, 1996/6/7
@@ -608,7 +626,7 @@
         ;; (redirect-frame-focus (window-frame canna:*previous-window*)
         ;;                       canna:*saved-redirection*)
 	;; end of modification
-	;; $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$GF~NO$7$F$$$?$N$J$i0J2<$b$9$k!#(B
+	;; $B%_%K%P%C%U%!$GF~NO$7$F$$$?$N$J$i0J2<$b$9$k!#(B
 ;	(if (eq canna:*previous-window* (selected-window))
 ;	    (progn
 ;	      (canna:insert-fixed nfixed)
@@ -632,11 +650,11 @@
 
 ;;;
 ;;; $B$+$s$J%b!<%I$N<gLr$O!"<!$N(B canna-self-insert-command $B$G$"$k!#$3$N(B
-;;; $B%3%^%s%I$OA4$F$N%0%i18:57:47#635/%-!<$K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.el$%s%I$5$l$k!#(B
+;;; $B%3%^%s%I$OA4$F$N%0%i%U%#%C%/%-!<$K%P%$%s%I$5$l$k!#(B
 ;;;
-;;; $B$3$N4X?t$G$O!"8=:_$N%b!<%I$,F|K\8lF~NO%b!<%I$+$I$&$+$r@(#) canna.el 1.11@(#)'637/$7$F!"(B
-;;; $BF|K\8lF~NO%b!<%I$G$J$$$N$G$"$l$P!"%7%9editor/lisp/mule/SCCS/s.canna.el`$N(B self-insert-command 
-;;; $B$r8F$V!#F|K\8lF~NO%b!<%I$G$"$l$P!"18:57:47'%s%9%b!<%I$KF~$j!"(B
+;;; $B$3$N4X?t$G$O!"8=:_$N%b!<%I$,F|K\8lF~NO%b!<%I$+$I$&$+$r%A%'%C%/$7$F!"(B
+;;; $BF|K\8lF~NO%b!<%I$G$J$$$N$G$"$l$P!"%7%9%F%`$N(B self-insert-command 
+;;; $B$r8F$V!#F|K\8lF~NO%b!<%I$G$"$l$P!"%U%'%s%9%b!<%I$KF~$j!"(B
 ;;; canna-functional-insert-command $B$r8F$V!#(B
 ;;;
 
@@ -648,7 +666,7 @@
   (interactive "*p")
   (adjust-minibuffer-mode)
   (if (and canna:*japanese-mode*
-	   ;; $B18:57:47'%s%9%b!<%I$@$C$?$i$b$&0lEY18:57:47'%s%9%b!<%I$KF~$C$?$j$7(B
+	   ;; $B%U%'%s%9%b!<%I$@$C$?$i$b$&0lEY%U%'%s%9%b!<%I$KF~$C$?$j$7(B
 	   ;; $B$J$$!#(B
 	   (not canna:*fence-mode*) )
       (canna:enter-canna-mode-and-functional-insert)
@@ -821,7 +839,7 @@
 	    (canna:enter-canna-mode)
 	    (canna:display-candidates
 	     (canna-touroku-string (buffer-substring start end))) ))
-    (message "$B%j!<%8%g%s$,IT@5$G$9!#11k%j!<%8%g%s$+!"2~9T$,4^$^$l$F$$$^$9!#(B")
+    (message "$B%j!<%8%g%s$,IT@5$G$9!#%L%k%j!<%8%g%s$+!"2~9T$,4^$^$l$F$$$^$9!#(B")
     ))
 
 (defun canna-extend-mode ()
@@ -829,9 +847,9 @@
   (interactive "*")
 ;  (if (and (not (eq (window-frame (minibuffer-window)) (selected-frame)))
 ;	   (not canna:*fence-mode*))
-	   ;; $B%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$rJ,N%$7$F$$$k;~$O0l;~E*$K18:57:47'%s%9%b!<%I$KF~$k(B
+	   ;; $B%_%K%P%C%U%!$rJ,N%$7$F$$$k;~$O0l;~E*$K%U%'%s%9%b!<%I$KF~$k(B
            ;; $B$=$&$7$J$$$H%a%K%e!<$rA*$Y$J$$(B
-           ;; (focus$B$,%_%K/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.elC18:57:47!$K9T$+$J$$$+$i(B)
+           ;; (focus$B$,%_%K%P%C%U%!$K9T$+$J$$$+$i(B)
   (if (not canna:*fence-mode*)
       (progn
 	(setq canna:*exit-japanese-mode* (not canna:*japanese-mode*))
@@ -951,11 +969,11 @@
 	     ))
 	   ;;$BG[?'@_Dj=*N;(B
 	   
-	   ;; $B!X$+$s$J!Y%7%9editor/lisp/mule/SCCS/s.canna.el`$N=i4|2=(B
+	   ;; $B!X$+$s$J!Y%7%9%F%`$N=i4|2=(B
 	   
 	   (setq init-val (canna:initialize))
 	   
-	   ;; $B%-!<$N/export/willow0/xemacs-20.0-release/editor/lisp/mule/SCCS/s.canna.el$%s09 Jun 1996#%s%0(B
+	   ;; $B%-!<$N%P%$%s%G%#%s%0(B
 	   
 	   (let ((ch 32))
 	     (while (< ch 127)
@@ -971,7 +989,7 @@
 			     (setq ok t) ))
 		      (setq keys (cdr keys))
 		      ) ok))
-		 (t ; $B09 Jun 1996U%)%k%H$N@_Dj(B
+		 (t ; $B%G%U%)%k%H$N@_Dj(B
 		  (global-set-key "\C-o" 'canna-toggle-japanese-mode) ))
 
 	   (if (not (keymapp (global-key-binding "\e[")))
@@ -1004,7 +1022,7 @@
 	   (canna:create-mode-line)
 	   (mode-line-canna-mode-update canna:*alpha-mode-string*)
 
-	 ;; $B%7%9editor/lisp/mule/SCCS/s.canna.el`4X?t$N=q$-BX$((B
+	 ;; $B%7%9%F%`4X?t$N=q$-BX$((B
 
 ;	   (fset 'abort-recursive-edit 
 ;		 (symbol-function 'canna:abort-recursive-edit))
@@ -1020,7 +1038,7 @@
 	     (terpri)
 	     (print-help-return-message)) )
 
-	  (t ; $B!X$+$s$J!Y%7%9editor/lisp/mule/SCCS/s.canna.el`$,;H$($J$+$C$?;~$N=hM}(B
+	  (t ; $B!X$+$s$J!Y%7%9%F%`$,;H$($J$+$C$?;~$N=hM}(B
 	   (beep)
 	   (with-output-to-temp-buffer "*canna-warning*"
 	     (princ "$B$3$N(B Mule $B$G$O(B canna $B$,;H$($^$;$s(B")
@@ -1071,7 +1089,7 @@
 	      (setq canna:*exit-japanese-mode* t) ))
 ;	      (canna-toggle-japanese-mode) ))
 	(if (not canna:*fence-mode*)
-	    ;; $B18:57:47'%s%9%b!<%I$@$C$?$i$b$&0lEY18:57:47'%s%9%b!<%I$KF~$C$?$j$7(B
+	    ;; $B%U%'%s%9%b!<%I$@$C$?$i$b$&0lEY%U%'%s%9%b!<%I$KF~$C$?$j$7(B
 	    ;; $B$J$$!#(B
 	    (canna:enter-canna-mode) )
 	(canna:display-candidates 

--Multipart_Wed_Jun_19_14:00:56_1996-1
Content-Type: text/plain; charset=US-ASCII

-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---
--Multipart_Wed_Jun_19_14:00:56_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 00:17:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA26982 for xemacs-beta-people; Wed, 19 Jun 1996 00:17:36 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA26979 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 00:17:35 -0500 (CDT)
Received: from caddy.arnet.com (caddy.arnet.com [199.86.10.214]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA01698 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 00:17:32 -0500 (CDT)
Subject: 19.14b26 qualified success on SCO/OSR5
To: xemacs-beta@xemacs.org
Date: Wed, 19 Jun 1996 00:16:15 -0500 (CDT)
From: Robert Lipe <robertl@arnet.com>
In-Reply-To: <199606190323.WAA24419@xemacs.cs.uiuc.edu> from "Chuck Thompson" at Jun 18, 96 10:23:36 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID:  <9606190016.aa05844@caddy.arnet.com>


I patched to 26 from a fresh 25.

host=i586-unknown-sco3.2v5.0.0  (SCO OpenServer 5.0)

../*b25/configure --with-gcc=no --site-includes=/usr/local/include \
 --site-libraries=/usr/local/lib --with-xpm --with-xface --with-sound=nas \
 --dynamic  | tee config.log

Configured for `i586-unknown-sco3.2v5.0.0'.

  Where should the build process find the source code?    /home/robertl/src/xx/xemacs-19.14-b25
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sco5-shr.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              cc -g 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in network sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


Tty (even color) and X modes both boot and look OK based on 60
seconds of eval.

Gnuserv/gnuclient work as we want them to.  This was a problem on
older versions.

Current unresolved issues on SCO.

	M-x getenv still fails on my machine regardless of compiler
	(sco or gcc) used, but only if dynamically linked.  This 
	means default installation fails becuase the binary can't 
	grok $PATH Kean doesn't see this on his system.    We are 
	still investigating.

	make all-elc now loops when loading bytecomp instead of 
	building  VM. Seems to happen regardless of optimization 
	or compiler, with or without relocating malloc, with or 
	without system malloc. Kean and I are still investigating.

I'm not certain that either of these are show stoppers, but they 
sure are puzzlers.


Thanx, guys.

RJL

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 00:46:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA27088 for xemacs-beta-people; Wed, 19 Jun 1996 00:46:34 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA27085 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 00:46:33 -0500 (CDT)
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA12069 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 00:46:35 -0500 (CDT)
Received: from FISHKILL by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4835;
   Wed, 19 Jun 96 01:46:17 EDT
Received: by FISHKILL (XAGENTA 4.0) id 1065; Wed, 19 Jun 1996 01:46:31 -0400 
Received: by spacedog.fishkill.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA27632; Wed, 19 Jun 1996 01:46:19 -0400
Date: Wed, 19 Jun 1996 01:46:19 -0400
Message-Id: <9606190546.AA27632@spacedog.fishkill.ibm.com>
From: "Doug Keller" <dkeller@VNET.IBM.COM>
To: xemacs-beta@cs.uiuc.edu
Subject: Sucess with b25 under AIX 3.2.5

Configured for `rs6000-ibm-aix3.2.5'.

  Where should the build process find the source code?    /afs/eds/u/hines/beta/xemacs/xemacs-19.14-b25
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/aix3-2-5.h' and `m/ibmrs6000.h'
  What compiler should XEmacs be built with?              xlc -O -Q -qnoansialias -D_ALL_SOURCE -tl -B/usr/ccs/bin/325/
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /afs/eds/u/hines/beta/xemacs/include
  Additional libraries:                                   /afs/eds/u/hines/beta/xemacs/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 02:54:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA27464 for xemacs-beta-people; Wed, 19 Jun 1996 02:54:01 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA27461 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 02:54:00 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA13240 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 02:53:54 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA12003; Wed, 19 Jun 1996 09:53:43 +0200
Received: from loopback by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA20488; Wed, 19 Jun 1996 09:53:42 +0200
Message-Id: <9606190753.AA20488@modas.informatik.uni-tuebingen.de>
To: xemacs-beta@cs.uiuc.edu
Subject: b26 success on AIX 4.1.4
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 19 Jun 1996 09:53:40 +0200
From: "Michael Sperber [Mr. Preprocessor]" <sperber@informatik.uni-tuebingen.de>


... AIXwindows, xpm, jpeg, gcc 2.7.2.  Previous betas also worked with
xlc with no problems.

All in all, I've had very few problems running beta since about b21 or
so.  I really like it.

Cheers =8-} Mike

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 03:29:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA01086 for xemacs-beta-people; Wed, 19 Jun 1996 03:29:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA01083 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 03:29:56 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA01968 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 03:29:51 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id RAA18607; Wed, 19 Jun 1996 17:29:48 +0900 (JST)
Message-Id: <199606190829.RAA18607@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: [20.0 b25] patch about CNS character sets
Mime-Version: 1.0 (SEMI mime-edit 0.26)
Content-Type: multipart/mixed;
 boundary="Multipart_Wed_Jun_19_17:29:43_1996-1"
Content-Transfer-Encoding: 7bit
Date: Wed, 19 Jun 1996 17:29:48 JST
Sender: morioka@jaist.ac.jp

--Multipart_Wed_Jun_19_17:29:43_1996-1
Content-Type: text/plain; charset=US-ASCII

  Registry of CNS character sets seems strange. According to naming
rule of X fonts, registry must be like

	CNS11643-1

or

	CNS11643.1992-1

however registry of mule is like

	CNS11643.1

namely it specifies plane number to year part.

  Following is patch:


--Multipart_Wed_Jun_19_17:29:43_1996-1
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="cns.patch"
Content-Transfer-Encoding: 7bit

--- src/mule-charset.c.orig	Mon Apr 15 04:03:19 1996
+++ src/mule-charset.c	Wed Jun 19 10:24:02 1996
@@ -1376,13 +1376,13 @@
 		  CHARSET_TYPE_94X94, 2, 0, 'G',
 		  CHARSET_LEFT_TO_RIGHT,
 		  build_string ("Chinese CNS Plane 1"),
-		  build_string ("CNS11643.1"));
+		  build_string ("CNS11643.1992-1"));
   Vcharset_chinese_cns_2 =
     make_charset (Qchinese_cns_2, LEADING_BYTE_CHINESE_CNS_2, 3,
 		  CHARSET_TYPE_94X94, 2, 0, 'H',
 		  CHARSET_LEFT_TO_RIGHT,
 		  build_string ("Chinese CNS Plane 2"),
-		  build_string ("CNS11643.2"));
+		  build_string ("CNS11643.1992-2"));
   Vcharset_chinese_big5_1 =
     make_charset (Qchinese_big5_1, LEADING_BYTE_CHINESE_BIG5_1, 3,
 		  CHARSET_TYPE_94X94, 2, 0, '0',
--- lisp/mule/chinese-hooks.el.orig	Thu May 16 21:26:05 1996
+++ lisp/mule/chinese-hooks.el	Wed Jun 19 10:25:22 1996
@@ -48,7 +48,7 @@
 ;; that appear once in some ancient manuscript and whose meaning
 ;; is unknown.
 (make-charset 'chinese-cns-3 "CNS Plane3"
-	      '(registry "CNS11643.3"
+	      '(registry "CNS11643.1992-3"
 		dimension 2
 		chars 94
 		final ?I
@@ -56,7 +56,7 @@
 		))
 
 (make-charset 'chinese-cns-4 "CNS Plane4"
-	      '(registry "CNS11643.4"
+	      '(registry "CNS11643.1992-4"
 		dimension 2
 		chars 94
 		final ?J
@@ -64,7 +64,7 @@
 		))
 
 (make-charset 'chinese-cns-5 "CNS Plane5"
-	      '(registry "CNS11643.5"
+	      '(registry "CNS11643.1992-5"
 		dimension 2
 		chars 94
 		final ?K
@@ -72,7 +72,7 @@
 		))
 
 (make-charset 'chinese-cns-6 "CNS Plane6"
-	      '(registry "CNS11643.6"
+	      '(registry "CNS11643.1992-6"
 		dimension 2
 		chars 94
 		final ?L
@@ -80,7 +80,7 @@
 		))
 
 (make-charset 'chinese-cns-7 "CNS Plane7"
-	      '(registry "CNS11643.7"
+	      '(registry "CNS11643.1992-7"
 		dimension 2
 		chars 94
 		final ?M

--Multipart_Wed_Jun_19_17:29:43_1996-1
Content-Type: text/plain; charset=US-ASCII


  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---
--Multipart_Wed_Jun_19_17:29:43_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 02:43:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA27451 for xemacs-beta-people; Wed, 19 Jun 1996 02:43:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA27448 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 02:43:43 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA01824 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 02:43:40 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA00621; Wed, 19 Jun 1996 00:36:40 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA24791; Wed, 19 Jun 1996 09:36:31 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA02980; Wed, 19 Jun 1996 09:36:30 +0200
Date: Wed, 19 Jun 1996 09:36:30 +0200
Message-Id: <9606190736.AA02980@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: dump in select_filedesc, assert(!filedesc_to_what_closure[fd])
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

I left 14b25 running over night in vm, with it automatically getting new
mail (checking once a minute).  When I came in this morning, XEmacs/vm
was gone, but a core file was left behind.  Looking at the timestamp on
the core file, the crash occurred about 3.5 hours after I had gone home.
My workstation was paused at the time.  I can't remember, but XEmacs
might've been iconified.

The Lisp and C traces are below.  Looking at the Lisp backtrace, new
mail had just arrived, and my audio notification subprocess was
activated.

Chuck's XSETCONSOLE patch to frame.c had been applied.

        Steve


===== Lisp backtrace =====

Fatal error: assertion failed, file event-Xt.c, line 1536, !filedesc_to_what_closure[fd]

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb `which xemacs` core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  # (unwind-protect ...)
  start-process-internal("background-2" "*background-2*" "/bin/csh" "-c" "say -d 0 -a \"[:tone 100,800][:np][:rate 120][:volume set 90]You have 8 new mail messages.[:np][:rate 120][:volume set 90]\"")
  apply(start-process-internal "background-2" "*background-2*" "/bin/csh" ("-c" "say -d 0 -a \"[:tone 100,800][:np][:rate 120][:volume set 90]You have 8 new mail messages.[:np][:rate 120][:volume set 90]\""))
  # bind (program-args program buffer name)
  start-process("background-2" "*background-2*" "/bin/csh" "-c" "say -d 0 -a \"[:tone 100,800][:np][:rate 120][:volume set 90]You have 8 new mail messages.[:np][:rate 120][:volume set 90]\"")
  apply(start-process "background-2" "*background-2*" "/bin/csh" ("-c" "say -d 0 -a \"[:tone 100,800][:np][:rate 120][:volume set 90]You have 8 new mail messages.[:np][:rate 120][:volume set 90]\""))
  # bind (process-environment default-directory switches command buffer name)
  comint-exec-1("background-2" "*background-2*" "/bin/csh" ("-c" "say -d 0 -a \"[:tone 100,800][:np][:rate 120][:volume set 90]You have 8 new mail messages.[:np][:rate 120][:volume set 90]\""))
  # (unwind-protect ...)
  # bind (switches startfile command name buffer)
  comint-exec("*background-2*" "background-2" "/bin/csh" nil ("-c" "say -d 0 -a \"[:tone 100,800][:np][:rate 120][:volume set 90]You have 8 new mail messages.[:np][:rate 120][:volume set 90]\""))
  # bind (job-number job-name dir buffer-name command)
  background("say -d 0 -a \"[:tone 100,800][:np][:rate 120][:volume set 90]You have 8 new mail messages.[:np][:rate 120][:volume set 90]\"")
  # (unwind-protect ...)
  # bind (match-data output-buffer command)
  default-dir-real-shell-command("say -d 0 -a \"[:tone 100,800][:np][:rate 120][:volume set 90]You have 8 new mail messages.[:np][:rate 120][:volume set 90]\" &" nil)
  # bind (default-directory insert command)
  ad-Orig-shell-command("say -d 0 -a \"[:tone 100,800][:np][:rate 120][:volume set 90]You have 8 new mail messages.[:np][:rate 120][:volume set 90]\" &" nil)
  byte-code("	\n\"!" [ad-Orig-shell-command command insert ad-return-value get-buffer-window "*Shell Command Output*" shown] 3)
  # (unwind-protect ...)
  # bind (shown ad-return-value insert command)
  shell-command("say -d 0 -a \"[:tone 100,800][:np][:rate 120][:volume set 90]You have 8 new mail messages.[:np][:rate 120][:volume set 90]\" &")
  # bind (saying background-string sync-string delay-string device-string volume-string rate-string voice-string background-show waitp errorp phoneticallyp device volume rate voice string)
  dectalk-say("You have 8 new mail messages.[:np][:rate 120][:volume set 90]" "Paul" 120 90 0 nil t nil)
  # bind (device volume rate voice G49619 waitp errorp string situation)
  dectalk-situation-say("Default" "You have 8 new mail messages." t nil)
  (if (string= G7932 "") nil (dectalk-situation-say "Default" (or G7932 "Success in some form") t G7934))
)
  (unless (string= G7932 "") (dectalk-situation-say "Default" (or G7932 "Success in some form") t G7934))
)
  (if (progn (with-dectalk-error G7930 G7931 t)) (unless (string= G7932 "") (dectalk-situation-say "Default" ... t G7934)) (unless (string= G7933 "") (dectalk-situation-say "Failure" ... t G7934)))
)
  # bind (G7934 G7933 G7932)
  (let ((G7932 G7929) (G7933 nil) (G7934 G7931)) (assert (or ... ...)) (if (progn ...) (unless ... ...) (unless ... ...)))
)
  (with-dectalk-message-notification G7929 nil G7931 (with-dectalk-error G7930 G7931 t))
)
  (with-dectalk-message G7929 nil G7931 (with-dectalk-error G7930 G7931 t))
)
  (with-dectalk-message-default G7929 G7931 (with-dectalk-error G7930 G7931 t))
)
  # bind (G7931 G7930 G7929)
  (let* ((G7929 notification) (G7930 ...) (G7931 nil)) (with-dectalk-message-default G7929 G7931 (with-dectalk-error G7930 G7931 t)))
)
  (with-dectalk-notification notification nil t)
)
  (cond ((vm-audio-notification-p seconds) (with-dectalk-notification notification nil t)) ((not quietp) (beep) (message notification)))
)
  (progn (cond (... ...) (... ... ...)))
)
  (if notification (progn (cond ... ...)))
)
  (when notification (cond (... ...) (... ... ...)))
)
  # bind (notification)
  (let ((notification ...)) (when notification (cond ... ...)))
)
  # bind (quietp seconds)
  vm-new-messages-notification()
  run-hooks(vm-arrived-messages-hook)
  # bind (tail-cons b-list new-messages gobble-order dont-read-attributes)
  vm-assimilate-new-messages(t)
  # (unwind-protect ...)
  # bind (b-list)
  vm-get-mail-itimer-function()
  # bind (current-itimer)
  itimer-callback(("vm-get-mail" 60 60 vm-get-mail-itimer-function 659))
  # (condition-case ... . error)
  # (catch top-level ...)
Abort process (core dumped)


===== C stacktrace =====

% dbx /usr/local/xemacs-beta/bin/xemacs-19.14-b25 core
dbx version 3.11.8
Type 'help' for help.
Core file created by program "xemacs-19.14-b25"

signal IOT/Abort trap at >*[__kill, 0x3ff8010ce68] 	beq	r19, 0x3ff8010ce80
(dbx) where
where
>  0 __kill(0x1201b9698, 0x3ffc0091560, 0x120099d40, 0x140169010, 0x140124978) [0x3ff8010ce68]
   1 fatal_error_signal(sig = 1) ["emacs.c":193, 0x120099dc8]
   2 __kill(0x3ffc00802f0, 0x59, 0x0, 0x0, 0x0) [0x3ff8010ce64]
   3 raise(0x6, 0x0, 0x2, 0x11fff6d20, 0x59) [0x3ff80121830]
   4 abort(0x7c04, 0x3ff800e0ca8, 0x59, 0x120099c40, 0x0) [0x3ff8010fc80]
   5 assert_failed(file = 0x3a7, line = 6, expr = 0x11fff7310 = "@^\\t ^A") ["emacs.c":1787, 0x12009c68c]
   6 emacs_Xt_select_process(p = 0x140dbe3000) ["event-Xt.c":1604, 0x1201db0ec]
   7 event_stream_select_process(proc = 0x3a7) ["event-stream.c":545, 0x1200b7850]
   8 create_process(process = (...), new_argv = 0x11fff7458, current_dir = 0x1408fb6c0 = "/usr/users/carney/Mail") ["process.c":1050, 0x120159464]
   9 Fstart_process_internal(nargs = 5, args = 0x11fff7670) ["process.c":1228, 0x120159c6c]
  10 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fff7668) ["eval.c":3191, 0x1200a57e4]
  11 Fapply(nargs = 5, args = 0x11fff7810) ["eval.c":3471, 0x1200a67dc]
  12 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fff7808) ["eval.c":3191, 0x1200a57e4]
  13 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  14 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  15 funcall_lambda(fun = (...), nargs = 5, arg_vector = 0x11fff7d60) ["eval.c":3636, 0x1200a75bc]
  16 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fff7d58) ["eval.c":3223, 0x1200a5a28]
  17 Fapply(nargs = 5, args = 0x11fff7f00) ["eval.c":3471, 0x1200a67dc]
  18 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fff7ef8) ["eval.c":3191, 0x1200a57e4]
  19 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  20 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  21 funcall_lambda(fun = (...), nargs = 4, arg_vector = 0x11fff8470) ["eval.c":3636, 0x1200a75bc]
  22 funcall_recording_as(recorded_as = (...), nargs = 4, args = 0x11fff8468) ["eval.c":3223, 0x1200a5a28]
  23 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  24 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  25 funcall_lambda(fun = (...), nargs = 5, arg_vector = 0x11fff89e8) ["eval.c":3636, 0x1200a75bc]
  26 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fff89e0) ["eval.c":3223, 0x1200a5a28]
  27 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  28 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  29 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fff8f60) ["eval.c":3636, 0x1200a75bc]
  30 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fff8f58) ["eval.c":3223, 0x1200a5a28]
  31 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  32 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  33 funcall_lambda(fun = (...), nargs = 2, arg_vector = 0x11fff94d8) ["eval.c":3636, 0x1200a75bc]
  34 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fff94d0) ["eval.c":3223, 0x1200a5a28]
  35 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  36 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  37 funcall_lambda(fun = (...), nargs = 2, arg_vector = 0x11fff9a30) ["eval.c":3636, 0x1200a75bc]
  38 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fff9a28) ["eval.c":3223, 0x1200a5a28]
  39 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  40 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  41 primitive_funcall(fn = 0x3ffbfff22a8, nargs = 536834832, args = (nil)) ["eval.c":3488, 0x1200a68d0]
  42 funcall_subr(subr = 0x6, args = 0x11fff7310) ["eval.c":3526, 0x1200a6ba8]
  43 Feval(form = (...)) ["eval.c":3064, 0x1200a5028]
  44 Fprogn(args = (...)) ["eval.c":746, 0x12009dc44]
  45 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":633, 0x1200681fc]
  46 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffa618) ["eval.c":3636, 0x1200a75bc]
  47 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffa610) ["eval.c":3223, 0x1200a5a28]
  48 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  49 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  50 funcall_lambda(fun = (...), nargs = 8, arg_vector = 0x11fffabc0) ["eval.c":3636, 0x1200a75bc]
  51 funcall_recording_as(recorded_as = (...), nargs = 8, args = 0x11fffabb8) ["eval.c":3223, 0x1200a5a28]
  52 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  53 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  54 funcall_lambda(fun = (...), nargs = 4, arg_vector = 0x11fffb058) ["eval.c":3636, 0x1200a75bc]
  55 apply_lambda(fun = (...), numargs = 4, unevalled_args = (...)) ["eval.c":3559, 0x1200a6d38]
  56 Feval(form = (...)) ["eval.c":3086, 0x1200a5154]
  57 Fprogn(args = (...)) ["eval.c":746, 0x12009dc44]
  58 Fif(args = (...)) ["eval.c":673, 0x12009d9e4]
  59 Feval(form = (...)) ["eval.c":2992, 0x1200a4d34]
  60 Feval(form = (...)) ["eval.c":3084, 0x1200a5128]
  61 Fif(args = (...)) ["eval.c":672, 0x12009d994]
  62 Feval(form = (...)) ["eval.c":2992, 0x1200a4d34]
  63 Flet(args = (...)) ["eval.c":920, 0x12009e76c]
  64 Feval(form = (...)) ["eval.c":2992, 0x1200a4d34]
  65 Feval(form = (...)) ["eval.c":3084, 0x1200a5128]
  66 Feval(form = (...)) ["eval.c":3084, 0x1200a5128]
  67 Feval(form = (...)) ["eval.c":3084, 0x1200a5128]
  68 FletX(args = (...)) ["eval.c":862, 0x12009e294]
  69 Feval(form = (...)) ["eval.c":2992, 0x1200a4d34]
  70 Feval(form = (...)) ["eval.c":3084, 0x1200a5128]
  71 Fprogn(args = (...)) ["eval.c":746, 0x12009dc44]
  72 Fcond(args = (...)) ["eval.c":702, 0x12009db24]
  73 Feval(form = (...)) ["eval.c":2992, 0x1200a4d34]
  74 Fprogn(args = (...)) ["eval.c":746, 0x12009dc44]
  75 Feval(form = (...)) ["eval.c":2992, 0x1200a4d34]
  76 Fif(args = (...)) ["eval.c":672, 0x12009d994]
  77 Feval(form = (...)) ["eval.c":2992, 0x1200a4d34]
  78 Feval(form = (...)) ["eval.c":3084, 0x1200a5128]
  79 Flet(args = (...)) ["eval.c":920, 0x12009e76c]
  80 Feval(form = (...)) ["eval.c":2992, 0x1200a4d34]
  81 funcall_lambda(fun = (...), nargs = 0, arg_vector = 0x11fffdb80) ["eval.c":3628, 0x1200a74a8]
  82 funcall_recording_as(recorded_as = (...), nargs = 0, args = 0x11fffdb78) ["eval.c":3223, 0x1200a5a28]
  83 run_hook_with_args_in_buffer(buf = 0x6, nargs = 1, args = 0x11fffdb78, cond = RUN_HOOKS_TO_COMPLETION) ["eval.c":3827, 0x1200a7e28]
  84 run_hook_with_args(nargs = 6, args = 0x11fff7310, cond = RUN_HOOKS_TO_COMPLETION) ["eval.c":3841, 0x1200a7f08]
  85 Frun_hooks(nargs = 6, args = 0x11fff7310) ["eval.c":3693, 0x1200a7984]
  86 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffdc78) ["eval.c":3191, 0x1200a57e4]
  87 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  88 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  89 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffe1e0) ["eval.c":3636, 0x1200a75bc]
  90 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffe1d8) ["eval.c":3223, 0x1200a5a28]
  91 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  92 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  93 funcall_lambda(fun = (...), nargs = 0, arg_vector = 0x11fffe738) ["eval.c":3636, 0x1200a75bc]
  94 funcall_recording_as(recorded_as = (...), nargs = 0, args = 0x11fffe730) ["eval.c":3223, 0x1200a5a28]
  95 Ffuncall(nargs = 6, args = 0x11fff7310) ["eval.c":3253, 0x1200a5b04]
  96 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d14]
  97 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffeca0) ["eval.c":3636, 0x1200a75bc]
  98 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffec98) ["eval.c":3223, 0x1200a5a28]
  99 call1(fn = (...), arg0 = (...)) ["eval.c":3992, 0x1200a83b0]
 100 execute_internal_event(event = (...)) ["event-stream.c":2817, 0x1200bf0c4]
 101 Fdispatch_event(event = (...)) ["event-stream.c":3814, 0x1200c3a2c]
 102 Fcommand_loop_1() ["cmdloop.c":542, 0x12007279c]
 103 command_loop_1(dummy = (...)) ["cmdloop.c":462, 0x12007230c]
 104 condition_case_1(handlers = (...), bfun = 0x120072260, barg = (...), hfun = 0x120072a00, harg = (...)) ["eval.c":1672, 0x12009feb0]
 105 command_loop_2(dummy = (...)) ["cmdloop.c":235, 0x120072bdc]
 106 internal_catch(tag = (...), func = 0x11fff7310, arg = (...), threw = (nil)) ["eval.c":1347, 0x12009f99c]
 107 initial_command_loop(load_me = (...)) ["cmdloop.c":273, 0x12007180c]
 108 Frunning_temacs_p() ["emacs.c":1317, 0x12009b7ec]
(dbx) 

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 05:00:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA01423 for xemacs-beta-people; Wed, 19 Jun 1996 05:00:55 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA01420 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 05:00:54 -0500 (CDT)
Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA02038 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 05:00:50 -0500 (CDT)
Received: from djp-fornet.cern.ch (djp-fornet.cern.ch [137.138.36.141]) by server21.digital.fr (8.7.3/8.7) with SMTP id MAA24218 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 12:00:26 +0200 (MET DST)
Received: by djp-fornet.cern.ch; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA12226; Wed, 19 Jun 1996 11:58:00 +0200
Date: Wed, 19 Jun 1996 11:58:00 +0200
Message-Id: <9606190958.AA12226@djp-fornet.cern.ch>
From: Stephen Carney <carney@xemacs.org>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.14-b26 build success on Digital UNIX V3.2D
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

Hardware  : DEC 3000-500
OS        : Digital UNIX V3.2D (41)
Compiler  : gcc-2.7.2
Libraries : X11R5, Motif, XAUTH, XPM, X-Face, DBM, GIF
XEmacs    : 19.14-b26 (full kit)

Configured for `alpha-dec-osf3.2'.
  Where should the build process find the source code?    /kits/install/xemacs/beta
  What installation prefix should install use?            /usr/local/xemacs-beta
  What operating system and machine description files should XEmacs use?
        `s/decosf3-2.h' and `m/alpha.h'
  What compiler should XEmacs be built with?              gcc -g2 -O3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? no
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 06:18:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA02130 for xemacs-beta-people; Wed, 19 Jun 1996 06:18:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA02127 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 06:18:02 -0500 (CDT)
Received: from sys3.cambridge.uk.psi.net (sys3.cambridge.uk.psi.net [154.32.106.10]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA02060 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 06:17:57 -0500 (CDT)
Received: from arrow by sys3.cambridge.uk.psi.net (8.7.5/SMI-5.5-UKPSINet)
	id MAA15104; Wed, 19 Jun 1996 12:15:55 +0100 (BST)
Received: by arrow (5.x/SMI-SVR4)
	id AA22676; Wed, 19 Jun 1996 12:12:33 +0100
>Received: from dx2.delcam.com by delcam.com; Wed, 19 Jun 96 12:11:45 BST
Received: from delcam by arrow.delcam.com; Wed, 19 Jun 1996 12:12 BST
Received: from dx2.delcam.com by delcam.com; Wed, 19 Jun 96 12:11:45 BST
Received: by dx2.delcam.com; Wed, 19 Jun 96 12:08:22 +0100
Message-Id: <28674.9606191108@dx2.delcam.com>
Date: Wed, 19 Jun 96 12:08:22 +0100
From: Paul Bibilo <peb@delcam.com>
To: xemacs-beta@xemacs.org
Subject: XEmacs-19.14-b26 Success on IRIX 5.2
X-Face:  "+N/{>9S5,OIk<0$%[)LGd}<Mh,R;qNhl+C]O!g9wsh6Q65Wiv,#M#&,MjgG1?&]jTbwsn*
 _yj,NR}PT7"irWSgi|(H5w)Q1C0.dO:qt?=S`eF/EcT!L_1D7eJ&b-J5d#AoLu&}b#'}nq(^pr2+u*
 7'RvZp0xv:q/K&%WDOQ(+H?AJw7[|DcUK{}5S!;I4^9vFe$A2%G_oz3K#2d{m#[MnE,-hxq9Po9v]R
 t]j*0md[y/3R~J
Content-Type: text


I patched to b26 and
Configured for `mips-sgi-irix5.2'.

  Where should the build process find the source code?    /local/ducdev/local/projects/emacs/beta/xemacs-19.14-b26
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/irix5-2.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              cc -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.

Built o.k. with make all-elc

No problems so far.

-- 
Paul Bibilo, Delcam International plc, |  Tel: +44 121 766 5544
Talbot Way, Small Heath, Birmingham,   |  Fax: +44 121 766 5511
England, B10 0HJ.                 _____|_____
#include <disclaimer.h>          | BLAT FOOP |



From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 08:12:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA02302 for xemacs-beta-people; Wed, 19 Jun 1996 08:12:06 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA02299 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 08:12:05 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA23280 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 08:12:02 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.51 #1)
	id E0uWN39-0003A4-00; Wed, 19 Jun 1996 09:11:59 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: hpux9.05 hppa1.1 b25 success
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uWN39-0003A4-00@neal.ctd.comsat.com>
Date: Wed, 19 Jun 1996 09:11:59 -0400

Applied frame.c patch.

./configure  --verbose --cflags=-g -O3
--site-includes=/usr/local/include/db --dynamic=yes --with-gnu-make

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 08:40:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA02394 for xemacs-beta-people; Wed, 19 Jun 1996 08:40:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA02391 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 08:40:09 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA26016 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 08:40:09 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA19797; Wed, 19 Jun 1996 15:38:52 +0200
Received: from loopback by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA22848; Wed, 19 Jun 1996 15:38:51 +0200
Message-Id: <9606191338.AA22848@modas.informatik.uni-tuebingen.de>
To: xemacs-beta@cs.uiuc.edu
Subject: b26 success on FreeBSD 2.1.0-RELEASE
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 19 Jun 1996 15:38:50 +0200
From: "Michael Sperber [Mr. Preprocessor]" <sperber@informatik.uni-tuebingen.de>


gcc 2.6.3, XFree86 3.1.2, xpm, the works ...

Smooth run so far.

Cheers =8-} Mike

PS:  I love the new buffers menu.

PPS: Ben's PSGML-HTML stuff is way cool.  Should have said that
     earlier, but here goes.  Thanks, Ben.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 09:24:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA02476 for xemacs-beta-people; Wed, 19 Jun 1996 09:24:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA02473 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 09:24:20 -0500 (CDT)
Received: from ns2.eds.com (ns2.eds.com [199.228.142.78]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA07016 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 09:24:16 -0500 (CDT)
Received: by ns2.eds.com (hello)
	id KAA14715; Wed, 19 Jun 1996 10:24:18 -0400
Received: by nnsp.eds.com (hello)
	id KAA24940; Wed, 19 Jun 1996 10:23:47 -0400 (EDT)
Received: from kocrsw12.delcoelect.com (kocrsw12.delcoelect.com [144.250.106.18]) by kocrsv04.delcoelect.com (8.7.5/8.7.3) with SMTP id JAA28579 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 09:23:46 -0500 (EST)
Received: from kocrsw12 by kocrsw12.delcoelect.com (SMI-8.6/SMI-SVR4)
	id JAA10880; Wed, 19 Jun 1996 09:23:45 -0500
X-Mailer: exmh version 1.6.6 3/24/96
To: xemacs-beta@xemacs.org
Subject: b26 builds okay on sparc-sun-solaris2.4
X-Face: 4tk3bJx]I+QTZ|=]*1+Z){9+;5u_hK*NBeZK6[+B+iB%bVuOJ%^uK~fIG}O-}%WLX*D^aW>
 Gv8E3Xtz0\N&fQl^:pj<K{xM`:d>pPt:9lF-YXB%O)?@rd?*/jE!s94`?]:jJ#C5RDP:;Mr.3lwo`0
 {vIT+<{%IRwe]vLd]7>\X|*z{TUX_t;?TPcOLBMIv8_V92!Vk(*DJVU~0M[`5D^PAWLniO1?YYWArM
 U*j9o+>?1MWi.lO?F-?aVt:qQ8OaG?R}B:I!7S_+KuzxZ.f9M@$z#n\bG2$Q2{od
Date: Wed, 19 Jun 1996 09:23:45 -0500
Message-ID: <10878.835194225@kocrsw12>
From: Mike Scheidler <c23mts@eng.delcoelect.com>

Had no problems building from a fresh distribution:

Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    
/users/c23mts/xemacs-19.14
  What installation prefix should install use?            /usr/std
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -O
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/std/include
  Additional libraries:                                   /usr/std/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

--
Mike Scheidler                     INTERNET:  c23mts@eng.delcoelect.com
Software Development Tools         UUCP:      deaes!c23mts
Delco Electronics Corporation      PHONE:     (317) 451-0319
Kokomo, IN 46904-9005              GMNET:     8-322-0319



From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 10:09:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA02570 for xemacs-beta-people; Wed, 19 Jun 1996 10:09:19 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA02567 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 10:09:18 -0500 (CDT)
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA27236 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 10:08:28 -0500 (CDT)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0uWOrX-00002CC>; Wed, 19 Jun 96 17:08 MET DST
Message-Id: <m0uWOrX-00002CC@susan.logware.de>
Date: Wed, 19 Jun 96 17:08 MET DST
From: Michael Diers <mdiers@logware.de>
To: XEmacs beta list <xemacs-beta@cs.uiuc.edu>
Subject: Re: b26 success on FreeBSD 2.1.0-RELEASE
In-Reply-To: <9606191338.AA22848@modas.informatik.uni-tuebingen.de>
References: <9606191338.AA22848@modas.informatik.uni-tuebingen.de>

Michael Sperber [Mr Preprocessor] <Michael> wrote:

> gcc 2.6.3, XFree86 3.1.2, xpm, the works ...

> Smooth run so far.

Ditto here. I configured w/ optimization and w/o error checking this
time.

-Michael


XEmacs 19.14-b26
  (applied patchkits b16-b26)

FreeBSD 2.1-STABLE (4.4BSD), XFree86 3.1.2 (X11R6), gcc 2.6.3

xpm 3.4f-patched, compface-19900129, jpeg-6, libpng-0.87, zlib-0.95
  (statically linked)

Configured for `i386-unknown-freebsd2.1'.

  Where should the build process find the source code?    /usr/contrib/pub/src/xemacs-19.14-b26
  What installation prefix should install use?		  /usr/contrib/pkg/xemacs-19.14-b26
  What operating system and machine description files should XEmacs use?
        `s/freebsd.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -O2 -fno-strength-reduce -m486 -pipe
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/contrib/include
  Additional libraries:                                   /usr/contrib/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 08:09:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA02295 for xemacs-beta-people; Wed, 19 Jun 1996 08:09:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA02291 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 08:09:41 -0500 (CDT)
Received: from gcm.com (gcm.com [146.121.48.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA22460 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 08:09:31 -0500 (CDT)
Received: (from uucp@localhost) by gcm.com (8.6.9/8.6.9) with UUCP id JAA26662 for xemacs-beta@cs.uiuc.edu; Wed, 19 Jun 1996 09:12:54 -0400
Received: from mis_bo9.it.gcm.com by gcm.com (4.1/GCM-2.0m)
	id AA09696; Wed, 19 Jun 96 09:08:17 EDT
Received: by mis_bo9.it.gcm.com (4.1/SMI-4.1)
	id AA26529; Wed, 19 Jun 96 09:08:16 EDT
Message-Id: <9606191308.AA26529@mis_bo9.it.gcm.com>
To: XEmacs Beta Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: 19.14b25 Failure on SunOS
X-Mailer: Mew version 1.06-dcw-a on Emacs 19.13 XEmacs Lucid
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
	boundary="--Next_Part(Wed_Jun_19_09:08:13_1996)--"
Date: Wed, 19 Jun 96 09:08:15 -0400
From: David C Worenklein <dcw@gcm.com>

----Next_Part(Wed_Jun_19_09:08:13_1996)--
Content-Type: Text/Plain; charset=us-ascii

More problems with surrogate minibuffers.

Move the cursor over the initial frame. Type C-x (wait for XEmacs to
transform) C-f ~/.emacs <RETURN>.  Then kill the buffer C-k
<RETURN>. Now try again C-x C-f, then move the cursor over the
minibuffer frame and type ~/.emacs <RETURN>.

>Signalling: (error "Cannot switch buffers in minibuffer window")
>  signal(error ("Cannot switch buffers in minibuffer window"))
>  cerror("Cannot switch buffers in minibuffer window")
>  apply(cerror "Cannot switch buffers in minibuffer window")
>  error("Cannot switch buffers in minibuffer window")
>  switch-to-buffer(#<buffer ".emacs">)
>  find-file("~/.emacs")
>  call-interactively(find-file)

.emacs and config.status attached.

PS While sending this, I got a (void-function :help-string) - Let me
see if I can figure out where that came from!


----Next_Part(Wed_Jun_19_09:08:13_1996)--
Content-Type: Text/Plain; charset=us-ascii
Content-Description: ".emacs"

(cond
 ((string-match "19.10 Lucid" emacs-version)  ; View-Master 2
  (message "View Master 2"))
 ((<= emacs-minor-version 13)
  (setq debug-on-error t)
  (setq debug-on-quit t)

  (load "~/emacs/dcw-base")
  (load "/vol/emacs/lib/xemacs/site-lisp/gcm/default")
  (setq debug-on-quit nil)
  (setq debug-on-error nil))
 (t ; beta 14
  (setq debug-on-error t)
  (setq debug-on-quit t)
  (setq bar-cursor nil)
  (setq default-minibuffer-frame (make-frame '(name "*minibuffer*" minibuffer only top 860 left 76 width 140 height 2 menubar-visible-p nil default-toolbar-visible-p nil)))
;  (setq initial-frame-plist 
;	'(minibuffer  nil width 145 height 55 name (format "Emacs %s" emacs-version)))
  (setq default-frame-plist
	'(modeline t minibuffer nil width 80 height 40))))



----Next_Part(Wed_Jun_19_09:08:13_1996)--
Content-Type: Text/Plain; charset=us-ascii
Content-Description: "config.status"

#!/bin/sh
# Generated automatically by configure.
# Run this file to recreate the current configuration.
# This directory was configured as follows,
# on host mis_bo9:
#
# ./configure  sparc-sun-sunos4.1.3 --compiler=acc --cflags=-g --dynamic --prefix=/vol/emacs/beta --with-sparcworks=yes --with-tooltalk=yes --with-sound=native --with-xpm --with-xface --site-includes=/vol/motif/usr/include /vol/openwin/include /vol/emacs/compface --site-libraries=/vol/motif/usr/lib /vol/openwin/lib /vol/emacs/compface --x-includes=/usr/local/X11R5/include --x-libraries=/usr/local/X11R5/lib --with-xpm

ac_cs_usage="Usage: config.status [--recheck] [--version] [--help]"
for ac_option
do
  case "$ac_option" in
  -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r)
    echo running ${CONFIG_SHELL-/bin/sh} ./configure  sparc-sun-sunos4.1.3 --compiler=acc --cflags=-g --dynamic --prefix=/vol/emacs/beta --with-sparcworks=yes --with-tooltalk=yes --with-sound=native --with-xpm --with-xface --site-includes=/vol/motif/usr/include /vol/openwin/include /vol/emacs/compface --site-libraries=/vol/motif/usr/lib /vol/openwin/lib /vol/emacs/compface --x-includes=/usr/local/X11R5/include --x-libraries=/usr/local/X11R5/lib --with-xpm --no-create
    exec ${CONFIG_SHELL-/bin/sh} ./configure  sparc-sun-sunos4.1.3 --compiler=acc --cflags=-g --dynamic --prefix=/vol/emacs/beta --with-sparcworks=yes --with-tooltalk=yes --with-sound=native --with-xpm --with-xface --site-includes=/vol/motif/usr/include /vol/openwin/include /vol/emacs/compface --site-libraries=/vol/motif/usr/lib /vol/openwin/lib /vol/emacs/compface --x-includes=/usr/local/X11R5/include --x-libraries=/usr/local/X11R5/lib --with-xpm --no-create ;;
  -version | --version | --versio | --versi | --vers | --ver | --ve | --v)
    echo "config.status generated by autoconf version 1.11"
    exit 0 ;;
  -help | --help | --hel | --he | --h)
    echo "$ac_cs_usage"; exit 0 ;;
  *) echo "$ac_cs_usage"; exit 1 ;;
  esac
done

trap 'rm -fr Makefile lib-src/Makefile.in man/Makefile.in src/Makefile.in lwlib/Makefile.in dynodump/Makefile.in src/config.h conftest*; exit 1' 1 2 15
LN_S='ln -s'
CC='acc'
CPP='/usr/lib/cpp -I/vol/motif/usr/include -I/vol/openwin/include -I/vol/emacs/compface -I/usr/local/X11R5/include'
RANLIB='ranlib'
INSTALL='/usr/bin/install -c'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_DATA='${INSTALL} -m 644'
YACC='bison -y'
SET_MAKE=''
ALLOCA=''
version='19.14-b25'
configuration='sparc-sun-sunos4.1.3'
canonical='sparc-sun-sunos4.1.3'
srcdir='/vol/emacs/xemacs-19.14-b25'
prefix='/vol/emacs/beta'
exec_prefix='${prefix}'
bindir='${exec_prefix}/bin'
datadir='${prefix}/lib'
statedir='${prefix}/lib'
libdir='${exec_prefix}/lib'
mandir='${prefix}/man/man1'
infodir='${prefix}/lib/xemacs-${version}/info'
infodir_user_defined='no'
lispdir='${datadir}/xemacs-${version}/lisp'
lispdir_user_defined='no'
sitelispdir='${datadir}/xemacs/site-lisp'
etcdir='${datadir}/xemacs-${version}/etc'
etcdir_user_defined='no'
lockdir='${statedir}/xemacs/lock'
lockdir_user_defined='no'
archlibdir='${libdir}/xemacs-${version}/${configuration}'
archlibdir_user_defined='no'
docdir=''
bitmapdir=''
c_switch_system=''
c_switch_machine=''
libsrc_libs=' '
LD_SWITCH_X_SITE='-L/usr/local/X11R5/lib -L/vol/openwin/lib '
LD_SWITCH_X_SITE_AUX=''
C_SWITCH_X_SITE='-I/usr/local/X11R5/include -I/vol/openwin/include/desktop -I/vol/openwin/include/desktop'
LD_SWITCH_SITE=' -L/vol/motif/usr/lib -L/vol/openwin/lib -L/vol/emacs/compface'
C_SWITCH_SITE=' -I/vol/motif/usr/include -I/vol/openwin/include -I/vol/emacs/compface'
CFLAGS='-g'
native_sound_lib='/usr/demo/SOUND/libaudio.a'
machfile='m/sparc.h'
opsysfile='s/sunos4-1-3shr.h'
dynodump_arch=''
internal_makefile_list='Makefile lib-src/Makefile.in man/Makefile.in src/Makefile.in lwlib/Makefile.in dynodump/Makefile.in'
LIBS='-lX11   -L/vol/motif/usr/lib -L/vol/openwin/lib -L/vol/emacs/compface     -u _XtToolkitInitialize -u _get_applicationShellWidgetClass -lm'
top_srcdir=''
ac_prsub='s%^prefix\([ 	]*\)=\([ 	]*\).*$%prefix\1=\2/vol/emacs/beta%
s%^exec_prefix\([ 	]*\)=\([ 	]*\).*$%exec_prefix\1=\2${prefix}%'
ac_vpsub=''
extrasub=''

ac_given_srcdir=$srcdir

CONFIG_FILES=${CONFIG_FILES-"$internal_makefile_list"}
for ac_file in .. ${CONFIG_FILES}; do if test "x$ac_file" != x..; then
  # Remove last slash and all that follows it.  Not all systems have dirname.
  ac_dir=`echo $ac_file|sed 's%/[^/][^/]*$%%'`
  if test "$ac_dir" != "$ac_file" && test "$ac_dir" != .; then
    # The file is in a subdirectory.
    test ! -d "$ac_dir" && mkdir "$ac_dir"
    ac_dir_suffix="/$ac_dir"
  else
    ac_dir_suffix=
  fi

  # A "../" for each directory in $ac_dir_suffix.
  ac_dots=`echo $ac_dir_suffix|sed 's%/[^/]*%../%g'`
  case "$ac_given_srcdir" in
  .)  srcdir=.
      if test -z "$ac_dir_suffix"; then top_srcdir=.
      else top_srcdir=`echo $ac_dots|sed 's%/$%%'`; fi ;;
  /*) srcdir="$ac_given_srcdir$ac_dir_suffix"; top_srcdir="$ac_given_srcdir" ;;
  *) # Relative path.
    srcdir="$ac_dots$ac_given_srcdir$ac_dir_suffix"
    top_srcdir="$ac_dots$ac_given_srcdir" ;;
  esac

  echo creating "$ac_file"
  rm -f "$ac_file"
  comment_str="Generated automatically from `echo $ac_file|sed 's|.*/||'`.in by configure."
  case "$ac_file" in
    *.c | *.h | *.C | *.cc | *.m )  echo "/* $comment_str */" > "$ac_file" ;;
    * )          echo "# $comment_str"     > "$ac_file" ;;
  esac
  sed -e "
$ac_prsub
$ac_vpsub
$extrasub
s%@LN_S@%$LN_S%g
s%@CC@%$CC%g
s%@CPP@%$CPP%g
s%@RANLIB@%$RANLIB%g
s%@INSTALL@%$INSTALL%g
s%@INSTALL_PROGRAM@%$INSTALL_PROGRAM%g
s%@INSTALL_DATA@%$INSTALL_DATA%g
s%@YACC@%$YACC%g
s%@SET_MAKE@%$SET_MAKE%g
s%@ALLOCA@%$ALLOCA%g
s%@version@%$version%g
s%@configuration@%$configuration%g
s%@canonical@%$canonical%g
s%@srcdir@%$srcdir%g
s%@prefix@%$prefix%g
s%@exec_prefix@%$exec_prefix%g
s%@bindir@%$bindir%g
s%@datadir@%$datadir%g
s%@statedir@%$statedir%g
s%@libdir@%$libdir%g
s%@mandir@%$mandir%g
s%@infodir@%$infodir%g
s%@infodir_user_defined@%$infodir_user_defined%g
s%@lispdir@%$lispdir%g
s%@lispdir_user_defined@%$lispdir_user_defined%g
s%@sitelispdir@%$sitelispdir%g
s%@etcdir@%$etcdir%g
s%@etcdir_user_defined@%$etcdir_user_defined%g
s%@lockdir@%$lockdir%g
s%@lockdir_user_defined@%$lockdir_user_defined%g
s%@archlibdir@%$archlibdir%g
s%@archlibdir_user_defined@%$archlibdir_user_defined%g
s%@docdir@%$docdir%g
s%@bitmapdir@%$bitmapdir%g
s%@c_switch_system@%$c_switch_system%g
s%@c_switch_machine@%$c_switch_machine%g
s%@libsrc_libs@%$libsrc_libs%g
s%@LD_SWITCH_X_SITE@%$LD_SWITCH_X_SITE%g
s%@LD_SWITCH_X_SITE_AUX@%$LD_SWITCH_X_SITE_AUX%g
s%@C_SWITCH_X_SITE@%$C_SWITCH_X_SITE%g
s%@LD_SWITCH_SITE@%$LD_SWITCH_SITE%g
s%@C_SWITCH_SITE@%$C_SWITCH_SITE%g
s%@CFLAGS@%$CFLAGS%g
s%@native_sound_lib@%$native_sound_lib%g
s%@machfile@%$machfile%g
s%@opsysfile@%$opsysfile%g
s%@dynodump_arch@%$dynodump_arch%g
s%@internal_makefile_list@%$internal_makefile_list%g
s%@LIBS@%$LIBS%g
s%@top_srcdir@%$top_srcdir%g
s%@DEFS@%-DHAVE_CONFIG_H%" $ac_given_srcdir/${ac_file}.in >> $ac_file
fi; done

# These sed commands are put into ac_sed_defs when defining a macro.
# They are broken into pieces to make the sed script easier to manage.
# They are passed to sed as "A NAME B NAME C VALUE D", where NAME
# is the cpp macro being defined and VALUE is the value it is being given.
# Each defining turns into a single global substitution command.
# Hopefully no one uses "!" as a variable value.
# Other candidates for the sed separators, like , and @, do get used.
#
# ac_d sets the value in "#define NAME VALUE" lines.
ac_dA='s!^\([ 	]*\)#\([ 	]*define[ 	][ 	]*\)'
ac_dB='\([ 	][ 	]*\)[^ 	]*!\1#\2'
ac_dC='\3'
ac_dD='!g'
# ac_u turns "#undef NAME" with trailing blanks into "#define NAME VALUE".
ac_uA='s!^\([ 	]*\)#\([ 	]*\)undef\([ 	][ 	]*\)'
ac_uB='\([ 	]\)!\1#\2define\3'
ac_uC=' '
ac_uD='\4!g'
# ac_e turns "#undef NAME" without trailing blanks into "#define NAME VALUE".
ac_eA='s!^\([ 	]*\)#\([ 	]*\)undef\([ 	][ 	]*\)'
ac_eB='$!\1#\2define\3'
ac_eC=' '
ac_eD='!g'
rm -f conftest.sed
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_SYS_STROPTS_H${ac_dB}HAVE_SYS_STROPTS_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_SYS_STROPTS_H${ac_uB}HAVE_SYS_STROPTS_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_SYS_STROPTS_H${ac_eB}HAVE_SYS_STROPTS_H${ac_eC}1${ac_eD}
${ac_dA}HAVE_SYS_TIMEB_H${ac_dB}HAVE_SYS_TIMEB_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_SYS_TIMEB_H${ac_uB}HAVE_SYS_TIMEB_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_SYS_TIMEB_H${ac_eB}HAVE_SYS_TIMEB_H${ac_eC}1${ac_eD}
${ac_dA}HAVE_SYS_TIME_H${ac_dB}HAVE_SYS_TIME_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_SYS_TIME_H${ac_uB}HAVE_SYS_TIME_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_SYS_TIME_H${ac_eB}HAVE_SYS_TIME_H${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_UNISTD_H${ac_dB}HAVE_UNISTD_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_UNISTD_H${ac_uB}HAVE_UNISTD_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_UNISTD_H${ac_eB}HAVE_UNISTD_H${ac_eC}1${ac_eD}
${ac_dA}HAVE_UTIME_H${ac_dB}HAVE_UTIME_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_UTIME_H${ac_uB}HAVE_UTIME_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_UTIME_H${ac_eB}HAVE_UTIME_H${ac_eC}1${ac_eD}
${ac_dA}HAVE_SYS_WAIT_H${ac_dB}HAVE_SYS_WAIT_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_SYS_WAIT_H${ac_uB}HAVE_SYS_WAIT_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_SYS_WAIT_H${ac_eB}HAVE_SYS_WAIT_H${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_LOCALE_H${ac_dB}HAVE_LOCALE_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_LOCALE_H${ac_uB}HAVE_LOCALE_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_LOCALE_H${ac_eB}HAVE_LOCALE_H${ac_eC}1${ac_eD}
${ac_dA}TIME_WITH_SYS_TIME${ac_dB}TIME_WITH_SYS_TIME${ac_dC}1${ac_dD}
${ac_uA}TIME_WITH_SYS_TIME${ac_uB}TIME_WITH_SYS_TIME${ac_uC}1${ac_uD}
${ac_eA}TIME_WITH_SYS_TIME${ac_eB}TIME_WITH_SYS_TIME${ac_eC}1${ac_eD}
${ac_dA}HAVE_STRUCT_UTIMBUF${ac_dB}HAVE_STRUCT_UTIMBUF${ac_dC}1${ac_dD}
${ac_uA}HAVE_STRUCT_UTIMBUF${ac_uB}HAVE_STRUCT_UTIMBUF${ac_uC}1${ac_uD}
${ac_eA}HAVE_STRUCT_UTIMBUF${ac_eB}HAVE_STRUCT_UTIMBUF${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}RETSIGTYPE${ac_dB}RETSIGTYPE${ac_dC}void${ac_dD}
${ac_uA}RETSIGTYPE${ac_uB}RETSIGTYPE${ac_uC}void${ac_uD}
${ac_eA}RETSIGTYPE${ac_eB}RETSIGTYPE${ac_eC}void${ac_eD}
${ac_dA}HAVE_TIMEVAL${ac_dB}HAVE_TIMEVAL${ac_dC}1${ac_dD}
${ac_uA}HAVE_TIMEVAL${ac_uB}HAVE_TIMEVAL${ac_uC}1${ac_uD}
${ac_eA}HAVE_TIMEVAL${ac_eB}HAVE_TIMEVAL${ac_eC}1${ac_eD}
${ac_dA}HAVE_TM_ZONE${ac_dB}HAVE_TM_ZONE${ac_dC}1${ac_dD}
${ac_uA}HAVE_TM_ZONE${ac_uB}HAVE_TM_ZONE${ac_uC}1${ac_uD}
${ac_eA}HAVE_TM_ZONE${ac_eB}HAVE_TM_ZONE${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}WORDS_BIGENDIAN${ac_dB}WORDS_BIGENDIAN${ac_dC}1${ac_dD}
${ac_uA}WORDS_BIGENDIAN${ac_uB}WORDS_BIGENDIAN${ac_uC}1${ac_uD}
${ac_eA}WORDS_BIGENDIAN${ac_eB}WORDS_BIGENDIAN${ac_eC}1${ac_eD}
${ac_dA}HAVE_LONG_FILE_NAMES${ac_dB}HAVE_LONG_FILE_NAMES${ac_dC}1${ac_dD}
${ac_uA}HAVE_LONG_FILE_NAMES${ac_uB}HAVE_LONG_FILE_NAMES${ac_uC}1${ac_uD}
${ac_eA}HAVE_LONG_FILE_NAMES${ac_eB}HAVE_LONG_FILE_NAMES${ac_eC}1${ac_eD}
${ac_dA}HAVE_XAUTH${ac_dB}HAVE_XAUTH${ac_dC}1${ac_dD}
${ac_uA}HAVE_XAUTH${ac_uB}HAVE_XAUTH${ac_uC}1${ac_uD}
${ac_eA}HAVE_XAUTH${ac_eB}HAVE_XAUTH${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_XLOCALE_H${ac_dB}HAVE_XLOCALE_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_XLOCALE_H${ac_uB}HAVE_XLOCALE_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_XLOCALE_H${ac_eB}HAVE_XLOCALE_H${ac_eC}1${ac_eD}
${ac_dA}THIS_IS_X11R5${ac_dB}THIS_IS_X11R5${ac_dC}1${ac_dD}
${ac_uA}THIS_IS_X11R5${ac_uB}THIS_IS_X11R5${ac_uC}1${ac_uD}
${ac_eA}THIS_IS_X11R5${ac_eB}THIS_IS_X11R5${ac_eC}1${ac_eD}
${ac_dA}HAVE_X11_XLOCALE_H${ac_dB}HAVE_X11_XLOCALE_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_X11_XLOCALE_H${ac_uB}HAVE_X11_XLOCALE_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_X11_XLOCALE_H${ac_eB}HAVE_X11_XLOCALE_H${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_LIBM${ac_dB}HAVE_LIBM${ac_dC}1${ac_dD}
${ac_uA}HAVE_LIBM${ac_uB}HAVE_LIBM${ac_uC}1${ac_uD}
${ac_eA}HAVE_LIBM${ac_eB}HAVE_LIBM${ac_eC}1${ac_eD}
${ac_dA}HAVE_XPM${ac_dB}HAVE_XPM${ac_dC}1${ac_dD}
${ac_uA}HAVE_XPM${ac_uB}HAVE_XPM${ac_uC}1${ac_uD}
${ac_eA}HAVE_XPM${ac_eB}HAVE_XPM${ac_eC}1${ac_eD}
${ac_dA}HAVE_XMU${ac_dB}HAVE_XMU${ac_dC}1${ac_dD}
${ac_uA}HAVE_XMU${ac_uB}HAVE_XMU${ac_uC}1${ac_uD}
${ac_eA}HAVE_XMU${ac_eB}HAVE_XMU${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_XFACE${ac_dB}HAVE_XFACE${ac_dC}1${ac_dD}
${ac_uA}HAVE_XFACE${ac_uB}HAVE_XFACE${ac_uC}1${ac_uD}
${ac_eA}HAVE_XFACE${ac_eB}HAVE_XFACE${ac_eC}1${ac_eD}
${ac_dA}HAVE_GIF${ac_dB}HAVE_GIF${ac_dC}1${ac_dD}
${ac_uA}HAVE_GIF${ac_uB}HAVE_GIF${ac_uC}1${ac_uD}
${ac_eA}HAVE_GIF${ac_eB}HAVE_GIF${ac_eC}1${ac_eD}
${ac_dA}HAVE_H_ERRNO${ac_dB}HAVE_H_ERRNO${ac_dC}1${ac_dD}
${ac_uA}HAVE_H_ERRNO${ac_uB}HAVE_H_ERRNO${ac_uC}1${ac_uD}
${ac_eA}HAVE_H_ERRNO${ac_eB}HAVE_H_ERRNO${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_SIGSETJMP${ac_dB}HAVE_SIGSETJMP${ac_dC}1${ac_dD}
${ac_uA}HAVE_SIGSETJMP${ac_uB}HAVE_SIGSETJMP${ac_uC}1${ac_uD}
${ac_eA}HAVE_SIGSETJMP${ac_eB}HAVE_SIGSETJMP${ac_eC}1${ac_eD}
${ac_dA}LOCALTIME_CACHE${ac_dB}LOCALTIME_CACHE${ac_dC}1${ac_dD}
${ac_uA}LOCALTIME_CACHE${ac_uB}LOCALTIME_CACHE${ac_uC}1${ac_uD}
${ac_eA}LOCALTIME_CACHE${ac_eB}LOCALTIME_CACHE${ac_eC}1${ac_eD}
${ac_dA}HAVE_ALLOCA_H${ac_dB}HAVE_ALLOCA_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_ALLOCA_H${ac_uB}HAVE_ALLOCA_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_ALLOCA_H${ac_eB}HAVE_ALLOCA_H${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_ALLOCA${ac_dB}HAVE_ALLOCA${ac_dC}1${ac_dD}
${ac_uA}HAVE_ALLOCA${ac_uB}HAVE_ALLOCA${ac_uC}1${ac_uD}
${ac_eA}HAVE_ALLOCA${ac_eB}HAVE_ALLOCA${ac_eC}1${ac_eD}
${ac_dA}HAVE_VFORK_H${ac_dB}HAVE_VFORK_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_VFORK_H${ac_uB}HAVE_VFORK_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_VFORK_H${ac_eB}HAVE_VFORK_H${ac_eC}1${ac_eD}
${ac_dA}HAVE_STRCOLL${ac_dB}HAVE_STRCOLL${ac_dC}1${ac_dD}
${ac_uA}HAVE_STRCOLL${ac_uB}HAVE_STRCOLL${ac_uC}1${ac_uD}
${ac_eA}HAVE_STRCOLL${ac_eB}HAVE_STRCOLL${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}SIZEOF_SHORT${ac_dB}SIZEOF_SHORT${ac_dC}2${ac_dD}
${ac_uA}SIZEOF_SHORT${ac_uB}SIZEOF_SHORT${ac_uC}2${ac_uD}
${ac_eA}SIZEOF_SHORT${ac_eB}SIZEOF_SHORT${ac_eC}2${ac_eD}
${ac_dA}SIZEOF_INT${ac_dB}SIZEOF_INT${ac_dC}4${ac_dD}
${ac_uA}SIZEOF_INT${ac_uB}SIZEOF_INT${ac_uC}4${ac_uD}
${ac_eA}SIZEOF_INT${ac_eB}SIZEOF_INT${ac_eC}4${ac_eD}
${ac_dA}SIZEOF_LONG${ac_dB}SIZEOF_LONG${ac_dC}4${ac_dD}
${ac_uA}SIZEOF_LONG${ac_uB}SIZEOF_LONG${ac_uC}4${ac_uD}
${ac_eA}SIZEOF_LONG${ac_eB}SIZEOF_LONG${ac_eC}4${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_ACOSH${ac_dB}HAVE_ACOSH${ac_dC}1${ac_dD}
${ac_uA}HAVE_ACOSH${ac_uB}HAVE_ACOSH${ac_uC}1${ac_uD}
${ac_eA}HAVE_ACOSH${ac_eB}HAVE_ACOSH${ac_eC}1${ac_eD}
${ac_dA}HAVE_ASINH${ac_dB}HAVE_ASINH${ac_dC}1${ac_dD}
${ac_uA}HAVE_ASINH${ac_uB}HAVE_ASINH${ac_uC}1${ac_uD}
${ac_eA}HAVE_ASINH${ac_eB}HAVE_ASINH${ac_eC}1${ac_eD}
${ac_dA}HAVE_ATANH${ac_dB}HAVE_ATANH${ac_dC}1${ac_dD}
${ac_uA}HAVE_ATANH${ac_uB}HAVE_ATANH${ac_uC}1${ac_uD}
${ac_eA}HAVE_ATANH${ac_eB}HAVE_ATANH${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_CBRT${ac_dB}HAVE_CBRT${ac_dC}1${ac_dD}
${ac_uA}HAVE_CBRT${ac_uB}HAVE_CBRT${ac_uC}1${ac_uD}
${ac_eA}HAVE_CBRT${ac_eB}HAVE_CBRT${ac_eC}1${ac_eD}
${ac_dA}HAVE_CLOSEDIR${ac_dB}HAVE_CLOSEDIR${ac_dC}1${ac_dD}
${ac_uA}HAVE_CLOSEDIR${ac_uB}HAVE_CLOSEDIR${ac_uC}1${ac_uD}
${ac_eA}HAVE_CLOSEDIR${ac_eB}HAVE_CLOSEDIR${ac_eC}1${ac_eD}
${ac_dA}HAVE_DUP2${ac_dB}HAVE_DUP2${ac_dC}1${ac_dD}
${ac_uA}HAVE_DUP2${ac_uB}HAVE_DUP2${ac_uC}1${ac_uD}
${ac_eA}HAVE_DUP2${ac_eB}HAVE_DUP2${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_FMOD${ac_dB}HAVE_FMOD${ac_dC}1${ac_dD}
${ac_uA}HAVE_FMOD${ac_uB}HAVE_FMOD${ac_uC}1${ac_uD}
${ac_eA}HAVE_FMOD${ac_eB}HAVE_FMOD${ac_eC}1${ac_eD}
${ac_dA}HAVE_FPATHCONF${ac_dB}HAVE_FPATHCONF${ac_dC}1${ac_dD}
${ac_uA}HAVE_FPATHCONF${ac_uB}HAVE_FPATHCONF${ac_uC}1${ac_uD}
${ac_eA}HAVE_FPATHCONF${ac_eB}HAVE_FPATHCONF${ac_eC}1${ac_eD}
${ac_dA}HAVE_FREXP${ac_dB}HAVE_FREXP${ac_dC}1${ac_dD}
${ac_uA}HAVE_FREXP${ac_uB}HAVE_FREXP${ac_uC}1${ac_uD}
${ac_eA}HAVE_FREXP${ac_eB}HAVE_FREXP${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_FTIME${ac_dB}HAVE_FTIME${ac_dC}1${ac_dD}
${ac_uA}HAVE_FTIME${ac_uB}HAVE_FTIME${ac_uC}1${ac_uD}
${ac_eA}HAVE_FTIME${ac_eB}HAVE_FTIME${ac_eC}1${ac_eD}
${ac_dA}HAVE_GETHOSTNAME${ac_dB}HAVE_GETHOSTNAME${ac_dC}1${ac_dD}
${ac_uA}HAVE_GETHOSTNAME${ac_uB}HAVE_GETHOSTNAME${ac_uC}1${ac_uD}
${ac_eA}HAVE_GETHOSTNAME${ac_eB}HAVE_GETHOSTNAME${ac_eC}1${ac_eD}
${ac_dA}HAVE_GETPAGESIZE${ac_dB}HAVE_GETPAGESIZE${ac_dC}1${ac_dD}
${ac_uA}HAVE_GETPAGESIZE${ac_uB}HAVE_GETPAGESIZE${ac_uC}1${ac_uD}
${ac_eA}HAVE_GETPAGESIZE${ac_eB}HAVE_GETPAGESIZE${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_GETTIMEOFDAY${ac_dB}HAVE_GETTIMEOFDAY${ac_dC}1${ac_dD}
${ac_uA}HAVE_GETTIMEOFDAY${ac_uB}HAVE_GETTIMEOFDAY${ac_uC}1${ac_uD}
${ac_eA}HAVE_GETTIMEOFDAY${ac_eB}HAVE_GETTIMEOFDAY${ac_eC}1${ac_eD}
${ac_dA}HAVE_GETWD${ac_dB}HAVE_GETWD${ac_dC}1${ac_dD}
${ac_uA}HAVE_GETWD${ac_uB}HAVE_GETWD${ac_uC}1${ac_uD}
${ac_eA}HAVE_GETWD${ac_eB}HAVE_GETWD${ac_eC}1${ac_eD}
${ac_dA}HAVE_LOGB${ac_dB}HAVE_LOGB${ac_dC}1${ac_dD}
${ac_uA}HAVE_LOGB${ac_uB}HAVE_LOGB${ac_uC}1${ac_uD}
${ac_eA}HAVE_LOGB${ac_eB}HAVE_LOGB${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_LRAND48${ac_dB}HAVE_LRAND48${ac_dC}1${ac_dD}
${ac_uA}HAVE_LRAND48${ac_uB}HAVE_LRAND48${ac_uC}1${ac_uD}
${ac_eA}HAVE_LRAND48${ac_eB}HAVE_LRAND48${ac_eC}1${ac_eD}
${ac_dA}HAVE_MATHERR${ac_dB}HAVE_MATHERR${ac_dC}1${ac_dD}
${ac_uA}HAVE_MATHERR${ac_uB}HAVE_MATHERR${ac_uC}1${ac_uD}
${ac_eA}HAVE_MATHERR${ac_eB}HAVE_MATHERR${ac_eC}1${ac_eD}
${ac_dA}HAVE_MKDIR${ac_dB}HAVE_MKDIR${ac_dC}1${ac_dD}
${ac_uA}HAVE_MKDIR${ac_uB}HAVE_MKDIR${ac_uC}1${ac_uD}
${ac_eA}HAVE_MKDIR${ac_eB}HAVE_MKDIR${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_MKTIME${ac_dB}HAVE_MKTIME${ac_dC}1${ac_dD}
${ac_uA}HAVE_MKTIME${ac_uB}HAVE_MKTIME${ac_uC}1${ac_uD}
${ac_eA}HAVE_MKTIME${ac_eB}HAVE_MKTIME${ac_eC}1${ac_eD}
${ac_dA}HAVE_PERROR${ac_dB}HAVE_PERROR${ac_dC}1${ac_dD}
${ac_uA}HAVE_PERROR${ac_uB}HAVE_PERROR${ac_uC}1${ac_uD}
${ac_eA}HAVE_PERROR${ac_eB}HAVE_PERROR${ac_eC}1${ac_eD}
${ac_dA}HAVE_POLL${ac_dB}HAVE_POLL${ac_dC}1${ac_dD}
${ac_uA}HAVE_POLL${ac_uB}HAVE_POLL${ac_uC}1${ac_uD}
${ac_eA}HAVE_POLL${ac_eB}HAVE_POLL${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_RANDOM${ac_dB}HAVE_RANDOM${ac_dC}1${ac_dD}
${ac_uA}HAVE_RANDOM${ac_uB}HAVE_RANDOM${ac_uC}1${ac_uD}
${ac_eA}HAVE_RANDOM${ac_eB}HAVE_RANDOM${ac_eC}1${ac_eD}
${ac_dA}HAVE_REALPATH${ac_dB}HAVE_REALPATH${ac_dC}1${ac_dD}
${ac_uA}HAVE_REALPATH${ac_uB}HAVE_REALPATH${ac_uC}1${ac_uD}
${ac_eA}HAVE_REALPATH${ac_eB}HAVE_REALPATH${ac_eC}1${ac_eD}
${ac_dA}HAVE_RENAME${ac_dB}HAVE_RENAME${ac_dC}1${ac_dD}
${ac_uA}HAVE_RENAME${ac_uB}HAVE_RENAME${ac_uC}1${ac_uD}
${ac_eA}HAVE_RENAME${ac_eB}HAVE_RENAME${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_RINT${ac_dB}HAVE_RINT${ac_dC}1${ac_dD}
${ac_uA}HAVE_RINT${ac_uB}HAVE_RINT${ac_uC}1${ac_uD}
${ac_eA}HAVE_RINT${ac_eB}HAVE_RINT${ac_eC}1${ac_eD}
${ac_dA}HAVE_RMDIR${ac_dB}HAVE_RMDIR${ac_dC}1${ac_dD}
${ac_uA}HAVE_RMDIR${ac_uB}HAVE_RMDIR${ac_uC}1${ac_uD}
${ac_eA}HAVE_RMDIR${ac_eB}HAVE_RMDIR${ac_eC}1${ac_eD}
${ac_dA}HAVE_SELECT${ac_dB}HAVE_SELECT${ac_dC}1${ac_dD}
${ac_uA}HAVE_SELECT${ac_uB}HAVE_SELECT${ac_uC}1${ac_uD}
${ac_eA}HAVE_SELECT${ac_eB}HAVE_SELECT${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_SETITIMER${ac_dB}HAVE_SETITIMER${ac_dC}1${ac_dD}
${ac_uA}HAVE_SETITIMER${ac_uB}HAVE_SETITIMER${ac_uC}1${ac_uD}
${ac_eA}HAVE_SETITIMER${ac_eB}HAVE_SETITIMER${ac_eC}1${ac_eD}
${ac_dA}HAVE_SETPGID${ac_dB}HAVE_SETPGID${ac_dC}1${ac_dD}
${ac_uA}HAVE_SETPGID${ac_uB}HAVE_SETPGID${ac_uC}1${ac_uD}
${ac_eA}HAVE_SETPGID${ac_eB}HAVE_SETPGID${ac_eC}1${ac_eD}
${ac_dA}HAVE_SETLOCALE${ac_dB}HAVE_SETLOCALE${ac_dC}1${ac_dD}
${ac_uA}HAVE_SETLOCALE${ac_uB}HAVE_SETLOCALE${ac_uC}1${ac_uD}
${ac_eA}HAVE_SETLOCALE${ac_eB}HAVE_SETLOCALE${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_SETSID${ac_dB}HAVE_SETSID${ac_dC}1${ac_dD}
${ac_uA}HAVE_SETSID${ac_uB}HAVE_SETSID${ac_uC}1${ac_uD}
${ac_eA}HAVE_SETSID${ac_eB}HAVE_SETSID${ac_eC}1${ac_eD}
${ac_dA}HAVE_SIGBLOCK${ac_dB}HAVE_SIGBLOCK${ac_dC}1${ac_dD}
${ac_uA}HAVE_SIGBLOCK${ac_uB}HAVE_SIGBLOCK${ac_uC}1${ac_uD}
${ac_eA}HAVE_SIGBLOCK${ac_eB}HAVE_SIGBLOCK${ac_eC}1${ac_eD}
${ac_dA}HAVE_SIGPROCMASK${ac_dB}HAVE_SIGPROCMASK${ac_dC}1${ac_dD}
${ac_uA}HAVE_SIGPROCMASK${ac_uB}HAVE_SIGPROCMASK${ac_uC}1${ac_uD}
${ac_eA}HAVE_SIGPROCMASK${ac_eB}HAVE_SIGPROCMASK${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_STRERROR${ac_dB}HAVE_STRERROR${ac_dC}1${ac_dD}
${ac_uA}HAVE_STRERROR${ac_uB}HAVE_STRERROR${ac_uC}1${ac_uD}
${ac_eA}HAVE_STRERROR${ac_eB}HAVE_STRERROR${ac_eC}1${ac_eD}
${ac_dA}HAVE_TZSET${ac_dB}HAVE_TZSET${ac_dC}1${ac_dD}
${ac_uA}HAVE_TZSET${ac_uB}HAVE_TZSET${ac_uC}1${ac_uD}
${ac_eA}HAVE_TZSET${ac_eB}HAVE_TZSET${ac_eC}1${ac_eD}
${ac_dA}HAVE_UTIMES${ac_dB}HAVE_UTIMES${ac_dC}1${ac_dD}
${ac_uA}HAVE_UTIMES${ac_uB}HAVE_UTIMES${ac_uC}1${ac_uD}
${ac_eA}HAVE_UTIMES${ac_eB}HAVE_UTIMES${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_WAITPID${ac_dB}HAVE_WAITPID${ac_dC}1${ac_dD}
${ac_uA}HAVE_WAITPID${ac_uB}HAVE_WAITPID${ac_uC}1${ac_uD}
${ac_eA}HAVE_WAITPID${ac_eB}HAVE_WAITPID${ac_eC}1${ac_eD}
${ac_dA}HAVE_MMAP${ac_dB}HAVE_MMAP${ac_dC}1${ac_dD}
${ac_uA}HAVE_MMAP${ac_uB}HAVE_MMAP${ac_uC}1${ac_uD}
${ac_eA}HAVE_MMAP${ac_eB}HAVE_MMAP${ac_eC}1${ac_eD}
${ac_dA}HAVE_SOCKETS${ac_dB}HAVE_SOCKETS${ac_dC}1${ac_dD}
${ac_uA}HAVE_SOCKETS${ac_uB}HAVE_SOCKETS${ac_uC}1${ac_uD}
${ac_eA}HAVE_SOCKETS${ac_eB}HAVE_SOCKETS${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}SYSV_SYSTEM_DIR${ac_dB}SYSV_SYSTEM_DIR${ac_dC}1${ac_dD}
${ac_uA}SYSV_SYSTEM_DIR${ac_uB}SYSV_SYSTEM_DIR${ac_uC}1${ac_uD}
${ac_eA}SYSV_SYSTEM_DIR${ac_eB}SYSV_SYSTEM_DIR${ac_eC}1${ac_eD}
${ac_dA}HAVE_TERMIOS${ac_dB}HAVE_TERMIOS${ac_dC}1${ac_dD}
${ac_uA}HAVE_TERMIOS${ac_uB}HAVE_TERMIOS${ac_uC}1${ac_uD}
${ac_eA}HAVE_TERMIOS${ac_eB}HAVE_TERMIOS${ac_eC}1${ac_eD}
${ac_dA}NLIST_STRUCT${ac_dB}NLIST_STRUCT${ac_dC}1${ac_dD}
${ac_uA}NLIST_STRUCT${ac_uB}NLIST_STRUCT${ac_uC}1${ac_uD}
${ac_eA}NLIST_STRUCT${ac_eB}NLIST_STRUCT${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_LIBDBM${ac_dB}HAVE_LIBDBM${ac_dC}1${ac_dD}
${ac_uA}HAVE_LIBDBM${ac_uB}HAVE_LIBDBM${ac_uC}1${ac_uD}
${ac_eA}HAVE_LIBDBM${ac_eB}HAVE_LIBDBM${ac_eC}1${ac_eD}
${ac_dA}HAVE_DBM${ac_dB}HAVE_DBM${ac_dC}1${ac_dD}
${ac_uA}HAVE_DBM${ac_uB}HAVE_DBM${ac_uC}1${ac_uD}
${ac_eA}HAVE_DBM${ac_eB}HAVE_DBM${ac_eC}1${ac_eD}
${ac_dA}EMACS_CONFIGURATION${ac_dB}EMACS_CONFIGURATION${ac_dC}"sparc-sun-sunos4.1.3"${ac_dD}
${ac_uA}EMACS_CONFIGURATION${ac_uB}EMACS_CONFIGURATION${ac_uC}"sparc-sun-sunos4.1.3"${ac_uD}
${ac_eA}EMACS_CONFIGURATION${ac_eB}EMACS_CONFIGURATION${ac_eC}"sparc-sun-sunos4.1.3"${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}config_machfile${ac_dB}config_machfile${ac_dC}"m/sparc.h"${ac_dD}
${ac_uA}config_machfile${ac_uB}config_machfile${ac_uC}"m/sparc.h"${ac_uD}
${ac_eA}config_machfile${ac_eB}config_machfile${ac_eC}"m/sparc.h"${ac_eD}
${ac_dA}config_opsysfile${ac_dB}config_opsysfile${ac_dC}"s/sunos4-1-3shr.h"${ac_dD}
${ac_uA}config_opsysfile${ac_uB}config_opsysfile${ac_uC}"s/sunos4-1-3shr.h"${ac_uD}
${ac_eA}config_opsysfile${ac_eB}config_opsysfile${ac_eC}"s/sunos4-1-3shr.h"${ac_eD}
${ac_dA}LD_SWITCH_X_SITE${ac_dB}LD_SWITCH_X_SITE${ac_dC}-L/usr/local/X11R5/lib -L/vol/openwin/lib ${ac_dD}
${ac_uA}LD_SWITCH_X_SITE${ac_uB}LD_SWITCH_X_SITE${ac_uC}-L/usr/local/X11R5/lib -L/vol/openwin/lib ${ac_uD}
${ac_eA}LD_SWITCH_X_SITE${ac_eB}LD_SWITCH_X_SITE${ac_eC}-L/usr/local/X11R5/lib -L/vol/openwin/lib ${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}LD_SWITCH_X_SITE_AUX${ac_dB}LD_SWITCH_X_SITE_AUX${ac_dC}${ac_dD}
${ac_uA}LD_SWITCH_X_SITE_AUX${ac_uB}LD_SWITCH_X_SITE_AUX${ac_uC}${ac_uD}
${ac_eA}LD_SWITCH_X_SITE_AUX${ac_eB}LD_SWITCH_X_SITE_AUX${ac_eC}${ac_eD}
${ac_dA}C_SWITCH_X_SITE${ac_dB}C_SWITCH_X_SITE${ac_dC}-I/usr/local/X11R5/include -I/vol/openwin/include/desktop -I/vol/openwin/include/desktop${ac_dD}
${ac_uA}C_SWITCH_X_SITE${ac_uB}C_SWITCH_X_SITE${ac_uC}-I/usr/local/X11R5/include -I/vol/openwin/include/desktop -I/vol/openwin/include/desktop${ac_uD}
${ac_eA}C_SWITCH_X_SITE${ac_eB}C_SWITCH_X_SITE${ac_eC}-I/usr/local/X11R5/include -I/vol/openwin/include/desktop -I/vol/openwin/include/desktop${ac_eD}
${ac_dA}LD_SWITCH_SITE${ac_dB}LD_SWITCH_SITE${ac_dC} -L/vol/motif/usr/lib -L/vol/openwin/lib -L/vol/emacs/compface${ac_dD}
${ac_uA}LD_SWITCH_SITE${ac_uB}LD_SWITCH_SITE${ac_uC} -L/vol/motif/usr/lib -L/vol/openwin/lib -L/vol/emacs/compface${ac_uD}
${ac_eA}LD_SWITCH_SITE${ac_eB}LD_SWITCH_SITE${ac_eC} -L/vol/motif/usr/lib -L/vol/openwin/lib -L/vol/emacs/compface${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}C_SWITCH_SITE${ac_dB}C_SWITCH_SITE${ac_dC} -I/vol/motif/usr/include -I/vol/openwin/include -I/vol/emacs/compface${ac_dD}
${ac_uA}C_SWITCH_SITE${ac_uB}C_SWITCH_SITE${ac_uC} -I/vol/motif/usr/include -I/vol/openwin/include -I/vol/emacs/compface${ac_uD}
${ac_eA}C_SWITCH_SITE${ac_eB}C_SWITCH_SITE${ac_eC} -I/vol/motif/usr/include -I/vol/openwin/include -I/vol/emacs/compface${ac_eD}
${ac_dA}UNEXEC_SRC${ac_dB}UNEXEC_SRC${ac_dC}unexsunos4.c${ac_dD}
${ac_uA}UNEXEC_SRC${ac_uB}UNEXEC_SRC${ac_uC}unexsunos4.c${ac_uD}
${ac_eA}UNEXEC_SRC${ac_eB}UNEXEC_SRC${ac_eC}unexsunos4.c${ac_eD}
${ac_dA}HAVE_X_WINDOWS${ac_dB}HAVE_X_WINDOWS${ac_dC}1${ac_dD}
${ac_uA}HAVE_X_WINDOWS${ac_uB}HAVE_X_WINDOWS${ac_uC}1${ac_uD}
${ac_eA}HAVE_X_WINDOWS${ac_eB}HAVE_X_WINDOWS${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}GNU_MALLOC${ac_dB}GNU_MALLOC${ac_dC}1${ac_dD}
${ac_uA}GNU_MALLOC${ac_uB}GNU_MALLOC${ac_uC}1${ac_uD}
${ac_eA}GNU_MALLOC${ac_eB}GNU_MALLOC${ac_eC}1${ac_eD}
${ac_dA}REL_ALLOC${ac_dB}REL_ALLOC${ac_dC}1${ac_dD}
${ac_uA}REL_ALLOC${ac_uB}REL_ALLOC${ac_uC}1${ac_uD}
${ac_eA}REL_ALLOC${ac_eB}REL_ALLOC${ac_eC}1${ac_eD}
${ac_dA}LISP_FLOAT_TYPE${ac_dB}LISP_FLOAT_TYPE${ac_dC}1${ac_dD}
${ac_uA}LISP_FLOAT_TYPE${ac_uB}LISP_FLOAT_TYPE${ac_uC}1${ac_uD}
${ac_eA}LISP_FLOAT_TYPE${ac_eB}LISP_FLOAT_TYPE${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}LWLIB_USES_MOTIF${ac_dB}LWLIB_USES_MOTIF${ac_dC}1${ac_dD}
${ac_uA}LWLIB_USES_MOTIF${ac_uB}LWLIB_USES_MOTIF${ac_uC}1${ac_uD}
${ac_eA}LWLIB_USES_MOTIF${ac_eB}LWLIB_USES_MOTIF${ac_eC}1${ac_eD}
${ac_dA}LWLIB_MENUBARS_LUCID${ac_dB}LWLIB_MENUBARS_LUCID${ac_dC}1${ac_dD}
${ac_uA}LWLIB_MENUBARS_LUCID${ac_uB}LWLIB_MENUBARS_LUCID${ac_uC}1${ac_uD}
${ac_eA}LWLIB_MENUBARS_LUCID${ac_eB}LWLIB_MENUBARS_LUCID${ac_eC}1${ac_eD}
${ac_dA}HAVE_MENUBARS${ac_dB}HAVE_MENUBARS${ac_dC}1${ac_dD}
${ac_uA}HAVE_MENUBARS${ac_uB}HAVE_MENUBARS${ac_uC}1${ac_uD}
${ac_eA}HAVE_MENUBARS${ac_eB}HAVE_MENUBARS${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}LWLIB_SCROLLBARS_LUCID${ac_dB}LWLIB_SCROLLBARS_LUCID${ac_dC}1${ac_dD}
${ac_uA}LWLIB_SCROLLBARS_LUCID${ac_uB}LWLIB_SCROLLBARS_LUCID${ac_uC}1${ac_uD}
${ac_eA}LWLIB_SCROLLBARS_LUCID${ac_eB}LWLIB_SCROLLBARS_LUCID${ac_eC}1${ac_eD}
${ac_dA}HAVE_SCROLLBARS${ac_dB}HAVE_SCROLLBARS${ac_dC}1${ac_dD}
${ac_uA}HAVE_SCROLLBARS${ac_uB}HAVE_SCROLLBARS${ac_uC}1${ac_uD}
${ac_eA}HAVE_SCROLLBARS${ac_eB}HAVE_SCROLLBARS${ac_eC}1${ac_eD}
${ac_dA}LWLIB_DIALOGS_MOTIF${ac_dB}LWLIB_DIALOGS_MOTIF${ac_dC}1${ac_dD}
${ac_uA}LWLIB_DIALOGS_MOTIF${ac_uB}LWLIB_DIALOGS_MOTIF${ac_uC}1${ac_uD}
${ac_eA}LWLIB_DIALOGS_MOTIF${ac_eB}LWLIB_DIALOGS_MOTIF${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}HAVE_DIALOGS${ac_dB}HAVE_DIALOGS${ac_dC}1${ac_dD}
${ac_uA}HAVE_DIALOGS${ac_uB}HAVE_DIALOGS${ac_uC}1${ac_uD}
${ac_eA}HAVE_DIALOGS${ac_eB}HAVE_DIALOGS${ac_eC}1${ac_eD}
${ac_dA}HAVE_TOOLBARS${ac_dB}HAVE_TOOLBARS${ac_dC}1${ac_dD}
${ac_uA}HAVE_TOOLBARS${ac_uB}HAVE_TOOLBARS${ac_uC}1${ac_uD}
${ac_eA}HAVE_TOOLBARS${ac_eB}HAVE_TOOLBARS${ac_eC}1${ac_eD}
${ac_dA}HAVE_TTY${ac_dB}HAVE_TTY${ac_dC}1${ac_dD}
${ac_uA}HAVE_TTY${ac_uB}HAVE_TTY${ac_uC}1${ac_uD}
${ac_eA}HAVE_TTY${ac_eB}HAVE_TTY${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}TOOLTALK${ac_dB}TOOLTALK${ac_dC}1${ac_dD}
${ac_uA}TOOLTALK${ac_uB}TOOLTALK${ac_uC}1${ac_uD}
${ac_eA}TOOLTALK${ac_eB}TOOLTALK${ac_eC}1${ac_eD}
${ac_dA}SUNPRO${ac_dB}SUNPRO${ac_dC}1${ac_dD}
${ac_uA}SUNPRO${ac_uB}SUNPRO${ac_uC}1${ac_uD}
${ac_eA}SUNPRO${ac_eB}SUNPRO${ac_eC}1${ac_eD}
${ac_dA}HAVE_NATIVE_SOUND${ac_dB}HAVE_NATIVE_SOUND${ac_dC}1${ac_dD}
${ac_uA}HAVE_NATIVE_SOUND${ac_uB}HAVE_NATIVE_SOUND${ac_uC}1${ac_uD}
${ac_eA}HAVE_NATIVE_SOUND${ac_eB}HAVE_NATIVE_SOUND${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}CONST_IS_LOSING${ac_dB}CONST_IS_LOSING${ac_dC}1${ac_dD}
${ac_uA}CONST_IS_LOSING${ac_uB}CONST_IS_LOSING${ac_uC}1${ac_uD}
${ac_eA}CONST_IS_LOSING${ac_eB}CONST_IS_LOSING${ac_eC}1${ac_eD}
${ac_dA}USE_ASSERTIONS${ac_dB}USE_ASSERTIONS${ac_dC}1${ac_dD}
${ac_uA}USE_ASSERTIONS${ac_uB}USE_ASSERTIONS${ac_uC}1${ac_uD}
${ac_eA}USE_ASSERTIONS${ac_eB}USE_ASSERTIONS${ac_eC}1${ac_eD}
${ac_dA}ERROR_CHECK_EXTENTS${ac_dB}ERROR_CHECK_EXTENTS${ac_dC}1${ac_dD}
${ac_uA}ERROR_CHECK_EXTENTS${ac_uB}ERROR_CHECK_EXTENTS${ac_uC}1${ac_uD}
${ac_eA}ERROR_CHECK_EXTENTS${ac_eB}ERROR_CHECK_EXTENTS${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}ERROR_CHECK_TYPECHECK${ac_dB}ERROR_CHECK_TYPECHECK${ac_dC}1${ac_dD}
${ac_uA}ERROR_CHECK_TYPECHECK${ac_uB}ERROR_CHECK_TYPECHECK${ac_uC}1${ac_uD}
${ac_eA}ERROR_CHECK_TYPECHECK${ac_eB}ERROR_CHECK_TYPECHECK${ac_eC}1${ac_eD}
${ac_dA}ERROR_CHECK_BUFPOS${ac_dB}ERROR_CHECK_BUFPOS${ac_dC}1${ac_dD}
${ac_uA}ERROR_CHECK_BUFPOS${ac_uB}ERROR_CHECK_BUFPOS${ac_uC}1${ac_uD}
${ac_eA}ERROR_CHECK_BUFPOS${ac_eB}ERROR_CHECK_BUFPOS${ac_eC}1${ac_eD}
${ac_dA}ERROR_CHECK_GC${ac_dB}ERROR_CHECK_GC${ac_dC}1${ac_dD}
${ac_uA}ERROR_CHECK_GC${ac_uB}ERROR_CHECK_GC${ac_uC}1${ac_uD}
${ac_eA}ERROR_CHECK_GC${ac_eB}ERROR_CHECK_GC${ac_eC}1${ac_eD}
CONFEOF
cat >> conftest.sed <<CONFEOF
${ac_dA}ERROR_CHECK_MALLOC${ac_dB}ERROR_CHECK_MALLOC${ac_dC}1${ac_dD}
${ac_uA}ERROR_CHECK_MALLOC${ac_uB}ERROR_CHECK_MALLOC${ac_uC}1${ac_uD}
${ac_eA}ERROR_CHECK_MALLOC${ac_eB}ERROR_CHECK_MALLOC${ac_eC}1${ac_eD}
${ac_dA}DEBUG_XEMACS${ac_dB}DEBUG_XEMACS${ac_dC}1${ac_dD}
${ac_uA}DEBUG_XEMACS${ac_uB}DEBUG_XEMACS${ac_uC}1${ac_uD}
${ac_eA}DEBUG_XEMACS${ac_eB}DEBUG_XEMACS${ac_eC}1${ac_eD}
${ac_dA}NO_UNION_TYPE${ac_dB}NO_UNION_TYPE${ac_dC}1${ac_dD}
${ac_uA}NO_UNION_TYPE${ac_uB}NO_UNION_TYPE${ac_uC}1${ac_uD}
${ac_eA}NO_UNION_TYPE${ac_eB}NO_UNION_TYPE${ac_eC}1${ac_eD}
CONFEOF
# This sed command replaces #undef's with comments.  This is necessary, for
# example, in the case of _POSIX_SOURCE, which is predefined and required
# on some systems where configure will not decide to define it in
# src/config.h.
cat >> conftest.sed <<\CONFEOF
s,^[ 	]*#[ 	]*undef[ 	][ 	]*[a-zA-Z_][a-zA-Z_0-9]*,/* & */,
CONFEOF
rm -f conftest.h
# Break up the sed commands because old seds have small limits.
ac_max_sed_lines=20

CONFIG_HEADERS=${CONFIG_HEADERS-"src/config.h"}
for ac_file in .. ${CONFIG_HEADERS}; do if test "x$ac_file" != x..; then
  echo creating $ac_file

  cp $ac_given_srcdir/$ac_file.in conftest.h1
  cp conftest.sed conftest.stm
  while :
  do
    ac_lines=`grep -c . conftest.stm`
    if test -z "$ac_lines" || test "$ac_lines" -eq 0; then break; fi
    rm -f conftest.s1 conftest.s2 conftest.h2
    sed ${ac_max_sed_lines}q conftest.stm > conftest.s1 # Like head -20.
    sed 1,${ac_max_sed_lines}d conftest.stm > conftest.s2 # Like tail +21.
    sed -f conftest.s1 < conftest.h1 > conftest.h2
    rm -f conftest.s1 conftest.h1 conftest.stm
    mv conftest.h2 conftest.h1
    mv conftest.s2 conftest.stm
  done
  rm -f conftest.stm conftest.h
  echo "/* $ac_file.  Generated automatically by configure.  */" > conftest.h
  cat conftest.h1 >> conftest.h
  rm -f conftest.h1
  if cmp -s $ac_file conftest.h 2>/dev/null; then
    # The file exists and we would not be changing it.
    echo "$ac_file is unchanged"
    rm -f conftest.h
  else
    rm -f $ac_file
    mv conftest.h $ac_file
  fi
fi; done
rm -f conftest.sed




echo "creating src/Makefile"; topsrcdir=/vol/emacs/xemacs-19.14-b25; ( cd ./src; rm -f junk.c; sed -e 's/^# Generated.*//' -e 's%/\*\*/#.*%%' < Makefile.in > junk.c; eval `echo ${CPP} -I. -I${topsrcdir}/src ${CPPFLAGS} junk.c \>junk.cpp`; < junk.cpp sed -e 's/^#.*//' -e 's/^[ \f\t][ \f\t]*$//' -e 's/^ / /' | sed -n -e '/^..*$/p' > Makefile.new; chmod 444 Makefile.new; mv -f Makefile.new Makefile; rm -f junk.c junk.cpp; )
echo "creating lwlib/Makefile"; topsrcdir=/vol/emacs/xemacs-19.14-b25; ( cd ./lwlib; rm -f junk.c; sed -e 's/^# Generated.*//' -e 's%/\*\*/#.*%%' < Makefile.in > junk.c; eval `echo ${CPP} -I. -I${topsrcdir}/src ${CPPFLAGS} junk.c \>junk.cpp`; < junk.cpp sed -e 's/^#.*//' -e 's/^[ \f\t][ \f\t]*$//' -e 's/^ / /' | sed -n -e '/^..*$/p' > Makefile.new; chmod 444 Makefile.new; mv -f Makefile.new Makefile; rm -f junk.c junk.cpp; )
echo "creating lib-src/Makefile"; topsrcdir=/vol/emacs/xemacs-19.14-b25; ( cd ./lib-src; rm -f junk.c; sed -e 's/^# Generated.*//' -e 's%/\*\*/#.*%%' < Makefile.in > junk.c; eval `echo ${CPP} -I. -I${topsrcdir}/src ${CPPFLAGS} junk.c \>junk.cpp`; < junk.cpp sed -e 's/^#.*//' -e 's/^[ \f\t][ \f\t]*$//' -e 's/^ / /' | sed -n -e '/^..*$/p' > Makefile.new; chmod 444 Makefile.new; mv -f Makefile.new Makefile; rm -f junk.c junk.cpp; )
echo "creating dynodump/Makefile"; topsrcdir=/vol/emacs/xemacs-19.14-b25; ( cd ./dynodump; rm -f junk.c; sed -e 's/^# Generated.*//' -e 's%/\*\*/#.*%%' < Makefile.in > junk.c; eval `echo ${CPP} -I. -I${topsrcdir}/src ${CPPFLAGS} junk.c \>junk.cpp`; < junk.cpp sed -e 's/^#.*//' -e 's/^[ \f\t][ \f\t]*$//' -e 's/^ / /' | sed -n -e '/^..*$/p' > Makefile.new; chmod 444 Makefile.new; mv -f Makefile.new Makefile; rm -f junk.c junk.cpp; )
echo "creating man/Makefile"; topsrcdir=/vol/emacs/xemacs-19.14-b25; ( cd ./man; rm -f junk.c; sed -e 's/^# Generated.*//' -e 's%/\*\*/#.*%%' < Makefile.in > junk.c; eval `echo ${CPP} -I. -I${topsrcdir}/src ${CPPFLAGS} junk.c \>junk.cpp`; < junk.cpp sed -e 's/^#.*//' -e 's/^[ \f\t][ \f\t]*$//' -e 's/^ / /' | sed -n -e '/^..*$/p' > Makefile.new; chmod 444 Makefile.new; mv -f Makefile.new Makefile; rm -f junk.c junk.cpp; )
exit 0

----Next_Part(Wed_Jun_19_09:08:13_1996)----

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 10:17:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA02594 for xemacs-beta-people; Wed, 19 Jun 1996 10:17:13 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA02589 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 10:17:12 -0500 (CDT)
Received: from chekov.ctd.comsat.com (exim@chekov.ctd.comsat.com [134.133.40.22]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA27395 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 10:17:13 -0500 (CDT)
Received: from neal by chekov.ctd.comsat.com with local (Exim 0.51 #1)
	id E0uWP0J-0002aB-00; Wed, 19 Jun 1996 11:17:11 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: b26 hppa1.1 hpux9.05 success
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uWP0J-0002aB-00@chekov.ctd.comsat.com>
Date: Wed, 19 Jun 1996 11:17:11 -0400

Built b26 on hppa1.1 hpux9.05 gcc-2.7.2 OK.

Configured for `hppa1.1-hp-hpux9.05'.

  Where should the build process find the source code?    /usr/local/beta/xemacs-19.14-b26
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/hpux9shr.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              gcc -g -O3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/include/X11R5
  Where do we find X Windows libraries?                   /usr/lib/X11R5 -L/usr/lib/Motif1.2
  Additional header files:                                /usr/local/include/db
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 10:17:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA02587 for xemacs-beta-people; Wed, 19 Jun 1996 10:17:06 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA02584 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 10:17:05 -0500 (CDT)
Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA07051 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 10:16:48 -0500 (CDT)
Received: from herr (herr.first.gmd.de) by prosun.first.gmd.de (4.1/SMI-4.1)
	id AA27076; Wed, 19 Jun 96 17:16:43 +0200
Sender: sh@prosun.first.gmd.de
Message-Id: <31C819DC.167EB0E7@first.gmd.de>
Date: Wed, 19 Jun 1996 17:16:44 +0200
From: Stephan Herrmann <sh@prosun.first.gmd.de>
Organization: GMD-FIRST
X-Mailer: Mozilla 2.02 (X11; I; SunOS 4.1.3_U1 sun4m)
Mime-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: b26 success, one ExternalClient problem persists
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Success with:

Configured for `sparc-sun-sunos4.1.3'.

  Where should the build process find the source code?
/export/herr/sh/compile/xemacs-19.14-b25
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sunos4-1-3shr.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -g -O3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?
/opt/X11R6/include
  Where do we find X Windows libraries?                   /opt/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Compiling in support for ToolTalk.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

However, one proplem with external clients (as reported earlier)
persists:

xemacs dumps core, when menubar is hidden in an external client frame.
The patch I sent, doesn't do anything do deal with UpdateSizeHint for
such a frame, but it prevents it from dumping and works alright for me
at the time being. Therefore I resend the patchlet. I would really like
to see it in the release.

-----------------------------------------------------------------------

*** /tmp/EmacsShell.c[1.0]      Mon Jun  3 03:00:10 1996
--- EmacsShell.c        Sat Jun  1 02:21:04 1996
***************
*** 33,38 ****
--- 33,39 ----
  #include <X11/Vendor.h>
  #include <X11/VendorP.h>
  #include "EmacsShell.h"
+ #include "ExternalShell.h"
  
  #if 0 /* Not currently used */
  
***************
*** 161,166 ****
--- 162,169 ----
  {
    if (XtIsSubclass (gw, topLevelEmacsShellWidgetClass))
      TopLevelEmacsShellUpdateSizeHints (gw);
+   else if (XtIsSubclass (gw, externalShellWidgetClass))
+     /* do what ??? Don't abort! */;
    else if (XtIsSubclass (gw, transientEmacsShellWidgetClass))
      TransientEmacsShellUpdateSizeHints (gw);
    else

-----------------------------------------------------------------------

Cheers
Stephan

-- 
--------------------------------------------------------------------------
			  Stephan Herrmann
			  ----------------
	GMD-FIRST				   TU-Berlin
 Gesellschaft f. Mathematik			 FB Informatik
   u. Datenverarbeitung				Softwaretechnik 
     sh@first.gmd.de			    stephan@cs.tu-berlin.de
  Phone: ++49 30 6392 1870
--------------------------------------------------------------------------

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 11:19:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA02900 for xemacs-beta-people; Wed, 19 Jun 1996 11:19:58 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA02897 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 11:19:57 -0500 (CDT)
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA00321 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 11:19:58 -0500 (CDT)
Received: from FISHKILL by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7035;
   Wed, 19 Jun 96 12:19:42 EDT
Received: by FISHKILL (XAGENTA 4.0) id 1137; Wed, 19 Jun 1996 12:19:53 -0400 
Received: by spacedog.fishkill.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA29620; Wed, 19 Jun 1996 12:19:51 -0400
Date: Wed, 19 Jun 1996 12:19:51 -0400
Message-Id: <9606191619.AA29620@spacedog.fishkill.ibm.com>
From: "Doug Keller" <dkeller@VNET.IBM.COM>
To: xemacs-beta@cs.uiuc.edu
Subject: Success with b26 under AIX 3.2.5

Configured for `rs6000-ibm-aix3.2.5'.

  Where should the build process find the source code?    /afs/eds/u/hines/beta/xemacs/xemacs-19.14-b26
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/aix3-2-5.h' and `m/ibmrs6000.h'
  What compiler should XEmacs be built with?              xlc -O -Q -qnoansialias -D_ALL_SOURCE -tl -B/usr/ccs/bin/325/
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /afs/eds/u/hines/beta/xemacs/include
  Additional libraries:                                   /afs/eds/u/hines/beta/xemacs/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 11:01:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA02742 for xemacs-beta-people; Wed, 19 Jun 1996 11:01:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA02739 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 11:01:13 -0500 (CDT)
Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA07082 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 11:01:05 -0500 (CDT)
Received: from djp-fornet.cern.ch (djp-fornet.cern.ch [137.138.36.141]) by server21.digital.fr (8.7.3/8.7) with SMTP id SAA03520 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 18:02:07 +0200 (MET DST)
Received: by djp-fornet.cern.ch; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA17826; Wed, 19 Jun 1996 17:59:40 +0200
Date: Wed, 19 Jun 1996 17:59:40 +0200
Message-Id: <9606191559.AA17826@djp-fornet.cern.ch>
From: Stephen Carney <carney@xemacs.org>
To: xemacs-beta@xemacs.org
Subject: RE: dump in select_filedesc, assert(!filedesc_to_what_closure[fd])
In-Reply-To: <290204464961842030@toto.iv>
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

Here's another dump in select_filedesc.  This time it was in 14b26, and
it happened when I did `C-x C-f
/carney@africa.cern.ch:/usr/web/digital-at-cern/joint-project/sue/'.
I'm using efs 1.14/1.52.

        Steve


===== Lisp backtrace =====

Fatal error: assertion failed, file event-Xt.c, line 1536, !filedesc_to_what_closure[fd]

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb `which xemacs` core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  # (unwind-protect ...)
  start-process-internal("*ftp carney@africa.cern.ch*" #<buffer "*ftp carney@africa.cern.ch*"> "ftp" "-i" "-n" "-g" "-v")
  apply(start-process-internal "*ftp carney@africa.cern.ch*" #<buffer "*ftp carney@africa.cern.ch*"> "ftp" ("-i" "-n" "-g" "-v"))
  # bind (program-args program buffer name)
  start-process("*ftp carney@africa.cern.ch*" #<buffer "*ftp carney@africa.cern.ch*"> "ftp" "-i" "-n" "-g" "-v")
  apply(start-process "*ftp carney@africa.cern.ch*" #<buffer "*ftp carney@africa.cern.ch*"> "ftp" ("-i" "-n" "-g" "-v"))
  # bind (proc opaque-p process-connection-type buffer use-gateway name user host)
  efs-start-process("africa.cern.ch" "carney" "*ftp carney@africa.cern.ch*")
  # bind (name proc user host)
  efs-get-process("africa.cern.ch" "carney")
  # bind (host type user host)
  efs-host-type("africa.cern.ch" "carney")
  # bind (start string backskip regexp lbackskip lregexp parsed host-type host user)
  # (unwind-protect ...)
  # bind (match-data buff cfs s-c-res path host user host-type default name)
  expand-file-name("/carney@africa.cern.ch:/user/web/digital-at-cern/joint-project/sue/")
  byte-code(" \"!C" [expand-file-name read-file-name "Find file: " default-directory] 4)
  call-interactively(find-file)
  # (condition-case ... . error)
  # (catch top-level ...)
Abort process (core dumped)


===== C stacktrace =====

% dbx /usr/local/xemacs-beta/bin/xemacs-19.14-b26 core
dbx version 3.11.8
Type 'help' for help.
Core file created by program "xemacs-19.14-b26"

signal IOT/Abort trap at >*[__kill, 0x3ff8010ce68] 	beq	r19, 0x3ff8010ce80
(dbx) where
>  0 __kill(0x1201b9a20, 0x3ffc0091560, 0x120099d80, 0x1401690b0, 0x140124978) [0x3ff8010ce68]
   1 fatal_error_signal(sig = 0) ["emacs.c":193, 0x120099e08]
   2 __kill(0x3ffc00802f0, 0x59, 0x0, 0x0, 0x0) [0x3ff8010ce64]
   3 raise(0x6, 0x0, 0x2, 0x11fffbc10, 0x59) [0x3ff80121830]
   4 abort(0x7c04, 0x3ff800e0ca8, 0x59, 0x120099c80, 0x0) [0x3ff8010fc80]
   5 assert_failed(file = 0x2f7e, line = 6, expr = 0x11fffc200 = "\200^\\t ^A") ["emacs.c":1787, 0x12009c6cc]
   6 emacs_Xt_select_process(p = 0x1406784000) ["event-Xt.c":1604, 0x1201db46c]
   7 event_stream_select_process(proc = 0x2f7e) ["event-stream.c":545, 0x1200b7890]
   8 create_process(process = (...), new_argv = 0x11fffc348, current_dir = 0x1409b4b68 = "/kits/install/xemacs/beta") ["process.c":1050, 0x1201596f4]
   9 Fstart_process_internal(nargs = 7, args = 0x11fffc570) ["process.c":1228, 0x120159efc]
  10 funcall_recording_as(recorded_as = (...), nargs = 7, args = 0x11fffc568) ["eval.c":3191, 0x1200a5824]
  11 Fapply(nargs = 5, args = 0x11fffc720) ["eval.c":3471, 0x1200a681c]
  12 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fffc718) ["eval.c":3191, 0x1200a5824]
  13 Ffuncall(nargs = 6, args = 0x11fffc200) ["eval.c":3253, 0x1200a5b44]
  14 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d54]
  15 funcall_lambda(fun = (...), nargs = 7, arg_vector = 0x11fffcc70) ["eval.c":3636, 0x1200a75fc]
  16 funcall_recording_as(recorded_as = (...), nargs = 7, args = 0x11fffcc68) ["eval.c":3223, 0x1200a5a68]
  17 Fapply(nargs = 5, args = 0x11fffce20) ["eval.c":3471, 0x1200a681c]
  18 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fffce18) ["eval.c":3191, 0x1200a5824]
  19 Ffuncall(nargs = 6, args = 0x11fffc200) ["eval.c":3253, 0x1200a5b44]
  20 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d54]
  21 funcall_lambda(fun = (...), nargs = 3, arg_vector = 0x11fffd3b8) ["eval.c":3636, 0x1200a75fc]
  22 funcall_recording_as(recorded_as = (...), nargs = 3, args = 0x11fffd3b0) ["eval.c":3223, 0x1200a5a68]
  23 Ffuncall(nargs = 6, args = 0x11fffc200) ["eval.c":3253, 0x1200a5b44]
  24 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d54]
  25 funcall_lambda(fun = (...), nargs = 2, arg_vector = 0x11fffd928) ["eval.c":3636, 0x1200a75fc]
  26 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffd920) ["eval.c":3223, 0x1200a5a68]
  27 Ffuncall(nargs = 6, args = 0x11fffc200) ["eval.c":3253, 0x1200a5b44]
  28 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d54]
  29 funcall_lambda(fun = (...), nargs = 2, arg_vector = 0x11fffde80) ["eval.c":3636, 0x1200a75fc]
  30 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffde78) ["eval.c":3223, 0x1200a5a68]
  31 Ffuncall(nargs = 6, args = 0x11fffc200) ["eval.c":3253, 0x1200a5b44]
  32 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d54]
  33 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffe418) ["eval.c":3636, 0x1200a75fc]
  34 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffe410) ["eval.c":3223, 0x1200a5a68]
  35 Ffuncall(nargs = 6, args = 0x11fffc200) ["eval.c":3253, 0x1200a5b44]
  36 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x120067d54]
  37 primitive_funcall(fn = 0x3ff8010fc20, nargs = 536855040, args = (nil)) ["eval.c":3488, 0x1200a6910]
  38 funcall_subr(subr = 0x6, args = 0x11fffc200) ["eval.c":3526, 0x1200a6be8]
  39 Feval(form = (...)) ["eval.c":3064, 0x1200a5068]
  40 Fcall_interactively(function = (...), record_flag = (...), keys = (...)) ["callint.c":331, 0x12006a4c4]
  41 Fcommand_execute(cmd = (...), record = (...), keys = (...)) ["eval.c":2628, 0x1200a39d4]
  42 execute_command_event(command_builder = 0x14023da80, event = (...)) ["event-stream.c":3480, 0x1200c239c]
  43 Fdispatch_event(event = (...)) ["event-stream.c":3765, 0x1200c360c]
  44 Fcommand_loop_1() ["cmdloop.c":542, 0x1200727dc]
  45 command_loop_1(dummy = (...)) ["cmdloop.c":462, 0x12007234c]
  46 condition_case_1(handlers = (...), bfun = 0x1200722a0, barg = (...), hfun = 0x120072a40, harg = (...)) ["eval.c":1672, 0x12009fef0]
  47 command_loop_2(dummy = (...)) ["cmdloop.c":235, 0x120072c1c]
  48 internal_catch(tag = (...), func = 0x11fffc200, arg = (...), threw = (nil)) ["eval.c":1347, 0x12009f9dc]
  49 initial_command_loop(load_me = (...)) ["cmdloop.c":273, 0x12007184c]
  50 Frunning_temacs_p() ["emacs.c":1317, 0x12009b82c]
(dbx) 

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 11:36:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA02965 for xemacs-beta-people; Wed, 19 Jun 1996 11:36:17 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA02962 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 11:36:16 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA07232 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 11:36:12 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA03794; Wed, 19 Jun 1996 11:36:14 -0500 (CDT)
Message-Id: <199606191636.LAA03794@charles.cs.uiuc.edu>
To: Mark Borges <mdb@cdc.noaa.gov>
cc: xemacs-beta@xemacs.org
Subject: Re: [19.14-b26] solaris-2.5 failure under X 
In-reply-to: Your message of "19 Jun 1996 10:23:24 MDT."
             <vk4to74vb7.fsf@cdc.noaa.gov> 
Date: Wed, 19 Jun 1996 11:36:14 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

SparcWorks.  I forgot to update the damn loaddefs-eos.el file again.
That thing is definitely going bye-bye in 19.15.

I'll put a corrected version on the ftp site soon.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 11:23:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA02924 for xemacs-beta-people; Wed, 19 Jun 1996 11:23:35 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA02921 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 11:23:34 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA07216 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 11:23:29 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id KAA28114; Wed, 19 Jun 1996 10:23:26 -0600
Received: by suomi (SMI-8.6) id KAA02748; Wed, 19 Jun 1996 10:23:25 -0600
Sender: mdb@cdc.noaa.gov
To: xemacs-beta@xemacs.org
Subject: [19.14-b26] solaris-2.5 failure under X
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 19 Jun 1996 10:23:24 -0600
In-Reply-To: Stephan Herrmann's message of Wed, 19 Jun 1996 17:16:44 +0200
Message-ID: <vk4to74vb7.fsf@cdc.noaa.gov>
Lines: 75
X-Mailer: Gnus v5.2.19/XEmacs 19.14

[ Built from a full distribution, 
   $ md5 xemacs-19.14-b26.tar.gz
   MD5 (xemacs-19.14-b26.tar.gz) = 5d376c4c94e7007a05fb551aa1e8344f
]

I must be doing something stupid. 19.14-b26 worked fine on a TTY, but
under X `xemacs -q' is reporting:
----------------------------------------
  $ xemacs -q
Initialization error: Symbol's value as variable is void: ps-print-color-p
        This probably means that XEmacs is picking up an old version of
        the lisp library, or that some .elc files are not up-to-date.
exec-directory is "/home/mdb/gnu/lib/xemacs-19.14-b26/sparc-sun-solaris2.5/"
data-directory is "/home/mdb/gnu/lib/xemacs-19.14-b26/etc/"
doc-directory is "/home/mdb/gnu/lib/xemacs-19.14-b26/sparc-sun-solaris2.5/"
load-path is ("/home/mdb/gnu/lib/xemacs/site-lisp" "/home/mdb/gnu/lib/xemacs/site-lisp/mel
/" "/home/mdb/gnu/lib/xemacs/site-lisp/tl/" "/home/mdb/gnu/lib/xemacs/site-lisp/tm/" "/hom
e/mdb/gnu/lib/xemacs-19.14-b26/lisp" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/bytecomp/" "
/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/calendar/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lis
p/cl/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/comint/" "/home/mdb/gnu/lib/xemacs-19.14-b
26/lisp/dired/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/edebug/" "/home/mdb/gnu/lib/xemac
s-19.14-b26/lisp/ediff/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/electric/" "/home/mdb/gn
u/lib/xemacs-19.14-b26/lisp/emulators/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/energize/
" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/eos/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/
epoch/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/eterm/" "/home/mdb/gnu/lib/xemacs-19.14-b
26/lisp/games/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/gnus/" "/home/mdb/gnu/lib/xemacs-
19.14-b26/lisp/hm--html-menus/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/hyperbole/" "/hom
e/mdb/gnu/lib/xemacs-19.14-b26/lisp/ilisp/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/iso/"
 "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/mailcrypt/" "/home/mdb/gnu/lib/xemacs-19.14-b26/
lisp/mh-e/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/modes/" "/home/mdb/gnu/lib/xemacs-19.
14-b26/lisp/ns/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/oobr/" "/home/mdb/gnu/lib/xemacs
-19.14-b26/lisp/packages/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/pcl-cvs/" "/home/mdb/g
nu/lib/xemacs-19.14-b26/lisp/prim/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/psgml/" "/hom
e/mdb/gnu/lib/xemacs-19.14-b26/lisp/rmail/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/sunpr
o/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/term/" "/home/mdb/gnu/lib/xemacs-19.14-b26/li
sp/tooltalk/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/url/" "/home/mdb/gnu/lib/xemacs-19.
14-b26/lisp/utils/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/viper/" "/home/mdb/gnu/lib/xe
macs-19.14-b26/lisp/vm/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/vms/" "/home/mdb/gnu/lib
/xemacs-19.14-b26/lisp/w3/" "/home/mdb/gnu/lib/xemacs-19.14-b26/lisp/x11/")
  backtrace(external-debugging-output t)
  # bind (string error debug-on-error stream debugger-args)
  early-error-handler(error (void-variable ps-print-color-p))
  # (catch debugger ...)
  # (unwind-protect ...)
  # bind (stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (frame-being-created)
  make-frame(nil #<x-device on "hpx06:0.0" 0x6fb>)
  frame-initialize()
  # bind (debugger debug-on-error command-line-args-left)
  command-line()
  # (unwind-protect ...)
  normal-top-level()
  # (condition-case ... . error)
  # (catch top-level ...)
  $
----------------------------------------
The variable in question appears in:

$ grep -l ps-print-color-p **/*.el
packages/ps-print.el
prim/loaddefs.el
w3/w3-menu.el
w3/w3-vars.el
x11/x-menubar.el
$

Is this a Sparcworks or EOS only problem?

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 11:48:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA03000 for xemacs-beta-people; Wed, 19 Jun 1996 11:48:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA02997 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 11:48:28 -0500 (CDT)
Received: from lemcbed.lem.uni-karlsruhe.de (lemcbed.lem.uni-karlsruhe.de [129.13.103.197]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA01243 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 11:48:12 -0500 (CDT)
Received: by lemcbed.lem.uni-karlsruhe.de; id AA25807; Wed, 19 Jun 1996 18:51:26 +0200
To: xemacs-beta@cs.uiuc.edu
Subject: b26 failure on DEC Unix 3.2
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Jens Lautenbacher <jens@lemcbed.lem.uni-karlsruhe.de>
Date: 19 Jun 1996 18:51:25 +0200
Message-Id: <x220jb4u0i.fsf@lemcbed.lem.uni-karlsruhe.de>
Lines: 46
X-Mailer: Gnus v5.2.19/XEmacs 19.14



Configured for `alpha-dec-osf3.2'.

  Where should the build process find the source code?    /server/users/jens/daten/gnu/xemacs-19.14-b23
  What installation prefix should install use?            /usr/users/jens
  What operating system and machine description files should XEmacs use?
        `s/decosf3-2.h' and `m/alpha.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/include/X11/
  Where do we find X Windows libraries?                   /usr/lib/X11/
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

[...]
gcc -c -Demacs -DHAVE_CONFIG_H  -I.        -I/server/users/jens/daten/gnu/xemacs-19.14-b23/src     -D_BSD            -I/usr/include/X11/             -I/server/users/jens/daten/gnu/xemacs-19.14-b23/src/../lwlib    -g -O  glyphs-x.c
glyphs-x.c:1880: parse error before `png_ptr'
glyphs-x.c: In function `png_read_from_memory':
glyphs-x.c:1885: `png_ptr' undeclared (first use this function)
glyphs-x.c:1885: (Each undeclared identifier is reported only once
glyphs-x.c:1885: for each function it appears in.)
glyphs-x.c:1885: warning: cast to pointer from integer of different size
glyphs-x.c:1887: `length' undeclared (first use this function)
glyphs-x.c:1889: `data' undeclared (first use this function)
make[1]: *** [glyphs-x.o] Error 1
make[1]: Leaving directory `/server/users/jens/daten/gnu/xemacs-19.14-b23/src'
make: *** [src] Error 2


Now trying without png support.

png library: libpng 1.0 beta 2 - version 0.81
	     August 24, 1995


From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 11:59:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA03043 for xemacs-beta-people; Wed, 19 Jun 1996 11:59:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA03040 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 11:59:43 -0500 (CDT)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA07264 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 11:59:36 -0500 (CDT)
Received: from hler.ifi.uio.no (4867@hler.ifi.uio.no [129.240.94.23]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <SAA10318@ifi.uio.no> for <xemacs-beta@xemacs.org> ; Wed, 19 Jun 1996 18:59:37 +0200
Received: (from larsi@localhost) by hler.ifi.uio.no ; Wed, 19 Jun 1996 18:59:37 +0200
Sender: larsi@ifi.uio.no
To: xemacs-beta@xemacs.org
Subject: Re: ^G granularity?
References: <199606160147.SAA22246@netcom2.netcom.com>
X-Face: &w!^oO<W.WBH]FsTP:P0f9X6M-ygaADlA_)eF$<UwQzj7:C=Gi<a?/_4$LX^@$Qq7-O&XHp
	lDARi8e8iT<(A$LWAZD*xjk^')/wI5nG;1cNB>~dS|}-P0~ge{$c!h\<y
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Date: 19 Jun 1996 18:59:35 +0200
In-Reply-To: wing@666.com's message of (unknown date)
Message-ID: <w8s3f3rohl4.fsf@hler.ifi.uio.no>
Lines: 24
X-Mailer: Gnus v5.2.22/XEmacs 19.14

wing@666.com (Ben Wing) writes:

> C-g does work for most people in most circumstances.  If it doesn't,
> there are only two explanations:
> 
> 1) the code is wrapped with a binding of `inhibit-quit' to t.
>    Ctrl-Shift-G should still work, I think.
> 
> 2) SIGIO is broken on your system, but BROKEN_SIGIO isn't defined.
> 
> To test #2, try executing
> 
> (while t)
> 
> from the *scratch* buffer.  If C-g doesn't interrupt, then you're
> seeing #2.

I tried this here as well (XEmacs 19.14 [Lucid] (sparc-sun-sunos4.1.3)
of Wed Jun 19 1996 on mimir.ifi.uio.no) (b26), and it failed.  I'm now
recompiling with BROKEN_SIGIO.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 12:23:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA03131 for xemacs-beta-people; Wed, 19 Jun 1996 12:23:17 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA03128 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 12:23:16 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA07337 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 12:23:12 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id LAA11118; Wed, 19 Jun 1996 11:23:15 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id LAA29259; Wed, 19 Jun 1996 11:23:13 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id LAA09764; Wed, 19 Jun 1996 11:22:56 -0600
Date: Wed, 19 Jun 1996 11:22:56 -0600
Message-Id: <199606191722.LAA09764@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: cthomp@cs.uiuc.edu
Cc: mdb@cdc.noaa.gov, xemacs-beta@xemacs.org
Subject: Re: [19.14-b26] solaris-2.5 failure under X 
In-Reply-To: <199606191636.LAA03794@charles.cs.uiuc.edu>
References: <vk4to74vb7.fsf@cdc.noaa.gov>
	<199606191636.LAA03794@charles.cs.uiuc.edu>
Reply-To: turner@lanl.gov

Chuck Thompson writes:
 > SparcWorks.  I forgot to update the damn loaddefs-eos.el file again.
 > That thing is definitely going bye-bye in 19.15.
 > 
 > I'll put a corrected version on the ftp site soon.

OK, ignore my msg about the same problem, then...

-John

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 12:20:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA03113 for xemacs-beta-people; Wed, 19 Jun 1996 12:20:49 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA03110 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 12:20:48 -0500 (CDT)
Received: from loiosh.kei.com (ckd@loiosh.kei.com [192.88.144.32]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA07314 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 12:20:44 -0500 (CDT)
Received: (from ckd@localhost) by loiosh.kei.com (8.7.5/8.7.3) id NAA28726; Wed, 19 Jun 1996 13:20:13 -0400 (EDT)
To: xemacs-beta@xemacs.org
Subject: b26 success on BSD/OS 2.1
X-Attribution: ckd
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Christopher Davis <ckd@loiosh.kei.com>
Date: 19 Jun 1996 13:20:13 -0400
Message-ID: <w4ennbpv76.fsf@loiosh.kei.com>
Lines: 29

I don't live on a SunOS box any more, so I can't easily test there.  The
last few betas have all compiled and run fine though (after that
XSETCONSOLE patch in the case of b25 :-)

Configured for `i386-unknown-bsdi2.1'.

  Where should the build process find the source code?    /src/xemacs-19.14-b26
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/bsdos2-1.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

I haven't tried it compiled in "need for speed" mode (gcc -O3 and no
debugging code) yet.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 12:22:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA03124 for xemacs-beta-people; Wed, 19 Jun 1996 12:22:04 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA03121 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 12:22:03 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA07327 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 12:21:58 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id LAA10841; Wed, 19 Jun 1996 11:22:00 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id LAA29211; Wed, 19 Jun 1996 11:21:58 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id LAA09752; Wed, 19 Jun 1996 11:21:40 -0600
Date: Wed, 19 Jun 1996 11:21:40 -0600
Message-Id: <199606191721.LAA09752@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: mdb@cdc.noaa.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: [19.14-b26] solaris-2.5 failure under X
In-Reply-To: <vk4to74vb7.fsf@cdc.noaa.gov>
References: <vk4to74vb7.fsf@cdc.noaa.gov>
Reply-To: turner@lanl.gov

Mark Borges writes:
 > [ Built from a full distribution, 
 >    $ md5 xemacs-19.14-b26.tar.gz
 >    MD5 (xemacs-19.14-b26.tar.gz) = 5d376c4c94e7007a05fb551aa1e8344f
 > ]
 > 
 > I must be doing something stupid. 19.14-b26 worked fine on a TTY, but
 > under X `xemacs -q' is reporting:
 > ----------------------------------------
 >   $ xemacs -q
 > Initialization error: Symbol's value as variable is void: ps-print-color-p
 >         This probably means that XEmacs is picking up an old version of
 >         the lisp library, or that some .elc files are not up-to-date.

[snip]

Ack!  I saw the same thing when I patched up from b25.

This was the first time this cycle I tried patching up rather than
getting the full dist, so I figured I'd done something wrong.

Just in an attempt to avoid getting the whole thing, I deleted all
.elc's with corresponding .orig's and rebuilt, but got the same
thing.

So I gave up and got the whole wad.  That's building now, but I guess
that's not going to work either.

 > Is this a Sparcworks or EOS only problem?

I'm building --with-sparcworks as well...

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 12:17:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA03096 for xemacs-beta-people; Wed, 19 Jun 1996 12:17:06 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA03093 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 12:17:05 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA01948 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 12:17:04 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id MAA16867 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 12:16:33 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id MAA13686 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 12:16:31 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id NAA23170 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 13:11:46 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: 19.14 b26:  failure on Solaris 2.5, gcc 2.7.2
Date: Wed, 19 Jun 1996 13:11:45 -0400
Message-ID: <8979.835204305@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

Built from a full distribution on Solaris 2.5, gcc 2.7.2, X11R6.1,
lucid only.

Configured for `sparc-sun-solaris2.5'.

  Where should the build process find the source code?    /home/unix/toy/apps/xemacs-19.14
  What installation prefix should install use?            /home/unix/toy/apps/XEmacs/beta
  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /apps/public/solaris2.5/X11R6.1/include
  Where do we find X Windows libraries?                   /apps/public/solaris2.5/X11R6.1/lib
  Additional header files:                                /apps/public/solaris2.4/include
  Additional libraries:                                   /apps/public/solaris2.4/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in both network and native sound support.
  Compiling in support for DBM.
  Compiling in support for ToolTalk.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

Compiled fine without problems.  However, running xemacs -q
-no-site-file says the following.  Exactly the same happens on Solaris
2.4 with the same config above, except with X11R6.

src/xemacs

Initialization error: Symbol's value as variable is void: ps-print-color-p

        This probably means that XEmacs is picking up an old version of
        the lisp library, or that some .elc files are not up-to-date.

exec-directory is "/home/unix/toy/apps/solaris/beta-19/lib-src/"
data-directory is "/home/unix/toy/apps/solaris/beta-19/etc/"
doc-directory is "/home/unix/toy/apps/solaris/beta-19/lib-src/"
load-path is ("/home/unix/toy/apps/solaris/beta-19/lisp" "/home/unix/toy/apps/solaris/beta-19/lisp/bytecomp/" "/home/unix/toy/apps/solaris/beta-19/lisp/calendar/" "/home/unix/toy/apps/solaris/beta-19/lisp/cl/" "/home/unix/toy/apps/solaris/beta-19/lisp/comint/" "/home/unix/toy/apps/solaris/beta-19/lisp/dired/" "/home/unix/toy/apps/solaris/beta-19/lisp/edebug/" "/home/unix/toy/apps/solaris/beta-19/lisp/ediff/" "/home/unix/toy/apps/solaris/beta-19/lisp/electric/" "/home/unix/toy/apps/solaris/beta-19/lisp/emulators/" "/home/unix/toy/apps/solaris/beta-19/lisp/energize/" "/home/unix/toy/apps/solaris/beta-19/lisp/eos/" "/home/unix/toy/apps/solaris/beta-19/lisp/epoch/" "/home/unix/toy/apps/solaris/beta-19/lisp/eterm/" "/home/unix/toy/apps/solaris/beta-19/lisp/games/" "/home/unix/toy/apps/solaris/beta-19/lisp/gnus/" "/home/unix/toy/apps/solaris/beta-19/lisp/hm--html-menus/" "/home/unix/toy/apps/solaris/beta-19/lisp/hyperbole/" "/home/unix/toy/apps/solaris/beta-19/lisp/ilisp/" "/home/!
 unix/toy/apps/solaris/beta-19/lisp/iso/" "/home/unix/toy/apps/solaris/beta-19/lisp/mailcrypt/" "/home/unix/toy/apps/solaris/beta-19/lisp/mh-e/" "/home/unix/toy/apps/solaris/beta-19/lisp/modes/" "/home/unix/toy/apps/solaris/beta-19/lisp/ns/" "/home/unix/toy/apps/solaris/beta-19/lisp/oobr/" "/home/unix/toy/apps/solaris/beta-19/lisp/packages/" "/home/unix/toy/apps/solaris/beta-19/lisp/pcl-cvs/" "/home/unix/toy/apps/solaris/beta-19/lisp/prim/" "/home/unix/toy/apps/solaris/beta-19/lisp/psgml/" "/home/unix/toy/apps/solaris/beta-19/lisp/rmail/" "/home/unix/toy/apps/solaris/beta-19/lisp/sunpro/" "/home/unix/toy/apps/solaris/beta-19/lisp/term/" "/home/unix/toy/apps/solaris/beta-19/lisp/tooltalk/" "/home/unix/toy/apps/solaris/beta-19/lisp/url/" "/home/unix/toy/apps/solaris/beta-19/lisp/utils/" "/home/unix/toy/apps/solaris/beta-19/lisp/viper/" "/home/unix/toy/apps/solaris/beta-19/lisp/vm/" "/home/unix/toy/apps/solaris/beta-19/lisp/vms/" "/home/unix/toy/apps/solaris/beta-19/lisp/w3/" "!
 /home/unix/toy/apps/solaris/beta-19/lisp/x11/")

  backtrace(external-debugging-output t)
  # bind (string error debug-on-error stream debugger-args)
  early-error-handler(error (void-variable ps-print-color-p))
  # (catch debugger ...)
  # (unwind-protect ...)
  # bind (stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (frame-being-created)
  make-frame(nil #<x-device on "rcur18:0.0" 0x6f5>)
  frame-initialize()
  # bind (debugger debug-on-error command-line-args-left)
  command-line()
  # (unwind-protect ...)
  normal-top-level()
  # (condition-case ... . error)
  # (catch top-level ...)

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 12:37:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA03195 for xemacs-beta-people; Wed, 19 Jun 1996 12:37:31 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA03192 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 12:37:30 -0500 (CDT)
Received: from tinderbox.Stanford.EDU (tinderbox.Stanford.EDU [171.64.72.13]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA07382 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 12:37:26 -0500 (CDT)
Received: by tinderbox.Stanford.EDU (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id KAA16956; Wed, 19 Jun 1996 10:37:30 -0700
Date: Wed, 19 Jun 1996 10:37:30 -0700
Message-Id: <199606191737.KAA16956@tinderbox.Stanford.EDU>
From: David Ofelt <ofelt@tinderbox.Stanford.EDU>
To: xemacs-beta@xemacs.org
Subject: Success with beta26 on IRIX 5.3


Beta 26 built fine, and has run fine for 30min or so.  

  Where should the build process find the source code?    /powderkeg/pk1/ofelt/local/xemacs/xemacs-19.14-b26
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/irix5-3.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              cc -O2 -mips2 -Olimit 4000
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

DaveO

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 12:44:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA03236 for xemacs-beta-people; Wed, 19 Jun 1996 12:44:51 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA03233 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 12:44:50 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA07405 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 12:44:46 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA04070; Wed, 19 Jun 1996 12:41:04 -0500 (CDT)
Message-Id: <199606191741.MAA04070@charles.cs.uiuc.edu>
To: carney@gvc.dec.com
cc: xemacs-beta@xemacs.org
Subject: Re: dump in select_filedesc, assert(!filedesc_to_what_closure[fd]) 
In-reply-to: Your message of "Wed, 19 Jun 1996 17:59:40 +0200."
             <9606191559.AA17826@djp-fornet.cern.ch> 
Date: Wed, 19 Jun 1996 12:41:03 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Stephen> Here's another dump in select_filedesc.  This time it was
    Stephen> in 14b26, and it happened when I did `C-x C-f
    Stephen> /carney@africa.cern.ch:/usr/web/digital-at-cern/joint-project/sue/'.
    Stephen> I'm using efs 1.14/1.52.


I found a file descriptor leak with Purify.  I don't know about its
impact on this crash but I believe the other one you reported involved
b26 checking for mail every minute.  It probably did cause that one.

No patch yet.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 13:02:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA03277 for xemacs-beta-people; Wed, 19 Jun 1996 13:02:39 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA03274 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 13:02:38 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA03134 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 13:02:32 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA03965; Wed, 19 Jun 1996 11:01:42 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [19.14-b26] Linux 2.0 Success
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 19 Jun 1996 11:01:41 -0700
Message-ID: <m220jbn056.fsf@deanna.miranova.com>
Lines: 34
X-Mailer: Gnus v5.2.21/XEmacs 19.14

(From a full distribution).

./configure  --with-xface=yes --with-sound=native --with-png=no

Configured for `i486-unknown-linux2.0.0'.

  Where should the build process find the source code?    /i/xemacs-19.14-b26
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 13:23:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA03343 for xemacs-beta-people; Wed, 19 Jun 1996 13:23:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA03340 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 13:23:43 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA07483; Wed, 19 Jun 1996 13:23:38 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id NAA19715; Wed, 19 Jun 1996 13:23:10 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id NAA15026; Wed, 19 Jun 1996 13:23:09 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id OAA29326; Wed, 19 Jun 1996 14:18:26 -0400
To: Chuck Thompson <cthomp@xemacs.org>
cc: xemacs-beta@xemacs.org
References: <199606190323.WAA24419@xemacs.cs.uiuc.edu> 
Subject: Re: XEmacs 19.14 beta26 
In-reply-to: (Your message of Tue, 18 Jun 1996 22:23:36 CDT.)
             <199606190323.WAA24419@xemacs.cs.uiuc.edu> 
Date: Wed, 19 Jun 1996 14:18:25 -0400
Message-ID: <16011.835208305@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

    Chuck> -- The force option to delete-frame is back.  You can no longer delete
    Chuck>    the last visible or iconic frame unless the second arg to
    Chuck>    delete-frame is non-nil.

FYI.  Consider this piece of code

	(let ((this-screen (selected-screen))
	      (mh-screen
	       (make-screen '((name . "MH-E Mail")
			      (width . 100) (height . 48)
			      ;; Should be -0 but -1 is close enough
			      (left . 106) (top . -1)))))
	  ;; If we succeeded, delete the old screen
	  (if mh-screen
	      (progn
		(delete-screen this-screen)
		(select-screen mh-screen))))

It suddenly stopped working in b26 but had worked on all betas up to
now.  (Yeah, I need to update "screen" to "frame".)   I don't see why
this fails with "attempt to delete last visible or iconic frame".  A
timing problem perhaps?

My fix was to do the select-screen, sit-for 0.5, then delete-screen.

Ray

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 13:24:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA03354 for xemacs-beta-people; Wed, 19 Jun 1996 13:24:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA03351 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 13:24:58 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA07486 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 13:24:54 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id LAA01994; Wed, 19 Jun 1996 11:26:56 -0700
Date: Wed, 19 Jun 1996 11:26:56 -0700
Message-Id: <199606191826.LAA01994@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: xemacs-beta@xemacs.org
Subject: 19.14b26 on SunOS 4.1.3_U1
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.48)
Content-Type: text/plain; charset=US-ASCII

It's up and running on my 4.1.3_U1 system with the following config:
	./configure  --site-libraries=/local/lib
	--site-includes=/local/include --with-xpm --with-xface
	--with-sound=native --with-gif --with-jpeg --with-png
	--prefix=/local/beta --dynamic

The only problem I have seen so far is one I reported earlier, it
sometimes doesn't update the display.  For example, I just did the
folowing:
	start VM from the toolbar
	iconify the windows
	once it is up, minimize vm, and bring up the scratch frame
	the frame will have a toolbar and scroolbar, but no modelines or text.
If I try and open a file (C-x C-f), it will accept my input, but won't
display the characters.  However, once I aborted with C-g, everything
appears to be working fine.

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 13:37:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA03408 for xemacs-beta-people; Wed, 19 Jun 1996 13:37:29 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA03405 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 13:37:28 -0500 (CDT)
Received: from gcm.com (gcm.com [146.121.48.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA07489 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 13:37:23 -0500 (CDT)
Received: (from uucp@localhost) by gcm.com (8.6.9/8.6.9) with UUCP id NAA28710 for xemacs-beta@xemacs.org; Wed, 19 Jun 1996 13:43:43 -0400
Received: from mis_bo9.it.gcm.com by gcm.com (4.1/GCM-2.0m)
	id AA16098; Wed, 19 Jun 96 13:39:05 EDT
Received: by mis_bo9.it.gcm.com (4.1/SMI-4.1)
	id AA27400; Wed, 19 Jun 96 13:39:05 EDT
Sender: dcw@gcm.com
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: How do I quantify XEmacs?
From: David Worenklein <dcw@gcm.com>
Date: 19 Jun 1996 13:39:03 -0400
Message-Id: <amk9x38zif.fsf@gcm.com>
Lines: 15
X-Mailer: Gnus v5.2.19/XEmacs 19.13

19.14b25 was really slow so I tried to quantify it.  I cd'ed to src
and used "make quantmacs", which made an undumped quantified emacs.  I
then moved quantmacs to temacs and used "make".  (Anyone want quantify
results for dumping xemacs?) The resulting xemacs crashes dbx, so
something's very wrong, but I was wondering why there was no way to
dump a quantified temacs, like a "make quantdump".  Am I doing
something wrong, or do I just have libraries that are out of date (or
some other stupidity).
--
 David C. Worenklein                                       GREENWICH   CAPITAL
 Operations Support                                        M a r k e t s,  Inc
 =============================================================================
 phone: 203-625-2945                                                      ====
 fax:   203-629-2535                                                      ====
 e-mail: dcw@gcm.com                                                      ====

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 13:48:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA03474 for xemacs-beta-people; Wed, 19 Jun 1996 13:48:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA03471 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 13:48:07 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA07520 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 13:48:02 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA04289; Wed, 19 Jun 1996 13:47:37 -0500 (CDT)
Message-Id: <199606191847.NAA04289@charles.cs.uiuc.edu>
To: David Worenklein <dcw@gcm.com>
cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: How do I quantify XEmacs? 
In-reply-to: Your message of "19 Jun 1996 13:39:03 EDT."
             <amk9x38zif.fsf@gcm.com> 
Date: Wed, 19 Jun 1996 13:47:36 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    David> 19.14b25 was really slow so I tried to quantify it.  I
    David> cd'ed to src and used "make quantmacs", which made an
    David> undumped quantified emacs.  I then moved quantmacs to
    David> temacs and used "make".  (Anyone want quantify results for
    David> dumping xemacs?) The resulting xemacs crashes dbx, so
    David> something's very wrong, but I was wondering why there was
    David> no way to dump a quantified temacs, like a "make
    David> quantdump".  Am I doing something wrong, or do I just have
    David> libraries that are out of date (or some other stupidity).

You simply can't dump Quantified and Purified images.  Run the image
like so:  'quantmacs -batch -l loadup.el run-temacs -q'.

Before you go through the trouble, are you compiling with all
debugging and error-checking off?  If not try that first.  Be warned
that while Quantify is directly responsible for quite a few
optimizations which have been made to XEmacs, doing a run which
generates results which can be acted upon is not necessarily a trivial
task.

Also, if you're still willing to do some runs make sure you configure
with the --quantify flag.  That will keep Quantify from starting to
record data until after the loadup is completed and will shut off
recording right before it shuts down (which generates enough bogus
data to throw most results off).  It also enables three additional
elisp commands:  quantify-start-recording-data,
quantify-stop-recording-data and quantify-clear data.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 13:49:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA03483 for xemacs-beta-people; Wed, 19 Jun 1996 13:49:32 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA03480 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 13:49:31 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA04063 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 13:49:30 -0500 (CDT)
Message-Id: <199606191849.NAA04063@a.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA094420169; Wed, 19 Jun 1996 19:49:29 +0100
Date: Wed, 19 Jun 1996 19:49:29 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@cs.uiuc.edu
Subject: 19.14b26 OK on hpux 10.10
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



Configured for `hppa1.1-hp-hpux10.10'.

  Where should the build process find the source code?    /home/cognot/APPS/src/xemacs-19.14-b26
  What installation prefix should install use?            /home/cognot/APPS/tmp
  What operating system and machine description files should XEmacs use?
        `s/hpux10shr.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              cc -Ae +O3 +Onoinline
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/include/X11R5
  Where do we find X Windows libraries?                   /usr/lib/X11R5 -L/usr/lib/X11R4
  Additional header files:                                /home/cognot/APPS/include
  Additional libraries:                                   /home/cognot/APPS/lib/hp700
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.

So far, so good.

One comment: apparently, the optimizer tries to inline a lot of stuff
in lstream.c while using +O3, so I've turned that optimization off. I
can provide the list of inlined routines if needed. At least one of
them is not inlined properly...

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 14:14:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA03556 for xemacs-beta-people; Wed, 19 Jun 1996 14:14:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA03553 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 14:14:58 -0500 (CDT)
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA07558 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 14:14:55 -0500 (CDT)
Received: from hpcobr30.cup.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA187241688; Wed, 19 Jun 1996 12:14:49 -0700
Message-Id: <199606191914.AA187241688@relay.hp.com>
Received: by hpcobr30.cup.hp.com
	(1.39.111.2/16.2) id AA059141688; Wed, 19 Jun 1996 12:14:48 -0700
Date: Wed, 19 Jun 1996 12:14:48 -0700
From: Patrick MacRoberts <macro@hpcobr30.cup.hp.com>
To: xemacs-beta@xemacs.org
Subject: b26 Success HP-UX 10.01, HP CC

Configured for `hppa1.1-hp-hpux10'.

  Where should the build process find the source code?    /usr/local/lib/xemacs-19.14-b26
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/hpux10shr.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              cc -Ae +O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 14:21:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA03584 for xemacs-beta-people; Wed, 19 Jun 1996 14:21:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA03581 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 14:21:42 -0500 (CDT)
Received: from GS213.SP.CS.CMU.EDU (GS213.SP.CS.CMU.EDU [128.2.209.183]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA07561 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 14:21:40 -0500 (CDT)
Received: by GS213.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA14601; Wed, 19 Jun 1996 15:21:40 -0400
Date: Wed, 19 Jun 1996 15:21:40 -0400
Message-Id: <9606191921.AA14601@GS213.SP.CS.CMU.EDU>
From: Darrell Kindred <dkindred+@cmu.edu>
To: xemacs-beta@xemacs.org
Subject: minor speed patch

Not a big deal if this doesn't make it into 19.14.

The problem: 

   Make two windows in an xemacs frame, put a different buffer in
   each, and in one buffer do (set-buffer-menubar (cdr default-menubar)).
   Put point in one window and move the mouse around over the other
   window.  CPU usage will be high, mainly because of repeated 
   calls to set_frame_menubar (which causes lots of where-is lookups).
   
The patch below eliminates this overhead in the case when
mode-motion-handler is nil.  A deeper fix would be to not
mark the menubar as changed unless a new window is selected.
At the moment, doing set-buffer to a buffer with a different
menubar triggers MARK_MENUBAR_CHANGED, even if its window never 
gets selected.

- Darrell

*** lisp/prim/mouse.el.orig	Thu Jun  6 20:20:32 1996
--- lisp/prim/mouse.el	Wed Jun 19 14:27:29 1996
***************
*** 1332,1338 ****
            (last-help-echo-object
  	   (clear-help-echo)))
      (if mouse-grabbed-buffer (setq buffer mouse-grabbed-buffer))
!     (if buffer
  	(save-window-excursion
  	  (set-buffer buffer)
  	  (run-hook-with-args 'mode-motion-hook event)
--- 1332,1338 ----
            (last-help-echo-object
  	   (clear-help-echo)))
      (if mouse-grabbed-buffer (setq buffer mouse-grabbed-buffer))
!     (if (and buffer (symbol-value-in-buffer 'mode-motion-hook buffer nil))
  	(save-window-excursion
  	  (set-buffer buffer)
  	  (run-hook-with-args 'mode-motion-hook event)

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 14:22:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA03598 for xemacs-beta-people; Wed, 19 Jun 1996 14:22:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA03595 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 14:22:41 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA07564 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 14:22:38 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id NAA28917; Wed, 19 Jun 1996 13:22:41 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id NAA01044; Wed, 19 Jun 1996 13:22:39 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id NAA09954; Wed, 19 Jun 1996 13:22:22 -0600
Date: Wed, 19 Jun 1996 13:22:22 -0600
Message-Id: <199606191922.NAA09954@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: 19.14b26: dired, font-lock, options
Reply-To: turner@lanl.gov

Since I had problems building because of loaddefs-eos.el thing, I
decided to grab the Solaris 2.4 binary.

With Chuck's help, succeeded several betas ago in getting
highlighting of dired buffers via

(add-hook 'dired-load-hook '(lambda () (require 'dired-xemacs-highlight)) t)

But I've noticed that marking and deleting files wasn't using the
dired-face-marked and dired-face-deleted faces, so tried messing
around with that a little.

Thought maybe I needed to "turn up" the level of highlighting.
Unfortunately, choosing Options -> Syntax Highlighing -> More yielded: 

Signalling: (wrong-type-argument symbolp (dired-font-lock-keywords))
  boundp((dired-font-lock-keywords))
  #<compiled-function (from "font-lock.elc") (n) "...(18)" [n intern-soft boundp] 2>((dired-font-lock-keywords))
  font-lock-set-defaults-1(t)
  font-lock-set-defaults(t)
  #<compiled-function (from "font-lock.elc") (buffer) "...(13)" [buffer font-lock-mode 0 font-lock-set-defaults t] 2>(#<buffer "dired">)
  mapcar(#<compiled-function (from "font-lock.elc") (buffer) "...(13)" [buffer font-lock-mode 0 font-lock-set-defaults t] 2> (#<buffer "dired-xemacs-highlight.el"> #<buffer "b26.txt"> #<buffer "*Edit Faces*"> #<buffer " *Minibuf-0*"> #<buffer "dired"> #<buffer "lisp"> #<buffer "xemacs-19.14-b26"> #<buffer "contrib"> #<buffer "xemacs-19.14"> #<buffer "turner"> #<buffer "*scratch*"> #<buffer " *Echo Area*"> #<buffer " *pixmap conversion*"> #<buffer " *Message-Log*"> #<buffer " xpm-button">))
  font-lock-recompute-variables()
  (if (and (integerp font-lock-maximum-decoration) (= 2 font-lock-maximum-decoration)) nil (setq font-lock-maximum-decoration 2) (font-lock-recompute-variables))
)
  eval((if (and (integerp font-lock-maximum-decoration) (= 2 font-lock-maximum-decoration)) nil (setq font-lock-maximum-decoration 2) (font-lock-recompute-variables)))

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 13:54:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA03491 for xemacs-beta-people; Wed, 19 Jun 1996 13:54:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA03488 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 13:54:45 -0500 (CDT)
Received: from ns1.eds.com (ns1.eds.com [192.85.154.78]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA07549 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 13:54:36 -0500 (CDT)
Received: by ns1.eds.com (hello)
	id OAA28352; Wed, 19 Jun 1996 14:54:41 -0400
Received: from kocrsw12.delcoelect.com (kocrsw12.delcoelect.com [144.250.106.18]) by kocrsv04.delcoelect.com (8.7.5/8.7.3) with SMTP id NAA10602 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 13:54:40 -0500 (EST)
Received: from kocrsw12 by kocrsw12.delcoelect.com (SMI-8.6/SMI-SVR4)
	id NAA12063; Wed, 19 Jun 1996 13:54:38 -0500
X-Mailer: exmh version 1.6.6 3/24/96
To: xemacs-beta@xemacs.org
Subject: b26 scrollbar placement problem
X-Face: 4tk3bJx]I+QTZ|=]*1+Z){9+;5u_hK*NBeZK6[+B+iB%bVuOJ%^uK~fIG}O-}%WLX*D^aW>
 Gv8E3Xtz0\N&fQl^:pj<K{xM`:d>pPt:9lF-YXB%O)?@rd?*/jE!s94`?]:jJ#C5RDP:;Mr.3lwo`0
 {vIT+<{%IRwe]vLd]7>\X|*z{TUX_t;?TPcOLBMIv8_V92!Vk(*DJVU~0M[`5D^PAWLniO1?YYWArM
 U*j9o+>?1MWi.lO?F-?aVt:qQ8OaG?R}B:I!7S_+KuzxZ.f9M@$z#n\bG2$Q2{od
Mime-Version: 1.0
Content-Type: multipart/mixed ;
	boundary="===_0_Wed_Jun_19_13:36:57_EST_1996"
Date: Wed, 19 Jun 1996 13:54:37 -0500
Message-ID: <12061.835210477@kocrsw12>
From: Mike Scheidler <c23mts@eng.delcoelect.com>

This is a multipart MIME message.

--===_0_Wed_Jun_19_13:36:57_EST_1996
Content-Type: text/plain

Here's a wierd one that I haven't seen thusfar in any of the 19.14 betas.
We must be getting close to a release.  :-)

The short description of the problem is that the scrollbar is overlapping
the menubar and toolbar instead of sitting beside the buffer area as it
should.  Instead of writing a thousand words, I'm attaching a GIF screen
shot.

I don't recall the sequence of events that led to this messed-up display,
but I believe it had something to do with having a split frame (I was using
GNUS), switching between the GNUS frame and the main frame, killing the
main frame, then quitting GNUS.  I'll see if I can come up with a formula
to reproduce this and let you all know if I do.

--
Mike Scheidler                     INTERNET:  c23mts@eng.delcoelect.com
Software Development Tools         UUCP:      deaes!c23mts
Delco Electronics Corporation      PHONE:     (317) 451-0319
Kokomo, IN 46904-9005              GMNET:     8-322-0319

--===_0_Wed_Jun_19_13:36:57_EST_1996
Content-Type: image/gif
Content-Description: screen1.gif
Content-Transfer-Encoding: x-uuencode

begin 644 screen1.gif
M1TE&.#=A20(- X0  $ .(+-'68 <0/___SY.4P   'V=I^;FYK^_OW-S<VB#
MBTU-3>7EY69F9KZ^OIF9F?_:N?\  /__    _P"+                    
M                         "P     20(- P %_B @CF1IGFBJKFSKOG L
MSW1MWWBN[WSO_\!@+D L&H]( '+);#J?T*AT2JU:K]BL=LOM>K_@L'A,]BJQ
MHD!-+6R[W_"X?$ZOV^]X&9NVS_O_@(&"@X2%AH<E>VQ69V6.CY"1DI.4E9:7
MF)&-4YM2G5%*(XM4:9FFIZBIJJNLK:Y&I9R?3[&>H6FE KJ[O+VYO<#!PL/$
MQ<;'R,G*R\S-SL_0T=+3U-76U]C9Q;_'W,;>V[>W1,G@VN?HZ>KK[.WN[_#Q
M\>;#],+VP;CZY,CX\O\  \8;,& 7P8.Z$ HC>(RAPX("(TJ<R,R?KS/E, IP
M D"7OG$!,O*C2+*DR64*_@4<9*B293"7PV"V/$FS)D"+O'#N^A7RGD=QHT3V
MM$FTJ+65!B$^3%G095.6"I$F5/H4*L*'+64:W<JUHL9N7[]I' JLHX"/03<V
M,:NSJ]NN5J?*C:MR9L*L4YLFG:OTKMR9#OV^'4RX;-AP(W7!NLB/K*^?BGC6
M@^RXL.6M6N/2?<JW+M.HH/]J#GVY=->V9P\/-;MS[.34D5W[A%W9M&V34NUB
M!2RZLU70OTDO70GQMO&3]&J#6\VX9VV/D$5)GHWZN/5WFSD#)EYWNW?=G#-3
MS5K\NOF)J)?O;*[X-5J>*BB?GR\O>V>[]['N'NW7?F#\] 783GJJD<#>1NX!
M_D5@8@(V>$YNY&D'TW[A425<5<7Q!Z&#'&:SX'/YR)9/=/N :!B#'::HXHHL
MGO.A4.U1I^!AQ%37XHTXYGCCB_V,%1]LTM%8CY Z%FGDD1SR"!:*0\;&Y#U$
M(BGEE%1>IJ183X;HI!Z(=.GEEV"&*>:8*?3A@IDMH,F"FF2VZ>:;<,8IYYQ#
MJ$' G7CFJ6<!?/;IYY^ !BKHH(06:NBAB":JZ**,-NKHHY!&*NFDE%9JZ:68
M9JKII@6<H8^>H.)IP &DEFKJJ:BFJNJJK+;JZJNPQBKKK+36:NNMN.:JZZZ\
M]NKKK\ &*^RPG<9V)P+((FM LLJ..NRST$8K[;34_E9K[;789JOMMJ@F4&R0
MQR9K@ $$,#LNL^BFJ^ZZ[+;K[KOPQBOOO/36:^^]^.:K[[[\]NOOOP '+/# 
M!#.;@+<SAJNL N6*NVS!$$<L\<045VSQQ1AGK/'&$Q_\[:<-(S NPR&?R_')
M**>L\LHLM^SRRQA[G'#)"M0<KLDPYZSSSCSW[///0*\KL[$-CUPSP\T&K?32
M3#?M]--0)SLTN.4:??2Q)B^P +):UZOUUUTC$':\88/]-==;BYWVO&:/S6S9
M:\OK]L1@VSNWP&W'S>[99_^;M]YD Q[UX"N[???;@JL[-<@B'^UXU0_#[;7@
MA^^=]N&2TULYXFAW#N_F_GC#G3CGGA<\=M^6EQYZOJ 3[GK&AH^N=KR+WW+G
MN*'>_C#I;,LN]^6^MZZN\'<+K[;Q_<;^+O+^*M]NY@,S/[SOKU=/L?/K(E\[
M&[?GKKOGIZ.>/>7 'X^NV:HG"WW=SX^._NSO[\TUY\K/S7[JYY<?/M]QB]^U
M_^*;'NG"=[SWW>]_P#->\1;8O[7=SWH0C!CV#J@_P6U/! I;5];*-[L.CD^ 
MYD,= CF8/_"1$(3I&J$)ET="_JD/@2_<&N@6B#89.O"&+_0@_Q+H0102<(4=
MS!SZ7.@N^]F0?C@,(?4BR$36-1"(HNLALBX( -V-ZXI8W" 49=>V'.JPA0D4
M_B$'H3<] R:1C!_\HA=_B#P:JO&-;#SC$@LXP3':4772JV/IA#C')OKQ7G_;
MXA[U1D4K9A%W6@QB_% X0#FND7PF?& *(2G(]C7RD5XL8!$!MSXP#O*3-0Q>
M$N%H1_8948%/!*(B8]C'/[J2A8TTI2<-AC"B6>UQ!$@D&O%70E)B<I*JW*0/
M[]B^+OHR?0'LY255V4E0QM"2OURE-'F'..KI\9C/?*4V\>4\-_Y0:K6DVBVO
MELO($1.6P,3F+J791DJR4Y3+G*8;>?E&><[RFYED9#/?F<Y^TC..T<SG-@<:
MN'A&<VZ%+*?CR*E+'LZ0DM]4H12W>$1Z(O&.B:,A_A&5^,S6]4V,%86?&B/J
M4"[>L*3$)&+L0FI1&.8PCBPEJ$RA&<EWQA0!"1VGS<K)S&0J,Y[U.^%!?5K-
M![H4GS_MW"(7J<G/!9"I9 1@)B4YR:4>%8Q(I2HC:UA5WFEUIF"EYO[DZ-.<
M&F"A.\596"7HSNBU<JUPC6O+0&=6M)),K7)=G3_UFM>^^O5E= TGR'1ZU]W]
MU6]MY>MA%\M8C 7V8[93*%J_U]C*6O:RF!6:8"-+6,IF]K.@#6U<ZSI9GHKV
MM*A-;1-)NU#='>RUL(VM;&=+V]K:]K:XS:UN=\O;WOKVM\ -KG"'2]SB&O>X
MR$VN<I?+W.9NEGN2;6TY_IU+W>I:][K8S:YVM\O=[GKWN]J%+'0[6TY.F?>\
MZ$VO>M?+WO:Z][WPC6][9T;><3'@OOC-KW[WR]_^^E>_Z_JO@ =,X (;^,  
M5A>"%\S@_P:XP09^,(0G3.$*6_C"&,ZPAC=\8070]ZREM>^!&\#A!D@XPR3>
M<(HU;&(%J[C$)X:QBUG,X1K;^,8XSC&"5XQB#]L2Q-+%J[L:D.)_$?G!1BZR
MOXA\WR0C><E*[M>173RP*:>KR5#&LFH)RF0&)-G'X@0R+H7<KBX[F<I9]G*:
MSWQE-4LYRORR,KJT## Y,XO.^S+SEKD,YSPW ,R#%3-##?LN/;_YR6_&L[X,
M_AWG%K<YR8K.EYV3%>E&([K1E=YS$QGM9T!S5M!I)?20^[QH1\_9S9A&M9\S
M;:])(XO5]>)TJ2^-+C[AR]4(@#6]9*UI/_+ZUG_^L%T]"Z]?WPO7NIZ7L5M-
M:DF;^LZJ+G6RY87L:".K  XH +!I+6UK]YJ)RXYUL'\\;-/&*]R[?C:EO7WL
M9@,[V;8NM+I?'>UX7[M/\I[VN>>=:VMC.]O;1G.BV?UMZZ$; =HN]KC#7&XR
ML^O@U.:WOA6.YT'M6]<%N&_"RRSQ>F\<X0G_N+J,;>]DB1Q=U4[7O[-MJ(=W
M'-($+_CKPOTG>7MZO* N;,TY7O%%H?SE:V96 8A#_I"2NUS1@&( GY2^<V:E
M7.@@-WG(1QWI!UB] %;/^@-,/G*@F]P!8 ^[V,<.=J,CZ^D#E[DK:>XGFPL[
MQ 98B=F=WF>L/R#C_K6[R-%^;WRGN^)$'P#63YXN3MO]ZOL]_-U_3FMMV[OI
MZ^+U XI.'*M?N^N77CG9-R_VD_-]U3%7^^"6':A1WQR#T1USW \R^*.K6N__
MU3OC!1[U>__]]8+W4^[G3O>*9YU0OY_]H[EN^]HCO.\_;[*MES_TY@\]]W>/
M=[SYKGG.6W_O7F\7H9(?>M%#C>U^Y_CIJYCZ0<O]ZI&O.^+S'GWAGUKJM2:\
MU#=N^,"SGNJOU[K^][]X_KIG?N>/5WR]IV93=W>Y)W@$L7C]-W6?5WW6MWD?
MAW:$PGH4*'@#Z'V;YF[SQWMT-WZZTW"K5W1M5WCJ=W>QAW[^)W"$)W]+QW1G
M5W>[]WSWQW/YQW\VB'V()G+,1WR.QWV7=WS/%X0)*'L@9VN?AW!A=RB=EX+#
MUR<4Z(3-AX (:'<O.'$8J#0')W\DZ('E%VKV1WB&MW[]183)(H$Z:'0M6'+U
M9W\62(.U9H,WZ'[01GSP!WD_6(5NAF]"*(52.'5EF'U?QW*&DH1,^'Y(&(2(
M>(!\<H""9WD0=X5+\X@*QX7U%8+$ 88EB'=CB()_^'\;N'%VB !KR'J"DGZ^
M_@>'^X>#M&<O$1AE(3=Y?5B!?JAM1WAM *=]*]>*#\8GV99M;/B+6">*&@B)
M3T-ZH;B%;Q=DEBAW77>*FLA?9/B"C3>"11A^) AXB\B'<H>)IXB*6J>*PZ=]
MXOB'6O:*NZ>(BRA]"5>+ L@NN5B(T/9OV.9\AJ*(5B>)Q/@S) <H;D=N</>%
MS5B#SYAXG"B-J^B.;>AZM7:)@==Z/BATJ;A]\+AN[J*%=RB,5?>+"8AY!TDO
M[]B)+L:+\ZB1;(AU^)B//0-^'/B'E)ASN@.0URB0A5*0PCB-X<>/IHA[<A>#
M](A]W?A[7PB.ANB.XTB.U@:+O[AU),AM'DF((-EF_KS8BU$XE>G(DXUXDBBY
M,RIID2_8DB (DP]I<MZH?T(YA_#7=X]'C4:YD#M9DF%Y;:GXA?UGD.&H+A;I
M>476=KHG@C+H=],'B$WIE'1Y:O,HE927C3N9CLV'E5F9,UO9CPSWCPT9D&\X
MEL$WD?1VEO,7?QK7BH"7F$[(C!<(D63)DSWYE$.I<N*F?#\HA'LX=(O'@( I
M=(,HF#49DE$YDG_2ASVYF,/8F$'SF*:7C*H'EJ,IEM$'?',YF&9Y?*IIEWCW
MESVWFVYYG'!9FL"(FLWYG+3)>WKV<7O(B+")EK=9E^GR@!"(F?UVB(89@U^H
MB(P)G"XCG.)'G.8WF3%9_ID%0&3\263129-F&'^X2'^_*8/XN9:D^8WN>8G:
M29%VJ7*@2)G%YYI1B(!*J8L=B0#H279&]W2YZ8O4J7N $I_RR3+TZ7)>*9E$
MQXT"V9_\^9_+69ZIF9:W5Y&F&81OB7!QF9W,Z:!<MX)<:6:S>)B49Z$]>'RU
MN*&=9W8>*I6^B(Z*>(Z"1Z(EJC(GFGXIJHS&B:#(N9\NV@ P6I8^BI9<*:$(
M69U<>IT*RJ,RNIW&)Z!N.(*A&:*@N(ZSJ:1E)W]F6'8@>HXB2H]46J4H<Z5=
MEZ7%>:#6"9=>ZJ)A*H=C"GHVBJ9X6)D**BA%UZ"9V9TGMY(8Z6\DJ92.FJGQ
M_H<H+I>#[$F/4PB%?7*/ORFH6EF@:HFE]AEJ%I>?$$JJZFF%^!>I6VIX@:*1
M!#J-Z\*IO*9X<,B1YEF-A3)JF0=R?3HH^Q>HKKHQQGB,'3BKA:5LK:JM3/EN
M,6>@*YJC=@FLF+J>\1* MEIK[=:M?F:3@&*9#R"MTYHQ^UAZ*(JMQ)9OW1=Q
M[,ILL-9RB3JN;,J.PVJ- 6NP^]:OSL:4\*IU:3JO^KBM$6>H@Z:MNLIQ"ENC
M03>@$MFFC]IM;)::(>NFR7*L;@BQP2FQ^T:QH6:Q^YJP&=IN%ZN04):Q+CNR
M'WMH,>NO+XNR5JJRDXBOYD9Q/2MO-AMQ,YN3."NJ_JFVM.8:, 3+LSX+-/+:
ME4+K<$I;LSN[FD6[JUJ;K,Z6M,@JLE]+MF';M5-+K4 +F8$&@C=;MB1[MC#G
MM&*;KI:VM0$'MMZ:MCY3M<+(LH7UI8+KHO<UN(9[N/SY8(B[N();N(S[N%T&
MN9"KN)++N(Y;N8A+N9C[N)J[N8-[N9X;NJ([NJ1;NJ9[NJ8+NJ8+N+J#N0R 
MNHFK8+#+9+-+8K4;8+7[NK.+N[4;NU>6N[T;O,([O,1;O(BKN[#+NEUH5\S;
MO,[[O- ;O=([O=1;O=9[O=B;O=J[O=S;O=[[O> ;ON([ON1;OM1[M3EGONJ[
MONS;ON[[OO ;O_([O_1;_K_JB[[VF[_ZN[_\V[_^^[\ ',#VB[\U P$%+, (
MG, *O, ,W, ._,!H1< *8, 3#,%'0\'=B\%HI<'4"P$>;%<<K+XA#+XC[#@C
M[,$E[+TI;,(KW+P?;,(LW,+M*\,67,/L*\$43,,!K,/1F\(\O% Y;+\_;+TM
M[,-"C+TZ/,3DJ\0VW,3?2\ HC,+R:\ O7,%5/,%7_,%!?, %G,5>7,',2\48
M/,8NS,5=K,%2?,%5+,;5&\5C_,5OO,)NK,9D?,5FC,5H;,<]O,98#,1 K,<;
M_,<AG,>$3,1\#,?.F\9G_+R*S,9.[,0X?,?O^\(YO,5D#,:4?,%FO,68W,4N
M_FS)FAS&D@S&I,S)E3S*T(O&H7S*I<S(,,S%F?S*K3S+;:S&L!S%F_S)BCS*
ME]S)J%S&MPS+GBS*POS+LQS+CUS#4&S,ZWO)@[S*T%S,LFS*P'S,NOS,O!S-
MI#R])4S-V^S*()S+TZS-2!S*VZS*S/S-V2S.3.S'UFS,V*S.YNS-R6S!^.O&
M[<R]SAS(TNS-@XS+M,S/[QS.DES([&S.W"S(]+S+Q$S']+S) (W'Y2S.=]S+
M#2W+\QS1#+W'R/S0&\S'\*S-^5S/ ^R/RBC-\;O/[NS++,W)"$W1 JW*1ES0
M!*W2\@S.![W.U3S0'&S1 MW!\XS1/OW3+QW01(W3_OY<U#6MU#E]TR2=P,OL
MU,T,RBMMR5;=U%<=QBX-R$$]SOT,TUPMU-'<T3A]S"Y-RP\=UEY]SFM]T47=
MRVDMQR(=S WMT5YMT6K]U/L;U2.]O8XLS[NLQ;8<QS',PD[]UTQ]QO$LT73<
MU</,R''\QJ6<UX\-T(A=T5[<TS0,UQC-V(E,T$*=V7\,V63MR7(LVHD,TN?<
MUWJ]OA*<OZP-V[+]O;'=S*V]TK>=V_S[VD=<PU0LQ+$]U/Y+V4U,W+I]W.W+
MV_5;V_/+W/J[T<@=W=(]W>=KTJI'W=B=W=J]W=S=O9$LU=T=WN(]WN3=Q-_M
MW.6=WNJ]WNS]Q-8]:.3<_M[R/=_T7=_>"\5S;-_ZO=_\W=]'<][^'> "/N#D
MS=<$?N (GN#'?<_YK> ._N 0WL &'N$47N$6KK\3?N$:ON$<3KX9WN$@'N(B
M/KW*/>(F?N(H7C,EGN(LWN(7ON(N'N,RCN P/N,V?N/Z#> XON,\OMXZGKWH
M#=I^;=P]7N0N_N,3;;[.'>1&WN00CM\1/=H&S=*>K=6<C<>9C-J+C-N!?<A,
M[N1@7MY([L>_;<WH?-ASC="Q;-,]W=7.?-9A'N<T_MZAAM*!7.:O;,?"3=%X
M7M&?C>8P_=5R/NAS'IDGC<]EC.>6K=G0K=AGKN8@G,8SC>61'>B$?NG\_>%W
M_M[2!_SH.ZW);?[6\=W66(WIIM[?FD[FG+[J@,[J;%W5@7[E;'[JM&[?J0[#
MBB[I&5W$JJW9J*S1>CSE6&[IM5[L8D[GA67LRK[L]5OCS/[LT.[>AG[=T5[M
MUB[M;0MWU[[MW'Z]8][MX-[MW^Z^#'W"A=W8_'W:,JS$[?SE/9S!SQWJ6SZ^
M[E[@R/Z!=D[ND/[NN&W?ZY[*1)SD*0WOO0WP2ZSA4-[H(OS1C1SL1VW84X[8
M"C_OG@W77G[N0S[9B]WP'/_96E[Q?-[IO%['>2S5C;S*P"[L)P_1_X[Q:O[Q
M'+W&,+_?XS[#0B[J_:[J_DS5K9[4@K[FB2V]K.S3_E?NY_#,\TE]YD-?S4N/
MR9.>UG>=YK-NY7H>TVD.U&X>]/)]ZY,L[YVMSG)=YC;MV$<]]6-/[([.]+%.
M]DJO]N[\S[!NU,0\]>",UU$/S'3OUCI]]K6<]>G<W@P>Y<W]]6#_\*"^ZO\\
M\1Q_R X-YPV>Y)5<[HT?V@IO\<ALRW=O\KHNZ%0/UFO=Y8R?]G^>\Y%-V 'O
M]^ -^/<N67"N[T9/^H;?Z8@?^W,?SD.]V'X]ZF0OU@8_^ZJ.^D]?ZG7M^;O/
MZHJ>T&4?].R>^?6>VUS/OG:?_#F/Z[Y/ZLS/^U2.]LA?VH[]Z'O>Q]6/],-\
M^7&OTF%M_MXO]?NN_;]N_O6<#_ZCS].&7=_/#_W![O4Z;?L:K]037^62C_$@
M "DCJ4!GF:HKB8KC^9:RB:9V3:LBGLMQ*PCCP6JL%M D-.IN2:8327OZ9L[F
M;M6<]JC&(U(ZZWW!YC,ZK5ZK 0$ _ T@$ R&%=W.WO/[_C]@H. @8>&-(6*B
M8A_6HN.CHQN<Y%S=G4K>)>0F9Z?G)V@CZ"AI6.DI:@HE92:>92ILK.RLH"CM
M+6ZN[LBJ7"OFZZ[P,'&Q\3%R,DDOW&^*LW*T]#1UM;4T<Z4>\/:U]S=XN/BX
M7S8TR3FY^CI[NWNN>?"S_'N]_3U^_E]\=TFZ/L"  @>2XZ?)'SV""A<R;+C+
M_J"K?@XG4JQH<1%$;@<O<NSH\2.+C/,D@BQI\J1"D0A)HFSI\J4ZE>@2PJQI
M\Z8RF2/^X>SI\R<LG0IX BUJ]*@BH421,FWJM(T<5C2'3L4U@-#5IUJWPHOJ
M:ZJS 6))9%6052S:$67))CI[9"T8N"7D<JUK-ZG79F"#E76K]F\*N70!]24<
M]R[BQ(:4\E51V*SCR&?0CC53N+):S%<QLR6KV>Q@Q:)''V'<#>YCP9*QSO7;
M&33@V) !5PY-^C9ITP<U4\[\.;"AM8]?#Y\M.[9MW,H1ZY:<>O5K0:BC&Q\N
M^+?QY=I%-Z^._'AV\"LHVYY^W#KUN=^WLT_<_3EM_NCB^UP_3QP\_/#M]S_M
M#AK]?[7U%F!RDT7&V7JST956@OPYV)1_#THXH3414G@AAL98F"&''=*RH8<A
MBC@*B".:>")&>6FST4Y5H?@BC("4&".--:8QHXTYZE@"CCOZ6&.//PJ)8I!#
M&AEBD4<JB6&22SKY8)-/2LE>E%-:B5N55VJI6)9;>EE7EU^*Z5288YII5)EG
MJME3FFNZ"5.;;\IY4IQSVNE1G7?J65&>>_K)4)]_"BI0H(,:BD^AARKJ3J*+
M.EJ0BO\L]2BE S5:*:;57)HIISE%NE<W+]@BY:C#E-II(OZ)REX,-HAR*A^P
MJD&&K+$>,<4AM[(P:JM;_N2ZQ)2J%M$>KJ$04FLM8!2;1B.\*FL&LCEVUVNS
MK0Z11*_7NFJM#Z)RFVVWVGJ+[;?EDGONMNB.FRX96031!0X\<*'$M6AP<>^[
M.N@++[T_% 'OLKMZ*T88J\;+K19:$%&ON+>:R^ZZ$3<<+L7@6ORPQ!5C//'%
MZLHB++VLCC'L$JX.:S+)]@KA[Q<9ESP$R0/W"RRT,K_<\JHTNVM%&2F''.RG
M+/V2,[$\_QPRRTDSLC/1 =\\\\E,SPJ%T4JGS.L3+-,<K8W-4;O?LOK>K+47
M9_@:]=4)Q[SVT12K[,*O5O_L;-R_^OSDM'>/X;'&?'<,,<<;]PWXX!G_[?*N
M_E77C7;;M9X-]=QJ(\WVXVLX33;;>AO]M,]8^RWXX8%_/CKAH1<N.N%!!<TB
M5=L0+3+GDZ.-<MO/,M[TYF/G3'OLMG>^,NXZVWVRV+GCO7I$E[R^7=B+([UP
M#GM0D36P6,S[P\+6M^O[T==G#K/ 64-_]_9';BHAUZ.D_\CZCIY?M.:Q:)W*
M_*B6AKQ&2I9]R_ZG]&^_*O W$M8!L( Q$>!*"&C !8+C?0Q\X"D<",$)?D*"
M%+P@)"R(P0VF"H$S80D'0_@0#[8(A"(\X8=(V#H%HK"%J="@"V-X(Q5.2H8V
MY 0,;ZC# $[B*T)ST0Z#B)<>ZN6')A0B$@N1PR3:_G")3(RA?QCDFR=2<0WO
MZ4QQJJC%%5PQ/K09$&SZPADI;I&#752/@6#CG366<8-G3,]XL"B?-KJ1AHT!
M3AH5-$<Z7O",KCG+@/(#1SY.T(\-PF-MY#@?0A8PBF-$D&,VXQGA0)*1"^Q3
M@2S91SL>$0U9U.0)XT1&4*+0B:2\)"=9^(Y,IH&5GCRE3QPI1MY4DA/D6<,M
M\2@=R[! -6C$92WW",L&IG(]^7%E</ZP(-;P,HZ_# 0KD3E,3Q%Q1<DSIB(5
M!,:QS+(UTI2F+G]IG<] DI*SY$UXS,F61_J2C=R<Y#2_\49L+A*0]-3/8?S0
MSC6FQC79*8YP,O-,XO@E_HL LB<;XTF->09HDN7)YB #$\A12I2,^Q3D? +J
MS 8M\YZK.>8A%1H-AN[S+1!=9#/I$TYW8F>@_PDG@#YZ4G%F$Y 4%6DR#*F?
MZS (H_A\I3Y7^DE_1E2C"1K,04UZ3Z+B=!HZ+6DO!<K/B&Z4#T;%XA_Q(]/H
M(#0T2;7/%\.:T*;FM)A3U*HG)7G6M;82C&GMZ7C4^E*T5C22GM%C5(]:SM94
M1ZXW):N&S*H(< +63XGZ9&$KU:B_)O91IFRLHAX+64/)TC*)5$\N<SG7L=95
MK^>TZ3NI.EDLF16QWS'/3FG*V?M,5397_>=H':33JJ8S/4;-:EY5B]2!"L@W
M_L&,[5T8FEN\#M6EIM7J:UTK4:D"ETJE50,Y80O32#*6N?A!;4,A$]KF;D>X
M^91D<L,K6N56];6;D2MWES/;K8+7N+HM*E=52][X$BB]HUFO+B^S4NGB]:<)
MO>TSL4M8^T)(L-7=K'8=:E[LE =!J'&P-[?K7P(S1[ 5/?!@-4MA\UEXPZ7L
ML(=%*-D0JVG$)#832:EZ8 R?^$HD92IK\]GB$C]WN?[E*83_\MM>[GC&'DHQ
M>H6YT<NV<KP^SA"0)ZS&E!XWLT?N6HW1V&,ENY,-+'[RA5*\9/:ZM<I6Q3*1
MHASCK<KXN$,&\XG>$T@53SFF;1TPFKL+XK=H.,Z&_IVSG>UGXCPO:<]\YG U
M)07$/RO6P+0DLE#9N8<K$UI"3Q4F@%>K5"HWVM%19NHRBWMAKQJYTK(5,UTQ
M"T?"FMG3E@XTJ"Z!XU'SDY)Q63-*30TE4*<VOR%%9JEES9]'[]?)7M0F8W.M
MZ_;PVKU>)#*N.SUL[53VNG!%CE^GW-EE,PG/U!Z4GZ\-HVQK.\RH-J(JNWTG
M;HM[1,VF,U'/V]-M,GC2#?ZL;T$+YW(3!+\T1>U%:^KN?=O6I?2FTZ4G#=9:
M+_4P#Z4M?Q7\[XYX%SH%[3?$)QSD/>9[X2YIN%UUG/#Y*ES&K^YUA"T.\&^S
M[A??U+AX(_[0:!H[UB*W_HB]6=O>B+=6XC;G.,[K^W**Q/RHM9WNKSE=3_H&
M>.<CCT,12RZ/%8^QKQ:==I/9#&^N=MGH?,(S>>:MSSHK6.M6-PFYOSYKDE]3
M['(*N]GW@_:T.Y?L^=MICY^]SHE*L>[P16G=Z2X@1K-]'5H^>(+E2W3<GCFW
M*7=YW^VAY1L+E>8@-2G@06[;JB?>[[0VLT8)3_0Q'RBE+:=TY1EU>=%&]_!P
M7W%:)>_;T =D\9ET"WHK+OC. S747F=]A48_]/C$WN'ZAGR9/X_CV^-^&'\/
MOL:%__O",Y_@H"\^I-P^P'BSE<<!G?IYVFWX5V/_GY2'ON6EGT#H<GT36;<^
M_M_!#RAKJQ_02+?FV]L/-/%_,-SR]]':[P^F@%/'HK\5NOYQ"?_-E^;M5P"2
M%OV5D*K=QU<!6R(I&CQ%H':='.(=X#U$$6QIFF4-W.,A6AX1GP7*DX5-AP8B
M'^?5G%=M4P6&X#M$2*1!5?-Y7P-2( BR8.XEX H%&*SUE[P=4D<]'BX]GPVR
M@PN^5]#1&0?^GK#9V!!:R@C*E_^MW$5!H*1Y7A,"1/X-UA4Z(0[6T#5,W!8B
M"ON!0PV&(3:,H1F:&QJF(9*L(1MV2!:^H4W$H1S"B1O689;=(1Y."!WN(4KT
MH1^"G1X&XJX-(B$2FR$>HIQUX: IXMB]GZ!UDB-^_AHC2N(DJIU@!8_<7*)[
M9"+EK(S#8(LCP,K_0$+[R \LG*+D[$S\0(LQ;$'QV(KQ+ TMA@/(R,WRL*(J
M<H_9E,(N#L0OSF+BR*(R!&,K_H$Q7L.T9,O7?(VNY,O>1"/!) [ 2$WY9$XI
M1L^_X,LT:B/##./S^$LU=B/U7&,H0F/!*$N\]$PY<J/;3,_!B&+4C.,Y;J,T
M?J,W=@X]"DPXHB,^B@] ^F,^PF,R;L(M@B+C@&/+?.+M.$Q#5DTNCHWP4,[N
M("3D!(_D:&)%_@Y%'N/BH(S-2,U"R@[O=(_BR$[:$,]#9B3X:.+62 &M] [P
MQ,U&7N3F),WR8 Y*%D/>_I"D13XC0T*.3 9E+-;/29[*X[AD0G[/1_YD_.@D
M3F;C0QJEVE0.4\:B3Z[B)E*D/!ZE4^:.]4RD\S!E5NKB5SY-1/)D,34C,X(+
M4)(DP@#D-49E3)(E6IIC4A+E-+IEPF!/5]XC6MJE.M(.1BI,23;.2][DMRCD
M5KJ-8>K.7PY/6'KD3E9FQ3#F6<9,7)IC5U2B\NAE[=A-8_(,4F8F2KZ*SJ!F
M4ZZD:1Z"4=I"45JDX\BF8)9E:B9F];#B37XELBBE,)JD2+HB1R+F\.3F4IZD
M0A)#3^*B1S9/61;F:@+G2%8E='KE5-*F98HF;^(F<T[-=?9,=$KD<*:D31KG
M_F%294>69_U@96 .8UT29WF29UJ>9FUV)B2FVG<*)69JICOF8W"6C3AB33\.
MYEWV)T'VXCUJ3^50#V7N#4;"32A&)(-*IRD,9+L<C'[BXV/:(SE>:''.#6="
MJ$P>:!1\HVK^(V?B B F0D%"4(M2R(HBPHLRT(R>VGV"FS[4J 'I*"7>J-)9
M(B<NHH^6G7JV9I"2B2<^YS&N#]>4"HG6C&BFJ'<>J1D<9'XFIRDRBVZN(B]2
MZ2,LH[6P)<)<03S63( FZ&9:96B"I8=VJ.<(I)=::9%R#WI")&LZYVU&*'O2
M9W;29(,&XG)BIY,B)U".9FCNZ:!N*51:SE!>HM>T_F68\J56BF5[^N>^O">E
MZDU2IJG*U*<C!NJ5[N>:5JIQ7N66GFI>OB4XUNDD@NJ<TFFF\NG\X"GY(&AQ
M+FIS<HZ4RJ&K^J8Z=F.AELR%^B6BVJKQ&*B4ZB3X.&HB>FDG>J:S\F&S1JM=
MQ"BU<N&0QM^U(B*T;BLF=JNWMEVV3E^XBJM4X&BY"NFY_JC]I6NU3JN[(H6U
MQFL]S"N]BAZXWNM]P:N^_H2]]NL!Y2O 5IC #NR[@JMOSF??\>C!CNOXY>=\
M6HRJ$J/T;,^)4BS#_F8AA*C&^@[B'$/&QJJQ&NO^["E'R*FO3NHBG.)D<BD;
M.$V6LD^G_FEX<L0NLJS+_@IBMXHI$#@C9NYC-K9C@N(FU?1E?^[ 8NYC%JRC
M2I[I7H(GTIJL@QK,T2YM:H[/D_JG\PBMFPXM7@KKY;#CUS+M@"IFV<K+R(2L
M<B9I=])-2VYML(YD=^J.0\8G8];DJ^#MO_2+WDZG2$JJ+O8M-=YF]@BJ6+:M
MX&+CVZYJ;8+DX28N?(;D\\R.VAJ?625LKL8.J^;IJ\;F4V+G6\[MWX)BX88J
MXXJL<V[NO8@C<:HI2]KFYX)F7]KMK1XNZ-:JJ<HNMJ[K-?&L"P"N=HYGT)(M
MYB+GB7ZL61+/_[2M$FAD9)XN9:;NF%IMK4+/8D:M*Q*KA+:ID@XN\E[M\MYN
M_N1RI_BVWN6"9J+F[H>Z"_,.9YT:JLIFZ.LJ3>EF:&F2)ZP>Y^!6[ZOF[+MP
M+I?BZIH2@<("<-RNYW_";9_F0Z\&9>B2;^QVKDH>9=ZR9OQ6IWB:3/;T[?U&
M#LF6KWA:0?T6[P,?)P+KKFO2[K$^+N76[@2W9TCNZC@T,.Q><)2^*3;R"U:*
MZ-)6K<+D,&P*Z\P4+CV2(J;^ZFE^K?)J<#CZ)6 FYX0^,8@JZ^P"ZX>6(MJF
MXPIK<:7RL R+P[]>HM3BJ\/6G\%^ ME4[BV$\2%*I>+QZQG7!,HZ,!JKCR*H
M\:C*WQS7L!1O;I=V3XI>ZJDFBVY*I2"OK_[M,?Q2_FK[[ NA(BVAUJ@C-RH[
MEJH-@FG/0FK0#NT4SRS6VFZSH.XZ)NO_-NKX/#(+*K*1CB^M:BDE'RJC3G"T
MM/(@X[&XT? B<^Y[SC*9"B<BGVXC]W*7?O']/6JD'K,A,\VE$C,L#[/TK/(?
MYW$HIR$N0W->PFPL#S+13FD!^_(O-[,95K/^*BKH\K*N[G M=G/^@FCP2K,M
M_YDXRR\Y _'+<NK(H$YODFT]!^0]OV,@OS.?L7$<*R,<#_3%%;1!_R%")[3.
MEK$",C17; KQ/5B![-9P22""030;Q&'3X=V" *#,*9M&\\@ VAT5(IA)3UWO
M#9UJ<%HEP=A(0T6W=N##_B6A6"5'I E<?V6<+Y5A'!<;IO$;#UKA]PT>]8W5
M.<7T'F"@2L=5.P'A19/>[ E>3BLU&C US<G'#!YU1GG>^3$?OEFU3#MT#AHU
MP87U$7H<0&&7OTE54*^@51>A-XW:7DE@D[';@W5<6T^@7J>?4@NT6*MEP08V
MFRPT84\$8!_V" VV8LNQ83?V0B0V9*_Q8T_V[OH0NUHV3DBV9L<"9W?V"U4V
M:#.P:(_V!9:V:=<K:J<V&?.NMK)V27PV;%?0:L]VP)*U,Q0O0$/6;BN'*H_S
M96+I,S."Q4YL-N<Q_[@M<M_Q& ="RW*"*LZF%5-H.D],O;&MX:XSBP+"<W^S
M_C?W]G&7<!U[0F_?+'?[+S)"LQCNK";_[O1J)]"&Z"B[XPG##&HJ+9E2K12+
M,'UCK7PW]V7B]Q5X+7O"8Y$6L3V;*-0:;Q>XI@_[8QHOJ/7.=]H^RVOZ-[*"
M=R#\MCQ73TZ:\DQ*, 77+0:;K0J;@DN.\ &_=Y1:L'7R[1)[+F$N[JR^+HP/
M, C3. O3;JKN\D:.+>&*N!];[LZB[P>[[\R&,'12<70JM^B.Y3R>^/=T</>Z
MK.BV;/N*JO$V;O-R.92_>+&J[Y,'[BBWKC93$VZ_@N_*"XOOIO#^MY*+N>W&
M^'<#3_CRI\'P[9U[<)W3.99>N8VGK+;,H@#?MY[/_F74(KH%IZITCKD(!SFQ
M:BHSJ^CY=F_Z5F9WNV=V-_J<=WCR>GJ<=[DZU_B1@SKNVBV6;[JN!CJ7UZ\S
MV^J2)_"6+W"7\Z^@=^S:%KFEE[KGXCC$OG!Z_K"4EVJ)[[J*0^]RIVZGDW#M
MX*0L!V>SA_KL%CNC0S+4'#%<*K#DOOC_ZK;("D,\=W,K/_C3\F>%F^U]D_L]
M1[C'PN3>.C&!XOKBEFWX<#*?H[L6*^@D>SB3I_!T"P\6BRUULW.O8X^O'WJ>
M1SJ*:KB,U/8),7Q#0/P9,C8?#;E36#S,.?P&N;%6</Q%R+9MXQ!VF^XU2+RI
MW#%(F/RSIGFH&#F4RBCW_C+IE!*R(7@!*2;YQJ:\BXU\_Z+W( 2Q'^#QC )X
M>->\1ZC\RKLVN:YYMP#]TTYZ)R>D&QL\?8NM@,*[AD*Y]G*H@GNJ@I/RTU>]
M@-N[?L>[3\8W-CL)AT?L]=YXDUHC*EMXHT,N:3*[UK<XI].LLR\WW:HGW8?Z
M80(^!W^[^RG]PWI[GYNZ-VOFE\M]P9-/VPNZQ([GO</WRZKW/)OYK;:]X#]O
MEJNSE!AS)B,SQX9P+0KQU#+J*2MKP/MY!Q?X;Q+]Z!(WZWL^LQ!O?4XH"7M\
MX6-VV2'^.H/^Q+(NX:?PXR-R8[Z^9,;^HV>S\#]CEA>_B OGYY_Y\>AZ](MJ
M_EJ"/9@7/P'[Z;#+C*,#.X4>K_=C_D<.?N,SY(P#\[S;O;4;2;AG;KG'_ZLG
M<6_6^LN,/1=G[0\C*@A BB*.IEF2Z,FV(P2O[LS"J1BC]NON-)E[X7C$F4^H
M2BJ/P!0M^(M*I]2J]8K-:K<F0   _@((!(/!139SUT^V^^I\R^=T=[R.S^OW
M_+Y?[@46.%9VUI)F^"<%I<AVUP@9^?,H66EYB9FI-3B(B%:H&<I%*5HZ1VJ:
MJKK*:L4IYGD(VDI;:WN+FZN[VR76.<L2RSM,7&Q\C%S\"B9\TLPU,, BG4<]
MG4QK/:.]'8W]#1Z>M4RH)FN^QMVG+J[J3?,.;\+>_EYOGTS^/"(<K=T_KR#>
M"&[_YDFC9@UA0'_Q^C446##@0H,1*TZD"!"B0!<6!WK<V**C1(D:&1(<R1&E
M%'KW6KK,E0^8LUD)/=I\A]#AM9L*>=X$"'0GRIPV4_H<6?-B3Y5"EQ)E>B*I
MU)Y2@R[=5H7ERZU<4\5$-].<NJI%H0X%2A9KT*A6B[(<N_:G4(HX0Z)%JQ-J
M6J=EW4;1:K"KX,&JOB8*:PBN7)7LDB*]&S*B6<=\X36T6E#QRLN+M8JL3)FS
M6;94 !,^C7J/X4]B[78FW13RX]AQ_;Y>*/EVVMI_;3O^ 5JV8H<@8:],C3QY
MG]7G$@NWW=<WU:O0)[<]_JL6*579UXW.KAO]^M.]U<MN'$M9N?KU@'S!DFF"
M7\GNU@,G/!@^;V#CGX%?+DG=0,5%I=%LHPG(D('WF>3=1;@5B!%[$DZ(!7/!
MP+>.+J91R&&''F[B'C,8*J /'K_9LN&'*J[(8B^"O =6?".:.& K*;:(8X[L
M68B8CC[^""1R/,H88Y!&'HDD-D/N,V.23CX)Y2I+DMADE%9>B:4B4Y:899=>
M?NG&EE6"26:99K8@9I%GKLDFF6D>UF:<<E[YYIQVWNEDG7CNR6>.>O8):* 4
M_BEHH8:B1NBABB[:4J*,/@HI/B&6 R>3:DH20:::1A!IIYY.\6<)-Q0A*AV;
M_FKZ*92HI,I'J*2^JD0+I(QZPJF98K&J%K-.HNL63,C0 QYQ#%M%KL9F\>L2
M?PP!K*Q6,.)$LHJZJFRUNR["@JV<:I*K$;V.$JRW=:S:;1'@?BLN'Z4V6T.Q
M5)3+IYXV[#!O#/52\L@1.)00@03]^KNMOD"<P$3!C+1+Q+X$0R'PP34$H; .
MM,8:J[UM,.SPPM$RVX3$$&-,\<.C?JQOQ@@+,3*Y$ \LL;,LDRS#QL1J[#+*
MAU)+:\YMI)N#"/]FZJ^UZP*KL[DGBSHTK$GTO//2ZQ9-<<ZS/LTNP3$C8776
ML"*-+=;1:GWLT4D?[;722W!M;<4QSWLRT57'.VF)_K$,3;?1;9/-0[^G(GQM
MVM@R.['9@FOMMM]1%Q[NTF]OS>[,C-M=<^!?0WYWM4[[<$?F/ ^L.<N(AQSR
MQ/"R6>>]3=!;;].1KZ#WIBB/#3;;-E^LN-&!#T[SX[4?COO6LO<@^^V.GUYW
M%*(3?GOBB*,B<.5J6_PZUAY/7OD-OP<JK^ZP$XZW"JVC"O7JJK<+>.-5)Q\N
MU,4OW_3V-7_.N]WH=T^]Y>-;WBWL^2+/>/W<R[\X0&7/<.ZCW-GR!C#P76US
M"0O@$-:G- CB37T)<QS:@-=  Q8-6FW;8-CL1[T/$JV X=.=N8JW/O\!T&PF
M(UW<1C0W[1F0>&3+P?=N_G4Z#>9N=K03G,S@)[+E@6QXT L6QE2VL?CIH&5+
M_*#PK)>_U;6P8Y!K7K.@F$(.ON^$T!K=EQQ5"6VQ:HRL B.F;$7&-';*C)$0
MHQK?N"@VPG&.=)R#'.N(QSQ6Z(5JDH]F;J2%W&!'CX3T4J(\XP=$%G*16#HD
M@6HRGX\PZ#@1(LDD'P1(1FKR-(YLRG:.4AG@N$8IY=FD*3W42=CL)CJ _"-W
M3@G+#Z6R.PNJ32M'&9I,QG*77)DE=(8SRBFXDI4(JA$OC]DH/E:*2C'ZXR<-
M1)_L8.8VR*PFHI3)&CBY,I*3,:8M,W)):XI3,'>L!G'&B4X?E3.=[-S3.ML)
M_D\YO3.>]#S3/.N)SR]BLSGY[.><[NG/@#X)H (MJ)$(:M"$Z@BA"FWHBACJ
MT(AR"*(2K>AZ*&K1C*8&HQKM*#GW>:%+>72D.P)ICTB*TD&9E$C+3*E+K_DB
M$?5Q3"^MZ4MP9M.<WG2EEDI$ >U$+"_"X7J+(.H4C'7$203O?CH%44PIE<T%
M!BJH?1#J#'EUU"TJSZI-=05/F6D(TP$/<\$K*UG/VC.SIA6M2&/KZ]JZUKC"
M=:YOK:OR5! Q'N:5BEAE8E_Q^D.[\O5\7>-!4@V;1"@JU:TT;&SJ'*M6ND*6
ML8^M;&3M:EG&#@:G@J(:TX260=#Q[ZI)W%W]A*?5_O=]=H097"U7)3K UY+I
M@3(,70!/>%NUA=9Y2KRJ;N-'0='JM'2/[2Q>?8<Y61FU@[D-H5]M]ZO._16U
MM1UL4V.[6+EB]K*3U6YW)9M9[X87O-PMKK/*M]L59A6(S%7O;X?G6^>"3:K2
M52YERXO?^^I7O/GE[WXEN]FOQE"X>^)8<*5+KOE.E[ZC[2V!<6N[PJ%M?B_%
M[J$,/$+T2>MN&\9LAI7KL>H5UG[X:^)SKRM@FG8U%[+M*$=7C D*=_7%,+Y$
MAU=,XQKKV!0YWK&/,]'C'PM9$D$>LI'_4.0C*UD/25ZRD^V88I$^><J7:#*5
MKSR.*+<4RUS6DI:[#&8B_G\YS&1&\IC+C&8FGSG-;(;R4^6FXC;+F0I6GC.8
M.6OG/$L!S_9=K:^*.E3XCO4-^R-TBW.;KB<<]J^(-O2-SZ5#0MMABG 8,8OX
MO%5'&._/_TLTI(65B7+5U].0./2(3=T(5/M6G6,6:Z+W^N@B1C>(/IS>J1?-
MU^(:+&66;A@25[!H71^LOB4K]@[WBBXA\AJY3 NVYSBWV!T:D=BX-AB!?2W+
M,_^T8E2+M&L]'%KXBEK"#'[;\5ZFZ.16,+Y+-&V#!7WN*DIXVY8F8-E N+ (
MW_N"[7/@V,Y]8.FUC]X;;36[R1UI=R].@H)FX.XR+3Z%JZZ$FS9AIQU<:'E7
M_E=75D1A^MY-O]XIN.(.?OC&':[J=A!WN2!O;.( '#5U]W;<%H^>N1'^8/F.
M+MZSUAB\?=YI@#>:T8:U->B2)E_VD7BK+:2NS3.WU(,OO:1OAN$LZ*WS]9K\
MBN4VG]8I+KF7=_W54OTZ8;FN[Y&KL,13?Y81SW[>EBM=QAH7N]K=*W*E3]3@
M#WZOR">,]L=I<>A"#W?0<9Y@G)O=\('_.0OM+O%G:[V]6Q>XW^_NM,)2V,]L
M#[CD(9]R<5AXP:2:HJP';W-H_X_2@>5A#O.-O)61EM9]Q[QU/4=4:G>Q@[+G
M=J 91ON^M=OIHN/8Q)O^>9DI]KE%[/>J81H&F2Z3_DMZCK&ZQI6J.E>_TJ%G
M[QJZ7R;M;]_M>GATLB,E_O$O&=/JWS[[*ST^5+\6_.V>.%/?Q5M<V3CJGS:"
M%WON")0V"O175018"^]'?J0F::D014,'?]AG?0YX?Q+(8:=0?L1@@+8@+^85
M?%<S1'X%:\'V.]C&?+@V:!=G="'8>OYW-LOF>L4&,XCE?0\(6-*&0<O7.+UG
M02R'/\.F;#9X5R3(@JV75S(&@(2!@/:&;ID7.XP7=O.6=L%E=QRH6O\V@_QV
M0 KWA+[#>-\'>Q*4-=_F6&-7<@I&?.6V>?P'>-Z"7DP(AO-F?O4P>G>EA&<X
M06277IC7@+]%>L"U>$!$_G$05GD$=VID:(:!QS=>UUQP%T$U9W]Y^':=4WB0
M5WOVL'(WUG$GESR5A8>55WK&YGRKEG1<Q#R*"'4R1WG;0X@D)S0=)C4%(S(,
MEW_ !G1Z.(*L=XA_TX(IE'!KUTM\1W.>YX<B!G&>V':]B()R5W<1-SBCUGB4
M8WR<YHCB@R^Y.'.Z6&O3.'N*1SL>AUM]XXM;,8?4Z#7=-G@(]GC<J(<.A(B/
M.(S"A86;.'99AT&P1X-2Z#)B*(A/(VZ39X=B2'?TN&EM"$'()XA("(S&\X$U
M:&(C)VW)$H/P^)"FAWI*E8VN=X/=,Y%0!X+Q9U5)%VL&5I&WB'&)%V*QUX) 
M_KA%5L0K(JF/I%61'U5U,R5E'I6!<'23HK=F*!6-[=23#[63/-E/.:ER0=E^
M1ZD 28B4;::4?)AJ1'=[^G=4 J@>(N0NH6:2$DE/31F.-C:!5XE_+$)_1 F5
MJJ50&\ARG&B"]+,RU=:6NJ>2P+:"I#B#N?9L(2ET;[F1>]F0_N>"8Q6116A\
M>#F+8^B6OR:#)S:5<\F6\09B1$B!Q,"57_AW:&B%7/B.;[AOIFB(4!AY=[AN
M;EA;GH>+]^:.:TA;Q_B*ID>9MD>-W5:))V>-FGE<WAB;QC".Q4B;\JB5B1B%
M9>=\=J@X/YF/S!ARDZB.Z'B,>M>)^G-<M;>%?6A!_HN'C_5FA$[(CCT9B#HY
MD],'"J[6G(+U=B<I?&HH-J#(0!R8E]>&BN(9BZ<%G"ZW:RF(:([)=.U9FXKI
MD'M(8HPYF^Y95/;IF]5I-2ZYG>&0FV8)B>-I.!$GBS,$CLC80,39H*+(H&!'
M=,XI=0&Y>G'GC)_#GTZ'@L+(:1QJF[M"D 6Z4]T95<;XC,MY>1$:FM/9A2#V
MF>LIH\HYA6N3A\+HC:4)HP))B[O9CN'IFJ 9>0;YF3;J-R:3FI)#ED"6D(#6
M@U;)?U78;'"IGW()A"M(H4]W@NE&;KW'ER^XD'U%=[A'ID6'@WY9F,.GB%%Y
M;!]FCVZZI;R76-UXDI$I_IE&N4M1JB@&"*B 6F5^&DN$VEEC>9M>B*B6D'Z/
MTJBF-*A=\:A+Z6--::G]IZGUA*F3EP=9*8U/R:<#B)^CVG=4>6)<)5NJUJ:^
M@JKHIVW/QXJ?.JOGMRS)>(&F6I:FVG">FH":]J9@.4=HN6$J:'335J:J!YBM
M:E]<VI%GBHE+)8*+:G^'J9 IR3V9&#OHN:QW:GM"R(CSJ9B1:DBQ"H^PV95+
M2)I9N7D\JH7F2)M<A)U?*JR<)Z#NNIHG6H%U>7FGB9EK-XD/2D<)BGBXZJ-Y
MUZ]:Q9L'*YW]0ZVZJ9'!6:0UJD3P,HH0:UMTV'F,1JY=<HE..H\D1UXRQZ[L
M_MB8^NIR1JJ6#ZN@%:ND,#<L)+NOWKJ/'$NG1X=R572$<$2P&V>2&NJ0&$N'
M#'N@+>N<]!J6%SFB\5FS_<E;)0NA$3N(.9NQ94A&/:N$VZB%"\2:5XB&7[N$
M.?>?^5E_ORJ<U_*2]#B206NT][.&6R>C6YMVEO<I6%M\'(ER;GFJS-J!GYA%
MV'JM53JD=5JO<1J2@ M='U.2-"L]F)B1>I5:=%F"(]FQ>6*H25*YF:H>E=H5
M::JY^L2B_&0E<?BYY1JZ(;5EI2MGG)L5<J!+JLNSEVL%Y[$%KRM-#6(<L%NW
MLEL:<V"[N N\X:&[D*(G!P%)X<04_8%)M#$4_Z$9_KA!%_=Q(,,;1V,&'M>+
M%[F1'J(D'GAA'JK$'P)"O=EGO:\T2/7Q$93D&\$4O@UR(N/[*,5KON?$&R?1
M&^"+(/4;&?9;2O!;O:=[4JLT&HW!%@LB&J44( ?B#_CKO\1KO<]$'P3<O\1$
M2HOQ3=_KO0WLP #,4I)4O[2+2[R1'_B1OQ0\#2#Q$-.KP0)4OBM,9O+KPF$&
MPS'<9:Q+PQ9EPS<,6[RKPT>6PSW<4#\,Q DEQ$-<4$5LQ &%Q$G<3TO,Q/CD
MQ$^\E3PLQ3 6Q57<3E]!!EO,Q7&&Q2A6=5TLQC7YQ3CV0@B QFFLQ@A QF4,
MQM%'*68@QW.,#JL(@:'F_L;RI$QTS,=,*Z'(0@<QJ;&[&KD6&+B1('PLF[E)
M6[:*3$2ONL%P3 9LC 9L[%,)1\CU%JJ_RLBU>L<*J @6:ZNXP*J=_$8Q8<D7
MDLK$4XW-NEMQZ(+&FJTZR*=%N#:N>+.#U7Q!J)?1EIB0*X+<"H,>MY8=:*VI
M2GMR.LM:BI'_*\D$@,9@ <VK;(P1>K&!BYJW?(ZZJJX3.[8>E&X 24+X^J\S
MF[4QBJ[!F<Y.ZY[WVLX.BK L7'5IG B3O,H_!8XTFK1 "[ JZH4U^K/J%:\Q
M"G_.**($C;'*R8E(.LZ')ZL9-W?D.\_1? ;VG,K@F7_6\YX)J#_7 ]$LR] &
M_GNS"RVVZNB70 L_CURJ".USS$/+8^AI&2?*"GNLI LW$QW-)*+&YH#/_9:N
M$ONTF79H^!C0OLFVJ6BA/6J<1!2Y0BJKV)G1SN.YRYAWBXPCJ$S/!C#-%+V@
M$NK.+ BW$_O5=-N:_)9X ,FU4.NBR4F&3 W08<C/Z@S5UPC/4*FC!6G5'8+5
M]+S&/ VAN?>#;K>F&"G3S56*9TK6?2FN2 "J+)E=.FN?>*O+PZ;1JDB1?[G8
M<7I%0-JAD_LP-Q,W?"S:J8O'H9#7=W+:XT0.HRW:K9"YD+Q(J2U.Y( ,LFU-
MMEU-M+TBWJ0'O)W' ?94$_*\E?"[OUV4P8T-(#R[_LKM!LQ]N\9=<,B-#,6=
M$8SANH$$W9L[*5B@O-!;22GAO(\T%]Z-'?1+PN$;WM^=O**QP-F='+K=NKKQ
M'-T 2M*AO=%4P,%TO<^4$_=='=3MWI(BW;WK%]N[(0+\&Q*<OOXAO?@[3/F1
MWR<<X- W"%= O^:1%P<^O_J!OL)[#>V]OB<L&0INPA..D ,N3.!]P?<+3<)+
MXN=]X231OBT^P.Z;O"9.X6)@X?--'O1-XPGN'>];W2!>P0^.OD".XR<.Q]S-
MWM\M2 4LY/[-O)[!W,;[P?S+P$2>Y+^(XHI ' DL"<\+X%DPYEN^"_"M"65N
M3AZ^YF8NDTLN"FK.!W+N_N9[U^5UKF-HCN<[IN=[7F-][N=F?.>!_L853NAY
MOMV'_N>)KNB"#N>-/F.,#NG#)>F3;E. ;NDIA>F93E*;SND>Y>F?KE&A_G&B
M[D^D7IQ!"-+"2H.L'J;*W(JP[0="]=.NSLVX6KBFO <V?6O^N8">+(>5OEZM
M3(O7)ZK6B:9/+0FTCNNVS@JUKNQVL.N%#*S ?MR/_BY4>#BRS)#-W-(T"Z[#
M/*[4_IRA,YC'+*:_K*QAJI:0B7S.!N]>6LST&<P@B^[(QFVE^(DT'8I"J.V"
MQ>LP(>Q=T\JE\EE20[%M*[+KW+2,>*$>.IHF*YI,2(FEA4(D=)G=/*,A%Z1E
M_NW-<%J'&=^N<XMW(1VVT'G4QX#J8=B2<AO66@NC&SO(CC==#9.Q'XI5! JB
MW_R'C6C4=3W3S2C2<RVP[1J-!MWRDOCQRJ@D Q_.]OZN^/GO+YKL^[[,-,^&
MA&6@D*V0:/W'Z+S2$<MS88]%?(O4J5?2E^/UP,6#J>GPUU;NYMEHUXP,*^_'
M;%IS."^T_=ZR["S2\IBB<)^>G9F.>=_S,E_-MZ76!2FR GV1473T_)[U*)O4
M\<P+=M_511?Q4GOV59^D0:OW%4JV#+NCK16W+$UP]EJPO:GS+1>=]8BRJE^9
MD4^,D^^S_GCKA>'T.Y-@8Z]A AB1GL^L)(/UKYE<_EMOIDCTMRZ-MW<[]\FG
M; V=_%,90=&%HO+^EY+;0YW]][7X1%0*Z\JP^Z;NJ[I.2)A/_L$ZR'J$_ND_
MJKB=)>WO_DH\_N("_Y9P_\X^_UDVZ#E?:NH/ HHXDB)40FFYLLI)IB\\RJUM
MU[=N[KW_ X/"(;%H/"*3RB6SN0($ -(H0/C*.5=8Y7:[Z]Z\1;$U:SZCT^HU
MN^TF0J7Q*C 6:YU4O'V>[,K3Z+G\P0C^R=CE(-*$X14N#@;ZW9G8219&'FJ]
M<79Z?H*&B@K-S95E:EWM1>J)72D&\C%FUH"MDGEA+=;.LD"NTO*I J..&A\C
M)RLO/U&9UA&C;,I&]\)&_D/F^LX42V][$W)W6XM[9^,PIZNOL[<?E5+5):*#
M#X_?UJ=2:D]3.WZ+,W1(X"-#BO99(^C''<.&#A]V@B<EB#V Y(+]*_:K%\=R
M'0'1ZT>.UY>,&#<26PAQ)<N6+H-(I/.CHDAA^/X)1'F2HZU8.GI>_.6*9T";
M&+&I?*ET*5-V,2E6ZUB)E51,U\91JJ3K:E5P'H\B(HA"85A!*LIZG=IT+=NV
MS)ZZ=:(RZ2A<<>_BS0L*KMXQ]Q[J["MX,.$L? M#8YH5,>/&CG\<?CE@0-O)
MCR]CSFPF,D/*)3S'!?U9,^G2IIO)B0=$].@>K%F[MDP"=CK9(VBW7N$9MP+>
M_J=_ U_*68=O'\5W4$X^V]WQ%K1!-P\N?;K+X3>2BYX,O7=VY2*TW^9^6_ON
MWKH_V][^W39WW]C#LP>_?';Z\/9SOQ^_G3WU_OZ566>#;*^-]YV!XLV'(&_>
M)6C>@>I!>)]NY2EXH(/D$6AA=N<5Z.!] _X7HHBB!.B<A!Y&:*&&QJ67(8HO
M/NB:?;"IIZ*$#':H8HTKVCBBCS^B42(+.\)XX8E$7N>ADA@VR*22 LXXH7P]
M/DEC;CQ^>"*06W*9A) <5IEED5CJ%]^2#<*G97,IHJGEF2[:2&2-T759IYTL
M/'6 GGORV:>??P(:J*"#$EJHH8<BFJBBBS+:J*./_D(:J:234EJII9=BFJFA
M"N2IJ:>?@AJJJ*.26JJIIZ*:JJI^)L"I,_'HB8"LL]):JZVWXIJKKKORVJNO
MOP(;K+##$ENLL<<BFZRRRS+;K+//0ANMK@FTVJFTUV*;K;;;<MNMM]^"&ZZX
MX])*K:NI310KN<)&$(&V[<*[KJ\33(  O;?>FVN^O=+;KZS[0EM  ;*V>VO!
MN1[<*[P')[PK!0]#3$&R LM;L<47VVJNM>S&2W"M"\_JKK(-\PIRR"33"G+'
M"ILLK;__U@OPK#+72C.N^>)<;[04$RSRQSX;#+2N#(N,,JX/)XOTK#QW*S#3
M3@\L:]084^VMQJ^F>P#'_CTCT##170MMK-&XQOOUV"2'37;!*S_;K\[VPOQV
MW+K:C*_<,$O+--M@IWVRKRB/;:O2QPZ. -/;.FWXP#Q3?'C5CV-[-;I5J NL
MV3]SW3>Q1@->M+L)=SZTYJ"G[?;,;^=L+\#W[JOSRZ>C_GKJ<;ON[^RJURWL
MX7NOW/+7/1.]MN<G&UUXK1#3BC3R"$0LL=13:\OXXE$W#KGUV4H^1=;#JAQV
M]\QR+G3H7&..\.@^HVQ[[:?/_?+L.;?N_OJJTX]W_>_/GSNPN_?>\>_"^PUL
MY/O?\([G/,%);'#(6Y[Q''<M!RJN<="['@6;E3U35&YSFB/?L@*'.?^ASWL;
M_BQ9RVA%L_C9CWXHO%_,9E8_$]9N=?F;H?WT]RO^=2UD BQ?"0DXP *BK'D'
M5*#SB"BK!D[P@=-+HN(JZ$1G71!66EL8"*EHJQ'F,&A6Y%L).;BK[Y'NBE@T
MW^>,9KH4WHYUL:MA"__U0K?%4&YPI"$+SW@L'*)OAUSTG->VZ,,]ALUX1QQB
M$0DYR%I)$&K44^0B%?D\1](*:DU$)*X8V4A)1A"3EGRD)AG)R<1E$I2;#*7T
M(#G*4WJ2E)<$9;FJA37*::U8P@M=%S7XMQ#J<7S<P^7-TC@_%<ZQC< <)@OQ
MMD(8LC&%RL)C&7?HPS#R$(@;%"3S#%G-62D-B=QZ_MH$$\G$)X+S5U'<GBR=
M*3YS(LN#*<,E-,NG0Y8%L)=H_.4)7<<^N-$Q=<>\)_Z:A<,<2O.'N12A0/5X
M*VH:\9J'5.C2OAFPJ3EN>L\+)T6#-4Y8RK*9!@6@06TIQH^"L*/$*R,O@Q9/
MV-41=_.TE1KYB;\SOK28,E7?Q* 7O!^:C( :_6/9 GE  S(TH<IK:-.6&$F)
M3K*B2MW51160P6"%$&TC3185?_>S/HYPBUX4X]Y@)\>6OO%NQ'SC/54*UOBM
MT)<VO*%-\\C!GJ(3>+RT:BT9BL"?)M2N$%1B1!NZUZ4"5E87E(-38QG8PR(V
M>@Y-;*_^RMC'KDMC<H!"_A0*"]G+8M98CLVLK3;+V<]>ZVI4D")H2VM:1"ZV
MM)X]+6N3U50]42NVLITM;6MKV]OB-K>ZW2UO>^O;WP(WN,(=+G&+:]SC(C>Y
MRETN<YOKW.?N]ES:HQQTJVO=ZV(WN]K=+G>[Z]WO@C>\M97N,^YDWO.B5RE?
M2B][V^O>4*SWO?*=+WV=$-_ZXC>_^NW!???KW__JM[\ 'C"!V2O@ B,XP5LZ
ML((;[&#J,/C!$IZP9B),X0MCF# 6SC"'.]R6#7LXQ")F"8A';.(3KZ/$*%XQ
MBT>AXA;#.,9MB,ED:VSC&^,XQSK>,8][[.,? SG(0AXRD8MLY",C.<E*7C*3
M:)OLY"=#.<I'QEH JFSE*V/YRI3-,I>[[.4O@SG,8AXSF<MLYC.C.<UJ7C.;
MV^SF-\,YSG*>,YWKW.8MFWER0W:&E/OLYS\#.M""'C2A"VWH0R,:R'Q.-*,;
1[>A'0SK2DIXTI2OMY!   #MR
 
end

--===_0_Wed_Jun_19_13:36:57_EST_1996--







From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 14:37:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA03683 for xemacs-beta-people; Wed, 19 Jun 1996 14:37:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA03680 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 14:37:21 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA07590 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 14:37:18 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id NAA01628; Wed, 19 Jun 1996 13:37:21 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id NAA01184; Wed, 19 Jun 1996 13:37:19 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id NAA09960; Wed, 19 Jun 1996 13:37:02 -0600
Date: Wed, 19 Jun 1996 13:37:02 -0600
Message-Id: <199606191937.NAA09960@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: Gnus 5.2.20 comment
Reply-To: turner@lanl.gov

Just noticed something I thought I'd mention.  I'm not really sure if
this is an XEmacs or Gnus thing.

I set mail aliases in my .mailrc.  In VM and in the old GNUS, they
expand to the correct address when I type either , or C-n.

However, when forwarding a post from Gnus 5.2.20, although , expands
the addresses, C-n does not.  This means I have to hit , and then
delete it to expand the last address in a list.  Or is there
something different I should be doing?

BTW, other than this, Gnus has been working fine.  With help from
Steven and Lars, all my other problems with scoring,
gnus-background-mode, etc. seem to be sorted out now.

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 14:47:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA03730 for xemacs-beta-people; Wed, 19 Jun 1996 14:47:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA03727 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 14:47:02 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA07615 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 14:46:58 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.52 #3)
	id E0uWTDJ-0003rY-00; Wed, 19 Jun 1996 15:46:53 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: Mike Scheidler <c23mts@eng.delcoelect.com>
Cc: xemacs-beta@xemacs.org
Subject: b26 scrollbar placement problem
In-Reply-To: <12061.835210477@kocrsw12>
References: <12061.835210477@kocrsw12>
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Message-Id: <E0uWTDJ-0003rY-00@neal.ctd.comsat.com>
Date: Wed, 19 Jun 1996 15:46:53 -0400

Thanks for the mail bomb, Mike :)
This is tm7.67.

Signalling: (error "Unable to decode GIF" "Given file is NOT GIF file")
  specifier-instance(#<image-specifier global=3D((... . ...) (... . ...) (.=
.. . ...)) fallback=3D((nil . ...)) 0x2e72> nil nil nil)
  glyph-property-instance(#<glyph (buffer) #<image-specifier global=3D(... =
... ...) fallback=3D(...) 0x2e72>0x2e71> image nil nil nil)
  glyph-image-instance(#<glyph (buffer) #<image-specifier global=3D(... ...=
 ...) fallback=3D(...) 0x2e72>0x2e71>)
  image-read-file("image/gif" "/tmp/tmc13387")
  mime-preview/filter-for-inline-image("image/gif" nil "x-uuencode")
  mime-preview/display-body(2140355 2166697 (1) [mime::content-info nil 213=
6851 2166743 "multipart/mixed" (("boundary" . "=3D=3D=3D_0_Wed_Jun_19_13:36=
:57_EST_1996")) nil ([mime::content-info ... 2139253 2140221 "text/plain" n=
il "7bit" nil] [mime::content-info ... 2140259 2166697 "image/gif" nil "x-u=
uencode" nil])] "image/gif" nil "screen1.gif" "x-uuencode")
  mime-preview/display-content([mime::content-info (1) 2140259 2166697 "ima=
ge/gif" nil "x-uuencode" nil] [mime::content-info nil 2136851 2166743 "mult=
ipart/mixed" (("boundary" . "=3D=3D=3D_0_Wed_Jun_19_13:36:57_EST_1996")) ni=
l ([mime::content-info ... 2139253 2140221 "text/plain" nil "7bit" nil] [mi=
me::content-info ... 2140259 2166697 "image/gif" nil "x-uuencode" nil])] #<=
buffer "INBOX"> "*Preview-INBOX*")
  mime-viewer/make-preview-buffer(nil)
  mime-viewer/setup-buffer(nil nil nil nil)
  mime/viewer-mode()
  byte-code("=C0 =88db=88~=88`=8A=09@=C2H=C2Hb=88=C3y=88`)}=88=C4 =88=0D=AB=
=8B=0E=06=AB=87=C7 =AB=83=C8 =88=0E=09=AC=88=CA =AB=87=0E=0B=AB=83=CC =88eb=
=88`=CD=CE=C3=CF#}=87" [vm-widen-page vm-message-pointer 0 nil mime/viewer-=
mode tm-vm/use-original-url-button vm-use-menus vm-menu-support-possible-p =
vm-energize-urls vm-highlighted-header-regexp vm-xemacs-p vm-use-lucid-high=
lighting vm-highlight-headers search-forward "\n\n" t] 5)
  tm-vm/preview-current-message()
  tm-vm/scroll-forward(nil)
  call-interactively(tm-vm/scroll-forward)

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 14:43:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA03710 for xemacs-beta-people; Wed, 19 Jun 1996 14:43:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA03707 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 14:43:44 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA05177 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 14:43:44 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id MAA05912; Wed, 19 Jun 1996 12:42:56 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [20.0 b25] patch for mule-misc.el
References: <199606190159.KAA25566@mikan.jaist.ac.jp>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of 18 Jun 1996 18:59:01 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 19 Jun 1996 12:42:55 -0700
Message-ID: <m2hgs74m2o.fsf@deanna.miranova.com>
Lines: 17
X-Mailer: Gnus v5.2.22/XEmacs 19.14

>>>>> "MORIOKA" == MORIOKA Tomohiko <ISO-2022-JP> writes:

MORIOKA>   I made a patch for mule-misc.el to fix function
MORIOKA> `string-to-char-list', and I propose a function `string-columns',
MORIOKA> which returns columns string occupies when displayed, same as
MORIOKA> `string-width' of MULE, and define an alias `string-width' for w3.

I applied this patch, and the canna.el patch, but 20.0-b25 still
crashes for me with the same backtrace I posted earlier when
translation of ISO-2022-JP is attempted.  Oh well, I should be running
the latest 19.14s for a few days anyway ...

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 15:09:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA03854 for xemacs-beta-people; Wed, 19 Jun 1996 15:09:41 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA03851 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 15:09:40 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA05750 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 15:09:40 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id NAA04741; Wed, 19 Jun 1996 13:09:04 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id NAA26940; Wed, 19 Jun 1996 13:08:54 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA03112; Wed, 19 Jun 1996 13:08:52 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA18812; Wed, 19 Jun 1996 13:08:46 -0700
Date: Wed, 19 Jun 1996 13:08:46 -0700
Message-Id: <199606192008.NAA18812@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: MORIOKA Tomohiko <morioka@jaist.ac.jp>
Cc: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
In-Reply-To: <199606190446.NAA06052@mikan.jaist.ac.jp>
References: <199606190332.UAA14491@xemacs.eng.sun.com>
	<199606190446.NAA06052@mikan.jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "MT" == MORIOKA Tomohiko <ISO-2022-JP> writes:

sorry if you received this twice.  I'm still working on configuring my
mailer.

MT>   By the way, in Emacs, mapcar is too slow. I love map. It is
MT> beautiful. However I don't use map for library because of speed.
MT> However in XEmacs, mapcar seems fast, so mapcar definition is better.

Martin> How about this definition for string-columns instead, in the
Martin> functional style?

Martin> (defun string-columns (string)
Martin> "Return number of columns STRING occupies when displayed.
Martin> Uses the charset-columns attribute of the characters in STRING,
Martin> which may not accurately represent the actual display width in a
Martin> window system."
Martin> (apply '+ (mapcar #'(lambda (c) 
Martin> (charset-columns (char-charset c)))
Martin> string)))

MT>   It is same reason. In Emacs, apply is too slow. In this case, my
MT> definition seems faster. So I think my definition is better.

I am a little surprised.  Perhaps it's the cons'ing that is expensive.  

Your original definition of string-columns will appear in the next
20.0 beta.

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 15:33:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA03994 for xemacs-beta-people; Wed, 19 Jun 1996 15:33:29 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA03991 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 15:33:28 -0500 (CDT)
Received: from tinderbox.Stanford.EDU (tinderbox.Stanford.EDU [171.64.72.13]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA07629 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 15:33:25 -0500 (CDT)
Received: by tinderbox.Stanford.EDU (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id NAA12169; Wed, 19 Jun 1996 13:33:28 -0700
Date: Wed, 19 Jun 1996 13:33:28 -0700
Message-Id: <199606192033.NAA12169@tinderbox.Stanford.EDU>
From: David Ofelt <ofelt@tinderbox.Stanford.EDU>
To: xemacs-beta@xemacs.org
Subject: delete-frame & the focus problem


I use fvwm, and always have frames in active in multiple desks.  In
b26, I can no longer delete the last frame in a desk with "C-x0" or
by hitting "q" in a VM windows (which worked through b24).  I'm pretty
sure the following is responsible:

-- The force option to delete-frame is back.  You can no longer delete
   the last visible or iconic frame unless the second arg to
   delete-frame is non-nil.

This causes XEmacs to behave differently from how it has always
behaved.  I'm now not quite sure how to delete the last window on a
desk without a) Making a new keybinding, b) Going to *scratch* and
typing the proper lisp, or c) Moving the window to a desk with another
emacs and then deleting it.

Also, the focus lossage that people have reported under fvwm is still
there.  I constantly having to iconify and uniconify my xemacs windows
to get them to start displaying again.

Other than those two problems, b26 is working fine.

DaveO



From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 15:48:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA04047 for xemacs-beta-people; Wed, 19 Jun 1996 15:48:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA04044 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 15:48:19 -0500 (CDT)
Received: from arthur.cs.purdue.edu (root@arthur.cs.purdue.edu [128.10.2.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA07649 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 15:48:16 -0500 (CDT)
Received: from mordred.cs.purdue.edu (hammer@mordred.cs.purdue.edu [128.10.2.2]) by arthur.cs.purdue.edu (8.7.4/PURDUE_CS-1.4) with ESMTP id PAA20334 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 15:48:19 -0500 (EST)
Received: (from hammer@localhost) by mordred.cs.purdue.edu (8.7.4/PURDUE_CS-1.4) id PAA03325; Wed, 19 Jun 1996 15:47:58 -0500 (EST)
To: xemacs-beta@xemacs.org
cc: hammer@cs.purdue.edu
Subject: Success (mostly) with b26 with irix5.3
References: <199606190323.WAA24419@xemacs.cs.uiuc.edu>
From: Adam Hammer <hammer@cs.purdue.edu>
Date: 19 Jun 1996 15:47:56 -0500
In-Reply-To: Chuck Thompson's message of Tue, 18 Jun 1996 22:23:36 -0500
Message-ID: <wxd92vv7ur.fsf@mordred.cs.purdue.edu>
Lines: 15


Compiled for mips-sgi-irix5.3 with GCC 2.7.2 to not use Motif and to
use our local X11R6 libraries.  Normal operations (mail/news reading,
some small editing) seem to work fine.

During the build process, it found our local X libraries (I have our
local xmkmf early in my PATH), but I had to hand edit src/Makefile to
include a ``-lw''.

I don't remember having to do this when compiling with SGI's X11
libraries, so it may not be a big deal.

Also, there's a comment in the src/s/irix5-2.h file (included by
irix5-3.h) about NEED_LIBW, but I cannot seem to find anything that
references that in the src directory.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 15:41:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA04025 for xemacs-beta-people; Wed, 19 Jun 1996 15:41:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA04022 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 15:41:39 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA07643 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 15:41:36 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA04768; Wed, 19 Jun 1996 15:41:36 -0500 (CDT)
Message-Id: <199606192041.PAA04768@charles.cs.uiuc.edu>
To: David Ofelt <ofelt@tinderbox.Stanford.EDU>
cc: xemacs-beta@xemacs.org
Subject: Re: delete-frame & the focus problem 
In-reply-to: Your message of "Wed, 19 Jun 1996 13:33:28 PDT."
             <199606192033.NAA12169@tinderbox.Stanford.EDU> 
Date: Wed, 19 Jun 1996 15:41:35 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    David> -- The force option to delete-frame is back.  You can no
    David>    longer delete the last visible or iconic frame unless
    David>    the second arg to delete-frame is non-nil.

I think the great Emacs solution is needed here.  The feature needs to
be enabled to keep people from shooting themselves in the foot by
deleting all accessible frames and having no way to regain control.
For 19.15 I guess we could look at doing something like trapping USR1
and creating a new frame if it received.  That off the top of the head
solution probably has all kinds of associated problems.

So, for 19.14 I will do this:

Create a new variable, delete-frame-always-force, which will be nil by
default.  If t the effect will be as if the force option was given to
delete-frame.  Different names for the variable are welcome.  This
should probably end up as an FAQ entry as well.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 15:47:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA04040 for xemacs-beta-people; Wed, 19 Jun 1996 15:47:29 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA04037 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 15:47:28 -0500 (CDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA07646 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 15:47:25 -0500 (CDT)
Received: from federal-excess.apple.com (federal-excess.apple.com [17.255.0.16]) by mail-out1.apple.com (8.7.1/8.7.1) with SMTP id NAA114784 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 13:48:01 -0700
Received: from zaphod.apple.com (zaphod.apple.com [17.221.20.63]) by federal-excess.apple.com (SMI-8.6/8.6.12) with SMTP id NAA29596 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 13:46:24 -0700
Received: by zaphod.apple.com (AIX 4.1/UCB 5.64/4.03)
          id AA18118; Wed, 19 Jun 1996 13:48:02 -0700
Message-Id: <9606192048.AA18118@zaphod.apple.com>
To: xemacs-beta@xemacs.org
Reply-To: butch@zaphod.uchicago.edu
Subject: 19.14b26 success AIX 4.1.4
Date: Wed, 19 Jun 96 13:48:02 -0700
From: Butch Anton <butch@zaphod.apple.com>

% ./configure  --compiler=gcc --with-gcc --site-includes=/home/butch/usr/include --site-libraries=/home/butch/usr/lib --with-x --with-menubars=lucid --with-scrollbars=motif --with-dialogs=motif --with-xpm --debug

No problems so far (except for font-lock stuff in my configuration
that I just haven't gotten around to fixing).  As soon as I get the
xlC compiler suite installed I'll try building with that.
  
Butch Anton       | Psycho Racing (Novice Sprints)    | butch@apple.com
Apple, MS 35-HN   | '87 EX-500 WERA #623 AMA/CCS #811 | DoD # 0124
10500 N. DeAnza   | Looking for an endurance ride     | AMA # 485814
Cupertino, CA     | Let me know if you're interested  | '90 FZR 600
95014             |                                   | '83 Seca 650 Turbo
+1 408 974 9111  | "Because you have to be crazy to race this piece of shit!"

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 15:50:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA04054 for xemacs-beta-people; Wed, 19 Jun 1996 15:50:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA04051 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 15:50:13 -0500 (CDT)
Received: from loiosh.kei.com (ckd@loiosh.kei.com [192.88.144.32]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA07652 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 15:50:07 -0500 (CDT)
Received: (from ckd@localhost) by loiosh.kei.com (8.7.5/8.7.3) id QAA01560 for xemacs-beta@xemacs.org; Wed, 19 Jun 1996 16:49:42 -0400 (EDT)
Date: Wed, 19 Jun 1996 16:49:42 -0400 (EDT)
From: Christopher Davis <ckd@loiosh.kei.com>
Message-Id: <199606192049.QAA01560@loiosh.kei.com>
To: xemacs-beta@xemacs.org
Subject: Re: delete-frame & the focus problem 

There used to be "allow-deletion-of-last-visible-screen".  Might be an
Epoch-ism; it's in my .emacs file from looong ago.

Change the -screen to -frame and document the sucker.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 15:52:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA04065 for xemacs-beta-people; Wed, 19 Jun 1996 15:52:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA04062 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 15:52:45 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA07658 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 15:52:42 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id OAA16459; Wed, 19 Jun 1996 14:52:46 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id OAA02013; Wed, 19 Jun 1996 14:52:44 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id OAA10003; Wed, 19 Jun 1996 14:52:27 -0600
Date: Wed, 19 Jun 1996 14:52:27 -0600
Message-Id: <199606192052.OAA10003@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: Gnus 5.2.20: thread sorting broken
Reply-To: turner@lanl.gov

This is using the 19.14b26 Solaris 2.4 binary.

I was doing:

(setq gnus-thread-sort-functions
      '(gnus-thread-sort-by-number
	gnus-thread-sort-by-subject
	gnus-thread-sort-by-score))

with 19.14b25 and it was working fine.  Great in fact; I loved it.
Can't recall what version of Gnus that was.

In any event, it isn't working with 5.2.20.

Should I be doing something different?

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 16:20:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA04258 for xemacs-beta-people; Wed, 19 Jun 1996 16:20:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA04255 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 16:20:13 -0500 (CDT)
Received: from big.aa.net (root@big.aa.net [204.157.220.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA07679 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 16:20:09 -0500 (CDT)
Received: from sym.primuscorp.com ([204.137.132.34]) by big.aa.net (8.6.12/8.6.9) with ESMTP id OAA19622 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 14:19:43 -0700
X-Intended-For: <xemacs-beta@xemacs.org>
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id OAA12346 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 14:20:25 -0700
Received: from pris by horus (SMI-8.6/SMI-SVR4)
	id OAA12210; Wed, 19 Jun 1996 14:19:47 -0700
Received: by pris (5.x/SMI-SVR4)
	id AA00934; Wed, 19 Jun 1996 14:20:08 -0700
Date: Wed, 19 Jun 1996 14:20:08 -0700
Message-Id: <9606192120.AA00934@pris>
From: Damon Lipparelli <lipp@primuscorp.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 19.14-b26: success under Solaris 2.4
Reply-To: Damon Lipparelli <lipp@primuscorp.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.14 (beta26) ]

./configure --verbose --with-gcc --cflags=-O4 --with-gnu-make --site-includes=/usr/local/include --site-libraries=/usr/local/sun4/lib --prefix=/users/lipp/xemacs-beta/19.x --exec-prefix=/users/lipp/xemacs-beta/19.x/sun4 --with-menubars=lucid --with-xpm --with-xface --with-jpeg --with-gif --with-png --with-tooltalk --with-sparcworks --with-sound=none --debug=no --error-checking=none

Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /users/lipp/src/xemacs-beta/19.x/xemacs-19.14-b26
  What installation prefix should install use?            /users/lipp/xemacs-beta/19.x
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/sun4/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in support for CDE.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.

After sticking the new version of "loaddefs-eos.elc", everything works fine.

-lipp

---

And furthermore, my bowling average is unimpeachable!!!

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 16:33:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA04323 for xemacs-beta-people; Wed, 19 Jun 1996 16:33:09 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA04320 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 16:33:08 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA07682 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 16:33:05 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id PAA04502; Wed, 19 Jun 1996 15:33:08 -0600
Received: by suomi (SMI-8.6) id PAA07418; Wed, 19 Jun 1996 15:33:07 -0600
Sender: mdb@cdc.noaa.gov
To: xemacs-beta@xemacs.org
Subject: Re: delete-frame & the focus problem
References: <199606192033.NAA12169@tinderbox.Stanford.EDU>
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 19 Jun 1996 15:33:06 -0600
In-Reply-To: David Ofelt's message of Wed, 19 Jun 1996 13:33:28 -0700
Message-ID: <vkhgs7o4x9.fsf@cdc.noaa.gov>
Lines: 27
X-Mailer: Gnus v5.2.20/XEmacs 19.14

>> On Wed, 19 Jun 1996 13:33:28 -0700,
>> David Ofelt(DO) wrote:

DO> Also, the focus lossage that people have reported under fvwm is
DO> still there.  I constantly having to iconify and uniconify my
DO> xemacs windows to get them to start displaying again.

I see this focus lossage, too, when I start something that takes a
while to load (e.g., VM or Gnus), switch desktops (and focus) to
another (non-XEmacs) window then come back to the XEmacs frame in a
few minutes.

But, since fvwm is also in beta* can one be sure XEmacs, and not
fvwm, is at fault? I've not seen the problem with other apps, but then
again I typically have many more XEmacs windows compared to other
apps. Does the focus problem with XEmacs happen under the control of
other virtual window managers (e.g., mvwm, tvtwm, ctwm, etc.)?

Just trying to insure this (annoying) problem gets logged in the right
spot...

* I'm currently using fvwm-2.0.42 w/focus-follows-mouse and a focus
policy called SloppyFocus (which just means the last window to have
focus doesn't lose it when the pointer moves over the root window).

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 16:22:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA04270 for xemacs-beta-people; Wed, 19 Jun 1996 16:22:00 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA04267 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 16:21:59 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA07424 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 16:21:59 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id OAA07503; Wed, 19 Jun 1996 14:21:10 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: b26 scrollbar placement problem
References: <12061.835210477@kocrsw12> <E0uWTDJ-0003rY-00@neal.ctd.comsat.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Neal Becker's message of 19 Jun 1996 12:46:53 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 19 Jun 1996 14:21:08 -0700
Message-ID: <m2ennb4hiz.fsf@deanna.miranova.com>
Lines: 18
X-Mailer: Gnus v5.2.22/XEmacs 19.14

>>>>> "Neal" == Neal Becker <Neal.Becker@comsat.com> writes:

Neal> Thanks for the mail bomb, Mike :)
Neal> This is tm7.67.

Neal> Signalling: (error "Unable to decode GIF" "Given file is NOT GIF
Neal> file")

It bombed me with tm7.68 as well.  This looks like a tm problem wrt to
uuencoded files as it also doesn't create them correctly.  Instead of
letting tm decode the message, use X u from Gnus to do it, and all is
well.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 17:05:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA04452 for xemacs-beta-people; Wed, 19 Jun 1996 17:05:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA04449 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 17:05:57 -0500 (CDT)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA07717 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 17:05:54 -0500 (CDT)
Received: from drich-pc.cisco.com (dhcp-h21-207.cisco.com [171.68.192.207]) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id PAA03284 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 15:04:10 -0700
Message-Id: <2.2.32.19960619220554.006c343c@diablo.cisco.com>
X-Sender: drich@diablo.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 19 Jun 1996 15:05:54 -0700
To: xemacs-beta@xemacs.org
From: Dan Rich <drich@cisco.com>
Subject: Re: 19.14b26 on SunOS 4.1.3_U1 -- problems

At 11:26 AM 6/19/96 -0700, Dan Rich wrote:
>The only problem I have seen so far is one I reported earlier, it
>sometimes doesn't update the display.

OK, here's a little more info about this problem.  It only happens after I
minimize (iconify) a window, and I can always start redisplay working again
by creating and then deleting a new frame.

Is anyone else seeing this, and does anyone have any ideas how I can track
this down a little more (would a trace run help the next time it happens?)

This is pretty much a standard build, and has been patched up since b23.

Dan Rich <drich@cisco.com>    | http://reality.sgi.com/employees/drich/
Webmaster                     | "Danger, you haven't seen the last of me!"
Cisco Systems, Inc.           |   "No, but the first of you turns my stomach!"
(408) 527-3195                |           -- The Firesign Theatre's Nick Danger


From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 16:59:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA04403 for xemacs-beta-people; Wed, 19 Jun 1996 16:59:33 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA04400 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 16:59:32 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA07989 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 16:59:33 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id QAA29605 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 16:59:02 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id QAA19904 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 16:59:02 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id RAA19008 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 17:54:17 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Configuring for multiple architectures
Date: Wed, 19 Jun 1996 17:54:18 -0400
Message-ID: <22621.835221258@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

For 19.13, I built versions for solaris and sunos.  Using the model
given in the pre-built versions, the arch-independent (lisp) stuff
went in /apps/public/XEmacs/19.13/lib/xemacs-19.13, but the
executables went in /apps/public/XEmacs/19.13/bin/arch.  Like this:

	/apps/public/XEmacs/19.13
		bin
			solaris2.4
		bin
			sunos4.1.3
		lib
			xemacs
			xemacs-19.13
		man

This works just fine.

How do I do this with 19.14?  I tried to configure with
--exec-prefix=/apps/public/XEmacs/19.14/bin/arch, but, as INSTALL
says, the execs get installed in EXECDIR/bin.  If I do so, xemacs
can't find its lisp files.  I suppose I could put in symlinks, but I
was hoping for a better, more automatic solution.

Any other suggestions?  Am I doing the config right?

Thanks,

Ray

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 17:19:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA04591 for xemacs-beta-people; Wed, 19 Jun 1996 17:19:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA04588 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 17:19:23 -0500 (CDT)
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA09835 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 17:19:20 -0500 (CDT)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0uWVCt-00002AC>; Wed, 19 Jun 96 23:54 MET DST
Message-Id: <m0uWVCt-00002AC@susan.logware.de>
Date: Thu, 20 Jun 96 00:19 MET DST
From: Michael Diers <mdiers@logware.de>
To: XEmacs beta list <xemacs-beta@cs.uiuc.edu>
Subject: Re: 19.14b26 qualified success on SCO/OSR5
In-Reply-To: <9606190016.aa05844@caddy.arnet.com>
References: <199606190323.WAA24419@xemacs.cs.uiuc.edu>
	<9606190016.aa05844@caddy.arnet.com>

Robert Lipe <robertl@arnet.com> wrote:

> Current unresolved issues on SCO.
[...]
> 	M-x getenv still fails on my machine regardless of compiler
> (sco or gcc) used, but only if dynamically linked.  This means
> default installation fails becuase the binary can't grok $PATH Kean
> doesn't see this on his system.  We are still investigating.
[...]

Doing configure w/ --dynamic, I still see a core dump on OS5 with
19.14-b26. No C backtrace available, dbx dies instantly. I think we
agree that the system I'm on is broken as can be.

Building *statically* does produce a working binary, though.

$ ./xemacs -nw -q -no-site-file
Fatal error: assertion failed, file
/usr/contrib/pub/src/xemacs-19.14-b26/src/eval.c, line 1903, abort()

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb `which xemacs` core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  sit-for(0)
  byte-code("  # eb!         " [add-timeout
startup-message-timeout #<compiled-function (from "startup.elc")
(ignore) "...(5)" [nil ... ...] 3> nil timeout startup-splash-frame
sit-for 0 next-command-event unread-command-event] 4)
  # (catch timeout ...)
  # (unwind-protect ...)
  # bind (timeout)
  command-line-1()
  # bind (command-line-args-left)
  command-line()
  # (unwind-protect ...)
  normal-top-level()
  # (condition-case ... . error)
  # (catch top-level ...)
ABORT instruction (core dumped)
$ dbx ./xemacs core
dbx: fatal error: Address already in use

-Michael


configure script
================

#!/bin/sh

name=xemacs
version=${1}

pkgname=${name}-${version}

src=/usr/contrib/pub/src/${pkgname}
pre=/usr/contrib/pkg/${pkgname}

cnf=`${src}/config.guess`
echo "Configuring ${pkgname} for ${cnf}"

build=/usr/contrib/pub/build/${pkgname}-${cnf}
mkdir ${build} 2>/dev/null
cd ${build}

PATH="/usr/bin:/bin:/usr/bin/X11"
export PATH

${src}/configure ${cnf} \
  --verbose \
  --extra-verbose \
  --with-gcc=no \
  --srcdir=${src} \
  --prefix=${pre} \
  --bindir=${pre}/${cnf}/bin \
  --dynamic

# eof


configure output
================

cd /usr/contrib/pub/build/xemacs-19.14-b26-i586-unknown-sco3.2v5.0.0/src/
~/contrib/scripts/cnf-xemacs 19.14-b26
Configuring xemacs-19.14-b26 for i586-unknown-sco3.2v5.0.0
checking for ln -s
	setting LN_S to ln -s
checking the configuration name
checking how to run the C preprocessor
	setting CPP to /lib/cpp -D_XOPEN_SOURCE -D_SCO_ELF
	setting RANLIB to ranlib
checking for a BSD compatible install
	setting INSTALL to /usr/bin/X11/scoinst -c
	setting INSTALL_PROGRAM to ${INSTALL}
	setting INSTALL_DATA to ${INSTALL} -m 644
checking for bison
checking for byacc
checking for AIX
checking for mach/mach.h
conftest.c: 3: Can't find include file mach/mach.h
checking for sys/stropts.h
	defining HAVE_SYS_STROPTS_H
checking for sys/timeb.h
	defining HAVE_SYS_TIMEB_H
checking for sys/time.h
	defining HAVE_SYS_TIME_H
checking for unistd.h
	defining HAVE_UNISTD_H
checking for utime.h
	defining HAVE_UTIME_H
checking for sys/wait.h
	defining HAVE_SYS_WAIT_H
checking for libintl.h
conftest.c: 3: Can't find include file libintl.h
checking for locale.h
	defining HAVE_LOCALE_H
checking for libgen.h
	defining HAVE_LIBGEN_H
checking for linux/version.h
conftest.c: 3: Can't find include file linux/version.h
checking for ANSI C header files
	defining STDC_HEADERS
checking for whether time.h and sys/time.h may both be included
	defining TIME_WITH_SYS_TIME
checking for sys_siglist declaration in signal.h or unistd.h
"conftest.c", line 8: error: undefined symbol: sys_siglist
"conftest.c", line 8: error: cannot dereference non-pointer type
"conftest.c", line 8: warning: improper pointer/integer combination: op "="
checking for struct utimbuf
	defining HAVE_STRUCT_UTIMBUF
checking for return type of signal handlers
	defining RETSIGTYPE to be void
checking for struct timeval
	defining HAVE_TIMEVAL
checking for struct tm in time.h
checking for tm_zone in struct tm
"conftest.c", line 7: error: undefined struct/union member: tm_zone
checking for tzname
	defining HAVE_TZNAME
checking for lack of working const
checking byte ordering
checking for long file names
	defining HAVE_LONG_FILE_NAMES
checking for -xildoff compiler flag
checking for specified window system
  No window system specified.  Looking for X11.
checking for X include and library files with xmkmf
  Using X11.
examining the machine- and system-dependent files to find out
 - which libraries the lib-src programs will want, and
 - whether the GNU malloc routines are usable.
checking for -ldnet
ld crtn.o: can't find library libdnet.a
checking for -lXbsd
ld crtn.o: can't find library libXbsd.a
checking for -lpthreads
ld crtn.o: can't find library libpthreads.a
checking for XFree86
	no
checking for -lX11
	yes
checking for -lXau
ld crtn.o: can't find library libXau.a
checking for -lDtSvc
ld crtn.o: can't find library libDtSvc.a
	defining HAVE_XLOCALE_H
checking the version of X11 being used
	defining THIS_IS_X11R5
checking for X11/Xlocale.h
	defining HAVE_X11_XLOCALE_H
checking for -lm
	defining HAVE_LIBM
checking for -lXpm
ld crtn.o: can't find library libXpm.a
checking for -lXmu
	defining HAVE_XMU
checking for compface.h
conftest.c: 3: Can't find include file compface.h
	defining HAVE_GIF
checking for jpeglib.h
conftest.c: 3: Can't find include file jpeglib.h
checking for png.h
conftest.c: 3: Can't find include file png.h
checking for -lXm
	Found Motif
checking for declaration of h_errno in netdb.h
"conftest.c", line 4: error: undefined symbol: h_errno
checking for sigsetjmp
	defining HAVE_SIGSETJMP
checking whether localtime caches TZ
checking whether cross-compiling
	no
checking for whether gettimeofday can't accept two arguments
	no
checking for whether inline functions are supported
"conftest.c", line 5: error: undefined symbol: inline
"conftest.c", line 5: error: Syntax error before or at: int
"conftest.c", line 10: warning: syntax violation:  empty declaration
"conftest.c", line 10: error: Syntax error before or at: return
"conftest.c", line 10: warning: syntax violation:  empty declaration
checking for working alloca.h
"conftest.c", line 2: error: cannot find include file: <alloca.h>
"conftest.c", line 4: warning: improper pointer/integer combination: op "="
checking for alloca
	defining HAVE_ALLOCA
checking for pid_t in sys/types.h
checking for vfork.h
conftest.c: 3: Can't find include file vfork.h
checking for working vfork
checking for strcoll
	defining HAVE_STRCOLL
checking size of short
	defining SIZEOF_SHORT to be 2
checking size of int
	defining SIZEOF_INT to be 4
checking size of long
	defining SIZEOF_LONG to be 4
checking for acosh
	defining HAVE_ACOSH
checking for asinh
	defining HAVE_ASINH
checking for atanh
	defining HAVE_ATANH
checking for cbrt
	defining HAVE_CBRT
checking for closedir
	defining HAVE_CLOSEDIR
checking for dup2
	defining HAVE_DUP2
checking for eaccess
	defining HAVE_EACCESS
checking for fmod
	defining HAVE_FMOD
checking for fpathconf
	defining HAVE_FPATHCONF
checking for frexp
	defining HAVE_FREXP
checking for ftime
	defining HAVE_FTIME
checking for gethostname
	defining HAVE_GETHOSTNAME
checking for getpagesize
	defining HAVE_GETPAGESIZE
checking for gettimeofday
	defining HAVE_GETTIMEOFDAY
checking for getwd
	defining HAVE_GETWD
checking for logb
	defining HAVE_LOGB
checking for lrand48
	defining HAVE_LRAND48
checking for matherr
	defining HAVE_MATHERR
checking for mkdir
	defining HAVE_MKDIR
checking for mktime
	defining HAVE_MKTIME
checking for perror
	defining HAVE_PERROR
checking for poll
	defining HAVE_POLL
checking for random
	defining HAVE_RANDOM
checking for realpath
	defining HAVE_REALPATH
checking for rename
	defining HAVE_RENAME
checking for res_init
	defining HAVE_RES_INIT
checking for rint
	defining HAVE_RINT
checking for rmdir
	defining HAVE_RMDIR
checking for select
	defining HAVE_SELECT
checking for setitimer
	defining HAVE_SETITIMER
checking for setpgid
	defining HAVE_SETPGID
checking for setlocale
	defining HAVE_SETLOCALE
checking for setsid
	defining HAVE_SETSID
checking for sigblock
undefined			first referenced
 symbol  			    in file
sigblock                            conftest.o
ld fatal: Symbol referencing errors. No output written to conftest
checking for sighold
	defining HAVE_SIGHOLD
checking for sigprocmask
	defining HAVE_SIGPROCMASK
checking for strerror
	defining HAVE_STRERROR
checking for tzset
	defining HAVE_TZSET
checking for utimes
	defining HAVE_UTIMES
checking for waitpid
	defining HAVE_WAITPID
checking for mmap
	defining HAVE_MMAP
checking for socket
checking for netinet/in.h
checking for arpa/inet.h
	defining HAVE_SOCKETS
checking for sun_len member in struct sockaddr_un
"conftest.c", line 6: error: undefined struct/union member: sun_len
checking for dirent.h
	defining SYSV_SYSTEM_DIR
checking how to do terminal I/O
checking for termios.h
	defining HAVE_TERMIOS
checking for nlist.h
	defining NLIST_STRUCT
checking for -lncurses
ld crtn.o: can't find library libncurses.a
checking for -ldb
ld crtn.o: can't find library libdb.a
checking for dbopen
undefined			first referenced
 symbol  			    in file
dbopen                              conftest.o
ld fatal: Symbol referencing errors. No output written to conftest
checking for -lgdbm
ld crtn.o: can't find library libgdbm.a
checking for -ldbm
	defining HAVE_LIBDBM
	defining HAVE_DBM
	defining EMACS_CONFIGURATION to be "i586-unknown-sco3.2v5.0.0"
	defining config_machfile to be "m/intel386.h"
	defining config_opsysfile to be "s/sco5-shr.h"
	defining LD_SWITCH_X_SITE to be 
	defining LD_SWITCH_X_SITE_AUX to be 
	defining C_SWITCH_X_SITE to be 
	defining LD_SWITCH_SITE to be 
	defining C_SWITCH_SITE to be 
	defining UNEXEC_SRC to be unexelf.c
	defining HAVE_X_WINDOWS
	defining GNU_MALLOC
	defining REL_ALLOC
	defining LISP_FLOAT_TYPE
	defining LWLIB_USES_MOTIF
	defining LWLIB_MENUBARS_LUCID
	defining HAVE_MENUBARS
	defining LWLIB_SCROLLBARS_LUCID
	defining HAVE_SCROLLBARS
	defining LWLIB_DIALOGS_MOTIF
	defining HAVE_DIALOGS
	defining HAVE_TOOLBARS
	defining HAVE_TTY
	defining CONST_IS_LOSING
	defining USE_ASSERTIONS
	defining ERROR_CHECK_EXTENTS
	defining ERROR_CHECK_TYPECHECK
	defining ERROR_CHECK_BUFPOS
	defining ERROR_CHECK_GC
	defining ERROR_CHECK_MALLOC
	defining DEBUG_XEMACS
	defining NO_UNION_TYPE


Configured for `i586-unknown-sco3.2v5.0.0'.

  Where should the build process find the source code?    /usr/contrib/pub/src/xemacs-19.14-b26
  What installation prefix should install use?		  /usr/contrib/pkg/xemacs-19.14-b26
  What operating system and machine description files should XEmacs use?
        `s/sco5-shr.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              cc -g 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


creating config.status
creating Makefile
creating lib-src/Makefile.in
creating man/Makefile.in
creating src/Makefile.in
creating lwlib/Makefile.in
creating dynodump/Makefile.in
creating src/config.h
creating src/Makefile
0: unknown flag -Xc
creating lwlib/Makefile
0: unknown flag -Xc
creating lib-src/Makefile
0: unknown flag -Xc
creating dynodump/Makefile
0: unknown flag -Xc
creating man/Makefile
0: unknown flag -Xc

Compilation finished at Wed Jun 19 23:19:48

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 17:43:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA04692 for xemacs-beta-people; Wed, 19 Jun 1996 17:43:19 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA04689 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 17:43:18 -0500 (CDT)
Received: from mimbres.cs.unm.edu (mimbres.cs.unm.edu [198.59.151.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA07746 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 17:43:14 -0500 (CDT)
Received: from hawaii.cs.unm.edu by mimbres.cs.unm.edu (5.65/033093) with SMTP
	id <AA09653@mimbres.cs.unm.edu>; Wed, 19 Jun 96 16:43:17 -0600
Received: by hawaii.cs.unm.edu (Smail3.1.28.1 #1)
	id m0uWVy0-0001KhC; Wed, 19 Jun 96 16:43 MDT
To: xemacs-beta@xemacs.org
Subject: 19.14-b26 success: Irix 5.3
From: Jason Stewart <jasons@cs.unm.edu>
Date: 19 Jun 1996 16:43:15 -0600
Message-Id: <xjnrarbwh30.fsf@hawaii.cs.unm.edu>
Lines: 32
X-Mailer: Gnus v5.2.9/XEmacs 19.13


./configure  --site-includes=/cs/gslocal/include --site-libraries=/cs/gslocal/lib
- You did not tell me what kind of host system you want to configure.
- I will attempt to guess the kind of system this is.
- Looks like this is a mips-sgi-irix5.3

Configured for `mips-sgi-irix5.3'.

  Where should the build process find the source code?    /nfs/scratch/jasons/sgi/xemacs-19.14-b26
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/irix5-3.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /cs/gslocal/include
  Additional libraries:                                   /cs/gslocal/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


It even works with -nw (Yeah!!!).

jas.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 17:33:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA04628 for xemacs-beta-people; Wed, 19 Jun 1996 17:33:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA04625 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 17:33:37 -0500 (CDT)
Received: from pallas.spacetec.no (pallas.spacetec.no [192.51.5.92]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA07727 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 17:33:32 -0500 (CDT)
Received: (from tor@localhost) by pallas.spacetec.no (8.7.1/8.7.1) id AAA19842 for xemacs-beta@xemacs.org; Thu, 20 Jun 1996 00:34:22 +0200
Message-Id: <199606192234.AAA19842@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Thu, 20 Jun 1996 00:34:20 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: xemacs-beta@xemacs.org
Subject: 19.14-b26 IRIX 5.3 ~ok

./configure --with-gcc=no --dynamic --with-xpm --with-sound=no \
--x-includes=/usr/local/include --with-menubars=lucid \
--with-scrollbars=lucid --with-dialogs=motif --with-tooltalk=no \
--const-is-losing=no --with-png=no

Configured for `mips-sgi-irix5.3'.

  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/irix5-3.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              cc -g
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/local/include
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

So far so good.  I'm only doing C editing with it.
I ran into a little snag in the build though, it picked up SGI's
/usr/lib/libXpm.so (because of --dynamic?) instead of my own libXpm in 
/usr/local/lib, and although things built ok the toolbar had no icons 
and the warnings buffer quickly filled up with xpm errors.  I was a bit
confused by this until I found out about /usr/lib/libXpm.so using elfdump -Dl
(almost same as 'ldd' on other systems').  In order to check that out quickly
I just did a more or less manual re-link of temacs with -L/usr/local/lib,
and everything looks normal now.  I'll figure out the right switch to use for
this before my next build.
(Maybe a little warning about using xpm and --dynamic on IRIX somewhere
 in PROBLEMS could be an idea?)

Tor

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 18:29:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA04888 for xemacs-beta-people; Wed, 19 Jun 1996 18:29:51 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA04885 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 18:29:50 -0500 (CDT)
Received: from tinderbox.Stanford.EDU (tinderbox.Stanford.EDU [171.64.72.13]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA07760 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 18:29:46 -0500 (CDT)
Received: by tinderbox.Stanford.EDU (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id QAA21941; Wed, 19 Jun 1996 16:29:50 -0700
Date: Wed, 19 Jun 1996 16:29:50 -0700
Message-Id: <199606192329.QAA21941@tinderbox.Stanford.EDU>
From: David Ofelt <ofelt@tinderbox.Stanford.EDU>
To: xemacs-beta@xemacs.org
Subject: Re: delete-frame & the focus problem
In-Reply-To: <vkhgs7o4x9.fsf@cdc.noaa.gov>
References: <199606192033.NAA12169@tinderbox.Stanford.EDU>
	<vkhgs7o4x9.fsf@cdc.noaa.gov>

Mark Borges writes:
 > But, since fvwm is also in beta* can one be sure XEmacs, and not
 > fvwm, is at fault? I've not seen the problem with other apps, but then
 > again I typically have many more XEmacs windows compared to other
 > apps. Does the focus problem with XEmacs happen under the control of
 > other virtual window managers (e.g., mvwm, tvtwm, ctwm, etc.)?

I've never had the focus-lossage problem with any other application
besides XEmacs.  I remember that the 19.13 betas also had this problem
for a while, but it was fixed by the final release.  

DaveO


From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 18:57:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA04937 for xemacs-beta-people; Wed, 19 Jun 1996 18:57:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA04934 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 18:57:31 -0500 (CDT)
Received: from mimbres.cs.unm.edu (mimbres.cs.unm.edu [198.59.151.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA07821 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 18:57:26 -0500 (CDT)
Received: from hawaii.cs.unm.edu by mimbres.cs.unm.edu (5.65/033093) with SMTP
	id <AA10723@mimbres.cs.unm.edu>; Wed, 19 Jun 96 17:57:28 -0600
Received: by hawaii.cs.unm.edu (Smail3.1.28.1 #1)
	id m0uWX7n-0001MkC; Wed, 19 Jun 96 17:57 MDT
To: xemacs-beta@xemacs.org
Subject: 19.14-b26 success on sparc-sun-sunos4.1.4
From: Jason Stewart <jasons@cs.unm.edu>
Date: 19 Jun 1996 17:57:25 -0600
Message-Id: <xjnpw6vwdne.fsf@hawaii.cs.unm.edu>
Lines: 32
X-Mailer: Gnus v5.2.9/XEmacs 19.13

./configure  --site-includes=/cs/gslocal/include
--site-libraries=/cs/gslocal/lib --with-xmu=yes


Configured for `sparc-sun-sunos4.1.4'.

  Where should the build process find the source code?    /nfs/u8/jasons/scratch/sun/xemacs-19.14-b26
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sunos4-1-3.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/local/X11R5/include
  Where do we find X Windows libraries?                   /usr/local/X11R5/lib
  Additional header files:                                /cs/gslocal/include
  Additional libraries:                                   /cs/gslocal/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

Without the -with-xmu=yes it couldn't find libXmu and it got a number
of undefinded symbols.

jas.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 19:11:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA05043 for xemacs-beta-people; Wed, 19 Jun 1996 19:11:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA05040 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 19:11:56 -0500 (CDT)
Received: from schizo.cdsnet.net (schizo.cdsnet.net [204.118.244.32]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA08098 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 19:11:51 -0500 (CDT)
Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.7.5/8.6.12) id RAA17736; Wed, 19 Jun 1996 17:17:09 -0700 (PDT)
Date: Wed, 19 Jun 1996 17:17:09 -0700 (PDT)
Message-Id: <199606200017.RAA17736@schizo.cdsnet.net>
From: Jaye Mathisen <mrcpu@schizo.cdsnet.net>
To: xemacs-beta@xemacs.org
Subject: 19.14 b26 OK on FreeBSD 2.1, with 1 problem


Fired up several VM's, then Saved and Quitted.  My last xemacs screen
has the VM toolbar down the side, but the XEmacs menu options and
choices, and the buffer is the *scratch* buffer.

Seems like the toolbar should've hit the road.

So something is weird.  And the grossly oversized motif pop-ups
previously mentioned..

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 20:26:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA05182 for xemacs-beta-people; Wed, 19 Jun 1996 20:26:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA05179 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 20:26:25 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA13000 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 20:26:20 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id TAA20909; Wed, 19 Jun 1996 19:26:21 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id TAA04607; Wed, 19 Jun 1996 19:26:19 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id TAA10191; Wed, 19 Jun 1996 19:26:00 -0600
Date: Wed, 19 Jun 1996 19:26:00 -0600
Message-Id: <199606200126.TAA10191@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: larsi@ifi.uio.no
Cc: xemacs-beta@xemacs.org
Subject: Re: GNUS crash
In-Reply-To: <x6wx16cvwu.fsf@eyesore.no>
References: <199606100538.XAA20844@gielgud.lanl.gov.xdiv>
	<x6wx16cvwu.fsf@eyesore.no>
Reply-To: turner@lanl.gov

Lars Magne Ingebrigtsen writes:
 > turner@xdiv.lanl.gov (John Turner) writes:
 > >   Trying to use the scrollbar, however, results in
 > > 
 > >   Key read has no ASCII equivalent #<misc-user-event (scrollbar-vertical-drag (#<window on "*Score Help*" 0x1b7d> . 90))>
 > 
 > `(setq debug-on-error t)', repeat the bug and mail me the backtrace.

This no longer happens (19.14b26), so never mind...

-John

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 20:34:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA05195 for xemacs-beta-people; Wed, 19 Jun 1996 20:34:16 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA05192 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 20:34:15 -0500 (CDT)
Received: from GS213.SP.CS.CMU.EDU (GS213.SP.CS.CMU.EDU [128.2.209.183]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA13003 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 20:34:11 -0500 (CDT)
Received: by GS213.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA41036; Wed, 19 Jun 1996 21:34:14 -0400
Date: Wed, 19 Jun 1996 21:34:14 -0400
Message-Id: <9606200134.AA41036@GS213.SP.CS.CMU.EDU>
From: Darrell Kindred <dkindred+@cmu.edu>
To: xemacs-beta@xemacs.org
Subject: gnuattach problems

Noticed a few problems I don't have time to work on tonight.
The first seems pretty important, the others are minor.

- Run xemacs in the background (tcsh 6.04), then run gnuattach in the
  same tty to connect to it.  Both XEmacs and gnuattach hang (XEmacs
  is hung with tty output).  Putting gnuattach in the background and
  foregrounding XEmacs reactivates it.  If this condition can't be
  handled properly, can it at least be detected so gnuattach can exit
  with an error rather than blocking?  Or is this all beyond
  xemacs/gnuattach's control?

- Run gnuattach then exit with C-x #.  I don't get a shell prompt until
  I press return.  Maybe gnuattach is exiting before xemacs is quite done
  with the tty?

- When you start 'gnuattach' with no arguments, it seems the only way
  to end the session is to do C-x # in the *scratch* buffer, which
  kills it.  Maybe there should be another way.

- Darrell

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 20:42:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA05212 for xemacs-beta-people; Wed, 19 Jun 1996 20:42:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA05209 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 20:42:07 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA20293 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 20:42:09 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id SAA11724; Wed, 19 Jun 1996 18:41:37 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id SAA28707; Wed, 19 Jun 1996 18:41:34 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA11341; Wed, 19 Jun 1996 18:41:32 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA27212; Wed, 19 Jun 1996 18:41:28 -0700
Date: Wed, 19 Jun 1996 18:41:28 -0700
Message-Id: <199606200141.SAA27212@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: ``XEmacs does not have the features to support lazy-lock.el''
Reply-To: Martin Buchholz <mrb@eng.sun.com>

Here is an excerpt from the recently posted lazy-lock.el, which
suggests that XEmacs is deficient...

;; Implementation differences with version 1:
;;
;; - Version 1 of lazy-lock.el is a bit of a hack.  Version 1 demand-driven
;; fontification, the core feature of lazy-lock.el, is implemented by placing a
;; function on `post-command-hook'.  This function fontifies where necessary,
;; i.e., where a window scroll has occurred.  However, there are a number of
;; problems with using `post-command-hook':
;;
;; (a) As the name suggests, `post-command-hook' is run after every command,
;;     i.e., frequently and regardless of whether scrolling has occurred.
;; (b) Scrolling can occur during a command, when `post-command-hook' is not
;;     run, i.e., it is not necessarily run after scrolling has occurred.
;; (c) When `post-command-hook' is run, there is nothing to suggest where
;;     scrolling might have occurred, i.e., which windows have scrolled.
;;
;; Thus lazy-lock.el's function is called almost as often as possible, usually
;; when it need not be called, yet it is not always called when it is needed.
;; Also, lazy-lock.el's function must check each window to see if a scroll has
;; occurred there.  Worse still, lazy-lock.el's function must fontify a region
;; twice as large as necessary to make sure the window is completely fontified.
;; Basically, `post-command-hook' is completely inappropriate for lazy-lock.el.
;;
;; Ideally, we want to attach lazy-lock.el's function to a hook that is run
;; only when scrolling occurs, e.g., `window-start' has changed, and tells us
;; as much information as we need, i.e., the window and its new buffer region.
;; Richard Stallman implemented a `window-scroll-functions' for Emacs 19.30.
;; Functions on it are run when `window-start' has changed, and are supplied
;; with the window and the window's new `window-start' position.  (It would be
;; better if it also supplied the window's new `window-end' position, but that
;; is calculated as part of the redisplay process, and the functions on
;; `window-scroll-functions' are run before redisplay has finished.)  Thus, the
;; hook deals with the above problems (a), (b) and (c).
;;
;; If only life was that easy.  Version 2 demand-driven fontification is mostly
;; implemented by placing a function on `window-scroll-functions'.  However,
;; not all scrolling occurs when `window-start' has changed.  A change in
;; window size, e.g., via C-x 1, or a significant deletion, e.g., of a number
;; of lines, causes `window-end' to change without changing `window-start'.
;; Arguably, these events are not scrolling events, but fontification must
;; occur for lazy-lock.el to work.  Hooks `window-size-change-functions' and
;; `redisplay-end-trigger-functions' were added for these circumstances.
;;
;; Ben Wing thinks these hooks are "horribly horribly kludgy", and implemented
;; a `pre-idle-hook', a `mother-of-all-post-command-hooks', for XEmacs 19.14.
;; He then hacked up a version 1 lazy-lock.el to use `pre-idle-hook' rather
;; than `post-command-hook'.  Whereas functions on `post-command-hook' are
;; called almost as often as possible, functions on `pre-idle-hook' really are
;; called as often as possible, even when the mouse moves and, on some systems,
;; while XEmacs is idle.  Thus, the hook deals with the above problem (b), but
;; unfortunately it makes (a) worse and does not address (c) at all.
;;
;; I freely admit that `redisplay-end-trigger-functions' and, to a much lesser
;; extent, `window-size-change-functions' are not pretty.  However, I feel that
;; a `window-scroll-functions' feature is cleaner than a `pre-idle-hook', and
;; the result is faster and smaller, less intrusive and more targeted, code.
;; Since `pre-idle-hook' is pretty much like `post-command-hook', there is no
;; point in making this version of lazy-lock.el work with it.  Anyway, that's
;; Lit 30 of my humble opinion.
;;
;; - Version 1 stealth fontification is also implemented by placing a function
;; on `post-command-hook'.  This function waits for a given amount of time,
;; and, if Emacs remains idle, fontifies where necessary.  Again, there are a
;; number of problems with using `post-command-hook':
;;
;; (a) Functions on `post-command-hook' are run sequentially, so this function
;;     can interfere with other functions on the hook, and vice versa.
;; (b) This function waits for a given amount of time, so it can interfere with
;;     various features that are dealt with by Emacs after a command, e.g.,
;;     region highlighting, asynchronous updating and keystroke echoing.
;; (c) Fontification may be required during a command, when `post-command-hook'
;;     is not run.  (Version 2 deferred fontification only.)
;;
;; Again, `post-command-hook' is completely inappropriate for lazy-lock.el.
;; Richard Stallman and Morten Welinder implemented internal Timers and Idle
;; Timers for Emacs 19.31.  Functions can be run independently at given times
;; or after given amounts of idle time.  Thus, the feature deals with the above
;; problems (a), (b) and (c).  Version 2 deferral and stealth are implemented
;; by functions on Idle Timers.  (A function on XEmacs' `pre-idle-hook' is
;; similar to an Emacs Idle Timer function with a fixed zero second timeout.
;; Hey, maybe I could stop using `window-scroll-functions' for demand-driven
;; fontification and use a zero second Emacs Idle Timer instead?  Only joking!)

;; Caveats:
;;
;; Lazy Lock mode does not work efficiently with Outline mode.  This is because
;; when in Outline mode, although text may be hidden (not visible in the
;; window), the text is visible to Emacs Lisp code (not surprisingly) and Lazy
;; Lock fontifies it mercilessly.  Hopefully this will be fixed one day.
;;
;; Because buffer text is not necessarily fontified, other packages that expect
;; buffer text to be fontified in Font Lock mode either might not work as
;; expected, or might not display buffer text as expected.  An example of the
;; latter is `occur', which copies lines of buffer text into another buffer.
;;
;; In Emacs 19.30, Lazy Lock mode does not ensure that an existing buffer is
;; fontified if it is made visible via a minibuffer-less command that replaces
;; an existing window's buffer (e.g., via the Buffers menu).  Upgrade!
;;
;; In Emacs 19.30, Lazy Lock mode does not work well with Transient Mark mode
;; or modes based on Comint mode (e.g., Shell mode), and also interferes with
;; the echoing of keystrokes in the minibuffer.  This is because of the way
;; deferral and stealth have to be implemented for Emacs 19.30.  Upgrade!
;;
;; Currently XEmacs does not have the features to support lazy-lock.el.  Maybe
;; it will one day.


From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 21:08:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA05333 for xemacs-beta-people; Wed, 19 Jun 1996 21:08:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA05330 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 21:08:41 -0500 (CDT)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA13070 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 21:08:38 -0500 (CDT)
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
	id AA16193; Wed, 19 Jun 96 22:06:57 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA08037; Wed, 19 Jun 1996 22:08:38 -0400
Date: Wed, 19 Jun 1996 22:08:38 -0400
Message-Id: <9606200208.AA08037@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Darrell Kindred <dkindred+@cmu.edu>
Cc: xemacs-beta@xemacs.org
In-Reply-To: Darrell Kindred's message of Tue, 18 Jun 1996 15:10:42 -0400,
	<9606181910.AA35159@GS213.SP.CS.CMU.EDU>
Subject: Re: [PATCH] linux ^@ problem fixed
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091

   Date: Tue, 18 Jun 1996 15:10:42 -0400
   From: Darrell Kindred <dkindred+@cmu.edu>

   Anyway, I finally got around to investigating this.  It turns out that
   "packet mode" isn't turned off when a pty is closed under linux, so
   sometimes the pty XEmacs gets is in packet mode, and each read starts
   with the single byte, TIOCPKT_DATA (which is zero).

Yup; this is a bug in Linux.

   Coincidentally, it looks like Ted Ts'o (tytso@mit.edu) introduced a
   fix for this in Linux kernel pre2.0.13 (two weeks ago), but it caused
   rlogin/telnet problems, so he backed it out in pre2.0.14.

Well, it turns out I was too enthusiastic with my bug fix, and cleared
packet mode on a hangup or vhangup.  Problem was that rlogin/telnet
calls vhangup(), and clearing packet mode caused the wrong thing to happen.

   The patch below clears packet-mode when a pty is opened, which
   eliminates the problem.  I hope we can get this in 19.14.

This patch you've listed below is perfectly safe on all systems, and
it's a good one to put in.  Yes, I believe FSF emacs 19.31 suffers from
the same problem.

If you're interested, here's the patch to the Linux kernel (versus 2.0)
that fixes the problem in the kernel.  I expect this will make it into
2.1.

							- Ted

===================================================================
RCS file: drivers/char/pty.c,v
retrieving revision 1.1
diff -u -r1.1 drivers/char/pty.c
--- drivers/char/pty.c	1996/06/10 23:35:19	1.1
+++ drivers/char/pty.c	1996/06/10 23:38:24
@@ -74,8 +74,10 @@
 	}
 	wake_up_interruptible(&tty->read_wait);
 	wake_up_interruptible(&tty->write_wait);
+	tty->packet = 0;
 	if (!tty->link)
 		return;
+	tty->link->packet = 0;
 	wake_up_interruptible(&tty->link->read_wait);
 	wake_up_interruptible(&tty->link->write_wait);
 	set_bit(TTY_OTHER_CLOSED, &tty->link->flags);

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 21:33:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA05393 for xemacs-beta-people; Wed, 19 Jun 1996 21:33:54 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA05390 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 21:33:52 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA20917 for <xemacs-beta@cs.uiuc.edu>; Wed, 19 Jun 1996 21:33:53 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA14583; Wed, 19 Jun 1996 19:33:03 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: delete-frame & the focus problem
References: <199606192033.NAA12169@tinderbox.Stanford.EDU>
	<vkhgs7o4x9.fsf@cdc.noaa.gov>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Mark Borges's message of 19 Jun 1996 14:33:06 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 19 Jun 1996 19:33:01 -0700
Message-ID: <m2688n4336.fsf@deanna.miranova.com>
Lines: 37
X-Mailer: Gnus v5.2.22/XEmacs 19.14

>>>>> "Mark" == Mark Borges <mdb@cdc.noaa.gov> writes:

>>> On Wed, 19 Jun 1996 13:33:28 -0700,
>>> David Ofelt(DO) wrote:

DO> Also, the focus lossage that people have reported under fvwm is
DO> still there.  I constantly having to iconify and uniconify my
DO> xemacs windows to get them to start displaying again.

Mark> I see this focus lossage, too, when I start something that takes a
Mark> while to load (e.g., VM or Gnus), switch desktops (and focus) to
Mark> another (non-XEmacs) window then come back to the XEmacs frame in a
Mark> few minutes.

Mark> But, since fvwm is also in beta* can one be sure XEmacs, and not
Mark> fvwm, is at fault? I've not seen the problem with other apps,
Mark> but then again I typically have many more XEmacs windows
Mark> compared to other apps. Does the focus problem with XEmacs
Mark> happen under the control of other virtual window managers (e.g.,
Mark> mvwm, tvtwm, ctwm, etc.)?

Yes, this is the same problem I reported earlier in conjuction with
olvwm (which is not a beta).

Throwing the focus around amongst frames loses bigtime when the frames
may be in other virtual desktops.

C-x 5 b and C-x 5 f have a lot of weird lossage associated with this
as well when focus-follows-mouse policy is in effect.

An acceptable fix for me is to have a variable that when set, causes
XEmacs to never touch the focus whatsoever.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 21:53:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA05426 for xemacs-beta-people; Wed, 19 Jun 1996 21:53:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA05423 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 21:53:57 -0500 (CDT)
Received: from spsgate.sps.mot.com (spsgate.sps.mot.com [192.70.231.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA13171 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 21:53:45 -0500 (CDT)
Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93)
	id AA11003 for xemacs-beta@xemacs.org; Wed, 19 Jun 96 19:53:47 MST
Received: from asc.sps.mot.com ([223.1.132.19]) by mogate (4.1/SMI-4.1/Email-2.0)
	id AA10489 for xemacs-beta@xemacs.org; Wed, 19 Jun 96 19:53:40 MST
Received: (from rwhitby@localhost) by asc.sps.mot.com (8.6.12/8.6.12) id MAA16226; Thu, 20 Jun 1996 12:21:43 +0930
Date: Thu, 20 Jun 1996 12:21:43 +0930
Message-Id: <199606200251.MAA16226@asc.sps.mot.com>
From: Rod Whitby <rwhitby@asc.sps.mot.com>
To: xemacs-beta@xemacs.org
Subject: Beta 26 success on Solaris 2.5, SunOS 4.1.4, HP-UX 9.05

1/ Solaris 2.5, X11R6.1, gcc-2.7.2
2/ SunOS 4.1.4, X11R6.1, gcc-2.7.2
3/ HP-UX 9.05,  X11R6.1, gcc-2.7.2

All built with:

	configure --prefix=/app/xemacs-19.14-b26 --with-database=no

Had to give --with-database=no, cause it looks like db-1.85 installs
itself badly (include file in wrong place, and no shared library).

Problems/Issues:

1/ I couldn't post until I set mail-host-address.
2/ I also see the fvwm/focus problem happen all the time.

The following code no longer works (it dumped core in b24 and gave an
error in b25).  It used to look at the result from the gnudoit, now it
just says that the process is no longer running.

(defun gnuserv-running-p ()
  "Returns whether a useful gnuserv is already running."
  (let ((output "")
	(proc (start-process "gnudoit" nil "gnudoit" "1234")))
    
    (set-process-filter
     proc
     (function (lambda (proc string)
		 (setq output
		       (concat output string)))))
    
    (while (eq (process-status proc) 'run)
      (accept-process-output))
    
    (set-process-filter proc nil)
    (string-match "^1234" output)))

(or (gnuserv-running-p)
    (null (string-match (concat "^" (system-name)) (getenv "GNU_HOST")))
    (progn (call-process "xauth" nil nil nil
 		 "add" (concat (system-name) ":999")
 		 "." (format "%08.0X%08.0X" (random) (random)))
    (gnuserv-start)))

-- 
-- Rod Whitby -- (rwhitby@asc.corp.mot.com, A11375@email.mot.com) _--_|\ 
-- Motorola Australian Software Centre, HW/SW Codesign Programme / MASC \
-- 2 Second Avenue, Technology Park, Adelaide SA 5095, Australia \_.-*._/
-- Phone: +61 8 203 3526, Fax: +61 8 203 3501, Timezone: GMT+9:30      v 

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 19 22:20:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA05479 for xemacs-beta-people; Wed, 19 Jun 1996 22:20:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA05476 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 19 Jun 1996 22:20:00 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA13252 for <xemacs-beta@xemacs.org>; Wed, 19 Jun 1996 22:19:56 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id UAA25745; Wed, 19 Jun 1996 20:19:28 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA04897; Wed, 19 Jun 1996 20:19:26 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA11987; Wed, 19 Jun 1996 20:19:24 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA27361; Wed, 19 Jun 1996 20:19:20 -0700
Date: Wed, 19 Jun 1996 20:19:20 -0700
Message-Id: <199606200319.UAA27361@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Rod Whitby <rwhitby@asc.sps.mot.com>
Cc: xemacs-beta@xemacs.org
Subject: Beta 26 success on Solaris 2.5, SunOS 4.1.4, HP-UX 9.05
In-Reply-To: <199606200251.MAA16226@asc.sps.mot.com>
References: <199606200251.MAA16226@asc.sps.mot.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Rod" == Rod Whitby <rwhitby@asc.sps.mot.com> writes:

Rod> The following code no longer works (it dumped core in b24 and gave an
Rod> error in b25).  It used to look at the result from the gnudoit, now it
Rod> just says that the process is no longer running.

Rod> (defun gnuserv-running-p ()
Rod>   "Returns whether a useful gnuserv is already running."
Rod>   (let ((output "")
Rod> 	(proc (start-process "gnudoit" nil "gnudoit" "1234")))
    
Rod>     (set-process-filter
Rod>      proc
Rod>      (function (lambda (proc string)
Rod> 		 (setq output
Rod> 		       (concat output string)))))
    
Rod>     (while (eq (process-status proc) 'run)
Rod>       (accept-process-output))
    
Rod>     (set-process-filter proc nil)
Rod>     (string-match "^1234" output)))

Reporting an error is intentional.  The code gets output from a
process until it's dead, then tries to modify the behaviour of the
dead process.

Why not just do something like
(delete-process proc) instead of
(set-process-filter proc nil) ?

Rod> (or (gnuserv-running-p)
Rod>     (null (string-match (concat "^" (system-name)) (getenv "GNU_HOST")))
Rod>     (progn (call-process "xauth" nil nil nil
Rod>  		 "add" (concat (system-name) ":999")
Rod>  		 "." (format "%08.0X%08.0X" (random) (random)))
Rod>     (gnuserv-start)))

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 00:15:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA05766 for xemacs-beta-people; Thu, 20 Jun 1996 00:15:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA05763 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 00:15:36 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA21755 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 00:15:32 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id XAA26841; Wed, 19 Jun 1996 23:15:34 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id XAA05562; Wed, 19 Jun 1996 23:15:32 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id XAA10443; Wed, 19 Jun 1996 23:15:14 -0600
Date: Wed, 19 Jun 1996 23:15:14 -0600
Message-Id: <199606200515.XAA10443@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: Gnus 5.2.20: SAVEDIR
Reply-To: turner@lanl.gov

I posted earlier that sorting of my summaries wasn't being done
properly (as defined by gnus-thread-sort-functions).

Turns out that isn't the problem.  That's a symptom.

The problem is that once again gnus-directory isn't being set to
the value of the env. var. SAVEDIR as it should be:

gielgud.lanl.gov% echo $SAVEDIR 
/home/turner/Mail/News 

C-h v gnus-directory:

gnus-directory's value is "~/News/" 

I have Gnus setup stuff in .gnus.

Ideas?

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 00:59:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA05827 for xemacs-beta-people; Thu, 20 Jun 1996 00:59:57 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA05824 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 00:59:56 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA25780 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 00:59:58 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id WAA17687; Wed, 19 Jun 1996 22:59:25 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA22738; Thu, 20 Jun 96 01:59:24 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id BAA11122; Thu, 20 Jun 1996 01:59:20 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id BAA13646; Thu, 20 Jun 1996 01:59:17 -0400
Date: Thu, 20 Jun 1996 01:59:17 -0400
Message-Id: <199606200559.BAA13646@detlev.canada.sun.com>
From: Georg Nikodym <georgn@detlev.Canada.Sun.COM>
To: XEmacs Beta List <xemacs-beta@cs.uiuc.edu>
Subject: b26
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII


beta 26 built for me using a recent build of Solaris 2.6, a recent
build of the next C compiler, a month old build of CDE, etc (you get
the idea).

I'll be away (in California) until July, so I won't be kvetching too
much about last minute fixes, etc (unless I find myself in front of a
workstation and I'm so incredibly bored that I can think of nothing
better to do than read mail).

Good luck with the release.

P.S. Chuck, congratulations on both the Bulls' victory and your having
     survived another year of editor hell.  Heck, we all survived.  Yay.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 01:22:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA05905 for xemacs-beta-people; Thu, 20 Jun 1996 01:22:19 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA05902 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 01:22:18 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA21821 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 01:22:17 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id AAA10183; Thu, 20 Jun 1996 00:22:17 -0600
Received: by suomi (SMI-8.6) id AAA13315; Thu, 20 Jun 1996 00:22:16 -0600
Sender: mdb@cdc.noaa.gov
To: Ding Gnus List <ding@ifi.uio.no>
Cc: xemacs-beta@xemacs.org
Subject: Re: Gnus 5.2.20: SAVEDIR
References: <199606200515.XAA10443@gielgud.lanl.gov.xdiv>
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 20 Jun 1996 00:22:15 -0600
In-Reply-To: John Turner's message of Wed, 19 Jun 1996 23:15:14 -0600
Message-ID: <vk20jb0zc8.fsf@cdc.noaa.gov>
Lines: 57
X-Mailer: Gnus v5.2.20/XEmacs 19.14

>> On Wed, 19 Jun 1996 23:15:14 -0600,
>> John Turner(JT) wrote:
[...]
JT> The problem is that once again gnus-directory isn't being set to
JT> the value of the env. var. SAVEDIR as it should be:

JT> gielgud.lanl.gov% echo $SAVEDIR 
JT> /home/turner/Mail/News 

JT> C-h v gnus-directory:
JT> gnus-directory's value is "~/News/" 

I hate it when that happens.

What *should* work according to my understanding of the
`gnus-directory' documentation is to

   (setq gnus-directory "/my/news/path/")

in your gnus-init-file. But it doesn't, because all the other Gnus
file variables the doc-string talks about:

------------------------------------------------------------
gnus-directory's value is "/home/mdb/Mail/news"
  -- a variable declared in Lisp.

Documentation:
*Directory variable from which all other Gnus file variables are
derived.
------------------------------------------------------------

have already been set by the time gnus-init-file is read. So, for
example, you wind up with gnus-article-save-directory still pointing
at the default ("~/News"). And then bad things happen.

The obvious fix it to have `gnus-init-file' be read earlier on in
gnus.el, but I don't know if there are any side-effects to doing
this.

The only way I've been able to get what I want is the ugly gross way:
manually set each of these in my gnus-init-file, e.g.,
------------------------------------------------------------
(setq
 gnus-directory (expand-file-name "~/Mail/news")
 gnus-nocem-directory (expand-file-name "~/Mail/news/NoCeM/")
 gnus-article-save-directory gnus-directory
 gnus-kill-files-directory gnus-directory
)
------------------------------------------------------------

I don't want to use SAVEDIR; my environment is polluted enough.

But it appears from looking at gnus.el that using SAVEDIR should work
(if it's been properly exported), but you're right it doesn't.

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 03:56:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA09809 for xemacs-beta-people; Thu, 20 Jun 1996 03:56:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA09806 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 03:56:28 -0500 (CDT)
Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA22007 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 03:56:26 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA27298; Thu, 20 Jun 1996 01:54:39 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA26252; Thu, 20 Jun 1996 10:54:32 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA16502; Thu, 20 Jun 1996 10:54:30 +0200
Date: Thu, 20 Jun 1996 10:54:30 +0200
Message-Id: <9606200854.AA16502@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: gcc warning patch for DUNIX
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

The following patch fixes the gcc complaint that it doesn't like the
-call_shared switch, which is acceptable to other compilers on DUNIX.

        Steve

*** src/s/decosf1-3.h.dist	Mon Jan 08 00:49:59 1996
--- src/s/decosf1-3.h	Wed Jun 19 17:32:18 1996
***************
*** 25,31 ****
--- 25,33 ----
  #define LD_SWITCH_SYSTEM
  
  #undef LD_SWITCH_CALL_SHARED
+ #ifndef USE_GCC
  #define LD_SWITCH_CALL_SHARED -call_shared
+ #endif /* !USE_GCC */
  
  #undef LD_SWITCH_SHARED
  #define LD_SWITCH_SHARED -shared


From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 04:18:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA09832 for xemacs-beta-people; Thu, 20 Jun 1996 04:18:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA09829 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 04:18:02 -0500 (CDT)
Received: from sys3.cambridge.uk.psi.net (sys3.cambridge.uk.psi.net [154.32.106.10]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA22020 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 04:17:59 -0500 (CDT)
Received: from arrow by sys3.cambridge.uk.psi.net (8.7.5/SMI-5.5-UKPSINet)
	id KAA07250; Thu, 20 Jun 1996 10:15:49 +0100 (BST)
Received: by arrow (5.x/SMI-SVR4)
	id AA27060; Thu, 20 Jun 1996 10:12:27 +0100
>Received: from dx2.delcam.com by delcam.com; Thu, 20 Jun 96 10:10:51 BST
Received: from delcam by arrow.delcam.com; Thu, 20 Jun 1996 10:12 BST
Received: from dx2.delcam.com by delcam.com; Thu, 20 Jun 96 10:10:51 BST
Received: by dx2.delcam.com; Thu, 20 Jun 96 10:07:28 +0100
Message-Id: <29709.9606200907@dx2.delcam.com>
Date: Thu, 20 Jun 96 10:07:28 +0100
From: Paul Bibilo <peb@delcam.com>
To: xemacs-beta@xemacs.org
Subject: b26 completion error in VM
X-Face:  "+N/{>9S5,OIk<0$%[)LGd}<Mh,R;qNhl+C]O!g9wsh6Q65Wiv,#M#&,MjgG1?&]jTbwsn*
 _yj,NR}PT7"irWSgi|(H5w)Q1C0.dO:qt?=S`eF/EcT!L_1D7eJ&b-J5d#AoLu&}b#'}nq(^pr2+u*
 7'RvZp0xv:q/K&%WDOQ(+H?AJw7[|DcUK{}5S!;I4^9vFe$A2%G_oz3K#2d{m#[MnE,-hxq9Po9v]R
 t]j*0md[y/3R~J
Content-Type: text


I was in VM and decided to edit my .emacs.  I did C-x C-f ~/.em<TAB>
When I hit the tab key it XEmacs bleeped at me and said
Symbols function definition is void: hkey-help-show

-- Paul



From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 04:35:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA09870 for xemacs-beta-people; Thu, 20 Jun 1996 04:35:34 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA09867 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 04:35:33 -0500 (CDT)
Received: from lemcbed.lem.uni-karlsruhe.de (lemcbed.lem.uni-karlsruhe.de [129.13.103.197]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA27874 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 04:35:29 -0500 (CDT)
Received: by lemcbed.lem.uni-karlsruhe.de; id AA01314; Thu, 20 Jun 1996 11:39:08 +0200
To: xemacs-beta@cs.uiuc.edu
Subject: Re: b26 failure on DEC Unix 3.2
References: <x220jb4u0i.fsf@lemcbed.lem.uni-karlsruhe.de>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Jens Lautenbacher <jens@lemcbed.lem.uni-karlsruhe.de>
Date: 20 Jun 1996 11:39:07 +0200
In-Reply-To: Jens Lautenbacher's message of 19 Jun 1996 18:51:25 +0200
Message-Id: <x2ybli3jd0.fsf@lemcbed.lem.uni-karlsruhe.de>
Lines: 3
X-Mailer: Gnus v5.2.19/XEmacs 19.14


Recompiled without png: Compiled OK.


From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 04:33:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA09854 for xemacs-beta-people; Thu, 20 Jun 1996 04:33:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA09849 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 04:33:11 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA22024 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 04:33:07 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Thu, 20 Jun 1996 11:13:17 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id LAA26349; Thu, 20 Jun 1996 11:12:12 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id LAA06576;
          Thu, 20 Jun 1996 11:10:41 +0200
Date: Thu, 20 Jun 1996 11:10:41 +0200
Message-Id: <199606200910.LAA06576@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de>
To: Raymond Toy <toy@rtp.ericsson.se>
Cc: xemacs-beta@xemacs.org
Subject: Re: buffer-menu sorting
In-Reply-To: <1851.835134324@rtp.ericsson.se>
References: <199606181001.DAA27414@netcom2.netcom.com> <1851.835134324@rtp.ericsson.se>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q(\V9 
        +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy 
        ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x 
        zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B: 
        s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Raymond" == Raymond Toy <toy@rtp.ericsson.se> writes:

    Raymond> I tried out the new buffer menus.  I like them, or,
    Raymond> rather, I would like them if I actually used the buffer
    Raymond> menu.  Can the same be done for the buffer list buffer?
    Raymond> I always thought the old method was just about as good as
    Raymond> random sorting.

Look at my mail from the 17 June. It contains two lisp files for this
purpose.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 05:17:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA10005 for xemacs-beta-people; Thu, 20 Jun 1996 05:17:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA10002 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 05:17:29 -0500 (CDT)
Received: from gatekeeper.abs.alcatel.co.uk (firewall-user@gatekeeper.abs.alcatel.co.uk [194.34.58.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA02728 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 05:17:26 -0500 (CDT)
Received: from unknown(194.36.210.121) by gatekeeper.abs.alcatel.co.uk via smap (g3.0.3)
	id xma017371; Thu, 20 Jun 96 11:10:08 +0100
Received: from uk.abs (hyperion) by rd.abs.alcatel.co.uk  (4.1/SMI-4.1)
	id AA29455; Thu, 20 Jun 96 11:11:33 BST
Received: by uk.abs (5.x/SMI-SVR4)
	id AA05554; Thu, 20 Jun 1996 11:11:37 +0100
Date: Thu, 20 Jun 1996 11:11:37 +0100
Message-Id: <9606201011.AA05554@uk.abs>
From: imac@rd.abs.alcatel.co.uk
To: xemacs-beta@cs.uiuc.edu
Subject: b26 OK ... Now

I downloaded the patch from 25 to 26 and compiled on Solaris 2.5
compiled ok but (sound familiar yet) got the ps-printxxx prob.
though it was my fault and I had screwed up the patch. Not a word on
the mailing list. So started a download of the full thing. Came back in
this morning and the mailing list is full of my problem. Thats what
you get for having timezones in the world. When I am Emperor of Earth,
I will abolish timezones, and everybody will work GMT.

Anyway got the patched eos files and built the complete dist and it
seems OK

Ian

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 06:37:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA10217 for xemacs-beta-people; Thu, 20 Jun 1996 06:37:23 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA10214 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 06:37:21 -0500 (CDT)
Received: from pat.idt.unit.no (pat.idt.unit.no [129.241.103.5]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA03573 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 06:37:22 -0500 (CDT)
Received: from ynde.idt.unit.no (1466@ynde.idt.unit.no [129.241.200.28]) by pat.idt.unit.no (8.6.12/8.6.12) with ESMTP id NAA14835 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 13:37:18 +0200
Received: (palat@localhost) by ynde.idt.unit.no (8.6.12/8.6.12) id NAA28072; Thu, 20 Jun 1996 13:36:59 +0200
Reply-To: palat@idt.unit.no
To: xemacs-beta@cs.uiuc.edu
Subject: b26 OK on sparc-sun-solaris2.4
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Sudeep Kumar Palat <palat@idt.unit.no>
Date: 20 Jun 1996 13:36:54 +0200
Message-ID: <yv9ivcmn1ux.fsf@ynde.idt.unit.no>
Lines: 36
X-Mailer: Gnus v5.2.20/XEmacs 19.14


b26 built successfully on sparc-sun-solaris2.4.  This is with the
updated loaddefs-eos.elc

>Configured for `sparc-sun-solaris2.4'.
>
>  Where should the build process find the source code?    /home/ynde/palat/Xemacs/xemacs-19.14-b26
>  What installation prefix should install use?            ${srcdir}
>  What operating system and machine description files should XEmacs use?
>	 `s/sol2-4.h' and `m/sparc.h'
>  What compiler should XEmacs be built with?              gcc  -g -O 
>  Should XEmacs use the GNU version of malloc?            yes
>  Should XEmacs use the relocating allocator for buffers? yes
>  What window system should XEmacs use?                   x11
>  Where do we find X Windows header files?                /store/include
>  Where do we find X Windows libraries?                   /store/lib
>  Additional header files:                                /home/ynde/palat/local/include
>  Additional libraries:                                   /home/ynde/palat/local/lib
>  Compiling in support for XAUTH.
>  Compiling in support for XPM.
>  Compiling in support for X-Face headers.
>  Compiling in support for GIF image conversion.
>  Compiling in support for JPEG image conversion.
>  Compiling in support for PNG image conversion.
>  Compiling in native sound support.
>  Compiling in support for Berkeley DB.
>  Compiling in support for GNU DBM.
>  Compiling in support for ToolTalk.
>  Compiling in support for SparcWorks.
>  Using the Lucid menubar.
>  Using the Lucid scrollbar.
>  Using the Athena dialog boxes.
>  Compiling in extra code for debugging.
>

sudeep

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 07:20:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA10298 for xemacs-beta-people; Thu, 20 Jun 1996 07:20:19 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA10295 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 07:20:17 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA03958 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 07:20:18 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id VAA07676; Thu, 20 Jun 1996 21:20:01 +0900 (JST)
Message-Id: <199606201220.VAA07676@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: [20.0 b25] patch for mule-misc.el 
In-reply-to: Your message of "19 Jun 1996 12:42:55 MST."
             <m2hgs74m2o.fsf@deanna.miranova.com> 
Mime-Version: 1.0 (SEMI mime-edit 0.26)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 20 Jun 1996 21:20:05 JST
Sender: morioka@jaist.ac.jp

>>>>> In <m2hgs74m2o.fsf@deanna.miranova.com> 
>>>>>	Steven L Baur <steve@miranova.com> wrote:

Steven> >>>>> "MORIOKA" == MORIOKA Tomohiko writes:

Steven> I applied this patch, and the canna.el patch, but 20.0-b25
Steven> still crashes for me with the same backtrace I posted earlier
Steven> when translation of ISO-2022-JP is attempted.  Oh well, I
Steven> should be running the latest 19.14s for a few days anyway ...

  Maybe it is caused by decode-coding-region.

  Please insert following to ~/.emacs when it is broken:

	(setq code-converter-is-broken t)

then emu uses own code-converter function.

  Regards,
-- 
tomo. <morioka@yo.rim.or.jp>

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 07:19:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA10278 for xemacs-beta-people; Thu, 20 Jun 1996 07:19:19 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA10275 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 07:19:18 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA03915 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 07:19:19 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id HAA17091 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 07:18:48 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id HAA27951 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 07:18:47 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id IAA03257 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 08:14:03 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: b26 ok on linux 1.3.59
Date: Thu, 20 Jun 1996 08:14:03 -0400
Message-ID: <23086.835272843@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

Patched up from b14, and config'ed using

	./configure  --extra-verbose --with-sound=both
	--with-jpeg--site-includes=/usr/local/include/jpeg
	--site-libraries=/usr/local/lib 

for Linux 1.3.59, gcc 2.7.2, ELF, Lucid widgets.  

Compiles and runs fine so far.  I still have the minor problem that using 
recycle.xpm as my GC cursor is quite right.  The color is the wrong shade
of green, and there's no black shadowing around it.  Otherwise, it looks 
good.

Ray



From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 08:03:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA10399 for xemacs-beta-people; Thu, 20 Jun 1996 08:03:21 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA10396 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 08:03:20 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA06222 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 08:03:21 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.52 #3)
	id E0uWjOK-0004An-00; Thu, 20 Jun 1996 09:03:20 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: libgr-2.0.8 available
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uWjOK-0004An-00@neal.ctd.comsat.com>
Date: Thu, 20 Jun 1996 09:03:20 -0400

libgr-2.0.8 is available from ftp.ctd.comsat.com:/pub/linux/ELF.
Changes are:

libpng-0.89c
zlib-1.0.2
build with -D_BSD_SOURCE

Note: the version number on zlib is now in sync with the number on the
package (1.0.2), which means the version number went down.  This will
confuse ldconf.  Sorry for any inconvenience.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 08:11:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA10421 for xemacs-beta-people; Thu, 20 Jun 1996 08:11:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA10418 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 08:11:02 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA22109 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 08:10:54 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id JAA07039 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 09:10:31 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp006917; Thu Jun 20 09:08:33 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA26128; Thu, 20 Jun 96 09:08:31 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA20129; Thu, 20 Jun 96 09:08:27 EDT
Message-Id: <9606201308.AA20129@cfdevx1.lehman.com>
From: Rick Campbell <rickc@lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: The problem for your problem.
Organization: Lehman Brothers Inc.
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: b26: SunOS413 success
Date: Thu, 20 Jun 1996 09:07:54 -0400
Sender: rickc@lehman.com

-----BEGIN PGP SIGNED MESSAGE-----

No apparent problems running in tty or X11 mode.  Tried out mh-e, gnus,
w3 and html-mode.

			Rick

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Configured for `sparc-sun-sunos4.1.3'.

  Where should the build process find the source code?    /home/fiasal/hack/rickc/xemacs/xemacs-19.14-b26
  What installation prefix should install use?		  /home/fiasal/hack/rickc/xemacs/xemacs-19.14-b6
  What operating system and machine description files should XEmacs use?
        `s/sunos4-1-3.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /home/fiasal/hack/rickc/xemacs/xemacs-build/include
  Where do we find X Windows libraries?                   /home/fiasal/hack/rickc/xemacs/xemacs-build/lib
  Additional header files:                                /home/fiasal/hack/rickc/xemacs/xemacs-build/include
  Additional libraries:                                   /home/fiasal/hack/rickc/xemacs/xemacs-build/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in both network and native sound support.
  Compiling in support for DBM.
  Compiling in support for ToolTalk.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMclEvVtTztlqB385AQG1CwP8D6CxTVh5aPdVHpchwAr5fWowKv/WVIFS
el4pyOMQm4y6twmvdfUMQZ2DutrjuHWWnZeyxnbmHZgroJHAajGXg8Vkjyb2v9BO
yi0h2SUrfsKsMKElAcj2DJljPT2ApzJvHDWNGibs8I2cPp2Fw8WmvZbTmp9OQBl2
NsQWcJ12V8U=
=OMKL
-----END PGP SIGNATURE-----

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 09:09:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA10646 for xemacs-beta-people; Thu, 20 Jun 1996 09:09:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA10643 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 09:09:39 -0500 (CDT)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA22254 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 09:09:37 -0500 (CDT)
Received: from ylfing.ifi.uio.no (4867@ylfing.ifi.uio.no [129.240.94.25]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <QAA12678@ifi.uio.no> ; Thu, 20 Jun 1996 16:09:39 +0200
Received: (from larsi@localhost) by ylfing.ifi.uio.no ; Thu, 20 Jun 1996 16:09:38 +0200
Sender: larsi@ifi.uio.no
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: Gnus 5.2.20: SAVEDIR
References: <199606200515.XAA10443@gielgud.lanl.gov.xdiv>
X-Face: &w!^oO<W.WBH]FsTP:P0f9X6M-ygaADlA_)eF$<UwQzj7:C=Gi<a?/_4$LX^@$Qq7-O&XHp
	lDARi8e8iT<(A$LWAZD*xjk^')/wI5nG;1cNB>~dS|}-P0~ge{$c!h\<y
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Date: 20 Jun 1996 16:09:37 +0200
In-Reply-To: John Turner's message of Wed, 19 Jun 1996 23:15:14 -0600
Message-ID: <w8s20jalg7y.fsf@ylfing.ifi.uio.no>
Lines: 23
X-Mailer: Gnus v5.2.23/XEmacs 19.14

John Turner <turner@xdiv.lanl.gov> writes:

> The problem is that once again gnus-directory isn't being set to
> the value of the env. var. SAVEDIR as it should be:
> 
> gielgud.lanl.gov% echo $SAVEDIR 
> /home/turner/Mail/News 
> 
> C-h v gnus-directory:
> 
> gnus-directory's value is "~/News/" 

This is the definition of `gnus-directory':

(defvar gnus-directory (or (getenv "SAVEDIR") "~/News/")
  "*Directory variable from which all other Gnus file variables are derived.")

So it should definitely be initialized from the SAVEDIR environment
variable...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 09:23:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA10770 for xemacs-beta-people; Thu, 20 Jun 1996 09:23:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA10767 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 09:23:38 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA22271 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 09:23:37 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA20462; Thu, 20 Jun 1996 08:23:36 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA07616; Thu, 20 Jun 1996 08:23:34 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA10833; Thu, 20 Jun 1996 08:23:17 -0600
Date: Thu, 20 Jun 1996 08:23:17 -0600
Message-Id: <199606201423.IAA10833@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: larsi@ifi.uio.no
Cc: xemacs-beta@xemacs.org
Subject: Re: Gnus 5.2.20: SAVEDIR
In-Reply-To: <w8s20jalg7y.fsf@ylfing.ifi.uio.no>
References: <199606200515.XAA10443@gielgud.lanl.gov.xdiv>
	<w8s20jalg7y.fsf@ylfing.ifi.uio.no>
Reply-To: turner@lanl.gov

Lars Magne Ingebrigtsen writes:
 > John Turner <turner@xdiv.lanl.gov> writes:
 > 
 > > The problem is that once again gnus-directory isn't being set to
 > > the value of the env. var. SAVEDIR as it should be:
 > > 
 > > gielgud.lanl.gov% echo $SAVEDIR 
 > > /home/turner/Mail/News 
 > > 
 > > C-h v gnus-directory:
 > > 
 > > gnus-directory's value is "~/News/" 
 > 
 > This is the definition of `gnus-directory':
 > 
 > (defvar gnus-directory (or (getenv "SAVEDIR") "~/News/")
 >   "*Directory variable from which all other Gnus file variables are derived.")
 > 
 > So it should definitely be initialized from the SAVEDIR environment
 > variable...

I know, I looked, and it looks OK to me as well.  But something is
overwriting it or *something*.

The above sequence is exactly what happens, whether or not I start
with -q.

I know it's probably brain damage on my part, but I just can't see it.

-John

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 09:07:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA10616 for xemacs-beta-people; Thu, 20 Jun 1996 09:07:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA10613 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 09:07:20 -0500 (CDT)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA22248 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 09:07:18 -0500 (CDT)
Received: from ylfing.ifi.uio.no (4867@ylfing.ifi.uio.no [129.240.94.25]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <QAA12563@ifi.uio.no> ; Thu, 20 Jun 1996 16:07:18 +0200
Received: (from larsi@localhost) by ylfing.ifi.uio.no ; Thu, 20 Jun 1996 16:07:16 +0200
Sender: larsi@ifi.uio.no
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: Gnus 5.2.20 comment
References: <199606191937.NAA09960@gielgud.lanl.gov.xdiv>
X-Face: &w!^oO<W.WBH]FsTP:P0f9X6M-ygaADlA_)eF$<UwQzj7:C=Gi<a?/_4$LX^@$Qq7-O&XHp
	lDARi8e8iT<(A$LWAZD*xjk^')/wI5nG;1cNB>~dS|}-P0~ge{$c!h\<y
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Date: 20 Jun 1996 16:07:14 +0200
In-Reply-To: John Turner's message of Wed, 19 Jun 1996 13:37:02 -0600
Message-ID: <w8s3f3qlgbx.fsf@ylfing.ifi.uio.no>
Lines: 21
X-Mailer: Gnus v5.2.23/XEmacs 19.14

John Turner <turner@xdiv.lanl.gov> writes:

> I set mail aliases in my .mailrc.  In VM and in the old GNUS, they
> expand to the correct address when I type either , or C-n.
> 
> However, when forwarding a post from Gnus 5.2.20, although , expands
> the addresses, C-n does not.  This means I have to hit , and then
> delete it to expand the last address in a list.  Or is there
> something different I should be doing?

mail-abbrev takes care of all abbrev things in Message mode.  
Perhaps Message should say:

(define-key message-mode-map "\C-n" 'abbrev-hacking-next-line)
(define-key message-mode-map "\M->" 'abbrev-hacking-end-of-buffer)

Probably.  I've added this to Gnus 5.2.23.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 09:09:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA10639 for xemacs-beta-people; Thu, 20 Jun 1996 09:09:29 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA10636 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 09:09:28 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA22251 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 09:09:27 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA17754; Thu, 20 Jun 1996 08:09:09 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA07384; Thu, 20 Jun 1996 08:09:08 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA10823; Thu, 20 Jun 1996 08:08:50 -0600
Date: Thu, 20 Jun 1996 08:08:50 -0600
Message-Id: <199606201408.IAA10823@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: peb@delcam.com
Cc: xemacs-beta@xemacs.org
Subject: Re: b26 completion error in VM
In-Reply-To: <29709.9606200907@dx2.delcam.com>
References: <29709.9606200907@dx2.delcam.com>
Reply-To: turner@lanl.gov

Paul Bibilo writes:

 > I was in VM and decided to edit my .emacs.  I did C-x C-f ~/.em<TAB>
 > When I hit the tab key it XEmacs bleeped at me and said
 > Symbols function definition is void: hkey-help-show

If it's repeatable, I think it helps to set debug-on-error to t and
repeat to obtain a Lisp backtrace...

-John

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 09:18:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA10757 for xemacs-beta-people; Thu, 20 Jun 1996 09:18:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA10754 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 09:18:26 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA22264 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 09:18:24 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA19426; Thu, 20 Jun 1996 08:18:24 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA07532; Thu, 20 Jun 1996 08:18:23 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA10828; Thu, 20 Jun 1996 08:18:05 -0600
Date: Thu, 20 Jun 1996 08:18:05 -0600
Message-Id: <199606201418.IAA10828@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: mdb@cdc.noaa.gov
Cc: ding@ifi.uio.no, xemacs-beta@xemacs.org
Subject: Re: Gnus 5.2.20: SAVEDIR
In-Reply-To: <vk20jb0zc8.fsf@cdc.noaa.gov>
References: <199606200515.XAA10443@gielgud.lanl.gov.xdiv>
	<vk20jb0zc8.fsf@cdc.noaa.gov>
Reply-To: turner@lanl.gov

Mark Borges writes:
 > >> On Wed, 19 Jun 1996 23:15:14 -0600,
 > >> John Turner(JT) wrote:
 > [...]
 > JT> The problem is that once again gnus-directory isn't being set to
 > JT> the value of the env. var. SAVEDIR as it should be:
 > 
 > JT> gielgud.lanl.gov% echo $SAVEDIR 
 > JT> /home/turner/Mail/News 
 > 
 > JT> C-h v gnus-directory:
 > JT> gnus-directory's value is "~/News/" 
 > 
 > I hate it when that happens.
 > 
 > What *should* work according to my understanding of the
 > `gnus-directory' documentation is to
 > 
 >    (setq gnus-directory "/my/news/path/")
 > 
 > in your gnus-init-file. But it doesn't, because all the other Gnus
 > file variables the doc-string talks about:
 > 
 > ------------------------------------------------------------
 > gnus-directory's value is "/home/mdb/Mail/news"
 >   -- a variable declared in Lisp.
 > 
 > Documentation:
 > *Directory variable from which all other Gnus file variables are
 > derived.
 > ------------------------------------------------------------
 > 
 > have already been set by the time gnus-init-file is read. So, for
 > example, you wind up with gnus-article-save-directory still pointing
 > at the default ("~/News"). And then bad things happen.
 > 
 > The obvious fix it to have `gnus-init-file' be read earlier on in
 > gnus.el, but I don't know if there are any side-effects to doing
 > this.
 > 
 > The only way I've been able to get what I want is the ugly gross way:
 > manually set each of these in my gnus-init-file, e.g.,
 > ------------------------------------------------------------
 > (setq
 >  gnus-directory (expand-file-name "~/Mail/news")
 >  gnus-nocem-directory (expand-file-name "~/Mail/news/NoCeM/")
 >  gnus-article-save-directory gnus-directory
 >  gnus-kill-files-directory gnus-directory
 > )
 > ------------------------------------------------------------
 > 
 > I don't want to use SAVEDIR; my environment is polluted enough.
 > 
 > But it appears from looking at gnus.el that using SAVEDIR should work
 > (if it's been properly exported), but you're right it doesn't.

I prefer to use SAVEDIR because a number of people here use my setup
stuff, and using env vars lets them put things where they want and not
have to muck around in .emacs, .vm, .gnus, ...

So I use env vars for a bunch of things.  I use the "standard" ones
like SAVEDIR and define new ones like VM_INBOX.  Then in my .vm I
have:

(if (getenv "VM_INBOX")
    (setq vm-primary-inbox (getenv "VM_INBOX")))

Anyway, I have a number of things like this, and it just makes it
easier for other folks to use my stuff.

But back to SAVEDIR.  It looks like the relevant code is right at the
top of gnus.el:

(defvar gnus-directory (or (getenv "SAVEDIR") "~/News/")
  "*Directory variable from which all other Gnus file variables are derived.")

which kinda looks OK, but I'm not an elisp expert at all...

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 10:16:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA10928 for xemacs-beta-people; Thu, 20 Jun 1996 10:16:45 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA10925 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 10:16:44 -0500 (CDT)
Received: from caddy.arnet.com (caddy.arnet.com [199.86.10.214]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA22399 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 10:16:42 -0500 (CDT)
Subject: Patch to PROBLEMS
To: xemacs-beta@xemacs.org
Date: Thu, 20 Jun 1996 10:14:30 -0500 (CDT)
From: Robert Lipe <robertl@arnet.com>
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID:  <9606201014.aa12748@caddy.arnet.com>

Kean's recent patch to s/sco5-shr.h  changed the error reported
by configure.  This patch makes the doc match the error. (sigh)

$ diff -c PROBLEMS_ PROBLEMS
*** PROBLEMS_   Thu Jun 20 10:09:15 1996
--- PROBLEMS    Thu Jun 20 10:09:53 1996
***************
*** 69,75 ****
  Note that use of '--dynamic' will result in the configure step
  generating what looks like error messages near the end of the process
  while it's generating the Makefiles.  You will see messages like
! "0: unknown flag -belf" at the end of the configure, you may safely
  disregard them.  They are an artifact of /lib/cpp and cc -E accepting
  different flags.  Why is /lib/cpp used instead of cc -E?  To avoid
  the tokenizers from hell.
--- 69,75 ----
  Note that use of '--dynamic' will result in the configure step
  generating what looks like error messages near the end of the process
  while it's generating the Makefiles.  You will see messages like
! "0: unknown flag -Xc" at the end of the configure, you may safely
  disregard them.  They are an artifact of /lib/cpp and cc -E accepting
  different flags.  Why is /lib/cpp used instead of cc -E?  To avoid
  the tokenizers from hell.


From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 09:11:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA10683 for xemacs-beta-people; Thu, 20 Jun 1996 09:11:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA10680 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 09:11:07 -0500 (CDT)
Received: from zero-gravity.netlab.london.sco.com (zero-gravity.netlab.london.sco.com [150.126.252.16]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA22257 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 09:11:04 -0500 (CDT)
Received: (from davided@localhost) by zero-gravity.netlab.london.sco.com (8.6.10/dme/nice-1.1) id OAA02344; Thu, 20 Jun 1996 14:06:14 GMT
Date: Thu, 20 Jun 1996 14:06:14 GMT
Message-Id: <199606201406.OAA02344@zero-gravity.netlab.london.sco.com>
To: xemacs-beta@xemacs.org
Subject: b26 on UnixWare 2.1
From: dave edmondson <davided@sco.com>
X-Face: "?v.huY]?B[a4C|xid!Tx8TpwOQe6]C(I}h8Vo1z6'9soM_Xvq2f3u::[F~rW>GWj6;IfU,10H;B&1JDE/H8?``q4XH4~!\_z{n3RDmkC;9d!Yx3O7n?9,[CE;TWB!
	F8.e5fc0dJXikU'v1qFVTfptB7xe$y*t#jx4`I44n,ypMQg@.|Z^ycJ:G]{dR~E}_.T1^shwC%T4eRGVu%h+J7lBzb>m20==Q*OPAf^~@6Lj^)rI9Tb*m*L}}HC~{>
	/__Od\I=[|aP6s}B%BhqtE-9uGJ0J3jchjcyJz5fW[i0$RfPv7Zp=!a+0pR

XEmacs 19.14-b26 compiles and runs under UnixWare 2.1 with the
included patches.  i've run it around the block a little, but not much
more than that.  more testing has been done using the same set of
changes with XEmacs 20.0-b24 (been using it for about 2 weeks).

20.0-b24 was tested with both the unixware 2.1 X libraries (which
meant motif and not athena) and xfree86 libraries (which meant athena
and no motif).  20.0-b24 was build with and without debug, with and
without -g and with and without -O.  19.14-b26 was only tested with
xfree86 libraries and debug/-g because of time constraints.  in all
cases pbm, jpeg and png were used.  no dbm support has ever been
included.  output from configure for 19.14-b26 is included after the
problem list.

kudos to the relevant people for gnus splash screen - it blew me away !
all round, 19.14 and 20.0 are truly wonderful, thanks to all who made
it happen.

problems and patches:
- src/Makefile.in.in is incorrect in its' handling of alloca.  if a
  system doesn't have an alloca (as unixware 2.1 doesn't), C_ALLOCA is
  set by configure and the correct @ALLOCA@ sed expression is
  performed.  code in src/Makefile.in.in doesn't correctly use the
  @ALLOCA@ definition though.  has noone else got a system without
  alloca ? [ in fact, -lucb has an alloca in it, but it's broken, and
  i try to avoid -lucb where i can ] (patch for this)
- some of the expressions in the resulting src/Makefile are too long
  for the distributed `make'.  i fixed this by rebuilding make with
  support for longer expressions, but gnu make would probably also
  work. (no patch for this)
- lwlib/lwlib.c included alloca.h when unixware doesn't have one.  i
  currently made this #if !defined(__USLC__), but i wonder if #if
  !defined(HAVE_ALLOCA) or something like it would be better. (patch
  for this)
- configure can't find Xmu, for much the same reasons as it fails on
  SunOS, so i copied the relevant hack.  the patch is for
  configure.in, but i haven't actually re-run autoconf as that would
  have required that i get gnu m4 (i just patched configure).  (patch
  for this)
- unixware 2.1 doesn't have a strcasecmp (in fact, there is one in
  -lucb, but i was avoiding it).  added one (from bsd) to sysdep.c
  #ifdef NEED_STRCASECMP, which src/s/usg-4-2.h now defines.  perhaps
  configure should check for strcasecmp ?  (patch for this)
- w3 doesn't seem to work very well with http servers.  html parsing
  is fine, but reading data over network streams never completes
  (stops at various %'s).  vm works okay with pop servers, so it's not
  completely broken.  i haven't had time to look at this properly, but
  it seems likely that the stream is getting killed (and the data
  lost) before emacs/w3 has got all it wanted out (certainly the inpcb
  for the connection has gone).  hopefully i'll spend some more time
  looking at this, but very busy next week and so may not have time.
  anyone offer any hints ?  (no patch for this)
- tm-7.68 seems to cause a few C-g interruptible loops, but i imagine
  that the problem lies in tm.  (no patch for this)

:; ./configure --site-includes=/usr/local/include \
	--site-libraries=/usr/local/lib

Configured for `i386-univel-sysv4.2MP'.

  Where should the build process find the source code?    /home/davided/src/xemacs-19.14-b26
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/usg5-4-2.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              cc -g 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

diffs: (don't forget to remove signature from the end)
===================================================================
RCS file: ./src/s/usg5-4-2.h,v
retrieving revision 1.1
diff -C 5 -r1.1 ./src/s/usg5-4-2.h
*** /tmp/T0a000_G	Thu Jun 20 14:51:56 1996
--- ./src/s/usg5-4-2.h	Thu Jun 20 13:21:24 1996
***************
*** 20,24 ****
--- 20,27 ----
  /* XEmacs change (since getwd is auto-determined) */
  #undef HAVE_GETWD  /* (appears to be buggy on SVR4.2) */
  
  /* XEmacs change: communicate to m/intel386.h */
  #define USG5_4_2
+ 
+ /* XEmacs: davided@sco.com: should be determined by configure ? */
+ #define NEED_STRCASECMP
===================================================================
RCS file: ./src/Makefile.in.in,v
retrieving revision 1.1
diff -C 5 -r1.1 ./src/Makefile.in.in
*** /tmp/T0a000_G	Thu Jun 20 14:51:56 1996
--- ./src/Makefile.in.in	Thu Jun 20 13:01:11 1996
***************
*** 888,903 ****
  #else
  mallocobjs =
  mallocdocsrc =
  #endif /* SYSTEM_MALLOC */
  
! 
! #ifndef HAVE_ALLOCA
! allocaobjs = alloca.o
! #else
! allocaobjs =
! #endif
  
  #ifdef HAVE_X_WINDOWS
  
  # ifdef EXTERNAL_WIDGET
  #  define EXTERNAL_WIDGET_OBJS ExternalShell.o extw-Xt-nonshared.o extw-Xlib-nonshared.o
--- 888,898 ----
  #else
  mallocobjs =
  mallocdocsrc =
  #endif /* SYSTEM_MALLOC */
  
! allocaobjs = @ALLOCA@
  
  #ifdef HAVE_X_WINDOWS
  
  # ifdef EXTERNAL_WIDGET
  #  define EXTERNAL_WIDGET_OBJS ExternalShell.o extw-Xt-nonshared.o extw-Xlib-nonshared.o
===================================================================
RCS file: ./src/sysdep.c,v
retrieving revision 1.1
diff -C 5 -r1.1 ./src/sysdep.c
*** /tmp/T0a000_G	Thu Jun 20 14:51:56 1996
--- ./src/sysdep.c	Thu Jun 20 13:22:12 1996
***************
*** 5319,5323 ****
--- 5319,5377 ----
  
    return STR$COMPARE (&src1, &src2);
  }
  
  #endif /* VMS */
+ 
+ #ifdef NEED_STRCASECMP
+ /*
+  * From BSD
+  */
+ static u_char charmap[] = {
+         '\000', '\001', '\002', '\003', '\004', '\005', '\006', '\007',
+         '\010', '\011', '\012', '\013', '\014', '\015', '\016', '\017',
+         '\020', '\021', '\022', '\023', '\024', '\025', '\026', '\027',
+         '\030', '\031', '\032', '\033', '\034', '\035', '\036', '\037',
+         '\040', '\041', '\042', '\043', '\044', '\045', '\046', '\047',
+         '\050', '\051', '\052', '\053', '\054', '\055', '\056', '\057',
+         '\060', '\061', '\062', '\063', '\064', '\065', '\066', '\067',
+         '\070', '\071', '\072', '\073', '\074', '\075', '\076', '\077',
+         '\100', '\141', '\142', '\143', '\144', '\145', '\146', '\147',
+         '\150', '\151', '\152', '\153', '\154', '\155', '\156', '\157',
+         '\160', '\161', '\162', '\163', '\164', '\165', '\166', '\167',
+         '\170', '\171', '\172', '\133', '\134', '\135', '\136', '\137',
+         '\140', '\141', '\142', '\143', '\144', '\145', '\146', '\147',
+         '\150', '\151', '\152', '\153', '\154', '\155', '\156', '\157',
+         '\160', '\161', '\162', '\163', '\164', '\165', '\166', '\167',
+         '\170', '\171', '\172', '\173', '\174', '\175', '\176', '\177',
+         '\200', '\201', '\202', '\203', '\204', '\205', '\206', '\207',
+         '\210', '\211', '\212', '\213', '\214', '\215', '\216', '\217',
+         '\220', '\221', '\222', '\223', '\224', '\225', '\226', '\227',
+         '\230', '\231', '\232', '\233', '\234', '\235', '\236', '\237',
+         '\240', '\241', '\242', '\243', '\244', '\245', '\246', '\247',
+         '\250', '\251', '\252', '\253', '\254', '\255', '\256', '\257',
+         '\260', '\261', '\262', '\263', '\264', '\265', '\266', '\267',
+         '\270', '\271', '\272', '\273', '\274', '\275', '\276', '\277',
+         '\300', '\301', '\302', '\303', '\304', '\305', '\306', '\307',
+         '\310', '\311', '\312', '\313', '\314', '\315', '\316', '\317',
+         '\320', '\321', '\322', '\323', '\324', '\325', '\326', '\327',
+         '\330', '\331', '\332', '\333', '\334', '\335', '\336', '\337',
+         '\340', '\341', '\342', '\343', '\344', '\345', '\346', '\347',
+         '\350', '\351', '\352', '\353', '\354', '\355', '\356', '\357',
+         '\360', '\361', '\362', '\363', '\364', '\365', '\366', '\367',
+         '\370', '\371', '\372', '\373', '\374', '\375', '\376', '\377',
+ };
+ 
+ int
+ strcasecmp(s1, s2)
+         char *s1, *s2;
+ {
+         register u_char *cm = charmap,
+                         *us1 = (u_char *)s1,
+                         *us2 = (u_char *)s2;
+ 
+         while (cm[*us1] == cm[*us2++])
+                 if (*us1++ == '\0')
+                         return (0);
+         return (cm[*us1] - cm[*--us2]);
+ }
+ #endif /* NEED_STRCASECMP */
===================================================================
RCS file: ./lwlib/lwlib.c,v
retrieving revision 1.1
diff -C 5 -r1.1 ./lwlib/lwlib.c
*** /tmp/T0a000_G	Thu Jun 20 14:51:56 1996
--- ./lwlib/lwlib.c	Thu Jun 20 13:33:40 1996
***************
*** 33,43 ****
  
  #if defined(__GNUC__) && !defined(alloca)
  #define alloca __builtin_alloca
  #endif
  
! #if ((!__GNUC__) && !defined(__hpux)) && !defined(_AIX) && !defined (_SCO_DS)
  #include <alloca.h>
  #endif
  
  #ifdef __SUNPRO_C
  void *__builtin_alloca (unsigned int);
--- 33,43 ----
  
  #if defined(__GNUC__) && !defined(alloca)
  #define alloca __builtin_alloca
  #endif
  
! #if ((!__GNUC__) && !defined(__hpux)) && !defined(_AIX) && !defined (_SCO_DS) && !defined (__USLC__)
  #include <alloca.h>
  #endif
  
  #ifdef __SUNPRO_C
  void *__builtin_alloca (unsigned int);
===================================================================
RCS file: ./configure.in,v
retrieving revision 1.1
diff -C 5 -r1.1 ./configure.in
*** /tmp/T0a000_G	Thu Jun 20 14:51:57 1996
--- ./configure.in	Thu Jun 20 14:50:44 1996
***************
*** 3293,3302 ****
--- 3293,3325 ----
        rm -f conftest*
        LIBS="${ac_save_LIBS}"
        test -n "${ac_have_lib}" && with_xmu="yes"
        # end expansion of ac_have_library
      fi
+     # On UnixWare 2.1 we must kludge harder to try to detect Xmu
+     # Upgrade to autoconf 2 and use ac_check_lib - mrb
+     if test "${with_xmu}" != "yes" && test -f "/.UpgradeVer2.1" ; then
+       # begin expansion of ac_have_library
+       ac_save_LIBS="${LIBS}"
+       if test x$HAVE_XFREE386 = xyes; then
+ 	LIBS="-lXt -lSM -lICE ${LIBS}"
+       else
+ 	LIBS="${LIBS} -lXmu -lXt -lXext -lX11"
+       fi
+       ac_have_lib=""
+       cat > conftest.${ac_ext} <<EOF
+ int main() { return 0; }
+ EOF
+       if eval $ac_compile; then
+         rm -rf conftest*
+         ac_have_lib="1"
+       fi
+       rm -f conftest*
+       LIBS="${ac_save_LIBS}"
+       test -n "${ac_have_lib}" && with_xmu="yes"
+       # end expansion of ac_have_library
+     fi
    fi
  fi
  if test "${with_xmu}" = "yes" ; then
    AC_DEFINE(HAVE_XMU)
  fi

dave.
---
	  ``We don't modify the data, we just pass it on.''
		   -- Andy Walker, SCO EMEA Support

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 10:38:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA10992 for xemacs-beta-people; Thu, 20 Jun 1996 10:38:22 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA10989 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 10:38:21 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA15469 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 10:38:15 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.52 #3)
	id E0uWloA-0004Dg-00; Thu, 20 Jun 1996 11:38:10 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: sync VM & gnus
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uWloA-0004Dg-00@neal.ctd.comsat.com>
Date: Thu, 20 Jun 1996 11:38:10 -0400

Gnus has nice uudecoding using X U.  Is this available in VM?  Can we
put it in the 'dispose' menu?

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 10:33:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA10968 for xemacs-beta-people; Thu, 20 Jun 1996 10:33:07 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA10965 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 10:33:06 -0500 (CDT)
Received: from gcm.com (gcm.com [146.121.48.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA22478 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 10:33:02 -0500 (CDT)
Received: (from uucp@localhost) by gcm.com (8.6.9/8.6.9) with UUCP id LAA08004 for xemacs-beta@xemacs.org; Thu, 20 Jun 1996 11:36:32 -0400
Received: from gsdws023.it.gcm.com by gcm.com (4.1/GCM-2.0m)
	id AA15167; Thu, 20 Jun 96 11:31:58 EDT
Received: by gsdws023.it.gcm.com (4.1/SMI-4.1)
	id AA27559; Thu, 20 Jun 96 11:31:57 EDT
Sender: dcw@gcm.com
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Teensiest little problem in 19.14b25
From: David Worenklein <dcw@gcm.com>
Date: 20 Jun 1996 11:31:56 -0400
Message-Id: <amennapk43.fsf@gcm.com>
Lines: 9
X-Mailer: Gnus v5.2.19/XEmacs 19.14

src/Makefile.in.in has quantify includes/libraries located in
/local/bin. This doesn't seem to be configurable.
--
 David C. Worenklein                                       GREENWICH   CAPITAL
 Operations Support                                        M a r k e t s,  Inc
 =============================================================================
 phone: 203-625-2945                                                      ====
 fax:   203-629-2535                                                      ====
 e-mail: dcw@gcm.com                                                      ====

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 10:44:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA11036 for xemacs-beta-people; Thu, 20 Jun 1996 10:44:49 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA11033 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 10:44:48 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA22541 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 10:44:46 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA06890; Thu, 20 Jun 1996 10:44:43 -0500 (CDT)
Message-Id: <199606201544.KAA06890@charles.cs.uiuc.edu>
To: David Worenklein <dcw@gcm.com>
cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: Teensiest little problem in 19.14b25 
In-reply-to: Your message of "20 Jun 1996 11:31:56 EDT."
             <amennapk43.fsf@gcm.com> 
Date: Thu, 20 Jun 1996 10:44:43 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    David> src/Makefile.in.in has quantify includes/libraries located
    David> in /local/bin. This doesn't seem to be configurable.

The quantify and purify changes were done for my convenience :-)  It
was convenient to hard code my paths.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 11:06:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA11199 for xemacs-beta-people; Thu, 20 Jun 1996 11:06:07 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA11196 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 11:06:05 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA17702 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 11:06:06 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.52 #3)
	id E0uWmFB-0004Eu-00; Thu, 20 Jun 1996 12:06:05 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: tm related failure (b26)
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Message-Id: <E0uWmFB-0004Eu-00@neal.ctd.comsat.com>
Date: Thu, 20 Jun 1996 12:06:05 -0400

19.14b26 + tm7.67

Signalling: (end-of-buffer)
  delete-char(3)
  filladapt-cleanup-kludge-at-point-min()
  run-hooks(filladapt-fill-paragraph-post-hook)
  byte-code("=08=AB=AB=09=AC=A8=8C=C2=89=89=C3=C2=89=1C=19=1D=1E=06=1E=07=
=1E=08=C9=C3=C2\"=AB=90=CA=0E=0B=0E=0C\"=14=CD=CE!=88=CF=D0=0C\"=88.=07=CA=
=0E=0B=0E=0C\"=87" [filladapt-mode fill-prefix nil t retval comment-multi-l=
ine adaptive-fill-regexp adaptive-fill-mode paragraph-ignore-fill-prefix fi=
lladapt-adapt filladapt-funcall function arg run-hooks filladapt-fill-parag=
raph-post-hook throw done] 6)
  filladapt-fill-paragraph(fill-paragraph nil)
  fill-paragraph(nil)
  fill-region-as-paragraph(1317 1320 nil nil)
  fill-region(1265 1975)
  enriched-decode(1265 2066)
  mime-preview/filter-for-text/enriched("text/enriched" (("charset" . "iso-=
8859-1")) "quoted-printable")
  mime-preview/display-body(1197413 1198230 (1) [mime::content-info nil 119=
4816 1198411 "multipart/alternative" (("boundary" . "NeXT-Mail-1122099133-1=
")) "7bit" ([mime::content-info ... 1196486 1197294 "text/plain" ... "quote=
d-printable" nil] [mime::content-info ... 1197320 1198230 "text/enriched" .=
.. "quoted-printable" nil])] "text/enriched" (("charset" . "iso-8859-1")) "=
" "quoted-printable")
  mime-preview/display-content([mime::content-info (1) 1197320 1198230 "tex=
t/enriched" (("charset" . "iso-8859-1")) "quoted-printable" nil] [mime::con=
tent-info nil 1194816 1198411 "multipart/alternative" (("boundary" . "NeXT-=
Mail-1122099133-1")) "7bit" ([mime::content-info ... 1196486 1197294 "text/=
plain" ... "quoted-printable" nil] [mime::content-info ... 1197320 1198230 =
"text/enriched" ... "quoted-printable" nil])] #<buffer "INBOX"> "*Preview-I=
NBOX*")
  mime-viewer/make-preview-buffer(nil)
  mime-viewer/setup-buffer(nil nil nil nil)
  mime/viewer-mode()
  byte-code("=C0 =88db=88~=88`=8A=09@=C2H=C2Hb=88=C3y=88`)}=88=C4 =88=0D=AB=
=8B=0E=06=AB=87=C7 =AB=83=C8 =88=0E=09=AC=88=CA =AB=87=0E=0B=AB=83=CC =88eb=
=88`=CD=CE=C3=CF#}=87" [vm-widen-page vm-message-pointer 0 nil mime/viewer-=
mode tm-vm/use-original-url-button vm-use-menus vm-menu-support-possible-p =
vm-energize-urls vm-highlighted-header-regexp vm-xemacs-p vm-use-lucid-high=
lighting vm-highlight-headers search-forward "\n\n" t] 5)
  tm-vm/preview-current-message()
  run-hooks(vm-select-message-hook)
  vm-run-message-hook([[#<marker at 1194751 in INBOX> #<marker at 1194816 i=
n INBOX> #<marker at 1196293 in INBOX> #<marker at 1196461 in INBOX> #<mark=
er at 1198411 in INBOX> #<marker at 1198412 in INBOX>] ["148" "148" nil #<m=
arker at 11499 in INBOX Summary> #<marker at 11585 in INBOX Summary> <<>> <=
-- From_ "6770" #<buffer "INBOX"> nil nil nil nil nil nil] [nil nil nil nil=
 t nil nil nil nil] ["1950" "Wed" "29" "May" "1996" "10:34:09" "+0200" "Lel=
e Gaifax" "lele@nautilus.eclipse.it" "<m0uOgho-0005pNC@nautilus.eclipse.it>=
" "85" "Re: mod_python.c with documentation" "^From:" nil nil "5" nil nil (=
number " " mark "  R  Lele Gaifax       May 29   85/1950  " thread-indent "=
\"Re: mod_python.c with documentation\"\n") nil] [nil <v> nil nil nil]] vm-=
select-message-hook)
  vm-preview-current-message()
  vm-next-message(1 1 1)
  call-interactively(vm-next-message)

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 11:23:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA11274 for xemacs-beta-people; Thu, 20 Jun 1996 11:23:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA11271 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 11:23:38 -0500 (CDT)
Received: from ns1.eds.com (ns1.eds.com [192.85.154.78]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA22582 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 11:23:36 -0500 (CDT)
Received: by ns1.eds.com (hello)
	id MAA20333; Thu, 20 Jun 1996 12:23:39 -0400
Received: from kocrsw12.delcoelect.com (kocrsw12.delcoelect.com [144.250.106.18]) by kocrsv04.delcoelect.com (8.7.5/8.7.3) with SMTP id LAA04587 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 11:23:38 -0500 (EST)
Received: from kocrsw12 by kocrsw12.delcoelect.com (SMI-8.6/SMI-SVR4)
	id LAA14176; Thu, 20 Jun 1996 11:23:36 -0500
X-Mailer: exmh version 1.6.6 3/24/96
To: xemacs-beta@xemacs.org
Subject: Re: 19.14-b26 success on sparc-sun-sunos4.1.4 
X-Face: 4tk3bJx]I+QTZ|=]*1+Z){9+;5u_hK*NBeZK6[+B+iB%bVuOJ%^uK~fIG}O-}%WLX*D
 ^aW>Gv8E3Xtz0\N&fQl^:pj<K{xM`:d>pPt:9lF-YXB%O)?@rd?*/jE!s94`?]:jJ#C5RDP:;M
 r.3lwo`0{vIT+<{%IRwe]vLd]7>\X|*z{TUX_t;?TPcOLBMIv8_V92!Vk(*DJVU~0M[`5D^PAW
 LniO1?YYWArMU*j9o+>?1MWi.lO?F-?aVt:qQ8OaG?R}B:I!7S_+KuzxZ.f9M@$z#n\bG2$Q2{od
In-reply-to: Your message of "19 Jun 1996 17:57:25 CST."
             <xjnpw6vwdne.fsf@hawaii.cs.unm.edu> 
Date: Thu, 20 Jun 1996 11:23:35 -0500
Message-ID: <14174.835287815@kocrsw12>
From: Mike Scheidler <c23mts@eng.delcoelect.com>


> Without the -with-xmu=yes it couldn't find libXmu and it got a number
> of undefinded symbols.

Thanks for this info.  I also experienced this error when building on sunos
4.1.3, but reconfiguring with "--with-xmu=yes" fixed it.

Since configure couldn't find the Xmu stuff on its own, I first tried
"--with-xmu=no", which supposedly uses replacement routines for the Xmu
stuff, but I still got the same unresolved symbols.  Am I misinterpreting
the purpose of this flag, or is it broken?

-- 
Mike Scheidler                     c23mts@eng.delcoelect.com
Corporate Software Technology
Delco Electronics Corporation      PHONE:  (317) 451-0319
Kokomo, IN 46904-9005              GMNET:  8-322-0319



From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 11:22:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA11267 for xemacs-beta-people; Thu, 20 Jun 1996 11:22:34 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA11264 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 11:22:33 -0500 (CDT)
Received: from tinderbox.Stanford.EDU (tinderbox.Stanford.EDU [171.64.72.13]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA22579 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 11:22:31 -0500 (CDT)
Received: by tinderbox.Stanford.EDU (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id JAA19878; Thu, 20 Jun 1996 09:22:34 -0700
Date: Thu, 20 Jun 1996 09:22:34 -0700
Message-Id: <199606201622.JAA19878@tinderbox.Stanford.EDU>
From: David Ofelt <ofelt@tinderbox.Stanford.EDU>
To: xemacs-beta@xemacs.org
Subject: Gnuattach


When I quit out of the tty buffer I started with gnuattach to send my
last mail message, it left my terminal in a bad state.

tinderbox%ls
DataMux.check         EMS.link2             Sdr
                                               DataMux.dc            EMS.mapped.db         Sdram.dc
                   DataMux.link          EMS.mapped.v          SdramDimm-Dave.dc
DataMux.link2         EMS.report            SdramDimm.check
                                                           DataMux.mapped.db     FakeEMS.check         SdramDimm.link
                                     DataMux.mapped.v      FakeEMS.dc            SdramDimm.link2
                DataMux.report        FakeEMS.link          SdramDimm.mapped.db
                                                                               EMS.check             FakeEMS.link2         SdramDimm.mapped.v
                                                             EMS.link              FakeEMS.report        SdramDimm.report



Where it should be:
DataMux.check         EMS.link2             Sdr
DataMux.dc            EMS.mapped.db         Sdram.dc
DataMux.link          EMS.mapped.v          SdramDimm-Dave.dc
DataMux.link2         EMS.report            SdramDimm.check
DataMux.mapped.db     FakeEMS.check         SdramDimm.link
DataMux.mapped.v      FakeEMS.dc            SdramDimm.link2
DataMux.report        FakeEMS.link          SdramDimm.mapped.db
EMS.check             FakeEMS.link2         SdramDimm.mapped.v
EMS.link              FakeEMS.report        SdramDimm.report

DaveO

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 11:38:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA11368 for xemacs-beta-people; Thu, 20 Jun 1996 11:38:55 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA11365 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 11:38:54 -0500 (CDT)
Received: from ives.phx.mcd.mot.com ([144.191.22.44]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA18424 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 11:38:55 -0500 (CDT)
Received: by ives.phx.mcd.mot.com (8.6.8.2/1.34.ives)
	id JAA02800; Thu, 20 Jun 1996 09:43:36 -0700
Date: Thu, 20 Jun 1996 09:43:36 -0700
Message-Id: <199606201643.JAA02800@ives.phx.mcd.mot.com>
From: "Lynn D. Newton" <lnewton@ives.phx.mcd.mot.com>
To: XEmacs Beta Bugs <xemacs-beta@cs.uiuc.edu>
Subject: good news and bad news
Reply-To: lnewton@ives.phx.mcd.mot.com
CC: randy_clayton@ives.phx.mcd.mot.com, steve_march@ives.phx.mcd.mot.com
X-Face:  FVNLrR&aQu[q[N3kO<A5Au*4b"pWyOi13$\H%OVNM8&P{?7;KTRLXSU)c'&Gg3{7GD.p:05
 To5$NCN#r-;vs&Qi@jhk\a@l;bMgx77!GI>4+!:X-+LgxFf'("(:8&7z+:!,24n1@j?C25:p>hno)_
 hPa5S&WgH"E-!{{N^-Cx}MiI_O'dU0
Comments: Hyperbole mail buttons accepted, v03.19.01.


THE GOOD NEWS:
-------------

The good news is that beta 25 built and installed and
came up on a Motorola Delta running SVR4, i.e.,
Motorola UNIX R40V4.4 on an 88k machine. This is the
first version we have been able to compile on this
platform since beta *15*! The problem was do to a bug
in our compiler. When we built and used a later version
of GCC (our standard compiler), the problem went away.
The configure options I used were:

./configure --prefix=/a/proj/gnu/xemacs-svr4-b25 \
	--with-gnu-make \
	--cflags=-O2 \
	--site-includes=/usr/tools/remote/contrib/xpm/include \
	--site-libraries=/usr/tools/remote/lib \
	--dynamic=yes \
        --with-scrollbars=lucid \
	--with-menubars=lucid \
        --with-dialogs=no \
	--with-xpm

THE BAD NEWS:
------------

The bad news is that it core dumps almost immediately.
A colleague at a different site compiled it separately,
using only slightly different (and irrelevant)
configure options and experienced the same thing. Here
is his report:

------- start of forwarded message (RFC 934 encapsulation) -------

    Lynn>  Well, I built beta 25 on SVR4, and it completed and
    Lynn> installed, which was a thrill, because it was the first time
    Lynn> I've been able to do that since beta 15.
    Lynn> 
    Lynn> After that I brought it up with -q -no-site-file and with just
    Lynn> -q. No problems. Then with .emacs.
    Lynn> 
    Lynn> The first time I try to exec an external process, e.g., when
    Lynn> running M-x shell or loading VM, it core dumps.

Yeah, for me too. Here is the message I get:

quaver 672 src/xemacs
Fatal error: assertion failed, file
/systest/work/rclayton/Build/xemacs-19.14-b25/src/frame.c, line 806,
RECORD_TYPEP (console, lrecord_device) || MARKED_RECORD_P (console)

Can you pass this up to the developers?

------- end -------

Is there any other information that is needed?

===============================================
Lynn D. Newton
Motorola Computer Group
Business: http://ives.phx.mcd.mot.com/~lnewton
Personal: http://www.eecs.umich.edu/~lnewton
===============================================

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 11:19:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA11257 for xemacs-beta-people; Thu, 20 Jun 1996 11:19:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA11254 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 11:19:41 -0500 (CDT)
Received: from tinderbox.Stanford.EDU (tinderbox.Stanford.EDU [171.64.72.13]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA22574 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 11:19:38 -0500 (CDT)
Received: by tinderbox.Stanford.EDU (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id JAA19852; Thu, 20 Jun 1996 09:19:39 -0700
Date: Thu, 20 Jun 1996 09:19:39 -0700
Message-Id: <199606201619.JAA19852@tinderbox.Stanford.EDU>
From: David Ofelt <ofelt@tinderbox.Stanford.EDU>
To: xemacs-beta@xemacs.org
Subject: gnuattach problems
In-Reply-To: <9606200134.AA41036@GS213.SP.CS.CMU.EDU>
References: <9606200134.AA41036@GS213.SP.CS.CMU.EDU>


Darrell Kindred writes:
 > - Run xemacs in the background (tcsh 6.04), then run gnuattach in the
 >   same tty to connect to it.  Both XEmacs and gnuattach hang (XEmacs
 >   is hung with tty output).  Putting gnuattach in the background and
 >   foregrounding XEmacs reactivates it.  If this condition can't be
 >   handled properly, can it at least be detected so gnuattach can exit
 >   with an error rather than blocking?  Or is this all beyond
 >   xemacs/gnuattach's control?

I just tried out gnuattach.  I have similar problems with b26.  When I
do a gnuattach from a tty to connect to my running X XEmacs windows,
the XEmacs process is suspended, and I have to go to the shell I
started it from and background it again.  

Another problem shows up when I try to define a region.  If I hit
C-space, I get the "mark set" message, but then if I move down a) no
region is highlighted, and when I go to yank the region, I get a "no
region is active now" message.  When I start a "-nw" XEmacs in a
shell, all the region stuff (including the zmacs highlighting) works
fine.

DaveO


From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 11:36:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA11345 for xemacs-beta-people; Thu, 20 Jun 1996 11:36:18 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA11342 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 11:36:17 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA18354 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 11:36:18 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id JAA25671; Thu, 20 Jun 1996 09:35:32 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [20.0 b25] patch for mule-misc.el
References: <199606201220.VAA07676@mikan.jaist.ac.jp>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: =?ISO-2022-JP?B?GyQoQjxpMiwbKEIgGyQoQkNOSScbKEI=?= / MORIOKA
 Tomohiko's message of 20 Jun 1996 05:20:05 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Jun 1996 09:35:29 -0700
Message-ID: <m2zq5ya0xa.fsf@deanna.miranova.com>
Lines: 17
X-Mailer: Gnus v5.2.22/XEmacs 20.0

>>>>> "Tomohiko" == MORIOKA Tomohiko <MORIOKA> writes:

Tomohiko>   Maybe it is caused by decode-coding-region.

Tomohiko>   Please insert following to ~/.emacs when it is broken:

Tomohiko> 	(setq code-converter-is-broken t)

Tomohiko> then emu uses own code-converter function.

Yup.  That makes it work again.  Thank you.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 11:53:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA11422 for xemacs-beta-people; Thu, 20 Jun 1996 11:53:18 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA11419 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 11:53:17 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA18714 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 11:53:19 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA07096; Thu, 20 Jun 1996 11:53:11 -0500 (CDT)
Message-Id: <199606201653.LAA07096@charles.cs.uiuc.edu>
To: lnewton@ives.phx.mcd.mot.com
cc: XEmacs Beta Bugs <xemacs-beta@cs.uiuc.edu>,
        randy_clayton@ives.phx.mcd.mot.com, steve_march@ives.phx.mcd.mot.com
Subject: Re: good news and bad news 
In-reply-to: Your message of "Thu, 20 Jun 1996 09:43:36 PDT."
             <199606201643.JAA02800@ives.phx.mcd.mot.com> 
Date: Thu, 20 Jun 1996 11:53:11 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Lynn> The bad news is that it core dumps almost immediately.  A
    Lynn> colleague at a different site compiled it separately, using
    Lynn> only slightly different (and irrelevant) configure options
    Lynn> and experienced the same thing. Here is his report:

Fixed in beta26.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 11:59:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA11442 for xemacs-beta-people; Thu, 20 Jun 1996 11:59:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA11439 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 11:59:46 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA18824 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 11:59:45 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id JAA26544; Thu, 20 Jun 1996 09:58:59 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: Neal Becker <Neal.Becker@comsat.com>
Subject: Re: libgr-2.0.8 available
References: <E0uWjOK-0004An-00@neal.ctd.comsat.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Neal Becker's message of 20 Jun 1996 06:03:20 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Jun 1996 09:58:57 -0700
Message-ID: <m2wx129zu6.fsf@deanna.miranova.com>
Lines: 31
X-Mailer: Gnus v5.2.22/XEmacs 20.0

>>>>> "Neal" == Neal Becker <Neal.Becker@comsat.com> writes:

Neal> libgr-2.0.8 is available from ftp.ctd.comsat.com:/pub/linux/ELF.
Neal> Changes are:

Neal> libpng-0.89c
Neal> zlib-1.0.2
Neal> build with -D_BSD_SOURCE

Neal> Note: the version number on zlib is now in sync with the number on the
Neal> package (1.0.2), which means the version number went down.  This will
Neal> confuse ldconf.  Sorry for any inconvenience.

I've updated the FAQ with a pointer to this and a pointer to libpng.

Libgr does not compile cleanly for me (Linux 2.0.0,Gcc 2.7.2no-srbug,
libc 5.3.12) :

gcc -c -fpic -fomit-frame-pointer -I. -O3 -D_BSD_SOURCE -I. -I. -I../../jpeg -I../../zlib -DJPEG_SUPPORT -DZIP_SUPPORT  tif_zip.c -o tif_zip.pic.o
tif_zip.c: In function `ZIPSetupEncode':
tif_zip.c:145: `DEFLATED' undeclared (first use this function)
tif_zip.c:145: (Each undeclared identifier is reported only once
tif_zip.c:145: for each function it appears in.)
make[2]: *** [tif_zip.pic.o] Error 1

What else needs to be upgraded as well?
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 12:09:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA11502 for xemacs-beta-people; Thu, 20 Jun 1996 12:09:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA11499 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 12:09:28 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA19078 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 12:09:30 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA26946; Thu, 20 Jun 1996 10:08:41 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: Neal Becker <Neal.Becker@comsat.com>
Subject: Re: libgr-2.0.8 available
References: <E0uWjOK-0004An-00@neal.ctd.comsat.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Neal Becker's message of 20 Jun 1996 06:03:20 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Jun 1996 10:08:39 -0700
Message-ID: <m2u3w69ze0.fsf@deanna.miranova.com>
Lines: 29
X-Mailer: Gnus v5.2.22/XEmacs 20.0

>>>>> "Neal" == Neal Becker <Neal.Becker@comsat.com> writes:

Neal> libgr-2.0.8 is available from ftp.ctd.comsat.com:/pub/linux/ELF.
Neal> Changes are:

Neal> libpng-0.89c
Neal> zlib-1.0.2
      ^^^^^^^^^^
Neal> build with -D_BSD_SOURCE

It looks like this change confuses libtiff.  Is this patch acceptable?

--- tif_zip.c.orig	Sun Jan 14 15:08:29 1996
+++ tif_zip.c	Thu Jun 20 10:03:35 1996
@@ -142,7 +142,7 @@
 	 * the decoder will fail.
 	 */
 	if (deflateInit2(&sp->stream, Z_DEFAULT_COMPRESSION,
-	    DEFLATED, -MAX_WBITS, DEF_MEM_LEVEL, 0) != Z_OK) {
+	    Z_DEFLATED, -MAX_WBITS, DEF_MEM_LEVEL, 0) != Z_OK) {
 		TIFFError(module, "%s: %s", tif->tif_name, sp->stream.msg);
 		return (0);
 	} else

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 11:58:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA11435 for xemacs-beta-people; Thu, 20 Jun 1996 11:58:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA11432 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 11:58:22 -0500 (CDT)
Received: from sys3.cambridge.uk.psi.net (sys3.cambridge.uk.psi.net [154.32.106.10]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA22669 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 11:58:17 -0500 (CDT)
Received: from arrow by sys3.cambridge.uk.psi.net (8.7.5/SMI-5.5-UKPSINet)
	id RAA21442; Thu, 20 Jun 1996 17:56:00 +0100 (BST)
Received: by arrow (5.x/SMI-SVR4)
	id AA29043; Thu, 20 Jun 1996 17:57:29 +0100
>Received: from dx2.delcam.com by delcam.com; Thu, 20 Jun 96 17:56:13 BST
Received: from delcam by arrow.delcam.com; Thu, 20 Jun 1996 17:57 BST
Received: from dx2.delcam.com by delcam.com; Thu, 20 Jun 96 17:56:13 BST
Received: by dx2.delcam.com; Thu, 20 Jun 96 17:52:50 +0100
Message-Id: <404.9606201652@dx2.delcam.com>
Date: Thu, 20 Jun 96 17:52:50 +0100
From: Paul Bibilo <peb@delcam.com>
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: b26 completion error in VM
In-Reply-To: John Turner's messaage of Thu 20 June 1996 08:08:50
References: <29709.9606200907@dx2.delcam.com>
	<199606201408.IAA10823@gielgud.lanl.gov.xdiv>
X-Face:  "+N/{>9S5,OIk<0$%[)LGd}<Mh,R;qNhl+C]O!g9wsh6Q65Wiv,#M#&,MjgG1?&]jTbwsn*
 _yj,NR}PT7"irWSgi|(H5w)Q1C0.dO:qt?=S`eF/EcT!L_1D7eJ&b-J5d#AoLu&}b#'}nq(^pr2+u*
 7'RvZp0xv:q/K&%WDOQ(+H?AJw7[|DcUK{}5S!;I4^9vFe$A2%G_oz3K#2d{m#[MnE,-hxq9Po9v]R
 t]j*0md[y/3R~J
Content-Type: text


John Turner writes:
 > Paul Bibilo writes:
 > 
 >  > I was in VM and decided to edit my .emacs.  I did C-x C-f ~/.em<TAB>
 >  > When I hit the tab key it XEmacs bleeped at me and said
 >  > Symbols function definition is void: hkey-help-show
 > 
 > If it's repeatable, I think it helps to set debug-on-error to t and
 > repeat to obtain a Lisp backtrace...
 > 

Here it is

Signalling: (void-function hkey-help-show)
  hkey-help-show(#<buffer "*Completions*">)
  minibuffer-completion-help()
  minibuffer-do-completion("~/.em")
  #<compiled-function (from "minibuf.elc") nil "...(97)" [last-command this-command nil minibuffer-scroll-window window windowp window-buffer buffer-name obuf (...) pos-visible-in-window-p set-window-start scroll-other-window minibuffer-do-completion buffer-string status none unique temp-minibuffer-message " [Sole completion]" exact " [Complete, but not unique]" t] 4 503268 nil>()
  call-interactively(minibuffer-complete)
  read-minibuffer-internal("Find file: ")
  byte-code("@ A V+
  read-from-minibuffer("Find file: " "~/" #<keymap read-file-name-map 2 entries 0x4e3> nil file-name-history)
  read-file-name-2(file-name-history "Find file: " nil nil nil nil read-file-name-internal)
  read-file-name-1(file-name-history "Find file: " nil nil nil nil read-file-name-internal)
  read-file-name("Find file: " nil nil nil)
  call-interactively(find-file)


-- Paul



From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 12:32:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA11645 for xemacs-beta-people; Thu, 20 Jun 1996 12:32:23 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA11642 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 12:32:22 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA19503 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 12:32:23 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA27700; Thu, 20 Jun 1996 10:31:38 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: loaddefs.el & premature evaluation of environment variables
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Jun 1996 10:31:32 -0700
Message-ID: <m2ohme9ybv.fsf@deanna.miranova.com>
Lines: 11
X-Mailer: Gnus v5.2.22/XEmacs 20.0

When a variable is designated as autoload, it gets its definition
pushed into prim/loaddefs.el, which gets evaluated when XEmacs is
dumped, and the environment variables contain no useful information.

Besides gnus-directory, message-user-organization, and
browse-url-grail have the same problem.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 12:25:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA11618 for xemacs-beta-people; Thu, 20 Jun 1996 12:25:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA11615 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 12:25:44 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA19382 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 12:25:38 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA27502; Thu, 20 Jun 1996 10:24:47 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Subject: Re: Gnus 5.2.20: SAVEDIR
References: <199606200515.XAA10443@gielgud.lanl.gov.xdiv>
	<w8s20jalg7y.fsf@ylfing.ifi.uio.no>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Lars Magne Ingebrigtsen's message of 20 Jun 1996 07:09:37 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Jun 1996 10:24:42 -0700
Message-ID: <m2rara9yn9.fsf@deanna.miranova.com>
Lines: 22
X-Mailer: Gnus v5.2.22/XEmacs 20.0

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

Lars> This is the definition of `gnus-directory':

(defvar gnus-directory (or (getenv "SAVEDIR") "~/News/")
  "*Directory variable from which all other Gnus file variables are derived.")

Omitting the crucial thing that makes this break:
;;;###autoload

Lars> So it should definitely be initialized from the SAVEDIR environment
Lars> variable...

It *is* being initialized from SAVEDIR, except that SAVEDIR is
evaluated when XEmacs is dumped due to this being an autoloaded
variable ...

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 12:51:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA11720 for xemacs-beta-people; Thu, 20 Jun 1996 12:51:26 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA11717 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 12:51:25 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA19991 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 12:51:26 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA07354; Thu, 20 Jun 1996 12:51:17 -0500 (CDT)
Message-Id: <199606201751.MAA07354@charles.cs.uiuc.edu>
To: Raymond Toy <toy@rtp.ericsson.se>
cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Re: Configuring for multiple architectures 
In-reply-to: Your message of "Wed, 19 Jun 1996 17:54:18 EDT."
             <22621.835221258@rtp.ericsson.se> 
Date: Thu, 20 Jun 1996 12:51:16 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Raymond> How do I do this with 19.14?  I tried to configure with
    Raymond> --exec-prefix=/apps/public/XEmacs/19.14/bin/arch, but, as
    Raymond> INSTALL says, the execs get installed in EXECDIR/bin.  If
    Raymond> I do so, xemacs can't find its lisp files.  I suppose I
    Raymond> could put in symlinks, but I was hoping for a better,
    Raymond> more automatic solution.

Same way you did it with 19.13.  Use --bindir.  Info on binary kits
coming as soon as I get the prerelease out the door.  That is several
hours off, though.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 13:05:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA11755 for xemacs-beta-people; Thu, 20 Jun 1996 13:05:07 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA11752 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 13:05:06 -0500 (CDT)
Received: from dowjones.com (gateway.dowjones.com [143.131.189.4]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA20277 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 13:05:08 -0500 (CDT)
Received: by dowjones.com; id OAA27247; Thu, 20 Jun 1996 14:16:11 -0400
Received: from wsj.dowjones.com(143.131.186.4) by gateway.dowjones.com via smap (V3.1)
	id xma027153; Thu, 20 Jun 96 14:15:28 -0400
Received: from nss_interbox.dowjones.com ([143.131.190.35]) by wsj.dowjones.com (5.x/SMI-SVR4)
	id AA00540; Thu, 20 Jun 1996 14:04:44 -0400
Message-Id: <31C6FDC8.66F6@nrs.dowjones.com>
Date: Tue, 18 Jun 1996 14:04:40 -0500
From: wkirk <wkirk@wsj.dowjones.com>
Organization: Dow Jones & Company, Inc.
X-Mailer: Mozilla 2.0 (Win16; U)
Mime-Version: 1.0
To: xemacs-beta@cs.uiuc.edu
Subject: toolbar redisplay beta 26
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The following code, and variations on it, leads to interesting results

(let ((buf (current-buffer)))
  (set-specifier default-toolbar-visible-p (cons (current-buffer) nil))
  (redisplay-frame)
  (sit-for 1)
  (switch-to-buffer "*dumb*")
  (switch-to-buffer buf)
  (sit-for 1)
  (set-specifier default-toolbar-visible-p (cons (current-buffer) t)))

This code will eval with no visible effect.  However, if you obscure
part of the emacs frame with another window after evaling this code and
then unobscure that part, the toolbar will have disappeared from the
part of the frame that was obscured.  Switching to another buffer and
then back to the original one causes re-display to happen.

I personally expected that just setting default-toolbar-visible-p would
cause the toolbar to disappear.  I at least expected that the call
to redisplay-frame would, well, redisplay the frame, sans toolbar as
specified.

If calls to (redisplay-frame) are inserted after each of the
switch-to-buffer's, then the frame gets drawn without a toolbar, even
though the last set-specifier should turn it back on.

It looks like the redisplay code isn't properly checking for changes
to the visibility of the toolbar.  If you unconditionally set the
specifier (as the options menu does), then the toolbar does (dis)appear.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 12:56:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA11728 for xemacs-beta-people; Thu, 20 Jun 1996 12:56:13 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA11725 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 12:56:12 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20100; Thu, 20 Jun 1996 12:56:13 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id MAA01837; Thu, 20 Jun 1996 12:55:42 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id MAA06657; Thu, 20 Jun 1996 12:55:41 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id NAA03936; Thu, 20 Jun 1996 13:50:56 -0400
To: Chuck Thompson <cthomp@cs.uiuc.edu>
cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
References: <199606201751.MAA07354@charles.cs.uiuc.edu> 
Subject: Re: Configuring for multiple architectures 
In-reply-to: (Your message of Thu, 20 Jun 1996 12:51:16 CDT.)
             <199606201751.MAA07354@charles.cs.uiuc.edu> 
Date: Thu, 20 Jun 1996 13:50:56 -0400
Message-ID: <28127.835293056@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:


    Raymond> How do I do this with 19.14?  I tried to configure with
    Raymond> --exec-prefix=/apps/public/XEmacs/19.14/bin/arch, but, as
    Raymond> INSTALL says, the execs get installed in EXECDIR/bin.  If
    Raymond> I do so, xemacs can't find its lisp files.  I suppose I
    Raymond> could put in symlinks, but I was hoping for a better,
    Raymond> more automatic solution.

    Chuck> Same way you did it with 19.13.  Use --bindir.  Info on
    Chuck> binary kits coming as soon as I get the prerelease out the
    Chuck> door.  That is several hours off, though.

Thanks.  I didn't save any mail from 19.13 vintage, and it's been so
long since 19.13 that I forgot how it was done.

Ray

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 12:57:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA11735 for xemacs-beta-people; Thu, 20 Jun 1996 12:57:08 -0500 (CDT)
Received: from c.cs.uiuc.edu (c.cs.uiuc.edu [128.174.252.3]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA11732 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 12:57:07 -0500 (CDT)
Received: from dowjones.com (gateway.dowjones.com [143.131.189.4]) by c.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA10788 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 12:57:06 -0500 (CDT)
Received: by dowjones.com; id OAA25295; Thu, 20 Jun 1996 14:03:13 -0400
Received: from wsj.dowjones.com(143.131.186.4) by gateway.dowjones.com via smap (V3.1)
	id xma025228; Thu, 20 Jun 96 14:02:32 -0400
Received: from nss_interbox.dowjones.com ([143.131.190.35]) by wsj.dowjones.com (5.x/SMI-SVR4)
	id AA00325; Thu, 20 Jun 1996 13:51:48 -0400
Message-Id: <31C6FABE.6FFA@nrs.dowjones.com>
Date: Tue, 18 Jun 1996 13:51:42 -0500
From: wkirk <wkirk@wsj.dowjones.com>
Organization: Dow Jones & Company, Inc.
X-Mailer: Mozilla 2.0 (Win16; U)
Mime-Version: 1.0
To: xemacs-beta@cs.uiuc.edu
Subject: beta 26 build `ok' on Linux 1.2.13
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Details:

configure --cflags='-O2 -m486' --with-menubars=lucid --with-scrollbars=lucid \
 --with-dialogs=lucid --with-xpm --prefix=/usr/beta/ --dynamic --debug=no \
 --error-checking=none

Configured for `i686-unknown-linux1.2.13'.

  Where should the build process find the source code?    /root/tar/xemacs-19.14-b26-accel
  What installation prefix should install use?            /usr/beta/
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -O2 -m486
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                 /usr/include/ncurses
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 13:16:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA11876 for xemacs-beta-people; Thu, 20 Jun 1996 13:16:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA11873 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 13:16:50 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20665 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 13:16:52 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA07505; Thu, 20 Jun 1996 13:16:49 -0500 (CDT)
Message-Id: <199606201816.NAA07505@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: loaddefs.el & premature evaluation of environment variables 
In-reply-to: Your message of "20 Jun 1996 10:31:32 PDT."
             <m2ohme9ybv.fsf@deanna.miranova.com> 
Date: Thu, 20 Jun 1996 13:16:48 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Steven> When a variable is designated as autoload, it gets its
    Steven> definition pushed into prim/loaddefs.el, which gets
    Steven> evaluated when XEmacs is dumped, and the environment
    Steven> variables contain no useful information.

    Steven> Besides gnus-directory, message-user-organization, and
    Steven> browse-url-grail have the same problem.


browse-url-grail has to be autoloaded at the moment but do the others?



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 13:17:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA11885 for xemacs-beta-people; Thu, 20 Jun 1996 13:17:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA11882 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 13:17:07 -0500 (CDT)
Received: from dowjones.com (gateway.dowjones.com [143.131.189.4]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA20672 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 13:17:08 -0500 (CDT)
Received: by dowjones.com; id OAA29016; Thu, 20 Jun 1996 14:28:12 -0400
Received: from wsj.dowjones.com(143.131.186.4) by gateway.dowjones.com via smap (V3.1)
	id xma028869; Thu, 20 Jun 96 14:27:28 -0400
Received: from nss_interbox.dowjones.com ([143.131.190.35]) by wsj.dowjones.com (5.x/SMI-SVR4)
	id AA00763; Thu, 20 Jun 1996 14:16:44 -0400
Message-Id: <31C70099.28B7@nrs.dowjones.com>
Date: Tue, 18 Jun 1996 14:16:41 -0500
From: wkirk <wkirk@wsj.dowjones.com>
Organization: Dow Jones & Company, Inc.
X-Mailer: Mozilla 2.0 (Win16; U)
Mime-Version: 1.0
To: xemacs-beta@cs.uiuc.edu
Subject: minimum frame heights
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Even with xrdb -load /dev/null to get rid of my .Xdefaults font settings,
XEmacs 19.14B26 will allow me to resize a frame small enough to 
obscure the minibuffer/echo area and part of the modeline.

I was surprised when initial-frame-plist let me specify a height of 1
for the frame and actually displayed it.  Shouldn't a frame's minimum
height be the same as the minimum window height or at least large
enough that both the modeline and echo area can continue to be displayed.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 13:27:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA11944 for xemacs-beta-people; Thu, 20 Jun 1996 13:27:53 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA11941 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 13:27:52 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20850 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 13:27:54 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA07570; Thu, 20 Jun 1996 13:27:49 -0500 (CDT)
Message-Id: <199606201827.NAA07570@charles.cs.uiuc.edu>
To: wkirk <wkirk@wsj.dowjones.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: minimum frame heights 
In-reply-to: Your message of "Tue, 18 Jun 1996 14:16:41 CDT."
             <31C70099.28B7@nrs.dowjones.com> 
Date: Thu, 20 Jun 1996 13:27:49 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    wkirk> Even with xrdb -load /dev/null to get rid of my .Xdefaults
    wkirk> font settings, XEmacs 19.14B26 will allow me to resize a
    wkirk> frame small enough to obscure the minibuffer/echo area and
    wkirk> part of the modeline.

    wkirk> I was surprised when initial-frame-plist let me specify a
    wkirk> height of 1 for the frame and actually displayed it.
    wkirk> Shouldn't a frame's minimum height be the same as the
    wkirk> minimum window height or at least large enough that both
    wkirk> the modeline and echo area can continue to be displayed.


I changed the minimum to 1 for minibuffer-only frames which can
legitimately have a height of 1.  The minimum height should really
depend on whether or not the frame is minibuffer-only or not.  I don't
want to fix this particular bug this close to release especially since
there is an easy enough workaround.  Don't resize the frame that small
:-)



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 13:33:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA11967 for xemacs-beta-people; Thu, 20 Jun 1996 13:33:03 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA11964 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 13:33:02 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20943; Thu, 20 Jun 1996 13:33:02 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA29245; Thu, 20 Jun 1996 11:32:17 -0700
Sender: steve@miranova.com
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: loaddefs.el & premature evaluation of environment variables
References: <199606201816.NAA07505@charles.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Thu, 20 Jun 1996 13:16:48 -0500
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Jun 1996 11:32:16 -0700
Message-ID: <m2vigm9vin.fsf@deanna.miranova.com>
Lines: 31
X-Mailer: Gnus v5.2.23/XEmacs 19.14

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

Steven> When a variable is designated as autoload, it gets its
Steven> definition pushed into prim/loaddefs.el, which gets
Steven> evaluated when XEmacs is dumped, and the environment
Steven> variables contain no useful information.

Steven> Besides gnus-directory, message-user-organization, and
Steven> browse-url-grail have the same problem.


Chuck> browse-url-grail has to be autoloaded at the moment but do the
Chuck> others?

Probably if autoloading a variable means what I think it means (this
is not an area that I've ever explored deeply in my years of
emacsing).

What does autoloading a variable do other than put the doc string in
the DOC file, and force evaluation of the variable at XEmacs dump
time?

Also, you'll have to arrange for browse-url-grail to be evaluated at
run time, else the getenv on GRAILDIR will be futile.

Regards,
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 13:38:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA11983 for xemacs-beta-people; Thu, 20 Jun 1996 13:38:00 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA11980 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 13:37:59 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA21008 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 13:38:01 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA07632; Thu, 20 Jun 1996 13:37:54 -0500 (CDT)
Message-Id: <199606201837.NAA07632@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: loaddefs.el & premature evaluation of environment variables 
In-reply-to: Your message of "20 Jun 1996 11:32:16 PDT."
             <m2vigm9vin.fsf@deanna.miranova.com> 
Date: Thu, 20 Jun 1996 13:37:54 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Steven> Probably if autoloading a variable means what I think it
    Steven> means (this is not an area that I've ever explored deeply
    Steven> in my years of emacsing).

autoloading a variable means that it is always bound.  The reason
browse-url-grail has to be autoloaded is because it is referenced by
the menubar code.  I tend to doubt if gnus-directory is referenced
unless someone activates gnus which will cause it be loaded anyhow.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 13:46:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA12028 for xemacs-beta-people; Thu, 20 Jun 1996 13:46:56 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA12025 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 13:46:54 -0500 (CDT)
Received: from uni-kl.de (stepsun.uni-kl.de [131.246.136.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA21720 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 13:46:51 -0500 (CDT)
Received: from corp-200.dfki.uni-kl.de by stepsun.uni-kl.de id aa21264;
          20 Jun 96 20:46 MET DST
Received: from serv-302.dfki.uni-kl.de (burt@serv-302 [131.246.242.102]) by corp-200.dfki.uni-kl.de (8.7.5/8.7.3) with ESMTP id UAA18277 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 20:46:26 +0200 (MET DST)
Organization: DFKI Kaiserslautern GmbH, D 67663 Kaiserslautern
Received: (from burt@localhost) by serv-302.dfki.uni-kl.de (8.7.5/8.7.3) id UAA24176 for xemacs-beta@cs.uiuc.edu; Thu, 20 Jun 1996 20:46:09 +0200 (MET DST)
Date: Thu, 20 Jun 1996 20:46:09 +0200 (MET DST)
Message-Id: <199606201846.UAA24176@serv-302.dfki.uni-kl.de>
From: Alastair Burt <burt@dfki.uni-kl.de>
To: XEmacs Beta Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: xemacs-19.14-b26 compiled
Content-Type: text

  Configured for `sparc-sun-solaris2.5'.

    Where should the build process find the source code?    /home/burt/tmp/xemacs-19.14-b26
    What installation prefix should install use?		  /usr/local
    What operating system and machine description files should XEmacs use?
	  `s/sol2-5.h' and `m/sparc.h'
    What compiler should XEmacs be built with?              gcc  -g -O 
    Should XEmacs use the GNU version of malloc?            yes
    Should XEmacs use the relocating allocator for buffers? yes
    What window system should XEmacs use?                   x11
    Where do we find X Windows header files?                /opt/X11/include
    Where do we find X Windows libraries?                   /opt/X11/lib
    Compiling in support for XAUTH.
    Compiling in support for XPM.
    Compiling in support for GIF image conversion.
    Compiling in support for JPEG image conversion.
    Compiling in native sound support.
    Compiling in support for DBM.
    Compiling in support for CDE.
    Using the Lucid menubar.
    Using the Lucid scrollbar.
    Using the Motif dialog boxes.
    Compiling in extra code for debugging.

Initial compilation failed due to lack of jerror.h.

  Producing `src/paths.h' from `src/paths.h.in'.
  rm -f src/paths.h.tmp
  chmod 0644 src/paths.h.tmp
  src/paths.h is unchanged
  cd lib-src; make all  \
	  CC='gcc' CFLAGS='-g -O' MAKE='make'
  cd lwlib; make all  \
	  CC='gcc' CFLAGS='-g -O' MAKE='make'
  cd dynodump; make all  \
	  CC='gcc' CFLAGS='-g -O' MAKE='make'
  cd src; make all  \
	  CC='gcc' CFLAGS='-g -O' MAKE='make'
  gcc -c -Demacs -DHAVE_CONFIG_H  -I. 	   -I/home/burt/tmp/xemacs-19.14-b26/src       	     -I/opt/X11/include    	   -I/usr/dt/include  -I/home/burt/tmp/xemacs-19.14-b26/src/../lwlib -g -O glyphs-x.c
  glyphs-x.c:1051: jerror.h: No such file or directory

Reconfigured specifying "--with-jpeg=no".  Compiled OK.

--- alastair


From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 13:46:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA12014 for xemacs-beta-people; Thu, 20 Jun 1996 13:46:09 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA12011 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 13:46:08 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA21608; Thu, 20 Jun 1996 13:46:08 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA29484; Thu, 20 Jun 1996 11:45:22 -0700
Sender: steve@miranova.com
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: loaddefs.el & premature evaluation of environment variables
References: <199606201837.NAA07632@charles.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Thu, 20 Jun 1996 13:37:54 -0500
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Jun 1996 11:45:21 -0700
Message-ID: <m2k9x29uwu.fsf@deanna.miranova.com>
Lines: 23
X-Mailer: Gnus v5.2.23/XEmacs 19.14

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

Steven> Probably if autoloading a variable means what I think it
Steven> means (this is not an area that I've ever explored deeply
Steven> in my years of emacsing).

Chuck> autoloading a variable means that it is always bound.  The reason
Chuck> browse-url-grail has to be autoloaded is because it is referenced by
Chuck> the menubar code.  I tend to doubt if gnus-directory is referenced
Chuck> unless someone activates gnus which will cause it be loaded anyhow.

I see.  No, they do not need to be autoloaded.  Is this correct Lars?

What can be done about browse-url-grail then?  Is there something
better than assigning a dummy value for loaddefs.el, and then
attaching a load hook to stuff the right value in when browse-url is
loaded?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 14:04:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA12120 for xemacs-beta-people; Thu, 20 Jun 1996 14:04:20 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA12117 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 14:04:19 -0500 (CDT)
Received: from gcm.com (gcm.com [146.121.48.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA29337 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 14:04:14 -0500 (CDT)
Received: (from uucp@localhost) by gcm.com (8.6.9/8.6.9) with UUCP id PAA09959 for xemacs-beta@xemacs.org; Thu, 20 Jun 1996 15:07:43 -0400
Received: from mis_bo9.it.gcm.com by gcm.com (4.1/GCM-2.0m)
	id AA20416; Thu, 20 Jun 96 15:03:11 EDT
Received: by mis_bo9.it.gcm.com (4.1/SMI-4.1)
	id AA20527; Thu, 20 Jun 96 15:03:11 EDT
Sender: dcw@gcm.com
To: xemacs-beta@xemacs.org
Subject: Re: 19.14b25 fail - :help-string
References: <Pine.SUN.3.91.960620114343.20039A-200000@mis_bo9>
From: David Worenklein <dcw@gcm.com>
Date: 20 Jun 1996 15:03:10 -0400
In-Reply-To: David Worenklein's message of Thu, 20 Jun 1996 11:46:06 -0400 (EDT)
Message-Id: <am91dil2mp.fsf@gcm.com>
Lines: 9
X-Mailer: Gnus v5.2.19/XEmacs 19.13

I re-loaded the offending package and it was better. Sounds like I had
a bytecomp out of date.
--
 David C. Worenklein                                       GREENWICH   CAPITAL
 Operations Support                                        M a r k e t s,  Inc
 =============================================================================
 phone: 203-625-2945                                                      ====
 fax:   203-629-2535                                                      ====
 e-mail: dcw@gcm.com                                                      ====

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 14:51:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA12346 for xemacs-beta-people; Thu, 20 Jun 1996 14:51:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA12343 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 14:51:48 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA25443 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 14:51:51 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA07827; Thu, 20 Jun 1996 14:51:46 -0500 (CDT)
Message-Id: <199606201951.OAA07827@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: loaddefs.el & premature evaluation of environment variables 
In-reply-to: Your message of "20 Jun 1996 11:45:21 PDT."
             <m2k9x29uwu.fsf@deanna.miranova.com> 
Date: Thu, 20 Jun 1996 14:51:46 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Steven> I see.  No, they do not need to be autoloaded.  Is this
    Steven> correct Lars?

I've gone ahead and removed the autoloads of gnus-directory
message-user-organization.


    Steven> What can be done about browse-url-grail then?  Is there
    Steven> something better than assigning a dummy value for
    Steven> loaddefs.el, and then attaching a load hook to stuff the
    Steven> right value in when browse-url is loaded?

This turned out to be easy once I actually looked at it.  The function
browse-url-grail needs to be autoloaded.  The variable does not.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 14:50:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA12338 for xemacs-beta-people; Thu, 20 Jun 1996 14:50:35 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA12335 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 14:50:34 -0500 (CDT)
Received: from dowjones.com (gateway.dowjones.com [143.131.189.4]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA25410 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 14:50:29 -0500 (CDT)
Received: by dowjones.com; id QAA07681; Thu, 20 Jun 1996 16:01:33 -0400
Received: from wsj.dowjones.com(143.131.186.4) by gateway.dowjones.com via smap (V3.1)
	id xma007668; Thu, 20 Jun 96 16:01:22 -0400
Received: from nss_interbox.dowjones.com ([143.131.190.35]) by wsj.dowjones.com (5.x/SMI-SVR4)
	id AA02588; Thu, 20 Jun 1996 15:50:38 -0400
Message-Id: <31C7169C.28C@nrs.dowjones.com>
Date: Tue, 18 Jun 1996 15:50:36 -0500
From: wkirk <wkirk@wsj.dowjones.com>
Organization: Dow Jones & Company, Inc.
X-Mailer: Mozilla 2.0 (Win16; U)
Mime-Version: 1.0
To: xemacs-beta@cs.uiuc.edu
Subject: core dump from balloon-help
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

On Linux-1.2.13 running XEmacs 19.14b26 (compiled with gcc -O -g -m486)

Running balloon-help (M-x load-library balloon-help) from a fresh emacs.
% xrdb -load /dev/null
% xemacs -q
Positioning the cursor over a toolbar icon causes a window to appear
for about a tenth of a second before it disappears.  Exiting emacs
results in the following wonderful core dump with backtrace

Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb `which xemacs` core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

gdb backtrace:

#0  0x501806ba in LINES ()
#1  0x501ee404 in LINES ()
#2  0x8026a42 in fatal_error_signal (sig=11) at emacs.c:193
#3  0xbffff27c in LINES ()
#4  0x50084add in LINES ()
#5  0x50084add in LINES ()
#6  0x50084add in LINES ()
#7  0x50084add in LINES ()
#8  0x50084add in LINES ()
#9  0x50084cd4 in LINES ()
#10 0x80b0710 in x_get_frame_parent (f=0x8346a00) at frame-x.c:1772
#11 0x80531b4 in delete_frame_internal (f=0x8346a00, force=1, 
    called_from_delete_device=1, from_io_error=0) at frame.c:1317
#12 0x801ec41 in delete_device_internal (d=0x8260b00, force=1, 
    called_from_delete_console=1, from_io_error=0) at device.c:767
#13 0x8017f1f in delete_console_internal (con=0x8277b00, force=1, 
    called_from_kill_emacs=1, from_io_error=0) at console.c:697
#14 0x80278c3 in Fkill_emacs (arg=404520964) at emacs.c:1482
#15 0x802bcc5 in primitive_funcall (fn=0x8027820 <Fkill_emacs>, nargs=1, 
    args=0xbffff4d0) at eval.c:3484
#16 0x802bed8 in funcall_subr (subr=0x80f323c, args=0xbffff4d0) at 
eval.c:3526
#17 0x802b600 in funcall_recording_as (recorded_as=404607796, nargs=1, 
    args=0xbffff52c) at eval.c:3207
#18 0x802b6f3 in Ffuncall (nargs=1, args=0xbffff52c) at eval.c:3253
#19 0x80116e6 in Fbyte_code (bytestr=940912276, vector=1209347840, 
maxdepth=5)
    at bytecode.c:450
#20 0x802c228 in funcall_lambda (fun=404041700, nargs=1, 
arg_vector=0xbffff644)
    at eval.c:3636
#21 0x802b6ae in funcall_recording_as (recorded_as=404607868, nargs=2, 
    args=0xbffff640) at eval.c:3223
#22 0x802b6f3 in Ffuncall (nargs=2, args=0xbffff640) at eval.c:3253
#23 0x8013c4d in Fcall_interactively (function=404607868, 
    record_flag=404520964, keys=404520964) at callint.c:896
#24 0x802bced in primitive_funcall (fn=0x8012b60 <Fcall_interactively>, 
    nargs=3, args=0xbffff730) at eval.c:3488
#25 0x802bed8 in funcall_subr (subr=0x80f15cc, args=0xbffff730) at 
eval.c:3526
#26 0x802b600 in funcall_recording_as (recorded_as=404597148, nargs=2, 
    args=0xbffff78c) at eval.c:3207
#27 0x802b6f3 in Ffuncall (nargs=2, args=0xbffff78c) at eval.c:3253
#28 0x802c7df in call1 (fn=404597148, arg0=404607868) at eval.c:3994
#29 0x80359d4 in execute_command_event (command_builder=0x8208f00, 
    event=405892584) at event-stream.c:3472
#30 0x8035fbe in Fdispatch_event (event=405892584) at event-stream.c:3815
#31 0x80165eb in Fcommand_loop_1 () at cmdloop.c:542
#32 0x801647c in command_loop_1 (dummy=404520964) at cmdloop.c:462
#33 0x80296b9 in condition_case_1 (handlers=404521060, 
    bfun=0x8016460 <command_loop_1>, barg=404520964, 
    hfun=0x8015f00 <cmd_error>, harg=404520964) at eval.c:1672
#34 0x8015fe0 in command_loop_3 () at cmdloop.c:224
#35 0x8016008 in command_loop_2 (dummy=404520964) at cmdloop.c:235
#36 0x8029399 in internal_catch (tag=404598180, 
    func=0x8016000 <command_loop_2>, arg=404520964, threw=0x0) at 
eval.c:1347
#37 0x801619c in initial_command_loop (load_me=404520964) at 
cmdloop.c:273
#38 0x80274d4 in main_1 (argc=1, argv=0xbffff978, envp=0xbffff980)
    at emacs.c:1317
#39 0x802780e in main (argc=1, argv=0xbffff978, envp=0xbffff980)
    at emacs.c:1439
#40 0x8006705 in _start ()
#41 0x8013c4d in Fcall_interactively (function=404607868, 
    record_flag=404520964, keys=404520964) at callint.c:896
#42 0x802bced in primitive_funcall (fn=0x8012b60 <Fcall_interactively>, 
    nargs=3, args=0xbffff730) at eval.c:3488
#43 0x802bed8 in funcall_subr (subr=0x80f15cc, args=0xbffff730) at 
eval.c:3526
#44 0x802b600 in funcall_recording_as (recorded_as=404597148, nargs=2, 
    args=0xbffff78c) at eval.c:3207
#45 0x802b6f3 in Ffuncall (nargs=2, args=0xbffff78c) at eval.c:3253
#46 0x802c7df in call1 (fn=404597148, arg0=404607868) at eval.c:3994
#47 0x80359d4 in execute_command_event (command_builder=0x8208f00, 
    event=405892584) at event-stream.c:3472
#48 0x8035fbe in Fdispatch_event (event=405892584) at event-stream.c:3815
#49 0x80165eb in Fcommand_loop_1 () at cmdloop.c:542
#50 0x801647c in command_loop_1 (dummy=404520964) at cmdloop.c:462
#51 0x80296b9 in condition_case_1 (handlers=404521060, 
    bfun=0x8016460 <command_loop_1>, barg=404520964, 
    hfun=0x8015f00 <cmd_error>, harg=404520964) at eval.c:1672
#52 0x8015fe0 in command_loop_3 () at cmdloop.c:224
#53 0x8016008 in command_loop_2 (dummy=404520964) at cmdloop.c:235
#54 0x8029399 in internal_catch (tag=404598180, 
    func=0x8016000 <command_loop_2>, arg=404520964, threw=0x0) at 
eval.c:1347
#55 0x801619c in initial_command_loop (load_me=404520964) at 
cmdloop.c:273
#56 0x80274d4 in main_1 (argc=1, argv=0xbffff978, envp=0xbffff980)
    at emacs.c:1317
#57 0x802780e in main (argc=1, argv=0xbffff978, envp=0xbffff980)
    at emacs.c:1439
#58 0x8006705 in _start ()
#59 0x8013c4d in Fcall_interactively (function=404607868, 
    record_flag=404520964, keys=404520964) at callint.c:896
#60 0x802bced in primitive_funcall (fn=0x8012b60 <Fcall_interactively>, 
    nargs=3, args=0xbffff730) at eval.c:3488
#61 0x802bed8 in funcall_subr (subr=0x80f15cc, args=0xbffff730) at 
eval.c:3526
#62 0x802b600 in funcall_recording_as (recorded_as=404597148, nargs=2, 
    args=0xbffff78c) at eval.c:3207
#63 0x802b6f3 in Ffuncall (nargs=2, args=0xbffff78c) at eval.c:3253
#64 0x802c7df in call1 (fn=404597148, arg0=404607868) at eval.c:3994
#65 0x80359d4 in execute_command_event (command_builder=0x8208f00, 
    event=405892584) at event-stream.c:3472
#66 0x8035fbe in Fdispatch_event (event=405892584) at event-stream.c:3815
#67 0x80165eb in Fcommand_loop_1 () at cmdloop.c:542
#68 0x801647c in command_loop_1 (dummy=404520964) at cmdloop.c:462
#69 0x80296b9 in condition_case_1 (handlers=404521060, 
    bfun=0x8016460 <command_loop_1>, barg=404520964, 
    hfun=0x8015f00 <cmd_error>, harg=404520964) at eval.c:1672
#70 0x8015fe0 in command_loop_3 () at cmdloop.c:224
#71 0x8016008 in command_loop_2 (dummy=404520964) at cmdloop.c:235
#72 0x8029399 in internal_catch (tag=404598180, 
    func=0x8016000 <command_loop_2>, arg=404520964, threw=0x0) at 
eval.c:1347
#73 0x801619c in initial_command_loop (load_me=404520964) at 
cmdloop.c:273
#74 0x80274d4 in main_1 (argc=1, argv=0xbffff978, envp=0xbffff980)
    at emacs.c:1317
#75 0x802780e in main (argc=1, argv=0xbffff978, envp=0xbffff980)
    at emacs.c:1439
#76 0x8006705 in _start ()
#77 0x8013c4d in Fcall_interactively (function=404607868, 
    record_flag=404520964, keys=404520964) at callint.c:896
#78 0x802bced in primitive_funcall (fn=0x8012b60 <Fcall_interactively>, 
    nargs=3, args=0xbffff730) at eval.c:3488
#79 0x802bed8 in funcall_subr (subr=0x80f15cc, args=0xbffff730) at 
eval.c:3526
#80 0x802b600 in funcall_recording_as (recorded_as=404597148, nargs=2, 
    args=0xbffff78c) at eval.c:3207
#81 0x802b6f3 in Ffuncall (nargs=2, args=0xbffff78c) at eval.c:3253
#82 0x802c7df in call1 (fn=404597148, arg0=404607868) at eval.c:3994
#83 0x80359d4 in execute_command_event (command_builder=0x8208f00, 
    event=405892584) at event-stream.c:3472
#84 0x8035fbe in Fdispatch_event (event=405892584) at event-stream.c:3815
#85 0x80165eb in Fcommand_loop_1 () at cmdloop.c:542
#86 0x801647c in command_loop_1 (dummy=404520964) at cmdloop.c:462
#87 0x80296b9 in condition_case_1 (handlers=404521060, 
    bfun=0x8016460 <command_loop_1>, barg=404520964, 
    hfun=0x8015f00 <cmd_error>, harg=404520964) at eval.c:1672
#88 0x8015fe0 in command_loop_3 () at cmdloop.c:224
#89 0x8016008 in command_loop_2 (dummy=404520964) at cmdloop.c:235
#90 0x8029399 in internal_catch (tag=404598180, 
    func=0x8016000 <command_loop_2>, arg=404520964, threw=0x0) at 
eval.c:1347
#91 0x801619c in initial_command_loop (load_me=404520964) at 
cmdloop.c:273
#92 0x80274d4 in main_1 (argc=1, argv=0xbffff978, envp=0xbffff980)
    at emacs.c:1317
#93 0x802780e in main (argc=1, argv=0xbffff978, envp=0xbffff980)
    at emacs.c:1439
#94 0x8006705 in _start ()
#95 0x8013c4d in Fcall_interactively (function=404607868, 
    record_flag=404520964, keys=404520964) at callint.c:896
#96 0x802bced in primitive_funcall (fn=0x8012b60 <Fcall_interactively>, 
    nargs=3, args=0xbffff730) at eval.c:3488
#97 0x802bed8 in funcall_subr (subr=0x80f15cc, args=0xbffff730) at 
eval.c:3526
#98 0x802b600 in funcall_recording_as (recorded_as=404597148, nargs=2, 
    args=0xbffff78c) at eval.c:3207
#99 0x802b6f3 in Ffuncall (nargs=2, args=0xbffff78c) at eval.c:3253
#100 0x802c7df in call1 (fn=404597148, arg0=404607868) at eval.c:3994
#101 0x80359d4 in execute_command_event (command_builder=0x8208f00, 
    event=405892584) at event-stream.c:3472
#102 0x8035fbe in Fdispatch_event (event=405892584) at 
event-stream.c:3815
#103 0x80165eb in Fcommand_loop_1 () at cmdloop.c:542
#104 0x801647c in command_loop_1 (dummy=404520964) at cmdloop.c:462
#105 0x80296b9 in condition_case_1 (handlers=404521060, 
    bfun=0x8016460 <command_loop_1>, barg=404520964, 
    hfun=0x8015f00 <cmd_error>, harg=404520964) at eval.c:1672

[...]

At this point I stopped recording the backtrace.  If you need more it 
goes to
at least 900 frames.  :-)

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 15:04:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA12381 for xemacs-beta-people; Thu, 20 Jun 1996 15:04:38 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA12378 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 15:04:37 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA25663 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 15:04:38 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id NAA31345; Thu, 20 Jun 1996 13:03:52 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: gnuattach problems
References: <9606200134.AA41036@GS213.SP.CS.CMU.EDU>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Darrell Kindred's message of Wed, 19 Jun 1996 21:34:14 -0400
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Jun 1996 13:03:49 -0700
Message-ID: <m2688m9ra2.fsf@deanna.miranova.com>
Lines: 28
X-Mailer: Gnus v5.2.23/XEmacs 19.14

>>>>> "Darrell" == Darrell Kindred <dkindred+@cmu.edu> writes:

Darrell> Noticed a few problems I don't have time to work on tonight.

Darrell> - Run gnuattach then exit with C-x #.  I don't get a shell
Darrell>   prompt until I press return.  Maybe gnuattach is exiting
Darrell>   before xemacs is quite done with the tty?

>>>>> "David" == David Ofelt <ofelt@tinderbox.Stanford.EDU> writes:

David> Another problem shows up when I try to define a region.  If I hit
David> C-space, I get the "mark set" message, but then if I move down a) no
David> region is highlighted, and when I go to yank the region, I get a "no
David> region is active now" message.  When I start a "-nw" XEmacs in a
David> shell, all the region stuff (including the zmacs highlighting) works
David> fine.

I have encountered both of these problems as well, although I now get
a new shell prompt since upgrading to the latest zsh beta.  It
definitely does not return cleanly to lynx 2.5FM.

As I reported earlier, gnuattach is not restoring the previous tty
settings as well.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 15:45:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA12565 for xemacs-beta-people; Thu, 20 Jun 1996 15:45:48 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA12562 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 15:45:46 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA26247 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 15:45:48 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.52 #3)
	id E0uWqbq-0004T7-00; Thu, 20 Jun 1996 16:45:46 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: libgr again
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uWqbq-0004T7-00@neal.ctd.comsat.com>
Date: Thu, 20 Jun 1996 16:45:47 -0400

I was too much in a hurry last night to get libgr-2.0.8.  The version
number on libpng shared lib is wrong.  It is set to 1.0.2.  It should
be 1.0.89 to match libpng0.89.  Change this is png/makefile.  I'll get
out libgr-2.0.9, which should also build on hpux, soon.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 10:47:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA11141 for xemacs-beta-people; Thu, 20 Jun 1996 10:47:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA11135 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 10:47:46 -0500 (CDT)
Received: from gcm.com (gcm.com [146.121.48.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA22545 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 10:47:35 -0500 (CDT)
Received: (from uucp@localhost) by gcm.com (8.6.9/8.6.9) with UUCP id LAA08131 for xemacs-beta@xemacs.org; Thu, 20 Jun 1996 11:50:58 -0400
Received: from mis_bo9.it.gcm.com by gcm.com (4.1/GCM-2.0m)
	id AA15518; Thu, 20 Jun 96 11:46:08 EDT
Received: by mis_bo9.it.gcm.com (4.1/SMI-4.1)
	id AA20049; Thu, 20 Jun 96 11:46:08 EDT
Date: Thu, 20 Jun 1996 11:46:06 -0400 (EDT)
From: David Worenklein <dcw@gcm.com>
To: xemacs-beta@xemacs.org
Cc: David Worenklein <dcw@gcm.com>
Subject: 19.14b25 fail - :help-string
Message-Id: <Pine.SUN.3.91.960620114343.20039A-200000@mis_bo9>
Mime-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1430489217-2053294700-835285566=:20039"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--1430489217-2053294700-835285566=:20039
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE

xemacs -q -no-site-file
C-x C-f <tab> <tab>

Signalling: (void-function :help-string)
  :help-string((concat (if (device-on-window-system-p) (substitute-command-=
keys "Click \\<list-mode-map>\\[list-mode-item-mouse-selected] on a complet=
ion to select it.\n") "") (substitute-command-keys "Type \\<minibuffer-loca=
l-completion-map>\\[advertised
-switch-to-completions] or \\[switch-to-completions] to move to this buffer=
, for keyboard selection.\n\n")))
  display-completion-list(("%backup%~" "../" "./" ".Xauthority" ".Xdefaults=
" ".Xebt" ".Xebt.old" ".abbrev_defs" ".addressbook" ".addressbook.lu" ".app=
s" ".bash_history" ".bash_logout" ".bash_profile" ".bbdb" ".builderXcessory=
/" ".bxrc" ".clockrc" ".cm.rc"
 ".contool" ".cshrc" ".custmst" ".dbquery.custmst" ".dbquery.log" ".dbquery=
.tranhist" ".dbquery.tranhst2" ".dbxrc" ".dxrc" ".emacs" ".emacs.desktop" "=
.emacs_bash" ".emacs~" ".envdefs" ".envset_de_aggregate" ".envset_default" =
".envset_gmx" ".envset_last" "
.fmaker/" ".forecast" ".forward" ".fvwmfmgr" ".fvwmrc" ".fvwmrc~" ".gnus" "=
.gnus~" ".hh/" ".hyperb/" ".inputrc" ".ispell_words" ".ispell_words~" ...) =
:user-data nil :activate-callback read-file-name-activate-callback)
  #<compiled-function (from "minibuf.elc") (completions) "...(11)" [display=
-completion-list completions :user-data completer read-file-name-internal :=
activate-callback read-file-name-activate-callback] 6>(("%backup%~" "../" "=
./" ".Xauthority" ".Xdefaults"
 ".Xebt" ".Xebt.old" ".abbrev_defs" ".addressbook" ".addressbook.lu" ".apps=
" ".bash_history" ".bash_logout" ".bash_profile" ".bbdb" ".builderXcessory/=
" ".bxrc" ".clockrc" ".cm.rc" ".contool" ".cshrc" ".custmst" ".dbquery.cust=
mst" ".dbquery.log" ".dbquery.
tranhist" ".dbquery.tranhst2" ".dbxrc" ".dxrc" ".emacs" ".emacs.desktop" ".=
emacs_bash" ".emacs~" ".envdefs" ".envset_de_aggregate" ".envset_default" "=
.envset_gmx" ".envset_last" ".fmaker/" ".forecast" ".forward" ".fvwmfmgr" "=
.fvwmrc" ".fvwmrc~" ".gnus" ".
gnus~" ".hh/" ".hyperb/" ".inputrc" ".ispell_words" ".ispell_words~" ...))
  minibuffer-completion-help()
  minibuffer-do-completion("~/")
  #<compiled-function (from "minibuf.elc") nil "...(97)" [last-command this=
-command nil minibuffer-scroll-window window windowp window-buffer buffer-n=
ame obuf (...) pos-visible-in-window-p set-window-start scroll-other-window=
 minibuffer-do-completion buff
er-string status none unique temp-minibuffer-message " [Sole completion]" e=
xact " [Complete, but not unique]" t] 4 511205 nil>()
  call-interactively(minibuffer-complete)
  read-minibuffer-internal("Find file: ")
  byte-code("=C0 =C1 V=AB=8A=C2=89=1B=1C=C5=0E=06!*=87=C5=0E=06!=87" [recur=
sion-depth minibuffer-depth t standard-input standard-output read-minibuffe=
r-internal prompt] 2)
  read-from-minibuffer("Find file: " "~/" #<keymap read-file-name-map 2 ent=
ries 0x4e4> nil file-name-history)
  read-file-name-2(file-name-history "Find file: " nil nil nil nil read-fil=
e-name-internal)
  read-file-name-1(file-name-history "Find file: " nil nil nil nil read-fil=
e-name-internal)
  read-file-name("Find file: " nil nil nil)
  call-interactively(find-file)



--
 David C. Worenklein                                       GREENWICH   CAPI=
TAL
 Operations Support                                        M a r k e t s,  =
Inc
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
 phone: 203-625-2945                                                      =
=3D=3D=3D=3D
 fax:   203-629-2535                                                      =
=3D=3D=3D=3D
 e-mail: dcw@gcm.com                                                      =
=3D=3D=3D=3D

--1430489217-2053294700-835285566=:20039
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="config.status"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SUN.3.91.960620114605.20039B@mis_bo9>
Content-Description: config.status

IyEvYmluL3NoDQojIEdlbmVyYXRlZCBhdXRvbWF0aWNhbGx5IGJ5IGNvbmZp
Z3VyZS4NCiMgUnVuIHRoaXMgZmlsZSB0byByZWNyZWF0ZSB0aGUgY3VycmVu
dCBjb25maWd1cmF0aW9uLg0KIyBUaGlzIGRpcmVjdG9yeSB3YXMgY29uZmln
dXJlZCBhcyBmb2xsb3dzLA0KIyBvbiBob3N0IG1pc19ibzk6DQojDQojIC4v
Y29uZmlndXJlICBzcGFyYy1zdW4tc3Vub3M0LjEuMyAtLXF1YW50aWZ5PXll
cyAtLWVycm9yX2NoZWNraW5nPW5vbmUgLS1kZWJ1Zz1ubyAtLWNvbXBpbGVy
PWFjYyAtLWNmbGFncz0tZyAtLWR5bmFtaWMgLS1wcmVmaXg9L3ZvbC9lbWFj
cy9iZXRhIC0td2l0aC1zcGFyY3dvcmtzPXllcyAtLXdpdGgtdG9vbHRhbGs9
eWVzIC0td2l0aC1zb3VuZD1uYXRpdmUgLS13aXRoLXhwbSAtLXdpdGgteGZh
Y2UgLS1zaXRlLWluY2x1ZGVzPS92b2wvbW90aWYvdXNyL2luY2x1ZGUgL3Zv
bC9vcGVud2luL2luY2x1ZGUgL3ZvbC9lbWFjcy9jb21wZmFjZSAvdm9sL3B1
cmUvcXVhbnRpZnktMi4wLjEtc3Vub3M0IC92b2wvZW1hY3MvanBlZy01YSAt
LXNpdGUtbGlicmFyaWVzPS92b2wvbW90aWYvdXNyL2xpYiAvdm9sL29wZW53
aW4vbGliIC92b2wvZW1hY3MvY29tcGZhY2UgL3ZvbC9wdXJlL3F1YW50aWZ5
LTIuMC4xLXN1bm9zNCAvdm9sL2VtYWNzL2pwZWctNWEgLS14LWluY2x1ZGVz
PS91c3IvbG9jYWwvWDExUjUvaW5jbHVkZSAtLXgtbGlicmFyaWVzPS91c3Iv
bG9jYWwvWDExUjUvbGliIC0td2l0aC14cG0gLS13aXRoLWdpZj15ZXMgLS13
aXRoX2pwZWcgLS13aXRoLXRpZmY9eWVzDQoNCmFjX2NzX3VzYWdlPSJVc2Fn
ZTogY29uZmlnLnN0YXR1cyBbLS1yZWNoZWNrXSBbLS12ZXJzaW9uXSBbLS1o
ZWxwXSINCmZvciBhY19vcHRpb24NCmRvDQogIGNhc2UgIiRhY19vcHRpb24i
IGluDQogIC1yZWNoZWNrIHwgLS1yZWNoZWNrIHwgLS1yZWNoZWMgfCAtLXJl
Y2hlIHwgLS1yZWNoIHwgLS1yZWMgfCAtLXJlIHwgLS1yKQ0KICAgIGVjaG8g
cnVubmluZyAke0NPTkZJR19TSEVMTC0vYmluL3NofSAuL2NvbmZpZ3VyZSAg
c3BhcmMtc3VuLXN1bm9zNC4xLjMgLS1xdWFudGlmeT15ZXMgLS1lcnJvcl9j
aGVja2luZz1ub25lIC0tZGVidWc9bm8gLS1jb21waWxlcj1hY2MgLS1jZmxh
Z3M9LWcgLS1keW5hbWljIC0tcHJlZml4PS92b2wvZW1hY3MvYmV0YSAtLXdp
dGgtc3BhcmN3b3Jrcz15ZXMgLS13aXRoLXRvb2x0YWxrPXllcyAtLXdpdGgt
c291bmQ9bmF0aXZlIC0td2l0aC14cG0gLS13aXRoLXhmYWNlIC0tc2l0ZS1p
bmNsdWRlcz0vdm9sL21vdGlmL3Vzci9pbmNsdWRlIC92b2wvb3Blbndpbi9p
bmNsdWRlIC92b2wvZW1hY3MvY29tcGZhY2UgL3ZvbC9wdXJlL3F1YW50aWZ5
LTIuMC4xLXN1bm9zNCAvdm9sL2VtYWNzL2pwZWctNWEgLS1zaXRlLWxpYnJh
cmllcz0vdm9sL21vdGlmL3Vzci9saWIgL3ZvbC9vcGVud2luL2xpYiAvdm9s
L2VtYWNzL2NvbXBmYWNlIC92b2wvcHVyZS9xdWFudGlmeS0yLjAuMS1zdW5v
czQgL3ZvbC9lbWFjcy9qcGVnLTVhIC0teC1pbmNsdWRlcz0vdXNyL2xvY2Fs
L1gxMVI1L2luY2x1ZGUgLS14LWxpYnJhcmllcz0vdXNyL2xvY2FsL1gxMVI1
L2xpYiAtLXdpdGgteHBtIC0td2l0aC1naWY9eWVzIC0td2l0aF9qcGVnIC0t
d2l0aC10aWZmPXllcyAtLW5vLWNyZWF0ZQ0KICAgIGV4ZWMgJHtDT05GSUdf
U0hFTEwtL2Jpbi9zaH0gLi9jb25maWd1cmUgIHNwYXJjLXN1bi1zdW5vczQu
MS4zIC0tcXVhbnRpZnk9eWVzIC0tZXJyb3JfY2hlY2tpbmc9bm9uZSAtLWRl
YnVnPW5vIC0tY29tcGlsZXI9YWNjIC0tY2ZsYWdzPS1nIC0tZHluYW1pYyAt
LXByZWZpeD0vdm9sL2VtYWNzL2JldGEgLS13aXRoLXNwYXJjd29ya3M9eWVz
IC0td2l0aC10b29sdGFsaz15ZXMgLS13aXRoLXNvdW5kPW5hdGl2ZSAtLXdp
dGgteHBtIC0td2l0aC14ZmFjZSAtLXNpdGUtaW5jbHVkZXM9L3ZvbC9tb3Rp
Zi91c3IvaW5jbHVkZSAvdm9sL29wZW53aW4vaW5jbHVkZSAvdm9sL2VtYWNz
L2NvbXBmYWNlIC92b2wvcHVyZS9xdWFudGlmeS0yLjAuMS1zdW5vczQgL3Zv
bC9lbWFjcy9qcGVnLTVhIC0tc2l0ZS1saWJyYXJpZXM9L3ZvbC9tb3RpZi91
c3IvbGliIC92b2wvb3Blbndpbi9saWIgL3ZvbC9lbWFjcy9jb21wZmFjZSAv
dm9sL3B1cmUvcXVhbnRpZnktMi4wLjEtc3Vub3M0IC92b2wvZW1hY3MvanBl
Zy01YSAtLXgtaW5jbHVkZXM9L3Vzci9sb2NhbC9YMTFSNS9pbmNsdWRlIC0t
eC1saWJyYXJpZXM9L3Vzci9sb2NhbC9YMTFSNS9saWIgLS13aXRoLXhwbSAt
LXdpdGgtZ2lmPXllcyAtLXdpdGhfanBlZyAtLXdpdGgtdGlmZj15ZXMgLS1u
by1jcmVhdGUgOzsNCiAgLXZlcnNpb24gfCAtLXZlcnNpb24gfCAtLXZlcnNp
byB8IC0tdmVyc2kgfCAtLXZlcnMgfCAtLXZlciB8IC0tdmUgfCAtLXYpDQog
ICAgZWNobyAiY29uZmlnLnN0YXR1cyBnZW5lcmF0ZWQgYnkgYXV0b2NvbmYg
dmVyc2lvbiAxLjExIg0KICAgIGV4aXQgMCA7Ow0KICAtaGVscCB8IC0taGVs
cCB8IC0taGVsIHwgLS1oZSB8IC0taCkNCiAgICBlY2hvICIkYWNfY3NfdXNh
Z2UiOyBleGl0IDAgOzsNCiAgKikgZWNobyAiJGFjX2NzX3VzYWdlIjsgZXhp
dCAxIDs7DQogIGVzYWMNCmRvbmUNCg0KdHJhcCAncm0gLWZyIE1ha2VmaWxl
IGxpYi1zcmMvTWFrZWZpbGUuaW4gbWFuL01ha2VmaWxlLmluIHNyYy9NYWtl
ZmlsZS5pbiBsd2xpYi9NYWtlZmlsZS5pbiBkeW5vZHVtcC9NYWtlZmlsZS5p
biBzcmMvY29uZmlnLmggY29uZnRlc3QqOyBleGl0IDEnIDEgMiAxNQ0KTE5f
Uz0nbG4gLXMnDQpDQz0nYWNjJw0KQ1BQPScvdXNyL2xpYi9jcHAgLUkvdm9s
L21vdGlmL3Vzci9pbmNsdWRlIC1JL3ZvbC9vcGVud2luL2luY2x1ZGUgLUkv
dm9sL2VtYWNzL2NvbXBmYWNlIC1JL3ZvbC9wdXJlL3F1YW50aWZ5LTIuMC4x
LXN1bm9zNCAtSS92b2wvZW1hY3MvanBlZy01YSAtSS91c3IvbG9jYWwvWDEx
UjUvaW5jbHVkZScNClJBTkxJQj0ncmFubGliJw0KSU5TVEFMTD0nL3Vzci9i
aW4vaW5zdGFsbCAtYycNCklOU1RBTExfUFJPR1JBTT0nJHtJTlNUQUxMfScN
CklOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnDQpZQUNDPSdiaXNv
biAteScNClNFVF9NQUtFPScnDQpBTExPQ0E9JycNCnZlcnNpb249JzE5LjE0
LWIyNScNCmNvbmZpZ3VyYXRpb249J3NwYXJjLXN1bi1zdW5vczQuMS4zJw0K
Y2Fub25pY2FsPSdzcGFyYy1zdW4tc3Vub3M0LjEuMycNCnNyY2Rpcj0nL3Zv
bC9lbWFjcy94ZW1hY3MtMTkuMTQtYjI1Jw0KcHJlZml4PScvdm9sL2VtYWNz
L2JldGEnDQpleGVjX3ByZWZpeD0nJHtwcmVmaXh9Jw0KYmluZGlyPScke2V4
ZWNfcHJlZml4fS9iaW4nDQpkYXRhZGlyPScke3ByZWZpeH0vbGliJw0Kc3Rh
dGVkaXI9JyR7cHJlZml4fS9saWInDQpsaWJkaXI9JyR7ZXhlY19wcmVmaXh9
L2xpYicNCm1hbmRpcj0nJHtwcmVmaXh9L21hbi9tYW4xJw0KaW5mb2Rpcj0n
JHtwcmVmaXh9L2xpYi94ZW1hY3MtJHt2ZXJzaW9ufS9pbmZvJw0KaW5mb2Rp
cl91c2VyX2RlZmluZWQ9J25vJw0KbGlzcGRpcj0nJHtkYXRhZGlyfS94ZW1h
Y3MtJHt2ZXJzaW9ufS9saXNwJw0KbGlzcGRpcl91c2VyX2RlZmluZWQ9J25v
Jw0Kc2l0ZWxpc3BkaXI9JyR7ZGF0YWRpcn0veGVtYWNzL3NpdGUtbGlzcCcN
CmV0Y2Rpcj0nJHtkYXRhZGlyfS94ZW1hY3MtJHt2ZXJzaW9ufS9ldGMnDQpl
dGNkaXJfdXNlcl9kZWZpbmVkPSdubycNCmxvY2tkaXI9JyR7c3RhdGVkaXJ9
L3hlbWFjcy9sb2NrJw0KbG9ja2Rpcl91c2VyX2RlZmluZWQ9J25vJw0KYXJj
aGxpYmRpcj0nJHtsaWJkaXJ9L3hlbWFjcy0ke3ZlcnNpb259LyR7Y29uZmln
dXJhdGlvbn0nDQphcmNobGliZGlyX3VzZXJfZGVmaW5lZD0nbm8nDQpkb2Nk
aXI9JycNCmJpdG1hcGRpcj0nJw0KY19zd2l0Y2hfc3lzdGVtPScnDQpjX3N3
aXRjaF9tYWNoaW5lPScnDQpsaWJzcmNfbGlicz0nICcNCkxEX1NXSVRDSF9Y
X1NJVEU9Jy1ML3Vzci9sb2NhbC9YMTFSNS9saWIgLUwvdm9sL29wZW53aW4v
bGliICcNCkxEX1NXSVRDSF9YX1NJVEVfQVVYPScnDQpDX1NXSVRDSF9YX1NJ
VEU9Jy1JL3Vzci9sb2NhbC9YMTFSNS9pbmNsdWRlIC1JL3ZvbC9vcGVud2lu
L2luY2x1ZGUvZGVza3RvcCAtSS92b2wvb3Blbndpbi9pbmNsdWRlL2Rlc2t0
b3AnDQpMRF9TV0lUQ0hfU0lURT0nIC1ML3ZvbC9tb3RpZi91c3IvbGliIC1M
L3ZvbC9vcGVud2luL2xpYiAtTC92b2wvZW1hY3MvY29tcGZhY2UgLUwvdm9s
L3B1cmUvcXVhbnRpZnktMi4wLjEtc3Vub3M0IC1ML3ZvbC9lbWFjcy9qcGVn
LTVhJw0KQ19TV0lUQ0hfU0lURT0nIC1JL3ZvbC9tb3RpZi91c3IvaW5jbHVk
ZSAtSS92b2wvb3Blbndpbi9pbmNsdWRlIC1JL3ZvbC9lbWFjcy9jb21wZmFj
ZSAtSS92b2wvcHVyZS9xdWFudGlmeS0yLjAuMS1zdW5vczQgLUkvdm9sL2Vt
YWNzL2pwZWctNWEnDQpDRkxBR1M9Jy1nJw0KbmF0aXZlX3NvdW5kX2xpYj0n
L3Vzci9kZW1vL1NPVU5EL2xpYmF1ZGlvLmEnDQptYWNoZmlsZT0nbS9zcGFy
Yy5oJw0Kb3BzeXNmaWxlPSdzL3N1bm9zNC0xLTNzaHIuaCcNCmR5bm9kdW1w
X2FyY2g9JycNCmludGVybmFsX21ha2VmaWxlX2xpc3Q9J01ha2VmaWxlIGxp
Yi1zcmMvTWFrZWZpbGUuaW4gbWFuL01ha2VmaWxlLmluIHNyYy9NYWtlZmls
ZS5pbiBsd2xpYi9NYWtlZmlsZS5pbiBkeW5vZHVtcC9NYWtlZmlsZS5pbicN
CkxJQlM9Jy1sWDExICAgLUwvdm9sL21vdGlmL3Vzci9saWIgLUwvdm9sL29w
ZW53aW4vbGliIC1ML3ZvbC9lbWFjcy9jb21wZmFjZSAtTC92b2wvcHVyZS9x
dWFudGlmeS0yLjAuMS1zdW5vczQgLUwvdm9sL2VtYWNzL2pwZWctNWEgICAg
IC11IF9YdFRvb2xraXRJbml0aWFsaXplIC11IF9nZXRfYXBwbGljYXRpb25T
aGVsbFdpZGdldENsYXNzIC1sbScNCnRvcF9zcmNkaXI9JycNCmFjX3Byc3Vi
PSdzJV5wcmVmaXhcKFsgCV0qXCk9XChbIAldKlwpLiokJXByZWZpeFwxPVwy
L3ZvbC9lbWFjcy9iZXRhJQ0KcyVeZXhlY19wcmVmaXhcKFsgCV0qXCk9XChb
IAldKlwpLiokJWV4ZWNfcHJlZml4XDE9XDIke3ByZWZpeH0lJw0KYWNfdnBz
dWI9JycNCmV4dHJhc3ViPScnDQoNCmFjX2dpdmVuX3NyY2Rpcj0kc3JjZGly
DQoNCkNPTkZJR19GSUxFUz0ke0NPTkZJR19GSUxFUy0iJGludGVybmFsX21h
a2VmaWxlX2xpc3QifQ0KZm9yIGFjX2ZpbGUgaW4gLi4gJHtDT05GSUdfRklM
RVN9OyBkbyBpZiB0ZXN0ICJ4JGFjX2ZpbGUiICE9IHguLjsgdGhlbg0KICAj
IFJlbW92ZSBsYXN0IHNsYXNoIGFuZCBhbGwgdGhhdCBmb2xsb3dzIGl0LiAg
Tm90IGFsbCBzeXN0ZW1zIGhhdmUgZGlybmFtZS4NCiAgYWNfZGlyPWBlY2hv
ICRhY19maWxlfHNlZCAncyUvW14vXVteL10qJCUlJ2ANCiAgaWYgdGVzdCAi
JGFjX2RpciIgIT0gIiRhY19maWxlIiAmJiB0ZXN0ICIkYWNfZGlyIiAhPSAu
OyB0aGVuDQogICAgIyBUaGUgZmlsZSBpcyBpbiBhIHN1YmRpcmVjdG9yeS4N
CiAgICB0ZXN0ICEgLWQgIiRhY19kaXIiICYmIG1rZGlyICIkYWNfZGlyIg0K
ICAgIGFjX2Rpcl9zdWZmaXg9Ii8kYWNfZGlyIg0KICBlbHNlDQogICAgYWNf
ZGlyX3N1ZmZpeD0NCiAgZmkNCg0KICAjIEEgIi4uLyIgZm9yIGVhY2ggZGly
ZWN0b3J5IGluICRhY19kaXJfc3VmZml4Lg0KICBhY19kb3RzPWBlY2hvICRh
Y19kaXJfc3VmZml4fHNlZCAncyUvW14vXSolLi4vJWcnYA0KICBjYXNlICIk
YWNfZ2l2ZW5fc3JjZGlyIiBpbg0KICAuKSAgc3JjZGlyPS4NCiAgICAgIGlm
IHRlc3QgLXogIiRhY19kaXJfc3VmZml4IjsgdGhlbiB0b3Bfc3JjZGlyPS4N
CiAgICAgIGVsc2UgdG9wX3NyY2Rpcj1gZWNobyAkYWNfZG90c3xzZWQgJ3Ml
LyQlJSdgOyBmaSA7Ow0KICAvKikgc3JjZGlyPSIkYWNfZ2l2ZW5fc3JjZGly
JGFjX2Rpcl9zdWZmaXgiOyB0b3Bfc3JjZGlyPSIkYWNfZ2l2ZW5fc3JjZGly
IiA7Ow0KICAqKSAjIFJlbGF0aXZlIHBhdGguDQogICAgc3JjZGlyPSIkYWNf
ZG90cyRhY19naXZlbl9zcmNkaXIkYWNfZGlyX3N1ZmZpeCINCiAgICB0b3Bf
c3JjZGlyPSIkYWNfZG90cyRhY19naXZlbl9zcmNkaXIiIDs7DQogIGVzYWMN
Cg0KICBlY2hvIGNyZWF0aW5nICIkYWNfZmlsZSINCiAgcm0gLWYgIiRhY19m
aWxlIg0KICBjb21tZW50X3N0cj0iR2VuZXJhdGVkIGF1dG9tYXRpY2FsbHkg
ZnJvbSBgZWNobyAkYWNfZmlsZXxzZWQgJ3N8LiovfHwnYC5pbiBieSBjb25m
aWd1cmUuIg0KICBjYXNlICIkYWNfZmlsZSIgaW4NCiAgICAqLmMgfCAqLmgg
fCAqLkMgfCAqLmNjIHwgKi5tICkgIGVjaG8gIi8qICRjb21tZW50X3N0ciAq
LyIgPiAiJGFjX2ZpbGUiIDs7DQogICAgKiApICAgICAgICAgIGVjaG8gIiMg
JGNvbW1lbnRfc3RyIiAgICAgPiAiJGFjX2ZpbGUiIDs7DQogIGVzYWMNCiAg
c2VkIC1lICINCiRhY19wcnN1Yg0KJGFjX3Zwc3ViDQokZXh0cmFzdWINCnMl
QExOX1NAJSRMTl9TJWcNCnMlQENDQCUkQ0MlZw0KcyVAQ1BQQCUkQ1BQJWcN
CnMlQFJBTkxJQkAlJFJBTkxJQiVnDQpzJUBJTlNUQUxMQCUkSU5TVEFMTCVn
DQpzJUBJTlNUQUxMX1BST0dSQU1AJSRJTlNUQUxMX1BST0dSQU0lZw0KcyVA
SU5TVEFMTF9EQVRBQCUkSU5TVEFMTF9EQVRBJWcNCnMlQFlBQ0NAJSRZQUND
JWcNCnMlQFNFVF9NQUtFQCUkU0VUX01BS0UlZw0KcyVAQUxMT0NBQCUkQUxM
T0NBJWcNCnMlQHZlcnNpb25AJSR2ZXJzaW9uJWcNCnMlQGNvbmZpZ3VyYXRp
b25AJSRjb25maWd1cmF0aW9uJWcNCnMlQGNhbm9uaWNhbEAlJGNhbm9uaWNh
bCVnDQpzJUBzcmNkaXJAJSRzcmNkaXIlZw0KcyVAcHJlZml4QCUkcHJlZml4
JWcNCnMlQGV4ZWNfcHJlZml4QCUkZXhlY19wcmVmaXglZw0KcyVAYmluZGly
QCUkYmluZGlyJWcNCnMlQGRhdGFkaXJAJSRkYXRhZGlyJWcNCnMlQHN0YXRl
ZGlyQCUkc3RhdGVkaXIlZw0KcyVAbGliZGlyQCUkbGliZGlyJWcNCnMlQG1h
bmRpckAlJG1hbmRpciVnDQpzJUBpbmZvZGlyQCUkaW5mb2RpciVnDQpzJUBp
bmZvZGlyX3VzZXJfZGVmaW5lZEAlJGluZm9kaXJfdXNlcl9kZWZpbmVkJWcN
CnMlQGxpc3BkaXJAJSRsaXNwZGlyJWcNCnMlQGxpc3BkaXJfdXNlcl9kZWZp
bmVkQCUkbGlzcGRpcl91c2VyX2RlZmluZWQlZw0KcyVAc2l0ZWxpc3BkaXJA
JSRzaXRlbGlzcGRpciVnDQpzJUBldGNkaXJAJSRldGNkaXIlZw0KcyVAZXRj
ZGlyX3VzZXJfZGVmaW5lZEAlJGV0Y2Rpcl91c2VyX2RlZmluZWQlZw0KcyVA
bG9ja2RpckAlJGxvY2tkaXIlZw0KcyVAbG9ja2Rpcl91c2VyX2RlZmluZWRA
JSRsb2NrZGlyX3VzZXJfZGVmaW5lZCVnDQpzJUBhcmNobGliZGlyQCUkYXJj
aGxpYmRpciVnDQpzJUBhcmNobGliZGlyX3VzZXJfZGVmaW5lZEAlJGFyY2hs
aWJkaXJfdXNlcl9kZWZpbmVkJWcNCnMlQGRvY2RpckAlJGRvY2RpciVnDQpz
JUBiaXRtYXBkaXJAJSRiaXRtYXBkaXIlZw0KcyVAY19zd2l0Y2hfc3lzdGVt
QCUkY19zd2l0Y2hfc3lzdGVtJWcNCnMlQGNfc3dpdGNoX21hY2hpbmVAJSRj
X3N3aXRjaF9tYWNoaW5lJWcNCnMlQGxpYnNyY19saWJzQCUkbGlic3JjX2xp
YnMlZw0KcyVATERfU1dJVENIX1hfU0lURUAlJExEX1NXSVRDSF9YX1NJVEUl
Zw0KcyVATERfU1dJVENIX1hfU0lURV9BVVhAJSRMRF9TV0lUQ0hfWF9TSVRF
X0FVWCVnDQpzJUBDX1NXSVRDSF9YX1NJVEVAJSRDX1NXSVRDSF9YX1NJVEUl
Zw0KcyVATERfU1dJVENIX1NJVEVAJSRMRF9TV0lUQ0hfU0lURSVnDQpzJUBD
X1NXSVRDSF9TSVRFQCUkQ19TV0lUQ0hfU0lURSVnDQpzJUBDRkxBR1NAJSRD
RkxBR1MlZw0KcyVAbmF0aXZlX3NvdW5kX2xpYkAlJG5hdGl2ZV9zb3VuZF9s
aWIlZw0KcyVAbWFjaGZpbGVAJSRtYWNoZmlsZSVnDQpzJUBvcHN5c2ZpbGVA
JSRvcHN5c2ZpbGUlZw0KcyVAZHlub2R1bXBfYXJjaEAlJGR5bm9kdW1wX2Fy
Y2glZw0KcyVAaW50ZXJuYWxfbWFrZWZpbGVfbGlzdEAlJGludGVybmFsX21h
a2VmaWxlX2xpc3QlZw0KcyVATElCU0AlJExJQlMlZw0KcyVAdG9wX3NyY2Rp
ckAlJHRvcF9zcmNkaXIlZw0KcyVAREVGU0AlLURIQVZFX0NPTkZJR19IJSIg
JGFjX2dpdmVuX3NyY2Rpci8ke2FjX2ZpbGV9LmluID4+ICRhY19maWxlDQpm
aTsgZG9uZQ0KDQojIFRoZXNlIHNlZCBjb21tYW5kcyBhcmUgcHV0IGludG8g
YWNfc2VkX2RlZnMgd2hlbiBkZWZpbmluZyBhIG1hY3JvLg0KIyBUaGV5IGFy
ZSBicm9rZW4gaW50byBwaWVjZXMgdG8gbWFrZSB0aGUgc2VkIHNjcmlwdCBl
YXNpZXIgdG8gbWFuYWdlLg0KIyBUaGV5IGFyZSBwYXNzZWQgdG8gc2VkIGFz
ICJBIE5BTUUgQiBOQU1FIEMgVkFMVUUgRCIsIHdoZXJlIE5BTUUNCiMgaXMg
dGhlIGNwcCBtYWNybyBiZWluZyBkZWZpbmVkIGFuZCBWQUxVRSBpcyB0aGUg
dmFsdWUgaXQgaXMgYmVpbmcgZ2l2ZW4uDQojIEVhY2ggZGVmaW5pbmcgdHVy
bnMgaW50byBhIHNpbmdsZSBnbG9iYWwgc3Vic3RpdHV0aW9uIGNvbW1hbmQu
DQojIEhvcGVmdWxseSBubyBvbmUgdXNlcyAiISIgYXMgYSB2YXJpYWJsZSB2
YWx1ZS4NCiMgT3RoZXIgY2FuZGlkYXRlcyBmb3IgdGhlIHNlZCBzZXBhcmF0
b3JzLCBsaWtlICwgYW5kIEAsIGRvIGdldCB1c2VkLg0KIw0KIyBhY19kIHNl
dHMgdGhlIHZhbHVlIGluICIjZGVmaW5lIE5BTUUgVkFMVUUiIGxpbmVzLg0K
YWNfZEE9J3MhXlwoWyAJXSpcKSNcKFsgCV0qZGVmaW5lWyAJXVsgCV0qXCkn
DQphY19kQj0nXChbIAldWyAJXSpcKVteIAldKiFcMSNcMicNCmFjX2RDPSdc
MycNCmFjX2REPSchZycNCiMgYWNfdSB0dXJucyAiI3VuZGVmIE5BTUUiIHdp
dGggdHJhaWxpbmcgYmxhbmtzIGludG8gIiNkZWZpbmUgTkFNRSBWQUxVRSIu
DQphY191QT0ncyFeXChbIAldKlwpI1woWyAJXSpcKXVuZGVmXChbIAldWyAJ
XSpcKScNCmFjX3VCPSdcKFsgCV1cKSFcMSNcMmRlZmluZVwzJw0KYWNfdUM9
JyAnDQphY191RD0nXDQhZycNCiMgYWNfZSB0dXJucyAiI3VuZGVmIE5BTUUi
IHdpdGhvdXQgdHJhaWxpbmcgYmxhbmtzIGludG8gIiNkZWZpbmUgTkFNRSBW
QUxVRSIuDQphY19lQT0ncyFeXChbIAldKlwpI1woWyAJXSpcKXVuZGVmXChb
IAldWyAJXSpcKScNCmFjX2VCPSckIVwxI1wyZGVmaW5lXDMnDQphY19lQz0n
ICcNCmFjX2VEPSchZycNCnJtIC1mIGNvbmZ0ZXN0LnNlZA0KY2F0ID4+IGNv
bmZ0ZXN0LnNlZCA8PENPTkZFT0YNCiR7YWNfZEF9SEFWRV9TWVNfU1RST1BU
U19IJHthY19kQn1IQVZFX1NZU19TVFJPUFRTX0gke2FjX2RDfTEke2FjX2RE
fQ0KJHthY191QX1IQVZFX1NZU19TVFJPUFRTX0gke2FjX3VCfUhBVkVfU1lT
X1NUUk9QVFNfSCR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVfU1lT
X1NUUk9QVFNfSCR7YWNfZUJ9SEFWRV9TWVNfU1RST1BUU19IJHthY19lQ30x
JHthY19lRH0NCiR7YWNfZEF9SEFWRV9TWVNfVElNRUJfSCR7YWNfZEJ9SEFW
RV9TWVNfVElNRUJfSCR7YWNfZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVf
U1lTX1RJTUVCX0gke2FjX3VCfUhBVkVfU1lTX1RJTUVCX0gke2FjX3VDfTEk
e2FjX3VEfQ0KJHthY19lQX1IQVZFX1NZU19USU1FQl9IJHthY19lQn1IQVZF
X1NZU19USU1FQl9IJHthY19lQ30xJHthY19lRH0NCiR7YWNfZEF9SEFWRV9T
WVNfVElNRV9IJHthY19kQn1IQVZFX1NZU19USU1FX0gke2FjX2RDfTEke2Fj
X2REfQ0KJHthY191QX1IQVZFX1NZU19USU1FX0gke2FjX3VCfUhBVkVfU1lT
X1RJTUVfSCR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVfU1lTX1RJ
TUVfSCR7YWNfZUJ9SEFWRV9TWVNfVElNRV9IJHthY19lQ30xJHthY19lRH0N
CkNPTkZFT0YNCmNhdCA+PiBjb25mdGVzdC5zZWQgPDxDT05GRU9GDQoke2Fj
X2RBfUhBVkVfVU5JU1REX0gke2FjX2RCfUhBVkVfVU5JU1REX0gke2FjX2RD
fTEke2FjX2REfQ0KJHthY191QX1IQVZFX1VOSVNURF9IJHthY191Qn1IQVZF
X1VOSVNURF9IJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9VTklT
VERfSCR7YWNfZUJ9SEFWRV9VTklTVERfSCR7YWNfZUN9MSR7YWNfZUR9DQok
e2FjX2RBfUhBVkVfVVRJTUVfSCR7YWNfZEJ9SEFWRV9VVElNRV9IJHthY19k
Q30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9VVElNRV9IJHthY191Qn1IQVZF
X1VUSU1FX0gke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX1VUSU1F
X0gke2FjX2VCfUhBVkVfVVRJTUVfSCR7YWNfZUN9MSR7YWNfZUR9DQoke2Fj
X2RBfUhBVkVfU1lTX1dBSVRfSCR7YWNfZEJ9SEFWRV9TWVNfV0FJVF9IJHth
Y19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9TWVNfV0FJVF9IJHthY191
Qn1IQVZFX1NZU19XQUlUX0gke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1I
QVZFX1NZU19XQUlUX0gke2FjX2VCfUhBVkVfU1lTX1dBSVRfSCR7YWNfZUN9
MSR7YWNfZUR9DQpDT05GRU9GDQpjYXQgPj4gY29uZnRlc3Quc2VkIDw8Q09O
RkVPRg0KJHthY19kQX1IQVZFX0xPQ0FMRV9IJHthY19kQn1IQVZFX0xPQ0FM
RV9IJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9MT0NBTEVfSCR7
YWNfdUJ9SEFWRV9MT0NBTEVfSCR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VB
fUhBVkVfTE9DQUxFX0gke2FjX2VCfUhBVkVfTE9DQUxFX0gke2FjX2VDfTEk
e2FjX2VEfQ0KJHthY19kQX1USU1FX1dJVEhfU1lTX1RJTUUke2FjX2RCfVRJ
TUVfV0lUSF9TWVNfVElNRSR7YWNfZEN9MSR7YWNfZER9DQoke2FjX3VBfVRJ
TUVfV0lUSF9TWVNfVElNRSR7YWNfdUJ9VElNRV9XSVRIX1NZU19USU1FJHth
Y191Q30xJHthY191RH0NCiR7YWNfZUF9VElNRV9XSVRIX1NZU19USU1FJHth
Y19lQn1USU1FX1dJVEhfU1lTX1RJTUUke2FjX2VDfTEke2FjX2VEfQ0KJHth
Y19kQX1IQVZFX1NUUlVDVF9VVElNQlVGJHthY19kQn1IQVZFX1NUUlVDVF9V
VElNQlVGJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9TVFJVQ1Rf
VVRJTUJVRiR7YWNfdUJ9SEFWRV9TVFJVQ1RfVVRJTUJVRiR7YWNfdUN9MSR7
YWNfdUR9DQoke2FjX2VBfUhBVkVfU1RSVUNUX1VUSU1CVUYke2FjX2VCfUhB
VkVfU1RSVUNUX1VUSU1CVUYke2FjX2VDfTEke2FjX2VEfQ0KQ09ORkVPRg0K
Y2F0ID4+IGNvbmZ0ZXN0LnNlZCA8PENPTkZFT0YNCiR7YWNfZEF9UkVUU0lH
VFlQRSR7YWNfZEJ9UkVUU0lHVFlQRSR7YWNfZEN9dm9pZCR7YWNfZER9DQok
e2FjX3VBfVJFVFNJR1RZUEUke2FjX3VCfVJFVFNJR1RZUEUke2FjX3VDfXZv
aWQke2FjX3VEfQ0KJHthY19lQX1SRVRTSUdUWVBFJHthY19lQn1SRVRTSUdU
WVBFJHthY19lQ312b2lkJHthY19lRH0NCiR7YWNfZEF9SEFWRV9USU1FVkFM
JHthY19kQn1IQVZFX1RJTUVWQUwke2FjX2RDfTEke2FjX2REfQ0KJHthY191
QX1IQVZFX1RJTUVWQUwke2FjX3VCfUhBVkVfVElNRVZBTCR7YWNfdUN9MSR7
YWNfdUR9DQoke2FjX2VBfUhBVkVfVElNRVZBTCR7YWNfZUJ9SEFWRV9USU1F
VkFMJHthY19lQ30xJHthY19lRH0NCiR7YWNfZEF9SEFWRV9UTV9aT05FJHth
Y19kQn1IQVZFX1RNX1pPTkUke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1I
QVZFX1RNX1pPTkUke2FjX3VCfUhBVkVfVE1fWk9ORSR7YWNfdUN9MSR7YWNf
dUR9DQoke2FjX2VBfUhBVkVfVE1fWk9ORSR7YWNfZUJ9SEFWRV9UTV9aT05F
JHthY19lQ30xJHthY19lRH0NCkNPTkZFT0YNCmNhdCA+PiBjb25mdGVzdC5z
ZWQgPDxDT05GRU9GDQoke2FjX2RBfVdPUkRTX0JJR0VORElBTiR7YWNfZEJ9
V09SRFNfQklHRU5ESUFOJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9V09S
RFNfQklHRU5ESUFOJHthY191Qn1XT1JEU19CSUdFTkRJQU4ke2FjX3VDfTEk
e2FjX3VEfQ0KJHthY19lQX1XT1JEU19CSUdFTkRJQU4ke2FjX2VCfVdPUkRT
X0JJR0VORElBTiR7YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RBfUhBVkVfTE9O
R19GSUxFX05BTUVTJHthY19kQn1IQVZFX0xPTkdfRklMRV9OQU1FUyR7YWNf
ZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVfTE9OR19GSUxFX05BTUVTJHth
Y191Qn1IQVZFX0xPTkdfRklMRV9OQU1FUyR7YWNfdUN9MSR7YWNfdUR9DQok
e2FjX2VBfUhBVkVfTE9OR19GSUxFX05BTUVTJHthY19lQn1IQVZFX0xPTkdf
RklMRV9OQU1FUyR7YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RBfUhBVkVfWEFV
VEgke2FjX2RCfUhBVkVfWEFVVEgke2FjX2RDfTEke2FjX2REfQ0KJHthY191
QX1IQVZFX1hBVVRIJHthY191Qn1IQVZFX1hBVVRIJHthY191Q30xJHthY191
RH0NCiR7YWNfZUF9SEFWRV9YQVVUSCR7YWNfZUJ9SEFWRV9YQVVUSCR7YWNf
ZUN9MSR7YWNfZUR9DQpDT05GRU9GDQpjYXQgPj4gY29uZnRlc3Quc2VkIDw8
Q09ORkVPRg0KJHthY19kQX1IQVZFX1hMT0NBTEVfSCR7YWNfZEJ9SEFWRV9Y
TE9DQUxFX0gke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX1hMT0NB
TEVfSCR7YWNfdUJ9SEFWRV9YTE9DQUxFX0gke2FjX3VDfTEke2FjX3VEfQ0K
JHthY19lQX1IQVZFX1hMT0NBTEVfSCR7YWNfZUJ9SEFWRV9YTE9DQUxFX0gk
e2FjX2VDfTEke2FjX2VEfQ0KJHthY19kQX1USElTX0lTX1gxMVI1JHthY19k
Qn1USElTX0lTX1gxMVI1JHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9VEhJ
U19JU19YMTFSNSR7YWNfdUJ9VEhJU19JU19YMTFSNSR7YWNfdUN9MSR7YWNf
dUR9DQoke2FjX2VBfVRISVNfSVNfWDExUjUke2FjX2VCfVRISVNfSVNfWDEx
UjUke2FjX2VDfTEke2FjX2VEfQ0KJHthY19kQX1IQVZFX1gxMV9YTE9DQUxF
X0gke2FjX2RCfUhBVkVfWDExX1hMT0NBTEVfSCR7YWNfZEN9MSR7YWNfZER9
DQoke2FjX3VBfUhBVkVfWDExX1hMT0NBTEVfSCR7YWNfdUJ9SEFWRV9YMTFf
WExPQ0FMRV9IJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9YMTFf
WExPQ0FMRV9IJHthY19lQn1IQVZFX1gxMV9YTE9DQUxFX0gke2FjX2VDfTEk
e2FjX2VEfQ0KQ09ORkVPRg0KY2F0ID4+IGNvbmZ0ZXN0LnNlZCA8PENPTkZF
T0YNCiR7YWNfZEF9SEFWRV9MSUJNJHthY19kQn1IQVZFX0xJQk0ke2FjX2RD
fTEke2FjX2REfQ0KJHthY191QX1IQVZFX0xJQk0ke2FjX3VCfUhBVkVfTElC
TSR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVfTElCTSR7YWNfZUJ9
SEFWRV9MSUJNJHthY19lQ30xJHthY19lRH0NCiR7YWNfZEF9SEFWRV9YUE0k
e2FjX2RCfUhBVkVfWFBNJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFW
RV9YUE0ke2FjX3VCfUhBVkVfWFBNJHthY191Q30xJHthY191RH0NCiR7YWNf
ZUF9SEFWRV9YUE0ke2FjX2VCfUhBVkVfWFBNJHthY19lQ30xJHthY19lRH0N
CiR7YWNfZEF9SEFWRV9YTVUke2FjX2RCfUhBVkVfWE1VJHthY19kQ30xJHth
Y19kRH0NCiR7YWNfdUF9SEFWRV9YTVUke2FjX3VCfUhBVkVfWE1VJHthY191
Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9YTVUke2FjX2VCfUhBVkVfWE1V
JHthY19lQ30xJHthY19lRH0NCkNPTkZFT0YNCmNhdCA+PiBjb25mdGVzdC5z
ZWQgPDxDT05GRU9GDQoke2FjX2RBfUhBVkVfWEZBQ0Uke2FjX2RCfUhBVkVf
WEZBQ0Uke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX1hGQUNFJHth
Y191Qn1IQVZFX1hGQUNFJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFW
RV9YRkFDRSR7YWNfZUJ9SEFWRV9YRkFDRSR7YWNfZUN9MSR7YWNfZUR9DQok
e2FjX2RBfUhBVkVfR0lGJHthY19kQn1IQVZFX0dJRiR7YWNfZEN9MSR7YWNf
ZER9DQoke2FjX3VBfUhBVkVfR0lGJHthY191Qn1IQVZFX0dJRiR7YWNfdUN9
MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVfR0lGJHthY19lQn1IQVZFX0dJRiR7
YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RBfUhBVkVfSlBFRyR7YWNfZEJ9SEFW
RV9KUEVHJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9KUEVHJHth
Y191Qn1IQVZFX0pQRUcke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZF
X0pQRUcke2FjX2VCfUhBVkVfSlBFRyR7YWNfZUN9MSR7YWNfZUR9DQpDT05G
RU9GDQpjYXQgPj4gY29uZnRlc3Quc2VkIDw8Q09ORkVPRg0KJHthY19kQX1I
QVZFX1RJRkYke2FjX2RCfUhBVkVfVElGRiR7YWNfZEN9MSR7YWNfZER9DQok
e2FjX3VBfUhBVkVfVElGRiR7YWNfdUJ9SEFWRV9USUZGJHthY191Q30xJHth
Y191RH0NCiR7YWNfZUF9SEFWRV9USUZGJHthY19lQn1IQVZFX1RJRkYke2Fj
X2VDfTEke2FjX2VEfQ0KJHthY19kQX1IQVZFX0hfRVJSTk8ke2FjX2RCfUhB
VkVfSF9FUlJOTyR7YWNfZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVfSF9F
UlJOTyR7YWNfdUJ9SEFWRV9IX0VSUk5PJHthY191Q30xJHthY191RH0NCiR7
YWNfZUF9SEFWRV9IX0VSUk5PJHthY19lQn1IQVZFX0hfRVJSTk8ke2FjX2VD
fTEke2FjX2VEfQ0KJHthY19kQX1IQVZFX1NJR1NFVEpNUCR7YWNfZEJ9SEFW
RV9TSUdTRVRKTVAke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX1NJ
R1NFVEpNUCR7YWNfdUJ9SEFWRV9TSUdTRVRKTVAke2FjX3VDfTEke2FjX3VE
fQ0KJHthY19lQX1IQVZFX1NJR1NFVEpNUCR7YWNfZUJ9SEFWRV9TSUdTRVRK
TVAke2FjX2VDfTEke2FjX2VEfQ0KQ09ORkVPRg0KY2F0ID4+IGNvbmZ0ZXN0
LnNlZCA8PENPTkZFT0YNCiR7YWNfZEF9TE9DQUxUSU1FX0NBQ0hFJHthY19k
Qn1MT0NBTFRJTUVfQ0FDSEUke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1M
T0NBTFRJTUVfQ0FDSEUke2FjX3VCfUxPQ0FMVElNRV9DQUNIRSR7YWNfdUN9
MSR7YWNfdUR9DQoke2FjX2VBfUxPQ0FMVElNRV9DQUNIRSR7YWNfZUJ9TE9D
QUxUSU1FX0NBQ0hFJHthY19lQ30xJHthY19lRH0NCiR7YWNfZEF9SEFWRV9B
TExPQ0FfSCR7YWNfZEJ9SEFWRV9BTExPQ0FfSCR7YWNfZEN9MSR7YWNfZER9
DQoke2FjX3VBfUhBVkVfQUxMT0NBX0gke2FjX3VCfUhBVkVfQUxMT0NBX0gk
e2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX0FMTE9DQV9IJHthY19l
Qn1IQVZFX0FMTE9DQV9IJHthY19lQ30xJHthY19lRH0NCiR7YWNfZEF9SEFW
RV9BTExPQ0Eke2FjX2RCfUhBVkVfQUxMT0NBJHthY19kQ30xJHthY19kRH0N
CiR7YWNfdUF9SEFWRV9BTExPQ0Eke2FjX3VCfUhBVkVfQUxMT0NBJHthY191
Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9BTExPQ0Eke2FjX2VCfUhBVkVf
QUxMT0NBJHthY19lQ30xJHthY19lRH0NCkNPTkZFT0YNCmNhdCA+PiBjb25m
dGVzdC5zZWQgPDxDT05GRU9GDQoke2FjX2RBfUhBVkVfVkZPUktfSCR7YWNf
ZEJ9SEFWRV9WRk9SS19IJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFW
RV9WRk9SS19IJHthY191Qn1IQVZFX1ZGT1JLX0gke2FjX3VDfTEke2FjX3VE
fQ0KJHthY19lQX1IQVZFX1ZGT1JLX0gke2FjX2VCfUhBVkVfVkZPUktfSCR7
YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RBfUhBVkVfU1RSQ09MTCR7YWNfZEJ9
SEFWRV9TVFJDT0xMJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9T
VFJDT0xMJHthY191Qn1IQVZFX1NUUkNPTEwke2FjX3VDfTEke2FjX3VEfQ0K
JHthY19lQX1IQVZFX1NUUkNPTEwke2FjX2VCfUhBVkVfU1RSQ09MTCR7YWNf
ZUN9MSR7YWNfZUR9DQoke2FjX2RBfVNJWkVPRl9TSE9SVCR7YWNfZEJ9U0la
RU9GX1NIT1JUJHthY19kQ30yJHthY19kRH0NCiR7YWNfdUF9U0laRU9GX1NI
T1JUJHthY191Qn1TSVpFT0ZfU0hPUlQke2FjX3VDfTIke2FjX3VEfQ0KJHth
Y19lQX1TSVpFT0ZfU0hPUlQke2FjX2VCfVNJWkVPRl9TSE9SVCR7YWNfZUN9
MiR7YWNfZUR9DQpDT05GRU9GDQpjYXQgPj4gY29uZnRlc3Quc2VkIDw8Q09O
RkVPRg0KJHthY19kQX1TSVpFT0ZfSU5UJHthY19kQn1TSVpFT0ZfSU5UJHth
Y19kQ300JHthY19kRH0NCiR7YWNfdUF9U0laRU9GX0lOVCR7YWNfdUJ9U0la
RU9GX0lOVCR7YWNfdUN9NCR7YWNfdUR9DQoke2FjX2VBfVNJWkVPRl9JTlQk
e2FjX2VCfVNJWkVPRl9JTlQke2FjX2VDfTQke2FjX2VEfQ0KJHthY19kQX1T
SVpFT0ZfTE9ORyR7YWNfZEJ9U0laRU9GX0xPTkcke2FjX2RDfTQke2FjX2RE
fQ0KJHthY191QX1TSVpFT0ZfTE9ORyR7YWNfdUJ9U0laRU9GX0xPTkcke2Fj
X3VDfTQke2FjX3VEfQ0KJHthY19lQX1TSVpFT0ZfTE9ORyR7YWNfZUJ9U0la
RU9GX0xPTkcke2FjX2VDfTQke2FjX2VEfQ0KJHthY19kQX1IQVZFX0FDT1NI
JHthY19kQn1IQVZFX0FDT1NIJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9
SEFWRV9BQ09TSCR7YWNfdUJ9SEFWRV9BQ09TSCR7YWNfdUN9MSR7YWNfdUR9
DQoke2FjX2VBfUhBVkVfQUNPU0gke2FjX2VCfUhBVkVfQUNPU0gke2FjX2VD
fTEke2FjX2VEfQ0KQ09ORkVPRg0KY2F0ID4+IGNvbmZ0ZXN0LnNlZCA8PENP
TkZFT0YNCiR7YWNfZEF9SEFWRV9BU0lOSCR7YWNfZEJ9SEFWRV9BU0lOSCR7
YWNfZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVfQVNJTkgke2FjX3VCfUhB
VkVfQVNJTkgke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX0FTSU5I
JHthY19lQn1IQVZFX0FTSU5IJHthY19lQ30xJHthY19lRH0NCiR7YWNfZEF9
SEFWRV9BVEFOSCR7YWNfZEJ9SEFWRV9BVEFOSCR7YWNfZEN9MSR7YWNfZER9
DQoke2FjX3VBfUhBVkVfQVRBTkgke2FjX3VCfUhBVkVfQVRBTkgke2FjX3VD
fTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX0FUQU5IJHthY19lQn1IQVZFX0FU
QU5IJHthY19lQ30xJHthY19lRH0NCiR7YWNfZEF9SEFWRV9DQlJUJHthY19k
Qn1IQVZFX0NCUlQke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX0NC
UlQke2FjX3VCfUhBVkVfQ0JSVCR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VB
fUhBVkVfQ0JSVCR7YWNfZUJ9SEFWRV9DQlJUJHthY19lQ30xJHthY19lRH0N
CkNPTkZFT0YNCmNhdCA+PiBjb25mdGVzdC5zZWQgPDxDT05GRU9GDQoke2Fj
X2RBfUhBVkVfQ0xPU0VESVIke2FjX2RCfUhBVkVfQ0xPU0VESVIke2FjX2RD
fTEke2FjX2REfQ0KJHthY191QX1IQVZFX0NMT1NFRElSJHthY191Qn1IQVZF
X0NMT1NFRElSJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9DTE9T
RURJUiR7YWNfZUJ9SEFWRV9DTE9TRURJUiR7YWNfZUN9MSR7YWNfZUR9DQok
e2FjX2RBfUhBVkVfRFVQMiR7YWNfZEJ9SEFWRV9EVVAyJHthY19kQ30xJHth
Y19kRH0NCiR7YWNfdUF9SEFWRV9EVVAyJHthY191Qn1IQVZFX0RVUDIke2Fj
X3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX0RVUDIke2FjX2VCfUhBVkVf
RFVQMiR7YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RBfUhBVkVfRk1PRCR7YWNf
ZEJ9SEFWRV9GTU9EJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9G
TU9EJHthY191Qn1IQVZFX0ZNT0Qke2FjX3VDfTEke2FjX3VEfQ0KJHthY19l
QX1IQVZFX0ZNT0Qke2FjX2VCfUhBVkVfRk1PRCR7YWNfZUN9MSR7YWNfZUR9
DQpDT05GRU9GDQpjYXQgPj4gY29uZnRlc3Quc2VkIDw8Q09ORkVPRg0KJHth
Y19kQX1IQVZFX0ZQQVRIQ09ORiR7YWNfZEJ9SEFWRV9GUEFUSENPTkYke2Fj
X2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX0ZQQVRIQ09ORiR7YWNfdUJ9
SEFWRV9GUEFUSENPTkYke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZF
X0ZQQVRIQ09ORiR7YWNfZUJ9SEFWRV9GUEFUSENPTkYke2FjX2VDfTEke2Fj
X2VEfQ0KJHthY19kQX1IQVZFX0ZSRVhQJHthY19kQn1IQVZFX0ZSRVhQJHth
Y19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9GUkVYUCR7YWNfdUJ9SEFW
RV9GUkVYUCR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVfRlJFWFAk
e2FjX2VCfUhBVkVfRlJFWFAke2FjX2VDfTEke2FjX2VEfQ0KJHthY19kQX1I
QVZFX0ZUSU1FJHthY19kQn1IQVZFX0ZUSU1FJHthY19kQ30xJHthY19kRH0N
CiR7YWNfdUF9SEFWRV9GVElNRSR7YWNfdUJ9SEFWRV9GVElNRSR7YWNfdUN9
MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVfRlRJTUUke2FjX2VCfUhBVkVfRlRJ
TUUke2FjX2VDfTEke2FjX2VEfQ0KQ09ORkVPRg0KY2F0ID4+IGNvbmZ0ZXN0
LnNlZCA8PENPTkZFT0YNCiR7YWNfZEF9SEFWRV9HRVRIT1NUTkFNRSR7YWNf
ZEJ9SEFWRV9HRVRIT1NUTkFNRSR7YWNfZEN9MSR7YWNfZER9DQoke2FjX3VB
fUhBVkVfR0VUSE9TVE5BTUUke2FjX3VCfUhBVkVfR0VUSE9TVE5BTUUke2Fj
X3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX0dFVEhPU1ROQU1FJHthY19l
Qn1IQVZFX0dFVEhPU1ROQU1FJHthY19lQ30xJHthY19lRH0NCiR7YWNfZEF9
SEFWRV9HRVRQQUdFU0laRSR7YWNfZEJ9SEFWRV9HRVRQQUdFU0laRSR7YWNf
ZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVfR0VUUEFHRVNJWkUke2FjX3VC
fUhBVkVfR0VUUEFHRVNJWkUke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1I
QVZFX0dFVFBBR0VTSVpFJHthY19lQn1IQVZFX0dFVFBBR0VTSVpFJHthY19l
Q30xJHthY19lRH0NCiR7YWNfZEF9SEFWRV9HRVRUSU1FT0ZEQVkke2FjX2RC
fUhBVkVfR0VUVElNRU9GREFZJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9
SEFWRV9HRVRUSU1FT0ZEQVkke2FjX3VCfUhBVkVfR0VUVElNRU9GREFZJHth
Y191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9HRVRUSU1FT0ZEQVkke2Fj
X2VCfUhBVkVfR0VUVElNRU9GREFZJHthY19lQ30xJHthY19lRH0NCkNPTkZF
T0YNCmNhdCA+PiBjb25mdGVzdC5zZWQgPDxDT05GRU9GDQoke2FjX2RBfUhB
VkVfR0VUV0Qke2FjX2RCfUhBVkVfR0VUV0Qke2FjX2RDfTEke2FjX2REfQ0K
JHthY191QX1IQVZFX0dFVFdEJHthY191Qn1IQVZFX0dFVFdEJHthY191Q30x
JHthY191RH0NCiR7YWNfZUF9SEFWRV9HRVRXRCR7YWNfZUJ9SEFWRV9HRVRX
RCR7YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RBfUhBVkVfTE9HQiR7YWNfZEJ9
SEFWRV9MT0dCJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9MT0dC
JHthY191Qn1IQVZFX0xPR0Ike2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1I
QVZFX0xPR0Ike2FjX2VCfUhBVkVfTE9HQiR7YWNfZUN9MSR7YWNfZUR9DQok
e2FjX2RBfUhBVkVfTFJBTkQ0OCR7YWNfZEJ9SEFWRV9MUkFORDQ4JHthY19k
Q30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9MUkFORDQ4JHthY191Qn1IQVZF
X0xSQU5ENDgke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX0xSQU5E
NDgke2FjX2VCfUhBVkVfTFJBTkQ0OCR7YWNfZUN9MSR7YWNfZUR9DQpDT05G
RU9GDQpjYXQgPj4gY29uZnRlc3Quc2VkIDw8Q09ORkVPRg0KJHthY19kQX1I
QVZFX01BVEhFUlIke2FjX2RCfUhBVkVfTUFUSEVSUiR7YWNfZEN9MSR7YWNf
ZER9DQoke2FjX3VBfUhBVkVfTUFUSEVSUiR7YWNfdUJ9SEFWRV9NQVRIRVJS
JHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9NQVRIRVJSJHthY19l
Qn1IQVZFX01BVEhFUlIke2FjX2VDfTEke2FjX2VEfQ0KJHthY19kQX1IQVZF
X01LRElSJHthY19kQn1IQVZFX01LRElSJHthY19kQ30xJHthY19kRH0NCiR7
YWNfdUF9SEFWRV9NS0RJUiR7YWNfdUJ9SEFWRV9NS0RJUiR7YWNfdUN9MSR7
YWNfdUR9DQoke2FjX2VBfUhBVkVfTUtESVIke2FjX2VCfUhBVkVfTUtESVIk
e2FjX2VDfTEke2FjX2VEfQ0KJHthY19kQX1IQVZFX01LVElNRSR7YWNfZEJ9
SEFWRV9NS1RJTUUke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX01L
VElNRSR7YWNfdUJ9SEFWRV9NS1RJTUUke2FjX3VDfTEke2FjX3VEfQ0KJHth
Y19lQX1IQVZFX01LVElNRSR7YWNfZUJ9SEFWRV9NS1RJTUUke2FjX2VDfTEk
e2FjX2VEfQ0KQ09ORkVPRg0KY2F0ID4+IGNvbmZ0ZXN0LnNlZCA8PENPTkZF
T0YNCiR7YWNfZEF9SEFWRV9QRVJST1Ike2FjX2RCfUhBVkVfUEVSUk9SJHth
Y19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9QRVJST1Ike2FjX3VCfUhB
VkVfUEVSUk9SJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9QRVJS
T1Ike2FjX2VCfUhBVkVfUEVSUk9SJHthY19lQ30xJHthY19lRH0NCiR7YWNf
ZEF9SEFWRV9QT0xMJHthY19kQn1IQVZFX1BPTEwke2FjX2RDfTEke2FjX2RE
fQ0KJHthY191QX1IQVZFX1BPTEwke2FjX3VCfUhBVkVfUE9MTCR7YWNfdUN9
MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVfUE9MTCR7YWNfZUJ9SEFWRV9QT0xM
JHthY19lQ30xJHthY19lRH0NCiR7YWNfZEF9SEFWRV9SQU5ET00ke2FjX2RC
fUhBVkVfUkFORE9NJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9S
QU5ET00ke2FjX3VCfUhBVkVfUkFORE9NJHthY191Q30xJHthY191RH0NCiR7
YWNfZUF9SEFWRV9SQU5ET00ke2FjX2VCfUhBVkVfUkFORE9NJHthY19lQ30x
JHthY19lRH0NCkNPTkZFT0YNCmNhdCA+PiBjb25mdGVzdC5zZWQgPDxDT05G
RU9GDQoke2FjX2RBfUhBVkVfUkVBTFBBVEgke2FjX2RCfUhBVkVfUkVBTFBB
VEgke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX1JFQUxQQVRIJHth
Y191Qn1IQVZFX1JFQUxQQVRIJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9
SEFWRV9SRUFMUEFUSCR7YWNfZUJ9SEFWRV9SRUFMUEFUSCR7YWNfZUN9MSR7
YWNfZUR9DQoke2FjX2RBfUhBVkVfUkVOQU1FJHthY19kQn1IQVZFX1JFTkFN
RSR7YWNfZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVfUkVOQU1FJHthY191
Qn1IQVZFX1JFTkFNRSR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVf
UkVOQU1FJHthY19lQn1IQVZFX1JFTkFNRSR7YWNfZUN9MSR7YWNfZUR9DQok
e2FjX2RBfUhBVkVfUklOVCR7YWNfZEJ9SEFWRV9SSU5UJHthY19kQ30xJHth
Y19kRH0NCiR7YWNfdUF9SEFWRV9SSU5UJHthY191Qn1IQVZFX1JJTlQke2Fj
X3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX1JJTlQke2FjX2VCfUhBVkVf
UklOVCR7YWNfZUN9MSR7YWNfZUR9DQpDT05GRU9GDQpjYXQgPj4gY29uZnRl
c3Quc2VkIDw8Q09ORkVPRg0KJHthY19kQX1IQVZFX1JNRElSJHthY19kQn1I
QVZFX1JNRElSJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9STURJ
UiR7YWNfdUJ9SEFWRV9STURJUiR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VB
fUhBVkVfUk1ESVIke2FjX2VCfUhBVkVfUk1ESVIke2FjX2VDfTEke2FjX2VE
fQ0KJHthY19kQX1IQVZFX1NFTEVDVCR7YWNfZEJ9SEFWRV9TRUxFQ1Qke2Fj
X2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX1NFTEVDVCR7YWNfdUJ9SEFW
RV9TRUxFQ1Qke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX1NFTEVD
VCR7YWNfZUJ9SEFWRV9TRUxFQ1Qke2FjX2VDfTEke2FjX2VEfQ0KJHthY19k
QX1IQVZFX1NFVElUSU1FUiR7YWNfZEJ9SEFWRV9TRVRJVElNRVIke2FjX2RD
fTEke2FjX2REfQ0KJHthY191QX1IQVZFX1NFVElUSU1FUiR7YWNfdUJ9SEFW
RV9TRVRJVElNRVIke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX1NF
VElUSU1FUiR7YWNfZUJ9SEFWRV9TRVRJVElNRVIke2FjX2VDfTEke2FjX2VE
fQ0KQ09ORkVPRg0KY2F0ID4+IGNvbmZ0ZXN0LnNlZCA8PENPTkZFT0YNCiR7
YWNfZEF9SEFWRV9TRVRQR0lEJHthY19kQn1IQVZFX1NFVFBHSUQke2FjX2RD
fTEke2FjX2REfQ0KJHthY191QX1IQVZFX1NFVFBHSUQke2FjX3VCfUhBVkVf
U0VUUEdJRCR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVfU0VUUEdJ
RCR7YWNfZUJ9SEFWRV9TRVRQR0lEJHthY19lQ30xJHthY19lRH0NCiR7YWNf
ZEF9SEFWRV9TRVRMT0NBTEUke2FjX2RCfUhBVkVfU0VUTE9DQUxFJHthY19k
Q30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9TRVRMT0NBTEUke2FjX3VCfUhB
VkVfU0VUTE9DQUxFJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9T
RVRMT0NBTEUke2FjX2VCfUhBVkVfU0VUTE9DQUxFJHthY19lQ30xJHthY19l
RH0NCiR7YWNfZEF9SEFWRV9TRVRTSUQke2FjX2RCfUhBVkVfU0VUU0lEJHth
Y19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9TRVRTSUQke2FjX3VCfUhB
VkVfU0VUU0lEJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9TRVRT
SUQke2FjX2VCfUhBVkVfU0VUU0lEJHthY19lQ30xJHthY19lRH0NCkNPTkZF
T0YNCmNhdCA+PiBjb25mdGVzdC5zZWQgPDxDT05GRU9GDQoke2FjX2RBfUhB
VkVfU0lHQkxPQ0ske2FjX2RCfUhBVkVfU0lHQkxPQ0ske2FjX2RDfTEke2Fj
X2REfQ0KJHthY191QX1IQVZFX1NJR0JMT0NLJHthY191Qn1IQVZFX1NJR0JM
T0NLJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9TSUdCTE9DSyR7
YWNfZUJ9SEFWRV9TSUdCTE9DSyR7YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RB
fUhBVkVfU0lHUFJPQ01BU0ske2FjX2RCfUhBVkVfU0lHUFJPQ01BU0ske2Fj
X2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX1NJR1BST0NNQVNLJHthY191
Qn1IQVZFX1NJR1BST0NNQVNLJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9
SEFWRV9TSUdQUk9DTUFTSyR7YWNfZUJ9SEFWRV9TSUdQUk9DTUFTSyR7YWNf
ZUN9MSR7YWNfZUR9DQoke2FjX2RBfUhBVkVfU1RSRVJST1Ike2FjX2RCfUhB
VkVfU1RSRVJST1Ike2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX1NU
UkVSUk9SJHthY191Qn1IQVZFX1NUUkVSUk9SJHthY191Q30xJHthY191RH0N
CiR7YWNfZUF9SEFWRV9TVFJFUlJPUiR7YWNfZUJ9SEFWRV9TVFJFUlJPUiR7
YWNfZUN9MSR7YWNfZUR9DQpDT05GRU9GDQpjYXQgPj4gY29uZnRlc3Quc2Vk
IDw8Q09ORkVPRg0KJHthY19kQX1IQVZFX1RaU0VUJHthY19kQn1IQVZFX1Ra
U0VUJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9UWlNFVCR7YWNf
dUJ9SEFWRV9UWlNFVCR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVf
VFpTRVQke2FjX2VCfUhBVkVfVFpTRVQke2FjX2VDfTEke2FjX2VEfQ0KJHth
Y19kQX1IQVZFX1VUSU1FUyR7YWNfZEJ9SEFWRV9VVElNRVMke2FjX2RDfTEk
e2FjX2REfQ0KJHthY191QX1IQVZFX1VUSU1FUyR7YWNfdUJ9SEFWRV9VVElN
RVMke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX1VUSU1FUyR7YWNf
ZUJ9SEFWRV9VVElNRVMke2FjX2VDfTEke2FjX2VEfQ0KJHthY19kQX1IQVZF
X1dBSVRQSUQke2FjX2RCfUhBVkVfV0FJVFBJRCR7YWNfZEN9MSR7YWNfZER9
DQoke2FjX3VBfUhBVkVfV0FJVFBJRCR7YWNfdUJ9SEFWRV9XQUlUUElEJHth
Y191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9XQUlUUElEJHthY19lQn1I
QVZFX1dBSVRQSUQke2FjX2VDfTEke2FjX2VEfQ0KQ09ORkVPRg0KY2F0ID4+
IGNvbmZ0ZXN0LnNlZCA8PENPTkZFT0YNCiR7YWNfZEF9SEFWRV9NTUFQJHth
Y19kQn1IQVZFX01NQVAke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZF
X01NQVAke2FjX3VCfUhBVkVfTU1BUCR7YWNfdUN9MSR7YWNfdUR9DQoke2Fj
X2VBfUhBVkVfTU1BUCR7YWNfZUJ9SEFWRV9NTUFQJHthY19lQ30xJHthY19l
RH0NCiR7YWNfZEF9SEFWRV9TT0NLRVRTJHthY19kQn1IQVZFX1NPQ0tFVFMk
e2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1IQVZFX1NPQ0tFVFMke2FjX3VC
fUhBVkVfU09DS0VUUyR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVf
U09DS0VUUyR7YWNfZUJ9SEFWRV9TT0NLRVRTJHthY19lQ30xJHthY19lRH0N
CiR7YWNfZEF9U1lTVl9TWVNURU1fRElSJHthY19kQn1TWVNWX1NZU1RFTV9E
SVIke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1TWVNWX1NZU1RFTV9ESVIk
e2FjX3VCfVNZU1ZfU1lTVEVNX0RJUiR7YWNfdUN9MSR7YWNfdUR9DQoke2Fj
X2VBfVNZU1ZfU1lTVEVNX0RJUiR7YWNfZUJ9U1lTVl9TWVNURU1fRElSJHth
Y19lQ30xJHthY19lRH0NCkNPTkZFT0YNCmNhdCA+PiBjb25mdGVzdC5zZWQg
PDxDT05GRU9GDQoke2FjX2RBfUhBVkVfVEVSTUlPUyR7YWNfZEJ9SEFWRV9U
RVJNSU9TJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9SEFWRV9URVJNSU9T
JHthY191Qn1IQVZFX1RFUk1JT1Mke2FjX3VDfTEke2FjX3VEfQ0KJHthY19l
QX1IQVZFX1RFUk1JT1Mke2FjX2VCfUhBVkVfVEVSTUlPUyR7YWNfZUN9MSR7
YWNfZUR9DQoke2FjX2RBfU5MSVNUX1NUUlVDVCR7YWNfZEJ9TkxJU1RfU1RS
VUNUJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9TkxJU1RfU1RSVUNUJHth
Y191Qn1OTElTVF9TVFJVQ1Qke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1O
TElTVF9TVFJVQ1Qke2FjX2VCfU5MSVNUX1NUUlVDVCR7YWNfZUN9MSR7YWNf
ZUR9DQoke2FjX2RBfUhBVkVfTElCREJNJHthY19kQn1IQVZFX0xJQkRCTSR7
YWNfZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVfTElCREJNJHthY191Qn1I
QVZFX0xJQkRCTSR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUhBVkVfTElC
REJNJHthY19lQn1IQVZFX0xJQkRCTSR7YWNfZUN9MSR7YWNfZUR9DQpDT05G
RU9GDQpjYXQgPj4gY29uZnRlc3Quc2VkIDw8Q09ORkVPRg0KJHthY19kQX1I
QVZFX0RCTSR7YWNfZEJ9SEFWRV9EQk0ke2FjX2RDfTEke2FjX2REfQ0KJHth
Y191QX1IQVZFX0RCTSR7YWNfdUJ9SEFWRV9EQk0ke2FjX3VDfTEke2FjX3VE
fQ0KJHthY19lQX1IQVZFX0RCTSR7YWNfZUJ9SEFWRV9EQk0ke2FjX2VDfTEk
e2FjX2VEfQ0KJHthY19kQX1FTUFDU19DT05GSUdVUkFUSU9OJHthY19kQn1F
TUFDU19DT05GSUdVUkFUSU9OJHthY19kQ30ic3BhcmMtc3VuLXN1bm9zNC4x
LjMiJHthY19kRH0NCiR7YWNfdUF9RU1BQ1NfQ09ORklHVVJBVElPTiR7YWNf
dUJ9RU1BQ1NfQ09ORklHVVJBVElPTiR7YWNfdUN9InNwYXJjLXN1bi1zdW5v
czQuMS4zIiR7YWNfdUR9DQoke2FjX2VBfUVNQUNTX0NPTkZJR1VSQVRJT04k
e2FjX2VCfUVNQUNTX0NPTkZJR1VSQVRJT04ke2FjX2VDfSJzcGFyYy1zdW4t
c3Vub3M0LjEuMyIke2FjX2VEfQ0KJHthY19kQX1jb25maWdfbWFjaGZpbGUk
e2FjX2RCfWNvbmZpZ19tYWNoZmlsZSR7YWNfZEN9Im0vc3BhcmMuaCIke2Fj
X2REfQ0KJHthY191QX1jb25maWdfbWFjaGZpbGUke2FjX3VCfWNvbmZpZ19t
YWNoZmlsZSR7YWNfdUN9Im0vc3BhcmMuaCIke2FjX3VEfQ0KJHthY19lQX1j
b25maWdfbWFjaGZpbGUke2FjX2VCfWNvbmZpZ19tYWNoZmlsZSR7YWNfZUN9
Im0vc3BhcmMuaCIke2FjX2VEfQ0KQ09ORkVPRg0KY2F0ID4+IGNvbmZ0ZXN0
LnNlZCA8PENPTkZFT0YNCiR7YWNfZEF9Y29uZmlnX29wc3lzZmlsZSR7YWNf
ZEJ9Y29uZmlnX29wc3lzZmlsZSR7YWNfZEN9InMvc3Vub3M0LTEtM3Noci5o
IiR7YWNfZER9DQoke2FjX3VBfWNvbmZpZ19vcHN5c2ZpbGUke2FjX3VCfWNv
bmZpZ19vcHN5c2ZpbGUke2FjX3VDfSJzL3N1bm9zNC0xLTNzaHIuaCIke2Fj
X3VEfQ0KJHthY19lQX1jb25maWdfb3BzeXNmaWxlJHthY19lQn1jb25maWdf
b3BzeXNmaWxlJHthY19lQ30icy9zdW5vczQtMS0zc2hyLmgiJHthY19lRH0N
CiR7YWNfZEF9TERfU1dJVENIX1hfU0lURSR7YWNfZEJ9TERfU1dJVENIX1hf
U0lURSR7YWNfZEN9LUwvdXNyL2xvY2FsL1gxMVI1L2xpYiAtTC92b2wvb3Bl
bndpbi9saWIgJHthY19kRH0NCiR7YWNfdUF9TERfU1dJVENIX1hfU0lURSR7
YWNfdUJ9TERfU1dJVENIX1hfU0lURSR7YWNfdUN9LUwvdXNyL2xvY2FsL1gx
MVI1L2xpYiAtTC92b2wvb3Blbndpbi9saWIgJHthY191RH0NCiR7YWNfZUF9
TERfU1dJVENIX1hfU0lURSR7YWNfZUJ9TERfU1dJVENIX1hfU0lURSR7YWNf
ZUN9LUwvdXNyL2xvY2FsL1gxMVI1L2xpYiAtTC92b2wvb3Blbndpbi9saWIg
JHthY19lRH0NCiR7YWNfZEF9TERfU1dJVENIX1hfU0lURV9BVVgke2FjX2RC
fUxEX1NXSVRDSF9YX1NJVEVfQVVYJHthY19kQ30ke2FjX2REfQ0KJHthY191
QX1MRF9TV0lUQ0hfWF9TSVRFX0FVWCR7YWNfdUJ9TERfU1dJVENIX1hfU0lU
RV9BVVgke2FjX3VDfSR7YWNfdUR9DQoke2FjX2VBfUxEX1NXSVRDSF9YX1NJ
VEVfQVVYJHthY19lQn1MRF9TV0lUQ0hfWF9TSVRFX0FVWCR7YWNfZUN9JHth
Y19lRH0NCkNPTkZFT0YNCmNhdCA+PiBjb25mdGVzdC5zZWQgPDxDT05GRU9G
DQoke2FjX2RBfUNfU1dJVENIX1hfU0lURSR7YWNfZEJ9Q19TV0lUQ0hfWF9T
SVRFJHthY19kQ30tSS91c3IvbG9jYWwvWDExUjUvaW5jbHVkZSAtSS92b2wv
b3Blbndpbi9pbmNsdWRlL2Rlc2t0b3AgLUkvdm9sL29wZW53aW4vaW5jbHVk
ZS9kZXNrdG9wJHthY19kRH0NCiR7YWNfdUF9Q19TV0lUQ0hfWF9TSVRFJHth
Y191Qn1DX1NXSVRDSF9YX1NJVEUke2FjX3VDfS1JL3Vzci9sb2NhbC9YMTFS
NS9pbmNsdWRlIC1JL3ZvbC9vcGVud2luL2luY2x1ZGUvZGVza3RvcCAtSS92
b2wvb3Blbndpbi9pbmNsdWRlL2Rlc2t0b3Ake2FjX3VEfQ0KJHthY19lQX1D
X1NXSVRDSF9YX1NJVEUke2FjX2VCfUNfU1dJVENIX1hfU0lURSR7YWNfZUN9
LUkvdXNyL2xvY2FsL1gxMVI1L2luY2x1ZGUgLUkvdm9sL29wZW53aW4vaW5j
bHVkZS9kZXNrdG9wIC1JL3ZvbC9vcGVud2luL2luY2x1ZGUvZGVza3RvcCR7
YWNfZUR9DQoke2FjX2RBfUxEX1NXSVRDSF9TSVRFJHthY19kQn1MRF9TV0lU
Q0hfU0lURSR7YWNfZEN9IC1ML3ZvbC9tb3RpZi91c3IvbGliIC1ML3ZvbC9v
cGVud2luL2xpYiAtTC92b2wvZW1hY3MvY29tcGZhY2UgLUwvdm9sL3B1cmUv
cXVhbnRpZnktMi4wLjEtc3Vub3M0IC1ML3ZvbC9lbWFjcy9qcGVnLTVhJHth
Y19kRH0NCiR7YWNfdUF9TERfU1dJVENIX1NJVEUke2FjX3VCfUxEX1NXSVRD
SF9TSVRFJHthY191Q30gLUwvdm9sL21vdGlmL3Vzci9saWIgLUwvdm9sL29w
ZW53aW4vbGliIC1ML3ZvbC9lbWFjcy9jb21wZmFjZSAtTC92b2wvcHVyZS9x
dWFudGlmeS0yLjAuMS1zdW5vczQgLUwvdm9sL2VtYWNzL2pwZWctNWEke2Fj
X3VEfQ0KJHthY19lQX1MRF9TV0lUQ0hfU0lURSR7YWNfZUJ9TERfU1dJVENI
X1NJVEUke2FjX2VDfSAtTC92b2wvbW90aWYvdXNyL2xpYiAtTC92b2wvb3Bl
bndpbi9saWIgLUwvdm9sL2VtYWNzL2NvbXBmYWNlIC1ML3ZvbC9wdXJlL3F1
YW50aWZ5LTIuMC4xLXN1bm9zNCAtTC92b2wvZW1hY3MvanBlZy01YSR7YWNf
ZUR9DQoke2FjX2RBfUNfU1dJVENIX1NJVEUke2FjX2RCfUNfU1dJVENIX1NJ
VEUke2FjX2RDfSAtSS92b2wvbW90aWYvdXNyL2luY2x1ZGUgLUkvdm9sL29w
ZW53aW4vaW5jbHVkZSAtSS92b2wvZW1hY3MvY29tcGZhY2UgLUkvdm9sL3B1
cmUvcXVhbnRpZnktMi4wLjEtc3Vub3M0IC1JL3ZvbC9lbWFjcy9qcGVnLTVh
JHthY19kRH0NCiR7YWNfdUF9Q19TV0lUQ0hfU0lURSR7YWNfdUJ9Q19TV0lU
Q0hfU0lURSR7YWNfdUN9IC1JL3ZvbC9tb3RpZi91c3IvaW5jbHVkZSAtSS92
b2wvb3Blbndpbi9pbmNsdWRlIC1JL3ZvbC9lbWFjcy9jb21wZmFjZSAtSS92
b2wvcHVyZS9xdWFudGlmeS0yLjAuMS1zdW5vczQgLUkvdm9sL2VtYWNzL2pw
ZWctNWEke2FjX3VEfQ0KJHthY19lQX1DX1NXSVRDSF9TSVRFJHthY19lQn1D
X1NXSVRDSF9TSVRFJHthY19lQ30gLUkvdm9sL21vdGlmL3Vzci9pbmNsdWRl
IC1JL3ZvbC9vcGVud2luL2luY2x1ZGUgLUkvdm9sL2VtYWNzL2NvbXBmYWNl
IC1JL3ZvbC9wdXJlL3F1YW50aWZ5LTIuMC4xLXN1bm9zNCAtSS92b2wvZW1h
Y3MvanBlZy01YSR7YWNfZUR9DQpDT05GRU9GDQpjYXQgPj4gY29uZnRlc3Qu
c2VkIDw8Q09ORkVPRg0KJHthY19kQX1VTkVYRUNfU1JDJHthY19kQn1VTkVY
RUNfU1JDJHthY19kQ311bmV4c3Vub3M0LmMke2FjX2REfQ0KJHthY191QX1V
TkVYRUNfU1JDJHthY191Qn1VTkVYRUNfU1JDJHthY191Q311bmV4c3Vub3M0
LmMke2FjX3VEfQ0KJHthY19lQX1VTkVYRUNfU1JDJHthY19lQn1VTkVYRUNf
U1JDJHthY19lQ311bmV4c3Vub3M0LmMke2FjX2VEfQ0KJHthY19kQX1IQVZF
X1hfV0lORE9XUyR7YWNfZEJ9SEFWRV9YX1dJTkRPV1Mke2FjX2RDfTEke2Fj
X2REfQ0KJHthY191QX1IQVZFX1hfV0lORE9XUyR7YWNfdUJ9SEFWRV9YX1dJ
TkRPV1Mke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX1hfV0lORE9X
UyR7YWNfZUJ9SEFWRV9YX1dJTkRPV1Mke2FjX2VDfTEke2FjX2VEfQ0KJHth
Y19kQX1HTlVfTUFMTE9DJHthY19kQn1HTlVfTUFMTE9DJHthY19kQ30xJHth
Y19kRH0NCiR7YWNfdUF9R05VX01BTExPQyR7YWNfdUJ9R05VX01BTExPQyR7
YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUdOVV9NQUxMT0Mke2FjX2VCfUdO
VV9NQUxMT0Mke2FjX2VDfTEke2FjX2VEfQ0KQ09ORkVPRg0KY2F0ID4+IGNv
bmZ0ZXN0LnNlZCA8PENPTkZFT0YNCiR7YWNfZEF9UkVMX0FMTE9DJHthY19k
Qn1SRUxfQUxMT0Mke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1SRUxfQUxM
T0Mke2FjX3VCfVJFTF9BTExPQyR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VB
fVJFTF9BTExPQyR7YWNfZUJ9UkVMX0FMTE9DJHthY19lQ30xJHthY19lRH0N
CiR7YWNfZEF9TElTUF9GTE9BVF9UWVBFJHthY19kQn1MSVNQX0ZMT0FUX1RZ
UEUke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1MSVNQX0ZMT0FUX1RZUEUk
e2FjX3VCfUxJU1BfRkxPQVRfVFlQRSR7YWNfdUN9MSR7YWNfdUR9DQoke2Fj
X2VBfUxJU1BfRkxPQVRfVFlQRSR7YWNfZUJ9TElTUF9GTE9BVF9UWVBFJHth
Y19lQ30xJHthY19lRH0NCiR7YWNfZEF9TFdMSUJfVVNFU19NT1RJRiR7YWNf
ZEJ9TFdMSUJfVVNFU19NT1RJRiR7YWNfZEN9MSR7YWNfZER9DQoke2FjX3VB
fUxXTElCX1VTRVNfTU9USUYke2FjX3VCfUxXTElCX1VTRVNfTU9USUYke2Fj
X3VDfTEke2FjX3VEfQ0KJHthY19lQX1MV0xJQl9VU0VTX01PVElGJHthY19l
Qn1MV0xJQl9VU0VTX01PVElGJHthY19lQ30xJHthY19lRH0NCkNPTkZFT0YN
CmNhdCA+PiBjb25mdGVzdC5zZWQgPDxDT05GRU9GDQoke2FjX2RBfUxXTElC
X01FTlVCQVJTX0xVQ0lEJHthY19kQn1MV0xJQl9NRU5VQkFSU19MVUNJRCR7
YWNfZEN9MSR7YWNfZER9DQoke2FjX3VBfUxXTElCX01FTlVCQVJTX0xVQ0lE
JHthY191Qn1MV0xJQl9NRU5VQkFSU19MVUNJRCR7YWNfdUN9MSR7YWNfdUR9
DQoke2FjX2VBfUxXTElCX01FTlVCQVJTX0xVQ0lEJHthY19lQn1MV0xJQl9N
RU5VQkFSU19MVUNJRCR7YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RBfUhBVkVf
TUVOVUJBUlMke2FjX2RCfUhBVkVfTUVOVUJBUlMke2FjX2RDfTEke2FjX2RE
fQ0KJHthY191QX1IQVZFX01FTlVCQVJTJHthY191Qn1IQVZFX01FTlVCQVJT
JHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9NRU5VQkFSUyR7YWNf
ZUJ9SEFWRV9NRU5VQkFSUyR7YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RBfUxX
TElCX1NDUk9MTEJBUlNfTFVDSUQke2FjX2RCfUxXTElCX1NDUk9MTEJBUlNf
TFVDSUQke2FjX2RDfTEke2FjX2REfQ0KJHthY191QX1MV0xJQl9TQ1JPTExC
QVJTX0xVQ0lEJHthY191Qn1MV0xJQl9TQ1JPTExCQVJTX0xVQ0lEJHthY191
Q30xJHthY191RH0NCiR7YWNfZUF9TFdMSUJfU0NST0xMQkFSU19MVUNJRCR7
YWNfZUJ9TFdMSUJfU0NST0xMQkFSU19MVUNJRCR7YWNfZUN9MSR7YWNfZUR9
DQpDT05GRU9GDQpjYXQgPj4gY29uZnRlc3Quc2VkIDw8Q09ORkVPRg0KJHth
Y19kQX1IQVZFX1NDUk9MTEJBUlMke2FjX2RCfUhBVkVfU0NST0xMQkFSUyR7
YWNfZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVfU0NST0xMQkFSUyR7YWNf
dUJ9SEFWRV9TQ1JPTExCQVJTJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9
SEFWRV9TQ1JPTExCQVJTJHthY19lQn1IQVZFX1NDUk9MTEJBUlMke2FjX2VD
fTEke2FjX2VEfQ0KJHthY19kQX1MV0xJQl9ESUFMT0dTX01PVElGJHthY19k
Qn1MV0xJQl9ESUFMT0dTX01PVElGJHthY19kQ30xJHthY19kRH0NCiR7YWNf
dUF9TFdMSUJfRElBTE9HU19NT1RJRiR7YWNfdUJ9TFdMSUJfRElBTE9HU19N
T1RJRiR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfUxXTElCX0RJQUxPR1Nf
TU9USUYke2FjX2VCfUxXTElCX0RJQUxPR1NfTU9USUYke2FjX2VDfTEke2Fj
X2VEfQ0KJHthY19kQX1IQVZFX0RJQUxPR1Mke2FjX2RCfUhBVkVfRElBTE9H
UyR7YWNfZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVfRElBTE9HUyR7YWNf
dUJ9SEFWRV9ESUFMT0dTJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9SEFW
RV9ESUFMT0dTJHthY19lQn1IQVZFX0RJQUxPR1Mke2FjX2VDfTEke2FjX2VE
fQ0KQ09ORkVPRg0KY2F0ID4+IGNvbmZ0ZXN0LnNlZCA8PENPTkZFT0YNCiR7
YWNfZEF9SEFWRV9UT09MQkFSUyR7YWNfZEJ9SEFWRV9UT09MQkFSUyR7YWNf
ZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVfVE9PTEJBUlMke2FjX3VCfUhB
VkVfVE9PTEJBUlMke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1IQVZFX1RP
T0xCQVJTJHthY19lQn1IQVZFX1RPT0xCQVJTJHthY19lQ30xJHthY19lRH0N
CiR7YWNfZEF9SEFWRV9UVFkke2FjX2RCfUhBVkVfVFRZJHthY19kQ30xJHth
Y19kRH0NCiR7YWNfdUF9SEFWRV9UVFkke2FjX3VCfUhBVkVfVFRZJHthY191
Q30xJHthY191RH0NCiR7YWNfZUF9SEFWRV9UVFkke2FjX2VCfUhBVkVfVFRZ
JHthY19lQ30xJHthY19lRH0NCiR7YWNfZEF9VE9PTFRBTEske2FjX2RCfVRP
T0xUQUxLJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9VE9PTFRBTEske2Fj
X3VCfVRPT0xUQUxLJHthY191Q30xJHthY191RH0NCiR7YWNfZUF9VE9PTFRB
TEske2FjX2VCfVRPT0xUQUxLJHthY19lQ30xJHthY19lRH0NCkNPTkZFT0YN
CmNhdCA+PiBjb25mdGVzdC5zZWQgPDxDT05GRU9GDQoke2FjX2RBfVNVTlBS
TyR7YWNfZEJ9U1VOUFJPJHthY19kQ30xJHthY19kRH0NCiR7YWNfdUF9U1VO
UFJPJHthY191Qn1TVU5QUk8ke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1T
VU5QUk8ke2FjX2VCfVNVTlBSTyR7YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RB
fUhBVkVfTkFUSVZFX1NPVU5EJHthY19kQn1IQVZFX05BVElWRV9TT1VORCR7
YWNfZEN9MSR7YWNfZER9DQoke2FjX3VBfUhBVkVfTkFUSVZFX1NPVU5EJHth
Y191Qn1IQVZFX05BVElWRV9TT1VORCR7YWNfdUN9MSR7YWNfdUR9DQoke2Fj
X2VBfUhBVkVfTkFUSVZFX1NPVU5EJHthY19lQn1IQVZFX05BVElWRV9TT1VO
RCR7YWNfZUN9MSR7YWNfZUR9DQoke2FjX2RBfUNPTlNUX0lTX0xPU0lORyR7
YWNfZEJ9Q09OU1RfSVNfTE9TSU5HJHthY19kQ30xJHthY19kRH0NCiR7YWNf
dUF9Q09OU1RfSVNfTE9TSU5HJHthY191Qn1DT05TVF9JU19MT1NJTkcke2Fj
X3VDfTEke2FjX3VEfQ0KJHthY19lQX1DT05TVF9JU19MT1NJTkcke2FjX2VC
fUNPTlNUX0lTX0xPU0lORyR7YWNfZUN9MSR7YWNfZUR9DQpDT05GRU9GDQpj
YXQgPj4gY29uZnRlc3Quc2VkIDw8Q09ORkVPRg0KJHthY19kQX1VU0VfQVNT
RVJUSU9OUyR7YWNfZEJ9VVNFX0FTU0VSVElPTlMke2FjX2RDfTEke2FjX2RE
fQ0KJHthY191QX1VU0VfQVNTRVJUSU9OUyR7YWNfdUJ9VVNFX0FTU0VSVElP
TlMke2FjX3VDfTEke2FjX3VEfQ0KJHthY19lQX1VU0VfQVNTRVJUSU9OUyR7
YWNfZUJ9VVNFX0FTU0VSVElPTlMke2FjX2VDfTEke2FjX2VEfQ0KJHthY19k
QX1OT19VTklPTl9UWVBFJHthY19kQn1OT19VTklPTl9UWVBFJHthY19kQ30x
JHthY19kRH0NCiR7YWNfdUF9Tk9fVU5JT05fVFlQRSR7YWNfdUJ9Tk9fVU5J
T05fVFlQRSR7YWNfdUN9MSR7YWNfdUR9DQoke2FjX2VBfU5PX1VOSU9OX1RZ
UEUke2FjX2VCfU5PX1VOSU9OX1RZUEUke2FjX2VDfTEke2FjX2VEfQ0KJHth
Y19kQX1RVUFOVElGWSR7YWNfZEJ9UVVBTlRJRlkke2FjX2RDfTEke2FjX2RE
fQ0KJHthY191QX1RVUFOVElGWSR7YWNfdUJ9UVVBTlRJRlkke2FjX3VDfTEk
e2FjX3VEfQ0KJHthY19lQX1RVUFOVElGWSR7YWNfZUJ9UVVBTlRJRlkke2Fj
X2VDfTEke2FjX2VEfQ0KQ09ORkVPRg0KIyBUaGlzIHNlZCBjb21tYW5kIHJl
cGxhY2VzICN1bmRlZidzIHdpdGggY29tbWVudHMuICBUaGlzIGlzIG5lY2Vz
c2FyeSwgZm9yDQojIGV4YW1wbGUsIGluIHRoZSBjYXNlIG9mIF9QT1NJWF9T
T1VSQ0UsIHdoaWNoIGlzIHByZWRlZmluZWQgYW5kIHJlcXVpcmVkDQojIG9u
IHNvbWUgc3lzdGVtcyB3aGVyZSBjb25maWd1cmUgd2lsbCBub3QgZGVjaWRl
IHRvIGRlZmluZSBpdCBpbg0KIyBzcmMvY29uZmlnLmguDQpjYXQgPj4gY29u
ZnRlc3Quc2VkIDw8XENPTkZFT0YNCnMsXlsgCV0qI1sgCV0qdW5kZWZbIAld
WyAJXSpbYS16QS1aX11bYS16QS1aXzAtOV0qLC8qICYgKi8sDQpDT05GRU9G
DQpybSAtZiBjb25mdGVzdC5oDQojIEJyZWFrIHVwIHRoZSBzZWQgY29tbWFu
ZHMgYmVjYXVzZSBvbGQgc2VkcyBoYXZlIHNtYWxsIGxpbWl0cy4NCmFjX21h
eF9zZWRfbGluZXM9MjANCg0KQ09ORklHX0hFQURFUlM9JHtDT05GSUdfSEVB
REVSUy0ic3JjL2NvbmZpZy5oIn0NCmZvciBhY19maWxlIGluIC4uICR7Q09O
RklHX0hFQURFUlN9OyBkbyBpZiB0ZXN0ICJ4JGFjX2ZpbGUiICE9IHguLjsg
dGhlbg0KICBlY2hvIGNyZWF0aW5nICRhY19maWxlDQoNCiAgY3AgJGFjX2dp
dmVuX3NyY2Rpci8kYWNfZmlsZS5pbiBjb25mdGVzdC5oMQ0KICBjcCBjb25m
dGVzdC5zZWQgY29uZnRlc3Quc3RtDQogIHdoaWxlIDoNCiAgZG8NCiAgICBh
Y19saW5lcz1gZ3JlcCAtYyAuIGNvbmZ0ZXN0LnN0bWANCiAgICBpZiB0ZXN0
IC16ICIkYWNfbGluZXMiIHx8IHRlc3QgIiRhY19saW5lcyIgLWVxIDA7IHRo
ZW4gYnJlYWs7IGZpDQogICAgcm0gLWYgY29uZnRlc3QuczEgY29uZnRlc3Qu
czIgY29uZnRlc3QuaDINCiAgICBzZWQgJHthY19tYXhfc2VkX2xpbmVzfXEg
Y29uZnRlc3Quc3RtID4gY29uZnRlc3QuczEgIyBMaWtlIGhlYWQgLTIwLg0K
ICAgIHNlZCAxLCR7YWNfbWF4X3NlZF9saW5lc31kIGNvbmZ0ZXN0LnN0bSA+
IGNvbmZ0ZXN0LnMyICMgTGlrZSB0YWlsICsyMS4NCiAgICBzZWQgLWYgY29u
ZnRlc3QuczEgPCBjb25mdGVzdC5oMSA+IGNvbmZ0ZXN0LmgyDQogICAgcm0g
LWYgY29uZnRlc3QuczEgY29uZnRlc3QuaDEgY29uZnRlc3Quc3RtDQogICAg
bXYgY29uZnRlc3QuaDIgY29uZnRlc3QuaDENCiAgICBtdiBjb25mdGVzdC5z
MiBjb25mdGVzdC5zdG0NCiAgZG9uZQ0KICBybSAtZiBjb25mdGVzdC5zdG0g
Y29uZnRlc3QuaA0KICBlY2hvICIvKiAkYWNfZmlsZS4gIEdlbmVyYXRlZCBh
dXRvbWF0aWNhbGx5IGJ5IGNvbmZpZ3VyZS4gICovIiA+IGNvbmZ0ZXN0LmgN
CiAgY2F0IGNvbmZ0ZXN0LmgxID4+IGNvbmZ0ZXN0LmgNCiAgcm0gLWYgY29u
ZnRlc3QuaDENCiAgaWYgY21wIC1zICRhY19maWxlIGNvbmZ0ZXN0LmggMj4v
ZGV2L251bGw7IHRoZW4NCiAgICAjIFRoZSBmaWxlIGV4aXN0cyBhbmQgd2Ug
d291bGQgbm90IGJlIGNoYW5naW5nIGl0Lg0KICAgIGVjaG8gIiRhY19maWxl
IGlzIHVuY2hhbmdlZCINCiAgICBybSAtZiBjb25mdGVzdC5oDQogIGVsc2UN
CiAgICBybSAtZiAkYWNfZmlsZQ0KICAgIG12IGNvbmZ0ZXN0LmggJGFjX2Zp
bGUNCiAgZmkNCmZpOyBkb25lDQpybSAtZiBjb25mdGVzdC5zZWQNCg0KDQoN
Cg0KZWNobyAiY3JlYXRpbmcgc3JjL01ha2VmaWxlIjsgdG9wc3JjZGlyPS92
b2wvZW1hY3MveGVtYWNzLTE5LjE0LWIyNTsgKCBjZCAuL3NyYzsgcm0gLWYg
anVuay5jOyBzZWQgLWUgJ3MvXiMgR2VuZXJhdGVkLiovLycgLWUgJ3MlL1wq
XCovIy4qJSUnIDwgTWFrZWZpbGUuaW4gPiBqdW5rLmM7IGV2YWwgYGVjaG8g
JHtDUFB9IC1JLiAtSSR7dG9wc3JjZGlyfS9zcmMgJHtDUFBGTEFHU30ganVu
ay5jIFw+anVuay5jcHBgOyA8IGp1bmsuY3BwIHNlZCAtZSAncy9eIy4qLy8n
IC1lICdzL15bIFxmXHRdWyBcZlx0XSokLy8nIC1lICdzL14gLyAvJyB8IHNl
ZCAtbiAtZSAnL14uLiokL3AnID4gTWFrZWZpbGUubmV3OyBjaG1vZCA0NDQg
TWFrZWZpbGUubmV3OyBtdiAtZiBNYWtlZmlsZS5uZXcgTWFrZWZpbGU7IHJt
IC1mIGp1bmsuYyBqdW5rLmNwcDsgKQ0KZWNobyAiY3JlYXRpbmcgbHdsaWIv
TWFrZWZpbGUiOyB0b3BzcmNkaXI9L3ZvbC9lbWFjcy94ZW1hY3MtMTkuMTQt
YjI1OyAoIGNkIC4vbHdsaWI7IHJtIC1mIGp1bmsuYzsgc2VkIC1lICdzL14j
IEdlbmVyYXRlZC4qLy8nIC1lICdzJS9cKlwqLyMuKiUlJyA8IE1ha2VmaWxl
LmluID4ganVuay5jOyBldmFsIGBlY2hvICR7Q1BQfSAtSS4gLUkke3RvcHNy
Y2Rpcn0vc3JjICR7Q1BQRkxBR1N9IGp1bmsuYyBcPmp1bmsuY3BwYDsgPCBq
dW5rLmNwcCBzZWQgLWUgJ3MvXiMuKi8vJyAtZSAncy9eWyBcZlx0XVsgXGZc
dF0qJC8vJyAtZSAncy9eIC8gLycgfCBzZWQgLW4gLWUgJy9eLi4qJC9wJyA+
IE1ha2VmaWxlLm5ldzsgY2htb2QgNDQ0IE1ha2VmaWxlLm5ldzsgbXYgLWYg
TWFrZWZpbGUubmV3IE1ha2VmaWxlOyBybSAtZiBqdW5rLmMganVuay5jcHA7
ICkNCmVjaG8gImNyZWF0aW5nIGxpYi1zcmMvTWFrZWZpbGUiOyB0b3BzcmNk
aXI9L3ZvbC9lbWFjcy94ZW1hY3MtMTkuMTQtYjI1OyAoIGNkIC4vbGliLXNy
Yzsgcm0gLWYganVuay5jOyBzZWQgLWUgJ3MvXiMgR2VuZXJhdGVkLiovLycg
LWUgJ3MlL1wqXCovIy4qJSUnIDwgTWFrZWZpbGUuaW4gPiBqdW5rLmM7IGV2
YWwgYGVjaG8gJHtDUFB9IC1JLiAtSSR7dG9wc3JjZGlyfS9zcmMgJHtDUFBG
TEFHU30ganVuay5jIFw+anVuay5jcHBgOyA8IGp1bmsuY3BwIHNlZCAtZSAn
cy9eIy4qLy8nIC1lICdzL15bIFxmXHRdWyBcZlx0XSokLy8nIC1lICdzL14g
LyAvJyB8IHNlZCAtbiAtZSAnL14uLiokL3AnID4gTWFrZWZpbGUubmV3OyBj
aG1vZCA0NDQgTWFrZWZpbGUubmV3OyBtdiAtZiBNYWtlZmlsZS5uZXcgTWFr
ZWZpbGU7IHJtIC1mIGp1bmsuYyBqdW5rLmNwcDsgKQ0KZWNobyAiY3JlYXRp
bmcgZHlub2R1bXAvTWFrZWZpbGUiOyB0b3BzcmNkaXI9L3ZvbC9lbWFjcy94
ZW1hY3MtMTkuMTQtYjI1OyAoIGNkIC4vZHlub2R1bXA7IHJtIC1mIGp1bmsu
Yzsgc2VkIC1lICdzL14jIEdlbmVyYXRlZC4qLy8nIC1lICdzJS9cKlwqLyMu
KiUlJyA8IE1ha2VmaWxlLmluID4ganVuay5jOyBldmFsIGBlY2hvICR7Q1BQ
fSAtSS4gLUkke3RvcHNyY2Rpcn0vc3JjICR7Q1BQRkxBR1N9IGp1bmsuYyBc
Pmp1bmsuY3BwYDsgPCBqdW5rLmNwcCBzZWQgLWUgJ3MvXiMuKi8vJyAtZSAn
cy9eWyBcZlx0XVsgXGZcdF0qJC8vJyAtZSAncy9eIC8gLycgfCBzZWQgLW4g
LWUgJy9eLi4qJC9wJyA+IE1ha2VmaWxlLm5ldzsgY2htb2QgNDQ0IE1ha2Vm
aWxlLm5ldzsgbXYgLWYgTWFrZWZpbGUubmV3IE1ha2VmaWxlOyBybSAtZiBq
dW5rLmMganVuay5jcHA7ICkNCmVjaG8gImNyZWF0aW5nIG1hbi9NYWtlZmls
ZSI7IHRvcHNyY2Rpcj0vdm9sL2VtYWNzL3hlbWFjcy0xOS4xNC1iMjU7ICgg
Y2QgLi9tYW47IHJtIC1mIGp1bmsuYzsgc2VkIC1lICdzL14jIEdlbmVyYXRl
ZC4qLy8nIC1lICdzJS9cKlwqLyMuKiUlJyA8IE1ha2VmaWxlLmluID4ganVu
ay5jOyBldmFsIGBlY2hvICR7Q1BQfSAtSS4gLUkke3RvcHNyY2Rpcn0vc3Jj
ICR7Q1BQRkxBR1N9IGp1bmsuYyBcPmp1bmsuY3BwYDsgPCBqdW5rLmNwcCBz
ZWQgLWUgJ3MvXiMuKi8vJyAtZSAncy9eWyBcZlx0XVsgXGZcdF0qJC8vJyAt
ZSAncy9eIC8gLycgfCBzZWQgLW4gLWUgJy9eLi4qJC9wJyA+IE1ha2VmaWxl
Lm5ldzsgY2htb2QgNDQ0IE1ha2VmaWxlLm5ldzsgbXYgLWYgTWFrZWZpbGUu
bmV3IE1ha2VmaWxlOyBybSAtZiBqdW5rLmMganVuay5jcHA7ICkNCmV4aXQg
MA0K
--1430489217-2053294700-835285566=:20039--

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 16:05:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA12626 for xemacs-beta-people; Thu, 20 Jun 1996 16:05:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA12623 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 16:04:58 -0500 (CDT)
Received: from silmaril.paradigm-sa.com (root@paradigm-IS.ISnet.net [196.26.13.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA00649 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 16:04:48 -0500 (CDT)
Received: from hyperion.paradigm-sa.com by silmaril.paradigm-sa.com with smtp
	(Smail3.1.29.1 #6) id m0uWqny-000330C; Thu, 20 Jun 96 22:58 SAT
Date: Thu, 20 Jun 1996 22:59:28 -0200 (SAT)
From: "J. Kean Johnston" <jkj@paradigm-sa.com>
Reply-To: hug@netcom.com
To: xemacs-beta@xemacs.org
Subject: SCO OSR5 successes and an essential patch
Message-ID: <Pine.SCO5.3.93.960620225841.27864A-100000@hyperion.paradigm-sa.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Cursory tests on SCO Open Server 5.0 are working for me in the following
environments:

Compiler  Optimizations                                   Dynamic
SCO cc    -g                                              Yes
SCO cc    -g                                              No
SCO cc    -O                                              Yes
SCO cc    -O                                              No
GCC       -g -O99 -m486 -fomit-frame-pointer              Yes

In all cases, I compiled with X11, Xpm support. With the exception of the
--with-gcc=no for the SCO cc compiles and --dynamic in cases where I tested
dynamic support, this was my configure:
./configure i486-sco3.25v.0 --with-xmu=yes --with-xpm --site-libraries=/usr/local/lib --site-includes=/usr/local/include

Static compiles with GCC do not work due to a GCC bug in the current snapshots.

All of this was with the following essential patch applied:

*** PROBLEMS.orig	Thu Jun 20 21:57:39 1996
--- PROBLEMS	Thu Jun 20 22:07:11 1996
***************
*** 66,80 ****
  	  --site-includes=/usr/local/include --site-libraries=/usr/local/lib \
  	  --with-xpm --with-xface --with-sound=nas --dynamic
  
- Note that use of '--dynamic' will result in the configure step 
- generating what looks like error messages near the end of the process
- while it's generating the Makefiles.  You will see messages like 
- "0: unknown flag -belf" at the end of the configure, you may safely 
- disregard them.  They are an artifact of /lib/cpp and cc -E accepting
- different flags.  Why is /lib/cpp used instead of cc -E?  To avoid
- the tokenizers from hell.
- 
- 
  The compiler known as icc [ supplied with the OpenServer 5 Development 
  System ] generates a working binary, but it takes forever to generate
  XEmacs.  ICC also whines more about the code than /bin/cc does.  I do
--- 66,71 ----
***************
*** 110,123 ****
  like help in making it work, e-mail me at <robertl@dgii.com>
  
  In earlier releases, gnuserv/gnuclient/gnudoit would open a frame 
! just fine, but would client would lock up and the server would
  terminate when you used C-x # to close the frame.   This is now 
  fixed in XEmacs.
- 
- 
- If you are building with gcc 2.8.0 or later, or any of the current
- pre-releases, and you are configuring with --dynamic, you must prefix
- your configure command line with CC='gcc -melf'.
  
  In etc/ there are two files of note. emacskeys.sco and emacsstrs.sco.
  The comments at the top of emacskeys.sco describe its function, and
--- 101,109 ----
  like help in making it work, e-mail me at <robertl@dgii.com>
  
  In earlier releases, gnuserv/gnuclient/gnudoit would open a frame 
! just fine, but the client would lock up and the server would
  terminate when you used C-x # to close the frame.   This is now 
  fixed in XEmacs.
  
  In etc/ there are two files of note. emacskeys.sco and emacsstrs.sco.
  The comments at the top of emacskeys.sco describe its function, and
*** src/s/sco5.h.orig	Thu Jun 20 21:30:08 1996
--- src/s/sco5.h	Thu Jun 20 21:48:06 1996
***************
*** 79,92 ****
  #undef ADDR_CORRECT
  #define ADDR_CORRECT(x) (int)((char *)(x) - (char*)0)
  
! #define C_SWITCH_SYSTEM -D_NO_STATIC -Xc
  
  #ifndef __GNUC__
! #define C_OPTIMIZE_SWITCH -O3
! #define C_DEBUG_SWITCH -g
  #else
! #define C_OPTIMIZE_SWITCH -O99 -m486 -fomit-frame-pointer
! #define C_DEBUG_SWITCH -g
  #endif
  
  /* configure can't get this right linking fails unless -lsocket is used.  */
--- 79,92 ----
  #undef ADDR_CORRECT
  #define ADDR_CORRECT(x) (int)((char *)(x) - (char*)0)
  
! #define C_SWITCH_SYSTEM -D_NO_STATIC
  
  #ifndef __GNUC__
! #define C_OPTIMIZE_SWITCH -O3 -Xc
! #define C_DEBUG_SWITCH -g -Xc
  #else
! #define C_OPTIMIZE_SWITCH -O99 -m486 -fomit-frame-pointer -Xc
! #define C_DEBUG_SWITCH -g -Xc
  #endif
  
  /* configure can't get this right linking fails unless -lsocket is used.  */
***************
*** 101,107 ****
  #define NEED_PTEM_H
  
  #define START_FILES pre-crt0.o /usr/ccs/lib/crt1.o /usr/ccs/lib/values-Xc.o
! #define LIB_STANDARD -lc /usr/ccs/lib/crtn.o
  
  /* Send signals to subprocesses by "typing" signal chars at them.  */
  #define SIGNALS_VIA_CHARACTERS
--- 101,107 ----
  #define NEED_PTEM_H
  
  #define START_FILES pre-crt0.o /usr/ccs/lib/crt1.o /usr/ccs/lib/values-Xc.o
! #define LIB_STANDARD -lc
  
  /* Send signals to subprocesses by "typing" signal chars at them.  */
  #define SIGNALS_VIA_CHARACTERS
*** src/s/sco5-shr.h.orig	Thu Jun 20 21:30:56 1996
--- src/s/sco5-shr.h	Thu Jun 20 21:35:45 1996
***************
*** 4,15 ****
  
  /* XEmacs change. */
  #undef LINKER
! #undef C_SWITCH_SYSTEM
  
  #ifndef __GNUC__
  #define LINKER cc -dy -Xc
! #define C_SWITCH_SYSTEM -D_NO_STATIC -Xc -dy
  #else
  #define LINKER gcc -melf -Xc
! #define C_SWITCH_SYSTEM -D_NO_STATIC -Xc -melf
  #endif
--- 4,19 ----
  
  /* XEmacs change. */
  #undef LINKER
! #undef C_OPTIMIZE_SWITCH
! #undef C_DEBUG_SWITCH
  
  #ifndef __GNUC__
  #define LINKER cc -dy -Xc
! #define C_OPTIMIZE_SWITCH -O3 -Xc -dy
! #define C_DEBUG_SWITCH -g -Xc -dy
  #else
  #define LINKER gcc -melf -Xc
! #define C_OPTIMIZE_SWITCH -O99 -m486 -fomit-frame-pointer -Xc -melf
! #define C_DEBUG_SWITCH -g -Xc -melf
  #endif
+ 


From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 16:48:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA12902 for xemacs-beta-people; Thu, 20 Jun 1996 16:48:36 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA12899 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 16:48:34 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA01317 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 16:48:30 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id RAA03477 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 17:48:25 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp003426; Thu Jun 20 17:47:43 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA07712; Thu, 20 Jun 96 17:47:42 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA15969; Thu, 20 Jun 96 17:47:41 EDT
Message-Id: <9606202147.AA15969@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: The joke that kills.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: New PCL-CVS `feature'?
Date: Thu, 20 Jun 1996 17:47:39 -0400
Sender: rickc@lehman.com

-----BEGIN PGP SIGNED MESSAGE-----

In 19.13, cvs-update only shows entries for subdirectories containing
interesting files, i. e. modifications, updates, unknowns.

In 19.14-b26, cvs-update shows entries for every subdirectory.

Is this a bug or a feature, i. e. is this the intended behavior?  If
so, is there any way for me to restore the old behavior?  Could the
change be related to the fact that I'm not using the most up-to-date
version of cvs?  Currently, I'm using CVS version 1.6, patch level 2.

			Rick

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMcnG1FtTztlqB385AQGyTgP/XYWlH5rCApCfq4zOazRHIf+xA1xe8B67
maMCuAq6V21awA51k6rjVdzRdbtqQqYligFcTEjnWR1k3on/UwXx0no9Pu1ketDF
suT4/o00IUISsLCQDHRrJzwYX+881MPTe6Lel0D9t2KUN/3HnnBTGbu7WMn/Crjx
RBMHleLksc4=
=/ARu
-----END PGP SIGNATURE-----
--
Rick Campbell <campbell@c2.org>
  http://www.c2.org/~campbell/

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 17:10:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA13030 for xemacs-beta-people; Thu, 20 Jun 1996 17:10:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA13027 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 17:10:28 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA01291 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 17:10:28 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id PAA01995; Thu, 20 Jun 1996 15:09:41 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: core dump from balloon-help
References: <31C7169C.28C@nrs.dowjones.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: wkirk's message of Tue, 18 Jun 1996 15:50:36 -0500
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Jun 1996 15:09:39 -0700
Message-ID: <m2spbq86vw.fsf@deanna.miranova.com>
Lines: 49
X-Mailer: Gnus v5.2.23/XEmacs 19.14

>>>>> "wkirk" == wkirk  <wkirk@wsj.dowjones.com> writes:

wkirk> On Linux-1.2.13 running XEmacs 19.14b26 (compiled with gcc -O -g -m486)
wkirk> Running balloon-help (M-x load-library balloon-help) from a fresh emacs.
wkirk> % xrdb -load /dev/null
wkirk> % xemacs -q
wkirk> Positioning the cursor over a toolbar icon causes a window to appear
wkirk> for about a tenth of a second before it disappears.  Exiting emacs
wkirk> results in the following wonderful core dump with backtrace

Duplicated on Linux 2.0.0

wkirk> gdb backtrace:

wkirk> #0  0x501806ba in LINES ()
wkirk> #1  0x501ee404 in LINES ()
wkirk> #2  0x8026a42 in fatal_error_signal (sig=11) at emacs.c:193
wkirk> #3  0xbffff27c in LINES ()
wkirk> #4  0x50084add in LINES ()
wkirk> #5  0x50084add in LINES ()
wkirk> #6  0x50084add in LINES ()
wkirk> #7  0x50084add in LINES ()
wkirk> #8  0x50084add in LINES ()
wkirk> #9  0x50084cd4 in LINES ()

I get something a little different at the beginning, but the rest of
the backtrace I got is as above.

#0  0x401df741 in __kill ()
#1  0x807eba5 in fatal_error_signal (sig=11) at emacs.c:193
#2  0xbffff4bc in __ypbindlist ()
#3  0x400b0add in CallGetValuesHook ()
#4  0x400b0add in CallGetValuesHook ()
#5  0x400b0add in CallGetValuesHook ()
#6  0x400b0add in CallGetValuesHook ()
#7  0x400b0cd4 in XtGetValues ()
#8  0x8153ce3 in x_get_frame_parent (f=0x84cfd00) at frame-x.c:1772  <=
#9  0x80c2104 in delete_frame_internal (f=0x84cfd00, force=1, 

I also found the tracking to be odd.  Once the balloon comes up the
it will track with the mouse so long as the mouse moves very slowly or
very quickly.  I found an intermediate speed where the balloon would
stop, and not ``catch up'' until the mouse had stopped.  It was tricky
and took some fiddling to duplicate, but is definitely repeatable.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 17:19:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA13088 for xemacs-beta-people; Thu, 20 Jun 1996 17:19:38 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA13085 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 17:19:37 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA02293 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 17:19:38 -0500 (CDT)
Message-Id: <199606202219.RAA02293@a.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA102289182; Thu, 20 Jun 1996 23:19:43 +0100
Date: Thu, 20 Jun 1996 23:19:43 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@cs.uiuc.edu
Subject: Bad interaction: gnus/bbdb.
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



Just tried to forward an article to someone, and when I tried to
complete his email address, completion proposed me with a set of lisp
functions... 

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 18:21:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA13296 for xemacs-beta-people; Thu, 20 Jun 1996 18:21:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA13293 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 18:21:37 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA01771 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 18:21:35 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id RAA23511; Thu, 20 Jun 1996 17:20:44 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id RAA15156; Thu, 20 Jun 1996 17:20:43 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id RAA00708; Thu, 20 Jun 1996 17:20:24 -0600
Date: Thu, 20 Jun 1996 17:20:24 -0600
Message-Id: <199606202320.RAA00708@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: rickc@lehman.com
Cc: xemacs-beta@xemacs.org
Subject: Re: New PCL-CVS `feature'?
In-Reply-To: <9606202147.AA15969@cfdevx1.lehman.com>
References: <9606202147.AA15969@cfdevx1.lehman.com>
Reply-To: turner@lanl.gov

Rick Campbell writes:

 > In 19.13, cvs-update only shows entries for subdirectories containing
 > interesting files, i. e. modifications, updates, unknowns.
 > 
 > In 19.14-b26, cvs-update shows entries for every subdirectory.
 > 
 > Is this a bug or a feature, i. e. is this the intended behavior?  If
 > so, is there any way for me to restore the old behavior?  Could the
 > change be related to the fact that I'm not using the most up-to-date
 > version of cvs?  Currently, I'm using CVS version 1.6, patch level 2.

I'm not seeing this.  You sure you're getting pcl-cvs from XEmacs and
not from the 1.6 dist or something?  Did it just start happening?

(I'm using CVS 1.7, but I'm using the XEmacs pcl-cvs rather than the
one that came with 1.7.)

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 21:01:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA13656 for xemacs-beta-people; Thu, 20 Jun 1996 21:01:50 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA13653 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 21:01:49 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA11119 for <xemacs-beta@cs.uiuc.edu>; Thu, 20 Jun 1996 21:01:51 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA06703; Thu, 20 Jun 1996 19:01:05 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: b26 on UnixWare 2.1
References: <199606201406.OAA02344@zero-gravity.netlab.london.sco.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: dave edmondson's message of Thu, 20 Jun 1996 14:06:14 GMT
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Jun 1996 19:01:03 -0700
Message-ID: <m23f3pq5k0.fsf@deanna.miranova.com>
Lines: 13
X-Mailer: Gnus v5.2.23/XEmacs 19.14

>>>>> "dave" == dave edmondson <davided@sco.com> writes:

dave> kudos to the relevant people for gnus splash screen - it blew me
dave> away !

The artist's name is Luis Fernandes <elf@mailhost.ee.ryerson.ca>.  He
also did the icons for the toolbars.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 21:50:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA13769 for xemacs-beta-people; Thu, 20 Jun 1996 21:50:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA13766 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 21:49:59 -0500 (CDT)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA05311 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 21:49:57 -0500 (CDT)
Received: from drich-pc.cisco.com (dhcp-h21-207.cisco.com [171.68.192.207]) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id TAA03379 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 19:48:09 -0700
Message-Id: <2.2.32.19960621024951.00b8485c@diablo.cisco.com>
X-Sender: drich@diablo.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 20 Jun 1996 19:49:51 -0700
To: xemacs-beta@xemacs.org
From: Dan Rich <drich@cisco.com>
Subject: 19.14b26 *really* broken on my system

Ok, I've brought this up several times now, and heard no responses; in
addition I hqve a new problem (that may have gone by already).

On SunOS 4.1.3_U1 with X11R6, I'm seeing a really strange problem.  Whenever
I minimize a frame, and then maximize it again, I don't get any display
updates in that frame.  The only way I have found to get the redisplay
working again is to start a new frame and then delete it.  The original
frame will then update, and will work fine until I minimize it again.  Is
anyone else seeing this?!?!?!

As for my second problem, I decided to give GNUS a try this afternoon.
Everything worked fine until I tried to exit, and then it gave me "Attempt
to delete the sole visible or iconified frame".  Now, I have two other
frames, they are just iconified right now.  I could have sworn that this
used to work....

Dan Rich <drich@cisco.com>    | http://reality.sgi.com/employees/drich/
Webmaster                     | "Danger, you haven't seen the last of me!"
Cisco Systems, Inc.           |   "No, but the first of you turns my stomach!"
(408) 527-3195                |           -- The Firesign Theatre's Nick Danger


From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 21:58:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA13779 for xemacs-beta-people; Thu, 20 Jun 1996 21:58:29 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA13776 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 21:58:28 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA05393 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 21:58:26 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA08801; Thu, 20 Jun 1996 21:58:25 -0500 (CDT)
Message-Id: <199606210258.VAA08801@charles.cs.uiuc.edu>
To: Dan Rich <drich@cisco.com>
cc: xemacs-beta@xemacs.org
Subject: Re: 19.14b26 *really* broken on my system 
In-reply-to: Your message of "Thu, 20 Jun 1996 19:49:51 PDT."
             <2.2.32.19960621024951.00b8485c@diablo.cisco.com> 
Date: Thu, 20 Jun 1996 21:58:24 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Dan> On SunOS 4.1.3_U1 with X11R6, I'm seeing a really strange
    Dan> problem.  Whenever I minimize a frame, and then maximize it
    Dan> again, I don't get any display updates in that frame.  The
    Dan> only way I have found to get the redisplay working again is
    Dan> to start a new frame and then delete it.  The original frame
    Dan> will then update, and will work fine until I minimize it
    Dan> again.  Is anyone else seeing this?!?!?!

No one has reported anything this serious, though some have seen this
occasionally.  I have seen something similar myself but only upon
startup when I change virtual desktops before XEmacs is fully
initialized.  Iconifying and uniconifying has always fixed it for
good.


    Dan> As for my second problem, I decided to give GNUS a try this
    Dan> afternoon.  Everything worked fine until I tried to exit, and
    Dan> then it gave me "Attempt to delete the sole visible or
    Dan> iconified frame".  Now, I have two other frames, they are
    Dan> just iconified right now.  I could have sworn that this used
    Dan> to work....

With p1 (packaging now) set allow-deletion-of-last-visible-frame to t
and you'll have the old behavior back.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 22:36:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA13837 for xemacs-beta-people; Thu, 20 Jun 1996 22:36:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA13834 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 22:36:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA08759 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 22:36:16 -0500 (CDT)
Message-Id: <199606210336.WAA08759@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.14 pre-release
Date: Thu, 20 Jun 1996 22:36:13 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/beta/xemacs-19.14.  Next release is the
final 19.14 distribution, out early Saturday, June 22.

If at all possible, please, please, please build the full distribution
rather than patching up.  With one possible additional patch depending
on what I here back from a query, I hope that this is pretty much
19.14 except for some updating to about.el and some text files in etc.


		     Binary Kit Volunteers Needed
		     ============================

I realize that not having the final release available until Saturday
will it difficult for many of you to build kits in time for the Sunday
release.  Don't let that stop you from volunteering.  We've never had
all of the kits available at the time the source was made available.
I'll be sending out the binary kit build instructions very shortly.
Tomorrow afternoon I'll send a message of which volunteers should
actually go ahead and build the kits.

Thanks for all the help.  You, the best testers, are as much
responsible for the success of XEmacs as anyone.


			-Chuck



-- gnus 5.2.23
-- browse-url 0.38
-- viper 2.90
-- all .elc's rebuilt
-- problem with using dired-mode-font-lock-keywords fixed
-- new variable `allow-deletion-of-last-visible-frame'
-- NEED_LIBW handled
-- glyphs-x.c should really build with older png libs now
-- balloon-help crash fixed
-- A patch for crash in multiple_change_finish_up which Lars hit.  I
   don't know if it is fully correct but it should be safe and prevent
   the crash.
-- some Unixware patches
-- some additional SCO patches

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 22:45:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA13872 for xemacs-beta-people; Thu, 20 Jun 1996 22:45:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA13869 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 22:44:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA09139 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 22:44:56 -0500 (CDT)
Message-Id: <199606210344.WAA09139@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: binary kit build instructions
Date: Thu, 20 Jun 1996 22:44:54 -0500
From: Chuck Thompson <cthomp@xemacs.org>

The optimal binary kit would be built as such:

	--with-menubars=lucid
	--with-scrollbars=lucid
	--with-dialogs=motif	if you have Motif
	--with-xpm		important - please use xpm 3.4h
	--with-xface
	--with-tooltalk		if you've got it
	--with-sound=native	if your system has it
	--with-sound=both	if you've got netaudio (else don't sweat it)
	--with-gif
	--with-png
	--with-jpeg
	--with-dbm		if you've got it

Compile with the highest level of optimization you feel comfortable
with.

If you don't have Motif then build with Athena dialogs instead.  Do
not change the menubar or scrollbar toolkit without talking to me
first.

I'm relaxing the static!, static!, static! rule somewhat.  Any
standard system library may be dynamically linked.  Any library which
might not be installed on a system MUST be statically linked.  Let me
repeat that.  ANY library which might not be installed on a system
MUST be statically linked.

Basically if a library doesn't get installed when doing the most
minimal install of the OS, or if there is quite a bit of variation
between installations of the OS (e.g. Linux) then you should be
linking statically.

Libraries which should definitely be statically linked include:

	XPM
	compface
	Motif
	JPEG
	PNG

If you use something like Athena3d, that's fine, but make sure the
thing is statically linked.

Do your builds with

	USRLOCAL=/usr/local
	CONFIG=`./config.guess`

	./configure $CONFIG			\
	  --prefix=$USRLOCAL			\
	  --bindir=$USRLOCAL/bin/$CONFIG

$USRLOCAL can be anything you want, it doesn't matter - all the pathnames
will be relative to that by the time I see them.

Use ldd or your system equivalent on all of the executables (xemacs
itself, and the lib-src executables) to verify that they are linked
the way you think they are linked.

The tar file you send me should then contain a README, and two directories:
bin/$CONFIG/ and lib/xemacs-19.14/$CONFIG/, which should contain no more
(and no less) than the following files:

	README.$CONFIG
	bin/$CONFIG/
	bin/$CONFIG/b2m
	bin/$CONFIG/ctags
	bin/$CONFIG/emacsclient
	bin/$CONFIG/etags
	bin/$CONFIG/gnuattach
	bin/$CONFIG/gnuclient
	bin/$CONFIG/gnudoit
	bin/$CONFIG/rcs-checkin
	bin/$CONFIG/xemacs symbolic link to xemacs-19.14
	bin/$CONFIG/xemacs-19.14
	lib/xemacs-19.14/$CONFIG/
	lib/xemacs-19.14/$CONFIG/DOC-19.14-XEmacs
	lib/xemacs-19.14/$CONFIG/cvtmail
	lib/xemacs-19.14/$CONFIG/digest-doc
	lib/xemacs-19.14/$CONFIG/emacsserver
	lib/xemacs-19.14/$CONFIG/fakemail
	lib/xemacs-19.14/$CONFIG/gnuserv
	lib/xemacs-19.14/$CONFIG/hexl
	lib/xemacs-19.14/$CONFIG/make-docfile
	lib/xemacs-19.14/$CONFIG/make-path
	lib/xemacs-19.14/$CONFIG/movemail
	lib/xemacs-19.14/$CONFIG/profile
	lib/xemacs-19.14/$CONFIG/rcs2log
	lib/xemacs-19.14/$CONFIG/sorted-doc
	lib/xemacs-19.14/$CONFIG/vcdiff
	lib/xemacs-19.14/$CONFIG/wakeup
	lib/xemacs-19.14/$CONFIG/yow


This is the directory setup that you will get if you just do "make install".

I am actually a little bit picky about file permissions and ownership
in this file, but don't worry too much. I repack all distributions
before I put them on the ftp site.

What follows is a sample README.$CONFIG.  Your READMEs should look
approximately like this, with appropriate query-replace results.
However, do mention anything else you think needs to be mentioned.

And of course, attempt an installation as described in the README, on a
different machine if possible.

When you're done, dump them in ftp.xemacs.org:/pub/beta/incoming/.
Please also put there the config.status file you used to build the kit.

Thanks!

------------------------------------------------------------------------------

This directory contains Solaris 2.4 executables for XEmacs 19.14.
These were compiled with Motif, XPM, X-Face, ToolTalk, PNG, GIF, JPG,
DBM, full optimization, and have system libraries dynamically linked
and all others statically linked.

Built by Chuck Thompson <cthomp@xemacs.org>

The tar file which contains these executables contains only the
executables (the architecture-dependent files.)  To use these
executables, you will also need the architecture-independent files
(the `lisp', `etc' and `info' directories.)  These files are
distributed in a seperate file (xemacs-19.14-common.tar.gz.)

HOW TO INSTALL
==============

Simply cd to the directory in which you wish to install xemacs,
and then unpack the architecture independent tar file, followed by
the architecture-dependent files for those architectures you use.

  cd /usr/local/	# or wherever you install 3rd-party software
  gzip -dc xemacs-19.14-common.tar.gz | tar -pxf -
  gzip -dc xemacs-19.14-sparc-sun-solaris2.4.tar.gz | tar -pxf -

Replace `/usr/local/' with what you like, but it probably ought not
have `xemacs' or a version number in it - that directory is expected
to be the common prefix for installed software, and xemacs-specific
subdirectories of it will be created.  The directories are arranged
in such a way that multiple versions of xemacs can peaceably coexist
under the same `/usr/local/' tree.

After unpacking, you will have a directory structure like:

  ./bin/sparc-sun-solaris2.4/xemacs-19.14*	executable
  ./lib/xemacs-19.14/lisp/			lisp library
  ./lib/xemacs-19.14/etc/			data directory
  ./lib/xemacs-19.14/info/			documentation
  ./lib/xemacs-19.14/sparc-sun-solaris2.4/	utility programs
  ./lib/xemacs/lock/				lock directory
  ./lib/xemacs/site-lisp/			local lisp code

For the executable to work, the directory layout must look pretty
much like this; the executable looks for "sibling" directories at
run-time to figure out where its lisp library is.  These constraints
on the local directory layout are necessary to avoid having to
hardcode pathnames into the executables, or require that environment
variables be set before running the executable.

It is possible to do a multi-architecture in such a way that the
executables for the various architectures are on different
partitions; in that case you must install some symbolic links so
that the directory structure appears as above from the clients.

For example, assume that $LOCAL refers to a directory which is
mounted only on machines of the same type; and $SHARED refers to
a directory which is shared among all machines.  You could set up
the directory hierarchy like this:

  $LOCAL/bin/xemacs-19.14*
  $LOCAL/lib/xemacs-19.14/sparc-sun-solaris2.4/
  $LOCAL/lib/xemacs-19.14/lisp@  ->  $SHARED/xemacs-19.14/lisp/
  $LOCAL/lib/xemacs-19.14/etc@   ->  $SHARED/xemacs-19.14/etc/
  $LOCAL/lib/xemacs-19.14/info@  ->  $SHARED/xemacs-19.14/info/
  $LOCAL/lib/xemacs@             ->  $SHARED/xemacs/

  $SHARED/xemacs-19.14/lisp/
  $SHARED/xemacs-19.14/etc/
  $SHARED/xemacs-19.14/info/
  $SHARED/xemacs/lock/
  $SHARED/xemacs/site-lisp/

That is, the various $SHARED directories contain only the
architecture-independent files, but still look like normal
installation trees, since the architecture-independent
directories have been replaced with symbolic links to the 
single $COMMON tree.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 23:31:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA13973 for xemacs-beta-people; Thu, 20 Jun 1996 23:31:29 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA13970 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 23:31:28 -0500 (CDT)
Received: from phys401.phys.pusan.ac.kr (cghan@phys401.phys.pusan.ac.kr [164.125.144.60]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA10345 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 23:31:17 -0500 (CDT)
Received: (from cghan@localhost) by phys401.phys.pusan.ac.kr (8.6.12/8.6.9) id OAA24075 for xemacs-beta@xemacs.org; Fri, 21 Jun 1996 14:26:18 +0900
Date: Fri, 21 Jun 1996 14:26:18 +0900
From: ChangGil Han <cghan@phys401.phys.pusan.ac.kr>
Message-Id: <199606210526.OAA24075@phys401.phys.pusan.ac.kr>
To: xemacs-beta@xemacs.org
Subject: success_of_19.14-p1_on_linux.2.0


Compilation of 19.14-p1: succeeded on linux.2.0 with 
  "--dynamic" option.

Configured for `i486-unknown-linux2.0.0'.

  Where should the build process find the source code?    /user2/xemacs-19.14-b26
  What installation prefix should install use?		  /user2/beta19
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


creating config.status
creating Makefile
creating lib-src/Makefile.in
creating man/Makefile.in
creating src/Makefile.in
creating lwlib/Makefile.in
creating dynodump/Makefile.in
creating src/config.h
creating src/Makefile
creating lwlib/Makefile
creating lib-src/Makefile
creating dynodump/Makefile
creating man/Makefile

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 20 23:59:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA14036 for xemacs-beta-people; Thu, 20 Jun 1996 23:59:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA14033 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 20 Jun 1996 23:59:38 -0500 (CDT)
Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA14717 for <xemacs-beta@xemacs.org>; Thu, 20 Jun 1996 23:59:35 -0500 (CDT)
X400-Received:  
 by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 21 Jun 1996 00:59:32 -0400 
X400-Received:  
 by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 21 Jun 1996 00:59:25 -0400 
X400-Received:  
 by /PRMD=bnr/ADMD=telecom.canada/C=ca/; Relayed; Fri, 21 Jun 1996 00:58:16 -0400 
X400-Received:  
 by /PRMD=bnr/ADMD=telecom.canada/C=ca/; Relayed; Fri, 21 Jun 1996 00:58:16 -0400 
Date:  Fri, 21 Jun 1996 00:58:16 -0400 
X400-Originator:  /dd.id=cnt02344/g=barry/i=bl/s=friedman/@bnr.ca 
X400-MTS-Identifier:  
 [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<9606210459.AA05376@nmerh209>] 
X400-Content-Type:  P2-1984 (2) 
Content-Identifier:  Minor nitpick 
From: "barry (b.l.) friedman" <friedman@nortel.ca>
Message-ID:  <9606210459.AA05376@nmerh209> 
To: xemacs-beta@xemacs.org
Subject:  Minor nitpick 
Reply-To: friedman@bnr.ca
X-Mailer: ELM [version 2.4.1 PL23] 
Content-Type: text 

I was just testing b26 today and for the heck of it I looked at the
options menu and spotted the selection for URL browser.  So I flipped
it to Netscape and went to find a url to try.  My first thought was
the XEmacs web page from the Help menu and sure enough, when I tried it
up came W3.  A vanilla url would did up netscape.  Is it possible to
fix this one?

-- 
Barry Friedman                          Phone: (613) 782-2389  Fax: 782-2228
Emax Computer Systems Inc.  440 Laurier Ave. W., Ottawa, Ont. Canada K1R 7X6
INTERNET: friedman@nortel.ca                                      ESN: 395-4270

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 00:56:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA14155 for xemacs-beta-people; Fri, 21 Jun 1996 00:56:53 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA14152 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 00:56:51 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA14783; Fri, 21 Jun 1996 00:56:49 -0500 (CDT)
Received: from revelle by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id XAA27676; Thu, 20 Jun 1996 23:56:51 -0600
Received: by revelle (SMI-8.6) id XAA23442; Thu, 20 Jun 1996 23:56:50 -0600
Sender: mdb@cdc.noaa.gov
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: [19.14-p1] solaris-2.5 built OK...
References: <199606210336.WAA08759@xemacs.cs.uiuc.edu>
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 20 Jun 1996 23:56:49 -0600
In-Reply-To: Chuck Thompson's message of Thu, 20 Jun 1996 22:36:13 -0500
Message-ID: <vkviglg0ny.fsf@cdc.noaa.gov>
Lines: 38
X-Mailer: Gnus v5.2.23/XEmacs 19.14

using SUN cc-4.0.

Cranked the optimization up another notch to `-xO4'; don't notice any
speed improvement over -xO3, though.

Seems OK on a TTY; will test under X11 tomorrow.

One other thing in the build process that I think was mentioned
before. The configure script generates a coredump and core file is
left. Not sure what tet generated it, or if it's normal.

Configured for `sparc-sun-solaris2.5'.

  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              cc -xO4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 01:45:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA14246 for xemacs-beta-people; Fri, 21 Jun 1996 01:45:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA14243 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 01:45:15 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA16446 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 01:45:17 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id XAA14918; Thu, 20 Jun 1996 23:44:30 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [19.14-p1] Linux 2.0 Success
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
Date: 20 Jun 1996 23:44:29 -0700
Message-ID: <m2wx11irle.fsf@deanna.miranova.com>
Lines: 37
X-Mailer: Gnus v5.2.23/XEmacs 19.14

I'm running stock Gnus, a first for me.

Everything went great during configure and build, and I am using
uptodate PNG libraries.

Configured for `i486-unknown-linux2.0.0'.

  Where should the build process find the source code?    /i/xemacs-19.14-p1
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 01:55:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA14294 for xemacs-beta-people; Fri, 21 Jun 1996 01:55:48 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA14291 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 01:55:47 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA16561 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 01:55:48 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA18150; Fri, 21 Jun 1996 08:55:18 +0200
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA18814; Fri, 21 Jun 1996 08:55:17 +0200
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@cs.uiuc.edu
Subject: Volunteering for binary kits AIX 4 and FreeBSD 2.1
References: <199606210336.WAA08759@xemacs.cs.uiuc.edu>
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 21 Jun 1996 08:55:16 +0200
In-Reply-To: Chuck Thompson's message of Thu, 20 Jun 1996 22:36:13 -0500
Message-Id: <y9lpw6t4pez.fsf@modas.informatik.uni-tuebingen.de>
Lines: 7
X-Mailer: Gnus v5.2.22/XEmacs 19.14


I can do AIX 4.1.4 and FreeBSD 2.1.0, though I'll probably only have
time for one on Sunday.  The next would be on Monday, if nobody else
volunteers for one of the two.

Cheers =8-} Mike


From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 02:48:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA14519 for xemacs-beta-people; Fri, 21 Jun 1996 02:48:37 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA14516 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 02:48:36 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA17069 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 02:48:36 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id IAA20542; Fri, 21 Jun 1996 08:49:53 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id IAA18926; Fri, 21 Jun 1996 08:49:41 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id IAA14050; Fri, 21 Jun 1996 08:53:04 +0100
Date: Fri, 21 Jun 1996 08:53:04 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606210753.IAA14050@wrath.parallax.co.uk>
To: cthomp@xemacs.org
Subject: Re: XEmacs 19.14 pre-release
Cc: xemacs-beta@cs.uiuc.edu
X-Sun-Charset: US-ASCII

> is now at ftp.xemacs.org:/pub/beta/xemacs-19.14.  Next release is the
> final 19.14 distribution, out early Saturday, June 22.
> 
> If at all possible, please, please, please build the full distribution
> rather than patching up.  With one possible additional patch depending
> on what I here back from a query, I hope that this is pretty much
> 19.14 except for some updating to about.el and some text files in etc.

Can you put a split version somewhere?

andy

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 03:20:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA18053 for xemacs-beta-people; Fri, 21 Jun 1996 03:20:46 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA18050 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 03:20:44 -0500 (CDT)
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA17381 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 03:20:39 -0500 (CDT)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0uX1Rx-00002AC>; Fri, 21 Jun 96 10:20 MET DST
Message-Id: <m0uX1Rx-00002AC@susan.logware.de>
Date: Fri, 21 Jun 96 10:20 MET DST
From: Michael Diers <mdiers@logware.de>
To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Volunteering for binary kits AIX 4 and FreeBSD 2.1
In-Reply-To: <y9lpw6t4pez.fsf@modas.informatik.uni-tuebingen.de>
References: <199606210336.WAA08759@xemacs.cs.uiuc.edu>
	<y9lpw6t4pez.fsf@modas.informatik.uni-tuebingen.de>

Michael Sperber [Mr Preprocessor] <sperber@informatik.uni-tuebingen.de> wrote:

> I can do AIX 4.1.4 and FreeBSD 2.1.0, though I'll probably only have
> time for one on Sunday.  The next would be on Monday, if nobody else
> volunteers for one of the two.

> Cheers =8-} Mike

I'll do FreeBSD 2.1.

-Michael

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 03:37:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA18096 for xemacs-beta-people; Fri, 21 Jun 1996 03:37:44 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA18093 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 03:37:31 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA17500 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 03:37:18 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Fri, 21 Jun 1996 10:30:58 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id KAA08748; Fri, 21 Jun 1996 10:30:27 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id KAA12664;
          Fri, 21 Jun 1996 10:28:55 +0200
Date: Fri, 21 Jun 1996 10:28:55 +0200
Message-Id: <199606210828.KAA12664@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de>
To: Neal Becker <Neal.Becker@comsat.com>
Cc: xemacs-beta@cs.uiuc.edu, Kyle Jones <kyle@wonderworks.com>
Subject: Re: sync VM & gnus
In-Reply-To: <E0uWloA-0004Dg-00@neal.ctd.comsat.com>
References: <E0uWloA-0004Dg-00@neal.ctd.comsat.com>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q(\V9 
        +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy 
        ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x 
        zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B: 
        s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Neal" == Neal Becker <Neal.Becker@comsat.com> writes:

    Neal> Gnus has nice uudecoding using X U.  Is this available in
    Neal> VM?  Can we put it in the 'dispose' menu?

I'm also searching for such a package for vm, but it seems, that it
doesn't exists. Does anyone kwow an uudecoding package for vm?

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 03:27:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA18066 for xemacs-beta-people; Fri, 21 Jun 1996 03:27:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA18063 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 03:27:37 -0500 (CDT)
Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA15034; Fri, 21 Jun 1996 03:27:33 -0500 (CDT)
Received: from djp-fornet.cern.ch (djp-fornet.cern.ch [137.138.36.141]) by server21.digital.fr (8.7.3/8.7) with SMTP id KAA13156; Fri, 21 Jun 1996 10:28:40 +0200 (MET DST)
Received: by djp-fornet.cern.ch; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA08453; Fri, 21 Jun 1996 10:26:05 +0200
Date: Fri, 21 Jun 1996 10:26:05 +0200
Message-Id: <9606210826.AA08453@djp-fornet.cern.ch>
From: Stephen Carney <carney@xemacs.org>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: RE: XEmacs 19.14 pre-release
In-Reply-To: <199606210336.WAA08759@xemacs.cs.uiuc.edu>
References: <199606210336.WAA08759@xemacs.cs.uiuc.edu>
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

cthomp@xemacs.org (Chuck Thompson) writes,
in <199606210336.WAA08759@xemacs.cs.uiuc.edu>:

>		     Binary Kit Volunteers Needed
>		     ============================

I volunteer to build the binary kit for Digital UNIX.

        Steve

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 03:34:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA18078 for xemacs-beta-people; Fri, 21 Jun 1996 03:34:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA18075 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 03:34:31 -0500 (CDT)
Received: from silmaril.paradigm-sa.com (root@paradigm-IS.ISnet.net [196.26.13.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA15041 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 03:34:25 -0500 (CDT)
Received: from hyperion.paradigm-sa.com by silmaril.paradigm-sa.com with smtp
	(Smail3.1.29.1 #6) id m0uX1em-0004S2C; Fri, 21 Jun 96 10:33 SAT
Date: Fri, 21 Jun 1996 10:34:45 -0200 (SAT)
From: "J. Kean Johnston" <jkj@paradigm-sa.com>
Reply-To: hug@netcom.com
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: SCO OSR5 Binary Distrib
Message-ID: <Pine.SCO5.3.93.960621103018.28741A-100000@hyperion.paradigm-sa.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I will do a binary distribution for SCO OSR5. I do however have two
questions:

a) The dynamic libraries. If the binary distribution itself contains the
   actual .so's, whats the real issue? The binary will still work.
b) Why have stuff in $LOCAL/bin/$CONFIG only? I can see the support
   queries and a million questions to the list that the binary could not
   be found. Most people have /usr/local/bin in their path. But
   /usr/local/bin/i486-sco3.2v5.0 is highly non standard. Perhaps the
   README should make this point VERY clear, that the binary needs to be
   linked into somewhere on the user's PATH. Not everyone that pulls down
   the binary distribution will have a brain. You can save yourself a
   lot of support questions.

flames > /dev/null

JKJ


From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 04:04:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA18247 for xemacs-beta-people; Fri, 21 Jun 1996 04:04:11 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA18244 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 04:04:10 -0500 (CDT)
Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA15072 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 04:04:06 -0500 (CDT)
Received: from djp-fornet.cern.ch (djp-fornet.cern.ch [137.138.36.141]) by server21.digital.fr (8.7.3/8.7) with SMTP id LAA31302 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 11:04:45 +0200 (MET DST)
Received: by djp-fornet.cern.ch; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA15715; Fri, 21 Jun 1996 11:02:21 +0200
Date: Fri, 21 Jun 1996 11:02:21 +0200
Message-Id: <9606210902.AA15715@djp-fornet.cern.ch>
From: Stephen Carney <carney@xemacs.org>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.14-p1 build success on Digital UNIX V3.2D
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

Flawless build, not a single warning.

        Steve


Hardware  : DEC 3000-500
OS        : Digital UNIX V3.2D (41)
Compiler  : gcc-2.7.2
Libraries : X11R5, Motif, XAUTH, XPM, X-Face, DBM, GIF
XEmacs    : 19.14-p1 (full kit)

Configured for `alpha-dec-osf3.2'.
  Where should the build process find the source code?    /kits/install/xemacs/beta
  What installation prefix should install use?            /usr/local/xemacs-beta
  What operating system and machine description files should XEmacs use?
        `s/decosf3-2.h' and `m/alpha.h'
  What compiler should XEmacs be built with?              gcc -g2 -O3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? no
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 04:15:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA18325 for xemacs-beta-people; Fri, 21 Jun 1996 04:15:28 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA18322 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 04:15:27 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA17814 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 04:15:17 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA17387; Fri, 21 Jun 1996 11:15:12 +0200
Received: from loopback by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA20610; Fri, 21 Jun 1996 11:15:10 +0200
Message-Id: <9606210915.AA20610@modas.informatik.uni-tuebingen.de>
To: xemacs-beta@cs.uiuc.edu
Subject: p1 success on AIX 4.1.4
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 21 Jun 1996 11:15:09 +0200
From: "Michael Sperber [Mr. Preprocessor]" <sperber@informatik.uni-tuebingen.de>


gcc 2.7.2 -O -g, xpm, jpeg.

No problems so far.

Cheers =8-} Mike

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 04:15:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA18320 for xemacs-beta-people; Fri, 21 Jun 1996 04:15:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA18317 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 04:15:25 -0500 (CDT)
Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA15084 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 04:15:22 -0500 (CDT)
Received: from djp-fornet.cern.ch (djp-fornet.cern.ch [137.138.36.141]) by server21.digital.fr (8.7.3/8.7) with SMTP id LAA26877 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 11:16:30 +0200 (MET DST)
Received: by djp-fornet.cern.ch; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA15810; Fri, 21 Jun 1996 11:13:59 +0200
Date: Fri, 21 Jun 1996 11:13:59 +0200
Message-Id: <9606210913.AA15810@djp-fornet.cern.ch>
From: Stephen Carney <carney@xemacs.org>
To: xemacs-beta@xemacs.org
Subject: VM frames don't go away
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

After doing C-c C-c to send or reply to mail in a VM composition frame,
the mail is sent but the frame is not removed.  The menubar is blanked
out, but the toolbar and modeline remain untouched.  If the frame is
iconized, then deiconized, all that comes back is the frame title.
Similarly, if part of the frame becomes occluded, then is re-exposed,
the re-exposed portion remains blank.

I've done `make all-elc' and even restored the pre-fab elc kit.  Neither
changes the behavior.


        Steve

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 05:25:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA18572 for xemacs-beta-people; Fri, 21 Jun 1996 05:25:18 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA18569 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 05:25:17 -0500 (CDT)
Received: from netcom2.netcom.com (root@netcom2.netcom.com [192.100.81.108]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA15110 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 05:25:13 -0500 (CDT)
Received: from netcom19.netcom.com (wing@netcom19.netcom.com [192.100.81.132]) by netcom2.netcom.com (8.6.13/Netcom)
	id DAA28113; Fri, 21 Jun 1996 03:25:16 -0700
Date: Fri, 21 Jun 1996 03:25:16 -0700
Message-Id: <199606211025.DAA28113@netcom2.netcom.com>
From: wing@666.com (Ben Wing)
To: cthomp@xemacs.org, xemacs-beta@xemacs.org
Subject: Re:  binary kit build instructions

I've got a few additional suggestions:

>Compile with the highest level of optimization you feel comfortable
>with.

Also make sure *NOT* to strip the binary.  A stack backtrace should
at least show the names of the functions on the stack (the default
behavior without -g, I think).

>Basically if a library doesn't get installed when doing the most
>minimal install of the OS, or if there is quite a bit of variation
>between installations of the OS (e.g. Linux) then you should be
>linking statically.
>
>Libraries which should definitely be statically linked include:
>
>	XPM
>	compface
>	Motif
>	JPEG
>	PNG

Given the size of Motif, I'd almost think it useful to have two
binaries -- one statically linked with Motif, the other dynamically
linked with Motif.  This is how the Linux Java JDK is distributed,
for example.

Also, ncurses and the db libraries should probably be statically linked.

Also, if you do link dynamically, try VERY VERY hard to link against
the oldest possible versions of the libraries.

Also, on Linux, I would strongly consider statically linking with
libc and libm, although dynamically linking with the standard X libraries
is probably OK.  Remember the _h_errno SNAFU in 19.13.

ben

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 05:45:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA18621 for xemacs-beta-people; Fri, 21 Jun 1996 05:45:47 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA18618 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 05:45:46 -0500 (CDT)
Received: from zero-gravity.netlab.london.sco.com (zero-gravity.netlab.london.sco.com [150.126.252.16]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA15130 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 05:45:42 -0500 (CDT)
Received: (from davided@localhost) by zero-gravity.netlab.london.sco.com (8.6.10/dme/nice-1.1) id KAA00533; Fri, 21 Jun 1996 10:38:58 GMT
Date: Fri, 21 Jun 1996 10:38:58 GMT
Message-Id: <199606211038.KAA00533@zero-gravity.netlab.london.sco.com>
To: carney@gvc.dec.com
Cc: xemacs-beta@xemacs.org
Subject: re: XEmacs 19.14-p1 build success on Digital UNIX V3.2D
In-Reply-To: <9606210902.AA15715@djp-fornet.cern.ch>
References: <9606210902.AA15715@djp-fornet.cern.ch>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: dave edmondson <davided@sco.com>
X-Face: "?v.huY]?B[a4C|xid!Tx8TpwOQe6]C(I}h8Vo1z6'9soM_Xvq2f3u::[F~rW>GWj6;IfU,10H;B&1JDE/H8?``q4XH4~!\_z{n3RDmkC;9d!Yx3O7n?9,[CE;TWB!
	F8.e5fc0dJXikU'v1qFVTfptB7xe$y*t#jx4`I44n,ypMQg@.|Z^ycJ:G]{dR~E}_.T1^shwC%T4eRGVu%h+J7lBzb>m20==Q*OPAf^~@6Lj^)rI9Tb*m*L}}HC~{>
	/__Od\I=[|aP6s}B%BhqtE-9uGJ0J3jchjcyJz5fW[i0$RfPv7Zp=!a+0pR

: Flawless build, not a single warning.

do you mean `_no_ warnings from the compiler' ?  on uw2.1 there are
lots, and deciding whether or not to look into them would be
interesting...

dave.
---
  ``My sweater is on backwards and inside out'' -- Alanis Morissette

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 05:59:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA18635 for xemacs-beta-people; Fri, 21 Jun 1996 05:59:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA18632 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 05:59:55 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA15136 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 05:59:46 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id GAA19526; Fri, 21 Jun 1996 06:59:20 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp019514; Fri Jun 21 06:59:02 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA26894; Fri, 21 Jun 96 06:59:01 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA04126; Fri, 21 Jun 96 06:58:59 EDT
Message-Id: <9606211058.AA04126@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Don't get frustrated without it.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: New PCL-CVS `feature'? 
In-Reply-To: Your message of "Thu, 20 Jun 1996 17:20:24 MDT."
             <199606202320.RAA00708@gielgud.lanl.gov.xdiv> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMcqAZ1tTztlqB385AQGvBwQAmFZG0XZ7DcWq4lmrU1BmVLfmCnngYzfS
	      r1uLN798NXDaxc8xizsYteM8dsIH8QZ0rQYfehj8PnnRRF9TOtqzGJiAQMNv2iH2
	      W+Mqrc9qnan3RKCqCtXPcngB+P9dRqezYEuH3r1WvgqRoghntrkCXG0oD3zeoz0b
	      I0Q0NKxdhVk=
	      =azNm
Date: Fri, 21 Jun 1996 06:58:56 -0400
Sender: rickc@lehman.com

    Date: Thu, 20 Jun 1996 17:20:24 -0600
    From: John Turner <turner@xdiv.LANL.GOV>
    
    Rick Campbell writes:
    
     > In 19.14-b26, cvs-update shows entries for every subdirectory.

    I'm not seeing this.  You sure you're getting pcl-cvs from XEmacs and
    not from the 1.6 dist or something?

Reasonably sure.  I can repeat it by starting b26 with the -q switch,
evaluating one form in *scratch*:
 (setq cvs-program "/home/fiasal/bin/cvs")

and then doing M-x cvs-update.  In particular, I'm not doing anything
to tell XEmacs where a rogue pcl-cvs version might live.  I'll enclose
a logs.tar.gz.uu (only 26 lines) which includes the output from a
19.13 run and a 19.14-b26 run at the end of this message.

  Did it just start happening?

This is the first beta that I've built in a while -- definitely the
first one since I saw that PCL-CVS was updated.

			Rick

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

begin 664 logs.tar.gz
M'XL( -A_RC$  ^U7SV_;-A1F.S0;/*#(AAXZ8$#?H8<-B"7+/Y&TE\'H8< Z
M!%@ZY#90%&5QIDF5I.+Z/]AA_]5VVF7_P+#3+KL/V'6/BKLFL1,I@5-WF![B
MR/KXO?>H9Y'\WO&S&66V'>T'42^0>D)NP0!@..P#7@?]:(C7J-^/.OZ^M%XG
M&B C&G;[HU%WU//TP:A+X#;FTMAY.QQ_U1Y_^PT8+CFU'**@,P@ QCI?&#')
M''PV_ARB_?WNGO_?@T-N8,P3;EZ>".M:ATRVV8D%IF?<PERX#&ALM2P<EPM0
M&N;4&*K<X@FDVD#"'172TY4MI .7<9A155 9M(XR80'_4L,Y6)TZ=.5[0%4"
M"UT WL"<2Y\(G,;Y)IC?B!@S@7!0*)P3,&XP@6IA_$0X@5F> )T@LG<NY1$_
M%BK5R]1G9Q:T6E\J2(3AS&FS@###?*$1;,I"2^5!"^"Y3D0J> ),P',ZY:F0
M_&JO$'.G8G+1N1P/9M,*9_Z*SG+);>@*'!>(1#><QFJD[L8B]386J;^Q2(,;
M1LJ<RT,FJ;7<WC"$4$P6";_RG0'X(DD00T.84<F"[ *8\)QI*4O\; S$A3I9
M!SM#V70ECIKRA:-QP-@E Q<C69?H^/N5.,ZY==A4KP1PBYRO@"=EM4YGL0;/
M*HIJ#<.E9/AU*KKRQ*]+NC*)94W7X:=%+4=>J*G2<U4>7%+8_*I"GRMH^7*N
MP<_6Y&*IUX%8ZW5P?@FZ]G=!:OM?@V>XPY;?6ML^C+9BG6U/8*MV_$;_]=MQ
M=W@;&K!"_PT&G<X;_=<=(33"FT;_O0U;I_]0@ND9G$4??TUG_ #@<=!JE.$[
MHPQ/G4.=E\]S4,%.-*NBO)90=7FA/V(=M^X:#C9+I9[7=DB-?_/JLC,NI:[-
MQAN;<_:=BVM7)KP6=RE$K^W0*/RWH/"K?I4-= %E"#&CD^HEM6P8:M*:OF*3
M?<69HH9U=C,\'&I0_">JR>O5Y VJ>-@BU:#4WH;?I8X+9_F?[KBJ*YT*Y0O]
M(D^H.XT),<J5>LX3KFSU4>.94L0UF7B5HG)/6C+]45J36KG"/*_.2O2\PHE:
M#^-YN(:F*%%SKI+:+I89D3O<P"]IF>_]0<C]G\@#LA,D\2O#R ^(_47N_OP;
M8N\O]Q94VCN$W'GY)]DE=R>:O(?W#PCYZ&_RD'P8Y),\R(M8"N9Y>X0\^@7Q
M#P):Q%[CH8_G/R5W/OG5Y[&.NL)Z];YS1,CN[^13<C_(=&%LX+6LEKSDYX1\
M? ^[J-W BHE"%\,#+9,@6L;[$<=WMMM]--988]NTIO]O^O^F____]O__ "8K
&; 8 (   
 
end

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 06:06:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA18650 for xemacs-beta-people; Fri, 21 Jun 1996 06:06:33 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA18647 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 06:06:33 -0500 (CDT)
Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA15146 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 06:06:29 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA27861; Fri, 21 Jun 1996 04:01:00 -0700
Received: by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA27698; Fri, 21 Jun 1996 13:00:44 +0200
Date: Fri, 21 Jun 1996 13:00:44 +0200
From: Steve Carney <carney@gvc.dec.com>
Message-Id: <9606211100.AA27698@clusaz.gvc.dec.com>
To: dave edmondson <davided@sco.com>
Cc: carney@gvc.dec.com, xemacs-beta@xemacs.org
Subject: re: XEmacs 19.14-p1 build success on Digital UNIX V3.2D
In-Reply-To: <199606211038.KAA00533@zero-gravity.netlab.london.sco.com>
References: <9606210902.AA15715@djp-fornet.cern.ch>
	<199606211038.KAA00533@zero-gravity.netlab.london.sco.com>
Reply-To: carney@gvc.dec.com

davided@sco.com (dave edmondson) writes,
in <199606211038.KAA00533@zero-gravity.netlab.london.sco.com>:

>: Flawless build, not a single warning.
>do you mean `_no_ warnings from the compiler' ?  on uw2.1 there are
>lots, and deciding whether or not to look into them would be
>interesting...

Not a single gcc compiler warning -- definite warm & fuzzies.  The code
is getting better, or gcc isn't picky.  I've had reasonably clean builds
with DEC C also.  Since 14b19, however, I've run into a DEC C
optimization problem with sticky highlighting that I haven't isolated.

Many of the warnings I've seen have been casting ints to ptrs (bad on a
64-bit machine).

        Steve


From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 06:42:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA18789 for xemacs-beta-people; Fri, 21 Jun 1996 06:42:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA18786 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 06:42:50 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA20839 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 06:42:51 -0500 (CDT)
Message-Id: <199606211142.GAA20839@a.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA103975679; Fri, 21 Jun 1996 12:14:39 +0100
Date: Fri, 21 Jun 1996 12:14:39 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@cs.uiuc.edu
Subject: binary kits.
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



I can make the folowing kits:

hppa1.1-hp-hpux9.05
hppa1.0-hp-hpux10.01
hppa1.1-hp-hpux10.10 (not too sure the 3 are needed).

mips-sgi-irix5.3
mips-sgi-irix6.2 (provided the machine is reconnected).

I unfortunately can't seem to ftp anywhere at the moment... Still
trying...

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 07:00:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA18819 for xemacs-beta-people; Fri, 21 Jun 1996 07:00:09 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA18816 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 07:00:08 -0500 (CDT)
Received: from silmaril.paradigm-sa.com (root@paradigm-IS.ISnet.net [196.26.13.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA15191 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 06:59:46 -0500 (CDT)
Received: from hyperion.paradigm-sa.com by silmaril.paradigm-sa.com with smtp
	(Smail3.1.29.1 #6) id m0uX4r7-0003emC; Fri, 21 Jun 96 13:58 SAT
Date: Fri, 21 Jun 1996 13:59:42 -0200 (SAT)
From: "J. Kean Johnston" <jkj@paradigm-sa.com>
Reply-To: hug@netcom.com
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Suggestions for documentation
Message-ID: <Pine.SCO5.3.93.960621125202.3479A-100000@hyperion.paradigm-sa.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

In the README file or some other suitable place, it would be useful if
you told users what packages can be used to extend XEmacs, and where to
get them. For example, point people to the homes of Xpm, JPEG, PNG etc.
I know I battled to find all of the 'official' homes of these packages to
make sure I had the latest version. This will be a small change and should
prolly make it in for the final release.

I know they are on the XEmacs site, but many users (especially if they
were compiled with -pedantic like me) like to get the latest and greatest
from the official homes. At the very least tell people WHERE on the XEmacs
site to find them. 'aux' was the last place I looked becuase to me that
means Apple UNIX.

If it helps, here is where things are kept:
JPEG : ftp://ftp.uu.net/graphics/jpeg
XPM  : ftp://ftp.x.org/contrib/libraries
TIFF : ftp://ftp.sgi.com/graphics/tiff
PNG  : ftp://ftp.uu.net/graphics/png
XFACE: ???
NAS  : ftp://ftp.x.org/contrib/audio/nas

JKJ


From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 07:54:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA19049 for xemacs-beta-people; Fri, 21 Jun 1996 07:54:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA19046 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 07:54:25 -0500 (CDT)
Received: from gate.instrumatic.ch (root@gate.instrumatic.ch [194.206.238.129]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA15220; Fri, 21 Jun 1996 07:53:17 -0500 (CDT)
Received: from neon-tetra.instrumatic.ch by gate.instrumatic.ch (5.x/SMI-SVR4)
	id AA22887; Fri, 21 Jun 1996 14:52:56 +0200
Received: (from simon@localhost) by neon-tetra.instrumatic.ch (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA05180; Fri, 21 Jun 1996 14:52:33 +0200
Date: Fri, 21 Jun 1996 14:52:33 +0200
Message-Id: <199606211252.OAA05180@neon-tetra.instrumatic.ch>
From: Simon Leinen <simon@instrumatic.ch>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: XEmacs 19.14 pre-release
In-Reply-To: <199606210336.WAA08759@xemacs.cs.uiuc.edu>
References: <199606210336.WAA08759@xemacs.cs.uiuc.edu>

The pre-release files are now on liaftp.epfl.ch:/pub/gnu/xemacs/beta

Hope this helps,
-- 
Simon.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 08:13:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA19123 for xemacs-beta-people; Fri, 21 Jun 1996 08:13:17 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA19120 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 08:13:16 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA15244 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 08:13:14 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA09843; Fri, 21 Jun 1996 08:13:12 -0500 (CDT)
Message-Id: <199606211313.IAA09843@charles.cs.uiuc.edu>
To: hug@netcom.com
cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: SCO OSR5 Binary Distrib 
In-reply-to: Your message of "Sat, 21 Jun 1996 10:34:45 -0200."
             <Pine.SCO5.3.93.960621103018.28741A-100000@hyperion.paradigm-sa.com> 
Date: Fri, 21 Jun 1996 08:13:12 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Kean> a) The dynamic libraries. If the binary distribution itself
    Kean>    contains the actual .so's, whats the real issue? The
    Kean>    binary will still work.

The binary distributions do not include the actual .so's and I'm not
willing to change that at the moment.  I can name lots of ways doing
so will generate lots of FAQ traffic.  The standard party line
remains, if you want a fully dynamically linked binary, build it
yourself.


    Kean> b) Why have stuff in $LOCAL/bin/$CONFIG only? I can see the
    Kean>    support queries and a million questions to the list that
    Kean>    the binary could not be found. Most people have
    Kean>    /usr/local/bin in their path. But
    Kean>    /usr/local/bin/i486-sco3.2v5.0 is highly non
    Kean>    standard.

The reason for the chosen location is that it makes it much easier to
create a multi-architecture installation using just binary kits.  I
can see how you would think that this would generate lots of questions
but reality is that this is how XEmacs / Lucid Emacs has always been
distributed and it has generated hardly any comments.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 08:29:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA19172 for xemacs-beta-people; Fri, 21 Jun 1996 08:29:29 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA19169 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 08:29:28 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA15276 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 08:29:26 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.6.12/8.6.9) with ESMTP id IAA20721; Fri, 21 Jun 1996 08:29:04 -0500
Message-Id: <199606211329.IAA20721@nvwls.cc.purdue.edu>
To: hug@netcom.com
cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: Suggestions for documentation 
In-reply-to: Your message of "Sat, 21 Jun 1996 13:59:42 -0200."
             <Pine.SCO5.3.93.960621125202.3479A-100000@hyperion.paradigm-sa.com> 
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 21 Jun 1996 08:29:01 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


>>>>> "JKJ" == J Kean Johnston <jkj@paradigm-sa.com> writes:

    JKJ> If it helps, here is where things are kept:
    JKJ> XFACE: ???

XFACE: ftp://ftp.cs.indiana.edu/pub/faces/compface

--
Joseph J. Nuspl Jr.
Purdue Data Network

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 08:16:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA19139 for xemacs-beta-people; Fri, 21 Jun 1996 08:16:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA19136 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 08:16:20 -0500 (CDT)
Received: from silmaril.paradigm-sa.com (root@paradigm-IS.ISnet.net [196.26.13.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA15247 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 08:16:14 -0500 (CDT)
Received: from hyperion.paradigm-sa.com by silmaril.paradigm-sa.com with smtp
	(Smail3.1.29.1 #6) id m0uX63T-00038OC; Fri, 21 Jun 96 15:15 SAT
Date: Fri, 21 Jun 1996 15:16:32 -0200 (SAT)
From: "J. Kean Johnston" <jkj@paradigm-sa.com>
Reply-To: hug@netcom.com
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Qualified success on SCO OSR5
Message-ID: <Pine.SCO5.3.93.960621150234.9310A-100000@hyperion.paradigm-sa.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Configured for `i486-unknown-sco3.2v5.0'.

  Where should the build process find the source code?    /u/tmp/xemacs-19.14-p1
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sco5-shr.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc  -g -Xc -melf -O99 -m486 -fomit-frame-pointer -Xc -melf 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in network sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

All working nicely, but I had to modify the generated makefile for two
reasons:
a) To make sure the extra libraries were statically linked
b) When the src/Makefile is generated, it does not seem to use the flags
   as would be computed for a compile. In this case, the -melf to GCC
   sets a manifest _SCO_ELF, which affects things like unexelf.o or
   unexec.o. Because the computed flags (as reported above) were not
   used when the makefile was generated, it got some stuff wrong. The
   patch belo fixes this.

There is an easy solution to this but it will cause (AGAIN) configure
to produce warnings when it generates the files. This is tiresome in
the extreme. To fix this, please put in this tiny patch:

*** src/s/sco5-shr.h.orig	Fri Jun 21 15:09:38 1996
--- src/s/sco5-shr.h	Fri Jun 21 15:09:43 1996
***************
*** 6,11 ****
--- 6,13 ----
  #undef LINKER
  #undef C_OPTIMIZE_SWITCH
  #undef C_DEBUG_SWITCH
+ #undef C_SWITCH_SYSTEM
+ #define C_SWITCH_SYSTEM -D_NO_STATIC -D_SCO_ELF
  
  #ifndef __GNUC__
  #define LINKER cc -dy -Xc


From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 08:24:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA19156 for xemacs-beta-people; Fri, 21 Jun 1996 08:24:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA19153 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 08:24:43 -0500 (CDT)
Received: from zero-gravity.netlab.london.sco.com (zero-gravity.netlab.london.sco.com [150.126.252.16]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA15268 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 08:24:38 -0500 (CDT)
Received: (from davided@localhost) by zero-gravity.netlab.london.sco.com (8.6.10/dme/nice-1.1) id NAA12218; Fri, 21 Jun 1996 13:19:48 GMT
Date: Fri, 21 Jun 1996 13:19:48 GMT
Message-Id: <199606211319.NAA12218@zero-gravity.netlab.london.sco.com>
To: xemacs-beta@xemacs.org
Subject: 19.15-p1 on UnixWare 2.1
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: dave edmondson <davided@sco.com>
X-Face: "?v.huY]?B[a4C|xid!Tx8TpwOQe6]C(I}h8Vo1z6'9soM_Xvq2f3u::[F~rW>GWj6;IfU,10H;B&1JDE/H8?``q4XH4~!\_z{n3RDmkC;9d!Yx3O7n?9,[CE;TWB!
	F8.e5fc0dJXikU'v1qFVTfptB7xe$y*t#jx4`I44n,ypMQg@.|Z^ycJ:G]{dR~E}_.T1^shwC%T4eRGVu%h+J7lBzb>m20==Q*OPAf^~@6Lj^)rI9Tb*m*L}}HC~{>
	/__Od\I=[|aP6s}B%BhqtE-9uGJ0J3jchjcyJz5fW[i0$RfPv7Zp=!a+0pR

XEmacs 19.14-p1 builds and runs on UnixWare 2.1 with the following
changes:
	- changes for (something to do with) popup frames in
	  src/frame-x.c caused a problem similar to that reported by
	  Stephen Carney (frames wouldn't go away when they should -
	  reproduce by C-x52 and then C-X50 that frame).  an
	  uninformed view of the code suggests that the popup variable
	  is actually set the wrong way as a result of the test.  this
	  fixes the problems i see, but i'm not sure how to test that
	  the logic actually works correctly for the case it was added
	  to handle.  patch included.
	- the change i proposed to src/Makefile.in.in to do with
	  alloca didn't happen, so i had to do it again. (patch
	  included).
	- the behaviour of NEED_LIBW changed a bit (src/Makefile.in.in
	  now actually does something with it).  unixware 2.1 without
	  the devsys installed doesn't have -lw, so i had to go and
	  get one.  linking without it didn't cause me any problems,
	  but no testing with the stock unixware X11 libraries has
	  been done yet.  (no patch).

previously i hadn't built with X-Face support - it's there now.  w3
behaviour hasn't changed (not that it was expected to) - it still
doesn't work.  built both --debug=yes/-g and --debug=no/-O, both seem
fine.

:; ./configure --site-includes=/usr/local/include \
	--site-libraries=/usr/local/lib --debug=no --cflags=-O

Configured for `i386-univel-sysv4.2MP'.

  Where should the build process find the source code?    /home/davided/src/xemacs-19.14-p1
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/usg5-4-2.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              cc -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.

===================================================================
RCS file: src/Makefile.in.in,v
retrieving revision 1.1
diff -C 5 -r1.1 src/Makefile.in.in
*** /tmp/T0a002vR	Fri Jun 21 14:11:28 1996
--- src/Makefile.in.in	Fri Jun 21 13:19:15 1996
***************
*** 893,908 ****
  #else
  mallocobjs =
  mallocdocsrc =
  #endif /* SYSTEM_MALLOC */
  
! 
! #ifndef HAVE_ALLOCA
! allocaobjs = alloca.o
! #else
! allocaobjs =
! #endif
  
  #ifdef HAVE_X_WINDOWS
  
  # ifdef EXTERNAL_WIDGET
  #  define EXTERNAL_WIDGET_OBJS ExternalShell.o extw-Xt-nonshared.o extw-Xlib-nonshared.o
--- 893,903 ----
  #else
  mallocobjs =
  mallocdocsrc =
  #endif /* SYSTEM_MALLOC */
  
! allocaobjs = @ALLOCA@
  
  #ifdef HAVE_X_WINDOWS
  
  # ifdef EXTERNAL_WIDGET
  #  define EXTERNAL_WIDGET_OBJS ExternalShell.o extw-Xt-nonshared.o extw-Xlib-nonshared.o
===================================================================
RCS file: src/frame-x.c,v
retrieving revision 1.1
diff -C 5 -r1.1 src/frame-x.c
*** /tmp/T0a002vR	Fri Jun 21 14:11:28 1996
--- src/frame-x.c	Fri Jun 21 13:43:15 1996
***************
*** 2141,2153 ****
       widget parent.  Deleting them are their parent has already been
       deleted can lead to crashes. */
    XSETFRAME (frame, f);
    popup = Fframe_property (frame, Qpopup, Qnil);
    if (!FRAMEP (popup) || !FRAME_LIVE_P (XFRAME (popup)))
-     popup = Qt;
-   else
      popup = Qnil;
  
  #ifdef EXTERNAL_WIDGET
    {
      Display *dpy = XtDisplay (w);
      expect_x_error (dpy);
--- 2141,2153 ----
       widget parent.  Deleting them are their parent has already been
       deleted can lead to crashes. */
    XSETFRAME (frame, f);
    popup = Fframe_property (frame, Qpopup, Qnil);
    if (!FRAMEP (popup) || !FRAME_LIVE_P (XFRAME (popup)))
      popup = Qnil;
+   else
+     popup = Qt;
  
  #ifdef EXTERNAL_WIDGET
    {
      Display *dpy = XtDisplay (w);
      expect_x_error (dpy);

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 08:41:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA19207 for xemacs-beta-people; Fri, 21 Jun 1996 08:41:00 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA19204 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 08:40:59 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA27257 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 08:40:58 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id IAA03043 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 08:40:27 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id IAA18883 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 08:40:26 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id JAA14769 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 09:35:43 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: 19.14p1 success on Solaris 2.5
Date: Fri, 21 Jun 1996 09:35:41 -0400
Message-ID: <12054.835364141@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


>From a full distribution, on Solaris 2.5, using gcc 2.7.2, X11R6.1

Configured for `sparc-sun-solaris2.5'.

  Where should the build process find the source code?    /home/unix/toy/apps/xemacs-19.14
  What installation prefix should install use?            /apps/public/XEmacs/19.14
  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /apps/public/solaris2.5/X11R6.1/include
  Where do we find X Windows libraries?                   /apps/public/solaris2.5/X11R6.1/lib
  Additional header files:                                /apps/public/solaris2.4/include
  Additional libraries:                                   /apps/public/solaris2.4/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in both network and native sound support.
  Compiling in support for DBM.
  Compiling in support for ToolTalk.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

So far so good.

Ray

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 09:20:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA19356 for xemacs-beta-people; Fri, 21 Jun 1996 09:20:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA19353 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 09:20:41 -0500 (CDT)
Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA28000 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 09:20:43 -0500 (CDT)
Received: from calico.cis.ohio-state.edu (calico.cis.ohio-state.edu [164.107.142.11]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id KAA23689; Fri, 21 Jun 1996 10:20:40 -0400
Received: (ware@localhost) by calico.cis.ohio-state.edu (8.6.7/8.6.4) id KAA13414; Fri, 21 Jun 1996 10:20:39 -0400
To: Martin Buchholz <mrb@eng.sun.com>
Cc: georgn@canada.sun.com, xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b25 OK on Solaris
References: <199606181055.LAA22397@ariel.uk.abs>
	<199606181552.LAA11579@detlev.canada.sun.com>
	<199606181641.JAA10120@xemacs.eng.sun.com>
	<199606182018.QAA11666@detlev.canada.sun.com>
	<199606182128.OAA10715@xemacs.eng.sun.com>
From: Pete Ware <ware@cis.ohio-state.edu>
Date: 21 Jun 1996 10:20:37 -0400
In-Reply-To: Martin Buchholz's message of (unknown date)
Message-ID: <vwmviglz1ai.fsf@calico.cis.ohio-state.edu>
Lines: 87
X-Mailer: Gnus v5.2.2/XEmacs 19.14

I use the following to switch between shells.  If you only have one
shell active, it automatically switches to that shell.  If you have
multiple shell buffers, it prompts.  If you are already in a shell
buffer, it jumps to the end.

Sorry for the lack of documentation.
--pete
----------------------------------------------------------------------
(provide 'go-shell)
(global-set-key "\^cs"		'go-shell::shell)
(global-set-key "\^c4s"		'go-shell::shell-other-window)

(defvar go-shell::which-shell-mode (list "Shell" "Telnet")
  "List of name for determing if we are in a shell")
(defvar go-shell::which-shell-buffer "*shell*"
  "Name for switching to alternate buffer")
(defvar go-shell::which-shell 'shell
  "Which shell to run.")

(defun go-shell::shell-list ()
  (interactive)
  (let ((b (buffer-list))
	(shell-bufs nil))
    (while b
      (set-buffer (car b))
      (setq b (cdr b))
      (if (member mode-name go-shell::which-shell-mode)
	  (setq shell-bufs (cons (list (buffer-name) (buffer-name))
				 shell-bufs)))
      )
    (nreverse shell-bufs)
    )
  )
(defun go-shell::shell-select ()
  (interactive)
  (let ((s (go-shell::shell-list))
	(b nil))
    (if (cdr s)
	(setq b (completing-read (concat "Shell (" (car (car s)) "): ")
				 s nil t nil))
      (setq b ""))
    (if (and b (not (string= b ""))) b (car (car s)))
    )
  )
(defun go-shell::shell-start (buffer)
  (interactive "s")
    (cond ((not (comint-check-proc buffer))
	   (let* ((prog (or explicit-shell-file-name
			    (getenv "ESHELL")
			    (getenv "SHELL")
			    "/bin/sh"))		     
		  (name (file-name-nondirectory prog))
		  (startfile (concat "~/.emacs_" name))
		  (xargs-name (intern-soft (concat "explicit-" name "-args")))
		  (buffer-no-star (substring buffer 1 -1))
		  )
	     (set-buffer (apply 'make-comint buffer-no-start prog
				(if (file-exists-p startfile) startfile)
				(if (and xargs-name (boundp xargs-name))
				    (symbol-value xargs-name)
				  '("-i"))))
	     (shell-mode))))
    )

(defun go-shell::shell (arg &optional shell-name)
  (interactive "P")
  (let ((this-buffer (buffer-name)))
    (setq shell-name (if shell-name shell-name (go-shell::shell-select)))
    (switch-to-buffer shell-name)
    (go-shell::shell-start shell-name)
    (if (or arg (string= this-buffer (buffer-name)))
	(goto-char (point-max))
      )
    )
  )
(defun go-shell::shell-other-window (arg &optional shell-name)
  (interactive "P")
  (let ((this-buffer (buffer-name)))
    (setq shell-name (if shell-name shell-name (go-shell::shell-select)))
    (switch-to-buffer-other-window shell-name)
    (go-shell::shell-start shell-name)
    (if (or arg (string= this-buffer (buffer-name)))
	(goto-char (point-max))
      )
    )
  )


From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 09:01:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA19260 for xemacs-beta-people; Fri, 21 Jun 1996 09:01:01 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA19257 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 09:00:59 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA27675; Fri, 21 Jun 1996 09:01:00 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id JAA03876; Fri, 21 Jun 1996 09:00:28 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id JAA19263; Fri, 21 Jun 1996 09:00:27 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id JAA17099; Fri, 21 Jun 1996 09:55:45 -0400
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
References: <199606210258.VAA08801@charles.cs.uiuc.edu> 
Subject: Re: 19.14b26 *really* broken on my system 
In-reply-to: (Your message of Thu, 20 Jun 1996 21:58:24 CDT.)
             <199606210258.VAA08801@charles.cs.uiuc.edu> 
Date: Fri, 21 Jun 1996 09:55:43 -0400
Message-ID: <12127.835365343@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:


    Dan> On SunOS 4.1.3_U1 with X11R6, I'm seeing a really strange
    Dan> problem.  Whenever I minimize a frame, and then maximize it
    Dan> again, I don't get any display updates in that frame.  The
    Dan> only way I have found to get the redisplay working again is
    Dan> to start a new frame and then delete it.  The original frame
    Dan> will then update, and will work fine until I minimize it
    Dan> again.  Is anyone else seeing this?!?!?!

    Chuck> No one has reported anything this serious, though some have
    Chuck> seen this occasionally.  I have seen something similar
    Chuck> myself but only upon startup when I change virtual desktops
    Chuck> before XEmacs is fully initialized.  Iconifying and
    Chuck> uniconifying has always fixed it for good.

I see something like this now on Solaris 2.5, X11R6.1.  Never happened
before, but now it happens everytime I create a new frame.  Create a
new frame.  Delete any frame.  The menubar and modeline go away, but I
the frame doesn't.  Iconifying and deiconifying that frame gives a
blank frame without scrollbar, modeline, menu, or toolbar. It just
hangs around.  Cannot type in that frame or anything.  However, the
other frame works just fine.  If I keep doing this, I get tons of
useless xemacs frames

This is a real show-stopper for me:  it's impossible to delete a frame
and have it go away.

Ray



From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 09:12:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA19319 for xemacs-beta-people; Fri, 21 Jun 1996 09:12:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA19316 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 09:12:07 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA27875 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 09:12:07 -0500 (CDT)
Message-Id: <199606211412.JAA27875@a.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA142216330; Fri, 21 Jun 1996 15:12:11 +0100
Date: Fri, 21 Jun 1996 15:12:11 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@cs.uiuc.edu
Subject: pre-1 OK on hpux 10.10, frame deletion problem is there as well.
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



Configured for `hppa1.1-hp-hpux10.10'.

  Where should the build process find the source code?    /home/cognot/APPS/src/xemacs-19.14-p1
  What installation prefix should install use?		  /home/cognot/APPS/tmp
  What operating system and machine description files should XEmacs use?
        `s/hpux10shr.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              cc -Ae +O3 +Onoinline
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/include/X11R5
  Where do we find X Windows libraries?                   /usr/lib/X11R5 -L/usr/lib/X11R4
  Additional header files:                                /home/cognot/APPS/include
  Additional libraries:                                   /home/cognot/APPS/lib/hp700
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.

C-x 5 2 C-x 5 0 leads to a "dead" frame that won't go away. b26 was
working ok in that respect.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 10:13:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA19522 for xemacs-beta-people; Fri, 21 Jun 1996 10:13:19 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA19519 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 10:13:01 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA29561 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 10:12:55 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Fri, 21 Jun 1996 17:11:05 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id RAA12873; Fri, 21 Jun 1996 17:10:21 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id RAA20720;
          Fri, 21 Jun 1996 17:08:50 +0200
Date: Fri, 21 Jun 1996 17:08:50 +0200
Message-Id: <199606211508.RAA20720@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de>
To: xemacs-beta@cs.uiuc.edu
Subject: XEmacs 19.14 p1 successful installed on Solaris 2.5
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q(\V9 
        +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy 
        ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x 
        zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B: 
        s0;|v1x"Jb

System: Solaris 2.5
X11: R6
gcc: 2.7.2
Configure Options: --prefix=/prog/xemacs/src/Beta --with-xpm
--with-sound=both --dynamic=yes --with-gif --with-jpeg --with-xface
--rel-alloc --with-png --with-tooltalk --with-cde

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 10:27:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA19624 for xemacs-beta-people; Fri, 21 Jun 1996 10:27:18 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA19621 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 10:27:15 -0500 (CDT)
Received: from pallas.spacetec.no (pallas.spacetec.no [192.51.5.92]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA29976 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 10:27:07 -0500 (CDT)
Received: (from tor@localhost) by pallas.spacetec.no (8.7.1/8.7.1) id RAA20868 for xemacs-beta@cs.uiuc.edu; Fri, 21 Jun 1996 17:28:08 +0200
Message-Id: <199606211528.RAA20868@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Fri, 21 Jun 1996 17:28:08 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: xemacs-beta@cs.uiuc.edu
Subject: 19.14-p1 success on IRIX 5.3

./configure \
  --with-gcc=no --cflags="-O2 -mips2 -Olimit 2000"  --dynamic \ 
  --with-xpm  --with-png  --with-sound=no --rel-alloc=yes \
  --site-includes=/usr/local/include --site-libraries=/usr/local/lib \
  --with-menubars=lucid --with-scrollbars=lucid --with-dialogs=motif \
  --with-tooltalk=no  --const-is-losing=no --debug=no --error-checking=none

  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/irix5-3.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              cc -O2 -mips2 -Olimit 2000
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.

OK so far.
(don't try -O3 with IRIX 5.3, too much problems came up)

Tor

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 10:17:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA19551 for xemacs-beta-people; Fri, 21 Jun 1996 10:17:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA19548 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 10:17:23 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA15360 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 10:17:18 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id JAA07362; Fri, 21 Jun 1996 09:17:08 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id JAA19867; Fri, 21 Jun 1996 09:17:06 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id JAA08613; Fri, 21 Jun 1996 09:16:47 -0600
Date: Fri, 21 Jun 1996 09:16:47 -0600
Message-Id: <199606211516.JAA08613@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: 19.14p1: Solaris 2.5, SunPro CC 4.0, CDE
Reply-To: turner@lanl.gov

Configured and built with a bit more optimization this time:

Configured for `sparc-sun-solaris2.5'.

  Where should the build process find the source code?    /usr/local/contrib/xemacs-19.14-p1
  What installation prefix should install use?		  ${srcdir}
  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              cc -g -fast -xO3 -fsimple=2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/dt/include /home/turner/Tools/include
  Additional libraries:                                   /usr/dt/lib /home/turner/Tools/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Compiling in support for ToolTalk.
  Compiling in support for CDE.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

A couple of comments about the config:

- configure still leaves a core file

- Although I told configure --error-checking=none, it still says
  "Compiling in extra code for debugging."  Am I missing something?
  I seem to remember some discussion about this, but only vaguely.

Build was very smooth.  Hadn't really paid much attention to warnings
recently, but since others are mentioning it, here's all that SunPro
CC 4.0 said:

"/usr/local/contrib/xemacs-19.14-p1/lib-src/gnuslib.c", line 114: warning: statement not reached
"./xmprimitivep.h", line 30: warning: undefining __STDC__
"frame-x.c", line 956: warning: argument #1 is incompatible with prototype:
	prototype: pointer to uchar : "./emacsfns.h", line 98
	argument : pointer to char

I'm seeing the "forgotten but not gone" frame deletion problem as
well.  I tried to abort a reply in VM, the menubar blanked, and the
frame couldn't be killed even by the window manager (CDE).  Could
still exit altogether and go back to b26, which is how I'm sending
this.  I thought at first it might have been the extra optimization,
but since others are seeing it as well, I doubt it.  But I may rebuild
with less optimization just to see.

Another thing I'm still seeing is something I reported a while ago
(b20 I believe):

- C-a and C-e don't work correctly when truncate-lines is t.

 1. Set truncate-lines to t and place point on a line that's
    too long for the frame.
 2. Hit C-e and you only go to the edge of the screen.  Hit it
    again and you go to the end of the line.
 3. Same for C-a.

What's the deal with that?  Not serious enough to fix?

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 10:34:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA19652 for xemacs-beta-people; Fri, 21 Jun 1996 10:34:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA19649 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 10:34:22 -0500 (CDT)
Received: from ns1.eds.com (ns1.eds.com [192.85.154.78]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA00248 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 10:34:23 -0500 (CDT)
Received: by ns1.eds.com (hello)
	id LAA00671; Fri, 21 Jun 1996 11:34:20 -0400
Received: from kocrsw12.delcoelect.com (kocrsw12.delcoelect.com [144.250.106.18]) by kocrsv04.delcoelect.com (8.7.5/8.7.3) with SMTP id KAA07194 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 10:34:19 -0500 (EST)
Received: from kocrsw12 by kocrsw12.delcoelect.com (SMI-8.6/SMI-SVR4)
	id KAA19165; Fri, 21 Jun 1996 10:34:18 -0500
X-Mailer: exmh version 1.6.6 3/24/96
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b26 *really* broken on my system 
X-Face: 4tk3bJx]I+QTZ|=]*1+Z){9+;5u_hK*NBeZK6[+B+iB%bVuOJ%^uK~fIG}O-}%WLX*D
 ^aW>Gv8E3Xtz0\N&fQl^:pj<K{xM`:d>pPt:9lF-YXB%O)?@rd?*/jE!s94`?]:jJ#C5RDP:;M
 r.3lwo`0{vIT+<{%IRwe]vLd]7>\X|*z{TUX_t;?TPcOLBMIv8_V92!Vk(*DJVU~0M[`5D^PAW
 LniO1?YYWArMU*j9o+>?1MWi.lO?F-?aVt:qQ8OaG?R}B:I!7S_+KuzxZ.f9M@$z#n\bG2$Q2{od
In-reply-to: Your message of "Fri, 21 Jun 1996 09:55:43 -0400."
             <12127.835365343@rtp.ericsson.se> 
Date: Fri, 21 Jun 1996 10:34:18 -0500
Message-ID: <19163.835371258@kocrsw12>
From: Mike Scheidler <c23mts@eng.delcoelect.com>


> I see something like this now on Solaris 2.5, X11R6.1.  Never happened
> before, but now it happens everytime I create a new frame.  Create a
> new frame.  Delete any frame.  The menubar and modeline go away, but I
> the frame doesn't.

I'm seeing this now in version p1 on sun-solaris-2.4, X11R5, with fvwm.  I
didn't have any trouble like this with b26.  In my case, the scrollbar and
menubar go away, but the toolbar, modeline, and buffer text remain.

> Iconifying and deiconifying that frame gives a blank frame without
> scrollbar, modeline, menu, or toolbar. It just hangs around.  Cannot type
> in that frame or anything.  However, the other frame works just fine.  If
> I keep doing this, I get tons of useless xemacs frames

When I do this I don't lose any of the components of the dead frame.  No
input to the frame is accepted, but if I type over the buffer and that
buffer is also visible in another window, the input goes there.

> This is a real show-stopper for me:  it's impossible to delete a frame
> and have it go away.

We must be *really* close to the official release date now.   :-)

-- 
Mike Scheidler                     c23mts@eng.delcoelect.com
Corporate Software Technology
Delco Electronics Corporation      PHONE:  (317) 451-0319
Kokomo, IN 46904-9005              GMNET:  8-322-0319



From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 10:36:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA19661 for xemacs-beta-people; Fri, 21 Jun 1996 10:36:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA19658 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 10:36:20 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA15470 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 10:36:16 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA10112 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 10:36:12 -0500 (CDT)
Message-Id: <199606211536.KAA10112@charles.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: frame deletion problems
Date: Fri, 21 Jun 1996 10:36:12 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

I know what's wrong and will fix it as soon as I can get my workspace
rebuilt.  That may take awhile since xemacs.cs.uiuc.edu is getting
pounded by ftp traffic :-)


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 11:33:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA19939 for xemacs-beta-people; Fri, 21 Jun 1996 11:33:22 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA19936 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 11:33:21 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA19833 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 11:33:18 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA10224 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 11:33:19 -0500 (CDT)
Message-Id: <199606211633.LAA10224@charles.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: having trouble ftp'ing the prerelease?
Date: Fri, 21 Jun 1996 11:33:19 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

Try again now.  We had a bad transceiver that had shoved the collision
rate over 80%.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 11:30:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA19932 for xemacs-beta-people; Fri, 21 Jun 1996 11:30:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA19929 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 11:30:26 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA19741 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 11:30:23 -0500 (CDT)
Received: from revelle by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id KAA05055; Fri, 21 Jun 1996 10:30:24 -0600
Received: by revelle (SMI-8.6) id KAA29983; Fri, 21 Jun 1996 10:30:23 -0600
Sender: mdb@cdc.noaa.gov
To: turner@lanl.gov
Cc: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: Re: 19.14p1: Solaris 2.5, SunPro CC 4.0, CDE
References: <199606211516.JAA08613@gielgud.lanl.gov.xdiv>
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 21 Jun 1996 10:30:23 -0600
In-Reply-To: John Turner's message of Fri, 21 Jun 1996 09:16:47 -0600
Message-ID: <vkd92txgps.fsf@cdc.noaa.gov>
Lines: 40
X-Mailer: Gnus v5.2.23/XEmacs 19.14

>> On Fri, 21 Jun 1996 09:16:47 -0600,
>> John Turner(JT) wrote:
JT> Configured and built with a bit more optimization this time:
JT> Configured for `sparc-sun-solaris2.5'.

JT> A couple of comments about the config:

JT> - configure still leaves a core file

I see that too.

JT> - Although I told configure --error-checking=none, it still says
JT>   "Compiling in extra code for debugging."  Am I missing something?
JT>   I seem to remember some discussion about this, but only vaguely.

Do you use `--debug=no'? I don't see this "Compiling in extra code for
debugging." note when I do.

JT> I'm seeing the "forgotten but not gone" frame deletion problem as
JT> well.

Yes, me too. But Chuck just said he knows where the problem is. Stay
tuned...

JT> - C-a and C-e don't work correctly when truncate-lines is t.

JT>  1. Set truncate-lines to t and place point on a line that's
JT>     too long for the frame.
JT>  2. Hit C-e and you only go to the edge of the screen.  Hit it
JT>     again and you go to the end of the line.
JT>  3. Same for C-a.

JT> What's the deal with that?  Not serious enough to fix?

Isn't this a feature of auto-show-mode? If you set auto-show-mode nil
in such a case, \C-e never takes you beyond the right edge of the
frame -- you have to use the horizontal scroll-bar.

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 11:49:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA20010 for xemacs-beta-people; Fri, 21 Jun 1996 11:49:35 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA20007 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 11:49:35 -0500 (CDT)
Received: from big.aa.net (root@big.aa.net [204.157.220.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA19881 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 11:49:30 -0500 (CDT)
Received: from sym.primuscorp.com ([204.137.132.34]) by big.aa.net (8.6.12/8.6.9) with ESMTP id JAA12349 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 09:49:31 -0700
X-Intended-For: <xemacs-beta@xemacs.org>
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id JAA28546 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 09:49:35 -0700
Received: from pris by horus (SMI-8.6/SMI-SVR4)
	id JAA05617; Fri, 21 Jun 1996 09:49:02 -0700
Received: by pris (5.x/SMI-SVR4)
	id AA22986; Fri, 21 Jun 1996 09:49:26 -0700
Date: Fri, 21 Jun 1996 09:49:26 -0700
Message-Id: <9606211649.AA22986@pris>
From: Damon Lipparelli <lipp@primuscorp.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 19.14-p1: success under Solaris 2.4
Reply-To: Damon Lipparelli <lipp@primuscorp.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.14 ]

./configure --verbose --with-gcc --cflags=-O4 --with-gnu-make --site-includes=/usr/local/include --site-libraries=/usr/local/sun4/lib --prefix=/users/lipp/xemacs-beta/19.x --exec-prefix=/users/lipp/xemacs-beta/19.x/sun4 --with-menubars=lucid --with-xpm --with-xface --with-jpeg --with-gif --with-png --with-tooltalk --with-sparcworks --with-sound=none --debug=no --error-checking=none

Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /users/lipp/src/xemacs-beta/19.x/xemacs-19.14-p1
  What installation prefix should install use?            /users/lipp/xemacs-beta/19.x
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/sun4/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in support for CDE.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.

Other than still having to specify "--debug=no", everything built and looks
fine.

-lipp

---

SHHHH!!  I hear SIX TATTOOED TRUCK-DRIVERS tossing ENGINE BLOCKS
 into empty OIL DRUMS..

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 12:31:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA20216 for xemacs-beta-people; Fri, 21 Jun 1996 12:31:01 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20213 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 12:30:59 -0500 (CDT)
Received: from GS213.SP.CS.CMU.EDU (GS213.SP.CS.CMU.EDU [128.2.209.183]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA20015 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 12:30:55 -0500 (CDT)
Received: by GS213.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA42063; Fri, 21 Jun 1996 13:30:54 -0400
Date: Fri, 21 Jun 1996 13:30:54 -0400
Message-Id: <9606211730.AA42063@GS213.SP.CS.CMU.EDU>
From: Darrell Kindred <dkindred+@cmu.edu>
To: xemacs-beta@xemacs.org
Subject: p1: error checking & debugging on?

I noticed that error-checking and debugging support are still turned
on by default in 19.14p1.  I assume this will be changed before the
release? 

- Darrell

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 12:11:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA20069 for xemacs-beta-people; Fri, 21 Jun 1996 12:11:21 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20066 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 12:11:20 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA04425 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 12:11:18 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA18781; Fri, 21 Jun 1996 10:10:25 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Suggestions for documentation
References: <199606211329.IAA20721@nvwls.cc.purdue.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: "Joseph J. Nuspl Jr."'s message of Fri, 21 Jun 1996 08:29:01 -0500
Date: 21 Jun 1996 10:10:23 -0700
Message-ID: <m2enn9m6bk.fsf@deanna.miranova.com>
Lines: 17
X-Mailer: Gnus v5.2.23/XEmacs 19.14

>>>>> "Joseph" == Joseph J Nuspl <nuspl@nvwls.cc.purdue.edu> writes:

>>>>> "JKJ" == J Kean Johnston <jkj@paradigm-sa.com> writes:

JKJ> If it helps, here is where things are kept:
JKJ> XFACE: ???

Joseph> XFACE: ftp://ftp.cs.indiana.edu/pub/faces/compface

This is a very good idea.  I'm putting this info in the
FAQ/Installation section.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 12:20:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA20161 for xemacs-beta-people; Fri, 21 Jun 1996 12:20:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20158 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 12:20:01 -0500 (CDT)
Received: from loiosh.kei.com (ckd@loiosh.kei.com [192.88.144.32]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA19972 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 12:19:55 -0500 (CDT)
Received: (from ckd@localhost) by loiosh.kei.com (8.7.5/8.7.3) id NAA00367; Fri, 21 Jun 1996 13:19:27 -0400 (EDT)
To: xemacs-beta@xemacs.org
Subject: the undeletable frame bug
X-Attribution: ckd
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Christopher Davis <ckd@loiosh.kei.com>
Date: 21 Jun 1996 13:19:27 -0400
Message-ID: <w4ohmdcbxc.fsf@loiosh.kei.com>
Lines: 24

It's here in p1, on BSD/OS 2.1:

Configured for `i386-unknown-bsdi2.1'.

  Where should the build process find the source code?    /src/xemacs-19.14-p1
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/bsdos2-1.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -m486 -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 12:25:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA20183 for xemacs-beta-people; Fri, 21 Jun 1996 12:25:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20180 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 12:25:03 -0500 (CDT)
Received: from dowjones.com (gateway.dowjones.com [143.131.189.4]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA04807 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 12:25:05 -0500 (CDT)
Received: by dowjones.com; id NAA11952; Fri, 21 Jun 1996 13:36:11 -0400
Received: from wsj.dowjones.com(143.131.186.4) by gateway.dowjones.com via smap (V3.1)
	id xma011941; Fri, 21 Jun 96 13:35:56 -0400
Received: from nss_interbox.dowjones.com ([143.131.190.35]) by wsj.dowjones.com (5.x/SMI-SVR4)
	id AA17231; Fri, 21 Jun 1996 13:25:09 -0400
Message-Id: <31C84620.7AF@nrs.dowjones.com>
Date: Wed, 19 Jun 1996 13:25:36 -0500
From: wkirk <wkirk@wsj.dowjones.com>
Organization: Dow Jones & Company, Inc.
X-Mailer: Mozilla 2.0 (Win16; U)
Mime-Version: 1.0
To: xemacs-beta@cs.uiuc.edu
Subject: set-frame-properties different from make-frame
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

in XEmacs 19.14 beta 26 (I haven't been able to build p1 yet):

eval'ing this
(progn
  (set-frame-properties (selected-frame) '(top 10 left 10))
  (make-frame '(top 10 left 10)))
under linux 1.2.13 running fvwm, the two frames will not be in the
same position.  It appears that set-frame-properties is setting the
location of the upper left corner of the emacs window ignoring the
window manager decorations while make-frame is setting the location
of the upper left corner including window manager decorations.
After the set-frame-properties, frame-property reports 6 for left and
-13 for top.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 12:38:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA20229 for xemacs-beta-people; Fri, 21 Jun 1996 12:38:17 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20226 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 12:38:15 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20031 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 12:38:11 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA10510; Fri, 21 Jun 1996 12:38:10 -0500 (CDT)
Message-Id: <199606211738.MAA10510@charles.cs.uiuc.edu>
To: Darrell Kindred <dkindred+@cmu.edu>
cc: xemacs-beta@xemacs.org
Subject: Re: p1: error checking & debugging on? 
In-reply-to: Your message of "Fri, 21 Jun 1996 13:30:54 EDT."
             <9606211730.AA42063@GS213.SP.CS.CMU.EDU> 
Date: Fri, 21 Jun 1996 12:38:10 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Darrell> I noticed that error-checking and debugging support are
    Darrell> still turned on by default in 19.14p1.  I assume this
    Darrell> will be changed before the release?

Definitely.  It should actually have been changed in the pre-release.
I just forgot to do it.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 12:42:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA20253 for xemacs-beta-people; Fri, 21 Jun 1996 12:42:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20250 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 12:42:13 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA20052 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 12:42:09 -0500 (CDT)
Received: from revelle by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id LAA08725; Fri, 21 Jun 1996 11:42:06 -0600
Received: by revelle (SMI-8.6) id LAA01222; Fri, 21 Jun 1996 11:42:05 -0600
Sender: mdb@cdc.noaa.gov
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: xemacs-beta@xemacs.org
Subject: Re: frame deletion problems
References: <199606211536.KAA10112@charles.cs.uiuc.edu>
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 21 Jun 1996 11:42:03 -0600
In-Reply-To: Chuck Thompson's message of Fri, 21 Jun 1996 10:36:12 -0500
Message-ID: <vk7mt1xdec.fsf@cdc.noaa.gov>
Lines: 14
X-Mailer: Gnus v5.2.23/XEmacs 19.14

>> On Fri, 21 Jun 1996 10:36:12 -0500,
>> Chuck Thompson(CT) wrote:
CT> I know what's wrong and will fix it as soon as I can get my workspace
CT> rebuilt.

Will you make a patch available, or just fix it for the release
tomorrow?

Using VM w/frames makes for an awfully big frame graveyard very
quickly -- I've been stuffing them into a designated dead-frame room
in fvwm, but it's rapidly filling up ;-).

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 12:52:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA20285 for xemacs-beta-people; Fri, 21 Jun 1996 12:52:32 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20282 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 12:52:31 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA05503 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 12:52:31 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA19379; Fri, 21 Jun 1996 10:51:44 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Suggestions for documentation
References: <Pine.SCO5.3.93.960621125202.3479A-100000@hyperion.paradigm-sa.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: "J. Kean Johnston"'s message of Fri, 21 Jun 1996 13:59:42 -0200 (SAT)
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 21 Jun 1996 10:51:42 -0700
Message-ID: <m2lohh3v0x.fsf@deanna.miranova.com>
Lines: 40
X-Mailer: Gnus v5.2.24/XEmacs 19.14

Version numbers?  Please correct me if I've got any of this wrong.

> If it helps, here is where things are kept:
> JPEG : ftp://ftp.uu.net/graphics/jpeg/

This site is a mirror of ftp://ftp.netcom.com/pub/tg/tgl/uunet/.

V6a is current.

> XPM  : ftp://ftp.x.org/contrib/libraries/

3.4h is current.

> TIFF : ftp://ftp.sgi.com/graphics/tiff/

v3.4b035 is current.  There is a HOWTO here.

> PNG  : ftp://ftp.uu.net/graphics/png/

This site is a mirror of ftp://godzilli.cs.sunysb.edu:pub/ngf/.

v0.89c is current.

> XFACE: ftp://ftp.cs.indiana.edu/pub/faces/compface/

No version number.  :-(  There is a mailing list for xfaces & picons,
should this be listed as well?

> NAS  : ftp://ftp.x.org/contrib/audio/nas/

1.2p4 is current.  There is a FAQ here.


What about DBM and ncurses?  Should they be listed as well?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 12:40:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA20246 for xemacs-beta-people; Fri, 21 Jun 1996 12:40:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20243 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 12:40:55 -0500 (CDT)
Received: from caddy.arnet.com (caddy.arnet.com [199.86.10.214]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA20048 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 12:40:50 -0500 (CDT)
Subject: Additional patch for SCO OSR5
To: xemacs-beta@xemacs.org
Date: Fri, 21 Jun 1996 12:39:12 -0500 (CDT)
From: Robert Lipe <robertl@arnet.com>
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID:  <9606211239.aa19866@caddy.arnet.com>


This allows a dumped Emacs to run.  My patch from the wee hours
of the morning allowed only temacs to run from the debugger.

Ooops.

RJL


*** emacs.c_	Thu Jun 20 19:49:07 1996
--- emacs.c	Fri Jun 21 12:18:40 1996
***************
*** 422,428 ****
  #endif /* SHAREABLE_LIB_BUG */
  #endif /* LINK_CRTL_SHARE */
  #endif /* VMS */
! #if (defined (MSDOS) && defined (EMX)) || defined (WIN32)
    environ = envp;
  #endif
  
--- 422,428 ----
  #endif /* SHAREABLE_LIB_BUG */
  #endif /* LINK_CRTL_SHARE */
  #endif /* VMS */
! #if (defined (MSDOS) && defined (EMX)) || defined (WIN32) || defined (_SCO_DS)
    environ = envp;
  #endif
  

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 12:45:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA20275 for xemacs-beta-people; Fri, 21 Jun 1996 12:45:41 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20272 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 12:45:40 -0500 (CDT)
Received: from caddy.arnet.com (caddy.arnet.com [199.86.10.214]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA20066 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 12:45:36 -0500 (CDT)
Subject: OSR5 success
To: xemacs-beta@xemacs.org
Date: Fri, 21 Jun 1996 12:40:39 -0500 (CDT)
From: Robert Lipe <robertl@arnet.com>
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID:  <9606211240.aa19909@caddy.arnet.com>


Prerelease 1 works for me after applying the earlier patch.

RJL

Configured for `i586-unknown-sco3.2v5.0.0'.

  Where should the build process find the source code?    /home/robertl/src/xx/xemacs-19.14-p1
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sco5-shr.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              cc -g -Xc -dy 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XPM.
  No Xmu; substituting equivalent routines.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in network sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 12:43:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA20263 for xemacs-beta-people; Fri, 21 Jun 1996 12:43:16 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20260 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 12:43:15 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20059 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 12:43:12 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA10575; Fri, 21 Jun 1996 12:43:14 -0500 (CDT)
Message-Id: <199606211743.MAA10575@charles.cs.uiuc.edu>
To: Mark Borges <mdb@cdc.noaa.gov>
cc: xemacs-beta@xemacs.org
Subject: Re: frame deletion problems 
In-reply-to: Your message of "21 Jun 1996 11:42:03 MDT."
             <vk7mt1xdec.fsf@cdc.noaa.gov> 
Date: Fri, 21 Jun 1996 12:43:14 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Mark> Will you make a patch available, or just fix it for the
    Mark> release tomorrow?

Patch coming real soon.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 13:11:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA20387 for xemacs-beta-people; Fri, 21 Jun 1996 13:11:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20384 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 13:11:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20255 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 13:11:10 -0500 (CDT)
Message-Id: <199606211811.NAA20255@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: frame bug patch
Date: Fri, 21 Jun 1996 13:11:07 -0500
From: Chuck Thompson <cthomp@xemacs.org>

Please apply this and let me know as soon as possible if 1) it
corrects the problems 2) introduces some new ones or 3) makes things
worse :-)


			-Chuck


------- frame-x.c -------
*** /tmp/da004vr	Wed Dec 31 18:00:00 1969
--- frame-x.c	Fri Jun 21 13:08:22 1996
***************
*** 2142,2151 ****
       deleted can lead to crashes. */
    XSETFRAME (frame, f);
    popup = Fframe_property (frame, Qpopup, Qnil);
!   if (!FRAMEP (popup) || !FRAME_LIVE_P (XFRAME (popup)))
!     popup = Qt;
!   else
!     popup = Qnil;
  
  #ifdef EXTERNAL_WIDGET
    {
--- 2142,2157 ----
       deleted can lead to crashes. */
    XSETFRAME (frame, f);
    popup = Fframe_property (frame, Qpopup, Qnil);
!   if (!NILP (popup))
!     {
!       /* If popup isn't nil then it means the frame has that property
!          and the value is supposed to be the parent frame.  The FRAMEP
!          check is to safeguard against it not being a frame. */
!       if (!FRAMEP (popup) || !FRAME_LIVE_P (XFRAME (popup)))
! 	popup = Qt;
!       else
! 	popup = Qnil;
!     }
  
  #ifdef EXTERNAL_WIDGET
    {

------- event-Xt.c -------
*** /tmp/da004vt	Wed Dec 31 18:00:00 1969
--- event-Xt.c	Fri Jun 21 13:03:31 1996
***************
*** 1113,1119 ****
        XGetWindowAttributes (event->xany.display, event->xmap.window,
  			    &xwa);
        if (xwa.map_state != IsViewable)
! 	return;
  
        FRAME_X_TOTALLY_VISIBLE_P (f) = 1;
  #if 0
--- 1113,1124 ----
        XGetWindowAttributes (event->xany.display, event->xmap.window,
  			    &xwa);
        if (xwa.map_state != IsViewable)
! 	{
! 	  /* Calling Fframe_iconified_p is the only way we have to
!              correctly update FRAME_ICONIFIED_P */
! 	  Fframe_iconified_p (frame);
! 	  return;
! 	}
  
        FRAME_X_TOTALLY_VISIBLE_P (f) = 1;
  #if 0
***************
*** 1167,1172 ****
--- 1172,1181 ----
  	  dispatch_epoch_event (f, event, Qx_unmap);
  #endif
  	}
+ 
+       /* Calling Fframe_iconified_p is the only way we have to
+          correctly update FRAME_ICONIFIED_P */
+       Fframe_iconified_p (frame);
      }
  }
  

------- frame.c -------
*** /tmp/da004vv	Wed Dec 31 18:00:00 1969
--- frame.c	Fri Jun 21 13:08:58 1996
***************
*** 1005,1010 ****
--- 1005,1019 ----
  	      Lisp_Object f = XCAR (frmcons);
  	      if (passed)
  		{
+ 		  /* #### Doing this here is bad and is now
+                      unnecessary.  The real bug was that f->iconified
+                      was never, ever updated unless a user explicitly
+                      called frame-iconified-p.  That has now been
+                      fixed.  With this change removed all of the other
+                      changes made to support this routine having the
+                      called_from_delete_device arg could be removed.
+                      But it is too close to release to do that now. */
+ #if 0
  		  /* Make sure the visibility and iconified flags are
                       up-to-date unless we're being deleted. */
  		  if (!called_from_delete_device)
***************
*** 1012,1017 ****
--- 1021,1027 ----
  		      Fframe_iconified_p (f);
  		      Fframe_visible_p (f);
  		    }
+ #endif
  
  		  /* Decide whether this frame is eligible to be returned.  */
  		  

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 13:27:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA20601 for xemacs-beta-people; Fri, 21 Jun 1996 13:27:57 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20598 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 13:27:56 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA06103 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 13:27:57 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA20027; Fri, 21 Jun 1996 11:27:07 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: binary kit build instructions
References: <199606211025.DAA28113@netcom2.netcom.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: wing@666.com's message of Fri, 21 Jun 1996 03:25:16 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 21 Jun 1996 11:27:04 -0700
Message-ID: <m2d92t3tdz.fsf@deanna.miranova.com>
Lines: 15
X-Mailer: Gnus v5.2.24/XEmacs 19.14

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

Ben> Also, on Linux, I would strongly consider statically linking with
Ben> libc and libm, although dynamically linking with the standard X libraries
Ben> is probably OK.  Remember the _h_errno SNAFU in 19.13.

I would further suggest that separate binaries be provided linked
against Linux 2.0 as well as Linux 1.2.13.  I was unsuccessful running
binaries linked against 1.2 on the 1.3 betas, and vice versa.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 13:45:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA20656 for xemacs-beta-people; Fri, 21 Jun 1996 13:45:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20653 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 13:45:45 -0500 (CDT)
Received: from big.aa.net (root@big.aa.net [204.157.220.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA20290 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 13:45:41 -0500 (CDT)
Received: from sym.primuscorp.com ([204.137.132.34]) by big.aa.net (8.6.12/8.6.9) with ESMTP id LAA24104 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 11:45:43 -0700
X-Intended-For: <xemacs-beta@xemacs.org>
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id LAA14221 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 11:45:52 -0700
Received: from pris by horus (SMI-8.6/SMI-SVR4)
	id LAA07628; Fri, 21 Jun 1996 11:45:16 -0700
Received: by pris (5.x/SMI-SVR4)
	id AA25766; Fri, 21 Jun 1996 11:45:40 -0700
Date: Fri, 21 Jun 1996 11:45:40 -0700
Message-Id: <9606211845.AA25766@pris>
From: Damon Lipparelli <lipp@primuscorp.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Chuck's 19.14-p1 "frame deletion" patch...
Reply-To: Damon Lipparelli <lipp@primuscorp.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.14 ]

...works for me.

Thanks,
-lipp
---

Does someone from PEORIA have a SHORTER ATTENTION span than me?

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 13:40:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA20641 for xemacs-beta-people; Fri, 21 Jun 1996 13:40:12 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20638 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 13:40:11 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA20284; Fri, 21 Jun 1996 13:40:07 -0500 (CDT)
Received: from revelle by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id MAA10391; Fri, 21 Jun 1996 12:40:10 -0600
Received: by revelle (SMI-8.6) id MAA02163; Fri, 21 Jun 1996 12:40:09 -0600
Sender: mdb@cdc.noaa.gov
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: Re: frame bug patch
References: <199606211811.NAA20255@xemacs.cs.uiuc.edu>
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 21 Jun 1996 12:40:06 -0600
In-Reply-To: Chuck Thompson's message of Fri, 21 Jun 1996 13:11:07 -0500
Message-ID: <vk20j92e7s.fsf@cdc.noaa.gov>
Lines: 17
X-Mailer: Gnus v5.2.23/XEmacs 19.14

>> On Fri, 21 Jun 1996 13:11:07 -0500,
>> Chuck Thompson(CT) wrote:
CT> Please apply this and let me know as soon as possible if
CT> 1) it corrects the problems 
Yes, I can happily delete frames now.

CT> 2) introduces some new ones
Don't know yet, but most indications are no, no new problems here.

CT> 3) makes things worse :-)

 :-] :-o :-) ;-) :-\ :-| :-d :-P 8-| :-(

Sorry. Just discovered smiley.el and want to test it out.

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 13:44:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA20649 for xemacs-beta-people; Fri, 21 Jun 1996 13:44:34 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20646 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 13:44:33 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA20287 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 13:44:29 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id LAA12400; Fri, 21 Jun 1996 11:44:03 -0700
Received: from x-files.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id LAA27174; Fri, 21 Jun 1996 11:43:58 -0700
Received: from x-files by x-files.eng.sun.com (SMI-8.6/SMI-SVR4)
	id LAA17491; Fri, 21 Jun 1996 11:44:00 -0700
Message-Id: <199606211844.LAA17491@x-files.eng.sun.com>
X-Mailer: exmh version 1.6.7 5/3/96
To: xemacs-beta@xemacs.org
Subject: 19.14p1: configuration vs. canonical
Mime-Version: 1.0
Content-Type: text/plain
Date: Fri, 21 Jun 1996 11:44:00 -0700
From: Greg Onufer <Greg.Onufer@eng.sun.com>

This is the first time I actually installed xemacs 19.14 versus
running it in place... and it broke.  It installs the files
based on the autoconfigure value of "configuration" but the startup
code searches for the directories based on "canonical" which may
not be the same (I configured "sparc-sun-sunos5.4", it changed that
into "sparc-sun-solaris2.4").

Cheers!greg





From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 13:49:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA20670 for xemacs-beta-people; Fri, 21 Jun 1996 13:49:28 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20667 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 13:49:27 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA06515 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 13:49:28 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA20416; Fri, 21 Jun 1996 11:48:36 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: the undeletable frame bug
References: <w4ohmdcbxc.fsf@loiosh.kei.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Christopher Davis's message of 21 Jun 1996 13:19:27 -0400
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 21 Jun 1996 11:48:32 -0700
Message-ID: <m291dh3se7.fsf@deanna.miranova.com>
Lines: 13
X-Mailer: Gnus v5.2.24/XEmacs 19.14

>>>>> "ckd" == Christopher Davis <ckd@loiosh.kei.com> writes:

ckd> It's here in p1, on BSD/OS 2.1:

Presumably you mean C-x 5 0 not deleting the Frame?  I'm seeing this
behavior for the first time on Linux 2.0.

I just noticed the icon, the color is cool.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 13:58:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA20709 for xemacs-beta-people; Fri, 21 Jun 1996 13:58:50 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20706 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 13:58:49 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20300; Fri, 21 Jun 1996 13:58:45 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id NAA17173; Fri, 21 Jun 1996 13:58:15 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id NAA25316; Fri, 21 Jun 1996 13:58:14 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id OAA15573; Fri, 21 Jun 1996 14:53:31 -0400
To: Chuck Thompson <cthomp@xemacs.org>
cc: xemacs-beta@xemacs.org
References: <199606211811.NAA20255@xemacs.cs.uiuc.edu> 
Subject: Re: frame bug patch 
In-reply-to: (Your message of Fri, 21 Jun 1996 13:11:07 CDT.)
             <199606211811.NAA20255@xemacs.cs.uiuc.edu> 
Date: Fri, 21 Jun 1996 14:53:31 -0400
Message-ID: <12925.835383211@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:


    Chuck> Please apply this and let me know as soon as possible if 1)
    Chuck> it corrects the problems 2) introduces some new ones or 3)
    Chuck> makes things worse :-)

Seems to work for me.  The frames go away now.  No apparent other
effects, but I've only run it for a few minutes.

Ray

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 14:08:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA20740 for xemacs-beta-people; Fri, 21 Jun 1996 14:08:50 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA20737 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 14:08:48 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA20306 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 14:08:47 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id NAA18774; Fri, 21 Jun 1996 13:08:46 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id NAA23163; Fri, 21 Jun 1996 13:08:44 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id NAA02623; Fri, 21 Jun 1996 13:08:24 -0600
Date: Fri, 21 Jun 1996 13:08:24 -0600
Message-Id: <199606211908.NAA02623@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: mdb@cdc.noaa.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: 19.14p1: Solaris 2.5, SunPro CC 4.0, CDE
In-Reply-To: <vkd92txgps.fsf@cdc.noaa.gov>
References: <199606211516.JAA08613@gielgud.lanl.gov.xdiv>
	<vkd92txgps.fsf@cdc.noaa.gov>
Reply-To: turner@lanl.gov

Mark Borges writes:
 > JT> - Although I told configure --error-checking=none, it still says
 > JT>   "Compiling in extra code for debugging."  Am I missing something?
 > JT>   I seem to remember some discussion about this, but only vaguely.
 > 
 > Do you use `--debug=no'? I don't see this "Compiling in extra code for
 > debugging." note when I do.

I just looked in configure, and it says --debug costs code size but
not speed, so I'll just leave that on.

 > JT> - C-a and C-e don't work correctly when truncate-lines is t.
 > 
 > JT>  1. Set truncate-lines to t and place point on a line that's
 > JT>     too long for the frame.
 > JT>  2. Hit C-e and you only go to the edge of the screen.  Hit it
 > JT>     again and you go to the end of the line.
 > JT>  3. Same for C-a.
 > 
 > JT> What's the deal with that?  Not serious enough to fix?
 > 
 > Isn't this a feature of auto-show-mode? If you set auto-show-mode nil
 > in such a case, \C-e never takes you beyond the right edge of the
 > frame -- you have to use the horizontal scroll-bar.

I'm confused.

- I go into a buffer with lines wider than the frame.  Say
  .xemacs-options.

- Initially (for me), both auto-show-mode and truncate-lines are t.

- Behavior is as described above (the quoted stuff I said).  In fact,
  it's even a little weirder.  C-e moves to the right edge of the
  frame, but a subsequent C-a basically scrolls the whole window to
  the right and leaves me at the left edge.  Basically the same place
  I would have been had I done another C-e and then a C-a.

  This seems to be in contradiction to what you were saying should
  happen. 

- If I set auto-show-mode to nil, the no amount of C-e's will move to
  the end of a truncated line; I have to use the horiz. scrollbar.
  That seems correct, I guess.

So I like auto-show-mode t, but it just doesn't seem to be working
quite right.

(Note: this was with b26.  Patched p1 is building now, and I'll post
if it's any different.)

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 14:16:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA20767 for xemacs-beta-people; Fri, 21 Jun 1996 14:16:41 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA20764 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 14:16:40 -0500 (CDT)
Received: from ns1.eds.com (ns1.eds.com [192.85.154.78]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA20312; Fri, 21 Jun 1996 14:16:38 -0500 (CDT)
Received: by ns1.eds.com (hello)
	id PAA16860; Fri, 21 Jun 1996 15:16:41 -0400
Received: from kocrsw12.delcoelect.com (kocrsw12.delcoelect.com [144.250.106.18]) by kocrsv04.delcoelect.com (8.7.5/8.7.3) with SMTP id OAA11930; Fri, 21 Jun 1996 14:16:40 -0500 (EST)
Received: from kocrsw12 by kocrsw12.delcoelect.com (SMI-8.6/SMI-SVR4)
	id OAA21257; Fri, 21 Jun 1996 14:16:38 -0500
X-Mailer: exmh version 1.6.6 3/24/96
To: xemacs-beta@xemacs.org
cc: Chuck Thompson <cthomp@xemacs.org>
Subject: Re: frame bug patch 
X-Face: 4tk3bJx]I+QTZ|=]*1+Z){9+;5u_hK*NBeZK6[+B+iB%bVuOJ%^uK~fIG}O-}%WLX*D
 ^aW>Gv8E3Xtz0\N&fQl^:pj<K{xM`:d>pPt:9lF-YXB%O)?@rd?*/jE!s94`?]:jJ#C5RDP:;M
 r.3lwo`0{vIT+<{%IRwe]vLd]7>\X|*z{TUX_t;?TPcOLBMIv8_V92!Vk(*DJVU~0M[`5D^PAW
 LniO1?YYWArMU*j9o+>?1MWi.lO?F-?aVt:qQ8OaG?R}B:I!7S_+KuzxZ.f9M@$z#n\bG2$Q2{od
In-reply-to: Your message of "21 Jun 1996 12:40:06 CST."
             <vk20j92e7s.fsf@cdc.noaa.gov> 
Date: Fri, 21 Jun 1996 14:16:37 -0500
Message-ID: <21255.835384597@kocrsw12>
From: Mike Scheidler <c23mts@eng.delcoelect.com>


> CT> 1) it corrects the problems 
> Yes, I can happily delete frames now.

Same here.  Looks good.

>  :-] :-o :-) ;-) :-\ :-| :-d :-P 8-| :-(
> 
> Sorry. Just discovered smiley.el and want to test it out.

I just found it yesterday myself.  I don't recall seeing anything in the
announcements about this new, can't-live-without package.  :-P ;-)

-- 
Mike Scheidler                     c23mts@eng.delcoelect.com
Corporate Software Technology
Delco Electronics Corporation      PHONE:  (317) 451-0319
Kokomo, IN 46904-9005              GMNET:  8-322-0319



From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 15:03:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA20950 for xemacs-beta-people; Fri, 21 Jun 1996 15:03:03 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA20947 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 15:03:02 -0500 (CDT)
Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA08219 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 15:03:04 -0500 (CDT)
Received: from calico.cis.ohio-state.edu (calico.cis.ohio-state.edu [164.107.142.11]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id QAA02088; Fri, 21 Jun 1996 16:02:58 -0400
Received: (ware@localhost) by calico.cis.ohio-state.edu (8.6.7/8.6.4) id QAA24552; Fri, 21 Jun 1996 16:02:57 -0400
To: Pete Ware <ware@cis.ohio-state.edu>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs 19.14-p1 compiled under HPUX, gcc, frame patch
References: <199606102149.RAA27430@calico.cis.ohio-state.edu>
From: Pete Ware <ware@cis.ohio-state.edu>
Date: 21 Jun 1996 16:02:55 -0400
In-Reply-To: Pete Ware's message of Mon, 10 Jun 1996 17:49:29 -0400
Message-ID: <vwmk9x1vsb4.fsf@calico.cis.ohio-state.edu>
Lines: 8
X-Mailer: Gnus v5.2.23/XEmacs 19.14

First pass seems much better with the frame patch.  I've been playing
with gnuattach and it seems pretty fragile (I'll know more later).

./configure --site-includes="/usr/local/include /usr/local/include/db"
	--x-libraries=/usr/lib/X11R5 --prefix=/usr/contrib hppa1.1-hp-hpux9shr


--pete

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 15:32:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA21033 for xemacs-beta-people; Fri, 21 Jun 1996 15:32:33 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA21030 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 15:32:32 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA20371; Fri, 21 Jun 1996 15:32:30 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA11071; Fri, 21 Jun 1996 15:32:31 -0500 (CDT)
Message-Id: <199606212032.PAA11071@charles.cs.uiuc.edu>
To: turner@lanl.gov
cc: cthomp@xemacs.org, xemacs-beta@xemacs.org
Subject: Re: frame bug patch 
In-reply-to: Your message of "Fri, 21 Jun 1996 14:28:13 MDT."
             <199606212028.OAA03441@gielgud.lanl.gov.xdiv> 
Date: Fri, 21 Jun 1996 15:32:31 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    John> - keyboard macro slowness when lazy-lock on
    >> Am I imagining that this is fixed?  I don't remember it being
    John>    mentioned, but it seems to be gone.  Yeah!  This was one of the
    John>    most important problems I was seeing.

Yes, it is fixed and yes, it would appear that I forgot to add that
fact to CHANGES-beta.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 15:28:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA21010 for xemacs-beta-people; Fri, 21 Jun 1996 15:28:35 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA21007 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 15:28:34 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA20359; Fri, 21 Jun 1996 15:28:32 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id OAA02805; Fri, 21 Jun 1996 14:28:35 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id OAA24139; Fri, 21 Jun 1996 14:28:33 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id OAA03441; Fri, 21 Jun 1996 14:28:13 -0600
Date: Fri, 21 Jun 1996 14:28:13 -0600
Message-Id: <199606212028.OAA03441@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: cthomp@xemacs.org
Cc: xemacs-beta@xemacs.org
Subject: Re: frame bug patch
In-Reply-To: <199606211811.NAA20255@xemacs.cs.uiuc.edu>
References: <199606211811.NAA20255@xemacs.cs.uiuc.edu>
Reply-To: turner@lanl.gov

Chuck Thompson writes:
 > Please apply this and let me know as soon as possible if 1) it
 > corrects the problems 2) introduces some new ones or 3) makes things
 > worse :-)

Fixed it for me (Solaris 2.5, SunPro CC 4.0, CDE).

Here's how p1 stands for me...

Fixed recently:

- various Gnus things (e.g. gnus-directory)

- .xemacs-options (great)

- keyboard macro slowness when lazy-lock on
 > Am I imagining that this is fixed?  I don't remember it being
   mentioned, but it seems to be gone.  Yeah!  This was one of the
   most important problems I was seeing.

Still seeing:

- C-e/C-a weirdness when truncate-lines and auto-show-mode t

- configure leaves core

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 15:31:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA21027 for xemacs-beta-people; Fri, 21 Jun 1996 15:31:59 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA21024 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 15:31:57 -0500 (CDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.80.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA08962 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 15:31:58 -0500 (CDT)
From: rol@darmstadt.gmd.de
Received: from rieke_ppp.darmstadt.gmd.de.darmstadt.gmd.de (rieke_ppp [141.12.144.7]) by sonne.darmstadt.gmd.de (8.7.3/8.7.3) with SMTP id WAA10072 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 22:31:21 +0200 (MET DST)
Date: Fri, 21 Jun 1996 22:31:21 +0200 (MET DST)
Message-Id: <199606212031.WAA10072@sonne.darmstadt.gmd.de>
To: xemacs-beta@cs.uiuc.edu
Subject: 19.14p1 on Linux seems ok except the known frame-deletion-problem

Configured for `i586-unknown-linux2.0.0'.

  Where should the build process find the source code?    /scratch/xemacs-19.14-p1
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                 /usr/include/ncurses
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

Roland Rieke


From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 15:43:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA21210 for xemacs-beta-people; Fri, 21 Jun 1996 15:43:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA21207 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 15:43:44 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA09251 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 15:43:44 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id NAA22619; Fri, 21 Jun 1996 13:42:55 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14p1: Solaris 2.5, SunPro CC 4.0, CDE
References: <199606211516.JAA08613@gielgud.lanl.gov.xdiv>
	<vkd92txgps.fsf@cdc.noaa.gov>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Mark Borges's message of 21 Jun 1996 10:30:23 -0600
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 21 Jun 1996 13:42:54 -0700
Message-ID: <m2k9x03n3l.fsf@deanna.miranova.com>
Lines: 17
X-Mailer: Gnus v5.2.24/XEmacs 19.14

>>>>> "Mark" == Mark Borges <mdb@cdc.noaa.gov> writes:

Mark> Do you use `--debug=no'? I don't see this "Compiling in extra code for
Mark> debugging." note when I do.

If you can use --debug=no, then it should be documented that way in
configure.  I was poking around through configure --help last night
prior to building p1, and from the documentation could see no obvious
way to turn it off, as it implies that --debug does not take a
parameter.

(I'll admit, this is not a very big nit).
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 15:58:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA21243 for xemacs-beta-people; Fri, 21 Jun 1996 15:58:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA21240 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 15:58:18 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA09673 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 15:58:20 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id NAA22786; Fri, 21 Jun 1996 13:57:33 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: frame bug patch
References: <21255.835384597@kocrsw12>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Mike Scheidler's message of Fri, 21 Jun 1996 14:16:37 -0500
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 21 Jun 1996 13:57:32 -0700
Message-ID: <m2hgs43mf7.fsf@deanna.miranova.com>
Lines: 27
X-Mailer: Gnus v5.2.24/XEmacs 19.14

>>>>> "Mike" == Mike Scheidler <c23mts@eng.delcoelect.com> writes:

Mark Borges writes:
Mark> :-] :-o :-) ;-) :-\ :-| :-d :-P 8-| :-(
Mark> 
Mark> Sorry. Just discovered smiley.el and want to test it out.

Mike> I just found it yesterday myself.  I don't recall seeing
Mike> anything in the announcements about this new, can't-live-without
Mike> package.  :-P ;-)

It was a last minute thing, triggered by someone reporting that a
Microsoft package implemented it.  The way it was implemented clearly
illustrates the strength of networked development.  The idea was
reported on the Gnus Developer's list, and Wes Hardaker at UC Davis
(Northern California) implemented an initial version.  William Perry
tossed in some improvements a few hours later, half way across the
US.  And Lars finished it up a few hours after that, half way across
the world.  :-)

Gnus has pretty much been in feature freeze all year so far, and I
think we're getting antsy now to move on to Red Gnus.  :-]
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 16:08:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA21265 for xemacs-beta-people; Fri, 21 Jun 1996 16:08:32 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA21262 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 16:08:31 -0500 (CDT)
Received: from diamond.pilgrim.umass.edu (diamond.pilgrim.umass.edu [128.119.60.44]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA09869 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 16:08:18 -0500 (CDT)
Received: (from srivasta@localhost) by diamond.pilgrim.umass.edu (8.7.5/8.7.3) id RAA08669; Fri, 21 Jun 1996 17:07:36 -0400 (EDT)
Date: Fri, 21 Jun 1996 17:07:36 -0400 (EDT)
Message-Id: <199606212107.RAA08669@diamond.pilgrim.umass.edu>
From: srivasta@pilgrim.umass.edu (Manoj Srivastava)
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: XEmacs 19.14-b26 success on hpux 9.03 (shared)
Organization: University of Massachusetts, Amherst, MA 01003
X-Mail-System: Vm 5.96 (beta) for GNU Emacs 19.14 XEmacs Lucid (beta26)
X-Time: Fri Jun 21 17:07:30 1996
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII

Hi,

	I had to rebuild png and zlib, (interesting errors compiling
 src/glyphs-x.c with the old heades in place) but them's the breaks.

Configured for `hppa1.1-hp-hpux9shr'.
  Where should the build process find the source code?    /usr/local/build/xemacs-19.14-b26
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/hpux9shr.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              cc -Aa +O2 -D_HPUX_SOURCE
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

	Works fine, I guess. 

	manoj
-- 
 I waited and waited, and when no message came, I knew it must have
 been from you. Ashleigh Brilliant
Manoj Srivastava               Systems Research Programmer, Project Pilgrim,
Phone: (413) 545-3918                A143B Lederle Graduate Research Center,
Fax:   (413) 545-1249         University of Massachusetts, Amherst, MA 01003
<srivasta@pilgrim.umass.edu> <URL:http://www.pilgrim.umass.edu/%7Esrivasta/>

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 16:18:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA21332 for xemacs-beta-people; Fri, 21 Jun 1996 16:18:44 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA21329 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 16:18:42 -0500 (CDT)
Received: from diamond.pilgrim.umass.edu (diamond.pilgrim.umass.edu [128.119.60.44]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA10039 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 16:18:43 -0500 (CDT)
Received: (from srivasta@localhost) by diamond.pilgrim.umass.edu (8.7.5/8.7.3) id RAA10403; Fri, 21 Jun 1996 17:18:16 -0400 (EDT)
Date: Fri, 21 Jun 1996 17:18:16 -0400 (EDT)
Message-Id: <199606212118.RAA10403@diamond.pilgrim.umass.edu>
From: srivasta@pilgrim.umass.edu (Manoj Srivastava)
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: XEmacs failure on hpux3.0
Organization: University of Massachusetts, Amherst, MA 01003
X-Mail-System: Vm 5.96 (beta) for GNU Emacs 19.14 XEmacs Lucid (beta26)
X-Time: Fri Jun 21 17:18:14 1996
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII

Hi,

	Built on a DEC alpha OSF/1 3.0 system, and promptly crashed
 (in a manner I have been unable to reproduce since.) I hope the
 backtraces shed some light ...

	I'm getting the ``official'' DIGITAL UNIX 4.0 on Monday (the
 day of release of 19.14, ;-( I guess, so I'll have a crack at it
 again) 

	manoj

Configured for `alpha-dec-osf3.0'.

  Where should the build process find the source code?    /usr/local/build/xemacs-19.14-b26
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/decosf3-1.h' and `m/alpha.h'
  What compiler should XEmacs be built with?              cc -O2 -Olimit 3000
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.



----------------------------------------------------------------------
Fatal error (13).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb `which xemacs` core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  # bind (r ok message label)
  log-message-filter(message "Loading setup-x...done.")
  # bind (message label)
  log-message(message "Loading setup-x...done.")
  run-hook-with-args(log-message message "Loading setup-x...done.")
  byte-code("<C0><C1>\n@@\n@A#" [run-hook-with-args remove-message-hook log] 4)
  # (condition-case ... . ((error (byte-code "<C0><C2><C3>
                                                 \"<C5><C6>!<C7><C8><C9>!!<CA>
                                                            @
                                                             A\"" ... 3))))
  # bind (log frame label)
  remove-message(message #<x-frame "emacs" 0x8ba>)
  # bBroken pipe


----------------------------------------------------------------------
C backtrace:
__> gdb /usr/local/bin/xemacs
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (alpha-dec-osf3.0), Copyright 1996 Free Software Foundation, Inc...
(gdb) run
Starting program: /usr/local/bin/xemacs 

Program received signal SIGSEGV, Segmentation fault.
fflush () at ../../../../../src/usr/ccs/lib/libc/flsbuf.c:350
../../../../../src/usr/ccs/lib/libc/flsbuf.c:350: No such file or directory.
(gdb) where
#0  fflush () at ../../../../../src/usr/ccs/lib/libc/flsbuf.c:350
#1  0x12018855c in reset_one_device () at sysdep.c:1938
#2  0x12008b644 in delete_device_internal () at device.c:737
#3  0x12007c4d0 in delete_console_internal () at console.c:697
#4  0x12008b620 in delete_device_internal () at device.c:731
#5  0x12008ba20 in Fdelete_device () at device.c:820
#6  0x1200a68c4 in primitive_funcall () at eval.c:3486
#7  0x1200a6be0 in funcall_subr () at eval.c:3526
#8  0x1200a5c40 in funcall_recording_as () at eval.c:3204
#9  0x1200a5df8 in Ffuncall () at eval.c:3253
#10 0x12006db0c in Fbyte_code () at bytecode.c:450
#11 0x1200a7238 in funcall_lambda () at eval.c:3636
#12 0x1200a5c8c in funcall_recording_as () at eval.c:3210
#13 0x1200a5df8 in Ffuncall () at eval.c:3253
#14 0x12006db0c in Fbyte_code () at bytecode.c:450
#15 0x1200a7238 in funcall_lambda () at eval.c:3636
#16 0x1200a5c8c in funcall_recording_as () at eval.c:3210
#17 0x1200a5df8 in Ffuncall () at eval.c:3253
#18 0x12006db0c in Fbyte_code () at bytecode.c:450
#19 0x1200a7238 in funcall_lambda () at eval.c:3636
#20 0x1200a6d70 in apply_lambda () at eval.c:3559
#21 0x1200a5614 in Feval () at eval.c:3068
#22 0x1200a1f0c in condition_case_1 () at eval.c:1672
#23 0x120077b28 in top_level_1 () at cmdloop.c:194
#24 0x1200a18ec in internal_catch () at eval.c:1347
#25 0x120077d20 in initial_command_loop () at cmdloop.c:253
#26 0x12009d540 in main_1 () at emacs.c:1317
#27 0x12009dafc in main () at emacs.c:1439


-- 
 "To take a significant step forward, you must make a series of finite
 improvements." Donald J. Atwood, General Motors
Manoj Srivastava               Systems Research Programmer, Project Pilgrim,
Phone: (413) 545-3918                A143B Lederle Graduate Research Center,
Fax:   (413) 545-1249         University of Massachusetts, Amherst, MA 01003
<srivasta@pilgrim.umass.edu> <URL:http://www.pilgrim.umass.edu/%7Esrivasta/>

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 17:09:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA21468 for xemacs-beta-people; Fri, 21 Jun 1996 17:09:12 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA21465 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 17:09:11 -0500 (CDT)
Received: from ives.phx.mcd.mot.com ([144.191.22.44]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA12474 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 17:09:12 -0500 (CDT)
Received: by ives.phx.mcd.mot.com (8.6.8.2/1.34.ives)
	id PAA26999; Fri, 21 Jun 1996 15:13:51 -0700
Date: Fri, 21 Jun 1996 15:13:51 -0700
Message-Id: <199606212213.PAA26999@ives.phx.mcd.mot.com>
From: "Lynn D. Newton" <lnewton@ives.phx.mcd.mot.com>
To: XEmacs Beta Bugs <xemacs-beta@cs.uiuc.edu>
Subject: XEmacs19.14 p1 success on Motorola SVR4
Reply-To: lnewton@ives.phx.mcd.mot.com
X-Face:  FVNLrR&aQu[q[N3kO<A5Au*4b"pWyOi13$\H%OVNM8&P{?7;KTRLXSU)c'&Gg3{7GD.p:05
 To5$NCN#r-;vs&Qi@jhk\a@l;bMgx77!GI>4+!:X-+LgxFf'("(:8&7z+:!,24n1@j?C25:p>hno)_
 hPa5S&WgH"E-!{{N^-Cx}MiI_O'dU0
Comments: Hyperbole mail buttons accepted, v03.19.01.


Just reporting in ... Prerelease 1 OK on Motorola 88K
Delta running SVR4 (R40V4.4):

./configure --prefix=${INSTTREE} \
	--with-gnu-make \
	--cflags=-O2 \
	--site-includes=/usr/tools/remote/contrib/xpm/include \
	--site-libraries=/usr/tools/remote/lib \
	--dynamic=yes \
        --with-scrollbars=lucid \
	--with-menubars=lucid \
        --with-dialogs=no \
	--with-xpm 

So far it's running OK. The last couple of betas seem
to be considerably faster than the b15 I limped along
with for far too long. Which is a relief.

===============================================
Lynn D. Newton
Motorola Computer Group
===============================================

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 17:21:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA21577 for xemacs-beta-people; Fri, 21 Jun 1996 17:21:00 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA21574 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 17:20:58 -0500 (CDT)
Received: from ives.phx.mcd.mot.com ([144.191.22.44]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA12740 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 17:21:00 -0500 (CDT)
Received: by ives.phx.mcd.mot.com (8.6.8.2/1.34.ives)
	id PAA27450; Fri, 21 Jun 1996 15:25:54 -0700
Date: Fri, 21 Jun 1996 15:25:54 -0700
Message-Id: <199606212225.PAA27450@ives.phx.mcd.mot.com>
From: "Lynn D. Newton" <lnewton@ives.phx.mcd.mot.com>
To: XEmacs Beta Bugs <xemacs-beta@cs.uiuc.edu>
CC: randy_clayton@ives.phx.mcd.mot.com, steve_march@ives.phx.mcd.mot.com
Subject: delete-frame broken
Reply-To: lnewton@ives.phx.mcd.mot.com

X-Face:  FVNLrR&aQu[q[N3kO<A5Au*4b"pWyOi13$\H%OVNM8&P{?7;KTRLXSU)c'&Gg3{7GD.p:05
 To5$NCN#r-;vs&Qi@jhk\a@l;bMgx77!GI>4+!:X-+LgxFf'("(:8&7z+:!,24n1@j?C25:p>hno)_
 hPa5S&WgH"E-!{{N^-Cx}MiI_O'dU0
Comments: Hyperbole mail buttons accepted, v03.19.01.


Platform is SVR4 on Motorola 88K delta.

Bad news. This sounds vaguely like something I caught
the thread of while scanning the last several dozen
messages, so sorry if this is old. I have time only to
pay close attention to the things relative to our own
platforms ... This has happened twice:

I run M-x vm-mail, compose mail, then send it. The
"Sending ... done" message appears below. But the frame
does *not* go away. Furthermore, although its contents
are visible, it is essentially a dead frame. I move the
mouse to the frame and select it, and start typing, but
input is being read by the frame I just left. I can't
kill the frame. Then it appears I can't execute M-x
delete-frame at all, i.e., I try it directly on another
frame, and it inherits the same condition as the mail
frame. Bummer.

This didn't happen in b26.

===============================================
Lynn D. Newton
Motorola Computer Group
===============================================

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 17:38:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA21705 for xemacs-beta-people; Fri, 21 Jun 1996 17:38:14 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA21702 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 17:38:13 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA13086 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 17:38:15 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA11340; Fri, 21 Jun 1996 17:38:11 -0500 (CDT)
Message-Id: <199606212238.RAA11340@charles.cs.uiuc.edu>
To: Bill Dubuque <wgd@martigny.ai.mit.edu>
cc: mrb@eng.sun.com, xemacs-beta@cs.uiuc.edu
Subject: Re: ``XEmacs does not have the features to support lazy-lock.el'' 
In-reply-to: Your message of "Fri, 21 Jun 1996 18:32:46 EDT."
             <199606212232.RAA13012@a.cs.uiuc.edu> 
Date: Fri, 21 Jun 1996 17:38:10 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Bill> I disagree. FontiFly, the original lazy fontifier, works
    Bill> fine in XEmacs (in Win-Emacs to be precise, and there's no
    Bill> reason why it couldn't be upgraded from 19.6 to 19.14 if I
    Bill> had some spare time).

I had already talked to Simon about this before Martin sent this
message.  The intended statement was:

	'XEmacs does not have the features to support _this_ _version_
	 of lazy-lock.el'

Which is true enough.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 17:32:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA21683 for xemacs-beta-people; Fri, 21 Jun 1996 17:32:50 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA21680 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 17:32:49 -0500 (CDT)
Received: from martigny.ai.mit.edu (berne.ai.mit.edu [18.43.0.252]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA13012 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 17:32:51 -0500 (CDT)
Message-Id: <199606212232.RAA13012@a.cs.uiuc.edu>
Received: by martigny.ai.mit.edu
	(1.37.109.4/16.2) id AA16909; Fri, 21 Jun 96 18:32:46 -0400
Date: Fri, 21 Jun 96 18:32:46 -0400
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
To: mrb@eng.sun.com
Cc: xemacs-beta@cs.uiuc.edu
In-Reply-To: Martin Buchholz's message of Wed, 19 Jun 1996 18:41:28 -0700 <199606200141.SAA27212@xemacs.eng.sun.com>
Subject: ``XEmacs does not have the features to support lazy-lock.el''

  Date: Wed, 19 Jun 1996 18:41:28 -0700
  From: Martin Buchholz <mrb@eng.sun.com>

  Here is an excerpt from the recently posted lazy-lock.el, which
  suggests that XEmacs is deficient...

  ;; Currently XEmacs does not have the features to support lazy-lock.el.
  ;; Maybe it will one day.

I disagree. FontiFly, the original lazy fontifier, works fine in
XEmacs (in Win-Emacs to be precise, and there's no reason why it
couldn't be upgraded from 19.6 to 19.14 if I had some spare time).

Of course thats not saying that there shouldn't be display hooks
introduced. Chuck and I discussed this long ago but I don't
believe he has implemented anything yet.

Hacking fontifiers can be a very painstaking process and it may
well be that Simon just gave up on XEmacs after having pulled
out enough hair getting it working under FSF.

-Bill

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 17:56:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA21775 for xemacs-beta-people; Fri, 21 Jun 1996 17:56:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA21772 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 17:55:59 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA21512 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 17:55:56 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id PAA09836; Fri, 21 Jun 1996 15:55:43 -0700
Date: Fri, 21 Jun 1996 15:55:43 -0700
Message-Id: <199606212255.PAA09836@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: xemacs-beta@xemacs.org
Subject: 19.14-p1 on SunOS 4.1.3
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.48)
Content-Type: text/plain; charset=US-ASCII

Ok, I've built 19.14-p1 on SunOS 4.1.3_U1, and everything seems fine
(after adding Chuck's patch for the frame problem).  I have noticed my
frames-not-getting-problem, but it seems to be a little bit better
today.

Anyway, here's my config:
	./configure --site-libraries=/local/lib
	--site-includes=/local/include --with-xpm --with-xface
	--with-sound=native --with-gif --with-jpeg --with-png
	--prefix=/local/beta --dynamic

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 18:12:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA21861 for xemacs-beta-people; Fri, 21 Jun 1996 18:12:22 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA21858 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 18:12:21 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA13710 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 18:12:24 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA11434; Fri, 21 Jun 1996 18:12:16 -0500 (CDT)
Message-Id: <199606212312.SAA11434@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14p1: Solaris 2.5, SunPro CC 4.0, CDE 
In-reply-to: Your message of "21 Jun 1996 13:42:54 PDT."
             <m2k9x03n3l.fsf@deanna.miranova.com> 
Date: Fri, 21 Jun 1996 18:12:16 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Steven> If you can use --debug=no, then it should be documented
    Steven> that way in configure.  I was poking around through
    Steven> configure --help last night prior to building p1, and from
    Steven> the documentation could see no obvious way to turn it off,
    Steven> as it implies that --debug does not take a parameter.

>From the top of the help message:

Note that for most of the following options, you can explicitly enable
them using \`--OPTION=yes' and explicitly disable them using \`--OPTION=no'.
This is especially useful for auto-detected options.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 18:56:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA22034 for xemacs-beta-people; Fri, 21 Jun 1996 18:56:22 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA22031 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 18:56:21 -0500 (CDT)
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA14427 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 18:56:22 -0500 (CDT)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0uXG3m-00002AC>; Sat, 22 Jun 96 01:56 MET DST
Message-Id: <m0uXG3m-00002AC@susan.logware.de>
Date: Sat, 22 Jun 96 01:56 MET DST
From: Michael Diers <mdiers@logware.de>
To: XEmacs beta list <xemacs-beta@cs.uiuc.edu>
Subject: [19.14-p1] FreeBSD 2.1 success w/ frame patch

19.14-p1 w/ frame patch is fine on FreeBSD 2.1-STABLE. Most all
compiler optimizations enabled. Will link against xpm-3.4h first thing
tomorrow morning.

[I vaguely remember that xpm-3.4h didn't do much at all for my
 platform, as compared to 4.3f-patched. What about the other new libs
 in ftp.xemacs.org:/pub/beta/aux?] 

-Michael

--
XEmacs 19.14-p1

FreeBSD 2.1-STABLE (4.4BSD), XFree86 3.1.2 (X11R6), gcc 2.6.3

xpm 3.4f-patched, compface-19900129, jpeg-6, libpng-0.87, zlib-0.95
  (statically linked)

/usr/contrib/pub/src/xemacs-19.14-p1/configure i386-unknown-freebsd2.1
--verbose --extra-verbose
--site-includes=/usr/contrib/include --site-libraries=/usr/contrib/lib
--srcdir=/usr/contrib/pub/src/xemacs-19.14-p1
--prefix=/usr/contrib/pkg/xemacs-19.14-p1
--bindir=/usr/contrib/pkg/xemacs-19.14-p1/i386-unknown-freebsd2.1/bin
--cflags=-O3 -m486 -fno-strength-reduce -pipe
--error-checking=none --debug=no

Configured for `i386-unknown-freebsd2.1'.

  Where should the build process find the source code?    /usr/contrib/pub/src/xemacs-19.14-p1
  What installation prefix should install use?		  /usr/contrib/pkg/xemacs-19.14-p1
  What operating system and machine description files should XEmacs use?
        `s/freebsd.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -O3 -m486 -fno-strength-reduce -pipe
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/contrib/include
  Additional libraries:                                   /usr/contrib/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 19:30:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA22149 for xemacs-beta-people; Fri, 21 Jun 1996 19:30:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA22146 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 19:30:37 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA28803 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 19:30:33 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id RAA11379; Fri, 21 Jun 1996 17:29:50 -0700
Date: Fri, 21 Jun 1996 17:29:50 -0700
Message-Id: <199606220029.RAA11379@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: Mike Scheidler <c23mts@eng.delcoelect.com>
CC: xemacs-beta@xemacs.org
Subject: Smileys and VM
In-Reply-To: <21255.835384597@kocrsw12>
References: <vk20j92e7s.fsf@cdc.noaa.gov>
	<21255.835384597@kocrsw12>
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.48)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Mike" == Mike Scheidler <c23mts@eng.delcoelect.com> writes:

    >> :-] :-o :-) ;-) :-\ :-| :-d :-P 8-| :-(
    >> 
    >> Sorry. Just discovered smiley.el and want to test it out.

    Mike> I just found it yesterday myself.  I don't recall seeing
    Mike> anything in the announcements about this new,
    Mike> can't-live-without package.  :-P ;-)

So, has anyone written a VM hook for it yet? :-)

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 19:43:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA22288 for xemacs-beta-people; Fri, 21 Jun 1996 19:43:53 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA22285 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 19:43:52 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA28846 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 19:43:49 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA11650 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 19:43:52 -0500 (CDT)
Message-Id: <199606220043.TAA11650@charles.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: Re: Smileys and VM 
In-reply-to: Your message of "Fri, 21 Jun 1996 17:29:50 PDT."
             <199606220029.RAA11379@sandman.cisco.com> 
Date: Fri, 21 Jun 1996 19:43:52 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Dan> So, has anyone written a VM hook for it yet? :-)

Forgot to send this to the list :-)  For mh-e:

(add-hook 'mh-show-mode-hook '(lambda () (smiley-region (point-min)
							(point-max))))



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 20:48:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA22408 for xemacs-beta-people; Fri, 21 Jun 1996 20:48:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA22405 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 20:48:56 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA03107 for <xemacs-beta@xemacs.org>; Fri, 21 Jun 1996 20:48:53 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id SAA19503; Fri, 21 Jun 1996 18:48:40 -0700
Date: Fri, 21 Jun 1996 18:48:40 -0700
Message-Id: <199606220148.SAA19503@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: xemacs-beta@xemacs.org
Subject: gnuattach weirdness
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.48)
Content-Type: text/plain; charset=US-ASCII

I just found two problems using gnuattach (and I think someone already
mentioned the first, but I never saw any discussion about it).

If you run gnuattach with no arguments, there is no way to exit that I
can find.  C-x # won't do it, and C-x C-c kills the XEmacs process (as
you would expect).

The real weird one happened when I connected to my VM summary buffer.
Any time I tried to read a message, it would popup my original VM
frame and display the message there.  However, if I split the window
and changed one of the buffers to be INBOX, everything worked fine.

When I returned to my shell, it was in a strange mode (I think it may
have just been that echo was off), and I had to 'stty sane' in order
to get things working again. 

BTW, for those of you praising smiley mode, where does
message-xmas-find-glyph-directory come from?  I'm not finding it when
I do a (require 'smiley).

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 21 23:17:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA22861 for xemacs-beta-people; Fri, 21 Jun 1996 23:17:57 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA22858 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 21 Jun 1996 23:17:56 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA24702 for <xemacs-beta@cs.uiuc.edu>; Fri, 21 Jun 1996 23:17:59 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id VAA27887; Fri, 21 Jun 1996 21:17:11 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: cthomp@xemacs.org
Subject: Re: gnuattach weirdness
References: <199606220148.SAA19503@sandman.cisco.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Dan Rich's message of Fri, 21 Jun 1996 18:48:40 -0700
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 21 Jun 1996 21:17:10 -0700
Message-ID: <m2g27oo4l5.fsf@deanna.miranova.com>
Lines: 15
X-Mailer: Gnus v5.2.24/XEmacs 19.14

>>>>> "Dan" == Dan Rich <drich@cisco.com> writes:

Dan> BTW, for those of you praising smiley mode, where does
Dan> message-xmas-find-glyph-directory come from?  I'm not finding it when
Dan> I do a (require 'smiley).

Ouch!  This isn't fixed by Gnus 5.2.24 either.  smiley.el either needs
a (require 'messagexmas), or message-xmas-find-glyph-directory needs
to be autoload in messagexmas.el.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 04:26:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA27097 for xemacs-beta-people; Sat, 22 Jun 1996 04:26:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA27094 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 04:26:27 -0500 (CDT)
Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA26064 for <xemacs-beta@xemacs.org>; Sat, 22 Jun 1996 04:26:24 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA26676; Sat, 22 Jun 1996 02:22:06 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA28913; Sat, 22 Jun 1996 11:22:03 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA00027; Sat, 22 Jun 1996 11:22:02 +0200
Date: Sat, 22 Jun 1996 11:22:02 +0200
Message-Id: <9606220922.AA00027@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: DUNIX 14p1 static patch
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

I did a trial build for the (static) distribution.  Here's patch to
select the corresponding (new) header file.

It would be possible to patch decosf3-1-static.h instead, but then
the static and dynamic configuration names would not be in synch.

        Steve


New file src/s/decosf-3-2-static.h:

/* Synched up with: Not in FSF. */

#include "decosf3-2.h"

#ifdef NOT_C_CODE
/* This is to get rid of the definition that selects dynamic linking. */
#undef LD_SWITCH_CALL_SHARED
#ifdef USE_GCC
#define LD_SWITCH_CALL_SHARED -static -Xlinker -non_shared
#else
#define LD_SWITCH_CALL_SHARED -non_shared
#endif /* USE_GCC */
#endif /* NOT_C_CODE */



Patch file:

*** configure.dist	Thu Jun 20 19:48:35 1996
--- configure	Sat Jun 22 11:10:19 1996
***************
*** 2354,2359 ****
--- 2354,2360 ----
      sol2-4		) opsys=sol2-4-static ;;
      decosf1-3		) opsys=decosf1-3-static ;;
      decosf3-1		) opsys=decosf3-1-static ;;
+     decosf3-2		) opsys=decosf3-2-static ;;
      linux		) opsys=linux-static ;;
    esac
  fi


From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 12:15:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA27681 for xemacs-beta-people; Sat, 22 Jun 1996 12:15:12 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA27678 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 12:15:11 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA09990 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 12:15:12 -0500 (CDT)
Message-Id: <199606221715.MAA09990@a.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA143863715; Sat, 22 Jun 1996 18:15:15 +0100
Date: Sat, 22 Jun 1996 18:15:15 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@cs.uiuc.edu
Subject: p1 hangs in gnus.
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



This is something I got with b24, and was apparently OK in b26: Wen
launching gnus (through M-x or toolbar), xemacs would hang while
showing "loading gnus-vis...Done".

Trouble is, it apparently happen only when compiling with optimization
on. And HPUX cannot give any valid backtrace on the optimized exec.

I'll check with 10.01, to see if it's better.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 12:06:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA27674 for xemacs-beta-people; Sat, 22 Jun 1996 12:06:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA27671 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 12:06:13 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA29528; Sat, 22 Jun 1996 12:06:09 -0500 (CDT)
Message-Id: <199606221706.MAA29528@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA143673145; Sat, 22 Jun 1996 18:05:45 +0100
Date: Sat, 22 Jun 1996 18:05:45 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: Re: frame bug patch
In-Reply-To: <199606211811.NAA20255@xemacs.cs.uiuc.edu>
References: <199606211811.NAA20255@xemacs.cs.uiuc.edu>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

    Chuck> Please apply this and let me know as soon as possible if 1)
    Chuck> it corrects the problems 2) introduces some new ones or 3)
    Chuck> makes things worse :-)

Fixes things for me.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 12:56:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA27797 for xemacs-beta-people; Sat, 22 Jun 1996 12:56:52 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA27794 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 12:56:51 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA10388 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 12:56:52 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA31240; Sat, 22 Jun 1996 10:56:05 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Multiple Frame minibuffer BEEP/oddity in p1
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 22 Jun 1996 10:56:03 -0700
Message-ID: <m2688j90zw.fsf@deanna.miranova.com>
Lines: 42
X-Mailer: Gnus v5.2.24/XEmacs 19.14

I do not believe this constitutes a bug in Gnus, or Supercite.  I
also believe its too late to deal with this for 19.14.  The biggest
problem I've observed with XEmacs novices around here has been them
selecting a minibuffer prompting function, and then getting messed up
in similar fashion.


Required for this demonstration a window manager with
focus-follows-mouse policy set, and Supercite attached to the
message-cite-function.  I can repeat this at will.

Repeat by:
+ Select any group and read a message.
+ From the message buffer, do C-x 5 b *Group*
  (Wave the mouse in & out of the window since the focus is erroneously
  warped to the new frame).
+ Select a new group and enter it.
+ Reply or Followup to a message.
+ You will now be seeing a prompt like ``Complete attribution name: Lars''
+ Move the mouse back to the original frame and the minibuffer prompt
  follows the mouse.
+ Now here's the problem, the minibuffer looks active, but is not.
  C-x o normally will place the cursor in an active minibuffer, but will
  not in this case.
+ With the mouse, click the left button on the unselectable minibuffer and
  hit ENTER.

Signalling: (args-out-of-range #<buffer " *Minibuf-0*"> #<marker at 490 in *reply to Lars Magne Ingebrigtsen*> #<marker at 2341 in *reply to Lars Magne Ingebrigtsen*>)
  count-lines(#<marker at 490 in *reply to Lars Magne Ingebrigtsen*> #<marker at 2341 in *reply to Lars Magne Ingebrigtsen*>)
  sc-cite-original()
  message-yank-original()
  gnus-inews-yank-articles((115))
  gnus-post-news(nil "nnml:xemacs-beta-discuss" [115 "Odd .gz bug" "Lars Magne Ingebrigtsen <larsi@ifi.uio.no>" "22 Jun 1996 11:45:45 +0200" "<w8su3w4rx2u.fsf@ylfing.ifi.uio.no>" "" 1850 43 "Xref: deanna.miranova.com xemacs-beta-discuss:115"] "*Article nnml:xemacs-beta-discuss*" (115) nil nil)
  gnus-summary-followup((115) nil)
  gnus-summary-followup-with-original(nil)
  call-interactively(gnus-summary-followup-with-original)

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 13:02:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA27818 for xemacs-beta-people; Sat, 22 Jun 1996 13:02:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA27815 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 13:02:22 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA10470 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 13:02:24 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA12698; Sat, 22 Jun 1996 13:02:18 -0500 (CDT)
Message-Id: <199606221802.NAA12698@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Multiple Frame minibuffer BEEP/oddity in p1 
In-reply-to: Your message of "22 Jun 1996 10:56:03 PDT."
             <m2688j90zw.fsf@deanna.miranova.com> 
Date: Sat, 22 Jun 1996 13:02:18 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Steven> I do not believe this constitutes a bug in Gnus, or
    Steven> Supercite.  I also believe its too late to deal with this
    Steven> for 19.14.  The biggest problem I've observed with XEmacs
    Steven> novices around here has been them selecting a minibuffer
    Steven> prompting function, and then getting messed up in similar
    Steven> fashion.

You're right.  It's way too late since the final release is already
tarred up.  As soon as I finish up some ftp site changes it will be
available.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 13:40:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA27961 for xemacs-beta-people; Sat, 22 Jun 1996 13:40:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA27958 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 13:40:46 -0500 (CDT)
Received: from caviar.cv.ruu.nl (caviar.cv.ruu.nl [131.211.149.16]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA10960 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 13:40:48 -0500 (CDT)
Received: from triton.cv.ruu.nl (triton.cv.ruu.nl [131.211.148.17]) by caviar.cv.ruu.nl (8.7.5/8.7.3) with ESMTP id UAA00129 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 20:40:44 +0200 (METDST)
Received: from wodan.cv.ruu.nl (wodan.cv.ruu.nl [131.211.148.21]) by triton.cv.ruu.nl (8.7.5/8.7.3) with ESMTP id UAA26330 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 20:40:49 +0200 (METDST)
From: Fred Appelman <Fred.Appelman@cv.ruu.nl>
Received: (fred@localhost) by wodan.cv.ruu.nl (8.6.12/8.6.12) id UAA15418 for xemacs-beta@cs.uiuc.edu; Sat, 22 Jun 1996 20:40:42 +0200
Message-Id: <199606221840.UAA15418@wodan.cv.ruu.nl>
Subject: No success on Unixware-2.03
To: xemacs-beta@cs.uiuc.edu
Date: Sat, 22 Jun 1996 20:40:42 +0200 (METDST)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

I am trying to compile 19.14.b26 on the Unixware 2.03 compiler. 
So far I have not succeeded. I get the following configuratino from
the configure script:

Configured for `i586-unixware-sysv4.2'.

  Where should the build process find the source code?
                                    /net/xemacs-19.14.b26/xemacs-19.14-b26
  What installation prefix should install use? 
                                    /usr/local/packages/xemacs-19.14.b26
  What operating system and machine description files should XEmacs
use?
        `s/usg5-4-2.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -O
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?
/usr/X11R6/include
  Where do we find X Windows libraries?
/usr/X11R6/lib
  Compiling in support for SOCKS.
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  No Xmu; substituting equivalent routines.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for GNU DBM.
  Compiling in support for SOCKS.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


During the creating of the various file I get the following message:
[snip]
creating dynodump/Makefile.in
creating src/config.h
Segmentation Fault - core dumped
src/config.h is unchanged

Is there an easy way to better pin-point the source of the problems?

	Fred
-- 
Fred J.R. Appelman - Room E01.334      E-mail: Fred.Appelman@cv.ruu.nl
Department of Image Sciences           Tel: +31-30-2506710
Imaging Center Utrecht                 Fax: +31-30-2513399
University Hospital Utrecht, Heidelberglaan 100, 3584 CX Utrecht, Holland

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 14:30:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA28082 for xemacs-beta-people; Sat, 22 Jun 1996 14:30:35 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA28079 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 14:30:33 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA03140 for <xemacs-beta@xemacs.org>; Sat, 22 Jun 1996 14:30:31 -0500 (CDT)
Message-Id: <199606221930.OAA03140@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.14
Date: Sat, 22 Jun 1996 14:30:29 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/xemacs-19.14.

After almost 10 months, the end is near.  The patch from p1 to the
release is in the normal ftp directory.  /pub/xemacs-19.14 will become
/pub/xemacs tomorrow.  /pub/aux should now be up-to-date for the
release.  With the creation of XEmacs own ftp site not everything will
be shoved down underneath the /pub/xemacs directory anymore.  aux and
infodock have already been moved out.  contrib, docs, mlists will be
moving to the pub level as well.

I'll send out a list of who should build what binary kits shortly.  In
the meantime, please pull back the full release and make sure I didn't
screw anything up.


			-Chuck



-- gnus 5.2.25
-- fixed frame deletion problem introduced in pre-release
-- fixed problem with iconification introduced in b26
-- XEmacs web page entries on help menu now reference
   browse-url-browser-function
-- error checking off by default

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 15:40:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA28258 for xemacs-beta-people; Sat, 22 Jun 1996 15:40:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA28255 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 15:40:47 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA06753 for <xemacs-beta@xemacs.org>; Sat, 22 Jun 1996 15:40:44 -0500 (CDT)
Message-Id: <199606222040.PAA06753@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: 19.14 binary kits
Date: Sat, 22 Jun 1996 15:40:44 -0500
From: Chuck Thompson <cthomp@xemacs.org>

As already noted, the final 19.14 distribution is now at:

	ftp.xemacs.org:/pub/xemacs-19.14


Please check out the README and let me know about
mistakes/ommisions/anything else.  Below are the instructions for
making binary kits.  Get them to me as soon as you can.  Put them at
ftp.xemacs.org:/pub/beta/incoming.

If you are building a binary kit, build it from the full source
distribution.  DO NOT build binary kits from a patched source tree.
If this causes undo hardship for you, please let me know and I'll find
someone else to build the binary kits.  Sorry for not mentioning this
sooner.

The list of volunteers follows.  If I got it wrong, let me know.
Thanks for all of the help.


			-Chuck


NOTE: These binary kit names are not something completely set in stone.  If
      a better name fits what you actually build then use it.


 Thompson <cthomp@xemacs.org>
	README
	README.executables
	xemacs-19.14.tar.gz
	xemacs-19.14-common.tar.gz
	xemacs-19.14-sparc-sun-solaris2.4.tar.gz
	xemacs-19.14-sparc-sun-solaris2.4-sparcworks.tar.gz

Martin Buchholz <mrb@eng.sun.com>
	xemacs-19.14-i386-unknown-solaris2.4.tar.gz
	xemacs-19.14-i386-unknown-solaris2.4-sparcworks.tar.gz
	xemacs-19.14-sparc-sun-sunos4.1.3.tar.gz
	xemacs-19.14-sparc-sun-sunos4.1.3-sparcworks.tar.gz

Michael Diers <mdiers@logware.de>
	xemacs-19.14-i386-unknown-freebsd2.1.0.tar.gz

Michael Sperber <sperber@informatik.uni-tuebingen.de>
	xemacs-19.14-rs6000-ibm-aix4.1.4.tar.gz

Richard Cognot <cognot@ensg.u-nancy.fr>
	xemacs-19.14-hppa1.1-hp-hpux9.05.tar.gz
	xemacs-19.14-hppa1.1-hp-hpux10.01.tar.gz
	xemacs-19.14-hppa1.1-hp-hpux10.10.tar.gz
	xemacs-19.14-mips-sgi-irix5.3.tar.gz
	xemacs-19.14-mips-sgi-irix6.2.tar.gz

Stephen Carney <carney@gvc.dec.com>
	xemacs-19.14-alpha-dec-osf3.2.tar.gz
	xemacs-19.14-alpha-dec-osf4.0.tar.gz

Ketil Z Malde <ketil@ii.uib.no>
	xemacs-19.14-alpha-dec-linux2.0.tar.gz

Christopher Davis <ckd@loiosh.kei.com>
	xemacs-19.14-i386-unknown-bsdi2.1.tar.gz

Linux Builds: I'm going to let the three of you hash out who does
	      what.  I'm including what I would like to have.  If you
	      can't cover all of them, please send a message to the
	      beta list telling what still needs to be done.  If
	      someone of these are worthless, let me know.

Benedikt Eric Heinen <beh@icemark.thenet.ch>
Steven L Baur <steve@miranova.com>
Markus Gutschke <gutschk@ESCHER.UNI-MUENSTER.DE>

	xemacs-19.14-i486-unknown-linux2.0elf.tar.gz
	xemacs-19.14-i486-unknown-linux2.0elf-motif.tar.gz
	xemacs-19.14-i486-unknown-linux1.2.13elf.tar.gz
	xemacs-19.14-i486-unknown-linux1.2.13elf-motif.tar.gz
	xemacs-19.14-i486-unknown-linux1.2.13aout.tar.gz
	xemacs-19.14-i486-unknown-linux1.2.13aout-motif.tar.gz

SCO Builds: Same deal as Linux.  I kind of volunteered you.  I don't
	    know what actual versions are needed.

"J. Kean Johnston" <jkj@paradigm-sa.com>
Robert Lipe <robertl@arnet.com>

	xemacs-19.14-i386-unknown-sco3.2v5.0.0.tar.gz


If anyone can do something close to the following, great.  If not, oh well.

	xemacs-19.14-rs6000-ibm-aix3.2.5.tar.gz
	xemacs-19.14-sparc-sun-sunos4.1.3-openwindows3.0.tar.gz



===============================================================================
The optimal binary kit would be built as such:

	--with-menubars=lucid
	--with-scrollbars=lucid
	--with-dialogs=motif	if you have Motif
	--with-xpm		important - please use xpm 3.4h
	--with-xface
	--with-tooltalk		if you've got it
	--with-sound=native	if your system has it
	--with-sound=both	if you've got netaudio (else don't sweat it)
	--with-gif
	--with-png
	--with-jpeg
	--with-database		if you've got one

Compile with the highest level of optimization you feel comfortable
with.  Do not, under any circumstances, strip the binary.

If you don't have Motif then build with Athena dialogs instead.  Do
not change the menubar or scrollbar toolkit without talking to me
first.

I'm relaxing the static!, static!, static! rule somewhat.  Any
standard system library may be dynamically linked.  Any library which
might not be installed on a system MUST be statically linked.  Let me
repeat that.  ANY library which might not be installed on a system
MUST be statically linked.

Basically if a library doesn't get installed when doing the most
minimal install of the OS, or if there is quite a bit of variation
between installations of the OS (e.g. Linux) then you should be
linking statically.

Libraries which should definitely be statically linked include:

	XPM
	compface
	Motif
	JPEG
	PNG

If you use something like Athena3d, that's fine, but make sure the
thing is statically linked.

Do your builds with

	USRLOCAL=/usr/local
	CONFIG=`./config.guess`

	./configure $CONFIG			\
	  --prefix=$USRLOCAL			\
	  --bindir=$USRLOCAL/bin/$CONFIG

$USRLOCAL can be anything you want, it doesn't matter - all the pathnames
will be relative to that by the time I see them.

Use ldd or your system equivalent on all of the executables (xemacs
itself, and the lib-src executables) to verify that they are linked
the way you think they are linked.

The tar file you send me should then contain a README, and two directories:
bin/$CONFIG/ and lib/xemacs-19.14/$CONFIG/, which should contain no more
(and no less) than the following files:

	README.$CONFIG
	bin/$CONFIG/
	bin/$CONFIG/b2m
	bin/$CONFIG/ctags
	bin/$CONFIG/emacsclient
	bin/$CONFIG/etags
	bin/$CONFIG/gnuattach
	bin/$CONFIG/gnuclient
	bin/$CONFIG/gnudoit
	bin/$CONFIG/rcs-checkin
	bin/$CONFIG/xemacs symbolic link to xemacs-19.14
	bin/$CONFIG/xemacs-19.14
	lib/xemacs-19.14/$CONFIG/
	lib/xemacs-19.14/$CONFIG/DOC-19.14-XEmacs
	lib/xemacs-19.14/$CONFIG/cvtmail
	lib/xemacs-19.14/$CONFIG/digest-doc
	lib/xemacs-19.14/$CONFIG/emacsserver
	lib/xemacs-19.14/$CONFIG/fakemail
	lib/xemacs-19.14/$CONFIG/gnuserv
	lib/xemacs-19.14/$CONFIG/hexl
	lib/xemacs-19.14/$CONFIG/make-docfile
	lib/xemacs-19.14/$CONFIG/make-path
	lib/xemacs-19.14/$CONFIG/movemail
	lib/xemacs-19.14/$CONFIG/profile
	lib/xemacs-19.14/$CONFIG/rcs2log
	lib/xemacs-19.14/$CONFIG/sorted-doc
	lib/xemacs-19.14/$CONFIG/vcdiff
	lib/xemacs-19.14/$CONFIG/wakeup
	lib/xemacs-19.14/$CONFIG/yow


This is the directory setup that you will get if you just do "make install".

I am actually a little bit picky about file permissions and ownership
in this file, but don't worry too much. I repack all distributions
before I put them on the ftp site.

What follows is a sample README.$CONFIG.  Your READMEs should look
approximately like this, with appropriate query-replace results.
However, do mention anything else you think needs to be mentioned.

And of course, attempt an installation as described in the README, on a
different machine if possible.

When you're done, dump them in ftp.xemacs.org:/pub/beta/incoming/.
Please also put there the config.status file you used to build the kit.

Thanks!

------------------------------------------------------------------------------

This directory contains Solaris 2.4 executables for XEmacs 19.14.
These were compiled with Motif, XPM, X-Face, ToolTalk, PNG, GIF, JPG,
DBM, full optimization, and have system libraries dynamically
linked and all others statically linked.

Built by Chuck Thompson <cthomp@xemacs.org>

The tar file which contains these executables contains only the
executables (the architecture-dependent files.)  To use these
executables, you will also need the architecture-independent files
(the `lisp', `etc' and `info' directories.)  These files are
distributed in a seperate file (xemacs-19.14-common.tar.gz.)

HOW TO INSTALL
==============

Simply cd to the directory in which you wish to install xemacs,
and then unpack the architecture independent tar file, followed by
the architecture-dependent files for those architectures you use.

  cd /usr/local/	# or wherever you install 3rd-party software
  gzip -dc xemacs-19.14-common.tar.gz | tar -pxf -
  gzip -dc xemacs-19.14-sparc-sun-solaris2.4.tar.gz | tar -pxf -

Replace `/usr/local/' with what you like, but it probably ought not
have `xemacs' or a version number in it - that directory is expected
to be the common prefix for installed software, and xemacs-specific
subdirectories of it will be created.  The directories are arranged
in such a way that multiple versions of xemacs can peaceably coexist
under the same `/usr/local/' tree.

After unpacking, you will have a directory structure like:

  ./bin/sparc-sun-solaris2.4/xemacs-19.14*	executable
  ./lib/xemacs-19.14/lisp/			lisp library
  ./lib/xemacs-19.14/etc/			data directory
  ./lib/xemacs-19.14/info/			documentation
  ./lib/xemacs-19.14/sparc-sun-solaris2.4/	utility programs
  ./lib/xemacs/lock/				lock directory
  ./lib/xemacs/site-lisp/			local lisp code

For the executable to work, the directory layout must look pretty
much like this; the executable looks for "sibling" directories at
run-time to figure out where its lisp library is.  These constraints
on the local directory layout are necessary to avoid having to
hardcode pathnames into the executables, or require that environment
variables be set before running the executable.  You will probably
want to create a link such as the following:

  $LOCAL/bin/xemacs -> ./bin/sparc-sun-solaris2.4/xemacs-19.14


It is possible to do a multi-architecture in such a way that the
executables for the various architectures are on different
partitions; in that case you must install some symbolic links so
that the directory structure appears as above from the clients.

For example, assume that $LOCAL refers to a directory which is
mounted only on machines of the same type; and $SHARED refers to
a directory which is shared among all machines.  You could set up
the directory hierarchy like this:

  $LOCAL/bin/xemacs-19.14*
  $LOCAL/lib/xemacs-19.14/sparc-sun-solaris2.4/
  $LOCAL/lib/xemacs-19.14/lisp@  ->  $SHARED/xemacs-19.14/lisp/
  $LOCAL/lib/xemacs-19.14/etc@   ->  $SHARED/xemacs-19.14/etc/
  $LOCAL/lib/xemacs-19.14/info@  ->  $SHARED/xemacs-19.14/info/
  $LOCAL/lib/xemacs@             ->  $SHARED/xemacs/

  $SHARED/xemacs-19.14/lisp/
  $SHARED/xemacs-19.14/etc/
  $SHARED/xemacs-19.14/info/
  $SHARED/xemacs/lock/
  $SHARED/xemacs/site-lisp/

That is, the various $SHARED directories contain only the
architecture-independent files, but still look like normal
installation trees, since the architecture-independent
directories have been replaced with symbolic links to the 
single $COMMON tree.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 16:33:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA28410 for xemacs-beta-people; Sat, 22 Jun 1996 16:33:19 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA28407 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 16:33:17 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA13114 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 16:33:20 -0500 (CDT)
Received: from solberg by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id PAA03503; Sat, 22 Jun 1996 15:33:10 -0600
Received: by solberg (SMI-8.6) id PAA14500; Sat, 22 Jun 1996 15:33:04 -0600
Sender: mdb@cdc.noaa.gov
To: xemacs-beta@cs.uiuc.edu
Cc: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>,
        "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
Subject: Re: Multiple Frame minibuffer BEEP/oddity in p1
References: <m2688j90zw.fsf@deanna.miranova.com>
Organization: CIRES, University of Colorado
X-Attribution: mb
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 22 Jun 1996 15:33:04 -0600
In-Reply-To: Steven L Baur's message of 22 Jun 1996 10:56:03 -0700
Message-ID: <vkwx0z8qy7.fsf@cdc.noaa.gov>
Lines: 67
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>> On 22 Jun 1996 10:56:03 -0700,
>> Steven L Baur(SLB) wrote:
SLB> I do not believe this constitutes a bug in Gnus, or Supercite.  I
SLB> also believe its too late to deal with this for 19.14.

I just came across some weird lossage using Gnus-5.2.2[45] and
>> Steven L Baur(SLB) wrote:Supercite. (<<<<< See it yet? :-)

When using gnus-followup-with-original(), the attribution header (the
>> Steven L Baur(SLB) wrote:second line above) is appended to every
>> Steven L Baur(SLB) wrote:line that wraps and is filled. It's
>> Steven L Baur(SLB) wrote:extremely annoying. I also have filladapt
>> Steven L Baur(SLB) wrote:turned on, but turning it off doesn't help
>> Steven L Baur(SLB) wrote:(unless it's too late by then).

Does anyone else see this? Can anyone but me decipher the above? I
have SC and filladapt hooks into VM, and it works fine there. This
paragraph was manually corrected for readability. 

Appended are my relevant supercite customizations. Barry, do you know
if the sc-setup-filladapt() function overwrite below is still needed?

	     ;; ******************
	     (defun sc-header-wrote ()
	       "\"<sc-author> wrote on <date>:\", unless 1. the \"author\" field cannot be found, in which case nothing is inserted; or 2. the \"date\" field is
missing in which case only the author part is printed."
	       (let ((sc-mumble-string "")
		     (whofrom (sc-whofrom)))
		 (if whofrom
		     (insert sc-reference-tag-string
			     (sc-hdr "On " (sc-mail-field "date") ",")
			     (sc-hdr "\n" sc-reference-tag-string (sc-mail-field "sc-author") "")
			     (sc-hdr "\(" (sc-mail-field "sc-attribution") "\) wrote:")
		 ))))

	     ;; ******************
		;Actually, it's caused by recent changes to
		;filladapt. Supercite3.1's sc-setup-filladapt no
		;longer works, but I think this is a version that
		;works with both old filladapt, and new filladapt.
		; -Barry
	     (defun sc-setup-filladapt ()
	       "Setup `filladapt-prefix-table' to handle Supercited paragraphs."
	       (let ((elt (if (boundp 'filladapt-prefix-table)
			      ;; old version of filladapt
			      (rassq 'filladapt-supercite-included-text
				     filladapt-prefix-table)
			    ;; new version of filladapt
			    (rassq 'supercite-citation filladapt-token-table))))
		 (if elt (setcar elt (sc-cite-regexp))
		   (message "Filladapt doesn't seem to know about Supercite.")
		   (beep))))
))

(add-hook 'sc-pre-cite-hook
	  '(lambda ()
	     (setq
	      sc-reference-tag-string ">> "
	      sc-citation-leader ""
	      sc-auto-fill-region-p nil
					; sc-nested-citation-p t
	      sc-citation-delimiter ">"
	      )
))

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 17:36:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA28577 for xemacs-beta-people; Sat, 22 Jun 1996 17:36:36 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA28574 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 17:36:35 -0500 (CDT)
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA15385 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 17:36:36 -0500 (CDT)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0uXbI8-00002AC>; Sun, 23 Jun 96 00:36 MET DST
Message-Id: <m0uXbI8-00002AC@susan.logware.de>
Date: Sun, 23 Jun 96 00:36 MET DST
From: Michael Diers <mdiers@logware.de>
To: XEmacs beta list <xemacs-beta@cs.uiuc.edu>
Subject: [19.14 release] success on FreeBSD 2.1

XEmacs 19.14 release configures, builds, installs, and runs w/o
problems on FreeBSD 2.1. Configuration according to Chuck's
guidelines, gcc 2.6.3 level 3 optimization (modulo strength
reduction).

The binary kit will be in sometime tomorrow. Looks like it's about
time to say Good Job, Team XEmacs!

-Michael


--
XEmacs 19.14 release

FreeBSD 2.1-STABLE (4.4BSD), XFree86 3.1.2 (X11R6), gcc 2.6.3
xpm-3.4h, compface-19900129, jpeg-6, libpng-0.87, zlib-0.95

NOTE: dynamically linked against X11 and system libs,
  statically linked against everything else

/usr/contrib/pub/src/xemacs-19.14/configure i386-unknown-freebsd2.1
  --verbose --extra-verbose
  --srcdir=/usr/contrib/pub/src/xemacs-19.14
  --prefix=/usr/contrib/pkg/xemacs-19.14
  --bindir=/usr/contrib/pkg/xemacs-19.14/bin/i386-unknown-freebsd2.1
  --site-includes=/usr/contrib/include --site-libraries=/usr/contrib/lib
  --cflags=-O3 -m486 -fno-strength-reduce -pipe
  --with-menubars=lucid --with-scrollbars=lucid --with-dialogs=athena
  --with-xpm --with-xface --with-gif --with-png --with-jpeg
  --with-database=berkdb,dbm

[...]

Configured for `i386-unknown-freebsd2.1'.

  Where should the build process find the source code?    /usr/contrib/pub/src/xemacs-19.14
  What installation prefix should install use?		  /usr/contrib/pkg/xemacs-19.14
  What operating system and machine description files should XEmacs use?
        `s/freebsd.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -O3 -m486 -fno-strength-reduce -pipe
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/contrib/include
  Additional libraries:                                   /usr/contrib/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 17:40:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA28600 for xemacs-beta-people; Sat, 22 Jun 1996 17:40:15 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA28597 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 17:40:14 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA15444 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 17:40:15 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id PAA05237; Sat, 22 Jun 1996 15:39:29 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs 19.14
References: <199606221930.OAA03140@xemacs.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Sat, 22 Jun 1996 14:30:29 -0500
Date: 22 Jun 1996 15:39:27 -0700
Message-ID: <m2lohfjwf4.fsf@deanna.miranova.com>
Lines: 84
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Chuck> I'll send out a list of who should build what binary kits
Chuck> shortly.  In the meantime, please pull back the full release
Chuck> and make sure I didn't screw anything up.

I'm not sure who's fault this is, probably mine ...

Doing a make in the man/lispref directory, generated a permission
denied error when attempting to make ../info/lispref.info.  When doing
a `make lispref.dvi' I ended up with the following error:

...
Output written on lispref.dvi (992 pages, 2518544 bytes).
Transcript written on lispref.log.
if [ a != a ]; \
then \
  ./permute-index; \
  mv permuted.fns lispref.fns; \
else \
  ../texindex lispref.??; \
fi
make: *** [lispref.dvi] Error 139

Just doing a texi2dvi lispref.texi seemed to work O.K.

I took the full release, and the build completed without error.

Configured for `i486-unknown-linux2.0.0'.

  Where should the build process find the source code?    /usr/local/src/xemacs-19.14
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.


advocacy.el is also broken :-(.
*** advocacy.el~	Sun Jun 16 12:37:40 1996
--- advocacy.el	Sat Jun 22 15:36:11 1996
***************
*** 47,55 ****
  			 (get-face (nth (random max-faces) (face-list))))
  	    (setq count (- count 1))))))
      (let ((sound-file
! 	   (or (file-exists-p xemacs-praise-sound-file)
! 	       (file-exists-p
! 		(concat data-directory xemacs-praise-sound-file)))))
        (if (and (device-sound-enabled-p) sound-file)
  	  (progn
  	    (sit-for 0)
--- 47,57 ----
  			 (get-face (nth (random max-faces) (face-list))))
  	    (setq count (- count 1))))))
      (let ((sound-file
! 	   (or (and (file-exists-p xemacs-praise-sound-file)
! 		    xemacs-praise-sound-file)
! 	       (and ((file-exists-p
! 		      (concat data-directory xemacs-praise-sound-file)))
! 		    (concat data-directory xemacs-praise-sound-file)))))
        (if (and (device-sound-enabled-p) sound-file)
  	  (progn
  	    (sit-for 0)

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 17:45:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA28609 for xemacs-beta-people; Sat, 22 Jun 1996 17:45:01 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA28606 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 17:44:59 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA15464 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 17:45:02 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA13053; Sat, 22 Jun 1996 17:44:54 -0500 (CDT)
Message-Id: <199606222244.RAA13053@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs 19.14 
In-reply-to: Your message of "22 Jun 1996 15:39:27 PDT."
             <m2lohfjwf4.fsf@deanna.miranova.com> 
Date: Sat, 22 Jun 1996 17:44:54 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Steven> I'm not sure who's fault this is, probably mine ...

The advocacy.el bug is my fault.  I'm going to go ahead and correct
the distribution.  That is not a function I want failing :-)


    Steven> Doing a make in the man/lispref directory, generated a
    Steven> permission denied error when attempting to make
    Steven> ../info/lispref.info.  When doing a `make lispref.dvi' I
    Steven> ended up with the following error:

The package script removes write permissions to all of the files.
Maybe it shouldn't for the info files.  Extremely minor since most
people don't rebuild the info files.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 17:58:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA28630 for xemacs-beta-people; Sat, 22 Jun 1996 17:58:58 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA28627 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 17:58:57 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA15569; Sat, 22 Jun 1996 17:58:59 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id PAA05501; Sat, 22 Jun 1996 15:58:07 -0700
Sender: steve@miranova.com
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs 19.14
References: <199606222244.RAA13053@charles.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Sat, 22 Jun 1996 17:44:54 -0500
Date: 22 Jun 1996 15:58:06 -0700
Message-ID: <m2g27njvk1.fsf@deanna.miranova.com>
Lines: 29
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

Steven> I'm not sure who's fault this is, probably mine ...
Chuck> The advocacy.el bug is my fault.  I'm going to go ahead and correct
Chuck> the distribution.  That is not a function I want failing :-)

Yup.  :-)

Steven> Doing a make in the man/lispref directory, generated a
Steven> permission denied error when attempting to make
Steven> ../info/lispref.info.  When doing a `make lispref.dvi' I
Steven> ended up with the following error:

Chuck> The package script removes write permissions to all of the files.
Chuck> Maybe it shouldn't for the info files.  Extremely minor since most
Chuck> people don't rebuild the info files.

O.K.  But, I wasn't trying to rebuild the info files.  I was trying to
get hardcopy of the Lisp reference manual.  Why does a ``make'' there
attempt to rebuild the info files?

O.K.  Minor; calling `texi2dvi' instead of `make' works great.  I'll go
and try to find something else (and hope I don't).

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 17:56:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA28622 for xemacs-beta-people; Sat, 22 Jun 1996 17:56:51 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA28619 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 17:56:50 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA16835 for <xemacs-beta@xemacs.org>; Sat, 22 Jun 1996 17:56:46 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id QAA27821; Sat, 22 Jun 1996 16:56:49 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id QAA00343; Sat, 22 Jun 1996 16:56:46 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id QAA07481; Sat, 22 Jun 1996 16:56:26 -0600
Date: Sat, 22 Jun 1996 16:56:26 -0600
Message-Id: <199606222256.QAA07481@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: Suggestions for announcement and FAQ
Reply-To: turner@lanl.gov

In the 19.13 announcement, you might want to consider adding something
like the following:

----
The format for Save Options changed between 19.13 and 19.14.  If you
wish to use both versions, to the following:

1) First, save the portion at the end of your .emacs that was created
   by Save Options under XEmacs 19.13 as a new file, say
   .xemacs-options-19.13.  That is, everything between, and including,
   the lines: 

;; Options Menu Settings
;; =====================

and

;; ============================
;; End of Options Menu Settings

2) Then add this bit of code in its place:

;; Load options for XEmacs 19.13.
(if (= emacs-minor-version 13)
    (load "~/.xemacs-options-19.13"))

   When you use 19.14 and use Save Options, it will create a file
   called .xemacs-options in which settings for 19.14 will be saved,
   and a bit of code will be written to your .emacs to load that file
   only if you are running 19.14.
----

I can post the above to comp.emacs.xemacs with the title "Tips for
migrating from 19.13 to 19.14" as well (or instead).

Here are some things to maybe add to the FAQ:

Q. When I start up I see "Invalid color instantiator: nil".  What's
   happening? 

A. Are you loading version 1.4 of search-menu?  It is incompatible
   with XEmacs 19.14.

Q. When I try to post a message in the Gnus distributed with XEmacs
   19.14 I get the message "wrong-type-argument stringp nil" in the
   minibuffer, but it seems to work.  What's happening?

A. Are you using uniquify?  It is incompatible with Gnus 5.2.

This last one should maybe be in the Gnus FAQ instead (or as well).

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 18:01:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA28649 for xemacs-beta-people; Sat, 22 Jun 1996 18:01:43 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA28646 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 18:01:42 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA15666 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 18:01:45 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA13115; Sat, 22 Jun 1996 18:01:40 -0500 (CDT)
Message-Id: <199606222301.SAA13115@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs 19.14 
In-reply-to: Your message of "22 Jun 1996 15:58:06 PDT."
             <m2g27njvk1.fsf@deanna.miranova.com> 
Date: Sat, 22 Jun 1996 18:01:40 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Steven> O.K.  But, I wasn't trying to rebuild the info files.  I
    Steven> was trying to get hardcopy of the Lisp reference manual.
    Steven> Why does a ``make'' there attempt to rebuild the info
    Steven> files?

Because I didn't get around to removing our integrated copy of
makeinfo.  The way the dependencies are setup, if makeinfo has to get
rebuilt it triggers a rebuild of the manuals in subdirectories.  Very
annoying.  That problem will go away in 19.15 because I am going to
remove makeinfo from the distribution.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 18:23:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA28704 for xemacs-beta-people; Sat, 22 Jun 1996 18:23:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA28701 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 18:23:41 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA21059 for <xemacs-beta@xemacs.org>; Sat, 22 Jun 1996 18:23:37 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id RAA28205; Sat, 22 Jun 1996 17:23:40 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id RAA00422; Sat, 22 Jun 1996 17:23:37 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id RAA07545; Sat, 22 Jun 1996 17:23:17 -0600
Date: Sat, 22 Jun 1996 17:23:17 -0600
Message-Id: <199606222323.RAA07545@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: 19.14 release: build success
Reply-To: turner@lanl.gov

Smooth build, running fine.  Have done standard things, including VM
and Gnus.

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

Configured for `sparc-sun-solaris2.5'.

  Where should the build process find the source code?    /usr/local/contrib/turner/xemacs-19.14
  What installation prefix should install use?		  ${srcdir}
  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              cc -g -fast -xO3 -fsimple=2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/dt/include /home/turner/Tools/include
  Additional libraries:                                   /usr/dt/lib /home/turner/Tools/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Compiling in support for ToolTalk.
  Compiling in support for CDE.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 18:24:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA28719 for xemacs-beta-people; Sat, 22 Jun 1996 18:24:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA28716 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 18:24:44 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA15878 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 18:24:46 -0500 (CDT)
Received: from solberg by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id RAA04553; Sat, 22 Jun 1996 17:24:40 -0600
Received: by solberg (SMI-8.6) id RAA16119; Sat, 22 Jun 1996 17:24:34 -0600
Sender: mdb@cdc.noaa.gov
To: xemacs-beta@cs.uiuc.edu
Cc: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>,
        "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
Subject: Re: Multiple Frame minibuffer BEEP/oddity in p1
References: <m2688j90zw.fsf@deanna.miranova.com> <vkwx0z8qy7.fsf@cdc.noaa.gov>
Organization: CIRES, University of Colorado
X-Attribution: mb
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 22 Jun 1996 17:24:33 -0600
In-Reply-To: Mark Borges's message of 22 Jun 1996 15:33:04 -0600
Message-ID: <vkhgs3l8we.fsf@cdc.noaa.gov>
Lines: 50
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>> On 22 Jun 1996 15:33:04 -0600,
>> Mark Borges(mb) wrote:
>> On 22 Jun 1996 10:56:03 -0700,
>> Steven L Baur(SLB) wrote:
SLB> I do not believe this constitutes a bug in Gnus, or Supercite.  I
SLB> also believe its too late to deal with this for 19.14.

mb> I just came across some weird lossage using Gnus-5.2.2[45] and
>> Steven L Baur(SLB) wrote:Supercite. (<<<<< See it yet? :-)

In my best Emily Litella (of SNF fame), "Never mind."

Sorry. My fault. Everything is fine. My most humble apologies for the
false alarm.

For those of you still interested, here's what happened. When
gnus-followup-with-original(), is invoked, it leave the cited region
selected. I still don't like this, but fine. I'll just deactivate it
with the handy-dandy function baw:toggle-active-region(), (hidden in
my signature below) which I bind to `\C-c .' like this:

      ((equal (device-type) 'tty)
       ;;
       ;; Code which applies only when running emacs under tty
       (define-key global-map [(control c) ?.] 'baw:toggle-active-region)

Somehow, my fingers (poor fingers get all the blame and none of the
credit :-) ) insisted on typing `\C-x .' instead, which is, of course,

--------------------------------------------------
  set-fill-prefix:
  Set the fill prefix to the current line up to point.
  Filling expects lines to start with the fill prefix
  and reinserts the fill prefix in each resulting line.
--------------------------------------------------

So it turns out everything is working perfectly in this
area. XEmacs-19.14/Gnus-5.2.25/Supercite/filladapt are fine; no,
great!

Mark, who promises not to file another report this weekend, and have a
couple beers instead ;-)

-- 
  -mb-
(defun baw:toggle-active-region ()
  (interactive)
  (if (mark)
      (zmacs-deactivate-region)
    (zmacs-activate-region)))

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 18:31:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA28739 for xemacs-beta-people; Sat, 22 Jun 1996 18:31:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA28736 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 18:31:03 -0500 (CDT)
Received: from ensg.u-nancy.fr (ensg.u-nancy.fr [192.93.48.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA21158; Sat, 22 Jun 1996 18:30:58 -0500 (CDT)
Received: from pomerol.ensg.u-nancy.fr by ensg.u-nancy.fr with SMTP
	(1.37.109.4/16.2) id AA05828; Sun, 23 Jun 96 01:28:20 +0200
Received: by pomerol.ensg.u-nancy.fr@ensg.u-nancy.fr (950413.SGI.8.6.12) id PAA15359; Wed, 26 Jun 1996 15:38:59 +0100
Date: Wed, 26 Jun 1996 15:38:59 +0100
Message-Id: <199606261438.PAA15359@pomerol.ensg.u-nancy.fr@ensg.u-nancy.fr>
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: Re: 19.14 binary kits
In-Reply-To: <199606222040.PAA06753@xemacs.cs.uiuc.edu>
References: <199606222040.PAA06753@xemacs.cs.uiuc.edu>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

    Chuck> Richard Cognot <cognot@ensg.u-nancy.fr>
    Chuck> xemacs-19.14-hppa1.1-hp-hpux9.05.tar.gz
    Chuck> xemacs-19.14-hppa1.1-hp-hpux10.01.tar.gz
    Chuck> xemacs-19.14-hppa1.1-hp-hpux10.10.tar.gz
    Chuck> xemacs-19.14-mips-sgi-irix5.3.tar.gz
    Chuck> xemacs-19.14-mips-sgi-irix6.2.tar.gz

Right. the 2 sgi builds are on their way, as is the hpux 9.05 one.

I'm currently having problems with the hpux 10 builds: on 10.01, I get
an undefined symbol (alloca), and 10.10 is not stable enough to my
liking (I get a hang in gnus).

I didn't have that alloca problem with p1, though, so I really don't
see what's wrong...

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 18:51:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA28778 for xemacs-beta-people; Sat, 22 Jun 1996 18:51:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA28775 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 18:51:03 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA16289 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 18:51:02 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id QAA06447; Sat, 22 Jun 1996 16:50:15 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Suggestions for announcement and FAQ
References: <199606222256.QAA07481@gielgud.lanl.gov.xdiv>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: John Turner's message of Sat, 22 Jun 1996 16:56:26 -0600
Date: 22 Jun 1996 16:50:13 -0700
Message-ID: <m27mszjt56.fsf@deanna.miranova.com>
Lines: 23
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:

John> Q. When I try to post a message in the Gnus distributed with XEmacs
John>    19.14 I get the message "wrong-type-argument stringp nil" in the
John>    minibuffer, but it seems to work.  What's happening?

John> A. Are you using uniquify?  It is incompatible with Gnus 5.2.

John> This last one should maybe be in the Gnus FAQ instead (or as well).

I've added all of John's excellent suggestions to the FAQ.  That last
one will go into the XEmacs FAQ, since the Gnus FAQ was just posted to
Usenet a couple of days ago.

There will be a courtesy posting of the FAQ to comp.emacs.xemacs at
June 23, 04:00 GMT (9pm tonight US/Pacific time), so if anyone has any
last minute suggestions like John's here please make them before then.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 18:45:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA28771 for xemacs-beta-people; Sat, 22 Jun 1996 18:45:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA28768 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 18:45:22 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA21200 for <xemacs-beta@xemacs.org>; Sat, 22 Jun 1996 18:45:19 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA13214; Sat, 22 Jun 1996 18:39:53 -0500 (CDT)
Message-Id: <199606222339.SAA13214@charles.cs.uiuc.edu>
To: cognot@ensg.u-nancy.fr
cc: xemacs-beta@xemacs.org
Subject: Re: 19.14 binary kits 
In-reply-to: Your message of "Wed, 26 Jun 1996 15:38:59 BST."
             <199606261438.PAA15359@pomerol.ensg.u-nancy.fr@ensg.u-nancy.fr> 
Date: Sat, 22 Jun 1996 18:39:53 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Richard> I'm currently having problems with the hpux 10 builds: on
    Richard> 10.01, I get an undefined symbol (alloca), and 10.10 is
    Richard> not stable enough to my liking (I get a hang in gnus).

    Richard> I didn't have that alloca problem with p1, though, so I
    Richard> really don't see what's wrong...


The problem is a change that I knew I shouldn't have put in.  Dumb,
dumb, dumb, dumb.  Some changes should never be made when there isn't
any time to test them.  Although, it's quite possible that only 10.01
has a problem with the change.  Less than impressed have I been with
it.

Find the ALLOCA= line in src/Makefile and let me know what it is.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 18:57:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA28801 for xemacs-beta-people; Sat, 22 Jun 1996 18:57:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA28798 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 18:57:41 -0500 (CDT)
Received: from netcom2.netcom.com (root@netcom2.netcom.com [192.100.81.108]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA16330 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 18:57:44 -0500 (CDT)
Received: from netcom20.netcom.com (wing@netcom20.netcom.com [192.100.81.133]) by netcom2.netcom.com (8.6.13/Netcom)
	id QAA01077; Sat, 22 Jun 1996 16:57:42 -0700
Date: Sat, 22 Jun 1996 16:57:42 -0700
Message-Id: <199606222357.QAA01077@netcom2.netcom.com>
From: wing@666.com (Ben Wing)
To: cthomp@cs.uiuc.edu, steve@miranova.com
Subject: Re: XEmacs 19.14
Cc: xemacs-beta@cs.uiuc.edu

>Because I didn't get around to removing our integrated copy of
>makeinfo.  The way the dependencies are setup, if makeinfo has to get
>rebuilt it triggers a rebuild of the manuals in subdirectories.  Very
>annoying.  That problem will go away in 19.15 because I am going to
>remove makeinfo from the distribution.

Er ...  you're sure there isn't anything useful in the XEmacs-specific
version, right?  Back when we were at makeinfo-1.55, at least, I had
put in a fix that allowed for a cleaner make on the VM info files.

ben

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 19:00:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA28824 for xemacs-beta-people; Sat, 22 Jun 1996 19:00:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA28821 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 19:00:07 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA16377 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 19:00:10 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA13296; Sat, 22 Jun 1996 18:59:58 -0500 (CDT)
Message-Id: <199606222359.SAA13296@charles.cs.uiuc.edu>
To: wing@666.com (Ben Wing)
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs 19.14 
In-reply-to: Your message of "Sat, 22 Jun 1996 16:57:40 PDT."
             <199606222357.QAA01070@netcom2.netcom.com> 
Date: Sat, 22 Jun 1996 18:59:58 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Ben> Er ...  you're sure there isn't anything useful in the
    Ben> XEmacs-specific version, right?  Back when we were at
    Ben> makeinfo-1.55, at least, I had put in a fix that allowed for
    Ben> a cleaner make on the VM info files.

No, I'm not 100% positive.  Most of the changes were to eliminate
compilation warnings which don't matter if we don't include it.  If
such a change is needed I'll submit it to the maintainer and keep a
local modified version for now.  If it was really necessary, though, I
would think Kyle would have done something about it.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 19:39:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA28959 for xemacs-beta-people; Sat, 22 Jun 1996 19:39:36 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA28956 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 19:39:35 -0500 (CDT)
Received: from cortex.corpus.uni-muenster.de (gutschk@PPPE195.UNI-MUENSTER.DE [128.176.20.207]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA21775; Sat, 22 Jun 1996 19:39:21 -0500 (CDT)
Received: (from gutschk@localhost) by cortex.corpus.uni-muenster.de (8.6.12/8.6.11) id CAA11564; Sun, 23 Jun 1996 02:39:14 +0200
Sender: gutschk@uni-muenster.de
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: Re: 19.14 binary kits
References: <199606222040.PAA06753@xemacs.cs.uiuc.edu>
X-Face: +.[`xCMz]E6GW}5ECgY#C"Er6&v$q7:oe+zPlPtOh>/US;9B>;)ro_lpLx9/]q_{u-\YR>r
 P&)Da0gS,PW{@BWSG,PIV)3#J<$Ft_t]qa!xF~'*wuwg-CJj*0:EUr3z}y
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Markus Gutschke <gutschk@uni-muenster.de>
Date: 23 Jun 1996 02:39:13 +0200
In-Reply-To: Chuck Thompson's message of Sat, 22 Jun 1996 15:40:44 -0500
Message-ID: <m2n31vs6a6.fsf@cortex.corpus.uni-muenster.de>
Lines: 29
X-Mailer: Gnus v5.2.23/XEmacs 19.14

Chuck Thompson <cthomp@xemacs.org> writes:

> 
> As already noted, the final 19.14 distribution is now at:
> 
> 	ftp.xemacs.org:/pub/xemacs-19.14
> 
> 
> Please check out the README and let me know about
> mistakes/ommisions/anything else.  Below are the instructions for
> making binary kits.  Get them to me as soon as you can.  Put them at
> ftp.xemacs.org:/pub/beta/incoming.

Sorry, the README is unreadable:

  150 Opening ASCII mode data connection for /bin/ls.
  total 32328
  drwxr-x---   2 beta     beta         512 Jun 23 00:30 .
  drwxr-xr-x   8 ftp      ftp          512 Jun 22 19:04 ..
  -rw-------   1 340      6666       12710 Jun 22 20:46 README
  -rw-------   1 340      6666        3012 Jun 22 20:46 README.executables
  -rw-------   1 340      6666        1378 Jun 22 20:46 README.patch
  -r--r--r--   1 xemacs   xemacs    328745 Jun 22 20:45 gzip-1.2.4.tar.Z
  -r--r--r--   1 xemacs   xemacs   16175772 Jun 22 19:23 xemacs-19.14.tar.gz
  226 Transfer complete.



Markus

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 19:41:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA28982 for xemacs-beta-people; Sat, 22 Jun 1996 19:41:17 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA28979 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 19:41:15 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA21786; Sat, 22 Jun 1996 19:41:11 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA13383; Sat, 22 Jun 1996 19:41:11 -0500 (CDT)
Message-Id: <199606230041.TAA13383@charles.cs.uiuc.edu>
To: Markus Gutschke <gutschk@uni-muenster.de>
cc: Chuck Thompson <cthomp@xemacs.org>, xemacs-beta@xemacs.org
Subject: Re: 19.14 binary kits 
In-reply-to: Your message of "23 Jun 1996 02:39:13 +0200."
             <m2n31vs6a6.fsf@cortex.corpus.uni-muenster.de> 
Date: Sat, 22 Jun 1996 19:41:10 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Markus> Sorry, the README is unreadable:

That's because I haven't actually updated it yet.  Guess I should have
done a little more hacking on the 19.13 message I sent out about
checking it.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 20:09:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA29052 for xemacs-beta-people; Sat, 22 Jun 1996 20:09:38 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA29049 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 20:09:36 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA21808 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 20:09:37 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA13426; Sat, 22 Jun 1996 20:09:32 -0500 (CDT)
Message-Id: <199606230109.UAA13426@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu, ding@ifi.uio.no
Subject: Re: Gnus XFaces lost their transparency in 5.2.25. 
In-reply-to: Your message of "22 Jun 1996 18:03:02 PDT."
             <m2zq5vib7d.fsf@deanna.miranova.com> 
Date: Sat, 22 Jun 1996 20:09:31 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

It was done at my request to match the behavior of
highlight-headers.el.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 20:03:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA29038 for xemacs-beta-people; Sat, 22 Jun 1996 20:03:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA29035 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 20:03:48 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA19200 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 20:03:49 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id SAA07571; Sat, 22 Jun 1996 18:03:03 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: ding@ifi.uio.no
Subject: Gnus XFaces lost their transparency in 5.2.25.
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
Date: 22 Jun 1996 18:03:02 -0700
Message-ID: <m2zq5vib7d.fsf@deanna.miranova.com>
Lines: 33
X-Mailer: Gnus v5.2.25/XEmacs 19.14

I suggest backing out entirely the 5.2.24->5.2.25 patch to
gnus-xmas.el.  Except that it looks like this change was made
deliberately.  It looked much better when the faces were transparent. :-(

Sat Jun 22 10:57:35 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

        * gnus.el (gnus-thread-total-score-1): Replaced with old,
        non-buggy version.

        * gnus-xmas.el ((find-face 'gnus-x-face)): Set proper colors. 



--- gnus-xmas.el        Sat Jun 22 02:32:28 1996
+++ ../../gnus-5.2.24/lisp/gnus-xmas.el Fri Jun 21 09:53:37 1996
@@ -703,9 +703,7 @@
    args))
 
 (unless (find-face 'gnus-x-face)
-  (copy-face 'default 'gnus-x-face)
-  (set-face-foreground 'gnus-x-face "black")
-  (set-face-background 'gnus-x-face "white"))
+  (copy-face 'default 'gnus-x-face))
 
 (defun gnus-xmas-article-display-xface (beg end)
   "Display any XFace headers in the current article."


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 20:28:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA29071 for xemacs-beta-people; Sat, 22 Jun 1996 20:28:28 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA29068 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 20:28:27 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA22391; Sat, 22 Jun 1996 20:28:29 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id SAA07920; Sat, 22 Jun 1996 18:27:43 -0700
Sender: steve@miranova.com
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: xemacs-beta@cs.uiuc.edu, ding@ifi.uio.no
Subject: Re: Gnus XFaces lost their transparency in 5.2.25.
References: <199606230109.UAA13426@charles.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Sat, 22 Jun 1996 20:09:31 -0500
Date: 22 Jun 1996 18:27:42 -0700
Message-ID: <m2u3w3ia29.fsf@deanna.miranova.com>
Lines: 12
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

Chuck> It was done at my request to match the behavior of
Chuck> highlight-headers.el.

:-(  O.K.  :-(

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 21:59:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA29219 for xemacs-beta-people; Sat, 22 Jun 1996 21:59:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA29216 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 21:59:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA28634 for <xemacs-beta@xemacs.org>; Sat, 22 Jun 1996 21:59:36 -0500 (CDT)
Message-Id: <199606230259.VAA28634@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 20.0 beta26
Date: Sat, 22 Jun 1996 21:59:34 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/beta/xemacs-20.0.  Next release is
beta27 out ???????.

This doesn't have any of the Mule patches which have been sent to the
list lately.  Martin now tracks those and because of the 19.14 release
I have not received a workspace update from him in a little while.
Once Martin has everything back in sync and sends me an updated
workspace I'll release beta27.

It will be at least a couple of weeks before 19.15 beta1 is released.
Feel free to spend that time adding new features and fixing bugs and
sending me the resulting patches and files :-)



			-Chuck



-- gnus 5.2.25
-- browse-url 0.38
-- viper 2.90
-- XEmacs web page entries on help menu now reference
   browse-url-browser-function
-- problem with using dired-mode-font-lock-keywords fixed
-- new variable `allow-deletion-of-last-visible-frame'
-- NEED_LIBW handled
-- glyphs-x.c should really build with older png libs now
-- balloon-help crash fixed
-- A patch for crash in multiple_change_finish_up which Lars hit.  I
   don't know if it is fully correct but it should be safe and prevent
   the crash.
-- some Unixware patches
-- some additional SCO patches
-- auto-show-mode is now off by default in edit-faces-mode
-- incorrect echoing when hitting 'f1 in tty mode fixed
-- png build problem fixed
-- terminal.el env requirement removed
-- gdbglobal doesn't turn on everywhere anymore
-- The bug where window-displayed-height didn't always return the
   correct value is fixed.  The same bug was responsible for
   shrink-window-if-larger-than-buffer sometimes failing to work
   correctly.
-- The force option to delete-frame is back.  You can no longer delete
   the last visible or iconic frame unless the second arg to
   delete-frame is non-nil.
-- Darrell Kindred's patch fro the ^@ problem
-- a number of random elisp changes from Jamie
-- --with-cde flag is back
-- revert-buffer no longer causes complete refontification in lazy-lock.
-- some more options on Options menu, for Printing.

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 22 23:40:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA29536 for xemacs-beta-people; Sat, 22 Jun 1996 23:40:26 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA29517 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 22 Jun 1996 23:38:04 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA25692 for <xemacs-beta@cs.uiuc.edu>; Sat, 22 Jun 1996 23:38:06 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id VAA09343; Sat, 22 Jun 1996 21:37:16 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: Markus Gutschke <gutschk@uni-muenster.de>,
        Benedikt Eric Heinen <beh@icemark.thenet.ch>
Subject: Linux a.out+Motif needed (was Re: 19.14 binary kits)
References: <199606222040.PAA06753@xemacs.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Sat, 22 Jun 1996 15:40:44 -0500
Date: 22 Jun 1996 21:37:15 -0700
Message-ID: <m2buibi1ac.fsf@deanna.miranova.com>
Lines: 28
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

Chuck> Linux Builds: I'm going to let the three of you hash out who does
Chuck> 	      what.  I'm including what I would like to have.  If you
Chuck> 	      can't cover all of them, please send a message to the
Chuck> 	      beta list telling what still needs to be done.  If
Chuck> 	      someone of these are worthless, let me know.

There was considerable overlap on what we can collectively compile.
We're dropping the 2.0/1.2.13 distinction and need someone who can
compile a.out with Motif.

The names look something like:
Benedikt  xemacs-19.14-i486-unknown-linuxelf.tar.gz
Benedikt  xemacs-19.14-i486-unknown-linuxelf-motif.tar.gz
Markus    xemacs-19.14-i486-unknown-linuxelf-ALLSTATIC.tar.gz
?????     xemacs-19.14-i486-unknown-linuxaout-ALLSTATIC.tar.gz
Steve     xemacs-19.14-i486-unknown-linuxaout.tar.gz
?????     xemacs-19.14-i486-unknown-linuxaout-motif.tar.gz

The intent of the allstatic versions (Markus' idea) is to eliminate
any possibility of library incompatibility at the cost of a huge
program size.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 05:50:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA04556 for xemacs-beta-people; Sun, 23 Jun 1996 05:50:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA04553 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 05:50:58 -0500 (CDT)
Received: from ensg.u-nancy.fr (ensg.u-nancy.fr [192.93.48.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA29628 for <xemacs-beta@xemacs.org>; Sun, 23 Jun 1996 05:50:54 -0500 (CDT)
Received: from extreme.ensg.u-nancy.fr by ensg.u-nancy.fr with SMTP
	(1.37.109.4/16.2) id AA06103; Sun, 23 Jun 96 12:48:19 +0200
Received: by extreme.ensg.u-nancy.fr@ensg.u-nancy.fr (940816.SGI.8.6.9) id CAA09410; Thu, 27 Jun 1996 02:59:26 +0100
Date: Thu, 27 Jun 1996 02:59:26 +0100
Message-Id: <199606270159.CAA09410@extreme.ensg.u-nancy.fr@ensg.u-nancy.fr>
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: xemacs-beta@xemacs.org
Subject: Re: 19.14 binary kits 
In-Reply-To: <199606222339.SAA13214@charles.cs.uiuc.edu>
References: <199606261438.PAA15359@pomerol.ensg.u-nancy.fr@ensg.u-nancy.fr>
	<199606222339.SAA13214@charles.cs.uiuc.edu>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

    Chuck> Find the ALLOCA= line in src/Makefile and let me know what
    Chuck> it is.

Sorry, checked my private mailbox before the list.

Apparently, there is no such value in the makefile.
Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 06:38:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA04667 for xemacs-beta-people; Sun, 23 Jun 1996 06:38:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA04664 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 06:38:39 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA29722; Sun, 23 Jun 1996 06:38:35 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA20166; Sun, 23 Jun 1996 04:25:24 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA29790; Sun, 23 Jun 1996 13:25:21 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA20951; Sun, 23 Jun 1996 13:25:20 +0200
Date: Sun, 23 Jun 1996 13:25:20 +0200
Message-Id: <9606231125.AA20951@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: RE: 19.14 binary kits
In-Reply-To: <199606222040.PAA06753@xemacs.cs.uiuc.edu>
References: <199606222040.PAA06753@xemacs.cs.uiuc.edu>
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

cthomp@xemacs.org (Chuck Thompson) writes,
in <199606222040.PAA06753@xemacs.cs.uiuc.edu>:

>Stephen Carney <carney@gvc.dec.com>
>	xemacs-19.14-alpha-dec-osf3.2.tar.gz
>	xemacs-19.14-alpha-dec-osf4.0.tar.gz

I won't have a V4.0 system for at least a week, because the official
release has just started shipping (I don't have the final CDROM yet).

If someone has a V4.0 official release system (not one of the betas),
then they might want to build an XEmacs binary before I can get to it
(maybe a week or 2).

        Steve

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 06:40:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA04684 for xemacs-beta-people; Sun, 23 Jun 1996 06:40:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA04679 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 06:40:03 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA01308 for <xemacs-beta@cs.uiuc.edu>; Sun, 23 Jun 1996 06:40:03 -0500 (CDT)
Message-Id: <199606231140.GAA01308@a.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA151610007; Sun, 23 Jun 1996 12:40:07 +0100
Date: Sun, 23 Jun 1996 12:40:07 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@cs.uiuc.edu
Subject: hpux 10.01 binary kit
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



On its way to xemacs.cs.uiuc.edu.

Had to edit manually src/Makefile due to this alloca problem though.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 07:33:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA04796 for xemacs-beta-people; Sun, 23 Jun 1996 07:33:07 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA04793 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 07:33:06 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA29847 for <xemacs-beta@xemacs.org>; Sun, 23 Jun 1996 07:33:01 -0500 (CDT)
Message-Id: <199606231233.HAA29847@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: patch to final release
Date: Sun, 23 Jun 1996 07:32:59 -0500
From: Chuck Thompson <cthomp@xemacs.org>

This only affects HPUX 10 users.  That's guaranteed because only
hpux10.h defines FORCE_ALLOCA_H.  The funny thing is that I needed
some kind of define like that to fix this bug and it was already there
courtesy of FSF.  But they don't actually appear to use it.


			-Chuck



*** /tmp/geta29837	Sun Jun 23 07:30:53 1996
--- Makefile.in.in	Sun Jun 23 07:29:21 1996
***************
*** 895,901 ****
--- 895,905 ----
  mallocdocsrc =
  #endif /* SYSTEM_MALLOC */
  
+ #ifdef FORCE_ALLOCA_H
+ allocaobjs = alloca.o
+ #else /* !FORCE_ALLOCA_H */
  allocaobjs = @ALLOCA@
+ #endif /* !FORCE_ALLOCA_H */
  
  #ifdef HAVE_X_WINDOWS
  

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 07:47:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA04829 for xemacs-beta-people; Sun, 23 Jun 1996 07:47:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA04826 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 07:47:37 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA00342 for <xemacs-beta@xemacs.org>; Sun, 23 Jun 1996 07:47:35 -0500 (CDT)
Message-Id: <199606231247.HAA00342@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA184574060; Sun, 23 Jun 1996 13:47:40 +0100
Date: Sun, 23 Jun 1996 13:47:40 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: xemacs-beta@xemacs.org
Subject: Re: patch to final release 
In-Reply-To: <199606231246.HAA14322@charles.cs.uiuc.edu>
References: <199606231244.HAA00058@xemacs.cs.uiuc.edu>
	<199606231246.HAA14322@charles.cs.uiuc.edu>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

    Richard> As this patch is for Makefile.in.in, does it mean
    Richard> autoconf should be re-run?

    Chuck> No, autoconf is only used to generate configure from
    Chuck> configure.in.  You should run a make file the top-level,
    Chuck> though.  The dependencies should trigger a run of
    Chuck> config.status to update all of the makefiles.

Just tried it, works OK.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 07:46:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA04822 for xemacs-beta-people; Sun, 23 Jun 1996 07:46:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA04819 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 07:46:43 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA00073 for <xemacs-beta@xemacs.org>; Sun, 23 Jun 1996 07:46:41 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA14322; Sun, 23 Jun 1996 07:46:40 -0500 (CDT)
Message-Id: <199606231246.HAA14322@charles.cs.uiuc.edu>
To: cognot@ensg.u-nancy.fr
cc: xemacs-beta@xemacs.org
Subject: Re: patch to final release 
In-reply-to: Your message of "Sun, 23 Jun 1996 13:44:38 BST."
             <199606231244.HAA00058@xemacs.cs.uiuc.edu> 
Date: Sun, 23 Jun 1996 07:46:39 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Richard> As this patch is for Makefile.in.in, does it mean
    Richard> autoconf should be re-run?

No, autoconf is only used to generate configure from configure.in.
You should run a make file the top-level, though.  The dependencies
should trigger a run of config.status to update all of the makefiles.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 07:44:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA04815 for xemacs-beta-people; Sun, 23 Jun 1996 07:44:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA04812 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 07:44:37 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA00058; Sun, 23 Jun 1996 07:44:34 -0500 (CDT)
Message-Id: <199606231244.HAA00058@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA180253878; Sun, 23 Jun 1996 13:44:38 +0100
Date: Sun, 23 Jun 1996 13:44:38 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: Re: patch to final release
In-Reply-To: <199606231233.HAA29847@xemacs.cs.uiuc.edu>
References: <199606231233.HAA29847@xemacs.cs.uiuc.edu>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

    Chuck> This only affects HPUX 10 users.  That's guaranteed because
    Chuck> only hpux10.h defines FORCE_ALLOCA_H.  The funny thing is
    Chuck> that I needed some kind of define like that to fix this bug
    Chuck> and it was already there courtesy of FSF.  But they don't
    Chuck> actually appear to use it.

As this patch is for Makefile.in.in, does it mean autoconf should be
re-run? 

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 08:28:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA04899 for xemacs-beta-people; Sun, 23 Jun 1996 08:28:44 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA04896 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 08:28:43 -0500 (CDT)
Received: from caviar.cv.ruu.nl (caviar.cv.ruu.nl [131.211.149.16]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA07326 for <xemacs-beta@cs.uiuc.edu>; Sun, 23 Jun 1996 08:28:43 -0500 (CDT)
Received: from triton.cv.ruu.nl (triton.cv.ruu.nl [131.211.148.17]) by caviar.cv.ruu.nl (8.7.5/8.7.3) with ESMTP id PAA08043 for <xemacs-beta@cs.uiuc.edu>; Sun, 23 Jun 1996 15:26:43 +0200 (METDST)
Received: from wodan.cv.ruu.nl (wodan.cv.ruu.nl [131.211.148.21]) by triton.cv.ruu.nl (8.7.5/8.7.3) with ESMTP id PAA19211 for <xemacs-beta@cs.uiuc.edu>; Sun, 23 Jun 1996 15:26:49 +0200 (METDST)
From: Fred Appelman <Fred.Appelman@cv.ruu.nl>
Received: (fred@localhost) by wodan.cv.ruu.nl (8.6.12/8.6.12) id PAA22370 for xemacs-beta@cs.uiuc.edu; Sun, 23 Jun 1996 15:25:22 +0200
Message-Id: <199606231325.PAA22370@wodan.cv.ruu.nl>
Subject: configure core dump explained
To: xemacs-beta@cs.uiuc.edu (XEmacs mailing list)
Date: Sun, 23 Jun 1996 15:25:22 +0200 (METDST)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Yesterday I reported that configure produced a core dump.
I turned out to be caused by the fact the sed 3.0 of GNU has
bugs. This is a readme from the prep.ai.mit.edu ftp archive:

     sed 3.0 has been withdrawn from distribution.  It has major revisions,
     which mostly seem to be improvements; but it turns out to have bugs too
     which cause trouble in some common cases.
     
     Tom Lord won't be able to work fixing the bugs until May.  So in the
     mean time, we've decided to withdraw sed 3.0 from distribution and
     make version 2.05 once again the recommended version.

-- 
Fred J.R. Appelman - Room E01.334      E-mail: Fred.Appelman@cv.ruu.nl
Department of Image Sciences           Tel: +31-30-2506710
Imaging Center Utrecht                 Fax: +31-30-2513399
University Hospital Utrecht, Heidelberglaan 100, 3584 CX Utrecht, Holland

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 13:24:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA05576 for xemacs-beta-people; Sun, 23 Jun 1996 13:24:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA05573 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 13:24:10 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA11944 for <xemacs-beta@cs.uiuc.edu>; Sun, 23 Jun 1996 13:24:12 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA14709; Sun, 23 Jun 1996 13:24:08 -0500 (CDT)
Message-Id: <199606231824.NAA14709@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: configure core dump explained 
In-reply-to: Your message of "23 Jun 1996 11:20:04 PDT."
             <m2g27m2xij.fsf@deanna.miranova.com> 
Date: Sun, 23 Jun 1996 13:24:07 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Fred> Yesterday I reported that configure produced a core dump.  I
    Fred> turned out to be caused by the fact the sed 3.0 of GNU has
    Fred> bugs. This is a readme from the prep.ai.mit.edu ftp archive:

    Steven> I've added this to the FAQ.  Thanks.


Note that this is not the cause of the core file appearing when
configuring on Solaris.  That is being caused by the vfork test.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 13:20:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA05567 for xemacs-beta-people; Sun, 23 Jun 1996 13:20:53 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA05564 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 13:20:51 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA11917 for <xemacs-beta@cs.uiuc.edu>; Sun, 23 Jun 1996 13:20:52 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA12132; Sun, 23 Jun 1996 11:20:05 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: configure core dump explained
References: <199606231325.PAA22370@wodan.cv.ruu.nl>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Fred Appelman's message of Sun, 23 Jun 1996 15:25:22 +0200 (METDST)
Date: 23 Jun 1996 11:20:04 -0700
Message-ID: <m2g27m2xij.fsf@deanna.miranova.com>
Lines: 12
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>>>>> "Fred" == Fred Appelman <Fred.Appelman@cv.ruu.nl> writes:

Fred> Yesterday I reported that configure produced a core dump.
Fred> I turned out to be caused by the fact the sed 3.0 of GNU has
Fred> bugs. This is a readme from the prep.ai.mit.edu ftp archive:

I've added this to the FAQ.  Thanks.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 23 14:36:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA05820 for xemacs-beta-people; Sun, 23 Jun 1996 14:36:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA05817 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 23 Jun 1996 14:36:36 -0500 (CDT)
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA20399 for <xemacs-beta@xemacs.org>; Sun, 23 Jun 1996 14:36:34 -0500 (CDT)
Received: from FISHKILL by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1025;
   Sun, 23 Jun 96 15:36:18 EDT
Received: by FISHKILL (XAGENTA 4.0) id 1691; Sun, 23 Jun 1996 15:36:33 -0400 
Received: by spacedog.fishkill.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA22412; Sun, 23 Jun 1996 15:36:29 -0400
Date: Sun, 23 Jun 1996 15:36:29 -0400
Message-Id: <9606231936.AA22412@spacedog.fishkill.ibm.com>
From: "Doug Keller" <dkeller@VNET.IBM.COM>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: Re: binary kit build instructions
In-Reply-To: <199606210344.WAA09139@xemacs.cs.uiuc.edu>
References: <199606210344.WAA09139@xemacs.cs.uiuc.edu>

I can do AIX 3.2.5.

doug

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 02:14:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA07191 for xemacs-beta-people; Mon, 24 Jun 1996 02:14:10 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA07188 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 02:14:09 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA25389 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 02:14:06 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id AAA04836; Mon, 24 Jun 1996 00:12:29 GMT
Date: Mon, 24 Jun 1996 00:12:29 GMT
Message-Id: <199606240012.AAA04836@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: David Worenklein <dcw@gcm.com>
Cc: xemacs-beta@xemacs.org
Subject: 19.14b25 fail - :help-string
In-Reply-To: <Pine.SUN.3.91.960620114343.20039A-200000@mis_bo9>
References: <Pine.SUN.3.91.960620114343.20039A-200000@mis_bo9>

David Worenklein writes:
 >   This message is in MIME format.  The first part should be readable text,
 >   while the remaining parts are likely unreadable without MIME-aware tools.
 >   Send mail to mime@docserver.cac.washington.edu for more info.
 > 
 > --1430489217-2053294700-835285566=:20039
 > Content-Type: TEXT/PLAIN; charset=US-ASCII
 > Content-Transfer-Encoding: QUOTED-PRINTABLE
 > 
 > xemacs -q -no-site-file
 > C-x C-f <tab> <tab>
 > 
 > Signalling: (void-function :help-string)
 >   :help-string((concat (if (device-on-window-system-p) (substitute-command-=
 > keys "Click \\<list-mode-map>\\[list-mode-item-mouse-selected] on a complet=
 > ion to select it.\n") "") (substitute-command-keys "Type \\<minibuffer-loca=
 > l-completion-map>\\[advertised
 > -switch-to-completions] or \\[switch-to-completions] to move to this buffer=
 > , for keyboard selection.\n\n")))

Never seen this.  Does anyone else see it?  In 19.14 released?

 > 
 > --1430489217-2053294700-835285566=:20039
 > Content-Type: TEXT/PLAIN; charset=US-ASCII; name="config.status"
 > Content-Transfer-Encoding: BASE64
 > Content-ID: <Pine.SUN.3.91.960620114605.20039B@mis_bo9>
 > Content-Description: config.status
 > 
 > IyEvYmluL3NoDQojIEdlbmVyYXRlZCBhdXRvbWF0aWNhbGx5IGJ5IGNvbmZp
 > Z3VyZS4NCiMgUnVuIHRoaXMgZmlsZSB0byByZWNyZWF0ZSB0aGUgY3VycmVu
 > dCBjb25maWd1cmF0aW9uLg0KIyBUaGlzIGRpcmVjdG9yeSB3YXMgY29uZmln
 > dXJlZCBhcyBmb2xsb3dzLA0KIyBvbiBob3N0IG1pc19ibzk6DQojDQojIC4v
 > Y29uZmlndXJlICBzcGFyYy1zdW4tc3Vub3M0LjEuMyAtLXF1YW50aWZ5PXll

Evil Pine attachments!

ben

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 02:32:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA07253 for xemacs-beta-people; Mon, 24 Jun 1996 02:32:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA07250 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 02:32:13 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA25510 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 02:32:10 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id AAA05236; Mon, 24 Jun 1996 00:30:37 GMT
Date: Mon, 24 Jun 1996 00:30:37 GMT
Message-Id: <199606240030.AAA05236@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: drich@cisco.com
Cc: xemacs-beta@xemacs.org
Subject: gnuattach weirdness
In-Reply-To: <199606220148.SAA19503@sandman.cisco.com>
References: <199606220148.SAA19503@sandman.cisco.com>

Dan Rich writes:
 > I just found two problems using gnuattach (and I think someone already
 > mentioned the first, but I never saw any discussion about it).

Hey, did anyone ever follow my instructions and try to see where
the "stopped (TTY output)" signal was happening?

ben

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 03:02:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA07434 for xemacs-beta-people; Mon, 24 Jun 1996 03:02:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA07421 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 03:02:01 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA00335 for <xemacs-beta@cs.uiuc.edu>; Mon, 24 Jun 1996 03:01:57 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id BAA29832; Mon, 24 Jun 1996 01:01:11 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b25 fail - :help-string
References: <Pine.SUN.3.91.960620114343.20039A-200000@mis_bo9>
	<199606240012.AAA04836@nene.boundless.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Ben Wing's message of Mon, 24 Jun 1996 00:12:29 GMT
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 24 Jun 1996 01:01:09 -0700
Message-ID: <m2lohdwrzu.fsf@deanna.miranova.com>
Lines: 33
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

Ben> David Worenklein writes:
>> xemacs -q -no-site-file
>> C-x C-f <tab> <tab>
>> 
>> Signalling: (void-function :help-string)

Ben> Never seen this.  Does anyone else see it?  In 19.14 released?

Neither.  There is a showstopper in 19.14 that I will attempt to
demonstrate shortly though.

>> --1430489217-2053294700-835285566=:20039
>> Content-Type: TEXT/PLAIN; charset=US-ASCII; name="config.status"
>> Content-Transfer-Encoding: BASE64
>> Content-ID: <Pine.SUN.3.91.960620114605.20039B@mis_bo9>
>> Content-Description: config.status
>> 
>> IyEvYmluL3NoDQojIEdlbmVyYXRlZCBhdXRvbWF0aWNhbGx5IGJ5IGNvbmZp
>> Z3VyZS4NCiMgUnVuIHRoaXMgZmlsZSB0byByZWNyZWF0ZSB0aGUgY3VycmVu
>> dCBjb25maWd1cmF0aW9uLg0KIyBUaGlzIGRpcmVjdG9yeSB3YXMgY29uZmln
>> dXJlZCBhcyBmb2xsb3dzLA0KIyBvbiBob3N0IG1pc19ibzk6DQojDQojIC4v
>> Y29uZmlndXJlICBzcGFyYy1zdW4tc3Vub3M0LjEuMyAtLXF1YW50aWZ5PXll

Ben> Evil Pine attachments!

Hopefully, we can include tm in 19.15.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 03:38:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA10916 for xemacs-beta-people; Mon, 24 Jun 1996 03:38:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA10913 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 03:38:11 -0500 (CDT)
Received: from tuminfo2.informatik.tu-muenchen.de (root@tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26303 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 03:38:06 -0500 (CDT)
Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26468-1>; Mon, 24 Jun 1996 10:37:38 +0200
Received: from hphalle4.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <397501-221>; Mon, 24 Jun 1996 10:37:33 +0100
From: Axel Seibert <seiberta@informatik.tu-muenchen.de>
To: wing@666.com
CC: dcw@gcm.com, xemacs-beta@xemacs.org
In-reply-to: <199606240012.AAA04836@nene.boundless.com> (message from Ben Wing
	on Mon, 24 Jun 1996 00:12:29 GMT)
Subject: Re: 19.14b25 fail - :help-string
Message-Id: <96Jun24.103733+0100mesz.397501-221+322@hphalle0.informatik.tu-muenchen.de>
Date: 	Mon, 24 Jun 1996 10:37:22 +0100

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

Ben> David Worenklein writes:
>> 
>> xemacs -q -no-site-file C-x C-f <tab> <tab>
>> 
>> Signalling: (void-function :help-string) :help-string((concat (if
>> (device-on-window-system-p) (substitute-command-= keys "Click
>> \\<list-mode-map>\\[list-mode-item-mouse-selected] on a complet=
>> ion to select it.\n") "") (substitute-command-keys "Type
>> \\<minibuffer-loca=
l-completion-map> \\[advertised
>> -switch-to-completions] or \\[switch-to-completions] to move to
>> this buffer= , for keyboard selection.\n\n")))

Ben> Never seen this. Does anyone else see it? In 19.14 released?

Yep, I've seen this. Only last night I got around to compiling 19.14
released (directly patched up from beta24) and saw this for the first
time. 

This is xemacs-r under NEXTSTEP (without X)

Apart from this I've got big problems compiling the lisp files (e.g.
viper won't compile due to a unknown vaiable
"mouse-track-multiple...."; gnus won't compile because the maximum
recursive depth of included files is exceeded). 

Axel


From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 04:16:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA11133 for xemacs-beta-people; Mon, 24 Jun 1996 04:16:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA11130 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 04:16:51 -0500 (CDT)
Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA26506 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 04:16:48 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA16522; Mon, 24 Jun 1996 02:10:05 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA00559; Mon, 24 Jun 1996 11:09:48 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA18453; Mon, 24 Jun 1996 11:09:57 +0200
Date: Mon, 24 Jun 1996 11:09:57 +0200
Message-Id: <9606240909.AA18453@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: including w3 in a dumped binary
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

A while ago I remember that someone tried to include w3 in a dumped
XEmacs binary, but there were some problem modifying a read-only object.
Well, I just tried to dump an XEmacs including w3 and got the following
backtrace:

Signalling: (error "Attempt to modify read-only object")
  w3-preparse-buffer(#<buffer " *URL*">)
  w3-prepare-buffer()
  w3-pass-to-viewer()
  w3-sentinel(#<buffer "w3.el">)
  w3-fetch("http://localhost")
  #<compiled-function (from "w3.elc") nil "...(68)" [w3-setup-done w3-do-setup w3-track-last-buffer bufferp w3-last-buffer buffer-name switch-to-buffer message "Reusing buffer.  To reload, type %s." substitute-command-keys "\\[w3-reload-document]" w3-default-homepage call-interactively w3-fetch error "Invalid setting for w3-default-homepage: %S" string-match ".*:.*" "file:"] 4 "Retrieve the default World Wide Web home page.\nThe World Wide Web is a global hypertext system started by CERN in\nSwitzerland in 1991.\n\nThe home page is specified by the variable w3-default-homepage.  The\ndocument should be specified by its fully specified Uniform Resource\nLocator.  The document will be parsed as HTML (if appropriate) and\ndisplayed in a new buffer." nil>()
  call-interactively(w3)
  command-execute(w3 t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)


After a little hunting, I found that if I reloaded w3-parse, the problem
went away (w3-parse has a lot of compile-time definitions).  I'd guess
that something was put in purespace that shouldn't be.  Because w3 does
take a while to load, IWBRNI w3 could be included in a dumped binary.
In the mean time, here's a kludge to get around the problem:

(require 'advice)

(defvar *w3-readonly-p* t)

(defadvice w3 (before w3-ensure-not-readonly-advice activate)
  "Ensure that w3-parse is reloaded.  For an emacs dumped with w3, the
side-effect is that some w3 readonly storage is made writeable."
  (when *w3-readonly-p*
    (load-library "w3-parse")
    (setq *w3-readonly-p* nil)))

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 04:43:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA11268 for xemacs-beta-people; Mon, 24 Jun 1996 04:43:03 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA11265 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 04:43:02 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA01330 for <xemacs-beta@cs.uiuc.edu>; Mon, 24 Jun 1996 04:42:55 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id KAA25652 for <xemacs-beta@cs.uiuc.edu>; Mon, 24 Jun 1996 10:44:17 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id KAA07032 for <xemacs-beta@cs.uiuc.edu>; Mon, 24 Jun 1996 10:44:02 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id KAA18737; Mon, 24 Jun 1996 10:47:27 +0100
Date: Mon, 24 Jun 1996 10:47:27 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606240947.KAA18737@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: 19.14 wierdness
X-Sun-Charset: US-ASCII

Having finally downloaded it I'm getting wierdness when starting up
on some machines.

I get "wrong type argument stringp, nil" when I start with xemacs -q.

How do get a lisp backtrace from this?

andy

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 08:19:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA11743 for xemacs-beta-people; Mon, 24 Jun 1996 08:19:17 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA11740 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 08:19:16 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA10151 for <xemacs-beta@cs.uiuc.edu>; Mon, 24 Jun 1996 08:19:17 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.52 #3)
	id E0uYBXo-0005lQ-00; Mon, 24 Jun 1996 09:19:08 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: ediff bug fixed!
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uYBXo-0005lQ-00@neal.ctd.comsat.com>
Date: Mon, 24 Jun 1996 09:19:08 -0400

I tried ediff with 19.14 today and I see that now when I do 'q' (quit)
the minibuffer message (are you sure?) is visible in at least one of
the frames (not the tiny ediff one).  Thanks for fixing it.


From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 08:17:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA11733 for xemacs-beta-people; Mon, 24 Jun 1996 08:17:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA11730 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 08:17:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA27863 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 08:17:24 -0500 (CDT)
Message-Id: <199606241317.IAA27863@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: crash on exit in precompiled
Date: Mon, 24 Jun 1996 08:17:23 -0500
From: Chuck Thompson <cthomp@xemacs.org>

This is being reported with the 4.1.3 binaries.  I remember this
happening with the Solaris binaries at one point but my memory is that
dynodump was the answer then.  Anyone got any ideas?

Martin, did you compile in sound support?


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 09:34:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA12163 for xemacs-beta-people; Mon, 24 Jun 1996 09:34:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA12160 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 09:34:14 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA11630; Mon, 24 Jun 1996 09:34:16 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.6.12/8.6.9) with ESMTP id JAA27007; Mon, 24 Jun 1996 09:34:03 -0500
Message-Id: <199606241434.JAA27007@nvwls.cc.purdue.edu>
To: Chuck Thompson <cthomp@cs.uiuc.edu>
cc: wing@666.com (Ben Wing), xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs 19.14 
In-reply-to: Your message of "Sat, 22 Jun 1996 18:59:58 EST."
             <199606222359.SAA13296@charles.cs.uiuc.edu> 
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 24 Jun 1996 09:33:59 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


Good luck on trying to get ahold of the texinfo maintainer.  I've had
no luck what so ever.

Joe

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 11:11:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA12933 for xemacs-beta-people; Mon, 24 Jun 1996 11:11:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA12930 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 11:11:47 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA29827 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 11:11:44 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id KAA28927; Mon, 24 Jun 1996 10:11:46 -0600
Received: by suomi (SMI-8.6) id KAA24447; Mon, 24 Jun 1996 10:11:45 -0600
Sender: mdb@cdc.noaa.gov
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: Re: Glyph/display-table difficulties
References: <199606241548.KAA16896@charles.cs.uiuc.edu>
Organization: CIRES, University of Colorado
X-Attribution: mb
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 24 Jun 1996 10:11:44 -0600
In-Reply-To: Chuck Thompson's message of Mon, 24 Jun 1996 10:48:58 -0500
Message-ID: <vkvighi3lr.fsf@cdc.noaa.gov>
Lines: 28
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>> On Mon, 24 Jun 1996 10:48:58 -0500,
>> Chuck Thompson(CT) wrote:

CT> In the meantime, have you tried xpm-mode.el which is already in the
CT> XEmacs distribution (in lisp/modes)?

Unfortunately, not until now.

	(1) xemacs-19.14 -q
	(2) \C-x \C-f junk.xpm
	(3) M-x xpm-mode
	==>
	Signalling: (error "Unable to parse color")
	  signal(error ("Unable to parse color"))
	  cerror("Unable to parse color")
	  apply(cerror "Unable to parse color")
	  error("Unable to parse color")
	  xpm-parse-color()
	  xpm-init()
	  xpm-mode(nil)
	  call-interactively(xpm-mode)
	  command-execute(xpm-mode t)
	  execute-extended-command(nil)
	  call-interactively(execute-extended-command)
	

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 11:21:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA12965 for xemacs-beta-people; Mon, 24 Jun 1996 11:21:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA12961 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 11:21:53 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA29895 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 11:21:50 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id KAA29100; Mon, 24 Jun 1996 10:21:47 -0600
Received: by suomi (SMI-8.6) id KAA24655; Mon, 24 Jun 1996 10:21:46 -0600
Sender: mdb@cdc.noaa.gov
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: Re: Glyph/display-table difficulties
References: <199606241548.KAA16896@charles.cs.uiuc.edu>
	<vkvighi3lr.fsf@cdc.noaa.gov>
Organization: CIRES, University of Colorado
X-Attribution: mb
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 24 Jun 1996 10:21:45 -0600
In-Reply-To: Mark Borges's message of 24 Jun 1996 10:11:44 -0600
Message-ID: <vku3w1i352.fsf@cdc.noaa.gov>
Lines: 77
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>> On 24 Jun 1996 10:11:44 -0600,
>> Mark Borges(mb) wrote:
>> On Mon, 24 Jun 1996 10:48:58 -0500,
>> Chuck Thompson(CT) wrote:

CT> In the meantime, have you tried xpm-mode.el which is already in the
CT> XEmacs distribution (in lisp/modes)?

mb> Unfortunately, not until now.

mb> 	(1) xemacs-19.14 -q
mb> 	(2) \C-x \C-f junk.xpm
mb> 	(3) M-x xpm-mode
mb> 	==>
mb> 	Signalling: (error "Unable to parse color")
mb> 	  signal(error ("Unable to parse color"))
mb> 	  cerror("Unable to parse color")
mb> 	  apply(cerror "Unable to parse color")
mb> 	  error("Unable to parse color")
mb> 	  xpm-parse-color()
mb> 	  xpm-init()
mb> 	  xpm-mode(nil)
mb> 	  call-interactively(xpm-mode)
mb> 	  command-execute(xpm-mode t)
mb> 	  execute-extended-command(nil)
mb> 	  call-interactively(execute-extended-command)
	
I should note this doesn't happen for all XPM files I've tried. I'm
not up on the XPM spec, but the following xpm file (lucid.xpm, from a
way old lemacs release I think) triggers the above. Also, etc/gnus.xpm
gives the same error. Are all these bogus xpm files?

/* XPM */
static char *lucid[] = {
/* width height ncolors chars_per_pixel */
"185 35 3 1",
/* colors */
"  m None	c None",
"- m White	c White",
"# m Black	c Black",
/* pixels */
"                                                                                                                                                                                         ",
"                                                                                                                                                                                         ",
"          ###########                      ###########                   ###########       ###############################       ###########  ####################################       ",
"          #---------#                      #---------#                   #---------#     ##-------------------------------#      #---------#  #-----------------------------------#      ",
"          #---------#                      #---------#                   #---------#    #----------------------------------#     #---------#  #------------------------------------#     ",
"         #---------#                      #---------#                   #---------#    #------------------------------------#   #---------#  #--------------------------------------#    ",
"         #---------#                      #---------#                   #---------#    #------------------------------------#   #---------#  #--------------------------------------#    ",
"         #---------#                      #---------#                   #---------#   #-------------------------------------#   #---------#  #--------------------------------------#    ",
"         #---------#                      #---------#                   #---------#   #-------------------------------------#   #---------#  #--------------------------------------#    ",
"         #---------#                      #--------#                   #----------#  #--------------------------------------#   #---------#  #--------------------------------------#    ",
"        #---------#                      #---------#                   #---------#   #--------------------------------------#  #---------#  #---------------------------------------#    ",
"        #---------#                      #---------#                   #---------#  #---------------------------------------#  #---------#  #---------------------------------------#    ",
"        #---------#                      #---------#                   #---------#  #----------###################----------#  #---------#  #---------####################----------#    ",
"        #---------#                      #--------#                   #----------#  #---------#                  #----------#  #---------#  #---------#                   #---------#    ",
"        #---------#                      #--------#                   #----------#  #--------#                   ############  #---------#  #---------#                   #---------#    ",
"       #---------#                      #---------#                   #---------#  #---------#                                #---------#  #---------#                    #--------#     ",
"       #---------#                      #---------#                   #---------#  #---------#                                #---------#  #---------#                    #--------#     ",
"       #---------#                      #--------#                   #----------#  #--------#                                 #---------#  #---------#                   #---------#     ",
"       #---------#                      #--------#                   #----------#  #--------#                                 #---------#  #---------#                   #---------#     ",
"       #---------#                      #--------#                   #----------#  #--------#                   ############  #---------#  #---------#                   #---------#     ",
"      #---------#                      #---------#                   #---------#  #---------#                   #----------# #---------#  #---------#                   #---------#      ",
"      #---------#                      #----------#                 #----------#  #----------#                 #----------#  #---------#  #---------#                   #---------#      ",
"      #---------#####################  #----------###################----------#  #----------###################----------#  #---------#  #---------####################----------#      ",
"      #-----------------------------#  #---------------------------------------#  #---------------------------------------#  #---------#  #---------------------------------------#      ",
"      #-----------------------------#  #--------------------------------------#   #--------------------------------------#   #---------#  #--------------------------------------#       ",
"     #-----------------------------#   #--------------------------------------#   #--------------------------------------#  #---------#  #---------------------------------------#       ",
"     #-----------------------------#   #-------------------------------------#    #-------------------------------------#   #---------#  #--------------------------------------#        ",
"     #-----------------------------#   #-------------------------------------#    #-------------------------------------#   #---------#  #--------------------------------------#        ",
"     #-----------------------------#   #------------------------------------#     #------------------------------------#    #---------#  #-------------------------------------#         ",
"     #-----------------------------#   #------------------------------------#     #------------------------------------#    #---------#  #-------------------------------------#         ",
"    #-----------------------------#     #---------------------------------##       #---------------------------------##    #---------#  #------------------------------------##          ",
"    #-----------------------------#      #-------------------------------#          #-------------------------------#      #---------#  #-----------------------------------#            ",
"    ###############################       ###############################            ###############################       ###########  ####################################             ",
"                                                                                                                                                                                         ",
"                                                                                                                                                                                         "
};

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 11:36:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA13105 for xemacs-beta-people; Mon, 24 Jun 1996 11:36:44 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA13102 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 11:36:43 -0500 (CDT)
Received: from monolith.spry.com (monolith.spry.com [198.185.2.198]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA15869 for <xemacs-beta@cs.uiuc.edu>; Mon, 24 Jun 1996 11:36:45 -0500 (CDT)
Received: (from wmperry@localhost) by monolith.spry.com (8.7.4/8.7.3) id JAA14010; Mon, 24 Jun 1996 09:37:24 -0700
Date: Mon, 24 Jun 1996 09:37:24 -0700
Message-Id: <199606241637.JAA14010@monolith.spry.com>
From: William Perry <wmperry@monolith.spry.com>
To: xemacs-beta@cs.uiuc.edu
Errors-to: wmperry@spry.com
Reply-to: wmperry@spry.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;
Subject: mouse-position totally screwed

mouse-position only ever returns what it is supposed to if you are over a
glyph.  Gack.  The culprit is:

  if (x >= 0 && y >= 0 &&
      pixel_to_glyph_translation (f, x, y, &x, &y, &obj_x, &obj_y, &w,
				  &bufpos, &closest, &modeline_closest,
				  &obj1, &obj2)
      != OVER_NOTHING)
    {
      XCAR (XCDR (val)) = make_int (x);
      XCDR (XCDR (val)) = make_int (y);
    }
  else
    {
      XCAR (XCDR (val)) = Qnil;
      XCDR (XCDR (val)) = Qnil;
    }

in mouse-position in frame.c.  I think what you want is:

if (x >= 0 && y >= 0) 
 {
  if (pixel_to_glyph_translation (f, x, y, &x, &y, &obj_x, &obj_y, &w,
				  &bufpos, &closest, &modeline_closest,
				  &obj1, &obj2)
      != OVER_NOTHING)
    {
      XCAR (XCDR (val)) = make_int (x);
      XCDR (XCDR (val)) = make_int (y);
    }
  }
 else
  {
    XCAR (XCDR (val)) = Qnil;
    XCDR (XCDR (val)) = Qnil;
  }

That way if you are not over a glyph, the old values of x & y are
preserved.  Or am I insane?

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 13:15:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA14104 for xemacs-beta-people; Mon, 24 Jun 1996 13:15:25 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA14087 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 13:15:20 -0500 (CDT)
Received: from gcm.com (gcm.com [146.121.48.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA00780 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 13:15:12 -0500 (CDT)
Received: (from uucp@localhost) by gcm.com (8.6.9/8.6.9) with UUCP id OAA11258 for xemacs-beta@xemacs.org; Mon, 24 Jun 1996 14:18:48 -0400
Received: from mis_bo9.it.gcm.com by gcm.com (4.1/GCM-2.0m)
	id AA03862; Mon, 24 Jun 96 14:14:33 EDT
Received: by mis_bo9.it.gcm.com (4.1/SMI-4.1)
	id AA05256; Mon, 24 Jun 96 14:14:33 EDT
Sender: dcw@gcm.com
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Question - Dumping w/ additional packages
From: David Worenklein <dcw@gcm.com>
Date: 24 Jun 1996 14:14:31 -0400
Message-Id: <am4to1gjco.fsf@gcm.com>
Lines: 13
X-Mailer: Gnus v5.2.19/XEmacs 19.13

What kind of a performance improvement do you get by dumping a (10,000
line) package into XEmacs?  Is the improvement just at startup, or is
it at runtime too? Also, if you plan on superseding a dumped package
with a new version (eg Gnus), should you not dump it?

Thanks
--
 David C. Worenklein                                       GREENWICH   CAPITAL
 Operations Support                                        M a r k e t s,  Inc
 =============================================================================
 phone: 203-625-2945                                                      ====
 fax:   203-629-2535                                                      ====
 e-mail: dcw@gcm.com                                                      ====

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 13:23:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA14206 for xemacs-beta-people; Mon, 24 Jun 1996 13:23:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA14203 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 13:23:47 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA00817 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 13:23:44 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA17520; Mon, 24 Jun 1996 13:23:38 -0500 (CDT)
Message-Id: <199606241823.NAA17520@charles.cs.uiuc.edu>
To: David Worenklein <dcw@gcm.com>
cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: Question - Dumping w/ additional packages 
In-reply-to: Your message of "24 Jun 1996 14:14:31 EDT."
             <am4to1gjco.fsf@gcm.com> 
Date: Mon, 24 Jun 1996 13:23:37 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    David> What kind of a performance improvement do you get by
    David> dumping a (10,000 line) package into XEmacs?  Is the
    David> improvement just at startup, or is it at runtime too? Also,
    David> if you plan on superseding a dumped package with a new
    David> version (eg Gnus), should you not dump it?

It is just a startup time improvement.  If you plan on superseding it
you should almost certainly not dump it.  Dumping it won't necessarily
prevent you from loading a newer version, but it could definitely
cause dependency problems.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 14:09:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA14692 for xemacs-beta-people; Mon, 24 Jun 1996 14:09:16 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14689 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 14:09:15 -0500 (CDT)
Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA01064 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 14:09:13 -0500 (CDT)
Received: from calico.cis.ohio-state.edu (calico.cis.ohio-state.edu [164.107.142.11]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id PAA23151; Mon, 24 Jun 1996 15:08:56 -0400
Received: (ware@localhost) by calico.cis.ohio-state.edu (8.6.7/8.6.4) id PAA29437; Mon, 24 Jun 1996 15:08:55 -0400
Date: Mon, 24 Jun 1996 15:08:55 -0400
Message-Id: <199606241908.PAA29437@calico.cis.ohio-state.edu>
From: Pete Ware <ware@cis.ohio-state.edu>
To: xemacs-beta@xemacs.org
Subject: VM and blank space on toolbar (XEmacs 19.14-p1)

(XEmacs 19.14-p1, hppa1.1, HPUX 9.05, gcc-2.7.0, fvwm)

I got the usual blank space on the right side of a VM frame with the
lefthand toolbar.  It's pretty tough to get it to repeat.  A resize
cleared it up.

My guesses are there is some obscure race condition that causes either
XEmacs to drop a configure notify event or fvwm is forgetting to send a
configure notify event.

--pete

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 14:05:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA14636 for xemacs-beta-people; Mon, 24 Jun 1996 14:05:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14633 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 14:05:15 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA22148 for <xemacs-beta@cs.uiuc.edu>; Mon, 24 Jun 1996 14:05:16 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id OAA24218 for <xemacs-beta@cs.uiuc.edu>; Mon, 24 Jun 1996 14:04:45 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id OAA20746 for <xemacs-beta@cs.uiuc.edu>; Mon, 24 Jun 1996 14:04:43 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id PAA19717 for <xemacs-beta@cs.uiuc.edu>; Mon, 24 Jun 1996 15:00:01 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Thanks for 19.14
Date: Mon, 24 Jun 1996 15:00:03 -0400
Message-ID: <26613.835642803@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

With the release of 19.14, I'd like to thank all of the developers and
beta testers for making 19.14 what it is today.  It's great, and I'm
looking forward to even better things in 19.15/20.0.  Keep up the good
work!

Have a virtual beer on me.  If you're ever in my neck of the woods,
I'll buy you a real beer, too!

Ray

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 13:58:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA14573 for xemacs-beta-people; Mon, 24 Jun 1996 13:58:20 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA14570 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 13:58:19 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA01023 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 13:58:15 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id MAA16255; Mon, 24 Jun 1996 12:58:20 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id MAA11498; Mon, 24 Jun 1996 12:58:17 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id MAA16061; Mon, 24 Jun 1996 12:57:54 -0600
Date: Mon, 24 Jun 1996 12:57:54 -0600
Message-Id: <199606241857.MAA16061@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: Next/Prev
Reply-To: turner@lanl.gov

[Danger: elisp idiot posting]

I realize there were problems with the Next and Previous functions,
but some folks want to try them out anyway.

So I decided to try to just stick buttons on the menubar for them.  I
do this for other things (like kill-this-buffer), so I thought it would
be easy.

I tried some variations of:

(add-menu-item nil "<<<" '(select-window (previous-window)) t "File")
(add-menu-item nil ">>>" '(select-window (next-window)) t "File")

but none of them worked.  Then I looked in lisp/x11/x-toolbar.el (like I
should have done in the first place) and found the code used to do the
toolbar functions.  I extracted that and tried this:

(add-menu-item nil "<<<" '(frame-property (selected-frame) 'window-config-stack) t "File")
(add-menu-item nil ">>>" '(frame-property (selected-frame) 'window-config-unpop-stack) t "File")

But it still doesn't do anything.

What particular form of brain-damage am I suffering from this time?

Or were the problems bad enough that I should just not do this?

Thanks,

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 14:24:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA14803 for xemacs-beta-people; Mon, 24 Jun 1996 14:24:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14800 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 14:24:03 -0500 (CDT)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.255.59.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA01121 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 14:24:01 -0500 (CDT)
Received: from vecdg.hpl.hp.com by hplb.hpl.hp.com; Mon, 24 Jun 1996 20:23:53 +0100
Date: Mon, 24 Jun 1996 20:23:53 +0100
Message-Id: <199606241923.AA219344233@hplb.hpl.hp.com>
From: Dipankar Gupta <dg@hplb.hpl.hp.com>
To: Pete Ware <ware@cis.ohio-state.edu>
Cc: xemacs-beta@xemacs.org
Subject: VM and blank space on toolbar (XEmacs 19.14-p1)
In-Reply-To: <199606241908.PAA29437@calico.cis.ohio-state.edu>
References: <199606241908.PAA29437@calico.cis.ohio-state.edu>
Mime-Version: 1.0

 > 
 > My guesses are there is some obscure race condition that causes either
 > XEmacs to drop a configure notify event or fvwm is forgetting to send a
 > configure notify event.

I have been seeing this intermittently on most betas, and I run mwm,
HP's X11R5 server on HP-UX 9.05 and Reflections/X 5.0 on Windows NT.

--Dipankar

From xemacs-beta-request@cs.uiuc.edu  Mon Jun 24 14:15:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA14715 for xemacs-beta-people; Mon, 24 Jun 1996 14:15:47 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14712 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 24 Jun 1996 14:15:45 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA01089 for <xemacs-beta@xemacs.org>; Mon, 24 Jun 1996 14:15:43 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA17745; Mon, 24 Jun 1996 14:15:37 -0500 (CDT)
Message-Id: <199606241915.OAA17745@charles.cs.uiuc.edu>
To: Pete Ware <ware@cis.ohio-state.edu>
cc: xemacs-beta@xemacs.org
Subject: Re: VM and blank space on toolbar (XEmacs 19.14-p1) 
In-reply-to: Your message of "Mon, 24 Jun 1996 15:08:55 EDT."
             <199606241908.PAA29437@calico.cis.ohio-state.edu> 
Date: Mon, 24 Jun 1996 14:15:36 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Pete> I got the usual blank space on the right side of a VM frame
    Pete> with the lefthand toolbar.  It's pretty tough to get it to
    Pete> repeat.  A resize cleared it up.

    Pete> My guesses are there is some obscure race condition that
    Pete> causes either XEmacs to drop a configure notify event or
    Pete> fvwm is forgetting to send a configure notify event.


That is pretty much what I had determined quite some time ago.  It is
a lot easier to duplicate using balloon-help until you start trying to
trace it with a debugger.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 04:29:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA22640 for xemacs-beta-people; Tue, 25 Jun 1996 04:29:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA22637 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 04:29:41 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA05127; Tue, 25 Jun 1996 04:29:36 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id CAA15794; Tue, 25 Jun 1996 02:29:09 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id CAA04290; Tue, 25 Jun 1996 02:29:07 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA24681; Tue, 25 Jun 1996 02:29:05 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id CAA04945; Tue, 25 Jun 1996 02:29:04 -0700
Date: Tue, 25 Jun 1996 02:29:04 -0700
Message-Id: <199606250929.CAA04945@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: crash on exit in precompiled
In-Reply-To: <199606241317.IAA27863@xemacs.cs.uiuc.edu>
References: <199606241317.IAA27863@xemacs.cs.uiuc.edu>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

Chuck> This is being reported with the 4.1.3 binaries.  I remember this
Chuck> happening with the Solaris binaries at one point but my memory is that
Chuck> dynodump was the answer then.  Anyone got any ideas?

Strangely enough, I can only reproduce this problem running
Solaris2.4 binaries on a Solaris2.6 machine.

Here's a theory:  XEmacs binaries built on X11R5 tend to crash when
run on X11R6.  Happens with 20.0 beta 26 as well.  Are the 4.1.3
crashes happening on systems where X11R6 is being used?

Chuck> Martin, did you compile in sound support?

No, I'll try to create new binaries with sound support.  None of the
non-sparc-solaris2 machines I have access to today have a
/usr/demo/SOUND.  I wouldn't have expected native sound to work well
on non-sparc-solaris machines.  I tried to compile NAS for a while,
but gave up - it doesn't seem to be very high quality software (yet).

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 04:46:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA22690 for xemacs-beta-people; Tue, 25 Jun 1996 04:46:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA22687 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 04:46:24 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA18887 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 04:46:24 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id CAA19672; Tue, 25 Jun 1996 02:45:54 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id CAA04943; Tue, 25 Jun 1996 02:45:52 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA24752; Tue, 25 Jun 1996 02:45:47 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id CAA05007; Tue, 25 Jun 1996 02:45:45 -0700
Date: Tue, 25 Jun 1996 02:45:45 -0700
Message-Id: <199606250945.CAA05007@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: andyp@parallax.co.uk (Andy Piper)
Cc: xemacs-beta@cs.uiuc.edu
Subject: 19.14 wierdness
In-Reply-To: <199606240947.KAA18737@wrath.parallax.co.uk>
References: <199606240947.KAA18737@wrath.parallax.co.uk>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Andy" == Andy Piper <andyp@parallax.co.uk> writes:

Andy> Having finally downloaded it I'm getting wierdness when starting up
Andy> on some machines.

Andy> I get "wrong type argument stringp, nil" when I start with xemacs -q.

Is this with sparcworks support?  If so, it may be a bug in
sunpro-init.el that sure looks fixed to me in 19.14.  Perhaps you
patched up and failed to properly byte-compile sunpro-init.el?

Andy> How do get a lisp backtrace from this?

When I was faced with this very problem, I edited the startup files to
add
(setq debug-on-error t)

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 04:58:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA22734 for xemacs-beta-people; Tue, 25 Jun 1996 04:58:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA22731 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 04:58:41 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA18999 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 04:58:40 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id LAA16002; Tue, 25 Jun 1996 11:00:00 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id KAA07173; Tue, 25 Jun 1996 10:59:44 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id LAA07990; Tue, 25 Jun 1996 11:03:11 +0100
Date: Tue, 25 Jun 1996 11:03:11 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606251003.LAA07990@wrath.parallax.co.uk>
To: mrb@eng.sun.com
Subject: Re: 19.14 wierdness
Cc: xemacs-beta@cs.uiuc.edu
X-Sun-Charset: US-ASCII

> >>>>> "Andy" == Andy Piper <andyp@parallax.co.uk> writes:
> 
> Andy> Having finally downloaded it I'm getting wierdness when starting up
> Andy> on some machines.
> 
> Andy> I get "wrong type argument stringp, nil" when I start with xemacs -q.
> 
> Is this with sparcworks support?  If so, it may be a bug in
> sunpro-init.el that sure looks fixed to me in 19.14.  Perhaps you
> patched up and failed to properly byte-compile sunpro-init.el?

I got the complete p1 and patched up to r. The wierd thing is it works
on my machine but not any others.

> Andy> How do get a lisp backtrace from this?
> 
> When I was faced with this very problem, I edited the startup files to
> add
> (setq debug-on-error t)

Which startup file? :) Sorry for sounding dumb

andy

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 06:52:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA23317 for xemacs-beta-people; Tue, 25 Jun 1996 06:52:41 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA23314 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 06:52:40 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA21767 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 06:52:17 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id MAA18945; Tue, 25 Jun 1996 12:53:38 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id MAA10443; Tue, 25 Jun 1996 12:53:22 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id MAA08285; Tue, 25 Jun 1996 12:56:48 +0100
Date: Tue, 25 Jun 1996 12:56:48 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606251156.MAA08285@wrath.parallax.co.uk>
To: mrb@eng.sun.com
Subject: sunpro-startup?
Cc: xemacs-beta@cs.uiuc.edu
X-Sun-Charset: US-ASCII

Why does sunpro-startup check for the existance of bin/workshop or
lib/workshop.el? I have C++ visual workshop 2.1 and neither of these exist
in the installation, I would have though you would do much better
to look for bin/sparcworks. If I do this then the error I'm getting goes
away.

This is the problem:


Signalling: (wrong-type-argument stringp nil)
  string-match("/$" nil)
  sunpro-startup()
  run-hooks(before-init-hook)
  load-init-file()
  command-line()
  normal-top-level()


andy

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 07:43:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA23531 for xemacs-beta-people; Tue, 25 Jun 1996 07:43:13 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA23528 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 07:43:12 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA22713 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 07:43:13 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.53 #1)
	id E0uYXSa-0006Wf-00; Tue, 25 Jun 1996 08:43:12 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: 19.14 Xlib errors hpux9.05
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uYXSa-0006Wf-00@neal.ctd.comsat.com>
Date: Tue, 25 Jun 1996 08:43:12 -0400

I'm getting a lot of this on 19.14 hpux9.05 (X11R5):

xemacs: X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  88 (X_FreeColors)
  Serial number of failed request:  185046
  Current serial number in output stream:  185054

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 10:01:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA24642 for xemacs-beta-people; Tue, 25 Jun 1996 10:01:55 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA24639 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 10:01:54 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA06952 for <xemacs-beta@xemacs.org>; Tue, 25 Jun 1996 10:01:51 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id JAA20109; Tue, 25 Jun 1996 09:01:54 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id JAA20816; Tue, 25 Jun 1996 09:01:52 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id JAA20325; Tue, 25 Jun 1996 09:01:29 -0600
Date: Tue, 25 Jun 1996 09:01:29 -0600
Message-Id: <199606251501.JAA20325@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: praise-be-unto-xemacs
Reply-To: turner@lanl.gov

19.14b25, Solaris 2.5, CDE 1.0.1, SunPro C 4.0
Motif dialogs, Lucid scrollbars & menus

---

When I tried this on the version of 19.14 final I compiled I get:

Signalling: (wrong-type-argument stringp t)
  play-sound-file(t)
  byte-code(<snip>!)<snip>" [arg 0 face-list max-faces count "*Praise*" insert-face xemacs-praise-message get-face random 1 file-exists-p xemacs-praise-sound-file data-directory sound-file device-sound-enabled-p sit-for play-sound-file 10] 7)
  praise-be-unto-xemacs(1)
  call-interactively(praise-be-unto-xemacs)
  command-execute(praise-be-unto-xemacs t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

where the <snip>s represent deleted binary grunge.  When I configured,
configure said:

  Compiling in native sound support.

so I'm not sure why this happens (this is starting with -q, btw).

The precompiled Solaris 2.4 binary works fine.

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 11:13:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA25135 for xemacs-beta-people; Tue, 25 Jun 1996 11:13:34 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA25132 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 11:13:33 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA07335 for <xemacs-beta@xemacs.org>; Tue, 25 Jun 1996 11:13:30 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA20314; Tue, 25 Jun 1996 11:13:33 -0500 (CDT)
Message-Id: <199606251613.LAA20314@charles.cs.uiuc.edu>
To: turner@lanl.gov
cc: xemacs-beta@xemacs.org
Subject: Re: praise-be-unto-xemacs 
In-reply-to: Your message of "Tue, 25 Jun 1996 09:01:29 MDT."
             <199606251501.JAA20325@gielgud.lanl.gov.xdiv> 
Date: Tue, 25 Jun 1996 11:13:32 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

There were two "final" releases.  The second final had a small patch
to Makefile.in.in for HPUX10 and a patch for your problem.  I've put
the correct version of advocacy.el at ftp.xemacs.org:/pub/beta/xemacs-19.14



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 11:18:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA25187 for xemacs-beta-people; Tue, 25 Jun 1996 11:18:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA25184 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 11:18:37 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA07366 for <xemacs-beta@xemacs.org>; Tue, 25 Jun 1996 11:18:33 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id KAA06801; Tue, 25 Jun 1996 10:18:36 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id KAA22160; Tue, 25 Jun 1996 10:18:33 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id KAA20388; Tue, 25 Jun 1996 10:18:10 -0600
Date: Tue, 25 Jun 1996 10:18:10 -0600
Message-Id: <199606251618.KAA20388@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: cthomp@cs.uiuc.edu
Cc: xemacs-beta@xemacs.org
Subject: Re: praise-be-unto-xemacs 
In-Reply-To: <199606251613.LAA20314@charles.cs.uiuc.edu>
References: <199606251501.JAA20325@gielgud.lanl.gov.xdiv>
	<199606251613.LAA20314@charles.cs.uiuc.edu>
Reply-To: turner@lanl.gov

Chuck Thompson writes:

 > There were two "final" releases.  The second final had a small patch
 > to Makefile.in.in for HPUX10 and a patch for your problem.  I've put
 > the correct version of advocacy.el at ftp.xemacs.org:/pub/beta/xemacs-19.14

Ah.  I remember the stuff about the HP-UX 10 problem, but must have
missed the other.  Sorry...

-John

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 12:03:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA25590 for xemacs-beta-people; Tue, 25 Jun 1996 12:03:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA25587 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 12:03:45 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA07818 for <xemacs-beta@xemacs.org>; Tue, 25 Jun 1996 12:03:41 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id LAA17601; Tue, 25 Jun 1996 11:03:42 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id LAA23445; Tue, 25 Jun 1996 11:03:40 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id LAA20473; Tue, 25 Jun 1996 11:03:17 -0600
Date: Tue, 25 Jun 1996 11:03:17 -0600
Message-Id: <199606251703.LAA20473@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Cc: Hall@lanl.gov
Subject: Re: Summertime CD cutoff date
In-Reply-To: <Pine.SOL.3.91.960625185003.3004H-100000@serv>
References: <31C19504.16B@lanl.gov>
	<Pine.SOL.3.91.960625185003.3004H-100000@serv>
Reply-To: turner@lanl.gov

I just received the following.  This is the CD with loads of Solaris
2.5 binaries in pkgadd format.  The last one (Wintertime), had XEmacs
19.13 on it.  Has anyone contacted them about getting 19.14 on there?

Bernd Kratz writes:
 > > 
 > > What is the cutoff date for getting things onto the Summertime CD?
 >
 > Thanks for your interrest. The Summertime CD will be ready in 3-4 weeks.

Again, the URL for Wintertime is http://www.alli.fi/~ben/wintertime.html.

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 12:43:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA26035 for xemacs-beta-people; Tue, 25 Jun 1996 12:43:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA26032 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 12:43:13 -0500 (CDT)
Received: from gcm.com (gcm.com [146.121.48.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA08032 for <xemacs-beta@xemacs.org>; Tue, 25 Jun 1996 12:43:09 -0500 (CDT)
Received: (from uucp@localhost) by gcm.com (8.6.9/8.6.9) with UUCP id NAA21302 for xemacs-beta@xemacs.org; Tue, 25 Jun 1996 13:46:47 -0400
Received: from mis_bo9.it.gcm.com by gcm.com (4.1/GCM-2.0m)
	id AA04645; Tue, 25 Jun 96 13:42:49 EDT
Received: by mis_bo9.it.gcm.com (4.1/SMI-4.1)
	id AA10003; Tue, 25 Jun 96 13:42:48 EDT
Sender: dcw@gcm.com
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Really slow XEmacs
From: David Worenklein <dcw@gcm.com>
Date: 25 Jun 1996 13:42:47 -0400
Message-Id: <amzq5rrd9k.fsf@gcm.com>
Lines: 18
X-Mailer: Gnus v5.2.25/XEmacs 19.14

I found that as soon as I start sql-mode (and, particularly, within
sql-mode) typing slows to an unusable speed.  So I quantified XEmacs,
typed about two hundred random characters, and found that readchar (in lread.c)
was called five MILLION times from read1.  read1 took 35.25% of the
time, and readchar took about half of that.

I've never really delved into the C code, but what the hell would you
want to do 25,000 times per keystroke?

(I'll send anyone the .qv output if he or she wants it.)
-- 
--
 David C. Worenklein                                       GREENWICH   CAPITAL
 Operations Support                                        M a r k e t s,  Inc
 =============================================================================
 phone: 203-625-2945                                                      ====
 fax:   203-629-2535                                                      ====
 e-mail: dcw@gcm.com                                                      ====

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 12:52:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA26123 for xemacs-beta-people; Tue, 25 Jun 1996 12:52:17 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA26117 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 12:52:15 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA06895 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 12:52:16 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.53 #1)
	id E0uYcHe-00008i-00; Tue, 25 Jun 1996 13:52:14 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: SIGTTOU hpux9.05
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uYcHe-00008i-00@neal.ctd.comsat.com>
Date: Tue, 25 Jun 1996 13:52:14 -0400

Here is what I see regarding the gnuattach problem.

Program received signal SIGTTOU, Stopped (tty output).
0x800c1980 in ioctl ()
(gdb) where
#0  0x800c1980 in ioctl ()
#1  0x800fb1d8 in reset_shell_mode ()
#2  0x800f0e6c in tgetent ()
#3  0x11cf44 in init_tty_for_redisplay (d=0x4030e100, 
    terminal_type=0x403479f8 "xterm") at redisplay-tty.c:1091
#4  0x119bf8 in tty_init_device (d=0x4030e100, props=1074942977)
    at device-tty.c:68
#5  0x59064 in Fmake_device (type=1077069824, connection=807980680, 
    props=538912356) at device.c:591
#6  0x6e118 in primitive_funcall (fn=0x7b038060 <errno+35376>, 
    nargs=1074942977, args=0x0) at eval.c:3488
#7  0x6e39c in funcall_subr (subr=0x1, args=0x40125401) at eval.c:3526
#8  0x6d728 in funcall_recording_as (recorded_as=1, nargs=3, args=0x7b035e00)
    at eval.c:3231
#9  0x6d7cc in Ffuncall (nargs=1, args=0x40125401) at eval.c:3253
#10 0x46bc4 in Fbyte_code (bytestr=805466388, vector=1073901868, 
    maxdepth=269512484) at bytecode.c:450
#11 0x6ea3c in funcall_lambda (fun=268595516, nargs=2, arg_vector=0x7b035a04)
    at eval.c:3636
#12 0x6d728 in funcall_recording_as (recorded_as=1, nargs=2, args=0x7b035a00)
    at eval.c:3231
#13 0x6d7cc in Ffuncall (nargs=1, args=0x40125401) at eval.c:3253
#14 0x46bc4 in Fbyte_code (bytestr=807725672, vector=1076964736, 
---Type <return> to continue, or q <return> to quit--- 
    maxdepth=271772060) at bytecode.c:450
#15 0x6ea3c in funcall_lambda (fun=271653924, nargs=3, arg_vector=0x7b035604)
    at eval.c:3636
#16 0x6d728 in funcall_recording_as (recorded_as=1, nargs=3, args=0x7b035600)
    at eval.c:3231
#17 0x6d7cc in Ffuncall (nargs=1, args=0x40125401) at eval.c:3253
#18 0x46bc4 in Fbyte_code (bytestr=807727528, vector=1077070720, 
    maxdepth=269498444) at bytecode.c:450
#19 0x6ea3c in funcall_lambda (fun=271654052, nargs=3, arg_vector=0x7b0353c0)
    at eval.c:3636
#20 0x6e4b0 in apply_lambda (fun=271654052, numargs=3, 
    unevalled_args=269398020) at eval.c:3559
#21 0x6d060 in Feval (form=538912444) at eval.c:3086
#22 0x6e0e4 in primitive_funcall (fn=0x7b038060 <errno+35376>, 
    nargs=1074942977, args=0x0) at eval.c:3484
#23 0x6e39c in funcall_subr (subr=0x1, args=0x40125401) at eval.c:3526
#24 0x6d728 in funcall_recording_as (recorded_as=1, nargs=1, args=0x7b034e00)
    at eval.c:3231
#25 0x6d7cc in Ffuncall (nargs=1, args=0x40125401) at eval.c:3253
#26 0x46bc4 in Fbyte_code (bytestr=807845620, vector=1077100512, 
    maxdepth=538912396) at bytecode.c:450
#27 0x6e118 in primitive_funcall (fn=0x7b038060 <errno+35376>, 
    nargs=1074942977, args=0x0) at eval.c:3488
---Type <return> to continue, or q <return> to quit---

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 14:16:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA26869 for xemacs-beta-people; Tue, 25 Jun 1996 14:16:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA26866 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 14:16:39 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA11523 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 14:16:40 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id MAA29910; Tue, 25 Jun 1996 12:16:08 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA27401; Tue, 25 Jun 1996 12:16:06 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA02167; Tue, 25 Jun 1996 12:16:04 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA07858; Tue, 25 Jun 1996 12:16:01 -0700
Date: Tue, 25 Jun 1996 12:16:01 -0700
Message-Id: <199606251916.MAA07858@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: andyp@parallax.co.uk (Andy Piper)
Cc: xemacs-beta@cs.uiuc.edu
Subject: sunpro-startup?
In-Reply-To: <199606251156.MAA08285@wrath.parallax.co.uk>
References: <199606251156.MAA08285@wrath.parallax.co.uk>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Andy" == Andy Piper <andyp@parallax.co.uk> writes:

Andy> Why does sunpro-startup check for the existance of bin/workshop or
Andy> lib/workshop.el? I have C++ visual workshop 2.1 and neither of these exist
Andy> in the installation, I would have though you would do much better
Andy> to look for bin/sparcworks. If I do this then the error I'm getting goes
Andy> away.

sparcworks is going away, to be replaced by something called
`workshop'.  I wanted the Net binaries to have half a chance of
working when the next batch of Sun Developer products ships (as well
as continuing to work with the old products, of course!)

When a customer installs the workshop binary, it is used in preference
to sparcworks.

I've tested the following scenarios with the Net distribution:
- workshop && sparcworks installed (WorkShop toolbar button appears)
- sparcworks installed (19.13 behavior)
- neither (user gets a warning, but not an error)

Andy> This is the problem:

Andy> Signalling: (wrong-type-argument stringp nil)
Andy>   string-match("/$" nil)
Andy>   sunpro-startup()
Andy>   run-hooks(before-init-hook)
Andy>   load-init-file()
Andy>   command-line()
Andy>   normal-top-level()

Yes, this problem used to exist, but isn't it fixed now?

Are you really sure you don't have a private copy of one of the sunpro
files or you've patched up incorrectly?

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 15:42:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA27759 for xemacs-beta-people; Tue, 25 Jun 1996 15:42:35 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA27756 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 15:42:33 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA13989 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 15:42:35 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id NAA27783; Tue, 25 Jun 1996 13:42:02 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id NAA10363; Tue, 25 Jun 1996 13:41:59 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA03490; Tue, 25 Jun 1996 13:41:57 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA11482; Tue, 25 Jun 1996 13:41:55 -0700
Date: Tue, 25 Jun 1996 13:41:55 -0700
Message-Id: <199606252041.NAA11482@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: ben@alli.fi, vale@mathematik.uni-kassel.de
Cc: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: wintertime/summertime and XEmacs 19.14
Reply-To: Martin Buchholz <mrb@eng.sun.com>

You really should put the recently released XEmacs 19.14 on your next
CD.   I actually build packages myself these days, for use with the
Sun Developer Products CD, so I can make those same packages available
to you.

If you have any questions, or want to make an ftp site available to
me, please send me email.

P.S.  Deutsch verstehe ich auch.

-- 
Martin Buchholz
XEmacs Developer
Developers' Product Business Unit, SunSoft, Sun Microsystems, Inc.

Mailstop: MPK16-305           |  Email: Martin.Buchholz@sun.com
2550 Garcia Avenue            |  Phone: (415) 786-5895
Mountain View, CA 94043-1100  |    Fax: (415) 786-9552

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 15:44:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA27813 for xemacs-beta-people; Tue, 25 Jun 1996 15:44:13 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA27810 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 15:44:11 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA14024 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 15:44:13 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.53 #1)
	id E0uYey3-0000Dt-00; Tue, 25 Jun 1996 16:44:11 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: trying to track down sigttou
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uYey3-0000Dt-00@neal.ctd.comsat.com>
Date: Tue, 25 Jun 1996 16:44:11 -0400

Trying to track down sigttou from gnuattach on hpux9.05.  I stymied.
How can it be that xemacs gets SIGTTOU when it's controlling terminal
is /dev/ttyp1, and /dev/ttyp1 says:

stty -all < /dev/ttyp1
speed 9600 baud; rows 24; columns 80;
intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = ^@; eol2 = ^@;
swtch = ^@; start = ^Q; stop = ^S; susp = ^Z; min = 1; time = 0;
parenb -parodd cs8 hupcl -cstopb cread -clocal
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff
-iuclc -ixany
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop

Notice the -tostop.  This is not possible, right?  Also, I see that
both gnuattach and gnuserv say they have different process groups from
xemacs (I thought maybe it was some other process in the same process
group as xemacs that caused the signal to be sent to the whole group,
but yamm reports that the process group for gnuserv and gnuattach are
not the same as xemacs).


From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 17:07:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA29365 for xemacs-beta-people; Tue, 25 Jun 1996 17:07:32 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA29362 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 17:07:31 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA17540 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 17:07:33 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id PAA26579; Tue, 25 Jun 1996 15:06:58 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id PAA26283; Tue, 25 Jun 1996 15:06:53 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA05419; Tue, 25 Jun 1996 15:06:48 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA13634; Tue, 25 Jun 1996 15:06:46 -0700
Date: Tue, 25 Jun 1996 15:06:46 -0700
Message-Id: <199606252206.PAA13634@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Steve Christensen <steve@smc.vnet.net>
Cc: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: XEmacs 19.14 on vnet.net?
Reply-To: Martin Buchholz <mrb@eng.sun.com>

You really should put the recently released XEmacs 19.14 on your web
site of packages for Solaris in pkgadd format.  I actually build
packages myself these days, for use with the Sun Developer Products
CD, so I can make those same packages available to you.

XEmacs can be found at ftp://ftp.xemacs.org or http://www.xemacs.org

If you have any questions, or want to make an ftp site available to
me, please send me email.

-- 
Martin Buchholz
XEmacs Developer
Developers' Product Business Unit, SunSoft, Sun Microsystems, Inc.

Mailstop: MPK16-305           |  Email: Martin.Buchholz@sun.com
2550 Garcia Avenue            |  Phone: (415) 786-5895
Mountain View, CA 94043-1100  |    Fax: (415) 786-9552

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 18:16:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA29862 for xemacs-beta-people; Tue, 25 Jun 1996 18:16:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA29855 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 18:16:36 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA10145 for <xemacs-beta@xemacs.org>; Tue, 25 Jun 1996 18:16:32 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id RAA20903; Tue, 25 Jun 1996 17:16:36 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id RAA29743; Tue, 25 Jun 1996 17:16:34 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id RAA21397; Tue, 25 Jun 1996 17:16:11 -0600
Date: Tue, 25 Jun 1996 17:16:11 -0600
Message-Id: <199606252316.RAA21397@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: smileys and VM (also a Gnus typo)
Reply-To: turner@lanl.gov

This will probably be one for the FAQ, but how do I get VM to use
smiley.el?

I tried:

(require 'smiley)
(add-hook 'vm-select-message-hook 'gnus-smiley-display t)

in my .vm, but it barfed on:

(defvar smiley-data-directory (message-xmas-find-glyph-directory "smilies")
  "Location of the smiley faces files.")

in smiley.el.  If I'd started Gnus first, I guess it would work.  I'm
thinking I should just hard-code smiley-data-directory or 
message-xmas-find-glyph-directory or something, but thought I'd check
to see if someone else has done this more elegantly.

Also, I notice in smiley.el:

(defvar smiley-tongue-color "red"
  "Tongue color.")

(defvar smiley-circle-color "black"
  "Tongue color.")
   ^^^^^^
   Should be "Border" or something.  Looks like a cut'n'paste error.
   Not that anyone really cares...

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 19:04:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA00197 for xemacs-beta-people; Tue, 25 Jun 1996 19:04:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA00194 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 19:04:28 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA19502 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 19:04:24 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id RAA20136; Tue, 25 Jun 1996 17:03:33 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: smileys and VM (also a Gnus typo)
References: <199606252316.RAA21397@gielgud.lanl.gov.xdiv>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: John Turner's message of Tue, 25 Jun 1996 17:16:11 -0600
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 25 Jun 1996 17:03:32 -0700
Message-ID: <m220j3a0tn.fsf@deanna.miranova.com>
Lines: 26
X-Mailer: Gnus v5.3/Emacs 19.31

>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:

John> This will probably be one for the FAQ, but how do I get VM to use
John> smiley.el?

John> I tried:

John> (require 'smiley)
John> (add-hook 'vm-select-message-hook 'gnus-smiley-display t)

This one is already in the FAQ:
Subject: Q4.0.11 How do I make VM or mh-e display graphical smilies? [New]
                                    
   For mh-e use the following:     
(add-hook 'mh-show-mode-hook '(lambda () (smiley-region (point-min)  
                                                        (point-max))))
 
   For vm use the following:              
(require 'smiley)                                                        
(require 'messagexmas)    
(add-hook 'vm-select-message-hook '(lambda () (smiley-region (point-min)
                                                             (point-max))))
          
-- 
steve@miranova.com baur
GNU Emacs 19.31.2 (i486-unknown-linux, X toolkit) of Tue May 28 1996 on deanna.miranova.com

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 19:47:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA00549 for xemacs-beta-people; Tue, 25 Jun 1996 19:47:53 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA00546 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 19:47:51 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA20252 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 19:47:53 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id SAA26699; Tue, 25 Jun 1996 18:47:52 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id SAA00706; Tue, 25 Jun 1996 18:47:50 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id SAA21487; Tue, 25 Jun 1996 18:47:27 -0600
Date: Tue, 25 Jun 1996 18:47:27 -0600
Message-Id: <199606260047.SAA21487@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: steve@miranova.com, xemacs-beta@cs.uiuc.edu
Subject: Re: :) Re: smileys and VM (also a Gnus typo)
In-Reply-To: <199606260040.SAA21483@gielgud.lanl.gov.xdiv>
References: <199606252316.RAA21397@gielgud.lanl.gov.xdiv>
	<m220j3a0tn.fsf@deanna.miranova.com>
	<199606260040.SAA21483@gielgud.lanl.gov.xdiv>
Reply-To: turner@lanl.gov

I wrote:

 > What if there's a smiley in the subject line?

I wasn't very clear here.  What I'm getting at is displaying them in
the Summary buffer...

-John

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 19:41:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA00510 for xemacs-beta-people; Tue, 25 Jun 1996 19:41:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA00507 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 19:41:09 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA20033 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 19:41:06 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id SAA26388; Tue, 25 Jun 1996 18:40:57 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id SAA00648; Tue, 25 Jun 1996 18:40:54 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id SAA21483; Tue, 25 Jun 1996 18:40:32 -0600
Date: Tue, 25 Jun 1996 18:40:32 -0600
Message-Id: <199606260040.SAA21483@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu
Subject: :) Re: smileys and VM (also a Gnus typo)
In-Reply-To: <m220j3a0tn.fsf@deanna.miranova.com>
References: <199606252316.RAA21397@gielgud.lanl.gov.xdiv>
	<m220j3a0tn.fsf@deanna.miranova.com>
Reply-To: turner@lanl.gov

Steven L. Baur writes:

 > This one is already in the FAQ:
 > Subject: Q4.0.11 How do I make VM or mh-e display graphical smilies? [New]
 >                                     
 >    For mh-e use the following:     
 > (add-hook 'mh-show-mode-hook '(lambda () (smiley-region (point-min)  
 >                                                         (point-max))))
 >  
 >    For vm use the following:              
 > (require 'smiley)                                                        
 > (require 'messagexmas)    
 > (add-hook 'vm-select-message-hook '(lambda () (smiley-region (point-min)
 >                                                              (point-max))))

Ack.  My bad.  :)

Dan Rich sent me that as well.  To which I responded...

John Turner writes:
 > Your suggestion works great.  But two other things.
 > 
 > I know, I know, it's stupid.
 > 
 > What if there's a smiley in the subject line?
 > 
 > I first tried vm-summary-update-hook, but that didn't quite work.
 > vm-summary-pointer-update-hook was better, but that's still not quite
 > it.  What do you think?
 > 
 > There's also mail composition buffers...
 > 
 > -John
 > 
 > P.S. One thing I fear is an explosion of smiley use on the beta
 > list. :)  Ack!  See what I mean?

I added a :) to the front of the Subject, as that's one of the things
I had a problem with.

The other problem is whether they get re-done at the right times
(visiting other folders, etc.).

I know, this is silly.  But it's the cool kind of silly.  :)

-John

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 20:10:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA00665 for xemacs-beta-people; Tue, 25 Jun 1996 20:10:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA00662 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 20:10:09 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA25392 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 20:10:10 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id SAA02018; Tue, 25 Jun 1996 18:09:37 -0700
Date: Tue, 25 Jun 1996 18:09:37 -0700
Message-Id: <199606260109.SAA02018@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: turner@lanl.gov
Cc: steve@miranova.com, xemacs-beta@cs.uiuc.edu
Subject: Re: :) Re: smileys and VM (also a Gnus typo)
In-Reply-To: <199606260047.SAA21487@gielgud.lanl.gov.xdiv>
References: <199606252316.RAA21397@gielgud.lanl.gov.xdiv>
	<m220j3a0tn.fsf@deanna.miranova.com>
	<199606260040.SAA21483@gielgud.lanl.gov.xdiv>
	<199606260047.SAA21487@gielgud.lanl.gov.xdiv>
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.48)
Content-Type: text/plain; charset=US-ASCII

>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:

    John> I wrote:
    >> What if there's a smiley in the subject line?

    John> I wasn't very clear here.  What I'm getting at is displaying them in
    John> the Summary buffer...

How about this?

      ;; Setup smiley code
      (require 'messagexmas)
      (require 'smiley)
      (add-hook 'vm-select-message-hook 'smiley-buffer)
      (add-hook 'vm-summary-mode-hook 'smiley-buffer)
      (add-hook 'vm-summary-update-hook 'smiley-buffer)
      (add-hook 'vm-summary-redo-hook 'smiley-buffer)

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 21:27:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA01343 for xemacs-beta-people; Tue, 25 Jun 1996 21:27:10 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA01340 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 21:27:08 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA26777 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 21:27:08 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA23641; Tue, 25 Jun 1996 19:26:08 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Two Documentation Glitches
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 25 Jun 1996 19:26:06 -0700
Message-ID: <m2u3vzqp1c.fsf@deanna.miranova.com>
Lines: 14
X-Mailer: Gnus v5.2.25/XEmacs 19.14

1.  The main info directory says that the user's manual is for 19.14,
    however, the user's manual itself says it is for 19.13.

2.  In the Internals manual the timeline is wrong with respect to the
    great renaming.  The great Usenet renaming was completed by 1Q
    1987, not 1989 (along with an announcement on April 1st of that
    year that it had all been a mistake and the old names were being
    restored).

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Tue Jun 25 21:58:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA01451 for xemacs-beta-people; Tue, 25 Jun 1996 21:58:37 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA01448 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 25 Jun 1996 21:58:36 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA27166 for <xemacs-beta@cs.uiuc.edu>; Tue, 25 Jun 1996 21:58:32 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id UAA00558; Tue, 25 Jun 1996 20:58:30 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id UAA01313; Tue, 25 Jun 1996 20:58:27 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id UAA21975; Tue, 25 Jun 1996 20:58:00 -0600
Date: Tue, 25 Jun 1996 20:58:00 -0600
Message-Id: <199606260258.UAA21975@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: drich@cisco.com
Cc: steve@miranova.com, xemacs-beta@cs.uiuc.edu
Subject: Re: :) Re: smileys and VM (also a Gnus typo)
In-Reply-To: <199606260109.SAA02018@sandman.cisco.com>
References: <199606252316.RAA21397@gielgud.lanl.gov.xdiv>
	<m220j3a0tn.fsf@deanna.miranova.com>
	<199606260040.SAA21483@gielgud.lanl.gov.xdiv>
	<199606260047.SAA21487@gielgud.lanl.gov.xdiv>
	<199606260109.SAA02018@sandman.cisco.com>
Reply-To: turner@lanl.gov

Dan Rich writes:
 > How about this?
 > 
 >       ;; Setup smiley code
 >       (require 'messagexmas)
 >       (require 'smiley)
 >       (add-hook 'vm-select-message-hook 'smiley-buffer)
 >       (add-hook 'vm-summary-mode-hook 'smiley-buffer)
 >       (add-hook 'vm-summary-update-hook 'smiley-buffer)
 >       (add-hook 'vm-summary-redo-hook 'smiley-buffer)

Works for me.  Thanks.

Except smileys at the very start of the Subject line aren't converted
in Summary buffers.  Probably smiley.el, though I haven't looked...

-John

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 00:09:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA01957 for xemacs-beta-people; Wed, 26 Jun 1996 00:09:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA01954 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 00:09:15 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA00810 for <xemacs-beta@cs.uiuc.edu>; Wed, 26 Jun 1996 00:09:16 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id OAA10945; Wed, 26 Jun 1996 14:09:00 +0900 (JST)
Message-Id: <199606260509.OAA10945@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: smileys and VM (also a Gnus typo) 
In-reply-to: Your message of "25 Jun 1996 17:03:32 MST."
             <m220j3a0tn.fsf@deanna.miranova.com> 
Mime-Version: 1.0 (SEMI mime-edit 0.26)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 26 Jun 1996 14:09:05 JST
Sender: morioka@jaist.ac.jp

>>>>> In <m220j3a0tn.fsf@deanna.miranova.com> 
>>>>>	Steven L Baur <steve@miranova.com> wrote:

Steven> >>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:

John> This will probably be one for the FAQ, but how do I get VM to use
John> smiley.el?

John> I tried:

John> (require 'smiley)
John> (add-hook 'vm-select-message-hook 'gnus-smiley-display t)

Steven> This one is already in the FAQ:
Steven> Subject: Q4.0.11 How do I make VM or mh-e display graphical
Steven> smilies? [New]
                                    
Steven>    For mh-e use the following:     
> (add-hook 'mh-show-mode-hook '(lambda () (smiley-region (point-min)  
>                                                         (point-max))))
 
Steven>    For vm use the following:              
> (require 'smiley)                                                        
> (require 'messagexmas)    
> (add-hook 'vm-select-message-hook '(lambda () (smiley-region (point-min)
>                                                              (point-max))))

  For tm use the following:

(autoload 'smiley-buffer "smiley" nil t)
(add-hook 'mime-viewer/plain-text-preview-hook 'smiley-buffer)

# I think autoload is better.

  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 00:38:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA02164 for xemacs-beta-people; Wed, 26 Jun 1996 00:38:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA02161 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 00:38:08 -0500 (CDT)
Received: from cortex.corpus.uni-muenster.de (news@PPPE193.UNI-MUENSTER.DE [128.176.20.205]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA11544 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 00:37:59 -0500 (CDT)
Received: (from gutschk@localhost) by cortex.corpus.uni-muenster.de (8.6.12/8.6.11) id HAA06949; Wed, 26 Jun 1996 07:17:29 +0200
Sender: gutschk@uni-muenster.de
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: praise-be-unto-xemacs
References: <199606251501.JAA20325@gielgud.lanl.gov.xdiv>
X-Face: +.[`xCMz]E6GW}5ECgY#C"Er6&v$q7:oe+zPlPtOh>/US;9B>;)ro_lpLx9/]q_{u-\YR>r
 P&)Da0gS,PW{@BWSG,PIV)3#J<$Ft_t]qa!xF~'*wuwg-CJj*0:EUr3z}y
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Markus Gutschke <gutschk@uni-muenster.de>
Date: 26 Jun 1996 07:17:29 +0200
In-Reply-To: John Turner's message of Tue, 25 Jun 1996 09:01:29 -0600
Message-ID: <m2afxr87py.fsf@cortex.corpus.uni-muenster.de>
Lines: 49
X-Mailer: Gnus v5.2.25/XEmacs 19.14

John Turner <turner@xdiv.lanl.gov> writes:
> When I tried this on the version of 19.14 final I compiled I get:
> 
> Signalling: (wrong-type-argument stringp t)
>   play-sound-file(t)
>   byte-code(<snip>!)<snip>" [arg 0 face-list max-faces count
> "*Praise*" insert-face xemacs-praise-message get-face random 1
> file-exists-p xemacs-praise-sound-file data-directory sound-file
> device-sound-enabled-p sit-for play-sound-file 10] 7)
>   praise-be-unto-xemacs(1)
>   call-interactively(praise-be-unto-xemacs)
>   command-execute(praise-be-unto-xemacs t)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command)

You need to replace one of the functions in
lib/xemacs-19.14/lisp/prim/advocacy.el
There was an obvious typo that prevented it from working. After fixing
this, you should byte-compile the file.

(This change is so small, I did not bother to make a real diff.)

    ;;;###autoload
    (defun praise-be-unto-xemacs (&optional arg)
      "All Hail XEmacs!"
      (interactive "_p")
      (save-window-excursion
    	(let ((count (if (null arg)
    			 0
    		       arg))
    	      (max-faces (length (face-list))))
    	  (with-output-to-temp-buffer "*Praise*"
    	    (set-buffer "*Praise*")
    	    (while (> count 0)
    	      (progn
    		(insert-face xemacs-praise-message
    			     (get-face (nth (random max-faces) (face-list))))
    		(setq count (- count 1))))))
    	(let ((sound-file
    	       (or (and (file-exists-p xemacs-praise-sound-file)
    			xemacs-praise-sound-file)
    		   (and (file-exists-p
    			  (concat data-directory xemacs-praise-sound-file))
    			(concat data-directory xemacs-praise-sound-file)))))
    	  (if (and (device-sound-enabled-p) sound-file)
    	      (progn
    		(sit-for 0)
    		(play-sound-file sound-file))
    	    (sit-for 10)))))

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 02:32:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA02582 for xemacs-beta-people; Wed, 26 Jun 1996 02:32:36 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA02579 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 02:32:35 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA02408 for <xemacs-beta@cs.uiuc.edu>; Wed, 26 Jun 1996 02:32:21 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id IAA01769; Wed, 26 Jun 1996 08:33:11 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id IAA28616; Wed, 26 Jun 1996 08:32:54 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id IAA22588; Wed, 26 Jun 1996 08:36:22 +0100
Date: Wed, 26 Jun 1996 08:36:22 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606260736.IAA22588@wrath.parallax.co.uk>
To: mrb@eng.sun.com
Subject: Re: sunpro-startup?
Cc: xemacs-beta@cs.uiuc.edu
X-Sun-Charset: US-ASCII

> Andy> Why does sunpro-startup check for the existance of bin/workshop or
> Andy> lib/workshop.el? I have C++ visual workshop 2.1 and neither of these exist
> Andy> in the installation, I would have though you would do much better
> Andy> to look for bin/sparcworks. If I do this then the error I'm getting goes
> Andy> away.
> 
> sparcworks is going away, to be replaced by something called
> `workshop'.  I wanted the Net binaries to have half a chance of
> working when the next batch of Sun Developer products ships (as well
> as continuing to work with the old products, of course!)
> 
> When a customer installs the workshop binary, it is used in preference
> to sparcworks.

So why don't I have it - I believe I am bang up to date.

> I've tested the following scenarios with the Net distribution:
> - workshop && sparcworks installed (WorkShop toolbar button appears)
> - sparcworks installed (19.13 behavior)
> - neither (user gets a warning, but not an error)
> 
> Andy> This is the problem:
> 
> Andy> Signalling: (wrong-type-argument stringp nil)
> Andy>   string-match("/$" nil)
> Andy>   sunpro-startup()
> Andy>   run-hooks(before-init-hook)
> Andy>   load-init-file()
> Andy>   command-line()
> Andy>   normal-top-level()
> 
> Yes, this problem used to exist, but isn't it fixed now?
> 
> Are you really sure you don't have a private copy of one of the sunpro
> files or you've patched up incorrectly?

Can you send me your version of sunpro-init and I'll tell you if it is
different to mine. The wierd thing is that it works on my machine
but not any of the others.

andy

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 04:32:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA06630 for xemacs-beta-people; Wed, 26 Jun 1996 04:32:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA06627 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 04:32:43 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA12378 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 04:32:39 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA16133; Wed, 26 Jun 1996 02:25:43 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA24498; Wed, 26 Jun 1996 11:25:32 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA01832; Wed, 26 Jun 1996 11:25:24 +0200
Date: Wed, 26 Jun 1996 11:25:24 +0200
Message-Id: <9606260925.AA01832@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: color ttys
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

I'm not getting any color in ttys in 19.14.  None of my termcap entries
had AB or AF attributes.  So I created an xterm-color entry, based on
xterm, with AB and AF.  When I startup, (device-class) is 'color,
but the modeline is B&W, as are all of the M-x edit-faces entries.

What values do I need to give to AF and AB?  What am I missing?

        Steve


From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 07:00:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA07104 for xemacs-beta-people; Wed, 26 Jun 1996 07:00:07 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA07099 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 07:00:06 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA12871 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 06:59:58 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id HAA18150; Wed, 26 Jun 1996 07:59:07 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp018136; Wed Jun 26 07:58:52 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA19538; Wed, 26 Jun 96 07:58:50 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA01112; Wed, 26 Jun 96 07:58:47 EDT
Message-Id: <9606261158.AA01112@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Even your dog won't like it.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: turner@lanl.gov
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: It really is a feature (was Re: New PCL-CVS `feature'?)
In-Reply-To: Your message of "Fri, 21 Jun 1996 06:58:56 EDT."
             <9606211058.AA04126@cfdevx1.lehman.com> 
Date: Wed, 26 Jun 1996 07:58:46 -0400
Sender: rickc@lehman.com

-----BEGIN PGP SIGNED MESSAGE-----

    From: Rick Campbell <rickc@lehman.com>
    Date: Fri, 21 Jun 1996 06:58:56 -0400
    
        Date: Thu, 20 Jun 1996 17:20:24 -0600
        From: John Turner <turner@xdiv.LANL.GOV>
        
        Rick Campbell writes:
        
         > In 19.14-b26, cvs-update shows entries for every subdirectory.
    
        I'm not seeing this.  You sure you're getting pcl-cvs from XEmacs and
        not from the 1.6 dist or something?

It turns out that this is controlled
cvs-auto-remove-handled-directories.  This exists in 19.13 but
defaults to t.  In 19.14 it defaults to nil.  Setting it in my .emacs
restores the desired behavior.

			Rick

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMdEl71tTztlqB385AQFs0wQAoizDfD7wEArxF9MS3Oi574VRhePc3gtq
HRiI2F4R11+2Nbfi6LBP8tQxIDSs1MQrUuRKwLbEmZbOlND4Tc4+8bpQj3UKWjrH
7Z6btHfuoCPGH/sYasB7Y5TJg2I3fIivtS0g/Da04MZrovPxsxFa2QmpoVwOw+XY
e58o1W9ub/Q=
=CiY0
-----END PGP SIGNATURE-----

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 07:39:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA07354 for xemacs-beta-people; Wed, 26 Jun 1996 07:39:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA07348 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 07:39:57 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA13042 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 07:39:40 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id NAA08552 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 13:41:01 +0100
Received: from sloth.parallax.co.uk (sloth.parallax.co.uk [192.168.1.7]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id NAA08373 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 13:40:43 +0100 (BST)
Received: by sloth.parallax.co.uk (5.x/SMI-SVR4)
	id AA20859; Wed, 26 Jun 1996 13:34:17 +0100
Date: Wed, 26 Jun 1996 13:34:17 +0100
Message-Id: <9606261234.AA20859@sloth.parallax.co.uk>
From: Philip Aston <philipa@sloth>
To: xemacs-beta@xemacs.org
Subject: Bug in 19-14/dabbrev


Bug in 19-14/dabbrev


dabbrev-completion scans the buffers, then gives

"Bad keyword argument dabbrev--extent-clicked-on"


This worked in 19-13.


------------------
Philip Aston
Parallax Solutions

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 07:54:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA07424 for xemacs-beta-people; Wed, 26 Jun 1996 07:54:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA07421 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 07:54:50 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA07104 for <xemacs-beta@cs.uiuc.edu>; Wed, 26 Jun 1996 07:54:51 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.53 #1)
	id E0uYu7N-00006b-00; Wed, 26 Jun 1996 08:54:49 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: 19.14 crash again
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.67)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uYu7N-00006b-00@neal.ctd.comsat.com>
Date: Wed, 26 Jun 1996 08:54:49 -0400

19.14 hpux9.05 hppa1.1 gcc-2.7.2

This looks a lot like the crashes I reported in betas:

#0  0x800aec98 in kill ()
#1  0x65728 in fatal_error_signal (sig=2063791616) at emacs.c:193
#2  <signal handler called>
#3  0x800ba014 in strcat ()
#4  0x1221e0 in Fx_get_resource (name=810004868, class=805962676, 
    type=269496972, locale=2063825248, device=269398020, no_error=269398044)
    at device-x.c:913
#5  0x6e190 in primitive_funcall (fn=0x726c696e <end+845026406>, 
    nargs=1081475072, args=0x6e650000) at eval.c:3494
#6  0x6e39c in funcall_subr (subr=0x7b036814, args=0x40760000) at eval.c:3526
#7  0x6d728 in funcall_recording_as (recorded_as=2063820820, nargs=196932, 
    args=0x7b036458) at eval.c:3231
#8  0x6d7cc in Ffuncall (nargs=2063820820, args=0x40760000) at eval.c:3253
#9  0x46bc4 in Fbyte_code (bytestr=2063819664, vector=2063819712, 
    maxdepth=269854692) at bytecode.c:450
#10 0x7b036458 in ?? ()

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 07:59:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA07476 for xemacs-beta-people; Wed, 26 Jun 1996 07:59:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA07473 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 07:59:22 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA07139 for <xemacs-beta@cs.uiuc.edu>; Wed, 26 Jun 1996 07:59:24 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA22789; Wed, 26 Jun 1996 07:59:20 -0500 (CDT)
Message-Id: <199606261259.HAA22789@charles.cs.uiuc.edu>
To: Neal Becker <Neal.Becker@comsat.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14 crash again 
In-reply-to: Your message of "Wed, 26 Jun 1996 08:54:49 EDT."
             <E0uYu7N-00006b-00@neal.ctd.comsat.com> 
Date: Wed, 26 Jun 1996 07:59:20 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

This has got to be an HPUX bug either with the OS or the compiler.
I've had a couple reports of it sent to crashes@xemacs.org as well.
All happened on HPUX.  Can you see if there are any known bugs with
strcat?


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 05:09:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA06725 for xemacs-beta-people; Wed, 26 Jun 1996 05:09:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA06720 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 05:09:38 -0500 (CDT)
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA12451 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 05:09:33 -0500 (CDT)
Received: from crystal.WonderWorks.COM by relay3.UU.NET with SMTP 
	(peer crosschecked as: crystal.WonderWorks.com [192.203.206.1])
	id QQavtg23000; Wed, 26 Jun 1996 06:09:25 -0400 (EDT)
Received: by crystal.WonderWorks.COM 
	id GAAavtg20135; Wed, 26 Jun 1996 06:09:23 -0400
Date: Wed, 26 Jun 1996 06:09:23 -0400
Message-Id: <GAAavtg20135.199606261009@crystal.WonderWorks.COM>
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Second and subsequent vm frames clipped incorrectly on right hand side

Wheeee.

------- start of forwarded message (RFC 934 encapsulation) -------
From: Julian Byrne <jcb@kryten.eng.monash.edu.au>
SENDER: bug-vm-request@uunet.uu.net
To: bug-vm@uunet.uu.net
Subject: Second and subsequent vm frames clipped incorrectly on right hand side
Date: Wed, 26 Jun 1996 17:53:56 +1000

First of all: Thanks for a very worthwhile and useful package! ;-)

The contents of vm's second and subsequent frames are clipped on the right
hand side by what appears to be the width of the toolbar on the left
hand side. The compose and visit folder selection frames are not affected.

With a vanilla XEmacs 19.14 distribution for SGI and no .emacs,
..xemacs-options or .vm can invoke bug by starting xemacs,
clicking on Mail button, clicking on Quit button and clicking on Mail
button. Also triggered by clicking on Mail, clicking on Visit and
selecting a folder.

Clipping on each frame can be fixed by manually resizing each frame.
Once a frame has been resized the bug does not reappear in that frame
again though it continues in other newly created frames.

Example of display bug appended. To view save it in "bug.xwd.Z.uu" and:
	uudecode bug.xwd.Z.uu
        zcat bug.xwd.Z | xwud

Occurs in XEmacs 19.13 and 19.14. Let me know if you need any other info.

I've had a look through the vm lisp code but aren't familiar enough
with it to come up with a fix. My theory on the bug is that window
clipping boundaries are not being updated correctly when the vm toolbar
is created/inserted.

Thanks for all your efforts.

Regards,

Julian Byrne <Julian.Byrne@eng.monash.edu.au>

Emacs  : XEmacs 19.14 [Lucid] (mips-sgi-irix5.3) of Wed Jun 26 1996 on extreme
Package: VM 5.96 (beta)

current state:
==============
(setq
 vm-arrived-message-hook nil
 vm-arrived-messages-hook nil
 vm-auto-center-summary nil
 vm-auto-folder-case-fold-search nil
 vm-auto-get-new-mail t
 vm-auto-next-message t
 vm-berkeley-mail-compatibility nil
 vm-check-folder-types t
 vm-circular-folders 0
 vm-confirm-new-folders nil
 vm-confirm-quit 0
 vm-convert-folder-types t
 vm-crash-box "~/INBOX.CRASH"
 vm-default-folder-type 'From_
 vm-delete-after-archiving nil
 vm-delete-after-bursting nil
 vm-delete-after-saving nil
 vm-delete-empty-folders t
 vm-digest-burst-type "rfc934"
 vm-digest-identifier-header-format "X-Digest: %s\n"
 vm-digest-center-preamble t
 vm-digest-preamble-format "\"%s\" (%F)"
 vm-digest-send-type "rfc934"
 vm-display-buffer-hook nil
 vm-edit-message-hook nil
 vm-edit-message-mode 'text-mode
 vm-flush-interval t
 vm-folder-directory nil
 vm-folder-read-only nil
 vm-follow-summary-cursor t
 vm-forward-message-hook nil
 vm-forwarded-headers nil
 vm-forwarding-digest-type "rfc934"
 vm-forwarding-subject-format "forwarded message from %F"
 vm-frame-parameter-alist '((folder ((name . "VM"))))
 vm-frame-per-composition t
 vm-frame-per-folder t
 vm-highlight-url-face 'bold-italic
 vm-highlighted-header-regexp nil
 vm-honor-page-delimiters nil
 vm-in-reply-to-format "%i"
 vm-included-text-attribution-format "%F writes:\n"
 vm-included-text-discard-header-regexp nil
 vm-included-text-headers nil
 vm-included-text-prefix " > "
 vm-inhibit-startup-message nil
 vm-init-file "~/.vm"
 vm-invisible-header-regexp nil
 vm-jump-to-new-messages t
 vm-jump-to-unread-messages t
 vm-keep-crash-boxes nil
 vm-keep-sent-messages 1
 vm-mail-header-from nil
 vm-mail-hook nil
 vm-mail-mode-hook nil
 vm-mode-hook nil
 vm-mode-hooks nil
 vm-mosaic-program "Mosaic"
 vm-move-after-deleting nil
 vm-move-after-undeleting nil
 vm-move-messages-physically nil
 vm-movemail-program "movemail"
 vm-mutable-frames nil
 vm-mutable-windows t
 vm-netscape-program "netscape"
 vm-options-file "~/.vm.options"
 vm-pop-md5-program "md5"
 vm-preview-lines 0
 vm-preview-read-messages nil
 vm-primary-inbox "~/INBOX"
 vm-quit-hook nil
 vm-recognize-pop-maildrops "^[^:]+:[^:]+:[^:]+:[^:]+:[^:]+"
 vm-reply-hook nil
 vm-reply-ignored-addresses nil
 vm-reply-ignored-reply-tos nil
 vm-reply-subject-prefix nil
 vm-resend-bounced-discard-header-regexp nil
 vm-resend-bounced-headers '("Resent-" "From:" "Sender:" "Reply-To:" "To:"
			     "Cc:" "Subject:" "Newsgroups:" "In-Reply-To:"
			     "References:" "Keywords:" "X-")
 vm-resend-bounced-message-hook nil
 vm-resend-discard-header-regexp "\\(\\(X400-\\)?Received:\\|Resent-\\)"
 vm-resend-headers nil
 vm-resend-message-hook nil
 vm-retrieved-spooled-mail-hook nil
 vm-rfc1153-digest-discard-header-regexp "\\(X400-\\)?Received:"
 vm-rfc1153-digest-headers '("Resent-" "Date:" "From:" "Sender:" "To:" "Cc:"
			     "Subject:" "Message-ID:" "Keywords:")
 vm-rfc934-digest-discard-header-regexp nil
 vm-rfc934-digest-headers '("Resent-" "From:" "Sender:" "To:" "Cc:" "Subject:"
			    "Date:" "Message-ID:" "Keywords:")
 vm-search-using-regexps nil
 vm-select-message-hook nil
 vm-select-new-message-hook nil
 vm-select-unread-message-hook nil
 vm-send-digest-hook nil
 vm-skip-deleted-messages t
 vm-skip-read-messages nil
 vm-startup-with-summary t
 vm-strip-reply-headers nil
 vm-summary-format "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n"
 vm-summary-highlight-face 'bold
 vm-summary-mode-hook nil
 vm-summary-mode-hooks nil
 vm-summary-redo-hook nil
 vm-summary-show-threads nil
 vm-summary-subject-no-newlines t
 vm-summary-thread-indent-level 2
 vm-summary-uninteresting-senders nil
 vm-summary-uninteresting-senders-arrow "To: "
 vm-tale-is-an-idiot nil
 vm-trust-From_-with-Content-Length nil
 vm-undisplay-buffer-hook '(vm-delete-buffer-frame)
 vm-unforwarded-header-regexp "only-drop-this-header"
 vm-url-browser 'browse-url-w3
 vm-url-search-limit 12000
 vm-use-menus '(folder motion send mark label sort virtual undo dispose emacs
		nil help)
 vm-virtual-folder-alist nil
 vm-virtual-mirror t
 vm-visible-headers '("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:"
		      "Subject:" "Date:")
 vm-visit-folder-hook nil
 vm-visit-when-saving 0
 vm-warp-mouse-to-new-frame nil
 vm-window-configuration-file "~/.vm.windows"
 features '(mail-abbrevs sendmail reporter tapestry vm-summary vm-save
	    vm-motion vm-toolbar vm-folder vm-menu vm-mouse vm-misc vm-window
	    vm-autoload vm-version vm vm-vars vm-startup auto-show ediff-hook
	    vc-hooks x-iso8859-1 x-menubar mouse mode-motion itimer cc-mode
	    lisp-mode iso8859-1 page buff-menu lib-complete derived frame
	    text-props mini-cl cl cl-19 backquote lucid-scrollbars cut-buffer
	    lucid-menubars xface xpm png gif jpeg motif-dialogs x tty toolbar
	    native-sound scrollbar network-streams subprocesses menubar dbm
	    md5 lisp-float-type dialog window-system)
 )

begin 644 bug.xwd.Z
M'YV0``+:"0C@`$$!!!$$'+`GH(!8!",&(`B"X,2`%0,J!#"`#\$!$4.*W'@1
M0$F&#B$&7!<P@(F(5IKH`)'$B9`G6$!,J=.F31@Y>42&/(##XK]_$8D>#'@T
MH-*%1YL6+!J00,2C3P$4D(J5*@`#3*-F/1!5K%<$5=*JS9K`F+$X<.-D50#7
M+=RL"QSI=80#1U8&<>.XS=I`;U^]61T<WIOU@:K'D+-"8,($KB=/62-DRC1I
MTIT[624`&DTZZP0@J(&8,I65PHG7L+-6D"+ER1/462U(DP8-VK!A62^LWK1I
MS)BL&+)EHT:-%Z^L&;)DH4*E1HVL&GQIWYYUPZY=LF0-&I25@QPYG-)SRMK!
MBI71JU9E]4".7+APSIQE_9`F#1DR2221%0CZZ`,//%-,D54(P33H8%8BM"+A
MA%F-4$HIGWPR6E8D:*/--=<HHTQ6)332R#CCF)B5"5ML<<451AB1U0G$U;A)
M5B@PPL@AA_2450J$!"ED5BH88@B**&:UPGD9=D40"X((TD<?992150O$$`.B
MDP&Y<-\WWX"8U0L^^/"BCEG!4,V:;&85`V4![K!#5C*@@,)K'WR0U0S6]7F=
M5S34)XXXRF55PV[//`,,,%G9P`<?GX$!1E8WJ*=>5CB$H.FF6>4PQQQNN"%=
M5CJ44`())'30058[Z&BD&&)DQ0,""+1(:U8]?*?K+EGYT,6OP&;UPP'$%IL5
M$!8DJVQ60;3@[+-9"1'@M`)Z-<0:V&:;%1&2=.MM5D7\)RX961FQZ+F,>G7$
M?>R&DQ42R,0K;U9)3&EO'UDI8<F^_&:UQ+\`+Y$5$Z\4;'!63<`"2U)>.0'!
MPQ!G]<11ETF8%13>9*QQ5E%<YC%F7DGAS\@D9S6%I"A/ZA45(+3L<E95I)9:
M5E9L9G,F65WQR\X\9X5%.4`'G5469A1M=%9:J&J++05GM460#5IC359<7+AH
M@UEUP0TWYW1]3E9>2/K&&W#`D=47.HXR"BFD9`5&*G#'G5486]?-359BN!=>
MQEF-X8031WV7%1E%%('B:EF589W"&WIEQ@8;M#C$$%F=\<[E[QQS3%9H0!V,
MU%FET4PS966EQE&00))A5FN4-7I6;/SWPP_%%)-5&VJHD4\^N6?E!@88C%Y+
M+5F]<=0``_R7%1P1M9A5'!$EZ94<.>2PP@H*9S6'I"A*FA4=O84/359U[&/^
M^5G9T=/Z;61UATA9X1'0[$YYE8=4]1.DQU'T3T500P!(D(>RP@?DF6J`7ND#
M%[@0$`02Q`]+:Z`VLO*'@`PO?P$!Q`A&P",,`B`0C]*"%CPH"*FQ@`4>'$1`
M,G2!"V2%$!N$2PNS4HA'$8$(,_2*(:26K!P2Y!`!240B$(&(K"!B@RTB8E82
M\2@7N$")7E&$U`("18(L(B"?*E!6&+'!PFG1*XUX%/"^2!!'3!$`9`S((P*R
M)@]"8G*G.(4'(Y$>/>C!@Y*PASTHX\%)!&1G-[A!5B@QN4A$(I!9J41Z_H-(
MKUA"CS:P02,)<HF`P`T5J,@*)B:WASU@,BN92,_?/ND53>BQ9:0DR"8"TADN
M`8`3DZN2*SN1GKZXTA-Z5(`"7/F)!"2@'O7P("B,HSD/AL(YFM"$!T5Q%#:P
MP8.C\"687I054A@G%K&@IE=*X9P@:9,@ICB*>[X9D%/X,AG)B%=64&$<XJC3
M*ZEP3JC>21!5'`4U]`S(*GPYBUFXDA7&*40A7-D*YV`!"ZYTQ5%4H`)7OB(%
M*3A*`0J0%5B,IVL3S4HLMJ8+7634*[(XBHX^2I!90/0HG\D*+<83C6BDU"NU
MV!K;7DH06QS%#G:@:4!N`=%TI`,=Z,@*+L;S':!F)1=;TXM1O:*+HTAJJ039
M!42G,0U7\F(\%W)E+[:&!SRXTA='48(27/F+`!W%5%D!AMK.6H*L!(,?_/`0
M6KTBC*.P@A5S)<@PS/J/2UPB*\106SSBX=>L%`.N62JL5XQQE'TIEB#'X*LK
MD:&V;6S#E<F`JRL4^H^L*.,HHW'E,@(TCWFXDAEJJYTKFP%73&#"E<XX2NY<
M^8S^'*5P6?'-,&Y;A*Q$XR@%PJU7I'$49C!#N`29AFW_<8M;9(4:OSE*<[-2
MC:/49[I>L<91EH9=@EQCN:[$QF_,Y\IL'"4_KM3&44`!"E=NXS=`<R4WCH(+
M7+BR&T=1A")<Z0T[^E</6?E&&`9,X*R`PY`(CD16PA&P?V5%'/SJEU?&\;<*
M.R$KY&B'AC><E7(@X<,@SHHY%D'B$F?E'&Q+<=N\@@X/N/C%64E'[F:LAJRH
M8VPX?D-6UB&$'OLX*^PXCY#ED)5V[(4Q7G%'9Y8\B:R\(P-0CG)6X.&%*ELY
M*_&`G)8WD!5YA.?+LLC*/!I`YC)GA1X&.YA7ZE'?-N,B*_;HA9SGG)5[#._.
MQ/,*/A;`YSYG)1^_"31PO**/B1J:HE[9A[SFY15^T.K1",A*/]Q":6-DQ1\M
MS70TLO*/_'A:/UX1BJA'3>I2F_K4J$ZUJE?-ZE:[^M6PCK6L9TWK6MOZUKC.
MM:YWS>M>^_K7P`ZVL%]]O6(;^]C(3K:RE\WL9A<[(#V(MK2G3>UJ6_O:V,ZV
MMK?-[6Y[^]O@#K>XQTWN<IO[W.A.M[K7S>YVN_O=\(ZWO.=-[WK;^][1=K:^
M]\WO?2,$WP`/N,`'3O""&_S@"$^XPA?.\(8[G.#]CKC$([X#`$0[D!C/N,8W
MSO&.>_SC(`^YR$=.\I*;_.0H3[G*5\[REM^@3#"/N<QG3O.:R]SE..>XS7?.
M\Y[[O$PY#[K0AT[THAO]Z$A/NM)%/O&F.UW9\+!X#Y9.]:I;_>I8S[K(?7!O
MK8><ZP[WNMC'3O:RF_WL*G^ZVM5.`:FC_>UPC[O<7<YUI=<][G<_>][GSO>^
M^_WO?E^[X"=.`K<#_O"(3[S5]VYTQNM]ZFAWO.(G3_G*6Y[I@\_\OA]@^,M[
M_O.@S[CDASYZLI=>ZZ</O>I7S_JL:_[US89`YP/9E]KWI>.WUWCN45[[C/=>
MY+MON>U9'GS=!__W("^^QY6_<>8W'P?)1S[.CP]]YY^\^'DG@,:U/W+N>WSO
MMM^]]1L/>0*8'^/FUW[ZUX_TU+?^_?"/?\YA3_]D`V/V-PB_\Y4__NA#'^/2
M]WRT]W_"%WXK9WW2%X"X1X#1%W+]-X`?IW\E-W[4EW\,"(`7Z(`7>'?>%T@=
M"'(?J'.0-X`&:(%7EWW>=WXWL'[IUWXC*'\P&(,RB'+U5X//AG\/:(+&IW()
M2($92'RYIX`DAX#4]X,""'Q&Z'M)J(3+%X0Y"(%-R(11.($;.((?&((>AX6B
M]X+BMX1)AX+HQWTJN'3N-X-F>(8P:(,V^&\OJ(/&1X!=Z(9QF(3#9X%="(>]
M=X<8:(<1R(!Q"($]Z(;/YX2$^'^W5WV&N(3\]WN'>(%_R'$52()[B(@^"(6-
MF']VB(A[F(E0B'$<N'WHMX*BF''J!XH:!WY^J(F<:(+%UX.1>(HO>'YC.(9A
MN(+J-XLM&(8IF(N!5(9H^(O`"'IJ6(,5=W%2J(2,F(AUN(QU.(C*^(S/J(,E
MJ']TR'S,.(TE"(G)V(C#1XV"J(UOF(?9R(Q-^(/8Z(U3Z(29:(!SR(Y5&(JD
M*(JEF(+R&(H?B(I,R(WBV(SGN(T9N'>RN(L;QX(L:(OL9Y`!>9`OUX;!V)`.
M^7G#6']19XP8V(W<R(H7J8Y".(FTAY&4:(D?N8^=J(V1>)$>R8<+B(F8>(DG
MB9$-*(49R9(LN8!%R(?(UW_JV)+2B(<[^8V?&(\>"(^C.)3TZ(E<F(HN>9(B
M*8Z`F(BPN'VT2)"WZ(%B.)6V:)!7J8)CZ(L/V95>&7<127]M1Y$DR)1-*8>J
M.),I:8A)V9-M.9,/2(YOJ8K?F(\=69-WZ(5U*8GM>);^YY1^.9*XUY&!Z9:"
M:)9&*91!>85#N9BFN)#'Z)*!&)@F"9)/28I129!7N9F9:96ZN'%<^96B.9I>
M%Y:P5WAD^8U]V8X6V8"M^8<:R9./Z'_K2)=P68V<6(BVN9&169:[69M[29)H
M>9AZR8]T:9BZZ9/E]YA%291"V8'X.(G1.)RPZ8_8%XN>28M4N9V<R7[:B9!;
M2)KB.9YG9YJOQWFIV8JR^9OJZ9I,69V4^9LI*9T[&)]1^)I.V9=]6)^WJ9JX
M29^%&9<W>9PYF91J"9E!&8^,N:"/&9T!VI^SB9B@B9V;6:&UV)T8^IU4Z7VA
M29X>^J'S9YZ9)WOIZ8@Q:9,R>9S@V),BR:(G*IC(R)?YN9X?.9^Q:9\X::)-
M&9(S6HXRRJ.].9\/"I)IJ:*?V)Q(^IR*Z:`WJI0Q6:2&V8M6*)`6RIU::94)
MF955F9@@VJ5>:G0BFGGW5Z+.")@2N([!N8DY.8XIFHR;2),#BIBZ^9^QV9J6
M68[4N(]Q>J#AF)>`*8DO^:"4:)%VRJ7UV)P)>JCV>)F^6:=ZZJ>-ZIN,BHL;
MZIU;JJ4'69":*:5?VJF>ZG)A.GC0UH;6^(BW^:<V^J<!>*IOFJ/JJ:KKF8YF
MJHG568WN*)DFBJHDF:MO"J-'6)@[":4'"I"-Z9P*^IB&"IQ$VJ,Q6I&I^(_E
MAXNWJ*F7>J45RHL*B:"?NJW<.G*A*GALV*WB"G@=FG+E6I^DQY!C=Z[CVJ[B
M^:UK5XSJZJ[TNJ[S*G3LVJM!EZ_D5Z_^^JGPJG83>:__6K!D2+`YQZ]IRG(*
M2W0-:[`0&W\!^W1CB;`1>['[:K%TI[%9][#XRK$8&[)I.+%-AYH@*[(H6W)<
M]W,L:W,GNW@]T+(R.[,Q][(I>[,02;(3AYXVB[,^NW%=)W</][-$*[$Z*W$D
M&K,TN[1,V[1.^[10&[52.[546[56>[58F[5:N[5<V[5>^[5@&[9B.[9'*W%C
M.K9HF[9JN[9LV[9N^[9P&[=R.[=T6[=S6[81-VQZN[=\V[=^^[>`&[B".[B$
M6[B&>[B("[AXVV\"<``P\+B0&[F2.[F46[F6>[F8F[F:N[F<V[F>^[F@&[JB
M.[JD6[JF>[JHF[JJN[JLV[JN^[JP&[NR.[NT6[N/N[C\-B>Q.P.[V[NPR[N_
MZ[NO"[S#*[RN2[S':[RMB[S+J[RV^[S0&[W2.[TP@+O[!@^."P-&-P/`N[W=
M6W3<^[C>*[[@^[U$%[[:6[[D>[[F.W3H.[[IR[[KZ[[MNW$$D7+OJ[[Q2[_S
M6[3B:KWZ1@'9"[\$K+\%++_[*W3Y*W(!47(+S+\)''0/K,#U*\$5_'$`X,`7
M?`,$81`-;'(3G'&JUG$AG',E[+\`"\#-1@(#['&D)G(G['(QW'(Q/&HD-\,L
M=\(V?,,;;+^/F\$CA\,KI\,CS'$U#,2!%!%!W,,<_,(@)\1)K,0PO,$`P+U5
M/`-(S,/]BW&CAL5>7,4?K'%0C+],C,)>JL+-]@`MW'$%82S%$L8>-\8H1\1%
M+,8]W,9N#,<?5\(AH7(Z[,;$HL=[3,4A`0,!8<A]3,)EC,%9O'%\S,&:B\6*
MO,5<G,4?W,B3',$B;+F";,>4S'&)'')\#,8!@<68_,2$+!1?_,6G+,<GY\IF
M_*YHO&P0L,:@#,B!/`2GG'$X?,IZK,<Z/#D`<+D`(,Q&?,<>[!0&P<%3O,5A
MW,G-K,D<C,O%O,N.?,'%/#FZ/+G9;,S'_,D@%Q#"?+^>K,FJ9LB9S,9-7,E)
M',T8S,FZ/,C@+,(BX<[V:\7<:\4@G,JI-@37/,\:Y\3_+,VQ?,:SK&R,,L]X
MG,?>G,Z@[!1(W,%`3!#QS,M4+,S$W-`6#<X+_<;U[-#L3,^,C,E_/!12C,J4
MW,VDILV[#,OBK,TP#<<AG,%7W,TLG<_#W-)4O,Y13,Y-W,I,/,R5>](#/7*A
MC-+F7--6;,T@;;^X;"SBF\U%3<^B]L96O<Q37=#;>M#*5A`*_=1'7<[VN]!)
M$<@4S=)B#<H8#<^=7,/)#,@TK<M`W;^^S,9"#<Q4_-2!;,\!#=-^_=<5G=4A
M]]*`C=<I7=.%;<7H_,WF'-+/',5-[<.8:\UC'-9Q3,7YO-30S-ALK-?%0K[%
M+-@=',AO71"F3=I2O=$$K=4?RM7)UKA?[=E8S=D!K==G[=<D?=';#,^!K=HN
M[-F$W=N!-,&_7-P_/-?2;-JC_<9\+<*`_=S"C7%0?,B(3-CBW,BC;,7/#<:+
M+=B5+,6/S<S('="QYMLDQ]3>_=VF?,@3+<IY+=N@[<]IG<0GT,;*#-'*[<&Y
M+-_#O<BL+<NN;6RZN]H=3<V7G=)P;=-_G=N?G,U"/=0:+=UW7&HQS>`1_,PG
M;=D2WN#`W=Q<#-V%'=EC/=0O;>'VR\':+11RW=WSS<7DS=/,+,+>7>"RG<?F
MC<`C;<B0R]Y(W=EY;-8M'-II'1#U7=\U3LW\?0.P_-]=&>#'AKVQW>$B/LT,
MS=+63=OVN]80'MU*3L63S=+1/<H^_='RG-QY+&IEKM8@CMM3'L6<?.4M7LDI
M7N4Y+>*-W,"6;>(BK-]'7MHW/M(^W>,N3,Q,_<>D;1#)+-1)G.3]#=JO`0!&
MCFKZG=I=#M!,3II.;FP"'.6V?>#F#-=RK>!<'LR[O>7C+=E?[N#IC<&S+>A.
M?=_43-G8O.`"'>=N3N(_'.&-GM0I+A(8K=.6;M0SWN?&4LVM+L1"L<0`?=>&
M;!`_[.JU;=7XK>@<S.B5GKY$#NDT?N2IO>27WI"97FPLS.E@[>D^OM_0?>I9
M7NJ4J^KIO6IH;>L_C>%$W>8=3>/5/.6BONW0/-,/+KG4;<AR;><HCL4@/LS%
MLNKJ[,+#3NRY;-I_#NCHO>$$3=TY_<;';>ZW7.Q#$=]33>1%?MHB#]&);MJ3
ML^O?_J7A?CUJ3.X&;N_%;N5LCN5]'>JCINO7CNJ9J]+O'M$97N\1S\4_;M*!
M3O%J'M-@/>KU>]<$<=P`7^C8C-@J3CG$PKT*?^(,W_`>+10<#_%&S\!`W^:0
M?-S%ON,:_^K3KLP>/^0A;^2(KLS%/NDFC_(IWZ4KOP*U[/)P??9.;1#CC-O]
MKMMK'N^V_N]?/O!Q7MQWSO0TO^=QW^FKON\EK]R"3-S<;/B;_?7DK=V`;2PS
M(/8!G?5:[_#,K?GA'/:-3]4ZCL<YO=F&+O<1L?;F31"/'NE)8=^4#]'R[>UU
MCX9WG]`$7N.RSM'H;N7H3>J#C_,SS;G5K.[MC/4CCLCR3N72OMQ['?D++MMZ
MGL3M'KF9'_0'4/"B[OF2G/J@/,=+?^9#`?ET/]BH?_7<O_K.SN+F3^6YC\>R
MK_G:'O)F#?=#;_+^C/?U/C-T][Q:\--^?"_:J;3O9_J<F\T3-<JO@AD^0E?^
M$M_B&VD*C^NQOZ!7[7!;HMM[+6X"ZCCII\42V!OC?).#_-6Y^B?CR%OF(VZD
MS\8U0!?V_J9?_.-D:>Z6P0]$%^2LW0,#>=JNY/6_^R?5!.``E$%W#[8=0"G'
M`IM8J-MG#4Z893:<ENN4GC-3-16P\/D\,A;LJ-_+DW>2CPGJOPG8^EY9^RIV
M*-#S_3K0]_Q"6HQK?/>NK(G!RE8#.6`E0V3'K>AEP,EGU?)?^^-@;0_WR;VW
M=]].GA$\@B,KW`TX5H<`09\>5';)30I.02Q6!9W?AQM\8"P!]C0&J`D[FP:T
MA(O.`XK!]C<$,Q[ZFU\S0`52O:HW`\89_9N!H>_%N3>Z%@.+G1T<:X^P_MVO
MIK?8)EY)VX'$P@_F/'I6^T9>[H-]N\^_(4)@=/>@W!+<@#:0ANFV*S8%[UH$
MC(('+PO"OQRF#+?=]0.#V:^JM3I2>.:&6/U*A<4"BZE!*;@",^`;%&FS,(%Y
M0VYW"UT@)QR&]\R+K;>)!PNGF4F#:MC.!RX]0!@$)=H'C`C:[`\N0]%T]S8=
M@3LUG1#GU#!=-@DIH<"S@I'PX!T_97@*5YOC*W>13P-"0WP(R*3A%D.'@*P5
M2L)<2,3LFH>;A\*O'E*U>YC="((I@X)F[JWQP&`8$-]=$XMTD^^V)42%N!"]
MTMT;=Q[1'';!CBCQ2@T+-#7Q\("%LU%(%,\=2+QQQD(B2D"4F`YOFCZ+B$"/
M$Q*W\M8/[6$N!(/X#*?A1*OXU(2AF/-UR:\L%L5@=/=:7E+T8QS1#"Y%O7@7
MN6!?9(H,C"KBPZE(%1=8PM.**8TK[D,-UP^A67AK@B(0X$7$F<@8.6`ITX?W
ML"RJFI-G`Y.?7]N&<]'WK;R\]Q?YHE2D8'MQ+1HPL%?KY")E1'/S+?Q9,'"&
M#C\?8#0Y-7"&H9K):!*36S4TC1W',\(T^`?=(&%H9(@K#_B=QME8&E4CCEN-
MSS$Z0K!!AA=3HP:SCB5P.?:T]08<@Z-P;(+<$#L>Q_=3`&T9:NR+Z&W[3<?S
M=O[`(P:#=N=1Y6Q$\>@+\^*)`W;-D1]616$W_)IC&\R!=BT]OL/]V!ZS(W0<
MCPXI"9I'JE8=D]M9C(6W\$'"Q^_&P-C@(YR/#E(_ZKOOAR&AGS6KCQPM\]$T
MD"8A-60O<W'0#_[5-;XF(45?`PR+SK$%#LCKZ!\19.NY>XNP0-*T\/8(=9B+
M&Y$CLJ>Y0\?V_/KCP@.2.W*BM;6@]B/%VPO$9BCRDEVR_U@5VQN&^VDSDBA&
M-"PI)&'<]+-D/#)+XL/V%N/(V8XDDJX1SYU)\<8;DZ20?)*@+4HJ22EI)=L@
M<8N273)(%KU15B3;F9X$A392-(8[9[CPV"2;U)-#\E`"R3*9`>$8H@R20_),
M(DHQJ1M#'YGLA'?.3VK*&?G(WB"D/)2I;TO624,)*+EDG5R46.Y4,DI1V20)
MI*9DE4:2X9')24G;,B6H?)2@<C!ZRERY*"]EE;R5P)(-!LI$F.D<8J%\E'B.
M2NI*%,DKDR6G+&-NTDH&O@8W)4FELG25F=)7FC];B2N?Y6&;DY#-28)"5FDM
MM:6K+)?)$C]22"QY*ITEEUR6EE)<&DK(R"BMI4/CEL&R5WZP.^DGG66OI)*/
M#$G^2R_I&H>E_#F*"[(-=LMZ:0=AI<)4EB=R8$*]!M<")Z6Z%'VHLD-ZR%59
M)`&E)=N5\](G;LIN62I;):3\E#=N5'),5#D@(R:PC)7J;%8RS(]G,O-EKE2(
MY')E=DE8J"3?X:<LF0:36#HYNT@#P25D,Y=T3&72R4;9,W_FQ4R1H])<GLLQ
M)S4;YI5\ET]31JZS,1<NP6"U-)K3,D/NS'1)(CNFJ=R:/"V,N4Q)B3+KH<7L
MFJGR:NK+J`G$QN*5I)I:$UYNR;19)K-FT"2`HS%A%D@#*1WCXX$TG"7G8PK+
M!JD=4R3A=)$TLG'*,/MX+4$CV+.<?O%O_J+?E[TJHN?\G*`3>(7.T3DZ'Q?I
M/)V>TW2BSM69SU0GZUR=KO-UGL[8*3M+)PRHG:B3=N+.SZD[=V=%[)V^<PH"
MS^#9.F\G\>2=QO-X_L[DJ3R%)_-LGM`S>DK/Z4D]JZ?U_)SE\7E*3^T9/;DG
M]/2>S1-\*D_Q>3S))_$TG\$3??I.];D[V2?N=)^U$W[*3OGY.NDGZ[2?US-_
MZL_]R3_[)^I4D+4P@`K0`4I`"Z@!/:`(-($JT`7*0!NH`WV@$#2"2M`)2D$K
MJ`6]H!@T@Q8+'"D;$8\&_:`@-(2*T!%*0DNH"3VA*#2%JM`5^D";80<]/"PT
MALK0&4I#:Z@-O:$X-(?J4!+:$%\HX-FA0#2("M$A2D2+J!$]HDC4LR%,Q9-$
MFZ@3?:)0-(I*T2DZ1>NB#_T[QJ():%$M2D6[J!?]HF`TC(K1,=KG[EXM8Z+%
M8HMR43+*1MNH&WVC<#2.EE#.B4:)A1IM`G(TC^K1/<I'^Z@?-1;EL8X>@#OZ
M1PNI(3VDB#21`E$%*4@)J2)]I)`TDDK22=I"5]Z<:*1JE))JTDW*23MI)W6A
M2\?:K9PLFDD]J2D]I:@TE;[1'AI*16G*(:5;5)7*TEE*2VMI$5VB2H=RN-*3
M`TO7J"W]I<`TF`I3$6I%68YPI'J[M.3T4CPZ3)NI,WVFT-2`FM$K:G)6X9'3
MI2UGF4;3;<I-NZDW/0!T=.7HTF-Z`)*IR-&FWS2=JM-UFDH#J3@MI\=T*+[2
M-%I*V:D]O:?X%)$RTG<:3SFCRD&G^32@"M2!VD8YJ#'MI^;TG-+36$I0&ZI#
M?:A/%)2*TW[J<B"J1;VH&-6(LM)<ZD]93D;]J"`UI,I07)IT.JI'%:DH-:6J
MU`Q:3'-IT%FI,#6FRE0%.DT%Z4R]J3@UI^JU<.I!=:I/_:DYU9WV5*!*5(LJ
M2MVG0]6H*M6E^E`-*LKQIR85Y$159<I4JZI5S:<2]>0,Q:GJ<;CJR+FJ8#6L
M?M.-JE4YHUG=JO+MY`W'>2I6VZI;%:8DM9KZL[E*5P.)6DVK>'64OM6]RE=E
M:4LMJS>@KIY5NRI/O:I"[:N(-;%JTIKZ5/$J75VK@37)&=:0HU@KJV55I#Q5
MKA+6NJIQ(.MD!3F7-;2*5CXJ5#4K88VLIW6PHM:$VG%&JVM]K05UY36NE`-5
M'6M>1:VGE:W"UMW*6Z6H4TVJO36X"M=;NO*PETT=KL@UN=Y0L@I#E:MS?:XC
M=>6QL.,*7:NK=06A?[6Y7M?MRETO*&,%KMTUO(K7!9I9?^AX/:_H59JNO()`
M7=.K>WVO2E2V4M.^`U_KJWU]:K]5N][7_5I?LZI^Y:\`%KTR5_,:8`OL>(VK
M!-;`*MCMFET3[()]L,_UN_Y7"$MAAVMYQ:(5-L-:V/4Z7_F.AOVPO16I3E@0
M2V(M:WYUL"4VQ296_XIB5:R+?:L#MN6PUFSZ8FOL7D6P!U7IV-@=VU8;+#_5
ML3PVR%I5"?M.X:EGU*M"-LD:U0O[5,NIPYNQK57)2EF@6EIIJY'UC.44R4[9
M+7M316QC[:=9]I]RV3$K4T_LER6G4);CD-DUNU)9+&U%J%J6S<K9C!ICWVP\
MC;-S-L\V5>G:8<MJFA6S>C;0.E0?.U&!K*`]M`*5R,I80XMH&ZT]9;+TU=%*
MVG5:93'LI+VTW=3+6EI,RVF?J9GU.YTVU#I3-[M9Y2E@%3JB-M4&TSJ+6ULM
MV5&UL+:6XMC<&EGO:JV]K:O5MN;6LVI88ZVO5:6$MM46QUR+<6SM8#VVN';C
M_-IE:TH5;:F]J[<5V:;6O(IL$RJSO;:;%-*:U-JZ5FTML?VVW/;C8-MQ*TDK
M+:VEM5.UL')6;]M13:W&(;?P%K/*5^_86?F;:JVUQ7;="E9VNTOCK;\UI)_6
MU;I:R&I7,PZOM;?ZMM?^VX5+6HMKGY4[##?BYE%6ZV$EKL5UH[,VTE[<C2M&
M@VW%Y;@@UXLZ6XT;<DMN%(6T']?DJMPF:FY)[LI]N<0UW,W6Q`-S:V[,S727
ME.;:W)V[2!UN>^6Y0#>&4MRY$W2+;@W-N"G7Z"K=%.IQB>[2?;HH=.0F7:A+
M=;%K<GRX<:?J:MT0VG*G[M;]NA-4TX):L$MV*6C`/;-_;>.X6ZI:=MMN)1V4
M6)?D6%-C<7`_J\=QNWBW@0Y=D=/YW-AS.ZEY-_`>4*3+=T%<L?B,%57P*EX"
MVG2KZ95-@8B7QB[>R1L#I:Y6I;M^C5C\V;M+>3LOL4.YEQ?SID#-BW,\K^FM
M<5TW]&K>OQ9F)>_I?;UN3.Q:V=6+3`DNGH6]K_?LAEYMYG=M+\K!O<"76)!:
M*\M[<9GO-3G!%_CNW9(#T_3:8]V\&"?YXE["RWR+[U/3M;]7^N;>E:?&9*SU
M=;[YUNXJ6^U[>BUOX?V^U]?@BM]W2WY-+^AUO+(-^JK9]NMY4R_\]6SR=_S2
M7\HK>]'NL'6]^U?QZEZ(&X`G[_#UN@78[2Y?];MVU6]7S;^()`$+8#Y;?<]M
MO7W`@%<"Y]W&>X%W+5HMM2#XUK)=#8QWS6\'!K?[U@.KX*]*@C?PU:W`TS8&
MJ]89#&5;L`L.=^Q5[B+<6VML$6_=K<$V6`'/6QV<;P6NMW7``I<%!^&R.X`[
M,`U&P=,VV8+6)<R$?:X.-K7=%OMZX/4K2*@PV5W`;\<+?V$*K'/%\-;EP'#'
M#']=$YR&U;#6?;]9UPU77?L;A^4PU.V_3M<./]TFW(:)Q</YPX`X$`OB04R(
M"[$A/L2(.!'W@`.<AP^`(G[$D#@22^))3(DKL26^Q-\&#*,=8Y&:-*<G_L2@
M^.I0WSKLB'M6*.8[&O(KI>)3S(IO`!H.P\6B$V<=JKDFW2#*27:FTDSF.5J\
M+MU?VT1#JU@5RYVP=R$S8RMN<H%3D,KB60PAKV;+P62.4FLJSH>9-S%F,&8]
MU[@K96.J\XO%I#<^QICN!9?A4FQV;"6,,\;O,5[^1W,\C4'F8(.0P6@;.R1Y
MK'2Z\8<$QP8-!\==6.R'37'1V9NO<D"B8V5Y,J4QLSS(W7APRL*TR3:/9BW>
MF6]R:4)DH@.-W:0+-&H-F4'B0L6G^![:0R[&>I`>'QV`7(T/,CXF3WB8`/?C
MLT.2!Z8M9H^QT%<>-6@,CUGCX-R"[E)-^DR3?(ZII$A^QV,-(?-DE^@NW?$Z
M-LC,DAU/8W,\(W_R/Q[*]_@DMS9+NH\W<2SVQ[AXWK5(:MPGOW'BQ'HR64;2
MY))\.9%RO=R;57,L;\RDLR*Y<N6,R6YY)Q?*=.R337([5L@L&2I#3JD<CN&N
MRZ&H&7@9:QV4*3-=CEK^F7`9'B=DH'R4NS):7L<P4D?6XYMLERLDP\S*FW`C
MF\6\Z?/"&C$>QI]Y+O/EOEPLJ_+'@6F7Z_@BWZN,=@AS39:/&_,NMV2Q+.S,
M,LB\E(59+I/ED#F2*7-=!LJX&29+9J%,FVOS;A8[3/DM.^71?"/)\$&='*FY
M`:_FE=R:'><%/#EJV4NVXZ7\FA]:9>Z:N3D\5^-[O)P9,W&.RUDO+)]GW6R4
ME;)MELW#^#5'9>9,FH>F:7[`T-ERJ>81+)@'\T6&R,88%X.WSAR2>?%$/G\@
M>6OJ9#69D>>=I]1PY=D\YV(PJ1]WX4<N>IZYWBFQQ4>8,71D?CL&.BMC9OK\
MD-APR$'-^EDZ\V=_3*+?,D4&QH:Y18-C.'Q^AT!TYL)1ECK+:.Q\=2*TWQ')
M/GI'7SHZ7*-O-`2.P#I:2+/&(/V0ZJ"2%M(I>>2@Z,JUGTD.)U9:=BM+:^DM
MS:6[M)?^TF`Z3(MIL<6'3[0V,]*N%TN/Z37-IMNTFW[3<#I.R^DY7288\17^
MCAE8#QM=37R:[VR>UM-!=Q37Z"/[IP$USWW%4M5/WUY#;7--=**>'!711L.`
M*JV$&370I=%F&E)/0DE-J0^KI3[4'/8O:[-(_;@Z-67]U)=Z"'O?(4"J)[6*
MMM*H&E0KPOO<IPGUHH[5)M=.DV)<_7+YM-GAU8W:.??I1%VK/R..[L+`NE=S
M7ZQ;I0UKNMV\R1KFFN"TJH*S<&UUP`?W5$=KE?M^I2UN?<(#-P4G8?:[K7-U
MJ![64/A;1]OAV(,ML/XMUR$W):==<`VN97#DS='P&N3JWG;[@=7U"K;7L#I?
MZVLK3&_#[V.-PO^:V-Y;?"VP+^[0Y=??5EU?ZR*<K:=PP]ZX@IH?7VR+BZC/
MSL;&V,EX'']LAHNIK?+(CKA$6F.?['\;I?OPRF;95/GGONQKJZM=]LR&M[ZZ
M[-QLF!WNIJO(WMG8MF/_:J"-LT,V>"7:R[9D>VRD/6Y3MLEFVLRV9:MLJ.UK
MR_33IMI5FV"/6*R=:G,VQP',MYIK=]J,_:@E-95^U95:;*M:H>T=\_/9/M;O
M6FUW;:,]4=TVY3+5%EMNS^UPQRA$M=V>7'A;W.KMM7VNG[/9OMMHVU,/[K&M
MJNOVX0;<B5M;+V[&/:O]]N.67(&;\TYNRIWIC.NJOMR1*W,S[,T]:;VVVE74
M@)9T7UJR7:QM=>I6W9*6;7]MU*U;8;>C==2M.RX6:MLM:)4V?F;5F[I41^Z\
MS;L1K=,NUJU:=,_?XMUHI7;93M[#6W`S;^,=L_TV](;;Y'IZ]VZM;;@''P#6
MWGG6=(L=\'UH6??0)M]Z5G:?[GE]I$<W^EZSN!L#GVZB\[[3MSC.L11;"X?M
M^BUEC[?\!MCC>CKS;_C=N%6.L1;7V#OC#'`Y:[71M;U6WG%[@6_9FFVFL35G
M+;T2G,R*;R0,P!-X],W@8]9\%^P8+(*_-PA/LNI[?)_P"4ZW6^P*Y[&^6V>_
M\/Y=N+?V#*^QSGMIWW`AV\#/]PZ'X=Q[T_YP&[O!M<X0#[(B_-4>\1V;PKW.
M$F?B+5R(/_$4&\.5^!1WL?Y;AE]Q%9O#??@6)[$]/'??Z\3[Q4LL!>>[*?JE
MEG$SOO($6,X!W<*[?7_P-0YBDWAP3-$>7('3\3J^K-]XYI+CR'J/9]CX76\1
M:O2.X(+\P5;Q8CM`\V\BU[!9W.#"4V+'>QWY(Z^P7;RSQL!*_KHON8(-XY*<
M]''RVNW)#>P9_]J]M^_2WM;+2TNY(F_CM#J4!U!+[LH_N;!6O;2W^8)?4E[+
M^6L3G[NBO)/W\OU*R&5Y+@?F@(R6#W,`N\CM:B,7YLN\O]9P7+[)H7DT?Z^9
MW)A7<UY^S;%Y];:SAER9=W-I[I=Q#AP/W1A\G-O7(LZ`UUPZ5^?PU8ZK<'@>
MS_OXSZ;GYY60IUTB;,+QN7B-X1.[\))Q?RY@I[E`W\+4-J$7X1%,T`]L`3_H
M4#@AMFMW3;P;>G@-X_O<6_/;`"Z]+?H_#^(57&)+=(4>L0.V1[_HL/S4EG1_
M'6Y;^4E'Z3V;5E_K:ANQ#_D<?^G<E6U/["SLKQ>Z`,?IU[682VES*G^!>G=M
MYB%]A/]THPY=(_E0_]\NG:E7UVP^=J1Z4/_F-MRJ"]=3[L6U>G)EYUC'JS?U
M6R[%Q?I6M^='VZR'V"@^=M4Z<N6<U"MTN?6OSF'C^N?BBG-]K<M<P0EWN%=>
MW["S6CQB';_^UX.K"Q7LK[$RFL'";MAA.6+G8F].*S)VO9[ID*)A9FN3<[+S
M5BOZV&_@Y1O(UTRS[]9IVMG''C&3AJ(=ML+U&JF56PWZ2^VO-7NR=IC8"/<9
M;'>M"I(^\CEN!]%>^VT7K1Q4MY,^8W>-"?MOOZR'?;;'0.+NVX^[B77LRKWK
M`4,_M]B=^W./Z<(]@!9WO&[=^RIGC^Y;3PY^00W6W2LK:0?OM7"[EW?%NMI3
M3ART?E>1O*]WQ"K;W?L`5>_SW;O+U^R>WIM[?H>Q5)F_+W?__M][K,.ECV31
MMA=X`!_NC.4SWGFH?<&[5819VG<C-Y3P$WY9E_:E8]PQ/%@][X"GPWOX(7MU
MJ25H+U\C/JS6]Z!,,+6.B$_Q2S6W7[B*/"4M=-,DT-\-Q]LQ&']5@_N,EX4Z
MF2&SRS49Y(L\=N/N/+ZH)G<6[]B(_(UWR`X93,+-+I?DJVH/O8)`WLE#>04-
MGNGDGD3R5?ZG4O@?#P^-_)8W\Q32]8'Y,*]3O[MW=M!<7LA;:#G_Y`GFBV?S
M/A7$>^0YV3/I_#FFQ3K>HN'Y)5OB6?OIHU^#7LG7=4//R!!]HJ>R^YW1TT!'
M_^CS?("7]%7GSE?Z,GO@,3W5T?2;'J9>>4_/X==\J%>I8S[$F_I3?U0U/*E7
M.J">U;?Z<$<:_:?OE/5=ML3;^EN/ZSF]/I;9O?ZC4O5Y'NQ1/59WX<5>V(-T
MEYOL0RI8OSK-WMC'=&`?[?=LN.N^EGN,YYQJ/^LSW1G]R\87D&=O;D]G[[<Q
MO;*D5]S?='*/49VZV@WWVIZ;L_M!^]")[^BENR5\?\_[1'OL#3C^W>?6?-\/
M5*[^NUUW]A7X%A6LG_,X#L'U.,*'J/*\V&HN@"_O'SY61>O@G'9'=8M/4(6Z
MQ-]<\9ZA<WQ^S[=CN<'E7"'?I(]\DI_I<K`!1_DV?7FO?);OY&;NRP?YK+I]
MS_R.W^_EJG!LA0-]Y^-3@K^^!Q_0#_I"_]&F],\-W8X^TD_ZE):L^]^_N^VA
M_M#'^(Z;ZE=]JZ_T:;W))_9<7YTB=2,>]MFI4Z?X%#WMI^VR[TVI>D"'Z`>?
M[8_5G@_1V?5(%^D!7^Z/VF6?U(OCW>?HBEOO;U/3S;Y)^L+>^((_FMKQ;;N#
MZW7<3_R*'^OS<Y^^T0&_Y(;\T%2H,_[\7:TK/N8'IHM\\Y/PM[_4/_\P=?=.
MW/1G_GK/[%7_JJ7["-CUVU*B7]5E?S-]]E;']M]^J=_Z=3\M;>)DW_>#?K;>
M^X4_L#7WR-[XHU+4'_R5_^^/]':]<SG_V7_IH__F6O73GY,N^;\3Z[._]H?N
MJM[[S])4S_VQO_B?I&Z^_)__X^_U-SRL-__K'Y*V=_4?_T_IBO<[W;_^R_](
MCW-\V76N[OK?)W7IL1P2S7>#U5`TV5C^%P`F4MO?+4;6+#<($>&CX"V`V1;X
M9]^!-<&-!#@!4H"4%/EW`7(\!P]>Q`%6@-<>7Q<853GC#,\C`HZ`'6#@A-@5
M.,W/OF,.L8`M8,GWV)$U:XX\I@#2@'W4_?<!^CU_3TQSX?&`D92,]XSM-QG@
M5C;($(%%X`!(`!8_*:!DQP0^4@V@?(3N*($\S!1(!5J`!&`,B.)I@0P@GU7A
MG7A9(!BH3[EZX9\9>$CI>?@?_*<&8ER%7AKX!OY1/B#?L0/.@6R4$8B=46B[
MC)1$QN"!=*`3B!M)>649``@([E%58.)4YPUH<-X&>`A.7%S@(`CE^8%^(('W
M",91'J`DR.4%.I6@(7@)8H)HH'MG-N5)?9XG^`FN4BZ@H<<(IGFEH"-X"L*!
M-B"C=S<M@HN9(O,*RE%UH";(D'6"H-T=>`M64?P?_?<+PH(XEPF(=OB"PR`4
ME0C.'<A@,NA$C7IRH#,X1F6"=J`;*`T^@Z%@&W@-DE%L8-_1#&Z#&E4<*`R"
M@U^4;+?KX4[D8!B5VYV#Z&`Z6`Y6?]:?YN(.OH-P5SQX_<V#(E<D6`WB@UT4
M-<@,6H/\8!"5_FF#`:%OE0I&@P4A-A@+(H0)81*5"\H=WV!#:$/I@02A1,AR
M"8+>($!H$4Z$G1Y#N!$24=#@./@1WEQ.CF4G$HZ$0]1`"')H`%!`2^@21@$G
M!TL(!<"$IB!**!`>A"LA%$`;T(0LH0:@`="$(X=."`7<`%,`QO$33C$V83BX
M$'X<&@!M,!0&!%1`%1!(1`$:0,G1$MX`U$$@T11&`44A*I,4DH0!C@$$<NB$
M&D`5$!!(A1I'%=`5AAPP(14``%`!@81..`7`A5[A5Y@2!H,=1U,X%+J%:*%6
M"!-.`7UAR#$71H4W@%Z8%=:%=N%-&-BM-F2A64@78AQ482!1!40!+Z%66!G*
MA#-A84@;:`!%(5!H"R:&BF'G9@)>A7SAQG$41H4N(5%X`U"&5^$4P!H.A:XA
M%%`5I@4)PA((&O9<#=YHN!<^AAD':4@%G(9T(7!8&+:%<.%I^!8&AJ'=;;A#
M^8.]X6[(<?B&OF%<Z!Q&A]$A8J@<XE`JX<;1&E8!F"%,J!=BA51`=4@=3H?.
MH75X'7*$[=]J$QE.A52A;'@#-(9OH7A('H*'[V%Y:!N>A\N5..AQ'(550%38
M%Y*&`$`5(!_2A^,A>'@47C;X(7:XZ($<D6&"4!0>A52A8U@?$H52X7>8%1:(
MU,%,N!8FAPGBT847?AQJ(57X'?:'9^%J6!5JA3TAA?@=`H8FHFK(&?*&.UZ'
MZ"$NAB('8-@?2H5MX7&8<?2'46&"P"/"A5PA=4`%=(4WHHV((,J(--0RZ'$,
MAD`B8'@@!A),8H\H)*J%0B)A2!1.B?<ADBATZ8-!X5#X'G*%[Y^6.$,QAVSA
MB0@8PHA?H)C(0F6')0>)&""&B6KBFH@3HAR#(7+HO<2)<N)26!'BB5'7@G@2
M\HD\U(>X#P**?2*-^"<2BEQ71W@H(HH?5$BX)S**Q)08^.HE'1$AI*AW98,9
MH:48**:''J&FB$'-?X^BI\A2^8FAHJCH745Z[*#L9"I:78%=JJ@JKHH:5')G
M#V8NL&*L"-W-BI>+1E@K#EZ28J>X*T)0;")$J"O^BHS7G)@I$HL5%*AX+"*+
M81>IN"PRBQ$41?@L0HMO5S'H_E&*PR*U2/HHB7%'I:@M?EY<HK#X+0*+O>*B
M."ZJ5R7@M8AT>(OGHFS3#0Z*[2)YI1].B_$BKZB/J8M'![M8+^(RTB*\N"_:
MB];BI+@N9HO_(K^H*):*!6,`Y2C2BPFCPE@N(HP-X[:(*?J+$:/#R"F:BQ7C
MD:,L4HP9H\1X+PJ,^2+!F#'VB_]@QRA`^7B^HLGH+AZ,#*/*B'J%B]VBR%@Q
MDHE]G<P8,0:+,:/+6'D9BQRCSK@RZHDMH\^(7SF+/:/0.#3N=?CBG6@T:HP8
M8=&X-,9>+*/3^#1N4#!CS3@U_HR5G3%X=NB+-^/$6#)>C3L5S_@U@HT&(]`H
M-5Z-#V'.2#:6C9F.$I0RHHU-X]BX-@)24:/<.#<*7U7CV\$U-HPTH]YH,_*-
M7J.X>#?2C1<CQ`@V;HQVX]V8-EJ-@R/5B#2"C$ICXPA.Q8V"H^3(+3*.EF/>
M>`S^C0ECW[@Y2HYX8[H(.::)C>.[F#C.C8ACY5@Z$HVGX]I(,JJ.@R/*B#%.
MC9>CWP@Z3HZY8=)(.L:.#V/0>#@&CFICYE@X^HYPH]G8.I*-BZ/M"#J^CL'C
MZF@H&H[%HVBH.[(OM^/">#;2CKWC]?@TXHR8H_/H[6F-9L?>V#G.B]KCTI@\
M?H[+HZ!X//Z.SR/QB#W6@Z,C]9@^YH[Q(Z7G/9:$X&/9(3X6C-RC\B@\?H_3
MH_W(.QJ/L*/BR#H6D*BC^HA`NHZ48_,X0$J/]2,%4SUJCELCY\@_9H_K8_1H
MGP60$N3\"$!&D!;,!$E`.I`&Y,?X-KZ/;6/^2';LC_^B[`@]HI!.#J$T.VZ/
M%&3X:$&VD!CD`HD\`H_=XP/IY)!&)R0-.4+VD"5DRZ="CATLY+[(/!*1"63[
M6#X:C;4C^O@_.CD.W@LI1&:-'&0(Z4%ND""D"7-#*I%BHP[)/F8ZRM$,:3XN
M>JXBZR1"II#XTSFX1CHY`PZN>+F\D0&.,R1'5BY?9+UH/6:0,&2`8Q*Z'!:&
MA:%%3I$!#M&T<E@8R$,BF4A6&)G=%AG@`)$JAQ.@2$Z2E"0CF7$X`?(=(>G:
ME)$GQ]]`27Z2E:3&,0`$$J,D)GDD:I)<C5@8<IB2&(<D"4J^DHHD*^E*>I*C
MY"EY/P8X;B/'\3?<`)@D*\E+PI+`Y"+92L:26:(/&>#D2!N'*XD\R)+!9#,Y
M`%08H>1GV(]A8M1D-6E-7I/89#:I36Z3^4;=.$PNDK2D,QE,*I/$I#19BG&3
MZ&0ZJ4ZND^QD.^E.@AM[9,8A3LZ3DR0B^4QFB?W9DZ9/[I-F3-\X2X:3]"0L
M:4K.DO@DBY;R,&GQ!T+)3RZ4*T?_Z$H&$N1D0/E*]I+"I#F93W)C]`[!1`:V
M=F"3+A86&6CODM&A4":4H%DGDZ`QE`:3Z7A)WI,1I40)2E*4RZ0M>5%R8\W8
M%A2C+63LV7;VG2$=(R7\T5,2@&+2?(92VDBIXS`)4;J4+R4Y"4W>D\?,E5:.
MU90O&6RFCK%G[5EQQI9Q*S_ERF&/[65#96B4/$J22R5(P!$@E01!2UE."GJL
MV5-YE+%,4YYQUBKEE#S9QY155F0AY8%&E#UD=>4FQ*%U9+B0=F92?F@@FEXF
MFG657J4">51^D@N!2_D1+).!I"49(R9I8\=LQE:V>)99Q029<8+6&4W)Y'%G
MEU-11I+!E>>9>Y:4*6:.4UYV+0F5A&5AZ41>DHUE(AD0F)4"94004Y:!D*4B
M&,J,:!B39>F5"6=X$FC9E'5G3QG4M%.F8\&9;09<DI9696/&598=GZ5REEHB
M2%&DQC%+EI7`I"LI$LR62XQ3F9?A2[NE6_DPP6>_Y5O)4_IF`IEEAIN1.9F9
M/;29[90C6F@&=T!HR^5S>03%DQZ',BD2@)6QI!,@%!"4F20YMEW69$[98495
MSF:CY54I7/YFX4Q7UETZE\IE>>FBR6=Q1W+FC665\F7!XCDFD\NDJ\%?]I<S
MI=61G0EDUUAV%HVM9Y_E3REB)I?$98.I4X:6G)DMMF(BF('E>!9?5IAU3__8
M<="2^N5KZ00$`#MFCUD2O);8)8=I4+YH&EE(&:!]-*M@:Z>9C4T;I7?I41:9
MIT^#U@CJE>MEC@=B=F@<V8=9CF64'&6.AP72F/UD&+E*@I-E90!@9NZ89F9B
M^4SZDD*F)T9AFI9`)9@I9PH=1>4J&4Y6&";!F6EFGIF[Y`I86PY+;R9S^8S-
MF81FB&)"'I(1)9JY9YZ9$=Z?66A6'4[:HREI(AU+9,G16`8`3\">F6GRF$-@
M/T:G?9J@9J@I:HZ:I&:I^6FZD#G'CKEI[IELIG^GIIF:L&:L*6O.FK1FK6EK
M_AS1)<JA:BZ:K69-R$#2CT2'HMEG-IJWI&OS1PH=CF4CV?\,06>DZ(@0^C^T
M7==X,4::6YZ7B9&]>2+>:7/H0)'B8)!7(14W;:4BV-\,/5?-UM/GX#>[W;*9
MX,!WZX^YN6ZFF_#=$!1M4H`K7B5H)O%-1F:?=V_:FY5@MGGHD#7EIO:3WP"<
MVV;!27`:G`'G3@1M)IP')QBH!U*"#9FC=)WY2Q&GI!0N^9L\$.OSXP@__R;#
M^?A0,]S.Q[EMWCLBYQPH.T*<FR`A:&UF9@O:A39N?IS:YDY4<-HV':>\Z?]\
M0.K/>[=PPIS3'<ZI!FY_*&?+"0^]9$*GT!G28)QOC\?)<6:<"2=P0W,BG$JG
MS*G]O($AH9EG=$YYX&;1:7$^E@;GP3EOVC=09]@I<WJ=)2?KTW">G6<.$4C^
M$36ZF$:I<K(S&YJ3U^=U>&7-S1EO8H`#YP-H=XIW0I!T)W4:1'ZG=`<#SIOB
MGXU907Y1A.<CJ%*2D%%4XGD(UIG^(Q3%=UZ#Y^/AZ4BZ-DI0&KDZT9&NC>ZB
..>6Z>ER=7@[W<C@IB@P=4
`
end
------- end -------

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 09:06:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA07873 for xemacs-beta-people; Wed, 26 Jun 1996 09:06:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA07870 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 09:06:44 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA13404; Wed, 26 Jun 1996 09:06:37 -0500 (CDT)
Message-Id: <199606261406.JAA13404@a.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA211557963; Wed, 26 Jun 1996 15:06:03 +0100
Date: Wed, 26 Jun 1996 15:06:03 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: Neal Becker <Neal.Becker@comsat.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14 crash again 
In-Reply-To: <199606261259.HAA22789@charles.cs.uiuc.edu>
References: <E0uYu7N-00006b-00@neal.ctd.comsat.com>
	<199606261259.HAA22789@charles.cs.uiuc.edu>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

    Chuck> This has got to be an HPUX bug either with the OS or the
    Chuck> compiler.  I've had a couple reports of it sent to
    Chuck> crashes@xemacs.org as well.  All happened on HPUX.  Can you
    Chuck> see if there are any known bugs with strcat?

>From the problems database (through http://support.mayfield.hp.com):

Problem Report: 5003302299
Status:         Open

System/Model:   9000/700
Product Name:   HPUX S800 10.0X
Product Vers:   9245XB.10.00

Description: strcat(3C) may read beyond end of source string, can cause SIGSEGV


*** PROBLEM TEXT ***
strcat(3C) may read beyond the source string onto an unmapped page,
causing a segmentation violation.

Appears to be an hpux 10 problem, though.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 14:19:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA12588 for xemacs-beta-people; Wed, 26 Jun 1996 14:19:55 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA12585 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 14:19:54 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA27252 for <xemacs-beta@cs.uiuc.edu>; Wed, 26 Jun 1996 14:19:48 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id MAA27816; Wed, 26 Jun 1996 12:18:49 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14 crash again
References: <E0uYu7N-00006b-00@neal.ctd.comsat.com>
	<199606261259.HAA22789@charles.cs.uiuc.edu>
	<199606261406.JAA13404@a.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Richard Cognot's message of Wed, 26 Jun 1996 15:06:03 +0100
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 26 Jun 1996 12:18:47 -0700
Message-ID: <m220j2fk6g.fsf@deanna.miranova.com>
Lines: 17
X-Mailer: Gnus v5.2.25/XEmacs 19.14

I'm putting this into the FAQ.

>>>>> "Richard" == Richard Cognot <cognot@ensg.u-nancy.fr> writes:
>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:
    Chuck> This has got to be an HPUX bug either with the OS or the
    Chuck> compiler.  I've had a couple reports of it sent to
    Chuck> crashes@xemacs.org as well.  All happened on HPUX.

>> From the problems database (through http://support.mayfield.hp.com):
...


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 15:12:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA13196 for xemacs-beta-people; Wed, 26 Jun 1996 15:12:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA13191 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 15:12:25 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA15495 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 15:12:17 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id QAA11516 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 16:12:03 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp011328; Wed Jun 26 16:06:04 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA27192; Wed, 26 Jun 96 16:06:04 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA03251; Wed, 26 Jun 96 16:05:02 EDT
Message-Id: <9606262005.AA03251@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: It could be worse, but it'll take time.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: SunOS with Sparcworks gripe
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMdGX3VtTztlqB385AQGSawQAgG7b0x5UuOF5T/DFp6yV6UJfhuU9UALY
	      gl1+7/H1jNU/94+UxtzRMiLrA/n/XMqdhBY9QCFJ1fXyj3Hlh7ir696nG3nXopTQ
	      5vlVb40hh8lBOvw3o64hbn7hEP/TDronxGBfxA5f9W5rD2HjV5lxS2QBK5wfftxu
	      u+3MRA4CdwM=
	      =Z7vC
Date: Wed, 26 Jun 1996 16:04:51 -0400
Sender: rickc@lehman.com

As with 19.13, the Sparcworks support make s arbitrary changes in use
preferences.  Specifically, it makes the bar-cursor the default and
turns on pending delete.

I believe that this makes sparcworks configurations different from all
other XEmacs configurations in a way that can be quite confusing to
the unsuspecting.

Really, the sparcworks code should leave this stuff alone.

			rick

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 15:17:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA14086 for xemacs-beta-people; Wed, 26 Jun 1996 15:17:09 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA14073 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 15:17:06 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA15529 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 15:17:01 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id QAA11753 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 16:17:02 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp011373; Wed Jun 26 16:07:43 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA27309; Wed, 26 Jun 96 16:07:42 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA03342; Wed, 26 Jun 96 16:07:42 EDT
Message-Id: <9606262007.AA03342@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: The first fully modular software disaster.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: SunOS Sparworks crashes
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMdGYhltTztlqB385AQFUuwP/V86QAnGOhNXysFlXtKkzwNbzqj2aKlsL
	      qJ50GtdpkqgMWjwgwcF6UG3J0YzQ6U46V3DgAq2+gGk6nl7aBKJ3PwQJiQoPkdHz
	      vp0XQV9K2IVkT2EpDVR7w5za400+pycMXnn2ETvQLLxF2DKwRbnQPfPAGHOt5IaG
	      fusSMvdc8LU=
	      =FWur
Date: Wed, 26 Jun 1996 16:07:40 -0400
Sender: rickc@lehman.com

Users at my site have experienced both of the crashes reported here
recently:
 - xemacs -q crashes complaining about nil nnot being stringp.  So
   far, only one user has seen this.
 - Exiting by way of the menu causes a crash.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 16:27:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA14979 for xemacs-beta-people; Wed, 26 Jun 1996 16:27:02 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA14976 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 16:27:01 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA00943 for <xemacs-beta@cs.uiuc.edu>; Wed, 26 Jun 1996 16:27:03 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id OAA03976; Wed, 26 Jun 1996 14:26:38 -0700
Date: Wed, 26 Jun 1996 14:26:38 -0700
Message-Id: <199606262126.OAA03976@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: turner@lanl.gov
Cc: drich@cisco.com, steve@miranova.com, xemacs-beta@cs.uiuc.edu
Subject: Re: :) Re: smileys and VM (also a Gnus typo)
In-Reply-To: <199606260258.UAA21975@gielgud.lanl.gov.xdiv>
References: <199606252316.RAA21397@gielgud.lanl.gov.xdiv>
	<m220j3a0tn.fsf@deanna.miranova.com>
	<199606260040.SAA21483@gielgud.lanl.gov.xdiv>
	<199606260047.SAA21487@gielgud.lanl.gov.xdiv>
	<199606260109.SAA02018@sandman.cisco.com>
	<199606260258.UAA21975@gielgud.lanl.gov.xdiv>
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.48)
Content-Type: text/plain; charset=US-ASCII

>>>>> "John" == John Turner <turner@xdiv.LANL.GOV> writes:

    John> Except smileys at the very start of the Subject line aren't converted
    John> in Summary buffers.  Probably smiley.el, though I haven't looked...

It looks like that's due to the regexps in smiley.el.  They expect
whitespace before the :-), and the one in the subject buffer is
preceded by a quote.

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 17:00:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA15295 for xemacs-beta-people; Wed, 26 Jun 1996 17:00:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA15292 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 17:00:36 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA16012 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 17:00:32 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id QAA18347; Wed, 26 Jun 1996 16:00:33 -0600
Received: by suomi (SMI-8.6) id QAA10504; Wed, 26 Jun 1996 16:00:33 -0600
Sender: mdb@cdc.noaa.gov
To: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: [comp.emacs.xemacs] Minor bug deleting frames with 19.14, linux, fvwm
Organization: CIRES, University of Colorado
X-Attribution: mb
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 26 Jun 1996 16:00:32 -0600
Message-ID: <vkhgry1b0f.fsf@cdc.noaa.gov>
Lines: 26
X-Mailer: Gnus v5.2.25/XEmacs 19.14

This happens using solaris-2.5/fvwm2.0.42 as well.

------- Start of forwarded message -------
From: ogre@atomic.com (Joe Rumsey)
Newsgroups: comp.emacs.xemacs
Subject: Minor bug deleting frames with 19.14, linux, fvwm
Date: 26 Jun 1996 21:13:40 GMT
Organization: Atomic Games
Message-ID: <slrn4t3a0m.39r.ogre@earth.atomic.com>

  Using the precompiled linuxelf-athena binary under linux 2.0 and
fvwm2, I've found that often when I send a WM delete command to an
XEmacs 19.14 frame, the frame won't go away until emacs receives a
keyboard event (in that frame or any other).  Doesn't happen every
time, but it does work that way most of the time.

  Not a big deal, just annoying.

-- 
   /\ /\
   \_\_/                    Joe Rumsey
At(__o/_)mic Games        ogre@atomic.com
   / / \            http://www.atomic.com/~ogre/
   \/ \/

------- End of forwarded message -------

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 17:33:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA15631 for xemacs-beta-people; Wed, 26 Jun 1996 17:33:01 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA15628 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 17:32:59 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA16147 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 17:32:56 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id QAA19068; Wed, 26 Jun 1996 16:32:57 -0600
Received: by suomi (SMI-8.6) id QAA11043; Wed, 26 Jun 1996 16:32:56 -0600
Date: Wed, 26 Jun 1996 16:32:56 -0600
Message-Id: <199606262232.QAA11043@suomi.cdc.noaa.gov>
From: Mark Borges <mdb@cdc.noaa.gov>
To: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: [19.14] CDE include files
Organization: CIRES, University of Colorado
X-Attribution: mb

Our sysadmin tried to compile XEmacs-19.14 --with-cde. He says it
fails because these files (from frame-x.c) don't exist under
/usr/dt/include. 

	#ifdef HAVE_CDE
	#include <Dt/Dt.h>
	#include <Dt/Dnd.h>

i.e., there is no ../Dt/ subdirectory. Is this standard?

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 18:14:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA15918 for xemacs-beta-people; Wed, 26 Jun 1996 18:14:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA15915 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 18:14:31 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA16310 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 18:14:27 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id QAA03348; Wed, 26 Jun 1996 16:13:29 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA29530; Wed, 26 Jun 1996 16:13:02 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA23756; Wed, 26 Jun 1996 16:12:59 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA19568; Wed, 26 Jun 1996 16:12:55 -0700
Date: Wed, 26 Jun 1996 16:12:55 -0700
Message-Id: <199606262312.QAA19568@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Rick Campbell <rickc@lehman.com>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: SunOS with Sparcworks gripe
In-Reply-To: <9606262005.AA03251@cfdevx1.lehman.com>
References: <9606262005.AA03251@cfdevx1.lehman.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:

Rick> As with 19.13, the Sparcworks support make s arbitrary changes in use
Rick> preferences.  Specifically, it makes the bar-cursor the default and
Rick> turns on pending delete.

More like textedit?

Rick> I believe that this makes sparcworks configurations different from all
Rick> other XEmacs configurations in a way that can be quite confusing to
Rick> the unsuspecting.

Rick> Really, the sparcworks code should leave this stuff alone.

I tend to agree, but this is a historical thing.  I assume there was a
disagreement between Sun's Human Factors folks and the Net sometime in
the past.

Perhaps one of the old-timers can comment?

Martin


From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 19:49:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA16571 for xemacs-beta-people; Wed, 26 Jun 1996 19:49:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA16568 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 19:49:51 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA16680 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 19:49:47 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id RAA06050; Wed, 26 Jun 1996 17:49:36 -0700
Date: Wed, 26 Jun 1996 17:49:36 -0700
Message-Id: <199606270049.RAA06050@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: xemacs-beta@xemacs.org
Subject: Hanging frames
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.48)
Content-Type: text/plain; charset=US-ASCII

I'm still seeing the problems I mentioned before with frames becoming
hung even in the released version of 19.14.  Is anyone else still
seeing this?

Everything works fine until I iconify a frame, and then a good
percentage of the time, the frame ceases to update after I deiconify
it.  Sometimes the contents frame will be drawn, others I just get a
menubar and toolbar.  However, any input to the frozen frame is taken,
it just doesn't update the display (which can be really creepy if you
have the same buffer displayed in two frames -- one frozen and one not).

It used to be in the beta that I could always unfreeze a frame by
creating a new one from it, and then deleting the new frame.  That
doesn't even work any more.  Usually, the frame will eventually come
back to life if I leave it alone long enough.

Does anyone have any idea what is going on?  I can't seem to track
anything down that could explain this!

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 20:18:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA16789 for xemacs-beta-people; Wed, 26 Jun 1996 20:18:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA16786 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 20:18:12 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA16747 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 20:18:07 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa17826;
          26 Jun 96 21:11 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id VAA02060; Wed, 26 Jun 1996 21:10:47 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id VAA24555; Wed, 26 Jun 1996 21:10:46 -0400
Date: Wed, 26 Jun 1996 21:10:46 -0400
Message-Id: <199606270110.VAA24555@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: drich@cisco.com
Cc: xemacs-beta@xemacs.org
Subject: Re: Hanging frames
References: <199606270049.RAA06050@sandman.cisco.com>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Idiot Glee
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "DR" == Dan Rich <drich@cisco.com> writes:

    DR> I'm still seeing the problems I mentioned before with frames
    DR> becoming hung even in the released version of 19.14.  Is
    DR> anyone else still seeing this?

    DR> Everything works fine until I iconify a frame, and then a good
    DR> percentage of the time, the frame ceases to update after I
    DR> deiconify it.  Sometimes the contents frame will be drawn,
    DR> others I just get a menubar and toolbar.  However, any input
    DR> to the frozen frame is taken, it just doesn't update the
    DR> display (which can be really creepy if you have the same
    DR> buffer displayed in two frames -- one frozen and one not).

Dan, what window manager are you using?  I've seen this behavior even
in 19.13, but only under fvwm 2.0.42.  I never saw it under ctwm or
fvwm 1 (which admittedly I didn't flex much).  I've seen the same
thing under the 19.14 betas but haven't tried 19.14 proper yet.  I
have yet to figure out whether its an fvwm2 thing or an XEmacs thing
(or both?)

-Barry

From xemacs-beta-request@cs.uiuc.edu  Wed Jun 26 20:56:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA17044 for xemacs-beta-people; Wed, 26 Jun 1996 20:56:35 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA17041 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 26 Jun 1996 20:56:33 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA16836 for <xemacs-beta@xemacs.org>; Wed, 26 Jun 1996 20:56:31 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id SAA06367; Wed, 26 Jun 1996 18:56:17 -0700
Date: Wed, 26 Jun 1996 18:56:17 -0700
Message-Id: <199606270156.SAA06367@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
Cc: drich@cisco.com, xemacs-beta@xemacs.org
Subject: Re: Hanging frames
In-Reply-To: <199606270110.VAA24555@anthem.CNRI.Reston.Va.US>
References: <199606270049.RAA06050@sandman.cisco.com>
	<199606270110.VAA24555@anthem.CNRI.Reston.Va.US>
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.48)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Barry" == Barry A Warsaw <bwarsaw@anthem.cnri.reston.va.us> writes:
>>>>> "DR" == Dan Rich <drich@cisco.com> writes:

    DR> I'm still seeing the problems I mentioned before with frames
    DR> becoming hung even in the released version of 19.14.  Is
    DR> anyone else still seeing this?

    Barry> Dan, what window manager are you using?  I've seen this
    Barry> behavior even in 19.13, but only under fvwm 2.0.42. 

I'm currently using tvtwm on X11R6, but I don't know what version (I'm
running in a "supported" environment for a change, and didn't build it
myself).  The last time I asked our sysadmin group that question, they
couldn't tell me either, but claim it is only a few patches behind the
latest.

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 00:18:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA18016 for xemacs-beta-people; Thu, 27 Jun 1996 00:18:28 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA18013 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 00:18:27 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA17787 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 00:18:29 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id WAA07710; Wed, 26 Jun 1996 22:17:42 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [20.0-b26/Mule] Success on Linux 2.0.0/ELF
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 26 Jun 1996 22:17:40 -0700
Message-ID: <m2enn1q0zv.fsf@deanna.miranova.com>
Lines: 40
X-Mailer: Gnus v5.2.27/XEmacs 20.0

After trying out a highly optimized 19.14 final, I was curious to see
how much of a speedup of 20.0 I could get by cranking up the
optimization ...  It looks like it works reasonably well.

The canna.el patch is broken, the mule-charset.c and mule-misc.el and
chinese-hooks.el patches went in fine.

Configured for `i486-unknown-linux2.0.0'.

  Where should the build process find the source code?    /i/xemacs-20.0-b26
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 00:41:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA18074 for xemacs-beta-people; Thu, 27 Jun 1996 00:41:55 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA18071 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 00:41:53 -0500 (CDT)
Received: from cortex.corpus.uni-muenster.de (news@PPPE131.UNI-MUENSTER.DE [128.176.20.139]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA17505 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 00:41:44 -0500 (CDT)
Received: (from gutschk@localhost) by cortex.corpus.uni-muenster.de (8.6.12/8.6.11) id HAA02540; Thu, 27 Jun 1996 07:36:32 +0200
Sender: gutschk@uni-muenster.de
To: carney@gvc.dec.com
Cc: xemacs-beta@xemacs.org
Subject: Re: color ttys
References: <9606260925.AA01832@fornet.gvc.dec.com>
X-Face: +.[`xCMz]E6GW}5ECgY#C"Er6&v$q7:oe+zPlPtOh>/US;9B>;)ro_lpLx9/]q_{u-\YR>r
 P&)Da0gS,PW{@BWSG,PIV)3#J<$Ft_t]qa!xF~'*wuwg-CJj*0:EUr3z}y
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Markus Gutschke <gutschk@uni-muenster.de>
Date: 27 Jun 1996 07:36:31 +0200
In-Reply-To: Stephen Carney's message of Wed, 26 Jun 1996 11:25:24 +0200
Message-ID: <m2u3vxkduo.fsf@cortex.corpus.uni-muenster.de>
Lines: 27
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Stephen Carney <carney@gvc.dec.com> writes:

> 
> I'm not getting any color in ttys in 19.14.  None of my termcap
> entries had AB or AF attributes.  So I created an xterm-color entry,
> based on xterm, with AB and AF.  When I startup, (device-class) is
> 'color, but the modeline is B&W, as are all of the M-x edit-faces
> entries.
> 
> What values do I need to give to AF and AB?  What am I missing?
> 
>         Steve

These are the values that my color xterm sets by default. Maybe that
is helpful to you:

xterm|vs100|xterm terminal emulator (X window system):do=^J:le=^H:ho=\E[H:
    :co#80:li#25:cl=\E[H\E[2J:bs:am:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:ce=\E[K:
    :cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:md=\E[1m:mr=\E[7m:me=\E[m:
    :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:
    :pt:sf=\n:sr=\EM:al=\E[L:dl=\E[M:im=\E[4h:ei=\E[4l:mi:dc=\E[P:MT:
    :ks=\E[?1h\E=:ke=\E[?1l\E>:xn:AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:hs:
    :ts=\E[?E\E[?%i%dT:fs=\E[?F:es:ds=\E[?E:is=\E\E[m\E[?7h\E[?1;4l:
    :cs=\E[%i%d;%dr:rs=\E[r\E<\E[m\E[H\E[2J\E[?7h\E[?1;3;4;6l:


Markus

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 00:55:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA18119 for xemacs-beta-people; Thu, 27 Jun 1996 00:55:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA18116 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 00:55:41 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA18182; Thu, 27 Jun 1996 00:55:44 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id WAA16189; Wed, 26 Jun 1996 22:55:11 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA07307; Wed, 26 Jun 1996 22:55:09 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA29708; Wed, 26 Jun 1996 22:55:05 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA21349; Wed, 26 Jun 1996 22:55:00 -0700
Date: Wed, 26 Jun 1996 22:55:00 -0700
Message-Id: <199606270555.WAA21349@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: andyp@parallax.co.uk (Andy Piper), Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: Peter Cheng <phc@eng.sun.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: sunpro-startup?
In-Reply-To: <199606260736.IAA22588@wrath.parallax.co.uk>
References: <199606260736.IAA22588@wrath.parallax.co.uk>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Andy" == Andy Piper <andyp@parallax.co.uk> writes:

>> When a customer installs the workshop binary, it is used in preference
>> to sparcworks.

Andy> So why don't I have it - I believe I am bang up to date.

Not *that* up to date.  It's not ready for prime time yet - But
bleeding edge folks such XEmacs beta testers can get an alpha version from:
http://www.sun.com/sunsoft/Developer-products/ 
I highly recommend the C compiler.

Andy> This is the problem:
Andy> Signalling: (wrong-type-argument stringp nil)
Andy> string-match("/$" nil)
Andy> sunpro-startup()

Ok, I got it.  This problem occurs if and only if your PATH has
leading, trailing, or consecutive `:' characters.  Correct me if I'm wrong.

Chuck, I think we ought to put out a patch version of 19.14 sometime.
At the very least I'll build new sparcworks binaries (was going to do
that anyways).

Here's a patch:
*** /tmp/geta21325	Wed Jun 26 22:36:07 1996
--- sunpro-init.el	Wed Jun 26 22:31:25 1996
***************
*** 89,95 ****
          (cond
           ((let ((path exec-path) dir (found nil))
              (while (and path (not found))
!               (setq dir (car path))
                (setq path (cdr path))
                (setq dir (concat dir (if (string-match "/$" dir) "../" "/../")))
                (setq found (funcall sunpro-dir-p dir)))
--- 89,95 ----
          (cond
           ((let ((path exec-path) dir (found nil))
              (while (and path (not found))
!               (setq dir (or (car path) "."))
                (setq path (cdr path))
                (setq dir (concat dir (if (string-match "/$" dir) "../" "/../")))
                (setq found (funcall sunpro-dir-p dir)))

--
Martin Buchholz
XEmacs Developer
Developers' Product Business Unit, SunSoft, Sun Microsystems, Inc.

Mailstop: MPK16-305           |  Email: Martin.Buchholz@sun.com
2550 Garcia Avenue            |  Phone: (415) 786-5895
Mountain View, CA 94043-1100  |    Fax: (415) 786-9552

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 02:35:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA18556 for xemacs-beta-people; Thu, 27 Jun 1996 02:35:24 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA18553 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 02:35:23 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA18032 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 02:35:17 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id IAA21058; Thu, 27 Jun 1996 08:36:50 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id IAA27508; Thu, 27 Jun 1996 08:36:32 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id IAA05796; Thu, 27 Jun 1996 08:40:00 +0100
Date: Thu, 27 Jun 1996 08:40:00 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606270740.IAA05796@wrath.parallax.co.uk>
To: xemacs-beta@xemacs.org, rickc@lehman.com
Subject: Re: SunOS Sparworks crashes
X-Sun-Charset: US-ASCII


> Date: Wed, 26 Jun 1996 16:07:40 -0400
> 
> Users at my site have experienced both of the crashes reported here
> recently:
>  - xemacs -q crashes complaining about nil nnot being stringp.  So
>    far, only one user has seen this.

This is the duff supro-init code I have reported. Martin still hasn't given
a good reason why it doesn't check for sparcworks - given that is what
most people have ;)

andy

*** sunpro-init.el~     Tue Jun 25 12:35:40 1996
--- sunpro-init.el      Wed Jun 26 09:51:07 1996
***************
*** 82,89 ****
      (let ((sunpro-dir-p
             #'(lambda (dir)
                 (and dir
!                     (file-exists-p (concat dir "bin/workshop"))
!                     (file-exists-p (concat dir "lib/workshop.el"))))))
      
        (defconst sunpro-dir
          (cond
--- 81,87 ----
      (let ((sunpro-dir-p
             #'(lambda (dir)
                 (and dir
!                     (file-exists-p (concat dir "bin/sparcworks"))))))
      
        (defconst sunpro-dir
          (cond


From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 02:43:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAB18574 for xemacs-beta-people; Thu, 27 Jun 1996 02:43:41 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAB18571 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 02:43:40 -0500 (CDT)
Received: from red.parallax.co.uk (red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA19293 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 02:43:40 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id IAA21292; Thu, 27 Jun 1996 08:44:19 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id IAA27653; Thu, 27 Jun 1996 08:44:01 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id IAA06278; Thu, 27 Jun 1996 08:47:29 +0100
Date: Thu, 27 Jun 1996 08:47:29 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606270747.IAA06278@wrath.parallax.co.uk>
To: mrb@eng.sun.com
Subject: Re: sunpro-startup?
Cc: xemacs-beta@cs.uiuc.edu
X-Sun-Charset: US-ASCII


> >>>>> "Andy" == Andy Piper <andyp@parallax.co.uk> writes:
> 
> >> When a customer installs the workshop binary, it is used in preference
> >> to sparcworks.
> 
> Andy> So why don't I have it - I believe I am bang up to date.
> 
> Not *that* up to date.  It's not ready for prime time yet - But
> bleeding edge folks such XEmacs beta testers can get an alpha version from:
> http://www.sun.com/sunsoft/Developer-products/ 
> I highly recommend the C compiler.
> 
> Andy> This is the problem:
> Andy> Signalling: (wrong-type-argument stringp nil)
> Andy> string-match("/$" nil)
> Andy> sunpro-startup()
> 
> Ok, I got it.  This problem occurs if and only if your PATH has
> leading, trailing, or consecutive `:' characters.  Correct me if I'm wrong.

Perhaps - but this still doesn't fix the problem that very few people 
have workshop, whereas loads have sparcworks.

andy

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 02:24:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA18528 for xemacs-beta-people; Thu, 27 Jun 1996 02:24:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA18525 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 02:24:01 -0500 (CDT)
Received: from max3.rrze.uni-erlangen.de (max3.rrze.uni-erlangen.de [131.188.71.14]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA17992 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 02:23:53 -0500 (CDT)
Received: from [10.10.62.142] by max3.rrze.uni-erlangen.de; Thu, 27 Jun 96 09:23:34 +0200
Received: (from aoppelt@localhost) by feynman.oppelix.de (8.7.5/8.7.3/oppelix) id JAA27314; Thu, 27 Jun 1996 09:22:35 +0200
Date: Thu, 27 Jun 1996 09:22:35 +0200
Message-Id: <199606270722.JAA27314@feynman.oppelix.de>
From: Achim Oppelt <aoppelt@theorie3.physik.uni-erlangen.de>
To: xemacs-beta@xemacs.org
Subject: 20.0b26 build problems (during dump) on Linux 2.0.0

I am having problems building XEmacs 20.0b26 (patched up from b22) on Linux
2.0.0 (libc 5.3.12). 

----------------------------------------------------------------------
Configured for `i486-unknown-linux2.0.0'.

  Where should the build process find the source code?    /fast/XEmacs/xemacs-20.0b26
  What installation prefix should install use?		  /fast/XEmacs
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g
  Should XEmacs use the GNU version of malloc?            no
  (User chose not to use GNU allocators.)
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /local/include /local/japanese/include
  Additional libraries:                                   /local/lib /local/japanese/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in XIM (X11R5+ I18N input method) support.
  Compiling in Mule (multi-lingual) support.
  Compiling in support for Canna on Mule.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.
  Compiling in code for checking XEmacs memory usage.
----------------------------------------------------------------------

It then builds temacs without problems and builds the DOC file. However,
when running 'EMACSLOADPATH="/fast/XEmacs/xemacs-20.0b26/src/../lisp/prim"
./temacs -batch -l loadup.el dump', I get

----------------------------------------------------------------------
Loading loadup.el...
Using load-path (/fast/XEmacs/xemacs-20.0b26/src/../lisp/prim)
Loading backquote... (2752)
Loading bytecomp-runtime... (2704)
[...]
Loading modeline... (5024)
Loading loaddefs...*** Error in XEmacs initialization
(setting-constant t hebrew-holidays-1)
*** Backtrace
  really-early-error-handler((setting-constant t hebrew-holidays-1))
  # bind (t)
  byte-code("#!B#!B#!	B#!B#" [put hebrew-holidays-1 risky-local-variable t boundp ((holiday-rosh-hashanah-etc) (if all-hebrew-calendar-holidays ...)) current-load-list hebrew-holidays-2 ((if all-hebrew-calendar-holidays ... ...) (if all-hebrew-calendar-holidays ...) (if all-hebrew-calendar-holidays ...)) hebrew-holidays-3 ((if all-hebrew-calendar-holidays ...)) hebrew-holidays-4 ((holiday-passover-etc) (if ... ...) (if all-hebrew-calendar-holidays ...)) hebrew-holidays] 4)
  # bind (current-load-list standard-input)
  # (unwind-protect ...)
  # bind (load-file-name)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  load("loaddefs")
  # bind (x)
  (lambda (x) (load x) (garbage-collect))("loaddefs")
  funcall((lambda (x) (load x) (garbage-collect)) "loaddefs")
  (if (featurep (quote sparcworks)) (funcall l "eos/loaddefs-eos") (funcall l "loaddefs"))
)
  # bind (l)
  (let ((l ...)) (funcall l "backquote") (funcall l "bytecomp-runtime") (funcall l "subr") (funcall l "replace") (funcall l "version.el") (funcall l "cl") (funcall l "cmdloop") (or (fboundp ...) (funcall l "cmdloop1")) (funcall l "keymap") (funcall l "syntax") (funcall l "device") (funcall l "console") (funcall l "obsolete") (funcall l "specifier") (funcall l "faces") (funcall l "glyphs") (funcall l "objects") (funcall l "extents") (funcall l "events") (funcall l "text-props") (funcall l "process") (funcall l "frame") (funcall l "map-ynp") (funcall l "simple") (funcall l "keydefs") (funcall l "abbrev") (funcall l "derived") (funcall l "minibuf") (funcall l "list-mode") (funcall l "modeline") (if (featurep ...) (funcall l "eos/loaddefs-eos") (funcall l "loaddefs")) (funcall l "misc") (funcall l "profile") (funcall l "help") (if (not ...) (funcall l "files-nomule")) (funcall l "files") (funcall l "lib-complete") (funcall l "format") (funcall l "indent") (funcall l "isearch-mode"!
!
) (funcall l "buffer") (funcall l "buff-menu") (funcall l "undo-stack") (funcall l "window") (funcall l "paths.el") (funcall l "startup") (funcall l "lisp") (funcall l "page") (funcall l "register") (funcall l "iso8859-1") (funcall l "paragraphs") (funcall l "lisp-mode") (funcall l "text-mode") (funcall l "fill") (funcall l "cc-mode") (if (eq system-type ...) (funcall l "vmsproc")) (if (eq system-type ...) (funcall l "vms-patch")) (if (eq system-type ...) (progn ... ...)) (if (eq system-type ...) (progn ... ... ...)) (if (featurep ...) (funcall l "float-sup")) (funcall l "itimer") (if (featurep ...) (funcall l "toolbar") (progn ... ...)) (if (featurep ...) (funcall l "scrollbar")) (if (featurep ...) (funcall l "menubar")) (if (featurep ...) (funcall l "dialog")) (if (featurep ...) (funcall l "mule-load.el")) (if (featurep ...) (progn ... ... ...)) (if (featurep ...) (progn ... ... ... ... ... ... ... ... ...)) (if (featurep ...) (funcall l "tty-init")) (if (featurep ...) (func!
!
all l "tooltalk/tooltalk-load")) (funcall l "vc-hooks") (funcall l "ediff-hook") (funcall l "fontl-hooks") (funcall l "auto-show") (if (featurep ...) (funcall l "energize/energize-load.el")) (if (featurep ...) (funcall l "sunpro/sunpro-load.el")))
)
  (lambda nil (external-debugging-output (format "\nUsing load-path %s" load-path)) (buffer-disable-undo (get-buffer "*scratch*")) (let (...) (setq source-directory temp-path) (setq load-path ...)) (setq load-warn-when-source-newer t load-warn-when-source-only t) (let (...) (funcall l "backquote") (funcall l "bytecomp-runtime") (funcall l "subr") (funcall l "replace") (funcall l "version.el") (funcall l "cl") (funcall l "cmdloop") (or ... ...) (funcall l "keymap") (funcall l "syntax") (funcall l "device") (funcall l "console") (funcall l "obsolete") (funcall l "specifier") (funcall l "faces") (funcall l "glyphs") (funcall l "objects") (funcall l "extents") (funcall l "events") (funcall l "text-props") (funcall l "process") (funcall l "frame") (funcall l "map-ynp") (funcall l "simple") (funcall l "keydefs") (funcall l "abbrev") (funcall l "derived") (funcall l "minibuf") (funcall l "list-mode") (funcall l "modeline") (if ... ... ...) (funcall l "misc") (funcall l "profile") (fu!
!
ncall l "help") (if ... ...) (funcall l "files") (funcall l "lib-complete") (funcall l "format") (funcall l "indent") (funcall l "isearch-mode") (funcall l "buffer") (funcall l "buff-menu") (funcall l "undo-stack") (funcall l "window") (funcall l "paths.el") (funcall l "startup") (funcall l "lisp") (funcall l "page") (funcall l "register") (funcall l "iso8859-1") (funcall l "paragraphs") (funcall l "lisp-mode") (funcall l "text-mode") (funcall l "fill") (funcall l "cc-mode") (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (funcall l "itimer") (if ... ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (funcall l "vc-hooks") (funcall l "ediff-hook") (funcall l "fontl-hooks") (funcall l "auto-show") (if ... ...) (if ... ...)))()
  # (unwind-protect ...)
  call-with-condition-handler(really-early-error-handler (lambda nil (external-debugging-output (format "\nUsing load-path %s" load-path)) (buffer-disable-undo (get-buffer "*scratch*")) (let (...) (setq source-directory temp-path) (setq load-path ...)) (setq load-warn-when-source-newer t load-warn-when-source-only t) (let (...) (funcall l "backquote") (funcall l "bytecomp-runtime") (funcall l "subr") (funcall l "replace") (funcall l "version.el") (funcall l "cl") (funcall l "cmdloop") (or ... ...) (funcall l "keymap") (funcall l "syntax") (funcall l "device") (funcall l "console") (funcall l "obsolete") (funcall l "specifier") (funcall l "faces") (funcall l "glyphs") (funcall l "objects") (funcall l "extents") (funcall l "events") (funcall l "text-props") (funcall l "process") (funcall l "frame") (funcall l "map-ynp") (funcall l "simple") (funcall l "keydefs") (funcall l "abbrev") (funcall l "derived") (funcall l "minibuf") (funcall l "list-mode") (funcall l "modeline") (if ..!
!
. ... ...) (funcall l "misc") (funcall l "profile") (funcall l "help") (if ... ...) (funcall l "files") (funcall l "lib-complete") (funcall l "format") (funcall l "indent") (funcall l "isearch-mode") (funcall l "buffer") (funcall l "buff-menu") (funcall l "undo-stack") (funcall l "window") (funcall l "paths.el") (funcall l "startup") (funcall l "lisp") (funcall l "page") (funcall l "register") (funcall l "iso8859-1") (funcall l "paragraphs") (funcall l "lisp-mode") (funcall l "text-mode") (funcall l "fill") (funcall l "cc-mode") (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (funcall l "itimer") (if ... ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (funcall l "vc-hooks") (funcall l "ediff-hook") (funcall l "fontl-hooks") (funcall l "auto-show") (if ... ...) (if ... ...))))
  # bind (current-load-list standard-input)
  # (unwind-protect ...)
  # bind (load-file-name)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  load("loadup.el")
  # (condition-case ... . error)
  # (catch top-level ...)
*** Killing XEmacs
make[1]: *** [xemacs] Error 255
----------------------------------------------------------------------

Achim

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 03:10:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA19044 for xemacs-beta-people; Thu, 27 Jun 1996 03:10:52 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA19032 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 03:10:49 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA19570 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 03:10:50 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id BAA02881; Thu, 27 Jun 1996 01:10:19 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id BAA12134; Thu, 27 Jun 1996 01:10:17 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA00968; Thu, 27 Jun 1996 01:10:16 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id BAA22180; Thu, 27 Jun 1996 01:10:12 -0700
Date: Thu, 27 Jun 1996 01:10:12 -0700
Message-Id: <199606270810.BAA22180@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: andyp@parallax.co.uk (Andy Piper)
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: SunOS Sparworks crashes
In-Reply-To: <199606270809.JAA08225@wrath.parallax.co.uk>
References: <199606270809.JAA08225@wrath.parallax.co.uk>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Andy" == Andy Piper <andyp@parallax.co.uk> writes:

Andy> You are, of course, right; I should know better than to argue with the
Andy> man from Sun ;)

Well, actually, I've never used Sparcworks.  If the menu comes up, I
figure it's working.  I rely on the beta testers to tell me if the
current functionality is ever broken.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 02:59:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA18605 for xemacs-beta-people; Thu, 27 Jun 1996 02:59:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA18602 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 02:59:25 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA18116 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 02:59:23 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id AAA00917; Thu, 27 Jun 1996 00:58:56 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id AAA11764; Thu, 27 Jun 1996 00:58:55 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA00877; Thu, 27 Jun 1996 00:58:53 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA22164; Thu, 27 Jun 1996 00:58:49 -0700
Date: Thu, 27 Jun 1996 00:58:49 -0700
Message-Id: <199606270758.AAA22164@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: andyp@parallax.co.uk (Andy Piper)
Cc: xemacs-beta@xemacs.org, rickc@lehman.com
Subject: Re: SunOS Sparworks crashes
In-Reply-To: <199606270740.IAA05796@wrath.parallax.co.uk>
References: <199606270740.IAA05796@wrath.parallax.co.uk>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Andy" == Andy Piper <andyp@parallax.co.uk> writes:

>> Date: Wed, 26 Jun 1996 16:07:40 -0400
>> 
>> Users at my site have experienced both of the crashes reported here
>> recently:
>> - xemacs -q crashes complaining about nil nnot being stringp.  So
>> far, only one user has seen this.

This is the problem I just posted a patch for.

Andy> This is the duff supro-init code I have reported. Martin still hasn't given
Andy> a good reason why it doesn't check for sparcworks - given that is what
Andy> most people have ;)

But Andy, doesn't sunpro-init.el check for sparcworks later on in the
file?

This is the way it works for me:
If `workshop' is not installed, but `sparcworks' is, then you get a
Sparcworks menu show up in the menubar, just like 19.13.

Doesn't it work that way for you?

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 03:05:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA18701 for xemacs-beta-people; Thu, 27 Jun 1996 03:05:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA18698 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 03:05:12 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA19483 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 03:05:12 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id JAA21950; Thu, 27 Jun 1996 09:06:28 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id JAA28363; Thu, 27 Jun 1996 09:06:10 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id JAA08225; Thu, 27 Jun 1996 09:09:39 +0100
Date: Thu, 27 Jun 1996 09:09:39 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606270809.JAA08225@wrath.parallax.co.uk>
To: mrb@eng.sun.com
Subject: Re: SunOS Sparworks crashes
Cc: xemacs-beta@cs.uiuc.edu
X-Sun-Charset: US-ASCII


> >>>>> "Andy" == Andy Piper <andyp@parallax.co.uk> writes:
> 
> >> Date: Wed, 26 Jun 1996 16:07:40 -0400
> >> 
> >> Users at my site have experienced both of the crashes reported here
> >> recently:
> >> - xemacs -q crashes complaining about nil nnot being stringp.  So
> >> far, only one user has seen this.
> 
> This is the problem I just posted a patch for.
> 
> Andy> This is the duff supro-init code I have reported. Martin still hasn't given
> Andy> a good reason why it doesn't check for sparcworks - given that is what
> Andy> most people have ;)
> 
> But Andy, doesn't sunpro-init.el check for sparcworks later on in the
> file?
> 
> This is the way it works for me:
> If `workshop' is not installed, but `sparcworks' is, then you get a
> Sparcworks menu show up in the menubar, just like 19.13.
> 
> Doesn't it work that way for you?

You are, of course, right; I should know better than to argue with the
man from Sun ;)

andy

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 02:44:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA18581 for xemacs-beta-people; Thu, 27 Jun 1996 02:44:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA18578 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 02:44:36 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA18064 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 02:44:34 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA21453; Thu, 27 Jun 1996 00:36:11 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA25880; Thu, 27 Jun 1996 09:36:00 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA26977; Thu, 27 Jun 1996 09:35:55 +0200
Date: Thu, 27 Jun 1996 09:35:55 +0200
Message-Id: <9606270735.AA26977@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: filedesc_to_what_closure dumps reappear in 19.14
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

I got another filedesc_to_what_closure dump under 19.14 in a tty.
It's not easily reproducible, but it seems to have something to do with
subprocess interaction.  In this particular case, I had been running vm,
and then quit.  While editing a file, I did M-x shell and got the dump.
I've gotten a couple of these when doing M-x shell.

        Steve


Fatal error: assertion failed, file event-Xt.c, line 1545, !filedesc_to_what_closure[fd]

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

[...]

Abort (core dumped)


% dbx /usr/local/xemacs/bin/xemacs-19.14 core
dbx version 3.11.8
Type 'help' for help.
Core file created by program "xemacs-19.14"

signal IOT/Abort trap at >*[__kill, 0x3ff8010ce68] 	beq	r19, 0x3ff8010ce80
(dbx) where
>  0 __kill(0x1200868a4, 0x6, 0x14042f630, 0x0, 0x14047b0081) [0x3ff8010ce68]
   1 fatal_error_signal(sig = 1403) ["emacs.c":193, 0x1200868c0]
   2 __kill(0x3ffc00802f0, 0x59, 0x0, 0x0, 0x0) [0x3ff8010ce64]
   3 raise(0x6, 0x0, 0x2, 0x11fffbfe8, 0x59) [0x3ff80121830]
   4 abort(0x7c04, 0x3ff800e0ca8, 0x59, 0x120086800, 0x0) [0x3ff8010fc80]
   5 assert_failed(file = 0x57b, line = 6, expr = 0x11fffc5d8 = "") ["emacs.c":1830, 0x120088f2c]
   6 emacs_Xt_select_process(p = 0x1407652000) ["event-Xt.c":1612, 0x12016eba4]
   7 event_stream_select_process(proc = 0x57b) ["event-stream.c":545, 0x12009ebc0]
   8 create_process(process = (...), new_argv = 0x11fffc720, current_dir = 0x1409f7020 = "/usr/users/carney/xemacs") ["process.c":1044, 0x120114b34]
   9 Fstart_process_internal(nargs = 5, args = 0x11fffc938) ["process.c":1221, 0x120115064]
  10 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fffc930) ["eval.c":3191, 0x1200914c0]
  11 Fapply(nargs = 5, args = 0x11fffcad8) ["eval.c":3471, 0x1200922e0]
  12 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fffcad0) ["eval.c":3191, 0x1200914c0]
  13 Ffuncall(nargs = 6, args = 0x11fffc5d8) ["eval.c":3253, 0x1200917e4]
  14 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x1200611bc]
  15 funcall_lambda(fun = (...), nargs = 5, arg_vector = 0x11fffd048) ["eval.c":3636, 0x120092ff4]
  16 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fffd040) ["eval.c":3223, 0x120091708]
  17 Ffuncall(nargs = 6, args = 0x11fffc5d8) ["eval.c":3253, 0x1200917e4]
  18 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x1200611bc]
  19 funcall_lambda(fun = (...), nargs = 3, arg_vector = 0x11fffd5d0) ["eval.c":3636, 0x120092ff4]
  20 funcall_recording_as(recorded_as = (...), nargs = 3, args = 0x11fffd5c8) ["eval.c":3223, 0x120091708]
  21 Ffuncall(nargs = 6, args = 0x11fffc5d8) ["eval.c":3253, 0x1200917e4]
  22 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x1200611bc]
  23 funcall_lambda(fun = (...), nargs = 2, arg_vector = 0x11fffdb50) ["eval.c":3636, 0x120092ff4]
  24 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffdb48) ["eval.c":3223, 0x120091708]
  25 Ffuncall(nargs = 6, args = 0x11fffc5d8) ["eval.c":3253, 0x1200917e4]
  26 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x1200611bc]
  27 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffe158) ["eval.c":3636, 0x120092ff4]
  28 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffe150) ["eval.c":3223, 0x120091708]
  29 Fapply(nargs = 2, args = 0x11fffe150) ["eval.c":3414, 0x1200920f8]
  30 apply1(fn = (...), arg = (...)) ["eval.c":3968, 0x1200939b8]
  31 Fcall_interactively(function = (...), record_flag = (...), keys = (...)) ["callint.c":389, 0x1200635bc]
  32 Fcommand_execute(cmd = (...), record = (...), keys = (...)) ["eval.c":2628, 0x12008fa84]
  33 primitive_funcall(fn = 0x3ff8012d8b0, nargs = 536856024, args = (nil)) ["eval.c":3488, 0x1200923d0]
  34 funcall_subr(subr = 0x6, args = 0x11fffc5d8) ["eval.c":3526, 0x1200926a8]
  35 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffe590) ["eval.c":3204, 0x120091544]
  36 Ffuncall(nargs = 6, args = 0x11fffc5d8) ["eval.c":3253, 0x1200917e4]
  37 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x1200611bc]
  38 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffeb30) ["eval.c":3636, 0x120092ff4]
  39 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffeb28) ["eval.c":3223, 0x120091708]
  40 Ffuncall(nargs = 6, args = 0x11fffc5d8) ["eval.c":3253, 0x1200917e4]
  41 Fcall_interactively(function = (...), record_flag = (...), keys = (...)) ["callint.c":896, 0x12006515c]
  42 Fcommand_execute(cmd = (...), record = (...), keys = (...)) ["eval.c":2628, 0x12008fa84]
  43 execute_command_event(command_builder = 0x140538800, event = (...)) ["event-stream.c":3480, 0x1200a4804]
  44 Fdispatch_event(event = (...)) ["event-stream.c":3765, 0x1200a52c8]
  45 Fcommand_loop_1() ["cmdloop.c":542, 0x120069944]
  46 command_loop_1(dummy = (...)) ["cmdloop.c":462, 0x120069684]
  47 condition_case_1(handlers = (...), bfun = 0x120069648, barg = (...), hfun = 0x120069ba0, harg = (...)) ["eval.c":1672, 0x12008c300]
  48 command_loop_2(dummy = (...)) ["cmdloop.c":235, 0x120069d7c]
  49 internal_catch(tag = (...), func = 0x11fffc5d8, arg = (...), threw = (nil)) ["eval.c":1347, 0x12008bf2c]
  50 initial_command_loop(load_me = (...)) ["cmdloop.c":273, 0x120069194]
  51 Frunning_temacs_p() ["emacs.c":1317, 0x1200881c4]
(dbx) 

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 03:37:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA22252 for xemacs-beta-people; Thu, 27 Jun 1996 03:37:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA22249 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 03:37:38 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA19786 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 03:37:38 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id BAA06245; Thu, 27 Jun 1996 01:37:08 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id BAA12898; Thu, 27 Jun 1996 01:37:06 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA01143; Thu, 27 Jun 1996 01:37:05 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id BAA22237; Thu, 27 Jun 1996 01:37:01 -0700
Date: Thu, 27 Jun 1996 01:37:01 -0700
Message-Id: <199606270837.BAA22237@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: Crashes on exiting XEmacs
Reply-To: Martin Buchholz <mrb@eng.sun.com>

The crash when exiting XEmacs works like this:

If you build on (Solaris 2.5) X11R5, but run on (Solaris 2.6) X11R6,
then xemacs crashes in tt_close() in this code in shut_down_emacs():


#ifdef TOOLTALK
  tt_session_quit (tt_default_session ());
  tt_close ();
#endif


This seems to be just a bug in tt_close() in X11R6. One obvious
workaround attempt is to comment out the call to tt_close().

Any other suggestions?

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 03:57:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA22549 for xemacs-beta-people; Thu, 27 Jun 1996 03:57:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA22546 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 03:57:18 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA20025 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 03:56:52 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id JAA24399 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 09:58:03 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id JAA29930 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 09:57:45 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id KAA09932; Thu, 27 Jun 1996 10:01:13 +0100
Date: Thu, 27 Jun 1996 10:01:13 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606270901.KAA09932@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: saveconf fix
X-Sun-Charset: US-ASCII

This patch prevents saveconf from restoring empty buffers or prompting to
create directories that don't exist.

andy

*** /tmp/saveconf.el	Thu Jun 27 09:30:14 1996
--- /tmp/myconf.el	Thu Jun 27 09:30:14 1996
***************
*** 269,276 ****
  	;; Recover buffer contexts, if any.
  	;;
  	(while (setq sexpr (read context-buffer))
! 	  (set-buffer (find-file-noselect sexpr))
! 	  (goto-char (read context-buffer)))
  	(bury-buffer "*scratch*")
  	(kill-buffer context-buffer)
  	t )
--- 269,278 ----
  	;; Recover buffer contexts, if any.
  	;;
  	(while (setq sexpr (read context-buffer))
! 	  (set-buffer (find-file-noselect sexpr t))
! 	  (if (zerop (buffer-size))
! 	      (kill-buffer (current-buffer))
! 	    (goto-char (read context-buffer))))
  	(bury-buffer "*scratch*")
  	(kill-buffer context-buffer)
  	t )


From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 05:47:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA23315 for xemacs-beta-people; Thu, 27 Jun 1996 05:47:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA23312 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 05:47:20 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA18665 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 05:47:16 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id GAA01377; Thu, 27 Jun 1996 06:47:11 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp001369; Thu Jun 27 06:46:49 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA25086; Thu, 27 Jun 96 06:46:47 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA21601; Thu, 27 Jun 96 06:46:46 EDT
Message-Id: <9606271046.AA21601@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: The joke that kills.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: SunOS with Sparcworks gripe 
In-Reply-To: Your message of "Wed, 26 Jun 1996 16:12:55 PDT."
             <199606262312.QAA19568@xemacs.eng.sun.com> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMdJmj1tTztlqB385AQHHPAP+KYMs9nYfq/MQZdqnbIG5H+bZZzC98cbw
	      vyml4cMLb2Oi9fKFfNp85hwm1GYiNPl0bv6cpFSUuJ5x82xqUj2vG/TSpdxTgvZ6
	      1gkqWTncE6TJwN0xEZkthadh15QYmf9dASJHGYVkZm/Yarttf/mmCxHvH3fmyIaK
	      jxCr8nxPo28=
	      =YmID
Date: Thu, 27 Jun 1996 06:46:45 -0400
Sender: rickc@lehman.com

    Date: Wed, 26 Jun 1996 16:12:55 -0700
    From: Martin Buchholz <mrb@Eng.Sun.COM>
    
    >>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:
    
    Rick> As with 19.13, the Sparcworks support make s arbitrary changes in use
    Rick> preferences.  Specifically, it makes the bar-cursor the default and
    Rick> turns on pending delete.
    
    More like textedit?

Less like XEmacs.
    
    Rick> I believe that this makes sparcworks configurations
    Rick> different from all other XEmacs configurations in a way that
    Rick> can be quite confusing to the unsuspecting.
    
    Rick> Really, the sparcworks code should leave this stuff alone.
    
    I tend to agree, but this is a historical thing.

No, it's current.  Grab every prebuilt binary.  Start them all up.
All but two will have the block cursor and no pending delete.

These are user level customizations.  Having arbitrarily different
defaults based on whether or not you have a particular package loaded
is really a Bad Thing.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 05:59:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA23433 for xemacs-beta-people; Thu, 27 Jun 1996 05:59:41 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA23430 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 05:59:40 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA18699 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 05:59:37 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id GAA01683 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 06:59:39 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp001658; Thu Jun 27 06:59:20 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA25687; Thu, 27 Jun 96 06:59:19 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA21896; Thu, 27 Jun 96 06:59:18 EDT
Message-Id: <9606271059.AA21896@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Putting new limits on productivity.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Linux aout binaries?
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMdJpf1tTztlqB385AQGZwAP/UBuL4XcmEXx3zutjct2KUxFZUHjoL0Eh
	      SVD6ZgnoFLdjeZxXcXh0wvkf3MCJZjE1wsvQxCHbXjNXW4FdNG21RTXIK7pO5t0c
	      Va8i/SMJuhSDxIAiqDqBBhPBhI2lrFrLOQS8+FsUDAZ0J3OiZbNocV2xp0GDTRsY
	      2nKJFUYnKMQ=
	      =hF1U
Date: Thu, 27 Jun 1996 06:59:17 -0400
Sender: rickc@lehman.com

My Linux box is too wimpy to build XEmacs and I still haven't gotten
around to picking up ELF support.

I thought I saw earlier that there would be aout binaries for Linux,
but they don't seem to be there.  Is this just a delay or did I miss a
decision not to distribute them?

			Rick

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 05:59:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA23428 for xemacs-beta-people; Thu, 27 Jun 1996 05:59:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA23425 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 05:59:18 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA22827 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 05:59:20 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id DAA22890; Thu, 27 Jun 1996 03:58:49 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id DAA16664; Thu, 27 Jun 1996 03:58:46 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA02078; Thu, 27 Jun 1996 03:58:45 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id DAA25443; Thu, 27 Jun 1996 03:58:41 -0700
Date: Thu, 27 Jun 1996 03:58:41 -0700
Message-Id: <199606271058.DAA25443@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Rick Campbell <rickc@lehman.com>
Cc: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: Re: SunOS with Sparcworks gripe 
In-Reply-To: <9606271046.AA21601@cfdevx1.lehman.com>
References: <199606262312.QAA19568@xemacs.eng.sun.com>
	<9606271046.AA21601@cfdevx1.lehman.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:

Rick>     More like textedit?

Rick> Less like XEmacs.
    
Rick> I believe that this makes sparcworks configurations
Rick> different from all other XEmacs configurations in a way that
Rick> can be quite confusing to the unsuspecting.
    
Rick> Really, the sparcworks code should leave this stuff alone.
    
Rick>     I tend to agree, but this is a historical thing.

Rick> No, it's current.  Grab every prebuilt binary.  Start them all up.
Rick> All but two will have the block cursor and no pending delete.

I realize this is still the current behavior.  But the *reasons* are
historical.

Rick> These are user level customizations.  Having arbitrarily different
Rick> defaults based on whether or not you have a particular package loaded
Rick> is really a Bad Thing.

I guess the original idea was that --with-sparcworks gave you XEmacs
the `Sun Way'.  Sun ships it this way to customers on the Developers
Products CD.  One could certainly argue that there should be a
separation of style and functionality, but who wants yet another
configure-time option?

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 06:04:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA23477 for xemacs-beta-people; Thu, 27 Jun 1996 06:04:33 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA23474 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 06:04:31 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA22939 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 06:04:29 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id HAA01769; Thu, 27 Jun 1996 07:04:09 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp001761; Thu Jun 27 07:03:58 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA25963; Thu, 27 Jun 96 07:03:57 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA22028; Thu, 27 Jun 96 07:03:56 EDT
Message-Id: <9606271103.AA22028@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Never had it, never will.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: Re: SunOS with Sparcworks gripe 
In-Reply-To: Your message of "Thu, 27 Jun 1996 03:58:41 PDT."
             <199606271058.DAA25443@xemacs.eng.sun.com> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMdJqk1tTztlqB385AQGayQQAiPDlfDHgGYfP6F2sp7VjHCc0TAbLkfzP
	      kwARHapc/3yL98SjVQ6YggBJjIy6PyA68lySzyiFAIJBu8NkKprakxzNVCxSeGr3
	      ADzu3MH0LQM68XORKaWjWgUTX88iHHp2A6KgITInJhE08uGkPSDViI+lzZ2tG0AK
	      3Igak78HuPw=
	      =LGe8
Date: Thu, 27 Jun 1996 07:03:55 -0400
Sender: rickc@lehman.com

    Date: Thu, 27 Jun 1996 03:58:41 -0700
    From: Martin Buchholz <mrb@Eng.Sun.COM>

    One could certainly argue that there should be a separation of
    style and functionality, but who wants yet another configure-time
    option?

But we're talking about what should be run-time options.  If Sun wants
to provide XEmacs the Sun way, the correct implementation is a
recommended site-init file.

As it is, with these binaries, and only with these binaries, users
have to load in extra code at run-time in order to turn off
pending-delete, something that is, historically, very much *not* the
emacs way.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 07:03:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA23810 for xemacs-beta-people; Thu, 27 Jun 1996 07:03:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA23807 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 07:03:25 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA18937 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 07:03:19 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id HAA06239; Thu, 27 Jun 1996 07:02:50 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id HAA21729; Thu, 27 Jun 1996 07:02:49 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id HAA27211; Thu, 27 Jun 1996 07:58:09 -0400
To: Mark Borges <mdb@cdc.noaa.gov>
cc: XEmacs beta-list <xemacs-beta@xemacs.org>
References: <vkhgry1b0f.fsf@cdc.noaa.gov> 
Subject: Re: [comp.emacs.xemacs] Minor bug deleting frames with 19.14, linux, fvwm 
In-reply-to: (Your message of 26 Jun 1996 16:00:32 MDT.)
             <vkhgry1b0f.fsf@cdc.noaa.gov> 
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 27 Jun 1996 07:58:12 -0400
Message-ID: <5791.835876692@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


    mb> This happens using solaris-2.5/fvwm2.0.42 as well.

But not to me.  The window goes away immediately.  (Solaris 2.5,
fvwm2.0.42).  Weird.

Ray

    mb> ------- Start of forwarded message -------
    mb> From: ogre@atomic.com (Joe Rumsey)
    mb> Newsgroups: comp.emacs.xemacs
    mb> Subject: Minor bug deleting frames with 19.14, linux, fvwm
    mb> Date: 26 Jun 1996 21:13:40 GMT
    mb> Organization: Atomic Games
    mb> Message-ID: <slrn4t3a0m.39r.ogre@earth.atomic.com>

    mb>   Using the precompiled linuxelf-athena binary under linux 2.0 and
    mb> fvwm2, I've found that often when I send a WM delete command to an
    mb> XEmacs 19.14 frame, the frame won't go away until emacs receives a
    mb> keyboard event (in that frame or any other).  Doesn't happen every
    mb> time, but it does work that way most of the time.

    mb>   Not a big deal, just annoying.

-- 
   /\ /\
   \_\_/                    Joe Rumsey
At(__o/_)mic Games        ogre@atomic.com
   / / \            http://www.atomic.com/~ogre/
   \/ \/

------- End of forwarded message -------

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 08:06:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA24241 for xemacs-beta-people; Thu, 27 Jun 1996 08:06:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA24238 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 08:06:25 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA27555 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 08:06:26 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA26509; Thu, 27 Jun 1996 08:05:36 -0500 (CDT)
Message-Id: <199606271305.IAA26509@charles.cs.uiuc.edu>
To: Martin Buchholz <mrb@eng.sun.com>
cc: Rick Campbell <rickc@lehman.com>,
        XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: Re: SunOS with Sparcworks gripe 
In-reply-to: Your message of "Thu, 27 Jun 1996 03:58:41 PDT."
             <199606271058.DAA25443@xemacs.eng.sun.com> 
Date: Thu, 27 Jun 1996 08:05:36 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Martin> I guess the original idea was that --with-sparcworks gave
    Martin> you XEmacs the `Sun Way'.  Sun ships it this way to
    Martin> customers on the Developers Products CD.  One could
    Martin> certainly argue that there should be a separation of style
    Martin> and functionality, but who wants yet another
    Martin> configure-time option?

I do.  The extra changes annoy me enough that I don't use the
--with-sparcworks flag even though I use SPARCworks heavily.  I've
always hated the fact that it made both style and functionality
changes.  I wasn't in a position to do anything about it because Sun
was paying me salary.  Now I just don't have the time :-)



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 07:55:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA24181 for xemacs-beta-people; Thu, 27 Jun 1996 07:55:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA24178 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 07:55:38 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA24080 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 07:55:40 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA26486; Thu, 27 Jun 1996 07:54:57 -0500 (CDT)
Message-Id: <199606271254.HAA26486@charles.cs.uiuc.edu>
To: Martin Buchholz <mrb@eng.sun.com>
cc: andyp@parallax.co.uk (Andy Piper), Peter Cheng <phc@eng.sun.com>,
        xemacs-beta@cs.uiuc.edu
Subject: Re: sunpro-startup? 
In-reply-to: Your message of "Wed, 26 Jun 1996 22:55:00 PDT."
             <199606270555.WAA21349@xemacs.eng.sun.com> 
Date: Thu, 27 Jun 1996 07:54:57 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Martin> Chuck, I think we ought to put out a patch version of
    Martin> 19.14 sometime.

No way.  I am considering making 19.15 a bug-fix only release with
absolutely no new features and putting it out within a month or two,
though.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 08:45:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA24573 for xemacs-beta-people; Thu, 27 Jun 1996 08:45:07 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA24570 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 08:45:06 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA00281; Thu, 27 Jun 1996 08:45:07 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa07324;
          27 Jun 96 9:42 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id JAA06768; Thu, 27 Jun 1996 09:42:38 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id JAA24899; Thu, 27 Jun 1996 09:42:37 -0400
Date: Thu, 27 Jun 1996 09:42:37 -0400
Message-Id: <199606271342.JAA24899@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: Martin Buchholz <mrb@eng.sun.com>, Andy Piper <andyp@parallax.co.uk>,
        Peter Cheng <phc@eng.sun.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: sunpro-startup? 
References: <199606270555.WAA21349@xemacs.eng.sun.com>
	<199606271254.HAA26486@charles.cs.uiuc.edu>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Listen to the quiet voice
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "CT" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

    CT> No way.  I am considering making 19.15 a bug-fix only release
    CT> with absolutely no new features and putting it out within a
    CT> month or two, though.

That sounds like a good idea.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 09:52:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA24893 for xemacs-beta-people; Thu, 27 Jun 1996 09:52:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA24890 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 09:52:44 -0500 (CDT)
Received: from monolith.spry.com (monolith.spry.com [198.185.2.198]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA01396 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 09:52:45 -0500 (CDT)
Received: (from wmperry@localhost) by monolith.spry.com (8.7.4/8.7.3) id IAA00300; Thu, 27 Jun 1996 08:01:53 -0700
Date: Thu, 27 Jun 1996 08:01:53 -0700
Message-Id: <199606271501.IAA00300@monolith.spry.com>
From: William Perry <wmperry@monolith.spry.com>
To: xemacs-beta@cs.uiuc.edu
Errors-to: wmperry@spry.com
Reply-to: wmperry@spry.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;
Subject: forwarded message from Colin Rafferty
Comments: Hyperbole mail buttons accepted, v04.01.

What a way to start the day!!! Whoo hoo. :)  Sorry, had to share this with
you, I got a good chuckle out of it.

-Bill P.
------- start of forwarded message (RFC 934 encapsulation) -------
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by homer.spry.com (8.6.9/8.6.9) with ESMTP id HAA17482 for <wmperry@spry.com>; Thu, 27 Jun 1996 07:20:54 -0700
Received: from mlfire.ml.com (mlfire.ml.com [192.246.100.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <QAA00540@ifi.uio.no> for <ding@ifi.uio.no> ; Thu, 27 Jun 1996 16:14:15 +0200
Received: from commpost.ml.com ([146.125.4.24]) by mlfire.ml.com (8.7.5/8.7.3/MLgw-2.05) with SMTP id KAA10868 for <ding@ifi.uio.no>; Thu, 27 Jun 1996 10:18:16 -0400 (EDT)
Received: from spssunp.spspme.ml.com (spssunp.spspme.ml.com [192.168.111.13]) by commpost.ml.com (8.6.12/8.6.12) with ESMTP id KAA22029 for <ding@ifi.uio.no>; Thu, 27 Jun 1996 10:17:06 -0400 (EST)
Received: by spssunp.spspme.ml.com (SMI-8.6/SMI-4.1)
	id KAA15352; Thu, 27 Jun 1996 10:13:42 -0400
References: <ycqn31p9akx.fsf@lola-granola.MIT.EDU>
Reply-To: Colin Rafferty <craffert@ml.com>
X-Face: y,o:AU/bfCrS+zS/W"^puB!rT!G7?U1Mvp1Hd{6h^>X4@Xp5,|g+rG>4gv/iy^&x9`k#s!]X~{]Js>@A4c}4Z"Ct7=#1nPS:?mrWH8c#>$)>/Wc5yuX_OFO1(4cZM{LvsKWVQSl~/i>!n[-B*i-alq[/m\bsdy;W4p(_ic;$BE.oG@eJf@sr#x#}FT<=H8Ozu%g;JpVz:v_~vt[>ef/MeNeo3~D^R]]*bB7{HB|E1$wfMzw
X-Y-Zippy: Yow!  Is this sexual intercourse yet??  Is it, huh, is it??
In-Reply-To: Greg Stark's message of 26 Jun 1996 23:42:38 -0400
Message-ID: <ocrk9wt49nu.fsf@spssunp.spspme.ml.com>
Lines: 12
X-Mailer: Gnus v5.2.25/XEmacs 19.14
From: Colin Rafferty <craffert@spspme.ml.com>
To: (ding) GNUS Mailing List <ding@ifi.uio.no>
Subject: Re: smileys on fsf emacs
Date: 27 Jun 1996 10:13:41 -0400

Greg Stark writes:

> [ long explanation of how to hack FSF Emacs to do smileys (a simple
>   process under XEmacs) ]

> PS I know RMS doesn't like the term ``FSF Emacs''
>    but i can't imagine what else to call it.

How about obsolete?

- -- 
Colin
------- end -------

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 10:14:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA25199 for xemacs-beta-people; Thu, 27 Jun 1996 10:14:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA25195 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 10:14:35 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA19825 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 10:14:32 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id JAA29338; Thu, 27 Jun 1996 09:14:33 -0600
Received: by suomi (SMI-8.6) id JAA15715; Thu, 27 Jun 1996 09:14:31 -0600
Sender: mdb@cdc.noaa.gov
To: Raymond Toy <toy@rtp.ericsson.se>
Cc: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: Re: [comp.emacs.xemacs] Minor bug deleting frames with 19.14, linux, fvwm
References: <vkhgry1b0f.fsf@cdc.noaa.gov> <5791.835876692@rtp.ericsson.se>
Organization: CIRES, University of Colorado
X-Attribution: mb
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 27 Jun 1996 09:14:30 -0600
In-Reply-To: Raymond Toy's message of Thu, 27 Jun 1996 07:58:12 -0400
Message-ID: <vkd92l1dpl.fsf@cdc.noaa.gov>
Lines: 45
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>> On Thu, 27 Jun 1996 07:58:12 -0400,
>> Raymond Toy(RT) wrote:
mb> This happens using solaris-2.5/fvwm2.0.42 as well.

RT> But not to me.  The window goes away immediately.  (Solaris 2.5,
RT> fvwm2.0.42).  Weird.

X11R? Mine is X11R6.1.

Just to be concrete:

$ ldd `which xemacs`
        libtt.so.2 =>    /usr/dt/lib/libtt.so.2
        libce.so.0 =>    /usr/openwin/lib/libce.so.0
        libXaw.so.6.1 =>         /usr/X11R6/lib/libXaw.so.6.1
        libXpm.so.4.7 =>         /usr/X11R6/lib/libXpm.so.4.7
        libXmu.so.6.0 =>         /usr/X11R6/lib/libXmu.so.6.0
        libXt.so.6.0 =>  /usr/X11R6/lib/libXt.so.6.0
        libSM.so.6.0 =>  /usr/X11R6/lib/libSM.so.6.0
        libICE.so.6.0 =>         /usr/X11R6/lib/libICE.so.6.0
        libw.so.1 =>     /usr/lib/libw.so.1
        libXext.so.6.1 =>        /usr/X11R6/lib/libXext.so.6.1
        libX11.so.6.1 =>         /usr/X11R6/lib/libX11.so.6.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libkvm.so.1 =>   /usr/lib/libkvm.so.1
        libelf.so.1 =>   /usr/lib/libelf.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libintl.so.1 =>  /usr/lib/libintl.so.1
        libmp.so.1 =>    /usr/lib/libmp.so.1

$ ldd `which fvwm`
        libXpm.so.4.7 =>         /usr/X11R6/lib/libXpm.so.4.7
        libXext.so.6.1 =>        /usr/X11R6/lib/libXext.so.6.1
        libX11.so.6.1 =>         /usr/X11R6/lib/libX11.so.6.1
        libICE.so.6.0 =>         /usr/X11R6/lib/libICE.so.6.0
        libSM.so.6.0 =>  /usr/X11R6/lib/libSM.so.6.0
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libintl.so.1 =>  /usr/lib/libintl.so.1
        libmp.so.1 =>    /usr/lib/libmp.so.1
        libw.so.1 =>     /usr/lib/libw.so.1

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 10:50:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA25389 for xemacs-beta-people; Thu, 27 Jun 1996 10:50:50 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA25386 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 10:50:49 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA02751 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 10:50:50 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id JAA04263; Thu, 27 Jun 1996 09:50:19 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id JAA18789; Thu, 27 Jun 1996 09:50:17 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id JAA01579; Thu, 27 Jun 1996 09:49:52 -0600
Date: Thu, 27 Jun 1996 09:49:52 -0600
Message-Id: <199606271549.JAA01579@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: wmperry@spry.com
Cc: xemacs-beta@cs.uiuc.edu, Lally@lanl.gov, Dbk@lanl.gov, Robert@ferrell.com,
        Hall@lanl.gov, Srlee@lanl.gov, Henkel@lanl.gov
Subject: Re: forwarded message from Colin Rafferty
In-Reply-To: <199606271501.IAA00300@monolith.spry.com>
References: <199606271501.IAA00300@monolith.spry.com>
Reply-To: turner@lanl.gov

William Perry writes:
 > What a way to start the day!!! Whoo hoo. :)  Sorry, had to share this with
 > you, I got a good chuckle out of it.
 > 
 > -Bill P.
 > ------- start of forwarded message (RFC 934 encapsulation) -------
 > 
 > Greg Stark writes:
 > 
 > > [ long explanation of how to hack FSF Emacs to do smileys (a simple
 > >   process under XEmacs) ]
 > 
 > > PS I know RMS doesn't like the term ``FSF Emacs''
 > >    but i can't imagine what else to call it.
 > 
 > How about obsolete?
 > 
 > ------- end -------

Sounds like a plan.  ObsEmacs it is...

-John

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 10:53:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA25438 for xemacs-beta-people; Thu, 27 Jun 1996 10:53:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA25435 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 10:53:28 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA20030 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 10:53:25 -0500 (CDT)
Received: from mr2.exu.ericsson.se (mr2.exu.ericsson.com [138.85.147.12]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id KAA14263; Thu, 27 Jun 1996 10:52:50 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr2.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id KAA25502; Thu, 27 Jun 1996 10:52:49 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id LAA29658; Thu, 27 Jun 1996 11:48:09 -0400
To: Mark Borges <mdb@cdc.noaa.gov>
cc: XEmacs beta-list <xemacs-beta@xemacs.org>
References: <vkhgry1b0f.fsf@cdc.noaa.gov> <5791.835876692@rtp.ericsson.se>  <vkd92l1dpl.fsf@cdc.noaa.gov> 
Subject: Re: [comp.emacs.xemacs] Minor bug deleting frames with 19.14, linux, fvwm 
In-reply-to: (Your message of 27 Jun 1996 09:14:30 MDT.)
             <vkd92l1dpl.fsf@cdc.noaa.gov> 
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 27 Jun 1996 11:48:11 -0400
Message-ID: <6026.835890491@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "mb" == Mark Borges <mdb@cdc.noaa.gov> writes:



    mb> X11R? Mine is X11R6.1.

Same.

    mb> Just to be concrete:

    mb> $ ldd `which xemacs`
    mb>         libtt.so.2 =>    /usr/dt/lib/libtt.so.2
    mb>         libce.so.0 =>    /usr/openwin/lib/libce.so.0
    mb>         libXaw.so.6.1 =>         /usr/X11R6/lib/libXaw.so.6.1
    mb>         libXpm.so.4.7 =>         /usr/X11R6/lib/libXpm.so.4.7
    mb>         libXmu.so.6.0 =>         /usr/X11R6/lib/libXmu.so.6.0
    mb>         libXt.so.6.0 =>  /usr/X11R6/lib/libXt.so.6.0
    mb>         libSM.so.6.0 =>  /usr/X11R6/lib/libSM.so.6.0
    mb>         libICE.so.6.0 =>         /usr/X11R6/lib/libICE.so.6.0
    mb>         libw.so.1 =>     /usr/lib/libw.so.1
    mb>         libXext.so.6.1 =>        /usr/X11R6/lib/libXext.so.6.1
    mb>         libX11.so.6.1 =>         /usr/X11R6/lib/libX11.so.6.1
    mb>         libsocket.so.1 =>        /usr/lib/libsocket.so.1
    mb>         libnsl.so.1 =>   /usr/lib/libnsl.so.1
    mb>         libkvm.so.1 =>   /usr/lib/libkvm.so.1
    mb>         libelf.so.1 =>   /usr/lib/libelf.so.1
    mb>         libdl.so.1 =>    /usr/lib/libdl.so.1
    mb>         libc.so.1 =>     /usr/lib/libc.so.1
    mb>         libintl.so.1 =>  /usr/lib/libintl.so.1
    mb>         libmp.so.1 =>    /usr/lib/libmp.so.1

I get
        libaudio.so.2.3 =>       /apps/public/solaris2.5/X11R6.1/lib/libaudio.so.2.3
        libtt.so.2 =>    /usr/openwin/lib/libtt.so.2
        libce.so.0 =>    /usr/openwin/lib/libce.so.0
        libXaw.so.6.1 =>         /apps/public/solaris2.5/X11/lib/Xaw3d/libXaw.so.6.1
        libXpm.so.4.6 =>         /apps/public/solaris2.5/X11R6.1/lib/libXpm.so.4.6
        libjpeg.so.6.0 =>        /apps/public/solaris2.4/lib/libjpeg.so.6.0
        libXmu.so.6.0 =>         /apps/public/solaris2.5/X11R6.1/lib/libXmu.so.6.0
        libXt.so.6.0 =>  /apps/public/solaris2.5/X11R6.1/lib/libXt.so.6.0
        libSM.so.6.0 =>  /apps/public/solaris2.5/X11R6.1/lib/libSM.so.6.0
        libICE.so.6.0 =>         /apps/public/solaris2.5/X11R6.1/lib/libICE.so.6.0
        libw.so.1 =>     /usr/lib/libw.so.1
        libXext.so.6.1 =>        /apps/public/solaris2.5/X11R6.1/lib/libXext.so.6.1
        libX11.so.6.1 =>         /apps/public/solaris2.5/X11R6.1/lib/libX11.so.6.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libkvm.so.1 =>   /usr/lib/libkvm.so.1
        libelf.so.1 =>   /usr/lib/libelf.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libintl.so.1 =>  /usr/lib/libintl.so.1
        libmp.so.1 =>    /usr/lib/libmp.so.1

Looks like the key diffs are 

	Ray				Mark

	/usr/openwin/lib/libtt.so.2	/usr/dt/lib/libtt.so.2
	Xpm 4.6				4.7
	Xaw3d				Xaw
	libjpeg				none
	libaudio (NAS 1.2p4)		none

Same differences for fvwm.

Can't imagine any of these differences causing the problem, though.

Ray

	

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 11:26:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA25668 for xemacs-beta-people; Thu, 27 Jun 1996 11:26:38 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA25665 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 11:26:36 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA05017 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 11:26:36 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id RAA03398 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 17:27:48 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id RAA14567 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 17:27:29 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id RAA27312; Thu, 27 Jun 1996 17:30:56 +0100
Date: Thu, 27 Jun 1996 17:30:56 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606271630.RAA27312@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: annoying market bug
X-Sun-Charset: US-ASCII

Is anyone else seeing this annoying "marker does not point anywhere bug"
in 19.14? I get it quite a lot.

andy

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 11:36:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA25884 for xemacs-beta-people; Thu, 27 Jun 1996 11:36:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA25881 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 11:36:23 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA05341 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 11:36:24 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA27238; Thu, 27 Jun 1996 11:36:09 -0500 (CDT)
Message-Id: <199606271636.LAA27238@charles.cs.uiuc.edu>
To: andyp@parallax.co.uk (Andy Piper)
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: annoying market bug 
In-reply-to: Your message of "Thu, 27 Jun 1996 17:30:56 BST."
             <199606271630.RAA27312@wrath.parallax.co.uk> 
Date: Thu, 27 Jun 1996 11:36:09 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Andy> Is anyone else seeing this annoying "marker does not point
    Andy> anywhere bug" in 19.14? I get it quite a lot.

Do you have line-number-mode turned on?  If so, try turning it off.
I've spent a grand total of 30 seconds looking into this but I
wouldn't be surprised if the answer is to add the following line to
the beginning of real_current_modeline_height in redisplay.c:

  Fset_marker (w->pointm[CMOTION_DISP], w->pointm[CURRENT_DISP], w->buffer);



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 11:44:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA25951 for xemacs-beta-people; Thu, 27 Jun 1996 11:44:18 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA25948 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 11:44:17 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA05566; Thu, 27 Jun 1996 11:44:10 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id RAA03863; Thu, 27 Jun 1996 17:45:32 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id RAA15068; Thu, 27 Jun 1996 17:45:14 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id RAA27540; Thu, 27 Jun 1996 17:48:43 +0100
Date: Thu, 27 Jun 1996 17:48:43 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606271648.RAA27540@wrath.parallax.co.uk>
To: cthomp@cs.uiuc.edu
Subject: Re: annoying market bug
Cc: xemacs-beta@cs.uiuc.edu
X-Sun-Charset: US-ASCII


>     Andy> Is anyone else seeing this annoying "marker does not point
>     Andy> anywhere bug" in 19.14? I get it quite a lot.
> 
> Do you have line-number-mode turned on?  If so, try turning it off.

Yes and I'll try this.

andy

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 17:19:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA28882 for xemacs-beta-people; Thu, 27 Jun 1996 17:19:33 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA28879 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 17:19:31 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA15710 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 17:19:33 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id PAA16522; Thu, 27 Jun 1996 15:18:48 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [comp.emacs.xemacs] Minor bug deleting frames with 19.14, linux, fvwm
References: <vkhgry1b0f.fsf@cdc.noaa.gov>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Mark Borges's message of 26 Jun 1996 16:00:32 -0600
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 27 Jun 1996 15:18:46 -0700
Message-ID: <m2ybl8x54p.fsf@deanna.miranova.com>
Lines: 11
X-Mailer: Gnus v5.2.27/XEmacs 20.0

>>>>> "mb" == Mark Borges <mdb@cdc.noaa.gov> writes:

mb> This happens using solaris-2.5/fvwm2.0.42 as well.

I don't see anything unusual using Linux 2.0/olvwm.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 17:36:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA28976 for xemacs-beta-people; Thu, 27 Jun 1996 17:36:14 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA28973 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 17:36:13 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA16143 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 17:36:15 -0500 (CDT)
Received: from sbkifer.cs.sunysb.edu (sbkifer.cs.sunysb.edu [130.245.1.35]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id SAA02773 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 18:40:22 -0400
Message-Id: <199606272240.SAA02773@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: xemacs-beta@cs.uiuc.edu
Subject: button2 on the mode line
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 27 Jun 1996 18:34:34 -0400
Sender: kifer@cs.sunysb.edu

button2 on the mode line sometimes  causes the error:
    Signalling: (wrong-type-argument integer-or-marker-p nil)
	extent-at(nil #<buffer "*Completions*"> list-mode-item nil at)
	list-mode-item-mouse-selected(#<buttonup-event button2up>)
	call-interactively(list-mode-item-mouse-selected)

I recall this was reported, but don't remember if there was a patch.



	--michael  

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 17:33:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA28962 for xemacs-beta-people; Thu, 27 Jun 1996 17:33:52 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA28959 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 17:33:50 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA16108 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 17:33:48 -0500 (CDT)
Received: from sbkifer.cs.sunysb.edu (sbkifer.cs.sunysb.edu [130.245.1.35]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id SAA02770 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 18:37:50 -0400
Message-Id: <199606272237.SAA02770@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: xemacs-beta@cs.uiuc.edu
Subject: native sound only on console
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 27 Jun 1996 18:32:02 -0400
Sender: kifer@cs.sunysb.edu

native-sound-only-on-console t

doesn't seem to have any effect. xemacs -nw or even xemacs run on a
different machine in an xterm window tries to play sound.
In case of a different machine, it gives me an error that /dev/audio can't
be openeed. Because of this,

(setq native-sound-only-on-console t)
(load-default-sounds)

doesn't work if emacs runs remotedly. Is there a patch for this bug?


	--michael  

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 18:35:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA29593 for xemacs-beta-people; Thu, 27 Jun 1996 18:35:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA29590 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 18:35:15 -0500 (CDT)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA17157 for <xemacs-beta@cs.uiuc.edu>; Thu, 27 Jun 1996 18:35:17 -0500 (CDT)
Received: from fast.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id RAA07293; Thu, 27 Jun 1996 17:34:57 -0600
Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id RAA22350; Thu, 27 Jun 1996 17:34:56 -0600
Date: Thu, 27 Jun 1996 17:34:56 -0600
Message-Id: <199606272334.RAA22350@fast.cs.utah.edu>
From: Eric Eide <eeide@fast.cs.utah.edu>
To: xemacs-beta@cs.uiuc.edu
Subject: Minor Info Documentation Nit --- Missing `TAGS' File

The "Find Tag" node of the XEmacs Info documentation says this:

   Emacs comes with a tag table file `TAGS' (in the directory containing Lisp
   libraries) that includes all the Lisp libraries and all the C sources of
   Emacs.  By specifying this file with `visit-tags-table' and then using `M-.'
   you can quickly look at the source of any Emacs function.

But I can't find any `TAGS' file in the 19.14 distribution.

Eric.

From xemacs-beta-request@cs.uiuc.edu  Thu Jun 27 20:53:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA00378 for xemacs-beta-people; Thu, 27 Jun 1996 20:53:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA00375 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 27 Jun 1996 20:53:01 -0500 (CDT)
Received: from cortex.corpus.uni-muenster.de (news@PPPE133.UNI-MUENSTER.DE [128.176.20.141]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA22335 for <xemacs-beta@xemacs.org>; Thu, 27 Jun 1996 20:52:56 -0500 (CDT)
Received: (from gutschk@localhost) by cortex.corpus.uni-muenster.de (8.6.12/8.6.11) id UAA01991; Thu, 27 Jun 1996 20:04:22 +0200
Sender: gutschk@uni-muenster.de
To: Rick Campbell <rickc@lehman.com>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: Linux aout binaries?
References: <9606271059.AA21896@cfdevx1.lehman.com>
X-Face: +.[`xCMz]E6GW}5ECgY#C"Er6&v$q7:oe+zPlPtOh>/US;9B>;)ro_lpLx9/]q_{u-\YR>r
 P&)Da0gS,PW{@BWSG,PIV)3#J<$Ft_t]qa!xF~'*wuwg-CJj*0:EUr3z}y
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Markus Gutschke <gutschk@uni-muenster.de>
Date: 27 Jun 1996 20:04:21 +0200
In-Reply-To: Rick Campbell's message of Thu, 27 Jun 1996 06:59:17 -0400
Message-ID: <m2loh92key.fsf@cortex.corpus.uni-muenster.de>
Lines: 20
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Rick Campbell <rickc@lehman.com> writes:
> My Linux box is too wimpy to build XEmacs and I still haven't gotten
> around to picking up ELF support.
> 
> I thought I saw earlier that there would be aout binaries for Linux,
> but they don't seem to be there.  Is this just a delay or did I miss a
> decision not to distribute them?

AFAIK it is intended to eventually have a full set of AOUT binaries
for Linux. Unfortunately, so far nobody was able to build
these. Either, because their system is too small (such as yours) or
because they do not have an AOUT development environment (such as me
;-( ). I you really do insist on using a precompiled XEmacs 19.14 for
AOUT, your only solution is using the ALLSTATIC release. This binary
is HUGE, but it requires only few changes to make it run in an AOUT
environment. Have a look at the README file and feel free to contact
me, if you have further questions.


Markus

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 02:42:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA01942 for xemacs-beta-people; Fri, 28 Jun 1996 02:42:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA01939 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 02:42:42 -0500 (CDT)
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA23229 for <xemacs-beta@xemacs.org>; Fri, 28 Jun 1996 02:42:39 -0500 (CDT)
Received: from odin.corp.sgi.com by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO)
	for <@external-mail-relay.sgi.com:xemacs-beta@xemacs.org> id AAA09100; Fri, 28 Jun 1996 00:42:09 -0700
Received: from cardboard.mti.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI)
	for <@fddi-odin.corp.sgi.com:xemacs-beta@xemacs.org> id AAA24028; Fri, 28 Jun 1996 00:42:08 -0700
Received: from litotes.mti.sgi.com by cardboard.mti.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI.AUTO-MTI)
	for <@cardboard.mti.sgi.com:xemacs-beta@xemacs.org> id AAA05238; Fri, 28 Jun 1996 00:42:08 -0700
Received: by litotes.mti.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO)
	 id LAA21543; Fri, 21 Jun 1996 11:33:06 -0700
To: xemacs-beta@xemacs.org
Subject: Re: XEmacs 19.14 pre-release
References: <199606210336.WAA08759@xemacs.cs.uiuc.edu>
From: Rick Braumoeller <rickb@litotes.mti.sgi.com>
Date: 21 Jun 1996 11:33:05 -0700
In-Reply-To: Chuck Thompson's message of Thu, 20 Jun 1996 22:36:13 -0500
Message-ID: <wl7wx11ovml.fsf@litotes.mti.sgi.com>
Lines: 10
X-Mailer: Gnus v5.2.23/XEmacs 19.14

Chuck Thompson <cthomp@xemacs.org> writes:

   Binary Kit Volunteers Needed
   ============================

I'll volunteer to build for Irix 6.2 (and 5.3, if no one else steps
up).

  -- Rick


From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 02:42:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA01947 for xemacs-beta-people; Fri, 28 Jun 1996 02:42:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA01944 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 02:42:43 -0500 (CDT)
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA23228 for <xemacs-beta@xemacs.org>; Fri, 28 Jun 1996 02:42:38 -0500 (CDT)
Received: from odin.corp.sgi.com by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO)
	for <@external-mail-relay.sgi.com:xemacs-beta@xemacs.org> id AAA09098; Fri, 28 Jun 1996 00:42:08 -0700
Received: from cardboard.mti.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI)
	for <@fddi-odin.corp.sgi.com:xemacs-beta@xemacs.org> id AAA24024; Fri, 28 Jun 1996 00:42:08 -0700
Received: from litotes.mti.sgi.com by cardboard.mti.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI.AUTO-MTI)
	for <@cardboard.mti.sgi.com:xemacs-beta@xemacs.org> id AAA05235; Fri, 28 Jun 1996 00:42:07 -0700
Received: by litotes.mti.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO)
	 id LAA21706; Fri, 21 Jun 1996 11:40:42 -0700
Date: Fri, 21 Jun 1996 11:40:42 -0700
Message-Id: <199606211840.LAA21706@litotes.mti.sgi.com>
From: rickb@cardboard.mti.sgi.com (Rick Braumoeller)
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: 19.14-p1 OK on Irix 6.2

Platform: litotes.mti is a 128MB+3.9GB 200MHz Indigo2 R4400 with XL
          graphics, 6.2jun6c.

Configured for `mips-sgi-irix6.2'.

  Where should the build process find the source code?    /x/src/xemacs-19.14-p1
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/irix6-0.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              cc -O2 -mips2 -Olimit 3000
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/people/rickb/lib
  Additional libraries:                                   /usr/people/rickb/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

Looks good so far.

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 08:37:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA07073 for xemacs-beta-people; Fri, 28 Jun 1996 08:37:46 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA07070 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 08:37:45 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA13542 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 08:36:24 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id OAA20245 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 14:38:00 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id OAA07244 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 14:37:41 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id OAA10153; Fri, 28 Jun 1996 14:41:10 +0100
Date: Fri, 28 Jun 1996 14:41:10 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199606281341.OAA10153@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: gnus problems in 19.14
X-Sun-Charset: US-ASCII

hostname on my system yields "wrath"
domainname on my system yields "parallax.co.uk"

system-name under xemacs yields "wrath"
gnus fails to post because it thinks this is a duff name for replying
to (correct), so I set gnus-local-domain to "parallax.co.uk"
but it still fails.

what is the solution? (besides renaming my machine to wrath.parallax.co.uk)

andy

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 11:52:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA08770 for xemacs-beta-people; Fri, 28 Jun 1996 11:52:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA08767 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 11:52:47 -0500 (CDT)
Received: from gs214.SP.CS.CMU.EDU (GS214.SP.CS.CMU.EDU [128.2.250.65]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA21424 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 11:52:48 -0500 (CDT)
Received: by gs214.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA09994; Fri, 28 Jun 1996 12:52:46 -0400
Date: Fri, 28 Jun 1996 12:52:46 -0400
Message-Id: <9606281652.AA09994@gs214.SP.CS.CMU.EDU>
From: "Arup Mukherjee" <arup+@cmu.edu>
To: xemacs-beta@cs.uiuc.edu
Subject: gnuserv.el fix for tty mode
Reply-To: arup@cmu.edu



The gnuserv.el that shipped with 19.14 has the (IMO) highly
undesirable property that C-x # in tty mode causes emacs to
exit. (This is not what it's supposed to do, and not what it has done
in the past...) 

I don't see why the original line was commented out by someone in the
first place ... window-system is obsolete, it's still set to 'x for X
frames, so nothing should have been broken with the original line enabled. 

Here's a fix.

-Arup

*** lisp/packages/gnuserv.el.orig	Sun Jun 16 15:37:25 1996
--- lisp/packages/gnuserv.el	Fri Jun 28 12:40:45 1996
***************
*** 496,502 ****
        (server-start nil)
      (if server-buffer-clients
  	(progn (server-switch-buffer (server-done))
! 	       (cond ((or ;(not window-system) #### someone examine!
  			  (and gnuserv-frame 
  			       (or (and (fboundp 'frame-live-p)
  					(frame-live-p gnuserv-frame))
--- 496,504 ----
        (server-start nil)
      (if server-buffer-clients
  	(progn (server-switch-buffer (server-done))
! 	       (cond ((or (and (fboundp 'console-type)
! 			       (not (equal (console-type) 'x))) 
! 			  (and (boundp 'window-system) window-system)
  			  (and gnuserv-frame 
  			       (or (and (fboundp 'frame-live-p)
  					(frame-live-p gnuserv-frame))

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 13:11:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA09444 for xemacs-beta-people; Fri, 28 Jun 1996 13:11:53 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA09439 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 13:11:51 -0500 (CDT)
Received: from monolith.spry.com (monolith.spry.com [198.185.2.198]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA22959 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 13:11:45 -0500 (CDT)
Received: (from wmperry@localhost) by monolith.spry.com (8.7.4/8.7.3) id LAA00966; Fri, 28 Jun 1996 11:21:08 -0700
Date: Fri, 28 Jun 1996 11:21:08 -0700
Message-Id: <199606281821.LAA00966@monolith.spry.com>
From: William Perry <wmperry@monolith.spry.com>
To: xemacs-beta@cs.uiuc.edu
Errors-to: wmperry@spry.com
Reply-to: wmperry@spry.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;
Subject: PATCH: GPM support for XEmacs 20.0b26

This is a patch against a virgin 20.0b26 that adds support for GPM under
linux consoles (XTerm stuff won't work unless you use gpm-get-char as a
replacement for getchar, which isn't even used in XEmacs, so...)

Button1/Button2/Button3 work as expected, but for some reason mouse motion
event are not getting the attention they deserve.  The gpm code gets
triggered, the event gets created, but then nothing ever seems to happen to
it.  If someone could take a look at this, I'd appreciate it.

-Bill P.

*** configure.in	1996/06/24 15:08:40	1.1
--- configure.in	1996/06/24 15:32:13
***************
*** 714,719 ****
--- 714,735 ----
            eval "${opt}=\"${val}\""
          ;;
  
+         ## Has the user requested GPM support?
+ 	"with_gpm" )
+ 	  ## Make sure the value given was either "yes" or "no".
+ 	  case "${val}" in
+ 	    y | ye | yes )	val=yes ;;
+ 	    n | no )		val=no  ;;
+ 	    * )
+ 	      (echo "${progname}: the \`--${optname}' option is supposed to have a boolean value.
+ Set it to either \`yes' or \`no'."
+ 	       echo "${short_usage}") >&2
+ 	      exit 1
+ 	    ;;
+ 	  esac
+           eval "${opt}=\"${val}\""
+         ;;
+ 
          ## Has the user requested database support?
          "with_database" )
  	  if [ "${val}" = "no" ] ; then
***************
*** 3519,3524 ****
--- 3535,3558 ----
    AC_DEFINE(HAVE_TIFF)
  fi
  
+ #
+ # autodetect GPM
+ #
+ if test "${with_tty}" != "no" ; then
+   if test "${with_gpm}" != "no" ; then
+     if test "${with_gpm}" != "yes" ; then
+       AC_HAVE_LIBRARY(-lgpm, with_gpm="yes")
+     fi
+   fi
+ else
+   echo "GPM support cannot be specified without TTY support."
+   exit 1
+ fi
+ 
+ if test "${with_gpm}" = "yes" ; then
+   AC_DEFINE(HAVE_GPM)
+ fi
+ 
  # We use Lucid toolkit defaults for the menubars and scrollbars, but
  # if Motif is available we use it for the dialog boxes.
  if test "${window_system}" != "none" ; then
***************
*** 4345,4351 ****
    echo "  Additional libraries:                                   ${site_runtime_libraries}"
  fi
  
! 
  if [ "$with_socks" = "yes" ]; then
    echo "  Compiling in support for SOCKS."
  fi
--- 4379,4387 ----
    echo "  Additional libraries:                                   ${site_runtime_libraries}"
  fi
  
! if [ "$with_gpm" = "yes" ]; then
!   echo "  Compiling in support for GPM."
! fi
  if [ "$with_socks" = "yes" ]; then
    echo "  Compiling in support for SOCKS."
  fi
*** console-tty.c	1996/06/24 14:33:08	1.1
--- console-tty.c	1996/06/24 14:57:09
***************
*** 120,125 ****
--- 120,128 ----
  				 Fget_coding_system (Vdisplay_coding_system));
  #endif
    CONSOLE_TTY_DATA (con)->terminal_type = terminal_type;
+ #ifdef HAVE_GPM
+   connect_to_gpm (con);
+ #endif
    if (NILP (CONSOLE_NAME (con)))
      CONSOLE_NAME (con) = Ffile_name_nondirectory (tty);
    {
*** console-tty.h	1996/06/24 14:33:08	1.1
--- console-tty.h	1996/06/24 15:01:04
***************
*** 41,46 ****
--- 41,49 ----
  struct tty_console
  {
    int infd, outfd;
+ #ifdef HAVE_GPM
+   int mouse_fd;
+ #endif
    Lisp_Object instream, outstream;
    Lisp_Object terminal_type;
    char *term_entry_buffer;
***************
*** 192,197 ****
--- 195,203 ----
  };
  
  #define CONSOLE_TTY_DATA(c) CONSOLE_TYPE_DATA (c, tty)
+ #ifdef HAVE_GPM
+ #define CONSOLE_TTY_MOUSE_FD(c) (CONSOLE_TTY_DATA (c)->mouse_fd)
+ #endif
  #define CONSOLE_TTY_CURSOR_X(c) (CONSOLE_TTY_DATA (c)->cursor_x)
  #define CONSOLE_TTY_CURSOR_Y(c) (CONSOLE_TTY_DATA (c)->cursor_y)
  #define CONSOLE_TTY_REAL_CURSOR_X(c) (CONSOLE_TTY_DATA (c)->real_cursor_x)
*** event-Xt.c	1996/06/24 14:33:08	1.1
--- event-Xt.c	1996/06/24 16:08:44
***************
*** 1706,1712 ****
  emacs_Xt_select_console (struct console *con)
  {
    Lisp_Object console = Qnil;
!   int infd;
  
    if (CONSOLE_X_P (con))
      return; /* X consoles are automatically selected for when we
--- 1706,1712 ----
  emacs_Xt_select_console (struct console *con)
  {
    Lisp_Object console = Qnil;
!   int infd,mousefd;
  
    if (CONSOLE_X_P (con))
      return; /* X consoles are automatically selected for when we
***************
*** 1714,1726 ****
    infd = event_stream_unixoid_select_console (con);
    XSETCONSOLE (console, con);
    select_filedesc (infd, console);
  }
  
  static void
  emacs_Xt_unselect_console (struct console *con)
  {
    Lisp_Object console = Qnil;
!   int infd;
  
    if (CONSOLE_X_P (con))
      return; /* X consoles are automatically selected for when we
--- 1714,1732 ----
    infd = event_stream_unixoid_select_console (con);
    XSETCONSOLE (console, con);
    select_filedesc (infd, console);
+ #ifdef HAVE_GPM
+    mousefd = CONSOLE_TTY_MOUSE_FD (con);
+   if (mousefd != -1) {
+     select_filedesc (mousefd, console);
+   }
+ #endif
  }
  
  static void
  emacs_Xt_unselect_console (struct console *con)
  {
    Lisp_Object console = Qnil;
!   int infd,mousefd;
  
    if (CONSOLE_X_P (con))
      return; /* X consoles are automatically selected for when we
***************
*** 1728,1733 ****
--- 1734,1746 ----
    infd = event_stream_unixoid_unselect_console (con);
    XSETCONSOLE (console, con);
    unselect_filedesc (infd);
+ 
+ #ifdef HAVE_GPM
+   mousefd = CONSOLE_TTY_MOUSE_FD (con);
+   if (mousefd != -1) {
+     unselect_filedesc (mousefd);
+   }
+ #endif
  }
  
  /* read an event from a tty, if one is available.  Returns non-zero
*** event-unixoid.c	1996/06/24 14:33:08	1.1
--- event-unixoid.c	1996/06/24 17:40:05
***************
*** 39,44 ****
--- 39,49 ----
  #include "sysproc.h"		/* select stuff */
  #include "systime.h"
  
+ #ifdef HAVE_GPM
+ #include "gpmevent.h"
+ #include <gpm.h>
+ #endif
+ 
  /* Mask of bits indicating the descriptors that we wait for input on.
     These work as follows:
  
***************
*** 78,83 ****
--- 83,94 ----
  
    XSETCONSOLE (console, con);
  
+ #ifdef HAVE_GPM
+   if (fd == CONSOLE_TTY_MOUSE_FD (con)) {
+     return (handle_gpm_read (event,con,fd));
+   }
+ #endif
+   
    nread = read (fd, &ch, 1);
    if (nread <= 0)
      {
*** frame-tty.c	1996/06/24 14:33:08	1.1
--- frame-tty.c	1996/06/24 15:02:27
***************
*** 33,38 ****
--- 33,42 ----
  #include "console-tty.h"
  #include "frame.h"
  
+ #ifdef HAVE_GPM
+ #include <gpm.h>
+ #endif
+ 
  Lisp_Object Vdefault_tty_frame_plist;
  
  static void
***************
*** 62,67 ****
--- 66,91 ----
        call1 (Qinit_post_tty_win, FRAME_CONSOLE (f));
  }
  
+ #ifdef HAVE_GPM
+ static int
+ tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y)
+ {
+   Gpm_Event ev;
+   int num_buttons;
+ 
+   num_buttons = Gpm_GetSnapshot(&ev);
+   *x = ev.x;
+   *y = ev.y;
+   *frame = DEVICE_SELECTED_FRAME (d);
+   return (1);
+ }
+ 
+ static void
+ tty_set_mouse_position (struct window *w, int x, int y)
+ {
+ }
+ #endif
+ 
  
  /************************************************************************/
  /*                            initialization                            */
***************
*** 71,76 ****
--- 95,104 ----
  console_type_create_frame_tty (void)
  {
    CONSOLE_HAS_METHOD (tty, init_frame_1);
+ #ifdef HAVE_GPM
+   CONSOLE_HAS_METHOD (tty, get_mouse_position);
+   CONSOLE_HAS_METHOD (tty, set_mouse_position);
+ #endif
    CONSOLE_HAS_METHOD (tty, after_init_frame);
  }
  
*** frame.c	1996/06/24 14:33:08	1.1
--- frame.c	1996/06/24 16:38:18
***************
*** 1623,1643 ****
    y = XINT (XCDR (XCDR (val)));
    f = XFRAME (w->frame);
  
!   if (x >= 0 && y >= 0 &&
!       pixel_to_glyph_translation (f, x, y, &x, &y, &obj_x, &obj_y, &w,
! 				  &bufpos, &closest, &modeline_closest,
! 				  &obj1, &obj2)
!       != OVER_NOTHING)
!     {
!       XCAR (XCDR (val)) = make_int (x);
!       XCDR (XCDR (val)) = make_int (y);
!     }
    else
      {
        XCAR (XCDR (val)) = Qnil;
        XCDR (XCDR (val)) = Qnil;
      }
! 
    return val;
  }
  
--- 1623,1644 ----
    y = XINT (XCDR (XCDR (val)));
    f = XFRAME (w->frame);
  
!   if (x >= 0 && y >= 0) {
!     if (pixel_to_glyph_translation (f, x, y, &x, &y, &obj_x, &obj_y, &w,
! 				    &bufpos, &closest, &modeline_closest,
! 				    &obj1, &obj2)
! 	!= OVER_NOTHING)
!       {
! 	XCAR (XCDR (val)) = make_int (x);
! 	XCDR (XCDR (val)) = make_int (y);
!       }
!   }
    else
      {
        XCAR (XCDR (val)) = Qnil;
        XCDR (XCDR (val)) = Qnil;
      }
!   
    return val;
  }
  
*** /dev/null	Mon Dec 31 20:00:00 1979
--- gpmevent.c	Mon Jun 24 10:19:33 1996
***************
*** 0 ****
--- 1,109 ----
+ #include <config.h>
+ #include "lisp.h"
+ #include "console-tty.h"
+ #include "device.h"
+ #include "events.h"
+ #include "process.h"
+ #include "sysdep.h"
+ #include "sysproc.h"		/* select stuff */
+ #include "systime.h"
+ 
+ #ifdef HAVE_GPM
+ #include "gpmevent.h"
+ #include <gpm.h>
+ 
+ #if (!defined(__linux__))	/* possible under xterm */
+ #define KG_SHIFT	0
+ #define KG_CTRL		2
+ #define KG_ALT		3
+ #else
+ #include <linux/keyboard.h> 
+ #endif
+ 
+ extern SELECT_TYPE input_wait_mask, non_fake_input_wait_mask;
+ extern SELECT_TYPE process_only_mask, device_only_mask;
+ void select_filedesc (int fd, Lisp_Object what);
+ 
+ int handle_gpm_read(struct Lisp_Event *event, struct console *con, int fd)
+ {
+   Gpm_Event ev;
+   int modifiers,type,button;
+ 
+   type = -1;
+   button = 1;
+ 
+   if (!Gpm_GetEvent(&ev))
+     return(0);
+   
+   event->timestamp       = 0;
+   event->channel         = CONSOLE_SELECTED_FRAME (con);
+   
+   /* Whow, wouldn't named defines be NICE!?!?! */
+   modifiers = 0;
+   if (ev.modifiers & 1)   modifiers |= MOD_SHIFT;
+   if (ev.modifiers & 2)   modifiers |= MOD_META;
+   if (ev.modifiers & 4)   modifiers |= MOD_CONTROL;
+   if (ev.modifiers & 8)   modifiers |= MOD_META;
+ 
+   if (ev.type & GPM_DOWN)
+     type = GPM_DOWN;
+   else if (ev.type & GPM_UP)
+     type = GPM_UP;
+   else if (ev.type & GPM_MOVE) {
+     type = GPM_MOVE;
+     GPM_DRAWPOINTER(&ev);
+   }
+ 
+   if (ev.buttons & GPM_B_LEFT)
+     button = 1;
+   else if (ev.buttons & GPM_B_MIDDLE)
+     button = 2;
+   else if (ev.buttons & GPM_B_RIGHT)
+     button = 3;
+ 
+   switch (type) {
+   case GPM_DOWN:
+   case GPM_UP:
+     if (type == GPM_DOWN)
+       event->event_type           = button_press_event;
+     else event->event_type        = button_release_event;
+     event->event.button.x         = ev.x;
+     event->event.button.y         = ev.y;
+     event->event.button.button    = button;
+     event->event.button.modifiers = modifiers;
+     break;
+   case GPM_MOVE:
+     event->event_type             = pointer_motion_event;
+     event->event.motion.x         = ev.x;
+     event->event.motion.y         = ev.y;
+     event->event.motion.modifiers = modifiers;
+   default:
+     return (0);
+   }
+   return (1);
+ }
+ 
+ int connect_to_gpm(struct console *con)
+ {
+   /* Only do this if we are running after dumping and really interactive */
+   if (!noninteractive && initialized) {
+     /* We really only want to do this on a TTY */
+     if (EQ (CONSOLE_TYPE (con), Qtty)) {
+       Gpm_Connect conn;
+ 
+       conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE;
+       conn.defaultMask = GPM_MOVE;
+       conn.minMod = 0;
+       conn.maxMod = ((1<<KG_SHIFT)|(1<<KG_ALT)|(1<<KG_CTRL));
+ 
+       if (Gpm_Open (&conn, 0) == -1) {
+ 	CONSOLE_TTY_MOUSE_FD (con) = -1;
+ 	return(0);
+       }
+       set_descriptor_non_blocking (gpm_fd);
+       CONSOLE_TTY_MOUSE_FD (con) = gpm_fd;
+     }
+   }
+ }
+ 
+ #endif
*** /dev/null	Mon Dec 31 20:00:00 1979
--- gpmevent.h	Mon Jun 24 07:56:17 1996
***************
*** 0 ****
--- 1,7 ----
+ #ifndef _HAVE_GPM
+ #define _HAVE_GPM
+ 
+ int handle_gpm_read(struct Lisp_Event *event, struct console *con, int fd);
+ int connect_to_gpm(struct console *con);
+ 
+ #endif
*** Makefile.in.in	1996/06/24 14:33:08	1.1
--- Makefile.in.in	1996/06/24 15:44:54
***************
*** 419,424 ****
--- 419,431 ----
  JPEG_LIBS = -ljpeg
  #endif
  
+ #ifdef HAVE_GPM
+ GPM_LIBS = -lgpm
+ #define GPM_OBJS gpmevent.o
+ #else /* not HAVE_GPM */
+ #define GPM_OBJS
+ #endif /* not HAVE_GPM */
+ 
  #ifdef MULE
  #define MULE_INC -I${MULESRCDIR}
  #else
***************
*** 892,897 ****
--- 899,905 ----
  	TOOLBAR_OBJS TOOLTALK_OBJS TTY_OBJS \
  	undo.o UNEXEC \
  	XOBJS XMU_OBJS \
+ 	GPM_OBJS \
  	window.o
  
  #ifdef HAVE_TTY
***************
*** 1247,1254 ****
  	LIB_TOOLTALK $(LIBX) \
  	LIBS_SYSTEM LIBS_MACHINE LIBS_TERMCAP \
  	LIB_CANNA LIB_INTL QUANTIFY_LIBS \
! 	DATABASE_LIBS LIBS_DEBUG $(GNULIB_VAR) LIB_MATH LIB_STANDARD \
! 	$(GNULIB_VAR)
  
  /* Enable recompilation of certain other files depending on system type.  */
  
--- 1255,1262 ----
  	LIB_TOOLTALK $(LIBX) \
  	LIBS_SYSTEM LIBS_MACHINE LIBS_TERMCAP \
  	LIB_CANNA LIB_INTL QUANTIFY_LIBS \
! 	DATABASE_LIBS $(GPM_LIBS) LIBS_DEBUG $(GNULIB_VAR) LIB_MATH \
! 	LIB_STANDARD $(GNULIB_VAR)
  
  /* Enable recompilation of certain other files depending on system type.  */
  
*** config.h.in	1996/06/24 14:33:08	1.1
--- config.h.in	1996/06/24 15:29:23
***************
*** 210,215 ****
--- 210,218 ----
  #undef UNEXEC_SRC
  #undef AIX_SMT_EXP
  
+ /* Define HAVE_GPM if you have the 'gpm' library and want XEmacs to use it */
+ #undef HAVE_GPM
+ 
  /* Define HAVE_SOCKS if you have the `socks' library and want XEmacs to
     use it.  */
  #undef HAVE_SOCKS

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 15:03:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA10282 for xemacs-beta-people; Fri, 28 Jun 1996 15:03:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA10279 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 15:03:15 -0500 (CDT)
Received: from gs214.SP.CS.CMU.EDU (GS214.SP.CS.CMU.EDU [128.2.250.65]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA25373 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 15:03:16 -0500 (CDT)
Received: by gs214.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA14317; Fri, 28 Jun 1996 16:03:09 -0400
Date: Fri, 28 Jun 1996 16:03:09 -0400
Message-Id: <9606282003.AA14317@gs214.SP.CS.CMU.EDU>
From: "Arup Mukherjee" <arup+@cmu.edu>
To: xemacs-beta@cs.uiuc.edu
Subject: fixed gnuserv fix...
Reply-To: arup@cmu.edu


Hi again, 
	
	ignore the previous fix that I sent in for gnuserv.el ... it
causes problems with gnuattach. Here's one that appears to have better
behavior with both gnuclient and gnuattach... (diff is against the
gnuserv.el form 19.14)

-Arup

*** lisp/packages/gnuserv.el.orig	Sun Jun 16 15:37:25 1996
--- lisp/packages/gnuserv.el	Fri Jun 28 15:46:30 1996
***************
*** 496,502 ****
        (server-start nil)
      (if server-buffer-clients
  	(progn (server-switch-buffer (server-done))
! 	       (cond ((or ;(not window-system) #### someone examine!
  			  (and gnuserv-frame 
  			       (or (and (fboundp 'frame-live-p)
  					(frame-live-p gnuserv-frame))
--- 496,510 ----
        (server-start nil)
      (if server-buffer-clients
  	(progn (server-switch-buffer (server-done))
! 	       (cond ((fboundp 'console-type)        ;; XEmacs 19.14+
! 		      (or (and (equal (console-type) 'x)
! 			       gnuserv-frame
! 			       (frame-live-p gnuserv-frame))
! 			  (condition-case ()
! 			      (delete-frame (selected-frame) nil)
! 			    (error 
! 			     (message "Not deleting last visible frame...")))))
! 		     ((or (not window-system) 
  			  (and gnuserv-frame 
  			       (or (and (fboundp 'frame-live-p)
  					(frame-live-p gnuserv-frame))

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 15:28:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA10548 for xemacs-beta-people; Fri, 28 Jun 1996 15:28:57 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA10545 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 15:28:55 -0500 (CDT)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA25931 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 15:28:52 -0500 (CDT)
Received: from ylfing.ifi.uio.no (ylfing.ifi.uio.no [129.240.94.25]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <WAA19191@ifi.uio.no> ; Fri, 28 Jun 1996 22:28:16 +0200
Received: (from larsi@localhost) by ylfing.ifi.uio.no ; Fri, 28 Jun 1996 22:28:15 +0200
To: andyp@parallax.co.uk (Andy Piper)
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: gnus problems in 19.14
References: <199606281341.OAA10153@wrath.parallax.co.uk>
X-Face: &w!^oO<W.WBH]FsTP:P0f9X6M-ygaADlA_)eF$<UwQzj7:C=Gi<a?/_4$LX^@$Qq7-O&XHp
	lDARi8e8iT<(A$LWAZD*xjk^')/wI5nG;1cNB>~dS|}-P0~ge{$c!h\<y
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Date: 28 Jun 1996 22:28:14 +0200
In-Reply-To: andyp@parallax.co.uk's message of Fri, 28 Jun 1996 14:41:10 +0100
Message-ID: <w8sivcbad29.fsf@ylfing.ifi.uio.no>
Lines: 15
X-Mailer: Gnus v5.2.30/Emacs 19.31

andyp@parallax.co.uk (Andy Piper) writes:

> system-name under xemacs yields "wrath"
> gnus fails to post because it thinks this is a duff name for replying
> to (correct), so I set gnus-local-domain to "parallax.co.uk"
> but it still fails.
> 
> what is the solution? 

Set `mail-host-address' or `user-mail-address' to something
appropriate. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 18:45:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA12095 for xemacs-beta-people; Fri, 28 Jun 1996 18:45:05 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA12092 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 18:45:04 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA01124 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 18:45:05 -0500 (CDT)
Received: from sbkifer.cs.sunysb.edu (sbkifer.cs.sunysb.edu [130.245.1.35]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id TAA11538 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 19:49:14 -0400
Message-Id: <199606282349.TAA11538@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: xemacs-beta@cs.uiuc.edu
Subject: copy vs. SunCopy
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Jun 1996 19:43:24 -0400
Sender: kifer@cs.sunysb.edu

I found the following to be weird under SunOS 4.1.3/X11r6:

M-x describe-key-briefly

then press Copy on the sun keyboard.

You get: 

    copy runs repeat-complex-command

However, if you then evaluate

    (global-set-key [SunCopy] 'repeat-complex-command)

then the same sequence of events (M-x describe-key-briefly, then press Copy)
gives:

    SunCopy runs repeat-complex-command

That is, from this point on, the key changed its name!

Can somebody explain what is going on here?
This seems like a bug somewhere.



	--michael  

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 19:16:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA12243 for xemacs-beta-people; Fri, 28 Jun 1996 19:16:02 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA12240 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 19:16:00 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA01472 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 19:16:02 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA17728; Fri, 28 Jun 1996 17:15:29 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA26336; Fri, 28 Jun 1996 17:15:25 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA09799; Fri, 28 Jun 1996 17:15:23 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA28405; Fri, 28 Jun 1996 17:15:17 -0700
Date: Fri, 28 Jun 1996 17:15:17 -0700
Message-Id: <199606290015.RAA28405@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: kifer@cs.sunysb.edu (Michael Kifer)
Cc: xemacs-beta@cs.uiuc.edu
Subject: copy vs. SunCopy
In-Reply-To: <199606282349.TAA11538@cs.sunysb.edu>
References: <199606282349.TAA11538@cs.sunysb.edu>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Michael" == Michael Kifer <kifer@cs.sunysb.edu> writes:

Michael> I found the following to be weird under SunOS 4.1.3/X11r6:
Michael> M-x describe-key-briefly

Michael> then press Copy on the sun keyboard.

Michael> You get: 

Michael>     copy runs repeat-complex-command

Michael> However, if you then evaluate

Michael>     (global-set-key [SunCopy] 'repeat-complex-command)

Michael> then the same sequence of events (M-x describe-key-briefly, then press Copy)
Michael> gives:

Michael>     SunCopy runs repeat-complex-command

Michael> That is, from this point on, the key changed its name!

Michael> Can somebody explain what is going on here?
Michael> This seems like a bug somewhere.

This is supposed to be a feature.  See x-win-sun.el.  Keybindings work
with either `copy' or `SunCopy'.  It's true that it makes more sense
for keys like `r35'.

Martin

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 19:40:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA12371 for xemacs-beta-people; Fri, 28 Jun 1996 19:40:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA12368 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 19:40:26 -0500 (CDT)
Received: from hackvan.com (hackvan.com [206.80.31.242]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA01745 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 19:40:28 -0500 (CDT)
Received: by hackvan.com (Linux Smail3.1.29.1 #27)
	id m0uZo3u-000HE5C; Fri, 28 Jun 96 17:38 PDT
Message-Id: <m0uZo3u-000HE5C@hackvan.com>
Date: Fri, 28 Jun 96 17:38 PDT
From: stig@hackvan.com (Stig)
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Hanging frames
In-Reply-To: <199606270110.VAA24555@anthem.CNRI.Reston.Va.US>
References: <199606270049.RAA06050@sandman.cisco.com>
	<199606270110.VAA24555@anthem.CNRI.Reston.Va.US>
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/


I use tvtwm on Linux and I've had this problem for a long time.  I first
encountered it, though, with 19.12 on SunOS (also using tvtwm).  I recently
upgraded to a beta version of XFree86 (3.1.2E) and it seems to not be so
bad, but I also have a way-faster dual pentium machine and it could be a
race condition that just isn't tweaked as badly...either by the speed or the
concurrancy...don't know.

I hate few things, but I really *HATE* this bug.  I tried to find it once or
twice (a loooooooong time ago), but got lost in redisplay...

    Stig


Barry A. Warsaw wrote:
> >>>>> "DR" == Dan Rich <drich@cisco.com> writes:
> 
>     DR> Everything works fine until I iconify a frame, and then a good
>     DR> percentage of the time, the frame ceases to update after I
>     DR> deiconify it.  Sometimes the contents frame will be drawn,
>     DR> others I just get a menubar and toolbar.  However, any input
>     DR> to the frozen frame is taken, it just doesn't update the
>     DR> display (which can be really creepy if you have the same
>     DR> buffer displayed in two frames -- one frozen and one not).
> 
> Dan, what window manager are you using?  I've seen this behavior even
> in 19.13, but only under fvwm 2.0.42.  I never saw it under ctwm or
> fvwm 1 (which admittedly I didn't flex much).  I've seen the same
> thing under the 19.14 betas but haven't tried 19.14 proper yet.  I
> have yet to figure out whether its an fvwm2 thing or an XEmacs thing
> (or both?)

From xemacs-beta-request@cs.uiuc.edu  Fri Jun 28 22:13:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA13209 for xemacs-beta-people; Fri, 28 Jun 1996 22:13:07 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA13206 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 28 Jun 1996 22:13:06 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA08460 for <xemacs-beta@cs.uiuc.edu>; Fri, 28 Jun 1996 22:13:07 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.53 #1)
	id E0uZqT2-0004fN-00; Fri, 28 Jun 1996 23:13:04 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: gnus problems in 19.14
In-Reply-To: <w8sivcbad29.fsf@ylfing.ifi.uio.no>
References: <199606281341.OAA10153@wrath.parallax.co.uk>
	<w8sivcbad29.fsf@ylfing.ifi.uio.no>
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uZqT2-0004fN-00@neal.ctd.comsat.com>
Date: Fri, 28 Jun 1996 23:13:04 -0400

On my Linux box I have hostname set without domainname, but in .emacs
I have

(setq gnus-local-domain "ctd.comsat.com")

So why do I get a From: hostname generated without the domainname?

Stranger still, the same setup (hostname is set to host only without
domain, and gnus-local-domain set) works fine on my hpux machine.

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

    Lars> andyp@parallax.co.uk (Andy Piper) writes:
    >> system-name under xemacs yields "wrath"
    >> gnus fails to post because it thinks this is a duff name for replying
    >> to (correct), so I set gnus-local-domain to "parallax.co.uk"
    >> but it still fails.
    >> 
    >> what is the solution? 

    Lars> Set `mail-host-address' or `user-mail-address' to something
    Lars> appropriate. 

    Lars> -- 
    Lars> (domestic pets only, the antidote for overdose, milk.)
    Lars>   larsi@ifi.uio.no * Lars Ingebrigtsen

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 29 00:23:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA13818 for xemacs-beta-people; Sat, 29 Jun 1996 00:23:02 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA13815 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 29 Jun 1996 00:23:01 -0500 (CDT)
Received: from hackvan.com (hackvan.com [206.80.31.242]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA11666; Sat, 29 Jun 1996 00:23:02 -0500 (CDT)
Received: by hackvan.com (Linux Smail3.1.29.1 #27)
	id m0uZsT0-000HE5C; Fri, 28 Jun 96 22:21 PDT
Message-Id: <m0uZsT0-000HE5C@hackvan.com>
Date: Fri, 28 Jun 96 22:21 PDT
From: stig@hackvan.com (Stig)
To: cognot@ensg.u-nancy.fr
Cc: Chuck Thompson <cthomp@cs.uiuc.edu>, Neal Becker <Neal.Becker@comsat.com>,
        xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14 crash again 
In-Reply-To: <199606261406.JAA13404@a.cs.uiuc.edu>
References: <E0uYu7N-00006b-00@neal.ctd.comsat.com>
	<199606261259.HAA22789@charles.cs.uiuc.edu>
	<199606261406.JAA13404@a.cs.uiuc.edu>
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/

Richard Cognot wrote:
> 
> System/Model:   9000/700
> Product Name:   HPUX S800 10.0X
> Product Vers:   9245XB.10.00
> 
> Description: strcat(3C) may read beyond end of source string, can cause SIGSEGV
> 
> 
> *** PROBLEM TEXT ***
> strcat(3C) may read beyond the source string onto an unmapped page,
> causing a segmentation violation.
> 
> Appears to be an hpux 10 problem, though.

strcat is the sort of function that's often inlined by optimizing compilers,
so if it was compiled on hpux 10 with enough optimization, then it will
still affect other hpux versions.

    Stig
    

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 29 01:18:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA13940 for xemacs-beta-people; Sat, 29 Jun 1996 01:18:36 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA13937 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 29 Jun 1996 01:18:35 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA12208; Sat, 29 Jun 1996 01:18:37 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id XAA21039; Fri, 28 Jun 1996 23:06:45 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id XAA16881; Fri, 28 Jun 1996 23:06:44 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA13474; Fri, 28 Jun 1996 23:06:41 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id XAA29503; Fri, 28 Jun 1996 23:06:33 -0700
Date: Fri, 28 Jun 1996 23:06:33 -0700
Message-Id: <199606290606.XAA29503@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: stig@hackvan.com (Stig)
Cc: cognot@ensg.u-nancy.fr, Chuck Thompson <cthomp@cs.uiuc.edu>,
        Neal Becker <Neal.Becker@comsat.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14 crash again 
In-Reply-To: <m0uZsT0-000HE5C@hackvan.com>
References: <E0uYu7N-00006b-00@neal.ctd.comsat.com>
	<199606261259.HAA22789@charles.cs.uiuc.edu>
	<199606261406.JAA13404@a.cs.uiuc.edu>
	<m0uZsT0-000HE5C@hackvan.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Stig" == Stig  <stig@hackvan.com> writes:

Stig> strcat is the sort of function that's often inlined by optimizing compilers,
Stig> so if it was compiled on hpux 10 with enough optimization, then it will
Stig> still affect other hpux versions.

I would be surprised if HP supports hpux10-built binaries working on
hpux9 anyways.  I know that neither Sun nor IBM supports such compatibility.

Martin


From xemacs-beta-request@cs.uiuc.edu  Sat Jun 29 12:23:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA19872 for xemacs-beta-people; Sat, 29 Jun 1996 12:23:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA19869 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 29 Jun 1996 12:23:58 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA29198 for <xemacs-beta@xemacs.org>; Sat, 29 Jun 1996 12:23:54 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA08330; Sat, 29 Jun 1996 10:16:06 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA28013; Sat, 29 Jun 1996 19:15:55 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA11317; Sat, 29 Jun 1996 19:16:01 +0200
Date: Sat, 29 Jun 1996 19:16:01 +0200
Message-Id: <9606291716.AA11317@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
Reply-To: carney@gvc.dec.com
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.14 build (patched) success on Digital UNIX V4.0 
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

Following the configuration info is a small patch for 19.14 on DUNIX 4.0.
The first part is new file src/s/decosf4-0-static.h, and the rest is a
regular diff.

The only real breakage was "HAVE_RENAME" not being defined.  I guess
configure should've picked it up.  On the rename man page it indicates
that the implementation "does not conform to current standards".
However, it seems that the XEmacs definition has the same signature.

        Steve


Hardware  : DEC 3000-500
OS        : Digital UNIX V4.0 (386)
Compiler  : gcc-2.7.2
Libraries : X11R6, Motif
XEmacs    : 19.14 (full kit)

Configured for `alpha-dec-osf4.0'.
  Where should the build process find the source code?    /var/kits/install/xemacs/xemacs-19.14-distribution
  What installation prefix should install use?            /usr/local/xemacs-19.14-distribution
  What operating system and machine description files should XEmacs use?
        `s/decosf4-0.h' and `m/alpha.h'
  What compiler should XEmacs be built with?              gcc -O3
  Should XEmacs use the GNU version of malloc?            no
  (The GNU allocators don't work with this system configuration.)
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /var/kits/install/jpegsrc/release /usr/local/include
  Additional libraries:                                   /var/kits/install/jpegsrc/release /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.


===== src/s/decosf4-0-static.h =====

/* Synched up with: Not in FSF. */

#include "decosf4-0.h"

#ifdef NOT_C_CODE
/* This is to get rid of the definition that selects dynamic linking. */
#undef LD_SWITCH_CALL_SHARED
#ifdef USE_GCC
#define LD_SWITCH_CALL_SHARED -static -Xlinker -non_shared
#else
#define LD_SWITCH_CALL_SHARED -non_shared
#endif /* USE_GCC */
#endif /* NOT_C_CODE */


===== patches =====

*** configure.in.dist	Sat Jun 22 16:18:25 1996
--- configure.in	Tue Jun 25 22:47:31 1996
***************
*** 2360,2365 ****
--- 2360,2366 ----
      decosf1-3		) opsys=decosf1-3-static ;;
      decosf3-1		) opsys=decosf3-1-static ;;
      decosf3-2		) opsys=decosf3-2-static ;;
+     decosf4-0		) opsys=decosf4-0-static ;;
      linux		) opsys=linux-static ;;
    esac
  fi
*** src/s/decosf4-0.h.dist	Mon Feb 19 04:23:47 1996
--- src/s/decosf4-0.h	Tue Jun 25 21:09:53 1996
***************
*** 24,27 ****
--- 24,31 ----
  #define regoff_t sys_regoff_t
  #define regmatch_t sys_regmatch_t
  
+ #undef SYSTEM_MALLOC
  #define SYSTEM_MALLOC
+ 
+ #undef HAVE_RENAME
+ #define HAVE_RENAME
*** src/ralloc.c.dist	Mon Apr  1 02:18:58 1996
--- src/ralloc.c	Tue Jun 25 22:02:26 1996
***************
*** 757,763 ****
  static int
  MHASH (VM_ADDR addr)
  {
!   unsigned int addr_shift = (unsigned int)(addr) >> USELESS_LOWER_ADDRESS_BITS;
    int hval = addr_shift % MHASH_PRIME; /* We could have addresses which are -ve 
  					  when converted to signed ints */
    return ((hval >= 0) ? hval : MHASH_PRIME + hval);
--- 757,763 ----
  static int
  MHASH (VM_ADDR addr)
  {
!   EMACS_UINT addr_shift = (EMACS_UINT)(addr) >> USELESS_LOWER_ADDRESS_BITS;
    int hval = addr_shift % MHASH_PRIME; /* We could have addresses which are -ve 
  					  when converted to signed ints */
    return ((hval >= 0) ? hval : MHASH_PRIME + hval);
*** src/getloadavg.c.dist	Sun Jun  2 02:12:53 1996
--- src/getloadavg.c	Tue Jun 25 22:15:05 1996
***************
*** 156,161 ****
--- 156,163 ----
  
  #if defined (__osf__) && (defined (__alpha) || defined (__alpha__))
  #define OSF_ALPHA
+ struct rtentry;			/* Prevent warning in Digital UNIX 4.0 */
+ struct mbuf;			/* Prevent warning in Digital UNIX 4.0 */
  #include <sys/table.h>
  #endif
  

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 29 21:27:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA21843 for xemacs-beta-people; Sat, 29 Jun 1996 21:27:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA21840 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 29 Jun 1996 21:27:03 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA07479 for <xemacs-beta@cs.uiuc.edu>; Sat, 29 Jun 1996 21:27:04 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id TAA00411 for xemacs-beta@cs.uiuc.edu; Sat, 29 Jun 1996 19:25:36 GMT
Date: Sat, 29 Jun 1996 19:25:36 GMT
From: Ben Wing <wing@666.com>
Message-Id: <199606291925.TAA00411@nene.boundless.com>
To: xemacs-beta@cs.uiuc.edu
Subject: more on HPUX strcat

Here's a patch that makes it unnecessary to modify any Makefiles.

*** hpux10.h~	Sat Jun  1 23:50:10 1996
--- hpux10.h	Sat Jun 29 19:23:18 1996
***************
*** 15,20 ****
--- 15,21 ----
  #undef HAVE_RANDOM
  #define HPUX10
  #define FORCE_ALLOCA_H
+ #define OBJECTS_SYSTEM strcat.o /* XEmacs addition */
  
  /* XEmacs addition: New paths for hpux 10 */
  #undef C_SWITCH_X_SYSTEM

From xemacs-beta-request@cs.uiuc.edu  Sat Jun 29 21:22:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA21830 for xemacs-beta-people; Sat, 29 Jun 1996 21:22:27 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA21827 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 29 Jun 1996 21:22:26 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA07471 for <xemacs-beta@cs.uiuc.edu>; Sat, 29 Jun 1996 21:22:28 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id TAA00364 for xemacs-beta@cs.uiuc.edu; Sat, 29 Jun 1996 19:20:58 GMT
Date: Sat, 29 Jun 1996 19:20:58 GMT
From: Ben Wing <wing@666.com>
Message-Id: <199606291920.TAA00364@nene.boundless.com>
To: xemacs-beta@cs.uiuc.edu
Subject: Correct version of strcat()


Here's a correct version of strcat(), from glibc 1.09.  HPUX users
who are seeing strcat() crashes, please try this (add it to the link
line in src/Makefile) and see if it fixes things.

ben

---------------------------- strcat.c -------------------------------
/* Copyright (C) 1991 Free Software Foundation, Inc.
This file is part of the GNU C Library.

The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.

The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with the GNU C Library; see the file COPYING.LIB.  If
not, write to the Free Software Foundation, Inc., 675 Mass Ave,
Cambridge, MA 02139, USA.  */

/* Synched up with: Not in FSF. */

/* In HPUX 10 the strcat function references memory past the last byte of 
   the string!  This will core dump if the memory following the last byte is 
   not mapped.

   Here is a correct version from glibc 1.09.
*/

char *strcat (char *dest, const char *src);

/* Append SRC on the end of DEST.  */
char *
strcat (char *dest, const char *src)
{
  register char *s1 = dest;
  register const char *s2 = src;
  char c;

  /* Find the end of the string.  */
  do
    c = *s1++;
  while (c != '\0');

  /* Make S1 point before the next character, so we can increment
     it while memory is read (wins on pipelined cpus).  */
  s1 -= 2;

  do
    {
      c = *s2++;
      *++s1 = c;
    }
  while (c != '\0');

  return dest;
}
------------------------------- cut ---------------------------------

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 03:15:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26097 for xemacs-beta-people; Sun, 30 Jun 1996 03:15:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26094 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 03:15:15 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA11960 for <xemacs-beta@cs.uiuc.edu>; Sun, 30 Jun 1996 03:15:14 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA01863; Sun, 30 Jun 1996 01:13:28 GMT
Date: Sun, 30 Jun 1996 01:13:28 GMT
Message-Id: <199606300113.BAA01863@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: kifer@cs.sunysb.edu (Michael Kifer)
Cc: xemacs-beta@cs.uiuc.edu
Subject: native sound only on console
In-Reply-To: <199606272237.SAA02770@cs.sunysb.edu>
References: <199606272237.SAA02770@cs.sunysb.edu>

Michael Kifer writes:
 > native-sound-only-on-console t
 > 
 > doesn't seem to have any effect. xemacs -nw or even xemacs run on a
 > different machine in an xterm window tries to play sound.
 > In case of a different machine, it gives me an error that /dev/audio can't
 > be openeed. Because of this,
 > 
 > (setq native-sound-only-on-console t)
 > (load-default-sounds)
 > 
 > doesn't work if emacs runs remotedly. Is there a patch for this bug?

init_device_sound() assumes that if the current device is a TTY
device, it's on the console.  This is clearly not accurate but there
doesn't appear to be any easy way to determine if a given TTY is
on the console.

You could always wrap (load-default-sounds) in a condition-case.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 03:23:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26202 for xemacs-beta-people; Sun, 30 Jun 1996 03:23:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26197 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 03:23:52 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA01097 for <xemacs-beta@xemacs.org>; Sun, 30 Jun 1996 03:23:46 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA02108; Sun, 30 Jun 1996 01:22:17 GMT
Date: Sun, 30 Jun 1996 01:22:17 GMT
Message-Id: <199606300122.BAA02108@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: David Worenklein <dcw@gcm.com>
Cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Really slow XEmacs
In-Reply-To: <amzq5rrd9k.fsf@gcm.com>
References: <amzq5rrd9k.fsf@gcm.com>

David Worenklein writes:
 > I found that as soon as I start sql-mode (and, particularly, within
 > sql-mode) typing slows to an unusable speed.  So I quantified XEmacs,
 > typed about two hundred random characters, and found that readchar (in lread.c)
 > was called five MILLION times from read1.  read1 took 35.25% of the
 > time, and readchar took about half of that.
 > 
 > I've never really delved into the C code, but what the hell would you
 > want to do 25,000 times per keystroke?
 > 
 > (I'll send anyone the .qv output if he or she wants it.)

How many times per keystroke is Fread() or Fread_from_string() called?
That's what's important.  Is SQL-mode installing a post-command-hook
that does `read'?

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 03:15:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26093 for xemacs-beta-people; Sun, 30 Jun 1996 03:15:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26089 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 03:15:13 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA01066 for <xemacs-beta@xemacs.org>; Sun, 30 Jun 1996 03:15:07 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA01866; Sun, 30 Jun 1996 01:13:44 GMT
Date: Sun, 30 Jun 1996 01:13:44 GMT
Message-Id: <199606300113.BAA01866@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: Philip Aston <philipa@sloth>
Cc: xemacs-beta@xemacs.org
Subject: Bug in 19-14/dabbrev
In-Reply-To: <9606261234.AA20859@sloth.parallax.co.uk>
References: <9606261234.AA20859@sloth.parallax.co.uk>

Philip Aston writes:
 > 
 > Bug in 19-14/dabbrev
 > 
 > 
 > dabbrev-completion scans the buffers, then gives
 > 
 > "Bad keyword argument dabbrev--extent-clicked-on"
 > 
 > 
 > This worked in 19-13.

Fixed in the next beta.

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 03:18:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26162 for xemacs-beta-people; Sun, 30 Jun 1996 03:18:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26159 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 03:18:55 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA01087 for <xemacs-beta@xemacs.org>; Sun, 30 Jun 1996 03:18:51 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA01963; Sun, 30 Jun 1996 01:17:24 GMT
Date: Sun, 30 Jun 1996 01:17:24 GMT
Message-Id: <199606300117.BAA01963@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: carney@gvc.dec.com
Cc: xemacs-beta@xemacs.org
Subject: color ttys
In-Reply-To: <9606260925.AA01832@fornet.gvc.dec.com>
References: <9606260925.AA01832@fornet.gvc.dec.com>

Stephen Carney writes:
 > I'm not getting any color in ttys in 19.14.  None of my termcap entries
 > had AB or AF attributes.  So I created an xterm-color entry, based on
 > xterm, with AB and AF.  When I startup, (device-class) is 'color,
 > but the modeline is B&W, as are all of the M-x edit-faces entries.
 > 
 > What values do I need to give to AF and AB?  What am I missing?

Maybe you need color xterm?

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 03:22:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26182 for xemacs-beta-people; Sun, 30 Jun 1996 03:22:14 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26179 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 03:22:12 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA12027 for <xemacs-beta@cs.uiuc.edu>; Sun, 30 Jun 1996 03:22:11 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA02039; Sun, 30 Jun 1996 01:20:40 GMT
Date: Sun, 30 Jun 1996 01:20:40 GMT
Message-Id: <199606300120.BAA02039@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: Neal Becker <Neal.Becker@comsat.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: SIGTTOU hpux9.05
In-Reply-To: <E0uYcHe-00008i-00@neal.ctd.comsat.com>
References: <E0uYcHe-00008i-00@neal.ctd.comsat.com>

Neal Becker writes:
 > Here is what I see regarding the gnuattach problem.
 > 
 > Program received signal SIGTTOU, Stopped (tty output).
 > 0x800c1980 in ioctl ()
 > (gdb) where
 > #0  0x800c1980 in ioctl ()
 > #1  0x800fb1d8 in reset_shell_mode ()
 > #2  0x800f0e6c in tgetent ()
 > #3  0x11cf44 in init_tty_for_redisplay (d=0x4030e100, 
 >     terminal_type=0x403479f8 "xterm") at redisplay-tty.c:1091
 > #4  0x119bf8 in tty_init_device (d=0x4030e100, props=1074942977)
 >     at device-tty.c:68

OK, here's a patch that's along the lines of what you should try:


*** redisplay-tty.c~	Sun Jun 23 23:28:20 1996
--- redisplay-tty.c	Sun Jun 30 01:18:44 1996
***************
*** 1093,1099 ****
--- 1093,1101 ----
    CONSOLE_TTY_DATA (c)->term_entry_buffer = (char *) xmalloc (2044);
    bufptr = CONSOLE_TTY_DATA (c)->term_entry_buffer; 
  
+   EMACS_BLOCK_SIGNAL (SIGTTOU);
    status = tgetent (entry_buffer, terminal_type);
+   EMACS_UNBLOCK_SIGNAL (SIGTTOU);
  #if 0
    if (status < 0)
      return TTY_UNABLE_OPEN_DATABASE;


If you then hit SIGTTOU in other places, try blocking it in those
places, too.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 03:34:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26222 for xemacs-beta-people; Sun, 30 Jun 1996 03:34:26 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26219 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 03:34:23 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA12116 for <xemacs-beta@cs.uiuc.edu>; Sun, 30 Jun 1996 03:34:23 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA02475; Sun, 30 Jun 1996 01:32:56 GMT
Date: Sun, 30 Jun 1996 01:32:56 GMT
Message-Id: <199606300132.BAA02475@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: wmperry@spry.com
Cc: xemacs-beta@cs.uiuc.edu
Subject: mouse-position totally screwed
In-Reply-To: <199606241637.JAA14010@monolith.spry.com>
References: <199606241637.JAA14010@monolith.spry.com>

William Perry writes:
 > mouse-position only ever returns what it is supposed to if you are over a
 > glyph.  Gack.  The culprit is:
 > 
 >   if (x >= 0 && y >= 0 &&
 >       pixel_to_glyph_translation (f, x, y, &x, &y, &obj_x, &obj_y, &w,
 > 				  &bufpos, &closest, &modeline_closest,
 > 				  &obj1, &obj2)
 >       != OVER_NOTHING)
 >     {
 >       XCAR (XCDR (val)) = make_int (x);
 >       XCDR (XCDR (val)) = make_int (y);
 >     }
 >   else
 >     {
 >       XCAR (XCDR (val)) = Qnil;
 >       XCDR (XCDR (val)) = Qnil;
 >     }
 > 
 > in mouse-position in frame.c.  I think what you want is:
 > 
 > if (x >= 0 && y >= 0) 
 >  {
 >   if (pixel_to_glyph_translation (f, x, y, &x, &y, &obj_x, &obj_y, &w,
 > 				  &bufpos, &closest, &modeline_closest,
 > 				  &obj1, &obj2)
 >       != OVER_NOTHING)
 >     {
 >       XCAR (XCDR (val)) = make_int (x);
 >       XCDR (XCDR (val)) = make_int (y);
 >     }
 >   }
 >  else
 >   {
 >     XCAR (XCDR (val)) = Qnil;
 >     XCDR (XCDR (val)) = Qnil;
 >   }
 > 
 > That way if you are not over a glyph, the old values of x & y are
 > preserved.  Or am I insane?

Looks right.  I've applied the patch.

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 03:36:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26229 for xemacs-beta-people; Sun, 30 Jun 1996 03:36:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26226 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 03:36:55 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA01123 for <xemacs-beta@xemacs.org>; Sun, 30 Jun 1996 03:36:51 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA02532; Sun, 30 Jun 1996 01:35:23 GMT
Date: Sun, 30 Jun 1996 01:35:23 GMT
Message-Id: <199606300135.BAA02532@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: turner@lanl.gov
Cc: mdb@cdc.noaa.gov, xemacs-beta@xemacs.org
Subject: Re: 19.14p1: Solaris 2.5, SunPro CC 4.0, CDE
In-Reply-To: <199606211908.NAA02623@gielgud.lanl.gov.xdiv>
References: <199606211516.JAA08613@gielgud.lanl.gov.xdiv>
	<vkd92txgps.fsf@cdc.noaa.gov>
	<199606211908.NAA02623@gielgud.lanl.gov.xdiv>

John Turner writes:
 > Mark Borges writes:
 >  > JT> - Although I told configure --error-checking=none, it still says
 >  > JT>   "Compiling in extra code for debugging."  Am I missing something?
 >  > JT>   I seem to remember some discussion about this, but only vaguely.
 >  > 
 >  > Do you use `--debug=no'? I don't see this "Compiling in extra code for
 >  > debugging." note when I do.
 > 
 > I just looked in configure, and it says --debug costs code size but
 > not speed, so I'll just leave that on.
 > 
 >  > JT> - C-a and C-e don't work correctly when truncate-lines is t.
 >  > 
 >  > JT>  1. Set truncate-lines to t and place point on a line that's
 >  > JT>     too long for the frame.
 >  > JT>  2. Hit C-e and you only go to the edge of the screen.  Hit it
 >  > JT>     again and you go to the end of the line.
 >  > JT>  3. Same for C-a.
 >  > 
 >  > JT> What's the deal with that?  Not serious enough to fix?

I don't see this.

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 03:41:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26258 for xemacs-beta-people; Sun, 30 Jun 1996 03:41:13 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26255 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 03:41:11 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA12184; Sun, 30 Jun 1996 03:41:10 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA02684; Sun, 30 Jun 1996 01:39:40 GMT
Date: Sun, 30 Jun 1996 01:39:40 GMT
Message-Id: <199606300139.BAA02684@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: Steven L Baur <steve@miranova.com>
Cc: Chuck Thompson <cthomp@cs.uiuc.edu>, xemacs-beta@cs.uiuc.edu
Subject: Re: loaddefs.el & premature evaluation of environment variables
In-Reply-To: <m2k9x29uwu.fsf@deanna.miranova.com>
References: <199606201837.NAA07632@charles.cs.uiuc.edu>
	<m2k9x29uwu.fsf@deanna.miranova.com>

Steven L. Baur writes:
 > >>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:
 > 
 > Steven> Probably if autoloading a variable means what I think it
 > Steven> means (this is not an area that I've ever explored deeply
 > Steven> in my years of emacsing).
 > 
 > Chuck> autoloading a variable means that it is always bound.  The reason
 > Chuck> browse-url-grail has to be autoloaded is because it is referenced by
 > Chuck> the menubar code.  I tend to doubt if gnus-directory is referenced
 > Chuck> unless someone activates gnus which will cause it be loaded anyhow.
 > 
 > I see.  No, they do not need to be autoloaded.  Is this correct Lars?
 > 
 > What can be done about browse-url-grail then?  Is there something
 > better than assigning a dummy value for loaddefs.el, and then
 > attaching a load hook to stuff the right value in when browse-url is
 > loaded?

I think the standard thing is to autoload a piece of code that
attaches a hook to `before-init-hook' or `after-init-hook' to set the
value.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 03:42:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26263 for xemacs-beta-people; Sun, 30 Jun 1996 03:42:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26260 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 03:42:13 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA01144 for <xemacs-beta@xemacs.org>; Sun, 30 Jun 1996 03:42:08 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA02752; Sun, 30 Jun 1996 01:40:40 GMT
Date: Sun, 30 Jun 1996 01:40:40 GMT
Message-Id: <199606300140.BAA02752@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: Paul Bibilo <peb@delcam.com>
Cc: turner@lanl.gov, xemacs-beta@xemacs.org
Subject: Re: b26 completion error in VM
In-Reply-To: <404.9606201652@dx2.delcam.com>
References: <29709.9606200907@dx2.delcam.com>
	<199606201408.IAA10823@gielgud.lanl.gov.xdiv>
	<404.9606201652@dx2.delcam.com>

Paul Bibilo writes:
 > 
 > John Turner writes:
 >  > Paul Bibilo writes:
 >  > 
 >  >  > I was in VM and decided to edit my .emacs.  I did C-x C-f ~/.em<TAB>
 >  >  > When I hit the tab key it XEmacs bleeped at me and said
 >  >  > Symbols function definition is void: hkey-help-show
 >  > 
 >  > If it's repeatable, I think it helps to set debug-on-error to t and
 >  > repeat to obtain a Lisp backtrace...

This must be coming from Hyperbole (which you've presumably loaded,
right?).

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 04:00:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA26496 for xemacs-beta-people; Sun, 30 Jun 1996 04:00:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA26493 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 04:00:29 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA12325 for <xemacs-beta@cs.uiuc.edu>; Sun, 30 Jun 1996 04:00:29 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA03095; Sun, 30 Jun 1996 01:58:38 GMT
Date: Sun, 30 Jun 1996 01:58:38 GMT
Message-Id: <199606300158.BAA03095@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: "Michael Sperber [Mr. Preprocessor]" <sperber@informatik.uni-tuebingen.de>
Cc: xemacs-beta@cs.uiuc.edu
Subject: b26 success on FreeBSD 2.1.0-RELEASE
In-Reply-To: <9606191338.AA22848@modas.informatik.uni-tuebingen.de>
References: <9606191338.AA22848@modas.informatik.uni-tuebingen.de>

Michael Sperber writes:
 > PPS: Ben's PSGML-HTML stuff is way cool.  Should have said that
 >      earlier, but here goes.  Thanks, Ben.

Sure thing :) I only wish I had more time to fix up some of the
remaining raw edges.  Perhaps someone else wants to tackle this?

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 04:02:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA26510 for xemacs-beta-people; Sun, 30 Jun 1996 04:02:31 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA26507 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 04:02:29 -0500 (CDT)
Received: from nene.boundless.com (boundless.com [205.158.224.46]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA12341 for <xemacs-beta@cs.uiuc.edu>; Sun, 30 Jun 1996 04:02:29 -0500 (CDT)
Received: (from wing@localhost) by nene.boundless.com (8.7.3/8.7.3) id BAA02865; Sun, 30 Jun 1996 01:50:20 GMT
Date: Sun, 30 Jun 1996 01:50:20 GMT
Message-Id: <199606300150.BAA02865@nene.boundless.com>
From: Ben Wing <wing@666.com>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>, rms@gnu.ai.mit.edu,
        Simon.Marshall@esrin.esa.it
Subject: ``XEmacs does not have the features to support lazy-lock.el''
In-Reply-To: <199606200141.SAA27212@xemacs.eng.sun.com>
References: <199606200141.SAA27212@xemacs.eng.sun.com>

Martin Buchholz writes:
 > Here is an excerpt from the recently posted lazy-lock.el, which
 > suggests that XEmacs is deficient...
 > 

[blah blah blah]

Simon Marshall doesn't know what he's talking about and has obviously
not spent the time to verify the accuracy of the assertions he makes,
because many of them are unfounded and some are completely wrong.
The kludges he got RMS to implement are the wrong approach -- they're
completely hackish and not general and don't handle all cases, esp. in
XEmacs where you can have variable-width and variable-height lines.
Besides, they're completely unsafe -- Lisp code is called right in the
middle of redisplay, which violates the Second Golden Rule of
redisplay and is just asking for disaster (if an error, or a throw,
or a C-g, or a garbage collection, or anything similar occurs).

The fundamental thing, of course, is that lazy-lock (as distributed
with XEmacs) *DOES* work fine (and better than any implementation for
FSF Emacs that I've ever seen), and doesn't seem to suffer any of the
supposed problems that Simon attributes to it.

I could write a lengthy message refuting Simon's assertions, but there
doesn't seem any point, seeing as how Simon obviously has no interest
in reasoned debate -- otherwise he would be checking his facts more
carefully and working with the XEmacs people rather than randomly
slamming them.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 04:44:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA26696 for xemacs-beta-people; Sun, 30 Jun 1996 04:44:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA26693 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 04:44:39 -0500 (CDT)
Received: from psilocin.gnu.ai.mit.edu (rms@psilocin.gnu.ai.mit.edu [128.52.46.62]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA12751 for <xemacs-beta@cs.uiuc.edu>; Sun, 30 Jun 1996 04:44:39 -0500 (CDT)
Received: by psilocin.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id FAA03441; Sun, 30 Jun 1996 05:44:21 -0400
Date: Sun, 30 Jun 1996 05:44:21 -0400
Message-Id: <199606300944.FAA03441@psilocin.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: wing@666.com
to: mrb@eng.sun.com, xemacs-beta@cs.uiuc.edu, Simon.Marshall@esrin.esa.it
In-reply-to: <199606300150.BAA02865@nene.boundless.com> (message from Ben Wing
	on Sun, 30 Jun 1996 01:50:20 GMT)
Subject: Re: ``XEmacs does not have the features to support lazy-lock.el''

    The fundamental thing, of course, is that lazy-lock (as distributed
    with XEmacs) *DOES* work fine (and better than any implementation for
    FSF Emacs that I've ever seen)

I don't know how lazy-lock for GNU XEmacs compares with lazy-lock for
GNU Emacs.  But I would like to know; I'd be especially interested in
hearing about any specific situations in which the former does a
better job.  Even a single test case in which the former does a
significantly better job would be useful.  (Please also explain what
about the job is better.)

For any of you who are not unwilling to cooperate with developing
Emacs, this is a chance to help improve Emacs with a small amount of
work.


From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 06:47:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA27039 for xemacs-beta-people; Sun, 30 Jun 1996 06:47:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA27036 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 06:47:19 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA15222 for <xemacs-beta@cs.uiuc.edu>; Sun, 30 Jun 1996 06:47:18 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id UAA02592; Sun, 30 Jun 1996 20:47:09 +0900 (JST)
Message-Id: <199606301147.UAA02592@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: 20.0 XEmacs Lucid (beta26)
From: =?ISO-2022-JP?B?GyQoQjxpMiwbKEIgGyQoQkNOSScbKEI=?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: xemacs-beta@cs.uiuc.edu
Subject: [20.0/mule] filling
Mime-Version: 1.0 (SEMI mime-edit 0.28)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Sun_Jun_30_20:46:33_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Sun, 30 Jun 1996 20:47:12 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Sun_Jun_30_20:46:33_1996-1
Content-Type: text/plain; charset=US-ASCII

  I'm trying to use XEmacs/mule for daily use. So now I use it.

  I find a problem about filling for Japanese character.

  Normally in plain text, Japanese, Chinese and Korean character is
counted as 2 ASCII characters. However in XEmacs, length of each
character is 1. So filling does not work fine.

  I think such code should use character or string columns or
pixel-width instead of point or length directly.

  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---

--pgp-sign-Multipart_Sun_Jun_30_20:46:33_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.2i
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMdZpKxnuUGV7wuH5AQH9swQAijE5Dlj3U3XRyHmo+Nhm7HOoO8fsRXwG
ep5B7kVCwoGinszhZnOXkXpORXZJAxNCY6+7I4/Ar+yYFtHXQoNRL6+yxxPMNQxJ
Ud4/HRfqhN0LLTKOF7Irb+EvS2QlhXlbMmRpHLUJdK+0rGPlW7XiXaAxE5SPb69k
Lh96VlswAt8=
=/MfO
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Sun_Jun_30_20:46:33_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 10:35:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA27843 for xemacs-beta-people; Sun, 30 Jun 1996 10:35:05 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA27840 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 10:35:04 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA22070 for <xemacs-beta@cs.uiuc.edu>; Sun, 30 Jun 1996 10:35:04 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id AAA09907; Mon, 1 Jul 1996 00:34:54 +0900 (JST)
Message-Id: <199606301534.AAA09907@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.63, tm-view 7.65
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [20.0/mule] filling 
In-reply-to: Your message of "Sun, 30 Jun 1996 20:47:12 JST."
             <199606301147.UAA02592@mikan.jaist.ac.jp> 
Mime-Version: 1.0 (SEMI mime-edit 0.28)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Mon_Jul__1_00:34:15_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Mon, 01 Jul 1996 00:34:59 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Mon_Jul__1_00:34:15_1996-1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>>>>> In <199606301147.UAA02592@mikan.jaist.ac.jp>
>>>>>=09MORIOKA Tomohiko <morioka@jaist.ac.jp> wrote:

tomo>   I'm trying to use XEmacs/mule for daily use. So now I use it.

tomo>   I find a problem about filling for Japanese character.

tomo>   Normally in plain text, Japanese, Chinese and Korean character
tomo> is counted as 2 ASCII characters. However in XEmacs, length of
tomo> each character is 1. So filling does not work fine.

tomo>   I think such code should use character or string columns or
tomo> pixel-width instead of point or length directly.

  In addition, in Japanese and Chinese text, no spaces are required
between words. So one Japanese and Chinese character should regard as
one word of European languages.

  XEmacs/mule supports multi-script displaying, however multi-lingual
and Internationalization features seem not complete. (Maybe they were
cut off when merging) We must restore these MULE features.

  In addition, XEmacs supports multi-fonts, we can use variable width
fonts, however a lot of elisps expect one kind of fixed width
font. They uses `length' or point to calculate width. I think we
should rewrite such codes. They are old fashioned. (I want pixel width
functions: for example, return pixel-width of string, truncate string
by pixel width, move by pixel width, ...)


  By the way, can XEmacs support vertical line text? Japanese, Chinese
and Korean text can write vertical line (lines are growing to
right-to-left). Mongolian text must write vertically (lines is growing
to left-to-right). There are four writing directions in the world:

  (h) horizontal
      (h-0) left-to-right ; Latin*, Greek*, Cyrillic*, Georgian,
=09=09=09    Armenian, Devanagari, Gurmukhi, Gujarati,
=09=09=09    Oriya, Bengali, Tamil, Telugu, Kannada,
=09=09=09    Malayalam, Sinhalese, Burmese, Khmer, Thai*,
=09=09=09    Lao, Chinese*, Japanese*, Korean*, Chu-N=F4m,
=09=09=09    Tibetan, Amharic*
      (h-1) right-to-left ; Arabic*, Hebrew*, Urdu, Maldivian
  (v) vertical
      (v-0) right-to-left ; Chinese, Japanese, Korean, Chu-N=F4m
      (v-1) left-to-right ; Mongolian

=09(* is supported by mule)

In addition, historically, there were down-to-up vertical text, or
rongo-rongo way (direction is changed at every line breaks). Anyway,
modern scripts may be classified these 4 types.
=09
  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key=

--pgp-sign-Multipart_Mon_Jul__1_00:34:15_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.2i
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMdaehhnuUGV7wuH5AQE4wQQAtr3xOkuaqXgSvB9bjg7X8jMCjalWMTZD
7qIJJLKkewIJwysstg9X0Qw3HfC8ER2FNZC9fCvBcFf2fCu4tVO/29/xAbwKEgKN
IfHIttOq5GHqCadwrkuyVWpN0RKHcNT9GVYF5kIUou+5jNuwZuIZtXs+BsF7NrmV
P5o4zTyD+X0=
=5E53
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Mon_Jul__1_00:34:15_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 11:43:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA28158 for xemacs-beta-people; Sun, 30 Jun 1996 11:43:43 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA28155 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 11:43:42 -0500 (CDT)
Received: from hackvan.com (hackvan.com [206.80.31.242]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA24351 for <xemacs-beta@cs.uiuc.edu>; Sun, 30 Jun 1996 11:43:43 -0500 (CDT)
Received: by hackvan.com (Linux Smail3.1.29.1 #27)
	id m0uaPZm-000HE5C; Sun, 30 Jun 96 09:42 PDT
Message-Id: <m0uaPZm-000HE5C@hackvan.com>
Date: Sun, 30 Jun 96 09:42 PDT
From: stig@hackvan.com (Stig)
To: xemacs-beta@cs.uiuc.edu
Subject: Re: ``XEmacs does not have the features to support lazy-lock.el''
In-Reply-To: <199606300944.FAA03441@psilocin.gnu.ai.mit.edu>
References: <199606300150.BAA02865@nene.boundless.com>
	<199606300944.FAA03441@psilocin.gnu.ai.mit.edu>
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/

Richard Stallman wrote:
> 
> For any of you who are not unwilling to cooperate with developing
> Emacs, this is a chance to help improve Emacs with a small amount of
> work.
> 

I suppose that UTSL is a good answer (Use The Source, Luke!)...  Why does he
always need to have things _explained_ to him?

    Stig
    

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 15:31:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA29254 for xemacs-beta-people; Sun, 30 Jun 1996 15:31:07 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA29251 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 15:31:06 -0500 (CDT)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA26674 for <xemacs-beta@cs.uiuc.edu>; Sun, 30 Jun 1996 15:31:07 -0500 (CDT)
Received: from ylfing.ifi.uio.no (ylfing.ifi.uio.no [129.240.94.25]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <WAA25836@ifi.uio.no> ; Sun, 30 Jun 1996 22:30:35 +0200
Received: (from larsi@localhost) by ylfing.ifi.uio.no ; Sun, 30 Jun 1996 22:30:34 +0200
To: Neal Becker <Neal.Becker@comsat.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: gnus problems in 19.14
References: <199606281341.OAA10153@wrath.parallax.co.uk>
	<w8sivcbad29.fsf@ylfing.ifi.uio.no>
	<E0uZqT2-0004fN-00@neal.ctd.comsat.com>
X-Face: &w!^oO<W.WBH]FsTP:P0f9X6M-ygaADlA_)eF$<UwQzj7:C=Gi<a?/_4$LX^@$Qq7-O&XHp
	lDARi8e8iT<(A$LWAZD*xjk^')/wI5nG;1cNB>~dS|}-P0~ge{$c!h\<y
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Date: 30 Jun 1996 22:30:32 +0200
In-Reply-To: Neal Becker's message of Fri, 28 Jun 1996 23:13:04 -0400
Message-ID: <w8spw6hkpav.fsf@ylfing.ifi.uio.no>
Lines: 14
X-Mailer: Gnus v5.2.32/Emacs 19.31

Neal Becker <Neal.Becker@comsat.com> writes:

> On my Linux box I have hostname set without domainname, but in .emacs
> I have
> 
> (setq gnus-local-domain "ctd.comsat.com")
> 
> So why do I get a From: hostname generated without the domainname?

Use `mail-host-address' or `user-mail-address' instead.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 15:40:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA29265 for xemacs-beta-people; Sun, 30 Jun 1996 15:40:01 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA29262 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 15:40:00 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA03873 for <xemacs-beta@xemacs.org>; Sun, 30 Jun 1996 15:39:56 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id OAA14662; Sun, 30 Jun 1996 14:39:59 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id OAA14067; Sun, 30 Jun 1996 14:39:57 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id OAA05421; Sun, 30 Jun 1996 14:39:30 -0600
Date: Sun, 30 Jun 1996 14:39:30 -0600
Message-Id: <199606302039.OAA05421@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: VM weirdness
Reply-To: turner@lanl.gov

19.14, Solaris 2.5, CDE 1.0.1
precompiled binaries for Solaris 2.4 w/SPARCworks

---

This is going to be a pathetic bug report, but it's really weird, and
I just wondered if anyone else is seeing it.

o I've only seen this with VM.

o Visit another folder via the toolbar... new frame.

o Close that frame.

Now, whenever I open that 2nd frame, something new and wonderful
happens.  Actually, it's only been one of two things.  It either:

o opens a new frame as if I'd hit the Visit button on the toolbar, or

o it fires of a print job, as if I'd hit the Print button on the
  toolbar. 

Now I've got a frame around right now for which this happens every
time I've opened it... either a Visit or a Print.

Well I just noticed that depending on where my mouse is sitting on the
icon when I double click to open, when the frame opens, guess where
the mouse is sitting... that's right, either over the Print or the
Visit toolbar buttons.

I never saw this with the betas, but I must admit that this isn't
something I do terribly often.

Any ideas as to what might be happening?

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Sun Jun 30 21:10:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA00479 for xemacs-beta-people; Sun, 30 Jun 1996 21:10:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA00476 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 30 Jun 1996 21:10:02 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA04608 for <xemacs-beta@xemacs.org>; Sun, 30 Jun 1996 21:09:58 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id UAA20351; Sun, 30 Jun 1996 20:10:00 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id UAA14864; Sun, 30 Jun 1996 20:09:56 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id UAA05729; Sun, 30 Jun 1996 20:09:29 -0600
Date: Sun, 30 Jun 1996 20:09:29 -0600
Message-Id: <199607010209.UAA05729@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: wing@666.com
Cc: xemacs-beta@xemacs.org
Subject: Re: 19.14p1: Solaris 2.5, SunPro CC 4.0, CDE
In-Reply-To: <199606300135.BAA02532@nene.boundless.com>
References: <199606211516.JAA08613@gielgud.lanl.gov.xdiv>
	<vkd92txgps.fsf@cdc.noaa.gov>
	<199606211908.NAA02623@gielgud.lanl.gov.xdiv>
	<199606300135.BAA02532@nene.boundless.com>
Reply-To: turner@lanl.gov

Ben Wing writes:
 > John Turner writes:
 >  > 
 >  > - C-a and C-e don't work correctly when truncate-lines is t.
 >  > 
 >  >  1. Set truncate-lines to t and place point on a line that's
 >  >     too long for the frame.
 >  >  2. Hit C-e and you only go to the edge of the screen.  Hit it
 >  >     again and you go to the end of the line.
 >  >  3. Same for C-a.
 >  > 
 >  > What's the deal with that?  Not serious enough to fix?
 > 
 > I don't see this.

Well, shioot.  I don't either when I start with -q.  So someone's not
playing nicely together.

Does anyone else see this?  Maybe we can figure out what we're both
doing to cause it...

-John

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 02:53:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA01482 for xemacs-beta-people; Mon, 1 Jul 1996 02:53:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA01479 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 02:53:26 -0500 (CDT)
Received: from hackvan.com (hackvan.com [206.80.31.242]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA05288 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 02:53:24 -0500 (CDT)
Received: by hackvan.com (Linux Smail3.1.29.1 #27)
	id m0uadY2-000HE5C; Mon, 1 Jul 96 00:37 PDT
Message-Id: <m0uadY2-000HE5C@hackvan.com>
Date: Mon, 1 Jul 96 00:37 PDT
From: stig@hackvan.com (Stig)
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: Better way to Save Options....
In-Reply-To: <199606222256.QAA07481@gielgud.lanl.gov.xdiv>
References: <199606222256.QAA07481@gielgud.lanl.gov.xdiv>
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/


This is such an excellent idea, that I think Save Options ought to save
options to differrent files for each version of emacs.  Upon startup, if
there's no options file for the current version of xemacs, then check to see
if there's one for a previous version and load that...

    Stig

John Turner wrote:
> 
> The format for Save Options changed between 19.13 and 19.14.  If you
> wish to use both versions, to the following:
> 
> 1) First, save the portion at the end of your .emacs that was created
>    by Save Options under XEmacs 19.13 as a new file, say
>    .xemacs-options-19.13.  That is, everything between, and including,
>    the lines: 
> 
> ;; Options Menu Settings
> ;; =====================
> 
> and
> 
> ;; ============================
> ;; End of Options Menu Settings
> 
> 2) Then add this bit of code in its place:
> 
> ;; Load options for XEmacs 19.13.
> (if (= emacs-minor-version 13)
>     (load "~/.xemacs-options-19.13"))
> 
>    When you use 19.14 and use Save Options, it will create a file
>    called .xemacs-options in which settings for 19.14 will be saved,
>    and a bit of code will be written to your .emacs to load that file
>    only if you are running 19.14.

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 03:21:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA04972 for xemacs-beta-people; Mon, 1 Jul 1996 03:21:45 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA04969 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 03:21:43 -0500 (CDT)
Received: from hackvan.com (hackvan.com [206.80.31.242]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA05377 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 03:21:39 -0500 (CDT)
Received: by hackvan.com (Linux Smail3.1.29.1 #27)
	id m0uaeCk-000HE5C; Mon, 1 Jul 96 01:19 PDT
Message-Id: <m0uaeCk-000HE5C@hackvan.com>
Date: Mon, 1 Jul 96 01:19 PDT
From: stig@hackvan.com (Stig)
To: drich@cisco.com
Cc: xemacs-beta@xemacs.org
Subject: Re: gnuattach weirdness
In-Reply-To: <199606220148.SAA19503@sandman.cisco.com>
References: <199606220148.SAA19503@sandman.cisco.com>
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/

Dan Rich wrote:
> 
> I just found two problems using gnuattach (and I think someone already
> mentioned the first, but I never saw any discussion about it).
> 
> If you run gnuattach with no arguments, there is no way to exit that I
> can find.  C-x # won't do it, and C-x C-c kills the XEmacs process (as
> you would expect).

This may seem cretinous, but I think that with the advent of multiple
devices--and _particularly_ with all devices opened as a result of
gnuattach--the keystrokes that used to kill emacs should only cause it to
close all windows on the current device.

Logically, gnuattach is going to be viewed as a way to run emacs without
having to wait for it to start.  It should have the same basic keybindings
and behavior as a new emacs, within reason.  'C-x #' is an uncomfortable
user-interface change to push upon people who just want a faster way to
start emacs.


Also, some thought should be given to having a -server flag for xemacs that
causes to run gnuserv and not open a single device until later invocations
of gnuattach.  (Yes, I know that you can use -iconic to make it iconify...)

    Stig
    

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 04:22:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA05271 for xemacs-beta-people; Mon, 1 Jul 1996 04:22:52 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA05268 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 04:22:51 -0500 (CDT)
Received: from hackvan.com (hackvan.com [206.80.31.242]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA12722; Mon, 1 Jul 1996 04:22:49 -0500 (CDT)
Received: by hackvan.com (Linux Smail3.1.29.1 #27)
	id m0uaf9u-000HE5C; Mon, 1 Jul 96 02:20 PDT
Message-Id: <m0uaf9u-000HE5C@hackvan.com>
Date: Mon, 1 Jul 96 02:20 PDT
From: stig@hackvan.com (Stig)
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: loaddefs.el & premature evaluation of environment variables 
In-Reply-To: <199606201816.NAA07505@charles.cs.uiuc.edu>
References: <m2ohme9ybv.fsf@deanna.miranova.com>
	<199606201816.NAA07505@charles.cs.uiuc.edu>
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/

Chuck Thompson wrote:
> 
>     Steven> When a variable is designated as autoload, it gets its
>     Steven> definition pushed into prim/loaddefs.el, which gets
>     Steven> evaluated when XEmacs is dumped, and the environment
>     Steven> variables contain no useful information.
> 
>     Steven> Besides gnus-directory, message-user-organization, and
>     Steven> browse-url-grail have the same problem.
> 
> browse-url-grail has to be autoloaded at the moment but do the others?
> 
> 			-Chuck

It's good to autoload them just so that their docstrings are available
before the packages are loaded.  They can be initialized from
before-init-hook.

    Stig
    

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 06:29:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA05821 for xemacs-beta-people; Mon, 1 Jul 1996 06:29:09 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA05818 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 06:29:03 -0500 (CDT)
Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA15478; Mon, 1 Jul 1996 06:29:03 -0500 (CDT)
Received: from djp-fornet.cern.ch (djp-fornet.cern.ch [137.138.36.141]) by server21.digital.fr (8.7.5/8.7) with SMTP id NAA18425; Mon, 1 Jul 1996 13:20:52 +0200 (MET DST)
Received: by djp-fornet.cern.ch; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA03614; Mon, 1 Jul 1996 13:18:10 +0200
Date: Mon, 1 Jul 1996 13:18:10 +0200
Message-Id: <9607011118.AA03614@djp-fornet.cern.ch>
From: Stephen Carney <carney@cs.uiuc.edu>
To: Chuck Thompson <cthomp@cs.uiuc.edu>
Cc: andyp@parallax.co.uk (Andy Piper), xemacs-beta@cs.uiuc.edu
Subject: Re: annoying market bug 
In-Reply-To: <199606271636.LAA27238@charles.cs.uiuc.edu>
References: <199606271630.RAA27312@wrath.parallax.co.uk>
	<199606271636.LAA27238@charles.cs.uiuc.edu>
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

cthomp@cs.uiuc.edu (Chuck Thompson) writes,
in <199606271636.LAA27238@charles.cs.uiuc.edu>:

>Do you have line-number-mode turned on?  If so, try turning it off.
>I've spent a grand total of 30 seconds looking into this but I
>wouldn't be surprised if the answer is to add the following line to
>the beginning of real_current_modeline_height in redisplay.c:
>
>  Fset_marker (w->pointm[CMOTION_DISP], w->pointm[CURRENT_DISP], w->buffer);

I had line-number-mode turned on and was seeing the error.  After just a
little testing, the patch seems to work for me.  Previously, when I'd
MB2 on an article in a GNUS summary buffer, I'd get the error.

        Steve

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 06:15:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA05741 for xemacs-beta-people; Mon, 1 Jul 1996 06:15:53 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA05738 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 06:15:51 -0500 (CDT)
Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA05803 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 06:15:47 -0500 (CDT)
Received: from djp-fornet.cern.ch (djp-fornet.cern.ch [137.138.36.141]) by server21.digital.fr (8.7.5/8.7) with SMTP id NAA03725 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 13:16:24 +0200 (MET DST)
Received: by djp-fornet.cern.ch; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA03572; Mon, 1 Jul 1996 13:13:17 +0200
Date: Mon, 1 Jul 1996 13:13:17 +0200
Message-Id: <9607011113.AA03572@djp-fornet.cern.ch>
From: Stephen Carney <carney@xemacs.org>
To: xemacs-beta@xemacs.org
Subject: dump after loading man
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

In 19.14, I did "M-x man <some-man-entry>", which loaded man, then
dumped.  

        Steve


% dbx /usr/local/xemacs/bin/xemacs-19.14 core
dbx version 3.11.8
Type 'help' for help.
Core file created by program "xemacs-19.14"

signal IOT/Abort trap at >*[__kill, 0x3ff8010ce68] 	beq	r19, 0x3ff8010ce80
(dbx) where
>  0 __kill(0x120086838, 0x6, 0x0, 0x14047b1281, 0x11fff9d00) [0x3ff8010ce68]
   1 fatal_error_signal(sig = 644) ["emacs.c":193, 0x1200868c0]
   2 __kill(0x0, 0x3f, 0x0, 0x0, 0x0) [0x3ff8010ce64]
   3 raise(0x6, 0x0, 0x2, 0x11fff9548, 0x3f) [0x3ff80121830]
   4 abort(0x7c04, 0x3ff800e0ca8, 0x3f, 0x120086800, 0x0) [0x3ff8010fc80]
   5 assert_failed(file = 0x284, line = 6, expr = 0x11fff9b38 = "") ["emacs.c":1830, 0x120088f2c]
   6 signal_1(sig = (...), data = (...)) ["eval.c":1903, 0x12008cb74]
   7 signal_error(sig = (...), data = (...)) ["eval.c":2080, 0x12008d448]
   8 dead_wrong_type_argument(predicate = (...), value = (...)) ["data.c":105, 0x12006ea24]
   9 decode_console(console = (...)) ["console.c":178, 0x12006b26c]
  10 Fselected_device(console = (...)) ["device.c":244, 0x120076514]
  11 selected_frame() ["frame.c":691, 0x1200db7ac]
  12 garbage_collect_1() ["alloc.c":3856, 0x12005588c]
  13 funcall_recording_as(recorded_as = (...), nargs = 4, args = 0x11fff9f58) ["eval.c":3128, 0x12009110c]
  14 call3(fn = (...), arg0 = (...), arg1 = (...), arg2 = (...)) ["eval.c":4025, 0x120093be0]
  15 Fexpand_file_name(name = (...), defalt = (...)) ["fileio.c":906, 0x1200c096c]
  16 Fdo_auto_save(no_message = (...), current_only = (...)) ["fileio.c":4294, 0x1200c949c]
  17 shut_down_emacs(sig = 11, stuff = (...)) ["emacs.c":1553, 0x1200888e4]
  18 fatal_error_signal(sig = 644) ["emacs.c":170, 0x1200868a0]
  19 mark_object(obj = (...)) ["alloc.c":2756, 0x120053bb0]
  20 garbage_collect_1() ["alloc.c":3973, 0x120055d10]
  21 funcall_recording_as(recorded_as = (...), nargs = 3, args = 0x11fffa668) ["eval.c":3128, 0x12009110c]
  22 call2(fn = (...), arg0 = (...), arg1 = (...)) ["eval.c":4008, 0x120093b4c]
  23 Ffile_name_as_directory(file = (...)) ["fileio.c":629, 0x1200c036c]
  24 Fdirectory_files(dirname = (...), full = (...), match = (...), nosort = (...), files_only = (...)) ["dired.c":94, 0x1200795f4]
  25 primitive_funcall(fn = 0x1403fb190, nargs = 537213696, args = 0x1) ["eval.c":3492, 0x12009241c]
  26 funcall_subr(subr = 0x1, args = 0x120053b00) ["eval.c":3526, 0x1200926a8]
  27 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fffabd0) ["eval.c":3207, 0x120091554]
  28 Fapply(nargs = 2, args = 0x11fffad78) ["eval.c":3471, 0x1200922e0]
  29 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffad70) ["eval.c":3191, 0x1200914c0]
  30 Ffuncall(nargs = 1, args = 0x120053b00) ["eval.c":3253, 0x1200917e4]
  31 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x1200611bc]
  32 funcall_lambda(fun = (...), nargs = 6, arg_vector = 0x11fffb2f0) ["eval.c":3636, 0x120092ff4]
  33 funcall_recording_as(recorded_as = (...), nargs = 6, args = 0x11fffb2e8) ["eval.c":3223, 0x120091708]
  34 call6(fn = (...), arg0 = (...), arg1 = (...), arg2 = (...), arg3 = (...), arg4 = (...), arg5 = (...)) ["eval.c":4084, 0x120093dbc]
  35 Fdirectory_files(dirname = (...), full = (...), match = (...), nosort = (...), files_only = (...)) ["dired.c":82, 0x12007956c]
  36 primitive_funcall(fn = 0x1403fb190, nargs = 537213696, args = 0x1) ["eval.c":3492, 0x12009241c]
  37 funcall_subr(subr = 0x1, args = 0x120053b00) ["eval.c":3526, 0x1200926a8]
  38 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fffb840) ["eval.c":3207, 0x120091554]
  39 Ffuncall(nargs = 1, args = 0x120053b00) ["eval.c":3253, 0x1200917e4]
  40 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x1200611bc]
  41 funcall_lambda(fun = (...), nargs = 5, arg_vector = 0x11fffbdc0) ["eval.c":3636, 0x120092ff4]
  42 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fffbdb8) ["eval.c":3223, 0x120091708]
  43 Ffuncall(nargs = 1, args = 0x120053b00) ["eval.c":3253, 0x1200917e4]
  44 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x1200611bc]
  45 funcall_lambda(fun = (...), nargs = 2, arg_vector = 0x11fffc320) ["eval.c":3636, 0x120092ff4]
  46 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffc318) ["eval.c":3223, 0x120091708]
  47 Fapply(nargs = 2, args = 0x11fffc400) ["eval.c":3471, 0x1200922e0]
  48 apply1(fn = (...), arg = (...)) ["eval.c":3968, 0x1200939b8]
  49 Fcall_interactively(function = (...), record_flag = (...), keys = (...)) ["callint.c":389, 0x1200635bc]
  50 Fcommand_execute(cmd = (...), record = (...), keys = (...)) ["eval.c":2628, 0x12008fa84]
  51 primitive_funcall(fn = 0x1403fb190, nargs = 537213696, args = 0x1) ["eval.c":3488, 0x1200923d0]
  52 funcall_subr(subr = 0x1, args = 0x120053b00) ["eval.c":3526, 0x1200926a8]
  53 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffc840) ["eval.c":3204, 0x120091544]
  54 Ffuncall(nargs = 1, args = 0x120053b00) ["eval.c":3253, 0x1200917e4]
  55 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x1200611bc]
  56 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffcde0) ["eval.c":3636, 0x120092ff4]
  57 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffcdd8) ["eval.c":3223, 0x120091708]
  58 Ffuncall(nargs = 1, args = 0x120053b00) ["eval.c":3253, 0x1200917e4]
  59 Fcall_interactively(function = (...), record_flag = (...), keys = (...)) ["callint.c":896, 0x12006515c]
  60 Fcommand_execute(cmd = (...), record = (...), keys = (...)) ["eval.c":2628, 0x12008fa84]
  61 execute_command_event(command_builder = 0x140538c00, event = (...)) ["event-stream.c":3480, 0x1200a4804]
  62 Fdispatch_event(event = (...)) ["event-stream.c":3765, 0x1200a52c8]
  63 Fcommand_loop_1() ["cmdloop.c":542, 0x120069944]
  64 command_loop_1(dummy = (...)) ["cmdloop.c":462, 0x120069684]
  65 condition_case_1(handlers = (...), bfun = 0x120069648, barg = (...), hfun = 0x120069ba0, harg = (...)) ["eval.c":1672, 0x12008c300]
  66 command_loop_2(dummy = (...)) ["cmdloop.c":235, 0x120069d7c]
  67 internal_catch(tag = (...), func = 0x120053b00, arg = (...), threw = (nil)) ["eval.c":1347, 0x12008bf2c]
  68 Frecursive_edit() ["cmdloop.c":336, 0x1200695cc]
  69 primitive_funcall(fn = 0x1403fb190, nargs = 537213696, args = 0x1) ["eval.c":3482, 0x120092374]
  70 funcall_subr(subr = 0x1, args = 0x120053b00) ["eval.c":3526, 0x1200926a8]
  71 funcall_recording_as(recorded_as = (...), nargs = 0, args = 0x11fffdad0) ["eval.c":3207, 0x120091554]
  72 Ffuncall(nargs = 1, args = 0x120053b00) ["eval.c":3253, 0x1200917e4]
  73 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x1200611bc]
  74 primitive_funcall(fn = 0x1403fb190, nargs = 537213696, args = 0x1) ["eval.c":3488, 0x1200923d0]
  75 funcall_subr(subr = 0x1, args = 0x120053b00) ["eval.c":3526, 0x1200926a8]
  76 Feval(form = (...)) ["eval.c":3064, 0x120090d54]
  77 Fprogn(args = (...)) ["eval.c":746, 0x12008a324]
  78 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":633, 0x1200616ac]
  79 funcall_lambda(fun = (...), nargs = 2, arg_vector = 0x11fffe740) ["eval.c":3636, 0x120092ff4]
  80 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffe738) ["eval.c":3223, 0x120091708]
  81 Fapply(nargs = 2, args = 0x11fffe820) ["eval.c":3471, 0x1200922e0]
  82 apply1(fn = (...), arg = (...)) ["eval.c":3968, 0x1200939b8]
  83 call_debugger_259(arg = (...)) ["eval.c":337, 0x1200976b0]
  84 internal_catch(tag = (...), func = 0x120053b00, arg = (...), threw = (nil)) ["eval.c":1347, 0x12008bf2c]
  85 call_debugger(arg = (...)) ["eval.c":391, 0x12008966c]
  86 signal_call_debugger(conditions = (...), sig = (...), data = (...), active_handlers = (...), signal_vars_only = 75172993, stack_trace_displayed = 0x11fffece8, debugger_entered = 0x11fffecec) ["eval.c":541, 0x120089a60]
  87 signal_1(sig = (...), data = (...)) ["eval.c":1972, 0x12008cdcc]
  88 Fsignal(error_symbol = (...), data = (...)) ["eval.c":2071, 0x12008d30c]
  89 Fdispatch_event(event = (...)) ["event-stream.c":3731, 0x1200a510c]
  90 Fcommand_loop_1() ["cmdloop.c":542, 0x120069944]
  91 command_loop_1(dummy = (...)) ["cmdloop.c":462, 0x120069684]
  92 condition_case_1(handlers = (...), bfun = 0x120069648, barg = (...), hfun = 0x120069ba0, harg = (...)) ["eval.c":1672, 0x12008c300]
  93 command_loop_2(dummy = (...)) ["cmdloop.c":235, 0x120069d7c]
  94 internal_catch(tag = (...), func = 0x120053b00, arg = (...), threw = (nil)) ["eval.c":1347, 0x12008bf2c]
  95 initial_command_loop(load_me = (...)) ["cmdloop.c":273, 0x120069194]
  96 Frunning_temacs_p() ["emacs.c":1317, 0x1200881c4]
(dbx) 

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 08:06:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA06101 for xemacs-beta-people; Mon, 1 Jul 1996 08:06:36 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA06098 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 08:06:28 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA19581 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 08:06:19 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id OAA22965 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 14:07:54 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id OAA24758 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 14:07:31 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id OAA02431; Mon, 1 Jul 1996 14:11:02 +0100
Date: Mon, 1 Jul 1996 14:11:02 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199607011311.OAA02431@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: b26 patch problems
X-Sun-Charset: US-ASCII

Did anyone else get patch complaining about a malformed patch for 20.0 b26?

andy

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 10:39:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA07065 for xemacs-beta-people; Mon, 1 Jul 1996 10:39:50 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA07062 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 10:39:49 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA06925 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 10:39:46 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id JAA04258; Mon, 1 Jul 1996 09:39:47 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id JAA19449; Mon, 1 Jul 1996 09:39:45 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id JAA06410; Mon, 1 Jul 1996 09:39:17 -0600
Date: Mon, 1 Jul 1996 09:39:17 -0600
Message-Id: <199607011539.JAA06410@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: Save Options
Reply-To: turner@lanl.gov

Perusing comp.emacs.xemacs, it seems that people fairly frequently are
changing things via Options, esp. Edit Faces, and forgetting to Save
Options.

How difficult would it be to give a warning prior to quitting that
Options have been modified but not saved?

Or maybe the whole idea of it being a menu should be rethought.  Maybe
it should be a new frame (or set of frames), and to quit the frame you
either confirm the changes (triggering a Save Options) or simply quit.

I could do it in Tcl/Tk, but not elisp.  :)

Actually, there is something sort of related to this already written
in Tcl/Tk.  It's called The Dotfile Generator.  Take a look at:

http://www.imada.ou.dk/~blackie/dotfile/

Something along those lines, but integrated, might be nice.

Just musing (probably should have sent this to -discuss; is it still
alive?)...

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 11:01:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA07164 for xemacs-beta-people; Mon, 1 Jul 1996 11:01:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA07159 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 11:01:36 -0500 (CDT)
Received: from gcm.com (gcm.com [146.121.48.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA07091 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 11:01:24 -0500 (CDT)
Received: (from uucp@localhost) by gcm.com (8.6.9/8.6.9) with UUCP id MAA10363; Mon, 1 Jul 1996 12:04:57 -0400
Received: from gsdws023.it.gcm.com by gcm.com (4.1/GCM-2.0m)
	id AA07682; Mon, 1 Jul 96 11:46:07 EDT
Received: by gsdws023.it.gcm.com (4.1/SMI-4.1)
	id AA02174; Mon, 1 Jul 96 11:46:06 EDT
Sender: dcw@gcm.com
To: Ben Wing <wing@666.com>
Cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: Really slow XEmacs
References: <amzq5rrd9k.fsf@gcm.com>
	<199606300122.BAA02108@nene.boundless.com>
From: David Worenklein <dcw@gcm.com>
Date: 01 Jul 1996 11:46:06 -0400
In-Reply-To: Ben Wing's message of Sun, 30 Jun 1996 01:22:17 GMT
Message-Id: <amwx0oht8h.fsf@gcm.com>
Lines: 48
X-Mailer: Gnus v5.2.25/XEmacs 19.14

>>>>> "Ben" == Ben Wing <wing@666.com> writes:
	David Worenklein writes:
    >> I found that as soon as I start sql-mode (and, particularly,
    >> within sql-mode) typing slows to an unusable speed.  So I
    >> quantified XEmacs, typed about two hundred random characters,
    >> and found that readchar (in lread.c) was called five MILLION
    >> times from read1.  read1 took 35.25% of the time, and readchar
    >> took about half of that.
    >> 
    >> I've never really delved into the C code, but what the hell
    >> would you want to do 25,000 times per keystroke?

    Ben>  How many times per keystroke is Fread() or
    Ben> Fread_from_string() called?  That's what's important.  Is
    Ben> SQL-mode installing a post-command-hook that does `read'?

No, the only hooks are pending-delete-pre-hook and 
eldoc-mode-print-current-symbol-info, neither one of which seem to be
slowing down the system (based on elp results) The big difference I
can find is font-locking. font-lock-fontify-glumped-region takes more
than twice as long!

19.13
Function Name                          Call Count  Elapsed Time  Average Time
=====================================  ==========  ============  ============
font-lock-after-change-function        37          0.7086810000  0.0191535405
font-lock-fontify-glumped-region       37          0.6394399999  0.0172821621
font-lock-after-change-function-1      37          0.5731430000  0.0154903513
font-lock-hack-keywords                37          0.3924050000  0.0106055405
font-lock-fontify-region               37          0.0309899999  0.0008375675
font-lock-pre-command-hook             43          0.0139789999  0.0003250930
font-lock-post-command-hook            43          0.0136109999  0.0003165348

19.14
Function Name                          Call Count  Elapsed Time  Average Time
=====================================  ==========  ============  ============
font-lock-pre-idle-hook                56          1.3843780000  0.0247210357
font-lock-fontify-glumped-region       36          1.3202649999  0.0366740277
font-lock-after-change-function-1      36          1.2375010000  0.0343750277
font-lock-fontify-region               36          1.1411559999  0.0316987777
font-lock-fontify-keywords-region      36          0.8614039999  0.0239278888
font-lock-fontify-syntactically-region 36          0.1676269999  0.0046563055
self-insert-command                    46          0.1366160000  0.0029699130
font-lock-unfontify-region             36          0.0888930000  0.0024692500
font-lock-after-change-function        36          0.0432099999  0.0012002777
pending-delete-pre-hook                49          0.0399510000  0.0008153265
eldoc-mode-print-current-symbol-info   48          0.0247540000  0.0005157083


From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 13:51:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA08496 for xemacs-beta-people; Mon, 1 Jul 1996 13:51:13 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA08493 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 13:51:12 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA02912 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 13:51:06 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA01113; Mon, 1 Jul 1996 11:50:22 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: b26 success on FreeBSD 2.1.0-RELEASE
References: <9606191338.AA22848@modas.informatik.uni-tuebingen.de>
	<199606300158.BAA03095@nene.boundless.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Ben Wing's message of Sun, 30 Jun 1996 01:58:38 GMT
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 01 Jul 1996 11:50:21 -0700
Message-ID: <m2enmv95aq.fsf@deanna.miranova.com>
Lines: 19
X-Mailer: Gnus v5.2.32/XEmacs 20.0

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

Ben> Michael Sperber writes:
>> PPS: Ben's PSGML-HTML stuff is way cool.  Should have said that
>> earlier, but here goes.  Thanks, Ben.

Ben> Sure thing :) I only wish I had more time to fix up some of the
Ben> remaining raw edges.  Perhaps someone else wants to tackle this?

Absolutely.  I'd also like to see it sync'ed up with a later
pgsml-mode.  I think I can clean it up by 19.15 even if 19.15 is a
bug fix/fast track release (though not necessarily sync'ed up with
1a11 or later).

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 13:43:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA08440 for xemacs-beta-people; Mon, 1 Jul 1996 13:43:20 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA08437 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 13:43:17 -0500 (CDT)
Received: from tuminfo2.informatik.tu-muenchen.de (root@tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA07839 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 13:43:02 -0500 (CDT)
Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26516-1>; Mon, 1 Jul 1996 20:43:03 +0200
Received: from hphalle4.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <399223-221>; Mon, 1 Jul 1996 20:42:49 +0100
From: Axel Seibert <seiberta@informatik.tu-muenchen.de>
To: xemacs-beta@xemacs.org
Subject: xemacs-19.14, NEXTSTEP and X11
Message-Id: <96Jul1.204249+0100mesz.399223-221+721@hphalle0.informatik.tu-muenchen.de>
Date: 	Mon, 1 Jul 1996 20:42:41 +0100


Under NEXTSTEP I configured xemacs with

./configure  m68k-next-nextstep --cflags="-O4 -pipe" --rel-alloc=no

and tried to compile it with X11 for the first time; it compiled  
cleanly but when it tried to link temacs I got the following error:

ld: Undefined symbols:
_lwlib_uses_x11r6
_lwlib_does_not_use_motif
_lwlib_does_not_use_motif_1_2
_lwlib_menubars_lucid
_lwlib_scrollbars_lucid
_lwlib_dialogs_athena
_lwlib_does_not_use_energize
*** Exit 1
Stop.
*** Exit 1
Stop.

I don't unterstand this: the library path is set with -L../lwlib  
and the library is included as well (-llw); only when I included the  
object file ../lwlib/lwlib-config.o manually would temacs be linked  
(although I checked the contents of liblw.a with strings; output is  
included at the end of the mail). Here is the complete original  
command used to link temacs, which results in the above mentioned  
error:

cc -O4 -pipe     -L/usr/X11R6/lib  -X -noseglinkedit               
- -L. -L../lwlib        -o temacs pre-crt0.o  abbrev.o alloc.o  
blocktype.o buffer.o bytecode.o  callint.o callproc.o casefiddle.o  
casetab.o cmdloop.o   cmds.o console.o console-stream.o       data.o  
database.o    device.o dialog.o  dired.o doc.o   doprnt.o dynarr.o   
     editfns.o elhash.o emacs.o     eval.o events.o  event-stream.o  
event-unixoid.o  extents.o       faces.o fileio.o filelock.o  
filemode.o floatfns.o fns.o font-lock.o     frame.o          
general.o getloadavg.o dgif_lib.o gif_err.o gifalloc.o  glyphs.o  
gui.o          hash.o  indent.o inline.o insdel.o intl.o        
keymap.o        lread.o lstream.o       macros.o marker.o md5.o  
menubar.o  minibuf.o            objects.o opaque.o      print.o  
process.o profile.o pure.o      rangetab.o   redisplay.o  
redisplay-output.o regex.o     scrollbar.o  search.o signal.o  
sound.o   specifier.o    strftime.o   symbols.o syntax.o sysdep.o     
    toolbar.o    console-tty.o device-tty.o event-tty.o frame-tty.o  
objects-tty.o redisplay-tty.o cm.o      undo.o unexnext.o        
console-x.o device-x.o dialog-x.o  event-Xt.o frame-x.o glyphs-x.o  
gui-x.o  menubar-x.o  objects-x.o redisplay-x.o scrollbar-x.o   
toolbar-x.o  xgccache.o xselect.o     window.o termcap.o tparam.o    
lastfile.o    EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o  
TransientEmacsShell.o EmacsManager.o        -llw -lXaw -lXpm        
- -lXmu -lXt -lSM -lICE  -lXext -lX11                                
- -lgdbm        -lm  -lsys_s


Here comes the output of strings liblw.a
> strings liblw.a | fgrep lwlib_uses
FB91 : lwlib_uses_x11r6
> strings liblw.a | fgrep lwlib_does_
FBA2 : _lwlib_does_not_use_motif
FBBC : _lwlib_does_not_use_motif_1_2
FC1E : _lwlib_does_not_use_energize
> strings liblw.a | fgrep lucid
0431 : _lw_lucid_widget_p
2D89 : _lw_lucid_widget_p
4280 : _lw_lucid_widget_p
FBDA : _lwlib_menubars_lucid
FBF0 : _lwlib_scrollbars_lucid


- ---
Axel_Seibert@tumbolia.ppp.informatik.uni-muenchen.de (NeXT/MIME-Mail)
seibert@leo.org

 You are young only once, but you can stay immature indefinitely.

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 13:59:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA08524 for xemacs-beta-people; Mon, 1 Jul 1996 13:59:26 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA08521 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 13:59:24 -0500 (CDT)
Received: from ives.phx.mcd.mot.com ([144.191.22.44]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA03039 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 13:59:25 -0500 (CDT)
Received: by ives.phx.mcd.mot.com (8.6.8.2/1.34.ives)
	id LAA18307; Mon, 1 Jul 1996 11:59:56 -0700
Date: Mon, 1 Jul 1996 11:59:56 -0700
Message-Id: <199607011859.LAA18307@ives.phx.mcd.mot.com>
From: "Lynn D. Newton" <lnewton@ives.phx.mcd.mot.com>
To: XEmacs Beta Bugs <xemacs-beta@cs.uiuc.edu>
CC: randy_clayton@ives.phx.mcd.mot.com, steve_march@ives.phx.mcd.mot.com
Subject: describe-last-error broken??
Reply-To: lnewton@ives.phx.mcd.mot.com
X-Face:  FVNLrR&aQu[q[N3kO<A5Au*4b"pWyOi13$\H%OVNM8&P{?7;KTRLXSU)c'&Gg3{7GD.p:05
 To5$NCN#r-;vs&Qi@jhk\a@l;bMgx77!GI>4+!:X-+LgxFf'("(:8&7z+:!,24n1@j?C25:p>hno)_
 hPa5S&WgH"E-!{{N^-Cx}MiI_O'dU0
Comments: Hyperbole mail buttons accepted, v03.19.01.


------------------------------ my system -----------------------------
Editor:      XEmacs 19.14
Sys Type:    m88k-motorola-sysv4
OS Type:     usg-unix-v
Window Sys:  X
----------------------------------------------------------------------

I'll be amazed if I'm the first person to see this, but
...

I renamed my Emacs X resources file to hide it, started
xemacs -q -no-site-file, executed {C-b} in the
*scratch* buffer (to generate an error), and M-x
describe-last-error {C-h e} croaks. Here is the backtrace:

Signalling: (wrong-number-of-arguments #<compiled-function (from "help.elc") (thunk) "...(85)" [current-window-configuration one-window-p was-one-window winconfig "*Help*" thunk standard-output help-mode get-buffer-window helpwin window-buffer make-local-variable help-window-config help-selects-help-window select-window selected-window message substitute-command-keys "Type \\[help-mode-quit] to remove help window, \\[scroll-up] to scroll the help." "Type \\[delete-other-windows] to remove help window, \\[scroll-other-window] to scroll the help." "Type \\[switch-to-buffer-other-window] to restore the other window, \\[scroll-other-window] to scroll the help."] 5> 2)
  with-displaying-help-buffer("Last error was:\n" nil)
  #<compiled-function (from "cmdloop.elc") nil "...(11)" [with-displaying-help-buffer princ "Last error was:\n" standard-output display-error last-error] 5 466944 nil>()
  call-interactively(describe-last-error)

Needless to say, this makes debugging other startup
stuff a real pain in the behonkus.

===============================================
Lynn D. Newton
Motorola Computer Group
Business: http://ives.phx.mcd.mot.com/~lnewton
Personal: http://www.eecs.umich.edu/~lnewton
===============================================

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 13:41:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA08401 for xemacs-beta-people; Mon, 1 Jul 1996 13:41:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA08398 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 13:41:41 -0500 (CDT)
Received: from tuminfo2.informatik.tu-muenchen.de (root@tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA07832 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 13:41:29 -0500 (CDT)
Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26516-1>; Mon, 1 Jul 1996 20:41:12 +0200
Received: from hphalle4.informatik.tu-muenchen.de by hphalle0.informatik.tu-muenchen.de id <399220-221>; Mon, 1 Jul 1996 20:41:01 +0100
From: Axel Seibert <seiberta@informatik.tu-muenchen.de>
To: xemacs-beta@xemacs.org
Subject: Easymenu without X11
Message-Id: <96Jul1.204101+0100mesz.399220-221+720@hphalle0.informatik.tu-muenchen.de>
Date: 	Mon, 1 Jul 1996 20:40:52 +0100


Shortly before the final release of there was a patch for gnus
supporting tty-only systems. In the last few days I found some time to
play with gnus, and it still breaks without X11. To get gnus really
working without X, I had to apply the following patches to
easymenu.el:


diff -c easymenu.el.old easymenu.el
*** easymenu.el.old     Sat Jun  8 19:54:36 1996
- --- easymenu.el Sat Jun 29 19:02:49 1996
***************
*** 144,166 ****
         (easy-menu-do-define (quote (, symbol)) (, maps) (, doc)  
(, menu)))))

  (defun easy-menu-do-define (symbol maps doc menu)
    (set symbol menu)
    (fset symbol (list 'lambda '(e)
                     doc
                     '(interactive "@e")
                     '(run-hooks 'activate-menubar-hook)
                     '(setq zmacs-region-stays 't)
!                    (list 'popup-menu symbol))))

  (fset 'easy-menu-change (symbol-function 'add-menu))

  (defvar easy-menu-all-popups nil)
    ;; This variable hold the easy-menu mode menus of all major and
    ;; minor modes currently in effect.
!   (make-variable-buffer-local 'easy-menu-all-popups)

  (defun easy-menu-add (menu &optional map)
    "Add MENU to the current menu bar."
    (if easy-menu-all-popups
        (setq easy-menu-all-popups (cons menu easy-menu-all-popups))
      (setq easy-menu-all-popups (list menu mode-popup-menu)))
- --- 144,168 ----
         (easy-menu-do-define (quote (, symbol)) (, maps) (, doc)  
(, menu)))))

  (defun easy-menu-do-define (symbol maps doc menu)
+   (if (featurep 'menubar) (progn
    (set symbol menu)
    (fset symbol (list 'lambda '(e)
                     doc
                     '(interactive "@e")
                     '(run-hooks 'activate-menubar-hook)
                     '(setq zmacs-region-stays 't)
!                    (list 'popup-menu symbol))))))

  (fset 'easy-menu-change (symbol-function 'add-menu))

  (defvar easy-menu-all-popups nil)
    ;; This variable hold the easy-menu mode menus of all major and
    ;; minor modes currently in effect.
!  (if (featurep 'menubar) (make-variable-buffer-local  
'easy-menu-all-popups))

  (defun easy-menu-add (menu &optional map)
    "Add MENU to the current menu bar."
+   (if (featurep 'menubar) (progn
    (if easy-menu-all-popups
        (setq easy-menu-all-popups (cons menu easy-menu-all-popups))
      (setq easy-menu-all-popups (list menu mode-popup-menu)))
***************
*** 178,192 ****
        (t
         ;; Add at right.
         (set-buffer-menubar (copy-sequence current-menubar))
!        (add-menu nil (car menu) (cdr menu)))))

  (defun easy-menu-remove (menu)
    "Remove MENU from the current menu bar."
    (setq easy-menu-all-popups (delq menu easy-menu-all-popups)
        mode-popup-menu (car easy-menu-all-popups))
    (and current-menubar
         (assoc (car menu) current-menubar)
!        (delete-menu-item (list (car menu)))))

  (provide 'easymenu)

- --- 180,195 ----
        (t
         ;; Add at right.
         (set-buffer-menubar (copy-sequence current-menubar))
!        (add-menu nil (car menu) (cdr menu)))))))

  (defun easy-menu-remove (menu)
    "Remove MENU from the current menu bar."
+   (if (featurep 'menubar) (progn
    (setq easy-menu-all-popups (delq menu easy-menu-all-popups)
        mode-popup-menu (car easy-menu-all-popups))
    (and current-menubar
         (assoc (car menu) current-menubar)
!        (delete-menu-item (list (car menu)))))))

  (provide 'easymenu)
------- End of forwarded message -------

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 16:01:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA09237 for xemacs-beta-people; Mon, 1 Jul 1996 16:01:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA09234 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 16:01:50 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA08618 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 16:01:48 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id OAA03594 for xemacs-beta@xemacs.org; Mon, 1 Jul 1996 14:01:21 -0700
Date: Mon, 1 Jul 1996 14:01:21 -0700
From: Dan Rich <drich@cisco.com>
Message-Id: <199607012101.OAA03594@sandman.cisco.com>
To: xemacs-beta@xemacs.org
Subject: mailcrypt in 19.14

I have run into an odd problem (that's a switch! :-) when trying to verify a 
PGP signature with the vm and mailcrypt released in 19.14.  When I attempt
to run the verify from the menu, I get the following error in the minibuffer:
(macro . #<compiled-function (from "vm-misc.elc") nil "...(2)" [(and vm-mail-buffer (or (buffer-name vm-mail-buffer) (error "

Is anyone else seeing this, and does anyone have any idea what is going on? 
>From the message, I'm not even sure what function is generating the error, so
don't have an easy object to start the debug function on....


From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 17:25:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA09837 for xemacs-beta-people; Mon, 1 Jul 1996 17:25:27 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA09834 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 17:25:25 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA08162 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 17:25:20 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id PAA05007; Mon, 1 Jul 1996 15:24:35 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: mailcrypt in 19.14
References: <199607012101.OAA03594@sandman.cisco.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Dan Rich's message of Mon, 1 Jul 1996 14:01:21 -0700
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 01 Jul 1996 15:24:31 -0700
Message-ID: <m2pw6f7gtc.fsf@deanna.miranova.com>
Lines: 31
X-Mailer: Gnus v5.2.32/XEmacs 20.0

>>>>> "Dan" == Dan Rich <drich@cisco.com> writes:

Dan> I have run into an odd problem (that's a switch! :-) when trying
Dan> to verify a PGP signature with the vm and mailcrypt released in
Dan> 19.14.  When I attempt to run the verify from the menu, I get the
Dan> following error in the minibuffer: (macro . #<compiled-function
Dan> (from "vm-misc.elc") nil "...(2)" [(and vm-mail-buffer (or
Dan> (buffer-name vm-mail-buffer) (error "

Dan> Is anyone else seeing this, and does anyone have any idea what is
Dan> going on?  From the message, I'm not even sure what function is
Dan> generating the error, so don't have an easy object to start the
Dan> debug function on....

The mailcrypt .elcs in the 19.14 final released on the 22nd were out
of date with respect to Gnus, perhaps they are out of date with
respect to VM as well.  I missed finding this on time because I turned
off all additional packages when doing my final testing :-(.

Seeing the error with respect to a macro makes me suspect this is what
happened.

Since in general, mailcrypt must always be rebytecompiled after a Gnus
upgrade, it might be nice if the Makefile from the mailcrypt
distribution wasn't stripped from the XEmacs distribution.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 17:34:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA09905 for xemacs-beta-people; Mon, 1 Jul 1996 17:34:15 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA09902 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 17:34:14 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA08381 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 17:34:14 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id PAA05029; Mon, 1 Jul 1996 15:33:30 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: VM weirdness
References: <199606302039.OAA05421@gielgud.lanl.gov.xdiv>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: John Turner's message of Sun, 30 Jun 1996 14:39:30 -0600
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 01 Jul 1996 15:33:28 -0700
Message-ID: <m2n31j7gef.fsf@deanna.miranova.com>
Lines: 21
X-Mailer: Gnus v5.2.32/XEmacs 20.0

>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:

John> This is going to be a pathetic bug report, but it's really weird, and
John> I just wondered if anyone else is seeing it.

John> o I've only seen this with VM.

John> o Visit another folder via the toolbar... new frame.

John> o Close that frame.

John> Now, whenever I open that 2nd frame, something new and wonderful
John> happens.

Just out of curiosity, what is your setting of vm-warp-mouse-to-new-frame?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 17:52:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA10003 for xemacs-beta-people; Mon, 1 Jul 1996 17:52:10 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA10000 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 17:52:09 -0500 (CDT)
Received: from hackvan.com (hackvan.com [206.80.31.242]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA08637 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 17:52:07 -0500 (CDT)
Received: by hackvan.com (Linux Smail3.1.29.1 #27)
	id m0uarnq-000HE5C; Mon, 1 Jul 96 15:50 PDT
Message-Id: <m0uarnq-000HE5C@hackvan.com>
Date: Mon, 1 Jul 96 15:50 PDT
From: stig@hackvan.com (Stig)
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: mailcrypt in 19.14
In-Reply-To: <m2pw6f7gtc.fsf@deanna.miranova.com>
References: <199607012101.OAA03594@sandman.cisco.com>
	<m2pw6f7gtc.fsf@deanna.miranova.com>
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/

Steven L. Baur wrote:
> 
> >>>>> "Dan" == Dan Rich <drich@cisco.com> writes:
> 
> Dan> I have run into an odd problem (that's a switch! :-) when trying
> Dan> to verify a PGP signature with the vm and mailcrypt released in
> Dan> 19.14.  When I attempt to run the verify from the menu, I get the
> Dan> following error in the minibuffer: (macro . #<compiled-function
> Dan> (from "vm-misc.elc") nil "...(2)" [(and vm-mail-buffer (or
> Dan> (buffer-name vm-mail-buffer) (error "
> 
> The mailcrypt .elcs in the 19.14 final released on the 22nd were out
> of date with respect to Gnus, perhaps they are out of date with
> respect to VM as well.  I missed finding this on time because I turned
> off all additional packages when doing my final testing :-(.
> 
> Seeing the error with respect to a macro makes me suspect this is what
> happened.

No, the problem is that mailcrypt does not (require 'vm-whatever).  When
it's byte-compiled in -batch mode, that module isn't loaded and what should
be byte-compiled as an inlined macro is byte-compiled as a function call
instead.

I'm certain that Chuck removes all the .elc files and builds them from
scratch before a major release.  This isn't his fault.

> Since in general, mailcrypt must always be rebytecompiled after a Gnus
> upgrade, it might be nice if the Makefile from the mailcrypt
> distribution wasn't stripped from the XEmacs distribution.

The makefile wouldn't necessarily fix this.  (I haven't looked at the
makefile...it may load the required modules manually...if so, then that's a
bug and should be changed.)

    Stig

PS:  This problem has probably arisen because it took years of prodding for
Kyle to put (provide) statements in the source files to VM...whatever
hackery mailcrypt does with making sure those files are preloaded is
probably leftover from the old days of not being able to (require 'vm-misc).

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 18:08:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA10130 for xemacs-beta-people; Mon, 1 Jul 1996 18:08:39 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA10121 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 18:08:35 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA08886 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 18:08:34 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id RAA00542; Mon, 1 Jul 1996 17:08:26 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id RAA25805; Mon, 1 Jul 1996 17:08:24 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id RAA08773; Mon, 1 Jul 1996 17:07:57 -0600
Date: Mon, 1 Jul 1996 17:07:57 -0600
Message-Id: <199607012307.RAA08773@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: VM weirdness
In-Reply-To: <m2n31j7gef.fsf@deanna.miranova.com>
References: <199606302039.OAA05421@gielgud.lanl.gov.xdiv>
	<m2n31j7gef.fsf@deanna.miranova.com>
Reply-To: turner@lanl.gov

Steven L. Baur writes:
 > >>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:
 > 
 > John> This is going to be a pathetic bug report, but it's really weird, and
 > John> I just wondered if anyone else is seeing it.
 > 
 > John> o I've only seen this with VM.
 > 
 > John> o Visit another folder via the toolbar... new frame.
 > 
 > John> o Close that frame.
 > 
 > John> Now, whenever I open that 2nd frame, something new and wonderful
 > John> happens.
 > 
 > Just out of curiosity, what is your setting of vm-warp-mouse-to-new-frame?

nil

Also recall that I'm using CDE 1.0.1 on Solaris 2.5, and have it set
so that focus follows mouse (not click-to-type).

-John

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 18:39:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA10312 for xemacs-beta-people; Mon, 1 Jul 1996 18:39:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA10309 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 18:39:56 -0500 (CDT)
Received: from hackvan.com (hackvan.com [206.80.31.242]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA09171 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 18:39:52 -0500 (CDT)
Received: by hackvan.com (Linux Smail3.1.29.1 #27)
	id m0uasLT-000HE7C; Mon, 1 Jul 96 16:25 PDT
Message-Id: <m0uasLT-000HE7C@hackvan.com>
Date: Mon, 1 Jul 96 16:25 PDT
From: stig@hackvan.com (Stig)
To: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>
Cc: hug@netcom.com, XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: Suggestions for documentation 
In-Reply-To: <199606211329.IAA20721@nvwls.cc.purdue.edu>
References: <Pine.SCO5.3.93.960621125202.3479A-100000@hyperion.paradigm-sa.com>
	<199606211329.IAA20721@nvwls.cc.purdue.edu>
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/

Joseph J. Nuspl, Jr. wrote:
> 
> >>>>> "JKJ" == J Kean Johnston <jkj@paradigm-sa.com> writes:
> 
>     JKJ> If it helps, here is where things are kept: XFACE: ???
> 
> XFACE: ftp://ftp.cs.indiana.edu/pub/faces/compface

There should be a slightly altered copy of the library in the aux/ directory
of the xemacs distribution site.  It has minor fixes and a script that makes
it easier to create an xface...

    Stig
    

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 22:02:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA11139 for xemacs-beta-people; Mon, 1 Jul 1996 22:02:59 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA11136 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 22:02:58 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA17075 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 22:03:00 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id UAA00424; Mon, 1 Jul 1996 20:02:27 -0700
Date: Mon, 1 Jul 1996 20:02:27 -0700
Message-Id: <199607020302.UAA00424@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: stig@hackvan.com (Stig)
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: mailcrypt in 19.14
In-Reply-To: <m0uarnq-000HE5C@hackvan.com>
References: <199607012101.OAA03594@sandman.cisco.com>
	<m2pw6f7gtc.fsf@deanna.miranova.com>
	<m0uarnq-000HE5C@hackvan.com>
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Stig" == Stig  <stig@hackvan.com> writes:

    Stig> No, the problem is that mailcrypt does not (require
    Stig> 'vm-whatever).  When it's byte-compiled in -batch mode, that
    Stig> module isn't loaded and what should be byte-compiled as an
    Stig> inlined macro is byte-compiled as a function call instead.

Adding a (require 'vm-misc) and recompiling has cleared up the problem
for me.  Then again, I just discovered the pgp module for TM, so I'm
not sure I'm going to use mailcrypt any more....  (except that it
looks like tm-pgp won't let you both sign and encrypt a message).

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 22:44:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA11276 for xemacs-beta-people; Mon, 1 Jul 1996 22:44:45 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA11273 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 22:44:34 -0500 (CDT)
Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA09800 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 22:44:20 -0500 (CDT)
Received: from clove.kurims.kyoto-u.ac.jp (clove.kurims.kyoto-u.ac.jp [130.54.16.42]) by kurims.kurims.kyoto-u.ac.jp (8.7.5/3.4W2) with SMTP id MAA17320 for <xemacs-beta@xemacs.org>; Tue, 2 Jul 1996 12:43:42 +0900 (JST)
Date: Tue, 2 Jul 96 12:43:41 JST
Message-Id: <9607020343.AA15879@clove>
From: Jens-U H Petersen <petersen@kurims.kyoto-u.ac.jp>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: slow start up
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII

I just started beta testing xemacs-20 last week.  I built
xemacs-20.0-b26 --with-mule under sunos-4.1.4 and *X11R6*.
Actually I am kind of new to xemacs..

I find that it is really rather slow to start up (over 5s on a
quiet SparcStation 20!)... is that just because we are not using
a X11R6 fs (fontserver) here? or are there other reasons??

Jens

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 23:03:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA11384 for xemacs-beta-people; Mon, 1 Jul 1996 23:03:32 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA11381 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 23:03:26 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA18596 for <xemacs-beta@cs.uiuc.edu>; Mon, 1 Jul 1996 23:03:26 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id VAA29985; Mon, 1 Jul 1996 21:02:53 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id VAA19728; Mon, 1 Jul 1996 21:02:51 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA29983; Mon, 1 Jul 1996 21:02:51 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA11492; Mon, 1 Jul 1996 21:02:48 -0700
Date: Mon, 1 Jul 1996 21:02:48 -0700
Message-Id: <199607020402.VAA11492@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Ben Wing <wing@666.com>
Cc: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: byte-compile-dynamic
Reply-To: Martin Buchholz <mrb@eng.sun.com>

I think it was a mistake to make byte-compile-dynamic default to t.

If byte-compile-dynamic is t, then the elc file must be opened and
read the first time the function is called.  Since the functions in a
file tend to be used together, the net effect is that the first use of
a package tends to be much slower.  Setting byte-compile-dynamic to t
is only a win if the functions in a file are unrelated - if calling
one of those functions is unlikely to result in a call to many others.

This might be the case, for example, if there was a separate function
for each charset used by the user.

Unless you object, Ben, I will change the value back to nil, which is
the value used in Emacs 19.31.

Martin

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  1 23:50:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA11494 for xemacs-beta-people; Mon, 1 Jul 1996 23:50:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA11491 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 1 Jul 1996 23:50:01 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA09941 for <xemacs-beta@xemacs.org>; Mon, 1 Jul 1996 23:49:58 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id VAA05337; Mon, 1 Jul 1996 21:49:30 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id VAA21542; Mon, 1 Jul 1996 21:49:28 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA00207; Mon, 1 Jul 1996 21:49:28 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA11531; Mon, 1 Jul 1996 21:49:25 -0700
Date: Mon, 1 Jul 1996 21:49:25 -0700
Message-Id: <199607020449.VAA11531@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Jens-U H Petersen <petersen@kurims.kyoto-u.ac.jp>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: slow start up
In-Reply-To: <9607020343.AA15879@clove>
References: <9607020343.AA15879@clove>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Jens" == Jens-U H Petersen <petersen@kurims.kyoto-u.ac.jp> writes:

Jens> I just started beta testing xemacs-20 last week.  I built
Jens> xemacs-20.0-b26 --with-mule under sunos-4.1.4 and *X11R6*.
Jens> Actually I am kind of new to xemacs..

Jens> I find that it is really rather slow to start up (over 5s on a
Jens> quiet SparcStation 20!)... is that just because we are not using
Jens> a X11R6 fs (fontserver) here? or are there other reasons??

XEmacs pays a pretty big price for Mule support - and there is
certainly room for optimizations. Another factor might be that
byte-compile-dynamic is (IMO erroneously) set to t.

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Jul  2 00:12:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA11681 for xemacs-beta-people; Tue, 2 Jul 1996 00:12:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA11678 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 2 Jul 1996 00:11:55 -0500 (CDT)
Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA09989 for <xemacs-beta@xemacs.org>; Tue, 2 Jul 1996 00:11:43 -0500 (CDT)
Received: from clove.kurims.kyoto-u.ac.jp (clove.kurims.kyoto-u.ac.jp [130.54.16.42]) by kurims.kurims.kyoto-u.ac.jp (8.7.5/3.4W2) with SMTP id OAA17772; Tue, 2 Jul 1996 14:11:14 +0900 (JST)
Date: Tue, 2 Jul 96 14:11:14 JST
Message-Id: <9607020511.AA15980@clove>
From: Jens-U H Petersen <petersen@kurims.kyoto-u.ac.jp>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: reading Japanese newsgps
In-Reply-To: <199607020449.VAA11531@xemacs.eng.sun.com>
References: <9607020343.AA15879@clove>
	<199607020449.VAA11531@xemacs.eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII

[xemacs-20.0-b26 --with-mule]

I just tried to read a Japanese newsgroup with gnus, the Japanese
doesn't appear properly: i.e. I just get all the Japanese
appearing as ^[B....

Does it work at the moment for anyone?

Jens

From xemacs-beta-request@cs.uiuc.edu  Tue Jul  2 00:28:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA11715 for xemacs-beta-people; Tue, 2 Jul 1996 00:28:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA11712 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 2 Jul 1996 00:28:02 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA10042 for <xemacs-beta@xemacs.org>; Tue, 2 Jul 1996 00:27:52 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id WAA10997; Mon, 1 Jul 1996 22:27:24 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA24121; Mon, 1 Jul 1996 22:27:22 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA00410; Mon, 1 Jul 1996 22:27:22 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA12088; Mon, 1 Jul 1996 22:27:19 -0700
Date: Mon, 1 Jul 1996 22:27:19 -0700
Message-Id: <199607020527.WAA12088@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Jens-U H Petersen <petersen@kurims.kyoto-u.ac.jp>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: reading Japanese newsgps
In-Reply-To: <9607020511.AA15980@clove>
References: <9607020343.AA15879@clove>
	<199607020449.VAA11531@xemacs.eng.sun.com>
	<9607020511.AA15980@clove>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Jens" == Jens-U H Petersen <petersen@kurims.kyoto-u.ac.jp> writes:

Jens> [xemacs-20.0-b26 --with-mule]
Jens> I just tried to read a Japanese newsgroup with gnus, the Japanese
Jens> doesn't appear properly: i.e. I just get all the Japanese
Jens> appearing as ^[B....

The proper way is probably to use tm, but the following sort of works
for me:

 
(defun gnus-article-decode-iso2022 ()
  (save-excursion
   (set-buffer gnus-article-buffer)
   (goto-char (point-min))
   (while (search-forward "\e" nil t)
    (backward-char)
    (decode-coding-region (point) (point-end-of-line) 'iso-2022-jp))))
 
(add-hook 'gnus-article-prepare-hook 'gnus-article-decode-iso2022)

From xemacs-beta-request@cs.uiuc.edu  Tue Jul  2 06:12:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA16629 for xemacs-beta-people; Tue, 2 Jul 1996 06:12:07 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA16626 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 2 Jul 1996 06:12:06 -0500 (CDT)
Received: from eik (eik.ii.uib.no [129.177.16.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA11090 for <xemacs-beta@xemacs.org>; Tue, 2 Jul 1996 06:11:55 -0500 (CDT)
Received: from vipe.ii.uib.no (vipe) by eik with SMTP id AA05028
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Tue, 2 Jul 1996 13:11:46 +0200
Received: by vipe.ii.uib.no; (5.65/1.1.8.2/08Jun94-0756AM)
	id AA08535; Tue, 2 Jul 1996 13:11:45 +0200
Newsgroups: comp.emacs.xemacs
Sender: ketil@ii.uib.no
To: xemacs-beta@xemacs.org
Cc: "Cesar A. Rorato Crusius" <crusius@lcmi.ufsc.br>
Subject: [comp.os.linux.announce] XEmacs 19.14 with OffiX drag and drop
From: Ketil Z Malde <ketil@ii.uib.no>
Date: 02 Jul 1996 13:11:43 +0200
Message-Id: <KETIL-egenmuewpc.fsf@vipe.ii.uib.no>
Lines: 62
X-Newsreader: Gnus v5.2.1/XEmacs 19.14
Posted-To: comp.emacs.xemacs

The following message is a courtesy copy of an article
that has been posted as well.


Found this in comp.os.linux.announce, talked to the poster, and he asked
me to forward this to the xemacs community.  So here it is.

~kzm

------- Start of forwarded message -------
From: "Cesar A. Rorato Crusius" <crusius@lcmi.ufsc.br>
Newsgroups: comp.os.linux.announce
Subject: XEmacs 19.14 with OffiX drag and drop
Followup-To: comp.os.linux.x
Date: Thu, 27 Jun 1996 03:02:18 GMT
Organization: LCMI/UFSC
Message-ID: <cola-liw-835844538-20232-0@liw.clinet.fi>

-----BEGIN PGP SIGNED MESSAGE-----

XEmacs 19.14 is now OffiX compatible !!

Thanks to Savin Zlobec <savin@torina.fer.uni-lj.si> now XEmacs
can support drops from OffiX compatible applications.
You just have to apply a patch to XEmacs-19.14 sources and recompile
it. XEmacs can be found at

http://www.xemacs.org

The patch to make XEmacs accept drag-and-drop is at

ftp://sunsite.unc.edu/Incoming/xemacs-19.14_offix.diff.gz

And the OffiX distribution (you will need the DND library) can
be found at

http://gutenberg.lcmi.ufsc.br/OffiX

With the offix distribution you will also find an OffiX compatible
file manager - this means you will be able do drag files from the file
manager and drop them into xemacs. There are also a print tool and a
trash can that are OffiX compatible.

- -- 
Cesar Augusto Rorato Crusius  o__     o__     o__     o__     o__
Florianopolis - SC - BRASIL   ,>/'_   ,>/'_   ,>/'_   ,>/'_   ,>/'_
e-mail:c.crusius@ieee.org    (_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_)


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAwUBMdH5j4QRll5MupLRAQFsVQQAnOuF4secO6GslxUBp23kYCgP/Zg/XGhP
5YmmCZ+I3XVccYuMDoayd1U9gL+o8DspBJeQ0pmuOUIn6Ak5QBeI/BzjvyNLr+98
89+yZIpuiFF2g3wjmrSzTv/kRHpLJsSc02tJoJ4G90WIlm5epxb0L1YI3OF+97Gw
ZpLnsPjJ268=
=ZGJy
-----END PGP SIGNATURE-----

-- 
This article has been digitally signed by the moderator, using PGP.
Finger wirzeniu@kruuna.helsinki.fi for PGP key needed for validating signature.
Send submissions for comp.os.linux.announce to: linux-announce@news.ornl.gov
PLEASE remember a short description of the software and the LOCATION.
------- End of forwarded message -------

From xemacs-beta-request@cs.uiuc.edu  Tue Jul  2 10:30:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA17920 for xemacs-beta-people; Tue, 2 Jul 1996 10:30:17 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA17917 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 2 Jul 1996 10:30:16 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA04441 for <xemacs-beta@cs.uiuc.edu>; Tue, 2 Jul 1996 10:30:18 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id IAA00932; Tue, 2 Jul 1996 08:29:53 -0700
Date: Tue, 2 Jul 1996 08:29:53 -0700
Message-Id: <199607021529.IAA00932@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: stig@hackvan.com (Stig)
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Hanging frames
In-Reply-To: <m0uZo3u-000HE5C@hackvan.com>
References: <199606270049.RAA06050@sandman.cisco.com>
	<199606270110.VAA24555@anthem.CNRI.Reston.Va.US>
	<m0uZo3u-000HE5C@hackvan.com>
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Stig" == Stig  <stig@hackvan.com> writes:

    Stig> I hate few things, but I really *HATE* this bug.  I tried to
    Stig> find it once or twice (a loooooooong time ago), but got lost
    Stig> in redisplay...

Does anyone else have any ideas on this?  It's making it almost
impossible to use XEmacs on my system, as just about any frame that I
iconify becomes useless.  In addition, any frame that I bring up with
gnuclient is also hung (which is worse than the beta!).

And, just to add another data point, I recently reenabled my use of
frame-icon.el.  Now when I bring up a new frame, it doesn't have an
icon assigned, ie. it gets the default XEmacs icon.  It looks like
either unmap-screen-hook is not being executed, or the major-mode
isn't being set?

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Tue Jul  2 10:32:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA17928 for xemacs-beta-people; Tue, 2 Jul 1996 10:32:18 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA17925 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 2 Jul 1996 10:32:17 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA04477 for <xemacs-beta@cs.uiuc.edu>; Tue, 2 Jul 1996 10:32:13 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id IAA01008; Tue, 2 Jul 1996 08:31:50 -0700
Date: Tue, 2 Jul 1996 08:31:50 -0700
Message-Id: <199607021531.IAA01008@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: stig@hackvan.com (Stig)
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Hanging frames
In-Reply-To: <m0uZo3u-000HE5C@hackvan.com>
References: <199606270049.RAA06050@sandman.cisco.com>
	<199606270110.VAA24555@anthem.CNRI.Reston.Va.US>
	<m0uZo3u-000HE5C@hackvan.com>
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII


Oh, I forgot to add my other data point.  VM always works.  Even
though sometimes the frame is hung when I deiconify it, it will
refresh the frame as soon as I get new mail.  Any idea why this would
work (is VM calling some strange function? -- imagine that! :-)

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Tue Jul  2 11:59:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA18402 for xemacs-beta-people; Tue, 2 Jul 1996 11:59:10 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA18399 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 2 Jul 1996 11:59:09 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA07722 for <xemacs-beta@cs.uiuc.edu>; Tue, 2 Jul 1996 11:59:10 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id JAA11598; Tue, 2 Jul 1996 09:58:26 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: reading Japanese newsgps
References: <9607020343.AA15879@clove>
	<199607020449.VAA11531@xemacs.eng.sun.com> <9607020511.AA15980@clove>
	<199607020527.WAA12088@xemacs.eng.sun.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Martin Buchholz's message of Mon, 1 Jul 1996 22:27:19 -0700
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 02 Jul 1996 09:58:25 -0700
Message-ID: <m23f3a618u.fsf@deanna.miranova.com>
Lines: 25
X-Mailer: Gnus v5.2.32/XEmacs 20.0

>>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:

>>>>> "Jens" == Jens-U H Petersen <petersen@kurims.kyoto-u.ac.jp> writes:
Jens> [xemacs-20.0-b26 --with-mule]
Jens> I just tried to read a Japanese newsgroup with gnus, the Japanese
Jens> doesn't appear properly: i.e. I just get all the Japanese
Jens> appearing as ^[B....

Martin> The proper way is probably to use tm

All you have to do is bytecompile tm with your Mule-enabled v20.  I'm
running right now with Gnus 5.2.32 & Mailcrypt 3.4 bytecompiled with
19.14, and tm bytecompiled with 20.0-b26.  The tm installation will
put itself in a different place for 20.0 -vs- 19.14 so you can easily
switch between both versions.

NB:  There is a magic variable that sometimes needs setting:
(setq code-converter-is-broken t)

The 20.0 screendumps in the XEmacs FAQ were taken using tm & Gnus.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Tue Jul  2 12:15:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA18543 for xemacs-beta-people; Tue, 2 Jul 1996 12:15:34 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA18540 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 2 Jul 1996 12:15:33 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA08096 for <xemacs-beta@cs.uiuc.edu>; Tue, 2 Jul 1996 12:15:26 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA11773; Tue, 2 Jul 1996 10:14:42 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: mailcrypt in 19.14
References: <199607012101.OAA03594@sandman.cisco.com>
	<m2pw6f7gtc.fsf@deanna.miranova.com> <m0uarnq-000HE5C@hackvan.com>
	<199607020302.UAA00424@sandman.cisco.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Dan Rich's message of Mon, 1 Jul 1996 20:02:27 -0700
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 02 Jul 1996 10:14:40 -0700
Message-ID: <m2zq5i4lxb.fsf@deanna.miranova.com>
Lines: 17
X-Mailer: Gnus v5.2.32/XEmacs 20.0

>>>>> "Dan" == Dan Rich <drich@cisco.com> writes:

Dan> Adding a (require 'vm-misc) and recompiling has cleared up the
Dan> problem for me.  Then again, I just discovered the pgp module for
Dan> TM, so I'm not sure I'm going to use mailcrypt any more....
Dan> (except that it looks like tm-pgp won't let you both sign and
Dan> encrypt a message).

The PGP support in tm does not replace Mailcrypt.  Don't forget that
Mailcrypt supports good things like remailer chains, response blocks,
and Mixmaster.  :-)

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Tue Jul  2 13:09:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA18899 for xemacs-beta-people; Tue, 2 Jul 1996 13:09:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA18896 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 2 Jul 1996 13:09:48 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA09004 for <xemacs-beta@cs.uiuc.edu>; Tue, 2 Jul 1996 13:09:50 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa15445;
          2 Jul 96 14:08 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id OAA09082; Tue, 2 Jul 1996 14:08:05 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id OAA28537; Tue, 2 Jul 1996 14:08:04 -0400
Date: Tue, 2 Jul 1996 14:08:04 -0400
Message-Id: <199607021808.OAA28537@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Hanging frames
References: <199606270049.RAA06050@sandman.cisco.com>
	<199606270110.VAA24555@anthem.CNRI.Reston.Va.US>
	<m0uZo3u-000HE5C@hackvan.com>
	<199607021529.IAA00932@sandman.cisco.com>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Assemble some of the elements in a group and treat the group
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "DR" == Dan Rich <drich@cisco.com> writes:

    DR> Does anyone else have any ideas on this?  It's making it
    DR> almost impossible to use XEmacs on my system, as just about
    DR> any frame that I iconify becomes useless.

Oddly enough, I haven't been able to recreate this problem using 19.14
final release, and fvwm 2.0.42.  It must be some race condition that
I'm just not getting bit by yet.  It happened all the time for me in
the earlier betas, but so far (thankfully) it hasn't shown up yet.

-Bary

From xemacs-beta-request@cs.uiuc.edu  Tue Jul  2 12:38:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA18716 for xemacs-beta-people; Tue, 2 Jul 1996 12:38:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA18713 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 2 Jul 1996 12:38:55 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.192.93]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA12308 for <xemacs-beta@xemacs.org>; Tue, 2 Jul 1996 12:38:49 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id KAA01285; Tue, 2 Jul 1996 10:38:29 -0700
Date: Tue, 2 Jul 1996 10:38:29 -0700
Message-Id: <199607021738.KAA01285@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: xemacs-beta@xemacs.org
Subject: 20.0b25 build failure
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm getting a build failure on SunOS 4.1.3_U1 when using the following
config:
=09./configure  --site-libraries=3D/local/lib
=09--site-includes=3D/local/include --with-xpm --with-xface
=09--with-sound=3Dnative --with-gif --with-jpeg --with-png
=09--prefix=3D/local/beta --dynamic --with-mule

Has anyone else seen the following crash?

cd ../lwlib; make 
EMACSLOADPATH=3D"/a/ce-nfs-2/export/home5/drich/Src/xemacs-20.0-b25/src/../=
lisp/prim" ./temacs -batch -l loadup.el dump

Loading loadup.el...
Using load-path (/a/ce-nfs-2/export/home5/drich/Src/xemacs-20.0-b25/src/../=
lisp/prim)
Loading backquote... (2752)
Loading bytecomp-runtime... (2704)
Loading subr... (6628)
Loading replace... (11800)
Loading version.el... (2124)
Loading cl...
Loading cl-defs... (9664) (22092)
Loading cmdloop... (7256)
Loading keymap... (4616)
Loading syntax... (6904)
Loading device... (724)
Loading console... (112)
Loading obsolete... (11060)
Loading specifier... (2904)
Loading faces... (19580)
Loading glyphs... (7584)
Loading objects... (1844)
Loading extents... (1176)
Loading events... (2216)
Loading text-props... (2916)
Loading process... (4120)
Loading frame... (11204)
Loading map-ynp... (3032)
Loading simple...
 (37212)
Loading keydefs... (3664)
Loading abbrev... (7268)
Loading derived... (4540)
Loading minibuf... (25836)
Loading list-mode... (9708)
Loading modeline... (5024)
Loading loaddefs...*** Error in XEmacs initialization
(setting-constant t hebrew-holidays-1)
*** Backtrace
  really-early-error-handler((setting-constant t hebrew-holidays-1))
  # bind (t)
  byte-code("=C0=C1=C2=C3#=C4=C1!=AC=C5=C1=C0=C7=C2=C3#=C4=C7!=AC=C8=C7=C0=
=C9=C2=C3#=C4=C9!=AC=CA   =C9=C0=CB=C2=C3#=C4=CB!=AC=CC
                                                           =CB=C0=CD=C2=C3#=
" [put hebrew-holidays-1 risky-local-variable t boundp ((holiday-rosh-hasha=
nah-etc) (if all-hebrew-calendar-holidays ...)) current-load-list hebrew-ho=
lidays-2 ((if all-hebrew-calendar-holidays ... ...) (if all-hebrew-calendar=
-holidays ...) (if all-hebrew-calendar-holidays ...)) hebrew-holidays-3 ((i=
f all-hebrew-calendar-holidays ...)) hebrew-holidays-4 ((holiday-passover-e=
tc) (if ... ...) (if all-hebrew-calendar-holidays ...)) hebrew-holidays] 4)
  # bind (current-load-list standard-input)
  # (unwind-protect ...)
  # bind (load-file-name)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  load("loaddefs")
  # bind (x)
  (lambda (x) (load x) (garbage-collect))("loaddefs")
  funcall((lambda (x) (load x) (garbage-collect)) "loaddefs")
  (if (featurep (quote sparcworks)) (funcall l "eos/loaddefs-eos") (funcall=
 l "loaddefs"))
)
  # bind (l)
  (let ((l ...)) (funcall l "backquote") (funcall l "bytecomp-runtime") (fu=
ncall l "subr") (funcall l "replace") (funcall l "version.el") (funcall l "=
cl") (funcall l "cmdloop") (or (fboundp ...) (funcall l "cmdloop1")) (funca=
ll l "keymap") (funcall l "syntax") (funcall l "device") (funcall l "consol=
e") (funcall l "obsolete") (funcall l "specifier") (funcall l "faces") (fun=
call l "glyphs") (funcall l "objects") (funcall l "extents") (funcall l "ev=
ents") (funcall l "text-props") (funcall l "process") (funcall l "frame") (=
funcall l "map-ynp") (funcall l "simple") (funcall l "keydefs") (funcall l =
"abbrev") (funcall l "derived") (funcall l "minibuf") (funcall l "list-mode=
") (funcall l "modeline") (if (featurep ...) (funcall l "eos/loaddefs-eos")=
 (funcall l "loaddefs")) (funcall l "misc") (funcall l "profile") (funcall =
l "help") (if (not ...) (funcall l "files-nomule")) (funcall l "files") (fu=
ncall l "lib-complete") (funcall l "format") (funcall l "indent") (funcall =
l "isearch-mode") (funcall l "buffer") (funcall l "buff-menu") (funcall l "=
undo-stack") (funcall l "window") (funcall l "paths.el") (funcall l "startu=
p") (funcall l "lisp") (funcall l "page") (funcall l "register") (funcall l=
 "iso8859-1") (funcall l "paragraphs") (funcall l "lisp-mode") (funcall l "=
text-mode") (funcall l "fill") (funcall l "cc-mode") (if (eq system-type ..=
.) (funcall l "vmsproc")) (if (eq system-type ...) (funcall l "vms-patch"))=
 (if (eq system-type ...) (progn ... ...)) (if (eq system-type ...) (progn =
... ... ...)) (if (featurep ...) (funcall l "float-sup")) (funcall l "itime=
r") (if (featurep ...) (funcall l "toolbar") (progn ... ...)) (if (featurep=
 ...) (funcall l "scrollbar")) (if (featurep ...) (funcall l "menubar")) (i=
f (featurep ...) (funcall l "dialog")) (if (featurep ...) (funcall l "mule-=
load.el")) (if (featurep ...) (progn ... ... ...)) (if (featurep ...) (prog=
n ... ... ... ... ... ... ... ... ...)) (if (featurep ...) (funcall l "tty-=
init")) (if (featurep ...) (funcall l "tooltalk/tooltalk-load")) (funcall l=
 "vc-hooks") (funcall l "ediff-hook") (funcall l "fontl-hooks") (funcall l =
"auto-show") (if (featurep ...) (funcall l "energize/energize-load.el")) (i=
f (featurep ...) (funcall l "sunpro/sunpro-load.el")))
)
  (lambda nil (external-debugging-output (format "\nUsing load-path %s" loa=
d-path)) (buffer-disable-undo (get-buffer "*scratch*")) (let (...) (setq so=
urce-directory temp-path) (setq load-path ...)) (setq load-warn-when-source=
-newer t load-warn-when-source-only t) (let (...) (funcall l "backquote") (=
funcall l "bytecomp-runtime") (funcall l "subr") (funcall l "replace") (fun=
call l "version.el") (funcall l "cl") (funcall l "cmdloop") (or ... ...) (f=
uncall l "keymap") (funcall l "syntax") (funcall l "device") (funcall l "co=
nsole") (funcall l "obsolete") (funcall l "specifier") (funcall l "faces") =
(funcall l "glyphs") (funcall l "objects") (funcall l "extents") (funcall l=
 "events") (funcall l "text-props") (funcall l "process") (funcall l "frame=
") (funcall l "map-ynp") (funcall l "simple") (funcall l "keydefs") (funcal=
l l "abbrev") (funcall l "derived") (funcall l "minibuf") (funcall l "list-=
mode") (funcall l "modeline") (if ... ... ...) (funcall l "misc") (funcall =
l "profile") (funcall l "help") (if ... ...) (funcall l "files") (funcall l=
 "lib-complete") (funcall l "format") (funcall l "indent") (funcall l "isea=
rch-mode") (funcall l "buffer") (funcall l "buff-menu") (funcall l "undo-st=
ack") (funcall l "window") (funcall l "paths.el") (funcall l "startup") (fu=
ncall l "lisp") (funcall l "page") (funcall l "register") (funcall l "iso88=
59-1") (funcall l "paragraphs") (funcall l "lisp-mode") (funcall l "text-mo=
de") (funcall l "fill") (funcall l "cc-mode") (if ... ...) (if ... ...) (if=
 ... ...) (if ... ...) (if ... ...) (funcall l "itimer") (if ... ... ...) (=
if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...=
) (if ... ...) (if ... ...) (funcall l "vc-hooks") (funcall l "ediff-hook")=
 (funcall l "fontl-hooks") (funcall l "auto-show") (if ... ...) (if ... ...=
)))()
  # (unwind-protect ...)
  call-with-condition-handler(really-early-error-handler (lambda nil (exter=
nal-debugging-output (format "\nUsing load-path %s" load-path)) (buffer-dis=
able-undo (get-buffer "*scratch*")) (let (...) (setq source-directory temp-=
path) (setq load-path ...)) (setq load-warn-when-source-newer t load-warn-w=
hen-source-only t) (let (...) (funcall l "backquote") (funcall l "bytecomp-=
runtime") (funcall l "subr") (funcall l "replace") (funcall l "version.el")=
 (funcall l "cl") (funcall l "cmdloop") (or ... ...) (funcall l "keymap") (=
funcall l "syntax") (funcall l "device") (funcall l "console") (funcall l "=
obsolete") (funcall l "specifier") (funcall l "faces") (funcall l "glyphs")=
 (funcall l "objects") (funcall l "extents") (funcall l "events") (funcall =
l "text-props") (funcall l "process") (funcall l "frame") (funcall l "map-y=
np") (funcall l "simple") (funcall l "keydefs") (funcall l "abbrev") (funca=
ll l "derived") (funcall l "minibuf") (funcall l "list-mode") (funcall l "m=
odeline") (if ... ... ...) (funcall l "misc") (funcall l "profile") (funcal=
l l "help") (if ... ...) (funcall l "files") (funcall l "lib-complete") (fu=
ncall l "format") (funcall l "indent") (funcall l "isearch-mode") (funcall =
l "buffer") (funcall l "buff-menu") (funcall l "undo-stack") (funcall l "wi=
ndow") (funcall l "paths.el") (funcall l "startup") (funcall l "lisp") (fun=
call l "page") (funcall l "register") (funcall l "iso8859-1") (funcall l "p=
aragraphs") (funcall l "lisp-mode") (funcall l "text-mode") (funcall l "fil=
l") (funcall l "cc-mode") (if ... ...) (if ... ...) (if ... ...) (if ... ..=
.) (if ... ...) (funcall l "itimer") (if ... ... ...) (if ... ...) (if ... =
...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if ... ...) (if .=
.. ...) (funcall l "vc-hooks") (funcall l "ediff-hook") (funcall l "fontl-h=
ooks") (funcall l "auto-show") (if ... ...) (if ... ...))))
  # bind (current-load-list standard-input)
  # (unwind-protect ...)
  # bind (load-file-name)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  load("loadup.el")
  # (condition-case ... . error)
  # (catch top-level ...)
*** Killing XEmacs
*** Error code 255
make: Fatal error: Command failed for target `xemacs'
Current working directory /a/ce-nfs-2/export/home5/drich/Src/xemacs-20.0-b2=
5/src
*** Error code 1
make: Fatal error: Command failed for target `src'


-- 
Dan Rich <drich@cisco.com>  |=09http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!=
"
(408) 527-3195              |           -- The Firesign Theatre's Nick Dang=
er

From xemacs-beta-request@cs.uiuc.edu  Tue Jul  2 15:59:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA19840 for xemacs-beta-people; Tue, 2 Jul 1996 15:59:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA19834 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 2 Jul 1996 15:59:57 -0500 (CDT)
Received: from GS213.SP.CS.CMU.EDU (GS213.SP.CS.CMU.EDU [128.2.209.183]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA13230 for <xemacs-beta@xemacs.org>; Tue, 2 Jul 1996 15:59:54 -0500 (CDT)
Received: by GS213.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA36623; Tue, 2 Jul 1996 16:59:49 -0400
Date: Tue, 2 Jul 1996 16:59:49 -0400
Message-Id: <9607022059.AA36623@GS213.SP.CS.CMU.EDU>
From: Darrell Kindred <dkindred+@cmu.edu>
To: Usenet post <dkindred=news@pop.cs.cmu.edu>
Newsgroups: comp.emacs.xemacs
Subject: 19.14: frame-title-format bug [w/ patch]

The bug:

  Run xemacs -q, and do
	C-x 5 2
        in the new frame, C-x b newbuf RET
        in the first frame (*scratch* buffer), eval this:
             (make-local-variable 'frame-title-format)
             (make-local-variable 'frame-icon-title-format)
             (setq frame-title-format "frametitle")
             (setq frame-icon-title-format "icontitle")
  Now whenever the first frame is selected, all frames will have
  title "frametitle" and icon-title "icontitle"; when the second
  frame is selected, the frames will have their default titles.

The patch below fixes this bug.

- Darrell

*** src/frame.c.orig	Fri Jun 21 23:19:12 1996
--- src/frame.c	Tue Jul  2 16:40:53 1996
***************
*** 95,102 ****
  Lisp_Object Qframe_x_p, Qframe_tty_p;
  Lisp_Object Qdelete_frame;
  
! Lisp_Object Vframe_title_format;
! Lisp_Object Vframe_icon_title_format;
  
  Lisp_Object Vdefault_frame_name;
  Lisp_Object Vdefault_frame_plist;
--- 95,102 ----
  Lisp_Object Qframe_x_p, Qframe_tty_p;
  Lisp_Object Qdelete_frame;
  
! Lisp_Object Qframe_title_format, Vframe_title_format;
! Lisp_Object Qframe_icon_title_format, Vframe_icon_title_format;
  
  Lisp_Object Vdefault_frame_name;
  Lisp_Object Vdefault_frame_plist;
***************
*** 2785,2792 ****
    else if (!BUFFER_LIVE_P (XBUFFER (w->buffer)))
      return;
  
!   title_format = Vframe_title_format;
!   icon_format = Vframe_icon_title_format;
  
    if (HAS_FRAMEMETH_P (f, set_title_from_char))
      {
--- 2785,2793 ----
    else if (!BUFFER_LIVE_P (XBUFFER (w->buffer)))
      return;
  
!   /* do these need to be GCPRO'd?  -dkindred */
!   title_format = symbol_value_in_buffer (Qframe_title_format, w->buffer);
!   icon_format = symbol_value_in_buffer (Qframe_icon_title_format, w->buffer);
  
    if (HAS_FRAMEMETH_P (f, set_title_from_char))
      {
***************
*** 2892,2897 ****
--- 2893,2901 ----
    defsymbol (&Qbuffer_predicate, "buffer-predicate");
    defsymbol (&Qframe_being_created, "frame-being-created");
    defsymbol (&Qmake_initial_minibuffer_frame, "make-initial-minibuffer-frame");
+ 
+   defsymbol (&Qframe_title_format, "frame-title-format");
+   defsymbol (&Qframe_icon_title_format, "frame-icon-title-format");
  
    defsymbol (&Qvisible, "visible");
    defsymbol (&Qiconic, "iconic");

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 12:23:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA28204 for xemacs-beta-people; Wed, 3 Jul 1996 12:23:21 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA28201 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 12:23:20 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA02359 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 12:23:19 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA24668; Wed, 3 Jul 1996 10:22:35 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [Thomas Bueschgens <sledge@hammer.oche.de>] Re: GNUS 5.2.25, MailCrypt 3.4 and Xemacs-19.14
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: multipart/mixed;
 boundary="Multipart_Wed_Jul__3_10:22:33_1996-1"
Content-Transfer-Encoding: 7bit
Date: 03 Jul 1996 10:22:34 -0700
Message-ID: <m291d1ckv9.fsf@deanna.miranova.com>
Lines: 66
X-Mailer: Gnus v5.2.32/XEmacs 20.0

--Multipart_Wed_Jul__3_10:22:33_1996-1
Content-Type: text/plain; charset=US-ASCII

I'd like to pass on Thomas' distribution size reduction suggestion.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.
--Multipart_Wed_Jul__3_10:22:33_1996-1
Content-Type: message/rfc822

To: Steven L Baur <steve@miranova.com>
Subject: Re: GNUS 5.2.25, MailCrypt 3.4 and Xemacs-19.14
References: <m2pw6ntuyi.fsf@hammer.oche.de>
	<m2g27iovyx.fsf@deanna.miranova.com> <m2u3vxd6d7.fsf@hammer.oche.de>
	<m2n31k7ekn.fsf@deanna.miranova.com>
From: Thomas Bueschgens <sledge@hammer.oche.de>
Date: 01 Jul 1996 16:24:25 +0200
Message-ID: <m24tnsoxuu.fsf@hammer.oche.de>

 ...

Just in case my other posting never so the outer world:

	Why isn't the dstribution size of XEmacs reduced by almost 30%
	using the following two tricks:

	1) Creating *.info-Files instead of supplying them. Makeinfo
	   is QUITE fast and this will save about 1.5MB in the gzipped
	   distribution (and more for each elisp-package included,
	   when it comes with it's own info-stuff)

	2) Why "providing" elc's for ALL packages? Ok, bytecompiling
	   takes time, but as far as I understand Emacs/XEmacs, only
	   the stuff in 'prim' is needed to get a correclty dumped
	   XEmacs, right?  

	   Bytecompiling the otther .el-Files takes its time on my
	   486/100 Amd with 24MB and _slow_ disks, admitted, but this
	   would reduce the distrib-size about further 4MB

Are there "specific" reasons for the XEmacs-team to abandon one of
those size-reducing things? Esp. the first one would'nt cost THAT much
compile/install time, only a few minutes.

Just a though, comments are honestly welcomed.

Regards and thanks again for your hint/help,

		Thomas

-- 
 Thomas Bueschgens                      sledge@informatik.rwth-aachen.de
 Reihstrasse 61                         sledge@hammer.oche.de (uucp @ home)
 52062 Aachen                           PGP-Mails are welcome
 0241 / 404 817                         Public Key available on Server 
---------------------------------------------------------------------------
 The only system which is truly secure is one which is switched off and un-
 plugged, locked in a titanium lined safe, buried in a concrete bunker, and
 is surrounded by nerve gas and very highly paid armed guards. Even then, I
 wouldn't stake my life on it.                             -- Gene Spafford


--Multipart_Wed_Jul__3_10:22:33_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 12:16:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA28156 for xemacs-beta-people; Wed, 3 Jul 1996 12:16:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA28153 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 12:16:10 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA00822 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 12:12:54 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id MAA25557 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 12:12:07 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id MAA10373 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 12:12:05 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id NAA18980 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 13:12:04 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Some display bugs in 19.14
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 03 Jul 1996 13:07:35 -0400
Message-ID: <16227.836413655@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


Here are a couple of interesting display bugs that I noticed:

1.  Place the mouse pointer at the just under the toolbar but above
    the top of the scrollbar.  The mouse pointer changes to the same
    pointer as over the modeline.  However, pressing button 1 and 2
    produces an error "not over a window", but pressing button 3 gives
    the menu that would appear if the mouse pointer were in the same
    window as point.

2.  While playing around with mime-viewer mode in tm, there are some
    leftover junk.  My mail buffer had a preview showing of a
    postscript document.  With the frame split in two windows and the
    mail message in the top, scrolling the message left some junk in
    the bottom window.  The junk was a big red line, the same color
    and width as my text cursor.  Hmm, I can't reproduce it now...

Ray

P.S.  Is XEmacs capable of scrolling large glyphs such as a reduced
image of the first page of a PS document that tm put into the message
buffer?  It would be nice if it could.

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 12:23:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA28209 for xemacs-beta-people; Wed, 3 Jul 1996 12:23:45 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA28206 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 12:23:44 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA16675 for <xemacs-beta@xemacs.org>; Wed, 3 Jul 1996 12:23:39 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa14011;
          3 Jul 96 13:21 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id NAA03007; Wed, 3 Jul 1996 13:21:53 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id NAA29179; Wed, 3 Jul 1996 13:21:52 -0400
Date: Wed, 3 Jul 1996 13:21:52 -0400
Message-Id: <199607031721.NAA29179@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: xemacs-beta@xemacs.org
Subject: Font-lock bugs
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Cut a vital connection
X-WWW-Homepage: http://www.python.org/~bwarsaw


I'm seeing a lot of weird problems with font-lock suddenly stopping to
work.  I visit an existing file, and font-locking works great.  After
a time, it just stops font-locking at all (not even getting it
wrong!).  I actually have to revert-buffer to kick start font-lock
again.  It's very strange and I so far have no way to reproduce the
problem.  I have an inkling that it could be related to checking a
file in or out using VC with a CVS backend, but since that doesn't
always hose font-lock, there must be something else going on too.

Has anybody else seen this problem?

FTR: XEmacs 19.14, Solaris 2.5, with fast-lock, and
font-lock-maximum-size setq to nil.

-Barry

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 12:47:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA28319 for xemacs-beta-people; Wed, 3 Jul 1996 12:47:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA28316 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 12:46:58 -0500 (CDT)
Received: from plg.uwaterloo.ca (dmason@plg.uwaterloo.ca [129.97.140.10]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA03791 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 12:46:59 -0500 (CDT)
Received: (from dmason@localhost) by plg.uwaterloo.ca (8.7.5/8.7.3) id NAA25253; Wed, 3 Jul 1996 13:46:37 -0400 (EDT)
Date: Wed, 3 Jul 1996 13:46:37 -0400 (EDT)
From: Dave Mason <dmason@plg.uwaterloo.ca>
Message-Id: <199607031746.NAA25253@plg.uwaterloo.ca>
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Re: Some display bugs in 19.14
In-Reply-To: <16227.836413655@rtp.ericsson.se>
References: <16227.836413655@rtp.ericsson.se>
X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB
 !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP<lkW*7FT|:Dm
 9ejO^{)GHJdPQaa"C\<Ak`K27?328'V(u*|jAEZR9-z!o\^j:Cb&*tx_9\KbXD*2

Raymond Toy writes:
> 
> Here are a couple of interesting display bugs that I noticed:
> 
> 1.  Place the mouse pointer at the just under the toolbar but above
>     the top of the scrollbar.  The mouse pointer changes to the same
>     pointer as over the modeline.  However, pressing button 1 and 2
>     produces an error "not over a window", but pressing button 3 gives
>     the menu that would appear if the mouse pointer were in the same
>     window as point.

There doesn't have to be a menubar or toolbar for this to happen.  The
region is about 4 pixels high.

../Dave

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 13:05:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA28376 for xemacs-beta-people; Wed, 3 Jul 1996 13:05:06 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA28373 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 13:05:04 -0500 (CDT)
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA16813 for <xemacs-beta@xemacs.org>; Wed, 3 Jul 1996 13:04:59 -0500 (CDT)
Received: from FISHKILL by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9662;
   Wed, 03 Jul 96 14:05:13 EDT
Received: by FISHKILL (XAGENTA 4.0) id 3017; Wed, 3 Jul 1996 14:04:54 -0400 
Received: by spacedog.fishkill.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA25843; Wed, 3 Jul 1996 14:04:45 -0400
Date: Wed, 3 Jul 1996 14:04:45 -0400
Message-Id: <9607031804.AA25843@spacedog.fishkill.ibm.com>
From: "Doug Keller" <dkeller@VNET.IBM.COM>
To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
Cc: xemacs-beta@xemacs.org
Subject: Re: Font-lock bugs
In-Reply-To: <199607031721.NAA29179@anthem.CNRI.Reston.Va.US>
References: <199607031721.NAA29179@anthem.CNRI.Reston.Va.US>

Barry A. Warsaw writes:
 > I'm seeing a lot of weird problems with font-lock suddenly stopping to
 > work.  I visit an existing file, and font-locking works great.  After
 > a time, it just stops font-locking at all (not even getting it
 > wrong!).  I actually have to revert-buffer to kick start font-lock
 > again.  It's very strange and I so far have no way to reproduce the
 > problem.  I have an inkling that it could be related to checking a
 > file in or out using VC with a CVS backend, but since that doesn't
 > always hose font-lock, there must be something else going on too.
 >
 > Has anybody else seen this problem?

I have also noticed font-locking not working, I could not ever figure
out why it stopped working.

doug

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 13:27:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA28560 for xemacs-beta-people; Wed, 3 Jul 1996 13:27:36 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA28557 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 13:27:29 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA16877 for <xemacs-beta@xemacs.org>; Wed, 3 Jul 1996 13:27:24 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa15854;
          3 Jul 96 14:21 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id OAA04574; Wed, 3 Jul 1996 14:21:42 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id OAA29291; Wed, 3 Jul 1996 14:21:41 -0400
Date: Wed, 3 Jul 1996 14:21:41 -0400
Message-Id: <199607031821.OAA29291@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: Benedikt Eric Heinen <beh@icemark.thenet.ch>
Cc: xemacs-beta@xemacs.org
Subject: Re: Font-lock bugs
References: <199607031721.NAA29179@anthem.CNRI.Reston.Va.US>
	<Pine.LNX.3.91.960703200700.268A-100000@icemark.thenet.ch>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Change nothing and continue with immaculate consistency
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "BEH" == Benedikt Eric Heinen <beh@icemark.thenet.ch> writes:

    BEH> I recently noticed it at work with a vanilla XEmacs 19.13 (on
    BEH> AIX4),

Hmm, weird, because I never noticed it with 19.13.
    
    BEH> As for your temporary fix (reverting file) - you don't need
    BEH> to revert the buffer. It's sufficient to use 'M-x
    BEH> font-lock-mode' twice (to switch font-locking off and then on
    BEH> again).

Yeah, but I bind revert-buffer to M-C-r, which is easier to type. :-)
Thanks tho' for pointing out that really toggling font-lock-mode is
the lower level fix.  Its most like some cache is getting hose.  I
think I have noticed occasionally that newly visited font-locked files
in a fresh XEmacs also don't font-lock incrementally.  Leads me to
believe that some internal state isn't getting initialize properly
perhaps?

-Barry

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 13:12:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA28422 for xemacs-beta-people; Wed, 3 Jul 1996 13:12:25 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA28419 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 13:12:24 -0500 (CDT)
Received: from icemark.thenet.ch (beh@icemark.TheNet.CH [193.135.252.47]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA16845 for <xemacs-beta@xemacs.org>; Wed, 3 Jul 1996 13:12:16 -0500 (CDT)
Received: (from beh@localhost) by icemark.thenet.ch (8.6.12/8.6.12) id UAA00278; Wed, 3 Jul 1996 20:11:10 +0200
Date: Wed, 3 Jul 1996 20:11:09 +0200 (MET DST)
From: Benedikt Eric Heinen <beh@icemark.thenet.ch>
To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
cc: xemacs-beta@xemacs.org
Subject: Re: Font-lock bugs
In-Reply-To: <199607031721.NAA29179@anthem.CNRI.Reston.Va.US>
Message-ID: <Pine.LNX.3.91.960703200700.268A-100000@icemark.thenet.ch>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> I'm seeing a lot of weird problems with font-lock suddenly stopping to
> work.  I visit an existing file, and font-locking works great.  After
> a time, it just stops font-locking at all (not even getting it
> wrong!).  I actually have to revert-buffer to kick start font-lock
> again.  It's very strange and I so far have no way to reproduce the
> problem.

> Has anybody else seen this problem?

I recently noticed it at work with a vanilla XEmacs 19.13 (on AIX4), and 
I also can't reproduce it, which is why I haven't filed a buf report so far.
Your suspicion about the version controlling is probably not correct, 
because I looked at the 'lossage' in XEmacs to check what I did before 
it occured and only once the problem occured some time after a '\C-xvv'.

As for your temporary fix (reverting file) - you don't need to revert the 
buffer. It's sufficient to use 'M-x font-lock-mode' twice (to switch 
font-locking off and then on again).

yours,
	Benedikt

signoff

---
 Benedikt Eric Heinen  -  Muehlemattstrasse 53  -  CH3007 Bern  -   SWITZERLAND
 email: beh@icemark.thenet.ch				 phone: ++41.31.3714460


     ACCUSE, v.t.  To affirm another's guilt or unworth; most commonly as a
	       justification of ourselves for having wronged him.

		   Ambrose Bierce  ``The Devil's Dictionary''

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 14:23:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA28896 for xemacs-beta-people; Wed, 3 Jul 1996 14:23:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA28893 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 14:23:48 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA05628 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 14:23:49 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id MAA21917; Wed, 3 Jul 1996 12:23:17 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA05368; Wed, 3 Jul 96 15:23:15 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id PAA10845; Wed, 3 Jul 1996 15:23:11 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id PAA00364; Wed, 3 Jul 1996 15:23:04 -0400
Date: Wed, 3 Jul 1996 15:23:04 -0400
Message-Id: <199607031923.PAA00364@detlev.canada.sun.com>
From: Georg Nikodym <georgn@detlev.Canada.Sun.COM>
To: XEmacs Beta List <xemacs-beta@cs.uiuc.edu>
Subject: s/sol2-5.h buglet
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII


Small latent bug in sol2-5.h:

#ifndef NOT_C_CODE
/* Solaris 2.5 is the first Solaris that has getpagesize(), srandom()
   and random(), but they forgot to add prototypes to the header
   files. */
int getpagesize (void);
long random (void);
int srandom (unsigned int seed);
#endif /* NOT_C_CODE */

Well, in 2.6 we remembered to put in the prototypes (as per XPG4.2
in stdlib.h).  Turns out that the prototype for srandom should be:

	void srandom(unsigned int seed);

Since y'all seem to prefer patches instead of edifying erudition :-)
here it is:

*** sol2-5.h-DIST	Wed Jul  3 15:21:25 1996
--- sol2-5.h	Wed Jul  3 15:21:59 1996
***************
*** 27,33 ****
     files. */
  int getpagesize (void);
  long random (void);
! int srandom (unsigned int seed);
  #endif /* NOT_C_CODE */
  
  /* 2.5 now has random back in libc but we don't want to use it. */
--- 27,33 ----
     files. */
  int getpagesize (void);
  long random (void);
! void srandom (unsigned int seed);
  #endif /* NOT_C_CODE */
  
  /* 2.5 now has random back in libc but we don't want to use it. */

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 14:06:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA28868 for xemacs-beta-people; Wed, 3 Jul 1996 14:06:56 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA28865 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 14:06:43 -0500 (CDT)
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA05244 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 14:06:43 -0500 (CDT)
Received: from FISHKILL by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1565;
   Wed, 03 Jul 96 15:06:50 EDT
Received: by FISHKILL (XAGENTA 4.0) id 3040; Wed, 3 Jul 1996 15:06:17 -0400 
Received: by spacedog.fishkill.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA17162; Wed, 3 Jul 1996 15:06:15 -0400
Date: Wed, 3 Jul 1996 15:06:15 -0400
Message-Id: <9607031906.AA17162@spacedog.fishkill.ibm.com>
From: "Doug Keller" <dkeller@VNET.IBM.COM>
To: xemacs-beta@cs.uiuc.edu
Subject: Real Balloon Help

I have been playing around and through together some balloon help
code, it is real C code not lisp like Kyle did a while back.

Here is the C code with a small example program, the example requires
Motif.

I want to get feedback on what people think, should I finish this off
for 19.15 or 19.16?  Or is balloon help an overkill and not needed and
just continue to echo help in the message area?

begin 644 balloon.tar.gz
M'XL(`!^_VC$``^T[VW;CR'&<Q"?),'G(@\_)/K9E1R8Y($7J.I:B\9&HJZ.;
M18V'YZSV,"#0).$!T`S0$,G9F1._.+']G`_()^0C\@'Y@+PG#_F(5'4W@`9X
M&6EV9G?C$78HLNO6U=55U=6-WJ[INHSY*_ORNV85/O[3J-<WU]=)H0[?6W7Q
MW5!M_+FUVM@B]<W&YN;&VM;:UCH![,9FHT#JGT"7J2<*N1F`*O9KZKHT6$`W
M'X>/'`Q)OO^?/#]V?,N-;$K^+N2!X_=K@Q=%'68[;`KD.MTLS`Q#&O`LK-UH
MK+2G*`4TXHX[#:9C3OW087ZX$@[,(46*E&0I=M#!$D!MVG-\2CQS7!H;DS(I
MC5],?C[>GI13W/[E]<'A=>?5Z<'-"2%D(T%<79Y>W`#F\NBH=7A#GJ<LS<N+
MP\[)X>GQR0UPD-5Z%A.+(F2]7BR"N2*+DX[2BWQ=+!)RX(1#UYQ4B#V<[$"[
MR5P6>.:06/!G!RG:`D1Z_9VTT96-(^;SEI!:(;WD-Z*.FZ1O"?97CF^S$1DY
MOFA>.6.4[IGA:T6'#S:/FT#P;@?U-+ECD3OFV`15M3H6=EK*Z&ID-36(!=/`
MB34P@PH1]+[I44,IK$"=@/(H\$FY^#7T[?1*Y$>D?64&(154)2$W%I>(T%G+
MY.U;4A0Z(^\>JC>;-V$H`_G7@F4([LI[I:579N"#XVX#8>3:Q&=<CM/D5/*2
MOPUO_25-B?*.$*`+KKX8.F/JDEU21^2[XKO$<F!4*Z`@K=.W\E9+IR.U3:^?
M_N[B[]GSJLS6/F[^RG0C&L(,WV'7$<1`WZ<V<9G?5S,+8,#6>BR@_8!%O@UZ
M]OI*YQV%[9K6ZP3;S6.Q8_(4^1(-JB]ZCAWC?\T<OQ/RB4N!YA?0N$9),=:%
M(.B,')L/`+LN%$+-H''<Q.&1M_!C/U7@K8`GVF(39;:$?&R=@<!7*$_(4H[4
M;@H['S=+TKK"K-B/099!"P+SEDZ+,KV:FI%HY:<GG09E;3U\P/8MRB5DCT/R
MZT8<IL&$G]/S@-!.,AE)"PS0?'5Y1X/`L>DUM9V`6FB,YBLTQI5P*6RUS#OZ
MTK>ID(S<-::8P/\4URZY"2*:$*33V9&NF9]5016"X$Z$DL7D2@F`A!&27>'E
MRJBOE('0+L6G3P%Q0'MFY/)KQKB&)&6%KAOXKX'_8H#\;K+AY"A@'D0Z];E!
M3OUAQ"\C#G^-/%)R).:"><3?.)'2_"X,7/!K,PX\K:@KTVL4)%8]1W._S2$O
M&'=ZDP1U.!ZR$,`IP.<TD*-+8&<4;*;!1#90'B@<`WPLDS4YK$P=L3J!FG.B
M.9LQD<,@D)Z(2WWQHT)$]*C?`^KT!TD&:`*/R@FR%U0(F>W(\R;25#>`.13(
ML)3I5G8ENED6]#.^I51E]8H,8W`6":Z-9!@2LE*I*,42G!E:R/DL;MM4`'8J
M*R@IH=9S2L*B`V,^+7Z%:?N4=X1Y0^<-G8K>!YFZ@M5`1[<RMC.61ILFH\6&
MQ&)+%XD%X1208C+$02>]P+@K6A=JY8!_@A_:J!J"1@/'A<%1D9C!=:U!4!(T
M!OGIK?]3?4W+N)H^9$6/,JIQ8UD-=CD>I%S6-`VA/RR18M_3,#JM8G^VF]A#
MX.)A8)_/2$,NB^]7$08(WB@'6)ZCY/U5G*,@N)&JNRI$YC?5/*'N,.]'^C3V
M^K+\R4*[,Z$XN`[6"\I]DAZ[\H>P$Y8]J@U#*<4T94_4("6"CLUZ,1SF&OY+
MIELQ0GQ`X@5V535J""R!`*%R=5RDJ6RIH"U8`\'B`"JK&"?92D\09T0:FB&6
M$TRO'_O%>]F[,]B[_:3[5&1:[^R2]ADS[5]&-)A@9"O!J95_KOW>)DL]6.CL
MI5@CS<Y9J;ODXN79F8BAV*P+:T,7=!`=05EHD"@$-!%=U421F*B@^GW06'(Z
M@QW%QFBVYHKH7<YB8N7.ES5">M[2&395C5PPG^;GH&\)77;U,C8[IZ+0TOT@
MVYFQ2/^,!E`K:SJ\2Q?6)&1@N"+S'U!(%&R2"=M\@&D[BQ023_(\A\@Z0OL(
M8D/.D!YL"T?T;EH^F'"&7"Q4YTA%!EU:#\BU4>3W&,(D=F".Q&JX:)<AMH(/
M6!N5#>^WOLE5<6R0."ZU!6$,,ZOOJ9%ZDH/E5OVD%-`VULBFB7Y0\?#-UM;V
M`=BW)0XY]/T%6E..>'J-3?+9C+401_]L-VLF.=OW[2BS4JK-C7"$UH"-%@;&
MW&F>$RIJ4G>2EEIM4[TS!2<VD^T/PN/SA60#)0@[:AL%([YB2`9*T2_)&ODJ
M`^VR`+8G7Y+G""].QY;(7#.B2YYMS(TP+ZG=DQR:JR;?&_!Q]3RC1I$#$/E=
MC((&>7G:OBF+R*[*.JY<CHORCLRXZ6^Y45J&65J>5<''@Y5JG</F\9KB(..-
MVYRAII+Q&8/K9@^_#/3A/"QED'78,[):T8,\=ILI1#;0IVL!M42I#>E[IE<8
M"%01RGPC18Q82F-F+1$O6W+=RCGB].*FK:$+'#._?F;7UO>N/2L5V3\4MRXU
M`Q%_"K(B7:!%>7J^LE"5XR9LY&/Q[2/'=:]A-VWZ?7=^B,@A3(LQDD,`4IH]
M)^4'>$=VI(>^V74IY--`Y!%B^G+G34RP^#<9?..C#3[G5!]FAN3P$7)E_:L:
M+JO:Z?(*6<WB)S$^73X5LB&9ZUG0)`=:S7>1Q<T4+PQUQ=Q)G_D/-1,*-LB:
M@=$$O^_H&`^%8`DX9S:]#)R^XZ>)K(7G_$WF=1U?G-DLS@:">A_G'%96Y8UY
M?00-^$?:AXB@]^=)+;N:PVO3">E\S]+)M:)MD>Y:8;A@*4ISIEPSZYDI3H&3
M*6!C]C2GV)D3K=#*1^;Y<IYVD:BU!XA:DZ+NE2\RC.NSS++^H=(V9DG;6#S,
MS?F!FU(L$K`UJ].MS,R*,A+/R<.'N):09)#G\Z+N75)E8A6A59DW+"ET'K0/
M4SL8<=AIAKP#\2Z^M6KSD]6>W],J+:XQS"Y,W1@V$](PI$Q>0'7\]JU$3&+$
M1"%R-3#.SSWJ.S)^-E74Y2#I>8129)>,,Q#TNDE:@*0^<N+8V9.U![E&^Z4/
M)=[]<J_J];M^'?[9/=W<_8_!)^AC\?V/>GUCHR[O?ZQM-1H;#7'_8WWM\?['
MM_$4^61(;=HC^?L,^\DA][=ZTKXC$P\^]SLBU!@^Z-Q$XW_(BJBQW2-)[A1Y
MCP^[L!@5A(\]^2OX_'/AKPM_"J4OS,*3+^#S+]AVG2ZV2_#Y7>&'A1]$OC,N
M'+`WT'X.G]\#[,]13D#QIM:3`_C\`?B>1(6`P>]VH?`G7N&+PE_4>F$-3P@4
M+X3U#WX(O'\6LBBP:.$88&_A\S]Q_)^;KVG/<>FG\+'WQ?_J9CV^_[6YL5K'
M^%]?WWB,_V_C:8HK0[O$LHK-H[.]X]8NJ1YTKBY;I^U.Z_+E=?.05/O%L]/]
M%E)5W;:'?SC^P?"!KT:C6+S<_X7`AV#$&HL#H,:*Q9I58]O%IS\I-9ME`G]%
M'V52M<A/*C6K6$2.;4"@A'),5^V3*A/"8@Q\HPYE*!">_#?Z=^@YO.:R?N&B
M=0C#^!WXO0WPOQ3PT`J<(<?A_2M\_@;CRJ9WV/XW^'R!;<K%3<=_!WG_@'%!
MQT,6\((-L/\`6!^HBBX+^;,>;C@+-8#_IX@CC-'A$'G_"]K_A&W/%WW]+[1_
M@S$;8E"_[+2@#>`GOT5]O^_Q+V;N4US^++SW_F=C<VTSO?^Y)M;_QNKC_<]O
MY7GP7<\YUT3-H)^]L"GN=)[Z2!TZ5A[GK1PX)H1O*W</U%LY8H$W!;R*PL'^
M@@NAJG@Y=AGX\X')S7@'PO>&PR94%^(@<3B,-Y)VGW+X`9!P`-.>`WNFXZ,:
M\@9EKD#2^C@^N]Q/;UC*-SZD!VKAW:TOOX)\*+58PN"JI!>ZMH&64G??C>B2
MH5&D]_NV\<46SV+;WID3\MI,,>LY2KPN=!]*++Q0ZC:IFC;KTBI8XX[":,RJ
M1VTG\JI!U<<K!VZUVEBM5C+,'LRYXXM;?-OD^0S4B=CBISA\43]U)_4?(X<W
M]TO*^"-#0*&>!`/+WZ1B@4FQK3:;=.SP4EU[7T9%D9:7T#5(^_`.7R=6Z)VX
MJ;;/F$M-GU1LJ%I-;@W4NU%1#7JAO(7+?V4>4R[O9)906MN[B$(:'`B%EH',
M4#<.D'RJY(1>@42^S1/*N7C=[,.5FRHNNYILCW&'^1\N?'[!V]7?1V(\E,1A
M#$RK90B#D4H%&G=J2C`22.4-6B169D=9EG2CWI>K&YOBI6!:&:N[4NKLX`V>
M&:*0Y.*,NC>#L')9'8VDAR,>]4+*2R4QWO(;<1*<X5!G0X2\J;Z(HYSL%I_B
M]$)*./4=#OD'7Q,N2PI#>NZ2G%PA<%F.%H<IWB&1)+95$SQ#GF(9T-'61@I5
M1USPK-7K"HQB,VK%6296*[ZGB>8K+2$6\H$'"HT])).(IFN&H:&/2HJ'3N]H
M@('KMH:F)0[(X6G4$_2`!<X;"'>=0$-KP6P0]4RA3Y+1ZNCLR+IXZCF]46QS
MM54L:4,O@]6[+A@41KDT&@`3_KAG*B)IGZ.L#<]-W^Q36YF2+%T.J2_L*):1
MB'/FYZT9:Z1>%L*(.1ON<6Y:`T]$$"XFWM[-S5[SI'-T>7V>$KJTQ[.4<P@#
M-%Z&,B'$>OOF]/(B1WS%0@<C7'2_NIYBNPP&X>FR%HB2Q+JLC7J*37/;4K,Z
M)LUJ[]8GI%HED"Y$,C`M[MSA57IO"/M#F\!Z,22]R+=06NW6/[0=3G#K2(Y.
MSPXO]LX/`=@:.9!E"&?$Q`30HP&Y<U`!<=M*HS5N??%*%1'XVL_I$5^\_G,!
M:D\PV8<\!(D`O/7YB,&?04!Q:7RJ.9\Z,^5[MBTRWXGIVRXF,DB*N4O`!CDR
MW9`:<MDP9*I;Q)^[,)SPB\Q^#WZ55,]%LLY(D/E;B;B?+_^]X[K?B2]/^Q42
M9SR4K&Y^-&]?_]FG]O;;(MJ2\`$E^R^/C@ZO:X3<0`,R782]P+(W(5V:.C#K
M_AKOZ;,@!N")%7CF;?'B\N9P&YB=,`D,,C!#X*8^N-G`]"T('`P&R(@C\8X[
MH##YE$!F0]='(8XO=.DQI,%P&)F3;43@Y[0GD*ICZ&=D0GUHDV@(774G(G1`
MJ@<5)+%<!^^)&^(5NJF:P(-R\`8DLHHX!`8&4N/QA*@A#/@UF(7:!G8H54HD
M`(%KHQ@^,+FN4#)8R5O[7*/S*J!WW]OHW&A\M.C<^N1K$1;6Z&&W_A!LZK`(
MW'>D_I<?YO><_F?K8Q>PM_O>^MC6_5:`;)^?VH-\W/U+Y[GU/W/O^25LMS^F
M]TQ/$!!G?2(S01^C6KZW]VB$T_/<5)NYDMSCBS(7#!:##74R`29!XQ835FG1
MYL!Q[5)F'Z>)OZ9B<QE;7=^$IC,E#J?.@?N,L6%,E$K!]^'?]>G@X_/X/#Y_
MS,_C_;_'^W^/]_\>[_\]WO_[/)_'^W^?]_O_Q_M_C_?_'N__?;[Q_W]FY0E,
$`%```+_'
`
end

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 14:40:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA29005 for xemacs-beta-people; Wed, 3 Jul 1996 14:40:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA29002 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 14:40:18 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA06055 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 14:40:19 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id MAA26580; Wed, 3 Jul 1996 12:39:46 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA05682; Wed, 3 Jul 96 15:39:45 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id PAA11036; Wed, 3 Jul 1996 15:39:42 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id PAA00374; Wed, 3 Jul 1996 15:39:34 -0400
Date: Wed, 3 Jul 1996 15:39:34 -0400
Message-Id: <199607031939.PAA00374@detlev.canada.sun.com>
From: Georg Nikodym <georgn@detlev.Canada.Sun.COM>
To: XEmacs Beta List <xemacs-beta@cs.uiuc.edu>
Subject: another one
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII


Another buglet cause by similar recent additions to the 2.6 header
files.  This one's a little more interesting since no XEmacs code
seems to use usleep (unless my grep wasn't as well formed as it could
have been).

*** sunplay.c-DIST	Wed Jul  3 15:32:44 1996
--- sunplay.c	Wed Jul  3 15:34:39 1996
***************
*** 45,51 ****
  extern int audio_cmp_hdr();
  extern int audio_enc_to_str();
  extern int audio_drain();
- extern void usleep();
  #endif
  
  
--- 45,50 ----

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 15:30:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA29238 for xemacs-beta-people; Wed, 3 Jul 1996 15:30:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA29235 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 15:30:15 -0500 (CDT)
Received: from icemark.thenet.ch (beh@icemark.TheNet.CH [193.135.252.47]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA06946 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 15:30:10 -0500 (CDT)
Received: (from beh@localhost) by icemark.thenet.ch (8.6.12/8.6.12) id WAA00341; Wed, 3 Jul 1996 22:25:20 +0200
Date: Wed, 3 Jul 1996 22:25:20 +0200 (MET DST)
From: Benedikt Eric Heinen <beh@icemark.thenet.ch>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu, Thomas Bueschgens <sledge@hammer.oche.de>
Subject: Re: [Thomas Bueschgens <sledge@hammer.oche.de>] Re: GNUS 5.2.25, MailCrypt 3.4 and Xemacs-19.14
In-Reply-To: <m291d1ckv9.fsf@deanna.miranova.com>
Message-ID: <Pine.LNX.3.91.960703221957.300D-100000@icemark.thenet.ch>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On 3 Jul 1996, Steven L Baur wrote:
> I'd like to pass on Thomas' distribution size reduction suggestion.

>>        Why isn't the dstribution size of XEmacs reduced by almost 30%
>>        using the following two tricks:
>>
>>        1) Creating *.info-Files instead of supplying them. Makeinfo
>>           is QUITE fast and this will save about 1.5MB [...]
>>
>>        2) Why "providing" elc's for ALL packages? Ok, bytecompiling
>>           takes time, but as far as I understand Emacs/XEmacs, only
>>           the stuff in 'prim' is needed to get a correclty dumped
>>           XEmacs, right?  [...]

The question is - are we talking about the binary or source distribution 
here?

  If we are talking about the source distribution only, then I'll second 
those points. The Makefile surely can handle building that stuff.

  But - if we are talking about the binary distribution here, I am 
strictly AGAINST removing those things from the distributions, as the 
distribution should stay pretty easy as it could also be done by some 
'not-so-much-Unix-experts'. The current installation is so easy that even 
a 'DAU' (German abbreviation for 'most stupid user possible') should be 
able to do it, if (s)he can unpack the archive.


yours,
	Benedikt
signoff

---
 Benedikt Eric Heinen  -  Muehlemattstrasse 53  -  CH3007 Bern  -   SWITZERLAND
 email: beh@icemark.thenet.ch				 phone: ++41.31.3714460


     ACCUSE, v.t.  To affirm another's guilt or unworth; most commonly as a
	       justification of ourselves for having wronged him.

		   Ambrose Bierce  ``The Devil's Dictionary''



From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 16:03:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA29352 for xemacs-beta-people; Wed, 3 Jul 1996 16:03:41 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA29349 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 16:03:40 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA07644 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 16:03:40 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa19580;
          3 Jul 96 17:03 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id RAA09266; Wed, 3 Jul 1996 17:03:16 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id RAA29393; Wed, 3 Jul 1996 17:03:15 -0400
Date: Wed, 3 Jul 1996 17:03:15 -0400
Message-Id: <199607032103.RAA29393@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: Doug Keller <dkeller@VNET.IBM.COM>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Real Balloon Help
References: <9607031906.AA17162@spacedog.fishkill.ibm.com>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Water
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "DK" == Doug Keller <dkeller@vnet.ibm.com> writes:

    DK> I want to get feedback on what people think, should I finish
    DK> this off for 19.15 or 19.16?  Or is balloon help an overkill
    DK> and not needed and just continue to echo help in the message
    DK> area?

I have zero time to play with this unfortunately, but I think real
balloon help would be a win!

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 16:41:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA29552 for xemacs-beta-people; Wed, 3 Jul 1996 16:41:48 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA29549 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 16:41:47 -0500 (CDT)
Received: from hackvan.com (hackvan.com [206.80.31.242]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA08535 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 16:41:48 -0500 (CDT)
Received: by hackvan.com (Linux Smail3.1.29.1 #27)
	id m0ubZeg-000HE6C; Wed, 3 Jul 96 14:40 PDT
Message-Id: <m0ubZeg-000HE6C@hackvan.com>
Date: Wed, 3 Jul 96 14:40 PDT
From: stig@hackvan.com (Stig)
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Real Balloon Help
In-Reply-To: <199607032103.RAA29393@anthem.CNRI.Reston.Va.US>
References: <9607031906.AA17162@spacedog.fishkill.ibm.com>
	<199607032103.RAA29393@anthem.CNRI.Reston.Va.US>
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/

Barry A. Warsaw wrote:
> 
> >>>>> "DK" == Doug Keller <dkeller@vnet.ibm.com> writes:
> 
>     DK> I want to get feedback on what people think, should I finish
>     DK> this off for 19.15 or 19.16?  Or is balloon help an overkill
>     DK> and not needed and just continue to echo help in the message
>     DK> area?
> 
> I have zero time to play with this unfortunately, but I think real
> balloon help would be a win!

Agreed.  echoing help to the wrong side of the screen is better than nothing
but _clearly_ it's a kludge and should be improved upon.

    Stig
    

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 18:16:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA29961 for xemacs-beta-people; Wed, 3 Jul 1996 18:16:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA29958 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 18:16:29 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA17506 for <xemacs-beta@xemacs.org>; Wed, 3 Jul 1996 18:16:24 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id QAA26480; Wed, 3 Jul 1996 16:15:55 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA10844; Wed, 3 Jul 96 19:15:52 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id TAA16562; Wed, 3 Jul 1996 19:15:49 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id TAA00496; Wed, 3 Jul 1996 19:15:39 -0400
Date: Wed, 3 Jul 1996 19:15:39 -0400
Message-Id: <199607032315.TAA00496@detlev.canada.sun.com>
From: Georg Nikodym <georgn@detlev.Canada.Sun.COM>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: CLASH_DETECTION
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII


I've finally had it with the file locking stuff so I went poking
around in an attempt to shut it off...

Here're the patches.  The patch to configure and src/config.h.in have
been tested.  The patch to configure.in represents some educated
guessing.

<BORING PEDANTRY>
Realizing that some people may actually want the clash detection stuff
on and working, I looked at the code and have the following
suggestions:

	1) Lose the notion of SuperLock.  If the rest of the world
	   is "correct" then SuperLock is nothing more than a
	   bottleneck to concurrent access to the lockdir.
	2) Lose the code in filelock.c that attempts to flush
	   attribute cache data with extraneous calls to opendir().
	   This is a kludge of biblical proportions.  There is nothing
	   stopping an implementor of NFS from developing a fancy
	   cache mechanism that breaks this code.
	
	   The better way is to utilize NFS mount options (if
	   available) to control attribute cache characteristics.  The
	   option in the Sun world is "noac" (mount_nfs(1M)) which
	   is useful for things like the clients of mail servers...

Other less though out things that come to mind are:

	1) Since each machine in a NFS world will have a portion of
	   it's FS namespace which is private to it, the clash
	   detection code should use a separate location that is
	   on local disk for this kind of housekeeping.

	2) Better yet, redesign the whole thing altogether since it's
	   completely broken anyway.  Additionally, this problem (if
	   it even qualifies as such) should really be solved outside
	   the domain of any single application...
<\BORING PEDANTRY>

Anyway, here they are:

*** configure-DIST	Wed Jul  3 16:52:52 1996
--- configure	Wed Jul  3 18:06:27 1996
***************
*** 95,100 ****
--- 95,101 ----
  with_x11=''
  rel_alloc='default'
  use_system_malloc='default'
+ use_clash_detection='no'
  internal_makefile_list='Makefile lib-src/Makefile.in man/Makefile.in src/Makefile.in lwlib/Makefile.in dynodump/Makefile.in'
  energize_version='no'
  native_sound_lib=''
***************
*** 296,301 ****
--- 297,303 ----
    			is system-dependent).
  --use-system-malloc	Force use of the system malloc, rather than GNU
  			malloc.
+ --use-clash-detection	Override default clash detection.  Default=no.
  
  You may also specify any of the \`path' variables found in
  Makefile.in, including --bindir, --libdir, --lispdir, --datadir, and
***************
*** 937,942 ****
--- 939,962 ----
            eval "${opt}=\"${val}\""
          ;;
  
+         ## Has the user specified explicit instructions for use_clash_detection?
+ 	"use_clash_detection" )
+ 	  ## Make sure the value given was either "yes", "no", or "default".
+ 	  case "${val}" in
+ 	    y | ye | yes )	val=yes ;;
+ 	    n | no )		val=no  ;;
+ 	    d | de | def | defa | defau | defaul | default )
+ 				val=default ;;
+ 	    * )
+ 	      (echo "${progname}: the \`--${optname}' option is supposed to have a boolean value or \`default'.
+ Set it to either \`yes', \`no', or \`default'."
+ 	       echo "${short_usage}") >&2
+ 	      exit 1
+ 	    ;;
+ 	  esac
+           eval "${opt}=\"${val}\""
+         ;;
+ 
  	## Has the user tried to tell us where the X files are?
  	## I think these are dopey, but no less than three alpha
  	## testers, at large sites, have said they have their X files
***************
*** 3737,3742 ****
--- 3757,3768 ----
  configure___ system_malloc=no
  #endif
  
+ #ifdef USE_CLASH_DETECTION
+ configure__ use_clash_detection=yes
+ #else
+ configure__ use_clash_detection=no
+ #endif
+ 
  #ifndef C_DEBUG_SWITCH
  #define C_DEBUG_SWITCH -g
  #endif
***************
*** 7167,7172 ****
--- 7193,7214 ----
  }
   
  fi
+ 
+ if [ "${use_clash_detection}" = "yes" ]; then
+ 
+ {
+ test -n "$verbose" && \
+ echo "	defining USE_CLASH_DETECTION"
+ echo "#define" USE_CLASH_DETECTION "1" >> confdefs.h
+ DEFS="$DEFS -DUSE_CLASH_DETECTION=1"
+ ac_sed_defs="${ac_sed_defs}\${ac_dA}USE_CLASH_DETECTION\${ac_dB}USE_CLASH_DETECTION\${ac_dC}1\${ac_dD}
+ \${ac_uA}USE_CLASH_DETECTION\${ac_uB}USE_CLASH_DETECTION\${ac_uC}1\${ac_uD}
+ \${ac_eA}USE_CLASH_DETECTION\${ac_eB}USE_CLASH_DETECTION\${ac_eC}1\${ac_eD}
+ "
+ }
+ 
+ fi
+ 
  if [ "${rel_alloc}" = "yes" ] ; then
     
  {

*** src/config.h.in-DIST	Wed Jul  3 17:13:58 1996
--- src/config.h.in	Wed Jul  3 18:20:39 1996
***************
*** 103,112 ****
  
  #undef HAVE_LONG_FILE_NAMES
  
- #ifdef HAVE_LONG_FILE_NAMES
- #define CLASH_DETECTION
- #endif
- 
  #undef HAVE_LIBDNET
  #undef HAVE_LIBRESOLV
  
--- 103,108 ----
***************
*** 409,414 ****
--- 405,415 ----
  #define SYSTEM_MALLOC
  #endif
  
+ #undef USE_CLASH_DETECTION
+ #if defined(USE_CLASH_DETECTION) && !defined(CLASH_DETECTION)
+ #define CLASH_DETECTION
+ #endif
+ 
  #if 0 /* RMSmacs */
  /* These typedefs shouldn't appear when alloca.s or Makefile.in
     includes config.h.  */

*** configure.in-DIST	Wed Jul  3 16:52:44 1996
--- configure.in	Wed Jul  3 18:06:17 1996
***************
*** 110,115 ****
--- 110,116 ----
  with_x11=''
  rel_alloc='default'
  use_system_malloc='default'
+ use_clash_detection='no'
  internal_makefile_list='Makefile lib-src/Makefile.in man/Makefile.in src/Makefile.in lwlib/Makefile.in dynodump/Makefile.in'
  energize_version='no'
  native_sound_lib=''
***************
*** 311,316 ****
--- 312,318 ----
    			is system-dependent).
  --use-system-malloc	Force use of the system malloc, rather than GNU
  			malloc.
+ --use-clash-detection	Override default clash detection.  Default=no.
  
  You may also specify any of the \`path' variables found in
  Makefile.in, including --bindir, --libdir, --lispdir, --datadir, and
***************
*** 952,957 ****
--- 954,977 ----
            eval "${opt}=\"${val}\""
          ;;
  
+         ## Has the user specified explicit instructions for use_clash_detection?
+ 	"use_clash_detection" )
+ 	  ## Make sure the value given was either "yes", "no", or "default".
+ 	  case "${val}" in
+ 	    y | ye | yes )	val=yes ;;
+ 	    n | no )		val=no  ;;
+ 	    d | de | def | defa | defau | defaul | default )
+ 				val=default ;;
+ 	    * )
+ 	      (echo "${progname}: the \`--${optname}' option is supposed to have a boolean value or \`default'.
+ Set it to either \`yes', \`no', or \`default'."
+ 	       echo "${short_usage}") >&2
+ 	      exit 1
+ 	    ;;
+ 	  esac
+           eval "${opt}=\"${val}\""
+         ;;
+ 
  	## Has the user tried to tell us where the X files are?
  	## I think these are dopey, but no less than three alpha
  	## testers, at large sites, have said they have their X files
***************
*** 2910,2915 ****
--- 2930,2941 ----
  configure___ system_malloc=no
  #endif
  
+ #ifdef USE_CLASH_DETECTION
+ configure__ use_clash_detection=yes
+ #else
+ congigure__ use_clash_detection=no
+ #endif
+ 
  #ifndef C_DEBUG_SWITCH
  #define C_DEBUG_SWITCH -g
  #endif
***************
*** 4021,4026 ****
--- 4047,4055 ----
  elif [ "${use_system_malloc}" = "yes" ]; then
    ] AC_DEFINE(USE_SYSTEM_MALLOC) [
  fi
+ if [ "${use_clash_detection} = "yes" ]; then
+   ] AC_DEFINE(USE_CLASH_DETECTION) [
+ fi
  if [ "${rel_alloc}" = "yes" ] ; then
    ] AC_DEFINE(REL_ALLOC) [
  fi

From xemacs-beta-request@cs.uiuc.edu  Wed Jul  3 23:15:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA01098 for xemacs-beta-people; Wed, 3 Jul 1996 23:15:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA01095 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 3 Jul 1996 23:15:46 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA21796 for <xemacs-beta@cs.uiuc.edu>; Wed, 3 Jul 1996 23:15:47 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id VAA12777; Wed, 3 Jul 1996 21:15:15 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id VAA29371; Wed, 3 Jul 1996 21:15:04 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA11358; Wed, 3 Jul 1996 21:15:03 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA24758; Wed, 3 Jul 1996 21:14:57 -0700
Date: Wed, 3 Jul 1996 21:14:57 -0700
Message-Id: <199607040414.VAA24758@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: georgn@canada.sun.com
Cc: XEmacs Beta List <xemacs-beta@cs.uiuc.edu>
Subject: another one
In-Reply-To: <199607031939.PAA00374@detlev.canada.sun.com>
References: <199607031939.PAA00374@detlev.canada.sun.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Georg" == Georg Nikodym <georgn@detlev.Canada> writes:

Georg> Another buglet cause by similar recent additions to the 2.6 header
Georg> files.  This one's a little more interesting since no XEmacs code
Georg> seems to use usleep (unless my grep wasn't as well formed as it could
Georg> have been).

Georg> *** sunplay.c-DIST	Wed Jul  3 15:32:44 1996
Georg> --- sunplay.c	Wed Jul  3 15:34:39 1996
Georg> ***************
Georg> *** 45,51 ****
Georg>   extern int audio_cmp_hdr();
Georg>   extern int audio_enc_to_str();
Georg>   extern int audio_drain();
Georg> - extern void usleep();
Georg>   #endif
  
Maybe not this particular usleep, but my grep reveals:

./src/libsst.c:33:extern void usleep();
./src/libsst.c:454:    usleep( usec );
./src/libsst.c:494:	    case ',': usleep( usecper ); break;	/* big pause */
./src/libsst.c:503:	usleep( usecpause );
./lisp/oobr/tree-x/dissolve.c:145:      usleep(50000);
./lisp/oobr/tree-x/dissolve.c:168:      usleep(50000);
./lisp/oobr/tree-x/dissolve.c:187:      usleep(50000);
./lisp/oobr/tree-x/dissolve.c:221:      usleep(idle);
./lisp/oobr/tree-x/dissolve.c:242:      usleep(50000);
./lisp/oobr/tree-x/intf.c:357:    usleep(PauseTime * 100000);
./lisp/oobr/tree-x/usleep.c:3: *      usleep     -- This is the precision timer for Test Set
./lisp/oobr/tree-x/usleep.c:37:int     usleep( unsigned long int microSeconds )
./lisp/oobr/tree-x/usleep.c:49:                perror( "usleep time out of range ( 0 -> 4000000 ) " );
./lisp/oobr/tree-x/usleep.c:61:                perror( "usleep (select) failed" );

Interesting, all that C code hidden away inside the lisp tree.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Jul  4 01:50:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA01608 for xemacs-beta-people; Thu, 4 Jul 1996 01:50:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA01605 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 4 Jul 1996 01:50:46 -0500 (CDT)
Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA23611 for <xemacs-beta@cs.uiuc.edu>; Thu, 4 Jul 1996 01:49:10 -0500 (CDT)
Received: from downtown.oche.de (root@downtown.oche.de [194.94.253.3]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12)
	with SMTP id IAA15375; Thu, 4 Jul 1996 08:45:02 +0200
Received: (from sledge@localhost) by hammer.oche.de (8.7.5/8.7.3) id IAA01930; Thu, 4 Jul 1996 08:05:56 +0200
To: Benedikt Eric Heinen <beh@icemark.thenet.ch>, xemacs-beta@cs.uiuc.edu
Subject: Re: [Thomas Bueschgens <sledge@hammer.oche.de>] Re: GNUS 5.2.25, MailCrypt 3.4 and Xemacs-19.14
References: <Pine.LNX.3.91.960703221957.300D-100000@icemark.thenet.ch>
From: Thomas Bueschgens <sledge@hammer.oche.de>
Date: 04 Jul 1996 08:05:55 +0200
In-Reply-To: Benedikt Eric Heinen's message of Wed, 3 Jul 1996 22:25:20 +0200 (MET DST)
Message-ID: <m2ybl0k0xo.fsf@hammer.oche.de>
Lines: 53
X-Mailer: Gnus v5.2.32/XEmacs 19.14


   "Benedikt" == Benedikt Eric Heinen <beh@icemark.thenet.ch> writes:

Benedikt> On 3 Jul 1996, Steven L Baur wrote:
>> I'd like to pass on Thomas' distribution size reduction suggestion.
Good idea!

Even though I am not a member of the XEmacs beta-tester community I
dare to participate in this discussion.

>>> Why isn't the dstribution size of XEmacs reduced by almost 30%
>>> using the following two tricks:
>>> 
>>> 1) Creating *.info-Files instead of supplying them. Makeinfo is
>>> QUITE fast and this will save about 1.5MB [...]
>>> 
>>> 2) Why "providing" elc's for ALL packages? Ok, bytecompiling takes
>>> time, but as far as I understand Emacs/XEmacs, only the stuff in
>>> 'prim' is needed to get a correclty dumped XEmacs, right?  [...]

Benedikt> The question is - are we talking about the binary or source
Benedikt> distribution here?
The source one (at least this is the one I thought of).

Benedikt> If we are talking about the source distribution only, then
Benedikt> I'll second those points. The Makefile surely can handle
Benedikt> building that stuff.
It _almost_ does handle those targets! If memory serves me right Jamie
supplied a shellscript which byte-compiles all the *.el-files if a
working XEmacs is given. But supplying the elc's in the 'prim'-dir
should be enough to dump a working one, right?

Benedikt> But - if we are talking about the binary distribution here,
Benedikt> I am strictly AGAINST removing those things from the
Benedikt> distributions, as the distribution should stay pretty easy
Benedikt> as it could also be done by some 'not-so-much-Unix-experts'.
Correct. The binary-distribs are for people who like things rather
fast and easy. 

Best Regards,

		Thomas

-- 
 Thomas Bueschgens                      sledge@informatik.rwth-aachen.de
 Reihstrasse 61                         sledge@hammer.oche.de (uucp @ home)
 52062 Aachen                           PGP-Mails are welcome
 0241 / 404 817                         Public Key available on Server 
---------------------------------------------------------------------------
 The only system which is truly secure is one which is switched off and un-
 plugged, locked in a titanium lined safe, buried in a concrete bunker, and
 is surrounded by nerve gas and very highly paid armed guards. Even then, I
 wouldn't stake my life on it.                             -- Gene Spafford

From xemacs-beta-request@cs.uiuc.edu  Thu Jul  4 02:40:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA01730 for xemacs-beta-people; Thu, 4 Jul 1996 02:40:48 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA01727 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 4 Jul 1996 02:40:46 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA24060 for <xemacs-beta@cs.uiuc.edu>; Thu, 4 Jul 1996 02:40:48 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id AAA04658; Thu, 4 Jul 1996 00:39:19 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id AAA06527; Thu, 4 Jul 1996 00:39:17 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA12437; Thu, 4 Jul 1996 00:39:16 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA25926; Thu, 4 Jul 1996 00:39:12 -0700
Date: Thu, 4 Jul 1996 00:39:12 -0700
Message-Id: <199607040739.AAA25926@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Thomas Bueschgens <sledge@hammer.oche.de>
Cc: Benedikt Eric Heinen <beh@icemark.thenet.ch>, xemacs-beta@cs.uiuc.edu
Subject: Re: [Thomas Bueschgens <sledge@hammer.oche.de>] Re: GNUS 5.2.25, MailCrypt 3.4 and Xemacs-19.14
In-Reply-To: <m2ybl0k0xo.fsf@hammer.oche.de>
References: <Pine.LNX.3.91.960703221957.300D-100000@icemark.thenet.ch>
	<m2ybl0k0xo.fsf@hammer.oche.de>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Thomas" == Thomas Bueschgens <sledge@hammer.oche.de> writes:

Thomas> It _almost_ does handle those targets! If memory serves me right Jamie
Thomas> supplied a shellscript which byte-compiles all the *.el-files if a
Thomas> working XEmacs is given. But supplying the elc's in the 'prim'-dir
Thomas> should be enough to dump a working one, right?

It takes quite a while to recompile the elc's.  It all depends on your
net connection.  I am blessed with a net connection that allows me to
download elc's much faster than it takes to compile them (with make
all-elc).

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Jul  4 03:04:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA02284 for xemacs-beta-people; Thu, 4 Jul 1996 03:04:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA02264 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 4 Jul 1996 03:04:04 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA24241 for <xemacs-beta@cs.uiuc.edu>; Thu, 4 Jul 1996 03:04:02 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id JAA16506; Thu, 4 Jul 1996 09:04:43 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id JAA05074; Thu, 4 Jul 1996 09:04:16 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id JAA15257; Thu, 4 Jul 1996 09:07:49 +0100
Date: Thu, 4 Jul 1996 09:07:49 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199607040807.JAA15257@wrath.parallax.co.uk>
To: georgn@canada.sun.com, mrb@eng.sun.com
Subject: Re: another one
Cc: xemacs-beta@cs.uiuc.edu
X-Sun-Charset: US-ASCII


> >>>>> "Georg" == Georg Nikodym <georgn@detlev.Canada> writes:
> 
> Georg> Another buglet cause by similar recent additions to the 2.6 header
> Georg> files.  This one's a little more interesting since no XEmacs code
> Georg> seems to use usleep (unless my grep wasn't as well formed as it could
> Georg> have been).
> 
> Georg> *** sunplay.c-DIST	Wed Jul  3 15:32:44 1996
> Georg> --- sunplay.c	Wed Jul  3 15:34:39 1996
> Georg> ***************
> Georg> *** 45,51 ****
> Georg>   extern int audio_cmp_hdr();
> Georg>   extern int audio_enc_to_str();
> Georg>   extern int audio_drain();
> Georg> - extern void usleep();
> Georg>   #endif
>   
> Maybe not this particular usleep, but my grep reveals:
> 
> ./src/libsst.c:33:extern void usleep();
> ./src/libsst.c:454:    usleep( usec );
> ./src/libsst.c:494:	    case ',': usleep( usecper ); break;	/* big pause */
> ./src/libsst.c:503:	usleep( usecpause );
> ./lisp/oobr/tree-x/dissolve.c:145:      usleep(50000);
> ./lisp/oobr/tree-x/dissolve.c:168:      usleep(50000);
> ./lisp/oobr/tree-x/dissolve.c:187:      usleep(50000);
> ./lisp/oobr/tree-x/dissolve.c:221:      usleep(idle);
> ./lisp/oobr/tree-x/dissolve.c:242:      usleep(50000);
> ./lisp/oobr/tree-x/intf.c:357:    usleep(PauseTime * 100000);
> ./lisp/oobr/tree-x/usleep.c:3: *      usleep     -- This is the precision timer for Test Set
> ./lisp/oobr/tree-x/usleep.c:37:int     usleep( unsigned long int microSeconds )
> ./lisp/oobr/tree-x/usleep.c:49:                perror( "usleep time out of range ( 0 -> 4000000 ) " );
> ./lisp/oobr/tree-x/usleep.c:61:                perror( "usleep (select) failed" );
> 
> Interesting, all that C code hidden away inside the lisp tree.

I thought the oobr stuff was going to be added to lib-src eventually,
its annoying because you currently have to build it by hand.

andy

From xemacs-beta-request@cs.uiuc.edu  Thu Jul  4 04:58:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA05676 for xemacs-beta-people; Thu, 4 Jul 1996 04:58:57 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA05673 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 4 Jul 1996 04:58:51 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA25261 for <xemacs-beta@cs.uiuc.edu>; Thu, 4 Jul 1996 04:58:44 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Thu, 4 Jul 1996 11:58:09 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id LAA02166; Thu, 4 Jul 1996 11:57:56 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id LAA14926;
          Thu, 4 Jul 1996 11:56:14 +0200
Date: Thu, 4 Jul 1996 11:56:14 +0200
Message-Id: <199607040956.LAA14926@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: Thomas Bueschgens <sledge@hammer.oche.de>,
        Benedikt Eric Heinen <beh@icemark.thenet.ch>, xemacs-beta@cs.uiuc.edu
Subject: Re: [Thomas Bueschgens <sledge@hammer.oche.de>] Re: GNUS 5.2.25, 
         MailCrypt 3.4 and Xemacs-19.14
In-Reply-To: <199607040739.AAA25926@xemacs.eng.sun.com>
References: <Pine.LNX.3.91.960703221957.300D-100000@icemark.thenet.ch> <m2ybl0k0xo.fsf@hammer.oche.de> <199607040739.AAA25926@xemacs.eng.sun.com>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q(\V9 
        +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy 
        ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x 
        zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B: 
        s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:

>>>>> "Thomas" == Thomas Bueschgens <sledge@hammer.oche.de> writes:
    Thomas> It _almost_ does handle those targets! If memory serves me
    Thomas> right Jamie supplied a shellscript which byte-compiles all
    Thomas> the *.el-files if a working XEmacs is given. But supplying
    Thomas> the elc's in the 'prim'-dir should be enough to dump a
    Thomas> working one, right?

    Martin> It takes quite a while to recompile the elc's.  It all
    Martin> depends on your net connection.  I am blessed with a net
    Martin> connection that allows me to download elc's much faster
    Martin> than it takes to compile them (with make all-elc).

    Martin> Martin

What about an additional package tar file, in which everything, which
could be rebuild with a make, is deleted?

From xemacs-beta-request@cs.uiuc.edu  Thu Jul  4 04:53:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA05661 for xemacs-beta-people; Thu, 4 Jul 1996 04:53:54 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA05658 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 4 Jul 1996 04:53:44 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA25225 for <xemacs-beta@cs.uiuc.edu>; Thu, 4 Jul 1996 04:53:42 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Thu, 4 Jul 1996 11:52:27 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id LAA02105; Thu, 4 Jul 1996 11:52:08 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id LAA14924;
          Thu, 4 Jul 1996 11:50:24 +0200
Date: Thu, 4 Jul 1996 11:50:24 +0200
Message-Id: <199607040950.LAA14924@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de>
To: Doug Keller <dkeller@VNET.IBM.COM>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Real Balloon Help
In-Reply-To: <9607031906.AA17162@spacedog.fishkill.ibm.com>
References: <9607031906.AA17162@spacedog.fishkill.ibm.com>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q(\V9 
        +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy 
        ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x 
        zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B: 
        s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Doug" == Doug Keller <dkeller@VNET.IBM.COM> writes:

    Doug> I have been playing around and through together some balloon
    Doug> help code, it is real C code not lisp like Kyle did a while
    Doug> back.

    Doug> Here is the C code with a small example program, the example
    Doug> requires Motif.

    Doug> I want to get feedback on what people think, should I finish
    Doug> this off for 19.15 or 19.16?  Or is balloon help an overkill
    Doug> and not needed and just continue to echo help in the message
    Doug> area?

Last year I'd written an article about the XEmacs 19.13. In this
article I'd told also something about the ballon help package from
Kyle. After that a lot of people asked me, where they could
get this package. So I think, that your work would be a win for the
XEmacs. 


Heiko

PS: The newest Netscape version has also a ballon help for its toolbar
    icons. Maybe Jamie was insperated by Kyles package :-)

From xemacs-beta-request@cs.uiuc.edu  Thu Jul  4 06:24:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA06061 for xemacs-beta-people; Thu, 4 Jul 1996 06:24:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA06058 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 4 Jul 1996 06:24:50 -0500 (CDT)
Received: from gateway.msc.ie ([194.125.117.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA27637 for <xemacs-beta@cs.uiuc.edu>; Thu, 4 Jul 1996 06:23:59 -0500 (CDT)
Received: from opc022.msc.ie (opc022.msc.ie [194.125.117.22]) by gateway.msc.ie 
	  Sendmail (v8.7.5) with SMTP id MAA02156;
	  Thu, 4 Jul 1996 12:17:44 +0100
Message-ID: <31DBA39D.740D@msc.ie>
Date: Thu, 04 Jul 1996 11:57:33 +0100
From: Russell Ritchie <ritchier@msc.ie>
Reply-To: ritchier@msc.ie
Organization: Managed Solutions Corporation
X-Mailer: Mozilla 3.0b4 (Win95; I)
MIME-Version: 1.0
To: crashes@xemacs.org
CC: xemacs-beta@cs.uiuc.edu
Subject: 19.14 release crash on mips-sni-sys4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(At last I've had ftp access for long enough to get the source.)
What I get seems to run fine -nw in an xterm, but bombs on startup
using X itself.  Any suggestions?  Here's what info I have.

Configured for `mips-sni-sysv4'.

  Where should the build process find the source code?    /foo/xemacs-19.14
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/usg5-4.h' and `m/mips-siemens.h'
  What compiler should XEmacs be built with?              cc -DSVSV -g
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /home/SIWIN/X/include
  Where do we find X Windows libraries?                   /home/SIWIN/X/lib
  Compiling in support for XAUTH.     
  Compiling in support for GIF image conversion.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.
  Compiling in code for checking XEmacs memory usage.

% cc -v
Begin cc, version 1.00.11:3.5G K01 of 20 Apr 1994
        Driver version V3.5G
        used ULS-package Version: 02.06D
        using machine header file: /opt/C/lib/ulsmch
        msgcatname: c
Copyright (C) Siemens Nixdorf Informationssysteme AG 1994
Contains parts which belong to the copyrights of MIPS Technologies, Inc.
All rights reserved.
        tmpdirname: /var/tmp/

and the requesite C backtrace:

dbx xemacs core
dbx 2.0C00 SINIX (Feb 24 1994)
Copyright (C) Siemens Nixdorf Informationssysteme AG 1991
Base:   BSD, Copyright (C) The Regents of the University of California
All rights reserved
reading symbolic information ...
[using memory image in core]
Type 'help' for help
(dbx) backtrace
backtrace
^ unrecognized command
(dbx) where
.kill() at 0x1802ded4
fatal_error_signal(sig = 11), line 195 in "emacs.c"
sigacthandler() at 0x18036e78
.XtInitializeWidgetClass() at 0x18218360
_XtCreate() at 0x182186ec
_XtCreatePopupShell() at 0x1821919c
.XtCreatePopupShell() at 0x18219224
x_create_widgets(f = 0x898d00, lisp_window_id = 276221956, parent = 276221956), 
line 1483 in "frame-x.c"
x_init_frame_1(f = 0x898d00, props = 276221956), line 1704 in "frame-x.c"
Fmake_frame(props = 276221956, device = 277003264), line 423 in "frame.c"
primitive_funcall(fn = Fmake_frame, nargs = 2, args = 0x88346c), line 3486 in 
"eval.c"
funcall_subr(subr = 0x67e3e4, args = 0x88346c), line 3526 in "eval.c"
$b614, line 3207 in "eval.c"
funcall_recording_as(recorded_as = 276320156, nargs = 2, args = 0x883468), line 
3207 in "eval.c"
Ffuncall(nargs = 3, args = 0x883468), line 3253 in "eval.c"
Fbyte_code(bytestr = 812301592, vector = 1080737116, maxdepth = 5), line 450 in 
"bytecode.c"
$b625, line 3636 in "eval.c"
funcall_lambda(fun = 275430820, nargs = 0, arg_vector = 0x8837ec), line 3636 in 
"eval.c"
funcall_recording_as(recorded_as = 276500020, nargs = 0, args = 0x8837e8), line 
3210 in "eval.c"
Ffuncall(nargs = 1, args = 0x8837e8), line 3253 in "eval.c"
Fbyte_code(bytestr = 812583516, vector = 1081019088, maxdepth = 4), line 450 in 
"bytecode.c"
$b625, line 3636 in "eval.c"
funcall_lambda(fun = 275712916, nargs = 0, arg_vector = 0x88392c), line 3636 in 
"eval.c"
funcall_recording_as(recorded_as = 276761228, nargs = 0, args = 0x883928), line 
3210 in "eval.c"
Ffuncall(nargs = 1, args = 0x883928), line 3253 in "eval.c"
Fbyte_code(bytestr = 812582256, vector = 1081017792, maxdepth = 4), line 450 in 
"bytecode.c"
$b625, line 3636 in "eval.c"
funcall_lambda(fun = 275711728, nargs = 0, arg_vector = (nilv)), line 3636 in 
"eval.c"
apply_lambda(fun = 275711728, numargs = 0, unevalled_args = 276221956), line 3559 
in "eval.c"
Feval(form = 545297300), line 3068 in "eval.c"
condition_case_1(handlers = 276222052, bfun = Feval, barg = 545297300, hfun = 
cmd_error, harg = 276221956), line 1672 in "eval.c"
top_level_1(dummy = 276221956), line 194 in "cmdloop.c"
internal_catch(tag = 276299196, func = top_level_1, arg = 276221956, threw = 
(nilv)), line 1347 in "eval.c"
initial_command_loop(load_me = 276221956), line 253 in "cmdloop.c"
main_1(argc = 1, argv = 0x7fffea04, envp = 0x7fffea0c), line 1317 in "emacs.c"
.emacs.main(argc = 1, argv = 0x7fffea04, envp = 0x7fffea0c), line 1461 in "emacs.c"
_start() at 0x405fe4
(dbx) quit

From xemacs-beta-request@cs.uiuc.edu  Thu Jul  4 09:59:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA06751 for xemacs-beta-people; Thu, 4 Jul 1996 09:59:28 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA06748 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 4 Jul 1996 09:59:27 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA04606 for <xemacs-beta@cs.uiuc.edu>; Thu, 4 Jul 1996 09:59:27 -0500 (CDT)
Message-Id: <199607041459.JAA04606@a.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.39.111.2/16.2) id AA065378803; Thu, 4 Jul 1996 15:00:03 +0100
Date: Thu, 4 Jul 1996 15:00:03 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@cs.uiuc.edu
Subject: 19.14 on hpux 10.10
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



Finally found some time to look into this. FTR, compiling on hpux
10.10 lead to a hang in gnus when compiled with optimization on.

I've just discovered that my hpux 10.01 binary was working less well
than expected. In fact, on a 10.10 system, (while t) was not
interupted by C-g. I defined BROKEN_SIGIO and recompiled on 10.10,
and... the hang is now gone.

As far as configure goes, this will be a bit tricky: BROKEN_SIGIO is
needed on 10.10, but *not* on 10.01: If I run my 10.01 binary on a
10.01 machine, without BROKEN_SIGIO being defined, C-g works as
expected.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Thu Jul  4 11:07:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA06979 for xemacs-beta-people; Thu, 4 Jul 1996 11:07:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA06976 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 4 Jul 1996 11:07:32 -0500 (CDT)
Received: from maes.esrin.esa.it (maes.esrin.esa.it [192.106.252.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA06759 for <xemacs-beta@cs.uiuc.edu>; Thu, 4 Jul 1996 11:06:52 -0500 (CDT)
Received: from mail.esrin.esa.it (plod.esrin.esa.it) by maes.esrin.esa.it with SMTP id AA28567
  (5.65c/IDA-1.4.4 for <xemacs-beta@cs.uiuc.edu>); Thu, 4 Jul 1996 18:06:48 +0200
Received: from penelope.esa.it by mail.esrin.esa.it (4.1/SMI-4.1)
	id AA00543; Thu, 4 Jul 96 16:09:15 GMT
Date: Thu, 4 Jul 96 16:09:15 GMT
Message-Id: <9607041609.AA00543@mail.esrin.esa.it>
Received: by penelope.esa.it (4.1/SMI-4.1)
	id AA14540; Thu, 4 Jul 96 18:09:11 +0200
From: Simon Marshall <Simon.Marshall@esrin.esa.it>
To: Ben Wing <wing@666.com>
Cc: XEmacs Beta <xemacs-beta@cs.uiuc.edu>,
        Richard Stallman <rms@gnu.ai.mit.edu>
In-Reply-To: <199606300150.BAA02865@nene.boundless.com> (message from Ben Wing
	on Sun, 30 Jun 1996 01:50:20 GMT)
Subject: Re: ``XEmacs does not have the features to support lazy-lock.el''
Reply-To: Simon Marshall <Simon.Marshall@esrin.esa.it>

Ben> Simon Marshall doesn't know what he's talking about and has obviously
Ben> not spent the time to verify the accuracy of the assertions he makes,
Ben> because many of them are unfounded and some are completely wrong.
Ben> The kludges he got RMS to implement are the wrong approach -- they're
Ben> completely hackish and not general and don't handle all cases,
Ben> esp. in XEmacs where you can have variable-width and variable-height
Ben> lines.

The point about variable-width and variable-height lines is right, but the
conclusion is wrong.  I'm not sure you realise (a) how lazy-lock.el
fontifies a region and (b) what XEmacs 19.14 supports or could support.

All versions of lazy-lock.el, including the ones distributed with versions
of XEmacs, assume that lines are of equal height, etc.  So no version
handles variable-width and variable-height lines properly.  The problem
has nothing to do with the mechanism by which lazy-lock.el learns of
scrolling (the "kludges" as you call them), it is to do with the mechanism
by which lazy-lock.el fontifies a window.  You are confusing the two.

For the second part, all versions of lazy-lock.el could be made to work
with variable-width and variable-height lines in XEmacs 19.14, since they
could use the new function window-displayed-height.  It may be that the
new function doesn't work quite right (I'm guessing from the comments in
window_displayed_height) or wouldn't return the right value at the time
lazy-lock.el might call it, but it doesn't mean that it couldn't be made to.

Ben> The fundamental thing, of course, is that lazy-lock (as distributed
Ben> with XEmacs) *DOES* work fine (and better than any implementation for
Ben> FSF Emacs that I've ever seen), and doesn't seem to suffer any of the
Ben> supposed problems that Simon attributes to it.

Ben> I could write a lengthy message refuting Simon's assertions, but
Ben> there doesn't seem any point, seeing as how Simon obviously has no
Ben> interest in reasoned debate -- otherwise he would be checking his
Ben> facts more carefully and working with the XEmacs people rather than
Ben> randomly slamming them.

I made a big effort to explain in the comment why lazy-lock.el version 1,
and the use of post-command-hook, is a hack and suffers from problems and
has undesirable consequences.  I stand by the comments, but if you want to
show me which are wrong then I will correct them.  Less than a third of
the comment explains why version 1 plus XEmacs' pre-idle-hook does not
address all issues.  Maybe you can try to explain where that is wrong too.

I can't be bothered to reply to the personal gibes, but I've spent a lot
of effort on the XEmacs side in hassling, in terms of email more in
frequency than I've spent on the Emacs side.  (I think I only asked rms
once, he said no, and I assumed it would never happen.)  Even when you
ranted and insulted on gnu.emacs.sources following a release of version 2,
I still attempted to be reasonable about it.  After the gnu.emacs.sources
post, at the beginning of the year, Chuck suggested that you check with
him before blowing up.  I wish you had done so this time.

Version 2 lazy-lock.el is much better than any version 1, and in many
ways.  If I wasn't sure of that I wouldn't have bothered writing it, and I
wouldn't have bothered risking your wrath in saying so.

Simon.

From xemacs-beta-request@cs.uiuc.edu  Thu Jul  4 14:04:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA07677 for xemacs-beta-people; Thu, 4 Jul 1996 14:04:37 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA07674 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 4 Jul 1996 14:04:36 -0500 (CDT)
Received: from cortex.corpus.uni-muenster.de (news@PPPE155.UNI-MUENSTER.DE [128.176.20.165]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA08558 for <xemacs-beta@cs.uiuc.edu>; Thu, 4 Jul 1996 14:03:37 -0500 (CDT)
Received: (from gutschk@localhost) by cortex.corpus.uni-muenster.de (8.6.12/8.6.11) id TAA02046; Thu, 4 Jul 1996 19:00:53 +0200
Sender: gutschk@uni-muenster.de
To: "Doug Keller" <dkeller@VNET.IBM.COM>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Real Balloon Help
References: <9607031906.AA17162@spacedog.fishkill.ibm.com>
X-Face: +.[`xCMz]E6GW}5ECgY#C"Er6&v$q7:oe+zPlPtOh>/US;9B>;)ro_lpLx9/]q_{u-\YR>r
 P&)Da0gS,PW{@BWSG,PIV)3#J<$Ft_t]qa!xF~'*wuwg-CJj*0:EUr3z}y
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Markus Gutschke <gutschk@uni-muenster.de>
Date: 04 Jul 1996 19:00:51 +0200
In-Reply-To: "Doug Keller"'s message of Wed, 3 Jul 1996 15:06:15 -0400
Message-ID: <m2afxg6ji4.fsf@cortex.corpus.uni-muenster.de>
Lines: 26
X-Mailer: Gnus v5.2.25/XEmacs 19.14

"Doug Keller" <dkeller@VNET.IBM.COM> writes:
> I have been playing around and through together some balloon help
> code, it is real C code not lisp like Kyle did a while back.
> 
> Here is the C code with a small example program, the example requires
> Motif.
> 
> I want to get feedback on what people think, should I finish this off
> for 19.15 or 19.16?  Or is balloon help an overkill and not needed and
> just continue to echo help in the message area?

Looks very nice. Even though, I would probably not use it as I do not
use many of the GUI features anyways, I believe that it is yet another
feature that makes XEmacs more convenient for new users.

I played around with the demo code and noticed one small bug. When the
mouse pointer is moved close to the screen border, part of the balloon
help will be moved off screen. Now, when slowly moving the mouse
pointer back into the middle of the screen. The part of the window
that used to be obstructed does not get redrawn. You seem to miss some
of the exposure events.

This happens with FVWM 2.0.42 on Linux.


Markus

From xemacs-beta-request@cs.uiuc.edu  Fri Jul  5 01:19:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA10258 for xemacs-beta-people; Fri, 5 Jul 1996 01:19:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA10253 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 5 Jul 1996 01:19:27 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA23361 for <xemacs-beta@cs.uiuc.edu>; Fri, 5 Jul 1996 01:19:29 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id XAA16034; Thu, 4 Jul 1996 23:18:07 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: cthomp@xemacs.org
Subject: Wingpsgml sync'ed up with psgml 1a11
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 04 Jul 1996 23:18:05 -0700
Message-ID: <m2logzw7du.fsf@deanna.miranova.com>
Lines: 17
X-Mailer: Gnus v5.2.33/XEmacs 20.0

I've sync'ed up wingpsgml with psgml 1a11.  It works with 19.14, but
has some problems reading compiled dtds from 20.0-b26/MULE.

As a bonus, I've sync'ed the dtds with the ones Mark Gaither
distributes from Webtechs, and included dtds for Hot Java & Hot Java
Strict.

I've loaded tar copies of the lisp/psgml and etc/sgml directories into
the XEmacs.org incoming directory and also put them at
	ftp://ftp.miranova.com/pub/xemacs/psgml-1a11.elisp.tar.gz
	ftp://ftp.miranova.com/pub/xemacs/psgml-1a11.etc.sgml.tar.gz

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jul  5 04:16:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA14754 for xemacs-beta-people; Fri, 5 Jul 1996 04:16:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA14751 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 5 Jul 1996 04:16:07 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA25288 for <xemacs-beta@cs.uiuc.edu>; Fri, 5 Jul 1996 04:16:07 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id CAA16961; Fri, 5 Jul 1996 02:14:47 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Wingpsgml sync'ed up with psgml 1a11
References: <m2logzw7du.fsf@deanna.miranova.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Steven L Baur's message of 04 Jul 1996 23:18:05 -0700
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 05 Jul 1996 02:14:45 -0700
Message-ID: <m220ir3vuh.fsf@deanna.miranova.com>
Lines: 47
X-Mailer: Gnus v5.2.33/XEmacs 20.0

>>>>> "sb" == Steven L Baur <steve@miranova.com> writes:

sb> I've sync'ed up wingpsgml with psgml 1a11.  It works with 19.14, but
sb> has some problems reading compiled dtds from 20.0-b26/MULE.

The .elcs are not portable (defsubst/defmacro with dependencies on
char-int).  :-(

I don't know whether these changes are needed, but they make the code
look safer.

--- lisp/psgml/psgml-parse.el~	Thu Jul  4 18:55:18 1996
+++ lisp/psgml/psgml-parse.el	Fri Jul  5 00:12:22 1996
@@ -1206,6 +1206,8 @@
     (sgml-check-dtd-subset)
     (sgml-pop-entity)
     (erase-buffer)
+    ;; For XEmacs-20.0/Mule
+    (setq file-coding-system 'noconv)
     (sgml-write-dtd sgml-dtd-info to-file)
     t))
 
@@ -1233,6 +1235,7 @@
   "Merge the binary coded dtd in the current buffer with the current dtd.
 The current dtd is the variable sgml-dtd-info.  Return t if mereged
 was successfull or nil if failed."
+  (setq file-coding-system 'noconv)
   (goto-char (point-min))
   (sgml-read-sexp)			; skip filev
   (let ((dependencies (sgml-read-sexp))
@@ -2360,7 +2363,9 @@
     (set-buffer sgml-scratch-buffer)
     ;; For MULE to not misinterpret binary data set the mc-flag
     ;; (reported by Jeffrey Friedl <jfriedl@nff.ncl.omron.co.jp>)
-    (setq mc-flag nil)			
+    (setq mc-flag nil)
+    ;; For XEmacs 20.0/Mule
+    (setq file-coding-system 'noconv)
     (when (eq sgml-scratch-buffer (default-value 'sgml-scratch-buffer))
       (make-local-variable 'sgml-scratch-buffer)
       (setq sgml-scratch-buffer nil))

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jul  5 07:43:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA15667 for xemacs-beta-people; Fri, 5 Jul 1996 07:43:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA15664 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 5 Jul 1996 07:43:27 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA20424 for <xemacs-beta@xemacs.org>; Fri, 5 Jul 1996 07:43:20 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA14897; Fri, 5 Jul 1996 05:39:27 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA05520; Fri, 5 Jul 1996 14:39:17 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA17672; Fri, 5 Jul 1996 14:39:14 +0200
Date: Fri, 5 Jul 1996 14:39:14 +0200
Message-Id: <9607051239.AA17672@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: DUNIX waitpid patch
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

I can't remember the breakage in earlier versions of DUNIX V3.n, but
HAVE_WAITPID should be defined.  It always should've been, but I
probably papered over the problem instead of fixing it at the time.  A
posting in the newsgroup pointed out the problem with interactions with
cvs.

        Steve


*** src/s/decosf3-1.h.dist	Mon Jun 17 14:07:19 1996
--- src/s/decosf3-1.h	Thu Jul 04 09:13:36 1996
***************
*** 26,32 ****
  
  /* #### why the hell is configure so broken on this system? */
  #define HAVE_SELECT
- #define HAVE_UNION_WAIT
- #undef HAVE_WAITPID
  
  #define BROKEN_SIGIO
--- 26,30 ----

From xemacs-beta-request@cs.uiuc.edu  Fri Jul  5 12:09:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA17039 for xemacs-beta-people; Fri, 5 Jul 1996 12:09:09 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA17036 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 5 Jul 1996 12:09:07 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA20815 for <xemacs-beta@xemacs.org>; Fri, 5 Jul 1996 12:09:03 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id KAA17374; Fri, 5 Jul 1996 10:08:35 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA01208; Fri, 5 Jul 96 13:08:34 EDT
Received: from detlev.canada.sun.com.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id NAA20999; Fri, 5 Jul 1996 13:08:32 -0400
Received: by detlev.canada.sun.com.canada.sun.com (SMI-8.6/SMI-SVR4)
	id NAA01778; Fri, 5 Jul 1996 13:08:22 -0400
Date: Fri, 5 Jul 1996 13:08:22 -0400
Message-Id: <199607051708.NAA01778@detlev.canada.sun.com.canada.sun.com>
From: Georg Nikodym <georgn@detlev.Canada.Sun.COM>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: gnus gripe
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII


The new gnus does not seem to honor gnus-local-domain.  Instead it
uses (system-name) all over the place (which for me is _not_ a FQDN).

Thus when I try to post news, I am kvetched at about the lossage of my
system's configuration (puh-leeze) and I get humourous but insulting
shit put into the message id.

<rant>
I have yet to see a program that can correctly comment on system
configurations.  Programs that purport to do so end up being boorish
digital counterparts to the boorish IS types that want these sorts of
things so that they can remain boorish (while ignoring the fact that
they often don't know what the fuck they're talking about).
</rant>

From xemacs-beta-request@cs.uiuc.edu  Fri Jul  5 12:56:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA17159 for xemacs-beta-people; Fri, 5 Jul 1996 12:56:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA17156 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 5 Jul 1996 12:56:29 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA10239 for <xemacs-beta@cs.uiuc.edu>; Fri, 5 Jul 1996 12:56:30 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA19363; Fri, 5 Jul 1996 10:55:09 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14 on hpux 10.10
References: <199607041459.JAA04606@a.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Richard Cognot's message of Thu, 4 Jul 1996 15:00:03 +0100
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 05 Jul 1996 10:55:07 -0700
Message-ID: <m2hgrmzitg.fsf@deanna.miranova.com>
Lines: 17
X-Mailer: Gnus v5.2.33/XEmacs 20.0

I've added this information to the FAQ.  Feel free to Cc: me directly
on important finds like this so it can get to the top of the queue for
addition to the XEmacs FAQ.  It's especially important wrt systems
that I don't have access to (or packages I don't use like vm), since I
wait for independent confirmation of all posted solutions that I
cannot personally verify.

>>>>> "Richard" == Richard Cognot <cognot@ensg.u-nancy.fr> writes:

Richard> Finally found some time to look into this. FTR, compiling on hpux
Richard> 10.10 lead to a hang in gnus when compiled with optimization on.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jul  5 13:03:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA17211 for xemacs-beta-people; Fri, 5 Jul 1996 13:03:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA17208 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 5 Jul 1996 13:03:10 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA11304 for <xemacs-beta@cs.uiuc.edu>; Fri, 5 Jul 1996 13:03:10 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA19527; Fri, 5 Jul 1996 11:01:48 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: gnus gripe
References: <199607051708.NAA01778@detlev.canada.sun.com.canada.sun.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Georg Nikodym's message of Fri, 5 Jul 1996 13:08:22 -0400
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 05 Jul 1996 11:01:45 -0700
Message-ID: <m2enmqziie.fsf@deanna.miranova.com>
Lines: 33
X-Mailer: Gnus v5.2.33/XEmacs 20.0

>>>>> "Georg" == Georg Nikodym <georgn@detlev.Canada.Sun.COM> writes:

Georg> The new gnus does not seem to honor gnus-local-domain.  Instead
Georg> it uses (system-name) all over the place (which for me is _not_
Georg> a FQDN).

Gnus-local-domain is not used by Gnus.  You need to set
user-mail-address and mail-host-address.  I have them set as follows:

(setq user-mail-address "steve@miranova.com")
(setq mail-host-address "miranova.com")

This still does not fix the broken Sender: header though.


Subject: Q4.2.4 How do I customize the From: line? [New]               
                 
   How do I change the From: line? I have set gnus-user-from-line to Gail
   Gurman <gail.gurman@sybase.com>, but XEmacs Gnus doesn't use it.
   Instead it uses Gail Mara Gurman <gailg@deall> and then complains that
   it's incorrect. Also, as you perhaps can see, my Message-ID is screwy.
   How can I change that?                                              
                 
   Lars Magne Ingebrigtsen <larsi@aegir.ifi.uio.no> writes:          
   Set user-mail-address to gail.gurman@sybase.com or mail-host-address
   to sybase.com.                                                       


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jul  5 13:20:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA17273 for xemacs-beta-people; Fri, 5 Jul 1996 13:20:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA17270 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 5 Jul 1996 13:20:24 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA12396 for <xemacs-beta@cs.uiuc.edu>; Fri, 5 Jul 1996 13:20:24 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id LAA00773; Fri, 5 Jul 1996 11:19:51 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA02371; Fri, 5 Jul 96 14:19:50 EDT
Received: from detlev.canada.sun.com.Canada.Sun.COM by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id OAA22331; Fri, 5 Jul 1996 14:19:47 -0400
Received: by detlev.canada.sun.com.Canada.Sun.COM (SMI-8.6/SMI-SVR4)
	id OAA00425; Fri, 5 Jul 1996 14:19:37 -0400
Date: Fri, 5 Jul 1996 14:19:37 -0400
Message-Id: <199607051819.OAA00425@detlev.canada.sun.com.Canada.Sun.COM>
From: Georg Nikodym <georgn@detlev.Canada.Sun.COM>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: gnus gripe
In-Reply-To: <m2enmqziie.fsf@deanna.miranova.com>
References: <199607051708.NAA01778@detlev.canada.sun.com.canada.sun.com>
	<m2enmqziie.fsf@deanna.miranova.com>
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII

>>>>> "SLB" == Steven L Baur <steve@miranova.com> writes:

 SLB> Subject: Q4.2.4 How do I customize the From: line? [New]

Thanks.  To my shame, I'm only just beginning to learn what a great
resource the FAQ is.  Hat's off to you sir.

From xemacs-beta-request@cs.uiuc.edu  Fri Jul  5 20:07:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA18916 for xemacs-beta-people; Fri, 5 Jul 1996 20:07:16 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA18913 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 5 Jul 1996 20:07:15 -0500 (CDT)
Received: from hackvan.com (hackvan.com [206.80.31.242]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA21435 for <xemacs-beta@xemacs.org>; Fri, 5 Jul 1996 20:07:10 -0500 (CDT)
Received: by hackvan.com (Linux Smail3.1.29.1 #27)
	id m0ucLm5-000HE7C; Fri, 5 Jul 96 18:03 PDT
Message-Id: <m0ucLm5-000HE7C@hackvan.com>
Date: Fri, 5 Jul 96 18:03 PDT
From: stig@hackvan.com (Stig)
To: xemacs-beta@xemacs.org
Subject: If ^G doesn't work, it's a LISP bug...
In-Reply-To: <199606160147.SAA22246@netcom2.netcom.com>
References: <199606160147.SAA22246@netcom2.netcom.com>
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/

Ben Wing wrote:
> 
> C-g does work for most people in most circumstances.  If it doesn't,
> there are only two explanations:
> 
> 1) the code is wrapped with a binding of `inhibit-quit' to t.
>    Ctrl-Shift-G should still work, I think.

This is more of an aid to programmers than something you want to tell users
to use on a regular basis.

    - if inhibit-quit was set, it was probably for a reason...
    - it generates a backtrace, which will confuse or irritate mortals...
    - it won't work on tty devices.

Anything that takes a long time with inhibit-quit let-bound to t should also
poll the value of quit-flag to see if the user is starting to climb the
walls out of impatience...

Another alternative to binding inhibit-quit should be the use of
condition-case:

    (condition-case nil
	(something-that-takes-a-long-time)
      (quit
       (undo-what-was-only-half-done)))

If XEmacs hangs and it's not a case of BROKEN_SIGIO, then it should be
regarded as a lisp bug and one of the two techniques above ought to be put
in place.

Control-shift-g is a debugging aid to help the bleeding edge types and
kitchen sink repairmen out there, to locate the places where XEmacs hangs
for an unreasonably long time with inhibit-quit set to t.

    Stig

From xemacs-beta-request@cs.uiuc.edu  Sat Jul  6 14:00:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA24991 for xemacs-beta-people; Sat, 6 Jul 1996 14:00:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA24988 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 6 Jul 1996 14:00:28 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA19255 for <xemacs-beta@cs.uiuc.edu>; Sat, 6 Jul 1996 14:00:30 -0500 (CDT)
Received: from sbjh.cs.sunysb.edu (sbjh.cs.sunysb.edu [130.245.1.52]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id PAA27389 for <xemacs-beta@cs.uiuc.edu>; Sat, 6 Jul 1996 15:04:47 -0400
Message-Id: <199607061904.PAA27389@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbjh.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: xemacs-beta@cs.uiuc.edu
Subject: key-translation-map bug?
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 06 Jul 1996 14:58:45 -0400
Sender: kifer@cs.sunysb.edu

I think the following is a bug or a misfeature.

Binding meta-anything in key-translation-map trashes any other binding
for ESC (which interacts with viper and any other Vi emulation, I think).

For instance, suppose I bind:

(local-set-key "\C-[" '(lambda () (interactive) (message "rebound1")))

in some buffer in fundamental mode and then eval

(define-key key-translation-map [(meta p)] 
  '(lambda () (interactive) (message "rebound2"))) 


(Meta p) is unimportant here -- can be (meta left) or meta-anything.  Now,
ESC behaves as a prefix key again, trashing the previous explicit binding
for ESC.

I think this happens because ESC gets bound to a keymap in
key-translation-map, and it overrides other bindings.  I believe the same
would happen to any prefix key.


I tried the same experiment with FSF's version, and there binding
meta-something in key-translation-map doesn't cause total overriding of ESC
(even if you cause \e to become bound to a keymap in key-translation-map).


I think such total overriding (as in XEmacs) in inappropriate for
key-translation-map.
In any case, this causes bad interaction between delbackspace.el and viper
(and other vi emulations, I believe).


	--michael  

From xemacs-beta-request@cs.uiuc.edu  Sat Jul  6 14:53:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA25091 for xemacs-beta-people; Sat, 6 Jul 1996 14:53:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA25088 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 6 Jul 1996 14:53:58 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA22437 for <xemacs-beta@xemacs.org>; Sat, 6 Jul 1996 14:53:56 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id NAA09956; Sat, 6 Jul 1996 13:53:58 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id NAA05193; Sat, 6 Jul 1996 13:53:55 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id NAA27420; Sat, 6 Jul 1996 13:53:25 -0600
Date: Sat, 6 Jul 1996 13:53:25 -0600
Message-Id: <199607061953.NAA27420@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: 19.15?
Reply-To: turner@lanl.gov

What was the decision w.r.t. this?

Could including tm be categorized as a bug-fix?  :)

-John

------- start of forwarded message (RFC 934 encapsulation) -------
From: Chuck Thompson <cthomp@cs.uiuc.edu>
To: Martin Buchholz <mrb@eng.sun.com>
cc: andyp@parallax.co.uk (Andy Piper), Peter Cheng <phc@eng.sun.com>,
        xemacs-beta@cs.uiuc.edu
Subject: Re: sunpro-startup? 
Date: Thu, 27 Jun 1996 07:54:57 -0500

    Martin> Chuck, I think we ought to put out a patch version of
    Martin> 19.14 sometime.

No way.  I am considering making 19.15 a bug-fix only release with
absolutely no new features and putting it out within a month or two,
though.

			-Chuck
------- end -------

From xemacs-beta-request@cs.uiuc.edu  Sat Jul  6 23:30:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA26003 for xemacs-beta-people; Sat, 6 Jul 1996 23:30:59 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA26000 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 6 Jul 1996 23:30:58 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA05065 for <xemacs-beta@cs.uiuc.edu>; Sat, 6 Jul 1996 23:31:00 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id VAA06630; Sat, 6 Jul 1996 21:29:34 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.15?
References: <199607061953.NAA27420@gielgud.lanl.gov.xdiv>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: John Turner's message of Sat, 6 Jul 1996 13:53:25 -0600
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 06 Jul 1996 21:29:34 -0700
Message-ID: <m2pw68bs9d.fsf@deanna.miranova.com>
Lines: 26
X-Mailer: Gnus v5.2.34/XEmacs 19.14

>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:

Chuck> No way.  I am considering making 19.15 a bug-fix only release
Chuck> with absolutely no new features and putting it out within a
Chuck> month or two, though.

John> What was the decision w.r.t. this?
John> Could including tm be categorized as a bug-fix?  :)

It is and it isn't.  The time between beta releases has been getting
longer, but there are still some bugs in it.  On the other hand, tm
could really benefit by getting wider usage, something it will never
have until it is distributed with a stock emacs, and all of the
mail/news packages are broken without strong MIME support (IMHO).

Even for a bugfix release I believe component packaging a la RPM would
be a good idea, and there ought to be no problem having tm as an extra
package like AucTeX.

I'm still in shell-shock from the release, and wouldn't blame Chuck in
the slightest for being very conservative with 19.15.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sun Jul  7 12:06:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA01205 for xemacs-beta-people; Sun, 7 Jul 1996 12:06:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA01202 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 7 Jul 1996 12:06:10 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA19393 for <xemacs-beta@cs.uiuc.edu>; Sun, 7 Jul 1996 12:06:10 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA09097; Sun, 7 Jul 1996 10:04:42 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: sudish@mindspring.com (Sudish Joseph)
Subject: [comp.emacs.xemacs] pp.el should bind emacs-lisp-mode-hook to nil
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: multipart/mixed;
 boundary="Multipart_Sun_Jul__7_10:04:41_1996-1"
Content-Transfer-Encoding: 7bit
Date: 07 Jul 1996 10:04:41 -0700
Message-ID: <m2d9289eqe.fsf@deanna.miranova.com>
Lines: 52
X-Mailer: Gnus v5.2.34/XEmacs 19.14

--Multipart_Sun_Jul__7_10:04:41_1996-1
Content-Type: text/plain; charset=US-ASCII


--Multipart_Sun_Jul__7_10:04:41_1996-1
Content-Type: message/rfc822

From: sudish@mindspring.com (Sudish Joseph)
Subject: pp.el should bind emacs-lisp-mode-hook to nil
Date: 05 Jul 1996 22:39:31 -0400
Message-ID: <m220iqt89o.fsf@atreides.erehwon.org>
Newsgroups: comp.emacs.xemacs

In XEmacs 19.14 [Lucid] (i586-unknown-linux1.99.14) of Tue Jun 25 1996 on atreides

Subject says it all.  Running pp with font-lock or hilit in
emacs-lisp-mode-hook can slow things down badly if you're pp'ing a
large object.  Per Abrahamsen suggested this fix for GNU Emacs more
than a year back after noticing a slowdown in ding's scoring stuff.
That fix doesn't seem to have made it into 19.30|31 either.

Sorry to CC a maintainer directly, but since report-emacs-bug is
broken, I wasn't sure if the address in there was correct.

-Sudish

diff -u /home/sj/xemacs/lisp/utils/pp.el~ /home/sj/xemacs/lisp/utils/pp.el
--- /home/sj/xemacs/lisp/utils/pp.el~	Fri Jul  5 22:36:38 1996
+++ /home/sj/xemacs/lisp/utils/pp.el	Fri Jul  5 22:36:38 1996
@@ -50,7 +50,8 @@
     (set-buffer (generate-new-buffer " pp-to-string"))
     (unwind-protect
 	(progn
-	  (emacs-lisp-mode)
+	  (let (emacs-lisp-mode-hook)
+	    (emacs-lisp-mode))
 	  (let ((print-escape-newlines pp-escape-newlines)
 		(print-readably pp-print-readably))
 	    (prin1 object (current-buffer)))
@@ -139,7 +140,8 @@
       (pp (car values)))
     (save-excursion
       (set-buffer "*Pp Eval Output*")
-      (emacs-lisp-mode))))
+      (let (emacs-lisp-mode-hook)
+	(emacs-lisp-mode)))))
 
 (defun pp-eval-last-sexp (arg)
   "Run `pp-eval-expression' on sexp before point (which see).


--Multipart_Sun_Jul__7_10:04:41_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  8 11:08:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA09248 for xemacs-beta-people; Mon, 8 Jul 1996 11:08:50 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA09245 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 8 Jul 1996 11:08:48 -0500 (CDT)
Received: from maes.esrin.esa.it (maes.esrin.esa.it [192.106.252.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA26414 for <xemacs-beta@cs.uiuc.edu>; Mon, 8 Jul 1996 11:08:25 -0500 (CDT)
Received: from mail.esrin.esa.it (plod.esrin.esa.it) by maes.esrin.esa.it with SMTP id AA15432
  (5.65c/IDA-1.4.4 for <xemacs-beta@cs.uiuc.edu>); Mon, 8 Jul 1996 18:08:50 +0200
Received: from penelope.esa.it by mail.esrin.esa.it (4.1/SMI-4.1)
	id AA23709; Mon, 8 Jul 96 16:06:59 GMT
Date: Mon, 8 Jul 96 16:06:54 GMT
Message-Id: <9607081606.AA23709@mail.esrin.esa.it>
Received: by penelope.esa.it (4.1/SMI-4.1)
	id AA05593; Mon, 8 Jul 96 18:01:34 +0200
From: Simon Marshall <Simon.Marshall@esrin.esa.it>
To: XEmacs Beta <xemacs-beta@cs.uiuc.edu>
Subject: [19.14]: Pictures displayed in the wrong place
Reply-To: Simon Marshall <Simon.Marshall@esrin.esa.it>

A strange buglette, I wonder if it only happens to me.  Just do:

xemacs -no-init-file -no-site-file
Help/About XEmacs.../And many other contributors...

and I see most of the images that should be at the bottom of the buffer
shown in the middle of the window (i.e., it depends on the window height).

If I scroll to the bottom of the buffer, I see only Chuck's piccie.

Ta, Si.

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  8 12:55:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA09882 for xemacs-beta-people; Mon, 8 Jul 1996 12:55:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA09879 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 8 Jul 1996 12:55:28 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA28634 for <xemacs-beta@cs.uiuc.edu>; Mon, 8 Jul 1996 12:55:30 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.53 #2)
	id E0udKWv-00011M-00; Mon, 8 Jul 1996 13:55:29 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: hpux9.05 strcat crash fixed?
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0udKWv-00011M-00@neal.ctd.comsat.com>
Date: Mon, 8 Jul 1996 13:55:29 -0400

After recompiling 19.14 with the strcat.c from glibc I have been
running for more than 1 week without a crash.  Most likely, the
strcat.c is needed on hpux9 as well as hpux10 (there is a known libc
bug on hpux10, it must be in 9.05 as well, or at least the patched
libc I'm using).

From xemacs-beta-request@cs.uiuc.edu  Mon Jul  8 20:16:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA11875 for xemacs-beta-people; Mon, 8 Jul 1996 20:16:38 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA11872 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 8 Jul 1996 20:16:37 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA16618 for <xemacs-beta@cs.uiuc.edu>; Mon, 8 Jul 1996 20:16:40 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id SAA12501; Mon, 8 Jul 1996 18:16:05 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (5.x/SMI-5.3)
	id AA16799; Mon, 8 Jul 1996 18:06:29 -0400
Received: from zeppo.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id SAA02023; Mon, 8 Jul 1996 18:07:06 -0400
Received: by zeppo.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id SAA07167; Mon, 8 Jul 1996 18:05:39 -0400
Date: Mon, 8 Jul 1996 18:05:39 -0400
From: gra@zeppo.East.Sun.COM (Gary Adams - Sun Microsystems Labs BOS)
Message-Id: <199607082205.SAA07167@zeppo.East.Sun.COM>
To: xemacs-beta@cs.uiuc.edu
Subject: How to configure for ./lib-src/mule/ utilities (20.0b26) ?
X-Sun-Charset: US-ASCII

Can someone tell me if the configure flag --with-mule is
supposed to generate the lib-src/mule/Makefile for building 
the coco and m2ps utility programs? (sorry if this a faq,
but I'm new to the list and I couldn't find the mail archive).

./configure  sparc-sun-solaris2 --run-in-place --with-mule

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 10 13:30:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA27408 for xemacs-beta-people; Wed, 10 Jul 1996 13:30:07 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA27405 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 10 Jul 1996 13:30:06 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA29999 for <xemacs-beta@xemacs.org>; Wed, 10 Jul 1996 13:30:01 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id OAA15954 for <xemacs-beta@xemacs.org>; Wed, 10 Jul 1996 14:29:23 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp015727; Wed Jul 10 14:24:37 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA14937; Wed, 10 Jul 96 14:24:27 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA06458; Wed, 10 Jul 96 14:23:15 EDT
Message-Id: <9607101823.AA06458@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Never had it, never will.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Rebuilt SunOS binary?
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMeP07FtTztlqB385AQFm/QP/R2/yQ25Hc0rDReE1rmXhbtQgWjGvczuA
	      4DWH9fY1R8cETa38Ms0SoLABjaM/PfDTNdtCoK3xm+Zm1SrX2uFqLwn3ma3FIywb
	      uTOrc0tY1kn1x2EAa6KUU8I0k+6DJpynFg5EV/1pcUYJs8oL4Kymd/lcdvHn+h6a
	      Gz6AiKARm+k=
	      =3TOA
Date: Wed, 10 Jul 1996 14:22:42 -0400
Sender: rickc@lehman.com

Did the archive ever get updated with prebuilt SunOS binaries that
include sound support?

If not, will it?

			Rick

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 10 13:21:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA27384 for xemacs-beta-people; Wed, 10 Jul 1996 13:21:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA27381 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 10 Jul 1996 13:21:47 -0500 (CDT)
Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA27854 for <xemacs-beta@cs.uiuc.edu>; Wed, 10 Jul 1996 13:21:42 -0500 (CDT)
Received: from corp-200.dfki.uni-kl.de by stepsun.uni-kl.de id aa12210;
          10 Jul 96 20:21 MET DST
Received: from serv-201.dfki.uni-kl.de (burt@serv-201 [131.246.241.101]) by corp-200.dfki.uni-kl.de (8.7.5/8.7.3) with ESMTP id UAA26369 for <xemacs-beta@cs.uiuc.edu>; Wed, 10 Jul 1996 20:22:05 +0200 (MET DST)
Organization: DFKI Kaiserslautern GmbH, D 67663 Kaiserslautern
Received: (from burt@localhost) by serv-201.dfki.uni-kl.de (8.7.5/8.7.3) id UAA25781 for xemacs-beta@cs.uiuc.edu; Wed, 10 Jul 1996 20:21:32 +0200 (MET DST)
Date: Wed, 10 Jul 1996 20:21:32 +0200 (MET DST)
Message-Id: <199607101821.UAA25781@serv-201.dfki.uni-kl.de>
From: Alastair Burt <burt@dfki.uni-kl.de>
To: XEmacs Beta Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: xemacs-20.0-b25 crash report
Mime-Version: 1.0 (generated by tm-edit 1.2)
Content-Type: text/plain; charset=US-ASCII

Configured for `sparc-sun-solaris2.5'.

  Where should the build process find the source code?    /home/burt/tmp/xemacs-20.0-b25
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /opt/X11/include
  Where do we find X Windows libraries?                   /opt/X11/lib
  Additional header files:                                /home/burt/include
  Additional libraries:                                   /home/burt/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Compiling in support for CDE.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

Compiles OK.  Crashes on startup.

  Lisp backtrace follows:

    last-nonminibuf-frame()
    # bind (window old-frame target-frame explicit-frame)
    byte-code(..)
    # (catch done ...)
    # bind (override-frame not-this-window-p buffer)
    display-buffer(#<buffer "*Warnings*">)
    # bind (buffer)
    display-warning-buffer()
    # (condition-case ... . error)
    # bind (inhibit-quit)
    # (condition-case ... . error)
    # (catch top-level ...)

  C backtrace follows:
  (A real debugger may provide better information)

  25476:	src/xemacs -q /home/burt/tmp
   ef2b85f8 waitid   (0, 6386, efffc818, 3)
   ef2da5d8 waitpid  (6386, efffc900, 3, ef311078, 48, 0) + 58
   ef2f1020 system   (efffca70, 21e5a0, 21e538, 6384, 1036601c, 0) + 1d8
   00088150 fatal_error_signal (6, 0, efffcbb8, f026b494, 0, 0) + d0
   ef2b7d38 sigacthandler (6, 0, efffcbb8, ef311078, 18, 0) + 28
   ef2b95a8 abort    (7b, 228c18, 326, 228dd8, 1, 2) + c8
   00089c08 assert_failed (228c18, 326, 228dd8, f026b494, 0, 0) + 1c
   000e150c Flast_nonminibuf_frame (10366004, 4, f0000000, f025cd40, 0, 0) + 8c
   0008fb78 primitive_funcall (e1480, 1, efffd040, fffffff, 1037e3c4, 1037e3c4) + 68
   0008fcfc funcall_subr (26e8fc, efffd040, 1, 1, efffd078, 26e8fc) + c
   0008f05c funcall_recording_as (1026e8fc, 0, efffde68, 32a, 22d800, 2deb9d) + 320
   0008f1a4 Ffuncall (1, efffde68, efffd158, 2de71c, 0, 2debac) + c
   0005839c Fbyte_code (10366004, efffde68, a, 33f800, 7fffffff, 26dd18) + 800
   0008fba4 primitive_funcall (57b9c, 3, efffe0f8, fffffff, 10378984, 10378984) + 94
   0008fcfc funcall_subr (26a0b0, efffe0f8, 32b400, 335dd8, fffffff, 3260bc) + c
   0008ebc8 Feval    (3, 334800, 32b400, 335dd8, 22d800, efffdf88) + 848
   0008bd80 internal_catch (103cf894, 8e380, 202de70c, 0, 0, 2de6f4) + 94
   00058854 Fbyte_code (202de70c, efffe3b4, 5, 33f800, 7fffffff, 26dd18) + cb8
   000901d4 funcall_lambda (102de60c, 1, efffe768, fffffff, 4, 267fe4) + 3b0
   0008f14c funcall_recording_as (102de60c, 1, efffe764, 0, 22d800, 2a1153) + 410
   0008f1a4 Ffuncall (2, efffe764, 104e9200, 2a1110, 0, 323c7c) + c
   0005839c Fbyte_code (1037e804, efffe764, 1a, 33f800, 7fffffff, 26dd18) + 800
   000901d4 funcall_lambda (102a10f0, 0, efffea78, fffffff, 3, f0041a94) + 3b0
   0008f14c funcall_recording_as (102a10f0, 0, efffea74, 0, 0, f66f9dd8) + 410
   0008f1a4 Ffuncall (1, efffea74, 337000, 0, 0, 0) + c
   00090c58 call0    (10380bf4, 32b400, 32f800, 8c1f0, fffffff, 0) + 2c
   00091cbc catch_them_squirmers_call0 (10380bf4, 32b400, 1, 91cb8, 0, efffe880) + 4
   0008c260 condition_case_1 (10366064, 91cb8, 10380bf4, 91330, 10366004, 3) + 100
   00091e58 call0_trapping_errors (0, 102a10f0, 10366004, f026b494, 0, 0) + 18c
   00140fcc redisplay (10366004, 337000, 10366004, 337000, 0, 0) + 34
   000a1cec Fnext_event (10366004, 10366004, 10366004, f025cd40, 0, 0) + 74c
   00067d5c Fcommand_loop_1 (0, 10366004, 10468f00, 8c1f0, fc0b5c08, f0041a94) + 38c
   000679c0 command_loop_1 (10366004, 32b400, ffffffff, 67924, 0, efffec28) + 9c
   0008c260 condition_case_1 (10366064, 67924, 10366004, 66ac0, 10366004, 0) + 100
   00066bb8 command_loop_3 (0, effff030, 8bd54, 8bd5c, 0, 0) + 28
   00066be0 command_loop_2 (10366004, 0, 66bdc, f025cd40, 0, efffee10) + 4
   0008bd80 internal_catch (10378fcc, 66bdc, 10366004, 0, fffffff, 0) + 94
   00067074 initial_command_loop (7fffffff, 35fc00, 333c00, 0, effffe7e, effffe7e) + 47c
   00089164 main_1   (3, effff2f4, 21e400, f025cd40, 0, 0) + c1c
   000895a0 main     (3, effff2f4, effff304, 330a08, 1, 0) + a4
   000404e4 _start   (0, 0, 0, 0, 0, 0) + 5c

--- alastair


From xemacs-beta-request@cs.uiuc.edu  Wed Jul 10 14:12:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA27713 for xemacs-beta-people; Wed, 10 Jul 1996 14:12:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA27710 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 10 Jul 1996 14:12:55 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA00133 for <xemacs-beta@xemacs.org>; Wed, 10 Jul 1996 14:12:52 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id MAA15592; Wed, 10 Jul 1996 12:12:20 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA05869; Wed, 10 Jul 1996 12:12:09 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA23533; Wed, 10 Jul 1996 12:12:07 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA19400; Wed, 10 Jul 1996 12:12:00 -0700
Date: Wed, 10 Jul 1996 12:12:00 -0700
Message-Id: <199607101912.MAA19400@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Rick Campbell <rickc@lehman.com>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Rebuilt SunOS binary?
In-Reply-To: <9607101823.AA06458@cfdevx1.lehman.com>
References: <9607101823.AA06458@cfdevx1.lehman.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:

Rick> Did the archive ever get updated with prebuilt SunOS binaries that
Rick> include sound support?

Yes, they now include sound support.  And yes, I should have cc:ed
xemacs-beta as well as comp.emacs.xemacs when it was announced.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 11 21:00:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA09033 for xemacs-beta-people; Thu, 11 Jul 1996 21:00:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA09030 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 11 Jul 1996 21:00:40 -0500 (CDT)
Received: from pez.carroll.com (pez.carroll.com [199.224.10.48]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA03418 for <xemacs-beta@xemacs.org>; Thu, 11 Jul 1996 21:00:35 -0500 (CDT)
Received: (from pez@localhost) by pez.carroll.com (8.7.1/8.7.1) id WAA28011; Thu, 11 Jul 1996 22:06:40 -0400
Date: Thu, 11 Jul 1996 22:06:40 -0400
Message-Id: <199607120206.WAA28011@pez.carroll.com>
From: Peter Pezaris <pez@dwwc.com>
To: Ben Wing <wing@666.com>
Cc: David Worenklein <dcw@gcm.com>,
        XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: Really slow XEmacs
In-Reply-To: <199606300122.BAA02108@nene.boundless.com>
References: <amzq5rrd9k.fsf@gcm.com>
	<199606300122.BAA02108@nene.boundless.com>
Reply-To: pez@dwwc.com


    Ben> David Worenklein writes:
    >> I found that as soon as I start sql-mode (and, particularly,
    >> within sql-mode) typing slows to an unusable speed.  So I
    >> quantified XEmacs, typed about two hundred random characters,
    >> and found that readchar (in lread.c) was called five MILLION
    >> times from read1.  read1 took 35.25% of the time, and
    >> readchar took about half of that.
    >> 
    >> I've never really delved into the C code, but what the hell
    >> would you want to do 25,000 times per keystroke?
    >> 
    >> (I'll send anyone the .qv output if he or she wants it.)

    Ben> How many times per keystroke is Fread() or
    Ben> Fread_from_string() called? That's what's important.  Is
    Ben> SQL-mode installing a post-command-hook that does `read'?

Nope.  No post-command-hook in sql-batch-mode or
sql-interactive-mode buffers (which is where you would normally be
typing in SQL Mode).

-Pez

From xemacs-beta-request@cs.uiuc.edu  Fri Jul 12 03:45:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA13368 for xemacs-beta-people; Fri, 12 Jul 1996 03:45:15 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA13365 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 12 Jul 1996 03:45:13 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA15582 for <xemacs-beta@cs.uiuc.edu>; Fri, 12 Jul 1996 03:45:12 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id JAA16506 for <xemacs-beta@cs.uiuc.edu>; Fri, 12 Jul 1996 09:47:01 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id JAA06881 for <xemacs-beta@cs.uiuc.edu>; Fri, 12 Jul 1996 09:46:26 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id JAA07204; Fri, 12 Jul 1996 09:50:04 +0100
Date: Fri, 12 Jul 1996 09:50:04 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199607120850.JAA07204@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: GNUS slow
X-Sun-Charset: US-ASCII

I'm completely fed up with this version of GNUS - why is it so slow????
I've just done a test - 19.14 gnus starts in 1 minute 15 seconds, 
19.13 gnus starts in 10 seconds - thats a factor of 7 difference.
I don't find any of the new features useful, I preferred the old
toolbar. The only improvement that affects me is the splash screen
and I would gladly sacrifice that for the old speed improvement.

I am severely inclined to go back to the old version, so someone better
set me straight quick :)

andy

From xemacs-beta-request@cs.uiuc.edu  Fri Jul 12 05:53:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA13807 for xemacs-beta-people; Fri, 12 Jul 1996 05:53:59 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA13804 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 12 Jul 1996 05:53:57 -0500 (CDT)
Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA18316 for <xemacs-beta@cs.uiuc.edu>; Fri, 12 Jul 1996 05:53:22 -0500 (CDT)
Received: from corp-200.dfki.uni-kl.de by stepsun.uni-kl.de id aa10284;
          12 Jul 96 12:52 MET DST
Received: from serv-302.dfki.uni-kl.de (burt@serv-302 [131.246.242.102]) by corp-200.dfki.uni-kl.de (8.7.5/8.7.3) with ESMTP id MAA13255; Fri, 12 Jul 1996 12:53:24 +0200 (MET DST)
Organization: DFKI Kaiserslautern GmbH, D 67663 Kaiserslautern
Received: (from burt@localhost) by serv-302.dfki.uni-kl.de (8.7.5/8.7.3) id MAA03416; Fri, 12 Jul 1996 12:52:52 +0200 (MET DST)
Sender: burt@dfki.uni-kl.de
To: Andy Piper <andyp@parallax.co.uk>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: GNUS slow
References: <199607120850.JAA07204@wrath.parallax.co.uk>
Mime-Version: 1.0 (generated by tm-edit 1.2)
Content-Type: text/plain; charset=US-ASCII
From: Alastair Burt <burt@dfki.uni-kl.de>
Date: 12 Jul 1996 12:52:51 +0200
In-Reply-To: Andy Piper's message of Fri, 12 Jul 1996 09:50:04 +0100
Message-ID: <y3aspax3fr0.fsf@serv-302.dfki.uni-kl.de>
Lines: 33
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Andy Piper <andyp@parallax.co.uk> writes:

> I'm completely fed up with this version of GNUS - why is it so slow????
> I've just done a test - 19.14 gnus starts in 1 minute 15 seconds, 
> 19.13 gnus starts in 10 seconds - thats a factor of 7 difference.
> I don't find any of the new features useful, I preferred the old
> toolbar. The only improvement that affects me is the splash screen and I
> would gladly sacrifice that for the old speed improvement.
> 
> I am severely inclined to go back to the old version, so someone better
> set me straight quick :)

This was my first impression too.  In addition, to quote the author, it
looks like a "technicolor fruit salad".  However once I tamed the
colourfulness with the ("Help" "Customize...") package, I set to work on
imnproving the speed.  In the end I discovered setting these variables
helped:

  (setq gnus-check-new-newsgroups 'ask-server)
  (setq gnus-save-killed-list nil)
  (setq gnus-read-active-file 'some)

PLUS I killed all groups that I was not actually subscribed to.  Now the
new Gnus is faster than the old GNUS.  Whether this does the same for you
depends on the sophistication of your NNTP server.

At first I was nervous about killing the unsubscribed groups, thinking I
was losing the ability to subscribe to them later.  But the command "A A"
(gnus-group-list-active) shows me all the active groups on my server and I
will still be able find the newsgroup alt.chinchilla should the need arise.

--- alastair


From xemacs-beta-request@cs.uiuc.edu  Fri Jul 12 06:20:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA14234 for xemacs-beta-people; Fri, 12 Jul 1996 06:20:31 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA14231 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 12 Jul 1996 06:20:30 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA18744 for <xemacs-beta@cs.uiuc.edu>; Fri, 12 Jul 1996 06:20:25 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id MAA20149; Fri, 12 Jul 1996 12:20:42 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id MAA11239; Fri, 12 Jul 1996 12:20:07 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id MAA08544; Fri, 12 Jul 1996 12:23:47 +0100
Date: Fri, 12 Jul 1996 12:23:47 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199607121123.MAA08544@wrath.parallax.co.uk>
To: burt@dfki.uni-kl.de
Subject: Re: GNUS slow
Cc: xemacs-beta@cs.uiuc.edu
X-Sun-Charset: US-ASCII

> Andy Piper <andyp@parallax.co.uk> writes:
> 
> > I'm completely fed up with this version of GNUS - why is it so slow????
> > I've just done a test - 19.14 gnus starts in 1 minute 15 seconds, 
> > 19.13 gnus starts in 10 seconds - thats a factor of 7 difference.
> > I don't find any of the new features useful, I preferred the old
> > toolbar. The only improvement that affects me is the splash screen and I
> > would gladly sacrifice that for the old speed improvement.
> > 
> > I am severely inclined to go back to the old version, so someone better
> > set me straight quick :)
> 
> This was my first impression too.  In addition, to quote the author, it
> looks like a "technicolor fruit salad".  However once I tamed the
> colourfulness with the ("Help" "Customize...") package, I set to work on
> imnproving the speed.  In the end I discovered setting these variables
> helped:
> 
>   (setq gnus-check-new-newsgroups 'ask-server)
>   (setq gnus-save-killed-list nil)
>   (setq gnus-read-active-file 'some)

I use these but they make no difference

> PLUS I killed all groups that I was not actually subscribed to.  Now the
> new Gnus is faster than the old GNUS.  Whether this does the same for you
> depends on the sophistication of your NNTP server.

This makes a significant difference - but surely it would to the old
gnus as well?

> At first I was nervous about killing the unsubscribed groups, thinking I
> was losing the ability to subscribe to them later.  But the command "A A"
> (gnus-group-list-active) shows me all the active groups on my server and I
> will still be able find the newsgroup alt.chinchilla should the need arise.

andy

From xemacs-beta-request@cs.uiuc.edu  Fri Jul 12 06:51:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA14291 for xemacs-beta-people; Fri, 12 Jul 1996 06:51:57 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA14288 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 12 Jul 1996 06:51:56 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA18932 for <xemacs-beta@cs.uiuc.edu>; Fri, 12 Jul 1996 06:51:58 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.53 #2)
	id E0uegfi-0004bn-00; Fri, 12 Jul 1996 07:46:10 -0400
From: Neal Becker <Neal.Becker@comsat.com>
To: Alastair Burt <burt@dfki.uni-kl.de>
Cc: Andy Piper <andyp@parallax.co.uk>, xemacs-beta@cs.uiuc.edu
Subject: Re: GNUS slow
In-Reply-To: <y3aspax3fr0.fsf@serv-302.dfki.uni-kl.de>
References: <199607120850.JAA07204@wrath.parallax.co.uk>
	<y3aspax3fr0.fsf@serv-302.dfki.uni-kl.de>
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.70)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uegfi-0004bn-00@neal.ctd.comsat.com>
Date: Fri, 12 Jul 1996 07:46:10 -0400

>>>>> "Alastair" == Alastair Burt <burt@dfki.uni-kl.de> writes:

    Alastair> new Gnus is faster than the old GNUS.  Whether this does the same for you
    Alastair> depends on the sophistication of your NNTP server.


I've seen this comment before - what does it really mean?  Is my
inn-1.4unoff4 'sophisticated'?

From xemacs-beta-request@cs.uiuc.edu  Fri Jul 12 08:32:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA14595 for xemacs-beta-people; Fri, 12 Jul 1996 08:32:22 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA14592 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 12 Jul 1996 08:32:20 -0500 (CDT)
Received: from uni-kl.de (stepsun.uni-kl.de [131.246.136.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA24989 for <xemacs-beta@cs.uiuc.edu>; Fri, 12 Jul 1996 08:31:20 -0500 (CDT)
Received: from corp-200.dfki.uni-kl.de by stepsun.uni-kl.de id aa17302;
          12 Jul 96 15:21 MET DST
Received: from serv-302.dfki.uni-kl.de (burt@serv-302 [131.246.242.102]) by corp-200.dfki.uni-kl.de (8.7.5/8.7.3) with ESMTP id PAA14584; Fri, 12 Jul 1996 15:22:27 +0200 (MET DST)
Organization: DFKI Kaiserslautern GmbH, D 67663 Kaiserslautern
Received: (from burt@localhost) by serv-302.dfki.uni-kl.de (8.7.5/8.7.3) id PAA05617; Fri, 12 Jul 1996 15:21:54 +0200 (MET DST)
Sender: burt@dfki.uni-kl.de
To: Neal Becker <Neal.Becker@comsat.com>
Cc: Andy Piper <andyp@parallax.co.uk>, xemacs-beta@cs.uiuc.edu
Subject: Re: GNUS slow
References: <199607120850.JAA07204@wrath.parallax.co.uk>
	<y3aspax3fr0.fsf@serv-302.dfki.uni-kl.de>
	<E0uegfi-0004bn-00@neal.ctd.comsat.com>
Mime-Version: 1.0 (generated by tm-edit 1.2)
Content-Type: text/plain; charset=US-ASCII
From: Alastair Burt <burt@dfki.uni-kl.de>
Date: 12 Jul 1996 15:21:53 +0200
In-Reply-To: Neal Becker's message of Fri, 12 Jul 1996 07:46:10 -0400
Message-ID: <y3aohll38um.fsf@serv-302.dfki.uni-kl.de>
Lines: 38
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Neal Becker <Neal.Becker@comsat.com> writes:
> 
> >>>>> "Alastair" == Alastair Burt <burt@dfki.uni-kl.de> writes:
> 
>     Alastair> new Gnus is faster than the old GNUS.  Whether this does
>     Alastair> the same for you depends on the sophistication of your NNTP
>     Alastair> server.
> 
> I've seen this comment before - what does it really mean?  Is my
> inn-1.4unoff4 'sophisticated'?

This is my paraphrase of several comments in the texiinfo documentation.

    (setq gnus-check-new-newsgroups 'ask-server)

This will improve performance if the server understands the command
NEWGROUPS.

    (setq gnus-read-active-file 'some)

To quote the author: "on some servers this is quite fast", for example, "on
sparkling, brand new INN servers that support the `LIST ACTIVE group'
command".  I don't know how sparkling inn-1.4unoff4 is.

    (setq gnus-save-killed-list nil)

Good if setting gnus-check-new-newsgroups to 'ask-server works. 

How do you know if your server supports these commands?  The author, Lars
Magne Ingebrigtsen, suggests telnetting to the server and typing in "HELP".
The server will list the commands it supports.  Although the author also
warns that some servers list NEWGROUPS without supporting it properly.

In short, suck it and see.

--- alastair



From xemacs-beta-request@cs.uiuc.edu  Sun Jul 14 00:08:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA23977 for xemacs-beta-people; Sun, 14 Jul 1996 00:08:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA23974 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 14 Jul 1996 00:08:35 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA07577 for <xemacs-beta@xemacs.org>; Sun, 14 Jul 1996 00:08:31 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id XAA11354; Sat, 13 Jul 1996 23:08:35 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id XAA08510; Sat, 13 Jul 1996 23:08:31 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id XAA02257; Sat, 13 Jul 1996 23:07:57 -0600
Date: Sat, 13 Jul 1996 23:07:57 -0600
Message-Id: <199607140507.XAA02257@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: 19.14, Gnus hoseage
Reply-To: turner@lanl.gov

19.14, precompiled binaries for Solaris 2.4 w/SPARCworks
Solaris 2.5, CDE 1.0.1

---

On tty, using bundled Gnus, startup, SPC on group:

Signalling: (error "Illegal size: 0.25")
  signal(error ("Illegal size: 0.25"))
  cerror("Illegal size: %s" 0.25)
  apply(cerror ("Illegal size: %s" 0.25))
  error("Illegal size: %s" 0.25)
  gnus-configure-frame((cond (gnus-use-picons (quote ...)) (gnus-use-trees (quote ...)) (t (quote ...))) #<window on " *nntpd*" 0x1644>)
  gnus-configure-windows(article)
  gnus-article-prepare(265 nil)
  gnus-summary-display-article(265)
  gnus-summary-first-unread-article()
  gnus-summary-read-group("alt.comp.periphs.mainboard.supermicro" nil nil)
  gnus-group-read-group(nil nil nil)
  gnus-topic-read-group(nil)
  call-interactively(gnus-topic-read-group)

After this Gnus is hosed and I just have to q.

It was working fine earlier today on X.

I should probably mention that I did a ton of fooling around with
groups earlier today.  Killed a bunch, put many in topics, etc.  So
maybe I did something to screw up my .newsrc.eld.

Or is our newshost just messed up.

BTW, there should be some warning that C-k and C-w are bad bad bad to
do in the list of all groups (not the list of all active groups
including killed and zombies, but the list of subscribed and
unsubscribed; you know, the one you get when you do L).

Anyway, I hosed myself several times before I realized that while
these commands were appropriate in the old Gnus, they are not
equivalent to S k and S w.  Maybe they should be bound that way?

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 14 08:57:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA28379 for xemacs-beta-people; Sun, 14 Jul 1996 08:57:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA28375 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 14 Jul 1996 08:57:52 -0500 (CDT)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA07886 for <xemacs-beta@xemacs.org>; Sun, 14 Jul 1996 08:57:49 -0500 (CDT)
Received: from hler.ifi.uio.no (hler.ifi.uio.no [129.240.94.23]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <PAA28562@ifi.uio.no> ; Sun, 14 Jul 1996 15:57:51 +0200
Received: (from larsi@localhost) by hler.ifi.uio.no ; Sun, 14 Jul 1996 15:57:58 +0200
Sender: larsi@ifi.uio.no
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: 19.14, Gnus hoseage
References: <199607140507.XAA02257@gielgud.lanl.gov.xdiv>
X-Face: &w!^oO<W.WBH]FsTP:P0f9X6M-ygaADlA_)eF$<UwQzj7:C=Gi<a?/_4$LX^@$Qq7-O&XHp
	lDARi8e8iT<(A$LWAZD*xjk^')/wI5nG;1cNB>~dS|}-P0~ge{$c!h\<y
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Date: 14 Jul 1996 15:57:56 +0200
In-Reply-To: John Turner's message of Sat, 13 Jul 1996 23:07:57 -0600
Message-ID: <w8s3f2vq6mz.fsf@hler.ifi.uio.no>
Lines: 27
X-Mailer: Gnus v5.2.35/XEmacs 19.14

John Turner <turner@xdiv.lanl.gov> writes:

> On tty, using bundled Gnus, startup, SPC on group:
> 
> Signalling: (error "Illegal size: 0.25")
>   signal(error ("Illegal size: 0.25"))
>   cerror("Illegal size: %s" 0.25)

This usually means that you have a `gnus-buffer-configuration' that is
illegal.  

> BTW, there should be some warning that C-k and C-w are bad bad bad to
> do in the list of all groups (not the list of all active groups
> including killed and zombies, but the list of subscribed and
> unsubscribed; you know, the one you get when you do L).

In what way is `C-k' bad?

> Anyway, I hosed myself several times before I realized that while
> these commands were appropriate in the old Gnus, they are not
> equivalent to S k and S w.

They are equivalent...  Or at least they're supposed to be.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 14 09:26:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA28482 for xemacs-beta-people; Sun, 14 Jul 1996 09:26:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA28479 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 14 Jul 1996 09:26:11 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA07898 for <xemacs-beta@xemacs.org>; Sun, 14 Jul 1996 09:26:09 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA16028; Sun, 14 Jul 1996 08:26:09 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA09440; Sun, 14 Jul 1996 08:26:06 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA02715; Sun, 14 Jul 1996 08:25:32 -0600
Date: Sun, 14 Jul 1996 08:25:32 -0600
Message-Id: <199607141425.IAA02715@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: larsi@ifi.uio.no
Cc: xemacs-beta@xemacs.org
Subject: Re: 19.14, Gnus hoseage
In-Reply-To: <w8s3f2vq6mz.fsf@hler.ifi.uio.no>
References: <199607140507.XAA02257@gielgud.lanl.gov.xdiv>
	<w8s3f2vq6mz.fsf@hler.ifi.uio.no>
Reply-To: turner@lanl.gov

Lars Magne Ingebrigtsen writes:
 > John Turner <turner@xdiv.lanl.gov> writes:
 > 
 > > On tty, using bundled Gnus, startup, SPC on group:
 > > 
 > > Signalling: (error "Illegal size: 0.25")
 > >   signal(error ("Illegal size: 0.25"))
 > >   cerror("Illegal size: %s" 0.25)
 > 
 > This usually means that you have a `gnus-buffer-configuration' that is
 > illegal.  
 > 
Well, I don't set that myself anywhere.

To add to the mystery, it works fine this morning.

 > > BTW, there should be some warning that C-k and C-w are bad bad bad to
 > > do in the list of all groups (not the list of all active groups
 > > including killed and zombies, but the list of subscribed and
 > > unsubscribed; you know, the one you get when you do L).
 > 
 > In what way is `C-k' bad?
 > 
 > > Anyway, I hosed myself several times before I realized that while
 > > these commands were appropriate in the old Gnus, they are not
 > > equivalent to S k and S w.
 > 
 > They are equivalent...  Or at least they're supposed to be.

Next time I'm doing it I'll try to get specifics.  Maybe I'm being a
chowderhead (again).

-John

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 14 11:27:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA28787 for xemacs-beta-people; Sun, 14 Jul 1996 11:27:24 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA28784 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 14 Jul 1996 11:27:23 -0500 (CDT)
Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA07968 for <xemacs-beta@xemacs.org>; Sun, 14 Jul 1996 11:27:17 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id MAA22971 for <xemacs-beta@xemacs.org>; Sun, 14 Jul 1996 12:26:57 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp022968; Sun Jul 14 12:26:39 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA03406; Sun, 14 Jul 96 12:26:38 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA14308; Sun, 14 Jul 96 12:26:31 EDT
Message-Id: <9607141626.AA14308@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Never had it, never will.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: ILISP patches?
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMekfrFtTztlqB385AQGG/gP/fWqt+ELX70a9r+zCyDFNEpi1FsJ4GKhy
	      d3CxDHpKgGyEwCtqHMOZcFlmF4B1vn0Xf+R0iouCKL2WRKpubDONr4GfbOoxQnBh
	      saqqG0Z/Fv+JBmNMBI1u3Td9p89h8qB4d9jKLp83tu3aTRo9ZRHyVo+6pZaMzin/
	      t3ANqvXbn/s=
	      =XZz2
Date: Sun, 14 Jul 1996 12:26:30 -0400
Sender: rickc@lehman.com

The version of ILISP included with XEmacs has some modifications that
didn't make it back into the ILISP repository.  I have a feeling that
some of the changes address issues which were addressed independently
in patches that did make it in.  I'd like to make sure that nothing
gets dropped on the floor in the next release.

If you made XEmacs-specific changes to ILISP that you think should be
incorporated into the repository, could you get in touch with me?
Thanks.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 17 07:19:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA21706 for xemacs-beta-people; Wed, 17 Jul 1996 07:19:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA21703 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 17 Jul 1996 07:19:24 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA14668 for <xemacs-beta@cs.uiuc.edu>; Wed, 17 Jul 1996 07:19:23 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id NAA10793 for <xemacs-beta@cs.uiuc.edu>; Wed, 17 Jul 1996 13:21:30 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id NAA14907 for <xemacs-beta@cs.uiuc.edu>; Wed, 17 Jul 1996 13:20:48 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id NAA25420; Wed, 17 Jul 1996 13:24:32 +0100
Date: Wed, 17 Jul 1996 13:24:32 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199607171224.NAA25420@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: sunpro toolbar
X-Sun-Charset: US-ASCII

Any chance of this patch being added - it adds step up to the 
sparcworks toolbar.

andy

*** xemacs-20.0/lisp/eos/sun-eos-toolbar.el	Tue Jun 18 09:15:56 1996
--- sun-eos-toolbar.el	Mon Jul 15 14:31:40 1996
***************
*** 272,277 ****
--- 272,320 ----
       (expand-file-name "eos-step-into.xbm" eos::toolbar-icon-directory)))
    "A Step Into icon pair.")
  
+ (defvar eos::toolbar-step-up-icon
+   (if (featurep 'xpm)
+       (toolbar-make-button-list
+        "/* XPM */
+ static char * file[] = {
+ \"28 28 5 1\",
+ \" 	c #C8C8C8C8C8C8 s backgroundToolBarColor\",
+ \".	c #000000000000\",
+ \"O	c #0000FFFF0000\",
+ \"+	c #000077770000\",
+ \"@	c #000044440000\",
+ \"                            \",
+ \"                            \",
+ \"                            \",
+ \"                            \",
+ \"                            \",
+ \"                            \",
+ \"         .                  \",
+ \"         ..      .......    \",
+ \"         .O.                \",
+ \"      ....O@.               \",
+ \"     .++++++@.   .......    \",
+ \"    .O+++++++@.             \",
+ \"    .O++OOO+@.              \",
+ \"    .O+...O@.    .......    \",
+ \"    .O+. .O.                \",
+ \"    .O+. ..                 \",
+ \"    .O+. .                  \",
+ \"    .O+.                    \",
+ \"    .O+....   ........      \",
+ \"    .O++++.                 \",
+ \"     .OOOO.                 \",
+ \"      .....   .......       \",
+ \"                            \",
+ \"                            \",
+ \"                            \",
+ \"                            \",
+ \"                            \",
+ \"                            \"};")
+     (toolbar-make-button-list
+      (expand-file-name "eos-step-up.xbm" eos::toolbar-icon-directory)))
+   "A Step up icon pair.")
+ 
  (defvar eos::toolbar-step-over-icon
    (if (featurep 'xpm)
        (toolbar-make-button-list
***************
*** 921,926 ****
--- 964,973 ----
  	 eos::step
  	 eos::current-debugger-clique-id
  	 "step: Step into subprogram calls)"]
+ 	[eos::toolbar-step-up-icon
+ 	 eos::step-up
+ 	 eos::current-debugger-clique-id
+ 	 "step up: Step up from subprogram calls)"]
  	[eos::toolbar-build-icon
  	 eos::build
  	 eos::current-debugger-clique-id
***************
*** 989,994 ****
--- 1036,1045 ----
  	 eos::step
  	 eos::current-debugger-clique-id
  	 "step: Step into subprogram calls)"]
+ 	[eos::toolbar-step-up-icon
+ 	 eos::step-up
+ 	 eos::current-debugger-clique-id
+ 	 "step up: Step up from subprogram calls)"]
  	[eos::toolbar-build-icon
  	 eos::build
  	 eos::current-debugger-clique-id

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 17 22:42:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA23948 for xemacs-beta-people; Wed, 17 Jul 1996 22:42:58 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA23945 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 17 Jul 1996 22:42:56 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA13539 for <xemacs-beta@cs.uiuc.edu>; Wed, 17 Jul 1996 22:42:58 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id UAA22261; Wed, 17 Jul 1996 20:41:14 -0700
Sender: steve@miranova.com
To: nitsch@zeus.ph1.Uni-Koeln.DE (Ralf Nitsch)
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: xemacs dies before file deletion in dired-mode
References: <199607171301.IAA16017@a.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: nitsch@zeus.ph1.Uni-Koeln.DE's message of Wed, 17 Jul 1996 15:00:15 +0200
Mime-Version: 1.0 (generated by tm-edit 7.72)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Jul 1996 20:41:13 -0700
Message-ID: <m2687mjkiu.fsf@deanna.miranova.com>
Lines: 42
X-Mailer: Gnus v5.2.36/XEmacs 19.14

For what it's worth I can duplicate that crash with 19.14, but not
20.0-b26.  The first time I tried it I got a portion of the toolbar
overwritten with a modeline, and after filling in the dired prompt the
garbage modeline stayed on the screen until the next refresh.  I've
since tried to duplicate the overwrite and can't.  Perhaps it's got
something to do with buffers with non-integral numbers of lines.

$ mkdir foo
$ cd foo
$ integer i=0
$ while (( i < 500 )); do
	touch $i
	let i=i+1
done
xemacs -q

Manually resize the screen to about half the normal height
Proceed as in Ralf's message

>>>>> "Ralf" == Ralf Nitsch <nitsch@zeus.ph1.Uni-Koeln.DE> writes:

Ralf> I am using XEmacs 19.13 and encountered the following problem/bug:
Ralf> xemacs -q
Ralf> C-x 2
Ralf> M-x dired
Ralf> "mark so many files for deletion that the confirmation window would
Ralf> be full"
Ralf> x

Ralf> emacs dies giving this error message:

Ralf> Fatal error: assertion failed, file redisplay.c, line 6466, Dynarr_length (internal_cache)

Ralf> Fatal error (6).
Ralf> Your files have been auto-saved.


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 18 11:23:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA29191 for xemacs-beta-people; Thu, 18 Jul 1996 11:23:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA29188 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 18 Jul 1996 11:23:22 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA15790 for <xemacs-beta@xemacs.org>; Thu, 18 Jul 1996 11:23:18 -0500 (CDT)
Received: from newman (wmperry@localhost [127.0.0.1]) by newman (8.6.12/8.6.9) with SMTP id JAA03183 for <xemacs-beta@xemacs.org>; Thu, 18 Jul 1996 09:22:32 -0700
Sender: wmperry@newman
Message-ID: <31EE64C7.43C0A435@aventail.com>
Date: Thu, 18 Jul 1996 09:22:31 -0700
From: William Perry <wmperry@aventail.com>
Organization: Aventail, Inc.
X-Mailer: Mozilla 3.0b5a (X11; I; Linux 1.2.13 i586)
MIME-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: --with-socks w/SOCKS v5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello all,

  Well, seeing as I now work for a company doing commercial socks stuff,
I thought I would try to compile XEmacs 20.0b26 w/socks support (I am
using Socks v5).  Unfortunately, socks v5 has a variety of weirdnesses:

1. No longer uses 'R' as the prefix, but 'SOCKS', so the config.h.in 
   redefinitions of connect/accept/etc are wrong.  This can be changed
   with the preprocessor definition USE_SOCKS4_PREFIX though.

2. If you decide to link dynamically against libsocks5_sh.so, you do not
   need to use any prefix whatsoever.  This shouldn't normally be a
   problem, as the static and dynamic versions of the library have
   different stub names.

3. The library has changed names - it is now libsocks5.a

What would be the best way to modify configure.in to handle all this
hooplah?  A separate configuration switch --with-socks-v5? 
--with-socks=5|4 (defaulting to 4).

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 18 12:41:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA29532 for xemacs-beta-people; Thu, 18 Jul 1996 12:41:28 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA29529 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 18 Jul 1996 12:41:27 -0500 (CDT)
Received: from dowjones.com (firewall-user@gateway.dowjones.com [143.131.189.4]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA09410 for <xemacs-beta@cs.uiuc.edu>; Thu, 18 Jul 1996 12:41:29 -0500 (CDT)
Received: by dowjones.com; id NAA20203; Thu, 18 Jul 1996 13:55:32 -0400
Received: from wsj.dowjones.com(143.131.186.4) by gateway.dowjones.com via smap (V3.1.1)
	id xma020181; Thu, 18 Jul 96 13:55:22 -0400
Received: from nss_interbox.dowjones.com ([143.131.190.35]) by wsj.dowjones.com (5.x/SMI-SVR4)
	id AA14202; Thu, 18 Jul 1996 13:42:01 -0400
Message-Id: <31EE856B.12CC@nrs.dowjones.com>
Date: Thu, 18 Jul 1996 13:41:47 -0500
From: wkirk <wkirk@wsj.dowjones.com>
Organization: Dow Jones & Company, Inc.
X-Mailer: Mozilla 2.0 (Win16; U)
Mime-Version: 1.0
To: xemacs-beta@cs.uiuc.edu
Subject: rebinding C-u leads to strange prefix-argument problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've rebound C-u to advertised-undo and moved prefix-argument over to
C-a.  This has lead to a strange problem when I try to use a prefix
argument with undo.

evaluating this in the *scratch* buffer after doing /usr/bin/xemacs -q:
  (global-set-key "\C-u" 'advertised-undo)
and then typing C-1 C-2 C-u just echos the keystrokes in the echo area.
No undo uccurs until C-u is typed again.  This is XEmacs-19.14 on
Linux 1.2.13.

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 18 13:09:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA29712 for xemacs-beta-people; Thu, 18 Jul 1996 13:09:17 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA29709 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 18 Jul 1996 13:09:16 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA10047 for <xemacs-beta@cs.uiuc.edu>; Thu, 18 Jul 1996 13:09:17 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA27307; Thu, 18 Jul 1996 11:07:28 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Comments on 20.0-b26
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.72)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Jul 1996 11:07:27 -0700
Message-ID: <m2vifl3068.fsf@deanna.miranova.com>
Lines: 13
X-Mailer: Gnus v5.2.36/XEmacs 19.14

The buffer prompt works differently than in 19.14.  When doing a
`C-x 4 b' hitting blank results in an expansion of buffer names making
getting to a hidden buffer (like ' *Original Article nnml:xemacs-beta*')
unnecessarily cumbersome.  I prefer the 19.14 behavior.

File name expansion is slow.  I have 19.14 compiled -O4, and 20.0
compiled -g -O4 so there shouldn't be that much difference in speed,
but there is.  I'm not sure what to do to trace this one.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 18 09:03:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA28742 for xemacs-beta-people; Thu, 18 Jul 1996 09:03:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA28739 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 18 Jul 1996 09:03:40 -0500 (CDT)
Received: from teapot.netman.dk (teapot.netman.dk [193.88.72.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA15503 for <xemacs-beta@xemacs.org>; Thu, 18 Jul 1996 09:02:47 -0500 (CDT)
Received: (from tmadsen@localhost) by teapot.netman.dk (8.7.1/8.7.1) id QAA10157; Thu, 18 Jul 1996 16:02:09 +0200 (MET DST)
To: xemacs-beta@xemacs.org
Subject: Shared Library Support for XEmacs 20.0-b26
From: Tonny Madsen <Tonny.Madsen@netman.dk>
Date: 18 Jul 1996 16:02:08 +0200
Message-ID: <rrenm9oe1r.fsf@teapot.netman.dk>
Lines: 2538
X-Mailer: Gnus v5.2.29/XEmacs 20.0

Hi' Everybody,

This is the first ALPHA version of a module for shared library support
for XEmacs 20.0-b26. With this module you can load shared libraries
into Xemacs at run-time and add new functionality to a running XEmacs
this way. Note that you can normally even unload a shared library you
have previously loaded.

You can add just about the all the functionality with a shared library
as you can in an ordinary C file linked into Emacs, i.e. new classes
(see description below), subr, symbols, keywords and special variables
(defmumble). You can of cause not modify the existing functions, so
you will need some new hooks instead.

The patches for this is quite big (350Mb uuencoded and compressed) but
they include some other stuff too (see description below).

A "hacked" version of the module already existed for XEmacs 19.13, but
at that time it didn't always work as wanted due to it "hacky" (sp?)
nature and consequently I just kept it for myself.

The new shared library module adds a new Emacs object type, shlib in
elisp and Lisp_Shlib i C, which is used to handle shared
libraries. A shlib object goes through the following states:


       	       	       |
		       v
		 +> unloaded --> deleted -->
		 |     |
		 |     v
		 |  loaded
		 |     |
		 |     v
		 |  unloading
		 |     |
		 +-----+


The states are:

- unloaded: a shlib object exists for the shared library, but the
  library has not been loaded.

- loaded: the shared library has been successfully loaded into the
  XEmacs process

- unloading: XEmacs is trying to unload the shared library again. When
  there are no more references to data of the shared library the library
  is unloaded automatically

- deleted: the shlib object has been deleted and will be completely
  removed when there are no more references to the object.

It should be quite easy to use the shlib module (in my opinion at
least ;->), and I have actually already used it for some internal work
in the company I work for. I have also made a simple shared library
with the md5 functionality of XEmacs. Granted, this doesn't really do
anything special, but it was very easy, it illustrates an idea I have
(see the notes below) and it works just like the old C linked-in
version with the addition of the following C function to .../md5.c.

    #ifdef MAKE_SHLIB_MD5
    #include <shlib.h>

    Lisp_Object
    shlib_of_md5(Lisp_Object shlib, Lisp_Object function, Lisp_Object arg)
    {
      Lisp_Shlib	*shlibc = XSHLIB (shlib);

      if (EQ (function, Qload)) {
	syms_of_md5 ();
	vars_of_md5 ();
      } else if (EQ (function, Qtest_unload)) {
	return Qt;
      } else if (EQ (function, Qunload)) {
	return Qt;
      } else if (EQ (function, Qget_unloadable)) {
	return Qt;
      } else if (EQ (function, Qget_version)) {
	return make_int(SHLIB_VERSION);
      } else {
	signal_simple_error ("Illegal function", function);
      }
    }
    #endif

----------------------------------------

The follow small example show some of the things you can do with the
shlib module (better/real documentation is high on my TODO list).

First we make a new shlib object for the md5 shared library.

	(setq sl (make-shlib "/homes/crow/tmadsen/src/xemacs-20.0-b26/src/libemacsmd5.so.1"))

Most, if not all, information of a shlib object is available as
properties on the object. Some of the more important properties are
shown below. Those that are read-only is marked with (ro).

The name of the shared library file (ro)

	(get sl 'name)

The name of an entry function in the shared library that is called
when the library is loaded and unloaded. The default for the md5
library is "shlib_of_md5". The name can be changed as long as the
library isn't loaded. The usage of this function is described below.

	(get sl 'entry-name)

The version of shlib interface utilized by the shared library. This
allow for older versions of shared libraries to coexist with newer
versions of XEmacs. Note that the version number does *not* just
specify the shared library interface (in this case the interface to
the function "shlib_of_md5"), but also the interface from the shared
library to Emacs.

	(get sl 'version)

A flag that shows if the shlib object is currently loaded. (ro)

	(get sl 'loaded)

A flag that shows if the library can be unloaded once it has been
loaded. Not all libraries can be unloaded again. (ro)

	(get sl 'unloadable)

A flag that shows if the shared library is currently being
unloaded. In most cases a shared library will be completely unloaded
at the next garbage-collection, but in some cases where the user has
made other alternative reference to the internal structures of the
shared library, that is impossible. Consider the case a shared library
exports a subr, e.g. "md5". If the user makes other reference to a
subr object, e.g. (fset 'my-md5 (symbol-function 'md5)), then shlib
must wait until that reference disappears agian - which can easily
take forever. (ro)

	(get sl 'unloading)

A list of objects exported by shared library. While the library is
loaded this is a list of all objects exported via, defsymbol,
defkeyword, defclass, defsubr and defmumble. While the shared library
is being unloaded, this is a list with the objects that was still
referenced after the last garbage-collection. (In case you wonder,
internaly this is implemented as a list while the shared library is
loaded and a weak list under unloading). The unload of a shared
library can not be completed until the list is empty. (ro)

	(get sl 'objects)

A hook that is run after the library has been loaded. This allow a
developer to load other stuff at the load time or simply change
internal values. Use (add-hook (get sl 'after-load-hook) 'some-hook)
to add a new hook function. (ro)

Similar hook exists for before-load, before-unload and after-unload.

	(symbol-value (get sl 'after-load-hook))

Now we can load the shared library into the running emacs and add
the md5 function.

	(load-shlib sl)

And run the md5 function on something valuable ;->

	(md5 "Tonny Madsen")

When you don't want the shared library any more, it can be unloaded.

	(load-shlib sl)

The library will be completely unloaded as soon as all references to
internal data disappear as described above.

	(garbage-collect)

Now the library can be deleted

	(delete-shlib sl)

----------------------------------------

Notes and TODO list

Ther are still a number of things that need to be done with the shlib
module. Among things I've been thinking about are:

- shlib support is added with the configure switch '--with-shlib'. If
  there are no support for shared libraries on you architecture, the option
  will be ignored. See below.

- shlib only supports OSF/1 for now. It should be quite easy to add
  support for other architectures, and I plan to do some of the work
  (through I can't test it) for Sun, Linux and a few others. If
  somebody wants to help me out, I'll appreciate that. The wanted
  interface is described later in this mail.

- Ultimately, shlib could be a way to make a smaller XEmacs core,
  where some of the advanced functionality is left out until needed. I
  have made a small test with md5 as noted above. Which functionality
  to include in the XEmacs core and which to put in separate shared
  libraries should be controlled like databases are controlled now.

- shlib does not support defmumble yet. This will be supported for the
  next version.

- the naming of shlib functions is not consequent. Currently the name
  shlib is used for most function can variables, but Ben and Bill both
  wished for a longer and more descriptive name like dynamic-lib or
  shared-lib. Next version.

- shlib does not handle documentation strings yet. I haven't thought
  too much about this yet... Ideas appreciated.

- shared libraries should be autoloaded. I have started this, but I
  haven't finished yet. It seems to be a simple extention to
  do_autoload and Fautoload. Is it time to add an autoload object
  type?

- documentation, and lots of it...

- installation of automatically generated shared libraries.

- I intend to do some work with the magic symbols soon, as they
  currently are every difficult to extent and understand. One of the
  things I would like to add is autoloaded variables!

I hope the next version will be so stable that somebody can start to
experiment with the XEmacs light option described above.

----------------------------------------

To apply the patches use the commands

% cd .../xemacs-20.0-b26
% zcat xemacs-diff.gz | patch -f -N -p1

You can removed the src/lrecord.h file as it isn't used anymore...

% ./configure .... --with-shlib
% make

If you can't handle unified diffs, I have some context diffs
too... though they are somewhat bigger :-<

Note that I haven't changed anything in the installation yet, so if
you choose to install any of this (I can't recomment that!!!),
remember to copy libemacsmd5.so too.

----------------------------------------

In order to make shlib I have made some other changes to XEmacs. The
most important, by far, is the addition of classes as first-class
XEmacs objects. I expect these to change into a scaled-down version of
CLOS as soon as I get the shlib module finished.

Technically I have made the following changes to XEmacs:

- I have unified the two object types LHEADER and LCHEADER into
  one new object type LOBJECT. We now have three object types as
  described below.

- I have changed the header used for LOBJECTS to use a class index
  instead of a pointer. That has allowed me to add a number of flags
  to the header.

- I have changed src/Makefile to make a shared library for md5 if
  wanted. This is currently controlled directly by a non-setable
  #define in config.h.in

- I have split the LOBJECT of alloc.c into two new files classes.h
  (more or less the old lrecord.h) and classes.c

- I have put the make-... functions for floats, bit-vectors, extents,
  events, and markers into their respective files.

- lcrecord-list has disappeared again. The functionality is part of
  the LOBJECT inplementation (see LC_KEEPFREELIST below)

- staticvec is dynamically allocated

- I have changed all uses of the LRECORD structure and macroes to use
  the LOBJECT ditto.

- I have added some typecasts for alloca, as the alpha CC compiler
  otherwise gives me seome warnings.

- I have split Lisp_Subr into two parts, the static part that is const
  and allocated at compile time and the dynamic part that simply
  corvers the lobject_header.

- I have changed all references to header.uid to LHEADER_UID

- I have added a *temporary* option to xemacs -sleep, which will make
  emacs sleep for 50 seconds at startup. The option must the the first
  option. I use this option to attach to a running emacs from by
  debugger. If I start emacs directly from the debugger, the shared
  libraries of emacs itself (not shlib objects), like libXm.so,
  libXpm.so, libXt.so, libX11.so, and libc.so will have different
  positions in xemacs than in temacs, which make xemacs coredump (in
  my case because _iob has moved).

- the names of all class names expect cons, integer, char, etc has
  been capitalized.

The following is taken from classes.h (a new file):

   All data in Emacs is organized as objects. Each object belong to
   exactly one class. The class defines the common behaviour for all
   objects of that class.

   For each class known to Emacs the developer must use the
   DECLARE_..._CLASS and DEFINE_..._CLASS macros to fill out an
   implementation structure that describe the implementation of the
   class in terms of C functions and a few flags . This structure used
   as argument to the defclass function to define the new class to
   Emacs.

   Each class defined in emacs has a class id (always
   non-zero). This id is a small integer, that is used as an index in
   the table class_ids in order to find the class structure that
   corresponds to the class. The constant CLASS_ID_BITS (defined
   below) specify the number of bits that is used for the id in the
   header of LOBJECTS. The number of possible classes is
   2**CLASS_ID_BITS. Pure emacs classes also have a class id. The ids
   are allocated in defclass and freed again in the finalizer for the
   class of the class, i.e. the meta-class.

   *** OBJECT REPRESENTATIONS ***

   Emacs uses three different representation of objects. Which
   representation to use, depends on the amount of data for the
   object. The representations are called DIRECT OBJECTS, NONHEADER
   OBJECTS, and LOBJECTS. Each of these object representations is
   described in details below.

   The decision about which representation to used for a new object
   type is primary based on the number and the size of the new
   objects, but in general you should always use the LOBJECT
   representation. 

   A very, very large number of very, very small objects may be should
   be use NONHEADER OBJECTS. If the object is more than 4-5 words
   (int) large, it very probably *should* be a LOBJECT. With this
   said, just about all new objects in Emacs will be LOBJECTS.

   If you opt for using DIRECT or NONHEADER OBJECTS, you should know
   that there is a lot of work involved with changes to most parts of
   Emacs. So don't!

   If you have a Lisp_Object the corresponding class can be found with
   the macro XOBJECT_CLASS(obj).

   The following text first describes the different object
   representations and then describes how to make a new class.

   *** DIRECT OBJECTS ***

   These objects are used for objects that can be represented directly
   in an Lisp_Object structure. These objects are *very* fast to
   create, delete and access as they don't have any allocated data
   associated with them. DIRECT OBJECTS are identified directly by the
   value of the XTYPE(object) macro.

   These objects are ignored in garbage collection as there is no
   memory to free.

   Emacs has two object classes of this type: integers and characters.

   *** NONHEADER OBJECTS ***

   These objects (previously known as "basic" lrecord objects??) are
   objects that are not an LOBJECT, i.e. objects that do not have an
   lobject_header at the front. These objects are allocated in frob
   blocks (see alloc.c). A NONHEADER OBJECT can not be recognized from
   the memory image without a Lisp_Object "pointer", but is identified
   directly by the value of the XTYPE(object) macro.

   Garbage collection of these objects can easily become complicated
   as some special field in the memory block of the objects must be
   used for marking and mark_object and the corresponding
   sweep-function must be modified to do this.

   Emacs has a number of objects of this type depending on options on
   the compilation time: cons-cells, strings (depends on
   USE_LOBJECT_STRING), symbols (depends on USE_LHEADER_SYMBOL) and
   vectors (depends on USE_LOBJECT_VECTOR). Note that some of these
   object types are likely to be changed into LOBJECTS in the future.

   *** LOBJECTS ***

   These objects are used for all objects that is not DIRECT or
   NONHEADER. A LOBJECT is characterized by having an lobject_header
   as the first field of the structure.

   LOBJECTS are allocated and freed using the functions alloc_lobject
   and free_lobject.

   The memory used for LOBJECTS can be allocated using two different
   methods: either in frob blocks, where the objects are grouped
   together to save performance and malloc overhead (see below for a
   longer description), or individually using malloc for each
   object. The main difference between these allocation methods is how
   garbage-collection is performed. Note through that objects
   allocated in frob blocks must have the same size - if you have some
   variable-size data, you will have to use individual allocation.

   Some flags are used to control LOBJECTS:

   - LC_USEFROBBLOCKS specify that frob blocks are to be used.

   - LC_KEEPFREELIST specify that a free-list should be used for the
   malloc allocation method (this is normally not done; with this
   flag, garbage-collected LOBJECTS are freed with xfree.).

   - LC_INVISIBLECLASS specify that the classes will not accessable
   from elisp. This is not really used yet, but is ment for a class
   like Opaque.

   - LC_INVISIBLEOBJECTS specify that objects of the class is not
   visible at the elisp level. It currently only affect lobject_list,
   which will return a list of all live objects of a specific class.

   - LC_PROTECTEDOBJECTS specify that objects of the class can be made
   persistent by setting a flag in the object header. If the flag is
   set, the works like if the object is put on the staticvec
   array. This feature is primary ment for shlib loaded objects, which
   can not be put in the staticvec array (not if they should be
   unloaded later, that is).

   The class of an LOBJECT can be found with XLOBJECT_CLASS.

   LOBJECTS are identified as having (XTYPE(object) == Lisp_LObject)
   (checked with the macro LOBJECTP(object)).

   The structures used for LOBJECTS *must* have a struct
   lobject_header field as the first field. ###TM### I would like to
   do away with this requirement, but that seems to be rather
   difficult, and will probably require a replacement for malloc&co.

   All classes not mentioned above uses LOBJECTS.

   *** DECLARING A NEW CLASS ***

   ###TM###: DOC

   If you want to make a new LOBJECT class the object structure *must*
   have an lobject_header as the first field. If you expect to use any
   of the macroes found in this header file, the field name must be
   'header'. Thus we have:

   struct foo_object {
     lobject_header	header;
     Other fields...
   }

   

   *** FROB BLOCKS ***

   NONHEADER OBJECTS and LOBJECTS, with the LC_USEFROBBLOCKS flag
   specified are allocated in frob blocks.

   Frob blocks are large malloc()ed blocks of memory and that are
   subdivided into chunks of the correct size for an object of that
   type.  This is more efficient than malloc()ing each object
   separately because we save on malloc() time and overhead due to the
   fewer number of malloc()ed blocks, and also because we don't need
   any extra pointers within each object to keep them threaded
   together for GC purposes (this is accomplished by only allowing
   static-sized LOBJECTS - NONHEADER OBJECTS are always static-sized).

   alloc.c contains a large comment on the allocation method for
   NONHEADER OBJECTS.

   *** CURRENT CLASSES ***

   The following is a complete list of the defined object classes in
   XEmacs. Please update this list if you alter anything in Emacs.

   The 'repre' field specify the type of the object in terms of the
   basic object representation and can have the following values. The constants
   in brackets are found as the value of the 'objecttype' field of
   Lisp_Class.

     d	[LC_DIRECT] embedded in the "pointer" directly
     n	[LC_NONHEADER] declared as NONHEADER
     l	[LC_LOBJECT] uses lobject_header

   Some of the LOBJECTS have the suffix "(fb)"; these LOBJECTS
   (currently) uses frob blocks.



   Name				Type			Struct	Notes
   ----------------------------------------------------------------------------------------------------
   "integer"			(Lisp_Int)		d
   "char"			(Lisp_Char)		d
   "bit-vector"			Lisp_Bit_Vector		l(fb)
   "char-table"			Lisp_Char_Table		l
   "char-table-entry"		Lisp_Char_Table_Entry	l
   "charset"			Lisp_Charset		l
   "coding-system"		Lisp_Coding_System	l
   "color-instance"		Lisp_Color_Instance	l
   "compiled-function"		Lisp_Compiled_Function	l(fb)
   "cons"			Lisp_Cons		n
   "event"			Lisp_Event		l(fb)
   "face"			Lisp_Face		l
   "float"			Lisp_Float		l(fb)
   "font-instance"		Lisp_Font_Instance	l
   "glyph"			Lisp_Glyph		l
   "image-instance"		Lisp_Image_Instance	l
   "marker"			Lisp_Marker		l(fb)
   "opaque"			Lisp_Opaque		l	Should not be lisp visible
   "opaque-list"		Lisp_Opaque_List	l	Should not be lisp visible
   "process"			Lisp_Process		l
   "range-table"		Lisp_Range_Table	l
   "shared-lib"			Lisp_Shlib		l
   "specifier"			Lisp_Specifier		l
   "string"			Lisp_String		n/l(fb)
   "subr"			Lisp_Subr		l(fb)
   "subwindow"			Lisp_Subwindow		l
   "symbol"			Lisp_Symbol		n/l(fb)
   "tooltalk-message"		Lisp_Tooltalk_Message	l
   "tooltalk-pattern"		Lisp_Tooltalk_Pattern	l
   "vector"			Lisp_Vector		n/l(fb)
   "x-resource"			Lisp_X_Resource		l
   "buffer"			buffer			l
   "command-builder"		command_builder		l
   "console"			console			l
   "database"			database_struct		l
   "device"			device			l
   "extent"			extent			l(fb)
   "extent-auxiliary"		extent_auxiliary	l
   "extent-info"		extent_info		l
   "frame"			frame			l
   "hashtable"			hashtable_struct	l
   "keymap"			keymap			l
   "Class"			Lisp_Class		l
   "stream"			lstream			l	keep list of free objects
   "popup-data"			popup_data		l
   "toolbar-button"		toolbar_button		l
   "toolbar-data"		toolbar_data		l
   "weak-list"			weak_list		l
   "window"			window			l
   "window-configuration"	window_configuration	l	keep list of free objects

   ---				Lisp_Buffer_Cons	n	?
   "symbol-value-forward"	symbol_value_forward	l
   "symbol-value-buffer-local"	symbol_value_buffer_local l
   "symbol-value-lisp-magic"	symbol_value_lisp_magic	l
   "symbol-value-varalias"	symbol_value_varalias	l

As described above, all LOBJECTS have a lobject_header structure as
the first field. This structure is smaller than the previous structure
known from vanilla 20.0! It includes the following fields. (Note that
the dyn_alloc field is about to disappear again).

   typedef
   struct lobject_header {
     /* The class index of the class of the object. All classes are
	registered in the class_table. The CLASS_ID_BITS bits below allow
	for 2**CLASS_ID_BITS (32K for 15 bits) objects classes, which
	probably is enough for some time to come. */
     unsigned int		class_id : CLASS_ID_BITS;
     /* flag that indicates whether this LOBJECT has been
	allocated via alloc_lobject (flag is TRUE) or has been statically
	allocated (flag is FALSE). A statically allocated object will
	never be freed via free_lobject. */
     unsigned int		dyn_alloced : 1;
     /* The mark bit of the object. */
     unsigned int		marked : 1;
     /* A flag that indicates whether this instance has been
	finalized. This is used to guarantee that the finalize method
	is always called. */
     unsigned int		finalized : 1;
     /* Flag that indicates whether this LOBJECT is on a "free list".
	Free lists are used to minimize the number of calls to malloc()
	when we're repeatedly allocating and freeing a number of the
	same sort of LOBJECT.  LOBJECTs on a free list always get
	marked in a different fashion, so we can use this flag as a
	sanity check to make sure that free lists only have freed LOBJECTs
	and no freed LOBJECTs are elsewhere. */
     unsigned int		free : 1;
     /* Flag that indicates whether the object is *not* visible at the
	elisp level. The object-list function will only include the
	object in the returned list if this flag is cleared. 

	The flag is changed with the macro SET_LOBJECT_INVSIBLE(). */
     unsigned int		invisible : 1;
     /* Flag that indicates if an object is automatically protected from
	garbage collection. This flag is only valid if the class has the
	flag LC_PROTECTEDOBJECTS set.

	The protection of an object is changed with the macro
	SET_LOBJECT_PROTECTED(). */
     unsigned int		protected : 1;
   } lobject_header;

This new class and object implmentation has been put two new files:
classes.[ch]. The old file lrecord is obsolete.

----------------------------------------

In order to use the shlib module on an architecture, a small set of
low-level functions must be created. The following is from shlib.h

shlib depends on a 5 low-level functions for the actual operations
on shared libraries. These functions must be defined in a separate
C file with the name "shlib-<type>.c". <type> describes the type of
the low-level interface and is defined in the relavant m/*.h header
files as the value of the preprocessor macro
SHLIB_TYPE. E.g. m/alpha.h contains the following lines.

#define SHLIB_TYPE dlopen

This line means that the interface for Digital Alpha machines is
found in the file shlib-dlopen.c

The low-level functions are

- void shlib_lowlevel_init()

This function is called when XEmacs is started. It is *not* called
until Emacs is initialized (i.e. it is not called when emacs is
dumped).

- void *shlib_lowlevel_load(char *name)

This function loads the library with the specified name into the
running XEmacs and returns a handle for the library. If name == 0,
a handles should be returned for the running XEmacs itself. This
handle should be usable with the unload and get functions below. If
an error occur (library does not exist, library not loadable, etc)
a null-pointer should be returned and the next call of the error
function should return a string that describes the error condition.

- void shlib_lowlevel_unload(void *handle)

This function unloads a library previously loaded with the load
function. After this call, the handle will never be used again and
any memory allocated for the handle should be released.

- void *shlib_lowlevel_get(void *handle, char *name)

This function returns the address of the function or variable with
the specified name in the specified library previously loaded with
the load function. Currently this function will only be used once
for each library, but don't depend on this. If an error occur
(function or variable does not exist, etc) a null-pointer should be
returned and the next call of the error function should return a
string that describes the error condition.

- char *shlib_lowlevel_error()

This function should return a string that describes the last error
encountered with the load or get functions as described above. The
function will only be called if an error has occured.

The following is the code corresponding to the dlopen library used
on Digital Alpha machines.

void
shlib_lowlevel_init()
{
}

void *
shlib_lowlevel_load(char *name)
{
  return dlopen (name, RTLD_NOW);
}

void
shlib_lowlevel_unload(void *handle)
{
  dlclose (handle);
}

void *
shlib_lowlevel_get(void *handle, char *name)
{
  return dlsym (handle, name);
}

char *
shlib_lowlevel_error()
{
  return dlerror ();
}

As it can be seen, this is real easy - at least for this architecture ;->.

The following lowlevel interfaces are been defined so far:

Interface	Machines
==================================================
dlopen	OSF/1

----------------------------------------
The patch!

begin 644 xemacs-diff.gz
M'XL("(\:[C$``WAE;6%C<RUD:69F`.P[:W/:R+*?H?9'].+4&@)R$'[CZYP0
MC!W.^I%C\,:YFRVMD`;06DBL'K:)U__]=O>,A'@Y3C9UJF[5LAN0YM'3T^_N
M&=M.OP^:%GM.WQ'V80V?`V'%0>C<"GSVQ)W6=UP!]V)D6J%6JVY4M5YM1_,#
M9_#*\KV^,XB#A>YI3U[3M"],SG6',?P[]J!6!7V_OK57W]S'A_V=?+E<7@U9
M37-!WP.]5M^JUO6JG/;F#6C[6Y4M*./W-KQYDP=[XIDCQSI<7\_#G1,-C7M=
MIY<ROX1#U^EQ7R!<PW1='T?:HF_&;H2-<2B,<!)&8F2,YCMIK5IMEQ:KU?;4
M:KD<(N>$8/LB]-8C0'H&PHO<"=SYP<U&'@E+ZVJA;]V$N5S3'XV)QM0&83P>
M^T$$?3^`SD7SYPX430_:7B0"3T0P#OS[26DC7TY`$.I/@7AWVGX[71&AC)X8
MW6U=GN%Z<&=.(/)AA%MTQJZXYRV%(G!,%US'$R&8GDVXW#JV@%MS$`O<7(*D
MYCHW@BFS4V4V[%1W*LA<(DWR.3C(0[Z<O*VMP3LSA&@HB-@!LN'/6"#!;8E_
M@N._\N5<8<JQ`I2P@6>?F3<"1Z$D$HQ;TXT%#%"$/=Q*"`*G(-3"1(0%P&T6
M/+^PP5,M,Q10>/&`,QX+X'C<"#"!OV`B^"N$4@Y[#^D)D9;]'G9Y/O9P%SY-
MNUXJI.A3%-;0)_!(J0$*H'BL,WZ??M>T%P_^..*V=<`GQ_<`)88W&N*^D?I#
M$U70A)[ONP)%@#>%6'=0"IR(!JAM??H=<5NG?7WZW?/7-PKI^I"L'PZ1>D8<
MF@/Q6"C!ZY]JZ1AQC\!T]:IV(4+3FC('WW%M`H-X/AY^4N3Z5"A,Q]#$*7-7
MLY,%+.4F*&Z25!(S260V]VHZR<SFWN9^19="LR8\V^F3P*PY?50]*17&Z:EQ
M\?;?G7PYM0F&8<B^TU/J.9P;MR;<4#PQG$;P2KB79*6/G6[KS#AKX)!F'F:F
MSMH$9`)O8'=WBS>PN[NS7:G5I-3GH>_DRTX??B4Z3D48A>Y0R>5O!T0PCV@J
MQ]V_>,@@)T?>SXQ+&`R0M08LJIX?)71&LI-NOWA(D#=)VAX5]S(&T/.I2=+H
M(5^.D&6@>8CPK0AZ*)4%^.DG^)0ORT5S2!['<[P!O&O\TC(8U4+2N<:=.&/:
M!P6]`*]?,PFQ-]P8YLM'K>/.8>$%_8!V-!U[J",DTS)0$PP:BV,>,J^/G_C5
M;CQ.IZBFMXM-S4==/1T]YLOR,5Z<&B].C=.I\72J6)PJ%J>*=*J@J;@=_$8!
M)C'`?S`C"B3_2R2!V,,BM5?=WR>1VM-1M'99HM1\R3UR(TNG)^(A#3[QRO$6
M/0Q9C(QX9@WL$N'\,DQV.046^1D\I9K/@[2_2P2R@4BL#!6P\QEQ"([*=<Q(
MAB(UT'?J^EY=WWU&*$(SS]"`4S0"&(ULU3=WZK6M:312VZIQA(`__T0(LQ&"
MSI*]4ZO^$R'\$R$\*T*H[>]O<X10U6M?B!"Z']^WEOE[:C_,#ED9&?#([Q(7
M;-6J54)[JU;;K.@J+H#?H-$TT/^USUM%Z4-(HTOPZ]^)&`CI_W*\`$OW0LC0
M7K#[*QW?`BR2"P+%I-S<8JNQM;E7_7_B#Z$83<:B#B]2!I7^2R[2=<+QJW'@
MC%ZYOFG'XPWA+GBR)6-6.\PE@W/'@<-^$W;)^]7VZM6MU7YS&8`/*'6<S.]"
M=;^^5:NCAJ3N4]]ES:&?G:R/*"+IBGUA1JAX8UBWT?GX@]+4RM"0?NQ9J(B`
MYDGV%TJEU"K-`6`FE[)V;6:^E(%2:=7ZZ`P%=N;FIE&S1CO%?=+L[\1-QN9I
M9B9#GL/+9*PLJZ`W`1VJ>KU:Q?^1$[O5+[!R=KXLRU3W,`J:*<M4*U7D8V63
MS5_YX.``TFT0CJ<(#EQQBZ]$0+([(>M0H3,T`Q214Z<7F(%#RJ%4#&URF2`!
MQU-,./P=FZA\?A^N6X3OAAHBWZB_'PB,!OQ^=(=@#V#BQ^CH/71#MA-&@=.+
M(T$N%&.85[CZR$>>3;"!H<2>C1Z+7!=I:TC+T,O)^16<"$\$Z`G?QSW7L1!;
M2W@8/J"G&U-+.,0M]"8,A:8<$Q8=A04<^PB9;>U!XK@Q\0K)[]<JY+R+&)PB
MIH&*!DH,Q_0FX)K1=/#B9J=[LLDVT<I#?TR!D,F!PIV#@MIC3]R/W0K@2(;P
MH=U]=W'5A<;Y1_C0N+QLG'<_'K`#\.,(7;Z0L)S1V$5!QC@J"$POFB!!>/I9
MZ[+Y#N<TWK9/V]V/M(/C=O>\U>G`\<4E-.!]X[+;;EZ=-B[A_=7E^XM.:P.@
M(T1"3H:R@J1]9@M2S1:1Z;@IBS\B)S&6B5U;1D>H60+URL8PR?+'DR\S2Q+5
M]=&.<_`KR8ARJO!B"6M>O/_8/C]!=-M]<IT5N`L<%!D,N1*^,IPEO*W`SNXV
M1J-A"(U;48&F.>H%CCW`Q[,&5&OZYGX%KCH-M2&$,?$LDIMXS`C5V54C&X\[
MQ\LDGPP->?#`'T%J7IFGX'L8@CN2`,IJ2?5C(>&$W4Z7;?JVJ--+T;1M;>C[
M-[".@6>D#2SUAN--U_DL-+1S:,UH,2VQH(S7VMI:]PR_ZE!$Z.@=4`,B.22$
MHA3?T!^).Y)#R@CD``R%+1&&(OS)\@G2#W.&`D.Q$%`[Q-^SI&%@O:*D@$9@
M`K<L@5P<LMJ2+H[-)I-H1K?VZ]M/U+67S)\M<&].Z^)<)]N503#^K(J!IS$8
M-BD&J\"8*DJ*HOY\-4W%PDMF+(F#>8WWYR?8`+,M!NK8_\KRQ0YGOWL[>Q5]
M9P[55R^AHV*ED$T\IH;*Q+..DWPD2NOW_A!6%,++5R06"H&SQL]JD\;9T78&
M;8S,I^TH63TF^,C>W@C]#3TS$+M7['P&Q)(90-#\#%7*:PLS\5]G'E`><-NN
M&48LG:,XI$`1DX4[H)"!&D.X&V*6AWKN1`YKF0UH/TQ`$J$WD1:.XQ"TVW8\
M&I.%(R^#*MV;<(LFI.MC#F#DM(T<V$M.*/)$S/`P9_9Z@;A%&>!<!7][^'-#
MH2H]Q_V^".AA$@D+[0$^?LIK.0IL'"_"-WHB=>5']!Z.;;M"O40FR9:%3%5/
M(]OU_3'#*'\K#"0:&H8Y:)##-V[$<,&7D^63AHY/F",UB@B(CT<-=$F-3DNR
M\*CU]NI$/MKB%GT`C6@W3B^21@>%$MMLQO"3(N<>*5UY;W\G4;Y<W[08,>*>
MXZL'(J9Z'$GZ]=%,1GV/1\IOWXLT-8Z0[`>8\2M"#Z2'PK>!B,B^FK<#?#EI
M'TO<!NYD/"0@)U=MV4*D_=*LC`58!@!R0S,<*FP<C'682XY'51U^"&WA\D/D
MJE$W8C(R$UZX2'$BF)NAO99#60Q\6FED!C<L5*P[&"2<7[UM7"IU0G%'H:-F
MS,-.VYWWZ:86YZ=*^#P0D#MO=.28\T[:IDP*#O?'YI^Q2%F\O[W)!XB[>J6V
MSQQF#3%);3`_>\-Y?^.-,F'GJ+IWZ/X#+HJI,U$*DH;8@2U(NQN,0*2%`VGA
M)AN<:&``@3,Q^%R/DHD8DN'<"@;"%,%TWC4N6T=H1\Y_YM"3W317UQ*`#$<!
ME<$<A0AH&"QD``9]&[,6\PI%_Z39)'N6-)RP=9L:_'3%(NVW0NB,XZ@$+XK-
M9@DTM0^FA79-F\/P4_L\?8[$?02:K^81?DBD]NPN,^2Q_80TJ)]Q!*D+J*#]
MAS_(/HYC%$/>QQH(%X.8'Q-*%!'/J^L2_/47I$V&T3H]-HS2M^]JBOL:*.N^
MQNNF:Q#52I*(T\;V9?OZV:N>'DU7U0:@89AGW1B!&%"\/H$7#]V+B]/+BXON
MXZLX###7ZKT*?8.D4"9&2S!%_T6D)OX3*HI@SR;!B8+Y>8&#B@J+P+-+$DG4
MDEFB'+6:1N/T_;M&B0Z0TN:+SK'^3%IA-(\8'I\V3CJ2<.KQ],CH8);2?&?(
MN:#-\X]&M]^V<*SF6ED2_3A%B[!B9+Z"7,P[VU*KD5<*(G:_VA.46[WF#'%3
M,LY&6=?&A_;YT<6'3AZ4B=JK;.J83E>KNJJ+3'%O77=;E^>-4YQS=-+J2L/7
MNJ?RN^EVAL(EVXV8WFG7D>:A-+$8IFTH:]E67%'[=C.G/<?,(<(?GC1RVC.,
MG);7ID9-6CELR)HY>LW0Z,-WM'*$X'<S<X3G5]BY;]W6%'E:C^V<I@SLG*&3
M=)RW=,];]SL;.DF;14OW%418:>A2.BP!OLS4S9/E25OW?&I]FXV;H<PJ8_,5
M+'N.?9LAV!-K+K5P&ILLJ9ZG'R@L1;7M&&<7W?:Q1%1UIHBR?4Y:,P::`<%T
M9PS"N.B^:UT:Q^W35H<SP/O(<AWC>K1ASKY21@@*!.>`;%_W-REITJNZKK*F
M-&V=&I59Q%:AI9#*HK.((,6CR;%<%KUH%MM(8BO#5+VVL\-(UO:V%I#$B+6N
MZ@S9I?/E%1US62MEB<BOPHA.3@.!9IJN@$24%SKHD`L20$&6R4P/$P(TQ2-,
M%U#@D\*E%X]Z(CB0N&XA076JXV\C1?&!\R8S@""[/2I)F%/WU3QMM\Z[QG62
MLACG%^>2OLR&128L84%^D=GUA144/V@)!5_+3=7CBZ,KBVO0*6\VA/@V&+/8
M1RNPO^X^&_79H95%Z%_"^QD`9I$FEJY`.V7K<Q"?&UQ9ML87D7\>$$CUB"5W
MN[K'!U#;M9W*?D;+2#_F(BTR:["R.C53"*HG]:,9C+FM,ELR*F4K;^,`K<F]
M9@:#L(Z^,PPLVPD>7V6:-RQU(+TQ1`V3+N]%D2"F,?2*:6C7,PWRN'U3YTIC
M;7-S+SFWM@=.W^#B83VS4K8U>1PNK4;2=0$:)2N0.":<C'J^&\ZV#>=7F#;1
MN=-,`]LBJJAD&U-0B4V4)X#:/76BCR./T[EL'K4O2Z_<.SEV9@S7_H^Y(C/\
M^]5F66.SEI9^5=_3]64U*->-T<&9$ZCM46%Y<[->TY\N+"<3,Z>L^G9]2Z]O
M;V8JRCM<4-Y1?B3Y-&PZ3^AAM'XKK,@/9%U6W]_0-S=0NF2WBZ;?\@.;*_C3
M$5NRQM'U/6^"&-NA\)`K8Q>!T:7&5K,+810C61TOFE;WK+Q4(GG4SP?]6^J8
M'V6)L@.<A;D!G=((:O,L-[8%%'JF=1,%IH7<*BRO@J=#E6@4IK*1`2/KGMB9
M;4QJH-@LKWG*&WDS]H`T_P>J"'W/#Y+PI(E?WQ,F)Y>4T;%_I@([[8_/,JET
M2K<8;"0NX),ES[VH7`T#BSG3.FLT.T;[O)L,-GB<,;`23U]#?I&?KT@O/YTP
ML`Q9GZ3(WI#AP:_Z;P<JP^2C+/S_#UD3#^A,D@K:A,$X<.CZ6(5"$).KY=$0
MUP[IG?LP<W3^Y'MF%%JBB$2.19(%KA1.(W9LP_)C@G)`L2>GM-YG$?AP-Q0>
MR*+T`"P,=DW'`SKG"NG<TO:IV><S6;7H'9]`D8*8R!ZXXR-'3$=[IDW+L^SN
M4DQ6WMJKIE7W'U*\;GT'!^;+ZE>5%R-AD&DS0E0T<R"@2.B'SF>Z5_`@@>Y7
M*_IF#<'N[RCJ/A+Q,!A*0M_&Y<_H3"Y;S8O+(^-=JW&$`=[[HCL4IBV"$I5C
M`8K%M$%[32>X'+DQ5[37R<D>#CX\I`V'!I5=0\/D7V$;DJ"EZ:)7Y[1LX^UI
MZ^\L+(N[TU51!`W\B3WJ,'MTO6)FF[-KS:V$Z?;#4\N5RN72`3PB)\EJ%ZL+
MN_E[T#5M'CK]1P<_DG@AG>70V09GB)$_$$J\`C\>#$GB';J'B+')QFT!T.6X
M-I527D*C3Z?]4B1)+X@V,!YB=%Z19]M-61^Y,]T;)B/79;B"\A+80'-AA:]`
MT.T!9;D146L("(:*%SV!ZB!Y#31OJD^8L<=6E!I\0VX?7J+\&DEC2-JE*<G6
M6++3OJE(5Z")L7PWA:@`SI(17LZ1-:\]$/E7H>%:\HDQX-2\2&O!_QQ"M01F
MCPX:BZ6#I&]>`.4F#9YR2%.XJ@,/\D?.^7%A$HXV',]@$VJ,D(\^J49N9C5`
M-=54=OZEE7\\5#K/\S)@J"'9(1RNLAD\]R`[5GNMQ'1CCKJ',-LP-XND3ZXS
MPUOTK*##Z@\*^0BM,$62F`>2?:;;$R%=B(3VD4H*^1QW9C4TS[C8$F-=+M.B
M1+H<?A#Z'W>?YZ$'PG3!M.V5<$GN2O!31D"4SYX9RUJ!C&="S.R;4)O.!6B?
M-R];9Y13D!CCU]4Y)@*2^A689R_=XY4\"404!QX4$V#4^LCV&ZE:)=J]#T0H
M+X/'7DQ7?6E#V/Z+""852JV1M#[=?S&]]1!:)\U_L6JS[QQA6(A>*.3#9-1R
M-"=F.(0Q"D;(I\O^K;J\-'8I4))&X8)NAO!]-8S,$`VZ#T4$Q=:^$"Z_\S%U
MD6#**R3*G"36P\2HSW0"E^V)Q#X13[LDE[D@`W?GD)UB_^Z**#%8:$T=C!O_
M\'L82?/%I'5RL7P_:9WO"0=\YT?9(C(M>8UXE;$KJTU"ZJT>$KV?X^PA9`;-
M*/RB",AGJ1OSFCTW><ZR)0AE]7=&K^0L"GN*!P=D01!2;B48I9Q973W@\;1!
MV3FSKYS"3=68YG3<G=N7&M5#,;A)7A_Y-S5AR1K5!'C&4N42@N2F:^$J"?#'
M#.$(5+KZZE!$SB@^9V@*KX*X2:V[9\5.VK.:*-5OFL]?376._LN$:WG-=L*;
MT+P5ACPW-M22,IC5H4BCON2A9OP3\WJ%/"BJ'4RIEV79,L_TM+'/4(B*LS]F
M31YQL/C\^:5DK0KHI8Q_8WZJ,$>:(]+SY*`&MT<'`!H9&38`H0ANR2S)A+'U
M'Z`_.9-VI=T'-T%G]3:<\(GHM"(AT0WJU$QA>#,3VZC4`BU0>"?$6+"!@>4+
M\[W2&+>"629Y'3)8"!0A1^KO27H3N23#,A*C,358JW&5H@,O[7@TFE0KG+7P
MLYZ(4T:W'A6%.V+D:#>8G@ZH_I#:!UE+,1@E`PE[9P9V>G<*HTQ*N:T;YAGF
M."H&&Z,S8(=!IIX&=5HGOZ#E5<[`C"(Q&O/?E'"XB40;R8,]9G-(M$!@*UFF
M;FTHK:)KOL8%8Z2(LA#H0S$SB+"OR(RI^))&X'MI9D1I"9E25_L?SW$S9+L^
M:=+]>Y:Y+(^0YGD-\U-%1KH$98QG\>@'?N^982M-3Y!*7'ZR<I'@<);#P"\9
M0J+(]$'U+%ZK[.-4IA]JTH)04JJ$2V5GT^>OO^#K`$!9J3*1"?-4^$Y%#)D*
M[]0V*UL[4-ZNZI4MF;5^-_BR<G",W.P[]\+6.(2F+87RAC.G6?YHQ-=?R;97
MZ"A:_G5.L02N&:#^\+VWD*GH]V$D1CY&6309(F<D-2.,>[;#?\Y&TJ]*5L/8
MNTFO@"MKP%`8"Q(QTU/*)T<A3+Y>!VFM@Z\QBW[__]C[UNXV<B/1S_*Y/P+6
MG-BD2&KXU#-VKBQ3'FUD22/)'D\F<QB*;$E<4VR&3=K63KR__:(>>#:ZV;(U
M3G)WE8E)=@,%H``4J@KU&`U&<E*@R`0AJ!Z"G!?UI6S&8))HVI])MFH,G-Z@
M#QH2.1XXED0\,>."?B,<Z#MP?;`W)5'15LI7T4=)0B=:`Z1J`EE$;%2A*H$8
M)['=V#`&(7$2X1W]'=@,S/J2)T7]3((70I(86'U&(++9]Y(N$O8D7QJAH;(6
M?`%7D@Y/%S/P;TLD@F!*QU&2\.PAD!*+KG]?$(^)LX=37J8YQ\F%;NJ#M,JB
M;7\6.7A%:WB<T05RN@`Y4QS7PU-T$W5BBO?D\U*81H&CA7,/<01W9I&U.FDD
MHW6Y"N8?8TV;>14E4E2@+8F5`0J:LNMW`(+.W)OX8_0!56(W]!A@]-'[8318
M2-RH-3/H3P#.!S">X%@8,.8R&V?,81WB)-\N)*:B?C*"L<=L7"%!3J*/9KC8
M.;4<)C$MD>%P!/1$2F&@)L6^)SSR_I!FFJU,!S"W<(:/I3BC,<9S@^*+MR50
M.4<R`&QFW,A]EB?-^J4SJ9)%"TK,?QR?'#-!)`WT.<RF4CW?E'&+HM;Z'G0C
MBV8@G,)T(TPS$$9!NI%%,Z@?Q>E&%LU`.,7H1@[-(.P6H1MAFD$8*4PW?)I!
MYI*9=(,O)LXMLF$-$2M_`=E0)(.A(QCFZTN@OM`+$,=SM9@AF-%$_KJE<UK^
MI[HFMZU`U?/%3>JD`RV0]O,!,F@OTQ*X4@$;P`]6R9>-5OI$X@#-DZN`.'#_
M'M:4%U95$%=99?O;*LR=Q&85W8#F57W0@*?1Y'J=IUC_%N?&CC]!.S#8YFH\
M8BA9;XE3T+%+CO3T%*N#Y;5L7$H(:KC'\9R]E@@LJ5"3:30`MW,<<A]5"G?X
MHC^8TQ1IG"`4(+E`(9,=("+(Q2T(`:#T)P=.@W;)4"Y(34%MTJ&(<&Y4$VR:
MGR2Q[`B8/Z!)A*FS3C,%0.6DZB;Y0%.<)/*"YUBAC/38IF&FGZB!`47/I'\-
M2^Z&X.#)`%[Y?=+SH,,$+J($2#JN$D4\4H.651"(6JS,(?#H:!`X2+4I$(A:
M:!H<$#0ZZN&`X&%1[1X8\2<]7':R&UW8X^DW=)^4S#4CUK>[%,)4E3TGC"R'
M<P&;"`EYC=0PJ9+]"2%G&7@$D-N$!A_-X6#;FP,U`B):-65'Q+S0XN>].$+Z
M).6N.0%.HOYL`'=+\AM2JA&N74U):$X1#D-`RB-!2,3CC1TL5""K-S$XD+!=
M)(`FL2I2NS&A4_^<]Y`F'7B@X#'2UU=@N/A*EZ/K:Z1J_8G-:M"N#\RCW"1C
M\!*4_08''KPR(P^OF_[X"I:HA"AN1]<W<S[VWW/S"?C@E3VB:Q]=,&AT5M=[
MVDRQW04\"(B,`N`J1&/`&TU:S."<,!_<@/8!'`MHP0%E"$%"<E1PHY9\_J)L
M;7A%%=W]>Y^]2R=Y8/_>9^\RD.#^+;9W53>R]F^QO4OL1*'-E;-WF1WX$O+@
M[%V$D[%]"VY=YK.RMV^AK8M0\K9OL;U+G<G;OTOV+@%8LG^7[5V?]4SMWV)[
M%\'D[-_LO2MP:[]EVQ7H'#*80>HBV9S1[0CD)K!F5Y()K8PO@:#<BRB4$_QS
M2!-`JQ)WYB@9+)($>2SF0&$3`4,*/KO@A#X%_^I$R&4%2PJ'\S&"]11;E,*7
M=ZC3R\NE"99D+X%=(6(U5E;8@NXU256K&3=T'$X&L]$ES:5F8YEC^XD94AR3
M7)CC,>@)$Q"&V-2DIV4&;DKB!,5-LK+9V*QNB,I&NV6LDI"%D=02\267',7T
M@7V@I2;\*5EQ<O0?XGTXUIU%MW"JX64`$8$([R1$HUZO(WL,ETX@4Y,@E!@N
M(JS'(<&9[[GDN0J6-04+DY&3-FFB4#*]D[?=,Y@.<C3$D)*5S;H9OFU10)JO
M/89(-KA@&37@S8UMDI>_S:_I4\VK;'J\M"K.`Z@R1Q3$9Q7N-U>5/`N5J^+\
MXNS-_H5="N7<9!HCJX\PS$E&PBVK"[?KZ*^ZN=DQ`3_@=KW6'X^N0=!2,F.5
M#!RTD)4($@#HEG0>3U67X&98TEIJ5"N[DYCN%_OCVS@!KWJY(B%>`&J@57B$
M`9KVP)H`F>6#[`([F\">KK!SF_%U_WASAP0.;SA@.Z_^=VDAESSV&^Z@ZZLX
M\W#=>WA\\>)0;J-GST2K";;B;']R>/QV[^CP9>_TY!`NE7ORUYNNJ'\ZX#]"
MT@8Y]6J+/31H.@(J?7#6[?8.#M]U7V)\(RG5`RW!>RW4I7PD14KT25*6P6C.
M1`5V!6T_:UKX_,*[5MBOI7*5?I`@"#_UX5D8`-;`_=AG<1D/)FWY(A$HY:^Q
MX%``,(EXIX*B)=,5ZTIB,1D2B9.4?P(7W;?]H59S6B2,S0G(KK4A_ZJMNJAL
M;VVR(=5#:KUA9V;\'8"0;?<KYX\@/52?M,4\.,;V#HY.]BXH`)9\\[*[?[1W
M9B^;'E(D46*E@,U=X1#@MD!;8QT>'[Y^\QJK_"3K6U#VNT='YST$@F0V=0,$
M'`2_+PWC!>P]_$576.H2Q;Z'D2]VK3M6TR6Q=L4WJ^2@>V&/)WLD<DG3C=%5
MCJ6,NNE!(%0:>XGG1^FJ##8FI4"/RG*ME:WRR%)2>6N86.#=>?<"9T64Y$/=
M*W5_))\9:Q%]8>W-)=^Q_9\'7#<B>RTS6U1H-1.D!^H3;>%.$]@#N:J:;F0H
M]2?1)=QEPOU=F^;;3]V6=\UFX8NTMY+E.3G#=1?->[Q._(N_TI/25"\B2>K4
MJB'C:0G5=L-F/DI!EC14+@#]5.['\W-1FE:)K3(@C+4Q8J$EN81&8TOBH;&Y
M9=N$?@-B]D(>D(67P$,3,[;-L"D#F%!<CN:,*S)$I./Y.Q472,VZ^!O>(#QU
M;=LA;DX?+WIK)-*F;1^Q/3EPO9:8A)EV>\B.P%U(R9@^P[(:*6KF/KX%V@%?
MXBM1"K=2%A7_CA>V9:VA=>P9O6,+]D0TP"ILCN-1;F:J20AW5!9KHB2Y$5Z,
M<A4>O^J=RV][K[K4N9&D9-K>(PL71?;5%VT@@UUE"9EG@7=;%:NR1HUJK*HJ
MUA2-H\GU_$9N+R#$.+Q=KP01=GR?7E9DY>@$%:7KC$NVA=!&\QA+"MBM.D7]
M8BMSGDT3YXS$:92-R3#N5K&9$A\`]9<"L_.K-EZ$L\14(),W:PA5,74/EZD^
M6M*'LZEG+VC"8-79?Q"P)G1B6Q">*8.,G$6TZ^Z1R>*V!VA,++->GK\_:B-=
M?O!,O(,JI8\S68&L./JSZP4L,%'Z<=*?2V#3*DX=;%,%J%Q6:V3_A^[^GWL2
M=6`R.IJKQ[H/LH7,B6!8V'W8"=ETP2[I3Y6IP+.DQOR7[MG)*7>+1WT;W<)R
M*?$:J8IZU>KJFKO%J;F`I:)!-0`!8V9<NL\44I^($@P4A!4IE/PD19*3@UX3
MR8&V6TSUY+^7=X6IV`LIG7R,^)H[=K85RW-L"6MM+J!BV$G`*6BW<(NA*SW6
M0G7)]Q#+!L3"J)_<::E-$#;MH8(!G-IFIL^XH9Y(VMP0?_RC@QK<;,;PS=Y(
M+J%:NJ-Z<.2@[;C>8EI<!$V66(-W\E55^%OOX3?:Z%MLL`?>&&A#.4*Z)T:R
MNP1`?J]4N.-PVEAMP7D/7-6H*ABUOXQ^5=!X%DUQ-8<ONP=OCD4)W:%KUM%2
M%0?>8*KB//6DB?^!>?>CVADU@5HNL+M6FE[-AH"\R\@^ZAZ_NOAA_5$-;\PB
M.BA1)Q.AZ"O%K@N.FH@7[JA<Y"-%_,UT\RGJI@0C1&&YJN@U/K27D?U^US*<
M?BRG_E1/$IJ9X6)0#P*K9<DZ,?-M;Z+4L>,TP_TN^W/C3HLS(_:/.L1://ZY
M^'Q0&'2X9P;73Z&&@::K/"=PJ;8WN;/L(G0INB07Z&=F/<0K:KJ<\"9G`LZW
M4.`Z4<]@(^'CW<!DK?&+@L0`8$7C^5+"H#>7+$S;"[[\D?L!/_0.L\Y,>/F+
M?/=KL>V.P.Z[VY=W*&/+RR)5\9B/4=-3?_6E2?B#6T0VVNU-=))L;+6J#V\1
MF:W-4;8=/<NVPUH$^^KU`;^^EY8G!5QI?$1:5GM$JR)=!3W$\!T$'"DSNDC;
MV6AL6U<!DH%A2>82):B\<8`BIG3ZYJS[HOM*5#"6R70^,VQ(ODAR&1))4ET'
M\9Z@!>3X2R7'AZKQ,+A7HO*,K?S4\"2I1&P`&F5_U->><DNN"O;Z8F1MT-K:
MWM;(0JY/.%Q?4$=VW_51E9P3QBVY_+UP>:E$RAY?J)66X/$S?%R"U?FGH43G
M#<E$B)F-#EXH-5I;6]6MA]YU%7678^MVSG]^_>+DZ)'(WI'*M,JYOL9GJ.LI
MNO<(#&TX[=4.[5I\"Y71/(MJ^=SYU<#_\&PDG&V2.W>[WF&<*8)_?G%V>/P*
M-UYYUPI[$1A_A0Z"T#PF:JP<@#5K96;CB<\'3U_'+7^9NB$Q$\"H1#D<[KF`
M`W9'3FC:VJQ*Y`.BFBIBT#>Z4<#(;I-B=PH/K83+7M?*1)#GBW[>ZSBA*OK6
MP`&D78M!T<2/0@Y8JG24=S$0[*ID%\I:T\/";83<HZ>JXY&5=UG`S%]N46BY
M&>0(!L<^9K+)LB/)2=A<0!X`,^J2NF"P7LI%Z[R2K4[1]UO#@J=J6$_DZZMQ
M_SIQAJ<>:OZ(84.L6[]?JNRZ;+@73R.X,6GL(NXX62+&W9?<FRR`][5L'8Y"
M/]J6T(VB\M_5`"'"NQ2$X5KH&<K<-J<6:1G@(2\\<K?:AZ([[5MNM0_V\D7*
MB/V\WV[[8&\V1V=A-MJ'U#Y;=C%'"%NR_S+ZK[?@EVPIA0`E6W3?=H_5S9KK
MC$W=9N_%;[.07N-B_R?=`F<O)&7>;<\$=?5>2XG`Z+7D\"#T3O,@JL5SYU>=
M_@O)Y]J"A@D&FS5"*C74GB-Q03\,*8XK+W<E7I>*KEJ>'RT(!Y=M-K:T>OT+
M6(];C6]2_6,X(JW7ET\DU1Y-AOH)E;>O*YSGTUGTP7DN(8PF$-`1O);1T,>^
M,\#P,6>\3:;A;>)1ATF<1-$",E[I&;P?B?"1?7QRWNWR^OI?I&ND?Z,CCHQ+
M"Q]QE9S#\AZP'M0Z@&[&FXWM9K6Q`3&2MUHJ%A4&87JP"%WYO(+P`Z/E_3T@
MD6<R#\8A;ON@<UQP]D"R0/=MI"3?9]P'R;8^GI%!M^51">;6Z(^M0F:Y07Y*
M97*ZFM\LE%\?>Y?!T^O^[%*V7!O$XW%$NIG_7$S>ET&;BOZ'D,DB3I*19/EL
M!T7+LA8Z_4*EJB"URCJ1#B@+.303XBG!/'"'WS3*8I_]&2<FD`<RQ<QK+]`8
M&\F8CML`[TOL*"F,]UU\)5EA"I+6GYL\'8C$=2'.),E!13"$IT'5UW06*QAH
MLTA-/B;7(*-1YNLOOWV<.>7_(=C=1^))QQV;@N&M<;*TIH*ZWBR+PTDR!W\^
ML+S-F+8J18'1[!Y[*5@E5`<PO2=D,;(=80F947\V!O]1%9D;J[3*XJ<;A3'M
M'Z4J<KML6.BW:2$_XM!_LZ&V-AQ(`:(/:WLZ'=_MB#7O6IZ=1B<:^]K?4-E%
ML^7(Y`YCNCV6$+!H6RX71E-&OW2D.EQJ[T=DRV_-DM[]UW$\O+S#&1M=8<XM
MZ)>W$<`FF,-F1/T)+%N"@A%QR-<#EPB;M))ILVX"M[8*G5[EX#]V7`"[OK'J
ME\MRN!BP8T7>M*_X+9B17RGKG]"<<>\Q;`39D&O+:U4:(OS`/L:P96O'DD\_
M6S,10ZPAQ!-OU(G?C(H-4JBI4!-\WXQ>L'B/G#/W5%D1GDR;)!BZNY^=J!(Z
MLH4?TF(7&>?#XVY/:;0.7Y\>H<7+WL7A"3#4SL9;-=[4V(K6S`HA`IW`*"-X
M"Z/"V:@(BW:]NN+%_7@V`(*DJX!JO[9DS/>(Z!%J5ZRQ*N/=T;Z*<G%X+F4[
M`+/K<YSHG0NV#)!=#,/=,)O)EO2/CP^/3D4)BY7]N#H9P9?&.BA/*LP&P=GU
M`#C!JC08?*I`00R>W-)E%6!%`_^""'JRE6=9@5IV+1/A[MG9R5F/]+RO]BUC
MC0NDJ6Q,=QFA8YWMCZ4)*WI9`-)MPPL.)5]Z'`Y3*71`1<=`!`.4F>`*IG'H
M2Q"\'X'FLI^,!KUI&BKU\AZ@K3F3@@1'<5O'*$J[+IJ(U#"YUH0:8R))^#.P
M]PHUD`[00BO7BX1H-W8>$UCEW+4<;#K6H38+_,<_4N'KO++4'Q5GT,31@[]T
MY$PSI[K+:DLZN,2'QJ:&2EJ2D!W')VU1XQ$;'642B-D7;I5\$F1=9Y@8=*PY
M79N6B8I2VZJY%/%,B<:N>G::CM83"M@XI;D0STQHD*D.9:@UM"!G>N3R'C)^
M)F_@TG5WA%]"P@,X0L,3(M*&AJ<H=1J3#L'_':CQN]/CBS-MEK^$<BX[2*SV
M_#)E>Y_\KK3_?XG\_Q+Y(D3>[*P\(BY$-AJU^@O^'-JCR7_`3M4)QA;'+K6$
M/R!R)R_^0TY@'%?M\&I58_7N$VTST&IX$LI^1R5PT]'/*M@Q1R2]!X%T;:?]
M0*5?2S;O0^M@+`7)G>ZFW4@.6;-!+Z=L7T35H(DO9&KEOGKM6/'C\A_IT(Y*
M)$>!41Z`@YLJW6)^ZD,K55X9T\6<79<_CB;#^",GK5C,=/`>@(VFD&F2&8P'
M'0XJ;>_U4K%*%K7E/9#:W/9>*TA)PM0A:S3I,*ZYT5M5<%$5O35-8=*G>RZI
M(5-MAVJI96R4ZP^H?@[HA$\7LQ$F1Q>0W'HRD,1F&L%%>@PAKV;SFU0-Y0W=
M;',FJNW-CG;UE0/V3=ZTOV&6F5O^M<A5Z%KDBAT]PZYI5\JD3143*1,VWZ/I
MP)3,-&I3;IJ9U=GDIMEI;E>;#5%I0HXNR_$-0VFC_CL82]N-3`_-]E2`6"LZ
M_5>)"EDAGSG.:]8<J?VCD4CDZ+F`TN>'?^GR_L$^LV-5+_ITTY=\`>294S#R
M9EIMKA"GX06%KMN20<F)5VYV/%HYJ1M>Z-@@GM[!]:[Z7A7GYJMG7-;L;'6J
MVS"#G3JG4H$_-AG94?:/F@$@].R?O#X]/(*+YS?'^Z`*.R753UF9#%*Q##-!
M"*^:#<':?[^Y_J1+S$N!&WF7@JMT4@XD^]2'R(K/,DUA+?^:0IV8Y':B\@"0
M9'_]X4S85$?6B/EKNH2R5(52>FG(CEEO]+;>QK`7S?I&RTM&A+:=63[LJH@.
M4(XOTTM#O[=H%ZP)M[C5)F\`;9*LG-5M?^YW[+>-E8W98(:#-@YSL]6L-H!Z
M2<+.^8UX3J[AMDBLX0<<6BH]3KO1H>N[UY*@-;=K_[&8U+9;E&&133,D][1W
M<;A_+AJ=>IVSML[%*IW>J]I9%*[S*(OI.$X2N`>4<PZW`B*YDZ3DEJRP'"<#
M`@'>,JJ-7QGG%')S@"E=,;PEH@3#;#PV,LHS\5O]\ZZ3F(>^CH:?Y-(,*,[7
M3)M$C"JINJSW"+Z3<.D51<8XQ1A+0A*\V1W%'6+851)JD7WCZ"']V0@-SC[>
MQ(D.'@)<X?7H0S3AZ6M#=))*4RY3E<U0W_2Y//^:A,<P,(\/$WG3R^?/*#9%
MK)_*;BD%APEI3:%&=,@6"C"H$&2%=144A2;5AD%96?:BHLADX+%PT=M<,S]W
MW1(T-Y\P6T0\*%E(-576Z"0OK5EC8S"?:3>&FX4E'&[NUFYM61/P\?F1#>(7
MC99*!3QFS?SL`@=!T[O5KC:;,+^=5K6Y99&ASQQ32HH#$"_4R)@[U*!Y?$0+
M@(\Q.7?F%1DN]]YBE/;7_>O18`=-(.A/KI&5^]\\\.W'RI=IAG)%J(KN#M\5
MI3B;=XHW]+I36:$3!FCMREH?:2X69VT0LY*:N:AP]TVMWJ'L#'48SR2H@%=A
MHD3@L)8MM]2>4R_)SN:9.-I7G*M3U$V!@$1V!76-&3FTC"0ECPN6I1[GI+ZR
M):^*"_G(E-%%Q(K)S[%$BYXASJZH+9VI&=-:$(T#$[0D^[ZIK%&D^3[=5#C4
M/^0PJL.H]6#TLC`SS:]9CV9BHCT=73T%8JL":,-M\R5&856"^&7$=>$X_Q0-
M%L#][AV=7*`B#@-W\07X++JBT'ADMO%>LM6H]#/UY7D53V4=#(G&-]48D^]*
M\&I%IWX4UBL&P_Y$EIY0Z=IS-:%`U;@1[^IS5[\`?14NZ!+>B%KKF=[C/:JR
M!%<;BJF:,P4>XL6*(20KLAX&I\E*MT9M6TTA[73K+2DM5E8L+3TR0>(Z!AUQ
M?S2&E`J+60+N3"N*A"*-W<*X;I5FJ['E,'J<=88DN4G`IR/7T\:EP41H+4F"
M6D916K;<J3LM?_:Z8,79>>SV`9>#]3;=$P[P!G]:GL'&M[?JF`BYV>YT%.O@
M#_P+SI?_SXX-_Q@068?'UYX=PA4N[Z&)4P1DWA^#ON/^"KE=5V"EC19NL)+9
M8&8SIA6Q8A1\'HP</=]NL%%NTBY&80PI>YG1L]!:WY9+O`YK?;,.7UQISJSW
ME0)G20ZM^XU)"W#_\1C,=$?#43SO#7I@%SZ1"P_2-@VDL`-*)NPQE<\IQ0H0
M+%>,A#*TLJ;2>134*DQ],1C.[WJ1CDL<D##=JK?!+0VH3:<IY<V6):@@MJX'
ME&8/DK$J=VG*=J#?\%/LGYKQ$`0NQWHI5]1SFK$\L[VFK#=V<T%(5EG=9.;(
MDALI1?4X0JS<*HLDJS2763I:!Z)3&L7N4!4JQ;>0_M#58PN4'<O-NH:X9"->
MR@`!/EF0@UK*?8<3Y*0.%AAZT<^"VT_F2L])X1A&\@C]U)-$$*.-V+9<A8Z"
M\',Y`!"=?VDTMWZU7$9N^Y^<QL'1F"7>7#@4<\KJ&J9I2@\#E()?;.`!Z+%`
M/1-KJ8V>;E'[!O[`86LP""7<'(UF@\5H'B^("<6(H=0\Y#>S53#362R'>)LP
M81XN;J<J&K2V*(Z&6AV12/*'R1.>4HRH3Y\^V1B07:@U&)1J!$T8R4@8K6*]
M*I!0HX8)3D;@8`,=D.UA!G'[<LJJ\4=)Y?_Q#QM;SU-SJ\X962Y_C1@HOP(M
M3TT.\S3F@%RVAD'8\WMCG=5>1E;A3GJE4F"+4+WBPPH:[,!?H24FGEE=M._&
ME4[>78XJQ1ELE00T>L;D0<XOK(>:D++-L"\P;=R=:[-*6\?:$BJ:<*())K\@
M/L-[:$JCC:Y7V'UFRL:3'MTWHYJS]ME(H32(7PJ2B5]W`_D:X?)GWO,@.IY)
MV!FZ/_3"")EVG>IE.["07IMNF5]&OZ[[N'/L'=+%;8PN*>KAN1#@(B7#<V)5
M4K8.#HKEM_<I#`=)L6;]*;TAMC!5\_`%Q!L28@;N^@/4/'1:I&^_%+'+TX?<
ME'6^3&?^M3:%1Y6%9HLR9.`;<QWK;1XP@;%C28ODOS"S<0&I@VRZ_U1<1KE!
M<P%99R=/1%"(4P1:SRKGKBTT?ER=./#\&O9:ANOE_]HUJ61UOME[M$O;K7##
MO#O]EC_;$8+$`:95ETR:SMJ@*#!H`YRM0VE"-8F&!+)9*V\-_`EIWZP!ZR>E
M(:ZMDL>5U,U"%@C+Q@:#24F>&)E(M;]EWW'C:.Z32"$Q`6%"BI,OZ/YG-).T
MXCHV"2\F0^U+%/+,X"#RZ-,S\2NBB8;QS:'D)Y'Q72/)IM'9K+:V0+!I-ZH-
M*_XO62I270ZS7_-S[2)&[YEC-XN@R6I/_.2YA@38VL*4@OBFC+EX3>Y>9=K*
MZQC3^N:G149QL)1?2@)1UC36LEV*E8=#0/;XS5A)D>YKO3$TW(K0"U9M5[GH
MK+6*RI!)&@4.<2.JMLL1<-%%U^XX3CD!]Q""SX(G':(UFPQE;<9P[FZA_]:X
M<R89=U;KC;)&AW+L)%<ZG20935`M0]<5G0W;3-3*DAS=:TPJU"0HBK%&.HMG
MPA-:Z:;RI\ADKEQ5'5HE9S9*%()":17<XBC!#@A$DIV[HXP=I'T:1N-H'M'E
M-)O9@@GR9`:I)F\P^Q'Z$SII-#F'HV"-^CI)SS?]Z32";$F+>0SYW>BVM)^8
M+N%^X,XQ!&5&@MI"2<X^]N\2E='B"LD>N#3:\AITARO#XYZK_*2+!'B/VLCN
M>>_HY.24U9%5<RT;4E;*!4UYJLO+WBMXXORG;O=4;K:#P^.]H\._=&G!RE;*
MW[X+9UV[>;Q(14K>;&%:8$G)MUNV'5?@N+1"&,.!Z5RSTR&I'#[,:<D')ZY1
M_LX*H_P(JMF'9>"D]!YST&MZP[O%!#<\%5?]T3BQQ'1]UG'^)&`=5,8N3FO!
M!$*6'<V$SQM_KXFY$_21"?KC[H]N/,4?(1IE.9/"I^)!`C%Z%P[.:!'Z"08.
MA0MUHKPY1\"I`V+9(?"D],$<+$RP7.HOVW4HJ#L-<#SX"78<LRK_KQ*T/K3"
ML2^KGAU*7?94*;78/2@0&CEPX.GS*A6B_(.J$ICZ\-%D>NJ:HN&I%("_Y'#B
M\^1#J!N%CY/068+/S5YR)I7U'6@20W>]X@A,.)/^:+@CZ7V\$,E-?TQ)>.#M
MWP:UR_[@?2*)TDUM%EW+??,4<\3JC)X<>OH6<XH!PN?S$1-LI%/MC59U&VQ^
M-K<ZU48GEU"EC/D<S8..I$.;(E6X=UH"DU#Q5\!`%O/TI(2%K)UA`/,^2@$F
ML%F[+!O>WLN7AV``N'>$9#P#,)$ZI/=V4*`7<N/]^<M"CWXFM4Z6S5\`\6B5
MEX=L,MMC!'\%;A'.0^'3`,O'85XRGL]+T\+DWIO;N*1\2QP%42,3SHF,&WF3
MO(HQ2E45FM_!4XP/S"B9DH.@J<8HI&I4:1B+W\0[>N%5W'42H=4H<&0MOP_W
MFNJ<;MUCLO.,!T364K#:(ON!K+60'SC4[!R<+XJ;(0^8**7#H[FFX'YY&X?#
M_WW]SB%`#[5U+&CY>R<S(&5:K<DH^;`,(Q\>""$?'A(?'PJB(R=H8!9&5(S&
M;)1P`*ROQPDGF'L@I%C0T"T;#U8D,#8'-(]N=U=63`'\LP-TS2&S##IK^*7D
MF07"J(Y_-H=<-VXAAV3ES4Q^%#YUR]/5Z?M(8=;GX&/K0GNY:)=$ZE,PYAJN
MD]_R7>1.HYF4G1/+`@]=X4S&OXD4C.$R\:Y&ZEG5$Y)+/!3?WB%CY^'U]HXQ
M"^^40OW5?H^*G'*9LFV$J&@;<?;')[W3DY.C<ZCO94#L_?1#]U@6N.@='LM1
M+0DB1YTPQ-L%CV/R<K!11EM%8`N;AOT?8BLW-\D1H%5OM."+4F0:0Z_]&.(!
M\4KCNS]SI+[;WV.[*<6HIRW':D[=K&T9M`U35DH!N[-*"*IEVQJV[E+^(Y:1
M'EI1Y(Q0Q5N&ZIH'\*&0:.9#*7D)G]XI$9:L%/]("KP'-S0,C(&FWAL#K8#M
M%J^`5EO'V,Z[39![_"6;&]@93R^E5#.98&YMZL4EF;_V)W<4[@GX)),C)Z27
M!_L"*4-=19P55*"K*Y#4$?J%<&HKHYE/76.4RBA&*?U9L>K\0->E[I-7;IQ_
MDR#6:)1K%CFBX2HL`(08%";*:T(.;Z[S`;$\C%?!UQ-(=<N[*'!!\P32:%F!
M\)YP#=IXZ&J0NIC9)2Z.4X8KBR',4HUO<05LU:5$V805T&ZQ,Q!?K'B#O8S&
M\4<I2V'L*2=I:DJDB&,>/PFT91V58`U2E46W<HK!)6$672W&?MZEZ.XI1DV;
M\R*0A:)9-!FH<&A#]VY&H!$)).&./LEUC:6XYPQ`];\$2BK.9(Z7/<Q2E"F<
M''11'DL<SHO*,02CTD:CMZ=@51J_YTBOM+PI978BXH\3RM<""EYU0:D3NW":
M<U8:\.%HH.-0`#3NK?'H@QH"!0650R"U')Z#$Y48&)%"`0YY9RE>B58GP\#W
M5YBL>*XV`WDT$U3(222?#Q<L(#N-*$0@_I7N<`3AW#!;_1U;^J#2G<]C2'D=
M?\"5`K&^QQ^T'A%3'>KFR^NLMR\ZUZEYYAE66G-KFG.F-GM2E?X^?VK=2=46
MU\K=RZ:<:LUQ$#E!`1C@ZU,.VZ?ZA%N3MV5S`Y,$M^J=[>I6*,4H_#W),(%4
MQL5!2FZGG>2X\2$-]Q,_<9_6;]OMAJPJ@P6#!I9+BYKQU#+'H[0[->V]JDB@
M/;J06LR)GA-PZPS-)FMY[,ETVE%:("<ZP9+3/+AJ6`/B-Z2/!ZTBL9"3@J)D
MZ\SN:N$[#XHB*#84%0#Q9414)((\8<"#TM64WN0<T!C=,XE\C3A4MK;T\R0\
M[4ONB,+X5*<7^:QYV*UMS,_3:M0;?'PQ1L\61.2&H^1]`H2)=SS=6ZA3`9QM
MY%"!V!IB0]U2%5640KL^;!!B3[_I1=;+-Z]/[8LL'NI?(,-7O'`R%D[CF8ZK
M"[;9F'N>]<GM^F:[VI9(:VYM5GT/0^Q[]JB*C,N8[]]W@*=G)Q=R;[AN/BP&
ML&LTOI&<CV1]Q_T[DJA,25-D.HNO1F.RNKZ*_7*(AF9]J]H![K?=[(!%!R&"
MHZ/V.#HJ3[4QY;!3_BVSVPS9[(U2MGTI0SSP+["\0\BB-=?$[K&*L10LF6%B
M1VX,NAGG?@930,K-*WYI=CJ_.O<P9#-'.2(Y+TV^7>KH5TI@0[<TYK9.'GOP
MI03OW*N>!$."0J[,Q555K/XAJ?%)L%H5Z=+H8R./#Q1M>C=]>2!3Q7PT2XE[
M;*P83M[W[R#V!XQ`OEC,#+$8W$02)$S^WXCJUC!U>@W<=\>C?O)4V3?`U$+W
M?I'#JD%.W&?B:?)4V<JD!A4EI+6P!K6B;\N"-=(5#!;"Z\JWVO3F_)[H\Z!9
M&+S_T.,)#D:%D"V,@8QZQ1&1MP>^&!\V4`[!^!6X`1)^'YQXY;]R+.[V4*`^
M+S_NE"<JP@R1M,J*I$^A4A85"Y3ADSDP<\:#WR=8E4QB%3Z3B$"I,RZ+1O'[
M!Z`7UFD:6AN5E0+D@F'@V@A4R"J?GBJ%8)M&5%8R%T].95XU7S2Z\,Y>.LC<
M:MEC#9"!>P_9W?45MJOX<@RX^WCIR(/%[SD$9[-_4:=31_/2?F?5*-AUF[!4
M0J^<::&1&1)6)E[NA[W]/_=.>J\AHHRYHENE+U8/%1$,]8U+TSY;K;J>?RII
MF7QE]6,9))[2$"2?+'LC^,`#^'"?_G_([OZ'^_3^0W;G/RSON[H56:4O17O/
M(F.P^WP=6+#_"E)H``S)'4&VTL`=&9M-K.)GT7&1#B$X++(A*3@JAA,:%,'Q
MQI1GPR'\D9'.J@HAGN!+C6V*O2%F;.I5,#BKL6:LA@JA&MV3R(HLG&ULHXS:
MWDP'X[+_EGG;JHZ@$D:R%ZF!!*R#5E,ZI:+C2E54T\B#DH)W!P=E$N06A4/3
M"!$O`@-/&W*Y<VM4)QD-DL+-&F:&:G')^%E9F#&E$'^B!</?ZE3;><-78$)+
MUW'@YKG-V@$F,7MH9&E%XY(-9<"E1YAAE[E$`5J\O1`J4O[L/-DI,J0L=E:9
M'RU(B%C'&*1$;.-4D!0I2*%1,"1OP0;VZ23!K3E)BN_&B>*:_4;AE=]Y6J3;
M&]4M6*/;3:T;FT7S7^K@4WLP0,4Q1N0#&:&4ADG#*%=#]"JOGNH+WZ5#DXWE
M33JX*U=#JS"_9J#9YO)FG3/Q7LUZYS)?\F>/UD[5'&9=RU6C;PPUGP?!9A2M
MKH0Q0("81?F*KH0A^%WA9=?Z547I='&9BO]@JK0SJJ2HCUKR[>TMC)72VMAN
M,UTVIP7,[7+W=U&C4,>D(1TI'>G(]6C.]:3&X@$7YWS5XFCTJ^LJ+%`KSO2F
M9[O'4$Q&P8=1I]&N-F'0F_6V,7Z!P#!X[]<CC;FJ`S9#AY#%%6[%U(T8:.*!
M74*G!HGQ.[3'N8PP2,)=I.-L.Y7M*[5"`.S6W\K)O(TP<"8[@&%8>6,9H#M,
M]@$]"EC8^]B?3?`2$D-2"_8/XC6$14C)[;[`^\C`:Z17YO&2VRV"2-3&5*II
M6#[C8I7)YK*Q+C&Q=OE<*^2012I#8JJ4[AZ+7H$7']SGUH[)1'V=]UN'PH^U
M-IMMS09QZ>1R]EZY_$`6VWI]=T4.IY]`R(PDGF!TT'Z".68E.85,?VC2JP?^
M]O#LHK?W\N59[^W>V6'WG)>@VD6+T9"H`;K<-3O;.*O#Z')QK69]2@'#U4+2
MP6#M`6QNDM'(9F=31T^6J$T6EW+[/SDW9E+60]MKQWKL./2X-9"&@43?@S"]
MX=?!IO!-1GL$=$FCA(J,=\K2.0!79W-UZZFPPZD7WEV3?"^G\4K4:HO)Z&H4
M#9\UY7>*8@<WE+7:)/I8NP);SD\8+*76K*_7:Y?-C5H\&UU_G\P&W].%Z_K`
M+^&\?%2KU9:#6#GOSR%AM&C51;.QT^GL-+=%8WM[XU&E4LF%OW*QB,1_+,9"
M;(OZ]DYC<T=26*Q)^5'!U*A"'RS9*:L2N(U5]BYH3_*W]Z/QN$:/GF*RQ1&Y
MFX)AB;)Q`0AHB#(<)>!KV9\9.YO!S6@\G$43LDCIC[4WIGPY(1*]+-T=M;Y:
MY9X%^1WOR)?;F`L+U'_I7RJQG9WLCJU!J0A05-4A-^S]Z@NO'P"FHJ`4:5,7
M]EL4.KQU][A[]NKP+UV<J8Z45^5,T0?,E$['Q/?ZEH.&!U2L78KL1%5N^R;N
MOT%!'C@5F)+X*6L0-3!WF]Y9#5Y6Q;L7;PX.P`;T+97L<53$A#D^JJ%@+JL@
MF,T"(\M+HH>-K:TMT%7@)\4#D$1"LG17:33)]N3D\H2:T2JZ@+1%4H8?N64P
M3.A-I=A#OVOPNS9=-83$KX"R+-%Q4PO%7]328%7:@_6M:@M"438:=0@XS/L0
M#3?.%Y-3R9#L/TW$U>A33>ZD&F3Q'$WDKKZ2#!*8ZI7ZXB,P+/)GK!^B`[3B
M>1,Z5Z[!M&DQN93\?O0!G:PQ?MBEW*04:,L.(RYQ(\^M'DU`#[)P'Y7&H"2N
MRIY$XV$/%<;*N!WMZ.W08;W#`[2V?ME]\>:56D#,>^`=3$^2BX^0Q?50RHAR
M&>];EO3/)##ZGUJ-P9J?JX[]O?K3&1:>E-3<R9TB!2P(2[]N=;XJ-K81B`]#
MLDQO]XYZ^V_.SB3M43@X.#G[:>_LI:PAZN+S+K9=":/KQ=[YX;Y"%[#I-M+`
MIN)Z-)!L5AE!.,@KA"FJYN**KM*(V9,<Q]&;KNIP[_!E%3J-0==HN!B;\!YX
M4AV&8?]5R=-RY!_ZLYY=5Y1HT++*$]5;\H&`6K;W@\A"7?Y*HTV;A>G<>7.G
M`.Z8C`-6H`N]UWNO#.3,V?L?M_3MI6!JWW,MU)RU\&"3JF<&3U%W;FEJEB^R
M_W^G%`>RC*9]RQG-Z5!JLQ:9T");]G_L]/[3]FWA679VK^UY2%Q2IU-M0H20
M1KL-*9^`2Y)2]LN3?0C%PDX8QB1^#D^32?_Z6CX%`83FABUQ(>>U9'\>0>0%
M,+<')JDVC`<HT&5S0?+7WINCB_/_892#AYW'![G+Z79Q"]J1P$(R.;WTTBKO
MYC!2"N/%.:I_1X:J<D_L^<@KR%HM6[ZI_1S&?NZJ*,YE:>#_DZEV]M;*I==?
ML,&6D.ZOGNI,ZBTFB_=1#Q7NA*ID'(,?@:]4<%.A_E=_JI09H)*W]0BD*Z"G
M6E?`FA/7$_W\Z.2B]*F\<EE[#E%`2P!4"=UH<"]/D\U6U0H<"*&7[)L*K>N]
M0Y])2[,C/L;@JS2XB=]'%,F0?2C<88%FH+CVA3.&IW0P:;B@UOAZN&G=CMO?
M#/5.NIK;G4RMD%`IF#!#UI.45N?AM*XW>5K1FT):UYN5BYN%^`^Y!<6&:&SO
M-#9V6LU"6M>;E=?QA+2N6Z+1WFEM[#0[1NO:J&]C-L^Z,CUQD`E(XCNWC."!
M*I!GQ2[CIM=0181./(7A[Z@PZ(=NXO&0H][%$O1H(FE%HJ+K\:R"I@FLR7C'
MJ%QU39/%X3.J^EYVY5EYIK6V2IM63>DV-5O%>CVY-U4R$E'Z9)2I;CVKVGGW
M0M6$M/7XP*H_K:;K4/E3:(I*GEI-6>5>[?>LHO)7;FF*CF!&0;]30[%KG!RG
M*JE'@7H5C517\YR%VDH(M50U#[657-0>60`LW%8"N+5[Z>*LDH^S5!_M&CDX
M"]2S#@`E%AZ^[?9.Y>F@$Q/)[V1A7B[37FQMT69L;:D,1$@JZ3A@!:X*'-#K
M72?1L-]+>CUYYO[5*?I$O92%>SUY-M[.Y<$K7^#9+0DRA.\DY@(B<985M>R+
MDMQ5PJF-XA96K614+74_S>$^3O(@N5`0B`#?Z]L!)-NTZ@D?;E57G\YG,(0`
M1(+&78)GJD-.N5V%E[^R5GX3TWG*STW&L21(4W3G%=0RQ/;\"`$)^K/+T7S6
MGXVD>+:^OB[0XQ=2@"5PTW0)I[,\;63I-:1L3.[@2%`72!XMFD'D1+)1<(-]
MG.&+"[)XR-QO!:L+^^:W]Z[[>F__7+%+/_2@9U]_L'&2U*RC3;]><KCI<O:E
MHCS>ZJV=YK+CS=3-/>#:F%JKW7&/MW"(M\!QYYYVX_L<=_"GXZ.C#2ID@QA&
MT_D-OV4`V,]-BK@`'Z10L#G0@#W$9!)SM,U2[I@D-UL.GXQ?$@!/D^A4+E[_
M_`Q`_VOFROZ"KE26=,6BR<&N"$,NE[3EGOF!UC*._U2SS@GL9WSVF8*\VI(C
M"`/P6(7<'N#)%<1=BA'('\EQ'J@`6Q&`5BF*88\+R`,5QE":-\B%L0Q)!&XI
MF&(X(F"9O:+$P127M+&YT<'`TZ`]%(UZ0PSC`5[)@G7?YF8'?V-H#,E40$GZ
MT6[*`VR$$>D[G>VO/P@@\(L$GF%8HM_F'P.Z&`HYK_MW8"`B)1SY7[N3?PJX
M5>$0D-2SOK4C_VMN6+8EFTU,L(@?)"Z`-]/YFQ<0R@LT!>Q'K@T,I5!X.^5T
MVL_DTI,EJ6#M.;TR[DE.2;#AZ=$C"+*DJREG(X[`;U6"E'&_/<!,W/1GDC7(
MF@GU=LE,J&(KYU+4W)O.A-@4S?I.J[/3J2^9"5TUU\IGNU7=%A7\UTO]!@"(
MN>EA5NQ>]/<%W`!8YZ"CEJ'8V7B<EDU2-'W@@B])&N9-/[EQXW13]CL+TE*[
M'P!:0Z`U!+I:3;53T!8H54UO:15>`BUVT+;(G%;U='N$*Z=4<.@A^R(Z]:`T
M,I"]+I3.,3>"HC4L6NMF#3]M@G2/H>J*.0/593*&Z9LT90W2Z`>M-4&"0KL.
M2CGZR%FJ#[I('W9Y.C-S[R6IS,7L)_7,)8;3X@^EP'(KM-#<@>0MKHQ.!Y=+
M1I>7+)W\1;.)<6?H0X6=0>OW682VLF]!]YS<3>;]3]1H8GSI'TONC10#4-CX
MOXK'SE,U70SQW?X/>V>]"\CXS44H@P?;SZMCC7JW0;W;4-H%2E2J-')8`^XJ
MV0!52KQG&*\+9&,=NP?C_-BQ+72W(1)[F=)LPW/G(>4)30]_Z0@HQ2AZ#<,8
M-AJ=ZH:HP(<ZR:/)XM:>1KP*0UMEOD:9QSW_-::JT\:!@,=2>+K%&KL>+-%N
M^ZO$&"^:IMFP<)ZEG'9*PF*=UYY3TG@YG%W%M,#(G@F#,PHI>OZSI`#O2(^T
MT4;[S(VV\9'DS'(\W"A[O$09OW#43%9U`*\T"HA(*T1$RS&A*XATH)WM#0ZE
M0UM['M6>CZ,/T;CY"[I_P-W)A_Z8+EDV-IJX;CK;ULZ4521C]2^!#/%PB*#-
MOK'=P@%O&9]2ED&LW1:/A^Z"\[>C70"73BZ^?H_-0@T6W"_`)JLMHW;/+N=U
M:6QVFFB/N]E6[@G*'I=YURR#7+=3;!']^LU1-ZN8F5CV_ZAH0VJL)CPK7;"=
MOHXE\T*UP497/6)&$RUT'TQ&"&OM]-MB,L*-+ZU)J6N)(X"IFE;96=)::PL2
MJ%7@@Y:N@[N0)BO%7"[G;<-ZJ/L"$D8+90BR9,;.?@;)'M7MCE+L?O`]S5.J
MA2S%D[\0;:V/"R.M=LJN"UJG4'5?Z92&(!D,3Z,20%9:3Y0")+>;H]>[)S8K
M!;'I*YG2_<A%9T#%E(9P#Y3DC)@H/L8Q(N8-GHXD5Y7<8.Q5"M4:)8/^%",7
M`V(X+&D>JO*3-UHZ\`(7OG*@AQ.=)PW8.[S:Q1!)$"]>SMK'2/PGQ`)&3Q_P
M+9"2T?8&"=?D<+*-NO'.EM*-F_L-H`F<5#&'+&2MC$*D(*=R:/LOV?B9T+(V
M>X%M'MS@.5L[:U/G;^>T\M@9<\[^#:J+W<HA/;%5/W/G9Z,S8[<7V>?!';YT
M;Z?UQ@'\!`<15!6'\9-1W[IN]B2#TF!>%B7XE]@A$A$H/JJ^9@[C\"')@*W3
MZ">#T>B7XS>O>WOG^X>'.-3S7Q^"OZ%4B5DZ4/5V"7^CBI%*N3\1HB'JC9UZ
M7?XGF93->C9_XU8%;;3D;YH[C=9.IVWXFWJU+MG0ZF8#N5`X"E["U(U4:%8T
M>^DGHX%.3`D,_[LN-+B.PL)^/+VC3)JE_;($O-6IPK\;^.\6_+O=Q'];^&\;
M*V&0Y//X:OX1+,L.XL5DV*?;L,/)(`QWNP->7^+U""*VWR40,S^W-+:V(5Y$
M$_'3:'*]#IDE4;6`\R8_IY(!A"'JP3RJT%=XB6&$$^[@KKB+%QC^'\.ZRF/M
M<C%'341_,OQ>XN,VENOE3CYX5)$CD>L-T"9/F%MM.O3J^(UX)24\R,UYNK@<
MH\)F$$T2=):>PI/D!@RU[Z#XHTH6@G8%7YG(PS2!.9*X!0FL/X<^SD0\Q0L:
M<+]^5!GWYZ:D-T`SCJ&*MGX33\E!#D:&X=4O,;'PU6)<Q2CC/QU>_'#RYN)1
M9>_X9_'3WMG9WO'%S[N8U1."^X+'.9VNM^0#*_L^ZT_F=X"$U]TSN;>.)3$X
M/#J\^%EV6@[R\.*X*P^X@Y,SL2=.]\XN#O??R`-0G+XY.STY[ZX+<<[YCK/Q
M]ZARA3,@T32,YI`\$D?Z,V:Y,U'?Y>Z-1A#NO8_NE,OGY5&ECRI13*%*>-L5
M"7<'U]#^R>G/A\>O9"\/KR`N@N0>9B-(I!`_JD"A_$5>%9UM<1%A=,;3,81R
MJ,D%#O5;+5`3OHB3.91]O2?JS4:C46NTZIM5\>9\C]+85'"WGM]-!K!N%E/L
MZ(XX.#^0"W^]*7?>ZX4$W5RO`QH7EQ!48(ZQX040-XAC3YHTVI#G!^L&ZMY"
MSN@LN1E-=R@AJ[B()Y,[*6$-DVBR(_N/IJ#BK5Y:5/6[T60P7@PC\<=!/+D:
M7:_?/+<>KLHU/EV_6=5RZP][;[N]\Q^.#E_8I9*;\>B2BBF)M?)_H%L/^2<'
MM9:K@7[;GXU(*UCD#^$]Y)^:":18'W1?Y`^,O0!+'K-^R/V5C/N*6E.FWL.7
M3]$J"'_A[&G[1LX(3$D8)"$5[U1.&F8U88&KH^.F#-F!(X2@NH`]F`XQLX`&
MI>/:RTFE+F"N<DY@T#/]0/"8IX.S*M`I#^]75M9(DS(:)K]P_-.7Y[WSP[]T
M(58J%Z53>V7E1RP[W64L'8!"&/4RZX,=<4QA)R0^,-@B(B:>).#E.X0`\/+;
M@+8QA(T1UP/L"OF_"#)1.CR^6.$Z/2S>NQZ$&]M?S'`GH2>Q0)V?FAWP0X?=
M88.7@L?*"D6S,"5V\U_W(#FGG&G9"[*XPYX\]);(W1$O#\^`U2..[_R?L"%P
M/WS#(1^?''-BIL)C_G<?LOH[^B?/,N1'OY&<A.X'G)XJK`,R*_+4NJ2\)@F1
ME&&4#&8C9'WD>R0UAHA5*8,))&+A0]\`NXTDXW`'1*T_!+F?`G=<C2C)"N:$
M0`Z8VD+22QP:A\,1Q(FN"R^',J=!1RC1IZFD69`K1G)B((@@?;"SME]&<V#4
MWD\@A8L#F'(]Z/A%?J9F=9!*+J9'[XSTYO>H#N?I>'3%^3N'HC3#,-#E["I-
MJ@.\4%:1+7-*F],:]2S*68182Q+#()F%`"TZ26<T.-LIIA)("U\RAX184_D8
M//ENC3[Y>OINTK\=#>3`4'E.`;8-D-ZAY+E6UH!)S8BU'1(DR41`5L-/65'I
M:)IP6'3/CDN<:A&)L\G3!\W4GA,0N@V05?>5AH>:4F49!!1YHJ(&,U1(FX#"
MV1QM,.G.@5#R/=YRNN77U5E*X;OV=,JCZQ&D&HJ&CYG98QL@[B;Z:8DGT,$W
MY]V#LY,7F'?QO*S#F$-<\3%.):>P49FS2-:P\S:M$_,"_]U"LH\^\)O`]C/Q
MH/0IU-^DUS!IE@C%=/$*]RT\,I7]A#:("DNG;JQR"^$-'`#%TI]IX.==G7U/
M<3]J%9EU``4Y<.QSN:[H5,;@5[S*=NT2G(X&XU!9CQ4G-*3H9O8;$!'\AZ/)
MAU$R`F;+!S2=Q7.B)?0&1T(^=R"N./=2Z5VC-H1:;H\S<I\`SS::]"A2->6A
MT9$'(:B,TQ#EF==Y4C)`XA97(?URNLW00CL>=C8"X%&X%&!ES=(!:9L69*=&
MNU],!7+H`,]</8]67'T%+4!$/%>I=#2%(!`6/@%&'<E#^!VB3(T%]OJ2G:XV
M.I(%M:LP[B/O)2NC@20&QS&I2OCECCY;D<R;@QHE@O%H\MY.<FC%HM1'+4)C
M^F&2$'@(!K@]3FP&W[5]BL)3@8#ZB#?&"_QA7\UU<KJI-3`GT>&E0)9507G5
MI7().U.N\2_X(:D&V%56=.C]`*V"<KJ/4XP]&E^NJ<VB46T=J2KAXSRN76IL
M*N(;0+J%:`Q*-H^O(]0B&0S[]_B%.HE7_90J3M:\PJ6Q<A4Z'$N4X*)L<%(9
MZ2&NA$Y]M>^?7*E#K2H:6/J*;7)4L_)#X^FS/9V91P@.!F.&NJLGMQ@V%2AM
M;P[3'6OBWJ"\S'GTY.8$+Z'$0GV1Q5IP/L(@TSD'B@+$*6*HG]6@&.^A\>]J
M+@$+R;-?\K2L,:.L:YI6:`2H/0OOM`%*-FZMR==H7HKDY2BNU79#10.HJQ%1
M)58"K<$LYNCP"JX0WTO.!JX/5=(/W%V8DY87-43V$TG4ERRXEA/@3Q?NJR2!
M1LLRB&<S>`"-6\S2E3X5+)K^YV[W%%*='AV>7Y3%DR=!A%J4/'B`2=$.+.:$
MQ8UZ<^T0C]T2['RL@DW2$?98SAKQ%)(55>#L'6S38!@,4Q'5])4_WRNYD[U2
M<*97[C7-%F7Y;*TYFNSA:`@>[Y+)&V+44YZW>*+/,UH#+.SQ-!HV&`73&8P=
M@*'W/-\^FV2<N%[TT6K+4!H.T/I12.IRU\ICQ+F9>=[,_K%'*T!Y40;/NXH^
MYM2F+)OS*I^B8PV'J&L,,WY!:)G3EL%<C(`;RM[JT)`2A"-FS;&ZQ^`NT,2N
MK[NS2JA(DQPE>0DZK^3!Q4>854;5LIEWN[;+Z'LB@&$7>7AY!"LO$4ZELILN
MXF2RJNB5BV9KGAK3><WZ`PP5PNZ9BD_TM9!ZS21S.:)9#VY\2JOJ_>1:_"'A
M+?^'8?FOD]6J(*I$83!L;B8$/:7C1-[71(#!\+^8.T,7+`"DK.0]HYLPV<^-
MO*[ED4<56BEJ=9&,`FGO<X4.V#^^0J(L:V7+!D+)#SZC9'=+"$<]3C,.PDI0
M:BU_N9CC2TS6ZKF/Z`(4<8[7I&O')Q=KH!5@@;AO;^4==87IX'JDI`'.WXTV
MWG;&\`2(Y'`$M'-\!UHX0@?ZW8)9SV4\O]$@($V#$33,928GC%WWZ,!C#HRB
M$'NJ<*H'=F&D%CL,.J4C4QFE/:!I.@%&0JPO4:>Y4>*D"8Q2X@"RU7XWBAU?
MI`O*[;QE41C,+0A!<YPEO%:VUQ5I`2U8*6'3ZL_C%#W4Q"-;)>)(IRKW=3GT
M1!T<=;V][RG;@A*+G9GE8O6G\?'CQ_K$]!C.?*ZWB$#P`)PJ'P`%.-7*<D[5
M<!HUF],8#NWMPZ*Y=8!FH-ME.VT]05YKE(T06OC8G\PC%9..[^UCN*%>80XZ
MPI@'0!X@Q!**O$'ZNL[<=A^XJ4M(\D97?R/[CC(Q%P.P#C[T9W>VSH%V(RMB
MGNGX4<'VRC87"[F=:03^Q8,G^:CUQ5O*VD7W7GO?5!S5*_">:U`ST9#_0-WN
MS"F\A7TKLTA4WGF^##%'/.?%UERO=:.,0(`NTVZ&`!KK#MV&]_3.8119$RT/
M)(2CU-:3!._+:<U]FA,/;VZ_=64YT7@DJ:7S^:LY/!9%<S@\6S;)2769PRH2
M'EQ.,:"4MC@CM>`Y6PVCS'6C2&ML39@#Y*5*:W``2TAEQ[6P_)5W-8YM@(1^
M;^:%9^PGH@1@1'4+>Q(OZ8";4-.62&E<BNPE[0E/1`Z*Z!3A!X?'>T>'?^GN
MI-Y`=O0=FP"C/(A(N^F#JD3;3%AX0Q()_%*D%O@-[HX8(O_1(G?DN]1Y2?PN
M;T!('_-^-]UG2;1-S\XB2.]RKP.*UI.2>O+6G!&"[G5F9Q*XNDM:,@;(>=MW
M+$2E6^9"W9=,F\H>\M1Z4FLXA5.S]P]0W74-!^<L7ES?H'@.K*W6W>JI)HJ6
MK`L@5A-9AP=LU\0M:6G.J?`LHBMIB@"$017@D!O'\91A4!0AHT+"QF.G_9F(
M!X/%;(;F,9J]IJP5JB.1^`0]*)45B92M]Y$:2E1<CRAJ[%4?KA;14/!V(3?)
M.)+K.NE?*3"U&N`],'1/X:6C&LTBM%*3DAY:,R*0&"4'-?L0B:V/E]DP1$G5
M1Z#[E_BZ!47,,"ZC0?\`K0"C?C(:*S"0P6@PBS[2?;YD-&#TBHVG=8KGDMW<
MNKXR)4J![`D,9U6-9U7K>'!/@^:XRFR&7(K367R)V05`&N%^#*-Q-(\<8P`=
M20,O0=A@2PT8R_25T@>;X?-*Y0SI+^;Q+3#E."?,XU!_`,WX38E:RG<-":D<
M_L?^7<*6"ZRO)9[)Q'V$SG#E@(;'P="!;,V8<&28;^#\S*+:`+):1=:A[&QR
MQ`2&(0%LR6&!*\F=D$2:)H!]A&N<I`:B)ZD^BME"741#,@BED?-`HWQ(ZB7Y
M!0JHY<;%M,=Q`AFZ[1L6B,(UNKZYC!>0+@LGBSQ=H)!:;60^,J4%C?LUQDMT
M"Q.:[1"HG6#3U6LP-U^H^>HK2Q'%#=7BJYK9)?(H!D^].U$3AVC,N^Y<\A<D
MM,6NVAR%P8@?9E[)LC`%6F*^25EZ([-"ERW"NGEA):.EN_SB.RO2,>=H;\(7
M5BFAEWB'E2!;L)+%%;!/NJ,>$"I]R:Y^GZV40.A$WL/2-+Y<)CFOX'FU8LZO
ME1!+0#[Y!^[YHXQ.H)O+>_GF&,JH$K:^:D7+I6F$J-I?KC];87;F/T#E`F'U
MK`&`IM!6T3,AX''=0_A:R6%-6/9:L:5O#=UH&5U\Y$P)\X\KOI8%\94SW0V&
M'89J6*/`P@3#`MV0-C_QERMX,,F)$"4,$8+<^)$*.N*,CCFG$G-/=I_TS>UG
MBY]SM18Y)A_Y5UB:!&7P[WD<//RI579X3!D$3T[U989/.=2`(7A'<!<+?X/D
M;.)2[AXN.VC3RG+#CF8S^4P[U7U<R:><KOE4>9>N]78]LNG?E4CQ#F__=GGL
M2X>>0QDLNO`X1!@RM]!GNB(\40>\T?!I!J^$1[VSS*7`4UX7)XL9[="^LF>7
M/)5D1IE0>!HN`6<I.DA`%>1N)9@JJ9ZT6CM]$8@W=3HWP[H#8#".I)0W=(&`
M<`B('<6+!)GS:,),*O%C*QY)62<W5U2`@2;\8^0+$(J/1WJ'5\@>DHT]499Z
M3TV$7D,\^7Q*6W-(Y=2%KE.,ECD*%[V&*&52\W*(0N0L=4O2_KK=Z]'87")K
M;C^7[T57'OVJ/MZ77!<DUAZISAF8NK=%Z=<.0Z1U1K#L<PP2'T3KDWXD97?(
MIOA,_#@9C;]()11DFP^/WQZ>'[XXZBHM@;I1M)KYLNE$D<6:46T(ZDP@E#)S
MF#V#4$ZC@'-%R^+TB`K@='+OZ;G2^7T[AZNTORE)JZNX%%:#=7XOAZMT*"T.
MZH4]<B.KL3[35V3N.@;M*@18H+X?F2TO^AABHJJ,AP*:JE04,BIIM9Y*L%FO
M6CN.%GP@DE@E8_P4#*Z03E<>QNPD-;Y3ZLM=5!.AB@5E;ZT;D6SXY#IB9:.[
MKSY;7225=!9RA:%L_`!+@D0G&3]23%,@"MC6JI\9E^T\"9H,?@VQ4M!O[[+N
M\GV[?])DRHZOK*Q<+JY^:=;KOUK$B3``7`U@CZES-)L!<[>*+RFW)9?0Q_]W
M?_Q#`@8;]4]_^/1\M4HLA--W[F)9&7#8QARJSV\.7Z9[K.VFL?DK#,U?%:O<
MX&JU:#,T=/2H[0TX92@#LV>3G368K_?)NJV?E]N&W-CXT'5!EU;9QVTU!#^E
M5Y;`M(M8!CSC0E88)&_\#("*RUX*[G,`_SS3R^>N(,[3N]'U]U3&,[9CCI0Y
M>L-1\CZ1['?^KG.8A;*C1P)RHB^,J;P<BFM`4:I;VB!M,8%&B?Y36=#U-BV[
MQEZJ7/*+7_-78Y:AK3M<FS6ZM6%5WB7<W9"?NJ/-54:AWA#R+@BU[7I6<>>R
MT#9T5X:Y1A^K^D*M`TU1H!Y47[BD%,L"4/*K-(O%[+UMI2*V[-HJ[!%.016L
ML,.F]=1C%1[B(8SGOU`1Z<Z1IY!<R394=*0G"V%&O:J+H5!&6'4--!V53(;6
MI8AFALIPF]8\FN?+G;^,W:8%S;XS]##!]Q0N0GBD+N?L&:.^C+3U;8#NY!()
MOJ%,$1[]@NQ,ZIJJ2B[P#43/I4&BSD`2[@-+EJJ*<^=7`_^KRXX^JIRQDQ:9
MZ^"%A+V2F<=.IM$`0]L0]<,(#B0.E)1HYDE3^'A726P4%XC#4S%_J8@,LVV.
M\$>'/L/6(_W&WLW:]*?8W^_BW6P.-@E>=Z@4Y"H%<I4Y)R6N'S397!D-#8D_
MCN=:UV5</GFMXD1TSQVA])%SO8VL[&.S][`32EY4!YVV19_`-E#666Q9-1EZ
MENAZ@W!L.'/:$-_\3#SA(O)G,.6@<4R#G9.;A'(W3::(0$/-@\.S\PM4A?;4
MN;\KD`T8Q(O)/+XR)WX97D`H4Z83J!`R6UUN[K)FNCP,AN%I>T7+2-2%MQM`
ML&U;8Q*5N1C/QR=?\#(N(&H,['ZX8@:^$RQHS=UPSP:XY/9%(>8+G`?`68YY
MIQP_@A`_N%;.,=%W\Q\Z`IAPUC-;L'IO+-J,^PEG/<^3P>6?+5^&+[3S=$S\
MBQCY6W@,+/LP_AR/6\<&X/?!H3E%M0MCWUJ[9DW[ARD=GQ:I\YS<TTX5YVBP
M!1X/DN9-!G=D6TKQ:-B8:SQ8^`%SV)C4-?&ZCRC)1WC`I,A5F1>6);\:H"M)
MWL_.BMO.,1;?]<JF/8^UP:S'T993=8N.T36[B?5,&INH()>-)E`6JP[L=J8P
MLL(2B^4?E@_\F:![NF:]O25JJ>@8-:%IF^<7O(YNP66^1@_8TE-OG;M0:QLA
M%39;"/0EM,;9;@^/3LWK47!GLOMBR&PZ1'A1;(B<9]F)\1A3U[I^\(&(77P@
M4FC]MP-2\?4P>I>)%Y%AF4D:;.()45GG4AD$TNL/ASUUP:?5;YXSCR__&NH#
MY.>+17D5Z4"1'L0]8AX11%;!?6.T1=,@I<2W\24$O;MC<QZX?617$;`_Q]%)
MKF`TU@4Q%A]%9($ZR<A$T\+ZZ`PS_S@:Z",?@5Q%'W5$QCG;XJG`+F2\9UHP
M-M+L)(@0:%4DZP,.Q45*G(RE\/O>W;P?+X;74?HYM)U^*CMN:4`?OY5D[@12
M)ZGQNE:;^5<XV#V]6#$B".O>M89='_:-T`F+2MC%;'1UATFN+3**B'LF;OOO
MHYXL(?\A5#*K_V)QI1).6JI5*TR`)%+C:*(ZS_FLC:^DTPNW-:6W*])2H!5'
M`L9U`FPS<WXE4M."2MZX/%@JN?Z<,EZ3!BSA!)9`@C]&'$%S.HL2B)C63YBW
MI;)6-`)]NT4+P[_B\C@2AP+`1N9QJUSD[TZ/+\X4K++3Z_,0N62NA(BFZM*!
MI*PE^:PJ&(XB1HHR4':2H3;OG<2S6\EA:^N\1-G=\FI*P$06[_7YDI:VM5Q#
MO$D!W1(>X#NX01<3>XL6"/<2V"AZAV3J_+YHI]1#.\7?PSHFC]^Z4OZ;M04V
M$?>>IQ\7DTL(N>G.U#?5.!AV%^GY\K_?1>-@!=;B$Z,7@RNP1.KX3N69H*5B
M)9!06\SR`-$I*OC<<:IF'!R>=,$EK703\`:33."75;O0XE(*[4]L31=UZ,%B
M,V?DGE!OB\5FOOGRV,PW?FSFK9WF5BHV\W:GK6(SP]D:W4KBJ048YH_4E$@.
M)"<TLPK!7*5PRE\2A/E_`RK_;T#E_UD!E8\QPH0=(%E%8U3YK)5&]8>>B9,8
M>O?MHWE*07$6#Q>#8L?/[Q7-<T\N?$Q)JJ@36D7.KOL3M';M)\:KJ=L?W-@F
MBNCHAI0H^M1'SR3P2&'A]4(S`81T]G6);V]CL/D$KQ[8P1R-%Z%X?C0,Z1'Q
M&N"Q$D$'""B%XY1<&_498`\AO&\,?H^W*DF($LA4Z@Z(.$)G*+!Q;-!C'F+4
MY82"C,*MS`)('@(8N;3=:,6PHQ3A]#+2Y,`]!E0OM!RJ:>6^EB=)"]9'T9$X
M/!9235/@389P@#>?72^@#<6WZKL*+9^""R*M=G*298E4S9@Y!>"'P:L24V4O
M\6Q$\]:^ZOI0DEYT1,)JDWA2`VUD6;G'H.5L7R1P#XC\XS6H794$C-YP``W"
MP`ZC3TK6Q=,#+Q[,181L/I[AT1)3[)Z01E([6V&XAF0:3X8N(\^K,)Y@>'5M
M2M![<7AQ#@%*<*@(@9V4Z>*-/)$F)E#U:)ZXHU#Z_9'CK6SBJ"K7*NJ`@32-
M$XH=J5D"PF1S;<WIW+JDSG*`-`.J;'^<Q"K,CIH/:D!BC!:&'XO7#?E-<12N
MP95"1:/3;H:V^H*JV(Q\58S6HW5R^I:G3LW9F9*8<!QF<=8]/>N>JQRCYP*I
MH%EO@#S`))P4)LR]%CH]ODE.WT\WHP&YM'F%Y"POP'C:LP'OW\*U#H!`DF8/
M2AE?`[Y<8.1[SLH<-Y9VU82:1B#Z,>#33#(1QBMV)60*Z3?"4ZUH!<\/'N%L
M\,VHNL#]/!@AP]._!"KT$?`0Q@$[:/I!I]!L%MB^V>BV/[N#-"%@3S*QEW9_
MD@Z"(,'8M)@X(=G3:^8:[@RCP2Z)3&<5.@*SM2YX9'O`G=U5\5\QEC3,WAO6
M*R(@ZCB`B"Z7RE*'=RNVF@H#OJ[<MHU]/W)*<N].1+O6$1\E4>%@]V#427VH
M`@.([6I#QS5J#*/D]-7(Y'(D5UV>R:0_&E8I(17-$G3:3(/A]S5WJ5<,XT/V
M%O`IN5B<1(JLP"M0_DZ-KVJC'TY`II]]9<V$Y'<<XPZ08WTON_`A'G]0Z0#(
M?A-IY&T,;E=2)H"-;IT(DH.C,&>/W3XRW;'--G6\-*2\T'4B',JI`SA`XY,Z
M-UD-;`-:U!W;*_\JE@3L(SK1@Y$)>;JJ3<,'O28=UH)/[6E:W!.K[@U$.XQ1
M#<<;)D7'O%#ZAGY=6%N;"(;>>^HA\2PT>-T;64;Y;1,C,8'SST:C/L_6`XVL
MP;I<0^]M=7*3-VY5>2<CVS`81#IFRAV'J:,9F]Q9)P(01>8@DG@P<O)$W*[[
M@X?V1T,Y!C)%L:,[S77B"4OE\PZS2%'ORS37ZYG88_\:)"WD("R,@S"/9,8Q
M*A$$!X.?4TC;=>=8`1YE_C'VY6UEP0>T<$?Q([0RP&Q+LJSRISW[Z;P"60N@
M9'G\$"LJN["*N9A658Y25?A/?\+H)PZ+J^.JP/U#7X?3YW/6*36,L1!/)T+Q
M[-!H^X.9V&0>6D0I_VXBHE:(?DZ8(1FYO102[&L2&-@U"08Z.0TQ!12I_Q;F
M40G(+K5893WR*A\IB;6VZ&!TUU?AM?4JO7R\HYA($H48D*,8T#4TIA74P6+Z
MI`TG#E"><WCKK-@D'AX9&#K1@G2(=;H\4B0!;.XQ:`%&.YB]5S=EZL1UR"8=
M)A"RI::Y=Q6X'54M(_)*'\:XG--+OV^=HK[U*O(!Q"5!A^()ZTR`9=+3!\@8
M\;T[^.WO(,]<&T3C<8)Y\V35!!AFQ6QA37*>(5I^?G%V>/RJ7%475W9A*LB6
MS605!!H;POL'V=MX%BC/@$DO+A>FE/19VK+B,23VKL*QTHH?C]Y#)`(*O4&G
MWI"B6.N@!XH#7B#IM8C`T;V(O\VH*!$!-HL^Q1&`WE.PP92E^"@Q9`BWE!7L
M8N+M<;5&3?`'6J#J$EF?(=SCC/0<1@PP49PL"=0V/:$6N;SV7;0.:MX4&A.Z
M23X"4Q&C)('6)S>3=(RMHD,.IJ)/X!%@;S88S?4L7DQYU^I0V7)FP6Y=2.G_
M"NYV*"[)4(6HTLD]K-M6G#TFIW)]S.P\)654,TJY<_1A-%Q@L`X:!,.[8F5$
M2K*X!>%*C7*`R4,^1J0G3*)TI"Q4MMPP'Y<.E($,/(T(+J!Y"U#@&8J`0GBA
MN<I*PH*T1,=#P1@9R/&C2ZOF[6!7\9E.R:30(`)9!F([31@.$CPL]-CYE'B%
MH*T/*3+Z5B0<\)2;Q6.]6%0&LUK*YL62Q?MS9SP`CW8V0%VW(3@.P`X`.]ZS
ML?FWA7E:DADAS41ISNDRZ.J0G*70;&!7L5`L%L"@J_YD1D-W2QH'83)P7B\[
MXW`O]MR1:*$\8L$"60CD`#$7)_8!(J)$F-%-Y_F`8K.(U[)L_`Z\H?DH1E42
MR9$(FK:%)*+B9-K_^R(*=TX-R.F>9\K,B@ILGI879\_@D6`G*3/7.@8HU<YH
M&#&I+W>290R$!M4(AB1B'/_,L:F&+#;RX1BNFZR^])51]<!E^FLAA[T"(V(B
M=RN),\*9PK4#F+7-@8PGT1Q]N_IT9\QGC7(8YW`\+*M2"18IR4,]0N$MH1D8
M^2(M!,M@09ZLDN09RNH?8]MR)86$Q<Q1`>A)1@,>B=/^T+B85`FC)&$8AF]*
MTK_3EF##%8SN?$4BA]Y2Q`=-&#A>R6@-H"/G:263X7[3DJ-XYWA;!D\W2T3I
M)^H`+;D,(_@/6U8*9#1<0O-#.U4>R:<,_535=KIM)>M+GWQK0&K7E*Q,14,,
M.YW=Z>-\77SWW7<7K^4_XE`N`<`H+@&6_"0#V(<X29K>R*7_]X5DFV%FJ\9I
M4YYQMPF3R%D?SD=FL*_D\E^,YZ2^<ET[&9+LMA1=X7Y&KQ8BB4\&FN&&&P-%
M@&`-0$E)*0'_ES%&1)(O?%4'"M>HA9=\(D@9W9]('VNQ66KP.^(EY,JRU0\0
M>]23W?6B(;6VV2*6R2K.!^EF27Q*B4Z!.>`F*3.8.NQ4D#,F`KA2,-_N8L)B
M`ISD:GK''.&8)AHOVVTYX2D5?`I[=9&HZ.GJ+&0#R*LX5F*#,B3R'*T</QYQ
M@HP06<NNK],-L8J';TT"G+""CUB#^K3D:VLXK2!UJ6,:R!=U6SNMY*6$T]<Y
MWH%.VD!::Z4R,,/T3N*;&4V2G4ALI@87E\B`*-9^<+.8O#=DVDK(X,6PL^.T
M@<R`$?/HD$1U803[9(2W*Z`X5)T"NA*9*S`FV-,^Q/4BP;(/*^5C1*QH;&I2
M,#08@&9$AXO(MOF\BC[*R3-B7`H1M&?Q"L!JB#0]$)./V?4[N6SGL[XRVDI4
MZ#VKW]`LIL"88[*9&_!$\=EIP->K?4G]9],8C4D4]R/Y#!2<U>T]'=*LL>/5
M"\<$,H\6SU,+K3!<)JA#MBMI<LM*"15'$%6;N$K@$A&U?ZST3S%K5[[8)0+4
M:/_-V5GW^$*YW+CBGJ6&1)VJ"F^G>0R^=,.[LI29!T)A0PMQ.H[`['NA'`Y&
M"0%AYKL_GJ,J_HXBAUHV(KHO3U&;^)2IB7U'A=*]&[[8OEY4JXMRA`?O)3CT
MY<0("&;DJ('Q+M$2I<6\E(+K^T@%[D4RR,344=P\-3;Z3[7,2H>XMHE38Y5'
MU,HOVGK_5Q')W3`TJ2.,"LE5J0HQP6IZMG^%ZY,Q1.J!+KDW.)*(8F%>F;_2
M:>4+VT:$X6'HA6SDJ(6D$I_$:NGJLKRZRP*>*L;\A>)ER]2*3P85[97'PXK\
MNY`XDA_G2/Y70-@C9->^P1\VM,HJTE79"S)9/)S,RRLK1!Q605EA7NW+7^;=
MY6A>(U4.E,`"+T;SWEM\M+(R!BP9*#6\[M4E`53O`A[)DGZIFL3@[&XU5;37
MA>=V><D\.R#E;P,O!O57C?)V:F#XL'>.#TW)<3RKH9V<%.!-4?FT=\A/35G0
MFT5#K;<SQ>E%[X!?.!B06\ET5/Y862&*L0HF168,7?CEX.ZJ/S!8.Y`_]/BN
M),-M:A[`+[>FI*&I01W(AZDQ78_OIC<:TBOXI5M!_6X*S"$\3<'!7`YF-;S&
MGTZ?8A0M=0F2-&6)E7,2)E@$00&1I4:[(KG>.I5[\ON\``#)]8*XK)L^I=]Z
MG#-0&.I%BD7.X!$O4BZ5W`")D=VXU(#.0;+28!1'9+!PKIZ8,JA<-07PIUP0
MWUN(`EM+4T+^<-`HWTIJ/8P_VD7HB6D%M;*F`/[T6IG'\7C>'[^OW8(FX5J/
M_(*?]U[3<P53EY_V(>SI)%7^E)ZK\AYY4*3!Z<.GFCR:XL7,6N;O>F?\2(_F
M<@'ZM54*NG(%R+0VY*T\T&J7BQ&$<)5%^$F/GU@E)TE,-(B_&BB@\X+[<GBI
MOO>(*S=EH@\CZB5],[4A63CM8OJVXLP6/:OU%Y]&XU$?"1L]ZNE'+B"YW:YB
M4PI^F5T_DT<'M(1?3!=N^LF-)K'ZAQH"%WH?W=WVIU""OIGJ>"@;"D5.S6:]
M1GV@H"MC^@K?5I"?5*R1G7*2]UL\74QK@$JHB+]Z\&O%7DN7DN)+$7:.5)0?
M].A!JAR#4J4<6!^C_GM%&U;@!VJ-S&N]5]0><=_4Y'*X&ETO9GTBZ/2TYSS-
M'[$ZM%?T28BKE$C]9.5/]I:L(;-48S?JU960<[6[B;D&K?P:<+YCKQJ]ZN$K
M$:H+!+&&CB!>3?0$QA?!-C](44>NT,2KI1Y#'1S]MT^.[IE>HXO)GN3ML_]^
M+W-*%"1)CV3;/7K&9&`%H,-4K(/9+RMX!@LS"M2F<(IQ-N5SC,16&LWT&PJ3
M(TJ-/_[1*5SF_OV$W&L?<MA.X5Y:KN'Y?$S"Z71FXFC80<^-2OCPY5.6!_1-
MI38Q@VMP;6,QE)"TTB`)CB(C/L"*-:A`.`#1>O1/,-45ELYQ^=_OM[9LZ<RH
MN5"UQ)+T960IM&XC7G6.UC1E6*H%;#1IG.`%&LXMI_-A]2,K6N\L+3BI;]4%
M&'441#TY?Q!_RG'D9>68BCIG=,!D#.IHUQV1=MW1./9UY@,K>,;(\K?MX6%'
MJ]2U^,2MQZZ6@$6&`\H.WP!3E%K-/^.;1@?KE8TM`77$5I@+HT>5B(TF>$&'
MFG;8110)'^Z^;G4Z$#>EF_:+W7%[K`)7X14!*=$G0S1:2.!RE&X^82Z5+A2L
M`2``+??**.$^C/KN]:XH\;V#N#A[TRW#=:>JS-H8N"E*P=&U#O:.SKMH+V)*
MIP)7V<D4*.Z^3N<%'7*CXH808R=UW^%49+QV0+Z`F?'72@@,)[JS(.PMQZD2
M<WRDZDC0YFI-W6Y>+_K@`1)%YJ;.RZ;!,$"G1/N5S$[#W38QIZV>'Q1="Q3<
MN`]<(F<J75WGY@_4$_=R]G8TH<PZ[HD%722;059*,I2/8%WW,7HZ0W,W,$H;
MFC6@K%^@<;H),P#G)@TH7D;'Y)FDS2S5-QZ`[K_"V76D<FSPQ.)Q:JP"KR3'
MBXXG2:P<6\E(%>[%T(<SX9M_Z,%D-+]36<[X@B'1EOU7!E.HZD3U#ZU@U4FU
M1R9#S!'DO$/T@I_E1SL7D#?+T$3A";8O`M>D@+OF7:AR;YQKU0M=B_,=J[,;
MKX!P7)REU8)@J1/18AKN6.%&CU67!ID8(@_C8FL[7U:AJK=L?^-=L]E>JH?'
M;_%&N50.XTC'VEV&J)%U(.$N<Q*N:'=>8[TF`N:'Z@J5^X\(DJPN&/O[6:$,
MOK!T\"XYFJ\[>.%>L*&:T]TPJKANV*TW`V-FJ(2QS]XYO+N$IR`&880&>2KI
M#5[0*X20;4ZL-?4?^;(0/6CPUE+U%6)9*0S\!#3#N;Z5TOEHBJ%":!\[AY1O
M?V097]L]13L0'(ISP8K+6\[^X$8[*"G$(@RGL*OHA:[\?1$E:CE$:+Y$H[.9
M*1,,';J:"KGOF;Y\P,B%$QN`?/,]YZ^Q>3+%3(4C/"D>ZK_]V[@=<<K>^NP&
M@X'Z5%-.1$NU;((MK*SI:(.R&3DG.S9V750I0-F7DRJN)43X3-T?_N,?J:`R
M_B@T!R''@L&MUKYX2"I3N=,IKWT:JW&*`$KKM!K><1P:YC-%9&$)QE\F&'`'
M0M5GA.XJ9[Z1K[!NK0&QFQ7\5+0MSG@I2D]*ZKL)(/OHGR(Z6<$/EO[]7J+3
M`:E2^&)(.QI1U"EV^!Z8[%[&RH/F.C@G.-&9T8K8\SXGM*K>8A0C$)18OS1^
MU4N(Y2@%P<*B^8H%-1W/=%)4+.KE'?!)VDVR9&P)[^\F&4F1"`5]=GU$\RO*
M;*=][QPI$[;1<?=M]VQ-'W,0Z<#.8%95MY$(!CT`,%C.961N]/`B,DO6]$,T
M*D)YS-&`'#)!@4@H?/>:CF;CB*:'+WT*X[RC&$`#/KV423.Z5RC"H"Z*7>_,
M,`4Q5Z7RT&ZJWGBZ+;:I3#MPJ!Z>.Q:NAGP.=2C_)(,11<B27:@;1(R24,0C
MR7*]VD>YMAK@F<'\SK+\5PPR7=Y2/L0[86=0D?P\,$5R2<H36N4`!UZ#K<H&
M?2U%SEGR4Y8QNG/Q)-6N:W:'?NL6%+8:I,MJM$^<U":C,3J#&0-1S^,I5A8\
M6O0HD0G&0$66"78N^@2^!B.R:I0-<$A/;<D!%25"Y6:<H\80&1<V]Y?\G7@9
MHVD`AZ\&$S"Y$Q:#2*&6`VRPR&,)"9IMYQ%1DCM45+"B2,6]$F8=#2%YK.3R
M47I`P<R.U<^&)<IF1HV1@;`%W_&;HZ.J%'DE;R<[+L4B.3KE$P&XCM!:U61T
M=L+/4,H"3-\2RNE@83B0WB%WW<*"D&Q<,IHOR$ML1QLW@ON%F-Z`I4:LELFK
M_2KY'Y-Q&`OR0*(HU(1.VZ,RU_O>%PHIY$+;GQB"L+A5K<D&Y*Q,V6;*Y#1D
M#V,HZ8H/@7%1'&%+`DXB22:'QDO<L5?71FSDB`LN@@-&AVZH)IZJ=IX:,+)%
M)X</K4>=Z=%;"];N=54A9M/:XE1)"E=L45/6%CS"1LJZ92%($3#B0?$>Z[QA
MWZ+7D?$(3J^.DG:F=CQ'7!M:P:H$7&IE3^D.+K'')Q>IQ%':;TZ=H>@K:^=)
MU:[$RD-A'CNT&"4NN5JHF"7>IM"`JA"Z8H<T\;02[VQA=_F40,ZS0M.1`&]S
MI\/C!_'*#A*V1:ZF]WW+`\+W$T!+QY!98X+VV.;,<)S!%$-E3R-W%F9&*SHO
MT5I;JU+9>-O2:ADU(G@3V-;C:#\%Y9Y:BDZ&X]NQ`E$:3=ZK:EI[P_Z2*N^A
MHDB03Y%8!4>\9CM)*2T#TY$WDQ-O*E7*K$*SR<J)M/,44L&PRH9FUU+96SGJ
M"7VHED`<LIHFI(VQK>W1WMZ-U:P.)#AKP-1IC5.IET-1%N^71+TX4T6:55?7
M1Q[F\]CL:EQ>;!8ZIQ,%*Y<.3B1Y/CS_\_G>VZYV/5>Q.I2MLCZODZCL,%OL
M;X2VI/J<1@W?9#$5I6C]>ETI=34GI&U5:6\HWB"+&6`?2Y>R]!4Z#'/`!<!\
M&3]^VCL[/CQ^M2/`XAV5R2DU^\Q%J,$*F%;IG:R$'@N_1,B@@XC7U#JPD\HM
MR9V2.=%*$X396AS6%(B[(I#LX)12Q,Z3:'Q%9N4(()H9=U&$C+YM;^'28BA%
MW9Y<+Y+8*&4]1Y=!WR3$FCE*2?=-R8J4!&QQ'.Y$IMU1+/\-!7/7T$PX'/N+
M\9P)4(^[7BK#0L0?4NZVHF^E,<\U?&ZP<`(I-1U`[,R@,:B,S3]DKUBP\NM;
MB6&0V^K^:#2O)+^7UJ*_+_KC<BK95</MK'S2I$X.H^G\QETNP0[H"!L6%%H.
MRN06;'P4TN'`60-:N*;FZF_8L:?.6NS^B*R+\9JW;U:Y`BZV.^/5DMPHM2+>
MV["=[TSW`/KZ$<0A)5'$L_=I]31X6P*VH(8_J9QI34OA1C-]A<&BC*NJ4JSR
M"4SB(USD0+Q\N;343#N\<Q)I[T83E".^!.NO>9KJDK$HN6*M9T@J4G2%IM.3
M[B]066;77BMR:Q:MZ#[1Z0$5)$D,[]<%;PA3C-V8JFUE.[#5H;Y_N5*+@':<
M75JC3Q+@CFW3[U`R[=AKG_X!]U2@6(XO:AB*OI97-NR6%"0K)9QN-2)&VCKV
M@!SZ[O;)8DJQ_.0Z9P7!W/<E@3L;=74T@AB`KFNT$%TK&)J.1,`:AGJ&[MB+
M+NZ^E5Q(*,Z['4IWC7N!,3A]-9BZZUE;6Q.G*@(5,;@ZLX2**PMEC-;4LFO3
MT2J(K06B&)'?RX+XMO>2FAG6%G%![*UM^N/QWBLK]4_U>KVA(M&1[9%JT?-C
MQO/-<M(F`ZERJ@&'D:<&FEI'RN&P>"SJ5I%O8-A6F!0?'E37)9?`MA'LB;TE
M'J(%YE6IC:WL-OBP,%=]GNQ@O1@1379=190CJM</GV?&?C3JCJH9[V+2"F;%
M/E`4#P[-MT1)#+O#0,)07!CA)A2C0&M2O?LQBS=7*M^]A`@,RKX4D"6I*E<[
M='/$&"TV#K+OL"Q"&`SO%U(L!Z.NN[#^&4KF9;9&![^[?KET>'P!+=9<`T6#
MFGV03GV[VB67>[:0RY`6$Y@@]IWD:CHD.]T)&2$21ZGN\+T[55IJNMYQ;!^$
MRKG.4"K54_AS,,!53(XY"^@%GE!HXZ)LJ`Q$"V!V=HRUL4ZA1X4_HV$XI\PH
MB@.0,HNAX0=P8T3/^H&:+W.B>]D3+?N5.^(S5VQC,5:EEFPOTU0N]_*Z"H\+
MM9\"!7KJWMW[.A%C/QO$G;I9-:M&88TD6@I-OJ+N91*S0,]-QB#:`UZ:2!?1
MP35`B8)V`R7L1$*A]PH"GL/9`#)?J_KQI$>Z'SF2;#"I4H`0S'BD+RJ_M[@*
M<AFTV0ISJ<414EBHT6ZZCE]AXL9'Y%-L'%\OS&4\N%?;JF#VA-?VBM;MC=R;
MD\4MN<;#:4F\F`K\`5Z,HWF-7*;_]*<_>><@N2%*%L5YJMT)5U8:S@O>1BM@
MP!Q$BO*(#.A$51@?4C:9X\[ND:TT=3KE*[CM?MGJ^A7;M-K3VZVLM+C7AW)3
M(!,&YII]8WBKXMN`Z98Z[BDX@42_NCA0I"6<#8]?9N>X@U,DKL&E/#K#UH`>
MU*B$E^F*<]TK__:?.6`Y2,J8;HDNDCDMNUI)XSC6=RD<+-JV2/>Z1*2WO++R
MUT>582Q^6\&_OZ;/M5&OMZO>A`:.KZS:E.ZNU^.,I/*+G^46GV+Z4:IAY0K3
M(7)_D45^U>URNA5&DDE(;][_AL/Y;+KQ67?I,VC[Y3HM<9+(T"JPY+Z^Y>IO
M,2PJ)((2S5D"R%@A3"+9@6N-/LT:L4S'.$L!E:BZ%=>J_"5O`5&)$GT\V`)B
M9636IQKO2[P>AL@=QL,[&9&E)<(3.FPDW07WQ:M]Y@#A6$4@BEJ1\SA4TC&V
MM/T[U=.BVQ&4"LZ>VM+RN.53F=BL&<@K95<8L*=!Z[R!ELL/*9N;/>+M$KW(
M,K@U^9,V359!/P6Q+IV]__1;["`DW90]M%YX/8/]$DJ`E)N%3=>VLAKC1C:U
M%;OJ9356G1`\&J&KTA?.K<@(_*M:SB%:D=%6BKMTB`AB`SJ*V'$3%T/KE+JX
MUULST`/IBQ&234F<SGY>\9_Y3U32&;\<#A,711"77EYAC4M:1D)5Q$\7D:9S
M[OA3=G-8M[SKULD8:6I4SN\BU/3P6*XLEZ;RGKSR5"[$%E&P5!5G71_"FLV*
M6"OM\\VAS8QM%]C2/-BE-,#%,IQ")9X(.Y]S62'SFQHAA@W:KF8C##69]?=M
M_+?85-HV$68C-Z/LWW<CWB?F-+"F'LVRE0:3T\MIK:439-18\EF&?%9F.B\(
M.??0BLRIY3@Y_71M9$G"Z.LP`77M4,6]E"?*NK!"=\*-@ZZ*KE)8O*KO</M.
M!,>;T5QG_^`<A]VSLY.S'F6XAA!?^.V1Q<JI*2?NG8-,#WJ4&0T:[Y%(0"%$
MD!C@^@7_ZMG$1OL:,1[??4>U-6W@DN&DT,R?06)?IZ*L=WA\)+%O-2RBV2R>
M]1`;NK2KB.^A)CY<W9"<@G!4<8_\]CD%V;M7^X!14<+"$#--H\LFC*P7+UD(
M5%G<5&^9$-K-V.CE/OVHNOK==]/0#&I)*WL2:6?\$R;1-"S6OF06[?K_Y'FT
MN_([S:03Q$_/HS-Y_SM[/'N,*IC!4YJ'JG"Q4"[OZEK?8!(Y7'_ID^Q'>N8R
M:-BGL@/BO'NA&"WD,:8*5EF*1AD(T7DFL8:;9')J+^0PYK!6%N(L'@W[B5RI
M/*'AQB9XPO`A=,\SYMN3IP+S^N]`9>\_C"\@,0'`#]KQ(&JLKB_96*7PIOY$
M;CP%=E;^!J)U#[F:BRS\;^@UE'(W6<ZR_Q,9=IUAZS[\NJM\Y`$[Q`27`Z\*
MU$=4R2:^RM90U<D"?J&=3A4M:6#U%=B1A5>T>&8H[&^"EJ=6BE?)?*!JTVMV
MB9!+K5X5U#UEJ%85U%&T$JK:5>I5[[\5%^3G`*)\BG5O7%5MLO#[H"V-.-UK
M#W=?A+T@_BB!O<T+E`MBU"6>_Q[XU!E3\K&I%(H$FB]8OFQ]?CU^S[L_OND>
M[W>_'-%@@?I-T%T<X0^&\BRB0(-.M_<Y2*6UGW;`Q,\R9C!YNI2='U\HVBJS
MT/;H05I8N#8[_9()9'O!*IO_5=EXKPK_)/;$BM]O8BF'??'IM<H_Q"0[X!0^
MA$*(4!@1A))EN\X&5GSK_:Z3Z._1WW4J$0'WF4M3X6$FTX:W?#9#V]F&\'G%
M^Z-7SK3:+'YY!2Z=/#E//-/&4*4G`026=P4+@"S_?5.?^-<JX`6;CRGC^<R_
M?QIW:T)SZ$Y:Z0\`CH3R"FU@^Q/!D;9]LUDW.:!K;/CNR&'DQF`/;BZXX7?M
MN?K]:SFO.0AB)2#S_&@>R@9+AKJ40\*]%.$.H-(`)3$PX)="EFD8%&BR5]:3
MPCW!NQIR9[8;?;UW]N?N2YT2Z[3$\1EDP_RM]ISJ44MG!J5OR%B0FPR-1)8H
M`1[12V6M++\3$`C`:^%"I:/R^Z5ZI?N$^\OOE]QA#;V)^*9+MO$&/?*L5HY"
MS;PYOE=#=;\AR@0>D0<-B8AL/Y/3*`;/<58;^^^PQ837NIE\7I'6LV!_]B'+
M.IIA8N)9L/:-)X%]0RYY_0G:I9)ATE"[3,#]("=5-]%6K(!\[I`@L;ORW"L-
M$RG5)[-!V6:1;J/;@>Q62=_V"BA7%J(L*OI@Q4<Z1DAUA>]6A;!J`6"G#CP(
MU5$%UKA*+:-*V8F2`HYI>B2!08";GM>;[,X0<W#?_CSZIL=`Z@RPPQ;\"QX#
M_>OH>_LT,-TEBSLO7(I%'>^8RZXZ]#'.<2(+W%EC*IXR)_41)76M8:NT/)JL
M@.G<4%,W+E(@NYZ5-L8YHM3]-Y,KZDG)LS4U^CEXG]\9/B$\#)C$5TSY0B>&
MBOY%O?#/$8D@K[=?WAUED:@LO1YIFWVG8[9D=&HTF67A*N,_I53Q2XFX'6K)
M(>)^]F!%P=,4_@F.7NUQ[@*WW+W`QK3/!1D]A[J0V0,=M`XZ@1'JU#%B-[MN
M8M>!]0D6<TX0IS_:]^(+^F-BPD&'P/DCV!_C%?(,TMC*4EYWO-5BJ<H5;S<#
MDSC-XCB=#'!Y]E+0+);:V:#0QAA<#B.67L>?REBQG+J7LM)(HV?!*=.'/RG1
MB7):B!T^45AD-.UC:5G<8T:#&[\LP1@8(+'YS8$]L]_6_@][9ZER<)AYY2B)
MJE^2,@3X92DOJE^68NS[94MT0]:[ZD-."E'J]0X.C[J]7E7T>G"?"=]6WTPH
MC[$3[T:*KZL2\9;O^UJYC@(M@RX'**4U(2Y.<^A3"@C8Y#$,VTC/;417_Z8B
M7/#P)MG^FY[=&F<&0<RK`K-D&?&5OWW4-\AE(_;A4AC6[K*_WXNU`<.C'?#Y
MDBN;74SM)+1"=FY(]$MVMS90W24>:%W;0:W&X^$J%L:8GP`,8YY(&/(H&P(=
MH%NSJSA>IRJSJ)]`L"ZV@U+F33I>@5U%\5Q@TPJY5)79,9A&T?4Z63?WM8KS
M!IDS*X#;,+I<7-?B20V+8V"V9'$)<8X@0[R7=I?\MN%6C>FY]DVD'G!D:[)'
M)O_R,==A?P4:4XR!NSB6FQSWCXL1MC:.T:$!/;$IB>%@!K[CHRL5B&4ZC2;1
MD$:E8F#)LV0X@@QOF&L:[,8?D24:8.B97.1[DEJ@JS)9<!/ZB&2*DBRD',BL
M`$W@,"AAOE.E+""2JLD-LK@E?/*LP#)0?BC*Y[>$;N&R=[>CZQLTL?LXBR?7
M5<4RX40`LN>([2$[!ZOJ'%],N>C):;J&<#[<U0O"87^&^;-@E53%(285U5%N
M,I<)&]A-:JGE(N?B%%(X)LK1.KVB8(0G?T80I6LY&3/TV<0(*CA>#J&A<[*K
M5&N6PPJ%1D,0D&%T-)?G?]EROE%!_CB!HEKQ)3WX@_,#=A$=QIQ*DMW`,6EI
M+#M[JY?'V>MS"2DFY8+<J5%"SCX0#`V3S4,XAU%"UH>TKBF8AUS:?84SB%\_
MB\9W_@VLWHW^C;QCGD+&K0['*ZRBCM`J/LDUBPNEAX84&G$EV]R@*CX!\Z5J
MN2RA<7`:Q@,W?X+J[O')L>DQ)N\@@XWI+**`R-Q_W7L6H"3+]?B9J5"PYQJJ
MZ7:JW[J+#XS.H>1=>[\;/G\_9&;WNP@VO^&Y_=(-C`J[C+(&*OOR;WEN>YUQ
M$KU"[':==I,2():4!;.*'[T^(#^6H'$0*_2J%M\&1X?+3<&LLH!AI%>GBFO=
MQI7`L,:VR<&Z4R-Y.OYFI]!(8/W[97%UZ@9&96=S.56^W7HY75R.Y>)XJZ.I
M`/T]T.%9OC&?MP;I/'F=KMD!+-!=PH1\&5E)F_%\G?4GB6'D:8%!CAN,UPV_
M4NHM8.X40(2':3VMB^5T8ASELJ]"2/78U0/"62B3H`'VZ3*>W]#*3=F1K:R9
MBY%?E=+Y):T0N,NVY.Y4W373EU+XEE$!!V%A5T/`.%>J:@_S88S'MEDK7V@:
MU\Q@Q<7$KII14\^C2:9M3Z2.#6+=V_LJJE3$F31.*'*7EP@E'4-B37>K:--Z
MIE&_O*Q-]*;*;IBB0Y''U:-4)!8XD#Z,XD7B)%RA$*#.P%CV2+>L&+`7$"=R
M%ETMQF,KI[@)'\&)L-$E2?M4PM8PF6]T'$E(#3Q?(!>)\7_D(#"[+:1VEKR\
M?"SK19^F(S#D&W!^J0_1C+BXF_YL6)O'-8S*A0QJ8-Z<2(4<A,U$O0$EFN\^
M[29G]\`%+[V#D_*%T?[,S9W*$Q=T_<K8N:R"4;T$$)E;Q]AQ]MYU7^_MG_>4
M0_,//0`,\I^HU>1&A,7ZK"F_<\A@R6[7:G)AU\"I7GR*@!VO->OK]=IE<Z,6
MST;7WR>SP?>4_6[]9EV>L%XA__VC6JU6"-#*Q<U"_,=B(IIUT=C>:;=WVAOR
MR_;&HTJELJR5E9_DFO^/Q5@T-D6CL]-H[K0;5/G__E]1:S8ZU;:HP$>C+?[O
M_WTDOI/R570E?MA[V^V=@S/G(V%34'K^P]'A"Y6660>D^EL".3V?RCF\G/4Y
M#3EFHW^GPMLH(T^AO96<U@#J(^/`9#\T'7B]]V=^"H:OJA/8CN1V,-&H[@&%
MG.#\Y5?]P6@,&6SD2N(>N1<'&N[KEQVU4F1WA#?XB^[9:]7L;$'2WM\@D?13
M$,6N9_U;COT(0Y.[2DJ3DGN!HTV@%&8CQ$'&0ZP]L-ZJ?5J_R5H5ZOW2M:<*
MKIQ+B1_67J,C5]!.L[G3ZBQ=>[KR:TE:8.V)+=%H[[0V=IH;9NVU-C>J'5&A
M#UAZ`M-EQ[,AYU4'S"*),PHG$]>.E2K,T")5$,KS[?1D_X='-<W3GG7W3\Y>
M2OZOIW*F:N=X+W$J$(D,5KA09<&K1CS89$I^)P?)ZX-"$[D^X)F8(!78V*EO
M[G0V"TVCK'JQB(B`;(CZUDZKN5.W"$BCWJANB@I]P"02:^%09HQ#SO#"D<K3
M9X*"@P4HXF880B`J8DU9M-'$H[ZW^[I[?+%W<7AR+$HZI6U5\+?JHQJKZ85P
MNEMUVS:VEG8%7@Y<AM90VAQ2MKN?:A<@512@8@WKXJEF10C[-$NM)FPU^J"M
M!G(Y-3&3DC<$NB_C#F2M5VD57V)0S0F7T'S5=W]4<_&'1-0__>'3\U5`"/4)
M$H6C:4=):Q-EZ=ISTE7@T/4-VV(T!'05K&D9[HC2$PM.F08O@6"GY<@N%U=5
ML?K='_^0U,QD/P:6_N1(SLNAI..G"!UNA%9!][`J=@A5;4)5VZ`*_MR@KR0=
M`"CY>2RG&-<5@*MZ(58;T#7X^_RHENJ?PET()]F%\]$@CQBPB^D-U'485;=[
M!<4^TV`[C>JV'*S\V,+!_@8`[+VK)OJ9^'$R&N_B()QU)SEQ25J>*>9YP-'B
M2JXUJEZEM'%65L94KF=MFB60%3MK;@]YU>MZUP-Y`-._#5@0-<&6/[I3`V!'
MW_'<B=);AM+CT+L)QYZV[86*5<+5A^H-54QO7%@5NXI6;@*W)3\WJAM$+>]N
MDUY\96@;T+OR(PK^HBPX-3#D804&D(-,YW+VSS';FJI.FK,I(<4JY+SFFP'L
M4*->KW8:LD=`OYO;:KVC+OA\,3F5Z-Q_"G&D/M4@6;B.\G(5]='^H]1'M?)$
M_HSU0^2XB)Z]CQ)6Y1,AN8S&H^@#9M6XI70U?<BQ$:$H7[,L5]_NG?7T;CW9
MWSLJC<EF%T-0L4$KZ@%K='//A`^%]M[A0>_XY*+WLOOBS2NU.$+YHL5A3_8U
MZNTC'/I[)H'1_]02#=;\7.76W3\6MLKBB9HSRB[=0_OB=:OW5;&Q#5!\&.<_
MOWZ[=]0[[QZAA8+&`N?]E55$77SF<$49&'NQ=WZXKS!&`2A,RU6!>:N!#I`>
MU<9?(61942PTNG(S%5>AUZB`!+2QP=G]D*7Z#$/_JR+*<O0?^K.>4QDLCKC.
M$]7C,J%+.-8;F(+QBY8<;<U,A"^907<N4'DM\KK1>[WWR@`/S^/_R&U@+PE3
M_YYKHN9:]#S@S.K9@<,A,,$715;;_[<32P-93N6^Y;SF]RFU;PM-Z__HW;M\
MDEVR_J\YU<LV,E24/_?>'%V<_P_;Q3SL7";%G=3;Q2T(DH'9-`YL>G[+NU\Z
MOQD=*[B'[1G]'[V!<^8W]_3]5YIE9_M:6B66@#;:*.XWVBV6]\&7KP=W<`IU
MR3B&5&0!X=3-&_%?_2E*;A(5Y*9ABYTD6-KN&^JQM0393/W\Z.2B]*F\@J(]
M&)F4`+02V38WI:PN.]Q1,B3^]6=.?E`VJP-)"S,=.BJXCY2(\29^'ZUC=1"^
MTM(W")#W%^Q%6K(/P`:Y]T%@![0&;K^SU`:!BFZG,O4-I'&`=03JAM*3M$)@
M]^'4O[F:_()Z?*V(_P+U[S(=?FL+=?CX0>I?&Z>\'53(4IYGY0IB);[V@IIZ
M!1#E>`UC4EKHL.G4TM-$956ARQ2Z8-BL-AIPPR`_Z]B]SZ@72MT,:&5-2J=:
M,]8N1&30WD7?*%B:7*^J5=.HA2R[%PO$M!JHQ370](7*GMKM625?[??LPO)G
M?GDVDS'#H0?I,;F]25=3ST(U,RV*,C%="6+:MMW)PG0E'].^A5&JFHV]@)51
MNGP8@>FNE@.6B"$$AFI:QP(50J6UJ:V,Y[Z:TH#&/>.6B5[ETQ@J@U?4K_MW
M0FP#@9'_M9<0&*L>7BXUX'))_M?L6)=+FVW4E\J/1I/V+]U&/Y1-U/<YIOF'
M[`ZC#!"R_PC20_5)WQ[988Y$:97=<U;QE@N^.;=!]?0O03ZW<"N*E^R@CH4;
MC$>IZZ%FO4E6`/5_`IX%9#$I@N9OA&>X)($KF9M^80Q_CXG:9_T!Y'L&20`L
MM"<1F72#1;4`>Q4P>4*?RAF<5I.82L!%MTKS"("O%O/_`F4YQH-'6R,Y963U
M`E/5EG,D#]QV4UV:XXT-F_B_>7$F>:?%Y8R8+G9:4/,.UVJF1.WY[6@"5K:<
M*2!5&$KU5!FW;IEND`3UJ(D79FW-`F#"-3&!:KO9G</WX*[@]JG_J4<5*Z8(
M]83?>#W957>97/B99**/?Q;_^(?0#]X<=Z6P<-1]R1></%*ZSX(1;&PUX19L
M8WNKVMBRKD=MSS&\EG;KDPL9#D8%5CS2)V^L;[+-1'`:E1*S#XYK%Q0F'R23
M,HEO/G?MT(V.-UZDLZ7Z+3B>8"E',*RGH>-,BH>SAUV^W\%^XY^WW[VH:&P/
MP)?R:I.OU-UOZH=C]";+:P+0_30'`D"6C>#M$]].XPEF*96L*ERZH;T1[9FM
M)EX$;G6::L5]_B8S<$Y7PM#'M^0`F3\-WVP&Z*YZM<IF`/>9!1H3F?=EPJ>]
M*N'3E_O`)T1ESC,[DN)/PFY$6]B:[L:6)-<@M&]M=/BBG1410"D_1OWW>"O;
MP[!!2^Q;="Y4!<))%VH!PRRDZ4R7-HBEAC(`K0;05JL&<C6E;_+_4-M@RK/Q
MA`W`&,_4JSX"JMX@0K8VND2.M<U/T/DCO_-IBYN\CNJ21;KI6^;8G0S:YHBW
MH&?2Q9)=6&"O(@QK(,#1:S2XF3]^_%@=_HTM>5)MR'6TW6SHP]9U.T\6X[DV
MUA"6\*U;$6L?Q^(9S>$2_8L90%6K7AS,9T$/ZU`<?`CQ<5Q[CE5T=^D97A13
M*&[6>6TW-E%)M]WI\+"A+*;"D",&`#XB]1)]+,7AX\.C4RJI<]K(%\Y3M7(9
MW+N?NGL@<9U?<`G*E8$M,!?P&W>MU:"N;6QSUW@-L">?%"+!II\SP%&CHPFE
M594/P">RQE$/=%7)!42S*[1I5L<&&E>QH,^];BK+*>\90L$?Z`SZ\DR]DAU?
M4;WN;%.OMS<U0K%Q[)<>?$]NI)/]'6I=<,X*TPL@=.!3;K]U7XD5V:*`;2$7
M]G]"XH5Q!.;"E_'U(C&$$GEBO<BWR2ZT66^T<SOWY^[/_Z0.;C>I@ZUZ;@?)
M#.*?T479M0YU<;/EF+%!BA6S^MR%5M4BBXY-A8XXR!?I'6+\D#]&3SEUZRRZ
MC3]@QJ8YZY+MD9J-UL0`%H\I@0T%;^E!.F:U/NW4*,5K"<2/$"7C8*#V`N&B
MTR!<;&W_BU$/V;5-ZMJV(FP\%N61!57(*8+3F,MGU_W99?\Z6A?B#/".#N%V
MTEQ*)`SK#1"I1P#.,+S2X+GSD):OAX8E(R%*`_'@>2RXU"K-1D.=3;!FOX@,
MKF330!&B@V;_"/\%C>PW35LQQY"4**^N1N"*`]YKF&)%95C$=0$+";A0'M@6
M35*CJ2?)VI&7=Q'^?Z=6HDZ&\(Z+>R6%>5J]V+,`IOELM$GX+A4W2&\TMZAO
M&QL6TB'DP&P>CY)(UU</%(CKN&>5>6S]W'7&T/V1VZYJF/98PJ^Y$Y@>#MLC
M:]-F2^Y$T#.UY$YL-!P#2++[#5L_>BR'>?%!L^;VTT0+!+X)9>K933]5FY5K
MMJDEWKR*TI,?24`D<=$86>K7[Z.[CY)%DB7XV^I#W`0!9B[E/LG1T=+KY7I:
M*J==.D1#-.L[[>V=5G.YKI;KYCH#;.!&V=AT[X)4[1[]?J@[(9?SO<((L6B%
M2WY=+U]@A"2+C=S<K#9;H@(?#>LR2%\>O-R[V'NQ=YZZX5']KV8,R+OJ,6`R
M[GI4=:N>JI.Z[0F4E9O2*>[=]P1JD`+.'E[JWL;4JH3Q85U1+,='90D^O!N9
M0./."--W,H$:68,,=+QL&7UP>78)@&JE3[7GPTLITDV&>`^3Y="BH'V%1TL&
MB(!+BU-9NT>;^F3P4=@!1E5<M6:SF%1O)M\=@B.DISJ8[33CKYUL<?YEH,]I
M83Z[?[I<9N]\^3W=-R/%AXN(M4?@_.Q-3-DE>:DZ0_A%Z%]J$N'WR0CF>G7;
MQ#/<5I:`;H%`'AD+UYY?<:AHHS%O-)'7:UAJB$Q_HM_4PBKD6*0QI[Q=N`^^
M<\R7`W3=9QSP9>.L(RPNJ]&ND_?4EB-+I9R-=%-_2$3I#\GW^%]9.T@):^D'
M7)UL9(.W$]GM)XM+^B+9X=ND:IC@(%[4RR)C+.@H1.@@9R&:]$[#0L-O"IBG
M:-P5:MIU<AU4/V*Q,URQ56.G-KPTL^H<$%AG>&G1;MU[/0T8L:B7X-U)#]<$
M'??-.C";FXTMS]=F>'F;Q6G:>RC%WJF7\L32!'2*?*#ML/SRQ>L'Y/G"YC_F
M=4&>[V;E7/)[_]&?",GZ-#9WVEL[S:V"/%_(`FC3\B!'^8-7A#I6>YH)>]W[
M(6AQLY2)R/;$+5!5:$_<KY^*Z(.4%+.8;WZY9!JXU,K!;$1^_`U1;^YT-G8:
MRQAO53.?[=X&%US\-\\#EX!]#;L2`O`E_K<$"(@[?DE[W_)SI]U<WULJDL<]
M>$T&.(?\-E/,@6HQQ^NVT2';TL[R4[+864834,SI=F@<9X?%'6Z'6>ZVPT+.
MMGIF'[_LOCW<-ZZVP[2C;9.PT^Q4\QQM&8[M9SO\0B_;%!J*^M@.O\+#=J.%
M-W_X$?2PY4E-.]CRB[5A`:Z0%J/%#.K]D`?.X_[TBL[SJ/5,FX<AP^:A[1%+
M$PBAQVA'#;4W[%:#O&'EIW=",Z').*3UV(*^L/2:@]6D?6&=UZQ4>JA#(N.T
MYI>%#HF0J>Z2@!M>S8QS&A6$%:TF=!;%`YOIOB9#7([A,4JXE:?:6!=#OX+M
M;A_"T"4Q!,&<17(S11^B(2LV&VBZBY^YIKMJ6?EDV=+KX`),:76"]3Q5#M?,
M4N3X=:A\6HGCEP,5CBGJ*W#\TJS9T*-(*V]2-91AJ54I8*RKZF4R6AFHK810
M:^M9PJBMY*+6UPGYE2R$!?1!?NDPSE)]#!GH!G`6J!<VS]5U'\XZ%V(TAK<]
MO%E"4Z`(LOY[TYFD"9+QW*G7=]K+N$ZLYEKF0MPHRS*W5:_#OJS@9\-B;L`V
M3\X)G(&^_(^10,EV#U[7GD-TT6?/1%U?_%'(/3A#5]82?$NV?_#5KFJ$18"9
M&#ABQ3'NLQHND4!R>'Q1%JE./,?*M15J\G(Q&@_UV>X7=MNVP28&5"4(*J'J
MS.B@>D'KW*C\=32'P>H:QAJS)O)&8&'DOJ`2KL[L$W<,![=_\OKT\*C[LG?P
MYAA9+SVQL`0ZI`[H=-K.S=-OZ@L>!62A)><PH3AA?0'>5'@RJ+!7-54\M#[*
MAN_&J0ZN!KQPHBLY6?9C-`(&"`I)?J(J7G4O+KKO+D#L6$S'&$AVM5SE(:`9
M1&>CKH>`5V,0N`^@X-W5RF?3Q?3R%2;93DV\DQ@5I?CJ*HG(,%/+#,%^+ZG-
M>/QL[OQX5O"&TTS$QA8RTAM;&];UML*8LQ_5"L];2KMZ\3JK)&,;6FN9FL,`
M$(8`,*A:XP&8K&@,9E89U%"]S">(JI2FB:`.V=YIM7?:[7R:J&M:DGBC#HJ4
M3LLBB^A,V&J[3!;4G(,D]^`W8-KVCP(NCL>3*$G<-V@56%J#/O14]+2RBF[*
M^C=BR-NH1F@O4R/HT7R%)B$+QI<H$S2LU:K!=,';#%/>[UBNML&?T!R]PP_!
MWJ6U#X5ZXNL@`OW(UD9LHJ7`YM8#Z2+,%#JZ"'P44C>X$K53C`F)*XL;L@V*
M!=/:'X;?_V$\Y$;+K%4O,3PR'7PF?M@[_^%B[\51MP=F%:!Y0$,:I7K80E1L
MN>I\_&,X:BM5G9=L;]`;1Y/K^8TDA>0@H%N7I'S6OY-T_7MQ='A^RFSC>>]4
M#OL'N6+/?BZ[ZS*(+.O]<IS=0Q.QC6?=MFT#->@Y/0>:KS3R/%36#JF!WLS-
M*)&]TA!0`0#VT,_(Z.O-\8N3-\<@TD`=?!M-YK,[%6$K6"^ODO`KX1M9#5%]
M<=)[>P)8\BIB/3E?LES6Y+ECHON>!EK9MM5%APH>;-.MP,6>OQW%&OXJ>+.7
MVLQ&FZ-?.0J=C.:RU#LV$&OMJ9G7)K@A'/^XF%Q"X@TVI$##S,IFHU5=9D^G
M&_UZHSJ]IY<8U6UNH[G?YG:]FF$BC8;>T0=[T/]"O=^DWFM[+M<@D*;XFQH#
M&BPL&8AG$;A%*B?P>3!TEN4S9$>T7!341&/"JBIRX%Q`;UVG".IZV,51,0FT
MMS&2,#Y_<VY.9GXG+*[521'F3,<6N)XVY"`V6TH/19$(T(5"5$3#DIUJ)KKT
M8[<G;!6K&W3\Q#"KEZF9[BNZX=BUG8QLOIA-G)UB'9F"N(YE<CVLR2<PG0%7
MM)0?FB-(RU=`-9(;$"=X-DO64W5GBRXF9GMD1-.'AJ`;=C(SZH0C9D,QU6K%
M:76<T2Q/";M;;:,?\=9VTU,T$U>?I6AVR*ZG1D9QVB.I3L3%Z9WS^J&DG["*
M6;TL)/W<^-)/9Z>^Y#)8U\R_"D8W[4JSK51"_G5P]PBH1^^'7E"3:W&\N7QV
M4%=9J+)M[:?IF*\8+@#)U1);D#(4Q68AF)JZ5DI='"HM";=;P5,:A^J07M(9
M9TH%'*RGU)YNU8`"V:I=R4"LI3HM@MC*,L1Z:N)0#UQ$I97%H3J9N`KU/Z0U
M#N,J7%OR2Y#_R!H^IE/[>A(!S[/T(_1N"8&@0MI`N-D4]?I.I[/36:8=X8IV
MKH'&3GU;!XM'/54;<PW`QZ8E=T'4HAYQK/%D$/6B_FQ\)TJX7?D(,!'XT4P?
MTSJH?!"2*^$(/3KEK@67B_B0*XX_C(J:A.Q@5?PH^4/%\%;1L5.V"JQ-?(G,
MLN2U]JXP0S)FH2,#(;K,NHS8#AI-CS8DT[#)/F'H"\H]TZ?/![C@AO!7LAL_
M8!H%O`J[&LV2N342'228QPM5((F'3B"7R$-^0GF0M544U^E?7@*K6S(LJ7X#
M*,<79$."2L3-.MS)6C9NWD&9!H-3CR]JX=&E*GR0?`5L^`@R)62\3W3'J$>R
M8QO.JE&EKS![7P`,;)513+,=2"CA%L;,%5Q6<V)6J@LKN0`0DA]Z+[L79(T0
M:E;B];WI?V,3U&J;S8YB(-T*[Z.[V_XT-((Q*%VH4]Z+;.1QYL/@F]E[R-K"
M^$"VV,MYX=<8=FR4>&9N;#CM5T+C.A[Z]B;*,MM:T;*BPTN4ROH7AL:`!U)(
M<47D$@HHCC!+]0[@'IF^@HAS7"JK^-I;9%'0W'86RX?^++Q8](LBBT45_OK%
M8C?K+)9&G>)I->J=9G`$@:E7KZRI7S+!NL9])EA5LB>XT6JT$.$M"^%(=V^F
MTW&?J;C*I!)$+);6&$5*>"[9^REEC0JE<XE4`GA(MR+G,U'2,&9S63(AE,'E
MXF?=438'F<_OS*C:;)C2H4M.-0O]RQ@B<)1W]<664HN#4^85I/B>B+X`QQ^Z
MO"'/LK=[1R\.+\[Q('FU#SXI^)/(.]XA]F?7`_%<BI+HYRAG>"!E,WCZX9?&
MKU6Q6DO&$5B:EDE`@6!_UQ\JE5W]8U"K\0\L*4J=.E&-SW0@H$.E%1T01<;?
ME'U2!U,`;&S4J]O:@5D>1*#Y05_0]Q$G.1R\A]`'46T80;J;T832P:E9Z(/!
M1SR6/^,K`B*?3.,$G?I8"\$Z")V^^^UH\@$T:Q(.Y[*4.Q[OD7)*`&RV2-?7
M9V$50KHR3`PJ*"P@J\31K.XNZ2"E>(U!'9G72[L8M")_WZ^G%@#H+DX>`/G'
M/P#6+_5?(8OFT^^?EA^(8[R:)%EBI7Y=@&_$<@$3UT8!UI'JVE=K4B9M[=0M
MX;*%(:IT`A,K+9.=S1*WE95'#I2VF'`TD0CM7T?HWZ<2QM&-U"P:1V`\#-Z*
MF+>METS[VOILUXF612>/&U5C`'&BG`?#F6*JZJ!'WE`LE0,(S[Y+28$X@(@#
MDS1=+EC8OZGN(!1EHFZ_X=@^M71IQ0CP\)P2DSB)HL5M+U0PU#`K\(IV'?'-
M&LO>(!Z/X5:SH5M0^81`]UZO!Y"&C4*2Q-%<M_WB;BZ9A<5$M4QB?JK6U3CN
M@V5BO`#]*?ZB6+J`@N#4W,'%"F3F+NEP5NZHUCAX%L=X:5)HCL8V=QP'J^.N
M1I`6DB)D^#%9J,<F<9_"NQV$YC4]6YO.9]1A/L_P\N/@Z&3O`KT=`^B:+F;Y
MHZ=(F2B:M3;5&>#@8Q;=>HMK<=MP<2&?-$EB<VJ:""G3P*@K::SK"DYQ$(]3
MY0UL>.V41ZUZ=OD4_&#Y)+(BP83K>#B(/EK17ESRI+T(.$##Y@;Z3<!'@#8,
M(TV\4!IRL8^/`H1I>A<J#9<!;C_GL;_M_=;4CH>%3^+:/.[I"'?NRNQBE34L
M1MIZJ`40/P)K/^OW;N,AG$^SA(QNMMO(I&^W-S-(.2Y/.!&(FM]K*PM^&E&4
M)E76MDCP$9<N(G3"GG:=`E#"YV9ZGF")J-WJVTE`?$8R*++?2'[(G8S+Q=45
M>9LOI=1.B3Q*7;D/+?%)'[SKR6Z.D+ESAY55G`:1+OSU_,DDFEU#'M8,I99^
MO80_T>5L8\C&]DZ]L325IE4WK?S>,OQ)!^\;*QWKVA'^/%&!A%W)#P+_![N*
M'Y3DIQ0L1.GC:#QF26-T10MIB-F1&%X0F/Q2>TZ_M!I&!0R$&`[O+KK'<%U$
M1:Q;&54H4(+;*Y76KFYO(#"CBJWB%?G\@+.<P87JUP5G^0;UD.=2$!(;X.W6
M:>RTD`OM+)_ET!6'/<MD\Z@NOC%<EZPZ&JC)0+X>1#U6UB&2\.9V-9%4?57\
MYV+R'BYN^Q@A<"Q%J?$=Q_+!NFC"DMPE\^@6,VE)(9C5?#BSLT@*U@.5QMCD
M&M8W=O+5(H$GEJ=ELLXIB.]5]XB-AP0)T.HF`A0#/4[WU-T[$O5/C6:KW=G8
MW'J`E3"-!YD6?O1NR1J@0JC!EG1.M.K@1-%N['26V#RKBDH&$=NBOKTC%T_=
MFOTVL$<5^>]6ZBSXT>0'E4S`!\EWN==-[WIGW?.3-V=I1X0"B47=^R8;5,:%
MDX%IU]7U4E=.P?*2<GA5O$NG8"VZ^'"'F[HXLFM6LG!D79X4P5%E*8Z\NZ-P
M)]P1IV^/@K6R!QT<A.,^8&KI(!2SLO9[4_YS[Y0;%;RM/6<W!&V*C53),SOU
M,/203C[O#E^*3Z.A"I\+'FX;F^G(EM:>2(>V%+$G0\3-(@$N+9@/$>'R4TV!
M6W666<HEU5Z"9#6945J'E[!K^)AP:GA#RD].'+0R?5<["XXB;6>:/XQTC(S\
M0>CRQ8>0XRZ[M842])82#)"W-9#E)J!E5Q5[<[!PPK@(:5=*SRK/ZX)8^S0K
M&/[2[[PQR+.VLKUE@DV%K?$<"!Y?)X49I54`530896\J_?J*Y6UD*(<H86I/
M5B;0'ZJ6WV$,I-(:APDL@^J0G^D:>/,"VD7++$F_%$^>Z)@3Z<#5&JYO,B3;
M,:$J4M4T=+\:FZ1A7[21D].7BNZ+NP7L$9HX&%XA,V12S4([%L'WFE+Q.DHS
MY,D`<S;&K;'C]3T2X@;<4E8ZC?:RZ8INI^&IPC<//$T(\Y\^16IDWV9Z>,QF
M:C9)/MMPK;Y5C#HB"!B/T&*<=TA0,H^9)]ZQ9\[IXH?:<\B2"U?8O]1_M6*N
M;E!$SHU6ZW=M_V`@N=X2JJ&LQC>;9!/;V/Y]!X]:&"O.;*M-^I-6.V5Y!_QV
MEN&=2UX]T[I/'!R@UY>'0,KP[A,^[K'Z^^L%$CFD+'D$7RT11[",;4_3@`PG
M2Y.C<#W;G*:UTZSO-"QAI(7V_"UU,'PWF@S&BV$D5';[]9M5^VD\[?]]@0]K
MP:M84Q)O8Z&@OA?FXTW?`(HU_14UGNJT:C:W@/PU6W7N5,CWAV;JJ]U^`,PJ
MQD>:+7?V`4N=7CR)>O)C,0%&R':U01AY_C[:BS&'!3NW^B..]GMOSKL'9R<O
M7AR=[/_YW`TD'FS5]^VQVPPDKFNV*:BM3EN'(3W`2P]O-4UV#,"-[R52PM<F
MVX:7):.25<-*PH'P0]DUO+\_06`0SF]2NXIGMV(U6&X'R\'24,Z9S3:%76W;
M-"OD\^*/.N4`DX.!Z2R^G<XQ-@F%_@2ML20.Y>>KT"7T,,I&!]56R,X%$AAR
MV$VGV<%D995F9UL9'U@2%>B,),$::E>^0CD#,H6I-+A[R%28D3%[@RK8-04;
M,VQX[7%F/\0'WY7EE*"-DRZB=BV5RL!1?A&3:&`EM0OW5>D#Y3^93094V=I!
MWJCS"$06&G2!/"SH0IE(R"D1SF*0B8)L2:[9:5,(]T[;=3>\3W0`WIJ.I[^]
MZ7P/<.7Y/W<][+$_FTWJSV93!8.3T_<&5FE_,8_'<7\HI^E`?:^*<_.U614=
MR&;[_=HC982JW.'!/$85)*>;@\.C[OJCFBZ`>EZZGM_%E_0$>0ZD6$Q0)*`I
M6*_*S[\!M*?KCRKY0*(1!'PO!.M1!?*3^,94L;H,Q!#=J!&&TC4Z_1^!SEJ*
MQ)+8BY<G^VRF`J%<XL'"B!#*(DLM(5GO0/)M$A94/#R^Z)[MR4&\[<+T3>))
M;3(:BZ1_E^@:;#8K/\9C\F-6U'-\M\Z3UZ;`XIOM#;V8E#N4`^;5/E^4<,8I
M]$7'%:*6;$V_8[L;P!Z)\*'G:([VW7??7;R6_^RHKB*&IF312UTYO#(=P7`W
M=)<)UP`0'K\O)W`BS)(:8O[5^$,TFXV&)F;_5AV-Z>3GAHFIP0J'Q>3C:#*$
MM3]')<)"LK\:WEOUM2<YO`4K%+R'X.PVS[)NQ*T)/[0`<3`8SA!SLG"Y3*'Y
MV?C,08E>_O-X&+--VV?EK)1CCB=PPMNB]",-(=1JE>VQY;JQEH4\97^<RV,5
MWP';`U_XOK:YS3'HM[=:5G)<':/29ZW$&G(<S^P@",;9:0(7N8I!$B['Y/DU
M^8!=[R:J"C^,4Y,+G!R9#'#NKW-'/[N60D'R"_2T]WKO76_O[-7YKUE%D]XX
MNIHKK&S5"2O;#4?\T^5D#T!D`9V?ZH!-EBF3VA\5"C@EG$V850D>ARJAA'@]
M4HB.`D:.^L$?R;#&DAE;C<T.A99I;%G[X-]R%FU!.8/7UN?6`<4QE3MB-*%`
M9N9@!QFK86)N_//FIMU"=:04ZU4XNW_7F;%1N+A=CD1=YDO02)7+EH3$^.PT
M*6!(IZ5TWC#IX'E+4G(8H=74;O_E5Z7TYM4D><3;$9#+'@-DYDD?4TI4<M%>
M%:F$D/>"I`5$]5"9R"E/S$Z#-$*=1F=3Q1EQ_$7""J$4KUKV<SZP<)X*VCN:
MW(S`RO+OBY&4A5;Y9PU^AE(XF$/5<(8/HT>2/%.-C/<S]4EVD65Z);LLZXDF
MHK$-_EK-S9UZ:YE^R:F?OO2V#&\;VVW*%>5=+\HYN94<3@]C7$6SWR>M`^NR
MT.0>=$YB&B,O@`;JG+(%<K=S*G#L$8=QXGX!0P9LJN*RX'0!'15\;K"2RLH\
M_?KUWO'+WHLWAT<ONV=PC?M7&)6;\-L9=S4#'ZD$X![DS$3@65`\"('$X%DU
M,5].NG(J47AFRYRX.H6;0/IO#T9%>"F\"^*N4@QWJ=3>66!"XP^E^LZLGX^"
M["&6,S+_*2G?+IO6NZAH`RJXDK'"RHNQI"]O4_#),I[V&BEUKB#(RRAYG_0_
M1$74K@RRQB!7TW-:+/)2:B6HB+\]I@NHY4!P@:OU5.TLS:T_&[F*&QS8B\R!
MI2_3BP\B?;&>,01?^Y(>0+;:A;RP*JVF4KJD8@TS%.A>(."POUS6U)=BU^5^
M5ZLJ;IZZ-0],1H&VP_?G0;QHHH^7<'@P/--'"%MPM=&WJPV.=MZ-E..7FLF'
M^"-(IPD8)7"Y`"R$^AKB-!0H:G:*::5H!=+A/'TXOB/3)YQ?%N`U;*_P1@>,
M*IM-'?LAE\M(EO$7&WAEOK'AAITSIN=?I>`F$`^GU$9XDC:PN;NGO*:GK*#E
M'_6J/0Z[BNF;:R[39?O^+$K5=?JP5)5<I%.ZQK(^D;'^:_`)3!8SR`$I\9Q$
M0O+3@_?C.Y"5Y"-V'03%(C)FY%:@7!\VP8A2_MMHL@29Y4X`@F/W;1>B8D8?
MR+OD.]E`'?:DHX4:QI!&.9Z]!V711S*;!>Y0\9;@6G\;R^Z.)G`%A;K+==9#
M8>2GD6RJOBM&4E@K!:V`:/P0V4V]':$-M!A5*BS6E=!/:*W,_AGBE]&O`/43
MQ+R_C*(KXV>;BI>N/3IX`FK/V>N",N$"!)HYN\C@IC^91&.'CD?SWI@&[47\
MD12GQ/6X@&7-9#4/3%4/<=X[QNA[T8>JTK#Q!=76-EAI;2M'/(H31GXCH8E4
M@NEM=`MAWDH4SU!A<2WB0')+NI[7[30Z&94>&J/;Z?S.QB.%KG(2&[7K:*71
MKF^R(Q1K,EEHKUF[1)U,EM^,Y:H?P`1F*&<`_K'&IYH>DIT,1V\!W+HZ`P[&
MZK6Q_\XN:&+9D9V`E+OMW,FT?;X3T]&G:`Q^"-?CN^E-;S[K3Y(QHKU4)@OQ
MT6V4L"[`1!M;7V=47,A=!@[/$,N$3-<M`Q*,*)8L;B&TI)S__@2N)_Y&AO)/
MR_*LQEW*0\V`Q#8G!4$1TI2,B)]X$2*'-8QO80W&L[NJB*]D/;@Y&2MC>%B2
M>K23>+Z.H'3"WR8ZG\K/(-.09+$+9CJ%&QU*N5*A!XC9?5:1M-O5`[(#&7X6
M_+(0.T!^$J_[=Z+10C^)]M*,0DY-U\-BVS)K00.M2LNUTZJ)$[CO^@CI2D?S
MIPEN63U)EM[!53N,OU#OL+("E(&H!`RD9PC)BOG*OI.@IF[)'L-G,R]5`>_@
MT+EJ=`6XB7T?@<R:KI*!ZV:H%B*O!I9.J1'\4N`_I`MZ*@._+`G#>@0I]4"J
MO(J39*H$HDQQK:S(7SE8K02P:HGJV5BMY&'54SI$7A6#K;2"P2\;1)C?PU"X
MJ33"TK5"2["H`B8[T%IQ")9BC3B*_1_VCH^[1Z5^&8)>E#4+\Q"!#/`DR!1T
MU-LEI$T5TU$,Q"9$,6B`S+*$MNFJ:5EGPQ"W[29$A*K01UZ0;8+7ZR\^C<8C
MN*[_<M704I4.M573;8%HX35?4*F3JE9(JZ-,X-1*\J'DB4+4];V\KJ?5-O?H
MIFVVMZR3V8J9[3;&6-G6D<]2BAD#+J"722V&-?04+*:5274TI98)X7MIVV&M
M3!`K$"8:G-.MI%$21%4\\4OW)+7H+\9SOH"B2JJ!`G44OXS.K+V]-^\.CP[W
MSGY6+JM0B1))LGP`7K/3,659Y\`>=DGS7L6SVD)/IVUYT&_I4+"X.KY,/<N-
M@5#Z$*I9WL<`SNP#^'6_W8LU[J>.=6IFJ6*M0LMW]&%Z$)G[>$F'TZK70'=]
MM:O;V1R?I7H';)TKC7H[4^EJ3W/FYL:W7["OL8=96UKA.J^QW(ULQN]LK</C
M@Q.]5PB-O*THI!0GBMUH;\-=FW;EX@K#:-X?W$C)RS_38+.PMH`:,A[N1M)F
M?WD:%A5;65&^[R@WNY7"(Z/JW"&M-Z!7>I(JI);@4G(%S'2AJAQFV2\138;I
M][PK-:%AT/!*J42>J#)7XS[<P5OZ$>=-N>R,$,/9!7OMU%J7W>K%4XR!W]A%
MT9]IIKH:E06,J'P9H;IL/'H?<1P+%533A4JSR`'G&[Q&5#P!BB?.4PKV$3I2
MEGG&1F\8D[G2W*[7JU8XD(N;2$IZ_9D*/9;(O7<3C:=28E,F`-1W3-..9H^R
M'*\24!K%5[B+>"U0JPGFG8ON$&XRNAV-^_HBV84:@[")`'A'61"\I5@J`QI-
M!*HJFOS)ZA3SK!+H!%D.YK-^19.KD($76`PB%ALM=:L=`,_+AE9B.`I1`2UX
M[Z?#BQ]ZIV<GI^?ZT-&DFO7;*RO64/0S5D&[#^5D'Y]<='?`B/(N7LBU*?>I
MG)^^*F`H-\WL+6871`Q7K3*CN<#8&1*8L2==MPJ<W_2OI)@RFM]Q,#K\JVL8
M:A.C1ESARC(+UR6NH_ET%D]UF>F"?GO%9M&M6PS0K@LY!#GK/'11W?50S>?6
MRHIPD$V/7%S3LVQ45Q0GDXUI720#T?J]AV=ZKKN:@V6G0":2G5(9.*8R/HIS
M+DXWVG@IT=KH:,=-OKF@S2B)!)I/4U1*,+8&3IT;`'VE?*PL*#%2\(0C'H:8
MB@`?O_)%3/Q*/@=?H.7[<?'P%^3DWZ59[G?[>Y!-@'&B^&@K]$R(N[\7'.8N
MPQP_58M4>9OM5^GL-S8;#8K2W%#\O-;JDC2?J=:U6`C_J<5SI5XY\Y.Z$*9"
M<!',WT*WQ@R)(HSHHC7X_5`WQJS)R-`1J[?%-"DW?KREYDY]62AQ7=7V?FQ"
M$)]FW<TUT*%<`^UPK@%<$^=9R084#?6)A*6(10`I36RPGJ>&Y9I9>EB_#D=?
M2FEB_7(FE%-(%^N79D6A'D5:KYJJH;6+IE)('\OU,A6R&:BMA%!KJRW#J*WD
MHM97QOJ5+(0%U+%^Z3#.4GT,:F33.`O4$X_<X7E6DU]\>P&$XG5T.Y(2",HI
M+(DU-MP$]!G'P4.&AG',C2))M>EJT636:F!JK3IL7^@2]&4VR3RH,O4]&5<L
M*=5>KE(Q9_T6@R&\-6W.H*#M:''0(8IB`\^E+4$X/HP,>A.LJRF/5SU(@X(0
M[$WB(BF#OH2AN+O-`Y1)JVQ8GD7J/68D0(B",Q(D24%`09QFD:D@A&5HS1EI
M-A'+0&LN+)^P(1_TD'3%A8XB[!KS"DQ;.EN8?JC1T6Y#6?>PMN(J2SN91QIR
M:J8(`NC*\FA!)JP@!2!H^9O?JVW5S-KR7@VSVW6E\$;WZCEK2(T[:TOZ=;TE
MJ*MG;VJ"$-[/V5@-[6(/J^$-[%7W,92Y;;UZ.4@*#R-GGZ:0E`5!<#CJJ_$B
MN>D-4/WJ7C]D**Q9P]3JL-_7%H<K_C\Z`C6R\*#%P5B2":G.P`1O0J_$Q_Z$
MK/%H-E";6'M4DS709=H*W%YSYLN*X*Y48BHN,:H(L;:2%K#^5\L^F!\DXPZ9
MW^7+/5R(+5PF*+JT(9)]:XE#CJJ8OCVV$BAMM_`6L<6F:9:E+%17RI"`H:L3
M@5@6L6ZDG%#1`"53.YA__^2JJ@#2:A4!*HT7W]G@(]9.T?<ZE7/L8V5I?$:&
MJ/A5*83<`DHMY&#`+X-*(<?,XZ"?'4[/'<F!-1)/X;9T*%0V<R#6ZXQAV"4R
M!Y&MUFHWT%2SK:,^Z0UU91(<!(+E'6"('["W&\_O$RH/.V3L,Z_ZH?!X+O"P
M`NI*CPP3J$;JJH-JJ6NFK39FV6ILM=3XO*108>V-`HXW(3^JJQ#ELS^:B&N(
MZ(MAG\A"V%'`W,;#:"Q+5L6J^OH@:A<B`&&E"[\K0GIN`J1GB<+%K6A9Y;4L
M=0L%+VMY<J2>T-]+@(2X%GS'T6Q16)RF(G\9S!WMQ,`^,>S4P5XZ"F]&-9<)
MHXH9W->56Q[*IO@MKXSDJG0QC\/R2M+QKCJ>XHBH=!;7FHF22AHE%@>1A9)*
M#DH\UNG*K:`'FV:6O)*A\7I=0Z[&85LF">:Z`'*)+,X8,F_,^Z-)@E:T>-?*
MP[$*B37ZK#[`)L8T8ED,!+]<LHVY%"I.T01M&[QMVEL[G26!ZG7-W(W<;M%6
MYD\.,K*8]&[B^+THH0-T#RQ.\('2_*?2(IEB<"YA(C.=P(GCB10IB^IX>(IX
M?28.HD]3,"+497*J&[\$'EBG00/KV%$N=&P"]/.0BP$<)MY2PH)>GX+7811,
M=)(]AM4(A6!SP%/W$:7&(ACO]E^>\0L3($$VOLF=4`[]X(D,Q5^\.3B`P)JR
M:<(JI]XV^<0YK5DOGHSO3&KNQZ&7*O;EDR<2^.-G*B,:)V)0[V'UCR8+Y?K6
MVMBFOFULF[[!T3X94A0A,,>\EF=@,IK(TU:>Q'.,[R(`^44*SZ+^&`NO"R_I
MN%X,E[7G9C[-2M"C75K0&KG$:.\<PLJ\/GEY>'`@ZY3%'_&I>>!@R@;)24F&
MZ1J(JS:EN.=/LO7ZK($!1\)+2)D=0=5='4\5)TXW-H36]31/XMYME"3]ZXA#
MJ694")26G?@-,\LICH^B8VB7-\HQ=IM<\R`HZA5_TB#$3Y&`-22&,=UP@L-4
M$AN?*9Q<+!%]DKLCP4KDUM4?S"5?*]]`1VO4T?[D#JLD.L]\]OCUY*H=CPGO
MX,<P2@9R)NJY""E2G3#$HNG+D_/>\07AHH/V)17^U'X%L[X15R^C*_(1HY"G
M<L"258<\#3-P'^S/(:+LG"-L0<]H6^!?259"#'+-IZ"&ATMR+?S&XR'<"HO^
M#-+*EM7M,`S3'@%F`"R`.$UFEU0.U<0>+R:2=94$?TE>.E,-B=:#G)"0\3+G
MC*37RT])*J<O&,6F:-:+Y#*WZN:SO-L;%&#51!T[Z[XZ/+^05%P%1*6\-VN7
M?$QFGS&!XR6WN'?N\%_PZ*%3[NMGQF1="F)-OUXR,[J<YF`:&Z+90.QVELR,
MJ9O6@[2MB"288PU3K354E"\3/FD8WTJ6KQ?-9O&,0B>UX-0=C8<F?&<\A?!B
MI7X#_VUB`$$GO]*CRI)44X\J*%:FPK;[TBX"6+MBP[VK#+\_A,R+`AM!Q\32
M%5CUE4H!@&5M7TCE:=MB>:N76`"Y=,@0A_&9)>_LA/>!9_#@,VO5]N/)!S#A
MHY%+2H>M'DXP'=$(TYPF5?2)%(SQ/GC774<"$:X,0-$F=G,S[=--O7NP;!`$
M[N'\NQ$>Z'O@,^7?34^5RH=^U*OVF.PJIF_5])K(,8%V^[#4O[M(IXP-])(^
MY5@Z;V,RRV9=1?(&)3!H<;N4:DVN`Z@"P:XN(3`E!*W\&VV<IU4A*9U:+A-:
M*<0CREWWU2"HQ*.<G&\`T4\1W:K[2B.F/IEZ(X4BH3QH+R31,X:CU)NOI\/9
M)+@`]27B>;,@T1$DQAW(?U1?0G@=F@OI5^LH<;:<Q%=;F/@JE>3%Y#!]N&UM
MP7RXO0UQOPBHW%RFA=0NMU[QKK*?.*&&_;%7_9YGA11^(8N]Q6(YA$`6JKT-
M=#CM";&TR[IX@1X'`P`['<ZA$F13!Q^-.BV5S[S)T=^<DYDI1;3X6W(KOS^%
M3@CJ1,+70O!Q6;O$].A@1LH-AOLDUOC`M@9C)#,R"#L\OD"S^I$ZN]W'MW#4
MAK3:ULB%]LO7?W)@M884'09]B':1T3L.K9^(ADC&\9S,8AF`:A+6?5FLB=*+
MPXO>6[D,3L[D@CA^)9G_D[.]5UWJW$@>_**A'0&RL#'U^8P>5%;J=7MMX-`5
M.`M[E$Q7E*;`4F#+NQQVXU8'_P"Y!HDN5$0;>'B"J@#<Q6`P6]^E.&VR-Y+U
M8O098_O;T?7-'"WF03LG2]XJJ_EI[3E`_:4`.C#.AL/43(FEJ81X.COGLED"
MF6F+`XR>!<%V%<F:BUUWL<FSJ`?H21CI*,41MDD"!@SQ`\GK0Y72QYFL@#[G
M$%T1`S!+3G?2GTM@TRIYUP!%9$!EO4!(<RIQ""+J2(>6T'V0+60B6.=3AMF0
M!;,WF%T2V$T#4G+>-FDJ6V/^2_?LY)2[Q:-6#C$\]\C'F*ZNN7N%W6LPSC#)
M0+PW#:H!"*9=[J/K#2/U"62N.7XE.WG>.SWYJ7O6.SGH-7%?:>OD5$_^>WE7
MF!R\6$!R8`HZ(_EG>[NPBF4QD;1B:&\:(`?82<#I-?`^L'6J6C&#I/I[/`K!
M*+V?W&GG$M:5V$,%+8K:/J;/N%&>2"+7$'_\HX,:W$0\A,\T06HCF=DKM*-Z
M0+LI=;;:8IYR"M[)5U7A;[V'WVBC;['!'GAC^-&("`"'&:IHW:-I"P[.DNSA
M2![DA-I?1K\J:#R+IKB:0Q7]'GI><_@B/R]]59RGGC3Q/PR)7SFC)OJ0_7I\
M)P:SJ#^GM<WGN9"[A)%]U#U^=?'#^J-*MS^X$9P^"Q8TTOY8'!X?7D@N^CP"
M3Z[$]<L2?S/=A.CX:]\+E1J@I&@WTVM\:"\C^_TN+S/4+QYBSEN>)'!3H\6@
M'@16RY)U8N;;WD2I8\=IAOM=]N?&G19G1ESF3KS>._ZY^'Q0\E?(R(+Z;S6,
M!.0MGA/(%[LWN5."F)Q!78JB2V#<(?LANA%!SF]T!;(G9V+%%>9GL)$F=I1G
M>[+6^$5!8H!QXL;SI81!;ZX(S0[D]H(O'.(:?^@=9IV9&%M9OONUV':?F.C)
MQ7?[\@YE;'E9I"H>\S%J>NJOOC0)U\DO1D,Y>Z,YA$TX4-_E\C)?&_@?);_@
ME85^EFKIR\U)UT"<JF$+_#'0$;&YI0R\M;A\"'%[Y-DUBA+<[A!I<<Z)+1+!
M.8(@&3(STW-PU;SMWP%[R.Y'EQ$(_\HG4Y^`]%CEKN-[8C+>P$LE3`1AG$]9
M:0KQII]Q^\HJ1Y6IHIT473."B<A8A6<#Q9=S416$2;IT#5.KT[EP$'K-@FXR
M_&GP%?NU3KSGMJX#E#E1TY4]CAM630JF$#\=3D`_]Q\#]3/_F<CM$/[N5G(8
M/$"=HX6:Q?VWCY*&$Z;]G9)O03+7K9B0[01U;(&%:U6X4B*LNFVF9XKO;$WA
M\9+2@B\=WQR_.'ES_)(2V)75G2'!H>EA&Y2MS3:8%LOEO;FIDC,M7Q.\&MC&
M*W\UD'+YWW(Q\/@>>C%HL&HQX,GMM1G:MBH98<6I,RY6B98`Z1NE[`Q#IQL%
MB!3<A_0MP+-`O6@VOQ/@<(ZP5KT%QCF]MIMU7#BM>K-9?.%("N[0$VW@F;V"
M_CV7#@_LH9>.!JN6CD:HVVPF*7'*CY=44-1$57H&5S0%%I($&DM14:\E5'^I
MU<3+AW/"M>J=+2<NY9+5LR#'*J0^9-;KKYQ_S_5"3KT2DN)QK*?I!?%0A(@:
MK=B-C@.M4CT.&[H2GGEF:3',)<2[G,1J_B5S)&F(!D;33QD86G6=@@'^0*]:
M^VYT!<F2A%)Z$[N)<7+Q^9MSHU;F=_;2H4<PGPTSEWCY76^@-56KT7!S!JG!
M-XPS=<UD>7KL]@,Y-.MMNC?,I076<JI#37(=;#7@R[(NA==T(WL]-[YB+3>"
MB[F16LA5+M\,EF\N7?@-,/6"^D4(92.PMAN%-D4S4+.9WA&J-^.FE<6H5"_K
M7FLT0]=KS^ER2)+%NNZ^76+L%1'@4]+]L3:)D@0D4#2BH0@JXB-NF?EH`/+K
M)5!/6$9.'^Q=:.B$W178LU*X@0LINDA"HF^7'.<5U7N05N<&;='&1NO;;=$M
MWJ);]7^1+;JMMNAV_7^WZ/]NT7^M+=K!,!^5UD:CK>+TZJO_[%M_5WN2<@=A
M[FHL,0#A..AG#7^&PG<8S8K1O02*W46R6[/>),88'_)7+9[5)C%%^!#002M2
MM*>.HE5@O7=>">>5ZD/J!<7+?A"_EIGDCK,,&NC=$I,&*J1#LC8;HMG::6_N
MM)M+C!JXHF764-_::35WZI:17X,REM-'7D!6A%8T*)=(9ST/U7=^%$Q[CG#`
M.`@^"P9VI+)V1W*SG6.)'+.$`Z<+:6.$W.9\XP+56(Y)P683@UAL-JMV*F$"
M/XOZ0X@)SR>#XJ_Q)9CZ+29<0E$F\=T?:2K^D(CZIS]\>K[J(C%L!GLUNZT]
M)Y\%&+?\02Y+ZPMT2*W<#P`?*+TWAR_E9K/`E9736X(#N$)O@2ID1O]#4J-N
M2[P_/CC;>RVGY?!MMW>*H#'U.&2)6!4[C+,MPID)HNZG,$?(?@IRE5S:J+1U
MQ]W"5;PLK:5ZJG`:1E)6X7R$%.P[JUH:N*'I@T;NN+@B$M7]@?=R%L?S'N39
MC3_:$3JISIIENYGE!4F+V?*`5#LI!Y;G^:BW0TUEM="-L>&FF^OBBC`T6<A#
M`/)&(H`>6)DD^B5:@,*:@>G$J;PJ:XUFDW(.;S:]S`9,L#)LX=3`TMF/HG$$
M#J;8#7`A@C1(^(P6<`V>A<Z\1!8:S-V*],RK^$!'4H:K);TK<B3=^"Y:VSO-
M0D=2R-6R87EHD=/&ANMJB54?TLT2TOA@?+^$LWA#,%!HY&FB4F9AN$S(JPC9
MJ^%"]C("3GXVBCY$0_;!);TF?M;M>#[VOGI+DWH9`6'D&\D,YTU:GM[98'EN
MPBI.N6X&*GE^FU0MRW'3JX&ETZZ;7BGPW=0%?>=-KRQ[,ZK.I]TW_?(JGH.I
M$@B#P;4RO3Z#N*P$<&D[5H9P6<G#I>_QZ54Q.`KX?'IE@VCR.Q<*AY%&4[J6
ME8V`BN#YJ6I24,Z_?CUQP6!72>U3!LMK7N>3&%-.6_-"]+M-22ET2(@L*F/7
M=7G?QD['SK32;C90(J)/SZQ7B@)T%#Z<5:\!>0^CWDQ.6$-;K1K(#C^+W*AY
MQ;Q-N*P.#FZ5]U#@\LK.6%QC^G/U+H>)/@_V/LU,YW4_'=D\K_.&\R[8]9QX
MJ>TV\N3\^1!,N>Z4X<JAN\E'GXN$IRZ_:,IH_MEG&%>M!E93K",-::-%FV'#
MI#9/@3%,^/]/G'.@-V7=0GH&<@KG3LR]^/A6>Y,TJFVZ<]>1]8.K5:PE']%^
M._RRK%D?=KET4BO0]H$LAJ7D(PTP78:M2SV2M2OHL7,0(BE+["VH3'*"%X%*
M>E3W@</%[53HZ$D<P0#0Q:-)[I)YI&X(^;*(>OU9;4-`O&G<T=%V.BUPXY&?
MR@G\D=`:U3S<%@D`8ZB'CG.M1"$'%P7;<D4C&X+PYP)][XBZR;$K*0\_>7]O
MUM%IL+79:'N2#IV7O4]9PHX[C2FY1;U%_9_^09JZAV,GPN**>5V0G;C!+*ZO
M^S,!KJY;D-JHOB2NA%4W+;<T#3L!)C%M2NS9(OJY]H!_WP?E!?N\RSC%+$'@
MS8N?#H]?GOSD"Q!+H;C2A`4G0Z)(`C5UK91D$2H-3M].!4_""-4AMM8994IF
ML.IER0T%<%K)P*G%=2_':6493CW)(@E4=7&4EC!"=3+1%.J]'=C2'<!#R>(!
M_10^/9<0HXE8^Y3@EP?0>]!&SA5,BHDE7Q+@3M=,BR1;EI<A1G>J=)J!&'>C
MV_XU&.'+1Q,58^TAI!(/[D.()@BRID#*(]IM(RVD>.\5+YE=2W/\?LT0EIR:
M@>&&+@'([1O+'G+9'&D&"]8.,P><EFN*C3@MX10;KZX7'&W0P3$UUI#P$^I[
M8+'DIP.CE4[!>#HZ%L_7"E#NF@O>;8Q&.?<6+NMNBF:P[JNI%DN%I*(#;T;0
M!`I8YK(O)M59,MO80%F3/@A3K_=^?M'MO>R^?=V]^$&4WLEOA_M=48)>#Z,/
M(PQ#&%Y1$,U&EO,;BY)!?QI!9J-ROG06PF$QX6PI2G.DH0T2AC:,+`1_WZ_I
MZW9,U\092\#0K\]R!"0T1C>R80RRQ65\>RGBQ5PE/U>6&4L%H]%#R44C?\M^
M.]DH=^58"R>3UD@L\)K<W$(SWLHF9@1T0FOF$0=N(A!RTZ4^8FT\O4_@38]V
MI=+!I3&^O/6P$):"E);#S.U:X`YK/`U=8N%3Z.]430-:WL,7_9R3N!^^WGO5
M[1V?7/QP>/R*`X&V2!LE/S<LF58R1';B.']>>"YV`^DIWU$CA\?G%WO'L#HD
M*+DN4H\]9-#(W+PV7PZ*]O<DGK/CZ.B*]C<G95(9V2?QI`;(K#IO7[\YOV#[
M&N@/1NFB+5+C+3*+DG@Q&T2)<3+]>"/Y38A1A9T1&E6CA`.`;%((SH;E_6#Q
M9Y1!_JN#$!.8!XE"C*`D$<!/+PXQ/>-#@G_431GJ!4=(H!]V*C!50&>IXEXO
MO!C%#DZJ]MA,&7LCOH("67R6.[A7SN"\T,09HZ,2F6.S7V>-S"X3'I>3?,L9
M5;9"N5FG\&SRLVUMX1!'5"O,$6&O]&&,OT+\SQ?`<@]V!W*>"IJ`!/@D1L$&
MH:!1SS3:6"T7TSUSEW`C%U,_+T%31NEEB+BGZ4:'0@PU.FH1I'*IR@D)Y%`U
MJTRL7=_GX*25:0PVKM7^RP(=/A55-4&^CM?ZM((/GM[-[0Y:6FQN:U,S1_^8
MI7VTNF0>!E@H.B]LTCT?]3&>"NK.'DI[D*>'+*:%9#WBZ_Z=:+10C]C::2^)
MV>?4S-1`-EL=S`""GXV'UT%F*"%]-G&9!!W4NMT+B$DRXO(1P3PC]X#LZCE]
MV!G*3F\M&AAN_93:,[/>J_U>H*JG`,VL3;J\-%Y2JM!L",J((``D8(;APZFX
M"4GN@_Y*(?1[>M%4^SGX3VM(,VOGXS%S@"'SC!P\YL"1I#2:+&Y]%0Z05+K1
MP;0&X/X0"$KO8O;WT=5:`HH3:T[?.;7)AZJM#_34F?*0!EV(+.+$\/0Q9T^[
MN8E66A`'F/GVC.#YS"J&F#=#&EX=_7SZ@W^'DEG3I2E<-X.47'LUL'2*<*1*
M[?=,08],^&5IU>D1I#9SJKQ:J*9*@`1PK2S:GH/52@"KUI[(QFHE#ZL>A;CV
MJAALI>F!7S:(,+^'H4V?1EBZE@B:"_[(H7!9JJB*'S$[N?-D-(@GZN=#7(TL
M1MDF6_1N"6M#A?!V`S@;L2GJ]9UF:Z>UN82SL2JZ`6\MDU"*IXK_YODH3./I
M8LJ6Y[[X#8I/I?;.5T\7N-_`AFK0$$@CNM6"[@A6!:%$EAX3-I0,HIES(Z%\
M!]0V,/5S;B1.L8LO4UU,WT04ZHZNDML9<U>(D#^.AE*,IE"\O<$XABA@['5"
M"JMFTQ)VI2`!@7=+%/==_OH[.`#]?0'17L:C856\I;8@E-YE?_`^*;.J>NKF
M<LX2>*R>&H''Q64*EBOFN&/EPE+*',H*HZ']"***]6[EB739GW&D?"VVX>W'
M=AN$(?CP;#$6HVQ##+>S.LS[#Y`#X/3D],WIN>?&1!7D?].'L!NGK9HA`-&[
M(D3"R8G<;.#EZ1*[<54Q5_II;:#PT]+9#S&>,X;:(GL8<#0']1YYZB62%X5D
M#AAEA\(W);%2J6,B)-S-_J);QZ>'DON)HX3"%V#0GDDDZ\QC+T)/:00Q?R"\
MXUB2F%I_,(B29'0YCDB/<[F80TQI\&!+<,N`BB`90TQ("?(6HO'?QL/%N#^#
M9CG<3ZI'!;H3<[@ZN$K([%*![B`$U24.8)RF!`]LIC_^.!Y=BL.7RL5R/HMP
M$HF\P#7(;!8ETW@RY.0$J`G&[E!8IHT&ZFTWZOF9DVQ"&*)NAI'#S=9[N7>Q
MY[.!^3!<7M"&DL$0!NN:>BG6,%A>LH1>%8])#-8BGL4=:8KQLVMF<7_+T%K)
M0JO-Q.6CM;(4K1Y'&*SL(2G-&P9K9>,IV'^3B_)Z,)W%/6\S2U[DIZ/#%SVY
MVE'U^-5$^WUT=]N?9K!VZF4^V5:ET!(?F+MF2]2;.XVMI2ZHIF:>T4NC3<YZ
M;4^0I=J_C^PZ[<\P<^X*N'#_&1M*F%XF47\&^4%%_VH>L6.0/#:8@5P38F\B
M9`^B&1C08!K>[]GGL`VV._#1MLB,7II_[O[\FE:633!HD%5WS!ZA4#4SB$2J
M#I5/$8=4.5JFIE^I[:UK&(W;Z[T_<\*AP^Y9[X>]\Q\`0(G3"<W*5JA0_<RJ
M[5>$,(/GT':)8E%^`E=."@\IO^Z`ESUJ-MMU]&IL>2*`Y6!,?5WN80PGRG%,
M!R0X?E$]-J?"&-T_W6#(O3]ABIIEH@!57]4364P$4+-N=SW7)YEG(IO?_[/7
MCS2?OZ1-WRA(MYAM!Q1`>6'[GR8%#&EV+/L?\+J!,-TJ*.T!S\W58CS&&`MH
M)T.\]]==C7'/U34._?SBRS$/FGLIY,+.MB9B(,'K+2L/F@+'">3H:@6EJ>;&
M9M6..4*3*?%9=9Z42H3C9Z*!;M-WJW*;K4+8I;*[>+.1PG]?,,Z<VZ_--AKF
M;[:VLNZ^=,Y4__J+4;?&GTLE05[:5;%TLUI_2F(T.W%I^Z[T:#:4\DDFRJO2
MNE;-EB/EZ09FZI"?OFNRVG=A*=%T,&6K?SN:Q#-(_1;U8%]AKB5(Y`J/:_"X
M!E.(CQ_(?I\Y@+#0J%X68C\<RWTI-C;;.\TENB5=,RTW6ID]FAV*:=E1NF%U
M6/7>42QMFJ;>#[V@U!`^P'?_I0]^R?];13UIX"O8A)02U*H44!NK>EF20Q9J
M*R'46MQV!FHKN:CU)(14)0MA:<D@53J,LU0?0XKC`,X"]<*J8U"W99S*B@6B
M(VU*WR%9WCCN/XBD@>J$X2B1$.))QH[WRN1O?*^PX[FSL=-N[;27>.[X`'+)
MP`:FA=WH,/-NR$#W1XGW.\G$P)3(8[-T5W:WDB[P[M7^Q<^G7<$%]<\[3-3X
M[O3XXDR_HQ]W97+,E@=\G86(EAOL!5]BG+1W;XY?[YW]&7-.36+Q=!B+WSZ+
MCS=R4IY:,:.EM"+_PP0+(XB#?AM/AI"%83"+X0$?8W)^0)WT0*`DUWSQ6OZS
M@WHE,+9#W16HA[X3:M-1]TM]P*3\!S(Q_'<)'DD1`!/0412V!UJ(2U=A\25H
M+Q]06S:W15TNOOI.<XG51JIVYN)KU/$NMX$^>MG+;_T#+\#U#QE+$`I=+]8Y
M`"N4Y%]R`?([,LW1+^&G$QW@'2Q:FB:\4D4Z<@&EA'QJJI!-)-[P0KR[CG-V
M`D7EN2WUJY=E2+?ZF]PA_`P@@;_JI>03!:\\"(IF`5"+!2MZ]1INI7^S'1'8
M$-[X`!$/LP]R=D"1M6\%>3%9+`NL>EG/SJ8FZ\G=8H5>V*AO@K,Y?<"Z^?Y!
M390@-]U--(M8T0WHG_9G4H@%O36HR!.Y&>'-/(;)5/.F(L%$2;0KDO@V0OE`
MN1A`,ERM#)=PKJ-9%57FG"BWA4DFYOWK!.W/I!@$2NHV:^[U;E6:!`K*CPON
M7GUUH_R?0Y=1*K.Z_05=1A!.MP5%QN1>VV$QN>>"`PMN0$AOF$SZM&).0=;,
MP)\<<5T*+!>GM8/#=\=O7K,O!B!;OLJ*BBSP$AR5='T_Y"7)G"S-C>F7'ZE2
MGD.279*B3I30+0(ZWL`-T*M]N<-O^A]&\6+&2@0WFJ-*5ES%49V14)D>5(,&
M=7+Q0_>L=GIR>`R9<NG2!L:ET%=H8(X24XG=[US^N-B`>"@,PAI010WHB)G$
MP@,2.J7%/N5]?`>A.G,'1%$\L30!J.HGP072I*:/#L\OW.6AMP\%EI/4^/CG
M0X-E9YWZ10CT.>HBH-=>+/#,?G,-5J-<0(XWRH?#JX2T&W2=.)J37XY)"Y/,
M8U`50Y[M:#1QQT^0`^-OT?BYAPH#7Q9*5X+C3#"RO]"LH@^``RJV%`4$(!L%
M*K5+810@Y6AC_!WZ0.Z!.,#@6!6]#(U5422:7U1WX/SBXP+SRS6<F<%GP<#!
M##8G<+`IP5N%5_M-?[:"-PX=G-W]'_;.%"XVR20"/GZ/$_$[3L$H5C6/LJJR
M4C*C,HP'."86*]&E90`ITJ:S^'H6)92OSP!"K5:4`"#A=%<L)I>0Y%TXG<!!
MMFB0K;24I7*08`H2R?1RLN8?&9;+[KJ%D?]-E4?,VTC$J&Z!/G5(_[/9T4X]
M:AD:;<_QR;'26P"4JJ%GU12%<W0_0!B!IWMG0>A7Q7(@1BDB:[*BE=4B17I0
M2?=`*1%T\^DV'?8=*PZT?D16%_#3:G=JU<"$[7B1\\Z6@2W@]@1:I5V9.52>
M="#8':U)L=#YR>G3CS"VH"Y*`U`/EL*H+.F!I9;)K9W7@WP89,/RDN`@A^=D
MAWHJ::L11JZBCV(Z[J-/FV3E1D.P_:`XA9OD;;VY64]M/+A6@$[AGI.]`.6Z
M.UFZ!&\T72@54.[\@BSP0>\,8AO<6Y0>XV3#!*,:A.\QX!=$;.V%,\J!"GI:
M%9\\\1#&LM7$BP+Z\*V*Z4#%.V.VCG(9!OLJV;U)'FM>BRNF68D"M\SF!,/8
M"IAVEO3Y6ZU&M=F2_8;/AGU!'.QG3B^"@6"8!4GCP@T!@Q!2\5^R*WN17[AZ
M5M@7OPZ'RD\%?/'+0;074]0/]>*7Y@`F>BCI("^I&FK#694"^FA5+S,R3!Z2
M*R$DVR%5<I!<R46R'P?&KV2A+A`!QB\=QEZJHR'Z%<!>H![0%DK^$CP_%1XL
M!-QGV;I$NRBPG-.T>'^^9H9%[@SCV?K)ZX-]NEI3'#A?4WO5W4_!,S95)[PN
M`F>DZA_'_@^>M8&54@C2DE4:."_S8.3W9CDDH>DY$/#M>@//G>WMP+E#\E'H
MW&$Y[,O.'27@W??<,<?.=H..G>WZ=NZQ8XF269)DX-C16=13J'#V+PN9WK&3
M4]D]=E3UC&/G@U^'4\;XQTZJG-PF5E'OV$F5IH5CAI(Z/M(UU&JS*@6.'54O
MZ]C)17(EA&1K:><AN9*+9._8^>!7LE"7/G92I</82W4TM'T#V`O46W+L*#Q8
M"+C/LG6I5U%@.<=.\?Y\S0R+W!EVCAW5!_O8L:8X<.RD]JJ[GX+'3JI.>%T$
M#@O5OQ]IO,%C)[!2"D%:LDH#AT4>C/S>+(?D'3N=C6JS+@EXIUEM;*8.'I/G
MV3.4S3AE:IZS9O1I7LQZUCI7Y"\=0@[41)>C>?)+X]?=3,MZ._ESN//.OC-Y
MH_TCHP`@]^BP064<'U9^(%/7U$L=(\'R<NE[5;SC)%A+9]K..U;"-=6*\BH'
MCA>[?M814VB"*ED39"WI(A-463I!WM'CC"!CAM)'4+!6-L:#@PAMZPR,9]2W
M-"VRXJEKZ@R7\MK8&7**B7_\0]@/&N74&B,0$"/@7E!2X?_A9AZ5-4AD-E$_
MM(W94%S]D)5XG53^I0]@&O"A7'L.U,#JGU42R(HI![^P!X?'1X?'744SG'SN
MX<4BUCZ0H=*(K2(;]09J?QKU>B>D_B&M?4C]0U<$7ZC^X;N'>[#A8$<@A\WI
MU4%!1XX$E_W9K'\G+A>#]Y%Q':@W-Y%+E\/3;+IE>/83D)$2F5+;R=QQ[NE!
M[Q`-%7_"78]FTB'=DKE#R;I"">F6<`C5`*)=(1TAI'1+V94]W1)7S](M^748
M#RG=DE\.9&%3U-<M^:598-1#2>N(4C6TE&DJA71+7"]3MY2'Y$H(R;;F(0?)
ME5PD^[HEOY*%NH!NR2\=QEZJHT$9/8V]0+UENB7&@X6`^RQ;3[=4$%B>;JEP
M?[YFAD5@AA.7R2\E9:\7I6G9UB^9:0[IE_+W5%B_5&QGA;1"W,,?:<QA_5)Z
MM12"M&2EAK1".3#R>[,<DLOH-^J=3<S%6&\K1P[G^A*=NOU[76<]R`*/:D6$
M@(I?C5*K4GZ)FW@V%[>C"5S'R&5TV_^$WY#MIY2LX+LAUJ:S^'8Z5\?R!D6_
MEX/HP$F6XV8+XT@%17<%@/,W+U*L?T:U5&CZ;$8_<<M#V5`L>H^MU\72$>C3
MK+SJ>"CN?)!]UQ5"1P;62<W5H\IORSF1BI<<V)MI3*(K2[DNBM!@[VHQ&8"]
M%,Y3F::KC.DTY+N)5QB\D+R"\"@OMGYX[BOIN7?#T0?GW@^AGR-#)&X%/:O!
MF/EIB<&=6*]K09K@3VRZCJF%N%1;SL,GS%3MN7KIU^'-&:[#+[TZM&^#->B5
M5WX8#X*%Y7.O9&`U4%%:$T66&957B\VWX`"'PFB6MN%HU+<HH$A]<SL0:NHU
M5BNF'RFB"DG#%FO`[%>!*$8?[#(<^V.-/A6QW-IF8KFUH5(Q9Q!+&G$UT*1#
M,,%\N)LBF3F57;*IJF<0SEN_#I5/$<]4.4DRK:(>`4V5IGUBAI(BB.D::G-9
ME0*$5-7+HDJY2*Z$D&QMYCPD5W*1[%&H6[^2A;HTE4J5#F,OU=$0K0I@+U"/
M;%'`]"^16V<RE&Q`-'B/B<['<8RQ0L!\^M5^-.0ZB43*:(S"+UBL@!$MA.B\
M4AH0QBCPC;7GO`/782.M?RB7(6LZA`,J[W*8$=5M@DTJAEM0,=QJ%0/NK@9J
M!BKRL\X:`M<*#)D7EXW2"^/EX9FU+J"H,LO!K]U;>&0'H`03ODRS)RCKFCV9
MTB&S)RPO=%R?[MG9B10E<#Z@,'[C,3;;-,:&NHPT-FN>T9)L,M]L"D?V(PRL
M/YA'8<6ZAI)G.Y4&Y!M0^7U)&3_E@<CK2P%`RER]T6BUJPTX+!I-),/^:7$P
MCOOSASLLT/]'_":&\0*<QH>[Z<;H]`!+)X@0DJU&OX+"U71]-T7LT<G>A7\2
M9-;T\L12W:P\L5X-+)W.$^N5@CRQNJ"?)]8K2_.I1Y`BY*GR.@&JKA+*$TNU
M,O/$9F.U$L"JG5DU$ZN5/*SZ&6.]*@9;@8RQ7MD@POP>!C/&IA"6KF717'Q"
M)/<*2.Z5)+FP5M=MNKN%'I2-QJ;EQ*:\_R3![TEB9L9FE.#_^`</&8T"Y>0*
MLW+2U6S%MZRI5Q=55OHA3AT@C@[/3ZD`4E"M;VUL$[\(?6ZG'-?L"0,7*?28
M?2P@;`@B0G*PTZD\G-;AK:EJ>EG/6/YU7PFOI^$>S:3G<'EE"KI7;T%J.CGJ
M[8Z=1D6%NI6XWC_IGNUWD<0"WNE\-DUGS^)]YLU2?.3,4^:I#!$)T9%)^1CI
MR"Y6-[/.9%G<B[2LRP9.9"QM;8._=,].L+0R@X7,$RX\7<0REJ52A0[VICR3
M((A04Q[L6[D'N^QX[KF.B/F1D14\U!6$G#/=!^)'1_;ZX!_#V=5S^K`,B&V[
MO'=Q_.9U^E)-7WX]1U]*QYC9JN)=HGFU4C=F5-5<FC5:3?+:385@_ACUW_?`
MA/GW"5X%D'=AZU!2(V"(Q?QF%B^N;_"6Z3%[GJ#[KNZ+'Q6YT:(P\;+_DIO,
MCXNL@5130W28CY^Z>\8.W&9`\@"X/(@%(H,/"=74M5+\2*BTG'BW@L>7A.K0
M&G`&F.(T@O74TG:K!O@4JW86KY(_#Y6,>;!V5.X\5);-@\>YA*JZ>$US,*$Z
MF:@-=3Q$1<*H#=>VMK79&O!/Z2-P-A]!%,6"M$<ZS6IS&W,K*=<)CCFVF$0]
M#2#!8TF4UN3^[:&`.NQ-TX&%T379DD5UA"*"X4BE-:W<UV0#*4JM"$6I^5DU
MHXA2G'&(+?SA*(A-JBS':7;-_2WK20I1"U`(IY/55/]2E.)H7_GY!JA%$6`N
MU?#`95".+`A.[10%R:HEB4:ZHD=)_+K@<>>L^A0>4F3!!P&'@;MNDIMX,1Z*
M2?1!+@'*Y$=A4"-R]QS+%W!W&&-EI7DU]20#=BDETQC#I\KS@_R=']7L)81A
M_9RNT)*G`&.8RZG`>J*"WJ*"=6$WI5.6W?8G_6NYDTP@+^<4]-<6;DQ8ZO>I
MZ.;E4J\`W"/Q?Q[4"Y-"73;0Y;71VFQK/T]!N?WD%(#7E^R1Y>(U06TY*MO!
MD1EBS]7BR?@./;L$1*,\.)_T9U>@I5^8;3NXB2&&KQUWX&7WX,UQ:0RJ>"GA
M3>@SH8_;T41?]M$7N@G@;"H.*<&:!*VW=_;JO">^^T[5$\B5G$?@I3:&;.;?
M$P".(.A?X%#S5$3^/1._R?]9"=-GXG-VWS!NH3,<R;Q(6)6O&O#*7X$;^XH!
M$P"U%8+#IBLX[(G<#']ESWP8_;W&"E5%J*\/$CM$=CKJWV;$C=5OET004<5T
MPJ/FIFC6=SKMG<Z2R+&FJI48H-'<J6_H?.UT/F_R=G+S)1,I4'DL&1@%S!-K
M=$B279F3S#.0(5F1N/C*0*')M6$%<@:<=W]\TSV6LG0J8BB!69432M]4)CP,
MJ:F><91.KX@_(CM>Z,J*VT])V.A+(&BH[IR*'GKN]TE@&CN.1W`$X>*ZIP=G
MW2Z<4E7[76ZOK7)97;>*9/??XMGD2/;>'%WT7AR=@!'CFX.#+CCW],X/_](5
MG4:3,ZDUJBV(Z==HJI#?9"R!DTOSQ]!3#`\WC])2\DNK^>NNKFAOM;>J'!XX
M<)*X96'AV*!Z@W@QF>.QPBV+-?VU![DZ2_G]DK^KCOT%Q&M4J50UR*EF\T;(
MIPF\DRF-(*C0KAB)/X8Z)4:5"@<^^4V%Q(1;&A<5HU]!+R*[(8NN7,H7[W>I
M\&<DF;H'?OQ+](%503#UY*J0G&N24:L`5#(G%37,SR=4/MX1M)GNLM];E3LB
M75*.&#]C?SR</`+^W'&F8?PJ<-RZ?&#N@Y4DGD)L4\[03>A?=0R.]28(=)9:
MJE3T1.",PPR\.SJ7O._>:U'*X:8"XQC]:G*O_B6"J%9SR)=<%=&G032=(T_)
M%W6L9+B-;I-(CJI$J[(LFZ_HV37Q8'&S4^#?+;S\;K95["<5#E5W&2,Y0-]H
MU`^\@N$9&AK`.I:E);HSF,8@?JJ0XQ<ZMF(ECU[Y[,R`OKKDJ#078/JK^&XQ
MZ$.:6<G#71KO?<#KH)](GNTC!$FQ(O9X=.!]%$T3</:')`AC#C]>,3O@':5*
MA5/'VW-2L(7\WHEXXA-TZB<-4J<D)O0CX<23=F.[A?DU&AL;5H8-.`4EY]V?
M86!:YZ`%TR4.6.L]ISEB(N7$KC6KO?*9B(`_^7HSIR>G'%P&P4FT@PCCT8-$
M6S);HO0DO"L,K<,A5[*&_!N@[,'8KXSH;>IM,?:+(F="##?1`/:KO;T\<J&N
MF@Y;V+92KC1`68W_/GS(FK2*09\=+&(:TFC4"D1#4@J%C*J>$D%5SE(?I&IQ
MC;3*0)=,"_RFAVE17U7+TO]EHZ`21(&E`LM$024?!9[.+UW-QD%:WV?*+\=$
MNK<8QD?S%IP&[3X*#U%<X4'R>9U247@9"[D[#Z?.7\KKH6!)V<Q56,(1V-,0
MDX4GKZI-MF4P%OT-:Z.^7Y)*\]X8XGPUA;K]OC^>WO0S*)1^FT^A=+&5@]F(
M*-0FIQ;IM/(IE*D*64DPT.06"(CMQD[=HE`->6J!I9W\V'+N>=\<=]]U]Z6@
M%WTB0#'<.+*!DXJ?B*<S(%_*]C5<5(+R)<%J2R2_@RE`+F?]V2BB1609=9[_
M`(E<CHY@69_+TK)@;3B.I]%$ME4Q/8%(P+W]D]>G>V>'YR?'=`&J!5!PNWP(
M@9ZLIC+D>?5RR6QQ*3]_5W/I<:)K_B1'A'.U*1J=G;:<Z8U0`J\.W\GK6&.T
MA"G46(6B)5=2?%5?S/H08D[R"+"?YA%;J,DM()E@;9,&LT1G.+[N\7-S@*?W
M[]4LONQ=2C[ZO5B#[[C';1W!RLHH\*R?2J1-AH$K:[?V&QK<RLK:)4988YX'
MVI%L"K%PU,?:<Q6X#UZN8Y(YW1V2LN&7X*KPP99QE",@P$UE0^<?O6DTHT:0
MN5*`)-\/\7M#EK!E+0I0!\!.I#):<YMB.U]DNU!`+//8;6E.)9B`'7%:>G*K
MA(FJT^^R24L!++\NM8XL\C_^(:PGK(08EC%`X6BRB*QFH3;@39:G*<'1KJC>
MD*ZA=W0(V?8H=#'47<%&R281K'_ECS)5S!Z(6SIG6!8,R^PQT)Z4:Y`+6/DL
MT/[%;5]VG6TYP-?7+NWVGX$7[+\J?:_^<Y?]]NP>T6Q8`U$@'OO#W@V\U##U
MJF"0^/$9!`L.VPA$."N5*%N:N]F$.*U-X%XOG8XH",#YP48KEKZ(1T"IB`K7
M=(X*!>.FG]P$$O-`*T,IQ]]8&LL7>^>'^]D)C@C@JC9T)F6CT?TI^V=[V$8I
MJ<NI<57M'MJ%PL;707TN05BNS<W*E?3:&Q+(PV_.NP=G)R]0K7CNITX*C]'K
MCU<I8\!^FB5WO"*8;8FBWB$?`Y8:1J.I^!5>;*I#,U(O@%5V(OI@+R*9!")I
MB2A]O!D-;L1',,Q&!AIWAV2'@5Q*P@@17/NDZ%$GYF5T!<'+\0WF1!O-M<[B
MIC^:4%Y)A%L5EW?RW7"!1W+5:D8WH:^W).%)XBHEX/P(C#G"N9%S)\]KN.FZ
M$[/H-OY`D6-ODVC\(4K@5+LU39>)Z[*6R:/*/=<)'_F88\EYH<XZ:RI65N;1
MK3XRC%6_*,GG5:%O`_"UY$N@BYH4R"+TBHB0O?4?9>]]$3?<.\JX:>]C]BC9
MQ-6QT:ZVE>>@.)$G=Y_D'LD<\5RN:].Z@S>TN]]#TA_>#P>HKE3K^]SYQ8G"
M).1'E3/4>TF&2_*=<!?)*D9E]R]HB4%*4I2U4&Z#187!S2%"Y?JCRMKWH@S(
M**D)L,?XH3_.X)U0Q8WXSTRT=*NIARRDSG+D>?C);70KEZA^XAP<T[+_G$X;
MZ[F$,)K`H2-Q2T95ZHV](%")R7FB2$_(HX*IK]C;NS*)DRA:W/8L?`N''?T?
MA1I(VOMI.AX-1A"U'IFX/C?(0>EYFY/2EK`5Q,9\IA#HZC:GJ-JD/6@V`C*F
MA!':"CA$>H";P?G=P/]P.PC>#D"4&*/S&\A50\/EJ-/R'TGL)/\]&8V!V$SB
M243I:5OU-@H^[;J.\,.L;)KE*Y-&Q)V`8#E@9-.%2(^99ED5\$K.2T4/78Y.
M/'XF//Z2;A"\U1,&^2Q4B#J)?OX5FQ$,-/XLL_$4SYO1$M)C)P&Y&9=V4))B
M#$ZCQ=MB%27.>!LIU%)X[S@OM;*]O=G`].";;97NDA7I+G'P,[^9,<'SH<D#
M;A$60H_SCKH3)R,VQ@F^9XGH`?)$W0X[66H(>+-$!P%%*"=)7VF+6EL[S269
MH*B:K2EJ[-0W=SJ6IJC=:E5A$\*'VH0'TUG\`>(HEWZ4$.@ZI*+#IV`J5-+R
MO'[9L4*C_Q&5/>LWSU.4'E_@1`X[SB&/+]QS7NDUW*?]V;5S*IQ#Q965-00P
M@)L_[)&DB/!`K078TV"-;F#^B&F_])[6"VS84?=60J@[#NLA;\8`O'F4S'N+
MB0N6J?N/\R65O[0>Y#NCNI"1\\OJ2]XT@87O5U:);$LTQ6\E(9$2D8,&A3PI
M?_7'O035N#V5,O1P/(ZN)3.GFI.'BOIJLX$/E?7J-IHL+ONSVJ>LS67>+]EB
MIJ"?_&=3;IHE&\VJG'MUU-Z&K):5]G;3Y'^5\T/!P0_.]EYW>U(*??-B[PRS
M:LM9*ZNS[S=S:^=E`A=KM_@!-^]+<H!:&;FK^K+=S4N^K)$PB^7`$"KU*E:1
MS!&P5G(N>YC3O@?JA`<AJ8MQ5`.E6Q+-LZ;?*;)D!3AE?75O:Z>QO601N/73
MR;\W+:7O)F9VI@_+@BNED6%X7Z&2"4,(:%:6)GUF2')'\[>":9]5:;=#N8F?
MM3NK+)BCTMA/]2B=`'IIZT'=A&D[6SG1VL9DSO2AW,H*I4Y6<_*'1*5/=M,7
M8RAFVG8EG<\%W-.D.-$[EE1";KNDS&%'(($QC$"N1R]K,3QUTQ6;,IJ9"R1E
M5MU+9V6F%+V8_8X^:-B%$AX+G@&\S9R`O*]&=-9]=7A^<?8SCLJM*&>(^.($
MGUXQ[%6==CH]ZNRRN;BX5]KF=G,#Z;C\4#CPM([:U@+M.0:)?V_`"PQ,AY;0
M;&<]*JM'7BF*A`_,5N'&@E3:%&,]#L\`QLX#7.*B(%_1C6U4KD`^9C</,]`Y
M0U7"/+G5'X^QYC?3%,=])25PJX,/>SIDW-<Z1>YQ.M#U*YCV@GWN!MS<-I:Q
M"&[]?"ZAC7ZZ].$[ZO-*>*A+>7_I`D7A?;Z)%D\5_,SUD],T-4Q!K;Q`M-Q\
M.Y7<^JZQBH:08:PR2-7B&BECE71)#E6A"GL^+2'(*C`#CREEV1*H8\=S4-4"
M7G&Z9I9-S!*<5X(XMTQ-\G%>R<>Y9QTS2%6S\9BVC@F5#Z(RW=^LT!@^*D,U
MA1O`!$X>N-KK;;>%J*^HBW5%V5BL381\K2-JD";Y@6A3/(3\>GF,*Y<H0IFX
M:(`P=8H0)ET]Q;5:I@K-!MB35.@CT^^`8/62NV0>%?(^*,!Y(L@:@81#WV["
MX1^)Y7->*\8OLTZXYTX18A:=K4)ES[%L'HM*73\/=SW`KA;HNZZ1U7-=8'F_
ML]G;YB8P-Q7Z,+(J]8AYVKOR?;A>9V$HQI=XUP*L:R'.U6DB@W_=KL,JA@^E
M\<I$D%B3$",)3O%Q]"O%S+EUV!BW$%_G3(>1R9V!,%NGVP[S=EX-["_$8+!Z
MP"`('KW30/0K`79Z+]&[Y.?SB^[KWJD\?7XZ.[SH0BHW5@B9"H;13=4[.0?>
M?N]E?CWB-3IHL28_FT%V$P>7R6WZR%*L)46A+CWY$<BQO[56X6'-)2V:*^4%
M_>1'IQ)IN615IU8-G\JE_*#G0A[+RB6*GPLW:75&JU'\7`CQJQUS+FPAH=C:
M"'&K]OI^2)Y5'M?'X!$(U_/@)LI$`!.SPBE."X8FR#%TQ=@/\)G/TKIK)8^"
MVFDOK>6?8G*+0O087A=F%MOK[`";W;1JIUG@C%J8JM*OZ+/#62T22^9C(LW@
M9O;X.`M$B$UVH60RR\5GLY(SFS9367@V*T5FTV>HO6%E3V>`N<ZJFS<Q62,+
MY_/,FIAL*#;K[9P1H,PR1T))?V75UM>35&7=&6:S]=M\4JJ+,1V<H"EO&\GH
M$O;:5$VSUA8)!8($YY\*MR')V]YB?A//DAWQ(IJ(GS!)V_[-8O!>BBGQ[30!
MBWGT&"%G)&0%XR12##>:`5#4#$\SM8N<@0Z2CIH?+$(IWN4")!<T)-7I.Q[B
M;21CB^[[P\7M5-)@@2-'\]+^:`*4]^-H,HP_,@%6IN62(8,D#1!/XZ$C#<`?
MI==&[YQ.PW6-!KEC$(^EY#&:R$>3053(X%";#8;-#CV(]S`_S!%U),B:`HD"
M@]U&2-AQWFN)(;.6)32X-4/X<6H&AINMO,>RAUPV5T""`1]F#C@D(A49<4A(
M*C)>72\XVO!E@3_6'(-&9)4>4*2R5XN1J:S+A)1H9;W+D[`RY"NGO;2`%=#R
M#XB6A_3ZF(0'+U&V[#N4UWL_O^CV7G;?ONY>_"!*[^2WP_TN0AI&'T82Q5F3
M+G!Z,'^WTQAY2X$C:'G)=<(7WR9\^64"A.Z%-$16>$(TRZ1;83-H_R(8"KFF
MF^80&+CN`2D+SY7TH5!9<3@1NA'P=PE;_X?.!9#9O_)8T*;KO#Z++(3,[2UQ
MH*RB&,\;F,JTT=G4:PU&K(`2Q*HDU<"$].BG>EQ6$O7`R-]+!'N')B"=I$$9
M$=]'K`/=E^Z]PK2S,2C*,U;:TR/N]S-!7VB3-3L8@*?9WG`U=Z2.P^V:>2HN
M,<7-.AM=L`]Q-`)$^V1T6D@?C.YK)AC9=?0Z\NH%T./62XW3BXT+[PN<@U#.
M/@:];J1.P2+#2Y^!109G:MUS:,%CSX,BJT>P7*T#PB[\"4ISR(3-3=(_&EN9
MS,;%VA48@1V<'%_T#H_/+_:.84<34<DX9&N%#UEGW6GR?Q4Z5[\"GGN<7"T_
MBUTPA8[BJ_!1W."CN(FGL,3XML9X%@6^2AW%WM*#D[AT]<7G<`"[Q<[A98C+
M.8>;VW@.-[?KP8/XZHL.XJN'.8BO_C4/XJO00>S1&+!A<\[A5AM,"BJM]O97
MG,-7!<]AET8%CF&GMS3TJZQ3V"\+-#)]"%]E',*->FL+;2K@T[5P5J[7&0KN
M0!]M[7=J70C7Y`(+)--H`$J462]@>P'PW0)>4HDMBSW/9G/$VH"GY^L8I94\
M'NF>7)+-)^F+"I=3,O<0C49CBT;<K&>,V#]W](!_SQ5YOS5IKTIKR%>I(3^8
M=BU\6:'?%M.N4<26U_V9:-4%W%QO[3276-68JKD7%(T&^9K@)Y/VAU0\A2.W
M^`+),O5(ANKZ'D"$I;P^.CG3K!!%[P:MGZ,[+PS9OY)P86?>23B;T5;QV_4#
MMQ(9]?!:(E4U=2^1U2HKKWV\!.X4,OM]G`DD>#?AP@%W,$=#7AS]E4+H3UTB
M>.WGX#]TC9!5.Q>/F0,,WR1DXC$'CI0R;)Z)O#?=0JY,02RO_819#!7/GL/9
M!Z\O[8GX?>+::[XAW4,^E-J;?&NI#?&^`?7RN+@\N<]*PV,+8*ET/$4A>NEY
M7)A9:7J<8]!*UV/73J?MR:@%^4M2%?TT/AEU.4V)CXET@IZL^CK320I$*,V/
M"R4SW4_QV:SDS*:=+J?P;%:*S*:?'L@;5O9T!M(%9=3-G9BLD073"&5.3#84
M2;6TL@TX[=YM7TJ@46(LJ1F#S**M#5V2I5TND")L4L"NC:T`S7*P_T\@65_/
M5$[[?U]$63>V_'()2\FEM-E+<TLT6SN-^DZCO82C5#6M",SU[9W&AN._0SF+
M\5_?#I*T(00FH/&T'SBZ$="8K%!\2$M+<I\0R]0FR/#XQ8FPS(^<WGD>.#J4
MLGIK+ZH3?!907Z:"*I]XO?#"'1?I33HZ<FZ7LF_;&O5ME.;J*E\@\@IJ;G0@
M?V''MD8?-G?;6,TYD7Y38A[%MN6PMNHA>%<9MPTEY,4:H4N;"0045C-<L9Q!
MEG:BG-JR&'^`'3Z:;4S#W53.U]D^:=0XA_4MYI>V5+=/,&L`4R\=RE20TNO;
M+X72;;(&I8<K2L7KX5IJ707PW#OB'#(92GDJ!7D:_&ZE%?+%^N69YN;V*F=A
MM]&/M*$]1'@=\`1`?T"1Y\U#]K+&%I>N[0SG(VO@6>LY#=]58K@@TJO4\J8B
M0W2,_-)L;/!B'4U&BH[T8KS*Z,_&=UGJ-'OO^4_U,*`7;_G9=#XS<7$QIH(F
M(UYT:Z(A9;K>%EZ(W1"TAW!UXC,K0PG#+PL=F"D5S.9.<XF=J*Z9JX&AG&'-
M4)YJ6B&_#Z-"6P&T_(&C.'^SJ'C@>Q/<S-<SN0J1J$(TP4D\J5%8)]9`54')
MS@<+1SN1Y=A7$)VY0KY<UN;XUQR_<X^'Z91P1%L0CJL"'YMY1K2YI[:1\4Y.
M]R0/X4N+.95=^5!5SQ`,8[\.E4^)@JER4MRSBGK"GRZ=BN]K1I.2U52E+"$M
MG_$*X<N2-_+P5<G%ER=ZQ7XE"PMI84N77HJ(5%_I&HT9GM\WRG'VZG23;04.
M87^=!E-W%8(56K;YF;OL(\E?P.&L7>$:>BEG9NQRZV7,97:V+J=Z_O)>BG!_
MH0<S^A5#>&#=+TGNYPXD"^-9VT#5*X:_\'"<73&^9Z:S>VR)K^8ZD*7-D-+Y
M73[/P87\<"L;.^TE@9551<NBNM&"B,PJOQ(<4IO-#32IYD]FDCWQ.O_49:]%
M"*P"B"UE%9,K"<)9*X.3K$-Z1<,3[]368.,%JRKIG8$K7EE9N[U#_AAKL)D#
M;R8==!'N,B'P\.7BZI=FO?XK^\=\G5VI%9@"_?.HM=ISS@&_[H9N5U8EJI3E
MP^<DYN#1E%5YQW+#=NY+&X;872K6&[?C658D#MR\S@9<$K_4SF2SC78F]$%7
MS/X,!OIY>'S1/3O>.Q**;+SKHDW'Y>+Z3Y)W^T-2=J?LG<JP:*\P"D&=QE5Z
MKMYYM%M6UO,F=Q)LA^[KO?USR"7LK/_BZ$#KWP[;OG:LZW:*35?[;G0U@8AC
M2FGP5O;GY`P#D>'S-^?FB.%W=+7?3X@P]M[*U1S/=A34WZA)BKVSK6/OJ+1.
MNNV:2=/]V&T<`S%:;]-=8&[#[SL%<0GWG=]Y?3]'Y\54WR7/#?C:W%)$3?T5
M&02'DLD9A"FAS#ATA\@]9(=-,/3C(Q(/K([65A3Y\^CDV-"_T.+<5=902/V$
M0_S2JU$.5;5SC0(V_MNHTF<3R>#*J_W3LY,FVU!YRZ^&,<#'BD+X&X,U-F7<
M3:6"Y0(M^49O%'H\@]1H8&C#M:Q4@=;$"@:4A`TKEUU_,9Y[&JEE,!Y`/2&G
M`[)'9+(*_'89L\#%.)[A1#3KHK&Y`ZJ&^C)V05=-Z?3MK(H-RFO>""DI3@G&
MPTGIRG]5.:QR)U62DV!$EL9V$W6T^!&^=U!@"L=1=V,WZ.JDQRH<&HSKH1$J
M?BL8&DR5=GM?375H.;BT+I6G+$>[>YKJ=5JK6[R'.4$73%=RHHEU*)I81WG"
M3*+YQQC=G2:3"#GZWM35XG#3BHOE"(XEM),Y!L'DG:1^^UT8JRHJB8?DA,IV
M$.+2\L)P'G/$1NSJ%NX4^DA'OYKW==PK('6R.PQ9-H)>G3K@;NHYXD_U"Y\I
ME6]K>Y."K6U:C`+)4><7D`O3*J\2J$%'Y.GQEL>#XM6N,.B!]^5=P<7>[;\\
MXV=EG8\D#&)Y?3X*>7'ZDX:E]U1I%59-RBD04XP^TVA%%@HJT')U,4PFRH1%
M'0<4->85.\1DJ`#P#@LP+SR`N*`<TU<ATV]!OLYM(/`>?'\I=&SWN'OVZO`O
MW4<&-PYF9!^B232[AFUE^F*($@#GC'1HEZU[-35M3ME>TC+<=M\B<Z16\[_@
M6I$'PW]^_*\=*:ZCX/[WQ6@N,#EB#1,0)&#5+>F!;*`_NZN*?@)Z`/EZ!%'G
MQ<?^G5$\MY"BT(=A%64#/[XYO-CEHP;^0FO2LFUW=C"4+8LG3P0$E75I1EF%
MA*X*7`>VX?N7`1`K:N)HQ0NAC,C;G8VJY``J_$G#4S&<;ON89G+0'X^CH1@N
M4`;IR]FD/`IJ@A*Y"'ID05\JXRM&R/O1>.RMOBB11>1`R)!^&`U&$!MJ'E/6
MRQ)E9/A*BL=F%1G;.K23']G3=Q#:,P>24YM);E5O;!;0B"UT5IX-1M<W=,!:
M#;RO8,:<27:>BY7<?J6(C7$2T!AX'&C+WMC<D(7"?,J8C4*E%=DG;*F(]C=]
MW%6*O;%0AU8@K1;<PL)'Z!S$@/_02(.<D#@]L0BQ!F)M2C@N9D.N&`HKB*_A
M=K(:R(S=:W,GN(D.K[#?0%-43A)*HE<5M[&DFW=`BA:3.<3T!YHDOT/2.$I4
M@)SJ5H.L*K>L**$ZBZ]XI@,$PT7JU>A3-%0+9#29+N8]+E>:Q)-9A&DV4#]5
M`>9I)GG8<30IZW#Y:J8I596<6*L*S;DNE5'$[1SU:@S("W;J'4%Q@53U';P0
MJI?X(3LM>VO\G5O-9A/,."OR2T/;<V8Q4/<XF^YS#FFUP=?S+KGG!`K%DM0[
M#`3F&/O'/V``RXX`*)I[CJ"@#`VDH!<$+59^0^D88(<Y;J8R.'>M)H:IDI]^
MF"I'<DJ;'%C;,Q6<BM]-JT+)45,3B,H4FX%DOBK_77U(H3QL-*#?%A/*3:Y=
MB#:XN=-L[K269+(T55V[@79SI]FR\Q/@7I$?VUDR>?CN60MJ83G,7,7Q$O%O
M]'+KNS=Y&D+&+=XT54LM8O_V+EW2VE*!6[MT>9*(K#&EKNITG:QKNB68JP0Q
M9]^BY6*NDH\Y[SINFJIF8R-]#9<NGX&0='_+5FY2*LU)#Z%2R1HL)/NY&HKG
MSR1)?X@<I;)]*)"M'J.W2W<B%</MA`%`-S"G;'MIEA"WJFO!8ZG'-K?PTD)9
M'*OCX=V;8T@7@_DEW-,`F#=2)Y_26Z#3C_'4>GUZ>-1]V3MX<[P/"B1^[]#Y
MQ^FJV?74:09WGV`J=KZ8O)_$'R>:H_SJ29KU)Y)A[5]FS))YG3]-IEQ@GI9$
MDK+JYNHQVPV\(H"/=HIFG@&0W@6P+`^GR\2>]9`/ZDGF>7;7&]Y-^K.96(-?
MHPA(=(:)D%6UFM71'.^X@M6-7]S9WO&K;N]B[\51V"FN$$"7_#L@,XX`"ZQ5
MVZJ9.@K"-8#^>Y6\(R%<CT\!=_"IH\&IZ[FK%4-,93EB/`KOMIF%F32E#]?+
M&6=X+"EWLA^MEU/BV#<Q7NS&=CITBK/POSZ<F`WN(0*F(+P:PEMU9["8=MZ9
M<S8FL!^YJ3M2R*BF!I09+2RUVX/Z>BQ5NPB,)ZVW+]!W7:%0SX.1OSPRDQU+
MF>RUF^U&4%,`<1](WIO-_=C"5A/WBBQL=\VH">RE3Y<`\RRU@%L4T#2O/6>"
M+NN\1!+?DT>G;C=U#I1UH@EK2_*-XVRNHHY06*9FQ]PFI+:QK#,>NGW!6^2L
M$HA)Z-JW1B:U612?P'=\`4K9O@FSY6TV_/P<BD_($D6]7J?E3(L`@L!IB$@M
M+)?:V\JA.0\AI\ZBH9R`<?^N-I_?97%?;IDE+)A;.)#L:PF_[`-(<\V6H]AV
M:PO"4=)'>N,/HP]RWD$U<W+4[9UWCR2YDPRNCG-6W@TI0V6ME"Z4GF6K;JYF
MH-DBP*8A3#EFQ7-!*#JBA=^NA.$QZ?9SI4GAE7LU`PTBQV6B9J#<@RZ)K*QO
M3HFBRR&0^6UCI[V,*7>JYRZ%K?HFT#GZX.A"$[C;&5W?S+6&^/^U]^U?;1Q9
MPC_#V3^B0LXD$I*(Q/L1>Q=C<)C!0``_<B8Y&B$UH+60M&K)F$G\OW_W5<^N
M;@D;\NV>D^RL@>ZJV_6X=>N^;R_I6TH`?UR/;QS#E^$7R&%L<9Q\0K7D8-2Z
M3C39::G2LEJT&E+9#FP*-UMS!+-;A']2ISU^<U$%=,_I(/;BXH^7@M?E[&@J
MA:.)?-B!,LL890G["-!5N7\UQJ4_#-*K1HZN3+\LQC/=RFC*5$,MU[=7-TQ<
M:1Z*F9Y9[-ITO%?6*+70FGB&&(%A_^+TU=EI\_BDN7OV2HJGOQR@$1$N$[1?
M84WR\\-7AR<J^9A@.=_!Y/I&U/H,1/3ZALE^<7;RC_WC)G7"^T,_)P_%LS>G
M%X=P'S=/3O>/\][M'9V<[S_"MF"QSUJG-Q@F_1Q*X#>9LD5>6_8S:M%&U1O;
M]3K\#Y9[HYZ_49'^7'<5\SVO;*\YVU6OUF&WJFLD4N">+)S#J8'#<]2]'+5&
M]PO(L]YVQUTJ_CX8*0:KKEJWW=X]T>"]P?!^A+1#E?;*"'E5'6#9Z//!U?@.
M8*F#P:3?:7'-S\-^>RG>:TV]&+2`[X%C=3&:I.,D2:OJ3;]+!4+']_C\L-?K
M]@?=-!>`)*@&9*B0_96V#9V:T/X!`-A5=0G?B]<J-L+!IC+8'74_F*@V+#=1
M5."(+B?C!-&PU>_\`/,W=J?Y"LR*BDTG</Y'MRF[4`&J'[]1K]!_`,2PT\EE
MC]CP=M('_&[!4/!)>@,K?'F/S><K>8NUHY(NFM25E$A5RU3`N@3G%L8X4H,A
M%3/%LN[SE5YK;%L&$[3SZ*#Y#,=X,T#7?2R3#3.[Z_9Z:*:&$W@UZ:%18JS>
M'5[\=/+F8KZR>_R+>K=[!ASNQ2\[T!3/Y5@?45B8VV$/#HV"L0/'Q=OT>O]L
M[R=HO_OB\.CPXA>%J>`.#B^.T0!R<'*F=M7I[MG%X=Z;H]TS=?KF[!0.(1SM
M\R29LG[SE2O:`5BF3H)F'][*7V#'),3@I@5'%@YO`FC342W5!B29OB_SE1;)
MO3@[P9$=E<IP"(?V3DY_.3Q^!:-$D^0`I&AR+-;1#[B%\Y4HPJ]OK*G7Z#VZ
M^Q$#O%NWEZ-NYQI^?;VKZLN-E2U`\O-=H6QT`L_O^VW$C\F0!K2MC@=8!4H=
MG!\LV5;OX/MCV`3`HHM!OW\/'^FD<-ZEA:F&O"#5D!>\IS^FXTYW0#62[;-.
M[ZK=E[K)7.2="R;W!G<4V='$Z-82US_^K!NIQ4PS+`A<XLN7D^=7?G?<O(2`
ME-B%^^SBZ"5<"N_*.P[,#$0N,JQ+.,%)[!FHG5Z;$QS*XYWBL8%$XH&IJH*!
M@FRAX;(!W4#G3AGH9+TO9>"(49][/\YM4W3-S'2_?/'%$E3R7MY>WO(L97*C
M-.KUNKY3]C@RR$0$T462N6C2R7`X&(W_(MY_$>^_B+>0Y/:@?]6]]NGT`GJ$
M$$&WC^BP7O73D,Y[U/\_\-N/^1\0N7,2@":C!)FRQX1-"S&^'R;HL(GR4VF1
MB2VE6$!*H@/%S_'Q(N>AS4L50EUG31)2R;JSQ_I'G-ECW^=1P[TS'`V&4Q/Q
M#(8.&$H,0]V'DUF[^T\^MGH<M)V!.$IN'SZ@[+R&O3#[BL[<&].=-Y$RH1'\
M%-7H?`'4X`)8J#(X^#CY&5R05HA[GDMV&6<CJ^ZNN,EZYLCAW5UP_=Q;QJJ_
M!D$;CN6UJ,68]12'YV72[K5&1&N0SL%AQV19XY2*B;%B\TF.E;-;,.^?D;?:
MR3P=)^E8&*_LR[SGZ$S)[U#Q&G\O]QRMZ@^X#$@U::YXB76(.:`<P$#J<7N2
MT;C+Y.6'##SV5`V?=I)>`O=E]@4.+/:<APR28]ZK^&PDYT;V!1N?XX-SIQ^\
MNDQ@[@GQS\V;P>!#MG/K"CB%H@8"@D==",1O,G4L.;,)!I33*CNJ0G"1=A2Q
MJ.IX3C&H_=MO#U^?PK\QG`"N!MC(I-/\V!IU<>/2V/R`?D3&.1A@(($XY6<[
M$848QL`Q[3"+*7A]`>R%^#TS=5',=N+TZ)#S3*.X_58[3%-'@8HSOW@-_VRK
M5J>#>K';!)@Z/C2,CI2[ROD[%:;B*0C8_B?)Z(\LB0WX?PJ:E="G_(RKHTF?
MD019K69K=)TVR1FX>07L)?`DE%FMC\_]6VT1'R%9?XHU>4T;(K2,Q03%=KJG
M6):(G;>2P_',DFQ')%=[^<W-,=NEGJ']]*>CPQ<F1A8;EDH6$*L=GVL?^OA;
M2QGSVPB%+!=\)*1.^<`"`I7?,$NCI@$-F^8TEF-(3?*)6+1KEI0Q%*%/-D1-
MVA/O8I04#AL[7\GC8PWCY7%];A!NF*HB#T7((UM0)-6,T\QY)+YC&*9J!I<A
M@C'`8MF$!!5M;0Q32LQ>]>1OJ7I0J@719)4Y@T`3TS*JTGL=ZZ='S1@=%@$)
MYJ21),BI@$,J'@JOQBRY#"K98BON$&,55V1%=3/<Y%1]ITJTE4WAI;2]-5/_
M14F#;-V78KC,BN6#Y?</A6H8N7S`ILF7P;;!'/G`Q3$H#EULU?HC+D%D#XD8
M7&I5HUB8*.#\7;?P<_;^<\[`#!7.'Y76;3UP2-*M:#RSU=B)'*\93\GGO+OS
MP=+Z3.30W)@F??31[BMT<!\2#([8F9O[=;[2&:C?Y^;LW[PU&$/"@NO/WWYK
MNI6=5BKL1OYD[NV016@7E/I/]?-8;7.HK`'QV87Y6=W=H#JM5"][4SD[>?&G
M347/1'?<\9K-,EQ*??5G#?<`59C--/F?24+5`,+AEW=F'+VB9391D.9OAWHX
M3_71Y4>`:NA0PV3<>204V'EBJ6?FH?4MXT]D&##G7<AR9;NYG%.F8^9EL`^&
MG]*$R9.;,(I,+[.5SPOVY-W^[C\XHQHL"9Z#]^8)_4-/MU7/4*<B'HX[1-@V
MAVO[=D*9=W#*]@]8:O,'`N%-ER&;)+[$WR%U<E")U55:4><2-NBF"5I4?QCE
M_.(:Q(<Q?7D7J<]1\*Y$"H?!U?+2,!4.T">D.++0]9V''T'_L-$C_[#1(^^P
MT9/PL#D/_W\>-GZIS]@4D84;%Z-[9A-B'$\^MLC"!82UGLVNP(AJ&OHI.8P>
MG%`NPQH!$E,+GU(T](D/SBS-R3^2<+X<?L0YDU7E?-J!FW-.HUKYG'/ZX$/Y
M].>GUGC0`7H"Q*@UBC;9)`K)[O%?QWFVXYPY">$=95`X=AQFX+TC%B7&X2]2
M/&BV8)2DD][810$W9]O<'"=MD[N+LK4U,*X>.WTQYVZ^>8"6'55Z*!]>13`8
M[2']G>-7%>!EPT%^/7<>#C=D5JM3QO$H/'<XB*D<])11J;]X:>_E0UGFXMV8
MF7<V84MZLP8Z7;W9J2?GKIWI]&$4[6683W^$N8S1?4S&4<V7V4BWJMG;-\=$
M)-QKG2%H`O<4I@5Q?+&)E6NBUOR!C<7S3V!@>+E_\`9C^-CT!0SY`?]65>?Z
MEP;]KZ[0Z'4F&80&_1K6'H#-E'A'3.'"6+8T7UG\0>F+6^XF_6>@<($?.[XW
M'=/,4]//)9CE/WGQTZ0U:M\\Y:H#^>S4:-5PY?$O[?1P[OX1[,"H"UA-AB?6
M]XL/U747';^0P"VIBY.7)_X^B`=D9A?$`)MW]SKBGMX9F^,HR"A5R<F41Q"T
MH\CA,>>!/3F5>#67_:5O8SY(_G@U(P4<B)J>PB?%Q]37T1O64F7=67;T&PP5
MI.F4Y.L,HVP:N/HH>4A,9-E!56$U/KL;"K*[W4_TAM#;Z?S^X-V<KYPC?]M*
MU;\LPGRODD_M9#BFJMLD5L,19&D;DY%UK[Q\;>D$$9D_@,7BDA9YXO-,4(\*
M<UGZ0H1Q5QCO$HNY/@;8C%C,Q15J"(YYS$HOIKVW@ZWQEI_M9#TNHW0@WKO$
MG9Z[?TA-))>BM2@'/GL9P@KJD!3X#'FQ]LB+M9NDP2(%OL`Z=P'"<M'[SZ9<
MW3[P#K?D>?3DEP:9+>QR\YD\=_^(7""(X7V3EU9CN[X_YBN[O72@KM!54S(/
M<FOQ%[H/=D$+$+FGWKMAM"QASZ?!2&N.^S-WJSU*6N.$'$:8]WR*/1.7E;,$
ML!P1'"4TL_RZ)GM'MH#3&QI_[JZX.]S=)(1/,.:6[!:^X_%W(F^8/S6OL+]J
MPP:VND*T4C5HMR<C?$]MC@=C\7V6;(H$&\>0#F[1WS?I=5)U.TFIU$2[E]#I
M9%:9$AP3%'?@G)P1@Y)P'3R;.7!T&@-*[O4CEX&@C2_5/1/=E*NXD-`$??$(
MI0F"&X+&@1J#GQKHG]T/L^""<S+O`U.;)_?ZG+Y]5<1YZTY9WMOI;Q1^'LML
M&WQVT.RM#(SN&+/*O+/HP,\>[72X;S"9#KM'=KJ4#`V3OC<;_HYYF@0'9+/=
M+@7Z;%^5!O3[VE)IN^%,!4KTVKM88M<Z9NJS]SKE[=,7N_N'2^CVZ%"PKR=#
M1@X98^[ME=(:(25#7FW;MI%$B,DG6-RN=GQ/D?H),_`X7%T@)%I.1YPRK+BL
M?3/,JT7`A"H<$TP[*'=[/M]7R!9D+=,!8ZF'9=$N+^V!HQD"YL[X)1MO8SF`
MQ@YM6$"5Y0%=)!?5HO%3I,25>^C*RZ'!-XG.>,]6?+ZHY%A18L9G4WQ,'&^I
M+L<<]Y)^B?KZBE)8=A3EQR.02D8E2?[X_0_?6ZVX_B"TK&A-*:TP=.JW;X>Z
MTP)C\DK8L_),K11UHS@$Z+@6Z;CF=K1C=8>Z]+V393'6HF[H(CP>WI=<[P;F
M-C#SQ(+3JM]NC;UF`BE!/IF64-HZ^-QH5,SKWPQ-S=$I7TZZO8YX&V1T2)\Y
M2>M4C;2+4!ZI%WPZ2S`\&OM0I))F<[23N$^D0WT2'BZF0I(K(^[<6_:NAT#Q
ME(41\_SU06055+DC"3U^8V,IA!-W'-9GU;UB2OXQQL6="!UAV+R8'UO-K'LI
M?,@V)%KNV3R+)`]FW.P=P7^;6\+_T[TGV!2:N10>SM[F"^^&!&<87F<;GL;0
MNRNW62=K\)W9^),#65S(?`GMGK@+78DL9F7.,G3>;&:X0.I/B%LN\_$G21^X
MC#]81_5'_$^'PZ&;?.`2[XR`(AR12Z>[E.]0P\"S?$(L972[EXSDX$LLQ&-.
MKA7&0V)8Y=T`O=D`#[N8D!?]]>]:]^FVR"7=L425LBK`*%183D51&@=BGM]B
M4OSKQ.^,!)PQE0,/1X,[ZD%*&I'#>:`#:#]NWZC+`3!V\`'H:'A?+/`JRV%B
M5H,E$1D'[H@QT`"4RI!!)&"3_AWJA^05+;>!7$.NVETNE*9&*7(P&.-J]P.#
M)$V@#I7Q$T[<"7N("H<X#,E8Q0-IZH&,!WJXR@][*.#Q^;``91_C!>)W\SA^
MC[^G#?0;(\,XNM:'2MNL]G]JGNW#.9^K?ZK7ZXWPQ>&KX]TC?K<\7VC/Q*V2
M;)27L";>T"ZS8Q.QPQ]BV17R@G=52H-=(E!52J#-OQLE1?&8;L(Q%0I(W3Z&
MIA"6-XE/00&$RFCM'AT>7["TY%P,0<OOS+(:+CXC<`4S=VEIHL\/(CV=-*:G
M!5^B?9*/'4B)A8-V:X0>(63LZ?"O!63VARSMP,.72XRRRA)U.*9S`<<@G7X&
MW=-`X!Q%#($AC<7(/ZIFXM!.%">H[C4CT?H4LT)+,"ALHH&>G'T/S<A9!0D+
M/=.;!43,43\S5D!7VCRG(:VU;LL[Q:WH]Z1CR,0LAV6:!PPNNO\$4$^"%;R)
MEK.J:.T.L&-1&E>J/9CT43C"WX>=7I/R6W+:!FP(0B3PW!I-L^?2P=33*#$3
M;(V3P%(1/:L&D)@]RI`Q5QC&4;3:'V@S8&4F6"F.:3<NA.I/;B^QRK$>DAA&
M0QT+,"5C#H]55G,54#1C@><M(3I4T.6&NA#W3F'=P6[I59ST+W%YQH.2V9JJ
M,?(Y)]6WNKK90UJ=CM28RX0G9SEBGR&6K2:]0QY!"KCBL%G`2UIMFRP6>9,'
M;PW)UD(#LC169"#91@L,[A^NN'"$S--3"0M6PV,,>OJ!<Z*\DV;#78,7R//^
M<_FW'<14Y"1,--_2TI*FZ[,>S:\28/Z<\_CH_K!?*QZ)X&7B;+PU$<DEU!-L
M<Y4A_'*K;W)SX)O4,,=*@B]E#TV:MWX"&`E7VZL][W:[&O1Z@SNJBT27T3W1
M*.)6R;PCB'H)7Z-\*B/@V!--MPB'ZK\Y_BN1$&IIUOC-V1'7V#@]C'29J%I:
M+K9(TLGK).T>V05AP`@SN[#PGWI#)6NXWB+6FZ^B1'J#BX"%?BZ3I*\Z@WY2
MM?IPD5AA0>"Y2EIIMW<OMZE6.,))XR7M3WJ]FH2_8&$H?B"%[:OX"!"]VT:N
M@JM(=<=ITKO2ITXT4Z237"RK6>+>`MVDJ"S5,RQ-H.$YVBQ:*1RIELDG*9<$
M1S'PKA8D"_*56T8[%EA12&@,]<9Y!IC8_@7P=,XF[\1]-E,X@"6,L8`SS&3&
M(+`';4,FK#;'.E0BDM[<IV<'E$0EF+<77!#FOK)ZWPQPQZTB1]LFZN`O77LQ
M>MDMV-,J`<P(T\4BF&P(U,N](\0*J!2(X-;$(B?#;D;!9*S]+,.?RD7@IK1@
M!J5J^.8_7!G$73X0E4ZM:^%7+1V3'9IITMD.T5'/&OVQ\/A?VSQ3"['59<I/
M617[@SMU![QCFYU(8*WU8@")HHQ++L$>CKJH#>",2CKE@>[`2\US?P]SMU-7
MS^7&>KM_=GYX<OR82Q'H_?1@T-\EN>/<7R!N,P4L7A.-(!8;W"0>9E>=,YV'
M*-8!M!!7'.N)=[__H9617E:2V8>`G:9\^$_`Q6XONLZ??8XYF+%)W6)OT=VQ
M<X5R*C?G3D'3_@!'-TYZFLUQ;TSD;T(C1Z%Z-L<RDJNJC4HPIJ%1+7#V6UW&
MEZ8@*E"M3O`5FEDW!;%Z\*YK0*,"CX6H8==<33D\I1-:+3/TA277%SB4:QRV
M<N\F`:G4>)\A[:"<<%I`&K!.M727M#Z4M;*!_`@RMV?&V3CSV6"D[J7A(R=Q
M1;+L+A+-=$D468IC(K`YCOQ!?2#K'H\QW63U%<CKV,E\]/6D3XU*-1AYC;M8
M8=3'-H&8&L>N[`O7IPZ0/O&P'G=%6B+:ATYU;+35.F1W*"#<OL:K!H#90JM<
M7'60CFO7[1J)E'&GO*]P.<TY<^[&9]8S7$(7!BR<_R?LRK)>KC>,F*%4?WBE
MCD_>>7J^*I;KO6Z-+EO72:T-HA6IZFYODTZWA71P"5,@9HG*?(7K^6IW++=+
MQ'^4W*4R.@448NYR%0OT]D$>)P,L1A(^O(.GCL_10W4*7ZTL^%/%>$MR9Y'D
MW<06`?@\FNXGX<ASM!U'E`2SW!5NJHQ\V%[*C%`)442N,<<GWR.>;?<RL6@\
M$_D.W(YCA-K)A>>S3QEV+3I-.;\/9HP^QY0Q#NW^/Z..\7/-_5D*&5GV1U;)
M8()=Q(?4929?L447*Q88J51<)0UGP\9ML2)B"VU)N9)%A1LK[2)+#V]U+T<%
MA.IQ6'%*CXB^KN,N_'.?C*LL@$W&`D8X*&2@7,:)2O("U$BPEV)%-V4I4=R$
M"_'BDUB:!34@179KY"4#XSW4M=$&F4@+3@*UV#(IH"3UT\"*%;`Z?`-/^AB%
M@"<1=0\E[F/;Z6M`*].K_,3($[;2\OF;%V?A:+P\>K3EDH'XDM:1:DSC1J63
MRY$17OVK!E.#/Y.@5R`<T)`]NDKO\8/X.;LJ.M`9WE$MR1)T+@/)-,0,!W=P
ME9+FY?Z6&,-+/&Q?-%_Z1//M[M&;_>;KW5>'>\W"Z9]SUFU"C]O6-0@5=L*S
M?=6%^PXM?W`(0?RZ[B-;CZ>!*86;C3"4^0(%ILOUPQ*C"C/$YHA=A4Q*V(ZC
M*[2M".V^<-&;%TV.+PX`.%,K$$+=/*$^S4+6QRSQ#,RAOW;"L36%8VLV2JZZ
M:`8=_Q02".1#%,AZ-!UDQZ*W3<R)[4_R--).Y:1T2I\DC62^D[L?L\+4NZ9'
M9"4>?F'\WXW`DWF^2O_3/GQ(]&.^WKI]+")/N`_,K2F^JVWYB7FQ"SCMG!Y?
MQ'VCB@'M>^VF?J(M?N8KZ/PZFR'.]P(W`&(OV]DW1-E4B2:?8X1UON4-;ZJ/
MM1W+$W/ZC\^*:Q8D\8@GR<!924_()^UFUH@25?X7+YSLDV,#^H:`/Y*QA<ZK
MS/`U$'AA]].A)1:6R<=<(H@=<(-B/G8S!#C:;W?/2/'L8465UZ&J%A8\JAS`
MPJS`(;`7)XB*,T$K6H>%0R#XU^C2!)]:D(.M9V_3$(O[$]6%=#G'ON.7(V4C
M>35X=S5[X@W3=ZV.!O3$7!3B4??.A<'DP1GV4UP:A[ZIISWH/$DLW']H3Q(J
M-B!TC*M8BA\<XKFQ.QE:$&H;S7"3')-@ZK(S8:$=1PRV`8!&1<FCTJ<=D,FU
MY>J$+I8/`;'*1B)A5D0;M0!HN%"V_H+B0R-5/".3MR4\/1JD&>;2=Y(9(/+"
MQO@P&CJOS(V1>2.+(ZEMHR]=9W_GI9UQ!JCK<)]Y:9<M\\KE[7)&&NH^>6!%
MX749$`$W@1!<:N#5/66M!/D*+=@1F=>>[F(!_Q)=;JRQ:9??)#1C44B[H\3)
MZ6),I-1>V]L<'.]V$A#!Q_?.DA@`$N!#@<01^%X4D$V5ZD+GRS8"6BYSZ*BC
M`2(?X$M7%CG>Q(@&9O%0$Y?;4-:N>-WLFD76B]4\D1F%+C#0G1_52/U,*I#(
MQS)FK05Z4MPIJ]^Q7Q-U=_'W_)[\Q;`C=B4;"[$<.=%+5:6EZ\Q[+XFR"R@6
MPN3`"7/OY(')B6'*CLC-QE,\I@)8V<0^%I0^2EKUE(XG5U<Q'#%2[X+\1@L]
MC429[EEF`"#IAT9H2EUTO>VF[2@H5+4MP+]1]`+."Q$*?BRX-#!HQM>-C@`<
M+K@W@=]((QH+>0;#G'L/!I]W[QT,1X./0*9423-6#&?!R`S,&S:QCC+9)$^A
MB3A#&+//=X&;(-G#,G4B>%N6U$F_=Z]0,R3A[F&8#!G+;`>=?F+G$2O-Y52;
MY7>S5)J[^=)*<S=>I;G&=F-K>WD]4VEN>6-%%YH[]V4=$E524Z'JK\*C?]6N
M^ZMVW5?5KH,;@C*J-=_OO][=.V^R[N*GI@V/RKYQ(FAP1B!;4GH/LNKI^C%$
M4*]:;9H8$[0:K"+@_*3'^$)'C\P@1`%#M8:HB4>3/F4K(I*R1)$Q%K2<WTX7
MB7B'NW!P&QY3#/:C]S5Q*M3=C"8%?<$IOL:<Y4AKV9AP>"25P3'"E')<TYI9
MR2E@8A(CG9[;5A_+G=M/$92>DX6('ER04Q1.T8#F()!.DK;A:%)N%/B(;@\"
ML)+CF]T1$L%-L[/D?R;=4<)Q)3&?#=M\-UP.RL]"BA#L;C/"^(;1)?6"*TQ+
M_H0JVVK<P$)D?#HZ\A]?-'^$W[!2`-*2KLXE0E#P%D4DZ4L*!NNJZU17<!((
MF04,S+4WDG`(FPY08:-(E^HXU8)@#"M."UM>R@.#(_MO7(?6I1"VT3T;'$M$
MY#@*MMMCM3'/@%1(A-\4XE6NZAQ?:+..L0<V-*TOD5Z*4X5X7(8S5QTJA+]H
M<[IC6S;FX7EMVXJJM3@8)!8EX2#0D<'M`-=R\8@'W4F&P`:2IUA+K46/"$>F
MHAUA/`'J@EO:TI6IR$":R=J%DT_=*%>=0DCG^>KBU])DB/7Z>!WWF)X1[38)
MJ(2S_!'QXOE2>V%)\:_FP#'N$-H,V/#KGW.[%KB->(G:`3`1ZK4^PH6G;G]8
M!-:,2U\0',$5_@`%\NE=&XX20%8TJ9"1KST:4`<FT1>_G,(EN+]TO00@6[WA
M30O`"I%.`Y\`M*,;VJ(IO@4CM9T-.B&5PQ:W24O3K8"TPGA>=J^[8]BD7?PT
MCNZ&3"5"K#G%EPZTQO7F!=;5[1W4C2$"[+(AL%3Y*JIH<P><30W%6:DL5R.^
M:#J`<A%N98G)Y%-*K@K*-'>TA"`X+"5+0O_1(.=^0-1W<D=-;H=)I[SD#WXQ
M&#WEC?+J5T?FP4YUKI>,P5@;'DJX*Q<B8[>^267>ON5*@C#T,>MIUU3D42AL
MX1E5Y`0PNJUK8F<X)H`\";^EPU$N;F0UY',6PB0ES;^9B%`['"2:,.S^\^4&
MX^+!:$\VRBF&>G&1$P8)[P?E5*J:A>J+O865-<FX798YN0$UL8FU)#BD#PP.
MIR[0H?KX>49LO3_2W?CKZ,`=RG'F$0T>NPG17"K$['C)]`A^:+?+EIDVD(N/
MW<$DM6[39J$E"81R[NA=U$?PS8PSK3*;SSM&#'X?KS:;T.L:F3]]H^'5<IL`
M8WW/29LP39Q!B\RV`^U+6JG+-$6/Q90:[Y$UT)A-=T:G`]>7$:KL#3JR)B=<
M#T.[,Z<H>%J\K,X5X-S72VJ/;\[>?<#TT)(.4"N@5Q1Y2J&5(Y4`_=1?9":H
M0^Y>?&DR&]!-Z:3ZIX$@E**S#8\''H3<0\#$8[:#D'L(^+9_^$'@?8X9%W.(
M_.R'K]=*Q\[Q3?KDT)^,PM.!*^?3H%;J<-O`['U,B-OPJ8"WK6V3HM7L$3*=
MM$\6^R^\JYE#^<DB!O\`[J1#7!\.`:0D9'1C.B%W<EW!Q^-7L/X.Z\54CI&*
MWK")\[/3@5(39+ID+RS3V=@199R2N_?LXNAE\_CDG?C#?)XRICC5<S[2Z;5[
M`\SW[:59G#[R*30E-@UT$2M%(NCTQQA`[&,&8V-@M:W<![:;6FD'-0A]$98H
M`0-L+=#->Q2IX4)+6E(?EAI@!NLNNG^BC^A.[7D<N_300C&2_2)U*MR!NFJ-
MM!A]J%O.O1:$HL?/'OP?,T2$%7,GYP<_-#PI`MUFT'-E[,@)+,A@Y@P\52U)
M=L"D!V8CK*CV@$4F'X-J]9(P)MC\E#K.0&C,93)&@M<9M$E0(KEB6QTR..\I
M061W4%\"9V!:H])O]R9P:'\$>G;5O5ZZ>>X^1-,]/2(MREX06&<G)A+Z#U81
MX\75-5_O_OWD;*Z>^_KP&%ZOY;R>FRN5(N#*BXUZO1(!5)Y_(I^Q<Z/+I9OE
M`J0H&._W3^(I-F;@NDZ($PMB?R6!5O)]L"J`O',CN@S:&@W2==DJ+8;:@_(L
MJ4]8QQ>F.=+CH4O.*+Y-!B9`=B`ZW;[CCFO<,C73I3UP1:1,>AT=<18L0Y,=
M=1/6X>A<N,6M@%X"(T#A&<?($7@^*UZAV!YZE'VF^61@^M_2*;59$A:!V-J=
MCB6)M.__Y+FZ^:D[=0?>12L.]HM`>`7?!="N922=E(_=ON;^?'`A%LS92`4+
M\AR92J#F;,W&(R#Z*E)AH![[!0H\7OH,:FM!(&UTB%LVV"TG>X=T_XEY<B?_
M5ZCKK+(X*^I-'94F7H1\'3K@R(B-@`+-U5)L--'D#GX`D&^RS3;("4B(`/&;
MR'B/3`YX?6Y&R34\LWR@/C]5[=1!OWQ([N\`TZN:"TFN;H%TH]OG.RI-(Z4Q
MK%[8W-XMY,6!C\,-XN3TE\;3GQ;:^@(Y^;1%Q]!FIVJM[&8W:DI_CQ^F7-U*
MQ`_S!OLEM\/Q?=4'[033ZJ]$-\E6D"DV*'NKV>V+Q=JZH2$N&"8Z^J6L%3J[
MEZ:-`>69D?&\8R+\GG.08I^B3-:&(KW<WSO:/=LW*2!=;R@W:I!,UG*ABH/J
MI[)Z+Q512I^J*MO%[:%K4$##89G^/G+Z#K6W9'!KG^)'W)&=VD\Y;<6I5G^@
M6Y8GX>C*^HZ3Z!1#A`Z,2XW/-(@?S9QDSL.]UQ3&AM)PFTAOQBSNW*B[G1$'
MC5#L!'CY_:U'#8%8]D#$XL-BW8%)Y!&LAB.XA./>]P$\#:NSKTUC;[T3<:#1
M^"E8'KD>?$\$-C:'A@7LP-8[_Z#X&G_-CW":.RP(9))'BIY:,H_!370[2,=9
M&TFO)V<_]C$)`HV^&AO>3..MY+:[<O4.W;CE*?^+./D=HF>T#.[5&1^&];[;
MP5[X=R$Z1J$X`&3]IW[8=],CE@O5$O81,1'%_?7M/R>=`['#(`UP.G1/,2,J
M^@;+&=1P@2.I\.2[CO:R(&7;3C1;`D_G^S0'7NB)63(<LC4^!:9)@P*.W<6W
MZ>1\*^N\Z[:9IKK?*0094VM,^4"APL+V+=*8\15.=R6B3VC9QW7X>A<C49..
M8%VCCD#V_117(]MP[C5LW]\G?=784(W5[?K*]LH:>PWENALYG2\F";L<K:OZ
MYO9*8WMMS;H<;36JC;JJ\(__^J]Y)8DX)GVT@S*?I5+`./0@TT!5B1S"9)^D
M6/V.Z4N/#:8ZO=SVG-D2:%>STTT_I*V/N(FUE_L'A\?`AYSM[YV<O6R>[__\
M9O]X;[\)C-;1_NO]XXO="Q#*T4]-0\7`$?U[=;Y&A1=O6Z,/]KM8J+.+YS1L
MEAVB?F,><-DMYQ--N/%O3+-@7<QS5\#3+Q'[]/2$F3'3$WYKX3PZ*S(]Z?23
M2DV=G=,V-D7G]=1YNFTSDW5?YLQ8S7.@Q^W@(TKB+1L\;,-YC%T!A(Q!6S$S
M#T<1T7-Y>;VZIBK\`]%S7LP")?)=>0;,1*]GQP2\<$U&],VKO29',F)+&WBJ
MOO&>RD,EX-Z?G^[O'1X<[I])B]IS%/#M%\K<XW<>W<HRC8Y^X.CF?H?_%ZG4
MR6)!F28D)'))Z>7H.C%-9M*U.8[%,*-'(PL&4<VYP9GR4-'R!TLPRRQVJ"M5
M<J!YK#5H'O0#Y\'?8L3"7`QPO=[+S'6<#[U$3>JD+RU,%,^W/_XMK=FYUS_]
M[=/SA2I-#9:D]OPV&=\,.BE[^5;I$=.$I4F70H1S&A[]M+_[<O^L^>;P)1;C
M-=W*C&C8!P=UA<$@5U6U$(SCNC>X;/6>+52SL`$`K</Z%JT#_>!U0(6T<I*W
MJI*?N;66^:J>;V1>^6T+IZ;81:[9-N$MU)M`X74'-SPV^TQS6*UO5M=5!7]L
MR!S<PL!*UP56/'1;7*8MNJL2'W1*?1@YTZJ"1,ZA'TU<25A'0+!1BX+IF@A!
MU3#C2T]RD:8N%?2_*]HNZJ.SU61HS-0QZ7;%`[*(8A!`<K!R)T&#K<UZ=17P
M8&NS`6M)MZ(.'O(O,S@380"1.]%Y%;ILZ[?DVVW^6*!Q/2+KD>/A;-_/RGK<
M1%B/]5E9#]VYI]0F=EY9WU[9M*S'YB8>-OJ7&8_(UN+ZUJQF5'`THQJ=ICNU
MA\!><'K_%^47W`(<5J.Q46TT5(5^,D_TF8Z+49(P<^+L=37W_JM9W8<FR:0Q
MT2`^>?=\'(H+9/_"@6.4*`ZTH0/0Z6EZD2Z%VY_ZGW=:P^7C=X`'T_J(]L6=
M)3^*3=7M=W(<ZZJ?QGOG*JRF[T@E9T=<+='4':E,VY%0K17IZJ]P1+T5Z9.[
MR+'1N_V*%SG>FW@W_(^2%E$&'8>CX5.C1-?R];2+ZS[E"4WZ[12ZI9M1F,7K
MUKU26R#V;#<V.3ZCB&IY76V$!DA,:P[-6MO`BP'^Y;O5F#47X$:^0I*W0*H4
MY%#?\J.F^/J21.]TP(CD02^!'J151BO:3[MO]UD8=0RF"Q(YLF"TO+`OKB[A
MYU:GV>I\[+8Q_?S5H,H/0.3_V!HG?*%M,D7;JN,/YJ+_`TX@?]7(6A2.90;#
M">1$3N%7RDAX[O=9')$KSGE193FPM%CV'A-'X\KY(K[$`'A_8`"\E1!?[)X?
M[ADY,2L>$CADPN@7$<P<\8D?>Q\W&?W<UAX!H&81.<Z(;\%7U=%>$]812[>_
M.#K9^\>YJ1H_VS!,X^@HHMMAKC"X6AO+=;E;/^/]914?_I:STMB\S&X\82ZB
M#/&76PBTLKJUHF4>I?[X(R]-#U8B$3%%J>^^4SICD->./&VIJ7KVC+E+:`4M
M).Y,!G-P<O9N%^Z"/_[@A?':8&R:VT)AB^D?4QE`AD*ZT'#B&_559*PWZAM6
M..`=JY$BM@:'_@[#KK1Q^LIQ.4O5W0UZZ8C_-GHC8Y@!`6''CL%(^V3O64<U
MM-IB9JQT@!7^R(`$0'4VI25R#"&)M]<628/\TLC*K4IW-]WV#0Z'W+!\@_EX
M<)U02!3&;`D(9J[2LKH9],A_4OO"B0)4!K_GY'A1ATRF.MI?CU:`O_\E4'`]
MNNS2QR[EN#A"7&OH3ME;<-:4O%ZP!</LW?.FF+7$SW%?DV""/'%WS#>P*`B;
M!1=DF`N\V0V2[#<:JW:ST9*03BYQ6.PKU$K%H2C=9G%*8Y*/L-OLF\ZO7#S=
MUMJ'$F9T0XAD.I282VQ9UBTN?`]X&+G!$7*,R,,>'"Q/:'FMVEB!&2UOX$^9
MD@P*<W_L[Q[/-B[,.H)>[OP7=BUKI<MY][8+[7&GHRNA@SN,X[P=K%;/9$%X
M)[L`@(R9C<PR=8[#U8$'K;[2*<-A`AB#F[3Z553]`%<#]R6F$_4W,D9_O.W,
M$I]M=V'Y]<'A^^,WKPL:/&C][2>K_B/8&`QK-"HM[^6#]JFJ'_LC)^@S[5,1
M`!E='/7\W:AF]IO/`&?_TI#0O_2FU;]&1U)"]172XFRL6FW6%!)?O."FN5F_
M_4]`<-!FV_V0%%Y5[O##2GI3(.6BO0]'!HZAMFC0(@>*UGB,_@[B*ILF[M*E
MK?N44D.GIN^_H(55DWVO,$\A7":\F)NK1`@W5QU":$N6T\6BRYLS8823]Z_8
MM?B]UOP2"#047DG%B>X(2Q.:8`VU8++M8_\%@,]>UBU:?A^X>S/H+VSG(#6M
M^0.Z>PCM8E&(U'FHC#$!3K<WQR].WAR_!#[D[!_[9WQY^WN^:#9<,)R9]^7J
M2AVV8&,5?Q++-6<U[_E,=L::DL,E^_NTP-RO0.<636K1E!9>`[R+FH,^R!Z8
MXA*96HHM<9NXS*U`HKR,`;^MORAZFLB'D?U_X*0\SB%_9B*J4;.J<ILY;'JL
M[6SS=%O-.F?W,U\P<72SK='G"Z9-:;0B8\Q.VFGY=%.V'_F""0,?T.IU6VG!
M='63:9,U[9YNJOH34X7)VEN:W8$YG%8FC!U-3VJ$D3B945'*TV]F.)*A[)ES
M("NSC?\%G\,C.8?Q2?BG$(81E9:CQW"&F7GK,L,<@P,XXT21"-=>R[F+3],]
M=5,FZ1Z[)YBB=^!FG.!;>\[BT[.G;,KD[#%[@JDY!ZQ`3U*OHX&G`C]7Q-##
M_WT6,8#DPSRI+M,@7UKPFOG20N9UGD@1:93/R$IP36FQY/D=+99CQUC_5*6K
MNP[ES6,E$FMZX.>R5?70RLP5+4ME+G^R".%WT0>AA9DV%\V7_,6U#>+<&VN;
MFG7W8&7D*.]M1HCZFF&Z[^!4[+XY`A'JS<&!M]315K@S,!#;C&:VM;Y&,]M:
MW_A?-#.?(^7MN1PEK0^"`5N;&W0\MC:M0?SW^9DHIEJ\!&32`M-4(W,^Y>6K
MU-B1BRAT\"U1^6B;<D%/ZN<%I`P&IB0'O<3)U)X3NBZ18N&9V1S&BJ.3O=TC
MO6Q;Z[S96XZJ4$!HI\$69>[64221;^F&HK_"'*;^DU)9G%W(!I51=,)A'@RJ
M!$RO3::A.W:_/0UDD1<K[0W&S6$+ALOIU$LFB2.,"CKMH%GC2C6L6_RWZI=)
M^\,W`.+@_(`BX"\GUS7TMP<R?-GM=<?WVK^GOLX./O7_2P=CN0X[O(ZC-CN,
M*Z8S^J88HN3IY]!/=8AB-^I$U1`X(=E$<>%%QQ_>^*\_*FK&L^)_[4&')?\T
MG)^\W@^.!%O5EQN-%=IH_DG&,VW.JN7C,(Q`Z\I=7)Z"R;%>,^*ST]4.?6V-
MATX__[?@:/ZU1)F!FI.AMW/-=JN-9<AL/G=<F*KRJ8IVA%K=6JMNPI3YI]S]
MNI0\FBZA`^M/=[Z:(=!@&06S\'+8JDB;?-@\9/L%FN3F1IU.,?YT_=Z^\5"+
M@+H&+8T?9>,+*+?<%YQ?AP-W9,;H"?:9]=@7"\ZPUUDIYYZ)G6([9=.8?"Z[
M5/56==6/BA?DI]WCET>`?*]WW\/C2J6L%Y;]Z#8WM'//W&?_J^E-JS.X2SKA
MB9.5S",'[W7*?'-D:\]I@OY%%P%@IS0+%"T$.#Z2*_5&@ZSH\$M=.P8A@I&_
M$>%7R\@NJ7O.M+F.Y):?QV7QO?L";#%"31&E=U4+#\`05V`JPHVWNV>[1X>[
MYTXSZI<D]!GXS7F3M\W0X#&HOAY++L7/W>G(@#2I($:,=WQSL[J%&[ZY7FTP
M'L,53P;9WH!RK:7WZ3BY13,BIB2AE(G:![XU2C$Y@4W,T1X,$ZG:IAO%]ICO
MI.O)F/P-!76:*#TC%XBK]CO]7W3OM2#WF7!M?>MS-<[1H$=;A2&1D-_TEE4H
M://P957E0:BR4QSGK5"<59Y1OXGI6YI):]2[SW62-(X4V:=9#5-NFRQ/D],P
M))TYS=R3@QB!J&#J\&@'%?IC"!Q><\CUD206XL7DZO)^G("(K1:X[ME*537$
M?Q?0YL5@,(;];@V'B#C#T0"P\7:;O\&U"E-MOPD_T4T9'QO+Q(?`3]<_.1^)
M%@$W8?S?Q9%)J%RQ#&%I%\#*E2.TU2+37%-1O%6]F)&R>G]Z?'%F>Y35-\]D
MEBOK=.H:JT!F-QVE3,%$)Z,/,-%/MT3F+`W%YV5[X=TFM^TA("4\K>:M2E6%
MG:=<27;*V#[_`HJL$7>P=XU'L<B_W-;40A%1.C+YK#BUQ=S*8CYQ-RFHIS6,
M';O9NV5/XNQ]P\,Y>T_OO,:<Z%08I&?*;&K9(RPM@`4%%H*[X^>Q<VO\/*;@
MP;?)J#MN`85/QLFHI:-5`&>WD&U>::PO5QM;A+L.?$\31[G!*.<%GPLW^PZS
ME*8)TB"=H'L&\D/!$B8.9NI_<*QZ.CU1&4E6U7'P=Z(<Z,K""(*2'I=D6,^N
MN@U4"?)E4LT9&ZS^M7.LB"$T,@6*![`5TQXV?K_.3?X8=3A&X?@BJQP=7Q`O
M"@3(':=;/X>4L(QOZRN(9X!PFQO5E5711-"=7#,E.#SG02H`B,_+\Q73@H<?
MMFL>W@Y[:A'SH&J4]/*XY!4,).CE,'-!T!ZANA4#XH/,Y5SQ$SM&Z\(EN#D'
MTN!RT+E7Z;#U[W]S`')-*E]!%^1H/W']Z&^>@0AS_`OZ)&;?O#G>!Z)]M/^R
MK+&9AQOKG7WC]*:M-_)A9!C/%5971/FIN7OVZISSR+"?WE7WDTJ`["RUL6,Z
MT-%A?_P1COA'_:#;IP>FA%YDY`_\8(4_&`#Y43\P'U1S7+BU9"\T?]VE)72M
M.S/03X-1A<L>=`Z>9CK3`)SQZ*%\(RSLJ2,"^I4K@4#9?HB5-$S\'J(N_,B_
M:33-FTKROF0D,U"I2`T\6T4NF[;8=#%93B0GC+`NL*)4'U-.6@Z)&F1(T[P'
M(&=R!BP1L66V,ZVL&+8V>ZR9SR,7S90D,&"4T4TKD0(#0ZPNCTF>T>$4YV6\
M3ID"X)!.7OQ=E3[T)I0SGN;.!<BJRN$^X@V/M!.ZHT(Q]BL\\W'FEF&4O9A1
MF.4F\0@K*QM5E[WEOE=9/C;4VV@V]DJ&HUE6ZSIA65":2K`+HNKP5N#*YURG
M=3/K<955EM0>^FU/I_6@KYN%^?PHX7/WMT3^<H+G]-NI(2C<;.X<T/8U\'0K
M=0Q!65W97EN=&H(B79V(_49C>Z6^O;QE0U"66;>FSTJN5%0<.J<=QF<+GDOZ
MDUL/B2G&E/ZU")SG!F?^@R,M?BQJ3[O?JA*7RB&UB`<GZAI;%3CG%!",V6!9
M]4(Y(L=RV!T@H5]KSF`\SCR$$=,_5]74@50\(+YW[&S#J$2&D853.(C8DF:\
M!JH.$!<`@[R&\Y,:G\.6PG.6D'^F^*"&3J?LA+M%>27@QY8)H321;Y%0D=*G
M,G[@5US[TI$--J2G\IP#2,0;3"*FL0G?T(E)4UE[3GXDR0BZ51`<[YT'KJ+!
M:6<7]"YC8+:SWJ1GSW(]4Y"XVV#`>+A)Z6-9`;"Y4BFJU14=AKDU/I9A$%P0
MUX_\S$`OI2;@D&AF&E#683D_U,K[^-2P*Z7]93A;R)8.)+,X-E^3+XDS^D'S
M^.2B^7+_Q9M7AKX("?)W"W>V2)GYS]]V<N(]HQK#ZC2'M=PEE=/@+*J)XDPY
MBC,&,4Z!Y>T\NTOD[SK]2S<VG$#A`+CK#MQ9Z*7-39;\`!]QT18BH?,1VK["
M0!V8M%.#_G@TX"!._O!E<M/ZV!V,3#R)5AV;J!R]YZL2#LT_R7`;Q7>]?`;9
M/:DRJJ;6.(\H;W&]R$6I=%L&<5O8K%().8/(^I2=T-<'0M/;ZASK*`3MN<0@
MS#C(EXF3GBPO^>%AKBLR1]0]^HEQU7"S'AO?Z7(61\C<`^0:X6<\11[L^%%R
MF\SKQ"NKRV2YI1]BEUD)UMMZ0#_1:EO%Y:QK[7I^3O?'S%UG:\N<<94=N//$
MRRG[I,G9M$9F:<4H3C]D:5>#I=6*UR=:6`U^UF6U'J?37*USEU1;$F=<4`,S
MCK+ZM5E33G6Q;')=P)H:Y=NY*,$H=.UF<(="K0R3TB.Q\MA+\O<O[/(]FA>I
M=$L-?8NZMPDG$'(O_`(=8)AN;39E("O=PGX/U&]K\^I*M;&*YE7Z:>6(Z'^N
M?"TGR,E,9@1!>XM(\!9SB:4>9Q!J-^VP-"4G3HMXVU^MGEM-O[P.X>2,D^:>
M[0JB^^\S6F?UI8/EYHV:%RVV^/)71WGOCI+,NL!)SPDO_JM%Z`?/]E>6^QX^
M5V:=]4RG6(_KSO]@]+IW?&HY:R(S_E6,-7"VFIQJ&.[=GFC\O],#M.8[_01O
M\@Q6B/?*3*LE:@:\V?^/X(@>KT:5&*9\Z0K\.7B#J/)%R.)-_:M0ANTK6VR*
MUE*L90J=(.WL\AE1MC.`N7IG4\46.ZJL*._0`CP,A*L>(`"R?([URQGFC@C#
MJ$N^H[3=I7HY,T>K>'BTF<94*E\TWZQ29-999Z9-&[[*'A:KVM$SLMW">47&
M9$\)`7=GXAZWV'R,BD/EJJX,]!WO;$3U2V';+\""QU"GIN@7E*]/E==3%:K2
MSB3UP42F*]O+6]L@CT[3J.J^[Y(.JU0W5&-M&W,"+3LJU55*][8JISQ3^?67
MU^>'QX<76/Q518TQ3IC=-M;;DAS,MEJY-@!E&I(],TG_V;[YS6E.'.)^:]3K
M)I1#^F-W-.A3I(`IOL?E'U4)"^O5D/OCBG:3/OU19C^SQ]A%X-8_Y>XAOYRV
M@]Q*,BOUE<(,<IB4:75EVOY)SVP>.4<AOK&)NP?_BGH"L1EYP\7;26_<;0Z;
M@PFKL")YH=7/_(WF&'4>S2$PQ>[;`_^M'V-=U'9*RP2U<#FM/?T;<>DHL'%S
M+H8%G+2%8'A[B2A8I-R0[N>DO;@C1%:F(DE:R?^190Z"3%^CDC]43[C;GF#&
M!P37:J-I#1'NMDOI",:<R.5Q<&X\&/0N6WD)E,W;8JPSS<@00VC74,M8J'U[
M;;D8[6S7;.KD58MWZZO5#56A?TV.I6DARP*ZAEDI%ZI*_J0DE=5,4++W5CPG
M6CTQOC9%35V-A1]KILR%4!!J?"&C>AD9E1=I^9!A90(V<P:5'YZYM4H"(O]X
MC+2T>O4O)^,Q4!0O,>WX,I:%UL_+:MN4M5]!)N5L_!L1\+/W+1S$S,EA'X"=
M_'T'$_A!/H;*>S$P%/0JB(_W>\V`K2]R1IF/L<7#G!YAG!DBX"X,\DUV[6I#
M&->!W[XY!+8U^ZA!_ZL#"1;_@#6RK2ZO^3$IX\O0G6A\.3U\(!BQ67<M>V87
M/0O;=[W*KH'NP4FF_5A&-N@?G.V^WE<E;'(U(M;W2I1`&\M;E%1M>=.;+3L/
M7M6>N[3BG\-!^ELFZ"9"5-3B>(;("H\,Z<SM<^'":,HYX\?B:V4IG:Q5I_8<
MRV\ZBRE!GC;ZH+'"7"G\7)8;)I4DQ-(KS[L^MJ?9MWIB61]8KSLF*LZ@-N^Z
MUVL9I(Z%Y9?XZM'N_SC3:=[.=O_[CAB;R':N36$[;=="OG.EP<H!HQO@:C,C
M3EJW*L7(T@3C/17A/>?\N9<*MEC&LG?O5FUL]3D3G\98Z'[_/<"BLLUHSFBU
ML>9YEV(5T3;?'5.P0$IDC@)2>MWKFW'OGA#6:+"_`@[1T`'TO1UTD/U;4A+`
MDCD(CY6J66R7%[I$K9P-Y$,YH2'58N$/I^H.U[L#<^JU[J5^%V6I7"6C)?XH
M3.'L\S)Q!L4:X2].3HY>@#3_<O=B-TSC/!V2;\WW8>6D<L[I[_;-)'3.Z?-J
MKYGI%J1USNG).8+#N6?2,^?UUDF&,P`B*9Y]&'E9GF?9M$K^ICG9CF?8M,H,
MFQ9D>\X!D%G^;,[GG)Y%.Y`SFUCRY]P=R(7A*#SI#O=!R%T.UW+7T052FF0*
MG%O;"$ACRJ21,I`2T9,<I..;T6!R?1-P*RE5*J(](;+H#HTI:9H(*?5HJ*&?
M21>ALQ<356GG%'`SP]';&H&#9#%#-)-6BFGO8P229_28)-*5\*D&*2>+(\\<
M3*H_&]W3''$>@YNE?2_>P"DXSJ-^Q?#B%%!#G$(#,S#\_KET,-//H81.UQQ:
MF.GM'R6[&KFT+`LA/(\.D`*:J.%,HXK3MC1+&9TMC5""*5L:I8^9+<VAD!D@
MD8W)IY*9WL5[DSNW(EH9V9L".(%M'$O.Z2;M`>96-M('T4ZU")(ZJ?=T*Z"E
M2$_9N+WXJ?HXS/2XU?M0H$WCU]/9:6X7Z--6M[;KF]/Y:>E;J%!#%[,U]C3+
ME@2Y$"#-USKSZ6-5!G$I*95%18MLE4HU7K;:'ZC-Q;BIO5UO13Y;6T4W?O[A
M%$[+I,;7LS<`9DV2[U93LQJ+`E`%Z?(+53X(LB8@19WB?F5Z+&%TGM6<05?5
M5'@%6J(H+DQ1%M'\7N?/+ZXPFG$NT[5&>4,NR$NWL8ZJ9?[Q6(I/#W$\U6>T
M_I:O=!S.IOCTOM'M;/^M8Y28)41(_!0<K>F%L1X$KFBH#ZJ=U=BDM$[X@PF0
MZ[T;W4:U>)M>,S[/5D@K@P=.M*VK>W*GKO5/!5JFH'E`U3ZV>B;IS?(J%]1;
M*:*QI^C-/WHT?G5F&COD[ZJAI"%::5`6HI7ZK#16`W@$&AL']54T5D"Z-$@>
M/93&ZFXY@WY,&BNX,`N-/<V?7P&-G3Z7A])8.^1\&KN\MH(T=GEM^;%IK$:<
MIZ2Q^ALY1''X0!H['=RCT=CE]17R+UY?GDIC91O5(@SOBVBLQH,B&CNTZ#T+
MC;7-\VEL8[6^3*K[U7H]HKI'.$6Z^^RP(N^=JR&JP7<;:1V^R^=Y6GSR^_WN
M/.S7'#Z6-I^X_WQU/K^>40")1%:N3BGNY?0MU.AC;12\;^#'NBBNBN[NG1S%
MBL\A3N$"?0W+Q>[1/YJO]\_/=U_MQW0L#P"=5;;XP`O4+1Z&^0H7%T94Y9+3
M5Y0NF>X1M4L.!"N7AXL459GX4(J4)@_:KDKQ=@6Z@8=L5T:1DK-=$55*,-?"
M_8JK4W(@3%OS@NF6<T^/4.7"TV/N_BGW>^3TG.Y>7.R?1364#P"=<WH,\&FG
M9YB!$\+(/SW9ON[I<;OGG9XLA&`GG47*/ST&RM33,^MV14Z/NUTQ=)IQN^*G
M)[M=>:=GF`$47?""TY.%,&W-"Z;KF5["\]?\Q_XOJE&O?_W=?-?M=P9W.:I!
M_;+X7M:MQ,.V#[>IJM>WES>VEZ=XYYJ>;KJ#^O;*YO:JJQ1L;)(NI(%>GG@G
MHV:4JYD#$YCTFY3$$?[LP5)1SMX:5C@$$1,-\%C=KJ/X2Q@%>]6]GHS$=99J
M/#6P+'1=6J0<0>6R=6_Y3=/KVT2P&%4W_F>C_AO6*K&Q[?L734".B^;KDY<8
M9/^R=(=B;OLF0=Z//</1,5S[H#._V*`IKNB2W5FI5&8P/4[;[0H#0D_AQ/3F
MF`GFW%G%?#48-3O=]$/:^IC,(LHR))`-^)<9Q59I[,VE&@XOXB<F1Y[?%PB@
M[X)1987-&4<0")KA]YTSB5DPFR_1Z?[M[MGA[HNC_1)5/2R;736:EH;GVO3E
M`J;LHA$KG55^_^[P^.7).U6"QN6LX&?^\Z6X>#<G86),M%O0`UG(2'BLLN$T
MWRMU)T6E+NRA?44Y#9K?O\K5V?&_SQ'9UPBE4Z::U^T!,W^(,+M5)P75IBX(
M_'M$+#1N75:5)ENY.)PNT0KRN35IM0QKST418%^0=7`9AO/O9#1P/CUD6/Q4
M]QOJ=(C[%WK1/F*H^-"DA5A9J7.BW)7ZJDEIY-NG[URWP&"L6&K![(<9WU<M
MEGK\U0J6`*;$2P#C;`^&]^XJ5I7DQ>(79B'YN79P>DD>!]B$/)HD7U6JRZ3V
M*/4`AO?R]8$E*_'Y5:O-":E7U^M4FF]U;2NPEWE7UN/I<.F^0+,E+$MG?!,\
MNTG08VQ'AK:\A2)T!7Y9U;*TW$R3?MJ][E.U4A.^ZPTXR*7E!?4*FF#8U\'A
MJS=G="V%G'[LQJY&UR;@\N/`<SC]V%<<>#%8&8Y_"@S@[G/!!)S_%$C,;^8M
M7D8"R(&680_.]W]^LW^\MY_')]0\"`O:R3:Z0?+.N:VE@7[C7MWZE9SS.1MB
M$$$H#2"*`:Y,DHM<#J/^$.2J/`"Y`KDDO@.5J=B5E4^F0)H%,Z9,OQPI'68P
MPV?1:GL!0E0LRQ=?6;?%T1Y(/ONG!V?[^T>'YQ=>[QC>.*_CR%,)&<Y<#'):
MYJ!1OJ5A=7T+U<!`##?7'LG6$#M>4<:06\S,$?K-<_BAA9SO9QG"+!NGV;&\
M<>4T_X)1%G!MJYNKZ\BVP<^&DX+QL\T4JK^`8I'F'%+8ZPG<63\^4_0+LAU3
MI,.R5`RF![>M?NL:H%E&84IO+0_]LV@T(+W^9B2G#&D33VI,[V120;7Z7+;W
M,N&2\%(G':NI8)5Z]*>&OP5)_(PMZD.2##'#)HX1/<EUFCJ,8<5<I>\YKI]S
MJ;DL5$`Q:L^O>JWK5'T7GFD>-"^!8<6<(Q8IT["VLLZES>$7G;,&&_;U2BG9
M,/-WR7";[-1Z=G)RT=2/KLJ2]!WQP,+X@ET7=N:9R<<9H[*J1(PGYAT($<3*
MP[-B"B*+'3*BALS%)N;$&E4#VF+`@W'2UYJ/'?7?$]A./1C5Z<(@L#*U3H>H
M9Y/#@OO[C`D@FG8D=AUC56ZB&"+\LWRS%".ZP!PREGJL>Q/'4X1\<1*?/^)0
M_`GW;Y2DD]Y8DS0C%*VMKJ'@7UE;7=GR1.$K3>+2,5"O$0JI<++^EBX0&P&T
MB\.*2N_/+\X.CU\!)9,\V65//HZ`R8C((KYDR6Q!YSQ!.8!5UN=1,@9\PR%;
M;?@+DZ?Q"FQLH!ET;75]+3"#N@JIK!$T'R'"-E'S)[]"HZ?\%HM7DF_TNA^3
MIFU:P[_9-$HS6&^0*;"RME[7ZL?%'Y1<.`P!TU"3/`1HVJA3W6(3G88B3E<>
M94LHS4Q/I+22D!&`/3=-*]G]#<G.G.)2(D;H(XH]TX'MJHJN!!`8SG,VIS;G
M))?X;OKX;)IBPN;/CY3#5W3*<5.S?CF30CL3-[:QO;(^DT([8F36!FIRT:>"
MA\;%S*-L3Q!#Q8[&E.)13AW\-NAS'!<G)UNCF`'ZR4$#DN&"IJA,S2.`T8<[
M>R`A&W!_<(.[%J`YI0V@0>FL<!GCGM:ZAEK54+J/R_-AOYCH/D58SXCG.0)Y
M3`3/%[ISQ.P"P3H6"^!TBL0`Z'YYAKB\I0UEV[@TFUG:B.`Z353-"*>%XFB.
M`%H@<L9\]"-K%NEG??*]O!_>!:`ST5.:OI7EC2#[CUS\\*-Y6KHK2RP4_0GW
MM$0WE_!RI-/&*<=R\'\FU4%>WL,'`C&!5PINJ:X$4@H5X.A4E28]6`X0`SA`
,=?[_`;^0=PW@>@4`
`
end
-- 
Tonny Madsen, NetMan a/s, Vandtaarnsvej 77, DK-2860 Soeborg, Denmark
E-mail: Tonny.Madsen@netman.dk 
Telephone: +45 39 66 40 20 Fax: +45 39 66 06 75

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 18 17:35:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA00994 for xemacs-beta-people; Thu, 18 Jul 1996 17:35:31 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA00991 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 18 Jul 1996 17:35:30 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA16679 for <xemacs-beta@xemacs.org>; Thu, 18 Jul 1996 17:35:28 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id PAA28426; Thu, 18 Jul 1996 15:34:59 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id PAA28026; Thu, 18 Jul 1996 15:34:50 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA28344; Thu, 18 Jul 1996 15:34:48 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA25215; Thu, 18 Jul 1996 15:34:43 -0700
Date: Thu, 18 Jul 1996 15:34:43 -0700
Message-Id: <199607182234.PAA25215@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: William Perry <wmperry@aventail.com>
Cc: xemacs-beta@xemacs.org
Subject: --with-socks w/SOCKS v5
In-Reply-To: <31EE64C7.43C0A435@aventail.com>
References: <31EE64C7.43C0A435@aventail.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Bill" == William Perry <wmperry@aventail.com> writes:

Bill> What would be the best way to modify configure.in to handle all this
Bill> hooplah?  A separate configuration switch --with-socks-v5? 
Bill> --with-socks=5|4 (defaulting to 4).

I think it would be best if --with-* options only took yes or no as
values, generally.  So I'd like to see

--with-socks-v5
--with-socks-v4
--with-socks  (currently synonymous with --with-socks-v4)

all accepting null, `yes', or `no' values.

I once tried to add socks support to XEmacs, and discovered that it is
quite difficult to manage the configuration aspects, especially if you
ever expect the same binary to run in more than one particular socks
environment and can't/won't make sysadmin changes to all the machines
that will run that binary.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 18 19:03:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA01363 for xemacs-beta-people; Thu, 18 Jul 1996 19:03:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA01360 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 18 Jul 1996 19:03:03 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA17704 for <xemacs-beta@cs.uiuc.edu>; Thu, 18 Jul 1996 19:03:04 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id RAA32706; Thu, 18 Jul 1996 17:01:25 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: patl@lcs.mit.edu
Subject: [Patch] Gnus/Mailcrypt verifying signatures with form feeds
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.72)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Jul 1996 17:01:23 -0700
Message-ID: <m2wx01yuuk.fsf@deanna.miranova.com>
Lines: 24
X-Mailer: Gnus v5.2.36/XEmacs 19.14

Mailcrypt as included in XEmacs 19.14 does not verify signatures
correctly with Gnus when the message contains a C-l and Gnus is
`washing' formfeeds, due to the inserted text.

Here is the trivial fix:

--- mc-toplev.el~	Sun Mar 31 16:23:25 1996
+++ mc-toplev.el	Thu Jul 18 16:55:08 1996
@@ -550,7 +550,8 @@
 (defun mc-gnus-verify-signature ()
   (interactive)
   (gnus-summary-select-article)
-  (gnus-eval-in-buffer-window gnus-article-buffer
+  (save-excursion
+    (set-buffer gnus-original-article-buffer)
     (save-restriction (widen) (mc-verify-signature))))
 
 ;;;###autoload

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 18 21:37:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA01722 for xemacs-beta-people; Thu, 18 Jul 1996 21:37:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA01719 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 18 Jul 1996 21:37:28 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA27171 for <xemacs-beta@cs.uiuc.edu>; Thu, 18 Jul 1996 21:37:30 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id TAA29135; Thu, 18 Jul 1996 19:36:54 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id TAA02528; Thu, 18 Jul 1996 19:36:51 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA02594; Thu, 18 Jul 1996 19:36:49 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id TAA25681; Thu, 18 Jul 1996 19:36:44 -0700
Date: Thu, 18 Jul 1996 19:36:44 -0700
Message-Id: <199607190236.TAA25681@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Cc: PBernhar@isdlink1.hisd.harris.com (PBernhar)
Subject: xemacs widget
In-Reply-To: <1EEA7EA0.1903@isdlink1.hisd.harris.com>
References: <1EEA7EA0.1903@isdlink1.hisd.harris.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

Can anyone help Phil?

Hint to Chuck: anyone who is brave enough to use external widgets
deserves to be invited to the beta mailing list.

>>>>> "Phil" == PBernhar  <PBernhar@isdlink1.hisd.harris.com> writes:

Phil>      My name is phil, and I got your email address off of an
Phil>      xemacs news group.  I am having a problem with a feature of
Phil>      xemacs, and I am at about 'wits-end, so I hope you don't
Phil>      mind me asking you.
     
Phil>      I am trying to use the xemacs widget in an application, and
Phil>      I am having some trouble getting it to come up.  Do you
Phil>      know of anyone who worked on this widget or who may have
Phil>      experience with it?
     
Phil>      Thank you for your time.
     
Phil>      Phil Bernhard
Phil>      Harris ISD
     


From xemacs-beta-request@cs.uiuc.edu  Thu Jul 18 21:41:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA01751 for xemacs-beta-people; Thu, 18 Jul 1996 21:41:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA01748 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 18 Jul 1996 21:41:44 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA27279 for <xemacs-beta@cs.uiuc.edu>; Thu, 18 Jul 1996 21:41:47 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id TAA29795; Thu, 18 Jul 1996 19:41:15 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id TAA02727; Thu, 18 Jul 1996 19:41:12 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA02624; Thu, 18 Jul 1996 19:41:11 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id TAA25690; Thu, 18 Jul 1996 19:41:05 -0700
Date: Thu, 18 Jul 1996 19:41:05 -0700
Message-Id: <199607190241.TAA25690@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Steven L Baur <steve@miranova.com>
Cc: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: Comments on 20.0-b26
In-Reply-To: <m2vifl3068.fsf@deanna.miranova.com>
References: <m2vifl3068.fsf@deanna.miranova.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

Steven> File name expansion is slow.  I have 19.14 compiled -O4, and 20.0
Steven> compiled -g -O4 so there shouldn't be that much difference in speed,
Steven> but there is.  I'm not sure what to do to trace this one.

If you have compiled with mule support, XEmacs needs to convert every
filename in the directory into internal format before completing the
filename.  What if you had a japanese EUC encoded filename?

But there may well be other reasons for the slowness.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 18 22:11:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA01840 for xemacs-beta-people; Thu, 18 Jul 1996 22:11:05 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA01837 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 18 Jul 1996 22:10:58 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA27639 for <xemacs-beta@cs.uiuc.edu>; Thu, 18 Jul 1996 22:11:00 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id UAA03192; Thu, 18 Jul 1996 20:09:22 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Comments on 20.0-b26
References: <m2vifl3068.fsf@deanna.miranova.com>
	<199607190241.TAA25690@xemacs.eng.sun.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Martin Buchholz's message of Thu, 18 Jul 1996 19:41:05 -0700
Mime-Version: 1.0 (generated by tm-edit 7.72)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Jul 1996 20:09:21 -0700
Message-ID: <m2loghszvi.fsf@deanna.miranova.com>
Lines: 21
X-Mailer: Gnus v5.2.37/XEmacs 20.0

>>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:
>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

Steven> File name expansion is slow.

Martin> If you have compiled with mule support, XEmacs needs to
Martin> convert every filename in the directory into internal format
Martin> before completing the filename.  What if you had a japanese
Martin> EUC encoded filename?

Martin> But there may well be other reasons for the slowness.

If the converted names are cached (which they are through
minibuffer-completion-table, right?), that would explain it.

O.K.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Jul 19 00:17:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA02111 for xemacs-beta-people; Fri, 19 Jul 1996 00:17:45 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA02108 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 19 Jul 1996 00:17:40 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA17105 for <xemacs-beta@xemacs.org>; Fri, 19 Jul 1996 00:17:37 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id VAA13898; Thu, 18 Jul 1996 21:34:50 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id VAA07736; Thu, 18 Jul 1996 21:34:47 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA03456; Thu, 18 Jul 1996 21:34:47 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA25781; Thu, 18 Jul 1996 21:34:41 -0700
Date: Thu, 18 Jul 1996 21:34:41 -0700
Message-Id: <199607190434.VAA25781@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Tonny Madsen <Tonny.Madsen@netman.dk>
Cc: xemacs-beta@xemacs.org
Subject: Shared Library Support for XEmacs 20.0-b26
In-Reply-To: <rrenm9oe1r.fsf@teapot.netman.dk>
References: <rrenm9oe1r.fsf@teapot.netman.dk>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

Wow!  This looks like really good stuff.  The object allocation
redesign feels well thought out.

Some comments:

- My biggest need for shared lib support is to use os-provided
  functionality that is only optionally installed.  I assume that the
  shlib stuff will allow the CDE drag'n'drop to be used if and only if
  the shared lib can be found, so XEmacs can always be portably built
  with drag'n'drop support.

- Perhaps we should use defstruct-style syntax for new objects in
  XEmacs.  The cl package is now standard.

  (setq sl (make-shlib path))
  (shlib-name sl)
  (shlib-entry-name sl)
...

Martin

From xemacs-beta-request@cs.uiuc.edu  Fri Jul 19 06:02:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA06371 for xemacs-beta-people; Fri, 19 Jul 1996 06:02:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA06368 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 19 Jul 1996 06:02:40 -0500 (CDT)
Received: from teapot.netman.dk (teapot.netman.dk [193.88.72.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA17462 for <xemacs-beta@xemacs.org>; Fri, 19 Jul 1996 06:02:30 -0500 (CDT)
Received: (from tmadsen@localhost) by teapot.netman.dk (8.7.1/8.7.1) id NAA16635; Fri, 19 Jul 1996 13:01:53 +0200 (MET DST)
To: Martin Buchholz <mrb@eng.sun.com>
CC: xemacs-beta@xemacs.org
Subject: Re: Shared Library Support for XEmacs 20.0-b26
References: <rrenm9oe1r.fsf@teapot.netman.dk>
	<199607190434.VAA25781@xemacs.eng.sun.com>
From: Tonny Madsen <Tonny.Madsen@netman.dk>
Date: 19 Jul 1996 13:01:51 +0200
In-Reply-To: Martin Buchholz's message of Thu, 18 Jul 1996 21:34:41 -0700
Message-ID: <rr687ko6ao.fsf@teapot.netman.dk>
Lines: 66
X-Mailer: Gnus v5.2.29/XEmacs 20.0

Hi'

Martin Buchholz <mrb@Eng.Sun.COM> writes:

> 
> Wow!  This looks like really good stuff.  The object allocation
> redesign feels well thought out.

Glad you like it :-> The idea is to extent it into a real o-o
system. See below.

> Some comments:
> 
> - My biggest need for shared lib support is to use os-provided
>   functionality that is only optionally installed.  I assume that the
>   shlib stuff will allow the CDE drag'n'drop to be used if and only if
>   the shared lib can be found, so XEmacs can always be portably built
>   with drag'n'drop support.

If I understand you correctly, you have a shared library with CDE d&d
functions (probably part of some large CDE library, right), and now
you want to use this library at emacs startup if it is there and just
ignore it otherwise.

This depends alot on how your linker handles undefined symbols - and I
don't think we can do anything that is portable across all platforms
with shared libraries.

Personaly I would make a new file, say cde.c, with all the functions
and stuff that is now ifdef'ed with HAVE_CDE in several different
files. This file can be made into a shared library as is done with
md5.c in the patch. I have only looked a little on the CDE code in
emacs, but as far as I can see, you only have one place, in the
function x_popup_frame, where the CDE d&d code is mixed with other
code; and this single function can probably be split into two function
with a hook or something similar...

Now we have a situation where we have a shared library,
libemacscde.so, that depends on another shared library, libcde.so (?).

Most shared library implementations (actually all I know of) will
automatically load libcde.so if libemacscde.so is loaded. If libcde.so
can not be loaded, e.g. if it doesn't exist, the load of
libemacscde.so will fail too, and a signal will be thrown by shlib...

> - Perhaps we should use defstruct-style syntax for new objects in
>   XEmacs.  The cl package is now standard.
> 
>   (setq sl (make-shlib path))
>   (shlib-name sl)
>   (shlib-entry-name sl)
> ...

Yes, I want to do this too, and I think I will have something like it
for the next version. But, I want to go even futher. When I have
finished shlib, I want to implement a scaled-down version of CLOS! I
will write about that in a separate mail.

> 
> Martin
> 
/tonny
-- 
Tonny Madsen, NetMan a/s, Vandtaarnsvej 77, DK-2860 Soeborg, Denmark
E-mail: Tonny.Madsen@netman.dk 
Telephone: +45 39 66 40 20 Fax: +45 39 66 06 75

From xemacs-beta-request@cs.uiuc.edu  Fri Jul 19 06:57:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA06483 for xemacs-beta-people; Fri, 19 Jul 1996 06:57:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA06480 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 19 Jul 1996 06:57:25 -0500 (CDT)
Received: from teapot.netman.dk (teapot.netman.dk [193.88.72.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA17595 for <xemacs-beta@xemacs.org>; Fri, 19 Jul 1996 06:57:11 -0500 (CDT)
Received: (from tmadsen@localhost) by teapot.netman.dk (8.7.1/8.7.1) id NAA17075; Fri, 19 Jul 1996 13:56:40 +0200 (MET DST)
To: xemacs-beta@xemacs.org
Subject: Thoughts on a CLOS implmentation in XEmacs
From: Tonny Madsen <Tonny.Madsen@netman.dk>
Date: 19 Jul 1996 13:56:39 +0200
Message-ID: <rr4tn4o3rc.fsf@teapot.netman.dk>
Lines: 103
X-Mailer: Gnus v5.2.29/XEmacs 20.0

Hi'

Prompted by some comments from Martin Buchholz, I want to write about
some thoughts I have had about a CLOS like implementation of objects
in XEmacs.

I already have a design for this, that doesn't change all that much of
the XEmacs internals. The design have two parts: the implentation of
the defclass macro of CLOS and the implementation of the
defgeneric/defmethod macros.

** defclass **

I have implemented C based classes in Emacs (that is part of the shlib
patch), but there are no inheritance of C functions and structure
between these (and there probably never will be!!).

This design will allow for elisp based classes with single
inheritance. Multiple enheritance should be possible too, but there
are some problems: What if a new class enherits from two different C
based classes, e.g. both the Buffer and Toolbar classes. How will C
part of the the object be organized? Of cause this can always be
detected and rejected by a sensible implementation.

The Lisp_Class structure will be extented with a table of pointers to
the super-classes of the class. All the C based classes will inherit
from a single class, say Object (this really only matters in the
defgeneric/defmethod design below).

The C based classes will be divided into two groups: those that can be
super-classes and the others. Among "the others" you find integers,
characters, and cons and probably strings, vectors, events, extents
and other primitive emacs objects. Common for these are the facts that
they are used intensively in the emacs core and they exists in very
large numbers.

Objects of all classes in the first group, will all have a table of
member variables - called slots in CLOS lingo. (This can be a
hashtable, a plist or something else and the pointer can be Qnil if no
slots exist).

The values of the slots can be set and retrieved with two new
functions, slot-value and set-slot-value (these are the CLOS
names). The defclass macro will create accessor functions for the if
requested when a class is created. (These accessor functions are
actually methods, which means that the accessor function "name" can be
used for many different classes, including buffers and shlib's.)

The C based classes with slots can use a special DEFSLOT macro to add
access methods for the different C fields of their structures. Of
cause this C macro/function must interact sensible with the setf
functionality. If the value can not be found directly as a field in
the C structure of the objects, a normal method can be created and
used instead (see below).

If one ignores the defgeneric/defmethod part of the implmentation and
insures that all methods names are unique, i.e. (shlib-name sl)
instead of (name sl), this can be implemented quite easily, and I'll
probably do that for the next version of shlib.

** defgeneric/defmethod **

For a first implementation I only want to do method dispatching based
on the first argument, and not on the complete signature of the method
invocation.

Technically I want to do the following:

- I want to implement two new object types, Generic-Function and
  Method, with the same semantics (scaled-down a fair bit!!!) as seen
  in CLOS.

  For the first version, a generic-function object will have a
  hashtable with all the methods of the generic function indexed by
  the class of the first argument.

  Methods object will be very similar to SUBR's as known today.

- I want to alter funcall, eval&co to call a new C function if the
  function object is a generic-function object. Lets call that C
  function do_generic.

- do_generic will lookup the class of the first argument in the
  hashtable of the generic-function object and dispatch the call to
  the correct method. If no method is found, the super class of the
  first argument is tried, then the super-super-class, etc. Any found
  method can of cause be catched directly in the generic-function
  object for future invocations.

I will leave out alot of the advanced functionality of CLOS in the
first version; e.g. dispatching on the full signature of the method
invocation and define-method-combination.

More information on the interface and specification of CLOS can be
found in URL:ftp://parcftp.xerox.com/pub/pcl/doc/functi.dvi

Have a good weekend

/tonny
-- 
Tonny Madsen, NetMan a/s, Vandtaarnsvej 77, DK-2860 Soeborg, Denmark
E-mail: Tonny.Madsen@netman.dk 
Telephone: +45 39 66 40 20 Fax: +45 39 66 06 75

From xemacs-beta-request@cs.uiuc.edu  Sat Jul 20 15:15:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA14785 for xemacs-beta-people; Sat, 20 Jul 1996 15:15:34 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA14782 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 20 Jul 1996 15:15:33 -0500 (CDT)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA20071 for <xemacs-beta@xemacs.org>; Sat, 20 Jul 1996 15:15:31 -0500 (CDT)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.6.12/8.6.12) with SMTP id NAA01345 for <xemacs-beta@xemacs.org>; Sat, 20 Jul 1996 13:15:29 -0700
Date: Sat, 20 Jul 1996 13:15:29 -0700 (PDT)
From: Jaye Mathisen  <mrcpu@cdsnet.net>
To: xemacs-beta@xemacs.org
Subject: Font-lock weirdness for .pl files.
Message-ID: <Pine.NEB.3.94.960720131306.5880r-100000@mail.cdsnet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



Not sure it's an xemacs problem, but I don't have a different good idea on
where to send this.

The following code fragment screws up fontlock royally.  Specifically,
putting the cursor after the last paren on the follow line causes the [ to
blink, and such.

the [^= combo seems to throw things off.  Anybody have a quick fix?

                if (/User-Name = "([^"]+)"/) {
                        $user = $1;
                        }

                if (/Client-Id = ([0-9.]+[ \r\n])/) {
                  chop ($pm = $1);
                }

                if (/Client-Port-Id = ([0-9]+[ \r\n])/) {
                  chop ($port = $1);
                }
               
                &insertpmdatarec ($dbh,
$user,"Start",0,$date,$id,$pm,$port);



From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 05:06:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA19920 for xemacs-beta-people; Sun, 21 Jul 1996 05:06:26 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA19917 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 05:06:24 -0500 (CDT)
Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA12106 for <xemacs-beta@cs.uiuc.edu>; Sun, 21 Jul 1996 05:05:41 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id DAA28570 for <xemacs-beta@cs.uiuc.edu>; Sun, 21 Jul 1996 03:05:39 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id DAA02607 for <xemacs-beta@cs.uiuc.edu>; Sun, 21 Jul 1996 03:05:30 -0700
Date: Sun, 21 Jul 1996 03:05:30 -0700
Message-Id: <199607211005.DAA02607@shellx.best.com>
From: Ben Wing <wing@666.com>
To: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>,
        Martin Buchholz
    <mrb@eng.sun.com>
Subject: Re:  xemacs widget
Cc: PBernhar@isdlink1.hisd.harris.com (PBernhar)
References: <1EEA7EA0.1903@isdlink1.hisd.harris.com>

I wrote the external widget stuff.  I haven't tried to get it working
in a long long long time, but other people have tried more recently.
Some have even reported success :)

Chuck, did you ever include the external-widget test files from
era-specific into the standard distribution?  If not, they should go
in, as they make life easier for intrepid souls trying to use this
stuff.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 05:02:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA19889 for xemacs-beta-people; Sun, 21 Jul 1996 05:02:36 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA19886 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 05:02:34 -0500 (CDT)
Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA11296 for <xemacs-beta@cs.uiuc.edu>; Sun, 21 Jul 1996 05:02:34 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id DAA28253 for <xemacs-beta@cs.uiuc.edu>; Sun, 21 Jul 1996 03:02:33 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id DAA18414 for <xemacs-beta@cs.uiuc.edu>; Sun, 21 Jul 1996 03:02:32 -0700
Date: Sun, 21 Jul 1996 03:02:32 -0700
Message-Id: <199607211002.DAA18414@shellx.best.com>
From: Ben Wing <wing@666.com>
To: xemacs-beta@cs.uiuc.edu, wkirk <wkirk@wsj.dowjones.com>
Subject: Re:  rebinding C-u leads to strange prefix-argument problem

I bet that C-u == prefix-argument is hard-coded somewhere.  Poke
around the Lisp code in simple.el and you might find it.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 05:01:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA19881 for xemacs-beta-people; Sun, 21 Jul 1996 05:01:49 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA19878 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 05:01:48 -0500 (CDT)
Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA20773 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 05:01:45 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id DAA28175 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 03:01:38 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id DAA13497 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 03:01:38 -0700
Date: Sun, 21 Jul 1996 03:01:38 -0700
Message-Id: <199607211001.DAA13497@shellx.best.com>
From: Ben Wing <wing@666.com>
To: xemacs-beta@xemacs.org, William Perry <wmperry@aventail.com>
Subject: Re:  --with-socks w/SOCKS v5

	  Well, seeing as I now work for a company doing commercial socks stuff,
	I thought I would try to compile XEmacs 20.0b26 w/socks support (I am
	using Socks v5).  Unfortunately, socks v5 has a variety of weirdnesses:
	
	1. No longer uses 'R' as the prefix, but 'SOCKS', so the config.h.in 
	   redefinitions of connect/accept/etc are wrong.  This can be changed
	   with the preprocessor definition USE_SOCKS4_PREFIX though.
	
	2. If you decide to link dynamically against libsocks5_sh.so, you do not
	   need to use any prefix whatsoever.  This shouldn't normally be a
	   problem, as the static and dynamic versions of the library have
	   different stub names.
	
	3. The library has changed names - it is now libsocks5.a
	
	What would be the best way to modify configure.in to handle all this
	hooplah?  A separate configuration switch --with-socks-v5? 
	--with-socks=5|4 (defaulting to 4).

I'd prefer --with-socks=v5, --with-socks=v4, --with-socks=yes (same as v4).
I think it's cleaner than separate --with-socks-v5 options, and it
allows for other socks-related config options.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 05:04:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA19896 for xemacs-beta-people; Sun, 21 Jul 1996 05:04:12 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA19893 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 05:04:11 -0500 (CDT)
Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA11718 for <xemacs-beta@cs.uiuc.edu>; Sun, 21 Jul 1996 05:04:11 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id DAA28430 for <xemacs-beta@cs.uiuc.edu>; Sun, 21 Jul 1996 03:04:10 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id DAA25407 for <xemacs-beta@cs.uiuc.edu>; Sun, 21 Jul 1996 03:04:01 -0700
Date: Sun, 21 Jul 1996 03:04:01 -0700
Message-Id: <199607211004.DAA25407@shellx.best.com>
From: Ben Wing <wing@666.com>
To: xemacs-beta@cs.uiuc.edu, Steven L Baur <steve@miranova.com>
Subject: Re:  Comments on 20.0-b26

	The buffer prompt works differently than in 19.14.  When doing a
	`C-x 4 b' hitting blank results in an expansion of buffer names making
	getting to a hidden buffer (like ' *Original Article nnml:xemacs-beta*')
	unnecessarily cumbersome.  I prefer the 19.14 behavior.

This sounds like accidental version skew, probably in E-Lisp code.
Maybe something left-over from when I had space == "switch to other buffer"?

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 05:51:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA20020 for xemacs-beta-people; Sun, 21 Jul 1996 05:51:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA20017 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 05:51:47 -0500 (CDT)
Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA20806 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 05:51:43 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id DAA02798 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 03:51:47 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id DAA16954 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 03:33:16 -0700
Date: Sun, 21 Jul 1996 03:33:16 -0700
Message-Id: <199607211033.DAA16954@shellx.best.com>
From: Ben Wing <wing@666.com>
To: xemacs-beta@xemacs.org, Tonny Madsen <Tonny.Madsen@netman.dk>
Subject: Re:  Shared Library Support for XEmacs 20.0-b26

This stuff is WAY WAY cool and I'm really glad someone is getting
their hands dirty with the internals of XEmacs.  XEmacs is long
overdue with both the shared-library and the object-oriented stuff.
I'll see if I can add some detailed commentary on your implementation
sometime soon (from a cursory scan it looks great) ...  it may be a
few weeks though till I can emerge from the depths of VRML toolkit
hacking. (Not that different from XEmacs hacking, it turns out,
although more math ...)

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 10:17:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA20585 for xemacs-beta-people; Sun, 21 Jul 1996 10:17:19 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA20582 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 10:17:18 -0500 (CDT)
Received: from monolith.spry.com (wmperry.oz.net [207.13.185.53]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA20940 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 10:17:13 -0500 (CDT)
Received: (from wmperry@localhost) by monolith.spry.com (8.7.4/8.7.3) id IAA02992; Sun, 21 Jul 1996 08:11:43 -0700
Date: Sun, 21 Jul 1996 08:11:43 -0700
Message-Id: <199607211511.IAA02992@monolith.spry.com>
From: William Perry <wmperry@aventail.com>
To: Ben Wing <wing@666.com>
Cc: xemacs-beta@xemacs.org, Tonny Madsen <Tonny.Madsen@netman.dk>
Subject: Re:  Shared Library Support for XEmacs 20.0-b26
In-Reply-To: <199607211033.DAA16954@shellx.best.com>
References: <199607211033.DAA16954@shellx.best.com>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Ben Wing writes:

>This stuff is WAY WAY cool and I'm really glad someone is getting their
>hands dirty with the internals of XEmacs.  XEmacs is long overdue with
>both the shared-library and the object-oriented stuff.  I'll see if I can
>add some detailed commentary on your implementation sometime soon (from a
>cursory scan it looks great) ...  it may be a few weeks though till I can
>emerge from the depths of VRML toolkit hacking. (Not that different from
>XEmacs hacking, it turns out, although more math ...)

  shit shit shit - did I miss the message with the official patch?  The
email address my xemacs-beta stuff was getting forwarded to was bouncing.
Could some kind soul please resend it to me please.

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 11:04:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA20687 for xemacs-beta-people; Sun, 21 Jul 1996 11:04:55 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA20684 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 11:04:54 -0500 (CDT)
Received: from monolith.spry.com (wmperry.oz.net [207.13.185.53]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA20991 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 11:04:49 -0500 (CDT)
Received: (from wmperry@localhost) by monolith.spry.com (8.7.4/8.7.3) id JAA03217; Sun, 21 Jul 1996 09:15:05 -0700
Date: Sun, 21 Jul 1996 09:15:05 -0700
Message-Id: <199607211615.JAA03217@monolith.spry.com>
From: William Perry <wmperry@aventail.com>
To: xemacs-beta@xemacs.org
Subject: forwarded message from Erik Naggum, Re: byte-compiled portability
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

In response to me saying its stupid to use version #s to determine whether
a .elc file can be loaded into a certain emacsen.  ie: 19.31 .elcs cannot
be loaded into XEmacs 19.14, even though they should work.

Could we make sure to synch this up with 19.32 when it comes out (or the
next beta of 19.32 is out).

-Bill P.

------- start of forwarded message (RFC 934 encapsulation) -------
Return-Path: erik@naggum.no
Received: from naggum.no (erik@naggum.no [193.71.66.49]) by cosmo.aventail.com (8.6.12/8.6.9) with SMTP id XAA12796 for <wmperry@aventail.com>; Sat, 20 Jul 1996 23:25:28 -0700
Received: by naggum.no id <AA03798> for William Perry <wmperry@aventail.com>; Sun, 21 Jul 1996 06:32:17 UT
Organization: Naggum Software; +47 2295 0313
Message-Id: <3046919536613019@arcana.naggum.no>
In-Reply-To: <u7ybkeaz7v.fsf@monolith.spry.com>
X-UIDL: 6931cf0b8766b55d2bf1847c8d9708fe
From: Erik Naggum <erik@naggum.no>
To: William Perry <wmperry@aventail.com>
Subject: Re: emacs rewritten in java ?
Date: 21 Jul 1996 06:28:46 UT

|   So for post-19.3x .elcs that use dynamic docstrings, do:
|   
|   (if (not (and (featurep 'byte-compile-dynamic)
|                 (featurep 'whatever-other-cool-thing-this-bytecode-needs)))
|      (error "time.el requires dynamic docstring support, and other cool shit."))

Bill, this is the stroke of genius that makes me like working on Emacs with
all the bright people around the world chipping in: _of_course_ that's how
it should have been handled to begin with.

I'll try my very best to get this into 19.32.

thanks for an idea that only became obvious to me after you wrote it!

#\Erik

------- end -------

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 11:08:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA20810 for xemacs-beta-people; Sun, 21 Jul 1996 11:08:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA20807 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 11:08:14 -0500 (CDT)
Received: from monolith.spry.com (wmperry.oz.net [207.13.185.53]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA20997 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 11:08:10 -0500 (CDT)
Received: (from wmperry@localhost) by monolith.spry.com (8.7.4/8.7.3) id JAA04867; Sun, 21 Jul 1996 09:18:25 -0700
Date: Sun, 21 Jul 1996 09:18:25 -0700
Message-Id: <199607211618.JAA04867@monolith.spry.com>
From: William Perry <wmperry@aventail.com>
To: xemacs-beta@xemacs.org
Subject: Request for shared lib stuff satisfied...
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

praise be to mr. baur for his quick response.  no more copies necessary.
Damn thats a big patch. :)

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 11:17:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA20867 for xemacs-beta-people; Sun, 21 Jul 1996 11:17:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA20863 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 11:17:45 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA21533 for <xemacs-beta@cs.uiuc.edu>; Sun, 21 Jul 1996 11:17:38 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id JAA10506; Sun, 21 Jul 1996 09:15:41 -0700
Sender: steve@miranova.com
To: tm-en@chamonix.jaist.ac.jp
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: tm 7.72
References: <199607170544.OAA18745@mikan.jaist.ac.jp>
	<m2u3v6ahhv.fsf@deanna.miranova.com> <s1c7mrxyggp.fsf@jaist.ac.jp>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: morioka@jaist.ac.jp's message of 21 Jul 1996 20:48:54 +0900
Mime-Version: 1.0 (generated by tm-edit 7.72)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 21 Jul 1996 09:15:40 -0700
Message-ID: <m2vifhr39v.fsf@deanna.miranova.com>
Lines: 247
X-Mailer: Gnus v5.2.37/XEmacs 19.14

[Crossposted to the XEmacs beta list -- I'm having problems with a
Gnus group that contains email headers with KOI8 encoding]

Thanks for the advice, but it looks like there are still problems.  I
did a (require 'cyrillic) before entering the group and got a crash.

XEmacs 20.0-b26/mule/tm7.72

(setq code-converter-is-broken t)
Font Path:
  /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Type1/,
  /usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,
  /usr/X11R6/lib/X11/fonts/100dpi/,/usr/lib/X11/fonts/Latin5,
  /usr/lib/X11/fonts/Japanese

Latin5 is filled with fonts retrieved from ftp.XEmacs.org.  Lisp
backtrace followed by C backtrace.

Fatal error: assertion failed, file /i/xemacs-20.0-b26/src/./lisp.h, line 1221, INTP (obj)

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb /i/xemacs-20.0-b26/src/xemacs core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  # (unwind-protect ...)
  call-process-internal("cat" "/tmp/emacsa10322" t nil)
  apply(call-process-internal "cat" "/tmp/emacsa10322" t nil nil)
  # bind (args displayp buffer infile program)
  call-process("cat" "/tmp/emacsa10322" t nil)
  apply(call-process "cat" "/tmp/emacsa10322" t nil nil)
  # (unwind-protect ...)
  # bind (temp args displayp buffer deletep program end start)
  call-process-region(1 14 "cat" t t nil)
  # bind (process-output-coding-system process-input-coding-system)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (buffer coding-system end start)
  decode-coding-region(1 14 koi8)
  # (unwind-protect ...)
  # bind (curbuf tempbuf result coding-system str)
  decode-coding-string(" " koi8)
  # bind (cs charset string)
  decode-mime-charset-string(" " "KOI8-R")
  # bind (dest str encoding charset)
  mime/decode-encoded-text("KOI8-R" "Q" "=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7")
  # bind (charset encoding text word)
  mime/decode-encoded-word("=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=")
  # bind (dest ew beg end str)
  mime-eword/decode-string("=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su>")
  # bind (from subj method header)
  #<compiled-function (from "loadup.el") (header) "...(76)" [header 2 "" 1 gnus-current-select-method method subj from nntp decode-mime-charset-string default-mime-charset mime-eword/decode-string] 4>([2005 "Re:  Patch for SJIS handling" "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su>" "Sat, 8 Jun 1996 23:02:23 +0400 (MSD)" "<199606081902.XAA03340@astral.msk.su>" "<01I5NQIDR0J6003NL8@SCI.WFBR.EDU>" 984 23 "Xref: deanna.miranova.com lynx-dev:2005"])
  mapcar(#<compiled-function (from "loadup.el") (header) "...(76)" [header 2 "" 1 gnus-current-select-method method subj from nntp decode-mime-charset-string default-mime-charset mime-eword/decode-string] 4> ([2735 "Re:   Re: Making lynx smaller for menu-only usage." "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Thu, 18 Jul 1996 10:29:50 +0900" "<199607180129.KAA10462@ews07.nara.kindai.ac.jp>" "" 516 12 "Xref: deanna.miranova.com lynx-dev:2735"] [2728 "Re:  receiving data counter??" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 17 Jul 1996 18:23:22 -0500 (EST)" "<01I76SZIA02W000QP2@SCI.WFBR.EDU>" "" 1192 29 "Xref: deanna.miranova.com lynx-dev:2728"] [353 "12-21-95 INSERT draft" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Tue, 26 Dec 1995 16:26:06 -0500 (EST)" "<01HZ9PNV9LG20011DO@SCI.WFBR.EDU>" "" 3341 73 "Xref: diana.miranova.com lynx-dev:353"] [2608 " Re: Accessing password protected pages causes a  crash at exit" "Steven L Baur <steve@miranova.com>" "12 Jul 1996 11:53:!
!
00 -0700" "<m2ivbttib7.fsf@deanna.miranova.com>" "<01I6ZG43TIB6000APU@SCI.WFBR.EDU>" 7894 148 "Xref: deanna.miranova.com lynx-dev:2608"] [2772 " Is it time for Lynx 2.5.1?" "Subir Grewal <grewals@acf2.NYU.EDU>" "Thu, 18 Jul 1996 16:15:48 -0400 (EDT)" "<Pine.ULT.3.92.960718161033.10952E-100000@acf2.NYU.EDU>" "" 1162 25 "Xref: deanna.miranova.com lynx-dev:2772"] [2711 " Making lynx smaller for menu-only usage." "\"Carl D. Cravens\" <cravens@southwind.net>" "Wed, 17 Jul 1996 10:33:45 -0500 (CDT)" "<Pine.BSI.3.94.960717103115.5560A-100000@onyx.southwind.net>" "" 671 17 "Xref: deanna.miranova.com lynx-dev:2711"] [2725 " Re: Making lynx smaller for menu-only usage." "Steven L Baur <steve@miranova.com>" "17 Jul 1996 14:21:40 -0700" "<m220ialgnv.fsf@deanna.miranova.com>" "<Pine.BSI.3.94.960717103115.5560A-100000@onyx.southwind.net>" 966 24 "Xref: deanna.miranova.com lynx-dev:2725"] [2743 "Re:  Re: Making lynx smaller for menu-only usage." "lvirden@cas.org (Larry W. Virden, x2487)" "Th!
!
u, 18 Jul 96 05:57:55 EDT" "<9607180557.AA16908@cas.org>" "<m220ialgnv.fsf@deanna.miranova.com>" 591 13 "Xref: deanna.miranova.com lynx-dev:2743"] [2749 "Re:  Re: Making lynx smaller for menu-only usage." "\"Carl D. Cravens\" <cravens@southwind.net>" "Thu, 18 Jul 1996 08:45:10 -0500 (CDT)" "<Pine.BSI.3.94.960718084128.4580A-100000@onyx.southwind.net>" "<9607180557.AA16908@cas.org>" 1200 27 "Xref: deanna.miranova.com lynx-dev:2749"] [2771 "Re:  Re: Making lynx smaller for menu-only usage." "\"Mark T. Gray\" <markgray@postoffice.ptd.net>" "Thu, 18 Jul 1996 14:49:26 -0400 (EDT)" "<Pine.LNX.3.93.960718143322.1324B-100000@ptd.net>" "<Pine.BSI.3.94.960718084128.4580A-100000@onyx.southwind.net>" 2072 43 "Xref: deanna.miranova.com lynx-dev:2771"] [2764 "Re:  jlynx?" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 18 Jul 1996 13:17:46 -0500 (EST)" "<01I77WGYFV4I000X2U@SCI.WFBR.EDU>" "" 1685 40 "Xref: deanna.miranova.com lynx-dev:2764"] [2630 "Re:  Security problem with Lynx 2.5" "Jasvi!
!
nder Singh <jassi@giasbma.vsnl.net.in>" "Sat, 13 Jul 1996 16:27:15 +0530 (IST)" "<Pine.SOL.3.93.960713162445.8728B-100000@giasbmb>" "<9607111923.AA02652@boris>" 7296 245 "Xref: deanna.miranova.com lynx-dev:2630"] [2773 "Re:  Lynx and databases" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 18 Jul 1996 16:17:13 -0500 (EST)" "<01I782ZU5G2Q000X2U@SCI.WFBR.EDU>" "" 1178 26 "Xref: deanna.miranova.com lynx-dev:2773"] [2775 "Re:  Is it time for Lynx 2.5.1?" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 18 Jul 1996 18:06:05 -0500 (EST)" "<01I786IAF4N6000X2U@SCI.WFBR.EDU>" "" 1920 38 "Xref: deanna.miranova.com lynx-dev:2775"] [2 "SUBSCRIBE LYNX-DEV \"Steve Baur\"" "CREN ListProcessor Version 7 <listproc@ukanaix.cc.ukans.edu>" "Wed, 22 Nov 1995 17:33:09 CST" "<9511222333.AA19508@ukanaix.cc.ukans.edu>" "" 4974 145 "Xref: diana.miranova.com lynx-dev:2"] [37 "Re: Preprocessing (html -> text)?" "Gerald Oskoboiny <gerald@cs.ualberta.ca>" "Mon, 27 Nov 1995 23:22:12 -0700 (MST)" "<95Nov27.!
!
232745-0700_mst.138801-4+66@amisk.cs.ualberta.ca>" "<Pine.SUN.3.91.951123171719.20178A-100000@pens-emh3>" 1314 34 "Xref: diana.miranova.com lynx-dev:37"] [135 "lynx 2.4.2 on linux" "\"Marty Leisner\" <leisner@sdsp.mc.xerox.com>" "Mon, 4 Dec 1995 09:14:36 PST" "<9512041714.AA18902@gnu.mc.xerox.com>" "" 965 32 "Xref: diana.miranova.com lynx-dev:135"] [154 "freeWAIS-0.4 and lynx-2.4.2 namespace conflicts" "David D Kilzer <ddkilzer@cpre1.ee.iastate.edu>" "Wed, 06 Dec 1995 00:52:49 CST" "<9512060652.AA38624@ukanaix.cc.ukans.edu>" "" 1751 41 "Xref: diana.miranova.com lynx-dev:154"] [162 "Re: freeWAIS-0.4 and lynx-2.4.2 namespace conflicts" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 06 Dec 1995 13:30:45 -0500 (EST)" "<01HYHL02LIG8004HA0@SCI.WFBR.EDU>" "" 2910 65 "Xref: diana.miranova.com lynx-dev:162"] [270 "Re: Displaying source, over 80 columns." "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 15 Dec 1995 18:24:43 -0500 (EST)" "<01HYUGOLMGNC0008IJ@SCI.WFBR.EDU>" "" 1422 26 "Xr!
!
ef: diana.miranova.com lynx-dev:270"] [276 "Coloured links using ncurses" "R J Partington <rjp@heffer.demon.co.uk>" "Sat, 16 Dec 1995 04:08:30 +0000 (GMT)" "<199512160408.EAA00222@heffer.demon.co.uk>" "" 7467 287 "Xref: diana.miranova.com lynx-dev:276"] [289 "unzip comment" "jeske@pa.dec.com (Steve Jeske)" "Sun, 17 Dec 95 10:22:46 -0800" "<9512171822.AA15163@zumbrota.pa.dec.com>" "" 804 16 "Xref: diana.miranova.com lynx-dev:289"] [294 "Re: Links on a page" "Al Gilman <asgilman@access.digex.net>" "Sun, 17 Dec 1995 23:47:29 -0500 (EST)" "<199512180447.XAA26240@access2.digex.net>" "<199512180312.DAA07763@heffer.demon.co.uk>" 1284 29 "Xref: diana.miranova.com lynx-dev:294"] [354 "bug in lynxcgi implementation" "David Trueman <david@cs.dal.ca>" "Tue, 26 Dec 1995 18:36:40 -0400" "<Pine.SUN.3.91.951226183334.23020G-100000@cs.dal.ca>" "<01HZ9PNV9LG20011DO@SCI.WFBR.EDU>" 390 9 "Xref: diana.miranova.com lynx-dev:354"] [356 "Re: bug in lynxcgi implementation" "Foteos Macrides <MACRIDES@S!
!
CI.WFBR.EDU>" "Tue, 26 Dec 1995 20:41:09 -0500 (EST)" "<01HZ9YMTZYUQ0011DO@SCI.WFBR.EDU>" "" 1748 43 "Xref: diana.miranova.com lynx-dev:356"] [357 "Re: bug in lynxcgi implementation" "David Trueman <david@cs.dal.ca>" "Tue, 26 Dec 1995 22:56:00 -0400" "<Pine.SUN.3.91.951226225449.715B-100000@cs.dal.ca>" "<01HZ9YMTZYUQ0011DO@SCI.WFBR.EDU>" 1230 34 "Xref: diana.miranova.com lynx-dev:357"] [360 "2-4-FM and new Enhanced for Lynx icons" "Mike Brown <mike@hyperreal.com>" "Wed, 27 Dec 1995 10:10:39 -0800 (PST)" "<199512271810.KAA27420@taz.hyperreal.com>" "<v02140a01ad071d5b2265@[130.166.254.206]>" 1051 23 "Xref: diana.miranova.com lynx-dev:360"] [362 "SSLeay for Lynx" "Thomas Zerucha <tz@execpc.com>" "Wed, 27 Dec 1995 14:13:44 -0600 (CST)" "<Pine.SOL.3.91.951227140440.17791A-100000@earth>" "<199512271810.KAA27420@taz.hyperreal.com>" 995 29 "Xref: diana.miranova.com lynx-dev:362"] [394 "DirEd/Makefile problems, with patch" "Will Mengarini <seldon@eskimo.com>" "Wed, 10 Jan 1996 02:32:02!
!
 -0800 (PST)" "<199601101032.CAA25030@eskimo.com>" "" 8617 184 "Xref: miranova.com lynx-dev:394"] [435 "Re: DOWNLOADER: directive" "\"Mark T. Gray\" <markgray@postoffice.ptd.net>" "Mon, 15 Jan 1996 09:51:51 -0500 (EST)" "<Pine.LNX.3.91.960115094937.158E-100000@ptd.net>" "<9601151337.AA17652@blaze.trentu.ca>" 957 30 "Xref: miranova.com lynx-dev:435"] [441 "Re: DOWNLOADER: directive" "WHITLOCK@ACM.ORG" "Mon, 15 Jan 1996 12:49:28 -0600 (CDT)" "<01I01FJQSNME00HCNY@ACM.ORG>" "" 1563 41 "Xref: miranova.com lynx-dev:441"] [443 "Re: DOWNLOADER: directive" "Ismael Cordeiro <ismael@CAM.ORG>" "Mon, 15 Jan 1996 16:20:45 -0500 (EST)" "<199601152120.QAA10882@Ocean.CAM.ORG>" "<9601151337.AA17652@blaze.trentu.ca>" 1700 42 "Xref: miranova.com lynx-dev:443"] [445 "Re: DOWNLOADER: directive" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Mon, 15 Jan 1996 18:11:10 -0500 (EST)" "<01I01QVIE7J20030VP@SCI.WFBR.EDU>" "" 2051 40 "Xref: miranova.com lynx-dev:445"] [571 ": comp.infosystems.www.servers.misc: !
!
Lynx friendly imagemap" "lvirden@cas.org (Larry W. Virden, x2487)" "Sat, 27 Jan 1996 09:43:33 -0500" "<9601270943.AA15735@cas.org>" "" 2217 53 "Xref: miranova.com lynx-dev:571"] [641 "Re: State of libwww" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Tue, 06 Feb 1996 16:44:55 -0500 (EST)" "<01I0WDUHIGAW007DR1@SCI.WFBR.EDU>" "" 1665 29 "Xref: miranova.com lynx-dev:641"] [643 "Re: State of libwww" "Danny Mayer <mayer@ljsrv2.ENET.dec.com>" "Wed, 7 Feb 96 10:10:33 EST" "<9602071510.AA12769@us1rmc.bb.dec.com>" "" 2254 41 "Xref: miranova.com lynx-dev:643"] [824 "valid vs. \"historical\" vs. \"NetScape v2\" comment parsing" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Sat, 24 Feb 1996 11:28:46 -0500 (EST)" "<01I1L5255XDM00281N@SCI.WFBR.EDU>" "" 4633 93 "Xref: deanna.miranova.com lynx-dev:824"] [872 "Re: Lynx 2.4 is compliant with HTML 2.0? HTML 3.0?" "Gerald Oskoboiny <gerald@cs.ualberta.ca>" "Sun, 3 Mar 1996 17:13:54 -0700 (MST)" "<96Mar3.171427-0700_mst.138912-4+32@amisk.cs.ualberta.ca>!
!
" "<01I1WQ9XE0IQ003GQK@SCI.WFBR.EDU>" 1575 41 "Xref: deanna.miranova.com lynx-dev:872"] [1264 "RE: GridText.c bug still exists ... (add this line for Linux, at least)" "\"Bryan T. Vold\" <btv@ldl.HealthPartners.COM>" "Wed, 3 Apr 1996 15:04:44 -0600 (CST)" "<199604032104.PAA28710@ldl.HealthPartners.COM>" "" 1274 27 "Xref: deanna.miranova.com lynx-dev:1264"] [1273 "Re: LYNX  vs  AIX" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 04 Apr 1996 09:05:38 -0500 (EST)" "<01I34YPL38OI000SJ1@SCI.WFBR.EDU>" "" 2124 45 "Xref: deanna.miranova.com lynx-dev:1273"] [1277 "Lynx STARTFILE" "Al Gilman <asgilman@access.digex.net>" "Thu, 4 Apr 1996 10:51:31 -0500 (EST)" "<199604041551.KAA00939@access2.digex.net>" "<199604041343.IAA21912@access2.digex.net>" 2528 60 "Xref: deanna.miranova.com lynx-dev:1277"] [1279 "Re: problem with linux" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 04 Apr 1996 13:04:42 -0500 (EST)" "<01I357SOWQ3S000SJ1@SCI.WFBR.EDU>" "" 3748 74 "Xref: deanna.miranova.com lynx-d!
!
ev:1279"] [1289 "Re: problem with linux" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 04 Apr 1996 18:32:36 -0500 (EST)" "<01I35J7GL7PU000SJ1@SCI.WFBR.EDU>" "" 3255 57 "Xref: deanna.miranova.com lynx-dev:1289"] [1290 "Re: lynx2-4-FM autoconf" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 04 Apr 1996 18:55:46 -0500 (EST)" "<01I35JR9TNNI000SJ1@SCI.WFBR.EDU>" "" 1762 43 "Xref: deanna.miranova.com lynx-dev:1290"] [1529 "Re: 'secure protection of information'" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 24 Apr 1996 11:20:49 -0500 (EST)" "<01I3X1V56X9E007IG5@SCI.WFBR.EDU>" "" 2765 53 "Xref: deanna.miranova.com lynx-dev:1529"] [1535 "Re: Lynx and HTML \"IMG ALT\" tag" "Ismael Cordeiro <ismael@CAM.ORG>" "Wed, 24 Apr 1996 20:22:11 -0400 (EDT)" "<199604250022.UAA16752@Ocean.CAM.ORG>" "<v02110100ada3d6d0193b@[205.134.227.57]>" 2037 57 "Xref: deanna.miranova.com lynx-dev:1535"] [1664 "Re: lynx-bug, lynx-help" "Andrew Burday <andy@dep.philo.mcgill.ca>" "Tue, 30 Apr 1996 13:05:34 -0!
!
400 (EDT)" "<Pine.NXT.3.92.960429120320.14747C-100000@dep>" "<01I431GCIWYW00920T@SCI.WFBR.EDU>" 6832 149 "Xref: deanna.miranova.com lynx-dev:1664"] [1684 "Re: lynx-bug, lynx-help" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 01 May 1996 17:05:57 -0500 (EST)" "<01I474IBH6O8008RQI@SCI.WFBR.EDU>" "" 2018 43 "Xref: deanna.miranova.com lynx-dev:1684"] [1882 "Lynx-dev is Moving" "Al Gilman <asgilman@access.digex.net>" "Fri, 17 May 1996 00:28:24 -0400 (EDT)" "<199605170428.AAA13388@access2.digex.net>" "" 1964 63 "Xref: deanna.miranova.com lynx-dev:1882"] [1884 "Polymorphic WebObjects" "Al Gilman <asgilman@access.digex.net>" "Fri, 17 May 1996 09:24:26 -0400 (EDT)" "<199605171324.JAA05434@access2.digex.net>" "<199605171145.HAA29552@math.uwaterloo.ca>" 1241 29 "Xref: deanna.miranova.com lynx-dev:1884"] [1926 "Re: LYNX-DEV 2.5FM won't POST to this URL" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Tue, 04 Jun 1996 21:35:12 -0500 (EST)" "<01I5IWROQ1O2002TEJ@SCI.WFBR.EDU>" "" 2344 55 "Xref!
!
: deanna.miranova.com lynx-dev:1926"] [2005 "Re:  Patch for SJIS handling" "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su>" "Sat, 8 Jun 1996 23:02:23 +0400 (MSD)" "<199606081902.XAA03340@astral.msk.su>" "<01I5NQIDR0J6003NL8@SCI.WFBR.EDU>" 984 23 "Xref: deanna.miranova.com lynx-dev:2005"] [2018 "Re:  Patch for SJIS handling" "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su>" "Sun, 9 Jun 1996 13:39:32 +0400 (MSD)" "<199606090939.NAA00437@astral.msk.su>" "<01I5O6A3J8TU003GAP@SCI.WFBR.EDU>" 1048 24 "Xref: deanna.miranova.com lynx-dev:2018"] [2141 "Re:  Compile problems with 2-5M on Linux" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Mon, 17 Jun 1996 20:12:54 -0500 (EST)" "<01I60ZV5J4X0005GGP@SCI.WFBR.EDU>" "" 1583 33 "Xref: deanna.miranova.com lynx-dev:2141"] [2155 " Japanese (EUC) croaked" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Tue, 18 Jun 1996 23:49:12!
!
 +0900" "<199606181449.XAA12585@ews07.nara.kindai.ac.jp>" "" 1328 31 "Xref: deanna.miranova.com lynx-dev:2155"] [2235 " status of turning off numbered links" "lvirden@cas.org (Larry W. Virden, x2487)" "Fri, 21 Jun 1996 12:20:35 -0400" "<9606211220.AA5416@cas.org>" "" 1070 25 "Xref: deanna.miranova.com lynx-dev:2235"] [2243 " Lynx-current reload bug with Raw 8-bit mode OFF" "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) <ache@nagual.ru>" "Sat, 22 Jun 1996 01:19:21 +0400 (MSD)" "<199606212119.BAA02998@nagual.ru>" "" 682 25 "Xref: deanna.miranova.com lynx-dev:2243"] [2251 "Re:   patches for lynx2-5FM on 20-June-1996" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Sat, 22 Jun 1996 08:59:51 +0900" "<199606212359.IAA29734@ews07.nara.kindai.ac.jp>" "" 449 12 "Xref: deanna.miranova.com lynx-dev:2251"] [2254 "Re:  Lynx-current reload bug with Raw 8-bit mode OFF" "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) <ache@nagual.ru>" "Sat, 2!
!
2 Jun 1996 09:43:42 +0400 (MSD)" "<199606220543.JAA00677@nagual.ru>" "<01I66NJIZ4J6006D64@SCI.WFBR.EDU>" 1712 54 "Xref: deanna.miranova.com lynx-dev:2254"] [2261 "Re:   patches for lynx2-5FM on 20-June-1996" "Yamamoto Hirotaka <ymmt@is.s.u-tokyo.ac.jp>" "Sun, 23 Jun 96 01:40:06 JST" "<9606221640.AA05948@ise24>" "<199606212359.IAA29734@ews07.nara.kindai.ac.jp>" 799 22 "Xref: deanna.miranova.com lynx-dev:2261"] [2428 " SSL Lynx 2.5 FM available" "jeremy@tddi.inetnebr.com (Jeremy Bettis)" "Fri, 5 Jul 1996 00:21:58 -0500 (CDT)" "<m0uc3L8-000EvGC@tddi.uucp>" "" 548 15 "Xref: deanna.miranova.com lynx-dev:2428"] [2458 " Accessing password protected pages causes a crash at exit" "Steven L Baur <steve@miranova.com>" "07 Jul 1996 15:41:55 -0700" "<m2buhrh657.fsf@totally-fudged-out-message-id>" "" 919 23 "Xref: deanna.miranova.com lynx-dev:2458"] [2472 "Re:  Accessing password protected pages causes a crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Mon, 08 Jul 1996 10:42:33 -05!
!
00 (EST)" "<01I6TSFZNM0I009KYK@SCI.WFBR.EDU>" "" 1501 33 "Xref: deanna.miranova.com lynx-dev:2472"] [2493 "Re:  Accessing password protected pages causes a crash at exit" "jeremy@tddi.inetnebr.com (Jeremy Bettis)" "Mon, 8 Jul 1996 19:06:56 -0500 (CDT)" "<m0udQKR-000EvGC@tddi.uucp>" "<01I6TSFZNM0I009KYK@SCI.WFBR.EDU>" 921 31 "Xref: deanna.miranova.com lynx-dev:2493"] [2495 " Re: Accessing password protected pages causes a crash at exit" "Steven L Baur <steve@miranova.com>" "08 Jul 1996 18:07:39 -0700" "<m2buhqmdyc.fsf@deanna.miranova.com>" "<01I6TSFZNM0I009KYK@SCI.WFBR.EDU>" 1051 34 "Xref: deanna.miranova.com lynx-dev:2495"] [2515 "Re:  Re: Accessing password protected pages causes a crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Tue, 09 Jul 1996 21:00:19 -0500 (EST)" "<01I6VSEUYQ78009GQR@SCI.WFBR.EDU>" "" 1287 38 "Xref: deanna.miranova.com lynx-dev:2515"] [2543 ":  Comment commentary" "Walter Skorski <walt@genetics1.JMP.TJU.EDU>" "Wed, 10 Jul 1996 15:18:12 -0400 (ED!
!
T)" "<199607101918.PAA21210@clyde.jmp.tju.edu>" "<Pine.NEB.3.93.960710085604.28176C-100000@zip0.zipnet.net>" 4332 95 "Xref: deanna.miranova.com lynx-dev:2543"] [2545 "Re: :  Comment commentary" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 10 Jul 1996 16:20:06 -0500 (EST)" "<01I6WW0QJTRM00A34H@SCI.WFBR.EDU>" "" 5920 129 "Xref: deanna.miranova.com lynx-dev:2545"] [2583 "Re:  Re: Re: Re: Accessing password protected pages causes a crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 11 Jul 1996 20:01:13 -0500 (EST)" "<01I6YIYVD6ME00009R@SCI.WFBR.EDU>" "" 721 22 "Xref: deanna.miranova.com lynx-dev:2583"] [2592 "Re:  Accessing password protected pages causes a  crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 12 Jul 1996 08:42:03 -0500 (EST)" "<01I6Z9CD4PO2000APU@SCI.WFBR.EDU>" "" 8668 212 "Xref: deanna.miranova.com lynx-dev:2592"] [2597 "Re:  Accessing password protected pages causes a  crash at exit" "\"Mark T. Gray\" <markgray@postoffice.ptd.net>" "Fri!
!
, 12 Jul 1996 11:00:03 -0400 (EDT)" "<Pine.LNX.3.93.960712103618.165A-100000@ptd.net>" "<01I6Z9CD4PO2000APU@SCI.WFBR.EDU>" 1705 54 "Xref: deanna.miranova.com lynx-dev:2597"] [2601 "Re:  Accessing password protected pages causes a  crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 12 Jul 1996 11:53:33 -0500 (EST)" "<01I6ZG43TIB6000APU@SCI.WFBR.EDU>" "" 1073 26 "Xref: deanna.miranova.com lynx-dev:2601"] [2610 "Re:  Re: Accessing password protected pages causes a  crash at exit" "Andrew Kuchling <amk@magnet.com>" "Fri, 12 Jul 1996 16:50:34 -0400 (EDT)" "<199607122050.QAA29148@lemur.magnet.com>" "<m2ivbttib7.fsf@deanna.miranova.com>" 674 21 "Xref: deanna.miranova.com lynx-dev:2610"] [2611 "Re:  Re: Accessing password protected pages causes a  crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 12 Jul 1996 19:08:30 -0500 (EST)" "<01I6ZV2K4L5U000APU@SCI.WFBR.EDU>" "" 1544 35 "Xref: deanna.miranova.com lynx-dev:2611"] [2656 " Re: Accessing password protected p!
!
ages causes a crash at exit" "Steven L Baur <steve@miranova.com>" "14 Jul 1996 18:35:15 -0700" "<m2d91yxknk.fsf@totally-fudged-out-message-id>" "<01I72EJTIDEQ000LT1@SCI.WFBR.EDU>" 1033 24 "Xref: deanna.miranova.com lynx-dev:2656"] [2662 " Character styles for lynx2-5FM (patch follows in next mail)" "Rob Partington <rjp@heffer.demon.co.uk>" "Mon, 15 Jul 1996 13:02:32 +0000 (GMT)" "<199607151302.NAA02502@heffer.demon.co.uk>" "" 2196 57 "Xref: deanna.miranova.com lynx-dev:2662"] [2668 " Re: Accessing password protected pages causes a crash at exit" "\"Mark T. Gray\" <markgray@postoffice.ptd.net>" "Mon, 15 Jul 1996 10:29:01 -0400 (EDT)" "<Pine.LNX.3.93.960715070549.545B-100000@ptd.net>" "" 1706 35 "Xref: deanna.miranova.com lynx-dev:2668"] [2670 "Re:  Re: Accessing password protected pages causes a crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Mon, 15 Jul 1996 12:58:56 -0500 (EST)" "<01I73NNTX6UQ0002FJ@SCI.WFBR.EDU>" "" 3846 71 "Xref: deanna.miranova.com lynx-dev:2670"!
!
] [2681 " New patch for lynx2-5FM character styles" "Rob Partington <rjp@heffer.demon.co.uk>" "Mon, 15 Jul 1996 23:52:19 +0000 (GMT)" "<199607152352.XAA06357@heffer.demon.co.uk>" "" 25730 1061 "Xref: deanna.miranova.com lynx-dev:2681"] [2705 " Re: Vim, Lynx" "Bill Hogan <bhogan@bedlam.rahul.net>" "Tue, 16 Jul 96 23:57 PDT" "<m0ugQXx-0003pZC@bedlam.rahul.net>" "<m0ugJFn-0003pZC@bedlam.rahul.net> <Pine.SUN.3.90.960716181519.15418A-100000@foxtrot.rahul.net>" 1736 61 "Xref: deanna.miranova.com lynx-dev:2705"] [2747 " Another round of Makefile fixes" "lvirden@cas.org (Larry W. Virden, x2487)" "Thu, 18 Jul 1996 07:28:49 -0400" "<9607180728.AA11712@cas.org>" "" 50580 1293 "Xref: deanna.miranova.com lynx-dev:2747"] [2751 " <isindex> support" "\"Christopher R. Maden\" <crm@ebt.com>" "Thu, 18 Jul 1996 14:15:04 GMT" "<199607181415.OAA02972@phaser.EBT.COM>" "" 831 22 "Xref: deanna.miranova.com lynx-dev:2751"] [2756 " Lynx and databases" "Duncan Hill <dhill@sunbeach.net>" "Thu, 18 Jul 1996!
!
 11:36:12 +1030 (???)" "<Pine.LNX.3.91.960718113344.2569A-100000@deathstar.sunbeach.net>" "" 758 25 "Xref: deanna.miranova.com lynx-dev:2756"] [2757 " lynx with crawl and traversal (renaming outputs)" "Duncan Hill <dhill@sunbeach.net>" "Thu, 18 Jul 1996 08:12:30 +1030 (???)" "<m2pw5t2yzb.fsf@totally-fudged-out-message-id>" "" 811 23 "Xref: deanna.miranova.com lynx-dev:2757"] [2759 "Re:  Re: \"Version\"" "lyle@lion.quodata.com (Lyle H. Gray)" "Thu, 18 Jul 1996 09:22:36 -0400" "<m2n30x2yz8.fsf@totally-fudged-out-message-id>" "" 1161 26 "Xref: deanna.miranova.com lynx-dev:2759"] [2761 "Re:   Re: \"Version\"" "Bela Lubkin <filbo@armory.com>" "Thu, 18 Jul 1996 01:50:41 -0700" "<m2k9w12yz8.fsf@totally-fudged-out-message-id>" "" 8242 183 "Xref: deanna.miranova.com lynx-dev:2761"] [2762 " <isindex> support" "\"Christopher R. Maden\" <crm@ebt.com>" "Thu, 18 Jul 1996 14:15:04 GMT" "<m2ivbl2yz8.fsf@totally-fudged-out-message-id>" "" 1013 28 "Xref: deanna.miranova.com lynx-dev:2762"] [276!
!
5 "Re:  Re: Making lynx smaller for menu-only usage." "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 18 Jul 1996 13:36:00 -0500 (EST)" "<01I77XI9GJRY000X2U@SCI.WFBR.EDU>" "" 1017 24 "Xref: deanna.miranova.com lynx-dev:2765"] [2766 "Re:  Security problem with Lynx 2.5" "Jasvinder Singh <jassi@giasbma.vsnl.net.in>" "Thu, 18 Jul 1996 19:37:36 +0530 (IST)" "<m220i92vs1.fsf@totally-fudged-out-message-id>" "<Pine.SOL.3.93.960713162445.8728B-100000@giasbmb>" 8318 276 "Xref: deanna.miranova.com lynx-dev:2766"] [2768 "Re:  <isindex> support" "\"Christopher R. Maden\" <crm@ebt.com>" "Thu, 18 Jul 1996 18:03:28 GMT" "<199607181803.SAA03146@phaser.EBT.COM>" "<2.2.32.19960718170656.006fa020@rmii.com>" 464 15 "Xref: deanna.miranova.com lynx-dev:2768"] [2770 " Re: Usefulness of Lynx 2.5 for Blind" "\"Lloyd G. Rasmussen\" <lras@loc.gov>" "Thu, 18 Jul 96 14:41:18 EDT" "<64803.lras@loc.gov>" "" 3136 66 "Xref: deanna.miranova.com lynx-dev:2770"] [2774 "Re:   Re: \"Version\"" "Foteos Macrides <MA!
!
CRIDES@SCI.WFBR.EDU>" "Thu, 18 Jul 1996 17:22:34 -0500 (EST)" "<01I785BE9GLU000X2U@SCI.WFBR.EDU>" "" 4484 97 "Xref: deanna.miranova.com lynx-dev:2774"] [2778 " charset error" "svm@kozmix.ow.nl (Sander van Malssen)" "Thu, 18 Jul 1996 23:04:03 +0200 (MET DST)" "<m0uh0Eu-0006oUC@kozmix.ow.nl>" "" 458 14 "Xref: deanna.miranova.com lynx-dev:2778"] [2779 "Re:  <isindex> support" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 18 Jul 1996 15:48:20 -0500 (EST)" "<01I781R2COXE000X2U@SCI.WFBR.EDU>" "" 1496 34 "Xref: deanna.miranova.com lynx-dev:2779"] [2780 "Re:  Proxies" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 18 Jul 1996 19:06:01 -0500 (EST)" "<01I788VM1CA0000X2U@SCI.WFBR.EDU>" "" 1156 28 "Xref: deanna.miranova.com lynx-dev:2780"] [2781 " problems with lynx on vt100 (8-bit chars)" "\"J.B. Nicholson-Owens\" <jbn@mystery-train.cu-online.com>" "Thu, 18 Jul 96 18:01:14 -0500" "<9607182301.AA20698@mystery-train.cu-online.com>" "" 1665 35 "Xref: deanna.miranova.com lynx-dev:2781"] [!
!
2782 "Re:  Is it time for Lynx 2.5.1?" "Wayne Buttles <buttles@wsb.champlain.edu>" "Thu, 18 Jul 1996 19:26:01 -0400 (EDT)" "<Pine.LNX.3.94.960718192355.25868A-100000@wsb.champlain.edu>" "<Pine.ULT.3.92.960718161033.10952E-100000@acf2.NYU.EDU>" 381 14 "Xref: deanna.miranova.com lynx-dev:2782"] [2783 " Nevermind" "Wayne Buttles <buttles@wsb.champlain.edu>" "Thu, 18 Jul 1996 20:02:41 -0400 (EDT)" "<Pine.LNX.3.94.960718195919.26284A-100000@wsb.champlain.edu>" "<01I786IAF4N6000X2U@SCI.WFBR.EDU>" 529 15 "Xref: deanna.miranova.com lynx-dev:2783"] [2784 " Downloading Graphics" "jeffreyj@ksu.edu" "Thu, 18 Jul 1996 18:52:34 -0500 (CDT)" "<199607182352.SAA08226@nbc.ksu.ksu.edu>" "" 322 8 "Xref: deanna.miranova.com lynx-dev:2784"] [2785 " more about lynx vt* bug" "\"J.B. Nicholson-Owens\" <jbn@mystery-train.cu-online.com>" "Thu, 18 Jul 96 18:45:16 -0500" "<9607182345.AA20778@mystery-train.cu-online.com>" "" 2684 61 "Xref: deanna.miranova.com lynx-dev:2785"] [2786 "Re:  Is it time for Lynx!
!
 2.5.1?" "Subir Grewal <grewals@acf2.NYU.EDU>" "Thu, 18 Jul 1996 21:09:14 -0400 (EDT)" "<Pine.ULT.3.92.960718210307.20522A-100000@acf2.NYU.EDU>" "<01I786IAF4N6000X2U@SCI.WFBR.EDU>" 1474 31 "Xref: deanna.miranova.com lynx-dev:2786"] [2787 " Re: \"Version\"" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Fri, 19 Jul 1996 10:17:32 +0900" "<199607190117.KAA14346@ews07.nara.kindai.ac.jp>" "" 681 15 "Xref: deanna.miranova.com lynx-dev:2787"] [2788 "Re:  Re: \"Version\"" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Fri, 19 Jul 1996 10:24:15 +0900" "<199607190124.KAA14372@ews07.nara.kindai.ac.jp>" "" 421 11 "Xref: deanna.miranova.com lynx-dev:2788"] [2789 "Re:  Downloading Graphics" "Captain Horatio Pugwash <jacrutu@mv.mv.com>" "Thu, 18 Jul 1996 22:18:41 -0400 (EDT)" "<199607190218.WAA04665@mv.mv.com>" "<199607182352.SAA08226@nbc.ksu.ksu.edu>" 691 17 "Xref: deanna.miranova.com lynx-dev:2789"] [2790 " Re: \"Version\"" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Fri, 19 Ju!
!
l 1996 10:47:57 +0900" "<199607190147.KAA14452@ews07.nara.kindai.ac.jp>" "" 863 23 "Xref: deanna.miranova.com lynx-dev:2790"] [2791 "Re:  I finally did it..." "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Fri, 19 Jul 1996 11:12:55 +0900" "<199607190212.LAA14617@ews07.nara.kindai.ac.jp>" "" 325 9 "Xref: deanna.miranova.com lynx-dev:2791"] [2792 " VT100, all links reverse." "\"Dan J. Fraser\" <dfraser@mother.com>" "Fri, 19 Jul 1996 00:38:47 -0400 (EDT)" "<Pine.NEB.3.94.960719003725.19178A-100000@prospero.ca>" "" 575 21 "Xref: deanna.miranova.com lynx-dev:2792"] [2793 " Partington patch for character styles with ncurses" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Fri, 19 Jul 1996 13:30:34 +0900" "<199607190430.NAA15044@ews07.nara.kindai.ac.jp>" "" 26152 1061 "Xref: deanna.miranova.com lynx-dev:2793"] [2794 "Re:   Re: \"Version\"" "Bela Lubkin <filbo@armory.com>" "Thu, 18 Jul 1996 23:22:08 -0700" " <9607182322.aa10558@deepthought.armory.com>" "" 3442 73 "Xref: deanna.mi!
!
ranova.com lynx-dev:2794"] [2795 "Re:  Re: Making lynx smaller for menu-only usage." "david@djwhome.demon.co.uk (David Woolley)" "Thu, 18 Jul 1996 20:24:06 +0100 (BST)" "<m0ugygB-0005jYC@djwhome.demon.co.uk>" "<199607180129.KAA10462@ews07.nara.kindai.ac.jp>" 2806 56 "Xref: deanna.miranova.com lynx-dev:2795"] [2796 " please reply" "st2f304@hsvax1.hs.uni-hamburg.de (Phillip Helbig)" "Fri, 19 Jul 1996 09:54:25 +0200" "<96071909542521@hsvax1.hs.uni-hamburg.de>" "" 2490 62 "Xref: deanna.miranova.com lynx-dev:2796"] [2797 "Re:  A little \"goto\" suggestion..." "Ka-Ping Yee <kryee@math.uwaterloo.ca>" "Fri, 19 Jul 1996 07:01:25 -0400" "<199607191101.HAA10250@math.uwaterloo.ca>" "" 626 19 "Xref: deanna.miranova.com lynx-dev:2797"] [2798 "Re:  Downloading Graphics" "jspath@mail.bcpl.lib.md.us (Webmaster Jim)" "Fri, 19 Jul 1996 07:47:34 -0400" "<9607191147.AA06735@mail>" "" 545 17 "Xref: deanna.miranova.com lynx-dev:2798"] [2799 "Re:  Lynx and databases" "Duncan Hill <dhill@sunbeach.net>!
!
" "Fri, 19 Jul 1996 07:50:08 +1030 (???)" "<Pine.LNX.3.91.960719074905.3016A-100000@deathstar.sunbeach.net>" "<01I782ZU5G2Q000X2U@SCI.WFBR.EDU>" 1080 26 "Xref: deanna.miranova.com lynx-dev:2799"] [2800 "Re:   Re: \"Version\"" "jspath@mail.bcpl.lib.md.us (Webmaster Jim)" "Fri, 19 Jul 1996 07:59:32 -0400" "<9607191159.AA07223@mail>" "" 576 16 "Xref: deanna.miranova.com lynx-dev:2800"] [2801 "Re:  please reply" "Al Gilman <asgilman@access.digex.net>" "Fri, 19 Jul 1996 08:38:27 -0400 (EDT)" "<199607191238.IAA22748@access2.digex.net>" "<96071909542521@hsvax1.hs.uni-hamburg.de>" 782 27 "Xref: deanna.miranova.com lynx-dev:2801"] [2802 " Re: Partington patch for character styles with ncurses" "Rob Partington <rjp@heffer.demon.co.uk>" "Fri, 19 Jul 1996 11:49:19 +0000 (GMT)" "<199607191149.LAA01713@heffer.demon.co.uk>" "<199607190430.NAA15044@ews07.nara.kindai.ac.jp>" 2075 48 "Xref: deanna.miranova.com lynx-dev:2802"] [2803 " lynx -source and redirections" "Jean van Waterschoot <jvwater!
!
@mcs.net>" "Fri, 19 Jul 1996 10:10:58 -0500 (CDT)" "<199607191510.KAA00482@Kitten.mcs.com>" "" 1211 30 "Xref: deanna.miranova.com lynx-dev:2803"] [2804 "Re:  Downloading Graphics" "\"Jeremy Vink (aka \\\"Datum\\\")\" <jvink@freenet.calgary.ab.ca>" "Fri, 19 Jul 1996 09:12:59 -0600 (MDT)" "<Pine.A32.3.92.960719091004.37086A-100000@srv1.freenet.calgary.ab.ca>" "<199607190218.WAA04665@mv.mv.com>" 1787 41 "Xref: deanna.miranova.com lynx-dev:2804"] [2805 "Re:  <isindex> support" "\"Christopher R. Maden\" <crm@ebt.com>" "Fri, 19 Jul 1996 15:41:30 GMT" "<199607191541.PAA03697@phaser.EBT.COM>" "<01I781R2COXE000X2U@SCI.WFBR.EDU>" 1274 30 "Xref: deanna.miranova.com lynx-dev:2805"] [2806 "Re:   Re: \"Version\"" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 19 Jul 1996 11:58:36 -0500 (EST)" "<01I797LDNZ4I001A9U@SCI.WFBR.EDU>" "" 4070 81 "Xref: deanna.miranova.com lynx-dev:2806"] [2807 "Re:  Re: Making lynx smaller for menu-only usage." "\"Carl D. Cravens\" <cravens@southwind.net>" "Fri, !
!
19 Jul 1996 11:37:17 -0500 (CDT)" "<Pine.BSI.3.95.960719113457.25381A-100000@onyx.southwind.net>" "<Pine.LNX.3.93.960718143322.1324B-100000@ptd.net>" 1713 38 "Xref: deanna.miranova.com lynx-dev:2807"] [2808 "Re:  VT100, all links reverse." "\"Carl D. Cravens\" <cravens@southwind.net>" "Fri, 19 Jul 1996 11:42:14 -0500 (CDT)" "<Pine.BSI.3.95.960719114014.25381B-100000@onyx.southwind.net>" "<Pine.NEB.3.94.960719003725.19178A-100000@prospero.ca>" 879 26 "Xref: deanna.miranova.com lynx-dev:2808"] [2809 "Re:  Downloading Graphics" "smcgee@sol.slcc.edu (Scott McGee (Personal))" "Fri, 19 Jul 1996 11:18:10 -0600" "<9607191718.AA02378@sol.slcc.edu.>" "" 1433 34 "Xref: deanna.miranova.com lynx-dev:2809"] [2810 "Re:  Re: Making lynx smaller for menu-only usage." "\"Mark T. Gray\" <markgray@postoffice.ptd.net>" "Fri, 19 Jul 1996 14:34:03 -0400 (EDT)" "<Pine.LNX.3.93.960719141229.1577B-100000@ptd.net>" "<Pine.BSI.3.95.960719113457.25381A-100000@onyx.southwind.net>" 1595 32 "Xref: deanna.mir!
!
anova.com lynx-dev:2810"] [2811 " Minor bug in " "Peter Rostin <russin@dynas.se>" "Fri, 19 Jul 1996 21:30:03 +0200 (MET DST)" "<Pine.GSO.3.94.960719200156.16673A-100000@spirit.dynas.se>" "" 2942 104 "Xref: deanna.miranova.com lynx-dev:2811"] [2812 " where to start on documentation" "Al Gilman <asgilman@access.digex.net>" "Fri, 19 Jul 1996 17:17:36 -0400 (EDT)" "<199607192117.RAA15383@access2.digex.net>" "<Pine.ULT.3.92.960718210307.20522A-100000@acf2.NYU.EDU>" 1710 47 "Xref: deanna.miranova.com lynx-dev:2812"] [2813 "Re:  Re: Partington patch for character styles with ncurses" "Audin Malmin <amalmin@halcyon.com>" "Fri, 19 Jul 1996 19:00:32 -0700 (PDT)" "<199607200200.AA19733@halcyon.com>" "<199607191149.LAA01713@heffer.demon.co.uk>" 562 14 "Xref: deanna.miranova.com lynx-dev:2813"] [2814 "Re:  charset error" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 19 Jul 1996 21:51:20 -0500 (EST)" "<01I79T0GC77M00008X@SCI.WFBR.EDU>" "" 812 20 "Xref: deanna.miranova.com lynx-dev:2814"] !
!
[2815 "Re:  I finally did it..." "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 19 Jul 1996 22:14:54 -0500 (EST)" "<01I79TDIZGVC00008X@SCI.WFBR.EDU>" "" 1310 32 "Xref: deanna.miranova.com lynx-dev:2815"] [2816 " Re: downloading graphics" "Al Gilman <asgilman@access.digex.net>" "Fri, 19 Jul 1996 22:42:57 -0400 (EDT)" "<199607200242.WAA02554@access2.digex.net>" "" 480 14 "Xref: deanna.miranova.com lynx-dev:2816"] [2817 "Re:  where to start on documentation" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 19 Jul 1996 23:13:31 -0500 (EST)" "<01I79VEBSIMQ00008X@SCI.WFBR.EDU>" "" 1357 30 "Xref: deanna.miranova.com lynx-dev:2817"] [2818 "Re:  Re: downloading graphics" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 19 Jul 1996 23:16:15 -0500 (EST)" "<01I79W4Z9A2000008X@SCI.WFBR.EDU>" "" 579 16 "Xref: deanna.miranova.com lynx-dev:2818"] [2819 "Re:  lynx -source and redirections" "Captain Horatio Pugwash <jacrutu@mv.mv.com>" "Sat, 20 Jul 1996 01:08:07 -0400 (EDT)" "<199607200508.BAA07!
!
934@mv.mv.com>" "<199607191510.KAA00482@Kitten.mcs.com>" 693 21 "Xref: deanna.miranova.com lynx-dev:2819"] [2820 "Re:  where to start on documentation" "Subir Grewal <grewals@acf2.NYU.EDU>" "Sat, 20 Jul 1996 01:11:55 -0400 (EDT)" "<Pine.ULT.3.92.960720010717.7903C-100000@acf2.NYU.EDU>" "<01I79VEBSIMQ00008X@SCI.WFBR.EDU>" 1555 32 "Xref: deanna.miranova.com lynx-dev:2820"] [2821 "Re:  jlynx?" "asada@three-a.co.jp (Takuya ASADA)" "Sat, 20 Jul 1996 19:49:06 +0900 (JST)" "<199607201049.TAA16771@benten.three-a.co.jp>" "<01I77WGYFV4I000X2U@SCI.WFBR.EDU>" 659 18 "Xref: deanna.miranova.com lynx-dev:2821"] [2822 "Re: Re:  where to start on documentation" "Al Gilman <asgilman@access.digex.net>" "Sat, 20 Jul 1996 10:02:37 -0400 (EDT)" "<199607201402.KAA14604@access2.digex.net>" "" 2441 57 "Xref: deanna.miranova.com lynx-dev:2822"] [2823 "Re:  lynx -source and redirections" "Jean van Waterschoot <jvwater@mcs.net>" "Sat, 20 Jul 1996 10:45:29 -0500 (CDT)" "<199607201545.KAA15604@Kitten.mcs.c!
!
om>" "" 654 18 "Xref: deanna.miranova.com lynx-dev:2823"] [2824 "Re: Re:  where to start on documentation" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Sat, 20 Jul 1996 12:57:01 -0500 (EST)" "<01I7AOEWJOLE0002N8@SCI.WFBR.EDU>" "" 4194 88 "Xref: deanna.miranova.com lynx-dev:2824"] [2825 "Re:  I finally did it..." "Walter Skorski <walt@genetics1.JMP.TJU.EDU>" "Sat, 20 Jul 1996 13:58:15 -0400 (EDT)" "<199607201758.NAA19555@clyde.jmp.tju.edu>" "<01I79TDIZGVC00008X@SCI.WFBR.EDU>" 1178 36 "Xref: deanna.miranova.com lynx-dev:2825"] [2826 "Re:  Re: Making lynx smaller for menu-only usage." "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Sun, 21 Jul 1996 11:52:52 +0900" "<199607210252.LAA20229@ews07.nara.kindai.ac.jp>" "" 1313 28 "Xref: deanna.miranova.com lynx-dev:2826"] [2827 " In Lynx 2.6 can I please have tables and better text attributes." "Andrew <android7@wwa.com>" "Sun, 21 Jul 96 02:21 CDT" "<m0uhspM-000rVwC@maki.wwa.com>" "" 425 11 "Xref: deanna.miranova.com lynx-dev:2827"] [2!
!
828 "Re:  Re: Making lynx smaller for menu-only usage." "jspath@mail.bcpl.lib.md.us (Webmaster Jim)" "Sun, 21 Jul 1996 07:08:42 -0400" "<9607211108.AA15378@mail>" "" 1158 25 "Xref: deanna.miranova.com lynx-dev:2828"] [2829 "Re:  receiving data counter??" "david@djwhome.demon.co.uk (David Woolley)" "Thu, 18 Jul 1996 21:36:14 +0100 (BST)" "<m0ugznz-0005jaC@djwhome.demon.co.uk>" "<01I76SZIA02W000QP2@SCI.WFBR.EDU>" 1937 41 "Xref: deanna.miranova.com lynx-dev:2829"] [2830 " Case sensitive FTP sorting (patch)" "Sean Bolt <sbolt@pobox.com>" "Sun, 21 Jul 1996 10:07:18 -0400 (EDT)" "<9607211407.AA16181@olie.wvitcoe.wvnet.edu>" "" 7859 195 "Xref: deanna.miranova.com lynx-dev:2830"]))
  tm-gnus/decode-summary-from-and-subjects()
  run-hooks(gnus-select-group-hook)
  # bind (did-select quit-config new-group no-display kill-buffer no-article show-all group)
  gnus-summary-read-group("nnml:lynx-dev" nil nil)
  # bind (group number active marked entry group no-article all)
  gnus-group-read-group(nil nil nil)
  # bind (group no-article all)
  gnus-topic-read-group(nil)
  # bind (command-debug-status)
  call-interactively(gnus-topic-read-group)
  # (condition-case ... . error)
  # (catch top-level ...)


C Backtrace:
#0  0x40204741 in __kill ()
#1  0x808a23d in fatal_error_signal (sig=6) at emacs.c:193
#2  0xbfff8f64 in __ypbindlist ()
#3  0x4023218d in gsignal ()
#4  0x819f9de in ccl_driver (ccl=0x87a8494, 
    src=0x87a8800 " \201\201\201\201\201\201\b\201 >\201\217\b\217\" . [charset intern mime-charset-coding-system-alist coding-system-list])\bX\201\217\b\201Z\201\\\\\201\217\201\bX\201\217\b\201Z\026\013\201\025\201\217\016\013\201\201\201\bX\201\217\b\201Z\201\\\\\201\217\201\bX\201\217\b\201Z\201\\\\\201\217\201\bX"..., dst=0x88207e0, n=13, 
    end_flag=0) at /i/xemacs-20.0-b26/src/./lisp.h:1221
#5  0x81a829c in mule_decode (decoding=0x87a8400, 
    src=0x87a8800 " \201\201\201\201\201\201\b\201 >\201\217\b\217\" . [charset intern mime-charset-coding-system-alist coding-system-list])\bX\201\217\b\201Z\201\\\\\201\217\201\bX\201\217\b\201Z\026\013\201\025\201\217\016\013\201\201\201\bX\201\217\b\201Z\201\\\\\201\217\201\bX\201\217\b\201Z\201\\\\\201\217\201\bX"..., dst=0x88207e0, n=13)
    at /i/xemacs-20.0-b26/src/./mule-coding.c:2111
#6  0x81a7a05 in decoding_reader (stream=0x87a8400, 
    data=0x87a8800 " \201\201\201\201\201\201\b\201 >\201\217\b\217\" . [charset intern mime-charset-coding-system-alist coding-system-list])\bX\201\217\b\201Z\201\\\\\201\217\201\bX\201\217\b\201Z\026\013\201\025\201\217\016\013\201\201\201\bX\201\217\b\201Z\201\\\\\201\217\201\bX\201\217\b\201Z\201\\\\\201\217\201\bX"..., size=512)
    at /i/xemacs-20.0-b26/src/./mule-coding.c:1896
#7  0x80fbb49 in Lstream_raw_read (lstr=0x87a8400, 
    buffer=0x87a8800 " \201\201\201\201\201\201\b\201 >\201\217\b\217\" . [charset intern mime-charset-coding-system-alist coding-system-list])\bX\201\217\b\201Z\201\\\\\201\217\201\bX\201\217\b\201Z\026\013\201\025\201\217\016\013\201\201\201\bX\201\217\b\201Z\201\\\\\201\217\201\bX\201\217\b\201Z\201\\\\\201\217\201\bX"..., size=512)
    at lstream.c:547
#8  0x80fbc7a in Lstream_read (lstr=0x87a8400, data=0xbfff92a4, size=16384)
    at lstream.c:565
#9  0x80679ed in Fcall_process_internal (nargs=4, args=0xbfffd3fc)
    at callproc.c:571
#10 0x808ff43 in funcall_recording_as (recorded_as=405810140, nargs=5, 
    args=0xbfffd3f8) at eval.c:3191
#11 0x80905d2 in Fapply (nargs=6, args=0xbfffd3f8) at eval.c:3253
#12 0x808ff43 in funcall_recording_as (recorded_as=405822284, nargs=7, 
    args=0xbfffd3f4) at eval.c:3191
#13 0x8090113 in Ffuncall (nargs=7, args=0xbfffd3f4) at eval.c:3253
#14 0x80638d3 in Fbyte_code (bytestr=941823064, vector=1210258548, maxdepth=7)
    at bytecode.c:419
#15 0x8090eac in funcall_lambda (fun=404948524, nargs=4, arg_vector=0xbfffd784)
    at eval.c:3636
#16 0x809000e in funcall_recording_as (recorded_as=406451884, nargs=5, 
    args=0xbfffd780) at eval.c:3223
#17 0x80905d2 in Fapply (nargs=6, args=0xbfffd780) at eval.c:3253
#18 0x808ff43 in funcall_recording_as (recorded_as=405822284, nargs=7, 
    args=0xbfffd77c) at eval.c:3191
#19 0x8090113 in Ffuncall (nargs=7, args=0xbfffd77c) at eval.c:3253
#20 0x80638d3 in Fbyte_code (bytestr=941822536, vector=1210258172, maxdepth=7)
    at bytecode.c:419
#21 0x8090eac in funcall_lambda (fun=404948680, nargs=6, arg_vector=0xbfffd920)
    at eval.c:3636
#22 0x809000e in funcall_recording_as (recorded_as=406451980, nargs=7, 
    args=0xbfffd91c) at eval.c:3223
#23 0x8090113 in Ffuncall (nargs=7, args=0xbfffd91c) at eval.c:3253
#24 0x80638d3 in Fbyte_code (bytestr=943209040, vector=1212838144, maxdepth=7)
    at bytecode.c:419
#25 0x8090eac in funcall_lambda (fun=407865220, nargs=3, arg_vector=0xbfffdacc)
    at eval.c:3636
#26 0x809000e in funcall_recording_as (recorded_as=405852908, nargs=4, 
    args=0xbfffdac8) at eval.c:3223
#27 0x8090113 in Ffuncall (nargs=4, args=0xbfffdac8) at eval.c:3253
#28 0x80638d3 in Fbyte_code (bytestr=942249760, vector=1210685272, maxdepth=4)
    at bytecode.c:419
#29 0x8090eac in funcall_lambda (fun=405375160, nargs=2, arg_vector=0xbfffdc30)
    at eval.c:3636
#30 0x809000e in funcall_recording_as (recorded_as=406564836, nargs=3, 
    args=0xbfffdc2c) at eval.c:3223
#31 0x8090113 in Ffuncall (nargs=3, args=0xbfffdc2c) at eval.c:3253
#32 0x80638d3 in Fbyte_code (bytestr=947690508, vector=1216481600, maxdepth=4)
    at bytecode.c:419
#33 0x8090eac in funcall_lambda (fun=408180900, nargs=2, arg_vector=0xbfffddf0)
    at eval.c:3636
#34 0x809000e in funcall_recording_as (recorded_as=408179796, nargs=3, 
    args=0xbfffddec) at eval.c:3223
#35 0x8090113 in Ffuncall (nargs=3, args=0xbfffddec) at eval.c:3253
#36 0x80638d3 in Fbyte_code (bytestr=947705540, vector=1216513856, maxdepth=4)
    at bytecode.c:419
#37 0x8090eac in funcall_lambda (fun=408288100, nargs=3, arg_vector=0xbfffdfc8)
    at eval.c:3636
#38 0x809000e in funcall_recording_as (recorded_as=409735988, nargs=4, 
    args=0xbfffdfc4) at eval.c:3223
#39 0x8090113 in Ffuncall (nargs=4, args=0xbfffdfc4) at eval.c:3253
#40 0x80638d3 in Fbyte_code (bytestr=947705372, vector=1216513920, maxdepth=5)
    at bytecode.c:419
#41 0x8090eac in funcall_lambda (fun=408288068, nargs=1, arg_vector=0xbfffe24c)
    at eval.c:3636
#42 0x809000e in funcall_recording_as (recorded_as=409735964, nargs=2, 
    args=0xbfffe248) at eval.c:3223
#43 0x8090113 in Ffuncall (nargs=2, args=0xbfffe248) at eval.c:3253
#44 0x80638d3 in Fbyte_code (bytestr=947706676, vector=1216514048, maxdepth=5)
    at bytecode.c:419
#45 0x8090eac in funcall_lambda (fun=408287940, nargs=1, arg_vector=0xbfffe45c)
    at eval.c:3636
#46 0x809000e in funcall_recording_as (recorded_as=409830340, nargs=2, 
    args=0xbfffe458) at eval.c:3223
#47 0x8090113 in Ffuncall (nargs=2, args=0xbfffe458) at eval.c:3253
#48 0x80638d3 in Fbyte_code (bytestr=947706436, vector=1216514560, maxdepth=4)
    at bytecode.c:419
#49 0x8090eac in funcall_lambda (fun=410055588, nargs=1, arg_vector=0xbfffe564)
    at eval.c:3636
#50 0x809000e in funcall_recording_as (recorded_as=410055588, nargs=2, 
    args=0xbfffe560) at eval.c:3223
#51 0x8091720 in call1 (fn=410055588, arg0=1216443456) at eval.c:3253
#52 0x80cc9d8 in mapcar1 (leni=145, vals=0xbfffe5d4, fn=410055588, 
    seq=678658588) at fns.c:3321
#53 0x80ccb37 in Fmapcar (fn=410055588, seq=678658588) at fns.c:3382
#54 0x8090809 in primitive_funcall (fn=0x80ccae8 <Fmapcar>, nargs=2, 
    args=0xbfffe910) at eval.c:3486
#55 0x80909b8 in funcall_subr (subr=0x8205d5c, args=0xbfffe910) at eval.c:3526
#56 0x808ff8d in funcall_recording_as (recorded_as=405830860, nargs=3, 
    args=0xbfffe90c) at eval.c:3207
#57 0x8090113 in Ffuncall (nargs=3, args=0xbfffe90c) at eval.c:3253
#58 0x80638d3 in Fbyte_code (bytestr=947706220, vector=1216514112, maxdepth=3)
    at bytecode.c:419
#59 0x8090eac in funcall_lambda (fun=410276164, nargs=0, arg_vector=0xbfffea80)
    at eval.c:3636
#60 0x809000e in funcall_recording_as (recorded_as=409830292, nargs=1, 
    args=0xbfffea7c) at eval.c:3223
#61 0x809147e in run_hook_with_args_in_buffer (buf=0x843e200, nargs=1, 
    args=0xbfffea7c, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3253
#62 0x80914f6 in run_hook_with_args (nargs=1, args=0xbfffea7c, 
    cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3845
#63 0x80911c7 in Frun_hooks (nargs=1, args=0xbffff39c) at eval.c:3697
#64 0x808ff43 in funcall_recording_as (recorded_as=405821780, nargs=2, 
    args=0xbffff398) at eval.c:3191
#65 0x8090113 in Ffuncall (nargs=2, args=0xbffff398) at eval.c:3253
#66 0x80638d3 in Fbyte_code (bytestr=946477804, vector=1212096512, maxdepth=4)
    at bytecode.c:419
#67 0x8090eac in funcall_lambda (fun=409602532, nargs=3, arg_vector=0xbffff654)
    at eval.c:3636
#68 0x809000e in funcall_recording_as (recorded_as=409402500, nargs=4, 
    args=0xbffff650) at eval.c:3223
#69 0x8090113 in Ffuncall (nargs=4, args=0xbffff650) at eval.c:3253
#70 0x80638d3 in Fbyte_code (bytestr=945394856, vector=1214474368, maxdepth=6)
    at bytecode.c:419
#71 0x8090eac in funcall_lambda (fun=409401060, nargs=3, arg_vector=0xbffff808)
    at eval.c:3636
#72 0x809000e in funcall_recording_as (recorded_as=408749092, nargs=4, 
    args=0xbffff804) at eval.c:3223
#73 0x8090113 in Ffuncall (nargs=4, args=0xbffff804) at eval.c:3253
#74 0x80638d3 in Fbyte_code (bytestr=944522192, vector=1215203584, maxdepth=4)
    at bytecode.c:419
#75 0x8090eac in funcall_lambda (fun=409899332, nargs=1, arg_vector=0xbffff930)
    at eval.c:3636
#76 0x809000e in funcall_recording_as (recorded_as=409832388, nargs=2, 
    args=0xbffff92c) at eval.c:3223
#77 0x8090113 in Ffuncall (nargs=2, args=0xbffff92c) at eval.c:3253
#78 0x8066cea in Fcall_interactively (function=409832388, 
    record_flag=405733380, keys=405733380) at callint.c:931
#79 0x808eca8 in Fcommand_execute (cmd=409832388, record=405733380, 
    keys=405733380) at eval.c:2628
#80 0x80a28be in execute_command_event (command_builder=0x832b700, 
    event=407309220) at event-stream.c:3484
#81 0x80a3aaf in Fdispatch_event (event=407309220) at event-stream.c:3819
#82 0x80709b3 in Fcommand_loop_1 () at cmdloop.c:542
#83 0x80706cf in command_loop_1 (dummy=405733380) at cmdloop.c:462
#84 0x808d35a in condition_case_1 (handlers=405733476, 
    bfun=0x8070664 <command_loop_1>, barg=405733380, 
    hfun=0x806fa68 <cmd_error>, harg=405733380) at eval.c:1672
#85 0x8070b64 in command_loop_2 (dummy=405733380) at cmdloop.c:224
#86 0x808d175 in internal_catch (tag=405811148, 
    func=0x8070b44 <command_loop_2>, arg=405733380, threw=0x0) at eval.c:1347
#87 0x806ff2e in initial_command_loop (load_me=405733380) at cmdloop.c:273
#88 0x808ad54 in Frunning_temacs_p () at emacs.c:1374
#89 0x808b0e2 in main (argc=1, argv=0xbffffc28, envp=0xbffffc30)
    at emacs.c:1518
#90 0x804ed4b in _start ()


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 13:20:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA21095 for xemacs-beta-people; Sun, 21 Jul 1996 13:20:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA21092 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 13:20:45 -0500 (CDT)
Received: from monolith.spry.com (wmperry.oz.net [207.13.185.53]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA21225 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 13:20:39 -0500 (CDT)
Received: (from wmperry@localhost) by monolith.spry.com (8.7.4/8.7.3) id LAA09747; Sun, 21 Jul 1996 11:30:54 -0700
Date: Sun, 21 Jul 1996 11:30:54 -0700
Message-Id: <199607211830.LAA09747@monolith.spry.com>
From: William Perry <wmperry@aventail.com>
To: xemacs-beta@xemacs.org
Subject: Any success w/shared library support?
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Has anybody had success with the shared library support?  I threw in the
necessary stuff for Linux/ELF, and it compile and links, but when it goes
to actually dump the executable, it fails an assertion.  This is with my
GPM patches, but that shouldn't affect anything significant.

-Bill P.

cd ../lwlib; make 
make[1]: Entering directory `/usr/local/src/xemacs-20.0-b26/lwlib'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/local/src/xemacs-20.0-b26/lwlib'
EMACSLOADPATH="/usr/local/src/xemacs-20.0-b26/src/../lisp/prim"   ./temacs -batch -l loadup.el dump

Loading loadup.el...
Using load-path (/usr/local/src/xemacs-20.0-b26/src/../lisp/prim)
Loading backquote... (2556)Fatal error: assertion failed, file lisp.h, line 1023, OBJECT_TYPEP (_obj, class_symbol)
make: *** [xemacs] IOT trap/Abort

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 22:45:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA22055 for xemacs-beta-people; Sun, 21 Jul 1996 22:45:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA22052 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 22:45:22 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA21556 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 22:45:18 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id UAA23161; Sun, 21 Jul 1996 20:44:50 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA16271; Sun, 21 Jul 1996 20:44:48 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA01985; Sun, 21 Jul 1996 20:44:46 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA07059; Sun, 21 Jul 1996 20:44:44 -0700
Date: Sun, 21 Jul 1996 20:44:44 -0700
Message-Id: <199607220344.UAA07059@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Jaye Mathisen  <mrcpu@cdsnet.net>
Cc: xemacs-beta@xemacs.org
Subject: Font-lock weirdness for .pl files.
In-Reply-To: <Pine.NEB.3.94.960720131306.5880r-100000@mail.cdsnet.net>
References: <Pine.NEB.3.94.960720131306.5880r-100000@mail.cdsnet.net>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Jaye" == Jaye Mathisen <mrcpu@cdsnet.net> writes:

Jaye> Not sure it's an xemacs problem, but I don't have a different good idea on
Jaye> where to send this.

Jaye> The following code fragment screws up fontlock royally.  Specifically,
Jaye> putting the cursor after the last paren on the follow line causes the [ to
Jaye> blink, and such.

Jaye> the [^= combo seems to throw things off.  Anybody have a quick fix?

Jaye>                 if (/User-Name = "([^"]+)"/) {
Jaye>                         $user = $1;
Jaye>                         }

Try (untested) 
                if (/User-Name = "([^\"]+)"/) {

No perl mode does a perfect job of parsing perl.  You have to help it
out sometimes...

Martin

From xemacs-beta-request@cs.uiuc.edu  Sun Jul 21 23:06:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA22104 for xemacs-beta-people; Sun, 21 Jul 1996 23:06:49 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA22101 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 21 Jul 1996 23:06:48 -0500 (CDT)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA21571 for <xemacs-beta@xemacs.org>; Sun, 21 Jul 1996 23:06:44 -0500 (CDT)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.6.12/8.6.12) with SMTP id VAA17979; Sun, 21 Jul 1996 21:06:44 -0700
Date: Sun, 21 Jul 1996 21:06:40 -0700 (PDT)
From: Jaye Mathisen  <mrcpu@cdsnet.net>
To: Martin Buchholz <mrb@eng.sun.com>
cc: xemacs-beta@xemacs.org
Subject: Re: Font-lock weirdness for .pl files.
In-Reply-To: <199607220344.UAA07059@xemacs.eng.sun.com>
Message-ID: <Pine.NEB.3.94.960721210533.5880q-100000@mail.cdsnet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hey!  That worked fine.  I guess I should've thought of it.  Perl is not
my mother tongue, so when I find a RE that works, I never touch 'em again.

On Sun, 21 Jul 1996, Martin Buchholz wrote:

> Date: Sun, 21 Jul 1996 20:44:44 -0700
> From: Martin Buchholz <mrb@eng.sun.com>
> To: Jaye Mathisen <mrcpu@cdsnet.net>
> Cc: xemacs-beta@xemacs.org
> Subject: Font-lock weirdness for .pl files.
> 
> >>>>> "Jaye" == Jaye Mathisen <mrcpu@cdsnet.net> writes:
> 
> Jaye> Not sure it's an xemacs problem, but I don't have a different good idea on
> Jaye> where to send this.
> 
> Jaye> The following code fragment screws up fontlock royally.  Specifically,
> Jaye> putting the cursor after the last paren on the follow line causes the [ to
> Jaye> blink, and such.
> 
> Jaye> the [^= combo seems to throw things off.  Anybody have a quick fix?
> 
> Jaye>                 if (/User-Name = "([^"]+)"/) {
> Jaye>                         $user = $1;
> Jaye>                         }
> 
> Try (untested) 
>                 if (/User-Name = "([^\"]+)"/) {
> 
> No perl mode does a perfect job of parsing perl.  You have to help it
> out sometimes...
> 
> Martin
> 


From xemacs-beta-request@cs.uiuc.edu  Mon Jul 22 01:01:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA22306 for xemacs-beta-people; Mon, 22 Jul 1996 01:01:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA22303 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 22 Jul 1996 01:01:45 -0500 (CDT)
Received: from teapot.netman.dk (teapot.netman.dk [193.88.72.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA21684 for <xemacs-beta@xemacs.org>; Mon, 22 Jul 1996 01:01:38 -0500 (CDT)
Received: (from tmadsen@localhost) by teapot.netman.dk (8.7.1/8.7.1) id IAA29262; Mon, 22 Jul 1996 08:01:09 +0200 (MET DST)
To: xemacs-beta@xemacs.org
Subject: Change in low-level interface to shared libraries
From: Tonny Madsen <Tonny.Madsen@netman.dk>
Date: 22 Jul 1996 08:01:08 +0200
Message-ID: <rrzq4sn7x7.fsf@teapot.netman.dk>
Lines: 21
X-Mailer: Gnus v5.2.29/XEmacs 20.0

Hi'

I would like to make one interface change for the next version of
shlib: shlib_lowlevel_get will have one more argument, that specifies
the wanted type of symbol. For now the type will always be
SHLIB_LL_FUNCTION (= 0). I.e.

void *shlib_lowlevel_get(void *handle, char *name, unsigned int type)

#define SHLIB_LL_FUNCTION	0

This change is introduced to allow the shlib module to retrieve
variable addresses in the future. (The implementation of shared
libraries for some platforms, most notably hpux, seem to require
this).

/tonny
-- 
Tonny Madsen, NetMan a/s, Vandtaarnsvej 77, DK-2860 Soeborg, Denmark
E-mail: Tonny.Madsen@netman.dk 
Telephone: +45 39 66 40 20 Fax: +45 39 66 06 75

From xemacs-beta-request@cs.uiuc.edu  Mon Jul 22 01:13:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA22355 for xemacs-beta-people; Mon, 22 Jul 1996 01:13:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA22352 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 22 Jul 1996 01:12:59 -0500 (CDT)
Received: from teapot.netman.dk (teapot.netman.dk [193.88.72.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA21701 for <xemacs-beta@xemacs.org>; Mon, 22 Jul 1996 01:12:56 -0500 (CDT)
Received: (from tmadsen@localhost) by teapot.netman.dk (8.7.1/8.7.1) id IAA29314; Mon, 22 Jul 1996 08:12:27 +0200 (MET DST)
To: xemacs-beta@xemacs.org
Subject: [SHLIB] classes.c split into lobject.c and clos.c???
From: Tonny Madsen <Tonny.Madsen@netman.dk>
Date: 22 Jul 1996 08:12:26 +0200
Message-ID: <rrybkcn7ed.fsf@teapot.netman.dk>
Lines: 30
X-Mailer: Gnus v5.2.29/XEmacs 20.0

Hi' Everybody,

I have reviewed some of my code and ideas for the near future in the
weekend, and I found one item that could benefit for immediate action.

Today the files classes.[ch] contain code for two completely different
modules:

- the LOBJECT stuff that is an generalization of the LHEADER and
  LCHEADER allocation stuff found in 19.14 and 20.0-b26 and

- the beginning of an object-oriented system for xemacs based closely
  on CLOS.

This can, in the end, become a very big file, and I therefore want to
split it in the next version of shlib unless somebody disagree a lot
with this disposition :-/.

I hope to be able to distribute this next version on Thursday (or
Friday, the lastest) and the problems you face by this change should
therefore be minimal.

If anybody have low-level shared library interfaces you would like to
distribute with this version, fell free to mail me.

/tonny
-- 
Tonny Madsen, NetMan a/s, Vandtaarnsvej 77, DK-2860 Soeborg, Denmark
E-mail: Tonny.Madsen@netman.dk 
Telephone: +45 39 66 40 20 Fax: +45 39 66 06 75

From xemacs-beta-request@cs.uiuc.edu  Mon Jul 22 01:28:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA22370 for xemacs-beta-people; Mon, 22 Jul 1996 01:28:00 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA22367 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 22 Jul 1996 01:27:58 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA08698 for <xemacs-beta@cs.uiuc.edu>; Mon, 22 Jul 1996 01:28:00 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Mon, 22 Jul 1996 08:27:47 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id IAA13104; Mon, 22 Jul 1996 08:27:29 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id IAA09739;
          Mon, 22 Jul 1996 08:25:35 +0200
Date: Mon, 22 Jul 1996 08:25:35 +0200
Message-Id: <199607220625.IAA09739@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de>
To: xemacs-beta@cs.uiuc.edu
Subject: Missing extent feature
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q(\V9 
        +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy 
        ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x 
        zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B: 
        s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII

I want to insert a string in a buffer, but display a glyph instead of
this text. I've tried this by building an extent with the string as
it's content and the glyph as it's end glyph and with the invisible
property set to t. But the result was, that nothing is displayed. 
Isn't it possible to do such a thing with the XEmacs 19.14?

From xemacs-beta-request@cs.uiuc.edu  Mon Jul 22 02:12:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA22459 for xemacs-beta-people; Mon, 22 Jul 1996 02:12:58 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA22456 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 22 Jul 1996 02:12:53 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA09291 for <xemacs-beta@cs.uiuc.edu>; Mon, 22 Jul 1996 02:12:53 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id AAA19602; Mon, 22 Jul 1996 00:11:10 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Missing extent feature
References: <199607220625.IAA09739@daedalus.tnt.uni-hannover.de>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Heiko Muenkel's message of Mon, 22 Jul 1996 08:25:35 +0200
Mime-Version: 1.0 (generated by tm-edit 7.72)
Content-Type: text/plain; charset=US-ASCII
Date: 22 Jul 1996 00:11:09 -0700
Message-ID: <m2ivbgiwz6.fsf@deanna.miranova.com>
Lines: 14
X-Mailer: Gnus v5.2.37/XEmacs 19.14

>>>>> "Heiko" == Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de> writes:

Heiko> I want to insert a string in a buffer, but display a glyph instead of
Heiko> this text.

The simplest code I can think of that does this is smiley.el in
lisp/gnus.  The trick is that you have to attach the glyph as an
annotation ...

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Jul 22 09:08:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA26958 for xemacs-beta-people; Mon, 22 Jul 1996 09:08:12 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA26955 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 22 Jul 1996 09:08:05 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA22862 for <xemacs-beta@xemacs.org>; Mon, 22 Jul 1996 09:07:54 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.6.12/8.6.9) with ESMTP id JAA06749; Mon, 22 Jul 1996 09:07:56 -0500
Message-Id: <199607221407.JAA06749@nvwls.cc.purdue.edu>
To: Jaye Mathisen <mrcpu@cdsnet.net>
cc: xemacs-beta@xemacs.org
Subject: Re: Font-lock weirdness for .pl files. 
In-reply-to: Your message of "Sat, 20 Jul 1996 13:15:29 MST."
             <Pine.NEB.3.94.960720131306.5880r-100000@mail.cdsnet.net> 
Date: Mon, 22 Jul 1996 09:07:53 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


>>>>> "Jaye" == Jaye Mathisen <mrcpu@cdsnet.net> writes:

    Jaye> Not sure it's an xemacs problem, but I don't have a
    Jaye> different good idea on where to send this.

    Jaye> The following code fragment screws up fontlock royally.
    Jaye> Specifically, putting the cursor after the last paren on the
    Jaye> follow line causes the [ to blink, and such.


	if (/User-Name = "([^\"]+)"/) {
		$user = $1;
	}

Escaping the double quote works for me (under cperl-mode).

--
Joseph J. Nuspl Jr.
Purdue Data Network



From xemacs-beta-request@cs.uiuc.edu  Mon Jul 22 12:30:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA27521 for xemacs-beta-people; Mon, 22 Jul 1996 12:30:54 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA27518 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 22 Jul 1996 12:30:52 -0500 (CDT)
Received: from JATO.hackvan.com (hackvan.com [206.80.31.242]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA27676 for <xemacs-beta@cs.uiuc.edu>; Mon, 22 Jul 1996 12:30:52 -0500 (CDT)
Received: by JATO.hackvan.com (Linux Smail3.1.29.1 #27)
	id m0uiOnz-000HEDC; Mon, 22 Jul 96 10:30 PDT
Message-Id: <m0uiOnz-000HEDC@JATO.hackvan.com>
From: stig@hackvan.com (Stig)
Date: Mon, 22 Jul 1996 10:30:03 -0700
In-Reply-To: <m2ivbgiwz6.fsf@deanna.miranova.com>
       Steven L Baur <steve@miranova.com>'s message on Jul 22, 12:11am
X-Face: %UJuXrxLTOCdVz$`G?OIUl"OW-5%f6h&7m{~4OPx"]|nPv>'&piCsimqSByS>?9il2tfej-  .dlT<~1B7+Z?i/FCR)S?9xm`h<@1Uwwh2eLvK?yc7gIt||'C3CajJGzUTjjVpJN/<"dL>}6t<q]/X|  lDH[~V*TtkAN~6RM?:`AWPKi^ZJw8zK4b2A=smGp?S<@SrKcntaPIUGNKH#mP:5V0G7
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: Missing extent feature

In <m2ivbgiwz6.fsf@deanna.miranova.com>, Steven L Baur wrote...
> >>>>> "Heiko" == Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de> writes:
> 
> Heiko> I want to insert a string in a buffer, but display a glyph instead of
> Heiko> this text.
> 
> The simplest code I can think of that does this is smiley.el in
> lisp/gnus.  The trick is that you have to attach the glyph as an
> annotation ...


I think that does it, but it's not what he asked for.  That requires two
extents.  What he wants to do is have a single extent that makes the text
invisible and places the glyph.  To do it the way he wants, requires
separate visibility variables for the glyphs of an extent and the text of
the extent.  

I've wanted the same thing in the past as well.

	stig


From xemacs-beta-request@cs.uiuc.edu  Mon Jul 22 12:58:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA27612 for xemacs-beta-people; Mon, 22 Jul 1996 12:58:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA27609 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 22 Jul 1996 12:58:39 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA28128 for <xemacs-beta@cs.uiuc.edu>; Mon, 22 Jul 1996 12:58:39 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.6.12/8.6.9) with ESMTP id MAA07579; Mon, 22 Jul 1996 12:58:40 -0500
Message-Id: <199607221758.MAA07579@nvwls.cc.purdue.edu>
To: stig@hackvan.com (Stig)
cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: Missing extent feature 
In-reply-to: Your message of "Mon, 22 Jul 1996 10:30:03 MST."
             <m0uiOnz-000HEDC@JATO.hackvan.com> 
Date: Mon, 22 Jul 1996 12:58:38 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


Try attaching the image as a begin glyph instead of the end glyph.
This worked for me.

--
Joseph J. Nuspl Jr.
Purdue Data Network


From xemacs-beta-request@cs.uiuc.edu  Tue Jul 23 02:41:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA29963 for xemacs-beta-people; Tue, 23 Jul 1996 02:41:23 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA29960 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 23 Jul 1996 02:41:21 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA19011 for <xemacs-beta@cs.uiuc.edu>; Tue, 23 Jul 1996 02:40:41 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Tue, 23 Jul 1996 09:39:40 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id JAA25664; Tue, 23 Jul 1996 09:39:18 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id JAA11255;
          Tue, 23 Jul 1996 09:37:23 +0200
Date: Tue, 23 Jul 1996 09:37:23 +0200
Message-Id: <199607230737.JAA11255@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de>
To: xemacs-beta@cs.uiuc.edu
Subject: Bug found in the extent code in 19.14
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q(\V9
+y$PP~.4G[2n4W7{6Ilm[AMY9B: 0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy

^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x
zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:
s0;|v1x"Jb
  
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII

There is a bug in the annotaion (or extent ?) code. Try the following:

1. Insert the following two lines in a buffer:
   :-):-):-):-):-)
   :-) :-) :-) :-) :-)

2. Eval the following line in the same buffer:
   (setq buffer-invisibility-spec t)

2. load the library smiley.el (you've also to load messagexmas.el before
   smiley.el - there should be require statement in smiley.el!)

3. Eval the following 2 lines in the same buffer:
   (setq smiley-regexp-alist '((":-)" 0 "FaceGrinning.xpm")))
   (smiley-buffer)

You should now see, that in the first line only one smiley is
displayed instead of 5 smileys. The second line is correct. If you
eval now the following line: 
(setq buffer-invisibility-spec nil)
then you could see, that all smileys are displayed. It seems, that the
invisible extent property doesn't work correct.

From xemacs-beta-request@cs.uiuc.edu  Tue Jul 23 02:59:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA29994 for xemacs-beta-people; Tue, 23 Jul 1996 02:59:00 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA29991 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 23 Jul 1996 02:58:55 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA19131 for <xemacs-beta@cs.uiuc.edu>; Tue, 23 Jul 1996 02:58:12 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Tue, 23 Jul 1996 09:57:56 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id JAA25829; Tue, 23 Jul 1996 09:57:38 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id JAA11279;
          Tue, 23 Jul 1996 09:55:44 +0200
Date: Tue, 23 Jul 1996 09:55:44 +0200
Message-Id: <199607230755.JAA11279@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de>
To: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Missing extent feature
In-Reply-To: <199607221758.MAA07579@nvwls.cc.purdue.edu>
References: <m0uiOnz-000HEDC@JATO.hackvan.com> <199607221758.MAA07579@nvwls.cc.purdue.edu>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q(\V9
+y$PP~.4G[2n4W7{6Ilm[AMY9B: 0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy

^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x
zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:
s0;|v1x"Jb
  
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Joseph" == Joseph J Nuspl <nuspl@nvwls.cc.purdue.edu> writes:

    Joseph> Try attaching the image as a begin glyph instead of the
    Joseph> end glyph.  This worked for me.

Are you sure? I've already tested this, but without success. Does it
also work, if you insert the same text with the same glyph n times one
direct after the other?


From xemacs-beta-request@cs.uiuc.edu  Tue Jul 23 02:38:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA29948 for xemacs-beta-people; Tue, 23 Jul 1996 02:38:10 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA29945 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 23 Jul 1996 02:38:05 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA18927 for <xemacs-beta@cs.uiuc.edu>; Tue, 23 Jul 1996 02:37:14 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Tue, 23 Jul 1996 09:36:09 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id JAA25639; Tue, 23 Jul 1996 09:35:47 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id JAA11253;
          Tue, 23 Jul 1996 09:33:52 +0200
Date: Tue, 23 Jul 1996 09:33:52 +0200
Message-Id: <199607230733.JAA11253@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@daedalus.tnt.uni-hannover.de>
To: stig@hackvan.com (Stig)
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: Missing extent feature
In-Reply-To: <m0uiOnz-000HEDC@JATO.hackvan.com>
References: <m2ivbgiwz6.fsf@deanna.miranova.com> <steve@miranova.com> <m0uiOnz-000HEDC@JATO.hackvan.com>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q(\V9
+y$PP~.4G[2n4W7{6Ilm[AMY9B: 0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy

^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x
zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:
s0;|v1x"Jb
  
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Stig" == Stig  <stig@hackvan.com> writes:

    Stig> In <m2ivbgiwz6.fsf@deanna.miranova.com>, Steven L Baur
    Stig> wrote...
    >> >>>>> "Heiko" == Heiko Muenkel
    >> <muenkel@daedalus.tnt.uni-hannover.de> writes:
    >> 
    Heiko> I want to insert a string in a buffer, but display a glyph
    Heiko> instead of this text.
    >>  The simplest code I can think of that does this is smiley.el
    >> in lisp/gnus.  The trick is that you have to attach the glyph
    >> as an annotation ...


    Stig> I think that does it, but it's not what he asked for.  That
    Stig> requires two extents.  What he wants to do is have a single
    Stig> extent that makes the text invisible and places the glyph.
    Stig> To do it the way he wants, requires separate visibility
    Stig> variables for the glyphs of an extent and the text of the
    Stig> extent.

That's exact the feature that I want. Another usefull extent feature
that I need is the ability to use a whole extent as one character for
moving the point and deleting.

But however the code in smiley.el is already close to that what I need -
but it doesn't work :-( because of a bug in the 19.14. Look at my next mail.

From xemacs-beta-request@cs.uiuc.edu  Tue Jul 23 04:22:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA03935 for xemacs-beta-people; Tue, 23 Jul 1996 04:22:03 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA03932 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 23 Jul 1996 04:22:02 -0500 (CDT)
Received: from gateway.msc.ie (root@[194.125.117.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA20147 for <xemacs-beta@cs.uiuc.edu>; Tue, 23 Jul 1996 04:21:56 -0500 (CDT)
Received: from decalpha.msc.ie ([194.125.117.250]) by gateway.msc.ie 
	  Sendmail (v8.7.5) with SMTP id KAA01570 for <xemacs-beta@cs.uiuc.edu>;
	  Tue, 23 Jul 1996 10:21:42 +0100
Received: by decalpha.msc.ie; (5.65v3.2/1.1.8.2/08Jul96-0453PM)
	id AA11024; Tue, 23 Jul 1996 10:22:17 +0100
Date: Tue, 23 Jul 1996 10:22:17 +0100
Message-Id: <9607230922.AA11024@decalpha.msc.ie>
From: Russell Ritchie <ritchier@msc.ie>
To: xemacs-beta@cs.uiuc.edu
Subject: mode-motion+ patch for 19.14
References: <199607191409.JAA06646@charles.cs.uiuc.edu>

I sent this to comp.emacs.xemacs some time ago in response to a post after
our lousy net connection eventually allowed me to retrieve a working XEmacs.
In case Chuck missed it as a result of message volume, here it is again.

Joachim Krumnow wrote:
> 
> Hi XEmacers,
> 
> I'm going crazy w/ mode-motion+ 3.15 and the new XEmacs 19.14. 

Try the following patch.  Warning: I don't have access to anything
other than the 19.14 alpha precompiled binary release via a losing 
PC X server so this hasn't undergone the same degree of testing
previous releases of mode-motion+ have (from me at least).

diff -c mode-motion+.el.~1~ mode-motion+.el
*** mode-motion+.el.~1~	Fri Jun 28 12:04:45 1996
--- mode-motion+.el	Fri Jun 28 12:04:45 1996
***************
*** 32,37 ****
--- 32,40 ----
  ;; at all.
  
  ; Change History
+ ; Revision 3.16 Fri Jun 28 13:01:12 1996 Russell Ritchie <ritchier@msc.ie>.
+ ; Stop multiple highlighting lossage with 19.14 release.
+ 
  ; Revision 3.15 Thu Feb 15 14:26:34 GMT 1996 Russell.Ritchie@gssec.bt.co.uk
  ; lisp-interaction-popup-menu => lisp-interaction-mode-popup-menu,
  ; emacs-lisp-popup-menu => emacs-lisp-mode-popup-menu.
***************
*** 245,251 ****
  
  (require 'thing)
  (require 'mode-motion)
! (defconst mode-motion+-version "3.15")
  
  ;;; This file defines a set of mouse motion handlers that do some
  ;;; highlighting of the text when the mouse moves over.
--- 248,254 ----
  
  (require 'thing)
  (require 'mode-motion)
! (defconst mode-motion+-version "3.16")
  
  ;;; This file defines a set of mouse motion handlers that do some
  ;;; highlighting of the text when the mouse moves over.
***************
*** 1101,1113 ****
  	       (and buffer
  		    (set-buffer buffer)
  		    (select-window window))
- 	   
- 	       ;; kludge: if point = end-of-window, then probably the mouse
- 	       ;; is actually between the last line and the modeline.  In
- 	       ;; this case move point to back one
- 	       (and point
- 		    (not (< point (window-end window)))
- 		    (setq point (1- point)))
  	       ;; Create a new mode-motion-extent if there isn't one 
  	       ;; (or a destroyed one)
  	       (if (and (extent-live-p mode-motion-extent)
--- 1104,1109 ----
***************
*** 1162,1179 ****
  		   (if (or (not (motion-handler-follow-point handler))
  			   (pos-visible-in-window-p point))
  		       (progn
! 			 ;; set the extent face
  			 (set-extent-face
  			  mode-motion-extent (motion-handler-face handler))
- 			 ;; set the new boundary
- 			 (set-extent-endpoints 
- 			  mode-motion-extent (car region) (cdr region))
- 			 ;; highlight if required
- 			 (set-extent-property
- 			  mode-motion-extent 'highlight
- 			  (motion-handler-highlight handler))
- 			 (highlight-extent mode-motion-extent
- 					   (motion-handler-highlight handler))
  			 ;; make point follow the mouse or point to
  			 ;; the beginning of the line do not move the
  			 ;; cursor if a mark is set.
--- 1158,1167 ----
  		   (if (or (not (motion-handler-follow-point handler))
  			   (pos-visible-in-window-p point))
  		       (progn
! 			 (set-extent-endpoints
! 			  mode-motion-extent (car region) (cdr region))
  			 (set-extent-face
  			  mode-motion-extent (motion-handler-face handler))
  			 ;; make point follow the mouse or point to
  			 ;; the beginning of the line do not move the
  			 ;; cursor if a mark is set.



From xemacs-beta-request@cs.uiuc.edu  Tue Jul 23 07:35:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA04225 for xemacs-beta-people; Tue, 23 Jul 1996 07:35:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA04222 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 23 Jul 1996 07:35:38 -0500 (CDT)
Received: from maes.esrin.esa.it (maes.esrin.esa.it [192.106.252.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA24087 for <xemacs-beta@cs.uiuc.edu>; Tue, 23 Jul 1996 07:35:34 -0500 (CDT)
Received: from mail.esrin.esa.it (plod.esrin.esa.it) by maes.esrin.esa.it with SMTP id AA18949
  (5.65c/IDA-1.4.4 for <xemacs-beta@cs.uiuc.edu>); Tue, 23 Jul 1996 14:35:56 +0200
Received: from penelope.esa.it by mail.esrin.esa.it (4.1/SMI-4.1)
	id AA01951; Tue, 23 Jul 96 12:38:15 GMT
Date: Tue, 23 Jul 96 12:38:15 GMT
Message-Id: <9607231238.AA01951@mail.esrin.esa.it>
Received: by penelope.esa.it (4.1/SMI-4.1)
	id AA00394; Tue, 23 Jul 96 14:38:29 +0200
From: Simon Marshall <Simon.Marshall@esrin.esa.it>
To: XEmacs Beta <xemacs-beta@cs.uiuc.edu>
Subject: [19.14]: Scrollbar glitches
Reply-To: Simon Marshall <Simon.Marshall@esrin.esa.it>

Configured for `sparc-sun-sunos4.1.3C'.

  Where should the build process find the source code?    /home_rsps/simonm/Penelope/xemacs-19.14
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sunos4-1-3shr.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -O3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/share/X11/X11R5-Solaris1/include
  Where do we find X Windows libraries?                   /usr/share/X11/X11R5-Solaris1/lib
  Additional header files:                                /home_rsps/simonm/Penelope/Slash/usr/include
  Additional libraries:                                   /home_rsps/simonm/Penelope/Slash/usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.

Now start an XEmacs with a small window visiting a big file, e.g.:

xemacs -no-init-file -no-site-file -geometry 80x10 xemacs-19.14/src/fileio.c

so that the problem is easy to see, then:

1.  Do button-1 on the scrollbar thumb and drag down to display the bottom
of the buffer.  It won't let you scroll right to the bottom of the buffer.

2.  Instead, button-1 on the scrollbar down arrow to move further down
line by line.  This works, but notice the scrollbar thumb jump up and down.

Simon.

From xemacs-beta-request@cs.uiuc.edu  Tue Jul 23 10:30:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA04727 for xemacs-beta-people; Tue, 23 Jul 1996 10:30:54 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA04723 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 23 Jul 1996 10:30:50 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA02146 for <xemacs-beta@cs.uiuc.edu>; Tue, 23 Jul 1996 10:30:44 -0500 (CDT)
Received: from compserv1gw.cs.sunysb.edu (compserv1gw.cs.sunysb.edu [130.245.2.44]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id LAA05214 for <xemacs-beta@cs.uiuc.edu>; Tue, 23 Jul 1996 11:35:17 -0400
Message-Id: <199607231535.LAA05214@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host compserv1gw.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: xemacs-beta@cs.uiuc.edu
Subject: xemacs -nw and the meta key
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 23 Jul 1996 11:26:38 -0400
Sender: kifer@cs.sunysb.edu

I just noticed that xemacs -nw doesn't recognize the meta key.
In contrast, emacs -nw does recognize it.

Is it how things are supposed to be?

I don't know if it matters, but I am running xemacs (and emacs) on a remote
machine through an xterm window. (I can't test it on the host machine
because the place I am in right now doesn't have xemacs installed.)



	--michael  

From xemacs-beta-request@cs.uiuc.edu  Tue Jul 23 10:52:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA04815 for xemacs-beta-people; Tue, 23 Jul 1996 10:52:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA04812 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 23 Jul 1996 10:52:47 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA25136 for <xemacs-beta@xemacs.org>; Tue, 23 Jul 1996 10:52:43 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa09440;
          23 Jul 96 11:51 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id LAA07596; Tue, 23 Jul 1996 11:51:29 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id LAA00796; Tue, 23 Jul 1996 11:51:28 -0400
Date: Tue, 23 Jul 1996 11:51:28 -0400
Message-Id: <199607231551.LAA00796@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
To: xemacs-beta@xemacs.org
Subject: Inappropriate 19.14 font-lock kludgery
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Distorting time
X-WWW-Homepage: http://www.python.org/~bwarsaw


Take the following bit of Python code:

-------------------- snip snip --------------------foo.py
phone = """
(202) 555-1212
"""

def main():
    print "hello"
-------------------- snip snip --------------------

Put this in a python-mode buffer and turn on font-locking.  Now go to
the `def' line and hit a space.  Watch the line get font-locked like a
string.  Hitting TAB, or otherwise fixing up indentation doesn't
restore the proper font-lockage.

Of course, the problem is the open paren in column zero in the string
at the top.  I understand why this kludge is there, and while it makes
some sense in Lisp or C, it makes no sense in a language like Python.
It is interesting to note that Emacs 19.31 doesn't suffer the same
problem.

FTR: XEmacs 19.14, SS5, Solaris 2.5, gcc 2.7.2, font-lock, fast-lock.

-Barry

From xemacs-beta-request@cs.uiuc.edu  Tue Jul 23 14:32:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA05527 for xemacs-beta-people; Tue, 23 Jul 1996 14:32:41 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA05523 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 23 Jul 1996 14:32:36 -0500 (CDT)
Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA10773 for <xemacs-beta@cs.uiuc.edu>; Tue, 23 Jul 1996 14:32:34 -0500 (CDT)
Received: from corp-200.dfki.uni-kl.de by stepsun.uni-kl.de id aa09029;
          23 Jul 96 21:32 MET DST
Received: from serv-302.dfki.uni-kl.de (burt@serv-302 [131.246.242.102]) by corp-200.dfki.uni-kl.de (8.7.5/8.7.3) with ESMTP id VAA25138; Tue, 23 Jul 1996 21:33:29 +0200 (MET DST)
Organization: DFKI Kaiserslautern GmbH, D 67663 Kaiserslautern
Received: (from burt@localhost) by serv-302.dfki.uni-kl.de (8.7.5/8.7.3) id VAA09079; Tue, 23 Jul 1996 21:32:12 +0200 (MET DST)
Date: Tue, 23 Jul 1996 21:32:12 +0200 (MET DST)
Message-Id: <199607231932.VAA09079@serv-302.dfki.uni-kl.de>
From: Alastair Burt <burt@dfki.uni-kl.de>
To: XEmacs Beta Mailing List <xemacs-beta@cs.uiuc.edu>,
        Andy Norman <ange@hplb.hpl.hp.com>
Subject: gnuserv.el + XEmacs 19.14
Mime-Version: 1.0 (generated by tm-edit 7.71)
Content-Type: text/plain; charset=US-ASCII

window-system-version seems to have disappeared without trace in XEmacs 19.14.

*** gnuserv.el	1996/07/23 19:27:38	1.1
--- gnuserv.el	1996/07/23 19:28:11
***************
*** 223,231 ****
  (defun server-make-window-visible ()
    "Try to make this window even more visible."
    (and (boundp 'window-system)
!        (boundp 'window-system-version)
         (eq window-system 'x)
!        (eq window-system-version 11)
         (cond ((fboundp 'raise-frame)
  	      (raise-frame (selected-frame)))
  	     ((fboundp 'deiconify-screen)
--- 223,231 ----
  (defun server-make-window-visible ()
    "Try to make this window even more visible."
    (and (boundp 'window-system)
!        ;; (boundp 'window-system-version)
         (eq window-system 'x)
!        ;; (eq window-system-version 11)
         (cond ((fboundp 'raise-frame)
  	      (raise-frame (selected-frame)))
  	     ((fboundp 'deiconify-screen)

--- alastair


From xemacs-beta-request@cs.uiuc.edu  Tue Jul 23 21:09:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA06866 for xemacs-beta-people; Tue, 23 Jul 1996 21:09:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA06863 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 23 Jul 1996 21:09:51 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA26123 for <xemacs-beta@xemacs.org>; Tue, 23 Jul 1996 21:09:47 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id TAA13847; Tue, 23 Jul 1996 19:09:20 -0700
Received: from scooter.canada.sun.com (scooter-8.Canada.Sun.COM) by Canada.Sun.COM (4.1/SMI-4.1)
	id AA07028; Tue, 23 Jul 96 22:09:18 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id WAA25995; Tue, 23 Jul 1996 22:09:16 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id WAA00425; Tue, 23 Jul 1996 22:08:51 -0400
Date: Tue, 23 Jul 1996 22:08:51 -0400
Message-Id: <199607240208.WAA00425@detlev.canada.sun.com>
From: Georg Nikodym <georgn@canada.sun.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: fast lock and the options menu
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII


I used to use fast-lock but it don't seem to want to work anymore.
Regardless of what I select in the Options menu, the lisp that it
added to my .emacs contains only a remove-hook turning off
fast-lock...

What is the recommended way in 19.14 to enable fast-lock (no this
doesn't seem to be in the FAQ).

And while on the subject of the FAQ (which is great), has any though
been given to adding search capabilities?

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 08:49:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA12262 for xemacs-beta-people; Wed, 24 Jul 1996 08:49:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA12259 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 08:49:27 -0500 (CDT)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.255.59.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA11518 for <xemacs-beta@cs.uiuc.edu>; Wed, 24 Jul 1996 08:49:23 -0500 (CDT)
Received: from otter.hpl.hp.com by hplb.hpl.hp.com; Wed, 24 Jul 1996 14:42:40 +0100
Received: from cuthbert.hpl.hp.com by otter.hpl.hp.com with ESMTP
	(1.37.109.16/15.6+ISC) id AA287345758; Wed, 24 Jul 1996 14:42:39 +0100
Received: from hplb (localhost [127.0.0.1]) by cuthbert.hpl.hp.com (8.7.4/8.7.3) with ESMTP id OAA00681; Wed, 24 Jul 1996 14:42:19 GMT
Message-Id: <199607241442.OAA00681@cuthbert.hpl.hp.com>
To: Alastair Burt <burt@dfki.uni-kl.de>
Cc: XEmacs Beta Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Re: gnuserv.el + XEmacs 19.14 
In-Reply-To: Your message of "Tue, 23 Jul 1996 21:32:12 +0200."
             <199607231932.VAA09079@serv-302.dfki.uni-kl.de> 
Date: Wed, 24 Jul 1996 14:42:18 +0000
From: Andy Norman <ange@hplb.hpl.hp.com>

Alastair writes:

> window-system-version seems to have disappeared without trace in XEmacs 19.14.
> *** gnuserv.el	1996/07/23 19:27:38	1.1
> --- gnuserv.el	1996/07/23 19:28:11
> ***************

...

Try this patch instead.  Makes it work with older systems too...

--- gnuserv.el~	Sun Jun 16 19:37:25 1996
+++ gnuserv.el	Mon Jul 22 13:37:48 1996
@@ -222,10 +222,12 @@
 
 (defun server-make-window-visible ()
   "Try to make this window even more visible."
-  (and (boundp 'window-system)
-       (boundp 'window-system-version)
-       (eq window-system 'x)
-       (eq window-system-version 11)
+  (and (or (and (boundp 'window-system)
+		(boundp 'window-system-version)
+		(eq window-system 'x)
+		(eq window-system-version 11))
+	   (and (fboundp 'console-type)
+		(eq 'x (console-type))))
        (cond ((fboundp 'raise-frame)
 	      (raise-frame (selected-frame)))
 	     ((fboundp 'deiconify-screen)


						-- ange -- <><

http://www-uk.hpl.hp.com/people/ange		ange@hplb.hpl.hp.com

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 09:42:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA12404 for xemacs-beta-people; Wed, 24 Jul 1996 09:42:50 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA12401 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 09:42:49 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA12395 for <xemacs-beta@cs.uiuc.edu>; Wed, 24 Jul 1996 09:42:49 -0500 (CDT)
Received: from xdiv.lanl.gov by mailhost.lanl.gov (8.7.5/1.2)
	id IAA11243; Wed, 24 Jul 1996 08:42:35 -0600 (MDT)
Received: from gielgud.lanl.gov.xdiv (gielgud.lanl.gov [128.165.116.68]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id IAA16419; Wed, 24 Jul 1996 08:42:32 -0600
Received: by gielgud.lanl.gov.xdiv (SMI-8.6/SMI-SVR4)
	id IAA14474; Wed, 24 Jul 1996 08:41:52 -0600
Date: Wed, 24 Jul 1996 08:41:52 -0600
Message-Id: <199607241441.IAA14474@gielgud.lanl.gov.xdiv>
From: John Turner <turner@xdiv.lanl.gov>
To: kifer@cs.sunysb.edu
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: xemacs -nw and the meta key
In-Reply-To: <199607231535.LAA05214@cs.sunysb.edu>
References: <199607231535.LAA05214@cs.sunysb.edu>
Reply-To: turner@lanl.gov

Michael Kifer writes:
 > I just noticed that xemacs -nw doesn't recognize the meta key.
 > In contrast, emacs -nw does recognize it.
 > 
 > Is it how things are supposed to be?
 > 
 > I don't know if it matters, but I am running xemacs (and emacs) on a remote
 > machine through an xterm window. (I can't test it on the host machine
 > because the place I am in right now doesn't have xemacs installed.)

I run at home on an xterm via tip all the time and it works fine, but
I just tried exactly what you're describing just to make sure, and it
seems to work fine as well.  I'm using:

  19.14, precompiled binaries for Solaris 2.4 w/SPARCworks
  Solaris 2.5, CDE 1.0.1

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 09:46:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA12413 for xemacs-beta-people; Wed, 24 Jul 1996 09:46:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA12410 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 09:46:06 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA27137 for <xemacs-beta@xemacs.org>; Wed, 24 Jul 1996 09:46:03 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id KAA23226 for <xemacs-beta@xemacs.org>; Wed, 24 Jul 1996 10:45:41 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp023002; Wed Jul 24 10:41:26 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA27978; Wed, 24 Jul 96 10:41:22 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA01820; Wed, 24 Jul 96 10:41:19 EDT
Message-Id: <9607241441.AA01820@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Never had it, never will.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Prebuilt SunOS/Sparcworks binary still has problems
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMfY2B1tTztlqB385AQE9JAQAnB/npn2CfZNaOp5GSOBT9Yl+f+oyv/GE
	      fW3K4j5wBiTC7rgycbwpdJfVqkxIVP+7BKq34wiAy61BAkY9klcNXLU9PuxAweGm
	      Zmp+EeuBLIJM649Rjyg67A8v9nIEkru9oxhX4nGVQXyvDU+IRsNZwg1Zg+gTamad
	      +hxWr4Engg4=
	      =SB0T
Date: Wed, 24 Jul 1996 10:41:17 -0400
Sender: rickc@lehman.com

When running the prebuilt XEmacs-19.14 SunOS executable with
Sparcworks support, I've noticed a number of problems running under
X11.  None of these problems appear when running in tty mode:

 - Control-G is often (always?) ignored.

 - When doing a bit tags-query replace, if I just lay on the
   bang (!) key to replace everything everywhere, when it completes it
   inserts a whole bunch of bangs into the last buffer.  Normally, the
   ``processed all files'' message causes the remaining bang
   keystrokes to be ignored.

 - When the X server exits out from under XEmacs, it goes absolutely
   crazy, spewing messages about exiting with pending events in what
   appears to be an infinite loop.  This makes the machine (Sparc10)
   unusable until it is killed off.

Note that this is using the second (I think) build of these
configuration.  If there was another build that wasn't announced here,
I've missed it and would appreciate hearing about it.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 10:39:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA12692 for xemacs-beta-people; Wed, 24 Jul 1996 10:39:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA12689 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 10:39:24 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA27184 for <xemacs-beta@xemacs.org>; Wed, 24 Jul 1996 10:39:22 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id AAA20052; Thu, 25 Jul 1996 00:39:16 +0900 (JST)
Message-Id: <199607241539.AAA20052@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.65, tm-view 7.66
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: xemacs-beta@xemacs.org
Subject: [20.0 with mule] decode-coding-region
Mime-Version: 1.0 (generated by tm-edit 7.74)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Thu_Jul_25_00:39:02_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Thu, 25 Jul 1996 00:39:15 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Thu_Jul_25_00:39:02_1996-1
Content-Type: text/plain; charset=US-ASCII

  I hate my `code-converter-is-broken' hack, so I traced
`decode-coding-region'. It is failed at line 2151 of mule-coding.c:

  outstream = make_lisp_buffer_output_stream (buf, b, 0);

So traced `make_lisp_buffer_output_stream'. It calls following:

  Lisp_Object lstr = make_lisp_buffer_stream_1 (buf, pos, 0, flags, "w");

However `make_lisp_buffer_stream_1' seems not support output stream:

  /* Make sure the luser didn't pass "w" in. */
  if (!strcmp (mode, "w"))
    abort ();

:-< :-< :-<

  What is good way to fix it?
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key
--pgp-sign-Multipart_Thu_Jul_25_00:39:02_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMfZDnxnuUGV7wuH5AQE/EQP/etsJJcJi6iIM/OXX43ZFDKzrPj6f2X49
1nQR3tV8yHH3L01uIJxrq5jGypCV8c4E7Jk2nNVxZ5/AbSWF+DM9Ma/HzqVbD/2/
d6YDvE9RRHo+/9oHTIDJLAcrgWLYXzXV/8SVxx56YaD7y0ZYk1dJv0F1K5KASjD4
VY9OStnnFEw=
=0w3X
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Jul_25_00:39:02_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 11:02:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA12741 for xemacs-beta-people; Wed, 24 Jul 1996 11:02:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA12738 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 11:02:40 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA14420 for <xemacs-beta@cs.uiuc.edu>; Wed, 24 Jul 1996 11:02:42 -0500 (CDT)
Received: from compserv1gw.cs.sunysb.edu (compserv1gw.cs.sunysb.edu [130.245.2.44]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id MAA16766; Wed, 24 Jul 1996 12:07:00 -0400
Message-Id: <199607241607.MAA16766@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host compserv1gw.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: turner@lanl.gov
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: xemacs -nw and the meta key 
In-reply-to: "John Turner" of Wed, 24 Jul 1996 08:41:52 MDT
             <199607241441.IAA14474@gielgud.lanl.gov.xdiv> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 24 Jul 1996 11:58:19 -0400
Sender: kifer@cs.sunysb.edu

>>>>> "JT" == John Turner
>>>>> "MK" == Michael Kifer

    MK> I just noticed that xemacs -nw doesn't recognize the meta key.
    MK> In contrast, emacs -nw does recognize it.
    MK> 
    MK> Is it how things are supposed to be?
    MK> 
    MK> I don't know if it matters, but I am running xemacs (and emacs) on
    MK> a remote machine through an xterm window. 

    JT> I run at home on an xterm via tip all the time and it works fine, but
    JT> I just tried exactly what you're describing just to make sure, and it
    JT> seems to work fine as well.  I'm using:

    JT> 19.14, precompiled binaries for Solaris 2.4 w/SPARCworks

    Michael Diers (mdiers@logware.de)  have already solved the problem, at
    least partially. It appears that the problem exists when the remote
    machine is a BSD system.

    In this case, specifying 

    xterm*eightBitInput:  false

    solves the problem.  As I understand it, rlogin in BSD systems is a 7
    bit protocol, so the meta bit is cut off. The above resource
    circumvents the problem by telling xterm to send meta chars as ESC
    sequences.

    The only curious thing is, how FSF emacs manages to recognize meta
    chars via a 7 bit protocol (it doesn't require the above resource).


	--michael  


From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 11:25:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA12871 for xemacs-beta-people; Wed, 24 Jul 1996 11:25:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA12868 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 11:25:38 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA15770 for <xemacs-beta@cs.uiuc.edu>; Wed, 24 Jul 1996 11:25:40 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id LAA07141 for <xemacs-beta@cs.uiuc.edu>; Wed, 24 Jul 1996 11:25:08 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id LAA08770 for <xemacs-beta@cs.uiuc.edu>; Wed, 24 Jul 1996 11:25:06 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id MAA26070 for <xemacs-beta@cs.uiuc.edu>; Wed, 24 Jul 1996 12:25:04 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: $PATH and 19.14
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 24 Jul 1996 12:21:00 -0400
Message-ID: <7274.838225260@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


There was a message about this in comp.emacs.xemacs and a work around,
but I'm looking for a better solution.

The problem:
	if PATH contains a leading, trailing, or doubled-up colon,
	xemacs stops with the error "stringp, nil"

The workaround is, of course, to get rid of the extra colons or
replace them with ".", as needed.

However, I'm looking for a better solution within xemacs.  Any ideas?

Ray

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 14:25:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA13441 for xemacs-beta-people; Wed, 24 Jul 1996 14:25:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA13438 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 14:25:40 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA19441 for <xemacs-beta@cs.uiuc.edu>; Wed, 24 Jul 1996 14:25:40 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id PAA06843; Wed, 24 Jul 1996 15:24:13 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp006799; Wed Jul 24 15:23:24 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA28162; Wed, 24 Jul 96 15:23:23 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA10459; Wed, 24 Jul 96 15:23:07 EDT
Message-Id: <9607241923.AA10459@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Complex nonsolutions to simple nonproblems.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Michael Kifer <kifer@cs.sunysb.edu>
Cc: turner@lanl.gov, xemacs-beta@cs.uiuc.edu
Subject: Re: xemacs -nw and the meta key 
In-Reply-To: Your message of "Wed, 24 Jul 1996 11:58:19 EDT."
             <199607241607.MAA16766@cs.sunysb.edu> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMfZ3pltTztlqB385AQFbRgP/e5eDKPKrOUNk9OiGsCDT/afW0+E/Z6ZL
	      TDlqpU87m21e7PJzH+B9cjq5Nd9Y4Rrjxzxz5QusAC1y799gAc2qbXbKph4lXsl2
	      gBFhEPk3MipgBjJmnFpWAClFJv1Cy5DdIkYEbVbslwXszo4Sg6JzFMYlj0034Cee
	      lO8lncMiT0w=
	      =owUb
Date: Wed, 24 Jul 1996 15:23:03 -0400
Sender: rickc@lehman.com

    From: Michael Kifer <kifer@cs.sunysb.edu>
    Date: Wed, 24 Jul 1996 11:58:19 -0400
    
        In this case, specifying 
    
        xterm*eightBitInput:  false
    
        solves the problem.  As I understand it, rlogin in BSD systems is a 7
        bit protocol, so the meta bit is cut off.

I use the Xdefaults hack, albeit with a slightly tighter resource
spec:

  XTerm.vt100.eightBitInput: off

but it might also work to specify the `-8' optino to rlogin.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 16:48:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA13954 for xemacs-beta-people; Wed, 24 Jul 1996 16:48:12 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA13951 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 16:48:11 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA22273 for <xemacs-beta@cs.uiuc.edu>; Wed, 24 Jul 1996 16:48:13 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id OAA04083; Wed, 24 Jul 1996 14:47:39 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA18789; Wed, 24 Jul 1996 14:47:23 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA24174; Wed, 24 Jul 1996 14:47:17 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA17612; Wed, 24 Jul 1996 14:47:14 -0700
Date: Wed, 24 Jul 1996 14:47:14 -0700
Message-Id: <199607242147.OAA17612@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Raymond Toy <toy@rtp.ericsson.se>
Cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: $PATH and 19.14
In-Reply-To: <7274.838225260@rtp.ericsson.se>
References: <7274.838225260@rtp.ericsson.se>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Ray" == Raymond Toy <toy@rtp.ericsson.se> writes:

Ray> There was a message about this in comp.emacs.xemacs and a work around,
Ray> but I'm looking for a better solution.

Ray> The problem:
Ray> 	if PATH contains a leading, trailing, or doubled-up colon,
Ray> 	xemacs stops with the error "stringp, nil"

Ray> The workaround is, of course, to get rid of the extra colons or
Ray> replace them with ".", as needed.

Ray> However, I'm looking for a better solution within xemacs.  Any ideas?

This problem just won't go away.  Hopefully we'll have a new beta soon...

Here is a re-post for this patch:

*** /tmp/geta17470	Wed Jul 24 13:36:13 1996
--- sunpro-init.el	Thu Jul 18 17:46:57 1996
***************
*** 89,95 ****
          (cond
           ((let ((path exec-path) dir (found nil))
              (while (and path (not found))
!               (setq dir (car path))
                (setq path (cdr path))
                (setq dir (concat dir (if (string-match "/$" dir) "../" "/../")))
                (setq found (funcall sunpro-dir-p dir)))
--- 89,95 ----
          (cond
           ((let ((path exec-path) dir (found nil))
              (while (and path (not found))
!               (setq dir (or (car path) "."))
                (setq path (cdr path))
                (setq dir (concat dir (if (string-match "/$" dir) "../" "/../")))
                (setq found (funcall sunpro-dir-p dir)))

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 16:57:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA14103 for xemacs-beta-people; Wed, 24 Jul 1996 16:57:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA14100 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 16:57:42 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA05778 for <xemacs-beta@xemacs.org>; Wed, 24 Jul 1996 16:57:39 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id OAA07921; Wed, 24 Jul 1996 14:57:09 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA20884; Wed, 24 Jul 1996 14:56:45 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA24319; Wed, 24 Jul 1996 14:56:31 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA17631; Wed, 24 Jul 1996 14:56:28 -0700
Date: Wed, 24 Jul 1996 14:56:28 -0700
Message-Id: <199607242156.OAA17631@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: MORIOKA Tomohiko <morioka@jaist.ac.jp>
Cc: xemacs-beta@xemacs.org
Subject: [20.0 with mule] decode-coding-region
In-Reply-To: <199607241539.AAA20052@mikan.jaist.ac.jp>
References: <199607241539.AAA20052@mikan.jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Tomo" == MORIOKA Tomohiko <ISO-2022-JP> writes:
Tomo>   I hate my `code-converter-is-broken' hack, so I traced
Tomo> `decode-coding-region'. It is failed at line 2151 of mule-coding.c:

Tomo>   outstream = make_lisp_buffer_output_stream (buf, b, 0);

Tomo> So traced `make_lisp_buffer_output_stream'. It calls following:

Tomo>   Lisp_Object lstr = make_lisp_buffer_stream_1 (buf, pos, 0, flags, "w");

Tomo> However `make_lisp_buffer_stream_1' seems not support output stream:

Tomo>   /* Make sure the luser didn't pass "w" in. */
Tomo>   if (!strcmp (mode, "w"))
Tomo>     abort ();

This patch will be in the next beta. Does it fix your problem?

*** /tmp/geta17622	Wed Jul 24 14:51:10 1996
--- lstream.c	Sun Jun 23 00:03:42 1996
***************
*** 1532,1538 ****
  Lisp_Object
  make_lisp_buffer_output_stream (struct buffer *buf, Bufpos pos, int flags)
  {
!   Lisp_Object lstr = make_lisp_buffer_stream_1 (buf, pos, 0, flags, "w");
  
    Lstream_set_character_mode (XLSTREAM (lstr));
    return lstr;
--- 1532,1538 ----
  Lisp_Object
  make_lisp_buffer_output_stream (struct buffer *buf, Bufpos pos, int flags)
  {
!   Lisp_Object lstr = make_lisp_buffer_stream_1 (buf, pos, 0, flags, "wc");
  
    Lstream_set_character_mode (XLSTREAM (lstr));
    return lstr;

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 17:13:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA14220 for xemacs-beta-people; Wed, 24 Jul 1996 17:13:09 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA14217 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 17:13:02 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA24238 for <xemacs-beta@cs.uiuc.edu>; Wed, 24 Jul 1996 17:13:05 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id RAA19933; Wed, 24 Jul 1996 17:12:31 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id RAA13687; Wed, 24 Jul 1996 17:12:30 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id SAA00589; Wed, 24 Jul 1996 18:12:30 -0400
To: Martin Buchholz <mrb@eng.sun.com>
cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
References: <7274.838225260@rtp.ericsson.se>  <199607242147.OAA17612@xemacs.eng.sun.com> 
Subject: Re: $PATH and 19.14 
In-reply-to: (Your message of Wed, 24 Jul 1996 14:47:14 PDT.)
             <199607242147.OAA17612@xemacs.eng.sun.com> 
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 24 Jul 1996 18:08:23 -0400
Message-ID: <9705.838246103@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Martin" == Martin Buchholz <mrb@Eng.Sun.COM> writes:

    Martin> This problem just won't go away.  Hopefully we'll have a
    Martin> new beta soon...

Thanks for the patch.  That, of course, did the trick!

Ray

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 18:43:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA14547 for xemacs-beta-people; Wed, 24 Jul 1996 18:43:04 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA14544 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 18:43:03 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA05907 for <xemacs-beta@xemacs.org>; Wed, 24 Jul 1996 18:43:00 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id QAA14660; Wed, 24 Jul 1996 16:42:31 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA14988; Wed, 24 Jul 1996 16:42:23 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA26691; Wed, 24 Jul 1996 16:42:18 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA17962; Wed, 24 Jul 1996 16:42:13 -0700
Date: Wed, 24 Jul 1996 16:42:13 -0700
Message-Id: <199607242342.QAA17962@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Rick Campbell <rickc@lehman.com>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Prebuilt SunOS/Sparcworks binary still has problems
In-Reply-To: <9607241441.AA01820@cfdevx1.lehman.com>
References: <9607241441.AA01820@cfdevx1.lehman.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:

Rick> When running the prebuilt XEmacs-19.14 SunOS executable with
Rick> Sparcworks support, I've noticed a number of problems running under
Rick> X11.  None of these problems appear when running in tty mode:

Do the problems disappear if you build your own binary?

Rick>  - Control-G is often (always?) ignored.

Don't see this here.  Control-G does have some UI problems on all
xemacsen, though.  Does ESC ESC ESC instead work?

Rick>  - When the X server exits out from under XEmacs, it goes absolutely
Rick>    crazy, spewing messages about exiting with pending events in what
Rick>    appears to be an infinite loop.  This makes the machine (Sparc10)
Rick>    unusable until it is killed off.

Haven't heard about this problem before.

It's hard for me to support SunOS 4.  Sun itself has mostly abandoned
this platform.  The latest Sun hardware no longer runs SunOS4.  I
personally wish SunOS4 would just disappear into deserved oblivion.
About the only time I use it myself is when building a new binary.

Perhaps someone like Rick who actually uses and cares about this
platform could take on the role of official maintainer?

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 24 20:30:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA14734 for xemacs-beta-people; Wed, 24 Jul 1996 20:30:04 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA14731 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 24 Jul 1996 20:30:03 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA06024 for <xemacs-beta@xemacs.org>; Wed, 24 Jul 1996 20:29:59 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id VAA20115; Wed, 24 Jul 1996 21:29:57 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp020102; Wed Jul 24 21:28:57 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA03757; Wed, 24 Jul 96 21:28:54 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA17491; Wed, 24 Jul 96 21:28:52 EDT
Message-Id: <9607250128.AA17491@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Never had it, never will.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: Prebuilt SunOS/Sparcworks binary still has problems 
In-Reply-To: Your message of "Wed, 24 Jul 1996 16:42:13 PDT."
             <199607242342.QAA17962@xemacs.eng.sun.com> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMfbNxltTztlqB385AQErHwP/VV5NdtXbZ3xJwp3Yzq6GaWy15ABghRlt
	      4Ps9vnD9E1LTcjWMApzpIm+HVbIAplFuyTHn/FTPkl0+jTadNH/lWW/k/bVN8bPG
	      JxjQreRhhHTeSzAKfNqAeQsJyfSVgsYR3OqZP1iuld29vAOdcNkkcwBB4RcHUIYN
	      etPHfL0ObNY=
	      =66cf
Date: Wed, 24 Jul 1996 21:28:48 -0400
Sender: rickc@lehman.com

    Date: Wed, 24 Jul 1996 16:42:13 -0700
    From: Martin Buchholz <mrb@Eng.Sun.COM>
    
    >>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:
    
    Rick> When running the prebuilt XEmacs-19.14 SunOS executable with
    Rick> Sparcworks support, I've noticed a number of problems
    Rick> running under X11.  None of these problems appear when
    Rick> running in tty mode:
    
    Do the problems disappear if you build your own binary?

Yes, but then while I have a correct build for the features that I can
support, there are features that I want that I can't build in.  For
example, the last time that I checked, I couldn't build in sound
support without having root privileges to create /usr/demo/SOUND (or
whatever that standard directory is.
    
    Rick>  - Control-G is often (always?) ignored.
    
    Don't see this here.  Control-G does have some UI problems on all
    xemacsen, though.  Does ESC ESC ESC instead work?

This is a new thing, i.e different behavior than 19.13 pre-built
binaries and the betas that I've built.  Since I keep M-ESC bound to
eval expression, I didn't realize that ESC ESC ESC was supposed to do
anything.
    
    Rick>  - When the X server exits out from under XEmacs, it goes
    Rick>    absolutely crazy, spewing messages about exiting with
    Rick>    pending events in what appears to be an infinite loop.
    Rick>    This makes the machine (Sparc10) unusable until it is
    Rick>    killed off.
    
    Haven't heard about this problem before.

It's sporadic, but when it happens, it's a real show stopper.
    
    It's hard for me to support SunOS 4.  Sun itself has mostly abandoned
    this platform.  The latest Sun hardware no longer runs SunOS4.  I
    personally wish SunOS4 would just disappear into deserved oblivion.
    About the only time I use it myself is when building a new binary.

Unfortunately, since there were a lot of problems with early Solaris
releases -- it hasn't been until the last two or three that I've heard
anyone outside of Sun say that Solaris beats SunOS413 -- a lot of
companies have waited to start moving.  I suspect that the SunOS
install-base still rivals the Solaris install-base.  While I'd love to
have my firm move quickly now, like many companies it doesn't do much
of anything fast enough for my taste.
    
    Perhaps someone like Rick who actually uses and cares about this
    platform could take on the role of official maintainer?

I don't qualify based on Chuck's list.  It would be nice, though, if
whoever builds the executable uses SunOS regularly.  Anyone out there?

			Rick

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 25 08:10:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA19572 for xemacs-beta-people; Thu, 25 Jul 1996 08:10:23 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA19569 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 25 Jul 1996 08:10:18 -0500 (CDT)
Received: from softgate1.Softimage.COM (SoftGate1.Softimage.COM [198.168.8.130]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA21609 for <xemacs-beta@cs.uiuc.edu>; Thu, 25 Jul 1996 08:10:18 -0500 (CDT)
Received: from paperboy.RND.Softimage.COM ([157.58.88.230]) by softgate1.Softimage.COM (8.6.10/8.6.9) with ESMTP id JAA25341; Thu, 25 Jul 1996 09:14:11 -0400
Received: from system1.RND.Softimage.COM (system1.RND.Softimage.COM [154.61.200.224]) by paperboy.RND.Softimage.COM (8.6.10/8.6.9) with ESMTP id JAA29882; Thu, 25 Jul 1996 09:14:09 -0400
Received: from research20.RND.Softimage.COM (research20.RND.Softimage.COM [154.61.200.20]) by system1.RND.Softimage.COM (8.6.10/8.6.9) with ESMTP id JAA21700; Thu, 25 Jul 1996 09:13:53 -0400
Received: (marcpa@localhost) by research20.RND.Softimage.COM (8.6.9/8.6.9) id JAA08770; Thu, 25 Jul 1996 09:13:51 -0400
Date: Thu, 25 Jul 1996 09:13:51 -0400
Message-Id: <199607251313.JAA08770@research20.RND.Softimage.COM>
From: Marc Paquette <Marc.Paquette@Softimage.com>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: Raymond Toy <toy@rtp.ericsson.se>,
        XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: $PATH and 19.14
In-Reply-To: <199607242147.OAA17612@xemacs.eng.sun.com>
References: <7274.838225260@rtp.ericsson.se>
	<199607242147.OAA17612@xemacs.eng.sun.com>


Personnally, I tend to be nervous when something adds a '.' in my
path (security breech).

In this case, I suppose that this code is only trying to find the
sparcworks/sunpro/workshop executable and that the value of dir is
only used by sunpro-dir-p, that it is used in a non-dangerous way
(does not actually execute an external program) and that I'm just a
tad too paranoiac ?

Is this correct ?

On the other hand, would not the following line 91 (with rest
unpatched) be better ? 

            ((let ((path (remove-if 'null exec-path)) dir (found nil))


Martin Buchholz writes:
 > >>>>> "Ray" == Raymond Toy <toy@rtp.ericsson.se> writes:
 > 
 > Ray> There was a message about this in comp.emacs.xemacs and a work around,
 > Ray> but I'm looking for a better solution.
 > 
 > Ray> The problem:
 > Ray> 	if PATH contains a leading, trailing, or doubled-up colon,
 > Ray> 	xemacs stops with the error "stringp, nil"
 > 
 > Ray> The workaround is, of course, to get rid of the extra colons or
 > Ray> replace them with ".", as needed.
 > 
 > Ray> However, I'm looking for a better solution within xemacs.  Any ideas?
 > 
 > This problem just won't go away.  Hopefully we'll have a new beta soon...
 > 
 > Here is a re-post for this patch:
 > 
 > *** /tmp/geta17470	Wed Jul 24 13:36:13 1996
 > --- sunpro-init.el	Thu Jul 18 17:46:57 1996
 > ***************
 > *** 89,95 ****
 >           (cond
 >            ((let ((path exec-path) dir (found nil))
 >               (while (and path (not found))
 > !               (setq dir (car path))
 >                 (setq path (cdr path))
 >                 (setq dir (concat dir (if (string-match "/$" dir) "../" "/../")))
 >                 (setq found (funcall sunpro-dir-p dir)))
 > --- 89,95 ----
 >           (cond
 >            ((let ((path exec-path) dir (found nil))
 >               (while (and path (not found))
 > !               (setq dir (or (car path) "."))
 >                 (setq path (cdr path))
 >                 (setq dir (concat dir (if (string-match "/$" dir) "../" "/../")))
 >                 (setq found (funcall sunpro-dir-p dir)))
-- 
Marc Paquette				| Marc.Paquette@Softimage.COM
Administrateur de Systemes / Sysadmin   | Softimage Inc
tel: (514) 845-1636 ext. 3426		| 3510 Boulevard St-Laurent
fax: (514) 845-5676			| Montreal (Quebec) H2X 2V2
*** Softimage is a wholly owned subsidiary of Microsoft Corporation ***

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 25 06:30:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA19408 for xemacs-beta-people; Thu, 25 Jul 1996 06:30:55 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA19405 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 25 Jul 1996 06:30:52 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA15753 for <xemacs-beta@cs.uiuc.edu>; Thu, 25 Jul 1996 06:30:41 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id EAA16700; Thu, 25 Jul 1996 04:28:47 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [20.0 with mule] decode-coding-region
References: <199607241539.AAA20052@mikan.jaist.ac.jp>
	<199607242156.OAA17631@xemacs.eng.sun.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Martin Buchholz's message of Wed, 24 Jul 1996 14:56:28 -0700
Mime-Version: 1.0 (generated by tm-edit 7.74)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 25 Jul 1996 04:28:44 -0700
Message-ID: <m2687co9lf.fsf@deanna.miranova.com>
Lines: 203
X-Mailer: Gnus v5.2.37/XEmacs 19.14

>>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:

>>>>> "Tomo" == MORIOKA Tomohiko <ISO-2022-JP> writes:
Tomo> I hate my `code-converter-is-broken' hack, so I traced
Tomo> `decode-coding-region'. It is failed at line 2151 of mule-coding.c:

Martin> This patch will be in the next beta. Does it fix your problem?

I'm still getting a core dump when KOI8 decoding is attempted.
Fatal error: assertion failed, file /i/xemacs-20.0-b26/src/./lisp.h, line 1221, INTP (obj)

Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb /i/xemacs-20.0-b26/src/xemacs core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  decode-coding-region(1 14 koi8)
  # (unwind-protect ...)
  # bind (curbuf tempbuf result coding-system str)
  decode-coding-string(" " koi8)
  # bind (cs charset string)
  decode-mime-charset-string(" " "KOI8-R")
  # bind (dest str encoding charset)
  mime/decode-encoded-text("KOI8-R" "Q" "=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7")
  # bind (charset encoding text word)
  mime/decode-encoded-word("=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=")
  # bind (dest ew beg end str)
  mime-eword/decode-string("=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su>")
  # bind (from subj method header)
  #<compiled-function (from "loadup.el") (header) "...(76)" [header 2 "" 1 gnus-current-select-method method subj from nntp decode-mime-charset-string default-mime-charset mime-eword/decode-string] 4>([2005 "Re:  Patch for SJIS handling" "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su>" "Sat, 8 Jun 1996 23:02:23 +0400 (MSD)" "<199606081902.XAA03340@astral.msk.su>" "<01I5NQIDR0J6003NL8@SCI.WFBR.EDU>" 984 23 "Xref: deanna.miranova.com lynx-dev:2005"])
  mapcar(#<compiled-function (from "loadup.el") (header) "...(76)" [header 2 "" 1 gnus-current-select-method method subj from nntp decode-mime-charset-string default-mime-charset mime-eword/decode-string] 4> ([2921 "Re:   Tables, I do it, but is there a better way" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Thu, 25 Jul 1996 10:50:48 +0900" "<199607250150.KAA05182@ews07.nara.kindai.ac.jp>" "" 889 17 "Xref: deanna.miranova.com lynx-dev:2921"] [353 "12-21-95 INSERT draft" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Tue, 26 Dec 1995 16:26:06 -0500 (EST)" "<01HZ9PNV9LG20011DO@SCI.WFBR.EDU>" "" 3341 73 "Xref: diana.miranova.com lynx-dev:353"] [2608 " Re: Accessing password protected pages causes a  crash at exit" "Steven L Baur <steve@miranova.com>" "12 Jul 1996 11:53:00 -0700" "<m2ivbttib7.fsf@deanna.miranova.com>" "<01I6ZG43TIB6000APU@SCI.WFBR.EDU>" 7894 148 "Xref: deanna.miranova.com lynx-dev:2608"] [2888 " LYMessages_??.h" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "!
!
Wed, 24 Jul 1996 17:00:10 +0900" "<199607240800.RAA02423@ews07.nara.kindai.ac.jp>" "" 1288 38 "Xref: deanna.miranova.com lynx-dev:2888"] [2889 " Handling of text/html?" "\"Denis N. Antonioli\" <antonio@ifi.unizh.ch>" "Wed, 24 Jul 1996 10:30:53 +0200 (MET DST)" "<\"josef.ifi..466:24.06.96.08.30.56\"@ifi.unizh.ch>" "" 514 21 "Xref: deanna.miranova.com lynx-dev:2889"] [2903 "Re:  Handling of text/html?" "Walter Skorski <walt@genetics1.JMP.TJU.EDU>" "Wed, 24 Jul 1996 14:01:03 -0400 (EDT)" "<199607241801.OAA15996@clyde.jmp.tju.edu>" "<\"josef.ifi..466:24.06.96.08.30.56\"@ifi.unizh.ch>" 810 22 "Xref: deanna.miranova.com lynx-dev:2903"] [2 "SUBSCRIBE LYNX-DEV \"Steve Baur\"" "CREN ListProcessor Version 7 <listproc@ukanaix.cc.ukans.edu>" "Wed, 22 Nov 1995 17:33:09 CST" "<9511222333.AA19508@ukanaix.cc.ukans.edu>" "" 4974 145 "Xref: diana.miranova.com lynx-dev:2"] [37 "Re: Preprocessing (html -> text)?" "Gerald Oskoboiny <gerald@cs.ualberta.ca>" "Mon, 27 Nov 1995 23:22:12 -0700 (MST)" "!
!
<95Nov27.232745-0700_mst.138801-4+66@amisk.cs.ualberta.ca>" "<Pine.SUN.3.91.951123171719.20178A-100000@pens-emh3>" 1314 34 "Xref: diana.miranova.com lynx-dev:37"] [135 "lynx 2.4.2 on linux" "\"Marty Leisner\" <leisner@sdsp.mc.xerox.com>" "Mon, 4 Dec 1995 09:14:36 PST" "<9512041714.AA18902@gnu.mc.xerox.com>" "" 965 32 "Xref: diana.miranova.com lynx-dev:135"] [154 "freeWAIS-0.4 and lynx-2.4.2 namespace conflicts" "David D Kilzer <ddkilzer@cpre1.ee.iastate.edu>" "Wed, 06 Dec 1995 00:52:49 CST" "<9512060652.AA38624@ukanaix.cc.ukans.edu>" "" 1751 41 "Xref: diana.miranova.com lynx-dev:154"] [162 "Re: freeWAIS-0.4 and lynx-2.4.2 namespace conflicts" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 06 Dec 1995 13:30:45 -0500 (EST)" "<01HYHL02LIG8004HA0@SCI.WFBR.EDU>" "" 2910 65 "Xref: diana.miranova.com lynx-dev:162"] [270 "Re: Displaying source, over 80 columns." "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 15 Dec 1995 18:24:43 -0500 (EST)" "<01HYUGOLMGNC0008IJ@SCI.WFBR.EDU>" "" 14!
!
22 26 "Xref: diana.miranova.com lynx-dev:270"] [276 "Coloured links using ncurses" "R J Partington <rjp@heffer.demon.co.uk>" "Sat, 16 Dec 1995 04:08:30 +0000 (GMT)" "<199512160408.EAA00222@heffer.demon.co.uk>" "" 7467 287 "Xref: diana.miranova.com lynx-dev:276"] [289 "unzip comment" "jeske@pa.dec.com (Steve Jeske)" "Sun, 17 Dec 95 10:22:46 -0800" "<9512171822.AA15163@zumbrota.pa.dec.com>" "" 804 16 "Xref: diana.miranova.com lynx-dev:289"] [294 "Re: Links on a page" "Al Gilman <asgilman@access.digex.net>" "Sun, 17 Dec 1995 23:47:29 -0500 (EST)" "<199512180447.XAA26240@access2.digex.net>" "<199512180312.DAA07763@heffer.demon.co.uk>" 1284 29 "Xref: diana.miranova.com lynx-dev:294"] [354 "bug in lynxcgi implementation" "David Trueman <david@cs.dal.ca>" "Tue, 26 Dec 1995 18:36:40 -0400" "<Pine.SUN.3.91.951226183334.23020G-100000@cs.dal.ca>" "<01HZ9PNV9LG20011DO@SCI.WFBR.EDU>" 390 9 "Xref: diana.miranova.com lynx-dev:354"] [356 "Re: bug in lynxcgi implementation" "Foteos Macrides <M!
!
ACRIDES@SCI.WFBR.EDU>" "Tue, 26 Dec 1995 20:41:09 -0500 (EST)" "<01HZ9YMTZYUQ0011DO@SCI.WFBR.EDU>" "" 1748 43 "Xref: diana.miranova.com lynx-dev:356"] [357 "Re: bug in lynxcgi implementation" "David Trueman <david@cs.dal.ca>" "Tue, 26 Dec 1995 22:56:00 -0400" "<Pine.SUN.3.91.951226225449.715B-100000@cs.dal.ca>" "<01HZ9YMTZYUQ0011DO@SCI.WFBR.EDU>" 1230 34 "Xref: diana.miranova.com lynx-dev:357"] [360 "2-4-FM and new Enhanced for Lynx icons" "Mike Brown <mike@hyperreal.com>" "Wed, 27 Dec 1995 10:10:39 -0800 (PST)" "<199512271810.KAA27420@taz.hyperreal.com>" "<v02140a01ad071d5b2265@[130.166.254.206]>" 1051 23 "Xref: diana.miranova.com lynx-dev:360"] [362 "SSLeay for Lynx" "Thomas Zerucha <tz@execpc.com>" "Wed, 27 Dec 1995 14:13:44 -0600 (CST)" "<Pine.SOL.3.91.951227140440.17791A-100000@earth>" "<199512271810.KAA27420@taz.hyperreal.com>" 995 29 "Xref: diana.miranova.com lynx-dev:362"] [394 "DirEd/Makefile problems, with patch" "Will Mengarini <seldon@eskimo.com>" "Wed, 10 Jan 1996!
!
 02:32:02 -0800 (PST)" "<199601101032.CAA25030@eskimo.com>" "" 8617 184 "Xref: miranova.com lynx-dev:394"] [435 "Re: DOWNLOADER: directive" "\"Mark T. Gray\" <markgray@postoffice.ptd.net>" "Mon, 15 Jan 1996 09:51:51 -0500 (EST)" "<Pine.LNX.3.91.960115094937.158E-100000@ptd.net>" "<9601151337.AA17652@blaze.trentu.ca>" 957 30 "Xref: miranova.com lynx-dev:435"] [441 "Re: DOWNLOADER: directive" "WHITLOCK@ACM.ORG" "Mon, 15 Jan 1996 12:49:28 -0600 (CDT)" "<01I01FJQSNME00HCNY@ACM.ORG>" "" 1563 41 "Xref: miranova.com lynx-dev:441"] [443 "Re: DOWNLOADER: directive" "Ismael Cordeiro <ismael@CAM.ORG>" "Mon, 15 Jan 1996 16:20:45 -0500 (EST)" "<199601152120.QAA10882@Ocean.CAM.ORG>" "<9601151337.AA17652@blaze.trentu.ca>" 1700 42 "Xref: miranova.com lynx-dev:443"] [445 "Re: DOWNLOADER: directive" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Mon, 15 Jan 1996 18:11:10 -0500 (EST)" "<01I01QVIE7J20030VP@SCI.WFBR.EDU>" "" 2051 40 "Xref: miranova.com lynx-dev:445"] [571 ": comp.infosystems.www.serve!
!
rs.misc: Lynx friendly imagemap" "lvirden@cas.org (Larry W. Virden, x2487)" "Sat, 27 Jan 1996 09:43:33 -0500" "<9601270943.AA15735@cas.org>" "" 2217 53 "Xref: miranova.com lynx-dev:571"] [641 "Re: State of libwww" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Tue, 06 Feb 1996 16:44:55 -0500 (EST)" "<01I0WDUHIGAW007DR1@SCI.WFBR.EDU>" "" 1665 29 "Xref: miranova.com lynx-dev:641"] [643 "Re: State of libwww" "Danny Mayer <mayer@ljsrv2.ENET.dec.com>" "Wed, 7 Feb 96 10:10:33 EST" "<9602071510.AA12769@us1rmc.bb.dec.com>" "" 2254 41 "Xref: miranova.com lynx-dev:643"] [824 "valid vs. \"historical\" vs. \"NetScape v2\" comment parsing" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Sat, 24 Feb 1996 11:28:46 -0500 (EST)" "<01I1L5255XDM00281N@SCI.WFBR.EDU>" "" 4633 93 "Xref: deanna.miranova.com lynx-dev:824"] [872 "Re: Lynx 2.4 is compliant with HTML 2.0? HTML 3.0?" "Gerald Oskoboiny <gerald@cs.ualberta.ca>" "Sun, 3 Mar 1996 17:13:54 -0700 (MST)" "<96Mar3.171427-0700_mst.138912-4+32@amisk.cs.ual!
!
berta.ca>" "<01I1WQ9XE0IQ003GQK@SCI.WFBR.EDU>" 1575 41 "Xref: deanna.miranova.com lynx-dev:872"] [1264 "RE: GridText.c bug still exists ... (add this line for Linux, at least)" "\"Bryan T. Vold\" <btv@ldl.HealthPartners.COM>" "Wed, 3 Apr 1996 15:04:44 -0600 (CST)" "<199604032104.PAA28710@ldl.HealthPartners.COM>" "" 1274 27 "Xref: deanna.miranova.com lynx-dev:1264"] [1273 "Re: LYNX  vs  AIX" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 04 Apr 1996 09:05:38 -0500 (EST)" "<01I34YPL38OI000SJ1@SCI.WFBR.EDU>" "" 2124 45 "Xref: deanna.miranova.com lynx-dev:1273"] [1277 "Lynx STARTFILE" "Al Gilman <asgilman@access.digex.net>" "Thu, 4 Apr 1996 10:51:31 -0500 (EST)" "<199604041551.KAA00939@access2.digex.net>" "<199604041343.IAA21912@access2.digex.net>" 2528 60 "Xref: deanna.miranova.com lynx-dev:1277"] [1279 "Re: problem with linux" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 04 Apr 1996 13:04:42 -0500 (EST)" "<01I357SOWQ3S000SJ1@SCI.WFBR.EDU>" "" 3748 74 "Xref: deanna.miranova.c!
!
om lynx-dev:1279"] [1289 "Re: problem with linux" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 04 Apr 1996 18:32:36 -0500 (EST)" "<01I35J7GL7PU000SJ1@SCI.WFBR.EDU>" "" 3255 57 "Xref: deanna.miranova.com lynx-dev:1289"] [1290 "Re: lynx2-4-FM autoconf" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 04 Apr 1996 18:55:46 -0500 (EST)" "<01I35JR9TNNI000SJ1@SCI.WFBR.EDU>" "" 1762 43 "Xref: deanna.miranova.com lynx-dev:1290"] [1529 "Re: 'secure protection of information'" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 24 Apr 1996 11:20:49 -0500 (EST)" "<01I3X1V56X9E007IG5@SCI.WFBR.EDU>" "" 2765 53 "Xref: deanna.miranova.com lynx-dev:1529"] [1535 "Re: Lynx and HTML \"IMG ALT\" tag" "Ismael Cordeiro <ismael@CAM.ORG>" "Wed, 24 Apr 1996 20:22:11 -0400 (EDT)" "<199604250022.UAA16752@Ocean.CAM.ORG>" "<v02110100ada3d6d0193b@[205.134.227.57]>" 2037 57 "Xref: deanna.miranova.com lynx-dev:1535"] [1664 "Re: lynx-bug, lynx-help" "Andrew Burday <andy@dep.philo.mcgill.ca>" "Tue, 30 Apr 1996 13!
!
:05:34 -0400 (EDT)" "<Pine.NXT.3.92.960429120320.14747C-100000@dep>" "<01I431GCIWYW00920T@SCI.WFBR.EDU>" 6832 149 "Xref: deanna.miranova.com lynx-dev:1664"] [1684 "Re: lynx-bug, lynx-help" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 01 May 1996 17:05:57 -0500 (EST)" "<01I474IBH6O8008RQI@SCI.WFBR.EDU>" "" 2018 43 "Xref: deanna.miranova.com lynx-dev:1684"] [1882 "Lynx-dev is Moving" "Al Gilman <asgilman@access.digex.net>" "Fri, 17 May 1996 00:28:24 -0400 (EDT)" "<199605170428.AAA13388@access2.digex.net>" "" 1964 63 "Xref: deanna.miranova.com lynx-dev:1882"] [1884 "Polymorphic WebObjects" "Al Gilman <asgilman@access.digex.net>" "Fri, 17 May 1996 09:24:26 -0400 (EDT)" "<199605171324.JAA05434@access2.digex.net>" "<199605171145.HAA29552@math.uwaterloo.ca>" 1241 29 "Xref: deanna.miranova.com lynx-dev:1884"] [1926 "Re: LYNX-DEV 2.5FM won't POST to this URL" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Tue, 04 Jun 1996 21:35:12 -0500 (EST)" "<01I5IWROQ1O2002TEJ@SCI.WFBR.EDU>" "" 2344!
!
 55 "Xref: deanna.miranova.com lynx-dev:1926"] [2005 "Re:  Patch for SJIS handling" "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su>" "Sat, 8 Jun 1996 23:02:23 +0400 (MSD)" "<199606081902.XAA03340@astral.msk.su>" "<01I5NQIDR0J6003NL8@SCI.WFBR.EDU>" 984 23 "Xref: deanna.miranova.com lynx-dev:2005"] [2018 "Re:  Patch for SJIS handling" "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su>" "Sun, 9 Jun 1996 13:39:32 +0400 (MSD)" "<199606090939.NAA00437@astral.msk.su>" "<01I5O6A3J8TU003GAP@SCI.WFBR.EDU>" 1048 24 "Xref: deanna.miranova.com lynx-dev:2018"] [2141 "Re:  Compile problems with 2-5M on Linux" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Mon, 17 Jun 1996 20:12:54 -0500 (EST)" "<01I60ZV5J4X0005GGP@SCI.WFBR.EDU>" "" 1583 33 "Xref: deanna.miranova.com lynx-dev:2141"] [2155 " Japanese (EUC) croaked" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Tue, 18 Jun 1996!
!
 23:49:12 +0900" "<199606181449.XAA12585@ews07.nara.kindai.ac.jp>" "" 1328 31 "Xref: deanna.miranova.com lynx-dev:2155"] [2235 " status of turning off numbered links" "lvirden@cas.org (Larry W. Virden, x2487)" "Fri, 21 Jun 1996 12:20:35 -0400" "<9606211220.AA5416@cas.org>" "" 1070 25 "Xref: deanna.miranova.com lynx-dev:2235"] [2243 " Lynx-current reload bug with Raw 8-bit mode OFF" "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) <ache@nagual.ru>" "Sat, 22 Jun 1996 01:19:21 +0400 (MSD)" "<199606212119.BAA02998@nagual.ru>" "" 682 25 "Xref: deanna.miranova.com lynx-dev:2243"] [2251 "Re:   patches for lynx2-5FM on 20-June-1996" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Sat, 22 Jun 1996 08:59:51 +0900" "<199606212359.IAA29734@ews07.nara.kindai.ac.jp>" "" 449 12 "Xref: deanna.miranova.com lynx-dev:2251"] [2254 "Re:  Lynx-current reload bug with Raw 8-bit mode OFF" "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) <ache@nagual.ru>!
!
" "Sat, 22 Jun 1996 09:43:42 +0400 (MSD)" "<199606220543.JAA00677@nagual.ru>" "<01I66NJIZ4J6006D64@SCI.WFBR.EDU>" 1712 54 "Xref: deanna.miranova.com lynx-dev:2254"] [2261 "Re:   patches for lynx2-5FM on 20-June-1996" "Yamamoto Hirotaka <ymmt@is.s.u-tokyo.ac.jp>" "Sun, 23 Jun 96 01:40:06 JST" "<9606221640.AA05948@ise24>" "<199606212359.IAA29734@ews07.nara.kindai.ac.jp>" 799 22 "Xref: deanna.miranova.com lynx-dev:2261"] [2428 " SSL Lynx 2.5 FM available" "jeremy@tddi.inetnebr.com (Jeremy Bettis)" "Fri, 5 Jul 1996 00:21:58 -0500 (CDT)" "<m0uc3L8-000EvGC@tddi.uucp>" "" 548 15 "Xref: deanna.miranova.com lynx-dev:2428"] [2458 " Accessing password protected pages causes a crash at exit" "Steven L Baur <steve@miranova.com>" "07 Jul 1996 15:41:55 -0700" "<m2buhrh657.fsf@totally-fudged-out-message-id>" "" 919 23 "Xref: deanna.miranova.com lynx-dev:2458"] [2472 "Re:  Accessing password protected pages causes a crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Mon, 08 Jul 1996 10:!
!
42:33 -0500 (EST)" "<01I6TSFZNM0I009KYK@SCI.WFBR.EDU>" "" 1501 33 "Xref: deanna.miranova.com lynx-dev:2472"] [2493 "Re:  Accessing password protected pages causes a crash at exit" "jeremy@tddi.inetnebr.com (Jeremy Bettis)" "Mon, 8 Jul 1996 19:06:56 -0500 (CDT)" "<m0udQKR-000EvGC@tddi.uucp>" "<01I6TSFZNM0I009KYK@SCI.WFBR.EDU>" 921 31 "Xref: deanna.miranova.com lynx-dev:2493"] [2495 " Re: Accessing password protected pages causes a crash at exit" "Steven L Baur <steve@miranova.com>" "08 Jul 1996 18:07:39 -0700" "<m2buhqmdyc.fsf@deanna.miranova.com>" "<01I6TSFZNM0I009KYK@SCI.WFBR.EDU>" 1051 34 "Xref: deanna.miranova.com lynx-dev:2495"] [2515 "Re:  Re: Accessing password protected pages causes a crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Tue, 09 Jul 1996 21:00:19 -0500 (EST)" "<01I6VSEUYQ78009GQR@SCI.WFBR.EDU>" "" 1287 38 "Xref: deanna.miranova.com lynx-dev:2515"] [2543 ":  Comment commentary" "Walter Skorski <walt@genetics1.JMP.TJU.EDU>" "Wed, 10 Jul 1996 15:18:12 !
!
-0400 (EDT)" "<199607101918.PAA21210@clyde.jmp.tju.edu>" "<Pine.NEB.3.93.960710085604.28176C-100000@zip0.zipnet.net>" 4332 95 "Xref: deanna.miranova.com lynx-dev:2543"] [2545 "Re: :  Comment commentary" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 10 Jul 1996 16:20:06 -0500 (EST)" "<01I6WW0QJTRM00A34H@SCI.WFBR.EDU>" "" 5920 129 "Xref: deanna.miranova.com lynx-dev:2545"] [2583 "Re:  Re: Re: Re: Accessing password protected pages causes a crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Thu, 11 Jul 1996 20:01:13 -0500 (EST)" "<01I6YIYVD6ME00009R@SCI.WFBR.EDU>" "" 721 22 "Xref: deanna.miranova.com lynx-dev:2583"] [2592 "Re:  Accessing password protected pages causes a  crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 12 Jul 1996 08:42:03 -0500 (EST)" "<01I6Z9CD4PO2000APU@SCI.WFBR.EDU>" "" 8668 212 "Xref: deanna.miranova.com lynx-dev:2592"] [2597 "Re:  Accessing password protected pages causes a  crash at exit" "\"Mark T. Gray\" <markgray@postoffice.ptd.n!
!
et>" "Fri, 12 Jul 1996 11:00:03 -0400 (EDT)" "<Pine.LNX.3.93.960712103618.165A-100000@ptd.net>" "<01I6Z9CD4PO2000APU@SCI.WFBR.EDU>" 1705 54 "Xref: deanna.miranova.com lynx-dev:2597"] [2601 "Re:  Accessing password protected pages causes a  crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 12 Jul 1996 11:53:33 -0500 (EST)" "<01I6ZG43TIB6000APU@SCI.WFBR.EDU>" "" 1073 26 "Xref: deanna.miranova.com lynx-dev:2601"] [2610 "Re:  Re: Accessing password protected pages causes a  crash at exit" "Andrew Kuchling <amk@magnet.com>" "Fri, 12 Jul 1996 16:50:34 -0400 (EDT)" "<199607122050.QAA29148@lemur.magnet.com>" "<m2ivbttib7.fsf@deanna.miranova.com>" 674 21 "Xref: deanna.miranova.com lynx-dev:2610"] [2611 "Re:  Re: Accessing password protected pages causes a  crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Fri, 12 Jul 1996 19:08:30 -0500 (EST)" "<01I6ZV2K4L5U000APU@SCI.WFBR.EDU>" "" 1544 35 "Xref: deanna.miranova.com lynx-dev:2611"] [2656 " Re: Accessing password pr!
!
otected pages causes a crash at exit" "Steven L Baur <steve@miranova.com>" "14 Jul 1996 18:35:15 -0700" "<m2d91yxknk.fsf@totally-fudged-out-message-id>" "<01I72EJTIDEQ000LT1@SCI.WFBR.EDU>" 1033 24 "Xref: deanna.miranova.com lynx-dev:2656"] [2662 " Character styles for lynx2-5FM (patch follows in next mail)" "Rob Partington <rjp@heffer.demon.co.uk>" "Mon, 15 Jul 1996 13:02:32 +0000 (GMT)" "<199607151302.NAA02502@heffer.demon.co.uk>" "" 2196 57 "Xref: deanna.miranova.com lynx-dev:2662"] [2668 " Re: Accessing password protected pages causes a crash at exit" "\"Mark T. Gray\" <markgray@postoffice.ptd.net>" "Mon, 15 Jul 1996 10:29:01 -0400 (EDT)" "<Pine.LNX.3.93.960715070549.545B-100000@ptd.net>" "" 1706 35 "Xref: deanna.miranova.com lynx-dev:2668"] [2670 "Re:  Re: Accessing password protected pages causes a crash at exit" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Mon, 15 Jul 1996 12:58:56 -0500 (EST)" "<01I73NNTX6UQ0002FJ@SCI.WFBR.EDU>" "" 3846 71 "Xref: deanna.miranova.com lynx-!
!
dev:2670"] [2681 " New patch for lynx2-5FM character styles" "Rob Partington <rjp@heffer.demon.co.uk>" "Mon, 15 Jul 1996 23:52:19 +0000 (GMT)" "<199607152352.XAA06357@heffer.demon.co.uk>" "" 25730 1061 "Xref: deanna.miranova.com lynx-dev:2681"] [2705 " Re: Vim, Lynx" "Bill Hogan <bhogan@bedlam.rahul.net>" "Tue, 16 Jul 96 23:57 PDT" "<m0ugQXx-0003pZC@bedlam.rahul.net>" "<m0ugJFn-0003pZC@bedlam.rahul.net> <Pine.SUN.3.90.960716181519.15418A-100000@foxtrot.rahul.net>" 1736 61 "Xref: deanna.miranova.com lynx-dev:2705"] [2809 "Re:  Downloading Graphics" "smcgee@sol.slcc.edu (Scott McGee (Personal))" "Fri, 19 Jul 1996 11:18:10 -0600" "<9607191718.AA02378@sol.slcc.edu.>" "" 1433 34 "Xref: deanna.miranova.com lynx-dev:2809"] [2824 "Re: Re:  where to start on documentation" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Sat, 20 Jul 1996 12:57:01 -0500 (EST)" "<01I7AOEWJOLE0002N8@SCI.WFBR.EDU>" "" 4194 88 "Xref: deanna.miranova.com lynx-dev:2824"] [2841 "Re: Re:  where to start on documentat!
!
ion" "smcgee@sol.slcc.edu (Scott McGee (Personal))" "Mon, 22 Jul 1996 13:36:37 -0600" "<9607221936.AA00657@sol.slcc.edu.>" "" 1277 32 "Xref: deanna.miranova.com lynx-dev:2841"] [2842 " -validate allows file:///?" "Steven L Baur <steve@miranova.com>" "22 Jul 1996 12:34:47 -0700" "<m2k9vwulns.fsf@deanna.miranova.com>" "<01I7AOEWJOLE0002N8@SCI.WFBR.EDU>" 685 20 "Xref: deanna.miranova.com lynx-dev:2842"] [2843 " Lynx-view.pl w/Lynx-2.5FM" "Steven L Baur <steve@miranova.com>" "22 Jul 1996 12:23:51 -0700" "<m2n30sum60.fsf@deanna.miranova.com>" "<01I7AOEWJOLE0002N8@SCI.WFBR.EDU>" 2243 74 "Xref: deanna.miranova.com lynx-dev:2843"] [2847 "Re:  -validate allows file:///?" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Mon, 22 Jul 1996 17:38:38 -0500 (EST)" "<01I7DQH24M36000D2M@SCI.WFBR.EDU>" "" 2101 47 "Xref: deanna.miranova.com lynx-dev:2847"] [2848 " Re: Lynx-view.pl w/Lynx-2.5FM" "Steven L Baur <steve@miranova.com>" "22 Jul 1996 14:47:59 -0700" "<m291ccufhs.fsf@deanna.miranova.com>" "<01!
!
I7AOEWJOLE0002N8@SCI.WFBR.EDU> <m2n30sum60.fsf@deanna.miranova.com>" 854 24 "Xref: deanna.miranova.com lynx-dev:2848"] [2849 " Re: -validate allows file:///?" "Steven L Baur <steve@miranova.com>" "22 Jul 1996 16:21:20 -0700" "<m2spajub67.fsf@deanna.miranova.com>" "<01I7DQH24M36000D2M@SCI.WFBR.EDU>" 1440 37 "Xref: deanna.miranova.com lynx-dev:2849"] [2853 "Re: Re:  where to start on documentation" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Mon, 22 Jul 1996 20:34:36 -0500 (EST)" "<01I7DWS0M1Y0000D2M@SCI.WFBR.EDU>" "" 2163 49 "Xref: deanna.miranova.com lynx-dev:2853"] [2854 "Re:  -validate allows file:///?" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Tue, 23 Jul 1996 09:53:13 +0900" "<199607230053.JAA26369@ews07.nara.kindai.ac.jp>" "" 610 15 "Xref: deanna.miranova.com lynx-dev:2854"] [2855 " Re: -validate allows file:///?" "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Tue, 23 Jul 1996 09:35:50 +0900" "<199607230035.JAA26277@ews07.nara.kindai.ac.jp>" "" 537 12 "Xref: dea!
!
nna.miranova.com lynx-dev:2855"] [2857 " Remote Lynx is up." "Steven L Baur <steve@miranova.com>" "22 Jul 1996 19:37:22 -0700" "<m291cbu23h.fsf@deanna.miranova.com>" "" 2547 101 "Xref: deanna.miranova.com lynx-dev:2857"] [2874 " Re: Question - Frames in Lynx" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Tue, 23 Jul 1996 16:03:29 -0500 (EST)" "<01I7F1Q07AG8000ML0@SCI.WFBR.EDU>" "" 1964 43 "Xref: deanna.miranova.com lynx-dev:2874"] [2877 "Re:  Remote Lynx is up." "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Tue, 23 Jul 1996 18:56:39 -0500 (EST)" "<01I7F79TTMGI000ML0@SCI.WFBR.EDU>" "" 3012 70 "Xref: deanna.miranova.com lynx-dev:2877"] [2879 " Re: Remote Lynx is up." "Steven L Baur <steve@miranova.com>" "23 Jul 1996 16:18:45 -0700" "<m2pw5m8soa.fsf@deanna.miranova.com>" "<Pine.SUN.3.94.960723132359.25558A-100000@huitzilo.tezcat.com>" 1353 38 "Xref: deanna.miranova.com lynx-dev:2879"] [2885 " Re: Remote Lynx is up." "Steven L Baur <steve@miranova.com>" "23 Jul 1996 21:00:26 -0700" "<m2!
!
hgqy8fmt.fsf@deanna.miranova.com>" "<01I7F79TTMGI000ML0@SCI.WFBR.EDU>" 3098 84 "Xref: deanna.miranova.com lynx-dev:2885"] [2887 "Re:  Re: Remote Lynx is up." "asada@three-a.co.jp (Takuya ASADA)" "Wed, 24 Jul 1996 15:44:11 +0900 (JST)" "<199607240644.PAA02219@benten.three-a.co.jp>" "<m2hgqy8fmt.fsf@deanna.miranova.com>" 572 18 "Xref: deanna.miranova.com lynx-dev:2887"] [2900 " Re: Re: Remote Lynx is up." "Steven L Baur <steve@miranova.com>" "24 Jul 1996 10:21:21 -0700" "<m2zq4pd0tq.fsf@deanna.miranova.com>" "<199607240644.PAA02219@benten.three-a.co.jp>" 982 29 "Xref: deanna.miranova.com lynx-dev:2900"] [2905 "Re:  Re: Re: Remote Lynx is up." "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 24 Jul 1996 14:37:35 -0500 (EST)" "<01I7GCJXLZV60000FZ@SCI.WFBR.EDU>" "" 2290 61 "Xref: deanna.miranova.com lynx-dev:2905"] [2911 " Re: Handling of text/html?" "Steven L Baur <steve@miranova.com>" "24 Jul 1996 14:06:39 -0700" "<m27mrtcqe8.fsf@deanna.miranova.com>" "<199607241801.OAA15996@clyde!
!
.jmp.tju.edu>" 1203 31 "Xref: deanna.miranova.com lynx-dev:2911"] [2914 "Re:  Re: Handling of text/html?" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 24 Jul 1996 18:05:41 -0500 (EST)" "<01I7GKJ0JBS20000FZ@SCI.WFBR.EDU>" "" 960 24 "Xref: deanna.miranova.com lynx-dev:2914"] [2915 "Re:  Re: Handling of text/html?" "Foteos Macrides <MACRIDES@SCI.WFBR.EDU>" "Wed, 24 Jul 1996 18:46:45 -0500 (EST)" "<01I7GM0BR8RC0000FZ@SCI.WFBR.EDU>" "" 1113 25 "Xref: deanna.miranova.com lynx-dev:2915"] [2916 "Re:  Re: Re: Remote Lynx is up." "Subir Grewal <grewals@acf2.NYU.EDU>" "Wed, 24 Jul 1996 20:18:22 -0400 (EDT)" "<Pine.ULT.3.92.960724201110.1398A-100000@acf2.NYU.EDU>" "<01I7GCJXLZV60000FZ@SCI.WFBR.EDU>" 708 18 "Xref: deanna.miranova.com lynx-dev:2916"] [2917 " Re: Remote Lynx is up." "Nelson Henry Eric <nelsonhe@nara.kindai.ac.jp>" "Thu, 25 Jul 1996 09:25:15 +0900" "<199607250025.JAA04715@ews07.nara.kindai.ac.jp>" "" 488 12 "Xref: deanna.miranova.com lynx-dev:2917"] [2918 " Re: Handling o!
!
f text/html?" "Steven L Baur <steve@miranova.com>" "24 Jul 1996 17:46:37 -0700" "<m27mrtb1n6.fsf@deanna.miranova.com>" "<01I7GM0BR8RC0000FZ@SCI.WFBR.EDU>" 1167 28 "Xref: deanna.miranova.com lynx-dev:2918"] [2923 "Re:  LYMessages_??.h" "asada@three-a.co.jp (Takuya ASADA)" "Thu, 25 Jul 1996 14:02:30 +0900 (JST)" "<199607250502.OAA04358@benten.three-a.co.jp>" "<199607240800.RAA02423@ews07.nara.kindai.ac.jp>" 641 19 "Xref: deanna.miranova.com lynx-dev:2923"] [2924 " http ftp gopher?" "chall01@mail.coin.missouri.edu (Curtis Hall)" "Thu, 25 Jul 1996 00:49:18 -0500 (CDT)" "<v01540b00ae1c748af7c9@[198.209.10.47]>" "" 344 15 "Xref: deanna.miranova.com lynx-dev:2924"] [2925 "Re:  Re: Re: Remote Lynx is up." "asada@three-a.co.jp (Takuya ASADA)" "Thu, 25 Jul 1996 14:49:12 +0900 (JST)" "<199607250549.OAA04436@benten.three-a.co.jp>" "<01I7GCJXLZV60000FZ@SCI.WFBR.EDU>" 1400 43 "Xref: deanna.miranova.com lynx-dev:2925"] [2926 "Re:  Remote Lynx is up." "david@djwhome.demon.co.uk (David Woolley!
!
)" "Tue, 23 Jul 1996 08:25:31 +0100 (BST)" "<m0uibqV-0005fvC@djwhome.demon.co.uk>" "<m291cbu23h.fsf@deanna.miranova.com>" 532 24 "Xref: deanna.miranova.com lynx-dev:2926"] [2927 "Re:   Tables, I do it, but is there a better way" "asada@three-a.co.jp (Takuya ASADA)" "Thu, 25 Jul 1996 16:49:56 +0900 (JST)" "<199607250749.QAA04645@benten.three-a.co.jp>" "<199607250150.KAA05182@ews07.nara.kindai.ac.jp>" 945 25 "Xref: deanna.miranova.com lynx-dev:2927"]))
  tm-gnus/decode-summary-from-and-subjects()
  run-hooks(gnus-select-group-hook)
  # bind (did-select quit-config new-group no-display kill-buffer no-article show-all group)
  gnus-summary-read-group("nnml:lynx-dev" nil nil)
  # bind (group number active marked entry group no-article all)
  gnus-group-read-group(nil nil nil)
  # bind (group no-article all)
  gnus-topic-read-group(nil)
  # bind (command-debug-status)
  call-interactively(gnus-topic-read-group)
  # (condition-case ... . error)
  # (catch top-level ...)

#0  0x40204741 in __kill ()
#1  0x808a23d in fatal_error_signal (sig=6) at emacs.c:193
#2  0xbfffd2e8 in __ypbindlist ()
#3  0x4023218d in gsignal ()
#4  0x819f9de in ccl_driver (ccl=0x8330a94, 
    src=0x882c760 " m ITEM, as the newe@\202\b@o\b", 
    dst=0x882c7e0, n=13, end_flag=0) at /i/xemacs-20.0-b26/src/./lisp.h:1221
#5  0x81a829c in mule_decode (decoding=0x8330a00, 
    src=0x882c760 " m ITEM, as the newe@\202\b@o\b", 
    dst=0x882c7e0, n=13) at /i/xemacs-20.0-b26/src/./mule-coding.c:2111
#6  0x81afc04 in decoding_writer (stream=0x8330a00, 
    data=0x882c760 " m ITEM, as the newe@\202\b@o\b", size=13)
    at /i/xemacs-20.0-b26/src/./mule-coding.c:1914
#7  0x80fb634 in Lstream_flush_out (lstr=0x8330a00) at lstream.c:363
#8  0x80fb6a9 in Lstream_flush (lstr=0x8330a00) at lstream.c:393
#9  0x81afe39 in encoding_flusher (stream=0x882d900)
    at /i/xemacs-20.0-b26/src/./mule-coding.c:2418
#10 0x80fb682 in Lstream_flush_out (lstr=0x882d900) at lstream.c:385
#11 0x80fbf46 in Lstream_close (lstr=0x882d900) at lstream.c:393
#12 0x81a8369 in close_both_streams (cons=677724644)
    at /i/xemacs-20.0-b26/src/./mule-coding.c:2126
#13 0x8093984 in unbind_to (count=47, value=405733380) at eval.c:4800
#14 0x81a8772 in Fdecode_coding_region (start=1, end=14, 
    coding_system=407983716, buffer=405733380)
    at /i/xemacs-20.0-b26/src/./mule-coding.c:2187
#15 0x8090835 in primitive_funcall (fn=0x81a83d8 <Fdecode_coding_region>, 
    nargs=4, args=0xbfffda94) at eval.c:3490
#16 0x80909b8 in funcall_subr (subr=0x82be160, args=0xbfffda94) at eval.c:3526
#17 0x808ff8d in funcall_recording_as (recorded_as=405852908, nargs=4, 
    args=0xbfffdb74) at eval.c:3207
#18 0x8090113 in Ffuncall (nargs=4, args=0xbfffdb74) at eval.c:3253
#19 0x80638d3 in Fbyte_code (bytestr=942249768, vector=1210685280, maxdepth=4)
    at bytecode.c:419
#20 0x8090eac in funcall_lambda (fun=405375168, nargs=2, arg_vector=0xbfffdcdc)
    at eval.c:3636
#21 0x809000e in funcall_recording_as (recorded_as=406487012, nargs=3, 
    args=0xbfffdcd8) at eval.c:3223
#22 0x8090113 in Ffuncall (nargs=3, args=0xbfffdcd8) at eval.c:3253
#23 0x80638d3 in Fbyte_code (bytestr=947593856, vector=1216530720, maxdepth=4)
    at bytecode.c:419
#24 0x8090eac in funcall_lambda (fun=408197412, nargs=2, arg_vector=0xbfffde9c)
    at eval.c:3636
#25 0x809000e in funcall_recording_as (recorded_as=408196588, nargs=3, 
    args=0xbfffde98) at eval.c:3223
#26 0x8090113 in Ffuncall (nargs=3, args=0xbfffde98) at eval.c:3253
#27 0x80638d3 in Fbyte_code (bytestr=947609188, vector=1216488704, maxdepth=4)
    at bytecode.c:419
#28 0x8090eac in funcall_lambda (fun=405722052, nargs=3, arg_vector=0xbfffe074)
    at eval.c:3636
#29 0x809000e in funcall_recording_as (recorded_as=405724340, nargs=4, 
    args=0xbfffe070) at eval.c:3223
#30 0x8090113 in Ffuncall (nargs=4, args=0xbfffe070) at eval.c:3253
#31 0x80638d3 in Fbyte_code (bytestr=947609020, vector=1216488768, maxdepth=5)
    at bytecode.c:419
#32 0x8090eac in funcall_lambda (fun=405722020, nargs=1, arg_vector=0xbfffe2f8)
    at eval.c:3636
#33 0x809000e in funcall_recording_as (recorded_as=405724316, nargs=2, 
    args=0xbfffe2f4) at eval.c:3223
#34 0x8090113 in Ffuncall (nargs=2, args=0xbfffe2f4) at eval.c:3253
#35 0x80638d3 in Fbyte_code (bytestr=947618888, vector=1216488896, maxdepth=5)
    at bytecode.c:419
#36 0x8090eac in funcall_lambda (fun=405721892, nargs=1, arg_vector=0xbfffe508)
    at eval.c:3636
#37 0x809000e in funcall_recording_as (recorded_as=409845084, nargs=2, 
    args=0xbfffe504) at eval.c:3223
#38 0x8090113 in Ffuncall (nargs=2, args=0xbfffe504) at eval.c:3253
#39 0x80638d3 in Fbyte_code (bytestr=947618648, vector=1216489408, maxdepth=4)
    at bytecode.c:419
#40 0x8090eac in funcall_lambda (fun=411239396, nargs=1, arg_vector=0xbfffe610)
    at eval.c:3636
#41 0x809000e in funcall_recording_as (recorded_as=411239396, nargs=2, 
    args=0xbfffe60c) at eval.c:3223
#42 0x8091720 in call1 (fn=411239396, arg0=1216513856) at eval.c:3253
#43 0x80cc9d8 in mapcar1 (leni=102, vals=0xbfffe680, fn=411239396, 
    seq=677807004) at fns.c:3321
#44 0x80ccb37 in Fmapcar (fn=411239396, seq=677807004) at fns.c:3382
#45 0x8090809 in primitive_funcall (fn=0x80ccae8 <Fmapcar>, nargs=2, 
    args=0xbfffe910) at eval.c:3486
#46 0x80909b8 in funcall_subr (subr=0x8205d64, args=0xbfffe910) at eval.c:3526
#47 0x808ff8d in funcall_recording_as (recorded_as=405830860, nargs=3, 
    args=0xbfffe90c) at eval.c:3207
#48 0x8090113 in Ffuncall (nargs=3, args=0xbfffe90c) at eval.c:3253
#49 0x80638d3 in Fbyte_code (bytestr=947618432, vector=1216488960, maxdepth=3)
    at bytecode.c:419
#50 0x8090eac in funcall_lambda (fun=410300868, nargs=0, arg_vector=0xbfffea80)
    at eval.c:3636
#51 0x809000e in funcall_recording_as (recorded_as=409845036, nargs=1, 
    args=0xbfffea7c) at eval.c:3223
#52 0x809147e in run_hook_with_args_in_buffer (buf=0x8538c00, nargs=1, 
    args=0xbfffea7c, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3253
#53 0x80914f6 in run_hook_with_args (nargs=1, args=0xbfffea7c, 
    cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3845
#54 0x80911c7 in Frun_hooks (nargs=1, args=0xbffff39c) at eval.c:3697
#55 0x808ff43 in funcall_recording_as (recorded_as=405821780, nargs=2, 
    args=0xbffff398) at eval.c:3191
#56 0x8090113 in Ffuncall (nargs=2, args=0xbffff398) at eval.c:3253
#57 0x80638d3 in Fbyte_code (bytestr=944522768, vector=1212576768, maxdepth=4)
    at bytecode.c:419
#58 0x8090eac in funcall_lambda (fun=408824420, nargs=3, arg_vector=0xbffff654)
    at eval.c:3636
#59 0x809000e in funcall_recording_as (recorded_as=409446156, nargs=4, 
    args=0xbffff650) at eval.c:3223
#60 0x8090113 in Ffuncall (nargs=4, args=0xbffff650) at eval.c:3253
#61 0x80638d3 in Fbyte_code (bytestr=945429036, vector=1214064256, maxdepth=6)
    at bytecode.c:419
#62 0x8090eac in funcall_lambda (fun=409411428, nargs=3, arg_vector=0xbffff808)
    at eval.c:3636
#63 0x809000e in funcall_recording_as (recorded_as=409345708, nargs=4, 
    args=0xbffff804) at eval.c:3223
#64 0x8090113 in Ffuncall (nargs=4, args=0xbffff804) at eval.c:3253
#65 0x80638d3 in Fbyte_code (bytestr=946621404, vector=1211021376, maxdepth=4)
    at bytecode.c:419
#66 0x8090eac in funcall_lambda (fun=408330692, nargs=1, arg_vector=0xbffff930)
    at eval.c:3636
#67 0x809000e in funcall_recording_as (recorded_as=409779788, nargs=2, 
    args=0xbffff92c) at eval.c:3223
#68 0x8090113 in Ffuncall (nargs=2, args=0xbffff92c) at eval.c:3253
#69 0x8066cea in Fcall_interactively (function=409779788, 
    record_flag=405733380, keys=405733380) at callint.c:931
#70 0x808eca8 in Fcommand_execute (cmd=409779788, record=405733380, 
    keys=405733380) at eval.c:2628
#71 0x80a28be in execute_command_event (command_builder=0x832b700, 
    event=407066320) at event-stream.c:3484
#72 0x80a3aaf in Fdispatch_event (event=407066320) at event-stream.c:3819
#73 0x80709b3 in Fcommand_loop_1 () at cmdloop.c:542
#74 0x80706cf in command_loop_1 (dummy=405733380) at cmdloop.c:462
#75 0x808d35a in condition_case_1 (handlers=405733476, 
    bfun=0x8070664 <command_loop_1>, barg=405733380, 
    hfun=0x806fa68 <cmd_error>, harg=405733380) at eval.c:1672
#76 0x8070b64 in command_loop_2 (dummy=405733380) at cmdloop.c:224
#77 0x808d175 in internal_catch (tag=405811148, 
    func=0x8070b44 <command_loop_2>, arg=405733380, threw=0x0) at eval.c:1347
#78 0x806ff2e in initial_command_loop (load_me=405733380) at cmdloop.c:273
#79 0x808ad54 in Frunning_temacs_p () at emacs.c:1374
#80 0x808b0e2 in main (argc=1, argv=0xbffffc28, envp=0xbffffc30)
    at emacs.c:1518
#81 0x804ed4b in _start ()

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 25 09:50:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA19881 for xemacs-beta-people; Thu, 25 Jul 1996 09:50:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA19878 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 25 Jul 1996 09:50:46 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA23502 for <xemacs-beta@cs.uiuc.edu>; Thu, 25 Jul 1996 09:50:46 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id JAA08561; Thu, 25 Jul 1996 09:49:42 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id JAA19541; Thu, 25 Jul 1996 09:49:41 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id KAA08221; Thu, 25 Jul 1996 10:49:40 -0400
To: Marc Paquette <Marc.Paquette@Softimage.com>
cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
References: <7274.838225260@rtp.ericsson.se> <199607242147.OAA17612@xemacs.eng.sun.com>  <199607251313.JAA08770@research20.RND.Softimage.COM> 
Subject: Re: $PATH and 19.14 
In-reply-to: (Your message of Thu, 25 Jul 1996 09:13:51 EDT.)
             <199607251313.JAA08770@research20.RND.Softimage.COM> 
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 25 Jul 1996 10:45:37 -0400
Message-ID: <12679.838305937@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Marc" == Marc Paquette <Marc.Paquette@Softimage.com> writes:


    Marc> Personnally, I tend to be nervous when something adds a '.'
    Marc> in my path (security breech).

My understanding is that it's not adding "." to the path.  It was, in
essence, already there because PATH contained "::" or something like
that.

I guess xemacs was converting "::" to be nil instead of ".", which is
equivalent.  So, you already had that breach, and xemacs is just
making it explicit.  

Ray

From xemacs-beta-request@cs.uiuc.edu  Thu Jul 25 15:03:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA21195 for xemacs-beta-people; Thu, 25 Jul 1996 15:03:39 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA21192 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 25 Jul 1996 15:03:37 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA03502 for <xemacs-beta@cs.uiuc.edu>; Thu, 25 Jul 1996 15:03:39 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id NAA15634; Thu, 25 Jul 1996 13:02:26 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id NAA03098; Thu, 25 Jul 1996 13:01:36 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA10877; Thu, 25 Jul 1996 13:01:34 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA20900; Thu, 25 Jul 1996 13:01:29 -0700
Date: Thu, 25 Jul 1996 13:01:29 -0700
Message-Id: <199607252001.NAA20900@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Marc Paquette <Marc.Paquette@Softimage.com>
Cc: Raymond Toy <toy@rtp.ericsson.se>,
        XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: $PATH and 19.14
In-Reply-To: <199607251313.JAA08770@research20.RND.Softimage.COM>
References: <7274.838225260@rtp.ericsson.se>
	<199607242147.OAA17612@xemacs.eng.sun.com>
	<199607251313.JAA08770@research20.RND.Softimage.COM>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Marc" == Marc Paquette <Marc.Paquette@Softimage.COM> writes:

Marc> Personnally, I tend to be nervous when something adds a '.' in my
Marc> path (security breech).

If you have a NULL element on your PATH, that is exactly equivalent to
`.' (on Solaris at least - try it)

Marc> In this case, I suppose that this code is only trying to find the
Marc> sparcworks/sunpro/workshop executable and that the value of dir is
Marc> only used by sunpro-dir-p, that it is used in a non-dangerous way
Marc> (does not actually execute an external program) and that I'm just a
Marc> tad too paranoiac ?

The `.' on their PATH is effectively already there.

Martin

From xemacs-beta-request@cs.uiuc.edu  Fri Jul 26 06:39:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA27067 for xemacs-beta-people; Fri, 26 Jul 1996 06:39:51 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA27064 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 26 Jul 1996 06:39:50 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA08767 for <xemacs-beta@xemacs.org>; Fri, 26 Jul 1996 06:39:43 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id UAA24185; Fri, 26 Jul 1996 20:34:41 +0900 (JST)
Message-Id: <199607261134.UAA24185@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.65, tm-view 7.66
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: Martin Buchholz <mrb@eng.sun.com>
cc: xemacs-beta@xemacs.org
Subject: Re: [20.0 with mule] decode-coding-region 
In-reply-to: Your message of "Wed, 24 Jul 1996 14:56:28 MST."
             <199607242156.OAA17631@xemacs.eng.sun.com> 
Mime-Version: 1.0 (generated by tm-edit 7.74)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Fri_Jul_26_20:34:22_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Fri, 26 Jul 1996 20:34:41 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Fri_Jul_26_20:34:22_1996-1
Content-Type: text/plain; charset=US-ASCII

>>>>> In <199607242156.OAA17631@xemacs.eng.sun.com> 
>>>>>	Martin Buchholz <mrb@eng.sun.com> wrote:

Martin> >>>>> "Tomo" == MORIOKA Tomohiko <ISO-2022-JP> writes:

Tomo>   I hate my `code-converter-is-broken' hack, so I traced
Tomo> `decode-coding-region'. It is failed at line 2151 of
Tomo> mule-coding.c:

Tomo>   outstream = make_lisp_buffer_output_stream (buf, b, 0);

Tomo> So traced `make_lisp_buffer_output_stream'. It calls following:

Tomo>   Lisp_Object lstr = make_lisp_buffer_stream_1 (buf, pos, 0, flags, "w");

Tomo> However `make_lisp_buffer_stream_1' seems not support output stream:

Tomo>   /* Make sure the luser didn't pass "w" in. */
Tomo>   if (!strcmp (mode, "w"))
Tomo>     abort ();

Martin> This patch will be in the next beta. Does it fix your problem?

Martin> *** /tmp/geta17622	Wed Jul 24 14:51:10 1996
Martin> --- lstream.c	Sun Jun 23 00:03:42 1996

  Thanks. It is fixed.

  However behavior of `decode-coding-region' is not good. It does not
only change point, but also `save-excursion' does not work. Do you
have a any idea?

  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key
--pgp-sign-Multipart_Fri_Jul_26_20:34:22_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMfitRxnuUGV7wuH5AQH3yQP+Ng738RXJqDtFkKpUgzLRTz8M7XXCToDo
4TYKSZnEl33rm5xYD70PEz5c+sZoj3ps/+QhFm+YBPQ1EOLQCdn9DIk/6f0r5+SK
lYSTaMi6hHVdSDwxpANeSm04nxF0XQP/jJPFIwntJgFBtwL8kM+KqR59mkg0I5ka
6om+Tm9WSCE=
=LF4u
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Fri_Jul_26_20:34:22_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Fri Jul 26 06:46:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA27084 for xemacs-beta-people; Fri, 26 Jul 1996 06:46:19 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA27081 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 26 Jul 1996 06:46:19 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA24535 for <xemacs-beta@cs.uiuc.edu>; Fri, 26 Jul 1996 06:46:17 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id UAA24543; Fri, 26 Jul 1996 20:45:49 +0900 (JST)
Message-Id: <199607261145.UAA24543@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.65, tm-view 7.66
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.31
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: [20.0 with mule] decode-coding-region 
In-reply-to: Your message of "25 Jul 1996 04:28:44 MST."
             <m2687co9lf.fsf@deanna.miranova.com> 
Mime-Version: 1.0 (generated by tm-edit 7.74)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Fri_Jul_26_20:45:29_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Fri, 26 Jul 1996 20:45:48 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Fri_Jul_26_20:45:29_1996-1
Content-Type: text/plain; charset=US-ASCII

>>>>> In <m2687co9lf.fsf@deanna.miranova.com> 
>>>>>	Steven L Baur <steve@miranova.com> wrote:

Steven> >>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:

Steven> >>>>> "Tomo" == MORIOKA Tomohiko writes:
Tomo> I hate my `code-converter-is-broken' hack, so I traced
Tomo> `decode-coding-region'. It is failed at line 2151 of
Tomo> mule-coding.c:

Martin> This patch will be in the next beta. Does it fix your problem?

Steven> I'm still getting a core dump when KOI8 decoding is attempted.

  Martin's patch solves problem of
`{decode|encode}-coding-{region|string}', however it does not solve
CCL problem. KOI8 problem may be caused by problem of CCL. hz or other 
coding-system using CCL does not work too.

  By the way, as quick hack, you can display KOI8 characters to define
private charset and coding-system for KOI8 if you have a font for
KOI8. (Of course, it is not good solution)

  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key
--pgp-sign-Multipart_Fri_Jul_26_20:45:29_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMfiv5xnuUGV7wuH5AQEj7wP/fV3bsI+Q0ThKcLutLID5HFX/ucCOPBmL
koI7lx9XB81VfOLEIb8EMWdhoxcw8YcU8pEWafJ9qk4vQbhufk2hVGt6eLwoCGxa
DxXu0wOOq59l9A/8gz+mLTVveomvKpoDrrm0IaVJ4zDx5n9dwl+p9UW+fG5ZrTQz
kZ8Wy24JYo4=
=Jl6I
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Fri_Jul_26_20:45:29_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Mon Jul 29 12:57:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA17585 for xemacs-beta-people; Mon, 29 Jul 1996 12:57:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA17582 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 29 Jul 1996 12:57:46 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA22583 for <xemacs-beta@cs.uiuc.edu>; Mon, 29 Jul 1996 12:57:40 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA12035; Mon, 29 Jul 1996 10:55:33 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Submission for XEmacs 19.15 (linux-c-mode)
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.74)
Content-Type: text/plain; charset=US-ASCII
Date: 29 Jul 1996 10:55:30 -0700
Message-ID: <m2spabuep9.fsf@deanna.miranova.com>
Lines: 114
X-Mailer: Gnus v5.2.37/XEmacs 19.14

Variations of this code have been used for a long time by Linux kernel
developers who use Emacs.  I propose adding it as a standard feature
to XEmacs.  This code plugs into cc-mode, and doesn't change anything
if not used.


;;; cc-linux.el --- Replace braindead GNU C style with the recommended
;;;                 Linux Kernel style

;; Author:		1996 Alan Shutko <ats@shep1.wustl.edu>
;; Maintainer:		1996 Steven L Baur <steve@miranova.com>
;; Created:		1996/07/25
;; Version:		1.0
;; Last Modified:	1996/07/27
;; Keywords:		c languages linux

;; This file is part of XEmacs.

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2 of the License, or
;; (at your option) any later version.
;; 
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;; 
;; You should have received a copy of the GNU General Public License
;; along with this program; if not, write to the Free Software
;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

;;; Synched up with: Not in FSF.

;;; Commentary:
;; See the file Documentation/CodingStyle distributed with the Linux kernel
;; This will define the M-x linux-c-mode command.  When hacking on a
;; module, if you put the string -*- linux-c -*- somewhere on the first
;; two lines, this mode will be automatically invoked. Also, you may want
;; to add
;;
;; (setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
;;                       auto-mode-alist))

;; to your .emacs file if you want to have linux-c-mode switched on
;; automagically when you edit source files under /usr/src/linux.

;; But even if you fail in getting emacs to do sane formatting, not
;; everything is lost: use "indent".

;; Now, again, GNU indent has the same brain dead settings that GNU emacs
;; has, which is why you need to give it a few command line options. 
;; However, that's not too bad, because even the makers of GNU indent
;; recognize the authority of K&R (the GNU people aren't evil, they are
;; just severely misguided in this matter), so you just give indent the
;; options "-kr -i8" (stands for "K&R, 8 character indents"). 

;;; Code:

(require 'cc-mode)

(defconst linux-c-style 
  '((c-basic-offset . 8)
    (c-comment-only-line-offset . 0)
    (c-offsets-alist
     (statement-block-intro . +)
     (knr-argdecl-intro . 0)
     (substatement-open . 0)
     (label . 0)
     (statement-cont . +))
    (c-hanging-braces-alist . ((brace-list-open) 
			       (substatement-open after) 
			       (block-close . c-snug-do-while)))
    (c-cleanup-list . ((brace-else-brace)))))

;;;###autoload
(defun linux-c-mode ()
  "C mode with Linux kernel indentation."
  (interactive)
  (c-mode)
  (set-c-style "linux"))

			             
(defun c-snug-if-or-do (syntax pos)
  "Dynamically calculate brace hanginess for do-while statements.
Using this function, `else' clauses that end a `if-else' block will
remain on the same line as the brace that closes that block.

See `c-hanging-braces-alist' for how to utilize this function as an
ACTION associated with `block-close' syntax."
  (save-excursion
    (let (langelem)
      (if (and (eq syntax 'block-close)
	       (setq langelem (assq 'block-close c-syntactic-context))
	       (progn (goto-char (cdr langelem))
		      (if (= (following-char) ?{)
			  (forward-sexp -1))
		      (looking-at "\\<if\\|do\\>[^_]")))
	  '(before)
	'(before after)))))

(add-hook 'c-mode-common-hook
 	  '(lambda () (c-add-style "Linux" linux-c-style)))

(provide 'cc-linux)

;;; cc-linux.el ends here


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Jul 29 14:17:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA17900 for xemacs-beta-people; Mon, 29 Jul 1996 14:17:03 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA17897 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 29 Jul 1996 14:17:02 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA25560 for <xemacs-beta@cs.uiuc.edu>; Mon, 29 Jul 1996 14:17:02 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa20666;
          29 Jul 96 15:12 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id PAA28983; Mon, 29 Jul 1996 15:11:47 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id PAA00499; Mon, 29 Jul 1996 15:11:46 -0400
Date: Mon, 29 Jul 1996 15:11:46 -0400
Message-Id: <199607291911.PAA00499@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Submission for XEmacs 19.15 (linux-c-mode)
References: <m2spabuep9.fsf@deanna.miranova.com>
Reply-To: CCMODE Maintainer <cc-mode-help@python.org>
X-Attribution: BAW
X-Oblique-Strategy: Listen to the quiet voice
X-WWW-Homepage: http://www.python.org/~bwarsaw


I wouldn't be opposed to adding a "linux" style to c-style-alist, but
I know zero about Linux coding styles.  If Steve's style looks good to
all you Linux hackers, let me know and I'll add it for the next
release.

-Barry

From xemacs-beta-request@cs.uiuc.edu  Mon Jul 29 17:29:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA18551 for xemacs-beta-people; Mon, 29 Jul 1996 17:29:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA18545 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 29 Jul 1996 17:29:58 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA13945 for <xemacs-beta@xemacs.org>; Mon, 29 Jul 1996 17:29:54 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id PAA09227; Mon, 29 Jul 1996 15:29:25 -0700
Received: from scooter.canada.sun.com (scooter-8.Canada.Sun.COM) by Canada.Sun.COM (4.1/SMI-4.1)
	id AA17225; Mon, 29 Jul 96 18:29:23 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id SAA13694; Mon, 29 Jul 1996 18:29:20 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id SAA04882; Mon, 29 Jul 1996 18:29:18 -0400
Date: Mon, 29 Jul 1996 18:29:18 -0400
Message-Id: <199607292229.SAA04882@detlev.canada.sun.com>
From: Georg Nikodym <georgn@canada.sun.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: deriving modes from cc-mode
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII


I'm attempting to derive a mode for ADL from cc-mode.

The language looks kind of like:

module NAME imports
    SOME,
    COMMA,
    SEPARATED,
    LIST,
    OF,
    IMPORTED,
    MODULES
{

    auxiliary {
	// extern C function decls go here
	boolean some_pre_condition(void);
	boolean is_sane(int);
    }

    int FUNCTION (ARG, LIST) // A la C but no semicolon until the
			     // end of the semantics {} statement
	semantics {

	    // Comma separated list of semantic assertions

	    exception := (return == -1),  // return is a value!
	    normal := ! exception,

	    @some_pre_condition(),

	    normally {
		some_post_condition,
		is_sane(return)
	    }
	};

}; // End of the module which can have 

Of course, it's more complicated than that, but a mode that handles
this stuff would be a great start.

Anyway, I now have a skeletel ADL mode, but I having some trouble
figuring out how the cc-mode code determines what the syntactic
elements are.  I'm beginning to get a sinking feeling that there's
more hard-coded stuff in there than is desirable (particularly WRT to
commas).

Has anybody been down this path, and are there any pearls of wisdom
that can be shared?

From xemacs-beta-request@cs.uiuc.edu  Tue Jul 30 12:30:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA24644 for xemacs-beta-people; Tue, 30 Jul 1996 12:30:21 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA24641 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 30 Jul 1996 12:30:19 -0500 (CDT)
Received: from ns1.eds.com (ns1.eds.com [192.85.154.78]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA02756 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 12:30:20 -0500 (CDT)
Received: by ns1.eds.com (hello)
	id NAA06839; Tue, 30 Jul 1996 13:30:19 -0400
Received: from kocrsv04.delcoelect.com (kocrsv04.delcoelect.com [144.250.100.205]) by nnsa.eds.com (8.7.5/8.7.3) with ESMTP id NAA30914 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 13:29:49 -0400 (EDT)
Received: from kocrsw12.delcoelect.com (kocrsw12.delcoelect.com [144.250.106.18]) by kocrsv04.delcoelect.com (8.7.5/8.7.3) with SMTP id MAA11178 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 12:29:48 -0500 (EST)
Received: from kocrsw12 by kocrsw12.delcoelect.com (SMI-8.6/SMI-SVR4)
	id MAA19988; Tue, 30 Jul 1996 12:29:47 -0500
X-Mailer: exmh version 1.6.6 3/24/96
To: xemacs-beta@cs.uiuc.edu
Subject: Problem with popup menu in 19.14
X-Face: 4tk3bJx]I+QTZ|=]*1+Z){9+;5u_hK*NBeZK6[+B+iB%bVuOJ%^uK~fIG}O-}%WLX*D^aW>
 Gv8E3Xtz0\N&fQl^:pj<K{xM`:d>pPt:9lF-YXB%O)?@rd?*/jE!s94`?]:jJ#C5RDP:;Mr.3lwo`0
 {vIT+<{%IRwe]vLd]7>\X|*z{TUX_t;?TPcOLBMIv8_V92!Vk(*DJVU~0M[`5D^PAWLniO1?YYWArM
 U*j9o+>?1MWi.lO?F-?aVt:qQ8OaG?R}B:I!7S_+KuzxZ.f9M@$z#n\bG2$Q2{od
Date: Tue, 30 Jul 1996 12:29:46 -0500
Message-ID: <19986.838747786@kocrsw12>
From: Mike Scheidler <c23mts@eng.delcoelect.com>

One of our users just ran across this problem in 19.14.  This may have
already been reported on the newsgroup, but I wouldn't know, as we're just
coming out of an extended period of Newslessness (damned corporate
politics...).  At any rate, here's the problem:

The x11/x-menubar.el module defines

        (defconst default-popup-menu
          '("XEmacs Commands"
            :filter edit-menu-filter
            ["Undo"             advertised-undo         t]
            ["Cut"              x-kill-primary-selection   t]
            ["Copy"             x-copy-primary-selection   t]
            ["Paste"            x-yank-clipboard-selection t]
            ["Clear"            x-delete-primary-selection t]
            "-----"
            ["Select Block"     mark-paragraph          t]
            ["Split Window"     (split-window)          t]
            ["Unsplit Window"   delete-other-windows    t]
            ))

If I do something like

        (setq global-popup-menu
        '("My Stuff"
            ["Kill buffer" kill-this-buffer t]
            ))

then enter a mode which has no popup menu defined (so that
`default-popup-menu' is appended to `global-popup-menu'), I get the error
message

        unrecognized menu descriptor: :filter

According to the `popup-menu' function description, :filter doesn't even
seem to be a valid keyword in the context of a popup menu.  In any event,
it doesn't seem to work, because if I set `global-popup-menu' to nil, I get
an unfiltered default menu.  The curious thing, in this case, is that no
error message is generated.

--
Mike Scheidler                     INTERNET:  c23mts@eng.delcoelect.com
Software Development Tools         UUCP:      deaes!c23mts
Delco Electronics Corporation      PHONE:     (317) 451-0319
Kokomo, IN 46904-9005              GMNET:     8-322-0319



From xemacs-beta-request@cs.uiuc.edu  Tue Jul 30 12:59:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA24733 for xemacs-beta-people; Tue, 30 Jul 1996 12:59:17 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA24730 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 30 Jul 1996 12:59:11 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA16089 for <xemacs-beta@xemacs.org>; Tue, 30 Jul 1996 12:59:08 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id LAA10107; Tue, 30 Jul 1996 11:59:10 -0600
Received: by suomi (SMI-8.6) id LAA13627; Tue, 30 Jul 1996 11:59:10 -0600
Date: Tue, 30 Jul 1996 11:59:10 -0600
Message-Id: <199607301759.LAA13627@suomi.cdc.noaa.gov>
From: Mark Borges <mdb@cdc.noaa.gov>
To: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: [19.14] feature lost from 19.13?
Organization: CIRES, University of Colorado
X-Attribution: mb

[ I'm posting this for a co-worker, who liked the following behaviour
  of XEmacs-19.13; personally, I don't care for it ]

In XEmacs-19.13, by default (i.e., `xemacs -q') one could load a file
containing a bunch of filenames, then invoke find-file ( \C-x \C-f,
without pressing return ). Subsequently, the mouse would automagically
highlight valid filenames when it passed over something that looked
like a filename in the buffer. Pressing the middle mouse button then
opens the highlighted file.

In XEmacs-19.14, this no longer works by default. Is there some option
that would enable it again?

I suspect this may have been related to the overzealous ange-ftp
behavior discussion a while back (where ange-ftp used to automatically
kick in whenever the mouse passed over something that looked like an
ange-ftp filename, I think). Did the elimination of that nasty
behaviour also remove the aforementioned `feature' as well?

I find the ffap package (find-file-at-point) to be more reliable, so
if this auto mouse magic is gone I can try to turn this colleague onto
it. But I thought I'd ask first to be certain.

Thanks,
-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Tue Jul 30 14:15:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA25055 for xemacs-beta-people; Tue, 30 Jul 1996 14:15:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA25049 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 30 Jul 1996 14:15:23 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA04471 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 14:15:22 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id OAA03788 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 14:14:33 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id OAA05631 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 14:14:32 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id PAA05908 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 15:14:34 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: switch-to-buffer-other-window annoyance
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 30 Jul 1996 15:10:34 -0400
Message-ID: <20403.838753834@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


-*- Mode: ranting-and-raving -*-

I suppose I'm the only one with this annoyance, but I truly, really,
honestly, passionately HATE how XEmacs 19.14 does this.  If I have two
frames up, one containing the buffer I want but it's on another
virtual screen (thanks to fvwm), and I press C-x 4 b to get that
buffer in the frame I'm looking at, focus disappears from the current
frame and goes to the hidden xemacs frame.  It looks like nothing has
happened except losing focus.  This is incredibly annoying.

I want that buffer in this frame, damn it!  If I had wanted it in the
other frame, I would have said so!

Of course, since this is xemacs, I can just hack up one line of
switch-to-buffer-other-window to do what I want, and I've done so, but
I find this truly annoying.

Sorry, just had to say that to someone.

Ray


From xemacs-beta-request@cs.uiuc.edu  Tue Jul 30 14:27:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA25080 for xemacs-beta-people; Tue, 30 Jul 1996 14:27:11 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA25077 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 30 Jul 1996 14:27:04 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA16480 for <xemacs-beta@xemacs.org>; Tue, 30 Jul 1996 14:27:03 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa11712;
          30 Jul 96 15:24 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id PAA22290; Tue, 30 Jul 1996 15:24:06 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id PAA00724; Tue, 30 Jul 1996 15:24:05 -0400
Date: Tue, 30 Jul 1996 15:24:05 -0400
Message-Id: <199607301924.PAA00724@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
To: xemacs-beta@xemacs.org
Subject: prim/files.el: set-auto-mode syncage with Emacs 19.31
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Destroy nothing
X-WWW-Homepage: http://www.python.org/~bwarsaw


We sometimes use this at the top of our Python scripts:

#! /bin/env python

As it is in XEmacs 19.14, set-auto-mode won't pick it up but Emacs
19.31 does.  This may be a kludge, but all I did was sync up this one
little bit with Emacs 19.31.

-Barry

-------------------- snip snip --------------------
*** files.el	1996/07/30 19:18:29	1.1
--- files.el	1996/07/30 19:21:56
***************
*** 1207,1213 ****
  		       (save-excursion
  			 (goto-char (point-min))
! 			 (if (looking-at "#! *\\([^ \t\n]+\\)")
! 			     (buffer-substring (match-beginning 1)
! 					       (match-end 1))
                             "")))
  		      elt)
--- 1207,1213 ----
  		       (save-excursion
  			 (goto-char (point-min))
! 			 (if (looking-at "#![ \t]?\\([^ \t\n]*/bin/env[ \t]\\)?\\([^ \t\n]+\\)")
! 			     (buffer-substring (match-beginning 2)
! 					       (match-end 2))
                             "")))
  		      elt)

From xemacs-beta-request@cs.uiuc.edu  Tue Jul 30 14:49:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA25160 for xemacs-beta-people; Tue, 30 Jul 1996 14:49:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA25156 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 30 Jul 1996 14:49:06 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA05013 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 14:49:05 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa12020;
          30 Jul 96 15:42 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id PAA22986; Tue, 30 Jul 1996 15:42:00 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id PAA00869; Tue, 30 Jul 1996 15:42:00 -0400
Date: Tue, 30 Jul 1996 15:42:00 -0400
Message-Id: <199607301942.PAA00869@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: Raymond Toy <toy@rtp.ericsson.se>
Cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Re: switch-to-buffer-other-window annoyance
References: <20403.838753834@rtp.ericsson.se>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Remove specifics and convert to ambiguities
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "RT" == Raymond Toy <toy@rtp.ericsson.se> writes:

    RT> I want that buffer in this frame, damn it!  If I had wanted it
    RT> in the other frame, I would have said so!

Here here!

From xemacs-beta-request@cs.uiuc.edu  Tue Jul 30 15:26:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA25286 for xemacs-beta-people; Tue, 30 Jul 1996 15:26:27 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA25283 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 30 Jul 1996 15:26:26 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.202.102]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA05816 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 15:26:25 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id NAA19850; Tue, 30 Jul 1996 13:20:13 -0700
From: Dan Rich <drich@cisco.com>
Message-Id: <199607302020.NAA19850@sandman.cisco.com>
Subject: Re: switch-to-buffer-other-window annoyance
To: bwarsaw@cnri.reston.va.us
Date: Tue, 30 Jul 1996 13:20:13 -0700 (PDT)
Cc: toy@rtp.ericsson.se, xemacs-beta@cs.uiuc.edu
In-Reply-To: <199607301942.PAA00869@anthem.CNRI.Reston.Va.US> from "Barry A. Warsaw" at Jul 30, 96 03:42:00 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> >>>>> "RT" == Raymond Toy <toy@rtp.ericsson.se> writes:
> 
>     RT> I want that buffer in this frame, damn it!  If I had wanted it
>     RT> in the other frame, I would have said so!
> 
> Here here!

If you want real frustration, try doing this when you are using gnuattach.
If you have the buffer you have switched to visible on the display where
you are running the XEmacs process, it won't display the buffer if you run
C-x 4 B.  You have to first split the window, and then switch to the 
buffer.

There are a whole bunch of weird things in gnuattach though, such as VM not
filling in the message contents when you forward or "R"eply to a message.
This could be a supercite issue rather than VM, but it's really annoying....


From xemacs-beta-request@cs.uiuc.edu  Tue Jul 30 18:34:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA25853 for xemacs-beta-people; Tue, 30 Jul 1996 18:34:52 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA25850 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 30 Jul 1996 18:34:47 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA11063 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 18:34:49 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id QAA10798; Tue, 30 Jul 1996 16:33:35 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA06437; Tue, 30 Jul 1996 16:33:32 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA03641; Tue, 30 Jul 1996 16:33:32 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA04307; Tue, 30 Jul 1996 16:33:28 -0700
Date: Tue, 30 Jul 1996 16:33:28 -0700
Message-Id: <199607302333.QAA04307@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Ben Wing <wing@666.com>
Cc: bwarsaw@cnri.reston.va.us, Dan Rich <drich@cisco.com>, toy@rtp.ericsson.se,
        xemacs-beta@cs.uiuc.edu
Subject: Re: switch-to-buffer-other-window annoyance
In-Reply-To: <199607302020.NAA19850@sandman.cisco.com>
References: <199607301942.PAA00869@anthem.CNRI.Reston.Va.US>
	<199607302020.NAA19850@sandman.cisco.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

Ben, lots of people, including here at Sun, are frustrated with this
change that I believe you are responsible for.  Please consider
undoing the change.

My guess is that the comment below explains the change.  Is it as
simple as putting (selected-frame) back in?

(defun switch-to-buffer-other-window (buffer)
  "Select buffer BUFFER in another window."
  (interactive "BSwitch to buffer in other window: ")
  (let ((pop-up-windows t))
    ;; XEmacs: this used to have (selected-frame) as the third argument,
    ;; but this is obnoxious.  If the user wants the buffer in a
    ;; different frame, then it should be this way.
    (pop-to-buffer buffer t)))


>>>>> "Dan" == Dan Rich <drich@cisco.com> writes:

>> >>>>> "RT" == Raymond Toy <toy@rtp.ericsson.se> writes:
>> 
RT> I want that buffer in this frame, damn it!  If I had wanted it
RT> in the other frame, I would have said so!
>> 
>> Here here!

Dan> If you want real frustration, try doing this when you are using gnuattach.
Dan> If you have the buffer you have switched to visible on the display where
Dan> you are running the XEmacs process, it won't display the buffer if you run
Dan> C-x 4 B.  You have to first split the window, and then switch to the 
Dan> buffer.

Dan> There are a whole bunch of weird things in gnuattach though, such as VM not
Dan> filling in the message contents when you forward or "R"eply to a message.
Dan> This could be a supercite issue rather than VM, but it's really annoying....



From xemacs-beta-request@cs.uiuc.edu  Tue Jul 30 19:38:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA26036 for xemacs-beta-people; Tue, 30 Jul 1996 19:38:09 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA26033 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 30 Jul 1996 19:38:08 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA11747 for <xemacs-beta@cs.uiuc.edu>; Tue, 30 Jul 1996 19:38:07 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id RAA00406; Tue, 30 Jul 1996 17:36:04 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: switch-to-buffer-other-window annoyance
References: <199607301942.PAA00869@anthem.CNRI.Reston.Va.US>
	<199607302020.NAA19850@sandman.cisco.com>
	<199607302333.QAA04307@xemacs.eng.sun.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Martin Buchholz's message of Tue, 30 Jul 1996 16:33:28 -0700
Mime-Version: 1.0 (generated by tm-edit 7.74)
Content-Type: text/plain; charset=US-ASCII
Date: 30 Jul 1996 17:36:03 -0700
Message-ID: <m2ivb5mf7w.fsf@deanna.miranova.com>
Lines: 121
X-Mailer: Gnus v5.2.38/XEmacs 19.14

This is related to a problem I reported in Mid May.

Date: Sun, 19 May 1996 01:23:01 GMT
Subject: Re: C-x 4 b focus warp bug
From: Ben Wing <wing@666.com>
Cc: xemacs-beta@cs.uiuc.edu

ben> OK, bring this up again after 19.14 is released and I'll look
ben> into it.  I don't want to change something like this so close to
ben> release.

To: xemacs-beta@cs.uiuc.edu
Subject: Re: C-x 4 b focus warp bug
From: Steven L Baur <steve@miranova.com>
Date: 15 May 1996 10:19:54 -0700
Message-ID: <m2loityhtx.fsf@deanna.miranova.com>

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

Ben> Steven L. Baur writes:

sb> I do not care for this kind of frame behavior.  Can it be turned off?
sb> Warping focus, especially with a virtual desktop, is *evil*.

 ...

sb> It's not from Kyle's code.  I use Gnus for mail (apologies to Kyle),
sb> but I can reproduce the problem with a naked XEmacs.

Ben> OK, here's an even easier way than what you've specified:

Ben> 1. Create a second frame
Ben> 2. In either frame, do (select-frame (next-frame))

Ben> Focus shifts to the other frame.

O.K.

Ben> Obviously this is a "feature" not a "bug", and this is longtime
Ben> XEmacs behavior.  There are a few questions, though --

I was afraid of that.  See below -- I first found and reported this
``feature'' (to the wrong person) last August.

Ben> 1. Is this behavior desirable?  If you're in explicit focus mode,
Ben>    it probably is.  In focus-follows-mouse mode, it's probably not.
Ben>    But how can you distinguish?  Maybe we need a variable combined
Ben>    with some approximate tests that try to query the window manager?
Ben>    I don't want to write this code, though.  Window managers suck
Ben>    more than the most powerful Hoover ever even dreamed of.

This is exactly why it is undesirable behavior.  My two examples show
how badly things go wrong when you change the environment.

I don't want XEmacs to work around this, nor should it be necessary.
To be precise here, though olvwm is not a perfect program, and the
relatively recent change to intercept M-q certainly sucks, it is a
very powerful and usable program and has served me quite well.

Ben> 2. It might be argued that this behavior in of itself is not problematic
Ben>    even though it violates the ICCCM (ediff warps the mouse, and that
Ben>    violates the ICCCM too, but nobody complains too much).  It might
Ben>    be argued that the problem lies in VM or GNUS, which is (by whatever
Ben>    it's doing) triggering incorrect calls to `select-frame'.

Please leave Gnus out of this.  Gnus doesn't deliberately trigger
anything like this or I would have complained bitterly a long time ago
(though as I recall, undesirable things did happen when selecting News
off of the toolbar, at least before the News icon drifted off into
oblivion somewhere beyond the bounds of the frame.  It's not Lars'
fault -- Gnus isn't ``frames-aware''.  Chalk up another negative side
effect of this feature).

For the record, I *did* complain bitterly about this almost a year
ago, the date indicates this would have been reported against XEmacs
19.12:

Date: Sat, 26 Aug 95 04:51:34 +0200
Message-Id: <9508260251.AA10116@sunscipw.cern.ch>
From: gnus-bug@ifi.uio.no (The Gnus Bugfixing Girls + Boys)
To: "Steven L. Baur" <steve@miranova.com>
In-Reply-To: "Steven L. Baur"'s message of Fri, 25 Aug 1995 19:36:42 -0700
Subject: Re: gnus-auto-select-first 0.99.12-18 

"Steven L. Baur" <steve@miranova.com> writes:
 ...
> 4.  The way multiple Frames appear to work is unacceptable, but it
> appears to have nothing to do with Gnus.  I hit q from an mh-e buffer,
> and that frame is left alone, an iconized frame pops up, clears and
> displays *scratch*.

Gnus is currently frame-unaware. This will probably change in the
future, but should exonerate it from this, at least...

 == End excerpted message ==

>> This is a serious bug, IMHO.  Focus should *never* be switched except
>> by explicit action of the user.  A command like C-x 4 b should never
>> cause actions to occur outside of the frame it was invoked from.

Ben> Well, XEmacs doesn't know about virtual screens so it's hard to fault
Ben> it for opening windows in different frames and expecting them to be
Ben> visible.  FSF Emacs does this, too.

I sure can fault it.  I've received death threats (tongue in cheek I
believe) when I was writing User Interface standards for TRW from
people who were quite opposed to mouse warping, and chording.  Focus
warping is worse; I believe my examples show why.

XEmacs shouldn't have to know about virtual screens.  It would be
doing The Right Thing nearly always if it didn't have this feature to
start with.

Repeating my original request, I respectfully request a way to turn
this misfeature off.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 31 07:46:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA01243 for xemacs-beta-people; Wed, 31 Jul 1996 07:46:36 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA01240 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 31 Jul 1996 07:46:35 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA29240 for <xemacs-beta@cs.uiuc.edu>; Wed, 31 Jul 1996 07:46:36 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id HAA22536; Wed, 31 Jul 1996 07:46:04 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id HAA11240; Wed, 31 Jul 1996 07:46:03 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id IAA14457; Wed, 31 Jul 1996 08:46:06 -0400
To: Martin Buchholz <mrb@eng.sun.com>
cc: xemacs-beta@cs.uiuc.edu
References: <199607301942.PAA00869@anthem.CNRI.Reston.Va.US> <199607302020.NAA19850@sandman.cisco.com>  <199607302333.QAA04307@xemacs.eng.sun.com> 
Subject: Re: switch-to-buffer-other-window annoyance 
In-reply-to: (Your message of Tue, 30 Jul 1996 16:33:28 PDT.)
             <199607302333.QAA04307@xemacs.eng.sun.com> 
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 31 Jul 1996 08:42:05 -0400
Message-ID: <21197.838816925@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Martin" == Martin Buchholz <mrb@Eng.Sun.COM> writes:


    Martin> Ben, lots of people, including here at Sun, are frustrated with this
    Martin> change that I believe you are responsible for.  Please consider
    Martin> undoing the change.

    Martin> My guess is that the comment below explains the change.  Is it as
    Martin> simple as putting (selected-frame) back in?

That's what I did.  Heaven!

Ray

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 31 07:46:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA01248 for xemacs-beta-people; Wed, 31 Jul 1996 07:46:41 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA01245 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 31 Jul 1996 07:46:39 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA29242 for <xemacs-beta@cs.uiuc.edu>; Wed, 31 Jul 1996 07:46:39 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id HAA22499; Wed, 31 Jul 1996 07:45:21 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id HAA11227; Wed, 31 Jul 1996 07:45:20 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id IAA14451; Wed, 31 Jul 1996 08:45:23 -0400
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
References: <199607301942.PAA00869@anthem.CNRI.Reston.Va.US> <199607302020.NAA19850@sandman.cisco.com> <199607302333.QAA04307@xemacs.eng.sun.com>  <m2ivb5mf7w.fsf@deanna.miranova.com> 
Subject: Re: switch-to-buffer-other-window annoyance 
In-reply-to: (Your message of 30 Jul 1996 17:36:03 PDT.)
             <m2ivb5mf7w.fsf@deanna.miranova.com> 
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 31 Jul 1996 08:41:22 -0400
Message-ID: <21191.838816882@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:


    Steven> This is related to a problem I reported in Mid May.

I think I either concurred with you then or had the same complaint at
some other time because my RCS logs of my xemacs startup says I fixed
it for myself, and, for some reason, took it out.

    Ben> 2. It might be argued that this behavior in of itself is not problematic
    Ben> even though it violates the ICCCM (ediff warps the mouse, and that
    Ben> violates the ICCCM too, but nobody complains too much).  It might

Actually, I woudl complain about this warping by ediff if I used it
more often.  I don't mind the warping when ediff brings up it's little
frame.  It is the right thing to do in this case.  What I hate is that
it doesn't warp the pointer back when I exit ediff.  Then I physically
HAVE to move the mouse back to my working frame.

When you're a touch typist, this is incredibly annoying.

Ray

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 31 07:41:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA01224 for xemacs-beta-people; Wed, 31 Jul 1996 07:41:35 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA01221 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 31 Jul 1996 07:41:34 -0500 (CDT)
Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA18002 for <xemacs-beta@xemacs.org>; Wed, 31 Jul 1996 07:41:31 -0500 (CDT)
Received: from djp-fornet.cern.ch (djp-fornet.cern.ch [137.138.36.141]) by server21.digital.fr (8.7.5/8.7) with SMTP id OAA15193 for <xemacs-beta@xemacs.org>; Wed, 31 Jul 1996 14:41:03 +0200 (MET DST)
Received: by djp-fornet.cern.ch; (5.65v3.2/1.1.8.2/29Apr96-0151PM)
	id AA20756; Wed, 31 Jul 1996 14:37:52 +0200
Date: Wed, 31 Jul 1996 14:37:52 +0200
Message-Id: <9607311237.AA20756@djp-fornet.cern.ch>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: --with-libdnet configuration option
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

I'd like the configure script to accept a "--with-libdnet" option.  This
would allow me to provide a "no" argument to prevent libdnet from being
autodetected, and loaded at run-time (libdnet_stub would be loaded
instead).  Having this feature would make it easier for me to generate
DECnet-free binary distribution kits on my system which has DECnet
installed.

I'm new to autoconf, but here's a patch that works:

*** configure.in.dist	Sat Jun 22 16:18:25 1996
--- configure.in	Wed Jul 31 13:56:15 1996
***************
*** 108,113 ****
--- 108,114 ----
  cflags='NO_CFLAGS_DEFINED'
  dynamic=''
  with_x11=''
+ with_libdnet=''
  rel_alloc='default'
  use_system_malloc='default'
  internal_makefile_list='Makefile lib-src/Makefile.in man/Makefile.in src/Makefile.in lwlib/Makefile.in dynodump/Makefile.in'
***************
*** 279,284 ****
--- 280,287 ----
  			to run.
  --usage-tracking	Enable some Sun-internal code.  If you don't
  			know what this is, you don't want it.
+ --with-libdnet (*)	Support DECnet if available.
+ --with-libnet=no	Don't support DECnet.
  
  
  Debugging options:
***************
*** 1324,1329 ****
--- 1327,1348 ----
  	  fi
          ;;
  
+         ## Has the user specified whether to use DECnet?
+         "with_libdnet" )
+ 	  ## Make sure the value given was either "yes" or "no".
+ 	  case "${val}" in
+ 	    y | ye | yes )	val=yes ;;
+ 	    n | no )		val=no  ;;
+ 	    * )
+ 	      (echo "${progname}: the \`--${optname}' option is supposed to have a boolean value.
+ Set it to either \`yes' or \`no'."
+ 	       echo "${short_usage}") >&2
+ 	      exit 1
+ 	    ;;
+ 	  esac
+ 	  eval "with_libdnet=\"${val}\""
+         ;;
+ 
          ## Fail on unrecognized arguments.
  	* )
  	  (echo "${progname}: Error: unrecognized option ${arg}"
***************
*** 2360,2365 ****
--- 2379,2385 ----
      decosf1-3		) opsys=decosf1-3-static ;;
      decosf3-1		) opsys=decosf3-1-static ;;
      decosf3-2		) opsys=decosf3-2-static ;;
+     decosf4-0		) opsys=decosf4-0-static ;;
      linux		) opsys=linux-static ;;
    esac
  fi
***************
*** 2984,2993 ****
  DEFS="${C_SWITCH_SITE} $c_switch_system $c_switch_machine $c_switch_x_system $DEFS"
  LIBS="${LD_SWITCH_SITE} $ld_switch_x_system $libsrc_libs $LIBS"
  
! dnl If found, this defines HAVE_LIBDNET, which m/pmax.h checks,
! dnl and also adds -ldnet to LIBS, which Autoconf uses for checks.
  dnl FSF 19.29 also checks for function dnet_ntoa.
! AC_HAVE_LIBRARY(-ldnet)
  dnl This causes -lresolv to get used in subsequent tests,
  dnl which causes failures on some systems such as HPUX 9.
  dnl FSF 19.29 also checks for function gethostbyname.
--- 3004,3020 ----
  DEFS="${C_SWITCH_SITE} $c_switch_system $c_switch_machine $c_switch_x_system $DEFS"
  LIBS="${LD_SWITCH_SITE} $ld_switch_x_system $libsrc_libs $LIBS"
  
! dnl If found, this defines HAVE_LIBDNET, which m/pmax.h and m/alpha.h
! dnl check, and also adds -ldnet to LIBS, which Autoconf uses for checks.
  dnl FSF 19.29 also checks for function dnet_ntoa.
! 
! case "${with_libdnet}" in
!   yes ) 
!         AC_HAVE_LIBRARY(-ldnet)
!         ;;
!   no )
! esac
! 
  dnl This causes -lresolv to get used in subsequent tests,
  dnl which causes failures on some systems such as HPUX 9.
  dnl FSF 19.29 also checks for function gethostbyname.


From xemacs-beta-request@cs.uiuc.edu  Wed Jul 31 08:16:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA01371 for xemacs-beta-people; Wed, 31 Jul 1996 08:16:10 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA01368 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 31 Jul 1996 08:16:09 -0500 (CDT)
Received: from maes.esrin.esa.it (maes.esrin.esa.it [192.106.252.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA04855 for <xemacs-beta@cs.uiuc.edu>; Wed, 31 Jul 1996 08:16:06 -0500 (CDT)
Received: from mail.esrin.esa.it (plod.esrin.esa.it) by maes.esrin.esa.it with SMTP id AA02943
  (5.65c/IDA-1.4.4 for <xemacs-beta@cs.uiuc.edu>); Wed, 31 Jul 1996 15:15:58 +0200
Received: from penelope.esa.it by mail.esrin.esa.it (4.1/SMI-4.1)
	id AA13782; Wed, 31 Jul 96 13:18:11 GMT
Date: Wed, 31 Jul 96 13:18:11 GMT
Message-Id: <9607311318.AA13782@mail.esrin.esa.it>
Received: by penelope.esa.it (4.1/SMI-4.1)
	id AA15074; Wed, 31 Jul 96 15:18:31 +0200
From: Simon Marshall <Simon.Marshall@esrin.esa.it>
To: XEmacs Beta <xemacs-beta@cs.uiuc.edu>
In-Reply-To: <21191.838816882@rtp.ericsson.se> (message from Raymond Toy on
	Wed, 31 Jul 1996 08:41:22 -0400)
Subject: Re: switch-to-buffer-other-window annoyance
Reply-To: Simon Marshall <Simon.Marshall@esrin.esa.it>

Ray> Actually, I woudl complain about this warping by ediff if I used it
Ray> more often.  I don't mind the warping when ediff brings up it's
Ray> little frame.  It is the right thing to do in this case.  What I hate
Ray> is that it doesn't warp the pointer back when I exit ediff.  Then I
Ray> physically HAVE to move the mouse back to my working frame.

Ray> When you're a touch typist, this is incredibly annoying.

I moaned to Michael following the original thread.  You can set
ediff-grab-mouse, which defaults to the warping behaviour.

------- Start of forwarded message -------
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: Simon Marshall <Simon.Marshall@esrin.esa.it>
Cc: XEmacs Discuss <xemacs-beta-discuss@cs.uiuc.edu>
Subject: Re: Ediff warp (Was: C-x 4 b focus warp bug) 
Date: Mon, 20 May 1996 11:26:35 -0400
Sender: kifer@cs.sunysb.edu

> Ben> 2. It might be argued that this behavior in of itself is not
> Ben> problematic even though it violates the ICCCM (ediff warps the mouse,
> Ben> and that violates the ICCCM too, but nobody complains too much).
> 
> SM> Well, that's the only thing that does bug me about Ediff, which is
> SM> otherwise great, but I haven't complained.
> 
> SM> Anyway, Michael, how come ediff-grab-mouse defaults to t?  I think it
> SM> would be better if it were nil.  What do you think?
> 
> MK> There was a brief period of time when ediff didn't warp the mouse.
> MK> You won't believe, but I got a good number of msgs from people who
> MK> couldn't figure out that they had to put the mouse in the small
> MK> window.
> 
> Actually, I sometimes accidentally type SPC in one of the diffed buffers
> and go ARGH!  Making Ediff warp doesn't really help here, since the warp
> happens after you type in the control window.
> 
> Just a thought---why not make the diffed windows be buffer-read-only with
> a local keymap where SPC is equivalent to SPC in the control window?  If a
> user genuinely wants to edit a diffed buffer, then there could be some
> mechanism to do recursive editing.  Then the differed buffers would behave
> like RMAIL, where you type `e' if you actually want to edit a message.

You can make the diffed buffers read-only via the hooks.

The problem with SPC having the same meaning as in the control window is
that the same buffer may be involved in two different active ediff sessions
(it's rare, but I do it sometimes). So, there is no way to find out which
active session and which control window to use.

One possibility is to set things up so that the first time you type
something in a diff'ed buffer, ediff could intercept the command and ask if
you really want to edit the buffer. However, I am not sure if this would be
a feature or an annoyance. I can't recall many times when I would
accidentally type into a diffed buffer. Usually this happens when the
pointer is *not* warped automatically into the control window.



	--michael  

------- End of forwarded message -------

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 31 09:37:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA01544 for xemacs-beta-people; Wed, 31 Jul 1996 09:37:59 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA01541 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 31 Jul 1996 09:37:58 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA05926 for <xemacs-beta@cs.uiuc.edu>; Wed, 31 Jul 1996 09:37:56 -0500 (CDT)
Received: from compserv1.cs.sunysb.edu (compserv1.cs.sunysb.edu [130.245.1.44]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id KAA07470 for <xemacs-beta@cs.uiuc.edu>; Wed, 31 Jul 1996 10:42:36 -0400
Message-Id: <199607311442.KAA07470@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host compserv1.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: xemacs-beta@cs.uiuc.edu
Subject: special-display-buffer-names bugs
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 31 Jul 1996 10:32:51 -0400
Sender: kifer@cs.sunysb.edu

There are couple of problems:

1. This var is not synched with 19.30 (don't be fooled by what the
   docstring says in 19.30/1 --- read the elisp manual).
   In 19.30/1 you can specify a separate function for each special buffer.

2. The XEmacs lisp manual refers to special-display-buffer-names as "see above"
    but it doesn't appear anywhere.
    


	--michael  

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 31 17:13:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA02995 for xemacs-beta-people; Wed, 31 Jul 1996 17:13:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA02992 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 31 Jul 1996 17:13:26 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA19055 for <xemacs-beta@xemacs.org>; Wed, 31 Jul 1996 17:13:22 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id PAA28196; Wed, 31 Jul 1996 15:12:51 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id PAA05151; Wed, 31 Jul 1996 15:12:44 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA22456; Wed, 31 Jul 1996 15:12:42 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA06125; Wed, 31 Jul 1996 15:12:38 -0700
Date: Wed, 31 Jul 1996 15:12:38 -0700
Message-Id: <199607312212.PAA06125@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
Cc: xemacs-beta@xemacs.org
Subject: prim/files.el: set-auto-mode syncage with Emacs 19.31
In-Reply-To: <199607301924.PAA00724@anthem.CNRI.Reston.Va.US>
References: <199607301924.PAA00724@anthem.CNRI.Reston.Va.US>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "BAW" == Barry A Warsaw <bwarsaw@cnri.reston.va.us> writes:

BAW> We sometimes use this at the top of our Python scripts:

BAW> #! /bin/env python

At first I thought this was a brilliant idea, to allow the creation of
portable scripts that don't depend on the location of the script
interpreter.  Of course all this is only necessary because Unix is
broken - it should be possible to have

#! python -some-flag -some-more-flags-longer-than-the-34-character-limit


But in retrospect, Barry's solution has 2 problems:
- can't specify flags (the token `python' *is* the "flag")
- too many machines (still) don't have /bin/env.

As a result, my current portability kludge for perl:

: # -*-Perl-*-
eval 'exec perl -w -S $0 ${1+"$@"}' # Portability kludge
    if 0;

is going to stay, although

#!/bin/env perl
BEGIN { $^W = 1; }

is somewhat more aesthetically pleasing.

I suggest that some similar bilingual portability hack be devised for
python scripts.

(ObXEmacs) I agree with Barry that XEmacs adopt the /bin/env patch.

(ObXEmacs) I recommend the perl portability kludge above for your perl
           scripts - note the method of specifiying the XEmacs major mode.
           This is surprisingly tricky to get right.

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 31 17:28:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA03030 for xemacs-beta-people; Wed, 31 Jul 1996 17:28:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA03027 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 31 Jul 1996 17:28:37 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA19072 for <xemacs-beta@xemacs.org>; Wed, 31 Jul 1996 17:28:33 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa17986;
          31 Jul 96 18:26 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id SAA27987; Wed, 31 Jul 1996 18:26:30 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id SAA00455; Wed, 31 Jul 1996 18:26:29 -0400
Date: Wed, 31 Jul 1996 18:26:29 -0400
Message-Id: <199607312226.SAA00455@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: xemacs-beta@xemacs.org
Cc: rms@prep.ai.mit.edu
Subject: Re: prim/files.el: set-auto-mode syncage with Emacs 19.31
References: <199607301924.PAA00724@anthem.CNRI.Reston.Va.US>
	<199607312212.PAA06125@xemacs.eng.sun.com>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Ghost echoes
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "MB" == Martin Buchholz <mrb@eng.sun.com> writes:

    MB> But in retrospect, Barry's solution has 2 problems: can't
    MB> specify flags (the token `python' *is* the "flag") too many
    MB> machines (still) don't have /bin/env.

Forget the fact that Python runs on many non-Unix machines, and so
making both hacks non-portable.  And aren't there Unixes that have the
env program in places other than /bin?

    MB> As a result, my current portability kludge for perl:

    | : # -*-Perl-*-
    | eval 'exec perl -w -S $0 ${1+"$@"}' # Portability kludge
    | if 0;

    MB> (ObXEmacs) I agree with Barry that XEmacs adopt the /bin/env
    MB> patch.

The real question is why the cars of the elements in
interpreter-mode-alist aren't just simple regexps?  Then if Emacs
didn't see -*- mode -*- in the first line, it would just run it
through these regexps and apply the appropriate major-mode.

Wouldn't that pick up both the quick-and-dirty /bin/env hack and
Martin's more proper `kludge'?  I figure if the word `python' appears
on the first line of the file, it's highly likely I want to edit in
python-mode, so the current definition of interpreter-mode-alist is
probably backwards compatible with my suggestion.

-Barry

From xemacs-beta-request@cs.uiuc.edu  Wed Jul 31 18:02:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA03108 for xemacs-beta-people; Wed, 31 Jul 1996 18:02:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA03105 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 31 Jul 1996 18:02:12 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA19151 for <xemacs-beta@xemacs.org>; Wed, 31 Jul 1996 18:02:08 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id QAA15840; Wed, 31 Jul 1996 16:01:32 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA14055; Wed, 31 Jul 1996 16:01:22 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA23760; Wed, 31 Jul 1996 16:01:21 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA06200; Wed, 31 Jul 1996 16:01:15 -0700
Date: Wed, 31 Jul 1996 16:01:15 -0700
Message-Id: <199607312301.QAA06200@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
Cc: xemacs-beta@xemacs.org, rms@prep.ai.mit.edu
Subject: Re: prim/files.el: set-auto-mode syncage with Emacs 19.31
In-Reply-To: <199607312226.SAA00455@anthem.CNRI.Reston.Va.US>
References: <199607301924.PAA00724@anthem.CNRI.Reston.Va.US>
	<199607312212.PAA06125@xemacs.eng.sun.com>
	<199607312226.SAA00455@anthem.CNRI.Reston.Va.US>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "BAW" == Barry A Warsaw <bwarsaw@anthem.cnri.reston.va.us> writes:

BAW> Forget the fact that Python runs on many non-Unix machines, and so
BAW> making both hacks non-portable.  And aren't there Unixes that have the
BAW> env program in places other than /bin?

Right - I should have been clearer.  The biggest problem with the
/bin/env hack is that the requirement to specify the exact pathname of
the real interpreter program is replaced with the requirement to
specify the exact pathname of the `env' command - this wins, but
not enough to be called portable, even on Unix.

ObRMS:  It loses on spiff.gnu.ai.mit.edu .

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Aug  1 05:47:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA08151 for xemacs-beta-people; Thu, 1 Aug 1996 05:47:18 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA08148 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 1 Aug 1996 05:47:17 -0500 (CDT)
Received: from pallas.spacetec.no (pallas.spacetec.no [192.51.5.92]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA19785 for <xemacs-beta@xemacs.org>; Thu, 1 Aug 1996 05:47:10 -0500 (CDT)
Received: (from tor@localhost) by pallas.spacetec.no (8.7.1/8.7.1) id MAA08995 for xemacs-beta@xemacs.org; Thu, 1 Aug 1996 12:47:09 +0200
Message-Id: <199608011047.MAA08995@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Thu, 1 Aug 1996 12:47:08 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: xemacs-beta@xemacs.org
Subject: IRIX 6.2

Hi guys,

Note that when we added the recommended patches for IRIX 6.2 then suddenly
XEmacs coredumped immediately (my self-compiled one, I haven't tested the
precompiled one but I suspect the problem will be there too).

The 'old' behaviour (for IRIX 6.2 with no patches) was that a 5.3-compiled
XEmacs would crash on 6.2 and vice versa.  After the patches were added
(recommended patches as of July 1) then the behaviour was reversed, i.e.
a 5.3-compiled XEmacs runs fine on IRIX 6.2 whereas the previously compiled
version for 6.2 crashed.
A recompile of XEmacs on 6.2 fixed things.  I suspect that this version now
runs on 5.3 as well, although I haven't been able to test this.

Just note that the precompiled XEmacs for IRIX 6.2 *may* not work for people
after they add the IRIX patchkit, maybe a note should be added that they
should then grab the 5.3 one (which should then work), or (arrgh) *another*
6.2 compiled one should be put on ftp.xemacs.org. 
What a mess..

(seems to me like SGI changed some structures somewhere, although I haven't
 been able to find any clues yet in the changed header files).

Tor

From xemacs-beta-request@cs.uiuc.edu  Thu Aug  1 11:47:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA08888 for xemacs-beta-people; Thu, 1 Aug 1996 11:47:11 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA08885 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 1 Aug 1996 11:47:08 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.202.102]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA20414 for <xemacs-beta@xemacs.org>; Thu, 1 Aug 1996 11:47:05 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id JAA05124; Thu, 1 Aug 1996 09:46:25 -0700
From: Dan Rich <drich@cisco.com>
Message-Id: <199608011646.JAA05124@sandman.cisco.com>
Subject: Re: IRIX 6.2
To: tor@spacetec.no (Tor Arntsen)
Date: Thu, 1 Aug 1996 09:46:25 -0700 (PDT)
Cc: xemacs-beta@xemacs.org
In-Reply-To: <199608011047.MAA08995@pallas.spacetec.no> from "Tor Arntsen" at Aug 1, 96 12:47:08 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> Note that when we added the recommended patches for IRIX 6.2 then suddenly
> XEmacs coredumped immediately (my self-compiled one, I haven't tested the
> precompiled one but I suspect the problem will be there too).
> 
> (seems to me like SGI changed some structures somewhere, although I haven't
>  been able to find any clues yet in the changed header files).

What patches did you add?  I may not work there any more, but I still have
enough connections to find out what changed in the patches... :-)

I know the earlier crashes were due to changes in the shared libraries.


From xemacs-beta-request@cs.uiuc.edu  Thu Aug  1 11:56:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA08906 for xemacs-beta-people; Thu, 1 Aug 1996 11:56:18 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA08903 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 1 Aug 1996 11:56:17 -0500 (CDT)
Received: from chacal.noc.demon.net (chacal.demon.co.uk [158.152.1.32]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA20423 for <xemacs-beta@xemacs.org>; Thu, 1 Aug 1996 11:56:14 -0500 (CDT)
Received: by chacal.noc.demon.net with local (Exim 0.42 #3)
	id E0um12Z-0000Av-00; Thu, 1 Aug 1996 17:56:03 +0100
From: jrg@demon.net (James R Grinter)
Date: Thu, 1 Aug 1996 17:56:03 +0000
In-Reply-To: <199608011646.JAA05124@sandman.cisco.com>
       "Re: IRIX 6.2" (Aug  1, 17:52)
X-Subliminal: vitae summa brevis spem nos, vetat incohare longam
Organization: Demon Internet, Network Operations Centre
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Dan Rich <drich@cisco.com>, Tor Arntsen <tor@spacetec.no>
Subject: Re: IRIX 6.2
Cc: xemacs-beta@xemacs.org
Message-Id: <E0um12Z-0000Av-00@chacal.noc.demon.net>

On Thu 1 Aug, 1996, Dan Rich <drich@cisco.com> wrote:
>> (seems to me like SGI changed some structures somewhere, although I haven't
>>  been able to find any clues yet in the changed header files).
>
>What patches did you add?  I may not work there any more, but I still have
>enough connections to find out what changed in the patches... :-)

When I added some shared lib patches I had to redump the executable
(that was a 19.14). Could that be it?

-- jrg.

From xemacs-beta-request@cs.uiuc.edu  Thu Aug  1 15:12:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA09622 for xemacs-beta-people; Thu, 1 Aug 1996 15:12:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA09619 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 1 Aug 1996 15:12:02 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA18057 for <xemacs-beta@cs.uiuc.edu>; Thu, 1 Aug 1996 15:11:49 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id PAA17439 for <xemacs-beta@cs.uiuc.edu>; Thu, 1 Aug 1996 15:11:09 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id PAA00933 for <xemacs-beta@cs.uiuc.edu>; Thu, 1 Aug 1996 15:11:08 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id QAA02399 for <xemacs-beta@cs.uiuc.edu>; Thu, 1 Aug 1996 16:11:11 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Fix:  buffer list like buffer-menu
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 01 Aug 1996 16:07:12 -0400
Message-ID: <24215.838930032@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


A while back, shortly after the buffer menu got the option to sort the
buffer menu, I asked about doing the same for the regular buffer
list.  Heiko Muenkel set out some lisp to do that.  However, it wasn't
integrated with buffers-menu stuff.

Here is the change I made to buff-menu.el that sorts the buffers in
the same way that the buffers-menu sorts them.  Sorry, no patch, but
it only requires changing a few lines in list-buffers-internal in
buff-menu.el.  (If this has already been done, I apologize for doing
it again.)

Change the lines near 521 from

(defun list-buffers-internal (output &optional predicate)
  (let ((current (current-buffer))
        (buffers (buffer-list)))
    (save-excursion

to

(defun list-buffers-internal (output &optional predicate)
  (let ((current (current-buffer))
        (buffers (if buffers-menu-sort-function
		     (sort (buffer-list) buffers-menu-sort-function)
		   (buffer-list))))
    (save-excursion
 
I think this is the right thing, and it's been working fine for me.

Ray

From xemacs-beta-request@cs.uiuc.edu  Thu Aug  1 18:25:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA10518 for xemacs-beta-people; Thu, 1 Aug 1996 18:25:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA10515 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 1 Aug 1996 18:25:25 -0500 (CDT)
Received: from psilocin.gnu.ai.mit.edu (rms@psilocin.gnu.ai.mit.edu [128.52.46.62]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA20976 for <xemacs-beta@xemacs.org>; Thu, 1 Aug 1996 18:25:22 -0500 (CDT)
Received: by psilocin.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id TAA30776; Thu, 1 Aug 1996 19:25:13 -0400
Date: Thu, 1 Aug 1996 19:25:13 -0400
Message-Id: <199608012325.TAA30776@psilocin.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: bwarsaw@cnri.reston.va.us
CC: mrb@eng.sun.com, xemacs-beta@xemacs.org
In-reply-to: <199607312226.SAA00455@anthem.CNRI.Reston.Va.US>
	(bwarsaw@anthem.cnri.reston.va.us)
Subject: Re: prim/files.el: set-auto-mode syncage with Emacs 19.31

I don't understand what issue this discussion is about.

From xemacs-beta-request@cs.uiuc.edu  Fri Aug  2 06:04:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA15529 for xemacs-beta-people; Fri, 2 Aug 1996 06:04:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA15526 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 2 Aug 1996 06:04:00 -0500 (CDT)
Received: from pallas.spacetec.no (pallas.spacetec.no [192.51.5.92]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA21753 for <xemacs-beta@xemacs.org>; Fri, 2 Aug 1996 06:03:54 -0500 (CDT)
Received: (from tor@localhost) by pallas.spacetec.no (8.7.1/8.7.1) id MAA13734; Fri, 2 Aug 1996 12:27:12 +0200
Message-Id: <199608021027.MAA13734@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Fri, 2 Aug 1996 12:27:11 +0200
In-Reply-To: Dan Rich <drich@cisco.com>
       "Re: IRIX 6.2" (Aug  1, 17:46)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Dan Rich <drich@cisco.com>
Subject: Re: IRIX 6.2
Cc: xemacs-beta@xemacs.org

On Aug 1, 17:46, Dan Rich wrote:
>What patches did you add?  I may not work there any more, but I still have
>enough connections to find out what changed in the patches... :-)
>
>I know the earlier crashes were due to changes in the shared libraries.

Patch SG0001266: rld patch -- fixes LD_LIBRARY_PATH too long problem
Patch SG0001208: XFS 6.2 rollup patch
Patch SG0001228: XLV with selective assemble
Patch SG0001247: Irix 6.2 networking fixes for rpcbind, IP alias, TOS, etc.
Patch SG0001251: IRIX 6.2 libc changes for patch 1227 plus previous libc patch, 1167
Patch SG0001270: RQS (requickstart) can damage C++ libraries
Patch SG0001281: rmail security patch for 6.2
Patch SG0001287: mount command fixes for 6.2
Patch SG0001289: patch for libfpe
Patch SG0001295: Flashio retry fix
Patch SG0001310: ls hangs when accessing a directory for which permission is..
Patch SG0001345: f77 namelist read variable fix (and -g)
Patch SG0001364: IRIX 6.2 STREAMS Patch
Patch SG0001365: bug fix for libm43 scalb function
Patch SG0001366: IRIX 6.2 Networking Commands Patch
Patch SG0001389: 6.2 kernel rollup
Patch SG0001393: 6.2 NFS rollup, including Bulk Data Service 1.0 client side

I believe 1251 is the only one with libc changes:

>versions long | grep patch | agrep 'include|libc'
f 19956  3539 patchSG0001251.eoe_sw.irix_lib   lib/libc.so.1
f  9837  4017 patchSG0001251.eoe_sw.irix_lib m lib32/libc.so.1
f 18607     6 compiler_eoe.hdr.lib    usr/include/patchhdr.h
f 64112     5 patchSG0001389.eoe_sw.unix   usr/include/sys/cachectl.h
f 33864    31 patchSG0001389.eoe_sw.unix   usr/include/sys/signal.h
f 62038     6 patchSG0001389.eoe_sw.unix   usr/include/sys/swash.h
f 25772    31 patchSG0001389.eoe_sw.unix   usr/include/sys/syssgi.h
f 20061  4132 patchSG0001251.eoe_sw.irix_lib m usr/lib32/mips4/libc.so.1
f 37185  4723 patchSG0001251.eoe_sw64.lib   usr/lib64/mips3/libc.so.1
f 63957  4640 patchSG0001251.eoe_sw64.lib   usr/lib64/mips4/libc.so.1

Tor

From xemacs-beta-request@cs.uiuc.edu  Fri Aug  2 14:27:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA17709 for xemacs-beta-people; Fri, 2 Aug 1996 14:27:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA17706 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 2 Aug 1996 14:27:39 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA22955 for <xemacs-beta@xemacs.org>; Fri, 2 Aug 1996 14:27:31 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa12911;
          2 Aug 96 15:22 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id PAA10451; Fri, 2 Aug 1996 15:22:25 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id PAA02364; Fri, 2 Aug 1996 15:22:24 -0400
Date: Fri, 2 Aug 1996 15:22:24 -0400
Message-Id: <199608021922.PAA02364@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
To: georgn@canada.sun.com
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: deriving modes from cc-mode
References: <199607292229.SAA04882@detlev.canada.sun.com>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Make an exhaustive list of everything you might do and do the last thing on the list
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "GN" == Georg Nikodym <georgn@canada.sun.com> writes:

    GN> I'm attempting to derive a mode for ADL from cc-mode.

    GN> Anyway, I now have a skeletel ADL mode, but I having some
    GN> trouble figuring out how the cc-mode code determines what the
    GN> syntactic elements are.  I'm beginning to get a sinking
    GN> feeling that there's more hard-coded stuff in there than is
    GN> desirable (particularly WRT to commas).

You're probably right.

    GN> Has anybody been down this path, and are there any pearls of
    GN> wisdom that can be shared?

I've had to go down this path each time I've integrated a new langauge
into cc-mode.  Trust me, it was *much* worse way back when.  Each time
I do it I add just as much generalization and parameterization as
needed to wedge the new language in.  There's no easy way, but if you
do the work, I'd love to look at any generalizations you come up with
that make it easier to get your language supported (I may not add
adl-mode to cc-mode, but it should be easy enough for you to have a
rather simple add-on file).

-Barry

From xemacs-beta-request@cs.uiuc.edu  Sat Aug  3 05:29:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA24161 for xemacs-beta-people; Sat, 3 Aug 1996 05:29:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA24158 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 3 Aug 1996 05:29:28 -0500 (CDT)
Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA28505 for <xemacs-beta@cs.uiuc.edu>; Sat, 3 Aug 1996 05:29:32 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id DAA15715 for <xemacs-beta@cs.uiuc.edu>; Sat, 3 Aug 1996 03:29:27 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id DAA22401 for <xemacs-beta@cs.uiuc.edu>; Sat, 3 Aug 1996 03:29:20 -0700
Date: Sat, 3 Aug 1996 03:29:20 -0700
Message-Id: <199608031029.DAA22401@shellx.best.com>
From: Ben Wing <wing@666.com>
To: Martin Buchholz <mrb@eng.sun.com>
Subject: Re: switch-to-buffer-other-window annoyance
Cc: xemacs-beta@cs.uiuc.edu, toy@rtp.ericsson.se, Dan Rich <drich@cisco.com>,
        bwarsaw@cnri.reston.va.us
References: <199607301942.PAA00869@anthem.CNRI.Reston.Va.US>
    <199607302020.NAA19850@sandman.cisco.com>

When I made that change, it was because I was trying to set things up
so you could have different frames for different buffers if you didn't
like windows.  However, it looks like it's not working, so go ahead
and change it back ...  I bet that there's something more fundamental
that needs to be fixed up w.r.t. the whole buffer/window/frame selection
process.  My head's not much in Emacs these days, though ...

ben

From xemacs-beta-request@cs.uiuc.edu  Sat Aug  3 11:16:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA24637 for xemacs-beta-people; Sat, 3 Aug 1996 11:16:49 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA24634 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 3 Aug 1996 11:16:48 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA24094 for <xemacs-beta@xemacs.org>; Sat, 3 Aug 1996 11:16:45 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA22219 for <xemacs-beta@xemacs.org>; Sat, 3 Aug 1996 11:16:47 -0500 (CDT)
Message-Id: <199608031616.LAA22219@charles.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs status update
Date: Sat, 03 Aug 1996 11:16:46 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

Between recovering from the 19.14 release and being extremely busy at
work I've done basically nothing for over a month.  I finally get a
chance this weekend to do some serious catching up and the very first
thing which happens is the drive on my Linux box at home croaks.  An
hour later I found out that the father of one of the people I work
with has died and I now have to help cover for him.  My hell summer
just got worse.  I'm cursed.

I'm still going to try and dig partially out of my hole this weekend
but my hopes for 19.15 beta1 out within one more week may have just
been dashed.  Basically, if you don't see beta1 by the end of next
weekend you won't see it until the first week of September.  I will
guranteed have a lot more free time after the fall semester starts
here.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Aug  5 10:35:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA08740 for xemacs-beta-people; Mon, 5 Aug 1996 10:35:35 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA08737 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 5 Aug 1996 10:35:34 -0500 (CDT)
Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA26660 for <xemacs-beta@xemacs.org>; Mon, 5 Aug 1996 10:35:27 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA12968; Mon, 5 Aug 1996 08:32:35 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA29824; Mon, 5 Aug 1996 17:32:19 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/05Aug96-0453PM)
	id AA01306; Mon, 5 Aug 1996 17:19:31 +0200
Date: Mon, 5 Aug 1996 17:19:31 +0200
Message-Id: <9608051519.AA01306@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: regex.c patch
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

In XEmacs 19.15, will regex.c be synched up with the version in Emacs
19.32?  If it won't be synched up, then can the following patch be
applied to prevent dumps when searching complicated regexps under DUNIX?

*** src/regex.c.dist	Mon Apr 29 02:15:01 1996
--- src/regex.c	Mon Aug 05 16:32:35 1996
***************
*** 1042,1048 ****
     This is a variable only so users of regex can assign to it; we never
     change it ourselves.  */
  #if defined (MATCH_MAY_ALLOCATE)
! int re_max_failures = 200000;
  #else
  int re_max_failures = 2000;
  #endif
--- 1042,1050 ----
     This is a variable only so users of regex can assign to it; we never
     change it ourselves.  */
  #if defined (MATCH_MAY_ALLOCATE)
! /* 4400 was enough to cause a crash on Alpha OSF/1,
!    whose default stack limit is 2mb.  */
! int re_max_failures = 4000;
  #else
  int re_max_failures = 2000;
  #endif


From xemacs-beta-request@cs.uiuc.edu  Mon Aug  5 10:57:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA08785 for xemacs-beta-people; Mon, 5 Aug 1996 10:57:54 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA08782 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 5 Aug 1996 10:57:53 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA19219 for <xemacs-beta@cs.uiuc.edu>; Mon, 5 Aug 1996 10:57:53 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id KAA20330 for <xemacs-beta@cs.uiuc.edu>; Mon, 5 Aug 1996 10:57:22 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id KAA26905 for <xemacs-beta@cs.uiuc.edu>; Mon, 5 Aug 1996 10:57:20 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id LAA07175 for <xemacs-beta@cs.uiuc.edu>; Mon, 5 Aug 1996 11:57:23 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: 19.14 vs gdb on Solaris 2.4
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 05 Aug 1996 11:53:29 -0400
Message-ID: <28745.839260409@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


One of the users here noticed the following problem with running gdb
in 19.14.  This is on a Solaris 2.4 machine with xemacs 19.14 built by
me.  

M-x gdb on any executable.  Run it.  Pressing C-c C-c in the gdb
buffer doesn't send the C-c to the process.  The gdb buffer is
effectively hosed.

I don't think I've seen this bug before, but I've been running on
a Solaris 2.5 version for a long time now.

Hints?

Ray

From xemacs-beta-request@cs.uiuc.edu  Tue Aug  6 00:36:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA11228 for xemacs-beta-people; Tue, 6 Aug 1996 00:36:28 -0500 (CDT)
Received: from c.cs.uiuc.edu (c.cs.uiuc.edu [128.174.252.3]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA11225 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 6 Aug 1996 00:36:27 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by c.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA20905 for <xemacs-beta@cs.uiuc.edu>; Tue, 6 Aug 1996 00:36:27 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id WAA08371; Mon, 5 Aug 1996 22:32:36 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA00463; Mon, 5 Aug 1996 22:32:34 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (5.x/SMI-SVR4)
	id AA10561; Mon, 5 Aug 1996 22:32:33 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA20706; Mon, 5 Aug 1996 22:32:28 -0700
Date: Mon, 5 Aug 1996 22:32:28 -0700
Message-Id: <199608060532.WAA20706@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Steven L Baur <steve@miranova.com>
Cc: XEmacs Beta Test <xemacs-beta@cs.uiuc.edu>
Subject: (decode-coding-region) bug
Reply-To: Martin Buchholz <mrb@eng.sun.com>

The good news is that it's easy to reproduce the bug reported by Steve
Baur et al:

  (load "cyrillic")
  (load "cyrillic-hooks")
  (decode-coding-string "\xe1" 'koi8)

The bad news is that this crash is in the scary ccl code.  Some day
I'll have to figure this stuff out, but so far I've managed to avoid
learning ccl.  My source of funding cares about Japanese, not Russian
or Chinese (which use ccl).

So it may take a while to fix unless someone (perhaps a Russian?)
volunteers.

From xemacs-beta-request@cs.uiuc.edu  Tue Aug  6 10:35:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA16496 for xemacs-beta-people; Tue, 6 Aug 1996 10:35:36 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA16493 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 6 Aug 1996 10:35:35 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA06047 for <xemacs-beta@cs.uiuc.edu>; Tue, 6 Aug 1996 10:35:37 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id KAA27045 for <xemacs-beta@cs.uiuc.edu>; Tue, 6 Aug 1996 10:35:04 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id KAA10132 for <xemacs-beta@cs.uiuc.edu>; Tue, 6 Aug 1996 10:35:03 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id LAA23571 for <xemacs-beta@cs.uiuc.edu>; Tue, 6 Aug 1996 11:35:07 -0400
To: xemacs-beta@cs.uiuc.edu
References: <199607301942.PAA00869@anthem.CNRI.Reston.Va.US> <199607302020.NAA19850@sandman.cisco.com>  <199608031029.DAA22433@shellx.best.com> 
Subject: list-buffers.  Was Re: switch-to-buffer-other-window annoyance 
In-reply-to: (Your message of Sat, 03 Aug 1996 03:29:21 PDT.)
             <199608031029.DAA22433@shellx.best.com> 
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 06 Aug 1996 11:31:13 -0400
Message-ID: <540.839345473@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


Along the same lines as the switch-to-buffer-other-window annoyance,
list-buffers also has this annoying behavior:  it uses any frame that
already contains the buffer list.

My solution is to replace list-buffers with this piece of code, taken
from buff-menu.el.  (The important part is the selected-frame).

(defun list-buffers (&optional files-only)
  (interactive (list (if current-prefix-arg t nil)))
  (let ((pop-up-windows t))
    (display-buffer (list-buffers-noselect files-only) nil (selected-frame))))


Should display-buffer use the selected frame by default?  I suppose
that would break a lot of code, but I haven't looked.

Ray


From xemacs-beta-request@cs.uiuc.edu  Wed Aug  7 02:57:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA20221 for xemacs-beta-people; Wed, 7 Aug 1996 02:57:37 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA20218 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 7 Aug 1996 02:57:36 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA29850 for <xemacs-beta@cs.uiuc.edu>; Wed, 7 Aug 1996 02:57:08 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Wed, 7 Aug 1996 09:55:53 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id JAA07365; Wed, 7 Aug 1996 09:55:15 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id JAA25203;
          Wed, 7 Aug 1996 09:53:10 +0200
Date: Wed, 7 Aug 1996 09:53:10 +0200
Message-Id: <199608070753.JAA25203@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
To: Ben Wing <wing@666.com>
Cc: Martin Buchholz <mrb@eng.sun.com>, xemacs-beta@cs.uiuc.edu,
        toy@rtp.ericsson.se, Dan Rich <drich@cisco.com>,
        bwarsaw@cnri.reston.va.us
Subject: Re: switch-to-buffer-other-window annoyance
In-Reply-To: <199608031029.DAA22401@shellx.best.com>
References: <199607301942.PAA00869@anthem.CNRI.Reston.Va.US> <199607302020.NAA19850@sandman.cisco.com> <199608031029.DAA22401@shellx.best.com>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.76)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

    Ben> When I made that change, it was because I was trying to set
    Ben> things up so you could have different frames for different
    Ben> buffers if you didn't like windows.  However, it looks like
    Ben> it's not working, so go ahead and change it back ...  I bet
    Ben> that there's something more fundamental that needs to be
    Ben> fixed up w.r.t. the whole buffer/window/frame selection
    Ben> process.  My head's not much in Emacs these days, though ...

    Ben> ben

I think that in general a buffer should be displayed in the current
frame, because it's hard to search in every frame for a missing
buffer. It would be also fine, if one could attach a buffer or may be
also all buffers of one mode explicitly to a specific frame. But also
in this case there should be a simple way (maybe a prefix command like
`use-the-current-frame-for-the-next-command') to display a buffer in
the current frame.

-- 

Heiko Muenkel
muenkel@tnt.uni-hannover.de
<A href="http://www.tnt.uni-hannover.de/wiss/muenkel.html">M&uuml;nkel</A>
PGP-KeyID: 0x05CC063D

From xemacs-beta-request@cs.uiuc.edu  Wed Aug  7 10:08:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA24957 for xemacs-beta-people; Wed, 7 Aug 1996 10:08:10 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA24954 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 7 Aug 1996 10:08:09 -0500 (CDT)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA01268 for <xemacs-beta@xemacs.org>; Wed, 7 Aug 1996 10:06:48 -0500 (CDT)
Received: from fast.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id JAA21867; Wed, 7 Aug 1996 09:06:40 -0600
Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id JAA02074; Wed, 7 Aug 1996 09:06:36 -0600
Sender: eeide@fast.cs.utah.edu
To: xemacs-beta@xemacs.org
Subject: [Q] How to Test Clipped-ness of Last Line?
From: Eric Eide <eeide@cs.utah.edu>
Date: 07 Aug 1996 09:06:35 -0600
Message-ID: <ywrvievs078.fsf@fast.cs.utah.edu>
Lines: 16
X-Mailer: Gnus v5.2.25/XEmacs 19.14

[I posted this question to `comp.emacs.xemacs' last week but didn't receive any
responses --- so I thought I'd ask a more technical audience.]

Is it possible for an Emacs Lisp program to determine if the last line of a
window is clipped?  In particular, given that `scroll-on-clipped-lines' is
true, I want to determine whether or not XEmacs will recenter if point is moved
onto the last line of a window.

Thanks for any help ---

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Wed Aug  7 10:09:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA24968 for xemacs-beta-people; Wed, 7 Aug 1996 10:09:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA24965 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 7 Aug 1996 10:08:59 -0500 (CDT)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA01272 for <xemacs-beta@xemacs.org>; Wed, 7 Aug 1996 10:08:56 -0500 (CDT)
Received: from fast.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id JAA21927; Wed, 7 Aug 1996 09:08:59 -0600
Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id JAA02114; Wed, 7 Aug 1996 09:08:59 -0600
Sender: eeide@fast.cs.utah.edu
To: xemacs-beta@xemacs.org
Subject: [Q] Point <--> Pixel Coordinates
From: Eric Eide <eeide@cs.utah.edu>
Date: 07 Aug 1996 09:08:58 -0600
Message-ID: <ywru3ufs039.fsf@fast.cs.utah.edu>
Lines: 21
X-Mailer: Gnus v5.2.25/XEmacs 19.14

[Another question sent to `comp.emacs.xemacs' that didn't receive any replies.
Both this question and the previous one are relevant for a more XEmacs-savvy
`scroll-in-place'.]

In XEmacs 19.14, are there any general-purpose functions for converting between
buffer positions (i.e., (point)) and window-relative pixel coordinates?  I've
found `event-closest-point' and `event-window-{x,y}-pixel', but these functions
operate on mouse events.

Point<-->pixel conversions would be useful to me in order to update
"scroll-in-place" for the brave new world of variable line heights and
character widths.

Thanks ---

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Wed Aug  7 15:40:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA26317 for xemacs-beta-people; Wed, 7 Aug 1996 15:40:09 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA26314 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 7 Aug 1996 15:40:08 -0500 (CDT)
Received: from deanna.miranova.com (deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA17673 for <xemacs-beta@cs.uiuc.edu>; Wed, 7 Aug 1996 15:40:10 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id NAA00914; Wed, 7 Aug 1996 13:37:26 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: Michael Turok <mturok@bfm.com>
Subject: [Michael Turok <mturok@bfm.com>] XEmacs FAQ Q2.1.21: XEmacs frame freezing
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: multipart/mixed;
 boundary="Multipart_Wed_Aug__7_13:37:24_1996-1"
Content-Transfer-Encoding: 7bit
Date: 07 Aug 1996 13:37:24 -0700
Message-ID: <m291br53sr.fsf@deanna.miranova.com>
Lines: 69
X-Mailer: Gnus v5.2.39/XEmacs 19.14

--Multipart_Wed_Aug__7_13:37:24_1996-1
Content-Type: text/plain; charset=US-ASCII

Is this a possible explanation for the freezing?  I don't have any
Suns around to test on, but I have observed strange interactions
between XEmacs and /dev/audio wrt running out of DMA RAM in Linux 2.0.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

--Multipart_Wed_Aug__7_13:37:24_1996-1
Content-Type: message/rfc822

Date: Wed, 7 Aug 1996 14:52:44 -0400
From: Michael Turok <mturok@bfm.com>
Message-Id: <199608071852.OAA27148@dev16.bfm.com>
To: steve@miranova.com
Subject: XEmacs FAQ Q2.1.21: XEmacs frame freezing


Hi,

I am not posting this, b/c I am not in any way an xemacs expert, and
thought that maybe someone who was more familiar with internals might
have a clue about why this happens.

I just read the faq below about xemacs freezing.  I have encountered
this problem, and "get out" of the situation by doing a trace -p on
the xemacs process, Ctrl-c'ing the trace, and then doing a trace -p on
the xemacs process again.  Voila, xemacs is no longer frozen.  

When xemacs freezes like this on me, it seems that xemacs is trying
very hard to write to /dev/audio, and gets "stuck".  For some reason,
trace -p tickles the xemacs process.

As people can tell, I haven't looked at this very much, and have (not
proudly) zero familiarity with xemacs internals.

I am using xemacs 19.13, on a sparc5 running SunOS 4.1.4 and fvwm
version 1.24r as my window manager.

Later,
Michael

----------------------------% cut here %----------------------------

   Subject: Q2.1.21 Every so often the XEmacs frame freezes [new]

   This has been a widely reported problem with various versions of
   XEmacs through 19.14. Some users have reported that killing and
   restarting the window manager helps. For others it does not. Part of
   the problem is that this does not manifest itself on any of the
   systems of the primary developers. There is no known solution at
   present.




+--------------------------------------------------------------+
|Michael Turok                           email: mturok@bfm.com |
|Blackrock Financial Management, Inc.    phone: (212) 409-3593 |
|New York, NY                            fax  : (212) 754-5397 |
+--------------------------------------------------------------+


--Multipart_Wed_Aug__7_13:37:24_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Wed Aug  7 16:00:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA26354 for xemacs-beta-people; Wed, 7 Aug 1996 16:00:18 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA26351 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 7 Aug 1996 16:00:17 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.202.102]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA18007 for <xemacs-beta@cs.uiuc.edu>; Wed, 7 Aug 1996 16:00:21 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id NAA11215; Wed, 7 Aug 1996 13:58:35 -0700
Date: Wed, 7 Aug 1996 13:58:35 -0700
Message-Id: <199608072058.NAA11215@sandman.cisco.com>
From: Dan Rich <drich@cisco.com>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu, Michael Turok <mturok@bfm.com>
Subject: Re: [Michael Turok <mturok@bfm.com>] XEmacs FAQ Q2.1.21: XEmacs frame freezing
In-Reply-To: <m291br53sr.fsf@deanna.miranova.com>
References: <m291br53sr.fsf@deanna.miranova.com>
Reply-To: drich@cisco.com
X-Face: >>@YIrj6h(9FH@Qs_-ob2y~:HhB3<K:s^%ne_GjM`oNo3yFzbT'Kover1p6Qf|2_'8inv!W
 x^4ApmkH}yJ*clwm{;w(]]EV=YexeKB[\$G>j#fE)'04Kv^h\Yc+PG%t~'xXevX509R
X-Planation: X-Face can be viewed with "faces" or "xmail" (X11R5 contrib tape).
Mime-Version: 1.0 (generated by tm-edit 7.76)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

    Steven> Is this a possible explanation for the freezing?  I don't
    Steven> have any Suns around to test on, but I have observed
    Steven> strange interactions between XEmacs and /dev/audio wrt
    Steven> running out of DMA RAM in Linux 2.0.

This is a different problem (but I think I reported this one too once
upon a time). When the frames freeze, you will have some windows
working perfectly (all the ones that haven't been iconified), while
others are frozen.  In addition, frozen frames still function, it just
doesn't update the display.

The odd thing is, VM breaks out of the freeze whenever you get new
mail.  So, my latest way to unfreeze a frame is:
    1.	Switch to the frozen frame
    2.	Switch to the VM INBOX ('C-x C-b INBOX')
    3.	Get new mail, sending myself one if I don't have any ('g')
    4.	Now the frame will update and will continue to work fine until
      	I iconify it again.
Unfortunately, I haven't been able to figure out what it is that VM
does which fixes the problem.  Just calling (raise-frame) doesn't
appear to do the trick.

Any ideas?

-- 
Dan Rich <drich@cisco.com>  |	http://reality.sgi.com/drich/
Webmaster                   | "Danger, you haven't seen the last of me!" 
Cisco Systems, Inc.         |   "No, but the first of you turns my stomach!"
(408) 527-3195              |           -- The Firesign Theatre's Nick Danger

From xemacs-beta-request@cs.uiuc.edu  Thu Aug  8 13:08:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA04846 for xemacs-beta-people; Thu, 8 Aug 1996 13:08:50 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA04843 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 8 Aug 1996 13:08:49 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA19115 for <xemacs-beta@cs.uiuc.edu>; Thu, 8 Aug 1996 13:08:45 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA05129; Thu, 8 Aug 1996 11:06:31 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Using RedHat Linux RPM for breaking XEmacs 19.15 lisp into packages
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: text/plain; charset=US-ASCII
Date: 08 Aug 1996 11:06:31 -0700
Message-ID: <m2afw5hhso.fsf@deanna.miranova.com>
Lines: 22
X-Mailer: Gnus v5.2.39/XEmacs 19.14

I have some good news and some bad news ...

The good news is that the RedHat Linux RPM program will not only
support this, but is already being used for adding e-lisp packages to
RMS Emacs in RedHat Linux.

The bad news is that it is somewhat non-portable requiring various
non-standard support:

GNU cpio 2.4.2 (a standard cpio won't work)
libgz compression library (already distributed with libpng)
xgettext (the `standard' Openwindows version won't work)

I've placed tar.gz's of rpm and xgettext in:
	ftp://ftp.miranova.com/pub/xemacs/RPM/

Would someone on a non-Linux system care to try building it?
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Aug  8 15:39:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA05438 for xemacs-beta-people; Thu, 8 Aug 1996 15:39:39 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA05435 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 8 Aug 1996 15:39:06 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA22010 for <xemacs-beta@cs.uiuc.edu>; Thu, 8 Aug 1996 15:39:04 -0500 (CDT)
Received: from kramer (kramer [192.168.1.12]) by newman (8.6.12/8.6.9) with SMTP id NAA13964; Thu, 8 Aug 1996 13:37:36 -0700
Sender: wmperry@newman
Message-ID: <320A50AE.31D7@aventail.com>
Date: Thu, 08 Aug 1996 13:40:14 -0700
From: William Perry <wmperry@aventail.com>
Organization: Aventail, Inc.
X-Mailer: Mozilla 3.0b6 (X11; I; SunOS 5.5.1 i86pc)
MIME-Version: 1.0
To: Steven L Baur <steve@miranova.com>
CC: xemacs-beta@cs.uiuc.edu
Subject: Re: Using RedHat Linux RPM for breaking XEmacs 19.15 lisp into packages
References: <m2afw5hhso.fsf@deanna.miranova.com>
Content-Type: multipart/mixed; boundary="------------2DE325F32415"

This is a multi-part message in MIME format.

--------------2DE325F32415
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steven L Baur wrote:
> 
> I have some good news and some bad news ...
> 
> The good news is that the RedHat Linux RPM program will not only
> support this, but is already being used for adding e-lisp packages to
> RMS Emacs in RedHat Linux.

  Whoo-hoo.

> The bad news is that it is somewhat non-portable requiring various
> non-standard support:
> 
> GNU cpio 2.4.2 (a standard cpio won't work)
> libgz compression library (already distributed with libpng)
> xgettext (the `standard' Openwindows version won't work)
> 
> I've placed tar.gz's of rpm and xgettext in:
>         ftp://ftp.miranova.com/pub/xemacs/RPM/
> 
> Would someone on a non-Linux system care to try building it?

  Well whaddya know!  Serendipity.  I'm working on this right now.  I am
probably going to be using RPM as the installation backend for our
server product.  I've already got it compiling under solaris and have
been talking to erik troan about adding autoconf support.  I've also
removed all the dependencies on stupid things like GNU CPIO (and GNU
cp), and reliance on some behaviour of GNU cpio that isn't true on at
least solaris' version.

   I was planning on working on rpm.el sometime in the not-too distant
future.  Would be nice to be able to install our server from within
emacs. :)

  The newer versions of RPM have a fairly nice library interface
(woefully underdocumented, but what the heck, its free!).  Anybody else
out there interested in working on this with me?  I've added my batch of
patches - I haven't sent these off to erik yet though.

-Bill P.

--------------2DE325F32415
Content-Type: text/plain; charset=us-ascii; name="patches"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="patches"

*** /tmp/T0a0037L	Thu Aug  8 13:39:00 1996
--- ./build/myftw.c	Wed Aug  7 14:09:57 1996
***************
*** 168,174 ****
    if (descriptors <= 0)
      descriptors = 1;
  
!   dirs = (DIR **) __alloca (descriptors * sizeof (DIR *));
    i = descriptors;
    while (i-- > 0)
      dirs[i] = NULL;
--- 168,174 ----
    if (descriptors <= 0)
      descriptors = 1;
  
!   dirs = (DIR **) alloca (descriptors * sizeof (DIR *));
    i = descriptors;
    while (i-- > 0)
      dirs[i] = NULL;
*** /tmp/T0a0037L	Thu Aug  8 13:39:01 1996
--- ./build/spec.c	Wed Aug  7 14:13:45 1996
***************
*** 783,789 ****
--- 783,793 ----
      }
      
      appendLineStringBuf(package->doc, "mkdir -p $DOCDIR");
+ #ifdef HAVE_GNU_CP
      appendStringBuf(package->doc, "cp -ar ");
+ #else
+     appendStringBuf(package->doc, "cp -pr ");
+ #endif
      appendStringBuf(package->doc, line);
      appendLineStringBuf(package->doc, " $DOCDIR");
  }
*** /tmp/T0a0037L	Thu Aug  8 13:39:01 1996
--- ./ftp.c	Wed Aug  7 14:03:13 1996
***************
*** 1,4 ****
--- 1,6 ----
  #include <netinet/in.h>
+ #include <arpa/inet.h>
+ #include <sys/socket.h>
  #include <alloca.h>
  #include <arpa/inet.h>
  #include <ctype.h>
***************
*** 142,150 ****
      struct hostent * hostinfo;
  
      if (isdigit(host[0])) {
!       if (!inet_aton(host, address)) {
! 	  return FTPERR_BAD_HOST_ADDR;
        }
      } else {
        hostinfo = gethostbyname(host);
        if (!hostinfo) {
--- 144,156 ----
      struct hostent * hostinfo;
  
      if (isdigit(host[0])) {
!       unsigned long int numeric_addr;
! 
!       numeric_addr = inet_addr (host);
!       if (numeric_addr == (unsigned long int) -1) {
! 	return FTPERR_BAD_HOST_ADDR;
        }
+       address->s_addr = numeric_addr;
      } else {
        hostinfo = gethostbyname(host);
        if (!hostinfo) {
***************
*** 309,315 ****
  	if (*chptr == ',') *chptr = '.';
      }
  
!     if (!inet_aton(passReply, &dataAddress.sin_addr)) 
  	return FTPERR_PASSIVE_ERROR;
  
      dataSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
--- 315,321 ----
  	if (*chptr == ',') *chptr = '.';
      }
  
!     if (getHostAddress(passReply, &dataAddress.sin_addr))
  	return FTPERR_PASSIVE_ERROR;
  
      dataSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
*** /tmp/T0a0037L	Thu Aug  8 13:39:01 1996
--- ./lib/header.c	Wed Aug  7 14:14:43 1996
***************
*** 8,14 ****
--- 8,16 ----
  /* network byte order and is converted on the fly to host order. */
  
  #include <stdlib.h>
+ #ifdef __linux__
  #include <asm/byteorder.h>
+ #endif
  #include <ctype.h>
  #include <malloc.h>
  #include <string.h>
*** /tmp/T0a0037L	Thu Aug  8 13:39:01 1996
--- ./lib/install.c	Thu Aug  8 08:15:45 1996
***************
*** 12,17 ****
--- 12,18 ----
  #include <time.h>
  #include <unistd.h>
  #include <zlib.h>
+ #include <stdio.h>
  
  #include "header.h"
  #include "install.h"
***************
*** 527,532 ****
--- 528,534 ----
      args = alloca(sizeof(char *) * (fileCount + 10));
  
      args[i++] = "cpio";
+ #ifdef HAVE_GNU_CPIO
      args[i++] = "--extract";
      args[i++] = "--unconditional";
      args[i++] = "--preserve-modification-time";
***************
*** 535,541 ****
--- 537,561 ----
  
      if (needSecondPipe)
  	args[i++] = "--verbose";
+ #else
+     /* The standard old CPIO way (the way god intended :) */
+     args[i++] = "-i"; /* --extract                        */
+     args[i++] = "-u"; /* --unconditional	          */
+     args[i++] = "-m"; /* --preserve-modification-time     */
+     args[i++] = "-d"; /* --make-directories               */
  
+     /*
+     ** There is apparently no equivalent to --quiet, but
+     ** the code further down is robust enough to not care
+     ** if it cannot find an installing file that gets spit
+     ** out in stdout/stderr.  Unless someone has a file
+     ** named '2864 blocks'.
+     */
+     
+     if (needSecondPipe)
+       args[i++] = "-v"; /* --verbose */
+ #endif
+ 
      /* note - if fileCount == 0, all files get installed */
      /* if fileCount > 500, we use a temporary file to pass the file
         list to cpio rather then args because we're in danger of passing
***************
*** 571,577 ****
--- 591,601 ----
  
  	fclose(f);
  
+ #ifdef HAVE_GNU_CPIO
  	args[i++] = "--pattern-file";
+ #else
+ 	args[i++] = "-E";
+ #endif
  	args[i++] = filelist;
      } else {
  	filelist = NULL;
***************
*** 603,612 ****
  	close(p[0]);
  
  	if (needSecondPipe) {
! 	    close(statusPipe[0]);   /* we don't need to read from it*/
! 	    close(2);      	    /* stderr will go to a pipe instead */
! 	    dup2(statusPipe[1], 2);
! 	    close(statusPipe[1]);
  	}
  
  	execvp(args[0], args);
--- 627,647 ----
  	close(p[0]);
  
  	if (needSecondPipe) {
! 	  /*
! 	  ** ACK!  some versions of CPIO send file listings (-v) to stdout,
!  	  ** while others send them to stderr.  *sigh*  Be paranoid and just
!  	  ** handle both of them.  Also, I am anal about hardcoding in things
! 	  ** like 1 == stdout, etc. - WMP
! 	  */
! 
! 	  int stderr_fd = fileno(stderr);
! 	  int stdout_fd = fileno(stdout);
!  	  close(statusPipe[0]);   /* we don't need to read from it*/
!  	  close(stderr_fd);	  /* stderr/stdout will go to a pipe instead */
!  	  close(stdout_fd);
!  	  dup2(statusPipe[1], stderr_fd);
!  	  dup2(statusPipe[1], stdout_fd);
!  	  close(statusPipe[1]);
  	}
  
  	execvp(args[0], args);
***************
*** 636,641 ****
--- 671,692 ----
  	     kill(SIGTERM, child);
  	}
  
+  	/*
+  	** On systems that were not using GNU cpio, things would sit and
+  	** spin, because cpio does not die when it hits the end of its
+  	** archive, but waits for the next archive.  So the 'waitpid'
+  	** call above would never return non-zero.
+  	**
+  	** This just checks to see whether we read 0 bytes.  Perhaps
+  	** the best thing to do would be keep a count of the # of times
+  	** we consecutively read 0 bytes.
+  	*/
+ 	
+  	if (bytesRead == 0) {
+  	  childDead = 1;
+  	  kill(SIGTERM, child);
+  	}
+  
  	if (needSecondPipe) {
  	    bytes = read(statusPipe[0], line, sizeof(line));
  
*** /tmp/T0a0037L	Thu Aug  8 13:39:02 1996
--- ./lib/oldheader.c	Wed Aug  7 14:16:20 1996
***************
*** 1,4 ****
--- 1,6 ----
+ #ifdef __linux__
  #include <endian.h>
+ #endif
  #include <errno.h>
  #include <fcntl.h>
  #include <netinet/in.h>
*** /tmp/T0a0037L	Thu Aug  8 13:39:02 1996
--- ./lib/rpm_malloc.h	Wed Aug  7 14:50:27 1996
***************
*** 1,8 ****
  #ifndef H_RPM_MALLOC
  #define H_RPM_MALLOC
  
- #ifndef __linux__
- #error malloc definition needed for non Linux OS
- #endif
  
  #endif
--- 1,5 ----
*** /tmp/T0a0037L	Thu Aug  8 13:39:02 1996
--- ./lib/rpmdb.c	Wed Aug  7 16:09:54 1996
***************
*** 52,57 ****
--- 52,74 ----
      return doopen(prefix, &db, O_CREAT | O_RDWR, perms, 1);
  }
  
+ #ifndef HAVE_FLOCK
+ /* Emulate flock() on posix/sysv machines - gack */
+ #define LOCK_SH		1	/* shared lock */
+ #define LOCK_EX		2	/* exclusive lock */
+ #define LOCK_NB		4	/* don't block when locking */
+ #define LOCK_UN		8	/* unlock */
+ static int flock (int fd, int args) {
+   struct flock the_lock;
+   if (args & LOCK_EX) {
+     the_lock.l_type = F_RDLCK | F_WRLCK;
+   } else {
+     the_lock.l_type = F_UNLCK;
+   }
+   return (fcntl(fd,F_SETLK,&the_lock) != -1);
+ }
+ #endif
+ 
  static int doopen (char * prefix, rpmdb *rpmdbp, int mode, int perms, 
  	       int justcheck) {
      char * filename;
*** /tmp/T0a0037L	Thu Aug  8 13:39:02 1996
--- ./lib/signature.c	Wed Aug  7 14:38:28 1996
***************
*** 12,18 ****
--- 12,20 ----
  #include <unistd.h>
  #include <sys/wait.h>
  #include <sys/stat.h>
+ #ifdef __linux__
  #include <asm/byteorder.h>
+ #endif
  #include <fcntl.h>
  #include <strings.h>
  
***************
*** 177,182 ****
--- 179,197 ----
      return 0;
  }
  
+ #ifndef HAVE_SETENV
+ static int setenv(const char *name,const char *value,int overwrite) {
+   int len = strlen(name) + strlen(value) + 10;
+   char *x = (char *) malloc(len);
+  
+   memset(x,0,len);
+   sprintf(x,"%s=%s",name,value);
+   putenv(x);
+   free(x);
+   return(1);
+ }
+ #endif
+ 
  static int makePGPSignature(char *file, void **sig, int_32 *size,
  			    char *passPhrase)
  {

--------------2DE325F32415--


From xemacs-beta-request@cs.uiuc.edu  Fri Aug  9 02:59:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA07502 for xemacs-beta-people; Fri, 9 Aug 1996 02:59:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA07499 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 9 Aug 1996 02:59:39 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA09370 for <xemacs-beta@cs.uiuc.edu>; Fri, 9 Aug 1996 02:59:05 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Fri, 9 Aug 1996 09:58:20 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id JAA02706; Fri, 9 Aug 1996 09:57:50 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id JAA27783;
          Fri, 9 Aug 1996 09:55:43 +0200
Date: Fri, 9 Aug 1996 09:55:43 +0200
Message-Id: <199608090755.JAA27783@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
To: xemacs-beta@cs.uiuc.edu
Subject: X-Resource iconPixmap broken?
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.76)
Content-Type: text/plain; charset=US-ASCII

For the XEmacs 19.13 I can set the xemacs icon with the following line
in the resource file.

xemacs*iconPixmap: /home/muenkel/appl/Global/lib/bitmap/lemacs.bm

In the XEmacs 19.14 the same line and icon leeds to the following
error message:

Warning: No type converter registered for 'String' to 'Bitmap' conversion.
 
root-xemacs: X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  72 (X_PutImage)
  Serial number of failed request:  61
  Current serial number in output stream:  62


The same occurs, if I'm using one of the icons from the XEmacs 19.14
distribution. Is this a bug or has something changed?

-- 

Heiko Muenkel
muenkel@tnt.uni-hannover.de
<A href="http://www.tnt.uni-hannover.de/wiss/muenkel.html">M&uuml;nkel</A>
PGP-KeyID: 0x05CC063D

From xemacs-beta-request@cs.uiuc.edu  Fri Aug  9 04:27:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA11245 for xemacs-beta-people; Fri, 9 Aug 1996 04:27:15 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA11242 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 9 Aug 1996 04:27:14 -0500 (CDT)
Received: from gatekeeper.abs.alcatel.co.uk (firewall-user@gatekeeper.abs.alcatel.co.uk [194.34.58.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA10001 for <xemacs-beta@cs.uiuc.edu>; Fri, 9 Aug 1996 04:27:08 -0500 (CDT)
Received: from unknown(194.36.210.121) by gatekeeper.abs.alcatel.co.uk via smap (g3.0.3)
	id xma006636; Fri, 9 Aug 96 10:18:11 +0100
Received: from portia.uk.abs by rd.abs.alcatel.co.uk  (4.1/SMI-4.1)
	id AA14969; Fri, 9 Aug 96 10:25:02 BST
Received: by portia.uk.abs (5.x/SMI-SVR4)
	id AA16446; Fri, 9 Aug 1996 10:25:10 +0100
Date: Fri, 9 Aug 1996 10:25:10 +0100
Message-Id: <9608090925.AA16446@portia.uk.abs>
From: imac@rd.abs.alcatel.co.uk
To: William Perry <wmperry@aventail.com>
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: Using RedHat Linux RPM for breaking XEmacs 19.15 lisp into packages
In-Reply-To: <320A50AE.31D7@aventail.com>
References: <m2afw5hhso.fsf@deanna.miranova.com>
	<320A50AE.31D7@aventail.com>

William Perry writes:
 
 >   Well whaddya know!  Serendipity.  I'm working on this right now.  I am
 > probably going to be using RPM as the installation backend for our
 > server product.  I've already got it compiling under solaris and have
 > been talking to erik troan about adding autoconf support.  I've also
 > removed all the dependencies on stupid things like GNU CPIO (and GNU
 > cp), and reliance on some behaviour of GNU cpio that isn't true on at
 > least solaris' version.
 > 
 

Well I saw Steve's message and thought I'd give it a try, and then saw
Bill's and thought away we go. But I get load of errors trying 'make'
It doesn't seem to like the 'if' statements in the makefile.
This is Solaris 2.5. Is it my make or does the makefile need hacking ?

Anyway I'll let you know how I got on.

-- 
                       \|/
                      (o o)
+==================oOO-(_)-OOo==========================+
|If you don't care where you are, you can't be lost     |
|                                                       |
|_______________________________________________________|
| Ian MacKinnon               imac@rd.abs.alcatel.co.uk |
| (44) 171 293 1413                                     |
|_______________________________________________________|

From xemacs-beta-request@cs.uiuc.edu  Fri Aug  9 05:13:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA11336 for xemacs-beta-people; Fri, 9 Aug 1996 05:13:58 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA11333 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 9 Aug 1996 05:13:57 -0500 (CDT)
Received: from gatekeeper.abs.alcatel.co.uk (firewall-user@gatekeeper.abs.alcatel.co.uk [194.34.58.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA11956 for <xemacs-beta@cs.uiuc.edu>; Fri, 9 Aug 1996 05:13:56 -0500 (CDT)
Received: from unknown(194.36.210.121) by gatekeeper.abs.alcatel.co.uk via smap (g3.0.3)
	id xma006821; Fri, 9 Aug 96 11:05:24 +0100
Received: from portia.uk.abs by rd.abs.alcatel.co.uk  (4.1/SMI-4.1)
	id AA15250; Fri, 9 Aug 96 11:12:15 BST
Received: by portia.uk.abs (5.x/SMI-SVR4)
	id AA16695; Fri, 9 Aug 1996 11:12:23 +0100
Date: Fri, 9 Aug 1996 11:12:23 +0100
Message-Id: <9608091012.AA16695@portia.uk.abs>
From: imac@rd.abs.alcatel.co.uk
To: William Perry <wmperry@aventail.com>, Steven L Baur <steve@miranova.com>,
        xemacs-beta@cs.uiuc.edu
Subject: Re: Using RedHat Linux RPM for breaking XEmacs 19.15 lisp into packages
In-Reply-To: <9608090925.AA16446@portia.uk.abs>
References: <m2afw5hhso.fsf@deanna.miranova.com>
	<320A50AE.31D7@aventail.com>
	<9608090925.AA16446@portia.uk.abs>

imac@rd.abs.alcatel.co.uk writes:
 > William Perry writes:
 >  
 >  >   Well whaddya know!  Serendipity.  I'm working on this right now.  I am
 >  > probably going to be using RPM as the installation backend for our
 >  > server product.  I've already got it compiling under solaris and have
 >  > been talking to erik troan about adding autoconf support.  I've also
 >  > removed all the dependencies on stupid things like GNU CPIO (and GNU
 >  > cp), and reliance on some behaviour of GNU cpio that isn't true on at
 >  > least solaris' version.
 >  > 
 >  
 > 
 > Well I saw Steve's message and thought I'd give it a try, and then saw
 > Bill's and thought away we go. But I get load of errors trying 'make'
 > It doesn't seem to like the 'if' statements in the makefile.
 > This is Solaris 2.5. Is it my make or does the makefile need hacking ?
 > 
 > Anyway I'll let you know how I got on.
 > 
I downloaded GNU make and that solved the makefile probs, but now it
cant find db.h. Any clues ??

From xemacs-beta-request@cs.uiuc.edu  Fri Aug  9 08:23:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA11711 for xemacs-beta-people; Fri, 9 Aug 1996 08:23:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA11708 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 9 Aug 1996 08:23:47 -0500 (CDT)
Received: from monolith.spry.com (wmperry.oz.net [207.13.185.53]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA18913 for <xemacs-beta@cs.uiuc.edu>; Fri, 9 Aug 1996 08:23:21 -0500 (CDT)
Received: (from wmperry@localhost) by monolith.spry.com (8.7.4/8.7.3) id GAA04134; Fri, 9 Aug 1996 06:32:59 -0700
Date: Fri, 9 Aug 1996 06:32:59 -0700
Message-Id: <199608091332.GAA04134@monolith.spry.com>
From: William Perry <wmperry@aventail.com>
To: imac@rd.abs.alcatel.co.uk
Cc: William Perry <wmperry@aventail.com>, Steven L Baur <steve@miranova.com>,
        xemacs-beta@cs.uiuc.edu
Subject: Re: Using RedHat Linux RPM for breaking XEmacs 19.15 lisp into packages
In-Reply-To: <9608091012.AA16695@portia.uk.abs>
References: <m2afw5hhso.fsf@deanna.miranova.com>
	<320A50AE.31D7@aventail.com>
	<9608090925.AA16446@portia.uk.abs>
	<9608091012.AA16695@portia.uk.abs>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

imac@rd.abs.alcatel.co.uk writes:
>imac@rd.abs.alcatel.co.uk writes:
> > William Perry writes:
> > 
> > Well I saw Steve's message and thought I'd give it a try, and then saw
> > Bill's and thought away we go. But I get load of errors trying 'make'
> > It doesn't seem to like the 'if' statements in the makefile.
> > This is Solaris 2.5. Is it my make or does the makefile need hacking ?
> > 
> > Anyway I'll let you know how I got on.
> > 
>I downloaded GNU make and that solved the makefile probs, but now it
>cant find db.h. Any clues ??

  You also need berkeley db to compile it.  If anyone wants a binary kit
for solaris/x86 2.5, let me know.  :)

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Sat Aug 10 07:42:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA19168 for xemacs-beta-people; Sat, 10 Aug 1996 07:42:32 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA19165 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 10 Aug 1996 07:42:31 -0500 (CDT)
Received: from eik (eik.ii.uib.no [129.177.16.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA22936 for <xemacs-beta@cs.uiuc.edu>; Sat, 10 Aug 1996 07:42:05 -0500 (CDT)
Received: from due.ii.uib.no (due) by eik with SMTP id AA05964
  (5.67b/IDA-1.5 for xemacs-beta@cs.uiuc.edu); Sat, 10 Aug 1996 14:41:51 +0200
Received: by due.ii.uib.no; (5.65/1.1.8.2/08Jun94-0756AM)
	id AA12657; Sat, 10 Aug 1996 14:41:49 +0200
Sender: ketil@ii.uib.no
To: xemacs-beta@cs.uiuc.edu
Subject: Line breaking
From: Ketil Z Malde <ketil@ii.uib.no>
Date: 10 Aug 1996 14:41:48 +0200
In-Reply-To: Heiko Muenkel's message of Fri, 9 Aug 1996 09:55:43 +0200
Message-Id: <KETIL-egn3039zsj.fsf@due.ii.uib.no>
Lines: 52
X-Mailer: Gnus v5.2.25/XEmacs 19.14


Thinking a bit about the issue of line breaking, I think I find it a bit
unsatisfactory.  Let me elaborate:

I work on two terminal withs.  Naturally, I'd like to use as much of the
terminal as possible, so I regularly use fill-paragraph or some such, to
rewrap.  However this tends to get cumbersome when I switch a lot, and I
don't think it necessary.

The alternative is to have backslashed wrapping, which may happen in the
middle of words, and which makes editing heavy - I use C-e and C-a a
lot, for instance, and long lines make this cumbersome.

I suggest to have automatic wrapping as a _presentation_ of long lines,
without introducing any end-of-line characters in the actual file.  Is
this possible?

This could also alleviate another minor problem - I rewrap mail in Gnus
to longer line length, but if the message is a Mime QP coded one, I get
lots of "= " where there were originally a line break.  The way I
suggest, that would still look like a "=^J" or whatever in the actual
text, and the decode-QP function would work on that.

Comments (for instance) at the end of a line could be presented in the
usual way, but remain on one line in the actual file.

File:

  int i;  // this is a very long comment regarding i

Presentation:

  int i;  // this is a very long
         // comment regarding i

In LaTeX mode, for instance (which could do with some brushing up, if
you ask me), I'd like to see autowrapping of arrays, so that elements
too long get wrapped neatly:

   field one  & field two is very long and
           & needs to wrap around     & field three is also very long
                                      & and continues on the next line

(Hope this worked out neatly.  Using proportional font - ugh!)

Of course, pressing ENTER introduces a good, hard line break, just like
we're used to.

Is this anything to think about?

~kzm


From xemacs-beta-request@cs.uiuc.edu  Sat Aug 10 10:50:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA19697 for xemacs-beta-people; Sat, 10 Aug 1996 10:50:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA19694 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 10 Aug 1996 10:50:12 -0500 (CDT)
Received: from wmperry.oz.net (wmperry.oz.net [207.13.185.53]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA07016 for <xemacs-beta@xemacs.org>; Sat, 10 Aug 1996 10:49:49 -0500 (CDT)
Received: (from wmperry@localhost) by wmperry.oz.net (8.7.4/8.7.3) id IAA02066; Sat, 10 Aug 1996 08:59:30 -0700
Date: Sat, 10 Aug 1996 08:59:30 -0700
Message-Id: <199608101559.IAA02066@wmperry.oz.net>
From: William Perry <wmperry@aventail.com>
To: Eric Eide <eeide@cs.utah.edu>
Cc: xemacs-beta@xemacs.org
Subject: Re: [Q] Point <--> Pixel Coordinates
In-Reply-To: <ywru3ufs039.fsf@fast.cs.utah.edu>
References: <ywru3ufs039.fsf@fast.cs.utah.edu>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Eric Eide writes:

>[Another question sent to `comp.emacs.xemacs' that didn't receive any
>replies.  Both this question and the previous one are relevant for a more
>XEmacs-savvy `scroll-in-place'.]
>
>In XEmacs 19.14, are there any general-purpose functions for converting
>between buffer positions (i.e., (point)) and window-relative pixel
>coordinates?  I've found `event-closest-point' and
>`event-window-{x,y}-pixel', but these functions operate on mouse events.
>
>Point<-->pixel conversions would be useful to me in order to update
>"scroll-in-place" for the brave new world of variable line heights and
>character widths.

  This is something I would love to see in XEmacs 19.15 - I do not think I
will have time to work on it though.  *sigh*  It should be generalized to
give the pixel-width of any string, taking into account text properties and
such that are on the string.

  This is necessary for Emacs-W3, and would be real useful for a
wysiwig-ier sgml mode, and latex mode, or wordperfect.el, whatever. :)

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Sun Aug 11 20:36:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA27227 for xemacs-beta-people; Sun, 11 Aug 1996 20:36:36 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA27224 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 11 Aug 1996 20:36:35 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA08366 for <xemacs-beta@xemacs.org>; Sun, 11 Aug 1996 20:36:30 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA11841 for <xemacs-beta@xemacs.org>; Sun, 11 Aug 1996 20:36:35 -0500 (CDT)
Message-Id: <199608120136.UAA11841@charles.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: I'm back... almost
Date: Sun, 11 Aug 1996 20:36:35 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

I finally managed to sort through my entire email backlog (up to 1700
messages) and put it into some kind of order.  Of course, I still have
to do something with most of it :-)  I've got about two dozen people to
get added to the beta list and some other administrative stuff to get
done this week.  Then its on to new releases.

Martin has done quite a bit of Mule work.  That work will form 20.0
beta27 to be released on Sunday, August 18.  XEmacs 19.15 beta1 will
be released on Sunday, August 18, along with 20.0 beta28.  I have
decided against any kind of version skewing to put the 19.15 and 20.0
beta release numbers in sync for two reasons.  First, I anticipate
20.0 releases happening more often than 19.15 releases which would
require constant skipping of 19.15 beta numbers.  That would be very
confusing.  Second, it shouldn't be nearly as difficult to keep
straight whether 19.15 or 20.0 is being talked about in bug reports
when the skew is 27+ rather than 1.




			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Aug 13 10:34:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA10178 for xemacs-beta-people; Tue, 13 Aug 1996 10:34:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA10175 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 13 Aug 1996 10:34:29 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA11651 for <xemacs-beta@xemacs.org>; Tue, 13 Aug 1996 10:34:21 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA15884; Tue, 13 Aug 1996 10:34:16 -0500 (CDT)
Message-Id: <199608131534.KAA15884@charles.cs.uiuc.edu>
To: Eric Eide <eeide@cs.utah.edu>
cc: xemacs-beta@xemacs.org
Subject: Re: [comp.emacs.xemacs] [19.14] BUG: Unterminated String Results in "Internal Emacs Bug" 
In-reply-to: Your message of "13 Aug 1996 09:28:43 MDT."
             <ywr7mr3wbf8.fsf@fast.cs.utah.edu> 
Date: Tue, 13 Aug 1996 10:34:16 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Eric> [I posted the following message to `comp.emacs.xemacs', but
    Eric> I haven't seen the maintainers lurking there recently, so I
    Eric> am forwarding to `xemacs-beta@xemacs.org' as well.  Eric.]

The maintainers lurk, they just don't post much.  Your bug has been
filed.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Aug 13 10:28:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA10156 for xemacs-beta-people; Tue, 13 Aug 1996 10:28:53 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA10153 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 13 Aug 1996 10:28:52 -0500 (CDT)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA11643 for <xemacs-beta@xemacs.org>; Tue, 13 Aug 1996 10:28:48 -0500 (CDT)
Received: from fast.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id JAA16772; Tue, 13 Aug 1996 09:28:49 -0600
Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id JAA11995; Tue, 13 Aug 1996 09:28:44 -0600
Sender: eeide@fast.cs.utah.edu
To: xemacs-beta@xemacs.org
Subject: [comp.emacs.xemacs] [19.14] BUG: Unterminated String Results in "Internal Emacs Bug"
From: Eric Eide <eeide@cs.utah.edu>
Date: 13 Aug 1996 09:28:43 -0600
Message-ID: <ywr7mr3wbf8.fsf@fast.cs.utah.edu>
Lines: 28
X-Mailer: Gnus v5.2.25/XEmacs 19.14

[I posted the following message to `comp.emacs.xemacs', but I haven't seen the
maintainers lurking there recently, so I am forwarding to
`xemacs-beta@xemacs.org' as well.  Eric.]

------- Start of forwarded message -------
Newsgroups: comp.emacs.xemacs
Subject: [19.14] BUG: Unterminated String Results in "Internal Emacs Bug"
From: Eric Eide <eeide@cs.utah.edu>
Date: 13 Aug 1996 09:24:58 -0600
Message-ID: <ywr91bjwblh.fsf@fast.cs.utah.edu>
Organization: University of Utah Department of Computer Science

If one loads an Emacs Lisp file containing an unterminated string (e.g., "foo),
XEmacs 19.14 produces a warning like the following:

	End of stream: #<INTERNAL EMACS BUG (filedesc lstream) 0x40232580>

Sounds serious :-).  Perhaps a more useful error message would be in order.  I
do not know if the "Internal Emacs Bug" represents anything more serious than a
scanner failure.

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX
------- End of forwarded message -------

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 14 07:20:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA16963 for xemacs-beta-people; Wed, 14 Aug 1996 07:20:23 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA16957 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 14 Aug 1996 07:20:21 -0500 (CDT)
Received: from maes.esrin.esa.it (maes.esrin.esa.it [192.106.252.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA27737 for <xemacs-beta@cs.uiuc.edu>; Wed, 14 Aug 1996 07:20:19 -0500 (CDT)
Received: from mail.esrin.esa.it (plod.esrin.esa.it) by maes.esrin.esa.it with SMTP id AA12711
  (5.65c/IDA-1.4.4 for <xemacs-beta@cs.uiuc.edu>); Wed, 14 Aug 1996 14:20:32 +0200
Received: from penelope.esa.it by mail.esrin.esa.it (4.1/SMI-4.1)
	id AA19208; Wed, 14 Aug 96 12:22:37 GMT
Date: Wed, 14 Aug 96 12:22:37 GMT
Message-Id: <9608141222.AA19208@mail.esrin.esa.it>
Received: by penelope.esa.it (4.1/SMI-4.1)
	id AA07539; Wed, 14 Aug 96 14:23:06 +0200
From: Simon Marshall <Simon.Marshall@esrin.esa.it>
To: XEmacs Beta <xemacs-beta@cs.uiuc.edu>
Subject: Specifiers: a bug and a question.
X-Mailer: XEmacs 19.14 (RMail/Mail)
X-Zippy: Where's the Coke machine?  Tell me a joke!!
X-Spook: cracking FBI South Africa Rule Psix security
Reply-To: Simon Marshall <Simon.Marshall@esrin.esa.it>

Hi all,

As a bit of background, for a long time I've been toying with making it
easier for users to have finer control of face appearance in font-lock.el.
Ever since face-lock.el, which must mean 2+ years.  And rms has suggested
that it should of course be applicable to faces in general.  So lately
I've been been toying with the idea of messing around with XEmacs
specifiers, because they seem to be what is required.  I held off because
there have been plenty of other things to mess with, and I was hoping a
merge might happen and thus the merged emacs would have the XEmacs display
engine and thus specifiers, and I wouldn't have to do anything.

Anyway, I've started to see whether specifiers address the particular
circumstances that at least relate to font-lock.el.  Probably font-lock.el
is potentially the most demanding face user package around.

I want to be able to specify things like "I want the face to be red on a
colour display when the frame has a light background, and pink when the
frame has a dark background."  And things like "I want the face to be bold
on a monochrome display, or reverse-video if bold is no different to the
default face."  I'm not sure how I can make specifiers do this, and I need
a bit of help in understanding them.

1.  First the bug.  As I understand it, for set-specifier, HOW-TO-ADD
defaults `remove-tag-set-prepend'.  This means, according to
add-spec-to-specifier, something like "replace any exisiting spec matching
the tag set to be added."  However, for generic specifiers it seems to
replace all tag sets with the new tag set:

(let ((fubar (make-specifier 'generic)))
  (define-specifier-tag 'foo)
  (define-specifier-tag 'bar)
  (set-specifier fubar 1 nil '(bar))
  (set-specifier fubar 2 nil '(foo))
  fubar)
 => #<generic-specifier global=((foo) . 2) 0xa91>

which is the same as specifying HOW-TO-ADD of `remove-locale':

(let ((fubar (make-specifier 'generic)))
  (define-specifier-tag 'foo)
  (define-specifier-tag 'bar)
  (set-specifier fubar 1 nil '(bar) 'remove-locale)
  (set-specifier fubar 2 nil '(foo) 'remove-locale)
  fubar)
 => #<generic-specifier global=((foo) . 2) 0xb7d>

whereas I had expected (in this case because the tag sets are unique
anyway) the behaviour you get if you use `prepend':

(let ((fubar (make-specifier 'generic)))
  (define-specifier-tag 'foo)
  (define-specifier-tag 'bar)
  (set-specifier fubar 1 nil '(bar) 'prepend)
  (set-specifier fubar 2 nil '(foo) 'prepend)
  fubar)
 => #<generic-specifier global=(((foo) . 2) ((bar) . 1)) 0xaa3>

I'm making a wild guess that this is a bug in set-specifier; a HOW-TO-ADD
of `remove-tag-set-prepend' is incorrectly implemented as `remove-locale',
at least for generic specifiers.  Or am I missing something?

2.  I came across this is that I'm trying to understand what would happen
in XEmacs if multiple specifier tag sets match a query of the specifier.
I believe order is important, and I want to check this.

For example, in:

(let ((fubar (make-specifier 'color)))
  (define-specifier-tag 'light)
  (set-specifier fubar "red" 'global '(color light) 'prepend)
  (set-specifier fubar "pink" 'global '(color) 'prepend)
  (specifier-matching-instance fubar '(color light)))

I would expect to get "pink" because (color) is the first tag set to
match, since its tag set is a subset of (color light) given as arg to
specifier-matching-instance.  However, in:

(let ((fubar (make-specifier 'color)))
  (define-specifier-tag 'light)
  (set-specifier fubar "pink" 'global '(color) 'prepend)
  (set-specifier fubar "red" 'global '(color light) 'prepend)
  (specifier-matching-instance fubar '(color light)))

I would expect to get "red" because (color light) is now the first to
match, since its tag set is a subset of (color light) given as arg.
I can't test this because I get an error as I'm not allowed to do this for
a color or generic specifier.  (I can't find anyway of trying it, probably
only due to laziness.)

But I'm assuming that "match" means something like "find, within the
specifier, a tag set whose tags are members of the tag set given as arg to
specifier-matching-instance", and not the other way round or some other
interpretation.

Is that correct?  How can I try this?  Of course, if I'm wrong then the
value is always "red".  However, this would mean that a value for each
possible combination of tag sets must be added to the specifier, even if
the value is the same.  For more than 2 tags it would be excessive.

I've a followup question, but it depends on the answer to this.

Thanks, Simon.

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 14 09:42:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA17301 for xemacs-beta-people; Wed, 14 Aug 1996 09:42:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA17298 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 14 Aug 1996 09:42:07 -0500 (CDT)
Received: from teapot.netman.dk (teapot.netman.dk [193.88.72.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA13702 for <xemacs-beta@xemacs.org>; Wed, 14 Aug 1996 09:41:47 -0500 (CDT)
Received: (from tmadsen@localhost) by teapot.netman.dk (8.7.1/8.7.1) id QAA16461; Wed, 14 Aug 1996 16:41:18 +0200 (MET DST)
To: xemacs-beta@xemacs.org
Subject: [SHLIB] Next version delayed :-/
From: Tonny Madsen <Tonny.Madsen@netman.dk>
Date: 14 Aug 1996 16:41:18 +0200
Message-ID: <rrk9v2koz5.fsf@teapot.netman.dk>
Lines: 88
X-Mailer: Gnus v5.2.29/XEmacs 20.0

Hi'

I know I promised a new version of the SHLIB patches some time ago,
but I'm afraid I haven't had the chance the do anything sensible for
the last 3 weeks. I have spend all my time going on un-scheduled
business trips, being sick and generally catching up with the in-queue
due to the first two...

And now, for the next 4 weeks, I'll be on vacation in the States
(driving from Now Orleans to San Francisco!!!). So don't expect
anything new before October!

By then I hope I can supply this, though:

- a rework of symeval.h and symbols.c that include autoloadable
  variables (if you reference the variable, a elisp files or shared
  library is loaded), variables that can have different values
  depending on any other lisp variable (a generallization of the
  buffer-local and console-local stuff). [I'm not sure how this work is
  positioned compared to the specifier stuff that does something very
  similar.] The rework is a side-reward (more or less) of the slot code
  for slot-value and (setf slot-value).

- everywhere a symbol can be used for a function (e.g. in funcall and
  defun) (setf symbol) can be used (CL behaviour). This allow you to
  do the following

    (defun some-accessor-func (...) ...)
    (defun (setf some-accessor-func) (...) ...)

  Then the following will work as expected

    (setf (some-accessor-func ...) ...)

  [currently implemented as a special 'setf property, but could as
  well be a new member of the struct Lisp_Symbol; What do you think?]

- C structures do not need any special header fields to be objects -
  that is managed transparently my the LOBJECT-code.

- defclass should work to define elisp classes with single
  inheritance. [I still need to find the class precedence lists for
  the built-in classes of Emacs, such as buffer, extent,
  etc]. Accessor function will be defun's, not defmethods - that must
  wait for the implementation of defgeneric.

- the following CLOS functions will be defined and working:

    slot-value
    (setf slot-value)
    slot-boundp
    slot-makunbound
    slot-exists-p
    find-class
    (setf find-class)
    class-of
    object-list	(not really CLOS - what *is* the CLOS variant of this?)

- SHLIB will be implemented for sun and linux (I have the code from
  Tcl), though I won't be able to test this myself ;-/

- a first version of a CL argument parsing function, which should
  allow for CL argument syntax for both C and elisp (&optional, &rest,
  &key, &aux and &allow-other-keys). Don't worry, the code will be
  ignored completely for C and elisp functions that doesn't use any
  &-constructs. This should allow us to do some better CL compability

- SHLIB versions of the some of the smaller modules of Emacs, like the
  sound system (I hope somebody else can do the work for glyphs)

- and many other small changes.

Some of this already works in the Emacs I've used for this message
(and all my daily work), so I don't think I have introduced any
serious errors along the way (but do expect a few...).

I'm back a few hours again tomorrow (GMT+1), so if anybody want a diff
against 20.0-b26, I can send it to you then. But I can't help you with
any problems the next 4 weeks and the documentation is lousy - the few
places it exists at all!

Time to go home and pack the suitcases :->

/tonny
-- 
Tonny Madsen, NetMan a/s, Vandtaarnsvej 77, DK-2860 Soeborg, Denmark
E-mail: Tonny.Madsen@netman.dk 
Telephone: +45 39 66 40 20 Fax: +45 39 66 06 75

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 15 08:49:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA24048 for xemacs-beta-people; Thu, 15 Aug 1996 08:49:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA24045 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 15 Aug 1996 08:49:21 -0500 (CDT)
Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA16154 for <xemacs-beta@xemacs.org>; Thu, 15 Aug 1996 08:49:18 -0500 (CDT)
Received: from herr.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1)
	id AA28168; Thu, 15 Aug 96 15:48:41 +0200
Date: Thu, 15 Aug 96 15:48:41 +0200
Message-Id: <9608151348.AA28168@prosun.first.gmd.de>
Received: by herr.first.gmd.de (4.1/SMI-4.1)
	id AA04376; Thu, 15 Aug 96 15:48:41 +0200
From: Stephan Herrmann <sh@prosun.first.gmd.de>
To: xemacs-beta@xemacs.org
Subject: Problem with resetting faces

Hi

  (set-face-font some-face nil locale) 
resp.
  (set-specifier some-font-spec nil locale)

both give a very unexpected error-message when you are trying to reset
the font for a face-specifier: It states, that the _locale_ is invalid:
"Must be string, vector, or font-instance" <locale-value>

In fact this is just a misinterpretation of arguments. Of course the
problem is solved by looking at the comment of set-face-property,
which tells to use remove-face-property (instead of setting to nil),
but that is not, where you look in the first place.

Are there any objections against the following patch, which would
allow a nil value on set-face-font (and set-specifier with a
face-spec. as argument)?

Seems like this problem occured several times in custom elisp-code, so the
patch might increase portability?

stephan


*** prim/faces.el[1.0]  Thu Aug 15 15:44:11 1996
--- prim/faces.el       Thu Aug 15 15:23:54 1996
***************
*** 428,434 ****
  
  See `set-face-property' for more information."
    (interactive (face-interactive "font"))
!   (set-face-property face 'font font locale tag-set how-to-add))
  
  (defun face-foreground (face &optional locale tag-set exact-p)
    "Return the foreground of the given face, or nil if it is unspecified.
--- 428,436 ----
  
  See `set-face-property' for more information."
    (interactive (face-interactive "font"))
!   (if font 
!       (set-face-property face 'font font locale tag-set how-to-add)
!     (remove-face-property face 'font locale tag-set)))
  
  (defun face-foreground (face &optional locale tag-set exact-p)
    "Return the foreground of the given face, or nil if it is unspecified.


--------------------------------------------------------------------------
			  Stephan Herrmann
			  ----------------
	GMD-FIRST				   TU-Berlin
 Gesellschaft f. Mathematik			 FB Informatik
   u. Datenverarbeitung				Softwaretechnik 
     sh@first.gmd.de			    stephan@cs.tu-berlin.de
  Phone: ++49 30 6392 1870
--------------------------------------------------------------------------

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 15 12:17:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA24813 for xemacs-beta-people; Thu, 15 Aug 1996 12:17:17 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA24810 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 15 Aug 1996 12:17:16 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA16702 for <xemacs-beta@cs.uiuc.edu>; Thu, 15 Aug 1996 12:17:17 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.55 #1)
	id E0ur62l-0006B3-00; Thu, 15 Aug 1996 13:17:15 -0400
To: xemacs-beta@cs.uiuc.edu
Subject: patch for hpux9+
Mime-Version: 1.0 (generated by tm-edit 7.77)
Content-Type: text/plain; charset=US-ASCII
From: Neal Becker <neal@ctd.comsat.com>
Date: 15 Aug 1996 13:17:14 -0400
Message-ID: <u94tm4zhwl.fsf@neal.ctd.comsat.com>
Lines: 3
X-Mailer: Gnus v5.2.25/XEmacs 19.14

I have not seen even 1 crash in xemacs in weeks.  I am certain that
the strcat.c from GNU is needed on at least some hpux9 systems, so we
may as well make this patch on all hpux9 and hpux10 systems.

From xemacs-beta-request@cs.uiuc.edu  Fri Aug 16 09:03:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA01959 for xemacs-beta-people; Fri, 16 Aug 1996 09:03:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA01956 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 16 Aug 1996 09:03:06 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA20712; Fri, 16 Aug 1996 09:03:05 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Fri, 16 Aug 1996 16:02:51 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id QAA27970; Fri, 16 Aug 1996 16:02:26 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id QAA07047;
          Fri, 16 Aug 1996 16:00:15 +0200
Date: Fri, 16 Aug 1996 16:00:15 +0200
Message-Id: <199608161400.QAA07047@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
To: xemacs-beta@cs.uiuc.edu
CC: Chuck Thompson <cthomp@cs.uiuc.edu>
Subject: New version of hm--html-menus
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.76)
Content-Type: text/plain; charset=US-ASCII

I've put the latest version of my package hm--html-menus-5.0.tar.gz
in /pub/beta/incoming of xemacs.cs.uiuc.edu.

I've made some changes, so that it could be better coexist with the
psgml html mode:

1. The name of the mode has changed from html-mode to hm--html-mode.

2. There is a new minor mode called hm--html-minor-mode. With that
   it is possible to use a psgml html mode as the major mode and
   this package as the minor mode. This is usefull, if you don't
   know the semantic of every html element or the syntax of a special
   html link or if you want better support for inserting links or
   if you want to use html elements, which are not in a DTD file -
   or if you love my mode more than the one provided by the psgml
   mode, but miss some tags in my mode.

It is now also possible to insert links by drag and drop with the
mouse. For that a lisp package, which provides a general (emacs) 
internal drag and drop interface, is included in the package.

Please let me know, what you think about the new version, especially
from the minor mode.


Heiko


Here is the original announcement of the package:

-----------------------------------
Hello,

I've written a new version (5.0) of my html package for the XEmacs 
and the GNU Emacs 19. The name of the package is:

		 hm--html-menus-5.0.tar.gz

With this package it is very easy to write html pages for the World Wide 
Web (WWW). Eg: In most cases the user gets help to construct a specific 
link by examples or by a completition list with possible input strings.
It is also possible to insert links and images by just clicking on its
source and destination (drag and drop feature).

The biggest new features in this release are:
- drag and drop functions to insert links with the mouse
- a minor mode to extent other html modes like the psgml mode
- some new html tags, like the <applet> tags
- fixed some old html tags 
- the pulldown menu in the Emacs 19 is no longer a global menu
- the popup menus in the Emacs 19 are now much fastere 
- the name of the mode has changed from html-mode to hm--html-mode
- the package is longer based on the package of Marc Andreessen
Read the NEWS file to see news in detail...

You should find hm--html-menus-5.0.tar.gz on the following ftp server:
	sunsite.unc.edu in /pub/Linux/apps/editors/emacs/
	ftp.tnt.uni-hannover.de in /pub/editors/xemacs/contrib

It may take some time, before the package is copied by the ftp admins
from the incoming directories to the above listed directories.

There is also a html documentation about the package. You can find it on:
http://www.tnt.uni-hannover.de:80/data/info/www/tnt/soft/info/www/html-editors/hm--html-menus/overview.html

The package provides functions to insert the following stuff in html-pages:
1. Anchors:
	html link, info link, gopher link, file link;
	ftp link, news link, mail link, wais (direct) link,
	wais (gateway) link;
	proggate link, local proggate link, general link;
	link target;
2. Frame elements:
	full html frame with html, head, body, title, header and signature
	elements or only the single elements;
	link element;
	html 'created'- and 'changed'- comments;  
	the current date in the title; 
3. Structure elements:
	menu or list item, menu, unordered list, ordered list, directory list;
	description list, description title, description entry;
	new paragraph, new line, horizontal rule, table, table title, 
	table header, table row, table entry;
4. for formatting paragraphs:
	without links, with links, blockquote, listing, abstract;
5. formatting:
	bold, italic, underline, typewriter, strikethru, super and subscript,
	emphasized, strong, big,
	definition, keyboard, variable,	code, sample, citation,
	html comment;
6. include:
	top aligned image, middle aligned image, bottom aligned image,
	applet, parameter
7. forms:
	form;
	text, password, isindex, integer, float, date, url, scribble fields; 
	checkbox, radio, reset, image, audio and submit buttons;
	option menus, scrolled lists and option entries;
	textarea;
8. entities:
	most of the special ISO- characters, less, greater and ampersand;

If it makes sense, the functions worked also on selected regions.
I've used the same menu items and the same keystrokes. Therefore, you
don't need to learn different menus or keys for similar functions.

You can choose the popup menus between an expert menu and an novice
menu interactively.

With the pulldown menu, you can do the following things:
- select the pulldown menu
- remove numeric names
- quotify hrefs
- reload the config files
- load html templates from a template directory (two templates are included
  in the package); templates written in a special template language are
  expanded automatically;
- preview html documents with the netscape
- preview html documents with the xmosaic
- preview html documents with the w3 package for the lemacs and emacs

You can insert links and images by clicking with Meta Button1 on its
source and then on its destination. For this drag and drop interface
the following destinations and links are supported:
- the inclusion of an GIF- or JPEG- image by clicking on its name
  in a dired buffer
- a file or relative link to any other file by clicking on its name
  in a dired buffer
- a file or relative link to a directory by clicking on a line without
  a filename in the dired buffer
- a file or relative link to a file by clicking in a buffer with this
  file
- a http or relative link to a html page by clicking in the w3 buffer, 
  which displays this page
- a http or relative link, which is in another html page by clicking 
  on the link in a w3 buffer
If there is an activated region in the source buffer, then the link
is inserted around it, so that the region is used as the name of the
link.

You can configure the html mode with a special configuration file for
your site and with another file specific for a user.

The html specification is under development and therefore this
package is also under development. So, if you have any ideas to
extend the package, feel free to email them to muenkel@tnt.uni-hannover.de.


Heiko

-- 

Heiko Muenkel
muenkel@tnt.uni-hannover.de
<A href="http://www.tnt.uni-hannover.de/wiss/muenkel.html">M&uuml;nkel</A>
PGP-KeyID: 0x05CC063D

From xemacs-beta-request@cs.uiuc.edu  Fri Aug 16 10:50:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA02307 for xemacs-beta-people; Fri, 16 Aug 1996 10:50:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA02304 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 16 Aug 1996 10:50:13 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA18481 for <xemacs-beta@xemacs.org>; Fri, 16 Aug 1996 10:50:10 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa09110;
          16 Aug 96 11:42 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id LAA12491; Fri, 16 Aug 1996 11:42:21 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id LAA05101; Fri, 16 Aug 1996 11:42:20 -0400
Date: Fri, 16 Aug 1996 11:42:20 -0400
Message-Id: <199608161542.LAA05101@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
To: xemacs-beta@xemacs.org
CC: fdrake@newcnri.cnri.reston.va.us
Subject: Serious bug in font-lock in 19.14
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Invert the figure and the ground
X-WWW-Homepage: http://www.python.org/~bwarsaw


It's been pretty clear to me for a while that font-lock in 19.14 is
quite a bit less stable than in 19.13.  I think I've posted some bug
reports before on this, as have others.  For example, occasionally
font-lock just stops fontifying the buffer.  This happens fairly
often, especially with large buffers, even though
font-lock-maximum-size is nil.  The workaround is to toggle
font-lock-mode off, then on again (e.g. I use revert-buffer since I
have a convenient keybinding for that).  font-lock-fontify-buffer does
*not* kick start font-lock when in this situation.

I've seen other, more insidious bugs with font-lock, where it just
gets confused and starts font-locking something as a comment or
string, even when the code is clearly outside a string or comment.
It's like font-lock is seriously confused and only a bizarre
combination of things can get it unconfused.

Thanks to a coworker of mine, I now have a reproducible test case for
y'all.  You will have to use python-mode.el since the code example is
Python code.  You can get the latest version of python-mode from:

    <http://www.python.org/ftp/emacs/>

Okay, so put the code sample given below in a file, say bug.py, and
visit it in python-mode, with font-lock turned on.  I use fast-lock,
but this shouldn't make a difference, as my coworker does not, and
I've seen the bug in both environments.  Oddly enough, you need the
entire code sample to show the bug; I haven't been able to boil it
down any farther.

Go to the line at the bottom of the file (`if not rater:').  Right
now, you should see the triple-quoted string just above font-locked as
string (font-lock-string-face), and in the method definition line
above that (`def __init__') the word `def' is font-lock-keyword-face,
and `__init__' is font-lock-function-name-face.  All is good.

Now, go to the end of the `if not rater:' line, this line should have
the `if' and `not' in font-lock-keyword-face.  Enter a space after the
colon and watch the line suddenly get put in font-lock-string-face!
Yikes!

If I do a font-lock-fontify-buffer it fixes the bogosity and all seems
fine again.  I can erase the space, and even enter new Python code
after that line and it all gets font-locked correctly.  But, if I edit
some text in the triple-quoted string, or if I hit return after the
last line then backspace back to the colon, once again the line gets
font-locked as a string.  To workaround the problem more permanently,
I can do the following.  Look for the open paren, in the triple-quoted
docstring.  It says: (SMI, SML, SMD).  Put a backslash in front of the
open paren.  Now go back to the last line and do some edits.  It stays
font-locked correctly, and I can't seem to get the bug to occur.
Removing the backslash causes the bug to happen as I've described.

I hope this will help you reproduce the bug.  Guess we're going to
have to escape all open parens in strings even if the *don't* start in
column zero.  It's strange that cutting out the code before the class
definition (`class Rated') stops the bug from happening even as I've
described.

-Barry

-------------------- snip snip --------------------bug.py
"""Implementation module for rate.d.
"""
__version__ = '$Revision: 1.7 $'

import os
import select
import socket
import string
import sys
import time
import traceback
import types

from ratedlib import *
from MetricStream import MetricStream
import Admin


#  State of the rate.d daemon.
#
INITIATING = 'initiating'		# collecting initial metrics
ACCEPTING = 'accepting'			# accepting RFS messages
CLOSING = 'closing'			# handling committed jobs only
CLOSED = 'closed'			# waiting for process exit


HIGH_WATER_MARK = 0			# SMI for high water mark metric
ACTIVE_JOB_COUNT = 1			# SMI for active job count

DEFAULT_EVENT_TIMEOUT = 5.0
DEFAULT_PENDING_TIMEOUT = 5.0
DEFAULT_COMMIT_TIMEOUT = 5.0

MAX_MSGLENGTH = 1024			# max receivable message size
MAX_RECENT_LENGTH = 100			# max number of recently committed jobs


_verbose = 1				# while we're debugging


class Rated:
    """Implementation of the rate.d daemon.

    Rated represents the 'application' -- the actual rate.d daemon
    process.  Exactly one of these should be created by the rate.d
    script.
    """

    _state = INITIATING

    _pendingTO = DEFAULT_PENDING_TIMEOUT	# default time outs, in seconds
    _committedTO = DEFAULT_COMMIT_TIMEOUT

    _max_rates = 100
    _maxHWM = None
    _cluster = gen_broadcast_address()
    _myhost = socket.gethostbyname(socket.gethostname())

    def __init__(self, ex_port = RATED_PORT, in_port = RATED_PORT + 1,
		 pr_port = RATED_PORT + 3,
		 monitor_addr = None, max_rates = None,
		 rater = None, apd_socket_name=None):
	"""Initializes internal data and communication ports.

	ex_port 
	    Port number for external communications.  All messages
	    from clients are directed to this port, and should be sent via
	    the socket bound to this port.  This port is a broadcast
	    target.  The same value should be supplied to each instance of
	    rate.d in the cluster.

	in_port
	    Port number for internal communications.  All messages to
	    and from the other servers in the cluster pass through this
	    port.  This port is broadcast-capable and a broadcast target.
	    The same value should be supplied to each instance of rate.d in
	    the cluster.

	pr_port
	    Port number for private internal communications.  This is only
	    used for administrative controls which don't need to be sent to
	    the entire DAXS but only to select hosts.

	max_rates
	    The maximum number of metrics values used to compute the average
	    recent value for that metric.  One value is used for all metrics.

	rater
	    The command to run to produce metric data.  This is the command
	    that represents the rater.d process.  The command should produce
	    sequences of (SMI, SML, SMD) triple on the standard output file.
	    This parameter must be supplied or a ValueError exception is
	    raised.

	apd_socket_name
	    Name of the UNIX-domain socket to make available to the application
	    protocol daemon.  Required.  The `Rated' instance is responsible
	    for creating and destroying the socket.
	"""
	if not rater:

From xemacs-beta-request@cs.uiuc.edu  Fri Aug 16 21:15:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA04026 for xemacs-beta-people; Fri, 16 Aug 1996 21:15:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA04021 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 16 Aug 1996 21:15:23 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA10195 for <xemacs-beta@cs.uiuc.edu>; Fri, 16 Aug 1996 21:15:25 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA12143; Fri, 16 Aug 1996 19:13:07 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: cthomp@xemacs.org, mrb@eng.sun.com
Subject: Re: I'm back... almost
References: <199608120136.UAA11841@charles.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Sun, 11 Aug 1996 20:36:35 -0500
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII
Date: 16 Aug 1996 19:13:06 -0700
Message-ID: <m220h6bvwt.fsf@deanna.miranova.com>
Lines: 24
X-Mailer: Gnus v5.2.39/XEmacs 19.14

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

Chuck> Martin has done quite a bit of Mule work.  That work will form
Chuck> 20.0 beta27 to be released on Sunday, August 18.  XEmacs 19.15
Chuck> beta1 will be released on Sunday, August 18, along with 20.0
Chuck> beta28.

I've uploaded compressed tar file replacements for psgml to
xemacs.org/pub/beta/incoming:
	psgml-1a11.etc.sgml.tar.gz
	psgml-1a11.elisp.tar.gz
which hopefully can be put into the next beta.

etc/sgml has a number of binary files that I can't make patch kits for
(and is rebuilt from the ground up anyway).  There are enough changes
between 1a9 and 1a11 that it seems easier to replace the directory.

This should fix the problems with validation in the distributed 19.14,
and also has miscellaneous other fixes and updates.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Fri Aug 16 21:21:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA04037 for xemacs-beta-people; Fri, 16 Aug 1996 21:21:53 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA04034 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 16 Aug 1996 21:21:52 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA10265 for <xemacs-beta@cs.uiuc.edu>; Fri, 16 Aug 1996 21:21:55 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA26503; Fri, 16 Aug 1996 21:21:51 -0500 (CDT)
Message-Id: <199608170221.VAA26503@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: I'm back... almost 
In-reply-to: Your message of "16 Aug 1996 19:13:06 PDT."
             <m220h6bvwt.fsf@deanna.miranova.com> 
Date: Fri, 16 Aug 1996 21:21:50 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Chuck> Martin has done quite a bit of Mule work.  That work will
    Chuck> form 20.0 beta27 to be released on Sunday, August 18.
    Chuck> XEmacs 19.15 beta1 will be released on Sunday, August 18,
    Chuck> along with 20.0 beta28.

I'm glad you quoted this.  That should have read "August 25" for the
19.15 beta1 / 20.0 beta28 release date.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Aug 17 21:51:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA10440 for xemacs-beta-people; Sat, 17 Aug 1996 21:51:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA10437 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 17 Aug 1996 21:51:43 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA10110 for <xemacs-beta@cs.uiuc.edu>; Sat, 17 Aug 1996 21:51:36 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA03510; Sat, 17 Aug 1996 19:49:13 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Patches for ps-print.el to sync up to 19.33 + bugfix
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Aug 1996 19:49:12 -0700
Message-ID: <m2vieho193.fsf@deanna.miranova.com>
Lines: 522
X-Mailer: Gnus v5.2.39/XEmacs 19.14

The following patch syncs up ps-print.el with the one distributed in
FSF Emacs 19.33.  There's also one `bug' fix.  The control character
comments put in the postscript prolog throw my postscript printer into
catatonia.  At least when I removed them, I was able to pretty print
buffers out of XEmacs again. :-)

I threw away the differences where the fsf code depended on the
variable pixel-components.  Hopefully that was the right thing to do.


*** ps-print.el-19.14	Sat Aug 17 11:47:36 1996
--- ps-print.el	Sat Aug 17 17:53:50 1996
***************
*** 1,8 ****
  ;;; ps-print.el --- Jim's Pretty-Good PostScript Generator for Emacs 19.
  
! ;; Copyright (C) 1993, 1994, 1995 Free Software Foundation, Inc.
  
  ;; Author: Jim Thompson <thompson@wg2.waii.com>
  ;; Keywords: print, PostScript
  
  ;; This file is part of XEmacs.
--- 1,9 ----
  ;;; ps-print.el --- Jim's Pretty-Good PostScript Generator for Emacs 19.
  
! ;; Copyright (C) 1993, 1994, 1995, 1996 Free Software Foundation, Inc.
  
  ;; Author: Jim Thompson <thompson@wg2.waii.com>
+ ;; Maintainer: duthen@cegelec-red.fr (Jacques Duthen Prestataire)
  ;; Keywords: print, PostScript
  
  ;; This file is part of XEmacs.
***************
*** 31,37 ****
  ;; version number.  When reporting bugs, please also report the
  ;; version of Emacs, if any, that ps-print was distributed with.)
  
! ;;; Synched up with: FSF 19.30.
  
  ;;; Commentary:
  
--- 32,38 ----
  ;; version number.  When reporting bugs, please also report the
  ;; version of Emacs, if any, that ps-print was distributed with.)
  
! ;;; Synched up with: FSF 19.33.
  
  ;;; Commentary:
  
***************
*** 85,91 ****
  ;; printout than to find 50 single-page printouts).
  ;; 
  ;; Ps-print has a hook in the kill-emacs-hooks so that you won't
! ;; accidently quit from Emacs while you have unprinted PostScript
  ;; waiting in the spool buffer.  If you do attempt to exit with
  ;; spooled PostScript, you'll be asked if you want to print it, and if
  ;; you decline, you'll be asked to confirm the exit; this is modeled
--- 86,92 ----
  ;; printout than to find 50 single-page printouts).
  ;; 
  ;; Ps-print has a hook in the kill-emacs-hooks so that you won't
! ;; accidentally quit from Emacs while you have unprinted PostScript
  ;; waiting in the spool buffer.  If you do attempt to exit with
  ;; spooled PostScript, you'll be asked if you want to print it, and if
  ;; you decline, you'll be asked to confirm the exit; this is modeled
***************
*** 200,206 ****
  ;; Ps-print keeps internal lists of which fonts are bold and which are
  ;; italic; these lists are built the first time you invoke ps-print.
  ;; For the sake of efficiency, the lists are built only once; the same
! ;; lists are referred in later invokations of ps-print.
  ;;
  ;; Because these lists are built only once, it's possible for them to
  ;; get out of sync, if a face changes, or if new faces are added.  To
--- 201,207 ----
  ;; Ps-print keeps internal lists of which fonts are bold and which are
  ;; italic; these lists are built the first time you invoke ps-print.
  ;; For the sake of efficiency, the lists are built only once; the same
! ;; lists are referred in later invocations of ps-print.
  ;;
  ;; Because these lists are built only once, it's possible for them to
  ;; get out of sync, if a face changes, or if new faces are added.  To
***************
*** 257,263 ****
  ;; or variables.  Functions are called, and should return a string to
  ;; show in the header.  Variables should contain strings to display in
  ;; the header.  In either case, function or variable, the PostScript
! ;; strings delimeters are added by ps-print, and should not be part of
  ;; the returned value.
  ;;
  ;; Here's an example: say we want the left header to display the text
--- 258,264 ----
  ;; or variables.  Functions are called, and should return a string to
  ;; show in the header.  Variables should contain strings to display in
  ;; the header.  In either case, function or variable, the PostScript
! ;; string delimeters are added by ps-print, and should not be part of
  ;; the returned value.
  ;;
  ;; Here's an example: say we want the left header to display the text
***************
*** 459,464 ****
--- 460,467 ----
  `ps-print-headers'.")
  
  ;;;###autoload
+ ;;; The 19.33 fsf version includes a test on pixel components instead
+ ;;;  of color-instance-rgb-components
  (defvar ps-print-color-p (and (or (fboundp 'x-color-values)	; fsf
  				  (fboundp 'color-instance-rgb-components))
  					; xemacs
***************
*** 608,616 ****
  ;;;###autoload
  (defun ps-print-buffer-with-faces (&optional filename)
    "Generate and print a PostScript image of the buffer.
- 
  Like `ps-print-buffer', but includes font, color, and underline
! information in the generated image."
    (interactive (list (ps-print-preprint current-prefix-arg)))
    (ps-generate (current-buffer) (point-min) (point-max)
  	       'ps-generate-postscript-with-faces)
--- 611,619 ----
  ;;;###autoload
  (defun ps-print-buffer-with-faces (&optional filename)
    "Generate and print a PostScript image of the buffer.
  Like `ps-print-buffer', but includes font, color, and underline
! information in the generated image.  This command works only if you
! are using a window system, so it has a way to determine color values."
    (interactive (list (ps-print-preprint current-prefix-arg)))
    (ps-generate (current-buffer) (point-min) (point-max)
  	       'ps-generate-postscript-with-faces)
***************
*** 620,626 ****
  ;;;###autoload
  (defun ps-print-region (from to &optional filename)
    "Generate and print a PostScript image of the region.
- 
  Like `ps-print-buffer', but prints just the current region."
  
    (interactive (list (point) (mark) (ps-print-preprint current-prefix-arg)))
--- 623,628 ----
***************
*** 632,640 ****
  ;;;###autoload
  (defun ps-print-region-with-faces (from to &optional filename)
    "Generate and print a PostScript image of the region.
- 
  Like `ps-print-region', but includes font, color, and underline
! information in the generated image."
  
    (interactive (list (point) (mark) (ps-print-preprint current-prefix-arg)))
    (ps-generate (current-buffer) from to
--- 634,642 ----
  ;;;###autoload
  (defun ps-print-region-with-faces (from to &optional filename)
    "Generate and print a PostScript image of the region.
  Like `ps-print-region', but includes font, color, and underline
! information in the generated image.  This command works only if you
! are using a window system, so it has a way to determine color values."
  
    (interactive (list (point) (mark) (ps-print-preprint current-prefix-arg)))
    (ps-generate (current-buffer) from to
***************
*** 645,651 ****
  ;;;###autoload
  (defun ps-spool-buffer ()
    "Generate and spool a PostScript image of the buffer.
- 
  Like `ps-print-buffer' except that the PostScript image is saved in a
  local buffer to be sent to the printer later.
  
--- 647,652 ----
***************
*** 658,666 ****
  ;;;###autoload
  (defun ps-spool-buffer-with-faces ()
    "Generate and spool a PostScript image of the buffer.
- 
  Like `ps-spool-buffer', but includes font, color, and underline
! information in the generated image.
  
  Use the command `ps-despool' to send the spooled images to the printer."
  
--- 659,667 ----
  ;;;###autoload
  (defun ps-spool-buffer-with-faces ()
    "Generate and spool a PostScript image of the buffer.
  Like `ps-spool-buffer', but includes font, color, and underline
! information in the generated image.  This command works only if you
! are using a window system, so it has a way to determine color values.
  
  Use the command `ps-despool' to send the spooled images to the printer."
  
***************
*** 672,678 ****
  ;;;###autoload
  (defun ps-spool-region (from to)
    "Generate a PostScript image of the region and spool locally.
- 
  Like `ps-spool-buffer', but spools just the current region.
  
  Use the command `ps-despool' to send the spooled images to the printer."
--- 673,678 ----
***************
*** 684,692 ****
  ;;;###autoload
  (defun ps-spool-region-with-faces (from to)
    "Generate a PostScript image of the region and spool locally.
- 
  Like `ps-spool-region', but includes font, color, and underline
! information in the generated image.
  
  Use the command `ps-despool' to send the spooled images to the printer."
    (interactive "r")
--- 684,692 ----
  ;;;###autoload
  (defun ps-spool-region-with-faces (from to)
    "Generate a PostScript image of the region and spool locally.
  Like `ps-spool-region', but includes font, color, and underline
! information in the generated image.  This command works only if you
! are using a window system, so it has a way to determine color values.
  
  Use the command `ps-despool' to send the spooled images to the printer."
    (interactive "r")
***************
*** 745,756 ****
  %*** NOTE: the following are missing in the Adobe documentation,
  %*** but appear in the displayed table:
  %*** macron at 0225, dieresis at 0230, cedilla at 0233, space at 0240.
! % \20x
      /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
      /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
      /dotlessi /grave /acute /circumflex /tilde /macron /breve /dotaccent
      /dieresis /.notdef /ring /cedilla /.notdef /hungarumlaut /ogonek /caron
! % \24x
      /space /exclamdown /cent /sterling
  	/currency /yen /brokenbar /section
      /dieresis /copyright /ordfeminine /guillemotleft
--- 745,756 ----
  %*** NOTE: the following are missing in the Adobe documentation,
  %*** but appear in the displayed table:
  %*** macron at 0225, dieresis at 0230, cedilla at 0233, space at 0240.
! % ^Px
      /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
      /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
      /dotlessi /grave /acute /circumflex /tilde /macron /breve /dotaccent
      /dieresis /.notdef /ring /cedilla /.notdef /hungarumlaut /ogonek /caron
! % ^Tx
      /space /exclamdown /cent /sterling
  	/currency /yen /brokenbar /section
      /dieresis /copyright /ordfeminine /guillemotleft
***************
*** 759,765 ****
  	/acute /mu /paragraph /periodcentered
      /cedilla /onesuperior /ordmasculine /guillemotright
  	/onequarter /onehalf /threequarters /questiondown
! % \30x
      /Agrave /Aacute /Acircumflex /Atilde
  	/Adieresis /Aring /AE /Ccedilla
      /Egrave /Eacute /Ecircumflex /Edieresis
--- 759,765 ----
  	/acute /mu /paragraph /periodcentered
      /cedilla /onesuperior /ordmasculine /guillemotright
  	/onequarter /onehalf /threequarters /questiondown
! % ^Xx
      /Agrave /Aacute /Acircumflex /Atilde
  	/Adieresis /Aring /AE /Ccedilla
      /Egrave /Eacute /Ecircumflex /Edieresis
***************
*** 768,774 ****
  	/Ocircumflex /Otilde /Odieresis /multiply
      /Oslash /Ugrave /Uacute /Ucircumflex
  	/Udieresis /Yacute /Thorn /germandbls
! % \34x
      /agrave /aacute /acircumflex /atilde
  	/adieresis /aring /ae /ccedilla
      /egrave /eacute /ecircumflex /edieresis
--- 768,774 ----
  	/Ocircumflex /Otilde /Odieresis /multiply
      /Oslash /Ugrave /Uacute /Ucircumflex
  	/Udieresis /Yacute /Thorn /germandbls
! % ^\\x
      /agrave /aacute /acircumflex /atilde
  	/adieresis /aring /ae /ccedilla
      /egrave /eacute /ecircumflex /edieresis
***************
*** 1198,1206 ****
  	       (listp filename)))
        (let* ((name (concat (buffer-name) ".ps"))
  	     (prompt (format "Save PostScript to file: (default %s) "
! 			     name)))
! 	(read-file-name prompt default-directory
! 			name nil))))
  
  ;; The following functions implement a simple list-buffering scheme so
  ;; that ps-print doesn't have to repeatedly switch between buffers
--- 1198,1208 ----
  	       (listp filename)))
        (let* ((name (concat (buffer-name) ".ps"))
  	     (prompt (format "Save PostScript to file: (default %s) "
! 			     name))
! 	     (res (read-file-name prompt default-directory name nil)))
! 	(if (file-directory-p res)
! 	    (expand-file-name name (file-name-as-directory res))
! 	  res))))
  
  ;; The following functions implement a simple list-buffering scheme so
  ;; that ps-print doesn't have to repeatedly switch between buffers
***************
*** 1565,1570 ****
--- 1567,1575 ----
  (defun ps-color-values (x-color)
    (cond ((fboundp 'x-color-values)
  	 (x-color-values x-color))
+         ;; From fsf 19.33
+         ;; ((fboundp 'pixel-components)
+ 	;;  (pixel-components x-color))
  	((and (fboundp 'color-instance-rgb-components)
  	      (xemacs-color-device))
  	 (color-instance-rgb-components
***************
*** 1644,1649 ****
--- 1649,1657 ----
       (memq face kind-list))))
  
  (defun ps-xemacs-face-kind-p (face kind kind-regex kind-list)
+   ;; fsf 19.33:
+   ;; (let* ((frame-font (or (face-font face) (face-font 'default)))
+   ;;       (kind-cons (assq kind (x-font-properties frame-font)))
    (let* ((frame-font
  	  (or (face-font-instance face) (face-font-instance 'default)))
  	 (kind-cons (and frame-font
***************
*** 1802,1809 ****
  			   (min (next-overlay-change from) to)))
  		 (setq position
  		       (min property-change overlay-change))
  		 (setq face
! 		       (cond ((get-text-property from 'invisible) nil)
  			     ((get-text-property from 'face))
  			     (t 'default)))
  		 (let ((overlays (overlays-at from))
--- 1810,1829 ----
  			   (min (next-overlay-change from) to)))
  		 (setq position
  		       (min property-change overlay-change))
+ 		 ;; The code below is not quite correct,
+ 		 ;; because a non-nil overlay invisible property
+ 		 ;; which is inactive according to the current value
+ 		 ;; of buffer-invisibility-spec nonetheless overrides
+ 		 ;; a face text property.
  		 (setq face
! 		       (cond ((let ((prop (get-text-property from 'invisible)))
! 				;; Decide whether this invisible property
! 				;; really makes the text invisible.
! 				(if (eq buffer-invisibility-spec t)
! 				    (not (null prop))
! 				  (or (memq prop buffer-invisibility-spec)
! 				      (assq prop buffer-invisibility-spec))))
! 			      nil)
  			     ((get-text-property from 'face))
  			     (t 'default)))
  		 (let ((overlays (overlays-at from))
***************
*** 1817,1823 ****
  						  0)))
  		       (if (and (or overlay-invisible overlay-face)
  				(> overlay-priority face-priority))
! 			   (setq face (cond (overlay-invisible nil)
  					    ((and face overlay-face)))
  				 face-priority overlay-priority)))
  		     (setq overlays (cdr overlays))))
--- 1837,1847 ----
  						  0)))
  		       (if (and (or overlay-invisible overlay-face)
  				(> overlay-priority face-priority))
! 			   (setq face (cond ((if (eq buffer-invisibility-spec t)
! 						 (not (null overlay-invisible))
! 					       (or (memq overlay-invisible buffer-invisibility-spec)
! 						   (assq overlay-invisible buffer-invisibility-spec)))
! 					     nil)
  					    ((and face overlay-face)))
  				 face-priority overlay-priority)))
  		     (setq overlays (cdr overlays))))
***************
*** 1831,1837 ****
  
  (defun ps-generate (buffer from to genfunc)
    (let ((from (min to from))
! 	(to (max to from)))
      (save-restriction
        (narrow-to-region from to)
        (if ps-razzle-dazzle
--- 1855,1864 ----
  
  (defun ps-generate (buffer from to genfunc)
    (let ((from (min to from))
! 	(to (max to from))
! 	;; This avoids trouble if chars with read-only properties
! 	;; are copied into ps-spool-buffer.
! 	(inhibit-read-only t))
      (save-restriction
        (narrow-to-region from to)
        (if ps-razzle-dazzle
***************
*** 1879,1885 ****
  	      ;; the postscript was generated without error.
  	      (setq completed-safely t))
  
! 	  ;; Unwind form: If some bad mojo ocurred while generating
  	  ;; postscript, delete all the postscript that was generated.
  	  ;; This protects the previously spooled files from getting
  	  ;; corrupted.
--- 1906,1912 ----
  	      ;; the postscript was generated without error.
  	      (setq completed-safely t))
  
! 	  ;; Unwind form: If some bad mojo occurred while generating
  	  ;; postscript, delete all the postscript that was generated.
  	  ;; This protects the previously spooled files from getting
  	  ;; corrupted.
***************
*** 1911,1919 ****
  	  (message "Printing..."))
        (save-excursion
  	(set-buffer ps-spool-buffer)
! 	(apply 'call-process-region
! 	       (point-min) (point-max) ps-lpr-command nil 0 nil
! 	       ps-lpr-switches))
        (if ps-razzle-dazzle
  	  (message "Printing...done")))
      (kill-buffer ps-spool-buffer)))
--- 1938,1951 ----
  	  (message "Printing..."))
        (save-excursion
  	(set-buffer ps-spool-buffer)
! 	(if (and (eq system-type 'ms-dos) (stringp dos-ps-printer))
! 	    (write-region (point-min) (point-max) dos-ps-printer t 0)
! 	  (let ((binary-process-input t)) ; for MS-DOS
! 	    (apply 'call-process-region
! 		   (point-min) (point-max) ps-lpr-command nil
! 		   (if (fboundp 'start-process) 0 nil)
! 		   nil
! 		   ps-lpr-switches))))
        (if ps-razzle-dazzle
  	  (message "Printing...done")))
      (kill-buffer ps-spool-buffer)))
***************
*** 1959,1965 ****
  (defun ps-article-subject ()
    (save-excursion
      (goto-char (point-min))
!     (if (re-search-forward "^Subject:[ \t]+\\(.*\\)$")
  	(buffer-substring (match-beginning 1) (match-end 1))
        "Subject ???")))
  
--- 1991,1997 ----
  (defun ps-article-subject ()
    (save-excursion
      (goto-char (point-min))
!     (if (re-search-forward "^Subject:[ \t]+\\(.*\\)$" nil t)
  	(buffer-substring (match-beginning 1) (match-end 1))
        "Subject ???")))
  
***************
*** 1969,1975 ****
  (defun ps-article-author ()
    (save-excursion
      (goto-char (point-min))
!     (if (re-search-forward "^From:[ \t]+\\(.*\\)$")
  	(let ((fromstring (buffer-substring (match-beginning 1) (match-end 1))))
  	  (cond
  
--- 2001,2007 ----
  (defun ps-article-author ()
    (save-excursion
      (goto-char (point-min))
!     (if (re-search-forward "^From:[ \t]+\\(.*\\)$" nil t)
  	(let ((fromstring (buffer-substring (match-beginning 1) (match-end 1))))
  	  (cond
  
***************
*** 2042,2048 ****
  (defun ps-info-file ()
    (save-excursion
      (goto-char (point-min))
!     (if (re-search-forward "File:[ \t]+\\([^, \t\n]*\\)")
  	(buffer-substring (match-beginning 1) (match-end 1))
        "File ???")))
  
--- 2074,2080 ----
  (defun ps-info-file ()
    (save-excursion
      (goto-char (point-min))
!     (if (re-search-forward "File:[ \t]+\\([^, \t\n]*\\)" nil t)
  	(buffer-substring (match-beginning 1) (match-end 1))
        "File ???")))
  
***************
*** 2051,2057 ****
  (defun ps-info-node ()
    (save-excursion
      (goto-char (point-min))
!     (if (re-search-forward "Node:[ \t]+\\([^,\t\n]*\\)")
  	(buffer-substring (match-beginning 1) (match-end 1))
        "Node ???")))
  
--- 2083,2089 ----
  (defun ps-info-node ()
    (save-excursion
      (goto-char (point-min))
!     (if (re-search-forward "Node:[ \t]+\\([^,\t\n]*\\)" nil t)
  	(buffer-substring (match-beginning 1) (match-end 1))
        "Node ???")))
  

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Sun Aug 18 08:30:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA15007 for xemacs-beta-people; Sun, 18 Aug 1996 08:30:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA15004 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 18 Aug 1996 08:30:12 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA20941 for <xemacs-beta@xemacs.org>; Sun, 18 Aug 1996 08:30:08 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id JAA07989 for <xemacs-beta@xemacs.org>; Sun, 18 Aug 1996 09:30:09 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp007985; Sun Aug 18 09:29:59 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA06635; Sun, 18 Aug 96 09:29:58 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA14107; Sun, 18 Aug 96 09:29:52 EDT
Message-Id: <9608181329.AA14107@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Putting new limits on productivity.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Partially read-only buffers using W3?!?!
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMhcaw1tTztlqB385AQGTRQP+Oh+kp1W3WkrZAfx/yx9e4TPB9epDBs+a
	      yCObsKmCYQGv3cosz4A+Hco8aUbkKZPCU4s9cl0odCiRQNHpq260uEqJh53Ecb+J
	      PPl3SNZd42MM3WNqD9SpW8/zq6XlRtZ/zhqFXVCcAHyqvp0W+NhONd8TB6WlXKm3
	      rtM/Kj/ems4=
	      =Z8tJ
Date: Sun, 18 Aug 1996 09:29:45 -0400
Sender: rickc@lehman.com

I was just trying to mail the contents of a web page (containing a news
article) to some friends.  I used W3 to grab the URL,
http://www.nytimes.com/library/cyber/week/0818justice.html, and started an
empty mail message using mh-e.  I then did C-x h (mark-whole-buffer), M-w
(kill-ring-save), C-x o (other-window), and C-y (yank).

Now, in the mail buffer, if I attempt to modify lines near the start of the
message body -- in particular if I try to do C-o (open-line) between the
first two lines, I get the error, `Buffer is read-only ...', however the
read-only flag does not show up in the mode line and I can modify other
parts of the buffer.

Can anyone explain this?

Actually, I was suprised to see all of the font stuff `stick' to the text
that was copied and yanked.  This seems very wrong to me.

			Rick

p. s.  I'm pretty sure that the Can't-break-out-with-Control-G problem
       with the distributed SunOS binary only exhibits itself when sound
       support (beeps over /dev/audio) is in use.  Running on a tty was
       just a special case of that.

From xemacs-beta-request@cs.uiuc.edu  Sun Aug 18 19:11:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA16361 for xemacs-beta-people; Sun, 18 Aug 1996 19:11:15 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA16358 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 18 Aug 1996 19:11:14 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA01014 for <xemacs-beta@cs.uiuc.edu>; Sun, 18 Aug 1996 19:11:19 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id UAA13661; Sun, 18 Aug 1996 20:11:00 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp013631; Sun Aug 18 20:10:47 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA06688; Sun, 18 Aug 96 20:10:43 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA18252; Sun, 18 Aug 96 20:10:35 EDT
Message-Id: <9608190010.AA18252@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: The art of incompetence.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu, cthomp@xemacs.org, mrb@eng.sun.com
Subject: Re: I'm back... almost 
In-Reply-To: Your message of "16 Aug 1996 19:13:06 PDT."
             <m220h6bvwt.fsf@deanna.miranova.com> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMhew9FtTztlqB385AQFAOwP/Y0BLvKz/d/a+OOteOccm9j8MC2oezQUQ
	      3sIKujCi5boX4KEax5VWpAu0jgNckLsjvcfn7YbeC9ITW2+ZqYSDPOc4AnDxfeSA
	      9yYZQJMdh4bDFjXov4DwbzTN+F6S2amovyco3WnCa4J612EBFp9MKjlh2h4yNA6w
	      VuwRtR7Nl8A=
	      =r+/m
Date: Sun, 18 Aug 1996 20:10:34 -0400
Sender: rickc@lehman.com

    From: Steven L Baur <steve@miranova.com>
    Date: 16 Aug 1996 19:13:06 -0700
    
    I've uploaded compressed tar file replacements for psgml to
    xemacs.org/pub/beta/incoming:

Are there any plans for key binding changes?  I like psgml a lot
except that it binds a bunch of standard bindings, particular C-M-
functions like C-M-f (forward-sexp).  Actually, these look like they
might be intended to have similar functionality, but they don't handle
moving past groups-of_words-seperated_by-non_whitespace.  With the
normal C-M- functions, I can jump over everything from `groups' to
`whitespace'.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Sun Aug 18 21:18:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA16686 for xemacs-beta-people; Sun, 18 Aug 1996 21:18:37 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA16683 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 18 Aug 1996 21:18:36 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA07387 for <xemacs-beta@cs.uiuc.edu>; Sun, 18 Aug 1996 21:18:41 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA09855; Sun, 18 Aug 1996 19:16:17 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: I'm back... almost
References: <9608190010.AA18252@cfdevx1.lehman.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Rick Campbell's message of Sun, 18 Aug 1996 20:10:34 -0400
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Aug 1996 19:16:16 -0700
Message-ID: <m2zq3sce4v.fsf@deanna.miranova.com>
Lines: 53
X-Mailer: Gnus v5.2.39/XEmacs 19.14

>>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:

Rick>     From: Steven L Baur <steve@miranova.com>
Rick>     Date: 16 Aug 1996 19:13:06 -0700
    
Rick>     I've uploaded compressed tar file replacements for psgml to
Rick>     xemacs.org/pub/beta/incoming:

Rick> Are there any plans for key binding changes?

Not on my part.

Rick> I like psgml a lot except that it binds a bunch of standard
Rick> bindings, particular C-M- functions like C-M-f (forward-sexp).
Rick> Actually, these look like they might be intended to have similar
Rick> functionality, but they don't handle moving past
Rick> groups-of_words-seperated_by-non_whitespace.  With the normal
Rick> C-M- functions, I can jump over everything from `groups' to
Rick> `whitespace'.

This would be easy enough to change.  Where do you want to put them?


The problems I see right now with psgml are:
1.  It is all the way broken with respect to the latest Cougar DTD.
    Psgml mode requires 8 bit characters.  I'm not sure how to fix
    this, especially since the code should work fine in 20.0 with MULE
    extensions (it drops core right now, but I think it should work).

2a.  There are too many menus across the menubar
2b.  It could use a toolbar of its own

3.  It still needs some enhancements for creating new files (a whole
    set of templates rather than 1 would be nice

4.  There is a font lock problem with respect to constructs of the
    form:
<A HREF="...">
Some text goes here</A>

The `Some text goes here' gets correctly colored when the anchor is on
just one line:
<A HREF="...">Some text goes here</A>
or when font-lock colors the entire buffer.  It gets colored
incorrectly when entered from the keyboard (in plain-old font-lock
mode) on two lines.


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 19 07:52:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA21535 for xemacs-beta-people; Mon, 19 Aug 1996 07:52:28 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA21532 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 19 Aug 1996 07:52:27 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA17281 for <xemacs-beta@cs.uiuc.edu>; Mon, 19 Aug 1996 07:52:32 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.55 #1)
	id E0usToX-00008Z-00; Mon, 19 Aug 1996 08:52:17 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: xemacs-beta@cs.uiuc.edu
cc: Michael Alan Dorman <mdorman@calder.med.miami.edu>
Subject: forwarded message from Michael Alan Dorman
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.77)
Content-Type: multipart/mixed;
 boundary="Multipart_Mon_Aug_19_08:52:16_1996-1"
Content-Transfer-Encoding: 7bit
Message-Id: <E0usToX-00008Z-00@neal.ctd.comsat.com>
Date: Mon, 19 Aug 1996 08:52:17 -0400

--Multipart_Mon_Aug_19_08:52:16_1996-1
Content-Type: text/plain; charset=US-ASCII

As I recall the problem had to do with libpng using setjump, and
apparantly the struct jmpbuf was different if _BSD_SOURCE was used.  

Can any of you guys recall the details?


--Multipart_Mon_Aug_19_08:52:16_1996-1
Content-Type: message/rfc822

Return-path: <mdorman@calder.med.miami.edu>
Delivery-date: Sun, 18 Aug 1996 13:34:53 -0400
Message-Id: <199608181735.NAA13576@calder.med.miami.edu>
X-Mailer: MH 6.8.4
From: Michael Alan Dorman <mdorman@calder.med.miami.edu>
To: neal@ctd.comsat.com
Subject: _BSD_SOURCE references in libgr...
Date: Sun, 18 Aug 1996 13:35:15 -0400

Sorry to bother you, but I was hoping you could clarify a comment you
make in the NEWS for libgr for me.  Specifically, you said:

* added -D_BSD_SOURCE for linux to be compatible with XFree86 (this
  solves a problem first noticed with xemacs-19.14 which uses
  -D_BSD_SOURCE because XFree86 does.  Maybe we should all drop
  this flag?  The problem is that setjump changes because of this 
  flag.)

You see, I maintain zlib and libpng packages for Debian, and know the
people who maintain libtiff and so forth, and this is the first I had
heard of any sort of incompatability between them and xemacs/xfree86.

Could you tell me in what form this incompatability manifests itself,
so I can see if our Debian packages are experiencing it?  I'd be much
obliged.

Cheers,

Mike.
--
Michael Alan Dorman                                   Head of Systems
mdorman@calder.med.miami.edu            Louis Calder Memorial Library
(305) 243-5530                 University of Miami School of Medicine 

--Multipart_Mon_Aug_19_08:52:16_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 19 13:26:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA22639 for xemacs-beta-people; Mon, 19 Aug 1996 13:26:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA22636 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 19 Aug 1996 13:26:47 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA14625 for <xemacs-beta@xemacs.org>; Mon, 19 Aug 1996 13:26:42 -0500 (CDT)
Message-Id: <199608191826.NAA14625@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 20.0 beta27
Date: Mon, 19 Aug 1996 13:26:40 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/beta/xemacs-20.0.  Next release is
beta28 out Sunday, August 25.

Things are finally starting to come back to life.  The next two weeks
will still be kind of slow but things will really start to pick up
once September rolls around.

Despite what Martin says I still had trouble bytecompiling files.  If
you patch up, keep that in mind.  Also, this beta is just the work
that Martin has been doing.  I have _many_ things on file that I will
get to shortly.

Say hi to the 33 new beta testers who were added just this weekend.


			-Chuck


-- gnus 5.2.39
-- etc 0.20
-- w3 3.0.11
-- url 1.0.41
-- canna.el patch
-- chinese font patch
-- stringp nil error when starting sparcworks
-- call7 and call8 had incorrect array sizes
-- makefile mode Error in `pre-idle-hook' (setting hook to nil):
   (void-function makefile-space-face)
-- Crashes when built on X11R5 and run on X11R6 fixed
-- Lisp backtrace is now printed on all crashes, not just debug build
-- XIM input now generates true events.  As a result it works with isearch.
-- 20.0/Mule can now byte-compile its own elisp files.
-- LOTS of typos fixed.
-- 20.0/Mule - Language Environment menu no longer shrinks to one element.
-- 20.0/Mule - no more Vietnamese language build-time warnings.
-- sunpro-init no longer opens /net/bin with possible hang at startup.
-- switch-to-buffer-other-window reverted to old-style behaviour
-- python-mode 2.67
-- auto-mode-alist regexps reorganized for efficiency
-- interpreter-mode-alist regexps now look at entire first line.
-- new (interactive) spec `i' can be used to skip arguments.
-- dired works in Asian locales.
-- (Mule) write-region now works.

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 19 14:39:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA22895 for xemacs-beta-people; Mon, 19 Aug 1996 14:39:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA22892 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 19 Aug 1996 14:39:38 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA14757; Mon, 19 Aug 1996 14:39:33 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.55 #1)
	id E0usZdj-0000KV-00; Mon, 19 Aug 1996 15:05:31 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: XEmacs 20.0 beta27
In-Reply-To: <199608191826.NAA14625@xemacs.cs.uiuc.edu>
References: <199608191826.NAA14625@xemacs.cs.uiuc.edu>
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.77)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0usZdj-0000KV-00@neal.ctd.comsat.com>
Date: Mon, 19 Aug 1996 15:05:31 -0400

Will there be a 19.15 or is 20.0 the future?

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 19 14:48:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA22947 for xemacs-beta-people; Mon, 19 Aug 1996 14:48:50 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA22944 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 19 Aug 1996 14:48:49 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA14782 for <xemacs-beta@xemacs.org>; Mon, 19 Aug 1996 14:48:42 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id PAA19918; Mon, 19 Aug 1996 15:48:23 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp019905; Mon Aug 19 15:47:33 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA14940; Mon, 19 Aug 96 15:47:31 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA19002; Mon, 19 Aug 96 15:47:30 EDT
Message-Id: <9608191947.AA19002@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: The art of incompetence.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Steven L Baur <steve@miranova.com>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: I'm back... almost 
In-Reply-To: Your message of "18 Aug 1996 19:16:16 PDT."
             <m2zq3sce4v.fsf@deanna.miranova.com> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMhjEuVtTztlqB385AQFubwP/bmMqoxz157afn3u2dbGYl1lushbWGlPq
	      EpBq7OFPnCircp6P+qxJ5Wbp7PE+ftl288ydNaL64riOQ9fUrb5CBzAyCXPRyFB2
	      B8gZMQgTO4Lz4zS29vevWe8p+2qpo1VXwyhEd4NwuDlQHisWiaxblgXZQYbOCFnq
	      BQ19nJCefZs=
	      =WYia
Date: Mon, 19 Aug 1996 15:47:13 -0400
Sender: rickc@lehman.com

    From: Steven L Baur <steve@miranova.com>
    Date: 18 Aug 1996 19:16:16 -0700
    
    >>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:
    
    Rick> I like psgml a lot except that it binds a bunch of standard
    Rick> bindings, particular C-M- functions like C-M-f (forward-sexp).
    Rick> Actually, these look like they might be intended to have similar
    Rick> functionality, but they don't handle moving past
    Rick> groups-of_words-seperated_by-non_whitespace.  With the normal
    Rick> C-M- functions, I can jump over everything from `groups' to
    Rick> `whitespace'.
    
    This would be easy enough to change.  Where do you want to put them?

I'm not sure.  It would be nice if some (C-M-f, C-M-b, etc.) were just
updated so that they:
 - maintained their current functionality when immediately in front of
   (or after as appropriate) a tag, but
 - acted like (called?) the standard C-M- bindings otherwise.

Others, e. g. C-M-u, already preserve the spirit of the standard
bindings -- tags are like special parens -- and should be left alone.
    
    The problems I see right now with psgml are:

    . . .

    4.  There is a font lock problem with respect to constructs of the
        form:
    <A HREF="...">
    Some text goes here</A>

Another problem that I've noticed is that if you abort (C-g) out of
tempo-template-html-hyperlink (C-z h) at the URL: prompt it leaves a
partial tag, that is, it inserts ``<a href="''.  If it waited until
after reading the URL before it inserted anything, this could be avoided.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 19 14:54:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA22964 for xemacs-beta-people; Mon, 19 Aug 1996 14:54:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA22961 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 19 Aug 1996 14:54:31 -0500 (CDT)
Received: from network-services.uoregon.edu (network-services.uoregon.edu [128.223.60.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14803 for <xemacs-beta@xemacs.org>; Mon, 19 Aug 1996 14:54:28 -0500 (CDT)
Received: from wayback. (wayback.uoregon.edu [128.223.156.117]) by network-services.uoregon.edu (8.7.5/8.7.3) with SMTP id MAA17381 for <xemacs-beta@xemacs.org>; Mon, 19 Aug 1996 12:54:25 -0700 (PDT)
Received: by wayback. (SMI-8.6/SMI-SVR4)
	id MAA14560; Mon, 19 Aug 1996 12:51:17 -0700
Date: Mon, 19 Aug 1996 12:51:17 -0700
Message-Id: <199608191951.MAA14560@wayback.>
From: "David M. Meyer 541/346-1747" <meyer@wayback.uoregon.edu>
To: xemacs-beta@xemacs.org
Subject: 20.0 beta 27 success on Solaris 2.5.1



Configured for `sparc-sun-solaris2.5.1'.

  Where should the build process find the source code?    /disk1/home/meyer/Misc/xemacs-20.0-b27
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/dt/include
  Additional libraries:                                   /usr/dt/lib 
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for GNU DBM.
  Compiling in support for CDE.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.
 
 

	So far, so good.

	Dave

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 19 14:56:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA22971 for xemacs-beta-people; Mon, 19 Aug 1996 14:56:09 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA22968 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 19 Aug 1996 14:56:08 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14809 for <xemacs-beta@xemacs.org>; Mon, 19 Aug 1996 14:56:05 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA02454; Mon, 19 Aug 1996 14:56:05 -0500 (CDT)
Message-Id: <199608191956.OAA02454@charles.cs.uiuc.edu>
To: Neal Becker <neal@ctd.comsat.com>
cc: xemacs-beta@xemacs.org
Subject: Re: XEmacs 20.0 beta27 
In-reply-to: Your message of "Mon, 19 Aug 1996 15:05:31 EDT."
             <E0usZdj-0000KV-00@neal.ctd.comsat.com> 
Date: Mon, 19 Aug 1996 14:56:04 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Neal> Will there be a 19.15 or is 20.0 the future?

There will definitely be a 19.15.  As previously announced :-)  19.15
beta1 and 20.0 beta28 will both be released next Sunday (or early
Monday).  Due to the 2 month hiatus, 19.15 will start out in feature
freeze.  It will _not_ have any kind of new packaging system.  My goal
is to release it sometime in early October.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 19 16:16:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA23252 for xemacs-beta-people; Mon, 19 Aug 1996 16:16:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA23249 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 19 Aug 1996 16:16:12 -0500 (CDT)
Received: from loiosh.kei.com (ckd@loiosh.kei.com [192.88.144.32]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA14958 for <xemacs-beta@xemacs.org>; Mon, 19 Aug 1996 16:16:08 -0500 (CDT)
Received: (from ckd@localhost) by loiosh.kei.com (8.7.5/8.7.3) id RAA00768 for xemacs-beta@xemacs.org; Mon, 19 Aug 1996 17:15:33 -0400 (EDT)
Date: Mon, 19 Aug 1996 17:15:33 -0400 (EDT)
From: Christopher Davis <ckd@loiosh.kei.com>
Message-Id: <199608192115.RAA00768@loiosh.kei.com>
To: xemacs-beta@xemacs.org
Subject: "Corrupt JPEG data"?

I vaguely remember this coming across the list at some point but a quick
(or not so quick) simple-minded grep over the past few months fails to find
any sign of it.  The JPEG appears to be valid but XEmacs 19.14 (linked, of
course, with the JPEG lib) complains and won't display it.

The JPEG in question would be up on the web if the $%*&*! web server weren't
having severe disk crises.

Message: "Corrupt JPEG data: 55 extraneous bytes before marker 0xe1

No, I don't know what version of the JPEG lib I have, but djpeg seems to be
perfectly happy with it and djpeg is using the same JPEG lib.  It's whatever
BSDI shipped with 2.1.

I can attach the file (using tm) to cause any poor suckers who need a chance
to get the same error message :)

--C

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 19 18:12:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA23513 for xemacs-beta-people; Mon, 19 Aug 1996 18:12:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA23510 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 19 Aug 1996 18:12:19 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA08839 for <xemacs-beta@cs.uiuc.edu>; Mon, 19 Aug 1996 18:12:18 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id QAA23181; Mon, 19 Aug 1996 16:09:45 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: "Corrupt JPEG data"?
References: <199608192115.RAA00768@loiosh.kei.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Christopher Davis's message of Mon, 19 Aug 1996 17:15:33 -0400 (EDT)
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII
Date: 19 Aug 1996 16:09:43 -0700
Message-ID: <m2ohk7ezt4.fsf@deanna.miranova.com>
Lines: 23
X-Mailer: Gnus v5.2.39/XEmacs 19.14

>>>>> "Christopher" == Christopher Davis <ckd@loiosh.kei.com> writes:

Christopher> I vaguely remember this coming across the list at some
Christopher> point but a quick (or not so quick) simple-minded grep
Christopher> over the past few months fails to find any sign of it.
Christopher> The JPEG appears to be valid but XEmacs 19.14 (linked, of
Christopher> course, with the JPEG lib) complains and won't display
Christopher> it.

Christopher> The JPEG in question would be up on the web if the $%*&*!
Christopher> web server weren't having severe disk crises.

Christopher> Message: "Corrupt JPEG data: 55 extraneous bytes before
Christopher> marker 0xe1

I've seen this a lot but haven't been able to track down the cause.
Be grateful it didn't crash XEmacs (which it sometimes does to me).

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 19 22:57:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA24063 for xemacs-beta-people; Mon, 19 Aug 1996 22:57:23 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA24060 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 19 Aug 1996 22:57:22 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA17795 for <xemacs-beta@cs.uiuc.edu>; Mon, 19 Aug 1996 22:57:24 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id UAA29601; Mon, 19 Aug 1996 20:54:56 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: XEmacs-20.0-b27 report
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII
Date: 19 Aug 1996 20:54:54 -0700
Message-ID: <m2wwyu90c1.fsf@deanna.miranova.com>
Lines: 100
X-Mailer: Gnus v5.2.39/XEmacs 19.14

Not a success, as it is pretty unrunnable in my environment. :-(

1.  These were the same configure settings I used with b26.
2.  I took the full source and replaced psgml mode with the updated version.
3.  Built with `make all-elc'

Configured for `i486-unknown-linux2.0.13'.

  Where should the build process find the source code?    /i/xemacs-20.0-b27
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

4. Error messages when byte compiling:

Checking for Mule support...yes
Compiling files without .elc...
/i/xemacs-20.0-b27/src/xemacs -batch -q -no-site-file -f batch-byte-compile lisp/./mule/arabic.el lisp/./mule/ethiopic.el lisp/./mule/vietnamese-hooks-2.el lisp/./mule/visual-mode.el 
Loading bytecomp...
Compiling /i/xemacs-20.0-b27/lisp/mule/arabic.el...
Loading cl-macs...
Loading visual-mode...
While compiling toplevel forms in file /i/xemacs-20.0-b27/lisp/mule/arabic.el:
  !! Invalid read syntax ((". in wrong context"))
Compiling /i/xemacs-20.0-b27/lisp/mule/ethiopic.el...
While compiling toplevel forms in file /i/xemacs-20.0-b27/lisp/mule/ethiopic.el:
  !! Invalid read syntax (("Invalid integer constant in reader" "" 2))
Compiling /i/xemacs-20.0-b27/lisp/mule/vietnamese-hooks-2.el...
While compiling toplevel forms in file /i/xemacs-20.0-b27/lisp/mule/vietnamese-hooks-2.el:
  !! Invalid read syntax (("#"))
Compiling /i/xemacs-20.0-b27/lisp/mule/visual-mode.el...
Loading byte-optimize...
While compiling enter-visual-mode in file /i/xemacs-20.0-b27/lisp/mule/visual-mode.el:
  ** reference to free variable display-direction
While compiling l2r-mode:
  ** assignment to free variable display-direction
While compiling r2l-mode:
  ** assignment to free variable display-direction
While compiling visual-forward-1-char:
  ** reference to free variable display-direction
While compiling visual-backward-1-char:
  ** reference to free variable display-direction
While compiling visual-char-direction:
  ** reference to free variable display-direction
While compiling toplevel forms:
  !! Invalid read syntax (("\"]\" in a list"))
Done
Done.


5.  When entering the Gnus group for this mailing list (which contains ISO
    2022-JP encoded headers), it hung:
read(7, "\1\2(0\0\0\0\0\n\0\0\3\0\0\0\0\0"..., 32) = 32
ioctl(7, FIONREAD, [0])                 = 0
write(7, "\2(\4\0\37\0\200\2\0@\0\0.\0\200"..., 20) = 20
--- SIGLOST (Possible I/O) ---
sigreturn()                             = ? (mask now [])
read(7, "\1\2*0\0\0\0\0\n\0\0\3\0\0\0\0\0"..., 32) = 32
write(7, "\2(\4\0\37\0\200\2\0@\0\0\10\0\200"..., 20) = 20
--- SIGLOST (Possible I/O) ---
sigreturn()                             = ? (mask now [])
read(7, "\1\2,0\0\0\0\0\n\0\0\3\0\0\0\0\0"..., 32) = 32
ioctl(7, FIONREAD, [0])                 = 0
write(7, "\2(\4\0\37\0\200\2\0@\0\0.\0\200"..., 20) = 20
--- SIGLOST (Possible I/O) ---
sigreturn()                             = ? (mask now [])
read(7, "\1\2.0\0\0\0\0\n\0\0\3\0\0\0\0\0"..., 32) = 32
write(7, "\2(\4\0\37\0\200\2\0@\0\0\10\0\200"..., 20) = 20
--- SIGLOST (Possible I/O) ---
sigreturn()                             = ? (mask now [])
read(7, "\1\00200\0\0\0\0\n\0\0\3\0\0\0\0"..., 32) = 32
ioctl(7, FIONREAD, [0])                 = 0


I'll try to fiddle some more with it later.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Tue Aug 20 11:44:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA29339 for xemacs-beta-people; Tue, 20 Aug 1996 11:44:22 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA29336 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 20 Aug 1996 11:44:21 -0500 (CDT)
Received: from big.aa.net (root@big.aa.net [204.157.220.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA16627 for <xemacs-beta@xemacs.org>; Tue, 20 Aug 1996 11:44:16 -0500 (CDT)
Received: from sym.primuscorp.com ([204.137.132.34]) by big.aa.net (8.7/8.7.5) with ESMTP id JAA29868 for <xemacs-beta@xemacs.org>; Tue, 20 Aug 1996 09:44:14 -0700
X-Intended-For: <xemacs-beta@xemacs.org>
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id JAA28427 for <xemacs-beta@xemacs.org>; Tue, 20 Aug 1996 09:44:15 -0700
Received: from pris by horus (SMI-8.6/SMI-SVR4)
	id JAA24052; Tue, 20 Aug 1996 09:42:19 -0700
Received: by pris (5.x/SMI-SVR4)
	id AA04434; Tue, 20 Aug 1996 09:44:07 -0700
Date: Tue, 20 Aug 1996 09:44:07 -0700
Message-Id: <9608201644.AA04434@pris>
From: Damon Lipparelli <lipp@primuscorp.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 20.0-b27: success under Solaris 2.4
Reply-To: Damon Lipparelli <lipp@primuscorp.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.14 ]

./configure --verbose --with-gcc --with-gnu-make --site-includes=/usr/local/include --site-libraries=/usr/local/sun4/lib --prefix=/users/lipp/xemacs-beta/20.x --exec-prefix=/users/lipp/xemacs-beta/20.x/sun4 --with-dialogs=athena --with-menubars=lucid --with-scrollbars=lucid --with-xpm --with-xface --with-jpeg --with-gif --with-png --with-tooltalk --with-sparcworks --with-sound=none --with-mule

Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /users/lipp/src/xemacs-beta/20.x/xemacs-20.0-b27
  What installation prefix should install use?            /users/lipp/xemacs-beta/20.x
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/sun4/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in Mule (multi-lingual) support.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

So far, so good.
-lipp

---

Alright, you!!  Imitate a WOUNDED SEAL pleading for a PARKING SPACE!!

From xemacs-beta-request@cs.uiuc.edu  Tue Aug 20 14:58:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA29838 for xemacs-beta-people; Tue, 20 Aug 1996 14:58:21 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA29835 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 20 Aug 1996 14:58:19 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA08281 for <xemacs-beta@cs.uiuc.edu>; Tue, 20 Aug 1996 14:58:19 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id MAA04069; Tue, 20 Aug 1996 12:57:37 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA11407; Tue, 20 Aug 1996 12:57:28 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA26739; Tue, 20 Aug 1996 12:57:24 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA23702; Tue, 20 Aug 1996 12:57:21 -0700
Date: Tue, 20 Aug 1996 12:57:21 -0700
Message-Id: <199608201957.MAA23702@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: XEmacs-20.0-b27 report
In-Reply-To: <m2wwyu90c1.fsf@deanna.miranova.com>
References: <m2wwyu90c1.fsf@deanna.miranova.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

Steven> Not a success, as it is pretty unrunnable in my environment. :-(
Steven> 1.  These were the same configure settings I used with b26.
Steven> 2.  I took the full source and replaced psgml mode with the updated version.
Steven> 3.  Built with `make all-elc'

Steven> 4. Error messages when byte compiling:

Apply this patch, then build a new xemacs binary, then make all-elc:

*** /tmp/geta23690	Tue Aug 20 12:52:39 1996
--- mule-load.el	Tue Aug 20 12:51:41 1996
***************
*** 36,56 ****
  ;; Now load files to set up all the different languages/environments
  ;; that Mule knows about.
  
! ;; (For now I'm commenting out those languages below known not to work --mrb)
! 
! ;;(load-gc "arabic-hooks")
  (load-gc "chinese-hooks")
  (load-gc "cyrillic-hooks")
! ;;(load-gc "ethiopic-hooks")
  (load-gc "european-hooks")
  (load-gc "greek-hooks")
! ;;(load-gc "hebrew-hooks")
! ;;(load-gc "ipa-hooks")
  (load-gc "japanese-hooks")
  (load-gc "korean-hooks")
! ;;(load-gc "thai-hooks")
! ;;(load-gc "vietnamese-hooks-1")
! ;;(load-gc "vietnamese-hooks-2")
  
  ;; load this last.  It sets up the XEmacs environment for Mule,
  ;; and assumes the existence of various stuff above.
--- 36,54 ----
  ;; Now load files to set up all the different languages/environments
  ;; that Mule knows about.
  
! (load-gc "arabic-hooks")
  (load-gc "chinese-hooks")
  (load-gc "cyrillic-hooks")
! (load-gc "ethiopic-hooks")
  (load-gc "european-hooks")
  (load-gc "greek-hooks")
! (load-gc "hebrew-hooks")
! (load-gc "ipa-hooks")
  (load-gc "japanese-hooks")
  (load-gc "korean-hooks")
! (load-gc "thai-hooks")
! (load-gc "vietnamese-hooks-1")
! (load-gc "vietnamese-hooks-2")
  
  ;; load this last.  It sets up the XEmacs environment for Mule,
  ;; and assumes the existence of various stuff above.


Steven> 5.  When entering the Gnus group for this mailing list (which contains ISO
Steven>     2022-JP encoded headers), it hung:
Steven> read(7, "\1\2(0\0\0\0\0\n\0\0\3\0\0\0\0\0"..., 32) = 32
Steven> ioctl(7, FIONREAD, [0])                 = 0
Steven> write(7, "\2(\4\0\37\0\200\2\0@\0\0.\0\200"..., 20) = 20
Steven> --- SIGLOST (Possible I/O) ---
Steven> sigreturn()                             = ? (mask now [])
Steven> read(7, "\1\2*0\0\0\0\0\n\0\0\3\0\0\0\0\0"..., 32) = 32
Steven> write(7, "\2(\4\0\37\0\200\2\0@\0\0\10\0\200"..., 20) = 20
Steven> --- SIGLOST (Possible I/O) ---
Steven> sigreturn()                             = ? (mask now [])
Steven> read(7, "\1\2,0\0\0\0\0\n\0\0\3\0\0\0\0\0"..., 32) = 32
Steven> ioctl(7, FIONREAD, [0])                 = 0
Steven> write(7, "\2(\4\0\37\0\200\2\0@\0\0.\0\200"..., 20) = 20
Steven> --- SIGLOST (Possible I/O) ---
Steven> sigreturn()                             = ? (mask now [])
Steven> read(7, "\1\2.0\0\0\0\0\n\0\0\3\0\0\0\0\0"..., 32) = 32
Steven> write(7, "\2(\4\0\37\0\200\2\0@\0\0\10\0\200"..., 20) = 20
Steven> --- SIGLOST (Possible I/O) ---
Steven> sigreturn()                             = ? (mask now [])
Steven> read(7, "\1\00200\0\0\0\0\n\0\0\3\0\0\0\0"..., 32) = 32
Steven> ioctl(7, FIONREAD, [0])                 = 0

Perhaps this will be fixed as well by the above patch.

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Aug 20 15:06:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA29864 for xemacs-beta-people; Tue, 20 Aug 1996 15:06:47 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA29861 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 20 Aug 1996 15:06:46 -0500 (CDT)
Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA16938; Tue, 20 Aug 1996 15:06:36 -0500 (CDT)
Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.5/8.7.3) with ESMTP id QAA19008; Tue, 20 Aug 1996 16:06:33 -0400
Message-Id: <199608202006.QAA19008@black-ice.cc.vt.edu>
X-Mailer: exmh version 1.6.7 5/3/96
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: XEmacs 20.0 beta27 on AIX 4.2
In-Reply-To: Your message of "Mon, 19 Aug 1996 13:26:40 CDT."
             <199608191826.NAA14625@xemacs.cs.uiuc.edu> 
From: Valdis.Kletnieks@vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199608191826.NAA14625@xemacs.cs.uiuc.edu>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="===_-1_Tue_Aug_20_16:06:31_EDT_1996";
	micalc=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 20 Aug 1996 16:06:32 -0400

--===_-1_Tue_Aug_20_16:06:31_EDT_1996
Content-Type: text/plain; charset=us-ascii

The following patch was needed to get tooltalk support to compile in cleanly.
It applies for both AIX 4.1 and 4.2 (AIX 3.2 doesn't have tooltalk support).
I found a similar patch to be needed for Xemacs 19.12 through 19.14 as well.

beta27 seems to work OK for the limited testing I've done so far (it
starts up, gnuclient connects, etc....)  More as I use it more.

** Warning - I screwed up and tried compiling with 'cc -O3' - this crashed
my entire machine twice.  'cc -g' seems to be safe.  I'll follow up on that
as well - not sure who's fault it is yet....


*** src/Makefile.in.in.orig	Mon Aug 19 13:04:06 1996
--- src/Makefile.in.in	Mon Aug 19 17:54:43 1996
***************
*** 776,782 ****
  
  #ifdef TOOLTALK
  # define TOOLTALK_OBJS tooltalk.o
! # if (defined (IRIX5) || defined (HPUX) || defined (POWERPC))
  #  define LIB_TOOLTALK -ltt
  # else
  #  if (defined (SPARC) && !defined (USG))
--- 776,782 ----
  
  #ifdef TOOLTALK
  # define TOOLTALK_OBJS tooltalk.o
! # if (defined (IRIX5) || defined (HPUX) || defined (POWERPC)) || 
defined(AIX4)
  #  define LIB_TOOLTALK -ltt
  # else
  #  if (defined (SPARC) && !defined (USG))

-- 
				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech



--===_-1_Tue_Aug_20_16:06:31_EDT_1996
Content-Type: application/pgp-signature

-----BEGIN PGP MESSAGE-----
Version: 2.6.2

iQCVAwUBMhoaxtQBOOoptg9JAQHbMQP8CIYgxEW1sBdWw9ClHvUrxnkhigTPMiI1
ngSwednk1IpmKWUNUMc1FZaC7MBHhwpiHMsM0tc8lSi6KYbuBXhipmSuGH2ADunm
ujH6l1jFy+H0oHlNLeRu1ESbPCZ6taLqSJHSv73IUAZZu4Dc2pV7LGXpUpjoh3uj
HVQuGXLJOhs=
=JPeb
-----END PGP MESSAGE-----

--===_-1_Tue_Aug_20_16:06:31_EDT_1996--

From xemacs-beta-request@cs.uiuc.edu  Tue Aug 20 16:08:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA00204 for xemacs-beta-people; Tue, 20 Aug 1996 16:08:55 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA00201 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 20 Aug 1996 16:08:54 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA09656 for <xemacs-beta@cs.uiuc.edu>; Tue, 20 Aug 1996 16:08:53 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id OAA03842; Tue, 20 Aug 1996 14:06:24 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs-20.0-b27 report
References: <m2wwyu90c1.fsf@deanna.miranova.com>
	<199608201957.MAA23702@xemacs.eng.sun.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Martin Buchholz's message of Tue, 20 Aug 1996 12:57:21 -0700
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII
Date: 20 Aug 1996 14:06:22 -0700
Message-ID: <m2viedvk8h.fsf@deanna.miranova.com>
Lines: 41
X-Mailer: Gnus v5.2.39/XEmacs 19.14

>>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:
Steven> Not a success, as it is pretty unrunnable in my environment. :-(
Steven> 1.  These were the same configure settings I used with b26.
Steven> 2.  I took the full source and replaced psgml mode with the updated version.
Steven> 3.  Built with `make all-elc'

Steven> 4. Error messages when byte compiling:

Martin> Apply this patch, then build a new xemacs binary, then make all-elc:

O.K. those are gone now.

Steven> 5.  When entering the Gnus group for this mailing list (which contains ISO
Steven> 2022-JP encoded headers), it hung:
 ...
Martin> Perhaps this will be fixed as well by the above patch.

Nope.  Here is a lisp backtrace:

Signalling: (quit)
  decode-mime-charset-region(476 612 iso-2022-int-1)
  (while (< (point) (point-max)) (decode-mime-charset-region (point) (progn ... ...) default-mime-charset) (forward-char))
)
  (let ((charset ...)) (goto-char (point-min)) (while (< ... ...) (decode-mime-charset-region ... ... default-mime-charset) (forward-char)))
)
  gnus-set-summary-default-charset()
  run-hooks(gnus-parse-headers-hook)
  gnus-get-newsgroup-headers-xover((1 4 7 52 75 77 79 149 188 201 233 320 336 338 459 473 474 538 559 592 593 638 659 686 688 742 753 765 766 831 847 849 860 862 865 922 924 925 927 946 967 990 998 1000 1152 1177 1181 1183 1185 1191 ...))
  gnus-select-newsgroup("nnml:xemacs-beta" nil)
  gnus-summary-read-group("nnml:xemacs-beta" nil nil)
  gnus-group-read-group(nil nil nil)
  gnus-topic-read-group(nil)
  call-interactively(gnus-topic-read-group)

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Tue Aug 20 20:08:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA00785 for xemacs-beta-people; Tue, 20 Aug 1996 20:08:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA00782 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 20 Aug 1996 20:08:40 -0500 (CDT)
Received: from pie.mhsc.org (root@pie.mhsc.org [38.251.45.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA19540 for <xemacs-beta@cs.uiuc.edu>; Tue, 20 Aug 1996 20:08:39 -0500 (CDT)
Received: (from glenn@localhost) by pie.mhsc.org (8.6.9/8.6.9) id VAA04459; Tue, 20 Aug 1996 21:07:55 -0400
Date: Tue, 20 Aug 1996 21:07:55 -0400
Message-Id: <199608210107.VAA04459@pie.mhsc.org>
From: Glenn Amerine <glenn@pie.mhsc.org>
Reply-to: glenn@pie.mhsc.org
To: xemacs-beta@cs.uiuc.edu
Subject: Xemacs-20.0-b27 report

So far so good. I'll try and bring it up on a newer ELF box tomorrow.

BTW, I ran into the Elisp compiling problem with the 26-27 patch. Do
you want those errors?

./configure
[snip]
Configured for `i486-unknown-linuxoldld1.1.54'.

  Where should the build process find the source code?    /u1/oct/xemacs-20.0-b27
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                 /usr/include/ncurses
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

Glenn
---
Glenn Amerine                             Inet: glenn@pie.mhsc.org
Computer Systems Analyst               Ma Bell: (614)224-1336
Metropolitan Human Services Commission     Fax: (614)224-6472

--VAA04452.840589533/pie.mhsc.org--

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 00:34:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA01210 for xemacs-beta-people; Wed, 21 Aug 1996 00:34:44 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA01207 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 00:34:43 -0500 (CDT)
Received: from konishki.bigbook.com (konishki.bigbook.com [207.76.139.159]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA00421 for <xemacs-beta@cs.uiuc.edu>; Wed, 21 Aug 1996 00:34:44 -0500 (CDT)
Received: from konishki.bigbook.com (LOCALHOST [127.0.0.1]) by konishki.bigbook.com (8.6.12/8.6.12) with ESMTP id FAA24032 for <xemacs-beta@cs.uiuc.edu>; Wed, 21 Aug 1996 05:35:45 GMT
Message-Id: <199608210535.FAA24032@konishki.bigbook.com>
X-Mailer: exmh version 1.6.7 5/3/96
To: xemacs-beta@cs.uiuc.edu
Subject: attempting to build under IRIX-6.2...
X-uri: <URL:http://www.u-aizu.ac.jp/~c-goetze/>
X-Face: #JCAl&l34b@_o'9J}'-'_X~-{w%68ex|k{YKr}PZ^SVhfp)M{,M~Kk05(4=J6k8~i/b@]e.
 LtM(@?f(L4i<yo-#O+(p"W=.2zW~2%|*0ya4[qsh6@b\}O3@[+~lSn]UQF#xk)r1{-:z/4<6Im0;rE
 3lZ(vQP^&<]@#=|4y,lj5%s&s]Hx,9@'T9cbdug7zvPH383!3%v<9sYGOr]P6a4r*Vc[J"$F!e'1
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 20 Aug 1996 22:35:44 -0700
From: Christian Goetze <cg@bigbook.com>

configure fails to find the X11 libraries... It even refuses to build when I 
tell them where they are:

% ./configure --with-x --x-libraries=/usr/lib
- You did not tell me what kind of host system you want to configure.
- I will attempt to guess the kind of system this is.
- Looks like this is a mips-sgi-irix6.2
checking for ln -s
checking the configuration name
checking for gcc
checking how to run the C preprocessor
checking for a BSD compatible install
checking for bison
checking for AIX
checking for mach/mach.h
checking for sys/stropts.h
checking for sys/timeb.h
checking for sys/time.h
checking for unistd.h
checking for utime.h
checking for sys/wait.h
checking for libintl.h
checking for locale.h
checking for libgen.h
checking for linux/version.h
checking for ANSI C header files
checking for whether time.h and sys/time.h may both be included
checking for sys_siglist declaration in signal.h or unistd.h
checking for struct utimbuf
checking for return type of signal handlers
checking for struct timeval
checking for struct tm in time.h
checking for tm_zone in struct tm
checking for tzname
checking for lack of working const
checking byte ordering
checking for long file names
checking for -xildoff compiler flag
checking for specified window system
  Using X11.
examining the machine- and system-dependent files to find out
 - which libraries the lib-src programs will want, and
 - whether the GNU malloc routines are usable.
checking for -ldnet
checking for -lXbsd
checking for -lpthreads
checking for XFree86
checking for -lX11
Unable to find X11 libraries.

% ls -l /usr/lib/libX11.so*
lrwxr-xr-x   1 root     sys            11 Feb 12  1996 /usr/lib/libX11.so -> 
libX11.so.1
-rw-r--r--   1 root     sys       1471032 Aug  9 06:40 /usr/lib/libX11.so.1
lrwxr-xr-x   1 root     sys            11 Feb 12  1996 /usr/lib/libX11.so.2 -> 
libX11.so.1



From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 01:36:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA01332 for xemacs-beta-people; Wed, 21 Aug 1996 01:36:28 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA01329 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 01:36:26 -0500 (CDT)
Received: from gsenm5.gsen.goldstar.co.kr ([156.147.207.106]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA01249 for <xemacs-beta@cs.uiuc.edu>; Wed, 21 Aug 1996 01:36:26 -0500 (CDT)
Received: (from jwchoi@localhost) by gsenm5.gsen.goldstar.co.kr (8.6.9H1/8.6.12) id PAA12204; Wed, 21 Aug 1996 15:30:59 +1000
Date: Wed, 21 Aug 1996 15:30:59 +1000
Message-Id: <199608210530.PAA12204@gsenm5.gsen.goldstar.co.kr>
From: "Choi jong won (DM-4338-96.8.1)" <jwchoi@gsen.goldstar.co.kr>
To: xemacs-beta@cs.uiuc.edu
Subject: Xemacs-20.0-b27 with MULE

Hello all,

I build b27(applyed patch from b26), successfully(so far). And have
some questions. 

o The status of mail programs(like vm, rmail, mail) Xemacs with mule
  support. Are they all work well with mule support?

o To me reading Korean characters ok. But can't type(write) Korean
  characters. (I read docs to find how to type, failed. Docs are seems
  to be obsolete now. Anyone has recent docs for configuring mule
  support?)

Jong-won

--
Configured for `sparc-sun-sunos4.1.3_U1'.

  Where should the build process find the source code?    /user1/jwc/XEMACS/xemacs-20.0-b26
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sunos4-1-3shr.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/local/X11R6/include
  Where do we find X Windows libraries?                   /usr/local/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 01:52:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA01357 for xemacs-beta-people; Wed, 21 Aug 1996 01:52:34 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA01354 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 01:52:33 -0500 (CDT)
Received: from max3.rrze.uni-erlangen.de (max3.rrze.uni-erlangen.de [131.188.71.14]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA17891 for <xemacs-beta@xemacs.org>; Wed, 21 Aug 1996 01:52:28 -0500 (CDT)
Received: from mpt307.dialin.rrze.uni-erlangen.de by max3.rrze.uni-erlangen.de; Wed, 21 Aug 96 08:50:23 +0200
Received: (from aoppelt@localhost) by feynman.oppelix.de (8.7.5/8.7.5/oppelix) id IAA02051; Wed, 21 Aug 1996 08:34:24 +0200
Date: Wed, 21 Aug 1996 08:34:24 +0200
Message-Id: <199608210634.IAA02051@feynman.oppelix.de>
From: Achim Oppelt <aoppelt@theorie3.physik.uni-erlangen.de>
To: xemacs-beta@xemacs.org
Subject: 20.0b27 success on Linux 2.0.13

XEmacs 20.0b27 compiled successfully on my Linux 2.0.13 Pentium with libc
5.4.4, XFree86 3.1.2E, MetroLink Motif 2.0. It loads and apparently
displays correctly the mule-doc/ISO2022.jp file. Canna seems to work too. I
haven't tried the XIM support yet (but it is compiled in).

Configured for `i586-oppelix-linux'.

  Where should the build process find the source code?    /fast/XEmacs/xemacs-20
  What installation prefix should install use?		  /fast/XEmacs
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O2 -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /local/include /local/japanese/include
  Additional libraries:                                   /local/lib /local/japanese/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in both network and native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in XIM (X11R5+ I18N input method) support.
  Compiling in Mule (multi-lingual) support.
  Compiling in support for Canna on Mule.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.
  Compiling in code for checking XEmacs memory usage.


Byte compilation apparently failed for some of the .el files (at least
there are no corresponding .elc files). I removed all .elc files before
doing make beta. This is the list of files that weren't compiled:

paths.elc
version.elc
edebug/edebug-test.elc
egg/egg-busyu.elc
egg/egg-jisx0201.elc
egg/egg-jsymbol.elc
egg/egg-keymap.elc
egg/egg-kinsoku.elc
egg/egg-quail.elc
egg/egg-sj3-client.elc
egg/egg-sj3.elc
egg/egg-wnn-client.elc
egg/egg-wnn.elc
egg/egg.elc
emulators/edt.elc
energize/energize-load.elc
energize/write-file.elc
eos/eos.elc
eos/loaddefs-eos.elc
eos/sun-eos.elc
hyperbole/kotl/kprop-em.elc
hyperbole/kotl/kview.elc
hyperbole/kotl/kvspec.elc
hyperbole/hsite-ex.elc
hyperbole/hsite.elc
hyperbole/hsys-www.elc
hyperbole/hui-em19-b.elc
hyperbole/hui-ep-but.elc
hyperbole/hui-epV4-b.elc
hyperbole/hui-xe-but.elc
ilisp/comint-v18.elc
ilisp/ilcompat.elc
ilisp/ilfsf18.elc
ilisp/ilfsf19.elc
ilisp/ilisp-bat.elc
ilisp/ilisp-bug.elc
ilisp/ilisp-chs.elc
ilisp/ilisp-cpat.elc
ilisp/ilisp-mak.elc
ilisp/ilisp-menu.elc
ilisp/ilisp-mnb.elc
ilisp/ilisp-s2c.elc
ilisp/ilisp-src.elc
ilisp/ilisp.elc
ilisp/illuc19.elc
ilisp/ilxemacs.elc
its/its-han-kata.elc
its/its-hangul.elc
its/its-hankaku.elc
its/its-hira.elc
its/its-kanainput.elc
its/its-kata.elc
its/its-pinyin.elc
its/its-zenkaku.elc
its/its-zhuyin.elc
mailcrypt/mc-remail.elc
modes/lisp-mnt.elc
modes/mail-abbrevs.elc
modes/sendmail.elc
mule/arabic.elc
mule/ethiopic.elc
mule/vietnamese-hooks-2.elc
mule/visual-mode.elc
oobr/hash-test.elc
packages/emacsbug.elc
packages/rnewspost.elc
prim/loadup-el.elc
prim/loadup.elc
prim/update-elc.elc
quail/quail-ccdospy.elc
quail/quail-ctcps3.elc
quail/quail-ctlau.elc
quail/quail-ctlaub.elc
quail/quail-cyrillic.elc
quail/quail-ethio.elc
quail/quail-etzy.elc
quail/quail-greek.elc
quail/quail-hangul.elc
quail/quail-hangul3.elc
quail/quail-hanja-jis.elc
quail/quail-hanja-ksc.elc
quail/quail-hebrew.elc
quail/quail-hsymbol.elc
quail/quail-ipa.elc
quail/quail-latin.elc
quail/quail-ltn.elc
quail/quail-punct-b5.elc
quail/quail-punct.elc
quail/quail-py-b5.elc
quail/quail-py.elc
quail/quail-qj-b5.elc
quail/quail-qj.elc
quail/quail-sw.elc
quail/quail-tcode.elc
quail/quail-thai.elc
quail/quail-tit.elc
quail/quail-tonepy.elc
quail/quail-viet.elc
quail/quail-zozy.elc
quail/quail.elc
sunpro/sunpro-load.elc
url/docomp.elc
url/url-sysdp.elc
utils/finder.elc
utils/mailpost.elc
vm/vm-byteopts.elc
vm/vm-search18.elc
vm/vm-search19.elc
w3/docomp.elc
w3/w3-sysdp.elc
w3/w3-xem20.elc

I can send in the log of the compilation if someone is interested; however
it is rather large (100k gzipped and uuencoded). There were lots of
warnings about functions not known to be defined (263), obsolete variables
(895), references to free variables (1606), assignments to free variables
(582), variables bound but not referenced (684), variable reference to
constant (68) and, before dumping xemacs, many (982) Ebola warnings (what
are those?) while temacs was byte-compiling some stuff. There were also
some (45) other warning and error messages. 

Keep up the good work!

Achim

PS: 
How do I get VM to decode those ISO-2022-JP headers that appear in this
mailing list (e.g. From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
MORIOKA Tomohiko <morioka@jaist.ac.jp>).

I guess I'll have to have a look at some of those Japanese newsgroups to
see if they are displayed properly in GNUS ...

Are there any plans to make XEmacs multi-threaded? configure seems to look
for the pthreads library. This would be fun on my SMP system (dual Pentium
100).

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 06:43:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA05383 for xemacs-beta-people; Wed, 21 Aug 1996 06:43:59 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA05380 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 06:43:58 -0500 (CDT)
Received: from fxwidegw.fujixerox.co.jp (root@fxwidegw.fujixerox.co.jp [202.32.191.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA05219 for <xemacs-beta@cs.uiuc.edu>; Wed, 21 Aug 1996 06:43:57 -0500 (CDT)
Received: from fxmxgw.fujixerox.co.jp (root@fxmxgw.fujixerox.co.jp [202.249.14.3]) by fxwidegw.fujixerox.co.jp (8.7.5+(8.7.4)2.6Wbeta6/3.3Wb-05/06/94-1.9) with ESMTP id UAA14908 for <xemacs-beta@cs.uiuc.edu>; Wed, 21 Aug 1996 20:43:50 +0900 (JST)
Received: from dspmailer.dsp.ksp.fujixerox.co.jp ([129.249.53.18]) by fxmxgw.fujixerox.co.jp (8.7.4+2.6Wbeta6/3.1W-02/17/94-fxmxgw/1.7) with SMTP id UAA24904 for <xemacs-beta@cs.uiuc.edu>; Wed, 21 Aug 1996 20:43:49 +0900 (JST)
Received: from haruka.dsp.ksp.fujixerox.co.jp by dspmailer.dsp.ksp.fujixerox.co.jp (4.1/6.4J.6-dspmailer.6.4J-6.1) id AA15185; Wed, 21 Aug 96 20:43:49 JST
Received: from haruka (localhost) by haruka.dsp.ksp.fujixerox.co.jp (5.0/6.4J.6-dsp-sub.6.4J-5.9) id AA08055; Wed, 21 Aug 1996 20:43:07 --900
Message-Id: <9608211143.AA08055@haruka.dsp.ksp.fujixerox.co.jp>
To: xemacs-beta@cs.uiuc.edu
Cc: kiuchi@dsp.ksp.fujixerox.co.jp
Subject: 20.0-b27 for Solaris2.4
Date: Wed, 21 Aug 1996 20:43:06 JST
From: Yasuhiko Kiuchi <kiuchi@dsp.ksp.fujixerox.co.jp>

Hi,

I've finally got a chance to try XEmacs-20.0-beta.

XEmacs-20.0-b27 has succesfully compiled on SPARCS/Solaris2.4 with
MULE and canna support.  I can input Hiragana and Kana-Kanji
conversion works great.  I will try fixing up my .emacs and related
files and will start using it.  Thanks.

Yasuhiko
----------
Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /public/work/src/kiuchi/xemacs-20.0-b27
  What installation prefix should install use?		  /opt/gnu/xemacs-20.0
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              cc -g
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/dt/include /opt/X11R6/include /opt/local/include
  Additional libraries:                                   /usr/dt/lib /opt/X11R6/lib /opt/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Compiling in support for ToolTalk.
  Compiling in Mule (multi-lingual) support.
  Compiling in support for Canna on Mule.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.
----------------------------------------------------------------------

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 09:42:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA05723 for xemacs-beta-people; Wed, 21 Aug 1996 09:42:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA05720 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 09:42:55 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA18467 for <xemacs-beta@xemacs.org>; Wed, 21 Aug 1996 09:42:45 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.7.5/8.7.3) with ESMTP id JAA05599 for <xemacs-beta@xemacs.org>; Wed, 21 Aug 1996 09:41:34 -0500
Message-Id: <199608211441.JAA05599@nvwls.cc.purdue.edu>
To: xemacs-beta@xemacs.org
Subject: Richard Stallman: Emacs
Date: Wed, 21 Aug 1996 09:41:25 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>



------- Forwarded Message

x-gateway: relay3.UU.NET from gnu-emacs-sources to gnu.emacs.sources; Tue, 20 Aug 1996 15:21:17 EDT
Date: Tue, 20 Aug 1996 15:21:01 -0400
Message-ID: <199608201921.PAA24741@psilocin.gnu.ai.mit.edu>
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Emacs
Newsgroups: gnu.emacs.sources
Path: mozo.cc.purdue.edu!purdue!gatech!usenet.eel.ufl.edu!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!wendy-fate.uu.net!gnu-emacs-sources
Sender: gnu-emacs-sources-request@prep.ai.mit.edu
Lines: 5

I'd like to ask people not to use the term "FSF Emacs".  That term was
coined as a put-down by people who maintain a modified version of GNU
Emacs, and who treat the official version as a rival.  If you don't
share that feeling, please don't use words that express it.


------- End of Forwarded Message


Ok.  I vote for eRMacS.  Where the eR is pronounced as in "_Grrrr_
what a pain in the #$$!"


From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 11:12:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA05961 for xemacs-beta-people; Wed, 21 Aug 1996 11:12:00 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA05958 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 11:11:59 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA21271 for <xemacs-beta@cs.uiuc.edu>; Wed, 21 Aug 1996 11:11:59 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id JAA10567; Wed, 21 Aug 1996 09:09:31 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Xemacs-20.0-b27 with MULE
References: <199608210530.PAA12204@gsenm5.gsen.goldstar.co.kr>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: "Choi jong won's message of Wed, 21 Aug 1996 15:30:59 +1000
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII
Date: 21 Aug 1996 09:09:30 -0700
Message-ID: <m2d90klnwl.fsf@deanna.miranova.com>
Lines: 18
X-Mailer: Gnus v5.2.39/XEmacs 19.14

>>>>> "Jong-won" == DM-4338-96 8 1 <Choi> writes:

Jong-won> Hello all,
Jong-won> I build b27(applyed patch from b26), successfully(so far). And have
Jong-won> some questions. 

Jong-won> o The status of mail programs(like vm, rmail, mail) Xemacs
Jong-won>   with mule support. Are they all work well with mule
Jong-won>   support?

Your best bet is to install tm (Tools for MIME), and then it can work
quite well.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 14:04:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA06403 for xemacs-beta-people; Wed, 21 Aug 1996 14:04:38 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA06400 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 14:04:37 -0500 (CDT)
Received: from atreides.erehwon.org (sj@user-168-121-167-78.dialup.mindspring.com [168.121.167.78]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA24677 for <xemacs-beta@cs.uiuc.edu>; Wed, 21 Aug 1996 14:04:38 -0500 (CDT)
Received: (from sj@localhost) by atreides.erehwon.org (8.7.5/8.7.3) id PAA19404; Wed, 21 Aug 1996 15:04:41 -0400
Sender: sj@mindspring.com
To: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Subject: Success on Linux 2.0.13
From: Sudish Joseph <sudish@mindspring.com>
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
Date: 21 Aug 1996 15:04:40 -0400
Message-ID: <m2d90kmud3.fsf@atreides.erehwon.org>
Lines: 46
X-Mailer: Red Gnus v0.12/XEmacs 19.14

Seems to be working fine for the most part.  Problems encountered: 

a) Compiling with --with-xim messes up keyboard-quit.  
In fact, C-g self-inserts irrespective of when it's looked up.  C-x
C-g inserts ^G, ditto for C-c C-g.  I don't know what the option is
supposed to do, so this might be normal.

b) Setting debug-on-error leads to weirdness.  
I had problems with efs and mule-files.el (efs refuses to load with
version 20.0, but seems to hose file loading completely, anyway).
Setting debug-on-error and loading a file to get a trace resulted in
the error being trapped but no backtrace buffer was constructed.

-Sudish

CFLAGS='-g -O2 -mpentium' ./configure --run-in-place
	--with-sound=native  --with-mule  --debug --no-doc-file

Configured for `i586-unknown-linux2.0.13'.

  Where should the build process find the source code?    
					/usr/src/xemacs/xemacs-20.0-b27
  What installation prefix should install use?            ${srcdir}
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O2 -mpentium
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.
  Compiling in code for checking XEmacs memory usage.

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 15:39:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA06611 for xemacs-beta-people; Wed, 21 Aug 1996 15:39:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA06608 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 15:39:36 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA19042 for <xemacs-beta@xemacs.org>; Wed, 21 Aug 1996 15:39:34 -0500 (CDT)
Message-Id: <199608212039.PAA19042@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA277139856; Wed, 21 Aug 1996 21:37:36 +0100
Date: Wed, 21 Aug 1996 21:37:36 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>
Cc: xemacs-beta@xemacs.org
Subject: Re: Richard Stallman: Emacs
In-Reply-To: <199608211441.JAA05599@nvwls.cc.purdue.edu>
References: <199608211441.JAA05599@nvwls.cc.purdue.edu>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Joseph" == Joseph J Nuspl <nuspl@nvwls.cc.purdue.edu> writes:

    RMS> I'd like to ask people not to use the term "FSF Emacs".
    RMS> That term was coined as a put-down by people who maintain
    RMS> a modified version of GNU Emacs, and who treat the
    RMS> official version as a rival.  If you don't share that
    RMS> feeling, please don't use words that express it.

Do you think he would consider RMSmacs a put-down as well ?
(Almost posted that, but I do not want to start a new flame war...).

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 15:55:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA06660 for xemacs-beta-people; Wed, 21 Aug 1996 15:55:00 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA06657 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 15:54:59 -0500 (CDT)
Received: from orion.hrz.tu-freiberg.de (orion.hrz.tu-freiberg.de [139.20.64.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA26593 for <xemacs-beta@cs.uiuc.edu>; Wed, 21 Aug 1996 15:54:52 -0500 (CDT)
Received: from assur.telematik.tu-freiberg.de by orion.hrz.tu-freiberg.de with SMTP
	(1.38.193.5/15.6) id AA10557; Wed, 21 Aug 1996 22:50:55 +0200
Received: by assur.telematik.tu-freiberg.de (SMI-8.6/MLU-s23)
	  id XAA25229; Wed, 21 Aug 1996 23:55:42 GMT
Date: Wed, 21 Aug 1996 23:55:42 GMT
From: Thoralf Polet <polet@assur.telematik.tu-freiberg.de>
Message-Id: <199608212355.XAA25229@assur.telematik.tu-freiberg.de>
To: xemacs-beta@cs.uiuc.edu
Subject: 20.0-b27 for Solaris2.4
X-Sun-Charset: US-ASCII


I just compiled XEmacs-20.0-beta27 using Sun's SparcWorks Compiler.
My plattform resembles a Sun4m running Solaris 2.4.
Everything worked fine, and as far I can see it now, XEmacs is running
properly.

Regards, Thoralf.

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 17:00:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA06883 for xemacs-beta-people; Wed, 21 Aug 1996 17:00:19 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA06880 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 17:00:18 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA19175; Wed, 21 Aug 1996 17:00:16 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id OAA12579; Wed, 21 Aug 1996 14:59:48 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA07633; Wed, 21 Aug 1996 14:59:20 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA19507; Wed, 21 Aug 1996 14:59:13 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA27748; Wed, 21 Aug 1996 14:59:10 -0700
Date: Wed, 21 Aug 1996 14:59:10 -0700
Message-Id: <199608212159.OAA27748@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Valdis.Kletnieks@vt.edu
Cc: Chuck Thompson <cthomp@xemacs.org>, xemacs-beta@xemacs.org
Subject: XEmacs 20.0 beta27 on AIX 4.2
In-Reply-To: <199608202006.QAA19008@black-ice.cc.vt.edu>
References: <199608191826.NAA14625@xemacs.cs.uiuc.edu>
	<199608202006.QAA19008@black-ice.cc.vt.edu>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:

Valdis> ** Warning - I screwed up and tried compiling with 'cc -O3' - this crashed
Valdis> my entire machine twice.  'cc -g' seems to be safe.  I'll follow up on that
Valdis> as well - not sure who's fault it is yet....

I think -O3 is only for the brave when using xlc.
-O2 is more likely to succeed.

When an app crashes the OS without even trying, it's generally
considered an OS bug.

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 18:07:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA07085 for xemacs-beta-people; Wed, 21 Aug 1996 18:07:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA07082 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 18:07:18 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA01002 for <xemacs-beta@cs.uiuc.edu>; Wed, 21 Aug 1996 18:07:21 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id QAA04813; Wed, 21 Aug 1996 16:06:48 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA24840; Wed, 21 Aug 1996 16:06:35 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA21543; Wed, 21 Aug 1996 16:06:32 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA28107; Wed, 21 Aug 1996 16:06:27 -0700
Date: Wed, 21 Aug 1996 16:06:27 -0700
Message-Id: <199608212306.QAA28107@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Sudish Joseph <sudish@mindspring.com>
Cc: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Subject: Success on Linux 2.0.13
In-Reply-To: <m2d90kmud3.fsf@atreides.erehwon.org>
References: <m2d90kmud3.fsf@atreides.erehwon.org>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Sudish" == Sudish Joseph <sudish@mindspring.com> writes:

Sudish> Seems to be working fine for the most part.  Problems encountered: 
Sudish> a) Compiling with --with-xim messes up keyboard-quit.  
Sudish> In fact, C-g self-inserts irrespective of when it's looked up.  C-x
Sudish> C-g inserts ^G, ditto for C-c C-g.  I don't know what the option is
Sudish> supposed to do, so this might be normal.

This patch (likely in b28) should fix the problem:

*** /tmp/geta28089	Wed Aug 21 15:54:53 1996
--- event-stream.c	Wed Aug 21 15:50:41 1996
***************
*** 3070,3081 ****
      return (Vprefix_help_command);
  
  #ifdef HAVE_XIM
!   /* If keysym is a char, then bind it to self-insert-char by default. */
    if (XEVENT_TYPE (builder->most_current_event) == key_press_event
!       && !NILP (Vcomposed_character_default_binding)
!       && CHARP (XEVENT (builder->most_current_event)->event.key.keysym))
!     return Vcomposed_character_default_binding;
! #endif
    
    /* If we read extra events attempting to match a function key but end
       up failing, then we release those events back to the command loop
--- 3070,3084 ----
      return (Vprefix_help_command);
  
  #ifdef HAVE_XIM
!   /* If keysym is a non-ASCII char, bind it to self-insert-char by default. */
    if (XEVENT_TYPE (builder->most_current_event) == key_press_event
!       && !NILP (Vcomposed_character_default_binding))
!     {
!       Lisp_Object keysym = XEVENT (builder->most_current_event)->event.key.keysym;
!       if (CHARP (keysym) && !CHAR_ASCII_P (XCHAR (keysym)))
!         return Vcomposed_character_default_binding;
!     }
! #endif /* HAVE_XIM */
    
    /* If we read extra events attempting to match a function key but end
       up failing, then we release those events back to the command loop

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 21 23:12:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA07774 for xemacs-beta-people; Wed, 21 Aug 1996 23:12:33 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA07771 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 21 Aug 1996 23:12:32 -0500 (CDT)
Received: from brlns0.brl.ntt.jp (brlns0.brl.ntt.jp [163.138.38.10]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA19502 for <xemacs-beta@xemacs.org>; Wed, 21 Aug 1996 23:12:28 -0500 (CDT)
Received: by brlns0.brl.ntt.jp (8.7.5/core*brl.mx14g) with TCP; Thu, 22 Aug 1996 13:12:26 +0900 (JST)
Received: by theory.brl.ntt.jp (8.6.9/core*brl.s11) with TCP; Thu, 22 Aug 1996 13:12:25 +0900
Message-Id: <199608220412.NAA01913@theory.brl.ntt.jp>
To: xemacs-beta@xemacs.org
Subject: 20.0-b7 with MULE success on SUNOS-413U1
X-Mailer: Mew version 1.06 on Emacs 19.28.3, Mule 2.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Thu, 22 Aug 1996 13:12:24 +0900
From: UMEMURA Akihiro <akihiro@theory.brl.ntt.jp>

Hi, I've got a chance to be a new beta tester.
XEmacs-20.0-b7 with following configuration succeeded to be
compiled on my Sparc station 10. 

It runs well, but I found some Japanese-related problems. 
(For example, providing 'mule prevents running w3.)
Is this a correct place to report them? 
Thank you.

Akihiro
------------
% configure --dynamic --with-mule --prefix=/local

Configured for `sparc-sun-sunos4.1.3_U1'.

  Where should the build process find the source code?    /local/src/xemacs-20.0-b27
  What installation prefix should install use?		  /local
  What operating system and machine description files should XEmacs use?
        `s/sunos4-1-3shr.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for GNU DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 02:02:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA08148 for xemacs-beta-people; Thu, 22 Aug 1996 02:02:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA08145 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 02:02:32 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA19704 for <xemacs-beta@xemacs.org>; Thu, 22 Aug 1996 02:02:31 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA03329; Wed, 21 Aug 1996 23:55:57 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA13885; Thu, 22 Aug 1996 08:55:35 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/05Aug96-0532PM)
	id AA25463; Thu, 22 Aug 1996 08:55:35 +0200
Date: Thu, 22 Aug 1996 08:55:35 +0200
Message-Id: <9608220655.AA25463@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: XEmacs 20.0-b27 build success on Digital UNIX V3.2D
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

Hardware  : DEC 3000-500
OS        : Digital UNIX V3.2D (41)
Compiler  : gcc-2.7.2
Libraries : X11R5, Motif
XEmacs    : 20.0-b27 (full kit)

Configured for `alpha-dec-osf3.2'.
  Where should the build process find the source code?    /kits/install/xemacs/xemacs-20.0-b27
  What installation prefix should install use?            /usr/local/xemacs-beta
  What operating system and machine description files should XEmacs use?
        `s/decosf3-2.h' and `m/alpha.h'
  What compiler should XEmacs be built with?              gcc -g2 -O3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? no
  What window system should XEmacs use?                   x11
  Additional header files:                                /kits/install/jpegsrc/release /usr/local/i
nclude
  Additional libraries:                                   /kits/install/jpegsrc/release /usr/local/l
ib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


-- 
Steve Carney        TEL:[41](22)782.90.60  http://www-digital.cern.ch/carney/
carney@gvc.dec.com  FAX:[41](22)782.94.92 

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 02:04:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA08153 for xemacs-beta-people; Thu, 22 Aug 1996 02:04:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA08150 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 02:04:39 -0500 (CDT)
Received: from mikan.jaist.ac.jp ([150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA19709 for <xemacs-beta@xemacs.org>; Thu, 22 Aug 1996 02:04:35 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id QAA25168; Thu, 22 Aug 1996 16:04:35 +0900 (JST)
Message-Id: <199608220704.QAA25168@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.67, tm-view 7.69
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.33
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: xemacs-beta@xemacs.org
Subject: 20.0 b27 with MULE success on SunOS 4.1.3 (shr)
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Thu_Aug_22_16:04:21_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Thu, 22 Aug 1996 16:04:34 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Thu_Aug_22_16:04:21_1996-1
Content-Type: text/plain; charset=US-ASCII

  I succeed to make XEmacs 20.0 b27 on SunOS 4.1.3.

  I tried to make as sunos4-1-3shr, however I don't know how to
specify. So I modifies configure as following:

======================================================================
--- configure-orig	Fri Jun 21 02:48:39 1996
+++ configure	Mon Jun 24 21:57:53 1996
@@ -2225,14 +2225,14 @@
     case "${canonical}" in
       ## The Sun386 didn't get past 4.0.
       i[3-9]86-*-sunos4	   ) opsys=sunos4-0      ;;
+      *-sunos4shr*	   ) opsys=sunos4-0shr   ;;
+      *-sunos4.0shr*	   ) opsys=sunos4-0shr   ;;
+      *-sunos4.1shr*	   ) opsys=sunos4-1shr   ;;
+      *-sunos4.1.2shr*	   ) opsys=sunos4-1-2shr ;;
+      *-sunos4.1.[3-9]shr* ) opsys=sunos4-1-3shr ;;
       *-sunos4.0*	   ) opsys=sunos4-0      ;;
       *-sunos4.1.2*        ) opsys=sunos4-1-2    ;;
       *-sunos4.1.[3-9]*	   ) opsys=sunos4-1-3    ;;
-      *-sunos4shr*	   ) opsys=sunos4-0shr   ;;
-      *-sunos4-0shr*	   ) opsys=sunos4-0shr   ;;
-      *-sunos4-1shr*	   ) opsys=sunos4-1shr   ;;
-      *-sunos4-1-2shr*	   ) opsys=sunos4-1-2shr ;;
-      *-sunos4-1-[3-9]shr* ) opsys=sunos4-1-3shr ;;
       *-sunos4* | *-sunos  ) opsys=sunos4-1	 ;;
 
       *-solaris2.3*	   ) opsys=sol2-3 	 ;;
======================================================================

(My autoconf (2.10) can not convert configure.in. What version of
autoconf supports configure.in of XEmacs?)


----------------------------------------------------------------------
  % ./configure sparc-sun-sunos4.1.3shr --with-mule --site-includes='/usr/local/include/jpeg /usr/local/canna/include' --with-canna --prefix=/usr/local/gnu

Configured for `sparc-sun-sunos4.1.3shr'.

  Where should the build process find the source code?    /tmp_mnt/lab/work8/xemacs-20.0-b27
  What installation prefix should install use?		  /usr/local/gnu
  What operating system and machine description files should XEmacs use?
        `s/sunos4-1-3shr.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/local/X11R6/include
  Where do we find X Windows libraries?                   /usr/local/X11R6/lib
  Additional header files:                                /usr/local/include/jpeg /usr/local/canna/include
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for DBM.
  Compiling in Mule (multi-lingual) support.
  Compiling in support for Canna on Mule.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
--- I protest Chinese nuclear testing --------------------------------
----------------- and virtual testing of United Status and France. ---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key
--pgp-sign-Multipart_Thu_Aug_22_16:04:21_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMhwGfRnuUGV7wuH5AQH6OwP+M/+h13r8NGrtvH537RVQm53CzxANxB0G
kZPx1rJ0jUmsHgRVOP4RgwRUfgKF4Cehi2b0tp2+V58w5Ms+TzvnOP/ncRZFnr9M
MwCnTp5MhFFB6ztjjUzv3EoWczjAa2n+YqoZYGQaAbQfac3/GlHL1w+1k4ZQbdNb
u9VRKopu/vI=
=HE6j
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Aug_22_16:04:21_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 03:03:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA08383 for xemacs-beta-people; Thu, 22 Aug 1996 03:03:55 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA08380 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 03:03:48 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA19779 for <xemacs-beta@xemacs.org>; Thu, 22 Aug 1996 03:03:38 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id RAA28864; Thu, 22 Aug 1996 17:03:37 +0900 (JST)
Message-Id: <199608220803.RAA28864@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.67, tm-view 7.69
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.33
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: xemacs-beta@xemacs.org
Subject: [20.0 b27] decode-coding-string does not work
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Thu_Aug_22_17:03:23_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Thu, 22 Aug 1996 17:03:36 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Thu_Aug_22_17:03:23_1996-1
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Aug_22_17:03:23_1996-1"
Content-Transfer-Encoding: 7bit

--Multipart_Thu_Aug_22_17:03:23_1996-1
Content-Type: text/plain; charset=US-ASCII

  `decode-coding-string' does not work. Definition of
`decode-coding-string' seems expect return value of
`decode-coding-region', however it returns nil even if code-conversion 
is succeeded. So I made following quick patch:


--Multipart_Thu_Aug_22_17:03:23_1996-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="mule-coding.el.diff"
Content-Transfer-Encoding: 7bit

--- mule-coding.el-orig	Thu May 16 21:26:08 1996
+++ mule-coding.el	Thu Aug 22 02:45:44 1996
@@ -54,9 +54,9 @@
 	  (set-buffer tempbuf)
 	  (erase-buffer)
 	  (insert str)
-	  (setq result (decode-coding-region (point-min) (point-max)
-					     coding-system)))
-      (if result
+	  (decode-coding-region (point-min) (point-max) coding-system)
+	  )
+      (if (> (point-max)(point-min))
 	  (setq result (buffer-string)))
       (set-buffer curbuf)
       (kill-buffer tempbuf))

--Multipart_Thu_Aug_22_17:03:23_1996-1
Content-Type: text/plain; charset=US-ASCII


  Maybe it seems bug of `decode-coding-region' so it seems better to
fix `decode-coding-region' instead of this patch.

  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
--- I protest Chinese nuclear testing --------------------------------
----------------- and virtual testing of United Status and France. ---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key
--Multipart_Thu_Aug_22_17:03:23_1996-1--

--pgp-sign-Multipart_Thu_Aug_22_17:03:23_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMhwUUhnuUGV7wuH5AQGc2AQAtNdfN9zmzCxrEXfP8Cqe7fP3Y5SSO5Vj
uZNfguK2QxzVP1YUwjKYYnM205sS8WefaTG9RGlPSklnrSqjp21kBwH5R7qhoRts
reV4V1lLsZK39XianlRVNnzuyP9V1WCsYtPoxQXklx8Yj8alBsFVnvivQNoFnRTf
b/ZJbEgE8/g=
=fwGQ
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Aug_22_17:03:23_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 07:41:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA12702 for xemacs-beta-people; Thu, 22 Aug 1996 07:41:31 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA12699 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 07:41:29 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA22619 for <xemacs-beta@cs.uiuc.edu>; Thu, 22 Aug 1996 07:41:29 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id NAA09277 for <xemacs-beta@cs.uiuc.edu>; Thu, 22 Aug 1996 13:41:27 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id NAA21475 for <xemacs-beta@cs.uiuc.edu>; Thu, 22 Aug 1996 13:43:11 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id NAA22665; Thu, 22 Aug 1996 13:47:22 +0100
Date: Thu, 22 Aug 1996 13:47:22 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199608221247.NAA22665@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: tm?
X-Sun-Charset: US-ASCII

Where can I find this?

andy

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 07:18:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA12600 for xemacs-beta-people; Thu, 22 Aug 1996 07:18:31 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA12597 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 07:18:30 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA22401 for <xemacs-beta@cs.uiuc.edu>; Thu, 22 Aug 1996 07:18:30 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id VAA10069; Thu, 22 Aug 1996 21:18:27 +0900 (JST)
Message-Id: <199608221218.VAA10069@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.67, tm-view 7.69
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.33
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: xemacs-beta@cs.uiuc.edu
Subject: [20.0-b27 with mule] string-match problem
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Thu_Aug_22_21:17:53_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Thu, 22 Aug 1996 21:18:24 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Thu_Aug_22_21:17:53_1996-1
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Aug_22_21:17:53_1996-1"
Content-Transfer-Encoding: 7bit

--Multipart_Thu_Aug_22_21:17:53_1996-1
Content-Type: text/plain; charset=US-ASCII

  When regexp is [^CHARASTERS] and first character of string is
non-ASCII character, XEmacs crashes.

  For example:


--Multipart_Thu_Aug_22_21:17:53_1996-1
Content-Type: text/plain; charset=ISO-2022-JP

Fatal error: assertion failed, file insdel.c, \
line 367, ptr == end

(snip)

Lisp backtrace follows:

  string-match("[^a]" "$B$"(B")
  eval((string-match "[^a]" "$B$"(B"))
  # bind (expr)
  eval-interactive((string-match "[^a]" "$B$"(B"))
  # bind (stab standard-output opoint eval-last-sexp-arg-internal)
  eval-last-sexp(t)
  # bind (standard-output)
  #<compiled-function (from "lisp-mode.elc") nil "...(20)" [standard-output ter\
pri eval-last-sexp t] 2 811763 nil>()
  call-interactively(eval-print-last-sexp)
  # (condition-case ... . error)
  # (catch top-level ...)
^M
[1]    IOT trap               canna-xemacs

--Multipart_Thu_Aug_22_21:17:53_1996-1
Content-Type: text/plain; charset=ISO-2022-JP

Lisp backtrace follows:

  string-match("[^ ]" "$B$"(B")
  eval((string-match "[^ ]" "$B$"(B"))
  # bind (expr)
  eval-interactive((string-match "[^ ]" "$B$"(B"))
  # bind (stab standard-output opoint eval-last-sexp-arg-internal)
  eval-last-sexp(t)
  # bind (standard-output)
  #<compiled-function (from "lisp-mode.elc") nil "...(20)" [standard-output ter\
pri eval-last-sexp t] 2 811763 nil>()
  call-interactively(eval-print-last-sexp)
  # (condition-case ... . error)
  # (catch top-level ...)
^M
[1]    IOT trap               canna-xemacs

--Multipart_Thu_Aug_22_21:17:53_1996-1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Lisp backtrace follows:

  string-match("[^ ]" "=F6hlich!")
  eval((string-match "[^ ]" "=F6hlich!"))
  # bind (expr)
  eval-interactive((string-match "[^ ]" "=F6hlich!"))
  # bind (stab standard-output opoint eval-last-sexp-arg-internal)
  eval-last-sexp(t)
  # bind (standard-output)
  #<compiled-function (from "lisp-mode.elc") nil "...(20)" [standard-output=
 ter\
pri eval-last-sexp t] 2 811763 nil>()
  call-interactively(eval-print-last-sexp)
  # (condition-case ... . error)
  # (catch top-level ...)
^M
[1]    IOT trap               canna-xemacs

--Multipart_Thu_Aug_22_21:17:53_1996-1
Content-Type: text/plain; charset=US-ASCII

OS: SunOS 4.1.3

Configured for `sparc-sun-sunos4.1.3shr'.

  Where should the build process find the source code?    /tmp_mnt/lab/work8/xemacs-20.0-b27
  What installation prefix should install use?		  /usr/local/gnu
  What operating system and machine description files should XEmacs use?
        `s/sunos4-1-3shr.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/local/X11R6/include
  Where do we find X Windows libraries?                   /usr/local/X11R6/lib
  Additional header files:                                /usr/local/include/jpeg /usr/local/canna/include
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for DBM.
  Compiling in Mule (multi-lingual) support.
  Compiling in support for Canna on Mule.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
--- I protest Chinese nuclear testing --------------------------------
----------------- and virtual testing of United Status and France. ---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key
--Multipart_Thu_Aug_22_21:17:53_1996-1--

--pgp-sign-Multipart_Thu_Aug_22_21:17:53_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMhxQBRnuUGV7wuH5AQHdjwP/XEJ7UTw/OIbgANrM9/0skco7v03nqs1B
6mqEW5ore8JvlCDeFP+tuAwFlzx3m1MVGbn+odtszQNIPFQVKgGdH6bJKGws7ons
rkBxYvy1d0Txts1iiWJ5p/HOXork5qHNSLtyFRomVRfOfs5lCzbx+bxWmhmgh2dU
g3hqhMNB90E=
=7KY0
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Aug_22_21:17:53_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 08:02:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA12751 for xemacs-beta-people; Thu, 22 Aug 1996 08:02:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA12748 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 08:02:19 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA24014 for <xemacs-beta@cs.uiuc.edu>; Thu, 22 Aug 1996 08:02:19 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id WAA11383; Thu, 22 Aug 1996 22:02:17 +0900 (JST)
Message-Id: <199608221302.WAA11383@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.67, tm-view 7.69
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.33
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Xemacs-20.0-b27 with MULE 
In-reply-to: Your message of "Wed, 21 Aug 1996 15:30:59 +1000."
             <199608210530.PAA12204@gsenm5.gsen.goldstar.co.kr> 
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Thu_Aug_22_22:01:58_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Thu, 22 Aug 1996 22:02:15 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Thu_Aug_22_22:01:58_1996-1
Content-Type: text/plain; charset=US-ASCII

>>>>> In <199608210530.PAA12204@gsenm5.gsen.goldstar.co.kr> 
>>>>>	"Choi jong won (DM-4338-96.8.1)" <jwchoi@gsen.goldstar.co.kr> wrote:

Choi> o To me reading Korean characters ok. But can't type(write)
Choi>   Korean characters. (I read docs to find how to type,
Choi>   failed. Docs are seems to be obsolete now. Anyone has recent
Choi>   docs for configuring mule support?)

  In original MULE, there are two way to input Korean. One is Wnn +
egg. It uses kserver of Wnn. Another way is to use quail package.
Quail is virtual keyboard system. It supports to select virtual
keyboard. There are two quail package to input Hangul and one package
to input Hanja (KS C5601-1987; there is package to input JIS X0208
Kanji by Hanja way).

  Unfortunately, both way are not ported yet.

  Quail is simple system. However original MULE is based on EMACS so
quail is depended on EMACS. So there is problems of incompatibility
between EMACS and XEmacs (ex. overlay vs. extent, keymap
format). Quail is very important system. It is available not only
Korean but also another languages such as European Languages uses
Latin, Cyrillic or Greek scripts. So it is important to port.

  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
--- I protest Chinese nuclear testing --------------------------------
----------------- and virtual testing of United Status and France. ---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key

--pgp-sign-Multipart_Thu_Aug_22_22:01:58_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMhxaUBnuUGV7wuH5AQEyJAP/cTV+qYttfbKOIR+o+v4AqlP120V2WfPO
abf3bp10ldeeHUF2ANMBGpZyq/hkuLfIfAIF0PzxIKzR+xC72Owt+kncRnLDyqO3
9Ts2cjPIok0rBEvXkv3++JHv84Fd1jRpHGaA+6otnPGAaXPeN735CBGs+GmItceV
m9wjAf+wnfc=
=vEwP
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Aug_22_22:01:58_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 08:05:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA12759 for xemacs-beta-people; Thu, 22 Aug 1996 08:05:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA12756 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 08:05:39 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA25858 for <xemacs-beta@cs.uiuc.edu>; Thu, 22 Aug 1996 08:05:37 -0500 (CDT)
Received: from is28e1s91.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id WAA11504; Thu, 22 Aug 1996 22:05:34 +0900 (JST)
Message-Id: <199608221305.WAA11504@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.67, tm-view 7.69
X-Emacs: Mule 2.3 =?ISO-2022-JP?B?KBskQkt2RSYyVhsoQik=?= based on 19.33
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: tm? 
In-reply-to: Your message of "Thu, 22 Aug 1996 13:47:22 +0100."
             <199608221247.NAA22665@wrath.parallax.co.uk> 
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Thu_Aug_22_22:05:22_1996-2"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Thu, 22 Aug 1996 22:05:33 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Thu_Aug_22_22:05:22_1996-2
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Aug_22_22:05:22_1996-2"
Content-Transfer-Encoding: 7bit

--Multipart_Thu_Aug_22_22:05:22_1996-2
Content-Type: text/plain; charset=US-ASCII

>>>>> In <199608221247.NAA22665@wrath.parallax.co.uk> 
>>>>>	andyp@parallax.co.uk (Andy Piper) wrote:

Andy> Where can I find this?


--Multipart_Thu_Aug_22_22:05:22_1996-2
Content-Type: multipart/alternative;
 boundary="Multipart_Thu_Aug_22_22:05:22_1996-1"
Content-Transfer-Encoding: 7bit

--Multipart_Thu_Aug_22_22:05:22_1996-1
Content-Type: text/plain; charset=US-ASCII


  It is available from

	ftp://ftp.jaist.ac.jp/pub/GNU/elisp/mime/beta/	(Japan)

or its mirrors

	ftp://ftp.nis.co.jp/pub/gnu/emacs-lisp/tm/beta/	(Japan)
	ftp://ftp.nisiq.net/pub/gnu/emacs-lisp/tm/beta/	(US)
	ftp://ftp.miranova.com/pub/gnus/jaist.ac.jp/	(US)
	ftp://ftp.unicamp.br/pub/mail/mime/tm		(Brazil)

Or following site is available in Europe:

	ftp://ftp.tnt.uni-hannover.de/pub/editors/xemacs/contrib/

If you know another mirrors, please teach me.


--Multipart_Thu_Aug_22_22:05:22_1996-1
Content-Type: message/external-body;
	access-type=anon-ftp;
	site="ftp.jaist.ac.jp";
	directory="/pub/GNU/elisp/mime/beta";
	name="tm7.78.tar.gz";
	mode=image

Content-Type: application/octet-stream;
	name="tm7.78.tar.gz";
	type=tar;
	conversions=gzip

--Multipart_Thu_Aug_22_22:05:22_1996-1--

--Multipart_Thu_Aug_22_22:05:22_1996-2
Content-Type: text/plain; charset=US-ASCII

-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
--- I protest Chinese nuclear testing --------------------------------
----------------- and virtual testing of United Status and France. ---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key
--Multipart_Thu_Aug_22_22:05:22_1996-2--

--pgp-sign-Multipart_Thu_Aug_22_22:05:22_1996-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMhxbGhnuUGV7wuH5AQGrwQQAnKqUEdRwnubqb5EOGuYOlvfjReCqZH47
BlTWS7+cLvrSaMZYycaciOpNhW6LTdxrevyitak4OCnnXqL6PetfK+cKDdkxv8wm
UaT+elaveWSAINTBoHR1DPWQfPApoOU1A2Yf26oVrA3lRp4SNZr5N87CC0lpoVEi
nZJc78IXFrI=
=ZpP6
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Aug_22_22:05:22_1996-2--

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 19:58:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA15269 for xemacs-beta-people; Thu, 22 Aug 1996 19:58:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA15266 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 19:58:24 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA15872 for <xemacs-beta@cs.uiuc.edu>; Thu, 22 Aug 1996 19:58:25 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id RAA29572; Thu, 22 Aug 1996 17:55:54 -0700
Sender: steve@miranova.com
To: Simon Marshall <Simon.Marshall@esrin.esa.it>
Cc: xemacs-beta@cs.uiuc.edu
Subject: font-lock (was Re: Xemacs features in GNUEmacs)
References: <redhouseDwAH8n.7Lp@netcom.com> <hrenl5vgzn.fsf@branagh.lanl.gov>
	<m2sp9lnz0q.fsf@deanna.miranova.com> <hrafvtthft.fsf@branagh.lanl.gov>
	<m220h48u76.fsf@deanna.miranova.com>
	<61g25jthru.fsf@anthem.cnri.reston.va.us>
	<wrpw4jx4at.fsf@esrin.esa.it>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Simon Marshall's message of 22 Aug 1996 09:32:10 +0200
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII
Date: 22 Aug 1996 17:55:52 -0700
Message-ID: <m2enky6hrb.fsf_-_@deanna.miranova.com>
Lines: 64
X-Mailer: Gnus v5.2.39/XEmacs 19.14

(I propose the following change for XEmacs 19.15)

>>>>> "Simon" == Simon Marshall <Simon.Marshall@esrin.esa.it> writes:

Simon> Maybe if Steven can explain how fast-lock.el loses, I will see
Simon> if I can fix it.

The second method I described where fast-lock (and font-lock) were
losing for me is where font-lock needs to be aware of more than just
the current line in order to color correctly.  This is of utmost
importance to me, as wrong or inconsistent coloring slows me down a
lot.

I've done a little experimentation with
font-lock-after-change-function-1 and have come up with something
which should be totally transparent if you want the current behavior
(one line font-locked while typing), but expandable to a customizable
region if that is what you want.

Here is the patch for XEmacs (a patch to the font-lock.el in Emacs
19.33 would be similar):

--- font-lock.el.orig	Sun Jun  9 08:49:39 1996
+++ font-lock.el	Thu Aug 22 17:43:30 1996
@@ -806,6 +806,16 @@
     (if font-lock-always-fontify-immediately
 	(font-lock-fontify-glumped-region))))
 
+(defvar font-lock-region-after 1
+  "Number of lines to consider for font lock changes during
+data entry.  A value of 1 means consider up to the end of the
+current line.")
+
+(defvar font-lock-region-before nil
+  "Number of lines to consider for font lock changes during
+data entry.  A value of nil means consider back to the beginning of
+the current line.")
+
 (defun font-lock-after-change-function-1 (beg end old-len)
   (if (null font-lock-mode)
       nil
@@ -827,10 +837,10 @@
 
 	    ;; Always recompute the whole line.
 	    (goto-char end)
-	    (forward-line 1)
+	    (forward-line font-lock-region-after)
 	    (setq end (point))
 	    (goto-char beg)
-	    (beginning-of-line)
+	    (beginning-of-line font-lock-region-before)
 	    (setq beg (point))
 	    ;; Rescan between start of line from `beg' and start of line after
 	    ;; `end'.


Is adding this acceptable?

Regards,
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 20:31:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA15375 for xemacs-beta-people; Thu, 22 Aug 1996 20:31:46 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA15372 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 20:31:45 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA21485 for <xemacs-beta@cs.uiuc.edu>; Thu, 22 Aug 1996 20:31:46 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id SAA29868; Thu, 22 Aug 1996 18:29:25 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [comp.emacs,comp.emacs.xemacs] Re: Xemacs features in GNUEmacs
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Aug_22_18:29:23_1996-1"
Content-Transfer-Encoding: 7bit
Date: 22 Aug 1996 18:29:23 -0700
Message-ID: <m2bug26g7g.fsf@deanna.miranova.com>
Lines: 56
X-Mailer: Gnus v5.2.39/XEmacs 19.14

--Multipart_Thu_Aug_22_18:29:23_1996-1
Content-Type: text/plain; charset=US-ASCII

This is a minor bugfix to fast-lock.el that shouldn't get lost.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

--Multipart_Thu_Aug_22_18:29:23_1996-1
Content-Type: message/rfc822

From: Steven L Baur <steve@miranova.com>
Newsgroups: comp.emacs,comp.emacs.xemacs
Subject: Re: Xemacs features in GNUEmacs
Date: 22 Aug 1996 14:42:48 -0700
Organization: XEmacs Advocacy Group
Message-ID: <m2d90j14fb.fsf@deanna.miranova.com>
References: <redhouseDwAH8n.7Lp@netcom.com> <hrenl5vgzn.fsf@branagh.lanl.gov>
	<m2sp9lnz0q.fsf@deanna.miranova.com> <hrafvtthft.fsf@branagh.lanl.gov>
	<m220h48u76.fsf@deanna.miranova.com>
	<61g25jthru.fsf@anthem.cnri.reston.va.us>
	<wrpw4jx4at.fsf@esrin.esa.it>
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII
Mail-Copies-To: never

>>>>> "Simon" == Simon Marshall <Simon.Marshall@esrin.esa.it> writes:

Simon> Maybe if Steven can explain how fast-lock.el loses, I will see
Simon> if I can fix it.

Easily fixed as it turns out.  There are some font-lock faces that
fast-lock doesn't know about:

--- fast-lock.el.orig	Tue Jan 30 20:20:03 1996
+++ fast-lock.el	Thu Aug 22 14:36:35 1996
@@ -224,6 +224,7 @@
   (if (save-match-data (string-match "XEmacs" (emacs-version)))
       '(font-lock-string-face font-lock-doc-string-face font-lock-type-face
 	font-lock-function-name-face font-lock-comment-face
+	font-lock-reference-face font-lock-variable-name-face
 	font-lock-keyword-face font-lock-preprocessor-face)
     ;; For Emacs 19.30 I don't think this is generally necessary.
     nil)

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.


--Multipart_Thu_Aug_22_18:29:23_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 21:24:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA15510 for xemacs-beta-people; Thu, 22 Aug 1996 21:24:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA15507 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 21:24:54 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA21481 for <xemacs-beta@xemacs.org>; Thu, 22 Aug 1996 21:24:52 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id WAA09261; Thu, 22 Aug 1996 22:24:29 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp009236; Thu Aug 22 22:24:11 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA27757; Thu, 22 Aug 96 22:24:09 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA16868; Thu, 22 Aug 96 22:24:00 EDT
Message-Id: <9608230224.AA16868@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Even your dog won't like it.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: cognot@ensg.u-nancy.fr
Cc: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>, xemacs-beta@xemacs.org
Subject: Re: Richard Stallman: Emacs 
In-Reply-To: Your message of "Wed, 21 Aug 1996 21:37:36 BST."
             <199608212039.PAA19042@xemacs.cs.uiuc.edu> 
Date: Thu, 22 Aug 1996 22:23:55 -0400
Sender: rickc@lehman.com

-----BEGIN PGP SIGNED MESSAGE-----

    Date: Wed, 21 Aug 1996 21:37:36 +0100
    From: Richard Cognot <cognot@ensg.u-nancy.fr>
    
    >>>>> "Joseph" == Joseph J Nuspl <nuspl@nvwls.cc.purdue.edu> writes:
    
        RMS> I'd like to ask people not to use the term "FSF Emacs".
        RMS> That term was coined as a put-down by people who maintain
        RMS> a modified version of GNU Emacs, and who treat the
        RMS> official version as a rival.  If you don't share that
        RMS> feeling, please don't use words that express it.
    
    Do you think he would consider RMSmacs a put-down as well ?
    (Almost posted that, but I do not want to start a new flame war...).

This is pretty old news and he has previously explicitly nixed
RMSmacs.  RMS doesn't like any other names besides "GNU Emacs" and
"Emacs".  He has more or less admitted that both terms are ambigious,
i. e. that either applies to other emacsen such as XEmacs.

As far as I know, he has not objected to his version being called
"FSF's GNU Emacs".

Two things that are new to me from this round are that RMS now has
some notion of his version being `official' in some sense (?!) and
that he's only asking for people who don't share a particular feeling
to avoid using the phrase "FSF Emacs".  Previously he's asked that
everyone avoid the term.

			Rick

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMh0VpltTztlqB385AQEukgP+Iii5e8VvmRZy4PlkSBXu2/EgIbXxmuJd
DrulDd9LlM4lE8stnnQzwA6r4E7hoMnCy9iTDgk1xTsGDQRBWawZsriEDJIOlSRf
+fv2/v3M1Zu63UWH8Ph0Y+U952LN18TFlJ4Q0MbaOO0a1cLxCcsEqN8xNDFfH+HB
a3blyrngX+8=
=rbNl
-----END PGP SIGNATURE-----

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 22 21:31:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA15540 for xemacs-beta-people; Thu, 22 Aug 1996 21:31:35 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA15537 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 22 Aug 1996 21:31:34 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA21486 for <xemacs-beta@xemacs.org>; Thu, 22 Aug 1996 21:31:33 -0500 (CDT)
Message-Id: <199608230231.VAA21486@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA283907455; Fri, 23 Aug 1996 03:30:55 +0100
Date: Fri, 23 Aug 1996 03:30:55 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Rick Campbell <rickc@lehman.com>
Cc: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>, xemacs-beta@xemacs.org
Subject: Re: Richard Stallman: Emacs 
In-Reply-To: <9608230224.AA16868@cfdevx1.lehman.com>
References: <199608212039.PAA19042@xemacs.cs.uiuc.edu>
	<9608230224.AA16868@cfdevx1.lehman.com>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:

    Rick> -----BEGIN PGP SIGNED MESSAGE----- Date: Wed, 21 Aug 1996
    Rick> 21:37:36 +0100 From: Richard Cognot <cognot@ensg.u-nancy.fr>
    
    >>>>>> "Joseph" == Joseph J Nuspl <nuspl@nvwls.cc.purdue.edu>
    >>>>>> writes:
        
    Me>     Do you think he would consider RMSmacs a put-down as
    Me> well ?  (Almost posted that, but I do not want to start a
    Me> new flame war...).

    Rick> This is pretty old news and he has previously explicitly
    Rick> nixed RMSmacs.
[...]

I know that, but what I was thinking of was, would he consider a name
based on his own name a put-down? ;-)

Maybe it's only french sense of humour...

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Fri Aug 23 02:55:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA16069 for xemacs-beta-people; Fri, 23 Aug 1996 02:55:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA16066 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 23 Aug 1996 02:55:55 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA21780 for <xemacs-beta@xemacs.org>; Fri, 23 Aug 1996 02:55:51 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Fri, 23 Aug 1996 09:55:32 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id JAA11181; Fri, 23 Aug 1996 09:55:18 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id JAA20444;
          Fri, 23 Aug 1996 09:53:00 +0200
Sender: muenkel@daedalus.tnt.uni-hannover.de
To: xemacs-beta@xemacs.org
Subject: [gnu.emacs.sources] Re: Emacs
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: message/rfc822
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
Date: 23 Aug 1996 09:52:59 +0200
Message-ID: <on686av8o4.fsf@daedalus.tnt.uni-hannover.de>
Lines: 10
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Date: Wed, 21 Aug 1996 12:33:19 -0400
Message-ID: <199608211633.MAA32536@psilocin.gnu.ai.mit.edu>
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Re: Emacs
Newsgroups: gnu.emacs.sources

Distinguishing the two versions is certainly necessary.  I do it by
writing GNU Emacs and GNU XEmacs, or, in contexts where there is no
problem of confusion with other Emacs implementations (which is most
of the time), just Emacs and XEmacs.

From xemacs-beta-request@cs.uiuc.edu  Fri Aug 23 09:43:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA20420 for xemacs-beta-people; Fri, 23 Aug 1996 09:43:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA20417 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 23 Aug 1996 09:43:35 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA22320 for <xemacs-beta@xemacs.org>; Fri, 23 Aug 1996 09:43:29 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA19148; Fri, 23 Aug 1996 07:37:29 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA14975; Fri, 23 Aug 1996 16:37:21 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/05Aug96-0532PM)
	id AA11384; Fri, 23 Aug 1996 16:37:18 +0200
Date: Fri, 23 Aug 1996 16:37:18 +0200
Message-Id: <9608231437.AA11384@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: asynch subprocess dumps
In-Reply-To: <9606270735.AA26977@fornet.gvc.dec.com>
References: <9606270735.AA26977@fornet.gvc.dec.com>
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

carney@gvc.dec.com (Stephen Carney) writes,
in <9606270735.AA26977@fornet.gvc.dec.com>:

>I got another filedesc_to_what_closure dump under 19.14 in a tty.
>It's not easily reproducible, but it seems to have something to do with
>subprocess interaction.  In this particular case, I had been running vm,
>and then quit.  While editing a file, I did M-x shell and got the dump.
>I've gotten a couple of these when doing M-x shell.

I'm still getting these dumps in 19.14 whenever I turn on a private hack
for audio notification for new messages in vm.  In a function called
through vm-arrived-messages-hook, I create an asynchronous subprocess
that announces the number of new messages.  Sometimes the asynch
notification subprocess induces the crash (under 50% of the time).

When the notification subprocess is synchronous, however, I don't seem
to get a dump, but the XEmacs vm frame will freeze.  Sometimes when it
freezes, I can do C-g or C-Sh-g and everything is fine.  After a C-g, I
think I've seen it update the INBOX Summary window when the frame
un-freezes (the documentation for vm-arrived-messages-hook says: "the
new messages will have already been added to the message list but may
not yet appear in the summary").  So, updating the INBOX Summary window
during/after my subprocess runs is expected.  Other times when the frame
freezes, there's nothing I can do to un-freeze it (kill XEmacs and start
again).

Just a guess, but could there be a bogus interaction between creating a
subprocess and updating the display?

When running under a tty, I thought it was a little strange to see
emacs_Xt_select_process in the stack trace.  Isn't stuff from event-Xt.c
only used for an X11 interface?

The same problem exists under 20.0-b27.

Anyway, here another similar dump...


Fatal error: assertion failed, file event-Xt.c, line 1545, !filedesc_to_what_closure[fd]

Fatal error (6).
Your files have been auto-saved.
[...]

% dbx /usr/local/xemacs/bin/alpha-dec-osf3.2/xemacs-19.14 core
dbx version 3.11.8
Type 'help' for help.
Core file created by program "xemacs-19.14"

signal IOT/Abort trap at >*[__kill, 0x3ff8010ce68] 	beq	r19, 0x3ff8010ce80
(dbx) where
where
>  0 __kill(0x120086844, 0x6, 0x14042f620, 0x0, 0x14047b0081) [0x3ff8010ce68]
   1 fatal_error_signal(sig = 10707) ["emacs.c":193, 0x120086860]
   2 __kill(0x3ffc00802f0, 0x30000, 0x120000000, 0x0, 0x0) [0x3ff8010ce64]
   3 raise(0x6, 0x0, 0x2, 0x11fff8de0, 0x59) [0x3ff80121830]
   4 abort(0x7c04, 0x3ff800e0ca8, 0x59, 0x1200867a0, 0x0) [0x3ff8010fc80]
   5 assert_failed(file = 0x29d3, line = 6, expr = 0x11fff93d0 = "\240g^H ^A") ["emacs.c":1830, 0x120088ecc]
   6 emacs_Xt_select_process(p = 0x1406729000) ["event-Xt.c":1612, 0x12016ec54]
   7 event_stream_select_process(proc = 0x29d3) ["event-stream.c":545, 0x12009eb60]
   8 create_process(process = (...), new_argv = 0x11fff9518, current_dir = 0x140b64440 = "/usr/users/carney/Mail") ["process.c":1044, 0x120114ad4]
   9 Fstart_process_internal(nargs = 5, args = 0x11fff9730) ["process.c":1221, 0x120115004]
  10 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fff9728) ["eval.c":3191, 0x120091460]
  11 Fapply(nargs = 5, args = 0x11fff98d0) ["eval.c":3471, 0x120092280]
  12 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fff98c8) ["eval.c":3191, 0x120091460]
  13 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  14 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  15 funcall_lambda(fun = (...), nargs = 5, arg_vector = 0x11fff9e20) ["eval.c":3636, 0x120092f94]
  16 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fff9e18) ["eval.c":3223, 0x1200916a8]
  17 Fapply(nargs = 5, args = 0x11fff9fc0) ["eval.c":3471, 0x120092280]
  18 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fff9fb8) ["eval.c":3191, 0x120091460]
  19 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  20 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  21 funcall_lambda(fun = (...), nargs = 4, arg_vector = 0x11fffa530) ["eval.c":3636, 0x120092f94]
  22 funcall_recording_as(recorded_as = (...), nargs = 4, args = 0x11fffa528) ["eval.c":3223, 0x1200916a8]
  23 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  24 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  25 funcall_lambda(fun = (...), nargs = 5, arg_vector = 0x11fffaaa8) ["eval.c":3636, 0x120092f94]
  26 funcall_recording_as(recorded_as = (...), nargs = 5, args = 0x11fffaaa0) ["eval.c":3223, 0x1200916a8]
  27 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  28 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  29 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffb020) ["eval.c":3636, 0x120092f94]
  30 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffb018) ["eval.c":3223, 0x1200916a8]
  31 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  32 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  33 funcall_lambda(fun = (...), nargs = 2, arg_vector = 0x11fffb598) ["eval.c":3636, 0x120092f94]
  34 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffb590) ["eval.c":3223, 0x1200916a8]
  35 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  36 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  37 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffbaf0) ["eval.c":3636, 0x120092f94]
  38 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffbae8) ["eval.c":3223, 0x1200916a8]
  39 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  40 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  41 funcall_lambda(fun = (...), nargs = 8, arg_vector = 0x11fffc098) ["eval.c":3636, 0x120092f94]
  42 funcall_recording_as(recorded_as = (...), nargs = 8, args = 0x11fffc090) ["eval.c":3223, 0x1200916a8]
  43 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  44 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  45 funcall_lambda(fun = (...), nargs = 4, arg_vector = 0x11fffc620) ["eval.c":3636, 0x120092f94]
  46 funcall_recording_as(recorded_as = (...), nargs = 4, args = 0x11fffc618) ["eval.c":3223, 0x1200916a8]
  47 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  48 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  49 funcall_lambda(fun = (...), nargs = 0, arg_vector = 0x11fffcb98) ["eval.c":3636, 0x120092f94]
  50 funcall_recording_as(recorded_as = (...), nargs = 0, args = 0x11fffcb90) ["eval.c":3223, 0x1200916a8]
  51 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  52 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  53 funcall_lambda(fun = (...), nargs = 0, arg_vector = 0x11fffd0e8) ["eval.c":3636, 0x120092f94]
  54 funcall_recording_as(recorded_as = (...), nargs = 0, args = 0x11fffd0e0) ["eval.c":3223, 0x1200916a8]
  55 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  56 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  57 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffd650) ["eval.c":3636, 0x120092f94]
  58 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffd648) ["eval.c":3223, 0x1200916a8]
  59 call1(fn = (...), arg0 = (...)) ["eval.c":3992, 0x120093a60]
  60 execute_internal_event(event = (...)) ["event-stream.c":2817, 0x1200a302c]
  61 Fsit_for(seconds = (...), nodisplay = (...)) ["event-stream.c":2629, 0x1200a2b8c]
  62 primitive_funcall(fn = 0x3ff8010fc20, nargs = 536843216, args = (nil)) ["eval.c":3486, 0x120092350]
  63 funcall_subr(subr = 0x6, args = 0x11fff93d0) ["eval.c":3526, 0x120092648]
  64 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffd870) ["eval.c":3207, 0x1200914f4]
  65 Ffuncall(nargs = 6, args = 0x11fff93d0) ["eval.c":3253, 0x120091784]
  66 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006115c]
  67 primitive_funcall(fn = 0x3ff8010fc20, nargs = 536843216, args = (nil)) ["eval.c":3488, 0x120092370]
  68 funcall_subr(subr = 0x6, args = 0x11fff93d0) ["eval.c":3526, 0x120092648]
  69 Feval(form = (...)) ["eval.c":3064, 0x120090cf4]
  70 condition_case_1(handlers = (...), bfun = 0x1200903c0, barg = (...), hfun = 0x12008c318, harg = (...)) ["eval.c":1672, 0x12008c2a0]
  71 Fcondition_case_3(bodyform = (...), var = (...), handlers = (...)) ["eval.c":1735, 0x12008c6c8]
  72 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":655, 0x120061724]
  73 funcall_lambda(fun = (...), nargs = 0, arg_vector = 0x11fffe880) ["eval.c":3636, 0x120092f94]
  74 funcall_recording_as(recorded_as = (...), nargs = 0, args = 0x11fffe878) ["eval.c":3223, 0x1200916a8]
  75 run_hook_with_args_in_buffer(buf = 0x6, nargs = 1, args = 0x11fffe878, cond = RUN_HOOKS_TO_COMPLETION) ["eval.c":3827, 0x12009350c]
  76 run_hook_with_args(nargs = 6, args = 0x11fff93d0, cond = RUN_HOOKS_TO_COMPLETION) ["eval.c":3841, 0x1200935b8]
  77 catch_them_squirmers_run_hook(hook_symbol = (...)) ["eval.c":4415, 0x120097d54]
  78 condition_case_1(handlers = (...), bfun = 0x120097d10, barg = (...), hfun = 0x120097b48, harg = (...)) ["eval.c":1672, 0x12008c2a0]
  79 safe_run_hook_trapping_errors(warning_string = 0x140408968 = "Error in `post-command-hook' (setting hook to nil)", hook_symbol = (...), allow_quit = 1) ["eval.c":4477, 0x1200952f4]
  80 post_command_hook() ["event-stream.c":3553, 0x1200a4b04]
  81 execute_command_event(command_builder = 0x140538500, event = (...)) ["event-stream.c":3484, 0x1200a47ac]
  82 Fdispatch_event(event = (...)) ["event-stream.c":3765, 0x1200a5268]
  83 Fcommand_loop_1() ["cmdloop.c":542, 0x1200698e4]
  84 command_loop_1(dummy = (...)) ["cmdloop.c":462, 0x120069624]
  85 condition_case_1(handlers = (...), bfun = 0x1200695e8, barg = (...), hfun = 0x120069b40, harg = (...)) ["eval.c":1672, 0x12008c2a0]
  86 command_loop_2(dummy = (...)) ["cmdloop.c":235, 0x120069d1c]
  87 internal_catch(tag = (...), func = 0x11fff93d0, arg = (...), threw = (nil)) ["eval.c":1347, 0x12008becc]
  88 initial_command_loop(load_me = (...)) ["cmdloop.c":273, 0x120069134]
  89 Frunning_temacs_p() ["emacs.c":1317, 0x120088164]
(dbx) 

(dbx) up 5
assert_failed:	 Source not available

(dbx) dump
assert_failed(file = 0x29d3, line = 6, expr = (nil)) ["emacs.c":1830, 0x120088ecc]

(dbx) up
emacs_Xt_select_process:	 Source not available

(dbx) dump
emacs_Xt_select_process(p = 0x141461500) ["event-Xt.c":1612, 0x12016ec54]
infd = 0
process = union {
    s = struct {
        type_mark = 1
        val = 0
    }
    gu = struct {
        type = Lisp_Record
        markbit = 0
        val = 0
    }
    i = 1
    v = 0x1
    cv = 0x1
}
fd = 0
what = union {
    s = struct {
        type_mark = 1
        val = 0
    }
    gu = struct {
        type = Lisp_Record
        markbit = 0
        val = 0
    }
    i = 1
    v = 0x1
    cv = 0x1
}
closure = 0x141461500

(dbx) up
event_stream_select_process:	 Source not available

(dbx) dump
event_stream_select_process(proc = 0x29d3) ["event-stream.c":545, 0x12009eb60]

(dbx) up
create_process:	 Source not available

(dbx) dump
create_process(process = union {
    s = struct {
        type_mark = 1
        val = 5375469824
    }
    gu = struct {
        type = Lisp_Record
        markbit = 0
        val = 5375469824
    }
    i = 86007517185
    v = 0x1406729001
    cv = 0x1406729001
}, new_argv = 0x11fff9518, current_dir = 0x140b64440 = "/usr/users/carney/Mail") ["process.c":1044, 0x120114ad4]
pid = 11025
inchannel = 0
outchannel = 11
forkin = 8
forkout = 7
pty_flag = 0
p = 0x140672900
fd = -1
i = 11025
stb = struct {
    st_dev = 108134401
    st_ino = 20
    st_mode = 108195841
    st_nlink = 20
    st_uid = 537195184
    st_gid = 1
    st_rdev = 536844096
    st_size = 4832918828
    st_atime = 536843720
    st_spare1 = 1
    st_mtime = 108171265
    st_spare2 = 20
    st_ctime = 536844080
    st_spare3 = 1
    st_blksize = 5
    st_blocks = 0
    st_flags = 536843544
    st_gen = 1
}
mask = 8
dummy = 0
sv = {
    [0] 108134401
    [1] 20
}
p = 0x140672900
p = 0x140672900
t = struct {
    c_iflag = 537195184
    c_oflag = 1
    c_cflag = 536844096
    c_lflag = 1
    c_cc = ",} "
    c_ispeed = 20
    c_ospeed = 536844080
}
p = 0x140672900
pty_max_bytes = 0
save_environ = 0x11ffff640
xforkin = 8
xforkout = 536843400
ldisc = 538005400
piddly = 1
temp = 536843400
(dbx) 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Carney        TEL:[41](22)782.90.60  http://www-digital.cern.ch/carney/
carney@gvc.dec.com  FAX:[41](22)782.94.92 

From xemacs-beta-request@cs.uiuc.edu  Sat Aug 24 16:40:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA27276 for xemacs-beta-people; Sat, 24 Aug 1996 16:40:47 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA27273 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 24 Aug 1996 16:40:28 -0500 (CDT)
Received: from lehman.Lehman.COM ([192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA23968 for <xemacs-beta@xemacs.org>; Sat, 24 Aug 1996 16:40:16 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id RAA12846; Sat, 24 Aug 1996 17:39:51 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp012835; Sat Aug 24 17:39:20 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA05758; Sat, 24 Aug 96 17:38:48 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA19044; Sat, 24 Aug 96 17:38:43 EDT
Message-Id: <9608242138.AA19044@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Even your dog won't like it.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
Cc: xemacs-beta@xemacs.org
Subject: Re: [gnu.emacs.sources] Re: Emacs 
In-Reply-To: Your message of "23 Aug 1996 09:52:59 +0200."
             <on686av8o4.fsf@daedalus.tnt.uni-hannover.de> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMh92SltTztlqB385AQH2NQP/Ytkt3d2ilNSLKFWpZ48jlkivTSP7rKaU
	      4y8W5ZyPdmPGIXwdddtB4UY4KWNoBo3TpSeDyGLpgLdklVmRlNbcG9y6gj2zXHOj
	      FY2mSGW3xcmTNVU+Hf+Dr2VaMgF3Pvb+XqPpWgYQX90fHvgi/PD1/p5wGt2F/oD4
	      fcHwOxbuyPk=
	      =xWGT
Date: Sat, 24 Aug 1996 17:38:40 -0400
Sender: rickc@lehman.com

    From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
    Date: 23 Aug 1996 09:52:59 +0200

    Distinguishing the two versions is certainly necessary.  I do it by
    writing GNU Emacs and GNU XEmacs, or, in contexts where there is no
    problem of confusion with other Emacs implementations (which is most
    of the time), just Emacs and XEmacs.

This is as RMS suggests.  Unfortunately, Emacs is the generic name.
When I refer to something happening in Emacs or even GNU Emacs, it is
often the case that it happens in both FSF's GNU Emacs and in XEmacs,
both of which are Emacs in my book.

Ultimately, the problem is in what to call the FSF version which will
distinguish it from other things which can legitimately be called GNU
Emacs.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Sun Aug 25 21:45:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA03788 for xemacs-beta-people; Sun, 25 Aug 1996 21:45:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA03785 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 25 Aug 1996 21:45:53 -0500 (CDT)
Received: from fgwmail.fujitsu.co.jp (fgwmail.fujitsu.co.jp [164.71.1.133]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA14376 for <xemacs-beta@xemacs.org>; Sun, 25 Aug 1996 21:45:49 -0500 (CDT)
Received: from fdmmail.fujitsu.co.jp by fgwmail.fujitsu.co.jp (8.7.5+2.6Wbeta6/3.3W5-MX960815-Fujitsu Mail Gateway)
	id LAA06068; Mon, 26 Aug 1996 11:45:36 +0900 (JST)
Received: from azalea.kawasaki.flab.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.6.12+2.5Wb4/3.3W9-MX960819-Fujitsu Domain Mail Master)
	id LAA06567; Mon, 26 Aug 1996 11:45:34 +0900
Received: from matt by azalea.kawasaki.flab.fujitsu.co.jp (8.6.9+2.4Wb/3.3W9-MX950601-Fujitsu Labs. Kawasaki Domain Mail Master)
	id LAA21866; Mon, 26 Aug 1996 11:45:33 +0900
Received: from matt (localhost [127.0.0.1]) by matt (SMI-8.6/3.4W596051312) with ESMTP id LAA16698 for xemacs-beta@xemacs.org; Mon, 26 Aug 1996 11:45:23 +0900
Message-Id: <199608260245.LAA16698@matt>
To: xemacs-beta@xemacs.org
Subject: 20.0-b27 with MULE on NetBSD-1.2_BETA/sparc
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: multipart/mixed;
 boundary="Multipart_Mon_Aug_26_11:45:22_1996-1"
Content-Transfer-Encoding: 7bit
Date: Mon, 26 Aug 1996 11:45:23 +0900
From: =?ISO-2022-JP?B?GyRCTCcxOhsoQiAbJEI/PxsoQg==?= / MINOURA Makoto <minoura@flab.fujitsu.co.jp>

--Multipart_Mon_Aug_26_11:45:22_1996-1
Content-Type: text/plain; charset=US-ASCII


I made a bug-fix patch for NetBSD/sparc.  I think it can
also be applied to 19.14 (and other previous versions).

I am not very sure about dynamic loading and shared object.
Is this fix correct?



--Multipart_Mon_Aug_26_11:45:22_1996-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="netbsd-sparc.diff"
Content-Transfer-Encoding: 7bit

diff -crN --exclude-from=exceptions xemacs-20.0-b27.ORIG/src/m/sparc.h xemacs-20.0-b27/src/m/sparc.h
*** xemacs-20.0-b27.ORIG/src/m/sparc.h	Sun Jun  2 03:46:58 1996
--- xemacs-20.0-b27/src/m/sparc.h	Wed Aug 21 09:51:54 1996
***************
*** 91,98 ****
--- 91,100 ----
  /* Must use the system's termcap, if we use any termcap.
     It does special things.  */
  
+ #ifndef LIBS_TERMCAP
  #ifndef TERMINFO
  #define LIBS_TERMCAP -ltermcap
+ #endif
  #endif
  
  /* Mask for address bits within a memory segment */
diff -crN --exclude-from=exceptions xemacs-20.0-b27.ORIG/src/unexfreebsd.c xemacs-20.0-b27/src/unexfreebsd.c
*** xemacs-20.0-b27.ORIG/src/unexfreebsd.c	Sun Mar 31 00:44:48 1996
--- xemacs-20.0-b27/src/unexfreebsd.c	Fri Aug 23 20:52:22 1996
***************
*** 289,296 ****
--- 289,303 ----
    /* We can get relocation sites in the bss region, for objects whose
       contents are copied from a shared library.  We don't need or want
       to restore these at present. */
+ #ifndef sparc
    if (ri->r_copy)
      return;
+ #else
+   /* Struct relocation_info_sparc doesn't have member r_copy.
+      Instead, we use the address to check if this is run-time-copied. */
+   if (ri->r_address >= ts->bssaddr && ri->r_address < ts->endaddr)
+     return;
+ #endif
  
    offset = unexec_addr_to_offset (ri->r_address, ts);
    if (offset == -1)
***************
*** 351,356 ****
--- 358,364 ----
          source++;
          *target = *source;
        }
+       break;
      default:
        unexec_error ("unknown reloc type %d seen during unexec()",
  		    0, ri->r_type);

--Multipart_Mon_Aug_26_11:45:22_1996-1
Content-Type: text/plain; charset=US-ASCII


By using this patch, I succeeded to compile XEmacs 20.0b27 with
MULE.

Hardware: SPARCStation IPX
OS: NetBSD-1.2_BETA, X11R6.1

./configure  --verbose --with-gnu-make --cflags=-O2 --site-includes='/usr/local/canna/include /usr/local/include' --site-libraries=/usr/local/lib --dynamic=yes --prefix=/usr/local --with-mule --with-xim --with-canna sparc-sun-netbsd1.2

Configured for `sparc-sun-netbsd1.2'.

  Where should the build process find the source code?    /export/proj/xemacs-20.0-b27
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/netbsd.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6.1/include
  Where do we find X Windows libraries?                   /usr/X11R6.1/lib
  Additional header files:                                /usr/local/canna/include /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for DBM.
  Compiling in XIM (X11R5+ I18N input method) support.
  Compiling in Mule (multi-lingual) support.
  Compiling in support for Canna on Mule.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


-- 
							MINOURA Makoto
					    minoura@flab.fujitsu.co.jp
					Integrated Networks Laboratory
			    Fujitsu Laboratories Ltd., Kawasaki, Japan

--Multipart_Mon_Aug_26_11:45:22_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Sun Aug 25 22:48:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA03921 for xemacs-beta-people; Sun, 25 Aug 1996 22:48:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA03918 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 25 Aug 1996 22:48:41 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA14568 for <xemacs-beta@xemacs.org>; Sun, 25 Aug 1996 22:48:38 -0500 (CDT)
Message-Id: <199608260348.WAA14568@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: no betas, but...
Date: Sun, 25 Aug 1996 22:48:37 -0500
From: Chuck Thompson <cthomp@xemacs.org>

I did spend the entire weekend working on XEmacs.  See:

	http://www.xemacs.org/beta/testing/

to find out what I did do.  I don't think it will take long for it to
be worth the additional delay in getting 19.15 going.  Bug reports
(haha) and suggestions concerning this setup are welcome.

I've rescheduled 19.15 beta1 and 20.0 beta28 for two weeks from today,
Sunday September 8.  I hope to get them out sooner than that but I
have one week of hell left at work which is probably going to last
through next weekend.

The good news is that this is definitely it for the extra hours at my
regular job meaning I'll have my XEmacs hacking time back.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 26 00:28:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA04089 for xemacs-beta-people; Sun, 25 Aug 1996 23:43:34 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA04086 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 25 Aug 1996 23:43:33 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA13988 for <xemacs-beta@cs.uiuc.edu>; Sun, 25 Aug 1996 23:43:32 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id VAA01239; Sun, 25 Aug 1996 21:40:52 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: bbdb-1.52 status?
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.79)
Content-Type: text/plain; charset=US-ASCII
Date: 25 Aug 1996 21:40:51 -0700
Message-ID: <m220guzrjg.fsf@deanna.miranova.com>
Lines: 8
X-Mailer: Gnus v5.2.39/XEmacs 19.14

Whatever happened to bbdb-1.52?  Is it no longer a planned part of
19.15?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 26 02:06:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA05059 for xemacs-beta-people; Mon, 26 Aug 1996 02:06:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA05056 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 26 Aug 1996 02:06:46 -0500 (CDT)
Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA14812 for <xemacs-beta@xemacs.org>; Mon, 26 Aug 1996 02:06:41 -0500 (CDT)
Received: from sun.rhrk.uni-kl.de by stepsun.uni-kl.de id aa20901;
          26 Aug 96 9:06 MET DST
Received: from aix8.rhrk.uni-kl.de by sun.rhrk.uni-kl.de id aa14900;
          26 Aug 96 9:06 MET DST
Received: by aix8 (Smail3.1.28.1 #7)
	id m0uuvku-0000YgC; Mon, 26 Aug 96 09:06 CETDST
Message-Id: <m0uuvku-0000YgC@aix8>
Date: Mon, 26 Aug 96 09:06 CETDST
From: Marcus Thiessel <thiessel@rhrk.uni-kl.de>
To: xemacs-beta@xemacs.org
Subject: core on new-frame (HP-UX 9.05)

core dumb running XEmacs 20.0 beta27 


I am using

- HP9000/735 / HP-UX A.09.05 A
- X11R5
- Motif 1.2, Xpm 3.4h, libXaw
- gcc-2.7.2 
- fvwm-1.24l

I ran 'configure' as follows (same as I compiled 19.14 before):

./configure CONFIGURATION-NAME hppa1.1-hp-hpux9shr --dynamic \
        --prefix=/usr/local/lib/X11/xemacs --with-x \
        --with-dialogs=lucid \
        --site-includes=/usr/local/lib/X11R5/include \
        --site-libraries=/usr/local/lib/X11R5/lib \
        --with-xpm --with-sound=no --cflags="-g -O2"

[...]

Configured for `hppa1.1-hp-hpux9shr'.

  Where should the build process find the source code?    /disk2/stuff/xemacs-20.0-b27
  What installation prefix should install use?            /usr/local/lib/X11/xemacs
  What operating system and machine description files should XEmacs use?
        `s/hpux9shr.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              gcc -g -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/lib/X11R5/include
  Additional libraries:                                   /usr/local/lib/X11R5/lib
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


[...]

After compiling successfully everything seemed te be fine. But when I
asked for a new frame ( C-x 5 2 ) I got an error, with could not be
traced back. (gdb-4.14 also produced a core which finally replace the
other one!). For some certain reasons which I don't know, I can't
reproduce this error.

Any comments or hints for reproduction?

--Marcus

Lisp backtrace follows:

  x-get-resource("custom-face-dark blue-default-default-nil-nil-nil.attributeBackgroundPixmap" "Face.AttributeBackgroundPixmap" string #<x-frame "emacs" 0x18ab> nil t)
  # bind (locale type class name)
  x-get-resource-and-maybe-bogosity-check("custom-face-dark blue-default-default-nil-nil-nil.attributeBackgroundPixmap" "Face.AttributeBackgroundPixmap" string #<x-frame "emacs" 0x18ab>)
  # bind (bg fg fn name face-sym locale face)
  x-init-face-from-resources(custom-face-dark\ blue-default-default-nil-nil-nil #<x-frame "emacs" 0x18ab>)
  # bind (devtype locale face)
  init-face-from-resources(custom-face-dark\ blue-default-default-nil-nil-nil #<x-frame "emacs" 0x18ab>)
  # bind (faces frame)
  init-frame-faces(#<x-frame "emacs" 0x18ab>)
  # (unwind-protect ...)
  # bind (frame-being-created)
  #<subr make-frame (interactive)>()
  # bind (command-debug-status)
  call-interactively(make-frame)
  # (condition-case ... . error)
  # (catch top-level ...)
Segmentation fault (core dumped)

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 26 07:30:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA09267 for xemacs-beta-people; Mon, 26 Aug 1996 07:30:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA09264 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 26 Aug 1996 07:30:48 -0500 (CDT)
Received: from charles.cs.uiuc.edu (charles.cs.uiuc.edu [128.174.252.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA19633 for <xemacs-beta@cs.uiuc.edu>; Mon, 26 Aug 1996 07:30:49 -0500 (CDT)
Received: from charles.cs.uiuc.edu (localhost [127.0.0.1]) by charles.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA20198; Mon, 26 Aug 1996 07:30:45 -0500 (CDT)
Message-Id: <199608261230.HAA20198@charles.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: bbdb-1.52 status? 
In-reply-to: Your message of "25 Aug 1996 21:40:51 PDT."
             <m220guzrjg.fsf@deanna.miranova.com> 
Date: Mon, 26 Aug 1996 07:30:45 -0500
From: Chuck Thompson <cthomp@cs.uiuc.edu>

    Steven> Whatever happened to bbdb-1.52?  Is it no longer a planned
    Steven> part of 19.15?

Heck, I originally planned to release it simultaneously with 19.14.
bbdb will never be a part of any XEmacs release (Jamie's wishes).  I
was planning on making it available in package format, however.  That
will have to wait until 19.16 since that is when the packge system
will show up.

There will be a 1.52 no later than the release of 19.15 even if it has
nothing else besides a few additional patches Jamie sent me and an
updated bbdb-gnus.el


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 26 10:57:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA09763 for xemacs-beta-people; Mon, 26 Aug 1996 10:57:07 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA09760 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 26 Aug 1996 10:57:06 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA28147 for <xemacs-beta@cs.uiuc.edu>; Mon, 26 Aug 1996 10:57:03 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id IAA02849; Mon, 26 Aug 1996 08:54:23 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: bbdb-1.52 status?
References: <199608261230.HAA20198@charles.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Mon, 26 Aug 1996 07:30:45 -0500
Mime-Version: 1.0 (generated by tm-edit 7.79)
Content-Type: text/plain; charset=US-ASCII
Date: 26 Aug 1996 08:54:22 -0700
Message-ID: <m2g25af8ep.fsf@deanna.miranova.com>
Lines: 16
X-Mailer: Gnus v5.2.39/XEmacs 19.14

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:

Steven> Whatever happened to bbdb-1.52?  Is it no longer a planned
Steven> part of 19.15?

Chuck> There will be a 1.52 no later than the release of 19.15 even if
Chuck> it has nothing else besides a few additional patches Jamie sent
Chuck> me and an updated bbdb-gnus.el

O.K.  I wanted to fool around with it, and bbdb-1.51 just doesn't work
for me at all.  I guess I'll wait.  :-(
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 26 11:06:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA09781 for xemacs-beta-people; Mon, 26 Aug 1996 11:06:36 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA09778 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 26 Aug 1996 11:06:35 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA15586 for <xemacs-beta@xemacs.org>; Mon, 26 Aug 1996 11:06:31 -0500 (CDT)
Received: from kramer (kramer [192.168.1.12]) by newman (8.6.12/8.6.9) with SMTP id JAA27866 for <xemacs-beta@xemacs.org>; Mon, 26 Aug 1996 09:05:18 -0700
Sender: wmperry@newman
Message-ID: <3221CBC8.41E0@aventail.com>
Date: Mon, 26 Aug 1996 09:07:36 -0700
From: William Perry <wmperry@aventail.com>
Organization: Aventail, Inc.
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 i86pc)
MIME-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: SOCKS v4/v5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Well, screw it.  Why is this even in the C code anyway?  Let's write it
in LISP!  Who's with ME?!!?!?

I've already got a base SOCKS v5 implementation written in lisp.  It has
hooks to plug in new authentication modules and new proxy commands. 
Seems to work halfway decent.  I might move some things into process
filters, but keeping a buffer around isn't that expensive, and VM-pop
and ange-ftp/efs do as well, so there's precedent, right?

I'll try to get the BIND & CONNECT proxy commands written later today. 
I want to add a socks-route command or something that will let the user
specify different socks servers for different destinations, etc.  Much
more flexible than a straight C implementation.  At least I think so.

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 26 11:25:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA09834 for xemacs-beta-people; Mon, 26 Aug 1996 11:25:41 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA09831 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 26 Aug 1996 11:25:40 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA00313 for <xemacs-beta@cs.uiuc.edu>; Mon, 26 Aug 1996 11:25:41 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id LAA29557 for <xemacs-beta@cs.uiuc.edu>; Mon, 26 Aug 1996 11:25:10 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id LAA21461 for <xemacs-beta@cs.uiuc.edu>; Mon, 26 Aug 1996 11:25:09 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id MAA00490 for <xemacs-beta@cs.uiuc.edu>; Mon, 26 Aug 1996 12:25:21 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Simple update for buffer-mode
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: multipart/mixed;
 boundary="Multipart_Mon_Aug_26_12:21:35_1996-1"
Content-Transfer-Encoding: 7bit
Date: Mon, 26 Aug 1996 12:21:43 -0400
Message-ID: <15823.841076503@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

--Multipart_Mon_Aug_26_12:21:35_1996-1
Content-Type: text/plain; charset=US-ASCII


I've always found it quite annoying the the buffer list in buffer mode
almost always produces results where the columns don't line up.  Also,
the little dot to mark the current buffer is too small.

Here is a little bit of elisp to replace the corresponding functions.
It changes the internal interface, but I've not noticed any problems
and the changes made aren't used by anyone anywhere else in lisp, so
it should be safe. :-)

I just noticed that an updated buffer-menu mode has been posted to
comp.emacs.xemacs.  Perhaps this could be integrated in?

Ray


--Multipart_Mon_Aug_26_12:21:35_1996-1
Content-Type: application/octet-stream; type=emacs-lisp
Content-Disposition: attachment; filename="rlt-list-buffers.el"
Content-Transfer-Encoding: 7bit

;;;; Replacement for buff-menu.  These functions produces a buffer
;;;; window that is sorted in the same order as the buffers menu.
;;;; Also, it automatically arranges for the width of the columns to
;;;; be the right size so everything stays lined up.  Cool.

(defun list-buffers (&optional files-only)
  "Display a list of names of existing buffers.
The list is displayed in a buffer named `*Buffer List*'.
Note that buffers with names starting with spaces are omitted.
Non-null optional arg FILES-ONLY means mention only file buffers.

The M column contains a * for buffers that are modified.
The R column contains a % for buffers that are read-only."
  (interactive (list (if current-prefix-arg t nil)))
  (let ((pop-up-windows t))
    (display-buffer (list-buffers-noselect files-only) nil (selected-frame))))


(defun default-list-buffers-identification (output)
  (let ((file (or (buffer-file-name (current-buffer))
		  (and (boundp 'list-buffers-directory)
		       list-buffers-directory))))
    (set-buffer output)
    (if file
	(insert file))))


(defun list-buffers-field-sizes (buf-list &optional predicate)
  "Compute the maximum size needed for the buffer name, the buffer
  size, and buffer mode for the buffer menu"
  ;; Set some reasonable minimum limits
  (let* ((buf-name-len 10)
	 (buf-size-len 4)
	 (buf-mode-len 4)
	 ;; Don't let buffer names get longer than this.  It's ugly
	 ;; and confusing if the space is really large.  Keep it
	 ;; sensible, and just allow misaligned columns.
	 (max-buf-name-len (max buf-name-len (/ (frame-width) 3))))
    (while buf-list
      (let* ((buf (car buf-list))
	     (name (buffer-name buf))
	     name-len)
	(cond ((null name)
	       ;; Ignore deleted buffers
	       )
	      ((and predicate
		    (not (if (stringp predicate)
			     (string-match predicate name)
			   (funcall predicate buf))))
	       ;; Ignore buffers that match the predicate
	       nil)
	      (t
	       (set-buffer buf)
	       ;; Get the right length for the buffer
	       (if (string-match "[\n\"\\ \t]" name)
		   (let ((print-escape-newlines t))
		     (setq name-len (length (prin1-to-string name))))
		 (setq name-len (length name)))
	       (setq buf-name-len (max buf-name-len name-len))
	       (setq buf-size-len (max buf-size-len
				       (length (prin1-to-string (buffer-size buf)))))
	       (setq buf-mode-len (max buf-mode-len (length mode-name)))))
	(setq buf-list (cdr buf-list))))
    (list (min buf-name-len max-buf-name-len)
	  buf-size-len buf-mode-len)))

(defun list-buffers-internal (output &optional predicate)
  (let ((current (current-buffer))
        (buffers (if buffers-menu-sort-function
		     (sort (buffer-list) buffers-menu-sort-function)
		   (buffer-list)))
	format-long)

    (save-excursion
      (destructuring-bind (buf-name-len buf-size-len buf-mode-len)
	  (list-buffers-field-sizes buffers predicate)
	(setq format-long (format "%%c%%c%%c %%-%ds %%%ds %%-%ds "
				  buf-name-len buf-size-len buf-mode-len))
	(set-buffer output)
	(setq buffer-read-only nil)
	(erase-buffer)
	(buffer-disable-undo output)
	(insert (format format-long ?\ ?M ?R "Buffer" "Size" "Mode"))
	(insert "File\n")
	(insert (format format-long ?\ ?- ?- "------" "----" "----"))
	(insert "----\n")
	(goto-char (point-max))
	
	(while buffers
	  (let* ((buffer (car buffers))
		 (name (buffer-name buffer))
		 this-buffer-line-start)
	    (setq buffers (cdr buffers))
	    (cond  ((null name))		;deleted buffer
		  ((and predicate
			(not (if (stringp predicate)
				 (string-match predicate name)
                               (funcall predicate buffer))))
		   nil)
		  (t
		   (set-buffer buffer)
		   (let* ((ro buffer-read-only)
			 (id list-buffers-identification)
			 (mark-current (if (eq buffer current)
					   (progn
					     (setq current (point))
					     ?\>)
					 ?\ ))
			 (mark-modified (if (buffer-modified-p buffer)
					    ?\* ?\ ))
			 (mark-ro (if ro ?\% ?\ ))
			 (buf-mode mode-name)
			 buf-name)
		     (set-buffer output)
		     (setq this-buffer-line-start (point))
		     (if (string-match "[\n\"\\ \t]" name)
			 (let ((print-escape-newlines t))
			   (setq buf-name (prin1-to-string name)))
		       (setq buf-name name))
		     (insert (format format-long
				     mark-current mark-modified mark-ro
				     buf-name
				     (prin1-to-string (buffer-size buffer))
				     buf-mode))
		     (cond ((stringp id)
			    (insert id))
			   (id
			    (set-buffer buffer)
			    (condition-case e
				(funcall id output)
			      (error
			       (princ "***" output) (prin1 e output)))
			    (set-buffer output)
			    (goto-char (point-max)))))
		   (put-nonduplicable-text-property this-buffer-line-start
						    (point)
						    'buffer-name name)
		   (put-nonduplicable-text-property this-buffer-line-start
						    (point)
						    'highlight t)
		   (insert ?\n)))))

	(Buffer-menu-mode)
	(if (not (bufferp current))
	    (goto-char current))))))



--Multipart_Mon_Aug_26_12:21:35_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Mon Aug 26 19:43:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA11312 for xemacs-beta-people; Mon, 26 Aug 1996 19:43:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA11309 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 26 Aug 1996 19:43:10 -0500 (CDT)
Received: from beavis (jmiller@port40.bayserve.net [206.148.244.138]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA18798 for <xemacs-beta@cs.uiuc.edu>; Mon, 26 Aug 1996 19:43:10 -0500 (CDT)
From: jmiller@bayserve.net
Received: (from jmiller@localhost) by beavis (8.6.12/8.6.9) id UAA00180; Mon, 26 Aug 1996 20:50:55 -0400
Date: Mon, 26 Aug 1996 20:50:55 -0400
Message-Id: <199608270050.UAA00180@beavis>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: bbdb-1.52 status?
In-Reply-To: <m2g25af8ep.fsf@deanna.miranova.com>
References: <199608261230.HAA20198@charles.cs.uiuc.edu>
	<m2g25af8ep.fsf@deanna.miranova.com>
Reply-to: jmiller@bayserve.net
Mime-Version: 1.0 (generated by tm-edit 7.74)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

Steven> O.K.  I wanted to fool around with it, and bbdb-1.51 just doesn't
Steven> work for me at all.  I guess I'll wait.  :-(

  bbdb-1.51 will work for me with 19.14/vm 5.96 if I don't put 
(require 'tm-vm) in my .vm file.  This is with tm7.74 but it did the 
same thing with 7.68.  I've got 7.78 but haven't installed it yet.

  It seems like something mucks with the vm-visible-headers alist because
  I don't get the normal From/To/Subject/Date headers.  I glanced at
  tm-vm.el quickly but haven't spent any serious time looking at what
  might cause it. 

Jeff


From xemacs-beta-request@cs.uiuc.edu  Tue Aug 27 00:36:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA11832 for xemacs-beta-people; Tue, 27 Aug 1996 00:36:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA11829 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 27 Aug 1996 00:36:03 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA28413 for <xemacs-beta@cs.uiuc.edu>; Tue, 27 Aug 1996 00:36:03 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id WAA10844; Mon, 26 Aug 1996 22:33:29 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: bbdb-1.52 status?
References: <199608261230.HAA20198@charles.cs.uiuc.edu>
	<m2g25af8ep.fsf@deanna.miranova.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Steven L Baur's message of 26 Aug 1996 08:54:22 -0700
Mime-Version: 1.0 (generated by tm-edit 7.79)
Content-Type: text/plain; charset=US-ASCII
Date: 26 Aug 1996 22:33:28 -0700
Message-ID: <m2raot5r2v.fsf@deanna.miranova.com>
Lines: 33
X-Mailer: Gnus v5.2.39/XEmacs 19.14

>>>>> "sb" == Steven L Baur <steve@miranova.com> writes:

>>>>> "Chuck" == Chuck Thompson <cthomp@cs.uiuc.edu> writes:
Steven> Whatever happened to bbdb-1.52?  Is it no longer a planned
Steven> part of 19.15?

Chuck> There will be a 1.52 no later than the release of 19.15 even if
Chuck> it has nothing else besides a few additional patches Jamie sent
Chuck> me and an updated bbdb-gnus.el

sb> O.K.  I wanted to fool around with it, and bbdb-1.51 just doesn't work
sb> for me at all.  I guess I'll wait.  :-(

Here's a patch if this isn't already fixed :-( ...

--- bbdb-gnus.el~	Mon May 27 14:32:30 1996
+++ bbdb-gnus.el	Mon Aug 26 22:15:36 1996
@@ -31,7 +31,7 @@
       (bbdb/gnus-pop-up-bbdb-buffer offer-to-create)
     (let ((from
 	   (progn
-	     (set-buffer "*Article*")
+	     (set-buffer gnus-article-buffer)
 	     (save-restriction
 	       (widen)
 	       ;;(gnus-article-show-all-headers)


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Aug 27 04:13:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA15984 for xemacs-beta-people; Tue, 27 Aug 1996 04:13:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA15981 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 27 Aug 1996 04:13:48 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA00844 for <xemacs-beta@cs.uiuc.edu>; Tue, 27 Aug 1996 04:13:48 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Tue, 27 Aug 1996 11:13:00 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id LAA24734; Tue, 27 Aug 1996 11:12:47 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id LAA00801;
          Tue, 27 Aug 1996 11:10:27 +0200
Date: Tue, 27 Aug 1996 11:10:27 +0200
Message-Id: <199608270910.LAA00801@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
To: Raymond Toy <toy@rtp.ericsson.se>
CC: xemacs-beta@cs.uiuc.edu
Subject: Re: Simple update for buffer-mode
In-Reply-To: <15823.841076503@rtp.ericsson.se>
References: <15823.841076503@rtp.ericsson.se>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Raymond" == Raymond Toy <toy@rtp.ericsson.se> writes:

    Raymond> [1 <text/plain; US-ASCII (7bit)>] I've always found it
    Raymond> quite annoying the the buffer list in buffer mode almost
    Raymond> always produces results where the columns don't line up.
    Raymond> Also, the little dot to mark the current buffer is too
    Raymond> small.

    Raymond> Here is a little bit of elisp to replace the
    Raymond> corresponding functions.  It changes the internal
    Raymond> interface, but I've not noticed any problems and the
    Raymond> changes made aren't used by anyone anywhere else in lisp,
    Raymond> so it should be safe. :-)

    Raymond> I just noticed that an updated buffer-menu mode has been
    Raymond> posted to comp.emacs.xemacs.  Perhaps this could be
    Raymond> integrated in?

Do you speak about my changes? I'll take a look at your code and try
to integrate it. But this may take some time, because I'm very busy
at the moment.

From xemacs-beta-request@cs.uiuc.edu  Tue Aug 27 09:22:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA16504 for xemacs-beta-people; Tue, 27 Aug 1996 09:22:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA16501 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 27 Aug 1996 09:22:03 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA10744 for <xemacs-beta@cs.uiuc.edu>; Tue, 27 Aug 1996 09:22:04 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id JAA03302; Tue, 27 Aug 1996 09:18:33 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id JAA06234; Tue, 27 Aug 1996 09:18:32 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id KAA10956; Tue, 27 Aug 1996 10:18:43 -0400
To: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
cc: xemacs-beta@cs.uiuc.edu
References: <15823.841076503@rtp.ericsson.se>  <199608270910.LAA00801@daedalus.tnt.uni-hannover.de> 
Subject: Re: Simple update for buffer-mode 
In-reply-to: (Your message of Tue, 27 Aug 1996 11:10:27 +0200.)
             <199608270910.LAA00801@daedalus.tnt.uni-hannover.de> 
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 27 Aug 1996 10:15:06 -0400
Message-ID: <17682.841155306@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Heiko" == Heiko Muenkel <muenkel@tnt.uni-hannover.de> writes:

    Heiko> Do you speak about my changes? I'll take a look at your
    Heiko> code and try to integrate it. But this may take some time,
    Heiko> because I'm very busy at the moment.

Yes.  I was too lazy to look up the article when I posted my message.
I think it is a nice addition.  Based on a quick perusal of what you
posted, it seems that your buffer-list-internal is the same as the
original.  My changes should drop in without any one noticing. :-)

Ray

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 28 12:58:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA24520 for xemacs-beta-people; Wed, 28 Aug 1996 12:58:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA24517 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 28 Aug 1996 12:58:25 -0500 (CDT)
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA20589 for <xemacs-beta@xemacs.org>; Wed, 28 Aug 1996 12:58:06 -0500 (CDT)
Received: from mordor.rsn.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA221265088; Wed, 28 Aug 1996 10:58:08 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id MAA01402; Wed, 28 Aug 1996 12:48:45 -0500 (CDT)
To: xemacs-beta@xemacs.org
Subject: XEmacs on HP-UX 10.20 and EINTR signal
From: Shane Holder <holder@mordor.rsn.hp.com>
Date: 28 Aug 1996 12:48:44 -0500
Message-Id: <fawn2zfmmbn.fsf@mordor.rsn.hp.com>
Lines: 10
X-Mailer: Gnus v5.2.29/Emacs 19.34


I'm running XEmacs 19.14 on HP-UX 10.20, and very frequently, XEmacs
will die with an EINTR.  Is anyone else experiencing something similar
to this?

-- 
Shane Holder                                 e-mail: holder@rsn.hp.com
Hewlett Packard                               phone:     (214)497-4182
3000 Waterview                       Never underestimate the bandwidth
Richardson, TX 75083                 of a truck moving at 70 MPH.

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 28 13:05:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA24545 for xemacs-beta-people; Wed, 28 Aug 1996 13:05:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA24542 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 28 Aug 1996 13:05:55 -0500 (CDT)
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA20598 for <xemacs-beta@xemacs.org>; Wed, 28 Aug 1996 13:05:49 -0500 (CDT)
Received: from mordor.rsn.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA234975552; Wed, 28 Aug 1996 11:05:52 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id MAA01488; Wed, 28 Aug 1996 12:56:29 -0500 (CDT)
To: xemacs-beta@xemacs.org
Subject: Running XEmacs under gdb on HP-UX
From: Shane Holder <holder@mordor.rsn.hp.com>
Date: 28 Aug 1996 12:56:28 -0500
Message-Id: <fawloezmlyr.fsf@mordor.rsn.hp.com>
Lines: 10
X-Mailer: Gnus v5.2.29/Emacs 19.34


How do I run XEmacs under gdb.  Everytime I try, I get lots of
SIGTRAP's even when I don't have a breakpoint set.  I don't have this
problem when running Emacs under gdb.

-- 
Shane Holder                                 e-mail: holder@rsn.hp.com
Hewlett Packard                               phone:     (214)497-4182
3000 Waterview                       
Richardson, TX 75083                 

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 28 19:05:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA26071 for xemacs-beta-people; Wed, 28 Aug 1996 19:05:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA26068 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 28 Aug 1996 19:05:03 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA08122 for <xemacs-beta@cs.uiuc.edu>; Wed, 28 Aug 1996 19:05:05 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA12865; Wed, 28 Aug 1996 17:04:32 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA14201; Wed, 28 Aug 1996 17:04:28 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA10879; Wed, 28 Aug 1996 17:04:28 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA12815; Wed, 28 Aug 1996 17:04:23 -0700
Date: Wed, 28 Aug 1996 17:04:23 -0700
Message-Id: <199608290004.RAA12815@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: "Choi jong won (DM-4338-96.8.1)" <jwchoi@gsen.goldstar.co.kr>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Xemacs-20.0-b27 with MULE
In-Reply-To: <199608210530.PAA12204@gsenm5.gsen.goldstar.co.kr>
References: <199608210530.PAA12204@gsenm5.gsen.goldstar.co.kr>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "jwc" == DM-4338-96 8 1 <Choi> writes:

jwc> Hello all,
jwc> I build b27(applyed patch from b26), successfully(so far). And have
jwc> some questions. 

jwc> o The status of mail programs(like vm, rmail, mail) Xemacs with mule
jwc>   support. Are they all work well with mule support?

jwc> o To me reading Korean characters ok. But can't type(write) Korean
jwc>   characters. (I read docs to find how to type, failed. Docs are seems
jwc>   to be obsolete now. Anyone has recent docs for configuring mule
jwc>   support?)

I am happy that Korean characters are readable.  You may want to see
what lisp/mule/japanese-hooks.el does, and experiment with additions
to your .emacs based on that.  If happy with those changes, submit a
patch to me for korean-hooks.el.

Docs and code could both be better :-)

Sun's intent is that all customers run Solaris 2.5+ and use XIM for
composed input (and that sunos4 quietly disappear).

If your decide not to try XIM, and were ambitious, you could try
to port egg or quail.

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 28 19:16:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA26100 for xemacs-beta-people; Wed, 28 Aug 1996 19:16:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA26097 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 28 Aug 1996 19:16:07 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA21202 for <xemacs-beta@xemacs.org>; Wed, 28 Aug 1996 19:16:04 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA16513; Wed, 28 Aug 1996 17:15:32 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA16436; Wed, 28 Aug 1996 17:15:27 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA11249; Wed, 28 Aug 1996 17:15:27 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA12830; Wed, 28 Aug 1996 17:15:22 -0700
Date: Wed, 28 Aug 1996 17:15:22 -0700
Message-Id: <199608290015.RAA12830@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Achim Oppelt <aoppelt@theorie3.physik.uni-erlangen.de>
Cc: xemacs-beta@xemacs.org
Subject: 20.0b27 success on Linux 2.0.13
In-Reply-To: <199608210634.IAA02051@feynman.oppelix.de>
References: <199608210634.IAA02051@feynman.oppelix.de>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Achim" == Achim Oppelt <aoppelt@theorie3.physik.uni-erlangen.de> writes:

Achim> displays correctly the mule-doc/ISO2022.jp file. Canna seems to work too. I
Achim> haven't tried the XIM support yet (but it is compiled in).

It would be nice if someone ever reported success with XIM on a
non-Solaris platform.

Achim> I can send in the log of the compilation if someone is interested; however
Achim> it is rather large (100k gzipped and uuencoded). There were lots of
Achim> warnings about functions not known to be defined (263), obsolete variables
Achim> (895), references to free variables (1606), assignments to free variables
Achim> (582), variables bound but not referenced (684), variable reference to
Achim> constant (68) and, before dumping xemacs, many (982) Ebola warnings (what
Achim> are those?) while temacs was byte-compiling some stuff. There were also
Achim> some (45) other warning and error messages. 

compilation warnings are for package owners to try to modernize their
packages.  It would be good for someone who understood a class of
warnings to make global changes to the core elisp files that come with
XEmacs.

Achim> How do I get VM to decode those ISO-2022-JP headers that appear in this
Achim> mailing list (e.g. From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
Achim> MORIOKA Tomohiko <morioka@jaist.ac.jp>).

tm.

Achim> Are there any plans to make XEmacs multi-threaded? configure seems to look
Achim> for the pthreads library. This would be fun on my SMP system (dual Pentium
Achim> 100).

When YOU implement it, or else in XEmacs 23.15.

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 28 19:36:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA26153 for xemacs-beta-people; Wed, 28 Aug 1996 19:36:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA26150 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 28 Aug 1996 19:36:57 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA21242 for <xemacs-beta@xemacs.org>; Wed, 28 Aug 1996 19:36:53 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA23830; Wed, 28 Aug 1996 17:35:42 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA20425; Wed, 28 Aug 1996 17:35:24 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA12015; Wed, 28 Aug 1996 17:35:22 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA13125; Wed, 28 Aug 1996 17:35:17 -0700
Date: Wed, 28 Aug 1996 17:35:17 -0700
Message-Id: <199608290035.RAA13125@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: UMEMURA Akihiro <akihiro@theory.brl.ntt.jp>
Cc: xemacs-beta@xemacs.org
Subject: 20.0-b7 with MULE success on SUNOS-413U1
In-Reply-To: <199608220412.NAA01913@theory.brl.ntt.jp>
References: <199608220412.NAA01913@theory.brl.ntt.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Akihiro" == UMEMURA Akihiro <akihiro@theory.brl.ntt.jp> writes:

Akihiro> It runs well, but I found some Japanese-related problems. 
Akihiro> (For example, providing 'mule prevents running w3.)
Akihiro> Is this a correct place to report them? 

Yes, this is the place to report Japanese-related problems.

If you build with mule support, then (featurep 'mule) is automatically t.
So (require 'mule) and (provide 'mule) should both be no-ops.

On the other hand, if you (setq mule t), then various lisp code will
assume you are running the original Mule, not XEmacs with mule
support.

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 28 19:45:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA26179 for xemacs-beta-people; Wed, 28 Aug 1996 19:45:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA26176 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 28 Aug 1996 19:45:17 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA21262 for <xemacs-beta@xemacs.org>; Wed, 28 Aug 1996 19:45:13 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA26218; Wed, 28 Aug 1996 17:44:44 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA21920; Wed, 28 Aug 1996 17:44:39 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA12335; Wed, 28 Aug 1996 17:44:37 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA13156; Wed, 28 Aug 1996 17:44:32 -0700
Date: Wed, 28 Aug 1996 17:44:32 -0700
Message-Id: <199608290044.RAA13156@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: MORIOKA Tomohiko <morioka@jaist.ac.jp>
Cc: xemacs-beta@xemacs.org
Subject: 20.0 b27 with MULE success on SunOS 4.1.3 (shr)
In-Reply-To: <199608220704.QAA25168@mikan.jaist.ac.jp>
References: <199608220704.QAA25168@mikan.jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Tomo" == MORIOKA Tomohiko writes:

Tomo>   I succeed to make XEmacs 20.0 b27 on SunOS 4.1.3.

Tomo>   I tried to make as sunos4-1-3shr, however I don't know how to
Tomo> specify. So I modified configure as following:

The binaries I built for the xemacs.org distribution are statically linked.
Others care more about sunos4 than I do, perhaps they would like to
own the configure and build maintenance for that platform?

XEmacs still uses autoconf 1.11, available at
ftp.xemacs.org:/pub/beta/aux

Everyone would like to upgrade to 2.10, but it's a fair bit of work.

Hopefully Chuck will add the patch to beta 28.

Martin

--- configure-orig	Fri Jun 21 02:48:39 1996
+++ configure	Mon Jun 24 21:57:53 1996
@@ -2225,14 +2225,14 @@
     case "${canonical}" in
       ## The Sun386 didn't get past 4.0.
       i[3-9]86-*-sunos4	   ) opsys=sunos4-0      ;;
+      *-sunos4shr*	   ) opsys=sunos4-0shr   ;;
+      *-sunos4.0shr*	   ) opsys=sunos4-0shr   ;;
+      *-sunos4.1shr*	   ) opsys=sunos4-1shr   ;;
+      *-sunos4.1.2shr*	   ) opsys=sunos4-1-2shr ;;
+      *-sunos4.1.[3-9]shr* ) opsys=sunos4-1-3shr ;;
       *-sunos4.0*	   ) opsys=sunos4-0      ;;
       *-sunos4.1.2*        ) opsys=sunos4-1-2    ;;
       *-sunos4.1.[3-9]*	   ) opsys=sunos4-1-3    ;;
-      *-sunos4shr*	   ) opsys=sunos4-0shr   ;;
-      *-sunos4-0shr*	   ) opsys=sunos4-0shr   ;;
-      *-sunos4-1shr*	   ) opsys=sunos4-1shr   ;;
-      *-sunos4-1-2shr*	   ) opsys=sunos4-1-2shr ;;
-      *-sunos4-1-[3-9]shr* ) opsys=sunos4-1-3shr ;;
       *-sunos4* | *-sunos  ) opsys=sunos4-1	 ;;

       *-solaris2.3*	   ) opsys=sol2-3 	 ;;

From xemacs-beta-request@cs.uiuc.edu  Wed Aug 28 20:50:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA26397 for xemacs-beta-people; Wed, 28 Aug 1996 20:50:31 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA26394 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 28 Aug 1996 20:50:29 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA21345 for <xemacs-beta@xemacs.org>; Wed, 28 Aug 1996 20:50:27 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id SAA12484; Wed, 28 Aug 1996 18:49:58 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id SAA01807; Wed, 28 Aug 1996 18:49:55 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA14268; Wed, 28 Aug 1996 18:49:54 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA13287; Wed, 28 Aug 1996 18:49:48 -0700
Date: Wed, 28 Aug 1996 18:49:48 -0700
Message-Id: <199608290149.SAA13287@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
Cc: xemacs-beta@xemacs.org
Subject: [20.0 b27] decode-coding-string does not work
In-Reply-To: <199608220803.RAA28864@mikan.jaist.ac.jp>
References: <199608220803.RAA28864@mikan.jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Tomo" == MORIOKA Tomohiko writes:

Tomo> `decode-coding-string' seems expect return value of
Tomo> `decode-coding-region', however it returns nil even if code-conversion 
Tomo> is succeeded. So I made following quick patch:

Tomo> --- mule-coding.el-orig	Thu May 16 21:26:08 1996
Tomo> +++ mule-coding.el	Thu Aug 22 02:45:44 1996
Tomo> @@ -54,9 +54,9 @@
Tomo>  	  (set-buffer tempbuf)
Tomo>  	  (erase-buffer)
Tomo>  	  (insert str)
Tomo> -	  (setq result (decode-coding-region (point-min) (point-max)
Tomo> -					     coding-system)))
Tomo> -      (if result
Tomo> +	  (decode-coding-region (point-min) (point-max) coding-system)
Tomo> +	  )
Tomo> +      (if (> (point-max)(point-min))
Tomo>  	  (setq result (buffer-string)))
Tomo>        (set-buffer curbuf)
Tomo>        (kill-buffer tempbuf))

I looked at this code, and came up with the following patch, which
should fix both decode-coding-string and encode-coding-string.
The temporary buffer used for conversion is no longer killed, but
reused instead, as these functions might be used very frequently someday.

*** /tmp/geta13278	Wed Aug 28 18:44:01 1996
--- mule-coding.el	Wed Aug 28 18:41:56 1996
***************
*** 42,86 ****
    (let ((codings (detect-coding-region start end)))
      (message "%s" (if (or arg (symbolp codings)) codings (car codings)))))
  
  (defun decode-coding-string (str coding-system)
    "Decode the string STR which is encoded in CODING-SYSTEM.
! Does not modify STR.  Returns the decoded string on successful conversion,
! or nil on failure."
!   (let ((curbuf (current-buffer))
! 	(tempbuf (generate-new-buffer " *code-convert-work*"))
! 	result)
!     (unwind-protect
! 	(progn
! 	  (set-buffer tempbuf)
! 	  (erase-buffer)
! 	  (insert str)
! 	  (setq result (decode-coding-region (point-min) (point-max)
! 					     coding-system)))
!       (if result
! 	  (setq result (buffer-string)))
!       (set-buffer curbuf)
!       (kill-buffer tempbuf))
!     result))
  
  (defun encode-coding-string (str coding-system)
    "Encode the string STR using CODING-SYSTEM.
! Does not modify STR.  Returns the encoded string on successful conversion,
! or nil on failure."
!   (let ((curbuf (current-buffer))
! 	(tempbuf (generate-new-buffer " *code-convert-work*"))
! 	result)
!     (unwind-protect
! 	(progn
! 	  (set-buffer tempbuf)
! 	  (erase-buffer)
! 	  (insert str)
! 	  (setq result (encode-coding-region (point-min) (point-max)
! 					     coding-system)))
!       (if result
! 	  (setq result (buffer-string)))
!       (set-buffer curbuf)
!       (kill-buffer tempbuf))
!     result))
  
  
  ;;;; Coding system accessors
--- 42,75 ----
    (let ((codings (detect-coding-region start end)))
      (message "%s" (if (or arg (symbolp codings)) codings (car codings)))))
  
+ (defmacro with-string-as-buffer-contents (str &rest body)
+   "With the contents of the current buffer being STR, run BODY.
+ Returns the new contents of the buffer, as modified by BODY.
+ The original current buffer is restored afterwards."
+   `(let ((curbuf (current-buffer))
+          (tempbuf (get-buffer-create " *string-as-buffer-contents*")))
+      (unwind-protect
+          (progn
+            (set-buffer tempbuf)
+            (buffer-disable-undo (current-buffer))
+            (erase-buffer)
+            (insert ,str)
+            ,@body
+            (buffer-string))
+        (erase-buffer tempbuf)
+        (set-buffer curbuf))))
+ 
  (defun decode-coding-string (str coding-system)
    "Decode the string STR which is encoded in CODING-SYSTEM.
! Does not modify STR.  Returns the decoded string on successful conversion."
!   (with-string-as-buffer-contents
!    str (decode-coding-region (point-min) (point-max) coding-system)))
  
  (defun encode-coding-string (str coding-system)
    "Encode the string STR using CODING-SYSTEM.
! Does not modify STR.  Returns the encoded string on successful conversion."
!   (with-string-as-buffer-contents
!    str (encode-coding-region (point-min) (point-max) coding-system)))
  
  
  ;;;; Coding system accessors

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 29 00:16:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA26937 for xemacs-beta-people; Thu, 29 Aug 1996 00:16:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA26934 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 29 Aug 1996 00:16:01 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA21566 for <xemacs-beta@xemacs.org>; Thu, 29 Aug 1996 00:15:58 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id WAA15190; Wed, 28 Aug 1996 22:15:31 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA18350; Wed, 28 Aug 1996 22:15:27 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA18028; Wed, 28 Aug 1996 22:15:27 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA13586; Wed, 28 Aug 1996 22:15:20 -0700
Date: Wed, 28 Aug 1996 22:15:20 -0700
Message-Id: <199608290515.WAA13586@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: carney@gvc.dec.com
Cc: xemacs-beta@xemacs.org
Subject: asynch subprocess dumps
In-Reply-To: <9608231437.AA11384@fornet.gvc.dec.com>
References: <9606270735.AA26977@fornet.gvc.dec.com>
	<9608231437.AA11384@fornet.gvc.dec.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Stephen" == Stephen Carney <carney@gvc.dec.com> writes:

Stephen> When running under a tty, I thought it was a little strange to see
Stephen> emacs_Xt_select_process in the stack trace.  Isn't stuff from event-Xt.c
Stephen> only used for an X11 interface?

Nope. The Xt event loop is used if X support is compiled in.  That
way, it's easy to open an X device and still have just one event loop.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 29 00:31:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA27023 for xemacs-beta-people; Thu, 29 Aug 1996 00:31:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA27020 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 29 Aug 1996 00:31:54 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id AAA21588 for <xemacs-beta@xemacs.org>; Thu, 29 Aug 1996 00:31:51 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id WAA17009; Wed, 28 Aug 1996 22:31:24 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA19553; Wed, 28 Aug 1996 22:31:20 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA18247; Wed, 28 Aug 1996 22:31:20 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA13684; Wed, 28 Aug 1996 22:31:15 -0700
Date: Wed, 28 Aug 1996 22:31:15 -0700
Message-Id: <199608290531.WAA13684@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: William Perry <wmperry@aventail.com>
Cc: xemacs-beta@xemacs.org
Subject: SOCKS v4/v5
In-Reply-To: <3221CBC8.41E0@aventail.com>
References: <3221CBC8.41E0@aventail.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Bill" == William Perry <wmperry@aventail.com> writes:

Bill> Well, screw it.  Why is this even in the C code anyway?  Let's write it
Bill> in LISP!  Who's with ME?!!?!?

I agree completely.  Socks needs the flexibility.

I hope the socks5 stuff is better than socks4, with which I struggled
mightily in '95.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 29 01:15:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA27143 for xemacs-beta-people; Thu, 29 Aug 1996 01:15:14 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA27140 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 29 Aug 1996 01:15:12 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA21992 for <xemacs-beta@cs.uiuc.edu>; Thu, 29 Aug 1996 01:15:15 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id XAA21918; Wed, 28 Aug 1996 23:14:40 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id XAA21661; Wed, 28 Aug 1996 23:14:37 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id XAA19020; Wed, 28 Aug 1996 23:14:35 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id XAA13914; Wed, 28 Aug 1996 23:14:29 -0700
Date: Wed, 28 Aug 1996 23:14:29 -0700
Message-Id: <199608290614.XAA13914@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: MORIOKA Tomohiko <morioka@jaist.ac.jp>, Ben Wing <wing@666.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: [20.0-b27 with mule] string-match problem
In-Reply-To: <199608221218.VAA10069@mikan.jaist.ac.jp>
References: <199608221218.VAA10069@mikan.jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Tomo" == MORIOKA Tomohiko <ISO-2022-JP> writes:

Tomo>   When regexp is [^CHARASTERS] and first character of string is
Tomo> non-ASCII character, XEmacs crashes.

Try this patch:

(At first sight this patch looks like it doesn't have a chance, since
it just comments out the offending code.  But it seems to behave
properly afterwards, surprisingly even with Japanese characters in the
regexp and search strings.

Ben: please bless)


*** /tmp/geta13562	Wed Aug 28 21:59:04 1996
--- search.c	Wed Aug 28 21:36:11 1996
***************
*** 242,247 ****
--- 242,251 ----
  static void
  fixup_search_regs_for_string (Lisp_Object string)
  {
+   /* ### fixup_search_regs_for_buffer converts from Bytinds to
+      Bufpos's.  So this function should convert from Bufpos's to
+      Bufpos's, i.e. do nothing.  Ben? */
+ #if 0
    int i;
  
    /* #### bytecount_to_charcount() is not that efficient.  This function
***************
*** 266,271 ****
--- 270,276 ----
  				    search_regs.end[i]);
  	}
      }
+ #endif
  }
  
  

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 29 02:30:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA27290 for xemacs-beta-people; Thu, 29 Aug 1996 02:30:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA27287 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 29 Aug 1996 02:30:52 -0500 (CDT)
Received: from brlns0.brl.ntt.jp (brlns0.brl.ntt.jp [163.138.38.10]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA21729 for <xemacs-beta@xemacs.org>; Thu, 29 Aug 1996 02:29:33 -0500 (CDT)
Received: by brlns0.brl.ntt.jp (8.7.5/core*brl.mx14g) with TCP; Thu, 29 Aug 1996 16:27:49 +0900 (JST)
Received: by theory.brl.ntt.jp (8.6.9/core*brl.s11) with TCP; Thu, 29 Aug 1996 16:27:48 +0900
Message-Id: <199608290727.QAA10533@theory.brl.ntt.jp>
To: mrb@eng.sun.com
Cc: xemacs-beta@xemacs.org
Subject: 'mule (Re: 20.0-b7 with MULE success on SUNOS-413U1)
In-Reply-To: Your message of "Wed, 28 Aug 1996 17:35:17 -0700"
References: <199608290035.RAA13125@xemacs.eng.sun.com>
X-Mailer: Mew version 1.05+ on Emacs 19.28.3, Mule 2.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Thu, 29 Aug 1996 16:27:14 +0900
From: UMEMURA Akihiro <akihiro@theory.brl.ntt.jp>

From: Martin Buchholz <mrb@Eng.Sun.COM>
Subject: 20.0-b7 with MULE success on SUNOS-413U1
Date: Wed, 28 Aug 1996 17:35:17 -0700

> Yes, this is the place to report Japanese-related problems.

Thank you.

> If you build with mule support, then (featurep 'mule) is automatically t.
> So (require 'mule) and (provide 'mule) should both be no-ops.

> On the other hand, if you (setq mule t), then various lisp code will
> assume you are running the original Mule, not XEmacs with mule
> support.

I see the difference of (boundp 'MULE) and (featurep 'mule).
My understanding is as follows:
Imagine I'm writing a elisp program that should be used all
variations of Emacs.
If I want to write a part that depend on the existance of
coding-system, I should use the test (featurep 'mule), and
if I want to write a part that depend on the implementation of
coding-system, I should use the test (boundp 'MULE).

There is a question. 
Is there any use of (featurep 'mule) ?
Namely, is there any compatibility between original Mule's
coding-system and XEmacs's coding-system?
Isn't it a good idea to replace the line 

  Vfeatures = Fcons (intern ("mule"), Vfeatures);

in mule.c with

  Vfeatures = Fcons (intern ("xmule"), Vfeatures);

and use (featurep 'xmule) to check the implementation
of coding-system?

Thank you.

akihiro

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 29 09:52:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA02011 for xemacs-beta-people; Thu, 29 Aug 1996 09:52:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA02008 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 29 Aug 1996 09:52:38 -0500 (CDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA06722 for <xemacs-beta@cs.uiuc.edu>; Thu, 29 Aug 1996 09:52:29 -0500 (CDT)
Received: from deimos.darmstadt.gmd.de (deimos [141.12.63.54]) by sonne.darmstadt.gmd.de (8.7.3/8.7.3) with SMTP id QAA15496 for <xemacs-beta@cs.uiuc.edu>; Thu, 29 Aug 1996 16:51:36 +0200 (MET DST)
Date: Thu, 29 Aug 1996 16:51:36 +0200 (MET DST)
Message-Id: <199608291451.QAA15496@sonne.darmstadt.gmd.de>
From: Roland Rieke <rol@darmstadt.gmd.de>
To: xemacs-beta@cs.uiuc.edu
Subject: etags.el problem with patch for 19.14


find-tag-tag seams to return one list to much when using default

diff -cr etags.el~ etags.el

*** etags.el~	Wed Jun 19 03:22:05 1996
--- etags.el	Thu Aug 29 16:22:38 1996
***************
*** 796,802 ****
  	   'find-tag-history))
      (if (string-equal tag-name "")
  	;; #### - This is a really LAME way of doing it!  --Stig
! 	(list default)			;indicate exact symbol match
        tag-name)))
  
  (defvar last-tag-data nil
--- 796,802 ----
  	   'find-tag-history))
      (if (string-equal tag-name "")
  	;; #### - This is a really LAME way of doing it!  --Stig
! 	default			;indicate exact symbol match
        tag-name)))
  
  (defvar last-tag-data nil


From xemacs-beta-request@cs.uiuc.edu  Thu Aug 29 12:49:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA02557 for xemacs-beta-people; Thu, 29 Aug 1996 12:49:19 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA02554 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 29 Aug 1996 12:49:18 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA22689 for <xemacs-beta@xemacs.org>; Thu, 29 Aug 1996 12:49:13 -0500 (CDT)
Received: from kramer (kramer [192.168.1.12]) by newman (8.6.12/8.6.9) with SMTP id KAA07997; Thu, 29 Aug 1996 10:47:00 -0700
Sender: wmperry@newman
Message-ID: <3225D82C.3014@aventail.com>
Date: Thu, 29 Aug 1996 10:49:32 -0700
From: William Perry <wmperry@aventail.com>
Organization: Aventail, Inc.
X-Mailer: Mozilla 3.0b8Gold (X11; I; SunOS 5.5.1 i86pc)
MIME-Version: 1.0
To: Martin Buchholz <mrb@eng.sun.com>
CC: xemacs-beta@xemacs.org
Subject: Re: SOCKS v4/v5
References: <3221CBC8.41E0@aventail.com> <199608290531.WAA13684@xemacs.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Martin Buchholz wrote:
> 
> >>>>> "Bill" == William Perry <wmperry@aventail.com> writes:
> 
> Bill> Well, screw it.  Why is this even in the C code anyway?  Let's write it
> Bill> in LISP!  Who's with ME?!!?!?
> 
> I agree completely.  Socks needs the flexibility.

  I've actually got my stuff working now - its not the best.  I wish
there was a lower-level interface to network-layer stuff and file
descriptors in general.

> I hope the socks5 stuff is better than socks4, with which I struggled
> mightily in '95.

  Its a lot better.  If you run into any problems if/when anybody checks
out v5, let me know.

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Thu Aug 29 13:48:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA02786 for xemacs-beta-people; Thu, 29 Aug 1996 13:48:01 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA02783 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 29 Aug 1996 13:48:00 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA22784 for <xemacs-beta@xemacs.org>; Thu, 29 Aug 1996 13:47:53 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id LAA17424; Thu, 29 Aug 1996 11:47:26 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id LAA21361; Thu, 29 Aug 1996 11:47:15 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id LAA06223; Thu, 29 Aug 1996 11:47:10 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id LAA15252; Thu, 29 Aug 1996 11:47:05 -0700
Date: Thu, 29 Aug 1996 11:47:05 -0700
Message-Id: <199608291847.LAA15252@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: UMEMURA Akihiro <akihiro@theory.brl.ntt.jp>
Cc: xemacs-beta@xemacs.org
Subject: 'mule (Re: 20.0-b7 with MULE success on SUNOS-413U1)
In-Reply-To: <199608290727.QAA10533@theory.brl.ntt.jp>
References: <199608290035.RAA13125@xemacs.eng.sun.com>
	<199608290727.QAA10533@theory.brl.ntt.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Akihiro" == UMEMURA Akihiro <akihiro@theory.brl.ntt.jp> writes:


>> On the other hand, if you (setq mule t), then various lisp code will
>> assume you are running the original Mule, not XEmacs with mule
>> support.

Sorry, I guess I meant (setq MULE t).

Akihiro> I see the difference of (boundp 'MULE) and (featurep 'mule).
Akihiro> My understanding is as follows:
Akihiro> Imagine I'm writing a elisp program that should be used all
Akihiro> variations of Emacs.
Akihiro> If I want to write a part that depend on the existance of
Akihiro> coding-system, I should use the test (featurep 'mule), and
Akihiro> if I want to write a part that depend on the implementation of
Akihiro> coding-system, I should use the test (boundp 'MULE).

Akihiro> There is a question. 
Akihiro> Is there any use of (featurep 'mule) ?
Akihiro> Namely, is there any compatibility between original Mule's
Akihiro> coding-system and XEmacs's coding-system?
Akihiro> Isn't it a good idea to replace the line 

Akihiro>   Vfeatures = Fcons (intern ("mule"), Vfeatures);

Akihiro> in mule.c with

Akihiro>   Vfeatures = Fcons (intern ("xmule"), Vfeatures);

Akihiro> and use (featurep 'xmule) to check the implementation
Akihiro> of coding-system?

I don't think this is a good idea.  If you want to use a function, say
coding-system-list, you could just do:

(if (fboundp 'coding-system-list)
  (let ((list (coding-system-list))) 
     ....))

This makes for more portable code in the long run.

Study the Zen of the FAQ entry below:

    Q3.0.5 How to check if a lisp function is defined?

Use the following elisp: 

(fboundp 'foo)

It's almost always a mistake to test emacs-version or any similar variables. 

Instead, use feature-tests, such as featurep or boundp or fboundp, or even simple
behavioural tests, eg. 

(defvar foo-old-losing-code-p 
  (condition-case nil (progn (losing-code t) nil)
   (wrong-number-of-arguments t)))

There is an incredible amount of broken code out there which could
work much better more often in more places if it did the above instead
of trying to divine its environment from the value of one variable.


From xemacs-beta-request@cs.uiuc.edu  Thu Aug 29 22:05:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA03972 for xemacs-beta-people; Thu, 29 Aug 1996 22:05:29 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA03969 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 29 Aug 1996 22:05:28 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA23433 for <xemacs-beta@xemacs.org>; Thu, 29 Aug 1996 22:05:23 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.55 #1)
	id E0uwJr7-0005o8-00; Thu, 29 Aug 1996 23:02:49 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: Shane Holder <holder@mordor.rsn.hp.com>
Cc: xemacs-beta@xemacs.org
Subject: Running XEmacs under gdb on HP-UX
In-Reply-To: <fawloezmlyr.fsf@mordor.rsn.hp.com>
References: <fawloezmlyr.fsf@mordor.rsn.hp.com>
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.79)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uwJr7-0005o8-00@neal.ctd.comsat.com>
Date: Thu, 29 Aug 1996 23:02:49 -0400

>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:

    Shane> How do I run XEmacs under gdb.  Everytime I try, I get lots of
    Shane> SIGTRAP's even when I don't have a breakpoint set.  I don't have this
    Shane> problem when running Emacs under gdb.

I do:
handle SIGTRAP nostop noprint ignore
or something like that.

From xemacs-beta-request@cs.uiuc.edu  Fri Aug 30 12:58:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA09699 for xemacs-beta-people; Fri, 30 Aug 1996 12:58:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA09696 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 30 Aug 1996 12:58:34 -0500 (CDT)
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA24800 for <xemacs-beta@xemacs.org>; Fri, 30 Aug 1996 12:58:22 -0500 (CDT)
Received: from mordor.rsn.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA281397904; Fri, 30 Aug 1996 10:58:24 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id NAA07421; Fri, 30 Aug 1996 13:03:02 -0500 (CDT)
To: Neal Becker <neal@ctd.comsat.com>
Cc: Shane Holder <holder@mordor.rsn.hp.com>, xemacs-beta@xemacs.org
Subject: Re: Running XEmacs under gdb on HP-UX
References: <fawloezmlyr.fsf@mordor.rsn.hp.com>
	<E0uwJr7-0005o8-00@neal.ctd.comsat.com>
From: Shane Holder <holder@mordor.rsn.hp.com>
Date: 30 Aug 1996 13:03:00 -0500
In-Reply-To: Neal Becker's message of Thu, 29 Aug 1996 23:02:49 -0400
Message-Id: <fawohjsn417.fsf@mordor.rsn.hp.com>
Lines: 19
X-Mailer: Gnus v5.2.29/Emacs 19.33

>>>>> "Neal" == Neal Becker <neal@ctd.comsat.com> writes:

>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:
  Shane> How do I run XEmacs under gdb.  Everytime I try, I get lots of
  Shane> SIGTRAP's even when I don't have a breakpoint set.  I don't have this
  Shane> problem when running Emacs under gdb.

  Neal> I do:

  Neal> handle SIGTRAP nostop noprint ignore
  Neal> or something like that.

Do you know why it's getting the SIGTRAP's?  It seems odd.

-- 
Shane Holder                                 e-mail: holder@rsn.hp.com
Hewlett Packard                               phone:     (214)497-4182
3000 Waterview                       Never underestimate the bandwidth
Richardson, TX 75083                 of a truck moving at 70 MPH.

From xemacs-beta-request@cs.uiuc.edu  Fri Aug 30 19:02:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA11066 for xemacs-beta-people; Fri, 30 Aug 1996 19:02:01 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA11063 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 30 Aug 1996 19:02:00 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA25254; Fri, 30 Aug 1996 19:01:56 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA25541; Fri, 30 Aug 1996 17:01:22 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA00026; Fri, 30 Aug 1996 17:01:16 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA14915; Fri, 30 Aug 1996 17:01:17 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA18206; Fri, 30 Aug 1996 17:01:09 -0700
Date: Fri, 30 Aug 1996 17:01:09 -0700
Message-Id: <199608310001.RAA18206@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Chuck Thompson <cthomp@xemacs.org>, Ben Wing <wing@666.com>
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Need help with X window position detection code
Reply-To: Martin Buchholz <mrb@eng.sun.com>

Chuck or Ben, if you understand this, please give me a hint.

I've been trying to fix a bug, and tracked it down to this:

(Solaris Openwin + CDE)
If you resize a frame, XEmacs gets a ConfigureNotify like this,

event->xconfigure = {
    type              = 22
    serial            = 2720U
    send_event        = 0
    display           = 0x488000
    event             = 113246255U
    window            = 113246255U
    x                 = 0
    y                 = 0
    width             = 386
    height            = 352
    border_width      = 0
    above             = 0
    override_redirect = 0
}

while if you move it, it gets instead:

event->xconfigure = {
    type              = 22
    serial            = 2214U
    send_event        = 1
    display           = 0x488000
    event             = 113246255U
    window            = 113246255U
    x                 = 499
    y                 = 106
    width             = 596
    height            = 625
    border_width      = 0
    above             = 0
    override_redirect = 0
}

Notice that one of these events has x = y = 0, while the other one has
the true absolute positions of the frame.

Since there is code in event-Xt.c to save the x and y values from the
event in shell->core.x and core.y, it is clear how this can lead to
anomalous behavior.

In particular, (set-frame-properties (selected-frame) '(left 100)) has
different effects after manually moving the frame than after resizing
it.

Then there is this function in x-frame.c:

static void
x_smash_bastardly_shell_position (Widget shell)
{
  /* Naturally those bastards who wrote Xt couldn't be bothered
     to learn about race conditions and such.  We can't trust
     the X and Y values to have any semblance of correctness,
     so we smash the right values in place. */
 
 /* We might be called before we've actually realized the window (if
     we're checking for the minibuffer resource).  This will bomb in
     that case so we don't bother calling it. */
  if (XtWindow (shell))
    x_get_top_level_position (XtDisplay (shell), XtWindow (shell),
			      &shell->core.x, &shell->core.y);
}


Perhaps we should call x_smash_bastardly_shell_position whenever we
get a ConfigureNotify event rather than trusting the values in the
event.  This is my current plan to fix this bug.

Martin


From xemacs-beta-request@cs.uiuc.edu  Sat Aug 31 09:23:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA16036 for xemacs-beta-people; Sat, 31 Aug 1996 09:23:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA16033 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 31 Aug 1996 09:23:20 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA26572 for <xemacs-beta@xemacs.org>; Sat, 31 Aug 1996 09:23:18 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.55 #1)
	id E0uwquW-0006Zo-00; Sat, 31 Aug 1996 10:20:32 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: Shane Holder <holder@mordor.rsn.hp.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: Running XEmacs under gdb on HP-UX
In-Reply-To: <fawohjsn417.fsf@mordor.rsn.hp.com>
References: <fawloezmlyr.fsf@mordor.rsn.hp.com>
	<E0uwJr7-0005o8-00@neal.ctd.comsat.com>
	<fawohjsn417.fsf@mordor.rsn.hp.com>
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.79)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uwquW-0006Zo-00@neal.ctd.comsat.com>
Date: Sat, 31 Aug 1996 10:20:32 -0400

>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:

>>>>> "Neal" == Neal Becker <neal@ctd.comsat.com> writes:
>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:
    Shane> How do I run XEmacs under gdb.  Everytime I try, I get lots of
    Shane> SIGTRAP's even when I don't have a breakpoint set.  I don't have this
    Shane> problem when running Emacs under gdb.

    Neal> I do:

    Neal> handle SIGTRAP nostop noprint ignore
    Neal> or something like that.

    Shane> Do you know why it's getting the SIGTRAP's?  It seems odd.

No.  My wild guess is that maybe gdb is really getting SIGIO and is
confused.  This behavior has existed on hpux9/xemacs for at least the
quite some time, probably the last 2 years.


From xemacs-beta-request@cs.uiuc.edu  Sat Aug 31 09:59:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA16067 for xemacs-beta-people; Sat, 31 Aug 1996 09:59:16 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA16064 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 31 Aug 1996 09:59:15 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA26595 for <xemacs-beta@xemacs.org>; Sat, 31 Aug 1996 09:59:12 -0500 (CDT)
Message-Id: <199608311459.JAA26595@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA026243355; Sat, 31 Aug 1996 15:55:55 +0100
Date: Sat, 31 Aug 1996 15:55:55 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Shane Holder <holder@mordor.rsn.hp.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: XEmacs on HP-UX 10.20 and EINTR signal
In-Reply-To: <fawn2zfmmbn.fsf@mordor.rsn.hp.com>
References: <fawn2zfmmbn.fsf@mordor.rsn.hp.com>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:

    Shane> I'm running XEmacs 19.14 on HP-UX 10.20, and very
    Shane> frequently, XEmacs will die with an EINTR.  Is anyone else
    Shane> experiencing something similar to this?

I don't know when 10.20 started shipping in the US, but we've received
the info about it less than 2 weeks ago, so I wouldn't expect too many
answers to this question yet... ;-)

While I'm at it, is the broken select() call in libxcurses fixed in
10.20?

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Sat Aug 31 14:59:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA16709 for xemacs-beta-people; Sat, 31 Aug 1996 14:59:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA16706 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 31 Aug 1996 14:59:45 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA26881 for <xemacs-beta@xemacs.org>; Sat, 31 Aug 1996 14:59:43 -0500 (CDT)
Received: from mordor.rsn.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA231381583; Sat, 31 Aug 1996 12:59:43 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id PAA15909; Sat, 31 Aug 1996 15:04:19 -0500 (CDT)
To: cognot@ensg.u-nancy.fr
Cc: Shane Holder <holder@mordor.rsn.hp.com>, xemacs-beta@xemacs.org
Subject: Re: XEmacs on HP-UX 10.20 and EINTR signal
References: <fawn2zfmmbn.fsf@mordor.rsn.hp.com>
	<199608311459.JAA26595@xemacs.cs.uiuc.edu>
From: Shane Holder <holder@mordor.rsn.hp.com>
Date: 31 Aug 1996 15:04:18 -0500
In-Reply-To: Richard Cognot's message of Sat, 31 Aug 1996 15:55:55 +0100
Message-Id: <fawwwyf1fst.fsf@mordor.rsn.hp.com>
Lines: 26
X-Mailer: Gnus v5.2.39/XEmacs 19.14

>>>>> "Richard" == Richard Cognot <cognot@ensg.u-nancy.fr> writes:

>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:

  Shane> I'm running XEmacs 19.14 on HP-UX 10.20, and very
  Shane> frequently, XEmacs will die with an EINTR.  Is anyone else
  Shane> experiencing something similar to this?

  Richard> I don't know when 10.20 started shipping in the US, but
  Richard> we've received the info about it less than 2 weeks ago, so
  Richard> I wouldn't expect too many answers to this question
  Richard> yet... ;-)

I was kind of hoping that some other OS's were experiencing this
problem, or that someone else inside HP was runing 19.14, and 10.20.

  Richard> While I'm at it, is the broken select() call in libxcurses
  Richard> fixed in 10.20?

I don't think so, there's still a select symbol in the library.

-- 
Shane Holder                                 e-mail: holder@rsn.hp.com
Hewlett Packard                               phone:     (214)497-4182
3000 Waterview                       Never underestimate the bandwidth
Richardson, TX 75083                 of a truck moving at 70 MPH.

From xemacs-beta-request@cs.uiuc.edu  Sat Aug 31 15:18:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA16742 for xemacs-beta-people; Sat, 31 Aug 1996 15:18:25 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA16739 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 31 Aug 1996 15:18:24 -0500 (CDT)
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA26898 for <xemacs-beta@xemacs.org>; Sat, 31 Aug 1996 15:18:22 -0500 (CDT)
Received: from mordor.rsn.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA220622702; Sat, 31 Aug 1996 13:18:22 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id PAA15921; Sat, 31 Aug 1996 15:22:59 -0500 (CDT)
To: Neal Becker <neal@ctd.comsat.com>
Cc: Shane Holder <holder@mordor.rsn.hp.com>, xemacs-beta@xemacs.org
Subject: XEmacs SIGIO and EINTR and ioctl's
References: <fawloezmlyr.fsf@mordor.rsn.hp.com>
	<E0uwJr7-0005o8-00@neal.ctd.comsat.com>
	<fawohjsn417.fsf@mordor.rsn.hp.com>
	<E0uwquW-0006Zo-00@neal.ctd.comsat.com>
From: Shane Holder <holder@mordor.rsn.hp.com>
Date: 31 Aug 1996 15:22:55 -0500
In-Reply-To: Neal Becker's message of Sat, 31 Aug 1996 10:20:32 -0400
Message-Id: <fawvidz1exs.fsf_-_@mordor.rsn.hp.com>
Lines: 28
X-Mailer: Gnus v5.2.39/XEmacs 19.14

>>>>> "Neal" == Neal Becker <neal@ctd.comsat.com> writes:
>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:

  Shane> Do you know why it's getting the SIGTRAP's?  It seems odd.

  Neal> No.  My wild guess is that maybe gdb is really getting SIGIO
  Neal> and is confused.  This behavior has existed on hpux9/xemacs
  Neal> for at least the quite some time, probably the last 2 years.

That might be.  I'm having problems under 10.20 (see other posts), and
I've chased them down to using Darryl Okahata's patches, or defining
BROKEN_SIGIO.  Darryl's patches fix the buffered cursor problems, but
cause the EINTR problems (under 10.20).  Also, if I compile with
BROKEN_SIGIO (10.20 won't interrupt (while t) via a ^G) I get the
EINTR problems.

I also find it interesting that XEmacs scrolls much faster without
Darryl's patches, than with, he's turned off some calls to ioctl, and
changed calls to ioctl(,SIOCSPGRP,) from -owner to owner.  This type
of socket contol is new to me so I'm having to learn what's trying to
be done.  If anyone has an explanation, please let me know.  Sysdep.c
isn't really covered well in the Internals Documentation.

-- 
Shane Holder                                 e-mail: holder@rsn.hp.com
Hewlett Packard                               phone:     (214)497-4182
3000 Waterview                       Never underestimate the bandwidth
Richardson, TX 75083                 of a truck moving at 70 MPH.

From xemacs-beta-request@cs.uiuc.edu  Sat Aug 31 16:34:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA16914 for xemacs-beta-people; Sat, 31 Aug 1996 16:34:24 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA16911 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 31 Aug 1996 16:34:23 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA26945 for <xemacs-beta@xemacs.org>; Sat, 31 Aug 1996 16:34:20 -0500 (CDT)
Message-Id: <199608312134.QAA26945@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA038197072; Sat, 31 Aug 1996 22:31:12 +0100
Date: Sat, 31 Aug 1996 22:31:12 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Shane Holder <holder@mordor.rsn.hp.com>
Cc: Neal Becker <neal@ctd.comsat.com>, xemacs-beta@xemacs.org
Subject: Re: XEmacs SIGIO and EINTR and ioctl's
In-Reply-To: <fawvidz1exs.fsf_-_@mordor.rsn.hp.com>
References: <fawloezmlyr.fsf@mordor.rsn.hp.com>
	<E0uwJr7-0005o8-00@neal.ctd.comsat.com>
	<fawohjsn417.fsf@mordor.rsn.hp.com>
	<E0uwquW-0006Zo-00@neal.ctd.comsat.com>
	<fawvidz1exs.fsf_-_@mordor.rsn.hp.com>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:

>>>>> "Neal" == Neal Becker <neal@ctd.comsat.com> writes:
>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:

    Shane> That might be.  I'm having problems under 10.20 (see other
    Shane> posts), and I've chased them down to using Darryl Okahata's
    Shane> patches, or defining BROKEN_SIGIO.  Darryl's patches fix
    Shane> the buffered cursor problems, but cause the EINTR problems
    Shane> (under 10.20).  Also, if I compile with BROKEN_SIGIO (10.20
    Shane> won't interrupt (while t) via a ^G) I get the EINTR
    Shane> problems.

FWIW: assuming you still have the buggy select() in libxcurses, if you
want to have ^G interrupt (while t) (and have many, many other
problems fixed), link with -ltermcap instead of -lcurses (or is it
-lxcurses? I cannot find where I did that change...). BROKEN_SIGIO is
needed *because* of that @#%!@#$^ select().

This broken select() is also resposible for XEmacs outputing a "poll:
interrupted system call" error message everytime it gets an event.

I saw a patch for this (PHCO_8086, I think), but I don't know if it
really works, as I haven't had the time to recompile XEmacs recently.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Sat Aug 31 17:39:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA17033 for xemacs-beta-people; Sat, 31 Aug 1996 17:39:52 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA17030 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 31 Aug 1996 17:39:51 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA04505 for <xemacs-beta@cs.uiuc.edu>; Sat, 31 Aug 1996 17:39:49 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id PAA01971; Sat, 31 Aug 1996 15:36:31 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: sample.emacs & http://www.XEmacs.org/beta/
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.80)
Content-Type: text/plain; charset=US-ASCII
Date: 31 Aug 1996 15:36:30 -0700
Message-ID: <m2wwyf6v0x.fsf@deanna.miranova.com>
Lines: 30
X-Mailer: Gnus v5.2.40/XEmacs 19.14

[1]  sample.emacs in 19.14 currently contains the code:

	      ;; Here's a way to add scrollbar-like buttons to the menubar
	      (add-menu-item nil "Top" 'beginning-of-buffer t)
	      (add-menu-item nil "<<<" 'scroll-down t)
	      (add-menu-item nil " . " 'recenter t)
	      (add-menu-item nil ">>>" 'scroll-up t)
	      (add-menu-item nil "Bot" 'end-of-buffer t)

The docstring for add-menu-item says:
add-menu-item: (menu-path item-name function enabled-p &optional before)
  -- a compiled Lisp function.
Obsolete; use `add-menu-button' instead.

Obsolete.  See the function `add-menu-button'.

I am unable to divine what magic add-menu-button requires to do the
same operation, but I don't think use of obsolete functions should be
encouraged.

[2]  Would you please allow access to the README files that are
currently displayed when one ftps to /pub/beta on the web site?  It
would be nice to have a `one-stop-shopping' URL just for checking on
the current beta status.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Sun Sep  1 01:45:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA18959 for xemacs-beta-people; Sun, 1 Sep 1996 01:45:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA18956 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 1 Sep 1996 01:45:00 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA27413 for <xemacs-beta@xemacs.org>; Sun, 1 Sep 1996 01:44:58 -0500 (CDT)
Received: from mordor.rsn.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA101240289; Sat, 31 Aug 1996 23:44:50 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id BAA16192; Sun, 1 Sep 1996 01:49:26 -0500 (CDT)
To: cognot@ensg.u-nancy.fr
Cc: Shane Holder <holder@mordor.rsn.hp.com>, Neal Becker <neal@ctd.comsat.com>,
        xemacs-beta@xemacs.org
Subject: Re: XEmacs SIGIO and EINTR and ioctl's
References: <fawloezmlyr.fsf@mordor.rsn.hp.com>
	<E0uwJr7-0005o8-00@neal.ctd.comsat.com>
	<fawohjsn417.fsf@mordor.rsn.hp.com>
	<E0uwquW-0006Zo-00@neal.ctd.comsat.com>
	<fawvidz1exs.fsf_-_@mordor.rsn.hp.com>
	<199608312134.QAA26945@xemacs.cs.uiuc.edu>
From: Shane Holder <holder@mordor.rsn.hp.com>
Date: 01 Sep 1996 01:49:25 -0500
In-Reply-To: Richard Cognot's message of Sat, 31 Aug 1996 22:31:12 +0100
Message-Id: <fawu3tibuh6.fsf@mordor.rsn.hp.com>
Lines: 47
X-Mailer: Gnus v5.2.39/XEmacs 19.14

>>>>> "Richard" == Richard Cognot <cognot@ensg.u-nancy.fr> writes:

>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:

>>>>> "Neal" == Neal Becker <neal@ctd.comsat.com> writes:
>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:

  Shane> That might be.  I'm having problems under 10.20 (see other
  Shane> posts), and I've chased them down to using Darryl Okahata's
  Shane> patches, or defining BROKEN_SIGIO.  Darryl's patches fix
  Shane> the buffered cursor problems, but cause the EINTR problems
  Shane> (under 10.20).  Also, if I compile with BROKEN_SIGIO (10.20
  Shane> won't interrupt (while t) via a ^G) I get the EINTR
  Shane> problems.

  Richard> FWIW: assuming you still have the buggy select() in
  Richard> libxcurses, if you want to have ^G interrupt (while t) (and
  Richard> have many, many other problems fixed), link with -ltermcap
  Richard> instead of -lcurses (or is it -lxcurses? I cannot find
  Richard> where I did that change...). BROKEN_SIGIO is needed
  Richard> *because* of that @#%!@#$^ select().

  Richard> This broken select() is also resposible for XEmacs
  Richard> outputing a "poll: interrupted system call" error message
  Richard> everytime it gets an event.

Interesting, I thought that the symptoms of the select problem was
only the "poll interrupted system call" messages, which I never saw, I
link archive_shared, which links the executable with all archive
libraries unless it can't find an archived version, and I thought I
read that an archived version didn't have the poll problems.  I'll try
the -ltermcap.

  Richard> I saw a patch for this (PHCO_8086, I think), but I don't
  Richard> know if it really works, as I haven't had the time to
  Richard> recompile XEmacs recently.

I'll also check that patch.

Thanks,
Shane

-- 
Shane Holder                                 e-mail: holder@rsn.hp.com
Hewlett Packard                               phone:     (214)497-4182
3000 Waterview                       Never underestimate the bandwidth
Richardson, TX 75083                 of a truck moving at 70 MPH.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  2 05:12:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA29024 for xemacs-beta-people; Mon, 2 Sep 1996 05:12:06 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA29021 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 2 Sep 1996 05:12:05 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA02789 for <xemacs-beta@cs.uiuc.edu>; Mon, 2 Sep 1996 05:12:29 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id DAA17875; Mon, 2 Sep 1996 03:11:34 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id DAA04259; Mon, 2 Sep 1996 03:11:32 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id DAA07308; Mon, 2 Sep 1996 03:11:31 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id DAA22248; Mon, 2 Sep 1996 03:11:29 -0700
Date: Mon, 2 Sep 1996 03:11:29 -0700
Message-Id: <199609021011.DAA22248@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: sample.emacs & http://www.XEmacs.org/beta/
In-Reply-To: <m2wwyf6v0x.fsf@deanna.miranova.com>
References: <m2wwyf6v0x.fsf@deanna.miranova.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

Steven> [1]  sample.emacs in 19.14 currently contains the code:
Steven> 	      ;; Here's a way to add scrollbar-like buttons to the menubar
Steven> 	      (add-menu-item nil "Top" 'beginning-of-buffer t)
Steven> 	      (add-menu-item nil "<<<" 'scroll-down t)
Steven> 	      (add-menu-item nil " . " 'recenter t)
Steven> 	      (add-menu-item nil ">>>" 'scroll-up t)
Steven> 	      (add-menu-item nil "Bot" 'end-of-buffer t)

I've changed these calls to use add-menu-button and made other minor
corrections to sample.emacs.  In 20.0 beta 28.

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 10:48:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA13374 for xemacs-beta-people; Wed, 4 Sep 1996 10:48:20 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA13371 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 10:48:19 -0500 (CDT)
Received: from dowjones.com (firewall-user@gateway.dowjones.com [143.131.189.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA03064 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 10:48:15 -0500 (CDT)
Received: by dowjones.com; id LAA13162; Wed, 4 Sep 1996 11:49:12 -0400 (EDT)
Received: from wsj.dowjones.com(143.131.186.4) by gateway.dowjones.com via smap (V3.1.1)
	id xma013114; Wed, 4 Sep 96 11:48:49 -0400
Received: from nss_interbox.dowjones.com ([143.131.190.35]) by wsj.dowjones.com (5.x/SMI-SVR4)
	id AA00458; Wed, 4 Sep 1996 11:49:07 -0400
Message-Id: <322DB186.7601@nrs.dowjones.com>
Date: Wed, 04 Sep 1996 11:42:46 -0500
From: wkirk <wkirk@wsj.dowjones.com>
Organization: Dow Jones & Company, Inc.
X-Mailer: Mozilla 2.0 (Win16; U)
Mime-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: event-point returns wrong value in 19.14
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

event-point can sometimes return the wrong value in XEmacs 19.14 when
a process filter is inserting to the top of the buffer and window-start
is below point-min.  Usually, the right value is returned, but it is 
occasionally off (often enough to be a problem).

I originally thought the problem was some kind of race between
event-point and redisplay invalidating the pixel_to_glyph_cache.
However, I explicitly invalidated the cache in event_pixel_translation
(events.c) before the call to pixel_to_glyph_translation (redisplay.c)
and the problem persisted.  The only other explanations that I can think
of is either emacs is computing the buffer position incorrectly or
getting the mouse - window coordinates confused somewhere.  This pretty
much brings me to the limits of my understanding of the emacs redisplay/
event code so I am reporting this now.  I will continue to investigate
the problem from my end as well since it's pretty important to us to get
this one fixed.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 13:20:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA13970 for xemacs-beta-people; Wed, 4 Sep 1996 13:20:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA13967 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 13:20:38 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA03514 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 13:20:34 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id LAA11399; Wed, 4 Sep 1996 11:19:04 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id LAA17879; Wed, 4 Sep 1996 11:18:04 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id LAA14576; Wed, 4 Sep 1996 11:18:00 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id LAA00170; Wed, 4 Sep 1996 11:17:55 -0700
Date: Wed, 4 Sep 1996 11:17:55 -0700
Message-Id: <199609041817.LAA00170@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: RMS' message re XEmacs
Reply-To: Martin Buchholz <mrb@eng.sun.com>

For those who haven't seen this:

From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Versions of Emacs
Newsgroups: gnu.emacs.sources
Date: Thu, 29 Aug 1996 17:07:39 -0400
x-gateway: relay2.UU.NET from gnu-emacs-sources to gnu.emacs.sources; Thu, 29 Aug 1996 22:51:49 EDT
Message-ID: <199608292029.QAA01520@ethanol.gnu.ai.mit.edu>
Path: engnews1.Eng.Sun.COM!news2me.EBay.Sun.COM!venus.sun.com!ames!enews.sgi.com!news.mathworks.com!uunet!in2.uu.net!wendy-fate.uu.net!gnu-emacs-sources
Sender: gnu-emacs-sources-request@prep.ai.mit.edu
Lines: 67

I appreciate your forbearance from using the term "FSF Emacs" and I'm
glad that you don't share the hostility of some of the other people
who have worked on XEmacs.  I didn't intend to imply that all of the
people who worked on XEmacs felt that way--only some of them.

XEmacs is a paradoxical case because it is GNU software in one sense,
and in another sense it is not.

XEmacs is GNU software because it's a modified version of a GNU
program.  And it is GNU software because the FSF is the copyright
holder for most of it, and therefore the legal responsibility for
protecting its free status falls on us whether we want it or not.
This is why the term "GNU XEmacs" is legitimate.

But in another sense it is not GNU software, because we can't use
XEmacs in the GNU system: using it would mean paying a price in terms
of our ability to enforce the GPL.  Some of the people who have worked
on XEmacs have not provided, and have not asked other contributors to
provide, the legal papers to help us enforce the GPL.  I have managed
to get legal papers for some parts myself, but most of the XEmacs
developers have not helped me get them.

XEmacs was possible because free software means that anyone can change
it and distribute a modified version.  I have no regrets about
establishing this freedom for Emacs.  Everyone should have the freedom
to change any program, and this is not limited to changes that the
original author likes.

Many people have taken advantage of the freedom to change GNU Emacs,
over the last decade.  Most of them were willing to cooperate on
integrating their changes into Emacs.  XEmacs arose as a separate
forked version because some of the developers--starting with
Zawinski--were unwilling to do that.

People should have the freedom to decide what to work on, including
the freedom to compete with the GNU project, but it's a shame when
they make that choice.  The whole community loses when someone chooses
competition rather than cooperation.

But this is worse than competition--it is unfair competition.  The
XEmacs developers can and do copy code they like from Emacs.  If I
could copy the code I like from XEmacs in the same way, at least the
rivalry would be fair.  But I can't do that't, because substantial
parts of XEmacs don't have legal papers, or don't have known authors.

As long as we cannot use XEmacs in the GNU system, the GNU project has
to make sure that Emacs is not left behind.  In other words, we have
to behave like rivals too, even though we wish there were no rivalry.
When XEmacs developers try to persuade people to use, test, fix and
enhance XEmacs instead of Emacs, the GNU project can't sit still; we
need them to use, test, fix and enhance Emacs instead.

There is good code in XEmacs, which I'd be happy to have in a merged
Emacs any day.  But I cannot copy it out of XEmacs myself because of
the uncertain authorship and/or lack of legal papers.

This problem could probably be resolved, at least for large parts of
XEmacs, with substantial help from the authors of that code.
Otherwise, the GNU project has to write or find replacements for it.

I invite people who like Emacs, and want the best possible version of
Emacs to be available for use in the GNU system, to help in one way or
the other.


Let's please move further discussion of this to gnu.misc.discuss.


From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 13:28:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA14025 for xemacs-beta-people; Wed, 4 Sep 1996 13:28:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA14022 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 13:28:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA03532; Wed, 4 Sep 1996 13:28:10 -0500 (CDT)
Message-Id: <199609041828.NAA03532@xemacs.cs.uiuc.edu>
To: Martin Buchholz <mrb@eng.sun.com>
cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: RMS' message re XEmacs 
In-reply-to: Your message of "Wed, 04 Sep 1996 11:17:55 PDT."
             <199609041817.LAA00170@xemacs.eng.sun.com> 
Date: Wed, 04 Sep 1996 13:28:09 -0500
From: Chuck Thompson <cthomp@xemacs.org>

As a point of reference, this was in reply to a message I posted
responding to some statements he made.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 13:47:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA14103 for xemacs-beta-people; Wed, 4 Sep 1996 13:47:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA14100 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 13:47:38 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA03559 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 13:47:35 -0500 (CDT)
Received: from xdiv.lanl.gov (xdiv.lanl.gov [128.165.116.106]) by mailhost.lanl.gov (8.7.5/8.7.3) with ESMTP id MAA08088 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 12:47:36 -0600 (MDT)
Received: from branagh.lanl.gov (branagh.lanl.gov [128.165.16.72]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id MAA12093 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 12:47:37 -0600
Received: by branagh.lanl.gov (SMI-8.6/SMI-SVR4)
	id MAA05841; Wed, 4 Sep 1996 12:46:15 -0600
Date: Wed, 4 Sep 1996 12:46:15 -0600
Message-Id: <199609041846.MAA05841@branagh.lanl.gov>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: Re: RMS' message re XEmacs
In-Reply-To: <199609041817.LAA00170@xemacs.eng.sun.com>
References: <199609041817.LAA00170@xemacs.eng.sun.com>
Reply-To: turner@lanl.gov

Martin Buchholz writes:
 > For those who haven't seen this:
 > 
 > From: rms@gnu.ai.mit.edu (Richard Stallman)
 > Subject: Versions of Emacs
 > Newsgroups: gnu.emacs.sources
 > Date: Thu, 29 Aug 1996 17:07:39 -0400

[snip]

 > Let's please move further discussion of this to gnu.misc.discuss.

Note that there have indeed been followups in g.m.d.  One of them,
from Erik Naggum, was quite harsh toward XEmacs...

-John

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 14:04:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA14153 for xemacs-beta-people; Wed, 4 Sep 1996 14:04:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14150 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 14:04:26 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA03604 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 14:04:22 -0500 (CDT)
Received: from kramer (kramer [192.168.1.12]) by newman (8.6.12/8.6.9) with SMTP id MAA15395 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 12:02:38 -0700
Sender: wmperry@newman
Message-ID: <322DD2E0.5FF2@aventail.com>
Date: Wed, 04 Sep 1996 12:05:04 -0700
From: William Perry <wmperry@aventail.com>
Organization: Aventail, Inc.
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 i86pc)
MIME-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: MD5 implementation...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I was thinking perhaps we should remove the RSA md5.[ch] files from
XEmacs and replace them with something a little more GNUish.  The
textutils has a GPL'd md5 implementation.  I'll look into moving it out
into the XEmacs source and see what happens.  I might also change the
interface so that you can have multiple concurrent MD5 computations
going - this would involve having a new MD5_ctx data type (unless anyone
can think of a good way to represent this as a lisp vector or
something).

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 14:25:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA14254 for xemacs-beta-people; Wed, 4 Sep 1996 14:25:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14251 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 14:25:51 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA03643 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 14:25:49 -0500 (CDT)
Message-Id: <199609041925.OAA03643@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA237245097; Wed, 4 Sep 1996 20:24:57 +0100
Date: Wed, 4 Sep 1996 20:24:57 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: turner@lanl.gov
Cc: xemacs-beta@xemacs.org
Subject: Re: RMS' message re XEmacs
In-Reply-To: <199609041846.MAA05841@branagh.lanl.gov>
References: <199609041817.LAA00170@xemacs.eng.sun.com>
	<199609041846.MAA05841@branagh.lanl.gov>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:

    >> Let's please move further discussion of this to
    >> gnu.misc.discuss.

    John> Note that there have indeed been followups in g.m.d.  One of
    John> them, from Erik Naggum, was quite harsh toward XEmacs...

Why is it that I'm not surprised he jumped in on this discussion...

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 15:33:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA14489 for xemacs-beta-people; Wed, 4 Sep 1996 15:33:34 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA14482 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 15:33:33 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id PAA03733 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 15:33:30 -0500 (CDT)
Received: from kramer (kramer [192.168.1.12]) by newman (8.6.12/8.6.9) with SMTP id NAA16088; Wed, 4 Sep 1996 13:31:37 -0700
Sender: wmperry@newman
Message-ID: <322DE7BC.5235@aventail.com>
Date: Wed, 04 Sep 1996 13:34:04 -0700
From: William Perry <wmperry@aventail.com>
Organization: Aventail, Inc.
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 i86pc)
MIME-Version: 1.0
To: cognot@ensg.u-nancy.fr
CC: turner@lanl.gov, xemacs-beta@xemacs.org
Subject: Re: RMS' message re XEmacs
References: <199609041817.LAA00170@xemacs.eng.sun.com>
		<199609041846.MAA05841@branagh.lanl.gov> <199609041925.OAA03643@xemacs.cs.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Richard Cognot wrote:
> 
> >>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:
> 
>     >> Let's please move further discussion of this to
>     >> gnu.misc.discuss.
> 
>     John> Note that there have indeed been followups in g.m.d.  One of
>     John> them, from Erik Naggum, was quite harsh toward XEmacs...
> 
> Why is it that I'm not surprised he jumped in on this discussion...

  You aren't apparently completely disconnected from reality. :)  Erik
seems to be quite the opinionated wanker at times.  If only his opinions
were right all the time like mine, it wouldn't be nearly as offensive
and annoying.

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 15:56:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA14567 for xemacs-beta-people; Wed, 4 Sep 1996 15:56:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA14564 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 15:56:20 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA03800 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 15:56:18 -0500 (CDT)
Message-Id: <199609042056.PAA03800@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA271990516; Wed, 4 Sep 1996 21:55:16 +0100
Date: Wed, 4 Sep 1996 21:55:16 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: William Perry <wmperry@aventail.com>
Cc: turner@lanl.gov, xemacs-beta@xemacs.org
Subject: Re: RMS' message re XEmacs
In-Reply-To: <322DE7BC.5235@aventail.com>
References: <199609041817.LAA00170@xemacs.eng.sun.com>
	<199609041846.MAA05841@branagh.lanl.gov>
	<199609041925.OAA03643@xemacs.cs.uiuc.edu>
	<322DE7BC.5235@aventail.com>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "William" == William Perry <wmperry@aventail.com> writes:

    William> Erik seems to be quite the opinionated wanker
    William> at times.

Hmmm. 'fraid I might even call that an understatement... ;-)

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 16:25:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA14630 for xemacs-beta-people; Wed, 4 Sep 1996 16:25:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA14627 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 16:25:57 -0500 (CDT)
Received: from pixar.com (pixar.pixar.com [138.72.10.20]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA03848 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 16:25:55 -0500 (CDT)
Received: from zule.pixar.com (gate-zule.pixar.com) by pixar.com with SMTP id AA04415
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Wed, 4 Sep 1996 14:25:22 -0700
Received: by zule.pixar.com (Smail3.1.28.1 #12)
	id m0uyPRr-0007rTC; Wed, 4 Sep 96 14:25 PDT
Message-Id: <m0uyPRr-0007rTC@zule.pixar.com>
Date: Wed, 4 Sep 96 14:25 PDT
From: Hunter Kelly <retnuh@zule.pixar.com>
To: xemacs-beta@xemacs.org
Subject: Re: RMS' message re XEmacs
In-Reply-To: <322DE7BC.5235@aventail.com>
References: <199609041817.LAA00170@xemacs.eng.sun.com>
	<199609041846.MAA05841@branagh.lanl.gov>
	<199609041925.OAA03643@xemacs.cs.uiuc.edu>
	<322DE7BC.5235@aventail.com>
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII


>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:
>> Let's please move further discussion of this to
>> gnu.misc.discuss.

John> Note that there have indeed been followups in g.m.d.  One of
John> them, from Erik Naggum, was quite harsh toward XEmacs...

Could someone forward some of this dialog to me?  My newsfeed
apparently expires the articles before I could read them.

Thanks,
Hunter

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 16:37:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA14745 for xemacs-beta-people; Wed, 4 Sep 1996 16:37:50 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA14742 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 16:37:49 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA03884 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 16:37:46 -0500 (CDT)
Message-Id: <199609042137.QAA03884@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA001243022; Wed, 4 Sep 1996 22:37:02 +0100
Date: Wed, 4 Sep 1996 22:37:02 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Hunter Kelly <retnuh@zule.pixar.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: RMS' message re XEmacs
In-Reply-To: <m0uyPRr-0007rTC@zule.pixar.com>
References: <199609041817.LAA00170@xemacs.eng.sun.com>
	<199609041846.MAA05841@branagh.lanl.gov>
	<199609041925.OAA03643@xemacs.cs.uiuc.edu>
	<322DE7BC.5235@aventail.com>
	<m0uyPRr-0007rTC@zule.pixar.com>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Hunter" == Hunter Kelly <retnuh@zule.pixar.com> writes:

>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:
    >>> Let's please move further discussion of this to
    >>> gnu.misc.discuss.

    John> Note that there have indeed been followups in g.m.d.  One of
    John> them, from Erik Naggum, was quite harsh toward XEmacs...

    Hunter> Could someone forward some of this dialog to me?  My
    Hunter> newsfeed apparently expires the articles before I could
    Hunter> read them.

Hasn't arrived here yet either, although John's followup has... Wait
and see...

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 16:35:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA14708 for xemacs-beta-people; Wed, 4 Sep 1996 16:35:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA14705 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 16:35:29 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA03870 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 16:35:25 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id RAA25063; Wed, 4 Sep 1996 17:35:11 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp025030; Wed Sep  4 17:34:33 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA03273; Wed, 4 Sep 96 17:34:31 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA17888; Wed, 4 Sep 96 17:34:30 EDT
Message-Id: <9609042134.AA17888@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Dissatisfaction guaranteed.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Versions of Emacs
In-Reply-To: Your message of "Wed, 04 Sep 1996 11:17:55 PDT."
             <199609041817.LAA00170@xemacs.eng.sun.com> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMi311NqLLcGaQCk9AQGoWAP/c6D5Fu/97x41gD6cjZwPNkcbV8NBRH/Y
	      DsJM6tYtj0hlI2gfDUiVAQqBG/gCF32OlghTukOa8q4CNxEXfvMrqZGFd0d4CERW
	      rasbI5LfEVIWD/Mj4o2R82SQF6Eet6V/oLHrOtKYC+VQNAtveZ3fUnBwbUN2yYEd
	      UaP6Rhz6EEQ=
	      =NQDt
Date: Wed, 04 Sep 1996 17:34:22 -0400
Sender: rickc@lehman.com

    Date: Wed, 4 Sep 1996 11:17:55 -0700
    From: Martin Buchholz <mrb@eng.sun.com>

    From: rms@gnu.ai.mit.edu (Richard Stallman)
    Date: Thu, 29 Aug 1996 17:07:39 -0400

    . . .
    
    Many people have taken advantage of the freedom to change GNU Emacs,
    over the last decade.  Most of them were willing to cooperate on
    integrating their changes into Emacs.  XEmacs arose as a separate
    forked version because some of the developers--starting with
    Zawinski--were unwilling to do that.

This strikes me as an inaccurate characterization of what happened.  It
is certainly true that it was not possible for RMS and JWZ (and RPG) to
come to an agreement as to how Emacs development should proceed.  Who
was `at fault' -- whatever that means -- is far less clear.  My
impression was that RMS was extremely unwilling to yield any amount of
decision making power to anyone and that he preferred to avoid data
abstraction in cases where I thought that it would be appropriate.
Since then, my feelings that RMS needs to have the ultimate say on every
decision regarding FSF's GNU Emacs have grown stronger.

I have an archive of some of the messages that were exchanged around the
time of the schism.  See http://www.c2.org/~campbell/rms-jwz.tar.gz for
an MH folder (directory with one message per file).  Append .uu to the
URL if you have trouble getting the binary file.

    The whole community loses when someone chooses competition rather
    than cooperation.

This may or may not be true.  There are a significant number of people
in the world who believe that competition is a good thing, that the end
results are better when competition exists.  In any case the FSF/Lucid
schism definitely involved some failure to cooperate on RMS' part.
    
    But this is worse than competition--it is unfair competition.  The
    XEmacs developers can and do copy code they like from Emacs.  If I
    could copy the code I like from XEmacs in the same way, at least the
    rivalry would be fair.  But I can't do that't, because substantial
    parts of XEmacs don't have legal papers, or don't have known authors.

    . . .
    
    There is good code in XEmacs, which I'd be happy to have in a merged
    Emacs any day.  But I cannot copy it out of XEmacs myself because of
    the uncertain authorship and/or lack of legal papers.

RMS has set up his own requirements and then complains that his actions
are restricted when others fail to meet his requirements.  The `legal
papers' issue is a red herring.

In fact, much of this is related to a part of RMS' philosophy which some
advocates of Free Software reject.  While I have written software that I
have distributed under the GPL, I have also written software that I have
distributed as Public Domain.  In general, I prefer the Public Domain
model to the restrictions of the GPL.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 16:58:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA14809 for xemacs-beta-people; Wed, 4 Sep 1996 16:58:06 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA14803 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 16:58:01 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA16684 for <xemacs-beta@cs.uiuc.edu>; Wed, 4 Sep 1996 16:57:52 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id OAA24249; Wed, 4 Sep 1996 14:55:09 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: RMS' message re XEmacs
References: <199609041817.LAA00170@xemacs.eng.sun.com>
	<199609041846.MAA05841@branagh.lanl.gov>
	<199609041925.OAA03643@xemacs.cs.uiuc.edu>
	<322DE7BC.5235@aventail.com> <m0uyPRr-0007rTC@zule.pixar.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Hunter Kelly's message of Wed, 4 Sep 96 14:25 PDT
Mime-Version: 1.0 (generated by tm-edit 7.81)
Content-Type: multipart/mixed;
 boundary="Multipart_Wed_Sep__4_14:55:08_1996-1"
Content-Transfer-Encoding: 7bit
Date: 04 Sep 1996 14:55:08 -0700
Message-ID: <m24tlekksj.fsf@deanna.miranova.com>
Lines: 70
X-Mailer: Red Gnus v0.26/XEmacs 19.14

--Multipart_Wed_Sep__4_14:55:08_1996-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "Hunter" == Hunter Kelly <retnuh@zule.pixar.com> writes:
>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:

John> Note that there have indeed been followups in g.m.d.  One of
John> them, from Erik Naggum, was quite harsh toward XEmacs...

Hunter> Could someone forward some of this dialog to me?  My newsfeed
Hunter> apparently expires the articles before I could read them.

If you have Red Gnus, open a Dejanews nnweb group and feed it the
search string `Emacs Versions'. :-)


--Multipart_Wed_Sep__4_14:55:08_1996-1
Content-Type: text/plain; charset=US-ASCII

Path: news.callamer.com!news.west.net!hsno.wco.com!waldorf.csc.calpoly.edu!charnel.ecst.csuchico.edu!newshub.csu.net!csulb.edu!news.sgi.com!enews.sgi.com!news.mathworks.com!newsfeed.internetmci.com!in3.uu.net!mcsun!EU.net!Norway.EU.net!nntp.uio.no!ifi.uio.no!usenet
From: Erik Naggum <erik@naggum.no>
Newsgroups: gnu.misc.discuss
Subject: Re: Versions of Emacs
Date: 03 Sep 1996 16:41:12 +0000
Organization: Naggum Software; +47 2295 0313; http://www.naggum.no
Lines: 27
Sender: erik@arcana.naggum.no
Message-ID: <3050757672434669@arcana.naggum.no>
References: <199608292029.QAA01520@ethanol.gnu.ai.mit.edu> <x7sp8zpsb7.fsf@unilab.dfci.harvard.edu>
NNTP-Posting-Host: naggum.no
X-Newsreader: Gnus v5.3/Emacs 19.34

[Richard Pieri]

|   Competition was not the goal, but face reality: XEmacs is the best
|   version of GNU Emacs out there because it has gone ahead and made
|   improvements that you and the FSF were unwilling to make.

I think XEmacs stinks.  it's Lisp is riddled with unnecessarily complex
abstract types, it is incredibly slow compared to Emacs, all the versions I
have tried have crashed on me.  I'm not a member of the "mouse generation",
but rather of "cat generation", and I am sufficiently experienced with what
computers can do that I am not fascinated by glitzy user interfaces (GUIs).
I really want an Emacs based on Common Lisp so I have a fully functional
Common Lisp environment.  (or GUILE -- I guess I can implement most of
Common Lisp on top of GUILE, which also looks _uniquely_ horrible.)

|   Rivalry is good for development.

no.  rivalry is good for producing changes in superficial aspects of
something that makes for less actual development and more competition in
areas where users who don't know what they're looking for will look.  in
particular, gimmick-laden user interfaces (GUIs).  this is not good when
more fundamental development requires time and resources that such rivalry
will eat up for ephemeral qualities.

#\Erik
-- 
those who do not know Lisp are doomed to reimplement it

--Multipart_Wed_Sep__4_14:55:08_1996-1
Content-Type: text/plain; charset=US-ASCII

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

--Multipart_Wed_Sep__4_14:55:08_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 21:48:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA15729 for xemacs-beta-people; Wed, 4 Sep 1996 21:48:53 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA15726 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 21:48:52 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA04270 for <xemacs-beta@xemacs.org>; Wed, 4 Sep 1996 21:48:50 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id TAA18987; Wed, 4 Sep 1996 19:48:20 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id LAA25622; Wed, 4 Sep 1996 11:47:25 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id LAA15532; Wed, 4 Sep 1996 11:47:21 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id LAA00234; Wed, 4 Sep 1996 11:47:16 -0700
Date: Wed, 4 Sep 1996 11:47:16 -0700
Message-Id: <199609041847.LAA00234@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: From the Linux Journal contents #31
Reply-To: Martin Buchholz <mrb@eng.sun.com>


UPCOMING:

A Comparison of Xemacs and Gnu emacs

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 22:06:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA15759 for xemacs-beta-people; Wed, 4 Sep 1996 22:06:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA15756 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 22:06:39 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA29424 for <xemacs-beta@cs.uiuc.edu>; Wed, 4 Sep 1996 22:06:39 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id UAA29375; Wed, 4 Sep 1996 20:03:57 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Fixing a long-standing annoyance: backward-delete-char-untabify
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.81)
Content-Type: text/plain; charset=US-ASCII
Date: 04 Sep 1996 20:03:56 -0700
Message-ID: <m2u3tdhdcz.fsf@deanna.miranova.com>
Lines: 34
X-Mailer: Red Gnus v0.26/XEmacs 19.14

It has always annoyed me that the default function in Emacs destroys
tabs when backspacing.  It is possible to redefine the function
altogether (which I've been doing for 10 years), but isn't it time to
make fixable without requiring the user to write Emacs lisp?

Pretty please Chuck?

--- simple.el~	Wed Sep  4 19:52:10 1996
+++ simple.el	Wed Sep  4 19:54:45 1996
@@ -303,6 +303,9 @@
   (if (eq arg '-) (setq arg -1))
   (kill-region (point) (- (point) arg)))
 
+(defvar dont-preserve-tabs t
+  "If nil preserve tabs when back spacing.")
+
 (defun backward-delete-char-untabify (arg &optional killp)
   "Delete characters backward, changing tabs into spaces.
 Delete ARG chars, and kill (save in kill ring) if KILLP is non-nil.
@@ -312,7 +315,7 @@
   (let ((count arg))
     (save-excursion
       (while (and (> count 0) (not (bobp)))
-	(if (= (preceding-char) ?\t)
+	(if (and dont-preserve-tabs (= (preceding-char) ?\t))
 	    (let ((col (current-column)))
 	      (forward-char -1)
 	      (setq col (- col (current-column)))

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep  4 22:27:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA15845 for xemacs-beta-people; Wed, 4 Sep 1996 22:27:38 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA15841 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 4 Sep 1996 22:27:37 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA29705 for <xemacs-beta@cs.uiuc.edu>; Wed, 4 Sep 1996 22:27:37 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id UAA25105; Wed, 4 Sep 1996 20:27:00 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA25680; Wed, 4 Sep 1996 20:26:58 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA25835; Wed, 4 Sep 1996 20:26:56 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA03954; Wed, 4 Sep 1996 20:26:52 -0700
Date: Wed, 4 Sep 1996 20:26:52 -0700
Message-Id: <199609050326.UAA03954@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Fixing a long-standing annoyance: backward-delete-char-untabify
In-Reply-To: <m2u3tdhdcz.fsf@deanna.miranova.com>
References: <m2u3tdhdcz.fsf@deanna.miranova.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

Steven> It has always annoyed me that the default function in Emacs destroys
Steven> tabs when backspacing.  It is possible to redefine the function
Steven> altogether (which I've been doing for 10 years), but isn't it time to
Steven> make fixable without requiring the user to write Emacs lisp?

Don't you want to use backward-delete-char instead of
backward-delete-char-untabify?

Maybe
(fset 'backward-delete-char-untabify 'backward-delete-char)

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 05:00:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA20103 for xemacs-beta-people; Thu, 5 Sep 1996 05:00:53 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA20100 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 05:00:52 -0500 (CDT)
Received: from pallas.spacetec.no (pallas.spacetec.no [192.51.5.92]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA04700 for <xemacs-beta@xemacs.org>; Thu, 5 Sep 1996 05:00:45 -0500 (CDT)
Received: (from tor@localhost) by pallas.spacetec.no (8.7.1/8.7.1) id MAA06489 for xemacs-beta@xemacs.org; Thu, 5 Sep 1996 12:02:18 +0200
Message-Id: <199609051002.MAA06489@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Thu, 5 Sep 1996 12:02:18 +0200
In-Reply-To: Richard Cognot <cognot@ensg.u-nancy.fr>
       "Re: RMS' message re XEmacs" (Sep  4, 20:27)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: xemacs-beta@xemacs.org
Subject: Re: RMS' message re XEmacs

On Sep 4, 20:27, Richard Cognot wrote:
>>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:
>    John> Note that there have indeed been followups in g.m.d.  One of
>    John> them, from Erik Naggum, was quite harsh toward XEmacs...
>
>Why is it that I'm not surprised he jumped in on this discussion...

That guy [EN] is able to poison any serious discussions about (X)Emacs, 
the only way to deal with him is to put him firmly into all your killfiles.
Unfortunately he can stir things up so much that a whole newsgroup can
be made unreadable.  Too bad, wonder what bad accident made him like that.

Tor

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 05:09:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA20299 for xemacs-beta-people; Thu, 5 Sep 1996 05:09:36 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA20296 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 05:09:35 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA11599 for <xemacs-beta@cs.uiuc.edu>; Thu, 5 Sep 1996 05:09:33 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Thu, 5 Sep 1996 12:09:20 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id MAA25855; Thu, 5 Sep 1996 12:09:13 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id MAA11334;
          Thu, 5 Sep 1996 12:06:48 +0200
Date: Thu, 5 Sep 1996 12:06:48 +0200
Message-Id: <199609051006.MAA11334@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
To: xemacs-beta@cs.uiuc.edu
Subject: Installation problems
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.80)
Content-Type: text/plain; charset=US-ASCII

During the installation of the xemacs 19.14 on a linux 2.0.20 system I
got the following error message:

  XEmacs: Can't mmap (/prog/xemacs-1/xemacs-19.14/src/xemacs):errno 12

It occurs during or after dumping the xemacs. Any ideas, what this
message want's to say?


Thanks,

Heiko

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 05:38:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA20667 for xemacs-beta-people; Thu, 5 Sep 1996 05:38:22 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA20664 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 05:38:21 -0500 (CDT)
Received: from jagor.srce.hr (root@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA04783; Thu, 5 Sep 1996 05:38:00 -0500 (CDT)
Received: from hniksic@localhost by jagor.srce.hr (8.7.5/8.6.12.CI)
	id KAA05198; Thu, 5 Sep 1996 10:07:21 +0200 (MET DST)
Sender: hniksic@public.srce.hr
To: Chuck Thompson <cthomp@xemacs.org>
Cc: Martin Buchholz <mrb@eng.sun.com>,
        XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: RMS' message re XEmacs
References: <199609041828.NAA03532@xemacs.cs.uiuc.edu>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/geturl/geturl.tar.gz
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 05 Sep 1996 10:07:20 +0200
In-Reply-To: Chuck Thompson's message of Wed, 04 Sep 1996 13:28:09 -0500
Message-ID: <kigraohtmfb.fsf@jagor.srce.hr>
Lines: 13
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Chuck Thompson (cthomp@xemacs.org) wrote:
> As a point of reference, this was in reply to a message I posted
> responding to some statements he made.

Could you please repost that message, since it seems to have expired
from my newsserver.

-- 
hniksic@srce.hr              |  Student of electrical engineering
hniksic@fly.cc.fer.hr        |  University of Zagreb, Croatia
------------------------------------------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 06:05:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA20729 for xemacs-beta-people; Thu, 5 Sep 1996 06:05:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA20726 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 06:05:19 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA17589 for <xemacs-beta@cs.uiuc.edu>; Thu, 5 Sep 1996 06:05:17 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Thu, 5 Sep 1996 13:04:55 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id NAA26328; Thu, 5 Sep 1996 13:04:48 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id NAA11377;
          Thu, 5 Sep 1996 13:02:21 +0200
Date: Thu, 5 Sep 1996 13:02:21 +0200
Message-Id: <199609051102.NAA11377@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Versions of Emacs
In-Reply-To: <9609042134.AA17888@cfdevx1.lehman.com>
References: <199609041817.LAA00170@xemacs.eng.sun.com> <9609042134.AA17888@cfdevx1.lehman.com>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.80)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:


    Rick> In fact, much of this is related to a part of RMS'
    Rick> philosophy which some advocates of Free Software reject.
    Rick> While I have written software that I have distributed under
    Rick> the GPL, I have also written software that I have
    Rick> distributed as Public Domain.  In general, I prefer the
    Rick> Public Domain model to the restrictions of the GPL.

I think, that you should read the recital from RMS, which he had held
(read) at KTH (Sweden) at the 30. October 1986. You can find it on
	http://www.ime.usp.br/~anr/misc/stallman-forelesning.html

In this recital he told something about the beginning of GNU and the
GPL and it makes clear, that it is absolutly necessary to put software
under something like the GPL, if one wants to make sure, that everyone
can use the software. He came to this conclusion, because he had made
realy bad experiences with a company, which has stolen his work on a
first version of an emacs. This was possible, because there was no
copyright assigned to his software and so the company was able to put
it's own copyright on his software and require money for it's use.

It's another question, if the FSF must have the copyright or not, but
I'm sure that it's necessary to assign something like the GPL to realy
free software, to make sure, that it remains free in the future.

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 06:35:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA20845 for xemacs-beta-people; Thu, 5 Sep 1996 06:35:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA20842 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 06:35:07 -0500 (CDT)
Received: from icemark.thenet.ch (beh@[193.135.252.47]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA04900 for <xemacs-beta@xemacs.org>; Thu, 5 Sep 1996 06:35:00 -0500 (CDT)
Received: (from beh@localhost) by icemark.thenet.ch (8.6.12/8.6.12) id NAA03244; Thu, 5 Sep 1996 13:34:44 +0200
Date: Thu, 5 Sep 1996 13:34:43 +0200 (MET DST)
From: Benedikt Eric Heinen <beh@icemark.thenet.ch>
To: Richard Stallman <rms@gnu.ai.mit.edu>,
        XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: Versions of Emacs
In-Reply-To: <199609041817.LAA00170@xemacs.eng.sun.com>
Message-ID: <Pine.LNX.3.91.960905130616.1997D-100000@icemark.thenet.ch>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


[As this mail goes to RMS and XEmacs-beta, the points where I address 
'you' I mean RMS!]:


> People should have the freedom to decide what to work on, including
> the freedom to compete with the GNU project, but it's a shame when
> they make that choice.  The whole community loses when someone chooses
> competition rather than cooperation.

Oh, I don't think so, the GNU project competes with the commercial market
the same way, as XEmacs competes with the 'FSF Emacs'. gcc competes with
other compilers available, and the FSF can't get parts of the sources from
those compilers. But in XEmacs, due the lack of legal papers, you can't
just copy the source (until you get them) but you can get the idea of how
to build the same behaviour for yourself and Emacs. 

On the other hand, I don't think that competition is bad. The XEmacs
authors are really pressed hard to keep this a competition the same as you
are pressed to keep this a competition. If one of the two loses its
interest the competition will be sort of over, as soon as the other has
improved his version of Emacs a good deal over his ex-competitor. 

And this is exactly what makes the competition good, since competition is
nearly always good for the customer (or user in this case, as I wouldn't
describe myself a customer in case of free software). I don't think that
Emacs would have the same features and the same quality it has now, if it
weren't for the competition, no matter whether this competition is fair or
unfair. For me, the choice was to have both installed for a long time
(that is until XEmacs got tty support, since I have to use both). Since
then I only have XEmacs installed on my system, but I still think it's
good that for instance in Linux distributions, the FSF GNU Emacs is still
incorporated into the distributions so users can decide for themselves. 

I also understand, why you say competition is bad, and that is because you
are one of the authors, who's got to work to keep up the competition until
the other party gives up. For you, competition means loads of additional
work and I really honor that, even though I am along those people who do
not (presently) use FSF's GNU Emacs, since your work keeps Chuck Thompson,
Ben Wing, and the other authors of XEmacs on their toes. 

I really honor the authors of BOTH versions, and I am happily using the
one Emacs, that I deem better (and I will not necessarily stay loyal to
XEmacs if Emacs starts getting better as XEmacs). 

yours,
	Benedikt

signoff

---
 Benedikt Eric Heinen  -  Muehlemattstrasse 53  -  CH3007 Bern  -   SWITZERLAND
 email: beh@icemark.thenet.ch				 phone: ++41.31.3714460


RIOT, n.  A popular entertainment given to the military by innocent bystanders.

				     Ambrose Bierce  ``The Devil's Dictionary''


From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 09:15:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA21242 for xemacs-beta-people; Thu, 5 Sep 1996 09:15:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA21239 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 09:15:07 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA25460 for <xemacs-beta@cs.uiuc.edu>; Thu, 5 Sep 1996 09:15:07 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa07769;
          5 Sep 96 10:05 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id KAA21167; Thu, 5 Sep 1996 10:04:23 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id KAA23718; Thu, 5 Sep 1996 10:04:21 -0400
Date: Thu, 5 Sep 1996 10:04:21 -0400
Message-Id: <199609051404.KAA23718@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: Fixing a long-standing annoyance: backward-delete-char-untabify
References: <m2u3tdhdcz.fsf@deanna.miranova.com>
	<199609050326.UAA03954@xemacs.eng.sun.com>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Is there something missing
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "MB" == Martin Buchholz <mrb@eng.sun.com> writes:

    MB> Don't you want to use backward-delete-char instead of
    MB> backward-delete-char-untabify?

Yeah, because otherwise it wouldn't be backward-delete-char-***untabify***

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 11:08:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA21714 for xemacs-beta-people; Thu, 5 Sep 1996 11:08:31 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA21711 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 11:08:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA05399 for <xemacs-beta@xemacs.org>; Thu, 5 Sep 1996 11:08:27 -0500 (CDT)
Message-Id: <199609051608.LAA05399@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: message reposts coming
Date: Thu, 05 Sep 1996 11:08:26 -0500
From: Chuck Thompson <cthomp@xemacs.org>

Since multiple people asked, I'm going to send the two "political"
messages I posted in the last couple of weeks to the beta list.  I
haven't decided what, if anything, to say in response to RMS's new
message.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 11:10:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA21762 for xemacs-beta-people; Thu, 5 Sep 1996 11:10:20 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA21759 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 11:10:19 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA05409 for <xemacs-beta@xemacs.org>; Thu, 5 Sep 1996 11:10:17 -0500 (CDT)
Message-Id: <199609051610.LAA05409@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: message #2
Date: Thu, 05 Sep 1996 11:10:16 -0500
From: Chuck Thompson <cthomp@xemacs.org>

>From nobody Fri Aug 23 23:20:13 1996
Sender: cthomp@xemacs.cs.uiuc.edu
To: rms@gnu.ai.mit.edu
Cc: cthomp@xemacs.org
Newsgroups: gnu.misc.discuss,comp.emacs.xemacs
Followup-To: gnu.misc.discuss
Subject: Re: Emacs
References: <199608211633.MAA32536@psilocin.gnu.ai.mit.edu>
From: Chuck Thompson <cthomp@xemacs.org>
Date: 23 Aug 1996 23:20:09 -0500
Message-ID: <qjenkx8lc6.fsf@xemacs.cs.uiuc.edu>
Organization: XEmacs Advocacy Group
X-Newsreader: Gnus v5.2.25/XEmacs 19.14
In-Reply-To: rms@gnu.ai.mit.edu's message of Wed, 21 Aug 1996 12:33:19 -0400
Lines: 67
Xref: xemacs.cs.uiuc.edu misc-news:41
X-Gnus-Article-Number: 41   Fri Aug 23 23:20:13 1996

(moved from gnu.emacs.sources)

>>>>> "RMS" == Richard Stallman <rms@gnu.ai.mit.edu> writes:

    RMS> I'd like to ask people not to use the term "FSF Emacs".  That
    RMS> term was coined as a put-down by people who maintain a
    RMS> modified version of GNU Emacs, and who treat the official
    RMS> version as a rival.  If you don't share that feeling, please
    RMS> don't use words that express it.

    RMS> Distinguishing the two versions is certainly necessary.  I do
    RMS> it by writing GNU Emacs and GNU XEmacs, or, in contexts where
    RMS> there is no problem of confusion with other Emacs
    RMS> implementations (which is most of the time), just Emacs and
    RMS> XEmacs.


I would appreciate a retraction of your first statement.  To the very
best of my knowledge the phrase was definitely coined as a way of
distinguishing GNU Emacs from XEmacs.  Regardless of its origin, I
maintain XEmacs.  I did not coin the phrase "FSF Emacs".  I have never
used it as a put-down.  Out of respect for your wishes I have not used
that term (other than when discussing the term itself such as here) in
any posting I have made since I became aware of your objections to it.

By the same token I personally do not care for the phrase "GNU
XEmacs".  As has been pointed out by others, XEmacs is noticeably
missing from all lists of GNU software.  If you wish to use the phrase
"GNU XEmacs" then please include XEmacs in all such lists which you
control.  Otherwise, I would prefer you use just plain "XEmacs".

As for your comment about those "who treat the official version as a
rival" well I suppose there has been some truth to that.  However,
please see a recent posting I made to comp.emacs and comp.emacs.xemacs
about this very issue.

I am rather disturbed by this entire posting of yours.  It can be read
to imply that you resent the existence of XEmacs.  Even if I were to
endorse the view that XEmacs is a rival, what's wrong with GNU Emacs
having a rival?  The ironic thing here is that you are responsible for
XEmacs being able to exist in the first place.  Without the GPL and
its application to Emacs no one would ever have been able to create a
different version of GNU Emacs.  I see XEmacs as being an embodiment
of the Free Software movement.  "If a piece of software doesn't do
what you want, then here's the source code.  You're free to modify it
to do what you want it to".  That's both why XEmacs can exist and why
it does exist.

For future reference, there have been and are other XEmacs developers.
There are many others who are vocal advocates of XEmacs who are not
actually developers.  Sometimes I agree with what they say.  Sometimes
I do not.  Before you use all-inclusive phrases such as "people who
maintain" please be sure that you know who is actually in that group
and be sure that your statements are really applicable to everyone in
that group.  In particular be sure that it includes me.  This is not
the first time you have globally referred to the XEmacs maintainers
and not actually accurately stated my views.  I've put out every
release which has been made under the name XEmacs.  I'm as official as
it gets with XEmacs.



-- 
Chuck Thompson					     primary XEmacs maintainer
Research Programmer
Department of Computer Science
University of Illinois at Urbana-Champaign

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 11:29:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA21861 for xemacs-beta-people; Thu, 5 Sep 1996 11:29:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA21858 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 11:29:42 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA05479 for <xemacs-beta@xemacs.org>; Thu, 5 Sep 1996 11:29:37 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id MAA01857 for <xemacs-beta@xemacs.org>; Thu, 5 Sep 1996 12:29:36 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp001808; Thu Sep  5 12:29:20 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA23948; Thu, 5 Sep 96 12:29:17 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA20392; Thu, 5 Sep 96 12:29:16 EDT
Message-Id: <9609051629.AA20392@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Don't get frustrated without it.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: Versions of Emacs 
In-Reply-To: Heiko Muenkel's message of "Thu, 05 Sep 1996 11:57:57 +0200."
             <199609050957.LAA11330@daedalus.tnt.uni-hannover.de> 
Date: Thu, 05 Sep 1996 12:29:15 -0400
Sender: rickc@lehman.com

-----BEGIN PGP SIGNED MESSAGE-----

Thanks for the suggestion.  I've read a number things from RMS on this
topic and its probably the case that one or more of our one-on-one
mini-debates were on this subject.  If he remembers any of these, he's
more likely to remember me as `Rick Busdiecker' -- I've only been Rick
Campbell since April of this year.

While I understand the real and potential dangers, I believe that it
is possible to put things in the Public Domain without losing anything
that you yourself have done.  The main thing that you lose is the
potential to be able to force others to share what they do with your
code.  I understand why someone would want to do that and I don't
fault people for doing so, it's just that my preference is still for a
complete lack of restrictions on use.

A nice example is CMU Common Lisp.  At Richard Stallman's urging (*)
Scott Fahlman decided early on that all of the code would be placed in
the public domain.  This helped get a lot of lisp implementations to
track the emerging standard in short order.  Early Lucid Common Lisp
was almost a complete rip-off of CMUCL, although at some point I
believe that they claimed that they had replaced all CMUCL code with
home-grown code.  In any case, the lack of restrictions helped to
foster commercial ventures which in turn helped the Lisp community as
a whole.

			Rick


(*) This is how Scott remembers it.  RMS may have a different
    recollection.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMi7XwFtTztlqB385AQEnLAP/ax4o/F37XsdtufrjKNsFgPUeTR3KELid
h5jKiE7dMMl38CF1o/6aZdgIcNUV82PYpvOlbummKqhzgI+w0mFP8wWrVN0HY1a0
MYMbUzaheomIuO9FN0bywvPTkguhca3GMceDeTc4VhFgUVQmEbj68dO+Q/U9ui6g
Vg0EQKgNJwU=
=PNMK
-----END PGP SIGNATURE-----

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 11:09:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA21738 for xemacs-beta-people; Thu, 5 Sep 1996 11:09:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA21731 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 11:09:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA05404 for <xemacs-beta@xemacs.org>; Thu, 5 Sep 1996 11:09:50 -0500 (CDT)
Message-Id: <199609051609.LAA05404@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: message #1
Date: Thu, 05 Sep 1996 11:09:49 -0500
From: Chuck Thompson <cthomp@xemacs.org>

>From nobody Sun Aug 18 09:21:24 1996
Sender: cthomp@xemacs.cs.uiuc.edu
Newsgroups: comp.emacs,comp.emacs.xemacs
Subject: that XEmacs / GNU Emacs debate (was Re: Xemacs features in GNUEmacs)
References: <redhouseDwAH8n.7Lp@netcom.com>
From: Chuck Thompson <cthomp@xemacs.org>
Date: 18 Aug 1996 09:21:21 -0500
Message-ID: <qjbug8ixi6.fsf@xemacs.cs.uiuc.edu>
Organization: XEmacs Advocacy Group
X-Newsreader: Gnus v5.2.25/XEmacs 19.14
Lines: 91
Xref: xemacs.cs.uiuc.edu misc-news:39
X-Gnus-Article-Number: 39   Sun Aug 18 09:21:24 1996

    Carter> So I compiled GNUEmacs 19.33.  It is much faster.
    Carter> Additionally, the various elisp packages people at work
    Carter> have written were developed for GNUEmacs and seem a little
    Carter> buggy when you run them on XEmacs.  In at least one case
    Carter> this is due to differences in REGEXP behaviour between the
    Carter> two.

This is not a completely fair comparison.  The last two releases of
GNU Emacs have been more towards stabilization than adding new
features.  The last XEmacs release was a new feature release pure and
simple.  XEmacs has a historical cycle of even numbered releases
having lots of new features and odd numbered releases only having bug
/ performance fixes.  19.12 had lots of new features and was slow.
19.13 fixed lots of bugs and was quite a bit faster.  19.14 adds lots
of new features and has slowed back down.  More on 19.15 in a minute.

Yes, packages originally written for GNU Emacs may initially not work
correctly on XEmacs.  The reverse is also very much true.  Sometimes
this may be due to a bug in XEmacs.  In other cases it has been caused
by GNU Emacs changing an interface.  Since there is always going to be
a delay between when such changes are made in GNU Emacs and when the
same or a similar change will show up in XEmacs, you are going to have
a period where the latest version of the package doesn't work
correctly in XEmacs.  To be fair, the reverse situation happens as
well.

The next XEmacs release, 19.15, will be faster than 19.14.  Will it be
as fast as GNU Emacs?  For some people, certainly.  For all people?
Doubtful.  It will assuredly require more memory than GNU Emacs if you
use all of its features.  Many of the major features that XEmacs
provides revolve around its display engine: better display of text and
the ability to display graphics.  The process needed to do this is an
order of magnitude more complex than that needed by the GNU Emacs
display engine.  Also, graphics eat more memory.

That doesn't mean that XEmacs can't improve its performance and reduce
its memory usage.  It can and has.  For example, the redisplay engine
actually uses 1/3 less memory in 19.14 than it does in 19.13.  Most
people don't see this fact because the extra graphics display
abilities in 19.14 more than make up the difference.  We're working on
it :-)


* SOAPBOX ON *

I think XEmacs is "better" than GNU Emacs.  If I didn't, there would
be little point in my continuing to work on it.  This doesn't mean
that I expect everyone to feel this way.  Both XEmacs and GNU Emacs
have their own sets of strengths and weaknesses.  Which editor any
given user prefers depends on how they weigh those strengths and
weaknesses.  It also depends on which version they are currently
comparing for both editors are under continued development.  Both
constantly incorporate features that were added to the other months
(and years) earlier.  Both constantly add new features not previously
present in either.

Having a single Emacs would make things less confusing for users.  I
don't believe it is going to happen, though.  The philosophical
differences between the two development camps are too great.  I do not
want to start any debates or flame wars on this topic.  There is no
"right" side or "wrong" side here.  There is just a difference of
opinions.

Unlike some, I believe that the split has actually been good for Emacs
as a whole.  A little competition, real or imagined, can be a good
motivator and I believe it has definitely motivated some (X)Emacs
features along faster than they would have otherwise.  There has
actually been surprisingly little overlap in the areas where GNU Emacs
and XEmacs have added the most new functionality.  My conclusion is
that the split has led to more combined overall functionality than
would exist at this point if the split had never occurred.

So, please, evaluate GNU Emacs and XEmacs and choose the one you like
best.  Occasionally re-evaluate your choice.  Remember that what is
currently a true comparison was possibly not in the past and may not
be again in the future.  When I say this I am talking about both
directions.  I could list comparisons that are currently favorable and
unfavorable to XEmacs where just the reverse used to be true.

Neither GNU Emacs nor XEmacs is going to disappear anytime soon,
though one or the other may have more users.  More people drink Coke
than Pepsi but neither one is hurting for customers.

* SOAPBOX OFF *


-- 
Chuck Thompson					     primary XEmacs maintainer
Research Programmer
Department of Computer Science
University of Illinois at Urbana-Champaign

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 21:25:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA23923 for xemacs-beta-people; Thu, 5 Sep 1996 21:25:21 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA23920 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 21:25:20 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA18171 for <xemacs-beta@cs.uiuc.edu>; Thu, 5 Sep 1996 21:25:20 -0500 (CDT)
Received: from sbkifer.cs.sunysb.edu (sbkifer.cs.sunysb.edu [130.245.1.35]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id WAA24076 for <xemacs-beta@cs.uiuc.edu>; Thu, 5 Sep 1996 22:30:51 -0400
Message-Id: <199609060230.WAA24076@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: xemacs-beta@cs.uiuc.edu
Subject: convert-standard-filename
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 05 Sep 1996 22:23:23 -0400
Sender: kifer@cs.sunysb.edu

any plans to add this function from e19.34 to 19.15?



	--michael  

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 21:49:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA23990 for xemacs-beta-people; Thu, 5 Sep 1996 21:49:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA23987 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 21:49:50 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA18496 for <xemacs-beta@cs.uiuc.edu>; Thu, 5 Sep 1996 21:49:50 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id TAA28152; Thu, 5 Sep 1996 19:49:19 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id TAA25391; Thu, 5 Sep 1996 19:49:16 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id TAA15905; Thu, 5 Sep 1996 19:49:13 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id TAA06426; Thu, 5 Sep 1996 19:49:12 -0700
Date: Thu, 5 Sep 1996 19:49:12 -0700
Message-Id: <199609060249.TAA06426@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: kifer@cs.sunysb.edu (Michael Kifer)
Cc: xemacs-beta@cs.uiuc.edu
Subject: convert-standard-filename
In-Reply-To: <199609060230.WAA24076@cs.sunysb.edu>
References: <199609060230.WAA24076@cs.sunysb.edu>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Michael" == Michael Kifer <kifer@cs.sunysb.edu> writes:

Michael> any plans to add this function from e19.34 to 19.15?

It will be in 20.0 beta 28.

Only the trivial (identity) version, as XEmacs hasn't been ported to
systems that need a non-trivial one (yet).  But this will be available
for package writers interested in portability.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Sep  5 22:07:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA24043 for xemacs-beta-people; Thu, 5 Sep 1996 22:07:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA24040 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 5 Sep 1996 22:07:36 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA06707 for <xemacs-beta@xemacs.org>; Thu, 5 Sep 1996 22:07:33 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id UAA00918; Thu, 5 Sep 1996 20:07:04 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA27604; Thu, 5 Sep 1996 20:07:02 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA16107; Thu, 5 Sep 1996 20:07:00 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA06719; Thu, 5 Sep 1996 20:06:59 -0700
Date: Thu, 5 Sep 1996 20:06:59 -0700
Message-Id: <199609060306.UAA06719@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: kifer@cs.sunysb.edu (Michael Kifer)
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: convert-standard-filename 
In-Reply-To: <199609060301.XAA24190@cs.sunysb.edu>
References: <199609060249.TAA06426@xemacs.eng.sun.com>
	<199609060301.XAA24190@cs.sunysb.edu>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Michael" == Michael Kifer <kifer@CS.SunySB.EDU> writes:

Michael> I suppose it will be added to 19.15 as well, right?
Michael> Also, I think expand-filename should call convert-standard-filename, so
Michael> that when XEmacs is ported to those other systems then expand-file-name
Michael> would always return a meaningful name for the OS at hand. What do you
Michael> think?

Chuck usually syncs 19.15 with 20.0.

Perhaps you would like to supply patches for
convert-standard-filename?  If you do, please send them directly to
Chuck.

There's lots of sync'ing with emacs-19.34 that would be really useful.
Ben used to do that work, but he's busy these days.  Volunteers?

Martin

From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 00:04:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA24314 for xemacs-beta-people; Fri, 6 Sep 1996 00:04:31 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA24311 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 00:04:30 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA21910 for <xemacs-beta@cs.uiuc.edu>; Fri, 6 Sep 1996 00:04:29 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id WAA10649; Thu, 5 Sep 1996 22:01:43 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Installation problems
References: <199609051006.MAA11334@daedalus.tnt.uni-hannover.de>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Heiko Muenkel's message of Thu, 5 Sep 1996 12:06:48 +0200
Message-ID: <m2u3tctf4q.fsf@deanna.miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.82)
Content-Type: text/plain; charset=US-ASCII
Date: 05 Sep 1996 22:01:41 -0700
Lines: 19
X-Mailer: Red Gnus v0.27/XEmacs 19.14

>>>>> "Heiko" == Heiko Muenkel <muenkel@tnt.uni-hannover.de> writes:

Heiko> During the installation of the xemacs 19.14 on a linux 2.0.20
Heiko> system I got the following error message:

(AFAIK the latest version is 2.0.18, typo?)

Heiko>   XEmacs: Can't mmap (/prog/xemacs-1/xemacs-19.14/src/xemacs):errno 12

Heiko> It occurs during or after dumping the xemacs. Any ideas, what this
Heiko> message want's to say?

mmap is used by malloc on Linux, were you running out of swap by any
chance?
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 04:13:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA28348 for xemacs-beta-people; Fri, 6 Sep 1996 04:13:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA28345 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 04:13:55 -0500 (CDT)
Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA07136 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 04:13:50 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id CAA21253 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 02:13:51 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id CAA17676 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 02:13:34 -0700
Date: Fri, 6 Sep 1996 02:13:34 -0700
Message-Id: <199609060913.CAA17676@shellx.best.com>
From: Ben Wing <wing@666.com>
To: Chuck Thompson <cthomp@xemacs.org>, Martin Buchholz <mrb@eng.sun.com>
Subject: Re:  Need help with X window position detection code
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>

>	(Solaris Openwin + CDE)
>	If you resize a frame, XEmacs gets a ConfigureNotify like this,
>	
>	event->xconfigure = {
>	    type              = 22
>	    serial            = 2720U
>	    send_event        = 0
>	    display           = 0x488000
>	    event             = 113246255U
>	    window            = 113246255U
>	    x                 = 0
>	    y                 = 0
>	    width             = 386
>	    height            = 352
>	    border_width      = 0
>	    above             = 0
>	    override_redirect = 0
>	}
>	
>	while if you move it, it gets instead:
>	
>	event->xconfigure = {
>	    type              = 22
>	    serial            = 2214U
>	    send_event        = 1
>	    display           = 0x488000
>	    event             = 113246255U
>	    window            = 113246255U
>	    x                 = 499
>	    y                 = 106
>	    width             = 596
>	    height            = 625
>	    border_width      = 0
>	    above             = 0
>	    override_redirect = 0
>	}
>	
>	Notice that one of these events has x = y = 0, while the other one has
>	the true absolute positions of the frame.
>	
>	Since there is code in event-Xt.c to save the x and y values from the
>	event in shell->core.x and core.y, it is clear how this can lead to
>	anomalous behavior.

You're seeing typical reparenting window manager crap.  The frame's top-level
window is enclosed in the window manager's window, and so its x and y
values are 0 (or something like that; I think they should be small
positive integers).  Meanwhile, the same reparenting bogosity means that
moving the window doesn't cause any real events to get sent (you moved
the parent, not the window itself), so a fake ICCCM-mandated event is sent.
I thought that resizing was supposed to cause the fake event to be sent,
too.

>	In particular, (set-frame-properties (selected-frame) '(left 100)) has
>	different effects after manually moving the frame than after resizing
>	it.
>	
>	Then there is this function in x-frame.c:
>	
>	static void
>	x_smash_bastardly_shell_position (Widget shell)
>	{
>	  /* Naturally those bastards who wrote Xt couldn't be bothered
>	     to learn about race conditions and such.  We can't trust
>	     the X and Y values to have any semblance of correctness,
>	     so we smash the right values in place. */
>	 
>	 /* We might be called before we've actually realized the window (if
>	     we're checking for the minibuffer resource).  This will bomb in
>	     that case so we don't bother calling it. */
>	  if (XtWindow (shell))
>	    x_get_top_level_position (XtDisplay (shell), XtWindow (shell),
>				      &shell->core.x, &shell->core.y);
>	}
>	
>	
>	Perhaps we should call x_smash_bastardly_shell_position whenever we
>	get a ConfigureNotify event rather than trusting the values in the
>	event.  This is my current plan to fix this bug.

Good idea.  Just remember that X Windows was actually a top-secret
Microsoft project whose aim was to kill Unix.

ben

From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 10:09:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA29189 for xemacs-beta-people; Fri, 6 Sep 1996 10:09:05 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA29185 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 10:09:03 -0500 (CDT)
Received: from maes.esrin.esa.it (maes.esrin.esa.it [192.106.252.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA25307; Fri, 6 Sep 1996 10:09:01 -0500 (CDT)
Received: from mail.esrin.esa.it (plod.esrin.esa.it) by maes.esrin.esa.it with SMTP id AA23484
  (5.65c/IDA-1.4.4); Fri, 6 Sep 1996 17:09:33 +0200
Received: from penelope.esa.it by mail.esrin.esa.it (4.1/SMI-4.1)
	id AA00580; Fri, 6 Sep 96 15:12:09 GMT
Date: Fri, 6 Sep 96 15:12:09 GMT
Message-Id: <9609061512.AA00580@mail.esrin.esa.it>
Received: by penelope.esa.it (4.1/SMI-4.1)
	id AA07148; Fri, 6 Sep 96 17:12:16 +0200
From: Simon Marshall <simonm@penelope.esrin.esa.it>
To: XEmacs Bugs <xemacs@cs.uiuc.edu>
Cc: XEmacs Beta <xemacs-beta@cs.uiuc.edu>
Subject: [19.14]: XEmacs coredumps when W3 visits http://www.microsoft.com/

In XEmacs 19.14 [Lucid] (sparc-sun-sunos4.1.3C) of Thu Jul  4 1996 on penelope

A colleague just showed me that all the Solaris 1 and 2 netscapes and
xmosaics that we have coredump when visiting www.microsoft.com.  With
premature regret I fired up an XEmacs, expecting at most a political or
religious Lisp error signaled, but I was not to be disappointed...

I am proud to confirm that XEmacs also coredumps with this URL:

 (gdb) where
 #0  0xef55eeec in dbytecp ()
 #1  0xe72ac in get_internet_address (host=808445204, address=0xefffd338, 
     errb=ERROR_ME) at process.c:1311
 #2  0xe75c4 in Fopen_network_stream_internal (name=810408000, 
     buffer=809204424, host=808445204, service=80) at process.c:1392
 ...

And the relevant bit of code:

 memcpy (&address->sin_addr, host_info_ptr->h_addr, host_info_ptr->h_length);

Yes, indeed, it is a sinful address, and ye shall not enter into it...

But, on the slightly more serious side, XEmacs shouldn't really coredump,
even when visiting The Devil's Domain.

Simon.

From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 10:46:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA29277 for xemacs-beta-people; Fri, 6 Sep 1996 10:46:56 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA29272 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 10:46:54 -0500 (CDT)
Received: from loiosh.kei.com (ckd@loiosh.kei.com [192.88.144.32]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA29760; Fri, 6 Sep 1996 10:46:54 -0500 (CDT)
Received: (from ckd@localhost) by loiosh.kei.com (8.7.5/8.7.3) id LAA29182; Fri, 6 Sep 1996 11:44:58 -0400 (EDT)
Date: Fri, 6 Sep 1996 11:44:58 -0400 (EDT)
Message-Id: <199609061544.LAA29182@loiosh.kei.com>
From: Christopher Davis <ckd@loiosh.kei.com>
To: Simon Marshall <simonm@penelope.esrin.esa.it>
Cc: XEmacs Bugs <xemacs@cs.uiuc.edu>, XEmacs Beta <xemacs-beta@cs.uiuc.edu>
Subject: Re: [19.14]: XEmacs coredumps when W3 visits http://www.microsoft.com/
In-Reply-To: <9609061512.AA00580@mail.esrin.esa.it>
References: <9609061512.AA00580@mail.esrin.esa.it>
X-Attribution: ckd
Mime-Version: 1.0 (generated by tm-edit 7.71)
Content-Type: text/plain; charset=US-ASCII

SM> == Simon Marshall <simonm@penelope.esrin.esa.it>

 SM> In XEmacs 19.14 [Lucid] (sparc-sun-sunos4.1.3C) of Thu Jul 4 1996 on
                              ^^^^^^^^^^^^^^^^^^^^^
 SM> penelope A colleague just showed me that all the Solaris 1 and 2
 SM> netscapes and xmosaics that we have coredump when visiting
 SM> www.microsoft.com.  With premature regret I fired up an XEmacs,
 SM> expecting at most a political or religious Lisp error signaled, but I
 SM> was not to be disappointed...

Guess what?  It's not XEmacs that has the bug.  It's SunOS.

Fixed in a jumbo libc patch, or install BIND 4.9.4-P1 which is a better
idea anyway.

From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 11:13:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA29379 for xemacs-beta-people; Fri, 6 Sep 1996 11:13:19 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA29376 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 11:13:14 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA02400 for <xemacs-beta@cs.uiuc.edu>; Fri, 6 Sep 1996 11:13:12 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id JAA25382; Fri, 6 Sep 1996 09:12:28 -0700
Received: from sunesc.East.Sun.COM by East.Sun.COM (5.x/SMI-5.3)
	id AA11871; Fri, 6 Sep 1996 12:12:07 -0400
Received: from tweety.East.Sun.COM by sunesc.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id MAA20764; Fri, 6 Sep 1996 12:12:08 -0400
Received: by tweety.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id MAA05659; Fri, 6 Sep 1996 12:11:54 -0400
Date: Fri, 6 Sep 1996 12:11:54 -0400
From: janice@tweety.East.Sun.COM (Janice Armstrong)
Message-Id: <199609061611.MAA05659@tweety.East.Sun.COM>
To: xemacs-beta@cs.uiuc.edu
Subject: can someone tell me where the ispell program is?
X-Sun-Charset: US-ASCII

Hi all,

    I am having trouble finding the ispell program with Xemacs 
19.13 on Solaris 2.5.  I saw several bugs relating to this.  It 
seemed to be a configuration problem.  Here are the ispell related 
files on my system:

/opt/SUNWspro/XEmacs-19.13/editor/info/ispell.info f none 0666 bin sys 0 0 805585940 SPROmrxmc
/opt/SUNWspro/XEmacs-19.13/editor/lisp/packages/ispell.el f none 0664 bin sys 91853 59134 808448717 SPROxemcs
/opt/SUNWspro/XEmacs-19.13/editor/lisp/packages/ispell.elc f none 0666 bin sys 41939 9200 808708283 SPROxemcs
/opt/SUNWspro/XEmacs-19.13/editor/man/ispell.texi f none 0664 bin sys 14413 53028 805582215 SPROmrxmc

Am I missing something?  Thanks in advance for any help with this.

-- Jan

From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 16:30:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA00896 for xemacs-beta-people; Fri, 6 Sep 1996 16:30:04 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA00889 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 16:29:50 -0500 (CDT)
Received: from psilocin.gnu.ai.mit.edu (rms@psilocin.gnu.ai.mit.edu [128.52.46.62]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA08377 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 16:29:47 -0500 (CDT)
Received: by psilocin.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id RAA24259; Fri, 6 Sep 1996 17:29:35 -0400
Date: Fri, 6 Sep 1996 17:29:35 -0400
Message-Id: <199609062129.RAA24259@psilocin.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: beh@icemark.thenet.ch, xemacs-beta@xemacs.org
cc: rms@gnu.ai.mit.edu
In-reply-to: <Pine.LNX.3.91.960905130616.1997D-100000@icemark.thenet.ch>
	(message from Benedikt Eric Heinen on Thu, 5 Sep 1996 13:34:43 +0200
	(MET DST))
Subject: Re: Versions of Emacs
Reply-to: rms@gnu.ai.mit.edu

Competition in making sandwiches, or digging ditches, makes people
work harder without wasting their effort.  Arguing by analogy that
competition is good for software development is development is missing
a crucial difference.

Competition in development of knowledge can lead to more total output,
but it does so at the cost of duplication of effort.  It may yield 1.3
times as much output with twice the work.  If you measure only the
output, that might look like an improvement.  But when I consider what
else we could have done with twice the work, the competition seems
like a gratuitous waste.

Still, if the competition between Emacs and XEmacs were fair, it would
not be such a big problem.  With nothing to disagree about except
technical matters, there would be no reason for rancour when we
disagree.  If we could exchange code back and forth, a feeling of
cooperation could spring up between us, even if we continued competing
in other ways.  This would also diminish the wasteful duplication of
effort (though some would remain, and this would not be as good as
full cooperation).

If both versions had the same clear legal status, each improvement in
either version would be an advance for the free software community as
a whole.  It would be rational for users to choose between the two
versions on technical grounds alone.  And if one version or the other
were eventually abandoned, that would be no tragedy for the community.

It is the situation with legal papers that makes the competition
unfair.  It also means that if XEmacs becomes more popular, that is a
setback for the free software community.  If XEmacs were to eclipse
Emacs, while continuing to have an unclear legal status, that would be
a great setback for the free software community.

That's why I ask people who care about the free software community to
help make Emacs good enough that XEmacs will fade away, or help change
the situation with XEmacs and legal papers, or some combination of the
two that gets the job done.


From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 19:29:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA01419 for xemacs-beta-people; Fri, 6 Sep 1996 19:29:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA01416 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 19:29:57 -0500 (CDT)
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA08607 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 19:29:53 -0500 (CDT)
Received: from harding.sde.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA072576194; Fri, 6 Sep 1996 17:29:55 -0700
Received: from harding (localhost) by harding.sde.hp.com with SMTP
	(1.39.111.2/16.2) id AA036186209; Fri, 6 Sep 1996 18:30:09 -0600
Sender: harding@sde.hp.com
Message-Id: <3230C210.2DC0@sde.hp.com>
Date: Fri, 06 Sep 1996 18:30:08 -0600
From: Laura Harding <harding@sde.hp.com>
Organization: Hewlett-Packard Company
X-Mailer: Mozilla 3.0b7Gold (X11; I; HP-UX B.10.10 9000/712)
Mime-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: Trying to compile...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Frustrations never end.  Can someone help? 

Platform:  HP712 running HPUX 10.10
Problem:   No Xmu files installed on this system

I had understood that these were pertinant only to the SUN platform, and
thus I should not need them for a standard HP compilation.  Here is the
results of configure:

Configured for `hppa1.1-hp-hpux'.

  Where should the build process find the source code?   
/users/harding/xemacs-20.0-b27
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/hpux10.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?               
/usr/include/X11R5/X11
  Where do we find X Windows libraries?                   /usr/lib/X11R5
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


Help!  Please............
laura


****************************************************
Warning:  Do not look into laser with remaining eye.
Laura Harding               Software Design Engineer
SESD, Hewlett Packard       Fort Collins, Colorado
(970) 229-7873              harding@sde.hp.com

From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 19:27:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA01398 for xemacs-beta-people; Fri, 6 Sep 1996 19:27:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA01395 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 19:27:07 -0500 (CDT)
Received: from icemark.thenet.ch (beh@icemark.TheNet.CH [193.135.252.47]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA08598 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 19:27:01 -0500 (CDT)
Received: (from beh@localhost) by icemark.thenet.ch (8.6.12/8.6.12) id CAA01803; Sat, 7 Sep 1996 02:26:35 +0200
Date: Sat, 7 Sep 1996 02:26:35 +0200 (MET DST)
From: Benedikt Eric Heinen <beh@icemark.thenet.ch>
To: Richard Stallman <rms@gnu.ai.mit.edu>
cc: xemacs-beta@xemacs.org
Subject: Re: Versions of Emacs
In-Reply-To: <199609062129.RAA24259@psilocin.gnu.ai.mit.edu>
Message-ID: <Pine.LNX.3.91.960907015638.208B-100000@icemark.thenet.ch>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> Competition in development of knowledge can lead to more total output,
> but it does so at the cost of duplication of effort.  It may yield 1.3
> times as much output with twice the work.  If you measure only the
> output, that might look like an improvement.  But when I consider what
> else we could have done with twice the work, the competition seems
> like a gratuitous waste.
But this duplication has (at the cost of less spare time of both the teams 
authors') the advantage, that the one 'cloning' the first feature is 
really eager to do it better. The 'advantages' that XEmacs has over 
Emacs, will probably cause you not just to 100% copy the behaviour, but 
also to (very much obcious to the user) improve the feature. If you could 
just copy the feature from the XEmacs, you'd probably incorporate without 
trying to improve it. Also competition IMHO *adds* to the motivation of 
work, as you want YOUR package to be better than the others in the same 
field. 
  As written before, *I* think XEmacs is better, but still Emacs is the 
clear number two, before any other Editor I know up to now. Hey - number 
two isn't the best there is, but it's still a very good ranking (I mean, 
how much competing editors are there?)


> Still, if the competition between Emacs and XEmacs were fair, it would
> not be such a big problem.  With nothing to disagree about except
[...]
> in other ways.  This would also diminish the wasteful duplication of
> effort (though some would remain, and this would not be as good as
> full cooperation).
And it would probably also lead to the end of the competition and to a 
further 'slowed-down growth' within the resulting Emacs, 


> [...]  If XEmacs were to eclipse Emacs, while continuing to have an 
> unclear legal status, that would be a great setback for the free 
> software community.
That would only be a setback for the free software community, if XEmacs 
would not be free to use for anyone. It might be possible with that 
unclear legal situation that you can't just reuse the code in XEmacs, but 
at least, you've got access to the source and may freely rip it for 
ideas, but at the cost of code duplication.



just another $0.02 of mine,

	Benedikt

signoff

---
 Benedikt Eric Heinen  -  Muehlemattstrasse 53  -  CH3007 Bern  -   SWITZERLAND
 email: beh@icemark.thenet.ch				 phone: ++41.31.3714460


RIOT, n.  A popular entertainment given to the military by innocent bystanders.

				     Ambrose Bierce  ``The Devil's Dictionary''



From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 22:09:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA01725 for xemacs-beta-people; Fri, 6 Sep 1996 22:09:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA01722 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 22:09:36 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA08774 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 22:09:34 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id UAA09328; Fri, 6 Sep 1996 20:09:05 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA16972; Fri, 6 Sep 1996 20:09:03 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA05009; Fri, 6 Sep 1996 20:09:00 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA09113; Fri, 6 Sep 1996 20:09:00 -0700
Date: Fri, 6 Sep 1996 20:09:00 -0700
Message-Id: <199609070309.UAA09113@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Ben Wing <wing@666.com>
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re:  Need help with X window position detection code
In-Reply-To: <199609060913.CAA17673@shellx.best.com>
References: <199609060913.CAA17673@shellx.best.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

Ben> You're seeing typical reparenting window manager crap.  The frame's top-level
Ben> window is enclosed in the window manager's window, and so its x and y
Ben> values are 0 (or something like that; I think they should be small
Ben> positive integers).  Meanwhile, the same reparenting bogosity means that
Ben> moving the window doesn't cause any real events to get sent (you moved
Ben> the parent, not the window itself), so a fake ICCCM-mandated event is sent.
Ben> I thought that resizing was supposed to cause the fake event to be sent,
Ben> too.

Thanks, Ben.

Hmmm, just learned about reparenting.  Here's the way dtwm works:

There are actually 2 X windows in the hierarchy between emacs' top-level
window and the root window:
One is slightly larger than the emacs window and holds the frame
decorations, etc...
One is exactly the same size and position as the emacs window.

As a result, the x,y positions of the top-level window are always 0,0.
XEmacs gets fake events on frame move, but not frame resize.  Perhaps
the wm's thinking is that the app DOES get a (real) event on resizes,
so the app can take appropriate action, and no fake event is necessary.
It's quite confusing though, since the fake event contains fake but
useful x,y info, while the real event contains `correct', but useless
x,y values.

>> Perhaps we should call x_smash_bastardly_shell_position whenever we
>> get a ConfigureNotify event rather than trusting the values in the
>> event.  This is my current plan to fix this bug.

Ben> Good idea.  Just remember that X Windows was actually a top-secret
Ben> Microsoft project whose aim was to kill Unix.

I already fixed it by ignoring any events with x==0,y==0.
But I'll probably change it to use x_smash_bastardly_shell_position
later, since that seems more robust.

Martin

From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 22:51:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA01826 for xemacs-beta-people; Fri, 6 Sep 1996 22:51:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA01823 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 22:51:26 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA08807 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 22:51:23 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id UAA13244; Fri, 6 Sep 1996 20:50:55 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA19447; Fri, 6 Sep 1996 20:50:53 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA05348; Fri, 6 Sep 1996 20:50:50 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA09167; Fri, 6 Sep 1996 20:50:50 -0700
Date: Fri, 6 Sep 1996 20:50:50 -0700
Message-Id: <199609070350.UAA09167@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Design Proposal: native-coding-system
Reply-To: Martin Buchholz <mrb@eng.sun.com>

XEmacs is a multi-lingual app, but it lives in a locale-centric
world.  On most operating systems, there is a ``natural'' coding
system that is used for most interactions between XEmacs and the
outside world:

- file contents
- file names
- comint process input and output
- selection text
- XIM conversion input
- etc...

Currently these are represented by different lisp variables with names
like process-input-coding-system and values like 'euc-japan.

On many systems these variables have identical values.  It seems to
make sense to add an extra level of logical indirection like this:

native-coding-system is a new symbol like the above,
And set-native-coding-system can be used to associate a coding system
with it.

The variables file-coding-system and friends can then have the simple
value 'native-coding-system (by default!  Full customizability
remains, of course).

It should then be possible to change language environments via one
call to (set-native-coding-system).

There might be a better name.  I rejected:
system-coding-system - Consistent somehow, but looks ridiculous.
locale-coding-system - Too dependent on one language localization
                       model.  Too much confusion with existing
                       `locale' concept in XEmacs.

native-coding-system can be initialized from the operating system
environment, typically via the environment variable LANG.

From xemacs-beta-request@cs.uiuc.edu  Fri Sep  6 23:14:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA01860 for xemacs-beta-people; Fri, 6 Sep 1996 23:14:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA01857 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 6 Sep 1996 23:14:54 -0500 (CDT)
Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA08847 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 23:14:51 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id UAA21911 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 20:59:27 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id UAA08364 for <xemacs-beta@xemacs.org>; Fri, 6 Sep 1996 20:59:20 -0700
Date: Fri, 6 Sep 1996 20:59:20 -0700
Message-Id: <199609070359.UAA08364@shellx.best.com>
From: Ben Wing <wing@666.com>
To: Martin Buchholz <mrb@eng.sun.com>
Subject: Re:  Need help with X window position detection code
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
References: <199609060913.CAA17673@shellx.best.com>

>	As a result, the x,y positions of the top-level window are always 0,0.
>	XEmacs gets fake events on frame move, but not frame resize.  Perhaps
>	the wm's thinking is that the app DOES get a (real) event on resizes,
>	so the app can take appropriate action, and no fake event is necessary.
>	It's quite confusing though, since the fake event contains fake but
>	useful x,y info, while the real event contains `correct', but useless
>	x,y values.

Window managers are notoriously bad at getting things right.  See the
comment I wrote about mwm and twm.

>	>> Perhaps we should call x_smash_bastardly_shell_position whenever we
>	>> get a ConfigureNotify event rather than trusting the values in the
>	>> event.  This is my current plan to fix this bug.
>	
>	Ben> Good idea.  Just remember that X Windows was actually a top-secret
>	Ben> Microsoft project whose aim was to kill Unix.
>	
>	I already fixed it by ignoring any events with x==0,y==0.

Definitely not a robust solution as the window might really be in the
upper-left corner ...

>	But I'll probably change it to use x_smash_bastardly_shell_position
>	later, since that seems more robust.

Right.

ben

From xemacs-beta-request@cs.uiuc.edu  Sat Sep  7 10:10:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA06376 for xemacs-beta-people; Sat, 7 Sep 1996 10:10:09 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA06373 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 7 Sep 1996 10:10:08 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA09239 for <xemacs-beta@xemacs.org>; Sat, 7 Sep 1996 10:10:04 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id LAA23870; Sat, 7 Sep 1996 11:05:09 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp023862; Sat Sep  7 11:05:00 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA02131; Sat, 7 Sep 96 11:04:59 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA06759; Sat, 7 Sep 96 11:04:57 EDT
Message-Id: <9609071504.AA06759@cfdevx1.lehman.com>
Reply-To: Rick Campbell <campbell@c2.net>
X-Windows: Even your dog won't like it.
Organization: Lehman Brothers Inc.
From: Rick Campbell <campbell@c2.net>
To: "Richard M. Stallman" <rms@gnu.ai.mit.edu>
Cc: Benedikt Eric Heinen <beh@icemark.thenet.ch>,
        XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: Versions of Emacs
In-Reply-To: Your message of "Fri, 06 Sep 1996 17:29:35 EDT."
             <199609062129.RAA24259@psilocin.gnu.ai.mit.edu>
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMjGO9hj0UvMeUesFAQFKDgQA0TDJS0kVj7xrqFuA6OndLvCaYzNF/ogk
	      qYpzWxuA0Xqdho/IkxKC0sSgsPr7PnFEjZM8YgV4JcE6cOZcQ9+SSLRLTjDoyBvC
	      a2j4qA5/UXGFQbyLRbZhQXFTwV9M2kEJ+e1uVpUJNTl+Zj7PafMPRgOVmqeR+63m
	      dwjz5j5sa0k=
	      =ktIj
Date: Sat, 07 Sep 1996 11:04:28 -0400
Sender: rickc@lehman.com

    Date: Fri, 6 Sep 1996 17:29:35 -0400
    From: Richard Stallman <rms@gnu.ai.mit.edu>

    Still, if the competition between Emacs and XEmacs were fair, it would
    not be such a big problem.

Personally, I find it rather curious that you and/or your legal
advisors have made up a rule for yourself and that you are now
complaining that others won't follow it.

If you believe that your rule creates a situation that is unfair for
you, then drop it.  At the very least, please stop making the
ridiculous suggestion that those who work on XEmacs are engaging in
unfair competition.  Any imbalance stems from your own policy
decisions, not from the thoughts and deeds of others.

XEmacs is free software.  Work on XEmacs is work that promotes free
software.

			Rick

p. s.  I also find it curious that you express so much concern about
       `legal papers' and yet appear to have very little apprehension
       about making libelous statements (See Chuck Thompson's recent
       message concerning XEmacs maintainers)

--
Rick Campbell <campbell@c2.net>	      ``One of the symptoms of an approaching
  http://www.c2.net/~campbell/		nervous breakdown is the belief that
					one's work is terribly important.''
							- Bertrand Russel

From xemacs-beta-request@cs.uiuc.edu  Sat Sep  7 10:35:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA06458 for xemacs-beta-people; Sat, 7 Sep 1996 10:35:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA06455 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 7 Sep 1996 10:35:22 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA09298 for <xemacs-beta@xemacs.org>; Sat, 7 Sep 1996 10:35:19 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.55 #1)
	id E0uzPPG-0007Jv-00; Sat, 7 Sep 1996 11:34:50 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: Laura Harding <harding@sde.hp.com>
Cc: xemacs-beta@xemacs.org
Subject: Trying to compile...
In-Reply-To: <3230C210.2DC0@sde.hp.com>
References: <3230C210.2DC0@sde.hp.com>
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.82)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0uzPPG-0007Jv-00@neal.ctd.comsat.com>
Date: Sat, 7 Sep 1996 11:34:51 -0400

Get the needed libXmu and other stuff from:

http://hpux.cae.wisc.edu/ Tue Jan  2 13:54:45 1996

From xemacs-beta-request@cs.uiuc.edu  Sat Sep  7 10:51:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA06526 for xemacs-beta-people; Sat, 7 Sep 1996 10:51:18 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA06521 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 7 Sep 1996 10:51:17 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA09316 for <xemacs-beta@xemacs.org>; Sat, 7 Sep 1996 10:51:13 -0500 (CDT)
Message-Id: <199609071551.KAA09316@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA046601412; Sat, 7 Sep 1996 16:50:12 +0100
Date: Sat, 7 Sep 1996 16:50:12 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: Laura Harding <harding@sde.hp.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: Trying to compile...
In-Reply-To: <3230C210.2DC0@sde.hp.com>
References: <3230C210.2DC0@sde.hp.com>
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.


>>>>> "Laura" == Laura Harding <harding@sde.hp.com> writes:

    Laura> Frustrations never end.  Can someone help?  Platform: HP712
    Laura> running HPUX 10.10 Problem: No Xmu files installed on this
    Laura> system

    Laura> I had understood that these were pertinant only to the SUN
    Laura> platform, and thus I should not need them for a standard HP
    Laura> compilation.  Here is the results of configure:

the simpliest thing to do is to install the Xmu stuff. It s available
in precompiled form from HP. Try http://hpux.cs.utah.edu/, where you
can find also a list of mirrors. These archives contains all of public
domain software officially ported to hpux.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Sat Sep  7 17:52:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA07617 for xemacs-beta-people; Sat, 7 Sep 1996 17:52:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA07614 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 7 Sep 1996 17:52:14 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA16587 for <xemacs-beta@xemacs.org>; Sat, 7 Sep 1996 17:52:10 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id PAA05183; Sat, 7 Sep 1996 15:51:39 -0700
Received: from etude2.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id PAA01625; Sat, 7 Sep 1996 15:51:36 -0700
Received: by etude2.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA20422; Sat, 7 Sep 1996 15:51:30 -0700
Sender: mrb@etude2.Sun.COM
Newsgroups: gnu.misc.discuss
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: Emacs and XEmacs
References: <3050997187251756@arcana.naggum.no>
	<w4ohjj1u7s.fsf@loiosh.kei.com> <3051100247773025@arcana.naggum.no>
From: Martin Buchholz <mrb@eng.sun.com>
Date: 07 Sep 1996 15:51:29 -0700
Message-ID: <ci5enkej5vy.fsf@eng.sun.com>
Organization: Sun Microsystems, Inc.
Lines: 37
X-Newsreader: Gnus v5.2.25/XEmacs 20.0
In-Reply-To: Erik Naggum's message of 07 Sep 1996 15:50:47 +0000
Posted-To: gnu.misc.discuss

The following message is a courtesy copy of an article
that has been posted as well.

I am one of the current active XEmacs developers.  Like many other
XEmacs developers, I wish we had one emacs that had the best features
of GNU Emacs and XEmacs.

XEmacs is generally nicer and more featureful. The user tends to have
more options.  The base code is nicer for (non-RMS) developers to work with.

But XEmacs has some performance problems.  It hasn't been ported to
non-Unix platforms, although such ports are welcome.

XEmacs has more bugs than GNU Emacs, partly because it tries to do
more, and partly because Emacs has had bug-fixing rather than feature
addition as a priority for a long time, and has had a long-time
devoted maintainer.  Much of the code in XEmacs was originally written
for GNU Emacs, and so breaks because of various incompatibilities.

Here at Sun, I am also the installer-maintainer of various GNU Emacs
versions (although I am not a GNU Emacs developer).

Longterm, I would like to see `Emacs' (that's a generic term) win, by
attracting more users.  The first time I ever used Emacs, the arrow
keys wouldn't work unless you played with your .emacs file.  I
couldn't believe it.  Perhaps that experience kept me from being an
Emacs user for 2 years.  Making things easier for novice users
eventually adds to the pool of developers.  Often even completely
useless, but `cool', things like XEmacs' 3-D modeline sways new users
to the Emacs camp.

Even if there are RMS-compatible legal papers for all of XEmacs, I
don't believe a `merge' will happen, because of technical and
personality differences.  The 2 flavors of Emacs will continue to take
code from the other, and one of the variants may eventually die out.
-- 
Martin Buchholz <mrb@eng.sun.com>
XEmacs Developer, Sunsoft Developer Products, Sun Microsystems Inc.
Voice: 415-786-5895  Fax: 415-786-9552
Snail Mail: MPK16-305, 2550 Garcia Avenue, Mountain View, CA 94043-1100

From xemacs-beta-request@cs.uiuc.edu  Sat Sep  7 18:27:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA07645 for xemacs-beta-people; Sat, 7 Sep 1996 18:27:01 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA07642 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 7 Sep 1996 18:27:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA16654; Sat, 7 Sep 1996 18:26:55 -0500 (CDT)
Message-Id: <199609072326.SAA16654@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
cc: s.kaplan@dstc.edu.au
Subject: XEmacs User Survey
Date: Sat, 07 Sep 1996 18:26:53 -0500
From: Chuck Thompson <cthomp@xemacs.org>

Thanks to everyone who volunteered two months ago to create this for
me.  Extra apologies to Simon for not getting this done two months ago
:-)  I decided I knew enough to do it myself after my adventure with
creating the new XEmacs bug tracking system.  A link to the front page
of the survey is now at:

	http://www.xemacs.org/beta/


I would appreciate it if everyone would take a look and give me some
feedback, either about bugs or suggestions for improvements.  I'll
give about a week for feedback and then this will move to the front
page of www.xemacs.org and I'll make a posting to all emacs related
newsgroups asking people to complete the survey.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Sep  7 20:10:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA07849 for xemacs-beta-people; Sat, 7 Sep 1996 20:10:11 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA07846 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 7 Sep 1996 20:10:10 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA16764; Sat, 7 Sep 1996 20:10:06 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id SAA14218; Sat, 7 Sep 1996 18:09:38 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id SAA06328; Sat, 7 Sep 1996 18:09:36 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA13490; Sat, 7 Sep 1996 18:09:35 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA09403; Sat, 7 Sep 1996 18:09:35 -0700
Date: Sat, 7 Sep 1996 18:09:35 -0700
Message-Id: <199609080109.SAA09403@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Chuck Thompson <cthomp@xemacs.org>,
        XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Performance bug?
Reply-To: Martin Buchholz <mrb@eng.sun.com>

Just noticed that the frame title is updated very frequently (every
call to redisplay?)

Caching the frame title string and checking whether it has changed
would be a reasonable optimization.  Most calls to update_frame_title()
do not change the displayed title.

Martin

From xemacs-beta-request@cs.uiuc.edu  Sat Sep  7 20:54:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA07924 for xemacs-beta-people; Sat, 7 Sep 1996 20:54:48 -0500 (CDT)
Received: from c.cs.uiuc.edu (c.cs.uiuc.edu [128.174.252.3]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA07921 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 7 Sep 1996 20:54:47 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by c.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA12503 for <xemacs-beta@cs.uiuc.edu>; Sat, 7 Sep 1996 20:54:45 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id SAA08095; Sat, 7 Sep 1996 18:58:07 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs User Survey
References: <199609072326.SAA16654@xemacs.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Sat, 07 Sep 1996 18:26:53 -0500
Mime-Version: 1.0 (generated by tm-edit 7.82)
Content-Type: text/plain; charset=US-ASCII
Date: 07 Sep 1996 18:58:06 -0700
Message-ID: <m2wwy5kbtd.fsf@deanna.miranova.com>
Lines: 30
X-Mailer: Red Gnus v0.28/XEmacs 19.14

>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

Chuck> 	http://www.xemacs.org/beta/

Chuck> I would appreciate it if everyone would take a look and give me some
Chuck> feedback, either about bugs or suggestions for improvements.

(I like the beta arrival schedule, even if 19.15beta1 is pushed back
another 10 days ... )

The survey appears to work, but what exactly are you looking for?

Other possible questions (with some overlap):
What packages do you use? (Gnus, VM, W3, etc.)
What packages do you like?
What packages do you not like?

(The latter two could provide a basis for the 19.16 package unbundling)

What are your favorite features?  (textual response)
What are your least favorite features?  (textual response)

How many hours per day do you use the editor?
Do you like to use the editor?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Sat Sep  7 21:16:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA07942 for xemacs-beta-people; Sat, 7 Sep 1996 21:16:31 -0500 (CDT)
Received: from c.cs.uiuc.edu (c.cs.uiuc.edu [128.174.252.3]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA07939 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 7 Sep 1996 21:16:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by c.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA12593 for <xemacs-beta@cs.uiuc.edu>; Sat, 7 Sep 1996 21:16:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA16887; Sat, 7 Sep 1996 21:16:13 -0500 (CDT)
Message-Id: <199609080216.VAA16887@xemacs.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs User Survey 
In-reply-to: Your message of "07 Sep 1996 18:58:06 PDT."
             <m2wwy5kbtd.fsf@deanna.miranova.com> 
Date: Sat, 07 Sep 1996 21:16:10 -0500
From: Chuck Thompson <cthomp@xemacs.org>

    Steven> (I like the beta arrival schedule, even if 19.15beta1 is
    Steven> pushed back another 10 days ... )

Ooops.  Its not.  That was a typo on my part.  It will come out
tomorrow, September 8.


    Steven> The survey appears to work, but what exactly are you
    Steven> looking for?

I want to know who uses it and where.  Your additional questions are
good ones which I'm considering doing on another survey later but I
don't want that kind of detail on this one.  It is already a little
longer than I would like.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Sep  7 22:14:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA08050 for xemacs-beta-people; Sat, 7 Sep 1996 22:14:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA08047 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 7 Sep 1996 22:14:11 -0500 (CDT)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA17006; Sat, 7 Sep 1996 22:14:08 -0500 (CDT)
Received: from xdiv.lanl.gov (xdiv.lanl.gov [128.165.116.106]) by mailhost.lanl.gov (8.7.5/8.7.3) with ESMTP id VAA15781; Sat, 7 Sep 1996 21:14:09 -0600 (MDT)
Received: from branagh.lanl.gov (branagh.lanl.gov [128.165.16.72]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id VAA18850; Sat, 7 Sep 1996 21:14:08 -0600
Received: by branagh.lanl.gov (SMI-8.6/SMI-SVR4)
	id VAA02354; Sat, 7 Sep 1996 21:12:37 -0600
Date: Sat, 7 Sep 1996 21:12:37 -0600
Message-Id: <199609080312.VAA02354@branagh.lanl.gov>
From: John Turner <turner@xdiv.lanl.gov>
To: cthomp@xemacs.org
Cc: xemacs-beta@xemacs.org, s.kaplan@dstc.edu.au
Subject: Re: XEmacs User Survey
In-Reply-To: <199609072326.SAA16654@xemacs.cs.uiuc.edu>
References: <199609072326.SAA16654@xemacs.cs.uiuc.edu>
Reply-To: turner@lanl.gov

Looks good.

I like Steven's additional questions.

Might be interesting to find out how many people use both XEmacs and
FSF's GNU Emacs (or whatever the politically-correct term for "the
editor formerly known as FSF Emacs" is) as well...

+-----------------------+--------------------------------------------------+
|John A. Turner         |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab.  |  sound is that cup, but empty;                   |
|e-mail: turner@lanl.gov|    noise is that cup, but broken."               |
|                       |                        - Robert Fripp            |
+-----------------------+--------------------------------------------------+

From xemacs-beta-request@cs.uiuc.edu  Sun Sep  8 06:19:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA12217 for xemacs-beta-people; Sun, 8 Sep 1996 06:19:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA12214 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 8 Sep 1996 06:19:07 -0500 (CDT)
Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA17386 for <xemacs-beta@xemacs.org>; Sun, 8 Sep 1996 06:19:04 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id EAA20863 for <xemacs-beta@xemacs.org>; Sun, 8 Sep 1996 04:19:05 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id EAA04926 for <xemacs-beta@xemacs.org>; Sun, 8 Sep 1996 04:18:48 -0700
Date: Sun, 8 Sep 1996 04:18:48 -0700
Message-Id: <199609081118.EAA04926@shellx.best.com>
From: Ben Wing <wing@666.com>
To: xemacs-beta@xemacs.org, beh@icemark.thenet.ch, rms@gnu.ai.mit.edu
Subject: Re: Versions of Emacs
Cc: rms@gnu.ai.mit.edu

>It is the situation with legal papers that makes the competition
>unfair.  It also means that if XEmacs becomes more popular, that is a
>setback for the free software community.  If XEmacs were to eclipse
>Emacs, while continuing to have an unclear legal status, that would be
>a great setback for the free software community.

This is a completely disingenuous position to take!  Linux, for example,
is distributed with *exactly identical* legal terms to XEmacs.  Are
you willing to claim that Linux is detrimental to the free software
community?

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Sep  8 06:28:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA12233 for xemacs-beta-people; Sun, 8 Sep 1996 06:28:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA12230 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 8 Sep 1996 06:28:43 -0500 (CDT)
Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA17395 for <xemacs-beta@xemacs.org>; Sun, 8 Sep 1996 06:28:39 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id EAA21211 for <xemacs-beta@xemacs.org>; Sun, 8 Sep 1996 04:28:41 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id EAA08272 for <xemacs-beta@xemacs.org>; Sun, 8 Sep 1996 04:28:39 -0700
Date: Sun, 8 Sep 1996 04:28:39 -0700
Message-Id: <199609081128.EAA08272@shellx.best.com>
From: Ben Wing <wing@666.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>,
        Martin Buchholz
    <mrb@eng.sun.com>
Subject: Re:  Design Proposal: native-coding-system

I think this is a very good idea.  It elegantly merges the locale-
centric model (which makes life easier in the simple case but
utterly hoses you if you want multi-lingual stuff) and the more
flexible but less easy to use Mule model.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Sep  8 11:02:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA12572 for xemacs-beta-people; Sun, 8 Sep 1996 11:02:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA12569 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 8 Sep 1996 11:02:42 -0500 (CDT)
Received: from psilocin.gnu.ai.mit.edu (rms@psilocin.gnu.ai.mit.edu [128.52.46.62]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA19162 for <xemacs-beta@xemacs.org>; Sun, 8 Sep 1996 11:02:39 -0500 (CDT)
Received: by psilocin.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id MAA01550; Sun, 8 Sep 1996 12:02:28 -0400
Date: Sun, 8 Sep 1996 12:02:28 -0400
Message-Id: <199609081602.MAA01550@psilocin.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
to: xemacs-beta@xemacs.org
cc: rms@gnu.ai.mit.edu
Subject: Re: Versions of Emacs
Reply-to: rms@gnu.ai.mit.edu

People have suggested on various occasions that I stop asking for
legal papers before installing code in Emacs, and adopt the same
policies that the XEmacs developers have used.  Disregarding the
reason for the legal papers, it's a natural thing to suggest.

I ask for legal papers because our lawyer told me this is important
for being able to enforce the GPL.

If I stopped doing this, that could create the same risk that the
XEmacs development practices create: the FSF could have difficulty
enforcing the GPL.  Companies might eventually get away with making
proprietary versions of Emacs or XEmacs.

I think this would be a great setback for the free software community.
It would not only be bad in itself, it would set a very discouraging
example.

There is also the danger that someone might contribute code, and after
we used it, his employer would tell us that we had no permission to
use it.  Then they could sue us.

I am no fan of bureaucracy and I wish we could dispense with it.  But
I can't change the legal system by wishing or by ignoring it.

People whose opinion is that these outcomes would not matter can still
say I'm making unnecessary work and handicaps for myself.  But I think
most of you will at least recognize that asking for legal papers is
not arbitrary or gratuitous.

So I ask those of you who agree that it is worth doing some work to
prevent these dangers, to convince the XEmacs developers to cooperate
in preventing them, or else help me prevent them on my own.  I also
ask you to speak up in discussions among XEmacs fans.



From xemacs-beta-request@cs.uiuc.edu  Sun Sep  8 11:56:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA12633 for xemacs-beta-people; Sun, 8 Sep 1996 11:56:45 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA12630 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 8 Sep 1996 11:56:43 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA19520 for <xemacs-beta@xemacs.org>; Sun, 8 Sep 1996 11:56:39 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id MAA07998; Sun, 8 Sep 1996 12:56:36 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp007991; Sun Sep  8 12:56:04 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA15008; Sun, 8 Sep 96 12:56:03 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA21285; Sun, 8 Sep 96 12:56:02 EDT
Message-Id: <9609081656.AA21285@cfdevx1.lehman.com>
Reply-To: Rick Campbell <campbell@c2.net>
X-Windows: Let it get in YOUR way.
Organization: Lehman Brothers Inc.
From: Rick Campbell <campbell@c2.net>
To: rms@gnu.ai.mit.edu
Cc: xemacs-beta@xemacs.org
Subject: Re: Versions of Emacs 
In-Reply-To: Your message of "Sun, 08 Sep 1996 12:02:28 EDT."
             <199609081602.MAA01550@psilocin.gnu.ai.mit.edu> 
Date: Sun, 08 Sep 1996 12:56:00 -0400
Sender: rickc@lehman.com

-----BEGIN PGP SIGNED MESSAGE-----

    Date: Sun, 8 Sep 1996 12:02:28 -0400
    From: Richard Stallman <rms@gnu.ai.mit.edu>
    
    People have suggested on various occasions that I stop asking for
    legal papers before installing code in Emacs, and adopt the same
    policies that the XEmacs developers have used.

    . . .
    
    People whose opinion is that these outcomes would not matter can still
    say I'm making unnecessary work and handicaps for myself.  But I think
    most of you will at least recognize that asking for legal papers is
    not arbitrary or gratuitous.

I can't speak for others on this, but will note that I have not
suggested that you stop asking for legal papers.  Also, while I have
suggested it in the past, I recognize that your asking for these
papers is not completely gratuitous.

What I have suggested and continue to suggest is that you stop
accusing others who do not ask for legal papers of unfair competition.
You have your reasons for asking for legal papers, but your reasons do
not impose conditions on others who do not share them.

While it may be your opinion, it is far from being a given that Linux,
XEmacs, CMU Common Lisp, and others are somehow hurting the cause of
free software.  They might be hurting one aspect of ``Free Software''
as defined by the FSF, by having fewer restrictions, that is, more
freedom, but that is another issue completely.

Please note that I have avoided arbitrarily inserted a G into the name
`Linux' just as I do not refer to the FSF's version of GNU Emacs as
`FSF Emacs'.  I think that in the interest of having people take your
request to stop using the term `FSF Emacs', you might consider
avoiding this practise as well.

			Rick

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMjL6khj0UvMeUesFAQEZswP/fwU9YoYvLPqxnkYZJyfk2LMwqFY9VVPe
HMTZaeGX4NTiHq+TZK+OTu9hZtnGlSqJDnxnl826H9BSYvdPik1MZPX5dhhKunbC
axNsibnUKItiwotmgwLjImx29gbTXEdKdD7cGz3Kv50++iwBmqIyanKrqoJbaaes
8jMn0KLbjl8=
=9DpO
-----END PGP SIGNATURE-----
--
Rick Campbell <campbell@c2.net>	      ``One of the symptoms of an approaching
  http://www.c2.net/~campbell/		nervous breakdown is the belief that
					one's work is terribly important.''
							- Bertrand Russel

From xemacs-beta-request@cs.uiuc.edu  Sun Sep  8 13:18:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA13086 for xemacs-beta-people; Sun, 8 Sep 1996 13:18:02 -0500 (CDT)
Received: from c.cs.uiuc.edu (c.cs.uiuc.edu [128.174.252.3]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA13081 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 8 Sep 1996 13:18:01 -0500 (CDT)
Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by c.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA14484 for <xemacs-beta@cs.uiuc.edu>; Sun, 8 Sep 1996 06:40:51 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id EAA21053 for <xemacs-beta@cs.uiuc.edu>; Sun, 8 Sep 1996 04:40:41 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id EAA11776 for <xemacs-beta@cs.uiuc.edu>; Sun, 8 Sep 1996 04:40:35 -0700
Date: Sun, 8 Sep 1996 04:40:35 -0700
Message-Id: <199609081140.EAA11776@shellx.best.com>
From: Ben Wing <wing@666.com>
To: Steven L Baur <steve@miranova.com>, William Perry <wmperry@aventail.com>
Subject: Re: Using RedHat Linux RPM for breaking XEmacs 19.15 lisp into
    packages
Cc: xemacs-beta@cs.uiuc.edu
References: <m2afw5hhso.fsf@deanna.miranova.com>

>*** /tmp/T0a0037L	Thu Aug  8 13:39:01 1996
>--- ./build/spec.c	Wed Aug  7 14:13:45 1996
>***************
>*** 783,789 ****
>--- 783,793 ----
>      }
>      
>      appendLineStringBuf(package->doc, "mkdir -p $DOCDIR");
>+ #ifdef HAVE_GNU_CP
>      appendStringBuf(package->doc, "cp -ar ");
>+ #else
>+     appendStringBuf(package->doc, "cp -pr ");
>+ #endif
>      appendStringBuf(package->doc, line);
>      appendLineStringBuf(package->doc, " $DOCDIR");

This isn't correct -- `cp -pr' doesn't correctly handle
symbolic links.  You'd need to do something like
`tar cf - foo | (cd bar && tar xpf -)'.

Maybe you'd even want `tar xpBf'.  I'm not sure whether this is
necessary or advisable, as I don't really understand the -B option.

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Sep  8 13:15:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA12829 for xemacs-beta-people; Sun, 8 Sep 1996 13:15:05 -0500 (CDT)
Received: from c.cs.uiuc.edu (c.cs.uiuc.edu [128.174.252.3]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA12826 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 8 Sep 1996 13:15:04 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by c.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA15813 for <xemacs-beta@cs.uiuc.edu>; Sun, 8 Sep 1996 11:52:01 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id JAA11953; Sun, 8 Sep 1996 09:55:29 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: Richard Stallman <rms@gnu.ai.mit.edu>
Subject: Re: Versions of Emacs
References: <199609081602.MAA01550@psilocin.gnu.ai.mit.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Richard Stallman's message of Sun, 8 Sep 1996 12:02:28 -0400
Mime-Version: 1.0 (generated by tm-edit 7.83)
Content-Type: text/plain; charset=US-ASCII
Date: 08 Sep 1996 09:55:28 -0700
Message-ID: <m27mq5hrpb.fsf@deanna.miranova.com>
Lines: 24
X-Mailer: Red Gnus v0.30/XEmacs 19.14

>>>>> "rms" == Richard Stallman <rms@gnu.ai.mit.edu> writes:

rms> I ask for legal papers because our lawyer told me this is
rms> important for being able to enforce the GPL.

Do you need separate copies of the assignment for both the emacsen, or
will one blanket assignment be sufficient?

After a developer's employer has signed the paperwork, is it necessary
for new papers to be signed if a brand new Emacs Lisp package is
written?

After a developer's employer has signed the paperwork, does it cover
making patches to existing copyright assigned packages in (either)
Emacs?

I've got copies of the copyright assignment Lars Magne Ingebrigtsen
sent me for Gnus (which I've used twice now), are those still current?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 06:09:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA18708 for xemacs-beta-people; Mon, 9 Sep 1996 06:09:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA18705 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 06:09:45 -0500 (CDT)
Received: from eik (eik.ii.uib.no [129.177.16.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA06126 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 06:09:38 -0500 (CDT)
Received: from terne.ii.uib.no (terne) by eik with SMTP id AA29129
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Mon, 9 Sep 1996 13:09:28 +0200
Received: by terne.ii.uib.no; (5.65/1.1.8.2/08Jun94-0756AM)
	id AA17722; Mon, 9 Sep 1996 13:09:22 +0200
Sender: ketil@ii.uib.no
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: RMS' message re XEmacs
References: <199609041817.LAA00170@xemacs.eng.sun.com>
From: Ketil Z Malde <ketil@ii.uib.no>
In-Reply-To: Martin Buchholz's message of Wed, 4 Sep 1996 11:17:55 -0700
Date: 09 Sep 1996 13:09:21 +0200
Message-Id: <KETIL-egsp8sosgu.fsf@terne.ii.uib.no>
Lines: 45
X-Mailer: Gnus v5.2.25/XEmacs 19.14


RMS writes:

> XEmacs arose as a separate
> forked version because some of the developers--starting with
> Zawinski--were unwilling to do that.

Uh..and according to the XEmacs developers, it arose as a separate
forked version because the Emacs developers were unwilling to program in
a way suitable for them.  I don't know enough of the source to
judge whether the XEmacs source is cleaner and more readable, most
people who hold an opinion seem to think so.

> People should have the freedom to decide what to work on, including
> the freedom to compete with the GNU project, but it's a shame when
> they make that choice.  The whole community loses when someone chooses
> competition rather than cooperation.

I don't know.  I'd say the whole community loses when someone holds and
uses the authority to bar progressive improvements.  The possibility to
take a GNU (or any GPLed) program and fork off another version when the
philosophical differences become insurmountable, is not a bug, it's a
feature.  It ensures that new paths will be explored, in spite of the
original author's intent, for the good of the community.

Posteriority will decide whether the XEmacs or the Emacs path was the
right one, or whether both (or none) are healthy and viable approaches.

> But this is worse than competition--it is unfair competition.

As others have pointed out, the unfairness arises from FSF's self
imposed rules.  If this rule turns out to be an obstacle for software
development, I hardly believe FSF can blame anybody, but themselves.

I really would wish that FSF and RMS could take a deep breath
occasionally, and look upon their works and see that it is good -- even
if every child won't follow in their exact footsteps.  XEmacs still
seems to be viewed in a rather hostile manner, Linux has been
reluctantly adopted as an illegitimate child.  Both are products of the
GNU effort, and great advances for the free software community.  I'd
like to see RMS as the benevolent father of free software, not as the
grumpy old tyrant of same.

~kzm
"Ask nicely, and thou shall recieve"

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 06:18:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA18717 for xemacs-beta-people; Mon, 9 Sep 1996 06:18:07 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA18714 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 06:18:06 -0500 (CDT)
Received: from eik (eik.ii.uib.no [129.177.16.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id GAA06136 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 06:18:02 -0500 (CDT)
Received: from terne.ii.uib.no (terne) by eik with SMTP id AA29204
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Mon, 9 Sep 1996 13:15:11 +0200
Received: by terne.ii.uib.no; (5.65/1.1.8.2/08Jun94-0756AM)
	id AA14963; Mon, 9 Sep 1996 13:14:14 +0200
Sender: ketil@ii.uib.no
To: Martin Buchholz <mrb@eng.sun.com>
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: Design Proposal: native-coding-system
References: <199609070350.UAA09167@xemacs.eng.sun.com>
From: Ketil Z Malde <ketil@ii.uib.no>
In-Reply-To: Martin Buchholz's message of Fri, 6 Sep 1996 20:50:50 -0700
Date: 09 Sep 1996 13:14:13 +0200
Message-Id: <KETIL-egpw3wos8q.fsf@terne.ii.uib.no>
Lines: 7
X-Mailer: Gnus v5.2.25/XEmacs 19.14


I like the idea, but wouldn't it be preferable to have these variables
prefixed with something, in order to make it easier to
search-by-completion after them.  (I.e. M-x coding- [TAB]  showing all
possibilities for customization)?  Guess it might be a bit late for that?

~kzm

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 07:26:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA18862 for xemacs-beta-people; Mon, 9 Sep 1996 07:26:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA18859 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 07:26:01 -0500 (CDT)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA06218 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 07:25:44 -0500 (CDT)
Received: from hniksic@localhost by jagor.srce.hr (8.7.5/8.6.12.CI)
	id OAA21775; Mon, 9 Sep 1996 14:25:02 +0200 (MET DST)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: Re: XEmacs User Survey
References: <199609072326.SAA16654@xemacs.cs.uiuc.edu>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/geturl/geturl.tar.gz
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 09 Sep 1996 14:25:01 +0200
In-Reply-To: Chuck Thompson's message of Sat, 07 Sep 1996 18:26:53 -0500
Message-ID: <kig7mq3swo2.fsf@jagor.srce.hr>
Lines: 21
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Chuck Thompson (cthomp@xemacs.org) wrote:
> I would appreciate it if everyone would take a look and give me some
> feedback, either about bugs or suggestions for improvements.  I'll
> give about a week for feedback and then this will move to the front
> page of www.xemacs.org and I'll make a posting to all emacs related
> newsgroups asking people to complete the survey.

It would be fine to add an extra level between average and expert. I
do not consider myself an average XEmacs user, but I am not a true
expert either (because of my limited grasp of Elisp). Proposed scale:
 - novice
 - average
 - advanced
 - expert

-- 
hniksic@srce.hr              |  Student of electrical engineering
hniksic@fly.cc.fer.hr        |  University of Zagreb, Croatia
------------------------------------------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 10:03:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA19399 for xemacs-beta-people; Mon, 9 Sep 1996 10:03:59 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA19396 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 10:03:58 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA19409 for <xemacs-beta@cs.uiuc.edu>; Mon, 9 Sep 1996 10:03:58 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id IAA24453; Mon, 9 Sep 1996 08:03:26 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA11121; Mon, 9 Sep 96 11:03:25 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id LAA03856; Mon, 9 Sep 1996 11:03:21 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id LAA04607; Mon, 9 Sep 1996 11:03:04 -0400
Date: Mon, 9 Sep 1996 11:03:04 -0400
Message-Id: <199609091503.LAA04607@detlev.canada.sun.com>
From: Georg Nikodym <georgn@canada.sun.com>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs User Survey 
In-Reply-To: <199609080216.VAA16887@xemacs.cs.uiuc.edu>
References: <m2wwy5kbtd.fsf@deanna.miranova.com>
	<199609080216.VAA16887@xemacs.cs.uiuc.edu>
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII

>>>>> "CT" == Chuck Thompson <cthomp@xemacs.org> writes:

 CT> I want to know who uses it and where.  Your additional questions
 CT> are good ones which I'm considering doing on another survey later
 CT> but I don't want that kind of detail on this one.  It is already
 CT> a little longer than I would like.

OK, one more suggestion...

You have three levels of XEmacs user.  I suspect that many people
would be reluctant to call themselves experts, yet are clearly not
average.  Ie.  anyone responsible for providing XEmacs installations
and/or support to a group...  Suggest you add an in between level, or
definitions (that is if the answer to that question is even
interesting).

A comment section would also be a good idea.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 14:04:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA20477 for xemacs-beta-people; Mon, 9 Sep 1996 14:04:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA20474 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 14:04:37 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA21779 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 14:04:33 -0500 (CDT)
Received: from charney by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id NAA27632; Mon, 9 Sep 1996 13:04:25 -0600
Received: by charney (SMI-8.6) id NAA01058; Mon, 9 Sep 1996 13:04:24 -0600
Date: Mon, 9 Sep 1996 13:04:24 -0600
Message-Id: <199609091904.NAA01058@charney.cdc.noaa.gov>
From: Mark Borges <mdb@cdc.noaa.gov>
To: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: [19.15b1] success on sparc-sun-solaris2.5.
Organization: CIRES, University of Colorado
X-Attribution: mb

Just in time. I was going into beta withdrawal...

The beta www site seems to have filled up as well. Will all of these
be fixed/addressed for 19.15? Or just the high priority/critical
variety?

There is also one report that I don't think is on the list of 115 that
is a pet peeve/annoyance for me. It's the one discussing focus
lossage, particularly bothersome with a virtual wm. Originally sent in
by Steven Baur and acknowledged by Ben a while back. I'll dig up a
couple references and send them in under separate cover.

------------------------------------------------------------------------------
Configured for `sparc-sun-solaris2.5'.

  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              cc -xO2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in support for CDE.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 14:10:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA20513 for xemacs-beta-people; Mon, 9 Sep 1996 14:10:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA20510 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 14:10:43 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA22368 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 14:10:41 -0500 (CDT)
Received: from charney by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id NAA27735; Mon, 9 Sep 1996 13:10:39 -0600
Received: by charney (SMI-8.6) id NAA01101; Mon, 9 Sep 1996 13:10:37 -0600
Date: Mon, 9 Sep 1996 13:10:37 -0600
Message-Id: <199609091910.NAA01101@charney.cdc.noaa.gov>
From: Mark Borges <mdb@cdc.noaa.gov>
To: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: [19.15] focus behavior: bug/feature
Organization: CIRES, University of Colorado
X-Attribution: mb

I didn't see this addressed in the new XEmacs 19.15 bug database. (At
least it doesn't show up when showing the entire database and
searching for the string `focus').

I realize 19.15 is already in feature freeze, but I hope this can be
addressed or at least discussed some more.

Thanks.

--------------------------------------------------------------------------
Message-Id: <199605190123.BAA00421@nene.boundless.com>
>> On Sun, 19 May 1996 01:23:01 GMT,
>> Ben Wing(BW) wrote:
BW> Steven L. Baur writes:
>> Repeating my original request, I respectfully request a way to turn
>> this misfeature off.

BW> OK, bring this up again after 19.14 is released and I'll look into it.
BW> I don't want to change something like this so close to release.

--------------------------------------------------------------------------
Message-Id: <199605151012.DAA03234@netcom2.netcom.com>
>> On Wed, 15 May 1996 03:12:39 -0700,
>> Ben Wing(BW) wrote:
>>>>>>> "Ben" == Ben Wing <wing@666.com> writes:
>> 
Ben> Steven L. Baur writes:
>>>> I figured out what was going on.  I was in a second frame in another
>>>> virtual console.  XEmacs was attempting to shift focus into the other
>>>> frame and the other window with *scratch* in it.
>>>> 
>>>> I do not care for this kind of frame behavior.  Can it be turned off?
>>>> Warping focus, especially with a virtual desktop, is *evil*.
>> 
Ben> I've sometimes seen this, I think (where suddenly a window goes out
Ben> of focus and you have to move the mouse out and back into the frame)
Ben> and I agree it's quite annoying.  I've never quite figured out what's
Ben> causing it -- I've only seen it after starting up VM using `M-x vm'
Ben> after it's retrieved my new mail, so I bet it's VM doing something
Ben> nasty.
>> 
Ben> Kyle?
>> 
>> It's not from Kyle's code.  I use Gnus for mail (apologies to Kyle),
>> but I can reproduce the problem with a naked XEmacs.

BW> OK, here's an even easier way than what you've specified:

BW> 1. Create a second frame
BW> 2. In either frame, do (select-frame (next-frame))

BW> Focus shifts to the other frame.

BW> Obviously this is a "feature" not a "bug", and this is longtime
BW> XEmacs behavior.  There are a few questions, though --

BW> 1. Is this behavior desirable?  If you're in explicit focus mode,
BW>    it probably is.  In focus-follows-mouse mode, it's probably not.
BW>    But how can you distinguish?  Maybe we need a variable combined
BW>    with some approximate tests that try to query the window manager?
BW>    I don't want to write this code, though.  Window managers suck
BW>    more than the most powerful Hoover ever even dreamed of.
BW> 2. It might be argued that this behavior in of itself is not problematic
BW>    even though it violates the ICCCM (ediff warps the mouse, and that
BW>    violates the ICCCM too, but nobody complains too much).  It might
BW>    be argued that the problem lies in VM or GNUS, which is (by whatever
BW>    it's doing) triggering incorrect calls to `select-frame'.

>> 1.  Be running X Windows with a virtual window manager like olvwm.
>> The focus behavior will be easier to follow if you have
>> click-to-focus mode set instead of focus-follows-mouse, but this is
>> not required, at least with olvwm.
>> 2.  Start xemacs -q in one virtual screen
>> 3.  Do C-x 5 b ~/.emacs
>> Any file will do here.
>> 4.  Drag the second frame into another virtual screen.
>> At this point you have two frames in two separate virtual screens,
>> the original XEmacs frame is sitting in the original *scratch* buffer.
>> 5.  Do C-x 4 b *scratch*
>> The window will not split, instead focus will be sent to the original
>> frame with the original *scratch* window.
>> 
>> Here is a second example.  Continuing on:
>> 6.  Select Options/General Options/Debug on Quit from the menubar
>> 7.  Repeat step 5 and hit C-g.
>> Nothing happens, right?
>> 8.  Shift virtual screens to verify that the *Backtrace* buffer was
>> opened on the original frame in the invisible virtual screen.
>> 
>> This is a serious bug, IMHO.  Focus should *never* be switched except
>> by explicit action of the user.  A command like C-x 4 b should never
>> cause actions to occur outside of the frame it was invoked from.

BW> Well, XEmacs doesn't know about virtual screens so it's hard to fault
BW> it for opening windows in different frames and expecting them to be
BW> visible.  FSF Emacs does this, too.

BW> However, the bug that I'm seeing is a bit different from this -- I don't
BW> have virtual screens, and the focus still gets lost from the VM frame.
BW> It doesn't appear to be going anywhere, just lost (although I might
BW> be mistaken).

BW> ben

------------------------------------------------------------------------------
Also see message id <m2ivdw6jfk.fsf@deanna.miranova.com>.


-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 15:16:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA20834 for xemacs-beta-people; Mon, 9 Sep 1996 15:16:53 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA20831 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 15:16:50 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA26731 for <xemacs-beta@cs.uiuc.edu>; Mon, 9 Sep 1996 15:16:47 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id NAA29678; Mon, 9 Sep 1996 13:20:30 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [19.15-b1] Success on Linux/ELF 2.0.18
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 09 Sep 1996 13:20:29 -0700
Message-ID: <m2hgp7784y.fsf@deanna.miranova.com>
Lines: 53
X-Mailer: Gnus v5.2.40/XEmacs 19.15

(emacs-version)
"XEmacs 19.15 [Lucid] (i486-unknown-linux2.0.18) of Mon Sep  9 1996 on deanna.miranova.com"

Flawless configure, compile, etc.  The psgml upgrade looks like (on
visual inspection) it was integrated O.K., but I haven't ran it yet.

Problems:
The upgrade patches I submitted for ps-print.el are missing, I hope
those aren't lost, ps-print is unusable for me and others without
them.

Simon Marshall's update of fast-lock.el, and my font lock region
patch.

Tools for MIME :-(  Oh well, 19.16 I hope.

For HTML wizards:  The psgml mode now includes the HTML Cougar DTD,
but psgml mode (and XEmacs 19) is unable to deal with multibyte
characters.  Any suggestions for a quick way to fix this?

Configured for `i486-unknown-linux2.0.18'.

  Where should the build process find the source code?    /i/xemacs-19.15-b1
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.



-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 15:17:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id PAA20839 for xemacs-beta-people; Mon, 9 Sep 1996 15:17:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA20836 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 15:16:59 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id PAA26385 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 15:16:50 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.7.5/8.7.3) with ESMTP id PAA26237 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 15:14:40 -0500
Message-Id: <199609092014.PAA26237@nvwls.cc.purdue.edu>
Reply-to: nuspl@purdue.edu
X-Mailer: MH-E 5.0.2
X-Attribution: JJN
X-Face: K'Q`VIQx)c-;TPHDA`.,kBQq(WyNe3AdopJ?B(.4yT%n|F?4>+?x]pQ4XC83s-4;|U{%9x]
 =yr4dko
To: xemacs-beta@xemacs.org
Subject: MH-E patch
Date: Mon, 09 Sep 1996 15:14:36 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


Here is a patch to sync mh-e w/ RMS 19.34.


--- /opt/xemacs-20.0-b26/lisp/mh-e/mh-utils.el	Sun Apr 14 19:56:17 1996
+++ mh-utils.el	Mon Sep  9 15:08:05 1996
@@ -16,8 +16,11 @@
 ;; GNU General Public License for more details.
 
 ;; You should have received a copy of the GNU General Public License
-;; along with GNU Emacs; see the file COPYING.  If not, write to
-;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+;; along with XEmacs; see the file COPYING.  If not, write to the
+;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+;; Boston, MA 02111-1307, USA.
+
+;;; Synched up with: FSF 19.34.
 
 ;;; Commentary:
 
@@ -25,7 +28,7 @@
 
 ;;; Change Log:
 
-;; $Id: mh-utils.el,v 1.9.1.2 95/10/22 22:02:53 gildea Exp $
+;; $Id: mh-utils.el,v 1.10 1996/06/28 06:56:17 rms Exp $
 
 ;;; Code:
 
@@ -300,7 +303,7 @@
 	   ;; Changing contents, so this hook needs to be reinitialized.
 	   ;; pgp.el uses this.
 	   (if (boundp 'write-contents-hooks) ;Emacs 19
-	       (setq write-contents-hooks nil))
+	       (kill-local-variable 'write-contents-hooks))
 	   (if formfile
 	       (mh-exec-lib-cmd-output "mhl" "-nobell" "-noclear"
 				       (if (stringp formfile)
@@ -512,7 +515,7 @@
 	     (end-of-line)
 	     (buffer-substring start (point)))))))
 
-(defvar mua-paradigm "MH-E")		;from mua.el
+(defvar mail-user-agent 'mh-e-user-agent) ;from reporter.el 3.2
 
 (defun mh-find-path ()
   ;; Set mh-progs and mh-lib.
@@ -556,7 +559,7 @@
       (setq mh-previous-seq (mh-get-profile-field "Previous-Sequence:"))
       (if mh-previous-seq
 	  (setq mh-previous-seq (intern mh-previous-seq)))
-      (setq mua-paradigm "MH-E")
+      (setq mail-user-agent 'mh-e-user-agent)
       (run-hooks 'mh-find-path-hook))))
 
 (defun mh-find-progs ()
@@ -894,23 +897,23 @@
   (cond ((eql status 0)			;success
 	 status)
 	((stringp status)		;kill string
-	 (error (format "%s: %s" command status)))
+	 (error "%s: %s" command status))
 	(t				;exit code
 	 (cond
 	  ((= (buffer-size) 0)		;program produced no error message
-	   (error (format "%s: exit code %d" command status)))
+	   (error "%s: exit code %d" command status))
 	  (t
 	   ;; will error message fit on one line?
 	   (goto-line 2)
 	   (if (and (< (buffer-size) (screen-width))
 		    (eobp))
-	       (error (buffer-substring 1 (progn (goto-char 1)
+	       (error "%s"
+		      (buffer-substring 1 (progn (goto-char 1)
 						 (end-of-line)
 						 (point))))
 	     (display-buffer (current-buffer))
-	     (error (format
-		     "%s failed with status %d.  See error message in other window."
-		     command status))))))))
+	     (error "%s failed with status %d.  See error message in other window."
+		    command status)))))))
 
 
 (defun mh-expand-file-name (filename &optional default)

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 16:14:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA21252 for xemacs-beta-people; Mon, 9 Sep 1996 16:14:12 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA21249 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 16:14:11 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA26506 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 16:14:08 -0500 (CDT)
Received: from kramer.aventail.com (root@newman [192.168.1.1]) by newman (8.6.12/8.6.9) with SMTP id OAA10494 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 14:12:29 -0700
Date: Mon, 9 Sep 1996 14:12:29 -0700
Message-Id: <199609092112.OAA10494@newman>
From: William Perry <wmperry@aventail.com>
To: xemacs-beta@xemacs.org
Subject: Success on Solaris 2.5/x86
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Everything appears to be working fine so far.

-Bill P.

Configured for `i386-unknown-solaris2.5.1'.
 
  Where should the build process find the source code?    /usr/local/src/xemacs-20.0-b28
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/dt/include /usr/demo/SOUND/include /usr/openwin/include
  Additional libraries:                                   /usr/demo/SOUND/lib /usr/dt/lib /usr/openwin/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in support for CDE.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 16:45:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA21412 for xemacs-beta-people; Mon, 9 Sep 1996 16:45:20 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA21409 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 16:45:19 -0500 (CDT)
Received: from pixar.com (pixar.pixar.com [138.72.10.20]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA26567 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 16:45:16 -0500 (CDT)
Received: from zule.pixar.com (gate-zule.pixar.com) by pixar.com with SMTP id AA07830
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Mon, 9 Sep 1996 14:44:40 -0700
Received: by zule.pixar.com (Smail3.1.28.1 #12)
	id m0v0E8G-0007r5C; Mon, 9 Sep 96 14:44 PDT
Message-Id: <m0v0E8G-0007r5C@zule.pixar.com>
Date: Mon, 9 Sep 96 14:44 PDT
From: Hunter Kelly <retnuh@zule.pixar.com>
To: Mark Borges <mdb@cdc.noaa.gov>
Cc: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: Re: [19.15] focus behavior: bug/feature
In-Reply-To: <199609091910.NAA01101@charney.cdc.noaa.gov>
References: <199609091910.NAA01101@charney.cdc.noaa.gov>
Mime-Version: 1.0 (generated by tm-edit 7.82)
Content-Type: text/plain; charset=US-ASCII


I understand the need to be able to switch frames from the keyboard,
but I get really annoyed when I do a C-x 4 b, and the focus shifts
into a frame that is already displaying the buffer.  I have so many
frames that get buried by other windows, I don't really care if the
buffer is being displayed elsewhere.  When I hit C-x 4 b, I want to
see the dang buffer in the frame I typed it in.

Hunter

Mark Borges writes:
 > Date: Mon, 9 Sep 1996 13:10:37 -0600
 > To: XEmacs beta-list <xemacs-beta@xemacs.org>
 > From: Mark Borges <mdb@cdc.noaa.gov>
 > Subject: [19.15] focus behavior: bug/feature
 > 
 > I didn't see this addressed in the new XEmacs 19.15 bug database. (At
 > least it doesn't show up when showing the entire database and
 > searching for the string `focus').
 > 
 > I realize 19.15 is already in feature freeze, but I hope this can be
 > addressed or at least discussed some more.
 > 
 > Thanks.
 > 
 > --------------------------------------------------------------------------
 > Message-Id: <199605190123.BAA00421@nene.boundless.com>
 > >> On Sun, 19 May 1996 01:23:01 GMT,
 > >> Ben Wing(BW) wrote:
 > BW> Steven L. Baur writes:
 > >> Repeating my original request, I respectfully request a way to turn
 > >> this misfeature off.
 > 
 > BW> OK, bring this up again after 19.14 is released and I'll look into it.
 > BW> I don't want to change something like this so close to release.
 > 
 > --------------------------------------------------------------------------
 > Message-Id: <199605151012.DAA03234@netcom2.netcom.com>
 > >> On Wed, 15 May 1996 03:12:39 -0700,
 > >> Ben Wing(BW) wrote:
 > >>>>>>> "Ben" == Ben Wing <wing@666.com> writes:
 > >> 
 > Ben> Steven L. Baur writes:
 > >>>> I figured out what was going on.  I was in a second frame in another
 > >>>> virtual console.  XEmacs was attempting to shift focus into the other
 > >>>> frame and the other window with *scratch* in it.
 > >>>> 
 > >>>> I do not care for this kind of frame behavior.  Can it be turned off?
 > >>>> Warping focus, especially with a virtual desktop, is *evil*.
 > >> 
 > Ben> I've sometimes seen this, I think (where suddenly a window goes out
 > Ben> of focus and you have to move the mouse out and back into the frame)
 > Ben> and I agree it's quite annoying.  I've never quite figured out what's
 > Ben> causing it -- I've only seen it after starting up VM using `M-x vm'
 > Ben> after it's retrieved my new mail, so I bet it's VM doing something
 > Ben> nasty.
 > >> 
 > Ben> Kyle?
 > >> 
 > >> It's not from Kyle's code.  I use Gnus for mail (apologies to Kyle),
 > >> but I can reproduce the problem with a naked XEmacs.
 > 
 > BW> OK, here's an even easier way than what you've specified:
 > 
 > BW> 1. Create a second frame
 > BW> 2. In either frame, do (select-frame (next-frame))
 > 
 > BW> Focus shifts to the other frame.
 > 
 > BW> Obviously this is a "feature" not a "bug", and this is longtime
 > BW> XEmacs behavior.  There are a few questions, though --
 > 
 > BW> 1. Is this behavior desirable?  If you're in explicit focus mode,
 > BW>    it probably is.  In focus-follows-mouse mode, it's probably not.
 > BW>    But how can you distinguish?  Maybe we need a variable combined
 > BW>    with some approximate tests that try to query the window manager?
 > BW>    I don't want to write this code, though.  Window managers suck
 > BW>    more than the most powerful Hoover ever even dreamed of.
 > BW> 2. It might be argued that this behavior in of itself is not problematic
 > BW>    even though it violates the ICCCM (ediff warps the mouse, and that
 > BW>    violates the ICCCM too, but nobody complains too much).  It might
 > BW>    be argued that the problem lies in VM or GNUS, which is (by whatever
 > BW>    it's doing) triggering incorrect calls to `select-frame'.
 > 
 > >> 1.  Be running X Windows with a virtual window manager like olvwm.
 > >> The focus behavior will be easier to follow if you have
 > >> click-to-focus mode set instead of focus-follows-mouse, but this is
 > >> not required, at least with olvwm.
 > >> 2.  Start xemacs -q in one virtual screen
 > >> 3.  Do C-x 5 b ~/.emacs
 > >> Any file will do here.
 > >> 4.  Drag the second frame into another virtual screen.
 > >> At this point you have two frames in two separate virtual screens,
 > >> the original XEmacs frame is sitting in the original *scratch* buffer.
 > >> 5.  Do C-x 4 b *scratch*
 > >> The window will not split, instead focus will be sent to the original
 > >> frame with the original *scratch* window.
 > >> 
 > >> Here is a second example.  Continuing on:
 > >> 6.  Select Options/General Options/Debug on Quit from the menubar
 > >> 7.  Repeat step 5 and hit C-g.
 > >> Nothing happens, right?
 > >> 8.  Shift virtual screens to verify that the *Backtrace* buffer was
 > >> opened on the original frame in the invisible virtual screen.
 > >> 
 > >> This is a serious bug, IMHO.  Focus should *never* be switched except
 > >> by explicit action of the user.  A command like C-x 4 b should never
 > >> cause actions to occur outside of the frame it was invoked from.
 > 
 > BW> Well, XEmacs doesn't know about virtual screens so it's hard to fault
 > BW> it for opening windows in different frames and expecting them to be
 > BW> visible.  FSF Emacs does this, too.
 > 
 > BW> However, the bug that I'm seeing is a bit different from this -- I don't
 > BW> have virtual screens, and the focus still gets lost from the VM frame.
 > BW> It doesn't appear to be going anywhere, just lost (although I might
 > BW> be mistaken).
 > 
 > BW> ben
 > 
 > ------------------------------------------------------------------------------
 > Also see message id <m2ivdw6jfk.fsf@deanna.miranova.com>.
 > 
 > 
 > -- 
 >   -mb-

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 17:07:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA21599 for xemacs-beta-people; Mon, 9 Sep 1996 17:07:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA21596 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 17:07:26 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA26608 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 17:07:21 -0500 (CDT)
Received: from charney by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id QAA01533; Mon, 9 Sep 1996 16:07:09 -0600
Received: by charney (SMI-8.6) id QAA05071; Mon, 9 Sep 1996 16:07:09 -0600
Sender: mdb@cdc.noaa.gov
To: Hunter Kelly <retnuh@zule.pixar.com>
Cc: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: Re: [19.15] focus behavior: bug/feature
References: <199609091910.NAA01101@charney.cdc.noaa.gov>
	<m0v0E8G-0007r5C@zule.pixar.com>
Organization: CIRES, University of Colorado
X-Attribution: mb
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 09 Sep 1996 16:07:07 -0600
In-Reply-To: Hunter Kelly's message of Mon, 9 Sep 96 14:44 PDT
Message-ID: <vkn2yz8hro.fsf@cdc.noaa.gov>
Lines: 21
X-Mailer: Gnus v5.2.40/XEmacs 19.15

>> On Mon, 9 Sep 96 14:44 PDT,
>> Hunter Kelly(HK) wrote:
HK> I understand the need to be able to switch frames from the keyboard,
HK> but I get really annoyed when I do a C-x 4 b, and the focus shifts
HK> into a frame that is already displaying the buffer.  I have so many
HK> frames that get buried by other windows, I don't really care if the
HK> buffer is being displayed elsewhere.  When I hit C-x 4 b, I want to
HK> see the dang buffer in the frame I typed it in.

I believe this feature has been reverted back in 19.15b1, according
to the CHANGES-beta file. Indeed, C-x 4 b creates a second window in
the current frame (even if the buffer is displayed in another frame)
in my copy of 19.15b1.

The problem I was concerned with is different and still there. A
common symptom is zombie (almost-dead) frames when used with a virtual
window manager if you switch focus at the wrong time. Fortunately a
iconify/de-iconify sequence brings the zombie frame back.

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 17:13:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA21614 for xemacs-beta-people; Mon, 9 Sep 1996 17:13:34 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA21611 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 17:13:33 -0500 (CDT)
Received: from wayback.uoregon.edu (wayback.uoregon.edu [128.223.156.117]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA26622 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 17:13:29 -0500 (CDT)
Received: (from meyer@localhost) by wayback.uoregon.edu (8.7.5/8.7.1) id PAA05972; Mon, 9 Sep 1996 15:09:40 -0700 (PDT)
Date: Mon, 9 Sep 1996 15:09:40 -0700 (PDT)
Message-Id: <199609092209.PAA05972@wayback.uoregon.edu>
From: "David M. Meyer 541/346-1747" <meyer@network-services.uoregon.edu>
To: xemacs-beta@xemacs.org
Subject: 20.0-beta28 success on space solaris 2.5.1




  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/dt/include
  Additional libraries:                                   /usr/dt/lib /usr/dt/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for GNU DBM.
  Compiling in support for CDE.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 18:08:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA21817 for xemacs-beta-people; Mon, 9 Sep 1996 18:08:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA21814 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 18:08:21 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA00867 for <xemacs-beta@cs.uiuc.edu>; Mon, 9 Sep 1996 18:08:18 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id QAA32359; Mon, 9 Sep 1996 16:12:00 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Dired problems and patches [19.14 & 19.15b1]
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 09 Sep 1996 16:11:59 -0700
Message-ID: <m2g24r5lmo.fsf@deanna.miranova.com>
Lines: 49
X-Mailer: Gnus v5.2.40/XEmacs 19.15

Problem 1:
dired-make-permissions-interactive is referenced as a global, but is
not autoloaded.

*** dired-chmod.el~	Tue Aug  8 14:07:04 1995
--- dired-chmod.el	Mon Sep  9 16:03:16 1996
***************
*** 132,137 ****
--- 132,138 ----
  					 ((looking-at "x") "o-x")
  					 (t "o-x")))))))
  
+ ;;;###autoload
  (defun dired-make-permissions-interactive ()
    (save-excursion
      (beginning-of-line 0)


Problem 2:
If one adds to dired-sort-on-size to the dired-after-readin-hook as
suggested by the documentation, XEmacs bombs with a buffer readonly
message.

*** dired.el~	Sun Sep  8 16:48:19 1996
--- dired.el	Mon Sep  9 16:01:31 1996
***************
*** 456,462 ****
        ;; dired-readin's output, nothing else.  The hook can
        ;; successfully use dired functions (e.g. dired-get-filename)
        ;; as the subdir-alist has been built in dired-readin.
!       (run-hooks 'dired-after-readin-hook)
        (goto-char (point-min))
        (dired-initial-position dirname))
      (set-buffer old-buf)
--- 456,463 ----
        ;; dired-readin's output, nothing else.  The hook can
        ;; successfully use dired functions (e.g. dired-get-filename)
        ;; as the subdir-alist has been built in dired-readin.
!       (let (buffer-read-only)
! 	(run-hooks 'dired-after-readin-hook))
        (goto-char (point-min))
        (dired-initial-position dirname))
      (set-buffer old-buf)

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 18:13:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA21840 for xemacs-beta-people; Mon, 9 Sep 1996 18:13:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA21837 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 18:13:13 -0500 (CDT)
Received: from pixar.com (pixar.pixar.com [138.72.10.20]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA26797 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 18:13:09 -0500 (CDT)
Received: from zule.pixar.com (gate-zule.pixar.com) by pixar.com with SMTP id AA13226
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Mon, 9 Sep 1996 16:12:41 -0700
Received: by zule.pixar.com (Smail3.1.28.1 #12)
	id m0v0FVQ-0007r1C; Mon, 9 Sep 96 16:12 PDT
Message-Id: <m0v0FVQ-0007r1C@zule.pixar.com>
Date: Mon, 9 Sep 96 16:12 PDT
From: Hunter Kelly <retnuh@zule.pixar.com>
To: xemacs-beta@xemacs.org
Subject: [19.15b1]  Success on IRIX 5.3
Mime-Version: 1.0 (generated by tm-edit 7.82)
Content-Type: text/plain; charset=US-ASCII



Sending mail with the new binary...

Configured for `mips-sgi-irix5.3'.

  Where should the build process find the source code?    /u0/retnuh/big1/beta/src/xemacs-19.15-b1
  What installation prefix should install use?            /home/retnuh/beta
  What operating system and machine description files should XEmacs use?
        `s/irix5-3.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include /home/retnuh/include
  Additional libraries:                                   /usr/local/lib /home/retnuh/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 18:39:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA21928 for xemacs-beta-people; Mon, 9 Sep 1996 18:39:44 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA21925 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 18:39:43 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA01256 for <xemacs-beta@cs.uiuc.edu>; Mon, 9 Sep 1996 18:39:42 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id SAA24824 for <xemacs-beta@cs.uiuc.edu>; Mon, 9 Sep 1996 18:39:11 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id SAA00508 for <xemacs-beta@cs.uiuc.edu>; Mon, 9 Sep 1996 18:39:10 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id TAA14587 for <xemacs-beta@cs.uiuc.edu>; Mon, 9 Sep 1996 19:39:29 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Release dates for 19.15 and 20.0 and the future of each?
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 09 Sep 1996 19:35:59 -0400
Message-ID: <2188.842312159@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


I'm curious about the release dates of 19.15 and 20.0 and the future
of each.  

I'm the "maintainer" here and am wondering what to do when 19.15 and
20.0 are finally released.  I don't really want to have to maintain
both versions because that's not really part of my job.  I also don't
really have the time to build and test both versions.  I "maintain"
XEmacs here because I want to use XEmacs.

I'm assuming that 19.xx will eventually go away in favor of the 20.yy
version.  Thus, if 19.15 comes out at the same time as 20.0, I think
I'll just go for 20.0.  20.0 would be nice, since we are a very
international company (although most stuff is from either the US or
Sweden).

Any thoughts on the way to go?  Really wish I had the time and disk
space to do both, but it's too much work for me to do during my "free"
time.

Ray


From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 18:33:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA21904 for xemacs-beta-people; Mon, 9 Sep 1996 18:33:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA21901 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 18:33:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA26863 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 18:33:53 -0500 (CDT)
Message-Id: <199609092333.SAA26863@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.15 beta1
Date: Mon, 09 Sep 1996 18:33:52 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/beta/xemacs-19.15.  Next release is beta2
out Sunday, September 9.

The longest break between releases has finally come to an end.  There
isn't actually much here once you get past the package updates but:

	1) As some of you have already noticed, I've been busy loading
	   up the bug database.

	2) My summer of hell is definitely over and I'm ready for some
	   serious XEmacs hacking.

I hope some of you are as well :-)  Ben is going to fix a few things
but he is having serious hand problems which are going to limit how
much he can do.  Martin is still busy at work but he is working almost
exclusively on 20.0 specific things.

A couple of administrative notes.  As I mentioned I've been busy
filling up the bug database.  If you don't see you're pet bug there
don't panic quite yet.  I still have almost 600 messages to go through
with potential additions to the database.  This damn editor is getting
way too popular.  A few patches to be applied are in the database but
for the most part I haven't bothered putting them in there.  I will
get to them for beta2.

An archive of these release note messages will soon be available at:

	http://www.xemacs.org/beta/release-notes/


			-Chuck

-- gnus 5.2.40
-- etc 0.22
-- w3 3.0.12
-- url 1.0.41
-- reporter 3.3
-- psgml 1a11
-- cc-mode 4.315
-- hm--html-menus 5.0
-- stringp nil error when starting sparcworks
-- call7 and call8 had incorrect array sizes
-- makefile mode Error in `pre-idle-hook' (setting hook to nil):
   (void-function makefile-space-face)
-- Crashes when built on X11R5 and run on X11R6 fixed
-- Lisp backtrace is now printed on all crashes, not just debug build
-- LOTS of typos fixed.
-- sunpro-init no longer opens /net/bin with possible hang at startup.
-- switch-to-buffer-other-window reverted to old-style behaviour
-- python-mode 2.67
-- auto-mode-alist regexps reorganized for efficiency
-- interpreter-mode-alist regexps now look at entire first line.
-- new (interactive) spec `i' can be used to skip arguments.
-- other assorted fixes and changes

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 18:34:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA21909 for xemacs-beta-people; Mon, 9 Sep 1996 18:34:31 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA21906 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 18:34:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA26868 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 18:34:27 -0500 (CDT)
Message-Id: <199609092334.SAA26868@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 20.0 beta28
Date: Mon, 09 Sep 1996 18:34:27 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/beta/xemacs-20.0.  Next release is
beta29 out Sunday, September 15.


			-Chuck


-- gnus 5.2.40
-- etc 0.22
-- w3 3.0.12
-- reporter 3.3
-- psgml 1a11
-- cc-mode 4.315
-- hm--html-menus 5.0
-- other assorted fixes and changes

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 18:42:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA21979 for xemacs-beta-people; Mon, 9 Sep 1996 18:42:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA21976 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 18:42:07 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA26898 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 18:42:03 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id SAA24895 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 18:41:35 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id SAA00538 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 18:41:34 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id TAA14606 for <xemacs-beta@xemacs.org>; Mon, 9 Sep 1996 19:41:53 -0400
To: xemacs-beta@xemacs.org
References: <199609051002.MAA06489@pallas.spacetec.no> 
Subject: Re: RMS' message re XEmacs 
In-reply-to: (Your message of Thu, 05 Sep 1996 12:02:18 +0200.)
             <199609051002.MAA06489@pallas.spacetec.no> 
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 09 Sep 1996 19:38:24 -0400
Message-ID: <2194.842312304@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Tor" == Tor Arntsen <tor@spacetec.no> writes:


    Tor> On Sep 4, 20:27, Richard Cognot wrote:
    >>>>>>> "John" == John Turner <turner@xdiv.lanl.gov> writes:
    John> Note that there have indeed been followups in g.m.d.  One of
    John> them, from Erik Naggum, was quite harsh toward XEmacs...
    >> 
    >> Why is it that I'm not surprised he jumped in on this discussion...

    Tor> That guy [EN] is able to poison any serious discussions about (X)Emacs, 
    Tor> the only way to deal with him is to put him firmly into all your killfiles.
    Tor> Unfortunately he can stir things up so much that a whole newsgroup can
    Tor> be made unreadable.  Too bad, wonder what bad accident made him like that.

Who knows?  But his name is really quite appropriate, don't you think?
:-)

Ray

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 19:23:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA22142 for xemacs-beta-people; Mon, 9 Sep 1996 19:23:21 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA22139 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 19:23:19 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA06805 for <xemacs-beta@cs.uiuc.edu>; Mon, 9 Sep 1996 19:23:20 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA26964; Mon, 9 Sep 1996 19:22:29 -0500 (CDT)
Message-Id: <199609100022.TAA26964@xemacs.cs.uiuc.edu>
To: Raymond Toy <toy@rtp.ericsson.se>
cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Re: Release dates for 19.15 and 20.0 and the future of each? 
In-reply-to: Your message of "Mon, 09 Sep 1996 19:35:59 EDT."
             <2188.842312159@rtp.ericsson.se> 
Date: Mon, 09 Sep 1996 19:22:27 -0500
From: Chuck Thompson <cthomp@xemacs.org>

    Raymond> I'm curious about the release dates of 19.15 and 20.0 and
    Raymond> the future of each.

    Raymond> I'm assuming that 19.xx will eventually go away in favor
    Raymond> of the 20.yy version.  Thus, if 19.15 comes out at the
    Raymond> same time as 20.0, I think I'll just go for 20.0.  20.0
    Raymond> would be nice, since we are a very international company
    Raymond> (although most stuff is from either the US or Sweden).


First, the current 19.xx version will almost certainly be 19.16 or
19.17 before 20.0 is released.  I don't anticipate a 20.0 release
until early next year.  Once 20.0 is release 19.x will go away.  The
likely scenario is to have the second to last 19.x release a couple
of months before the first 20.0 release and the final 19.x release
after 2-3 20.0 releases.  The assumption here is that the first
several 20.0 will come much closer together than is typical of XEmacs
releases and that a chunk of the fixes will be applicable to 19.x as
well.

Note that I don't expect anyone to actively test both versions (though
it's nice if you do so right before a release).  If you need the I18N
support, then go with 20.0.  Otherwise stick with 19.x for now.

For those with inquiring minds:  I'm going to try and release 19.15
before the end of October (i.e. as close to a month from now as
possible).


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 22:43:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA22746 for xemacs-beta-people; Mon, 9 Sep 1996 22:43:12 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA22743 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 22:43:11 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA12024 for <xemacs-beta@cs.uiuc.edu>; Mon, 9 Sep 1996 22:43:10 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id UAA09184; Mon, 9 Sep 1996 20:46:48 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [20.0-b28] Success Linux/ELF 2.0.18
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 09 Sep 1996 20:46:47 -0700
Message-ID: <m220gbm3q0.fsf@deanna.miranova.com>
Lines: 39
X-Mailer: Gnus v5.2.40/XEmacs 20.0

(The sure sign of beta addiction? :-)

(emacs-version)
"XEmacs 20.0 [Lucid] (i486-unknown-linux2.0.18, Mule) of Mon Sep  9 1996 on deanna.miranova.com"

Configured for `i486-unknown-linux2.0.18'.

  Where should the build process find the source code?    /i/xemacs-20.0-b28
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.



-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep  9 23:42:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA22942 for xemacs-beta-people; Mon, 9 Sep 1996 23:42:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA22939 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 9 Sep 1996 23:42:10 -0500 (CDT)
Received: from mickey.ai.kyutech.ac.jp (mickey.ai.kyutech.ac.jp [131.206.1.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA12448 for <xemacs-beta@cs.uiuc.edu>; Mon, 9 Sep 1996 23:42:05 -0500 (CDT)
Received: from localhost (localhost.mickey.ai.kyutech.ac.jp [127.0.0.1]) by mickey.ai.kyutech.ac.jp (8.6.9+2.4Wb3/3.3W9) with ESMTP id NAA09789 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 13:41:28 +0900
To: xemacs-beta@cs.uiuc.edu
Subject: [20.0-b28] success sunos 4.1.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
From: Murata Shuuichirou <mrt@mickey.ai.kyutech.ac.jp>
X-Mailer: Mew version 1.06 on Emacs 19.34.1, Mule 2.3
Message-Id: <19960910134126L/mrt@mickey.ai.kyutech.ac.jp>
Date: Tue, 10 Sep 1996 13:41:26 +0900
X-Dispatcher: impost version 0.91 (Jun 5,1996)
Lines: 35

(emacs-version)

"XEmacs 20.0 [Lucid] (sparc-sun-sunos4shr, Mule) of Tue Sep 10 1996 on mickey"

Configured for `sparc-sun-sunos4shr'.

  Where should the build process find the source code?    /tmp_mnt/yken/at_yken/xemacs-20.0-b28
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sunos4-0shr.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/local/X11R6/include
  Where do we find X Windows libraries?                   /usr/local/X11R6/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Compiling in Mule (multi-lingual) support.
  Compiling in support for Canna on Mule.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

--------
MURATA, Shuuichirou
K.I.T. Iizuka, JAPAN

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 02:49:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA23238 for xemacs-beta-people; Tue, 10 Sep 1996 02:49:58 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA23235 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 02:49:56 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA13566 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 02:49:53 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id IAA00167; Tue, 10 Sep 1996 08:49:49 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id IAA12131; Tue, 10 Sep 1996 08:51:41 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id IAA26888; Tue, 10 Sep 1996 08:56:04 +0100
Date: Tue, 10 Sep 1996 08:56:04 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199609100756.IAA26888@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu, steve@miranova.com
Subject: Re: [19.15-b1] Success on Linux/ELF 2.0.18
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: ovQeu4FeACUkvtWh/aSO3w==


> Tools for MIME :-(  Oh well, 19.16 I hope.

What is the reason that tm is not included as part of the release? I for
one have fond tm difficult to configure and a version integrated with
xemacs seems like a really good idea - especially as so many people
seem to use M$ exchange for sending mail.

andy

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 03:50:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA26804 for xemacs-beta-people; Tue, 10 Sep 1996 03:50:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA26801 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 03:50:51 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA27602 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 03:50:44 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id JAA01674 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 09:50:39 +0100
Received: from sloth.parallax.co.uk (sloth.parallax.co.uk [192.168.1.7]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id JAA13879 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 09:52:31 +0100 (BST)
Received: by sloth.parallax.co.uk (5.x/SMI-SVR4)
	id AA08712; Tue, 10 Sep 1996 09:45:43 +0100
Date: Tue, 10 Sep 1996 09:45:43 +0100
Message-Id: <9609100845.AA08712@sloth.parallax.co.uk>
From: Philip Aston <philipa@parallax.co.uk>
To: xemacs-beta@xemacs.org
Subject: Bug in VM's use of browse-url
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII



Hope this is a sensible place to post bug reports...




Bug in VM's use of browse-url

Xemacs Version 19-14

VM correctly figures out whether browse-url is set, and makes
vm-url-browser an alias if it is.

Unfortunately, it then goes and sets this to vm functions,
e.g. vm-mouse-send-url-to-netscape. This breaks browse-url.



Philip Aston
Parallax Solutions

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 04:22:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA26838 for xemacs-beta-people; Tue, 10 Sep 1996 04:22:50 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA26835 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 04:22:49 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA14379 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 04:22:44 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Tue, 10 Sep 1996 11:22:01 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id LAA20899; Tue, 10 Sep 1996 11:21:47 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id LAA17172;
          Tue, 10 Sep 1996 11:19:17 +0200
Date: Tue, 10 Sep 1996 11:19:17 +0200
Message-Id: <199609100919.LAA17172@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Installation problems
In-Reply-To: <m2u3tctf4q.fsf@deanna.miranova.com>
References: <199609051006.MAA11334@daedalus.tnt.uni-hannover.de> <m2u3tctf4q.fsf@deanna.miranova.com>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.80)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

>>>>> "Heiko" == Heiko Muenkel <muenkel@tnt.uni-hannover.de> writes:
    Heiko> During the installation of the xemacs 19.14 on a linux
    Heiko> 2.0.20 system I got the following error message:

    Steven> (AFAIK the latest version is 2.0.18, typo?)

A typo, it is 2.0.12.

    Heiko> XEmacs: Can't mmap
    Heiko> (/prog/xemacs-1/xemacs-19.14/src/xemacs):errno 12

    Heiko> It occurs during or after dumping the xemacs. Any ideas,
    Heiko> what this message want's to say?

    Steven> mmap is used by malloc on Linux, were you running out of
    Steven> swap by any chance?

Thanks, that was the reason.

-- 

Heiko Muenkel
muenkel@tnt.uni-hannover.de
<A href="http://www.tnt.uni-hannover.de/wiss/muenkel.html">M&uuml;nkel</A>
PGP-KeyID: 0x05CC063D

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 04:36:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA26989 for xemacs-beta-people; Tue, 10 Sep 1996 04:36:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA26985 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 04:36:28 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA27664; Tue, 10 Sep 1996 04:36:24 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA00088; Tue, 10 Sep 1996 02:31:49 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA04951; Tue, 10 Sep 1996 11:31:26 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/05Aug96-0532PM)
	id AA11264; Tue, 10 Sep 1996 11:31:22 +0200
Date: Tue, 10 Sep 1996 11:31:22 +0200
Message-Id: <9609100931.AA11264@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: RE: XEmacs User Survey
In-Reply-To: <199609072326.SAA16654@xemacs.cs.uiuc.edu>
References: <199609072326.SAA16654@xemacs.cs.uiuc.edu>
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

The "Where do you work?" question is ambiguous.  How about:
 - For what company/organization do you work?
and/or
 - What is your address?

If someone builds XEmacs instead of using the distributed binary, it
might be interesting to find out why.

        Steve

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 04:53:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA27044 for xemacs-beta-people; Tue, 10 Sep 1996 04:53:34 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA27041 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 04:53:33 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA27691; Tue, 10 Sep 1996 04:53:28 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Tue, 10 Sep 1996 11:52:45 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id LAA21315; Tue, 10 Sep 1996 11:52:29 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id LAA17197;
          Tue, 10 Sep 1996 11:50:00 +0200
Date: Tue, 10 Sep 1996 11:50:00 +0200
Message-Id: <199609100950.LAA17197@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
To: cthomp@xemacs.org
Cc: xemacs-beta@xemacs.org, s.kaplan@dstc.edu.au
Subject: Re: XEmacs User Survey
In-Reply-To: <199609072326.SAA16654@xemacs.cs.uiuc.edu>
References: <199609072326.SAA16654@xemacs.cs.uiuc.edu>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.80)
Content-Type: text/plain; charset=US-ASCII

I think that the possible answers to point 9 of the survey should be 
better "Never", "Sometimes" and "Allways" instead of "Yes" and "No".

-- 

Heiko Muenkel
muenkel@tnt.uni-hannover.de
<A href="http://www.tnt.uni-hannover.de/wiss/muenkel.html">M&uuml;nkel</A>
PGP-KeyID: 0x05CC063D

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 05:09:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA27134 for xemacs-beta-people; Tue, 10 Sep 1996 05:09:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA27131 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 05:09:06 -0500 (CDT)
Received: from gateway.msc.ie (root@[194.125.117.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA27715; Tue, 10 Sep 1996 05:08:46 -0500 (CDT)
Received: from decalpha.msc.ie ([194.125.117.250]) by gateway.msc.ie 
	  Sendmail (v8.7.5) with SMTP id LAA06350;
	  Tue, 10 Sep 1996 11:08:35 +0100
Received: by decalpha.msc.ie; (5.65v3.2/1.1.8.2/08Jul96-0453PM)
	id AA18237; Tue, 10 Sep 1996 11:09:23 +0100
Date: Tue, 10 Sep 1996 11:09:23 +0100
Message-Id: <9609101009.AA18237@decalpha.msc.ie>
From: Russell Ritchie <ritchier@msc.ie>
To: carney@gvc.dec.com
Cc: Chuck Thompson <cthomp@xemacs.org>, xemacs-beta@xemacs.org
Subject: RE: XEmacs User Survey
In-Reply-To: <9609100931.AA11264@fornet.gvc.dec.com>
References: <199609072326.SAA16654@xemacs.cs.uiuc.edu>
	<9609100931.AA11264@fornet.gvc.dec.com>

>>>>> "Stephen" == Stephen Carney <carney@gvc.dec.com> writes:

 Stephen> If someone builds XEmacs instead of using the distributed binary, it
 Stephen> might be interesting to find out why.

It might be worth having an "other: please give details" option on the
platforms list, in case it catches any ports that exist out there that
haven't been folded in.  We might be able get a few more binary kits that
way too.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 07:13:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA27407 for xemacs-beta-people; Tue, 10 Sep 1996 07:13:17 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA27404 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 07:13:15 -0500 (CDT)
Received: from gatekeeper.abs.alcatel.co.uk (firewall-user@gatekeeper.abs.alcatel.co.uk [194.34.58.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA27864 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 07:13:10 -0500 (CDT)
Received: from unknown(194.36.210.121) by gatekeeper.abs.alcatel.co.uk via smap (g3.0.3)
	id xma013145; Tue, 10 Sep 96 13:04:05 +0100
Received: from ariel.uk.abs by rd.abs.alcatel.co.uk  (4.1/SMI-4.1)
	id AA13196; Tue, 10 Sep 96 13:10:37 BST
Received: by ariel.uk.abs (SMI-8.6/SMI-SVR4)
	id NAA29725; Tue, 10 Sep 1996 13:10:43 +0100
Date: Tue, 10 Sep 1996 13:10:43 +0100
Message-Id: <199609101210.NAA29725@ariel.uk.abs>
From: Ian MacKinnon <imac@rd.abs.alcatel.co.uk>
To: xemacs-beta@xemacs.org
Subject: 19.15b1 OK on Solaris 2.5

Downloaded and built OK 
./configure  --site-libraries=/home/imac/lib --site-includes=/home/imac/includ
e --with-sound=both --native-sound-lib=/usr/demo/SOUND/lib/libaudio.a
All ok so far

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 07:31:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA27462 for xemacs-beta-people; Tue, 10 Sep 1996 07:31:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA27459 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 07:31:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA15544 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 07:31:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA27903; Tue, 10 Sep 1996 07:31:23 -0500 (CDT)
Message-Id: <199609101231.HAA27903@xemacs.cs.uiuc.edu>
To: andyp@parallax.co.uk (Andy Piper)
cc: xemacs-beta@cs.uiuc.edu, steve@miranova.com
Subject: Re: [19.15-b1] Success on Linux/ELF 2.0.18 
In-reply-to: Your message of "Tue, 10 Sep 1996 08:56:04 BST."
             <199609100756.IAA26888@wrath.parallax.co.uk> 
Date: Tue, 10 Sep 1996 07:31:21 -0500
From: Chuck Thompson <cthomp@xemacs.org>

    Andy> What is the reason that tm is not included as part of the
    Andy> release? I for one have fond tm difficult to configure and a
    Andy> version integrated with xemacs seems like a really good idea
    Andy> - especially as so many people seem to use M$ exchange for
    Andy> sending mail.

Hey!  This was _beta1_.  Hell, the first 19.12 releases didn't even
have the new redisplay in them.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 08:10:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA27572 for xemacs-beta-people; Tue, 10 Sep 1996 08:10:10 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA27569 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 08:10:09 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA19987 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 08:10:06 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id OAA11411; Tue, 10 Sep 1996 14:09:39 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id OAA21396; Tue, 10 Sep 1996 14:11:31 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id OAA29882; Tue, 10 Sep 1996 14:15:54 +0100
Date: Tue, 10 Sep 1996 14:15:54 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199609101315.OAA29882@wrath.parallax.co.uk>
To: cthomp@xemacs.org
Subject: Re: [19.15-b1] Success on Linux/ELF 2.0.18
Cc: xemacs-beta@cs.uiuc.edu, steve@miranova.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: XW4xr0dg7++LJHjkzOYMcA==


>     Andy> What is the reason that tm is not included as part of the
>     Andy> release? I for one have fond tm difficult to configure and a
>     Andy> version integrated with xemacs seems like a really good idea
>     Andy> - especially as so many people seem to use M$ exchange for
>     Andy> sending mail.
> 
> Hey!  This was _beta1_.  Hell, the first 19.12 releases didn't even
> have the new redisplay in them.

I should rephrase that as "Do you plan to include tm in 19.15? Please?"

I'll have to downgrade you, Chuck, from Minor Deity status :)

andy

BTW who finished off the CDE DND support - I was going to do it only
to find that it had already been completed.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 08:36:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA27702 for xemacs-beta-people; Tue, 10 Sep 1996 08:36:41 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA27699 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 08:36:40 -0500 (CDT)
Received: from omega.IntraNet.com (omega.IntraNet.com [192.148.106.20]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA00615 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 08:36:37 -0500 (CDT)
Received: by omega.IntraNet.com; (5.65/1.1.8.3/20May95-0100AM)
	id AA05117; Tue, 10 Sep 1996 09:42:19 -0400
Received: by giant.IntraNet.com (DECUS UUCP /2.0/2.0/2.0/);
          Tue, 10 Sep 96 09:18:03 EDT
Received: from blight.IntraNet.com by titan.intranet.com (MX V4.2 VAX) with
          SMTP; Tue, 10 Sep 1996 09:18:00 EDT
Received: (from edwards@localhost) by blight.IntraNet.com (AIX4.2/UCB 8.7/8.7)
          id JAA38234; Tue, 10 Sep 1996 09:17:09 -0400 (EDT)
Date: Tue, 10 Sep 1996 09:17:09 -0400 (EDT)
Message-Id: <199609101317.JAA38234@blight.IntraNet.com>
From: Jonathan Edwards <edwards@blight.IntraNet.com>
To: xemacs-beta@xemacs.org
Subject: 19.15-b1 success on AIX 4.2

Configured for `powerpc-ibm-aix4.2.0.0'.

  Where should the build process find the source code?    /usr/src/xemacs-19.15-b1
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/aix4.h' and `m/ibmrs6000.h'
  What compiler should XEmacs be built with?              cc -O3 -qarch=ppc -qtune=604
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 08:32:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA27691 for xemacs-beta-people; Tue, 10 Sep 1996 08:32:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA27688 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 08:32:47 -0500 (CDT)
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA00457 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 08:32:32 -0500 (CDT)
Received: from bilbo.ntc.nokia.com (bilbo.ntc.nokia.com [131.228.58.230]) by axl01it.ntc.nokia.com (8.6.9/8.6.9) with ESMTP id QAA02618 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 16:29:54 +0300
Received: from pippin.ntc.nokia.com (pippin.ntc.nokia.com [131.228.178.85]) by bilbo.ntc.nokia.com (8.7.5/8.7.3/Goodi) with ESMTP id QAA17889 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 16:31:59 +0300 (EET DST)
Received: (from marjola@localhost) by pippin.ntc.nokia.com (8.7.5/8.7.3/Goodi) id QAA10287; Tue, 10 Sep 1996 16:31:58 +0300 (EETDST)
Sender: marjola@bilbo.ntc.nokia.com
To: xemacs-beta@xemacs.org
Subject: [19.15-b1] Success on HP-UX 9.05
From: Pekka Marjola <pema@iki.fi>
X-Face: 8>EVnZ'MSz2dI{N`dzbBND,clpk$+(a>y[d"rnI,}HfS4x!)hp+1H&ha6Rj93tVlirvJ;Z@@MSpFN[;;X)aF\mDDlk6N&0t*B^C\]|<z,S8:j26ZbN:WmvgP-DV?l|'C<(|DacsbwYal'dmuMifMOXszyo]J:k{BSASbF-R
X-Attribution: PeMa
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 10 Sep 1996 16:31:57 +0300
Message-ID: <of0g24qa436.fsf@pippin.ntc.nokia.com>
Lines: 45


(emacs-version)
"XEmacs 19.15 [Lucid] (hppa1.1-hp-hpux9.05) of Tue Sep 10 1996 on frodo2"

When I linked it with either Xmu or Xau (don't know which, just
commented the whole directory), XEmacs dumped core when it tried to
create the initial frame. Worked OK with tty, though. Those Xmu and
Xau are from '92, so I'll propably try b2 with later versions. Anyway,
without those, no problems.

I haven't much tested other functionality yet, but b1 seems to be
working when run form HP-UX 10.01, too.


Configured for `hppa1.1-hp-hpux9.05'.

  Where should the build process find the source code?    /tmp_mnt/home/marjola/src/xemacs-19.15-b1
  What installation prefix should install use?            /net/share/contrib
  What operating system and machine description files should XEmacs use?
        `s/hpux9shr.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/include/X11R5
  Where do we find X Windows libraries?                   /usr/lib/X11R5
  Additional header files:                                /net/share/contrib/include /usr/local/include
  Additional libraries:                                   /net/share/contrib/lib /usr/local/lib
  Compiling in support for XPM.
  No Xmu; substituting equivalent routines.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


-- 
Pekka Marjola * pema@iki.fi * http://www.iki.fi/pema/ * +358-40-551 4842
PGP: 0x2865206D/C46E6452206FDB42A87D44F4E0E54E65 * GCS U+++$ L+++ E++...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Quidquid latine dictum sit, altum viditur.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 09:03:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA27779 for xemacs-beta-people; Tue, 10 Sep 1996 09:03:44 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA27776 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 09:03:43 -0500 (CDT)
Received: from chekov.ctd.comsat.com (exim@chekov.ctd.comsat.com [134.133.40.22]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA20560 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 09:03:43 -0500 (CDT)
Received: from neal by chekov.ctd.comsat.com with local (Exim 0.55 #1)
	id E0v0TPh-000456-00; Tue, 10 Sep 1996 10:03:41 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: success 19.15b1 hpux9.05 
Message-Id: <E0v0TPh-000456-00@chekov.ctd.comsat.com>
Date: Tue, 10 Sep 1996 10:03:41 -0400

Built 19.15b1 OK on hpux9.05.

I tried --run-in-place this time.  But then
/usr/local/lib/xemacs/site-lisp is not on load-path.  Why not? (that's
where I keep local stuff that stays between xemacs versions).  How to
fix?

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 09:39:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA27930 for xemacs-beta-people; Tue, 10 Sep 1996 09:39:14 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA27927 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 09:39:09 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA21041 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 09:39:09 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.55 #1)
	id E0v0Tuy-0002ek-00; Tue, 10 Sep 1996 10:36:00 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: cognot@ensg.u-nancy.fr
Cc: xemacs-beta@cs.uiuc.edu
Subject: 19.15b1 suggestions for HP.
In-Reply-To: <199609101429.JAA20898@a.cs.uiuc.edu>
References: <199609101429.JAA20898@a.cs.uiuc.edu>
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0v0Tuy-0002ek-00@neal.ctd.comsat.com>
Date: Tue, 10 Sep 1996 10:36:00 -0400

>>>>> "Richard" == Richard Cognot <cognot@ensg.u-nancy.fr> writes:

    Richard> Haven't had the time yet to compile on HP here, but I've seen the
    Richard> fixes for hpux 10 are in (namely, strcat replacement, and the use of
    Richard> -ltermcap instead of -lcurses. As far as I can tell, this fixes both
    Richard> problems #51 and #63.

    Richard> May I suggest these changes make it into the 9.x configuration files
    Richard> as well, as this basically allows for a single binary to run on both
    Richard> 9.X and 10.X systems?

Oh, I forgot.  I did the strcat patch to hpux9.h.  Please use this
patch for hpux9, at least some versions of the libc for hpux9 seem to
need this.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 09:29:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA27864 for xemacs-beta-people; Tue, 10 Sep 1996 09:29:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA27861 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 09:29:41 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA20898 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 09:29:41 -0500 (CDT)
Message-Id: <199609101429.JAA20898@a.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA264265732; Tue, 10 Sep 1996 15:28:52 +0100
Date: Tue, 10 Sep 1996 15:28:52 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@cs.uiuc.edu
Subject: 19.15b1 suggestions for HP.
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



Haven't had the time yet to compile on HP here, but I've seen the
fixes for hpux 10 are in (namely, strcat replacement, and the use of
-ltermcap instead of -lcurses. As far as I can tell, this fixes both
problems #51 and #63.

May I suggest these changes make it into the 9.x configuration files
as well, as this basically allows for a single binary to run on both
9.X and 10.X systems?

On a side note, #51 is due to a bug in HP's libxcurses in 10.10. Funny
thing is, there is a patch for this on 10.10 (PHCO_8086), but while
the bug is also there in 10.20, the patch does not apply to 10.20!
According to someone in HP, this will be fixed... in 10.30... So It's
probably a good idea not to assume this will be fixed any time soon.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 09:55:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA27997 for xemacs-beta-people; Tue, 10 Sep 1996 09:55:22 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA27994 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 09:55:21 -0500 (CDT)
Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA00861 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 09:55:12 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA16186; Tue, 10 Sep 1996 07:46:25 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA05208; Tue, 10 Sep 1996 16:46:13 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/05Aug96-0532PM)
	id AA11825; Tue, 10 Sep 1996 16:46:12 +0200
Date: Tue, 10 Sep 1996 16:46:12 +0200
Message-Id: <9609101446.AA11825@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
Reply-To: carney@gvc.dec.com
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.15-b1 build success on Digital UNIX V3.2D
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

Hardware  : DEC 3000-500
OS        : Digital UNIX V3.2D (41)
Compiler  : gcc-2.7.2
Libraries : X11R5, Motif
XEmacs    : 19.15-b1

Configured for `alpha-dec-osf3.2'.
  Where should the build process find the source code?    /kits/install/xemacs/beta
  What installation prefix should install use?            /usr/local/xemacs-beta
  What operating system and machine description files should XEmacs use?
        `s/decosf3-2.h' and `m/alpha.h'
  What compiler should XEmacs be built with?              gcc -g2 -O3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? no
  What window system should XEmacs use?                   x11
  Additional header files:                                /kits/install/jpegsrc/release 
                                                          /usr/local/include
  Additional libraries:                                   /kits/install/jpegsrc/release 
                                                          /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 10:36:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA28180 for xemacs-beta-people; Tue, 10 Sep 1996 10:36:11 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA28177 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 10:36:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA00957; Tue, 10 Sep 1996 10:36:02 -0500 (CDT)
Message-Id: <199609101536.KAA00957@xemacs.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@xemacs.org
Subject: Re: [19.15-b1] Success on Linux/ELF 2.0.18 
In-reply-to: Your message of "10 Sep 1996 08:28:58 PDT."
             <m2enka1j9h.fsf@deanna.miranova.com> 
Date: Tue, 10 Sep 1996 10:36:01 -0500
From: Chuck Thompson <cthomp@xemacs.org>

    Steven> You mean there's still hope for tm in 19.15?  This is good
    Steven> news.  :-)

Yes, there's hope.  I really hate to grow the distribution even more
without being able to provide a lite-version but tm has been so
heavily requested that I do now believe the plus of having it include
outweighs the negative of the size increase.

I suppose we could do a single "manual" lite-distribution which simply
doesn't tar up the big packages?


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 10:26:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA28122 for xemacs-beta-people; Tue, 10 Sep 1996 10:26:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA28119 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 10:26:19 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA26649 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 10:26:19 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id IAA12382; Tue, 10 Sep 1996 08:28:59 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [19.15-b1] Success on Linux/ELF 2.0.18
References: <199609101231.HAA27903@xemacs.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Tue, 10 Sep 1996 07:31:21 -0500
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 10 Sep 1996 08:28:58 -0700
Message-ID: <m2enka1j9h.fsf@deanna.miranova.com>
Lines: 20
X-Mailer: Red Gnus v0.31/XEmacs 19.15

>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

Andy> What is the reason that tm is not included as part of the
Andy> release? I for one have fond tm difficult to configure and a
Andy> version integrated with xemacs seems like a really good idea
Andy> - especially as so many people seem to use M$ exchange for
Andy> sending mail.

Chuck> Hey!  This was _beta1_.  Hell, the first 19.12 releases didn't even
Chuck> have the new redisplay in them.

You mean there's still hope for tm in 19.15?  This is good news.  :-)

It's not as if tm were a new feature -- some of us have been banging
on it for a long time.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 09:59:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA28012 for xemacs-beta-people; Tue, 10 Sep 1996 09:59:50 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA28009 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 09:59:49 -0500 (CDT)
Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA00871 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 09:59:43 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA15725; Tue, 10 Sep 1996 07:50:58 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA05221; Tue, 10 Sep 1996 16:50:49 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/05Aug96-0532PM)
	id AA11842; Tue, 10 Sep 1996 16:50:47 +0200
Date: Tue, 10 Sep 1996 16:50:47 +0200
Message-Id: <9609101450.AA11842@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: big-menubar in 15b1
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

In 15b1, loading the .el or .elc for big-menubar gives:

Signalling: (error "Attempt to modify read-only object")
  purecopy-menubar(["-------" nil nil])
  purecopy-menubar(("Tools" ["Grep..." grep t] ["Compile..." compile t] ["Shell Command..." shell-command t] ["Shell Command on Region..." shell-command-on-region (region-exists-p)] ["Debug (GDB)..." gdb t] ["Debug (DBX)..." dbx t] "-----" ("VC" :filter vc-menu-filter ["" vc-next-action buffer-file-name nil] ["Show status of" vc-file-status nil nil] "----" ["Revert to Last Revision" vc-revert-buffer vc-mode nil] ["Cancel Last Checkin" vc-cancel-version vc-mode] ["Rename File" vc-rename-this-file vc-mode nil] "----" ["Diff Against Last Version" vc-diff vc-mode] ["Diff Between Revisions..." vc-version-diff vc-mode] ["Visit Other Version..." vc-version-other-window vc-mode] ["Show Edit History" vc-print-log vc-mode] "----" ["List Locked Files Any User" vc-directory t] "----" ["Create Snapshot" vc-create-snapshot t] ["Retrieve Snapshot" vc-retrieve-snapshot t] "----" ["CVS Update Directory" cvs-update t]) ["---" nil nil] ("Compare" ["Two Files..." ediff-files t] ["Two Buffers...!
" ediff-buffers t] ["Three Files..

." ediff-files3 t] ["Three Buffers..." ediff-buffers3 t] "---" ["Two Directories..." ediff-directories t] ["Three Directories..." ediff-directories3 t] "---" ["File with Revision..." ediff-revision t] ["Directory Revisions..." ediff-directory-revisions t] "---" ["Windows Word-by-word..." ediff-windows-wordwise t] ["Windows Line-by-line..." ediff-windows-linewise t] "---" ["Regions Word-by-word..." ediff-regions-wordwise t] ["Regions Line-by-line..." ediff-regions-linewise t] "---" ["List Ediff Sessions..." ediff-show-registry t] ["Ediff Manual..." ediff-documentation t]) ("Merge" ["Files..." ediff-merge-files t] ["Files with Ancestor..." ediff-merge-files-with-ancestor t] ["Buffers..." ediff-merge-buffers t] ["Buffers with Ancestor..." ediff-merge-buffers-with-ancestor t] "---" ["Directories..." ediff-merge-directories t] ["Directories with Ancestor..." ediff-merge-directories-with-ancestor t] "---" ["Revisions..." ediff-merge-revisions t] ["Revisions with Ancestor..." ediff!
-merge-revisions-with-ancestor t] 

["Directory Revisions..." ediff-merge-directory-revisions t] ["Directory Revisions with Ancestor..." ediff-merge-directory-revisions-with-ancestor t] "---" ["List Ediff Sessions..." ediff-show-registry t] ["Ediff Manual..." ediff-documentation t]) ("Apply Patch" ["To a file..." ediff-patch-file t] ["To a buffer..." ediff-patch-buffer t] "---" ["List Ediff Sessions..." ediff-show-registry t] ["Ediff Manual..." ediff-documentation t]) ["-------" nil nil] ["OO-Browser..." oobr t] ("Tags" ["Find..." find-tag t] ["Find Other Window..." find-tag-other-window t] ["Tags Search..." tags-search t] ["Tags Replace..." tags-query-replace t] "-----" ["Continue" tags-loop-continue t] ["Pop stack" pop-tag-mark t] ["Apropos..." tags-apropos t])))
  purecopy-menubar((("File" :filter file-menu-filter ["Open..." find-file t] ["Open in Other Window..." find-file-other-window t] ["Open in New Frame..." find-file-other-frame t] ["Insert File..." insert-file t] ["View File..." view-file t] "------" ["Save" save-buffer t nil] ["Save As..." write-file t] ["Save Some Buffers" save-some-buffers t] "-----" ["Print Buffer" lpr-buffer t nil] ["Pretty-Print Buffer" ps-print-buffer-with-faces t nil] "-----" ["New Frame" make-frame t] ["Frame on Other Display..." make-frame-on-display t] ["Delete Frame" delete-frame t] "-----" ["Split Window" split-window-vertically t] ["Un-Split (Keep This)" delete-other-windows ...] ["Un-Split (Keep Others)" delete-window ...] "-----" ["Revert Buffer" revert-buffer t nil] ["Delete Buffer" kill-this-buffer t nil] "-----" ["Exit XEmacs" save-buffers-kill-emacs t]) ("Edit" :filter edit-menu-filter ["Undo" advertised-undo t] ["Cut" x-kill-primary-selection t] ["Copy" x-copy-primary-selection t] ["Paste!
" x-yank-clipboard-selection t] ["

Clear" x-delete-primary-selection t] "----" ["Search..." isearch-forward t] ["Search Backward..." isearch-backward t] ["Replace..." query-replace t] "----" ["Search (Regexp)..." isearch-forward-regexp t] ["Search Backward (Regexp)..." isearch-backward-regexp t] ["Replace (Regexp)..." query-replace-regexp t] "----" ("Bookmarks" ... ... "---" ... ... "---" ... ... ... "---" ... ... ...) "----" ["Goto Line..." goto-line t] ["What Line" what-line t] "----" "---" ("Mark" ... ... ... ... ... ... ... ... ...) "---" ("Search" ... ... "---" ... ... "---" ... ...) ("Replace" ... ... "---" ... ...) "---" ("Transpose" ... ... ... ... ... ...) "---" ("Register" ... ... "---" ... ...) ("Rectangles" ... ... ... ...) "---" ("Sort" ... ... ... ... ...) ("Center" ... ... ...) ("Indent" ... ... "---" ... ... ...) "---" ("Narrow" ... ... "---" ...)) ("Apps" ["Read Mail (VM)..." vm t] ["Read Mail (MH)..." ... t] ["Send mail..." mail t] ["Usenet News" gnus t] ["Browse the Web" w3 t] ["Gopher" gop!
her t] ["Hyperbole..." hyperbole t

] "----" ["Spell-Check Buffer" ispell-buffer t] ["Emulate VI" viper-mode t] "----" ("Calendar" ... ... ... ... ...) ("Games" ... ... ... ... ... ... ... ...)) ("Options" ["Read Only" ... :style toggle :selected buffer-read-only] ("Editing Options" ... ... ... ... ... ...) ("General Options" ... ... ...) ("Printing Options" ... ... ...) ("\"Other Window\" Location" ... ... ... ... ... ... "-----" ... ...) "-----" ("Syntax Highlighting" ... ... "-----" ... ... "-----" ... ... ... ... "-----" ... ...) ("Paren Highlighting" ... ... ... ...) "-----" ("Frame Appearance" ... ... ... ... ...) ("Menubar Appearance" ... ... ... ... "---" ... ...) ("Toolbar Appearance" ... ... ...) ("Open URLs With" ... ... ... ... ... ... ... ...) "-----" ["Edit Faces..." edit-faces t] ("Font" :filter font-menu-family-constructor) ("Size" :filter font-menu-size-constructor) ("Weight" :filter font-menu-weight-constructor) "-----" ["Save Options" save-options-menu-settings t]) ("Motion" ["Goto Mark" exc!
hange-point-and-mark ...] ["Goto L

ine..." goto-line t] "---" ["End of Balanced Parentheses ( )" forward-list t] ["Beginning of Balanced Parentheses ( )" backward-list t] ["Next Opening Parenthesis (" down-list t] ["Previous Opening Parenthesis (" backward-up-list t] ["Next Closing Parenthesis )" up-list t] "---" ["End of Balanced Expression" forward-sexp t] ["Beginning of Balanced Expression" backward-sexp t] "---" ["End of Function" end-of-defun t] ["Beginning of Function" beginning-of-defun t] "---" ["Next Page" forward-page t] ["Previous Page" backward-page t] "---" ["End of Buffer" end-of-buffer t] ["Beginning of Buffer" beginning-of-buffer t] "---" ["Save Current Position..." point-to-register t] ["Goto Saved Position..." register-to-point t] "---" ["Set Marker..." set-user-marker t] ["Goto Marker..." goto-user-marker t] ["List Markers" list-markers t] "---" ["Set Goal Column" set-goal-column t] ["Cancel Goal Column" ... goal-column]) ("Run" ["Compile..." compile t] ["Kill Compilation" kill-compilation !
t] "---" ["Next Error" next-error 

t] 
["Previous Error" previous-error t] ["Goto Error" compile-goto-error t] "---" ["GDB Debugger" gdb t]) ("Utilities" ["Shell" shell t] "---" ("Mail" ... ... ...) ["Dired..." dired t] "---" ["Grep..." grep t] ("Tags" ... "---" ... ... ... ... "---" ... ... ... "---" ... "---" ... ...) "---" ("Spell Check" ... ... ... ...) "---" ("Compare Windows" ... ...) "---" ["Hex Edit File..." hexl-find-file t]) ("Macro" ["Start Macro Recording" start-kbd-macro ...] ["End Macro Recording" end-kbd-macro defining-kbd-macro] ["Name Last Macro..." name-last-kbd-macro last-kbd-macro] ["Insert Macro in Buffer..." insert-kbd-macro t] ["Execute Last Macro" call-last-kbd-macro last-kbd-macro]) ("Buffers" :filter buffers-menu-filter ["List All Buffers" list-buffers t] "---") ("Tools" ["Grep..." grep t] ["Compile..." compile t] ["Shell Command..." shell-command t] ["Shell Command on Region..." shell-command-on-region ...] ["Debug (GDB)..." gdb t] ["Debug (DBX)..." dbx t] "-----" ("VC" :filter vc-menu-!
filter ... ... "----" ... ... ... 

"----" ... ... ... ... "----" ... "----" ... ... "----" ...) ["---" nil nil] ("Compare" ... ... ... ... "---" ... ... "---" ... ... "---" ... ... "---" ... ... "---" ... ...) ("Merge" ... ... ... ... "---" ... ... "---" ... ... ... ... "---" ... ...) ("Apply Patch" ... ... "---" ... ...) ["-------" nil nil] ["OO-Browser..." oobr t] ("Tags" ... ... ... ... "-----" ... ... ...)) nil ("Help" ["About XEmacs..." about-xemacs t] "-----" ["XEmacs WWW Page" xemacs-www-page t] ["Newest XEmacs FAQ via WWW" xemacs-www-faq t] ["XEmacs FAQ (local)" xemacs-local-faq t] ["XEmacs Tutorial" help-with-tutorial t] ["XEmacs News" view-emacs-news t] ["Sample .emacs" ... t] "-----" ["Info (Detailed Docs)" info t] ("Lookup in Info" ... ... ... ...) ["Package Browser" finder-by-keyword t] ["Describe Mode" describe-mode t] ["Apropos..." hyper-apropos t] ["Apropos Documentation..." apropos-documentation t] "-----" ["Recent Keystrokes/Messages" view-lossage t] ["Describe Key/Mouse..." describe-key t] !
["List Key Bindings" describe-bind

ings t] ["List Mouse Bindings" describe-pointer t] "-----" ["Describe Function..." describe-function t] ["Describe Variable..." describe-variable t] ["Where Is Command..." where-is t] "-----" ["Unix Manual..." manual-entry t] ("Misc" ... ... ...))))
  byte-code("@A!@B!@C!DEF\"HEI\"J\"EK\"EL\"MNOPQER\"SET\"/!UBW!" [delete-menu-item ("Edit" "Start Macro Recording") ("Edit" "End Macro Recording") ("Edit" "Execute Last Macro") purecopy-menubar assoc "File" default-menubar append "Edit" ("---" ("Mark" ... ... ... ... ... ... ... ... ...) "---" ("Search" ... ... "---" ... ... "---" ... ...) ("Replace" ... ... "---" ... ...) "---" ("Transpose" ... ... ... ... ... ...) "---" ("Register" ... ... "---" ... ...) ("Rectangles" ... ... ... ...) "---" ("Sort" ... ... ... ... ...) ("Center" ... ... ...) ("Indent" ... ... "---" ... ... ...) "---" ("Narrow" ... ... "---" ...)) "Apps" "Options" ("Motion" ["Goto Mark" exchange-point-and-mark ...] ["Goto Line..." goto-line t] "---" ["End of Balanced Parentheses ( )" forward-list t] ["Beginning of Balanced Parentheses ( )" backward-list t] ["Next Opening Parenthesis (" down-list t] ["Previous Opening Parenthesis (" backward-up-list t] ["Next Closing Parenthesis )" u!
p-list t] "---" ["End of Balanced 

Expression" forward-sexp t] ["Beginning of Balanced Expression" backward-sexp t] "---" ["End of Function" end-of-defun t] ["Beginning of Function" beginning-of-defun t] "---" ["Next Page" forward-page t] ["Previous Page" backward-page t] "---" ["End of Buffer" end-of-buffer t] ["Beginning of Buffer" beginning-of-buffer t] "---" ["Save Current Position..." point-to-register t] ["Goto Saved Position..." register-to-point t] "---" ["Set Marker..." set-user-marker t] ["Goto Marker..." goto-user-marker t] ["List Markers" list-markers t] "---" ["Set Goal Column" set-goal-column t] ["Cancel Goal Column" ... goal-column]) ("Run" ["Compile..." compile t] ["Kill Compilation" kill-compilation t] "---" ["Next Error" next-error t] ["Previous Error" previous-error t] ["Goto Error" compile-goto-error t] "---" ["GDB Debugger" gdb t]) ("Utilities" ["Shell" shell t] "---" ("Mail" ... ... ...) ["Dired..." dired t] "---" ["Grep..." grep t] ("Tags" ... "---" ... ... ... ... "---" ... ... ... "--!
-" ... "---" ... ...) "---" ("Spel

l Check" ... ... ... ...) "---" ("Compare Windows" ... ...) "---" ["Hex Edit File..." hexl-find-file t]) ("Macro" ["Start Macro Recording" start-kbd-macro ...] ["End Macro Recording" end-kbd-macro defining-kbd-macro] ["Name Last Macro..." name-last-kbd-macro last-kbd-macro] ["Insert Macro in Buffer..." insert-kbd-macro t] ["Execute Last Macro" call-last-kbd-macro last-kbd-macro]) ("Buffers" :filter buffers-menu-filter ["List All Buffers" list-buffers t] "---") "Tools" nil "Help" big-menubar current-load-list set-menubar] 15)
  load-internal("big-menubar" nil nil nil)
  load("big-menubar")
  load-library("big-menubar")
  eval((load-library "big-menubar"))
  eval-interactive((load-library "big-menubar"))
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp)


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Carney        TEL:[41](22)782.90.60  http://www-digital.cern.ch/carney/
carney@gvc.dec.com  FAX:[41](22)782.94.92 

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 10:56:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA28272 for xemacs-beta-people; Tue, 10 Sep 1996 10:56:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA28269 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 10:56:25 -0500 (CDT)
Received: from big.aa.net (root@big.aa.net [204.157.220.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA00999 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 10:56:21 -0500 (CDT)
Received: from sym.primuscorp.com ([204.137.132.34]) by big.aa.net (8.7/8.7.5) with ESMTP id IAA01397 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 08:56:22 -0700
X-Intended-For: <xemacs-beta@xemacs.org>
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id IAA19447 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 08:56:24 -0700
Received: from roy by horus (SMI-8.6/SMI-SVR4)
	id IAA21974; Tue, 10 Sep 1996 08:56:11 -0700
Received: by roy (SMI-8.6/SMI-SVR4)
	id IAA27140; Tue, 10 Sep 1996 08:56:17 -0700
Date: Tue, 10 Sep 1996 08:56:17 -0700
Message-Id: <199609101556.IAA27140@roy>
From: Damon Lipparelli <lipp@primus.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 19.15b1: success under Solaris 2.4 & 2.5.1
Reply-To: Damon Lipparelli <lipp@primus.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.15 (beta1) ]

./configure --verbose --with-gcc --with-gnu-make --site-includes=/usr/local/include --site-libraries=/usr/local/sun4/lib --prefix=/users/lipp/xemacs-beta/19.x --exec-prefix=/users/lipp/xemacs-beta/19.x/sun4 --with-dialogs=athena --with-menubars=lucid --with-scrollbars=lucid --with-xpm --with-xface --with-jpeg --with-gif --with-png --with-tooltalk --with-sparcworks --with-sound=none

Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /users/lipp/src/xemacs-beta/19.x/xemacs-19.15-b1
  What installation prefix should install use?            /users/lipp/xemacs-beta/19.x
  What operating system and machine description files should XEmacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/sun4/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in support for CDE.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

So far, so good.
-lipp

---

All I can think of is a platter of organic PRUNE CRISPS being trampled
 by an army of swarthy, Italian LOUNGE SINGERS...

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 12:26:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA28725 for xemacs-beta-people; Tue, 10 Sep 1996 12:26:06 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA28722 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 12:26:04 -0500 (CDT)
Received: from pixar.com (pixar.pixar.com [138.72.10.20]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA01179 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 12:26:00 -0500 (CDT)
Received: from zule.pixar.com (gate-zule.pixar.com) by pixar.com with SMTP id AA20411
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Tue, 10 Sep 1996 10:21:44 -0700
Received: by zule.pixar.com (Smail3.1.28.1 #12)
	id m0v0WVK-0007rOC; Tue, 10 Sep 96 10:21 PDT
Message-Id: <m0v0WVK-0007rOC@zule.pixar.com>
Date: Tue, 10 Sep 96 10:21 PDT
From: Hunter Kelly <retnuh@zule.pixar.com>
To: carney@gvc.dec.com
Cc: xemacs-beta@xemacs.org
Subject: Re: big-menubar in 15b1
In-Reply-To: <9609101450.AA11842@fornet.gvc.dec.com>
References: <9609101450.AA11842@fornet.gvc.dec.com>
Mime-Version: 1.0 (generated by tm-edit 7.82)
Content-Type: text/plain; charset=US-ASCII


I've been looking at this big (it is in the bug database, it is number
2).  I think that there may be a few different ways to fix it, but the
thing is, I don't fully understand what the _real_ problem is.  I
don't want to apply a patch that does not fully address the problem.

>From what I understand, this is caused by trying to insert a linebreak
into a menubar.  Here are two examples of code to do the insertion,
both of which cause the error:

>From vc-hooks.el, there is a line that looks like
	(add-menu-item '("Tools") "---" nil nil "Compare")

And from ediff-hook.el there are the following lines:
	(add-menu-button
	 '("Tools")
	 ["-------" nil nil] "OO-Browser...")

So, at first I thought that maybe it was because vc-hook was using
add-menu-item instead of add-menu-button.  But the same thing occurs
in ediff-hook.el as well, so that is not the problem.

Having done a little more extensive debugging, it turns out that the
error is signalled as soon as purecopy-menubar tries to do an 
aset on the vector ["---" nil nil].  Now, I am not sure why the vector
is read-only.  

Once we figure that out, it should be easy enough to come up with a
reasonable solution.

Hunter


Stephen Carney writes:
 > Date: Tue, 10 Sep 1996 16:50:47 +0200
 > To: xemacs-beta@xemacs.org
 > From: Stephen Carney <carney@gvc.dec.com>
 > Subject: big-menubar in 15b1
 > 
 > In 15b1, loading the .el or .elc for big-menubar gives:
 > 
 > Signalling: (error "Attempt to modify read-only object")
 >   purecopy-menubar(["-------" nil nil])
 >   purecopy-menubar( <default-menbar-cut-because-it-is-sooo-long> )
 >   load-internal("big-menubar" nil nil nil)
 >   load("big-menubar")
 >   load-library("big-menubar")
 >   eval((load-library "big-menubar"))
 >   eval-interactive((load-library "big-menubar"))
 >   eval-last-sexp(nil)
 >   call-interactively(eval-last-sexp)
 > 
 > 
 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 > Steve Carney        TEL:[41](22)782.90.60  http://www-digital.cern.ch/carney/
 > carney@gvc.dec.com  FAX:[41](22)782.94.92 

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 12:52:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA28832 for xemacs-beta-people; Tue, 10 Sep 1996 12:52:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA28829 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 12:52:07 -0500 (CDT)
Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA01239 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 12:52:03 -0500 (CDT)
Received: from calico.cis.ohio-state.edu (calico.cis.ohio-state.edu [164.107.142.11]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id NAA10848; Tue, 10 Sep 1996 13:51:41 -0400
Received: (ware@localhost) by calico.cis.ohio-state.edu (8.7.5/8.6.4) id NAA21966; Tue, 10 Sep 1996 13:51:41 -0400 (EDT)
To: xemacs-beta@xemacs.org
Subject: Re: tm and lite distribution
References: <199609101536.KAA00957@xemacs.cs.uiuc.edu>
From: Pete Ware <ware@cis.ohio-state.edu>
Date: 10 Sep 1996 13:51:39 -0400
In-Reply-To: Chuck Thompson's message of Tue, 10 Sep 1996 10:36:01 -0500
Message-ID: <vwmloeigswk.fsf@calico.cis.ohio-state.edu>
Lines: 4
X-Mailer: Gnus v5.2.25/XEmacs 19.14

How about doing a "lite" distribution by adding ange-ftp like
behaviour to load-path?

--pete

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 13:16:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA28922 for xemacs-beta-people; Tue, 10 Sep 1996 13:16:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA28919 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 13:16:41 -0500 (CDT)
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA01281 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 13:16:36 -0500 (CDT)
Received: from berne.ai.mit.edu by martigny.ai.mit.edu with SMTP
	(1.40.112.4/16.2) id AA012999386; Tue, 10 Sep 1996 14:16:26 -0400
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
Message-Id: <199609101816.AA012999386@martigny.ai.mit.edu>
Received: by berne.ai.mit.edu
	(1.40.112.4/16.2) id AA237069385; Tue, 10 Sep 1996 14:16:25 -0400
Date: Tue, 10 Sep 1996 14:16:25 -0400
To: ware@cis.ohio-state.edu
Cc: xemacs-beta@xemacs.org
In-Reply-To: <vwmloeigswk.fsf@calico.cis.ohio-state.edu> (message from Pete
	Ware on 10 Sep 1996 13:51:39 -0400)
Subject: autoloading over the net [was: tm and lite distribution]

  From: Pete Ware <ware@cis.ohio-state.edu>
  Date: 10 Sep 1996 13:51:39 -0400

  How about doing a "lite" distribution by adding ange-ftp like
  behaviour to load-path?

Does the autoload capability currently work transparently
for ange-ftp pathnames?  If so, this would be a nice way
of autoloading packages from their true home on the net,
thus ensuring you get the latest version. Of course you'd
probably want to cache the file locally, so that the autoload
goes over the net only if there is a newer version.

Are there already standards for autolaoding programs over
the net?  Presumably there must be some such scheme for Java
applets.

-Bill

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 14:02:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA29175 for xemacs-beta-people; Tue, 10 Sep 1996 14:02:18 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA29172 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 14:01:59 -0500 (CDT)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA01401 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 14:01:47 -0500 (CDT)
Received: from hniksic@localhost by jagor.srce.hr (8.7.5/8.6.12.CI)
	id VAA03748; Tue, 10 Sep 1996 21:01:34 +0200 (MET DST)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: Re: autoloading over the net [was: tm and lite distribution]
References: <199609101816.AA012999386@martigny.ai.mit.edu>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/geturl/geturl.tar.gz
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 10 Sep 1996 21:01:33 +0200
In-Reply-To: Bill Dubuque's message of Tue, 10 Sep 1996 14:16:25 -0400
Message-ID: <kig91ai42k2.fsf@jagor.srce.hr>
Lines: 16
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Bill Dubuque (wgd@martigny.ai.mit.edu) wrote:
> Does the autoload capability currently work transparently
> for ange-ftp pathnames?  If so, this would be a nice way
> of autoloading packages from their true home on the net,
> thus ensuring you get the latest version. Of course you'd

How would it deal with terribly slow connections, like mine? If I
understand what is being proposed, each time a package is autoloaded,
its home site would be looked up to see if there is a later
version. Such a scheme should be optional, IMO.

-- 
hniksic@srce.hr              |  Student of electrical engineering
hniksic@fly.cc.fer.hr        |  University of Zagreb, Croatia
------------------------------------------------------------------
I'm a Lisp variable -- bind me!

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 14:31:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA29320 for xemacs-beta-people; Tue, 10 Sep 1996 14:31:18 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA29317 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 14:31:16 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA25641 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 14:31:14 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id MAA15588; Tue, 10 Sep 1996 12:34:37 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: --run-in-place (was Re: success 19.15b1 hpux9.05)
References: <E0v0TPh-000456-00@chekov.ctd.comsat.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Neal Becker's message of Tue, 10 Sep 1996 10:03:41 -0400
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 10 Sep 1996 12:34:32 -0700
Message-ID: <m2wwy2yxiv.fsf@deanna.miranova.com>
Lines: 25
X-Mailer: Red Gnus v0.31/XEmacs 19.15

>>>>> "Neal" == Neal Becker <neal@ctd.comsat.com> writes:

Neal> Built 19.15b1 OK on hpux9.05.
Neal> I tried --run-in-place this time.  But then
Neal> /usr/local/lib/xemacs/site-lisp is not on load-path.  Why not? 

That's a feature.  It's actually useful when bytecompiled code is not
compatible across versions (as between 19 and 20).

Neal> (that's
Neal> where I keep local stuff that stays between xemacs versions).  How to
Neal> fix?

Is the --run-in-place necessary any more?  I've never used it, and
have run all the latest betas in place.

If you put a symbolic link to site-lisp in the top level directory of
the beta distribution, it will get added to the load-path when XEmacs
is run in place.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 14:45:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA29414 for xemacs-beta-people; Tue, 10 Sep 1996 14:45:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA29411 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 14:45:29 -0500 (CDT)
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA01510 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 14:45:27 -0500 (CDT)
Received: from berne.ai.mit.edu by martigny.ai.mit.edu with SMTP
	(1.40.112.4/16.2) id AA028764673; Tue, 10 Sep 1996 15:44:33 -0400
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
Message-Id: <199609101944.AA028764673@martigny.ai.mit.edu>
Received: by berne.ai.mit.edu
	(1.40.112.4/16.2) id AA239314665; Tue, 10 Sep 1996 15:44:25 -0400
Date: Tue, 10 Sep 1996 15:44:25 -0400
To: hniksic@srce.hr
Cc: xemacs-beta@xemacs.org, gnus-bug@ifi.uio.no
In-Reply-To: <kig91ai42k2.fsf@jagor.srce.hr> (message from Hrvoje Niksic on 10
	Sep 1996 21:01:33 +0200)
Subject: Re: autoloading over the net [was: tm and lite distribution]

  From: Hrvoje Niksic <hniksic@srce.hr>
  Date: 10 Sep 1996 21:01:33 +0200

  Bill Dubuque (wgd@martigny.ai.mit.edu) wrote:
  > Does the autoload capability currently work transparently
  > for ange-ftp pathnames?  If so, this would be a nice way
  > of autoloading packages from their true home on the net,
  > thus ensuring you get the latest version. Of course you'd

  How would it deal with terribly slow connections, like mine? If I
  understand what is being proposed, each time a package is autoloaded,
  its home site would be looked up to see if there is a later
  version. Such a scheme should be optional, IMO.

Indeed, it would be useful to have some control over update
polling, e.g. one could update only every month or so, or
en masse only when specified by the user, etc. Such functionality
is trivial to implement in e-lisp.

What would be better than polling is some way for a newsgroup or mail 
message to be able to automagically communicate that a new version 
is available, so that the next time you try to load it you get a message 
describing the new release, and a menu allowing you to download it if 
desired. It probably would be easy to add this capability to GNUS.

-Bill

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 16:11:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA29825 for xemacs-beta-people; Tue, 10 Sep 1996 16:11:06 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA29822 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 16:11:04 -0500 (CDT)
Received: from dowjones.com (firewall-user@gateway.dowjones.com [143.131.189.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA01698 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 16:11:01 -0500 (CDT)
Received: by dowjones.com; id RAA18553; Tue, 10 Sep 1996 17:12:01 -0400 (EDT)
Received: from wsj.dowjones.com(143.131.186.4) by gateway.dowjones.com via smap (V3.1.1)
	id xma018502; Tue, 10 Sep 96 17:11:54 -0400
Received: from nss_interbox.dowjones.com ([143.131.190.35]) by wsj.dowjones.com (5.x/SMI-SVR4)
	id AA28203; Tue, 10 Sep 1996 17:12:12 -0400
Message-Id: <3235E6FE.635B@nrs.dowjones.com>
Date: Tue, 10 Sep 1996 17:09:02 -0500
From: wkirk <wkirk@wsj.dowjones.com>
Organization: Dow Jones & Company, Inc.
X-Mailer: Mozilla 2.0 (Win16; U)
Mime-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: redisplay (19.14) crashes on `too-small' windows
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If window-min-height is set to 2 or lower, and a window with a modeline
and a horizontal scrollbar is created or resized to a height of 2
(meaning just the modeline and scrollbar are visible), then XEmacs
coredumps on buffer insertions (tested case was process output).  The
following patches appear to fix the problem by replacing abort()s or
assert()s with reasonable return values.  Since neither of these would
be called anyway unless things are in a wierd state, I think this can
just be added in.

(patch is against 19.14, apparently I'm behind because 19.15b1 is
already available).

*** xemacs-19.14/src/redisplay.c        Tue Jun 18 18:26:35 1996
--- xemacs-19.14-made/src/redisplay.c   Mon Sep  9 13:00:13 1996
***************
*** 6531,6537 ****
  
    start_elt = point_in_line_start_cache (w, cur_start, 0);
    if (start_elt == -1)
!     abort (); /* this had better never happen */
  
    while (1)
      {
--- 6531,6537 ----
  
    start_elt = point_in_line_start_cache (w, cur_start, 0);
    if (start_elt == -1)
!     return startp;
  
    while (1)
      {
*** xemacs-19.14/src/indent.c   Sun Apr 14 20:56:21 1996
--- xemacs-19.14-made/src/indent.c      Mon Sep  9 12:00:00 1996
***************
*** 549,554 ****
--- 549,555 ----
                                             ? -vtarget
                                             : vtarget));
  
+   if (elt<0) return orig;
    /* #### This assertion must be true before the if statements are hit
       but may possibly be wrong after the call to
       point_in_line_start_cache if orig is outside of the visible

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 17:09:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA00208 for xemacs-beta-people; Tue, 10 Sep 1996 17:09:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA00205 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 17:09:36 -0500 (CDT)
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA01770 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 17:09:31 -0500 (CDT)
Received: from harding.sde.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA041363368; Tue, 10 Sep 1996 15:09:28 -0700
Received: from harding (localhost) by harding.sde.hp.com with SMTP
	(1.39.111.2/16.2) id AA209533396; Tue, 10 Sep 1996 16:09:56 -0600
Sender: harding@sde.hp.com
Message-Id: <3235E733.1686@sde.hp.com>
Date: Tue, 10 Sep 1996 16:09:55 -0600
From: Laura Harding <harding@sde.hp.com>
Organization: Hewlett-Packard Company
X-Mailer: Mozilla 3.0b7Gold (X11; I; HP-UX B.10.10 9000/712)
Mime-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: Re: XEmacs 20.0 beta28
References: <199609092334.SAA26868@xemacs.cs.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

HP-UX 10.10 builds fine.  


Configured for `hppa1.1-hp-hpux'.

  Where should the build process find the source code?   
/users/harding/xemacs-20.0-b28
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/hpux10.h' and `m/hp800.h'
 What compiler should XEmacs be built with?             
/opt/ansic/bin/cc  -g 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?               
/usr/include/X11R5/X11
  Where do we find X Windows libraries?                   /usr/lib/X11R5
  No Xmu; substituting equivalent routines.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


laura

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 17:33:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA00308 for xemacs-beta-people; Tue, 10 Sep 1996 17:33:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA00305 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 17:33:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA03171 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 17:33:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA01810; Tue, 10 Sep 1996 17:31:26 -0500 (CDT)
Message-Id: <199609102231.RAA01810@xemacs.cs.uiuc.edu>
To: Raymond Toy <toy@rtp.ericsson.se>
cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Re: 19.15 b1 success on Solaris 2.5 
In-reply-to: Your message of "Tue, 10 Sep 1996 18:13:58 EDT."
             <16643.842393638@rtp.ericsson.se> 
Date: Tue, 10 Sep 1996 17:31:24 -0500
From: Chuck Thompson <cthomp@xemacs.org>

    Raymond> 	--site-libraries='/apps/public/solaris2.5/lib /apps/public/solaris2.4/lib'

    Raymond> I ran into one problem.  The build succeeds but at the
    Raymond> link stage, configure did not put in the necessary -R
    Raymond> commands for my site-libraries.  I need these because
    Raymond> libjpeg only exists as a shared library on my system.
    Raymond> (Forgot to build the unshared lib, I guess.)


--site-runtime-libraries, not --site-libraries, if you need the -R
flag (i.e. Solaris).


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 17:22:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA00280 for xemacs-beta-people; Tue, 10 Sep 1996 17:22:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA00277 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 17:22:28 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA03002 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 17:22:27 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id RAA27041; Tue, 10 Sep 1996 17:21:21 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id RAA16664; Tue, 10 Sep 1996 17:21:20 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id SAA29613; Tue, 10 Sep 1996 18:21:29 -0400
To: Chuck Thompson <cthomp@xemacs.org>
cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
References: <199609100022.TAA26964@xemacs.cs.uiuc.edu> 
Subject: Re: Release dates for 19.15 and 20.0 and the future of each? 
In-reply-to: (Your message of Mon, 09 Sep 1996 19:22:27 CDT.)
             <199609100022.TAA26964@xemacs.cs.uiuc.edu> 
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 10 Sep 1996 18:17:59 -0400
Message-ID: <16651.842393879@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:


    Raymond> I'm curious about the release dates of 19.15 and 20.0 and
    Raymond> the future of each.

    Chuck> First, the current 19.xx version will almost certainly be 19.16 or
    Chuck> 19.17 before 20.0 is released.  I don't anticipate a 20.0 release
    Chuck> until early next year.  Once 20.0 is release 19.x will go away.  The
    Chuck> likely scenario is to have the second to last 19.x release a couple
    Chuck> of months before the first 20.0 release and the final 19.x release
    Chuck> after 2-3 20.0 releases.  The assumption here is that the first
    Chuck> several 20.0 will come much closer together than is typical of XEmacs
    Chuck> releases and that a chunk of the fixes will be applicable to 19.x as
    Chuck> well.

That's good to know.  I'll just keep plugging away at 19.xx until the
imminient release of 20.0.  

    Chuck> Note that I don't expect anyone to actively test both versions (though
    Chuck> it's nice if you do so right before a release).  If you need the I18N
    Chuck> support, then go with 20.0.  Otherwise stick with 19.x for now.

I was at one point building both and mostly testing 20.0 when I had the time and
disk space.  Now, I'll just concentrate on 19.xx.  However, my wife
might like to read and write Korean.  Does 20.0 support Korean input
now?  (It didn't when I checked around beta8 or so.)  If so, I might
test 20.0 on my Linux box at home.

    Chuck> For those with inquiring minds:  I'm going to try and release 19.15
    Chuck> before the end of October (i.e. as close to a month from now as
    Chuck> possible).

Cool.

Ray

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 17:17:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA00230 for xemacs-beta-people; Tue, 10 Sep 1996 17:17:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA00227 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 17:17:46 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA02919 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 17:17:41 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id RAA26866 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 17:17:09 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id RAA16592 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 17:17:09 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id SAA29590 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 18:17:29 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: 19.15 b1 success on Solaris 2.5
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 10 Sep 1996 18:13:58 -0400
Message-ID: <16643.842393638@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


Grabbed the full sources via ftp (http failed for me for some reason,
saying that .../ftp-directory/ was not accessible by me).

Compiled successfully via

	../../xemacs-19.15-b1/configure  --verbose
	--prefix=/home/unix/toy/apps/XEmacs --with-sound=both
	--srcdir=../../xemacs-19.15-b1
	--site-includes='/apps/public/solaris2.5/include /apps/public/solaris2.4/include'
	--site-libraries='/apps/public/solaris2.5/lib /apps/public/solaris2.4/lib'

on Solaris 2.5, X11R6.1, nas

I ran into one problem.  The build succeeds but at the link stage,
configure did not put in the necessary -R commands for my
site-libraries.  I need these because libjpeg only exists as a shared
library on my system.  (Forgot to build the unshared lib, I guess.)

Except for this everything looks fine after 5 minutes of testing. :-)

Ray

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 17:43:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA00352 for xemacs-beta-people; Tue, 10 Sep 1996 17:43:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA00349 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 17:43:50 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA01834 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 17:43:46 -0500 (CDT)
Received: from kramer.aventail.com (root@newman [192.168.1.1]) by newman (8.6.12/8.6.9) with SMTP id PAA14307; Tue, 10 Sep 1996 15:42:00 -0700
Date: Tue, 10 Sep 1996 15:42:00 -0700
Message-Id: <199609102242.PAA14307@newman>
From: William Perry <wmperry@aventail.com>
To: Bill Dubuque <wgd@martigny.ai.mit.edu>
Cc: ware@cis.ohio-state.edu, xemacs-beta@xemacs.org
Subject: Re: autoloading over the net [was: tm and lite distribution]
In-Reply-To: <199609101816.AA012999386@martigny.ai.mit.edu>
References: <vwmloeigswk.fsf@calico.cis.ohio-state.edu>
	<199609101816.AA012999386@martigny.ai.mit.edu>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Bill Dubuque writes:
>  From: Pete Ware <ware@cis.ohio-state.edu>
>  Date: 10 Sep 1996 13:51:39 -0400
>
>  How about doing a "lite" distribution by adding ange-ftp like
>  behaviour to load-path?
>
>Does the autoload capability currently work transparently for ange-ftp
>pathnames?  If so, this would be a nice way of autoloading packages from
>their true home on the net, thus ensuring you get the latest version. Of
>course you'd probably want to cache the file locally, so that the autoload
>goes over the net only if there is a newer version.
>
>Are there already standards for autolaoding programs over the net?
>Presumably there must be some such scheme for Java applets.

  Uhhh, that would be a no. :)  Ben can probably answer better, but Java
applets you just download every time, subject of course to the standard
If-Modified-Since stuff in HTTP if you have a cached copy locally.

-Bill P.


From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 18:18:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA00462 for xemacs-beta-people; Tue, 10 Sep 1996 18:18:06 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA00459 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 18:18:05 -0500 (CDT)
Received: from pixar.com (pixar.pixar.com [138.72.10.20]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA03996 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 18:18:03 -0500 (CDT)
Received: from zule.pixar.com (gate-zule.pixar.com) by pixar.com with SMTP id AA10470
  (5.67b/IDA-1.5 for xemacs-beta@cs.uiuc.edu); Tue, 10 Sep 1996 16:17:32 -0700
Received: by zule.pixar.com (Smail3.1.28.1 #12)
	id m0v0c3f-0007rOC; Tue, 10 Sep 96 16:17 PDT
Message-Id: <m0v0c3f-0007rOC@zule.pixar.com>
Date: Tue, 10 Sep 96 16:17 PDT
From: Hunter Kelly <retnuh@zule.pixar.com>
To: Raymond Toy <toy@rtp.ericsson.se>
Cc: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: Re: 19.15 b1 success on Solaris 2.5
In-Reply-To: <16643.842393638@rtp.ericsson.se>
References: <16643.842393638@rtp.ericsson.se>
Mime-Version: 1.0 (generated by tm-edit 7.82)
Content-Type: text/plain; charset=US-ASCII

Raymond Toy writes:
 > Date: Tue, 10 Sep 1996 18:13:58 -0400
 > To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
 > From: Raymond Toy <toy@rtp.ericsson.se>
 > Subject: 19.15 b1 success on Solaris 2.5
 > 
 > 
 > Grabbed the full sources via ftp (http failed for me for some reason,
 > saying that .../ftp-directory/ was not accessible by me).
 > 

That happened to me, too.

Hunter

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 18:57:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA00591 for xemacs-beta-people; Tue, 10 Sep 1996 18:57:24 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA00588 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 18:57:23 -0500 (CDT)
Received: from big.aa.net (root@big.aa.net [204.157.220.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA01915 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 18:57:19 -0500 (CDT)
Received: from sym.primuscorp.com ([204.137.132.34]) by big.aa.net (8.7/8.7.5) with ESMTP id QAA17403 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 16:57:03 -0700
X-Intended-For: <xemacs-beta@xemacs.org>
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id QAA01546 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 16:57:36 -0700
Received: from deckard by horus (SMI-8.6/SMI-SVR4)
	id QAA01168; Tue, 10 Sep 1996 16:57:09 -0700
Received: by deckard (5.x/SMI-SVR4)
	id AA05509; Tue, 10 Sep 1996 16:57:15 -0700
Date: Tue, 10 Sep 1996 16:57:15 -0700
Message-Id: <9609102357.AA05509@deckard>
From: Damon Lipparelli <lipp@primus.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 20.0-b28: success under Solaris 2.4
Reply-To: Damon Lipparelli <lipp@primus.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.15 (beta1) ]

./configure --verbose --with-gcc --with-gnu-make --site-includes=/usr/local/include --site-libraries=/usr/local/sun4/lib --prefix=/users/lipp/xemacs-beta/20.x --exec-prefix=/users/lipp/xemacs-beta/20.x/sun4 --with-dialogs=athena --with-menubars=lucid --with-scrollbars=lucid --with-xpm --with-xface --with-jpeg --with-gif --with-png --with-tooltalk --with-sparcworks --with-sound=none --with-mule --puresize=847000

Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /users/lipp/src/xemacs-beta/20.x/xemacs-20.0-b28
  What installation prefix should install use?            /users/lipp/xemacs-beta/20.x
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/sun4/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in Mule (multi-lingual) support.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

Other than having to bump up the puresize by 5000 bytes, everything looks
fine.

-lipp

---

..  My pants just went on a wild rampage through
 a Long Island Bowling Alley!!

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 19:33:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA00747 for xemacs-beta-people; Tue, 10 Sep 1996 19:33:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA00744 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 19:33:04 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA02245 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 19:33:00 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA04903; Tue, 10 Sep 1996 17:32:01 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA01341; Tue, 10 Sep 1996 17:31:54 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA03793; Tue, 10 Sep 1996 17:31:35 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA16407; Tue, 10 Sep 1996 17:31:35 -0700
Date: Tue, 10 Sep 1996 17:31:35 -0700
Message-Id: <199609110031.RAA16407@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Ben Wing <wing@666.com>, XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: XEmacs and X11 Programming.
Reply-To: Martin Buchholz <mrb@eng.sun.com>

1. It is standard that Window manager MOVEs generate synthetic X
   events with ROOT-relative x and y coordinates, while Window manger
   RESIZEs generate real X events with PARENT-relative x and y
   coordinates.  This is documented in the ICCCM.

2. There are X functions XTranslateCoordinates and
   XtTranslateCoordinates that we should perhaps be using instead of
   x_get_top_level_shell_position.  XtTranslateCoordinates might save
   X traffic.

3. The Xt design is that the core.x and core.y values in the SHELL
   widget are used to save the root-relative position, while other
   widgets have parent-relative core.x and core.y values.  However,
   those values are not always accurate.  The documented interface is
   to use XtTranslateCoordinates instead of accessing those fields
   directly, which ensures that they are properly updated.

   If this is all correct, we can get rid of
   smash_bastardly_shell_position and x_get_top_level_shell_position.
   We would have to use stop accessing the core.x and core.y values
   directly, however.

Feedback appreciated.

Martin

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 19:35:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA00754 for xemacs-beta-people; Tue, 10 Sep 1996 19:35:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA00751 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 19:35:43 -0500 (CDT)
Received: from big.aa.net (root@big.aa.net [204.157.220.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA02252 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 19:35:36 -0500 (CDT)
Received: from sym.primuscorp.com ([204.137.132.34]) by big.aa.net (8.7/8.7.5) with ESMTP id RAA20920 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 17:35:00 -0700
X-Intended-For: <xemacs-beta@xemacs.org>
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id RAA07929 for <xemacs-beta@xemacs.org>; Tue, 10 Sep 1996 17:35:55 -0700
Received: from deckard by horus (SMI-8.6/SMI-SVR4)
	id RAA01961; Tue, 10 Sep 1996 17:35:26 -0700
Received: by deckard (5.x/SMI-SVR4)
	id AA05715; Tue, 10 Sep 1996 17:35:32 -0700
Date: Tue, 10 Sep 1996 17:35:32 -0700
Message-Id: <9609110035.AA05715@deckard>
From: Damon Lipparelli <lipp@primus.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 19.15-b1: core dump under Solaris 2.4
Reply-To: Damon Lipparelli <lipp@primus.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.15 (beta1) ]

After running fine for a while, XEmacs appeared to hang while loading a
"Makefile".  I tried "C-g" a couple of times, and eventually XEmacs died
with the appended stack trace.

Since this crash, I've been able to load the same "Makefile" fine.

-lipp

#0  0x11669c in print_internal (obj=278347780, printcharfun=278676608, 
    escapeflag=1) at print.c:949
949             if (lheader->implementation->printer)
(gdb) where
#0  0x11669c in print_internal (obj=278347780, printcharfun=278676608, 
    escapeflag=1) at print.c:949
#1  0x11656c in print_internal (obj=542924676, printcharfun=278676608, 
    escapeflag=1) at print.c:903
#2  0x11566c in Fprin1 (object=542924596, stream=272007604) at print.c:514
#3  0x88ab4 in Fbacktrace (stream=272007604, detailed=271900700) at eval.c:5038
#4  0x7d9bc in fatal_error_signal (sig=10) at emacs.c:172
#5  <signal handler called>
#6  0x11669c in print_internal (obj=278347780, printcharfun=272027904, 
    escapeflag=1) at print.c:949
#7  0x11656c in print_internal (obj=542924676, printcharfun=272027904, 
    escapeflag=1) at print.c:903
#8  0x1157d0 in Fprin1_to_string (object=542924596, noescape=271900676)
    at print.c:543
#9  0x854f8 in primitive_funcall (fn=0x115688 <Fprin1_to_string>, nargs=2, 
    args=0xefffccd0) at eval.c:3486
#10 0x85668 in funcall_subr (subr=0x2561f8, args=0xefffccd0) at eval.c:3526
#11 0x849c8 in funcall_recording_as (recorded_as=270885368, nargs=1, 
    args=0xefffcdf0) at eval.c:3204
#12 0x84b10 in Ffuncall (nargs=2, args=0xefffcdf0) at eval.c:3253
#13 0x56acc in Fbyte_code (bytestr=808110320, vector=1076545808, 
    maxdepth=2803969) at bytecode.c:450
#14 0x85510 in primitive_funcall (fn=0x563a4 <Fbyte_code>, nargs=3, 
    args=0xefffd078) at eval.c:3488
#15 0x85668 in funcall_subr (subr=0x250508, args=0xefffd078) at eval.c:3526
#16 0x84534 in Feval (form=539674848) at eval.c:3064
#17 0x805a0 in Fprogn (args=539674840) at eval.c:746
#18 0x81c78 in run_condition_case_handlers (val=542920884, var=272564468)
    at eval.c:1708
#19 0x81b6c in condition_case_1 (handlers=539674824, bfun=0x83ce4 <Feval>, 
    barg=539674760, hfun=0x81c38 <run_condition_case_handlers>, harg=272564468)
    at eval.c:1655
#20 0x81e38 in Fcondition_case_3 (bodyform=539674760, var=272564468, 
    handlers=539674824) at eval.c:1735
#21 0x56f78 in Fbyte_code (bytestr=808110144, vector=1076545636, 
    maxdepth=2803801) at bytecode.c:655
#22 0x85b40 in funcall_lambda (fun=271239724, nargs=1, arg_vector=0xefffd6ac)
    at eval.c:3636
#23 0x84ab8 in funcall_recording_as (recorded_as=271239724, nargs=1, 
    args=0xefffd6a8) at eval.c:3223
#24 0x84b10 in Ffuncall (nargs=2, args=0xefffd6a8) at eval.c:3253
#25 0x56acc in Fbyte_code (bytestr=808109400, vector=1076545028, 
    maxdepth=2803198) at bytecode.c:450
#26 0x85b40 in funcall_lambda (fun=271239120, nargs=2, arg_vector=0xefffd96c)
    at eval.c:3636
#27 0x84ab8 in funcall_recording_as (recorded_as=271239120, nargs=2, 
    args=0xefffd968) at eval.c:3223
#28 0x84b10 in Ffuncall (nargs=3, args=0xefffd968) at eval.c:3253
#29 0x56acc in Fbyte_code (bytestr=808107932, vector=1076543716, 
    maxdepth=2801885) at bytecode.c:450
#30 0x85b40 in funcall_lambda (fun=271238204, nargs=1, arg_vector=0xefffdc30)
    at eval.c:3636
#31 0x84ab8 in funcall_recording_as (recorded_as=271238204, nargs=1, 
    args=0xefffdc2c) at eval.c:3223
#32 0x84b10 in Ffuncall (nargs=2, args=0xefffdc2c) at eval.c:3253
#33 0x56acc in Fbyte_code (bytestr=808104352, vector=1076539856, 
    maxdepth=2798000) at bytecode.c:450
#34 0x85b40 in funcall_lambda (fun=271233504, nargs=1, arg_vector=0xefffdedc)
    at eval.c:3636
#35 0x84ab8 in funcall_recording_as (recorded_as=271233504, nargs=1, 
    args=0xefffded8) at eval.c:3223
#36 0x84b10 in Ffuncall (nargs=2, args=0xefffded8) at eval.c:3253
#37 0x56acc in Fbyte_code (bytestr=810994424, vector=1077487952, 
    maxdepth=5517919) at bytecode.c:450
#38 0x85b40 in funcall_lambda (fun=274121252, nargs=1, arg_vector=0xefffe18c)
    at eval.c:3636
#39 0x84ab8 in funcall_recording_as (recorded_as=274121252, nargs=1, 
    args=0xefffe188) at eval.c:3223
#40 0x84b10 in Ffuncall (nargs=2, args=0xefffe188) at eval.c:3253
#41 0x56acc in Fbyte_code (bytestr=813802232, vector=1078893824, 
    maxdepth=10433696) at bytecode.c:450
#42 0x85b40 in funcall_lambda (fun=278832228, nargs=0, arg_vector=0xefffe4a8)
    at eval.c:3636
#43 0x84ab8 in funcall_recording_as (recorded_as=278832228, nargs=0, 
    args=0xefffe4a4) at eval.c:3223
#44 0x84b10 in Ffuncall (nargs=1, args=0xefffe4a4) at eval.c:3253
#45 0x86468 in apply1 (fn=278832228, arg=271900676) at eval.c:3963
#46 0x58d9c in Fcall_interactively (function=278397220, record_flag=271900676, 
    keys=271900676) at callint.c:390
#47 0x8347c in Fcommand_execute (cmd=278397220, record=271900676, 
    keys=271900676) at eval.c:2628
#48 0x9bb60 in execute_command_event (command_builder=0x391b40, 
    event=274819772) at event-stream.c:3474
#49 0x9cd7c in Fdispatch_event (event=274819772) at event-stream.c:3768
#50 0x5e508 in Fcommand_loop_1 () at cmdloop.c:542
#51 0x5e158 in command_loop_1 (dummy=271900676) at cmdloop.c:462
#52 0x81bcc in condition_case_1 (handlers=271900772, 
    bfun=0x5e0b4 <command_loop_1>, barg=271900676, hfun=0x5d250 <cmd_error>, 
    harg=271900676) at eval.c:1672
#53 0x5d350 in command_loop_3 () at cmdloop.c:224
#54 0x5d378 in command_loop_2 (dummy=271900676) at cmdloop.c:235
#55 0x816ec in internal_catch (tag=271977892, func=0x5d36c <command_loop_2>, 
#56 0x5d80c in initial_command_loop (load_me=381804) at cmdloop.c:273
#57 0x7e9d0 in main_1 (argc=1, argv=0xefffecb4, envp=0xefffecbc)
    at emacs.c:1315
#58 0x7edec in main (argc=1, argv=0xefffecb4, envp=0xefffecbc) at emacs.c:1459

---

Toes, knees, NIPPLES.  Toes, knees, nipples, KNUCKLES...
 Nipples, dimples, knuckles, NICKLES, wrinkles, pimples!!
 I don't like FRANK SINATRA or his CHILDREN.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 20:15:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA00851 for xemacs-beta-people; Tue, 10 Sep 1996 20:15:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA00848 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 20:15:48 -0500 (CDT)
Received: from deanna.miranova.com (deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA12058 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 20:15:33 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id SAA20810; Tue, 10 Sep 1996 18:18:35 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: psgml-1a11 -> psgml-1a12 [Part 2 of 2]
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 10 Sep 1996 18:18:34 -0700
Message-ID: <m2sp8p26j9.fsf@deanna.miranova.com>
Lines: 88
X-Mailer: Red Gnus v0.32/XEmacs 19.15

This patch is for sync'ing the psgml documentation to 1.0a12.

diff -u --recursive --new-file psgml-1a11/psgml.texi psgml-1a12/psgml.texi
--- psgml-1a11/psgml.texi	Mon May 20 14:45:30 1996
+++ psgml-1a12/psgml.texi	Sat Aug 31 18:41:27 1996
@@ -7,7 +7,7 @@
 @syncodeindex vr cp
 @synindex ky cp
 @c %**end of header
-@c $Id: psgml.texi,v 2.7 1996/05/20 21:32:56 lenst Exp $
+@c $Id: psgml.texi,v 2.8 1996/09/01 01:20:46 lenst Exp $
 
 @ifinfo
 @format
@@ -195,18 +195,32 @@
 @comment  node-name,  next,  previous,  up
 @chapter Installing PSGML
 
+To install PSGML you first need to uncompress and unpack the source
+archive.  This is done with the @code{gunzip} and @code{tar} commands.
+
+@example
+gunzip psgml-1.0a12.tar.gz; tar xf psgml-1.0a12.tar
+@end example
+
+This should create a subdirectory to the current directory with the
+source code. This directory contains a @code{configure} command (see the
+file INSTALL for more information about configure).  You can use the
+@code{configure} command to configure the package or you can load the
+file @file{psgml-maint} and execute the @code{psgml-compile-files}
+command.
+
 Place the @file{*.el} and the @file{*.elc} files in a directory where
 Emacs can find it (i.e. one of the directories in the @code{load-path}
 variable, you can add a directory to this variable in your
-@file{.emacs}.)  If you obtained PSGML without @file{*.elc} files, you
-can create them by letting Emacs byte compile the @file{*.el} files (use
-@kbd{M-x byte-compile-file}).  Parsing SGML in Emacs Lisp is slow and
-needs all the speed it can get.  If you are using Emacs you need not
-compile @file{psgml-lucid.el}, it will probably not compile.  If you are
-using XEmacs you should not compile @file{psgml-other.el} but compile
-@file{psgml-lucid.el}.
+@file{.emacs}.)  
+
+If you use the @code{configure} approach, compile psgml with @code{make}
+and the you can run @code{make install} to install it in the system
+library @file{site-lisp}.  The files are installed in a subdirectory
+named @file{psgml}.  The location of @file{site-lisp} is figured out by
+@code{configure}, but you can change it in the @file{Makefile}.  You
+need to make sure that this subdirectory is in Emacs @code{load-path}.
 
-@c *** describe configure
 
 Put the following line in your .emacs:
 
@@ -376,10 +390,13 @@
 @samp{%C}, and public text description for @samp{%D}.  The text class
 will be converted to lower case and the owner and description will be
 transliterated according to the variable
-@code{sgml-public-transliterations}.  (*** there are more substitution
-characters: %%, %N, %P, %S, %Y, %C, %L, %O, %T, %V).
-The templates in the list is tried
-in order until an existing file is found.
+@code{sgml-public-transliterations}.  The templates in the list is tried
+in order until an existing file is found.  The @code{sgml-public-map} is
+modeled after @file{sgmls} environment variable @code{SGML_PATH} and
+psgml understand the following substitution characters: %%, %N, %P, %S,
+%Y, %C, %L, %O, %T, and %V.  The the default value of
+@code{sgml-public-map} is taken from the environment variable
+@code{SGML_PATH}.
 
 Given the public identifier above and the file name template 
 @samp{/usr/local/lib/sgml/%o/%c/%d}, the resulting file name is
@@ -478,7 +495,7 @@
 means the file containing the DOCTYPE declaration, if not in the buffer 
 @end table
 
-The default value is @code{sgml -s %s %s}.
+The default value is @code{nsgmls -s %s %s}.
 @end defopt
 
 @defopt sgml-validate-files

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 21:00:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA01071 for xemacs-beta-people; Tue, 10 Sep 1996 21:00:02 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA01068 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 21:00:01 -0500 (CDT)
Received: from beavis.bayserve.net (jmiller@port53.bayserve.net [206.148.244.151]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA12509 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 20:59:59 -0500 (CDT)
Received: (from jmiller@localhost) by beavis.bayserve.net (8.7.5/8.7.3) id WAA16029; Tue, 10 Sep 1996 22:11:26 -0400
Date: Tue, 10 Sep 1996 22:11:26 -0400
Message-Id: <199609110211.WAA16029@beavis.bayserve.net>
From: jmiller@bayserve.net
To: xemacs-beta@cs.uiuc.edu
Subject: [19.15b1] Success Linux/ELF 2.0.16 *
Reply-to: jmiller@bayserve.net
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII

* Note: This is on a Slackware 3.1 installation. I believe the initial
  problems I had were not XEmacs related.  

  1) ndbm.h was not installed but libgdbm.a was.  
  2) The jpeg functions used by XEmacs do not seem to like the libjpeg
     that comes with Slackware 3.1 (& 3.0 for that matter).  

  Fortunately I still had the libjpeg from the XEmacs aux dir.  I also
  copied over the ndbm.h from my old 3.0 installation.  Once I got these 2
  things straightened out, compilation was fine.

Configured for `i486-unknown-linux2.0.16'.

  Where should the build process find the source code?    /home/jmiller/source/xemacs-19.15-b1
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

So far, so good.  :)

-----------------------------------------------------------------------------
Jeff Miller
jmiller@bayserve.net
-----------------------------------------------------------------------------

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 20:12:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA00842 for xemacs-beta-people; Tue, 10 Sep 1996 20:12:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA00839 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 20:12:39 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA12030 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 20:12:11 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id SAA20714; Tue, 10 Sep 1996 18:15:43 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: psgml-1a11 -> psgml-1a12 [Part 1 of 2]
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 10 Sep 1996 18:15:42 -0700
Message-ID: <m2vidl26o1.fsf@deanna.miranova.com>
Lines: 1472
X-Mailer: Red Gnus v0.32/XEmacs 19.15

This is a sync-up patch to psgml to version 1.0a12.  A patch to the
documentation follows in part 2.

The patch looks much larger than it really is.  It removes
nefarious.el and about 30k of ChangeLog entries.  It does *not* appear
to fix the problems dealing with html-cougar :-(.

diff -c --recursive --new-file psgml-1a11/ChangeLog psgml-1a12/ChangeLog
*** psgml-1a11/ChangeLog	Sun Sep  8 16:55:15 1996
--- psgml-1a12/ChangeLog	Tue Sep 10 17:50:32 1996
***************
*** 1,3 ****
--- 1,7 ----
+ Tue Sep 10 17:52:40 1996  Steven L Baur  <steve@miranova.com>
+ 
+ 	* Various files: Sync'ed with 1.0a12
+ 
  Fri Jul 12 18:20:07 1996  Steven L Baur  <steve@miranova.com>
  
  	* Various files: Sync'ed up to Wingpsgml
***************
*** 10,15 ****
--- 14,46 ----
  	keywords.
  	
  
+ Sun Sep  1 01:53:33 1996  Lennart Staflin  <lenst@lysator.liu.se>
+ 
+ 	* Version 1.0a12
+ 
+ 	* psgml-maint.el: new file. Used to compile psgml.
+ 
+ Tue Aug 20 23:11:30 1996  Lennart Staflin  <lenst@lysator.liu.se>
+ 
+ 	* psgml.el:
+ 	(sgml-validate-error-regexps): Fixes from Dave Love <d.love@dl.ac.uk>
+ 	and David Megginson <dmeggins@uottawa.ca> for use with nsgmls.
+ 	(sgml-validate-command): changed default validate command to use
+ 	nsgmls.
+ 	
+ Sun Aug 11 19:21:56 1996  Lennart Staflin  <lenst@lysator.liu.se>
+ 
+ 	* iso88591.map: added code to character mappings.
+ 
+ Thu Jun 13 20:43:53 1996  Lennart Staflin  <lenst@lysator.liu.se>
+ 
+ 	* psgml-parse.el (sgml-get-and-move): use sgml-final, not
+ 	sgml-state-final-p. In this case the substate can be an AND-state.
+ 
+ Tue May 21 07:39:34 1996  Lennart Staflin  <lenst@lysator.liu.se>
+ 
+ 	* Version 1.0a11 released.
+ 
  Mon May 20 23:14:02 1996  Lennart Staflin  <lenst@lysator.liu.se>
  
  	* psgml.el (psgml-version): bump version.
***************
*** 845,1691 ****
  	* psgml-parse.el (sgml-next-data-field): stop any where but avoid
  	current element (previously only stopped at the beginning of an
  	element)
- 
- Mon Jul  4 00:27:06 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* Version 0.4 beta
- 
- 	* psgml-parse.el (sgml-show-context): Don't trust sgml-markup-type
- 	if explicit element is given as argument
- 
- 	* psgml.el (sgml-submit-bug-report): add some variables.
- 	(psgml-version): set version 0.4b
- 
- Wed Jun 15 16:50:44 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-validate-command): fix typo
- 
- 	* psgml-parse.el (sgml-find-attribute-element): use primitive
- 	sgml-parse-to instead of sgml-parse-to-here.
- 	(sgml-load-dtd): Install patch to search for file in
- 	sgml-system-path.  Make sure current directory is searched first
- 	and the file name is expanded.
- 
- Thu Jun  9 23:28:48 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-attrib-menu): Fix bug when no non-tokenlist
- 	attributes. 
- 	(sgml-tags-menu): use sgml-markup-type to check for start tag not
- 	sgml-current-state
- 
- Wed Jun  8 20:47:47 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* Version 0.4a4
- 
- 	* psgml-parse.el (sgml-need-dtd): Do all that is needed to set up
- 	a dtd, don't call parse.  Break loop if a sgml-parent-document
- 	points to the current file.
- 	(sgml-parse-to): call sgml-need-dtd
- 
- Tue Jun  7 12:44:54 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el: fixing some typos
- 
- 	* psgml-parse.el (sgml-last-element): set markup-type to nil,
- 	unless actually parsing.
- 	(sgml-find-context-of): set sgml-markup-type to nil if pos not in
- 	the markup.  Don't set sgml-current-state to markup type.
- 	(sgml-show-context): Display markup type also
- 
- Mon Jun  6 18:38:58 1994  Lennart Staflin  (lenst@konrad)
- 
- 	* psgml-parse.el (sgml-non-fixed-attributes): new func.
- 	(sgml-insert-attribute): use new func.
- 	(sgml-attrib-menu): use new func.
- 	(sgml-attrib-menu): Include #IMPLIED in menus for token types
- 	(sgml-insert-attribute): accept nil as value
- 
- Tue May 24 01:23:33 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-fold-region): set inhibit-read-only to t.
- 
- Sun May 22 22:44:33 1994  Lennart Staflin  (lenst@kajsa)
- 
- 	* psgml-parse.el (sgml-make-character-reference): fix typo.
- 	(sgml-insert-attribute): save-execursion around
- 	sgml-change-star-tag.
- 
- Sun May 22 03:07:42 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el: 
- 	(sgml-validate-error-regexps): new variable
- 	(sgml-validate): use it.
- 
- Sat May 21 03:00:02 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-buggy-subst-char-in-region): only set it by
- 	default in pre 19.23 emacs.
- 	(sgml-system-path): fixed typo.
- 
- Fri May 20 04:32:56 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-hide-region): undo intangible setting,
- 	confuses the parser.
- 
- Fri May 20 00:25:36 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml-parse.el (sgml-operate-on-tags): remove intangible property
- 	(sgml-hide-region): make hidden text intangible
- 
- 	* psgml-other.el: Remove short-cuts from the menus.
- 	(sgml-write-protect-intagible): new var.
- 	(sgml-insert): add a read-onlyt t if intangible and
- 	sgml-write-protect-intagible is t.
- 
- Wed May 18 03:47:27 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-mode-map): bind C-c + to sgml-insert-attribute
- 
- Tue May 17 22:49:57 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* nefarious.el: change to work with new name for element type data
- 	type.
- 
- Mon May 16 19:56:27 1994  Lennart Staflin  (lenst@astrid)
- 
- 	* psgml-parse.el (sgml-load-dtd): error if file does not exist
- 	(sgml-insert-tag): use sgml-element-data-p
- 	(sgml-skip-tag): new function.
- 	(sgml-kill-markup): use sgml-skip-tag
- 	(sgml-last-element): new function
- 	(sgml-normalize-content): use only integers
- 
- Thu May 12 02:31:07 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-find-attribute-element): use element after
- 	cursor if not after start-tag.
- 	(sgml-menu-ask): Capitalize title
- 
- Sun May  8 01:18:09 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el: ci 1.48
- 
- 	* psgml-dtd.el: ci 1.15
- 
- 	* psgml-parse.el: 
- 	change element structure to sgml-eltype
- 	(sgml-element-etag-optional): make macro
- 	(sgml-element-stag-optional): make macro
- 
- 	* psgml-dtd.el:
- 	change element structure to sgml-eltype
- 
- 	* psgml-parse.el: ci 1.47
- 	* psgml-dtd.el: ci 1.14
- 
- 	* psgml-parse.el (sgml-normalize-start-tag): use
- 	sgml-change-start-tag 
- 	(sgml-make-character-reference): new command
- 
- 	* psgml-dtd.el (sgml-parse-minimum-literal and
- 	sgml-parse-external):  moved from psgml-parse.
- 
- 	* psgml-parse.el (sgml-split-element): New command
- 
- Sat May  7 17:41:22 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-options-menu): uses sgml-user-options in a
- 	general way.
- 	(sgml-insert-start-tag): new function
- 	(sgml-change-start-tag): new function
- 	(sgml-find-attribute-element): new function
- 	(sgml-attrib-menu): new function
- 	(sgml-tags-menu): pop up a attribute menu if called when point is
- 	inside a start-tag.
- 	(sgml-element-attval): new function.
- 	(sgml-set-live-element-indicator): bind deactivate-mark.
- 
- 	* psgml.el (sgml-variable-description): new function
- 	(sgml-variable-type): new function
- 	(sgml-save-options): use sgml-user-options
- 
- 	* psgml-parse.el (sgml-find-context-of): don't change point.
- 
- Sat May  7 00:24:32 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml-parse.el (sgml-set-parse-state): fix bug that that set
- 	markup type of start tag for empty element to end-tag.
- 
- Fri May  6 22:06:52 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml-parse.el (sgml-parse-minimum-literal): New function
- 	(sgml-parse-external): use parse-minimum-literal for public
- 	identifier.
- 	(sgml-formal-pubid-regexp): simplify, now that
- 	parse-minimum-literal does the right thing.
- 
- 	* psgml-dtd.el (sgml-parse-cro): new function
- 	(sgml-parse-character-reference): new function
- 	(sgml-parse-parameter-literal): recognize character references
- 
- Thu May  5 23:01:17 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml-parse.el (sgml-pubid-parts): %% => %
- 
- Mon May  2 21:30:25 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml-parse.el (sgml-find-previous-element): takes optional
- 	argument: IN-ELEMENT, the enclosing element.
- 	(sgml-backward-element): use sgml-last-element
- 	(sgml-find-element-after): take IN-ELEMENT argument
- 	(sgml-backward-element): use sgml-last-element
- 	(sgml-beginning-of-element): use sgml-last-element
- 	(sgml-end-of-element): use sgml-last-element
- 	(sgml-down-element): use sgml-last-element
- 	(sgml-users-of-last-element): add new commancds
- 
- Thu Apr 28 05:59:13 1994  Lennart Staflin  (lenst@rune)
- 
- 	* psgml-lucid.el 
- 	installing patch from Bill P.
- 
- Thu Apr 28 05:11:08 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-mode): fix paragraph regexps.
- 
- Sun Apr 24 02:00:02 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el: ci 1.46
- 
- 	* psgml-other.el: ci 1.6
- 
- 	* psgml-lucid.el: ci 1.7
- 
- 	* psgml-parse.el (sgml-set-live-element-indicator): new format for
- 	sgml-active-dtd-indicator. 
- 	(sgml-options-menu): add a force-mode-line-update.
- 
- 	* psgml-lucid.el (sgml-build-custom-menus): quote arguments to
- 	sgml-doctype-insert. 
- 
- 	* psgml-parse.el (sgml-doctype-insert): insert doctype on empty line.
- 
- 	* psgml-other.el (sgml-build-custom-menus): quote arguments to
- 	sgml-doctype-insert.
- 
- 	* psgml-parse.el (sgml-options-menu): add
- 	sgml-live-element-indicator.
- 
- 	* psgml-lucid.el: installing patch from bill p.
- 	fixing face setting code
- 
- 	* psgml-parse.el (sgml-fold-region): bind after-change-hook to
- 	nil.
- 	Move face setting to emacs specific file.
- 	Move sgml-insert to emacs specific file.
- 
- Sat Apr 23 00:51:10 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el: 
- 	(sgml-set-parse-state): don't set markup-type to start-tag if
- 	element has empty start-tag.
- 	(sgml-fold-element): generalize to markup declaration outside the
- 	document element.
- 	(sgml-last-element): new variable.
- 	(sgml-users-of-last-element): new variable.
- 	(sgml-set-live-element-indicator): use sgml-last-element if the
- 	command is one of sgml-users-of-last-element.
- 	(sgml-backward-up-element): set and use sgml-last-element.
- 	(sgml-up-element): dito.
- 
- 	* psgml-parse.el: ci 1.45
- 	Changing to use overlays for setting face.
- 	(sgml-set-face-after-change): use overlay
- 	(sgml-set-face-for): use overlay
- 	(sgml-clear-faces): new command.
- 	(sgml-parse-to and sgml-next-trouble-spot): undo changes in 1.44
- 
- 	* psgml-dtd.el: ci 1.13
- 
- 	* psgml-parse.el  (ci v 1.44)
-         (sgml-set-face-for): set face of region.
- 	(sgml-set-face-after-change): remove face prop.
- 	(sgml-set-doctype): set after-change-function.
- 	(sgml-parse-to): restore buffer modification status after parse,
- 	in case face changes has modified buffer.
- 	(sgml-parser-loop): call sgml-set-face-for.
- 	(sgml-next-trouble-spot): clear faces with sgml-set-face-after-change.
- 	
- 
- Fri Apr 22 03:32:37 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-dtd.el (sgml-parse-parameter-literal): fix bug: should not
- 	recognize delimiter inside parameter reference.
- 
- Thu Apr 21 18:42:14 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-operate-on-tags): replaces
- 	sgml-identify-attributes.
- 	(sgml-hide-region): new function.
- 	(sgml-hide-tags): new command.
- 	(sgml-show-tags): new command.
- 	(sgml-parse-to): add-hook to pre-command-hook, no longer
- 	buffer-local.
- 	(sgml-set-live-element-indicator): new function.
- 	(sgml-set-active-dtd-indicator): new function.
- 
- 	* psgml.el (sgml-mode-map): C-M-h sgml-mark-current-element
- 
- 	* psgml-parse.el (sgml-mark-element): Only set mark after next
- 	element.
- 	(sgml-kill-element): Kill from point to after next element.
- 	(sgml-find-element-after): rewritten.
- 	(sgml-mark-current-element): new command.
- 
- Sun Apr 17 02:35:56 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml-parse.el (sgml-element-attribute-specification-end): new
- 	function. 
- 
- Sat Apr 16 00:59:14 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-is-goal-after-start): undoes change done
- 	apr 13 for no start-tag.
- 	(sgml-note-change-at): Prune element with no start-tag if changed
- 	before first content element.
- 
- Thu Apr 14 00:30:47 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-open-element): fixed bug. If new element
- 	should replace first element in current tree.
- 
- 
- Wed Apr 13 20:09:05 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-doctype-insert): allow setting any variable.
- 	(sgml-find-start-point): set parse state to start of element
- 	content only if element has a start tag and point is after.
- 
- 	* psgml.el (sgml-set-local-variable): Also set buffer local variable.
- 	(psgml-version): bump version.
- 
- 	* psgml-parse.el: move debugging code to psgml-debug.el.
- 	(sgml-insert-tag): change white-space fixing.
- 	(sgml-insert-element): let sgml-insert-tag insert a newline after
- 	the start-tag.
- 
- Tue Apr 12 02:16:42 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-print-valid-tags): new function.
- 	(sgml-print-list-of-tags): new function.
- 	(sgml-list-valid-tags): Better display.
- 
- Mon Apr 11 00:42:34 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-normalize-start-tag): leave cursor before
- 	inserted tag
- 	(sgml-normalize-end-tag): dito.
- 	(sgml-is-enabled-net): new function.
- 	(sgml-skip-cdata): check for NET.
- 	(sgml-parser-loop): check for NET when (R)CDATA.
- 
- Sat Apr  9 16:16:59 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-edit-attrib-specification-list): fix
- 	skipping to next attribute
- 	(sgml-quote-attribute-value): Anchor regexp at buffer limits
- 	instead of line.
- 
- 	* psgml-dtd.el (sgml-check-model-group): set mixed flag when
- 	parsing a data tag group.
- 	(sgml-check-model-group): add a skip-ts
- 
- 	* psgml-parse.el (sgml-do-pcdata): Force instances of #PCDATA
- 	token be #PCDATA*.
- 	(sgml-parse-start-tag): remove exludes from includes.
- 
- Fri Apr  1 00:01:47 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-parse-start-tag): Let exclusions modify
- 	acceptance of tokens in the model rather the give a error.
- 
- Mon Mar 28 01:16:23 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-untag-element): new command.
- 	(sgml-kill-markup): new command.
- 	(sgml-change-element-name): now translates the attribute list.
- 	(sgml-translate-attribute-specification-list): new function.
- 	(sgml-attribute-with-declared-value): new function.
- 
- 	* psgml-dtd.el: Now recognises shortref and usemap.
- 	Cleaning up how declarations are handled.
- 	Changing some names.
- 
- 	* psgml-parse.el (sgml-list-valid-tags): Be more informative.
- 	(sgml-normalize-content): Factor out tag normalizing.
- 	(sgml-normalize-start-tag): New function. Insert new attspec.
- 	(sgml-normalize-end-tag): New function.
- 	(sgml-check-marked-section): changed name from ..parse..
- 	(sgml-check-attribute-value-specification): new name.
- 
- Sun Mar 27 00:18:43 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-normalize-content): fix bug in closing
- 	unclosed tag.
- 	(sgml-pubid-parts): New part %P, whole pubid.
- 	sgml-tree: net-enabled is t if for current element, non-nil if for
- 	some parent element.  Constructor now has net-enabled as argument.
- 	Changed some functions to support new defintion.
- 	(sgml-load-dtd): don't save expanded file name in
- 	sgml-default-dtd-file. 
- 	(sgml-setup-dtd): Don't check if default-dtd-file exists.  Let
- 	load-dtd give error if it don't.
- 	(sgml-set-doctype): set sgml-activce-dtd-indicator
- 
- 	* psgml-dtd.el (sgml-check-model-group): Changed name from
- 	sgml-parse-mode-group.  Now handles data tag groups.
- 	(sgml-check-data-tag-pattern): new function.
- 
- 	* psgml-parse.el: Remove sgml-reset-parse and sgml-setup-buffer.
- 	(sgml-implied-end-tag): Error if implying end of document with
- 	anything but the buffer end.
- 
- 	* psgml-dtd.el (sgml-check-element-type): new function.  Parses
- 	name or ranked name or name/ranked group.
- 	(sgml-parse-element-dcl): Use above.
- 
- Sat Mar 26 00:57:08 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-other.el: New menu entries.
- 
- 	* psgml-parse.el (sgml-element-attribute-specification-start): new
- 	function.
- 	(sgml-element-attribute-specification-list): new function.
- 	(sgml-edit-attributes): use
- 	sgml-element-attribute-specification-start.
- 	(sgml-parser-loop): check sgml-shorttag.
- 	(sgml-parse-start-tag): check shorttag also choose move before
- 	included element.
- 	(sgml-parse-end-tag): check shorttag.
- 	(sgml-do-implied): check omittag.
- 	(sgml-implied-end-tag): check omittag.
- 	(sgml-check-tag-close): new function.
- 	(sgml-parse-end-tag): use above.  If NET, search for net-enabled=t.
- 	(sgml-next-trouble-spot): 
- 
- 	* psgml-dtd.el (sgml-parse-declared-value): Use new attribute types.
- 	(sgml-parse-default-value): dito.
- 
- 	* psgml-parse.el (sgml-options-menu): add shorttag.
- 	Creating Types for Attribute Declaration and 
- 	Attribute Specification.
- 	New functions:
- 	sgml-attdecl-declared-value sgml-attdecl-default-value
- 	sgml-attdecl-name sgml-attspec-attval sgml-attspec-name
- 	sgml-declared-value-notation sgml-declared-value-token-group
- 	sgml-default-value-attval sgml-default-value-type-p
- 	sgml-lookup-attdecl sgml-make-attdecl sgml-make-attspec
- 	sgml-make-declared-value sgml-make-default-value  
- 
- 	(sgml-edit-attrib-specification-list): use new types
- 
- 	(sgml-edit-attrib-finish): new definition
- 
- 	(sgml-edit-attrib-specification-list): new function.
- 
- 	(sgml-attribute-buffer): updated for new types.
- 
- 	(sgml-find-name-for-value): use sgml-attdecl-xx, etc.
- 
- 	(sgml-insert-attributes): New function.
- 
- 	(sgml-quote-attribute-value): Modified..
- 
- 	(sgml-parse-attribute-specification-list): use sgml-make-attspec.
- 
- Wed Mar 23 20:13:21 1994  Lennart Staflin  (lenst@konrad)
- 
- 	* psgml.el (sgml-save-options): Add sgml-shorttag.
- 
- Tue Mar 22 18:28:05 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (psgml-version): bump to 0.4a1
- 	Make some variables local.
- 
- Sun Mar 13 03:52:02 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el
- 	Bump version.
- 	(sgml-submit-bug-report): new function. 
- 
- 	* psgml-parse.el (sgml-edit-attrib-field-end): use
- 	sgml-edit-attrib-field-start and then check point+1, this to work
- 	in Lucid Emacs 19.9.
- 	(sgml-attribute-buffer): remove some properties
- 	(sgml-insert): fix Lucid extents.
- 
- Sat Mar 12 02:07:52 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-change-element-name): remove "*".
- 	(sgml-attribute-buffer): make category rear-nonsticky
- 
- Fri Mar 11 01:40:44 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-validate): save some buffers.
- 	(sgml-offer-save): option for above.
- 
- Thu Mar 10 02:40:44 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-last-closed-element): find the last closed
- 	element, for use by empty start-tag when OMITTAG NO.
- 	(sgml-parse-start-tag): check sgml-omittag and call
- 	sgml-last-closed-element.
- 	(sgml-complete): add declaration names.
- 
- Mon Mar  7 06:39:25 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-fill-region): make it give up if it can`t
- 	fill.
- 
- Sat Mar  5 12:38:58 1994  unknown  (lenst@lysita)
- 
- 	* psgml-lucid.el (x-popup-menu): reverse constructed menu.
- 
- 	* psgml-parse.el (sgml-doctype-insert): moved it here from
- 	psgml.el.  Set sgml-top-tree to nil, as there is now a new DTD.
- 
- Fri Mar  4 00:52:15 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-lucid.el (sgml-sgml-menu): Adding fill-element and
- 	normalize to menu.
- 
- Thu Mar  3 23:20:17 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-set-local-variable): set case fold search to t.
- 
- Sat Feb 26 19:14:25 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml-parse.el (sgml-parse-attribute-specification-list): check
- 	that name is not nil, as it may be returned by
- 	sgml-find-name-for-value.
- 
- Wed Feb 23 19:03:24 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-normalize-content): fix unclosed end tags.
- 	(sgml-parse-end-tag): skip SPACE after name.
- 	(sgml-do-fill): get fresh parse trees after posible change.  Don't
- 	use sgml-map-content.
- 
- Tue Feb 22 16:27:26 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-lucid.el: new file.
- 
- 	* psgml-other.el: new file.
- 
- 	* psgml-parse.el: 
-  	Installing changes for lucid compatibility (patches from William
- 	Perry).
- 
- 	* psgml.el (sgml-parent-document): Moved here.
-  	Installing changes for lucid compatibility (patches from William
- 	Perry).
- 
- Fri Feb 18 16:14:01 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-set-global): new function.
- 	(sgml-set-local): new function.
- 	(sgml-read-dtd): use sgml-set-global.
- 	(sgml-load-dtd): use the two new functions.
- 	(sgml-setup-dtd): new function, does some things previously done
- 	in sgml-parse-to.
- 	(sgml-parse-to): call above function.
- 
- Wed Feb 16 18:38:14 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-indent-or-tab): moved from psgml-parse.
- 
- Sat Feb 12 00:04:21 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-find-previous-element): don't try to parse
- 	to pos+1, use sgml-element-end insted.  pos+1 is no good if pos is
- 	point-max.  sgml-element-end may parse more than needed.
- 
- Fri Feb 11 01:01:35 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-normalize-content): expand empty start tag.
- 	(sgml-load-dtd): fix problem with wrong slected buffer when
- 	expanding file name.
- 
- 	* psgml-dtd.el (sgml-save-dtd): set sgml-loaded-dtd.
- 	(sgml-code-dtd): use sgml-buffer-doctype variable.
- 
- 	* psgml-parse.el (sgml-load-dtd): reuse loaded dtd from other
- 	buffer if possible.
- 	(sgml-skip-doctype): remove call to parse-prolog.
- 	(sgml-parse-to): if not top tree, load dtd or parse prolog.
- 	(sgml-buffer-doctype-state): remove.
- 	(sgml-buffer-doctyp): new variable, copy of argument to set-doctype.
- 	(sgml-doctype-state): remove.
- 	(sgml-set-doctype): set sgml-buffer-doctype.
- 	(sgml-entities-menu): add a call to (sgml-need-dtd).
- 	(sgml-need-dtd): new function.
- 
- Thu Feb 10 05:04:58 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-tags-menu): use new option.
- 
- 	* psgml.el (sgml-tag-region-if-active): new option.
- 
- Thu Feb 10 00:19:33 1994  Lennart Staflin  (lenst@ruben)
- 
- 	* psgml.el (sgml-mode-map): bind TAB
- 
- 	* psgml-parse.el (sgml-indent-or-tab): new command, bind to TAB.
- 
- 	* psgml-dtd.el (sgml-parse-nametoken-group): don't assume
- 	sgml-check-nametoken skips leading PS.
- 	(sgml-parse-entity-text): fix marked section type.
- 
- 	* psgml-parse.el (sgml-parse-nametoken-string): new function.
- 	(sgml-gname-symbol): new function.
- 	(sgml-check-nametoken): use above functions.
- 	(sgml-parse-attribute-specification-list): use
- 	sgml-parse-nametoken-string. 
- 	(sgml-parse-attribute-value-specification): dito.
- 	(sgml-find-name-for-value): take and return string.
- 	(sgml-quote-attribute-value): new function.
- 	(sgml-extract-attribute-value): take TYPE argument; don't do
- 	quoting.
- 	(sgml-edit-attrib-finish): use sgml-gname-symbol insted of intern
- 	and use sgml-quote-attribute-value when inserting value.
- 
- Wed Feb  9 23:03:54 1994  Lennart Staflin  (lenst@ruben)
- 
- 	* psgml-parse.el (sgml-note-change-at): don't set end of element
- 	to nil if the element is empty.
- 
- Wed Feb  9 07:28:05 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-note-change-at): fix bug if change in
- 	tag/data implying end tag.
- 	(sgml-parser-loop): pass empty start tag to sgml-parse-start-tag.
- 	(sgml-set-doctype): save document-element in a variable.
- 	(sgml-is-start-tag): recognize empty start tag.
- 	(sgml-parse-start-tag): handel empty start tag.
- 
- Sun Feb  6 19:01:32 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-insert): new function.
- 	(sgml-attribute-buffer): use insert insted of print, also sets
- 	properties for inserted text.
- 	(sgml-attribute-value-list): use properties.
- 	(sgml-extract-attribute-value): dito.
- 	(sgml-edit-attrib-default): new function.
- 	(sgml-edit-attrib-field-start): new function.
- 	(sgml-edit-attrib-next): new fuction.
- 	(sgml-suppress-warning): fix spelling.
- 
- 	* psgml.el (sgml-mode): handle the case that sgml-default-dtd-file
- 	returns nil.
- 	('sgml-default): set property for face.
- 	('sgml-fixed): dito.
- 
- Sat Feb  5 05:35:16 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-mode): change comment-start-skip.
- 
- 	* psgml-parse.el (sgml-what-element): new function.
- 	(sgml-map-content): new function.
- 
- 	* psgml.el (sgml-normalize-trims): new option.
- 
- 	* psgml-parse.el (sgml-element-next): fix bug in condition.
- 
- Sat Feb  5 03:06:45 1994  Lennart Staflin  (lenst@robin)
- 
- 	* psgml-parse.el (sgml-log-message): use set-buffer and insert
- 	insted of print.
- 	(sgml-insert-element): Leave point at first innermost element,
- 	also indicate required elements and suppress warnings.
- 	(sgml-find-name-for-value): add missing car.
- 
- Fri Feb  4 21:27:17 1994  Lennart Staflin  (lenst@robin)
- 
- 	* xtra.el (sgml-normalize-element): new command to normalize an
- 	element. 
- 	(sgml-normalize): takes optional argument, element to normalize.
- 	(sgml-normalize-content): takes third argument, ONLY-FIRST, if
- 	true only normalize first element.
- 
- Fri Feb  4 00:25:03 1994  Lennart Staflin  (lenst@lysita)
- 
-  	* psgml-parse.el (sgml-element-content): new function.
- 	(sgml-element-context-string): new function, will replace
- 	sgml-context-as-rec.
- 	(sgml-indent-line): take extra argument ELEMENT, to take level
- 	from element.  Also som code rewritten.
- 	(sgml-start-tag-of): take parse tree also
- 	(sgml-end-tag-of): dito.
- 	lot of changes to make a sgml-element view of parse tree.
- 	(sgml-indent-line): check data status of parent if at start tag.
- 
- Thu Feb  3 01:27:30 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-element-empty): new function, will replace
- 	sgml-element-empty-p. 
- 	(sgml-set-parse-state): use sgml-element-empty.
- 	(sgml-open-element): use sgml-element-empty.
- 	(sgml-alias-fields): alias some sgml-tree- fields as sgml-element-
- 	fields. 
- 	(sgml-element-model): new function.
- 	(sgml-element-data-p): new fucntion.
- 
- 	* xtra.el (sgml-normalize-content): make it less recursive.
- 
- 	* psgml-dtd.el (sgml-code-number): fix misspelling of single.
- 
- Wed Feb  2 19:27:50 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-read-number): use following-char insted of
- 	binding a variable.
- 	(sgml-buffer-entities): make buffer local.
- 
- 	* psgml.el (psgml-version): new var.
- 
- Mon Jan 31 02:23:14 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* xtra.el (sgml-normalize): new function.
- 	(sgml-normalize-content): new function.
- 
- Sun Jan 30 23:49:08 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-read-number): change to defsubst.
- 
- 	* psgml.el (sgml-default-dtd-file): handle (buffer-file-name) is
- 	nil.
- 
- Wed Jan 26 23:17:51 1994  Lennart Staflin  (lenst@astrid)
- 
- 	* psgml-dtd.el (sgml-make-alt): avoid multiple moves for same
- 	token. 
- 
- Sun Jan 23 20:57:15 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-parse-to): set pre-command-hook.
- 	(sgml-fold-element): ignore blanks at end of element
- 
- Fri Jan 14 05:29:44 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-external-file): fixing typo in error
- 	message and clearifying it.
- 
- Thu Jan 13 00:02:11 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml-parse.el (sgml-find-element-of): signal error if pos is
- 	end of buffer.
- 	(sgml-pubid-parts): allow \t and \n as SPACE after text class.
- 	(sgml-parse-to): remove setting before-change-hook.
- 	(sgml-set-doctype): add setq before-change-hook.
- 	(sgml-push-to-param): record file name for external parameters.
- 	Warn about undefined parameters.
- 
- Wed Jan 12 22:36:36 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml-parse.el (sgml-options-menu): add new option.
- 	(sgml-find-element-after): rewritten.
- 
- 	* psgml.el (sgml-doctype-insert): new function.
- 	(sgml-mode): build DTD menu also.
- 	(sgml-always-quote-attributes): new option.
- 
- Tue Jan 11 04:49:18 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml.el (sgml-max-menu-size): new user option.
- 
- 	* psgml-dtd.el (sgml-parse-prolog): set sgml-entities and
- 	sgml-buffer-entities.  Sort entities also.
- 	(sgml-code-dtd): code entites also.
- 	(sgml-parse-entity-dcl): save entity names on sgml-entities.
- 
- 	* psgml-parse.el (sgml-entities-menu): new function.
- 	(sgml-split-menu): new function.
- 	(sgml-read-dtd): set sgml-entities and sgml-buffer-entities. 
- 
- 	* psgml-dtd.el (sgml-save-dtd): set default dtd file.
- 
- Tue Jan 11 00:11:36 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml-parse.el (sgml-parse-attribute-specification-list): Now
- 	takes the element-type as argument.
- 	(sgml-find-name-for-value): dito.
- 	(sgml-edit-attributes): use sgml-find-element-of, will
- 	automatically load DTD if needed.
- 	(sgml-parser-loop): remove code to close elements at end of buffer.
- 	(sgml-parse-until-end-of): close elements at end of buffer.
- 
- Mon Jan 10 22:56:02 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el: move all code for parsing and commands using parsing
- 	to psgml-parse.el.  Added autoloads for moved commands.
- 
- 	* psgml-parse.el: new file with the parsing stuff and commands
- 	that use parsing from psgml.el.
- 	(sgml-check-nametoken): moved here from psgml-dtd.el
- 
- Sun Jan  9 01:59:20 1994  Lennart Staflin  (lenst@dell)
- 
- 	* psgml.el: A lot of changes.
- 	File has been split, psgml-dtd.el handles DTD parsing and saving.
- 	Code to load a saved DTD added.  Some optimizations are now done
- 	while building the DFAs.
- 	(sgml-close-element): allow ending top-tree if at end of buffer.
- 	(sgml-insert-element): leave point after last start tag.
- 	(sgml-log-message): record log size if buffer has a window.
- 	(sgml-log-warning): use log-message.
- 	(sgml-error): use log-warning.
- 	(sgml-mode): don't set pre-command-hook
- 
- 
- Sat Jan  8 03:02:19 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-skip-markup-declaration): new function.
- 	(sgml-skip-sgml-dcl): use above function.
- 	(sgml-parse-prolog): use sgml-skip-dcl
- 	(sgml-parse-dtd-subset): use sgml-skip-markup-declaration
- 	(sgml-fold-element): Use sgml-skip-markup-declaration
- 	(sgml-current-list-of-valid-elements): sort the list.
- 
- Sat Jan  8 00:30:53 1994  Lennart Staflin  (lenst@konrad)
- 
- 	* psgml.el (sgml-make-alt): use f to test insted of s1.
- 
- Wed Jan  5 23:39:58 1994  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-parse-parameter-literal): installing patch from
- 	James Clark; fixing contextual constraints for %.
- 	(sgml-&node-next): now as macro.
- 	(sgml-&node-dfas): dito.
- 
- Mon Dec 20 23:17:39 1993  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-with-parser-syntax): put a progn around the body.
- 	(sgml-parse-dtd-subset): Patch from James Clark; spelling
- 	correction.
- 	(sgml-parse-entity-text): Patch from James Clark; parsing external
- 	entitys. 
- 
- 
- Sun Dec 19 18:56:09 1993  Lennart Staflin  (lenst@lysita)
- 
- 	* psgml.el (sgml-find-element-after): rewritten not to loop at end
- 	of buffer and to also look for element after in parent if pos is
- 	at the end of its containing element.
- 	(sgml-element-end): return point-max if end of tree is undefined
- 	even after parsing.
- 	(sgml-element-next): new function, as sgml-tree-next but may parse
- 	to return a value.
- 	(sgml-insert-end-tag): insert NET if element opend with
- 	net-enabling start tag.
- 	(sgml-reset-log): new function to be called from pre-command-hook
- 	(sgml-parse-attlist): only reverse attlist once
- 
- 
- Thu Dec 16 23:37:22 1993  Lennart Staflin  (lenst@astrid)
- 
- 	* psgml.el (sgml-tag-region): don't change point in interactive.
- 	And don't bother to parse.
--- 876,878 ----
diff -c --recursive --new-file psgml-1a11/README.psgml psgml-1a12/README.psgml
*** psgml-1a11/README.psgml	Sun Sep  8 16:52:08 1996
--- psgml-1a12/README.psgml	Tue Sep 10 17:47:28 1996
***************
*** 1,4 ****
! This is the READ ME file for psgml.el version 1a11.       -*- text -*-
  
     PSGML is a major mode for editing SGML documents.  It works with
  GNU Emacs 19.19 and later or with XEmacs 19.13.
--- 1,4 ----
! This is the READ ME file for psgml.el version 1a12.       -*- text -*-
  
     PSGML is a major mode for editing SGML documents.  It works with
  GNU Emacs 19.19 and later or with XEmacs 19.13.
***************
*** 17,23 ****
  	psgml-api.texi	-- internals documentation
  	psgml-api.el	-- Extra functions for the API
  	fs.el		-- Example use of psgml to format a SGML file
! 	style.el	-- example style file for fs.el
  	catalog.sgml	-- example SGML-file for fs.el and style.el
  	iso88591.map
  	Makefile.in
--- 17,23 ----
  	psgml-api.texi	-- internals documentation
  	psgml-api.el	-- Extra functions for the API
  	fs.el		-- Example use of psgml to format a SGML file
! 	style.fs	-- example style file for fs.el
  	catalog.sgml	-- example SGML-file for fs.el and style.el
  	iso88591.map
  	Makefile.in
***************
*** 40,46 ****
--- 40,55 ----
  If you are using xemacs, you can run give the argument `--with-xemacs'
  to configure, or use `make xemacs'.
  
+ Instead of using configure you can load the psgml-main.el file and run
+ the command psgml-compile-files. Then you have to set load-path or
+ move the .elc files.
+ 
  Send bug reports, comments and suggestions to lenst@lysator.liu.se.
+ 
+ New in version 1.0a12
+ 
+ See ChangeLog...
+ 
  
  New in version 1.0a11
  
diff -c --recursive --new-file psgml-1a11/catalog.sgml psgml-1a12/catalog.sgml
*** psgml-1a11/catalog.sgml	Sun Sep  8 16:52:08 1996
--- psgml-1a12/catalog.sgml	Tue Sep 10 17:47:28 1996
***************
*** 1,4 ****
- 
  <!doctype example [
  <!element example	- -	(front, body) >
  <!element front		- -	(titlegrp) >
--- 1,3 ----
diff -c --recursive --new-file psgml-1a11/iso88591.map psgml-1a12/iso88591.map
*** psgml-1a11/iso88591.map	Sun Sep  8 16:52:11 1996
--- psgml-1a12/iso88591.map	Tue Sep 10 17:47:28 1996
***************
*** 92,94 ****
--- 92,156 ----
  253 [yacute]
  254 [thorn ]
  255 [yuml  ]
+ 192 
+ 193 
+ 194 
+ 195 
+ 196 
+ 197 
+ 198 
+ 199 
+ 200 
+ 201 
+ 202 
+ 203 
+ 204 
+ 205 
+ 206 
+ 207 
+ 208 
+ 209 
+ 210 
+ 211 
+ 212 
+ 213 
+ 214 
+ 216 
+ 217 
+ 218 
+ 219 
+ 220 
+ 221 
+ 222 
+ 223 
+ 224 
+ 225 
+ 226 
+ 227 
+ 228 
+ 229 
+ 230 
+ 231 
+ 232 
+ 233 
+ 234 
+ 235 
+ 236 
+ 237 
+ 238 
+ 239 
+ 240 
+ 241 
+ 242 
+ 243 
+ 244 
+ 245 
+ 246 
+ 248 
+ 249 
+ 250 
+ 251 
+ 252 
+ 253 
+ 254 
+ 255 
diff -c --recursive --new-file psgml-1a11/nefarious.el psgml-1a12/nefarious.el
*** psgml-1a11/nefarious.el	Sun Sep  8 16:55:16 1996
--- psgml-1a12/nefarious.el	Wed Dec 31 16:00:00 1969
***************
*** 1,248 ****
- ;;;; nefarious.el
- ;;; Last edited: Fri May 20 02:35:27 1994 by lenst@dell (Lennart Staflin)
- ;;; $Id: nefarious.el,v 1.2 1994/06/08 20:33:22 lenst Exp $
- 
- ;; Copyright (C) 1994 Lennart Staflin
- 
- ;; Author: Lennart Staflin <lenst@lysator.liu.se>
- 
- ;; This program is free software; you can redistribute it and/or
- ;; modify it under the terms of the GNU General Public License
- ;; as published by the Free Software Foundation; either version 2
- ;; of the License, or (at your option) any later version.
- ;; 
- ;; This program is distributed in the hope that it will be useful,
- ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
- ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- ;; GNU General Public License for more details.
- ;; 
- ;; You should have received a copy of the GNU General Public License
- ;; along with this program; if not, write to the Free Software
- ;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- 
- 
- ;;;; Commentary:
- 
- ;; This file is an addon to the PSGML package.  
- 
- ;; This file contains some commands to print out information about the
- ;; current DTD.
- 
- ;; sgml-list-elements
- ;;    Will list all elements and the attributes declared for the element.
- 
- ;; sgml-list-attributes
- ;;    Will list all attributes declared and the elements that use them.
- 
- ;; sgml-list-terminals
- ;;    Will list all elements that can contain data.
- 
- ;; sgml-list-occur-in-elements
- ;;    Will list all element types and where it can occur.
- 
- ;; sgml-list-content-elements
- ;;    Will list all element types and the element types that can occur
- ;;    in its content.
- 
- ;;;; Code:
- 
- (require 'psgml)
- (require 'psgml-parse)
- 
- (defconst sgml-attr-col 18)
- 
- 
- ;;;; Utility functions
- 
- (defsubst sgml-add-to-table (row-index elem table)
-   (let ((p (assq row-index table)))
-     (cond ((null p)
- 	   (cons (list row-index elem) table))
- 	  (t
- 	   (nconc p (list elem))
- 	   table))))
- 
- (defsubst sgml-add-last-unique (x l)
-   (unless (memq x l)
-     (nconc l (list x))))
- 
- (defun sgml-map-element-types (func)
-   (sgml-need-dtd)
-   (loop for x in sgml-buffer-eltype-map
- 	collect (funcall func (cdr x))))
- 
- (defun sgml-eltype-refrenced-elements (eltype)
-   (let* ((res				; result list (eltypes)
- 	 nil)
- 	(states				; list of states
- 	 (list (sgml-eltype-model eltype)))
- 	(agenda				; point into states
- 	 states))
-     (cond
-      ((not (sgml-model-group-p (car states)))
-       nil)
-      (t
-       (while agenda
- 	(cond
- 	 ((sgml-normal-state-p (car agenda))
- 	  (loop for m in (append (sgml-state-opts (car agenda))
- 				 (sgml-state-reqs (car agenda)))
- 		do
- 		(pushnew (sgml-move-token m) res)
- 		(sgml-add-last-unique (sgml-move-dest m) states)))
-        
- 	 (t				; &-node
- 	  (sgml-add-last-unique (sgml-&node-next (car agenda)) states)
- 	  (loop for dfa in (sgml-&node-dfas (car agenda)) do
- 		(sgml-add-last-unique dfa states))))
- 	(setq agenda (cdr agenda)))
-       res))))
- 
- ;;;; List elements
- 
- (defun sgml-list-elements ()
-   "List the elements and their attributes in the current DTD."
-   (interactive)
-   (message "Creating table...")
-   (sgml-display-table
-    (sgml-map-element-types
-     (function
-      (lambda (eltype)
-        (cons (sgml-eltype-name eltype)
- 	     (mapcar (function sgml-attdecl-name)
- 		     (sgml-eltype-attlist eltype))))))
-    "Elements" "Element" "Attribute"))
- 
- 
- ;;;; List attributes
- 
- (defun sgml-list-attributes ()
-   "List the attributes and in which elements they occur."
-   (interactive)
-   (let ((attributes nil))
-     (message "Creating table...")
-     (sgml-map-element-types
-      (function
-       (lambda (eltype)
- 	(loop for a in (sgml-eltype-attlist eltype) do
- 	      (setq attributes
- 		    (sgml-add-to-table (sgml-attdecl-name a)
- 				       (sgml-eltype-name eltype)
- 				       attributes))))))
-     (sgml-display-table attributes
- 			"Attributes" "Attribute" "Element")))
- 
- 
- 
- 
- ;;;; List terminals
- 
- (defun sgml-list-terminals ()
-   "List the elements that can have data in their content."
-   (interactive)
-   (message "Creating table...")
-   (let ((data-models (list sgml-cdata sgml-rcdata sgml-any)))
-     (sgml-display-table
-      (delq nil
- 	   (sgml-map-element-types
- 	    (function
- 	     (lambda (eltype)
- 	       (if (or (sgml-eltype-mixed eltype)
- 		       (memq (sgml-eltype-model eltype) data-models))
- 		   (list (sgml-eltype-name eltype)
- 			 (if (sgml-model-group-p
- 			      (sgml-eltype-model eltype))
- 			     'mixed
- 			   (sgml-eltype-model eltype))))))))
-      "Terminals" "Element" "Content")))
- 
- 
- ;;;; Element cross reference list
- 
- (defun sgml-list-content-elements ()
-   "List all element types and the element types that can occur in its content."
-   (interactive)
-   (message "Creating table...")
-   (sgml-display-table
-    (sgml-map-element-types
-     (function
-      (lambda (eltype)
-        (cons (sgml-eltype-name eltype)
- 	     (sgml-eltype-refrenced-elements eltype)))))
-    "Elements refrenced by elements"
-    "Element" "Content"))
- 
- (defun sgml-list-occur-in-elements ()
-   "List all element types and where it can occur."
-   (interactive)
-   (message "Creating table...")
-   (let ((cross nil))
-     (sgml-map-element-types
-      (function
-       (lambda (eltype)
- 	(loop for ref in (sgml-eltype-refrenced-elements eltype)
- 	      do (setq cross (sgml-add-to-table ref
- 						(sgml-eltype-name eltype)
- 						cross))))))
-     (sgml-display-table
-      cross
-      "Cross referenced element types" "Element" "Can occur in")))
- 
- 
- ;;;; Display table
- 
- (defun sgml-display-table (table title col-title1 col-title2 &optional width)
-   (or width
-       (setq width sgml-attr-col))
-   (let ((buf (get-buffer-create (format "*%s*" title))))
-     (message "Preparing display...")
-     (set-buffer buf)
-     (erase-buffer)
-     (insert col-title1)
-     (indent-to width)
-     (insert col-title2 "\n")
-     (insert-char ?= (length col-title1))
-     (indent-to width)
-     (insert-char ?= (length col-title2))
-     (insert "\n")
-     (setq table (sort table (function (lambda (a b)
- 					(string< (car a) (car b))))))
-     (loop for e in table do
- 	  (insert (format "%s" (car e)))
- 	  (loop for a in (sort (cdr e) (function string-lessp))
- 		for name = (symbol-name a)
- 		do
- 		(when (> (+ (length name) (current-column))
- 			 fill-column)
- 		  (insert "\n"))
- 		(when (< (current-column) sgml-attr-col)
- 		  (indent-to width))
- 		(insert  name " "))
- 	  (insert "\n"))
-     (goto-char (point-min))
-     (display-buffer buf)))
- 
- ;;;; Menus
- 
- (let ((menu
-        '("Info"
- 	 ["List elements" 		sgml-list-elements 		t]
- 	 ["List attributes" 		sgml-list-attributes 		t]
- 	 ["List terminals" 		sgml-list-terminals 		t]
- 	 ["List content elements" 	sgml-list-content-elements 	t]
- 	 ["List occur in elements" 	sgml-list-occur-in-elements 	t]
- 	 )))
-   (cond
-    (sgml-running-xemacs
-     (nconc sgml-dtd-menu (list menu)))
-    (t
-     (define-key (lookup-key sgml-mode-map [menu-bar sgml-dtd]) [info]
-       (let ((map (make-sparse-keymap (car menu))))
- 	(loop for e in (reverse (cdr menu)) do
- 	      (define-key map (vector (aref e 1))
- 		(cons (aref e 0) (aref e 1))))
- 	(cons (concat (car menu) "...") map))))))
- 
- 
- (provide 'nefarious)
- ;;; nefarious.el ends here
--- 0 ----
diff -c --recursive --new-file psgml-1a11/psgml-debug.el psgml-1a12/psgml-debug.el
*** psgml-1a11/psgml-debug.el	Sun Sep  8 16:52:14 1996
--- psgml-1a12/psgml-debug.el	Tue Sep 10 17:47:28 1996
***************
*** 1,6 ****
  ;;;;\filename dump.el
  ;;;\Last edited: Sun Mar 24 19:17:42 1996 by lenst@triton.lstaflin.pp.se (Lennart Staflin)
! ;;;\RCS $Id: psgml-debug.el,v 2.7 1996/03/31 21:26:25 lenst Exp $
  ;;;\author {Lennart Staflin}
  ;;;\maketitle
  
--- 1,6 ----
  ;;;;\filename dump.el
  ;;;\Last edited: Sun Mar 24 19:17:42 1996 by lenst@triton.lstaflin.pp.se (Lennart Staflin)
! ;;;\RCS $Id: psgml-debug.el,v 2.8 1996/09/01 01:20:21 lenst Exp $
  ;;;\author {Lennart Staflin}
  ;;;\maketitle
  
***************
*** 142,148 ****
    (with-output-to-temp-buffer "*Element dump*"
      (sgml-dp-element (sgml-lookup-eltype el-name))))
  
- 
  (defun sgml-dp-element (el)
    (cond
     ((sgml-eltype-defined el)
--- 142,147 ----
***************
*** 189,194 ****
--- 188,216 ----
    (loop for m in moves
  	collect (list (sgml-move-token m)
  		      (sgml-code-xlate (sgml-move-dest m)))))
+ 
+ 
+ ;;;; Dump state
+ 
+ (defun sgml-dump-state ()
+   (interactive)
+   (with-output-to-temp-buffer "*State dump*"
+     (sgml-dp-state sgml-current-state)))
+ 
+ (defun sgml-dp-state (state &optional indent)
+   (or indent (setq indent 0))
+   (cond
+    ((sgml-normal-state-p state)
+     (sgml-dp-model state indent))
+    (t
+     (princ (format "%sand-state\n" (make-string indent ? )))
+     (sgml-dp-state (sgml-and-state-substate state) (+ 2 indent))
+     (princ (format "%s--next\n" (make-string indent ? )))    
+     (sgml-dp-state (sgml-and-state-next state)     (+ 2 indent))
+     (princ (format "%s--dfas\n" (make-string indent ? )))        
+     (loop for m in (sgml-and-state-dfas state)
+ 	  do (sgml-dp-model m (+ indent 2))
+ 	  (princ (format "%s--\n" (make-string indent ? )))))))
  
  
  ;;;; Build autoloads for all interactive functions in psgml-parse
diff -c --recursive --new-file psgml-1a11/psgml-lfix.el psgml-1a12/psgml-lfix.el
*** psgml-1a11/psgml-lfix.el	Sun Sep  8 16:55:17 1996
--- psgml-1a12/psgml-lfix.el	Tue Sep 10 17:47:29 1996
***************
*** 1 ****
- (setq load-path (cons "." load-path))
--- 0 ----
diff -c --recursive --new-file psgml-1a11/psgml-parse.el psgml-1a12/psgml-parse.el
*** psgml-1a11/psgml-parse.el	Sun Sep  8 16:52:21 1996
--- psgml-1a12/psgml-parse.el	Tue Sep 10 17:47:31 1996
***************
*** 1,5 ****
  ;;;; psgml-parse.el --- Parser for SGML-editing mode with parsing support
! ;; $Id: psgml-parse.el,v 2.41 1996/05/20 21:38:08 lenst Exp $
  
  ;; Copyright (C) 1994, 1995 Lennart Staflin
  
--- 1,5 ----
  ;;;; psgml-parse.el --- Parser for SGML-editing mode with parsing support
! ;; $Id: psgml-parse.el,v 2.42 1996/06/13 18:45:06 lenst Exp $
  
  ;; Copyright (C) 1994, 1995 Lennart Staflin
  
***************
*** 469,475 ****
    ;; state is a and-state
    (let ((m (sgml-get-move (sgml-and-state-substate state) token)))
      (cond (m (cons m (cdr state)))
! 	  ((sgml-state-final-p (sgml-and-state-substate state))
  	   (sgml-next-sub-and (sgml-and-state-dfas state)
  			      token
  			      (sgml-and-state-next state))))))
--- 469,475 ----
    ;; state is a and-state
    (let ((m (sgml-get-move (sgml-and-state-substate state) token)))
      (cond (m (cons m (cdr state)))
! 	  ((sgml-final (sgml-and-state-substate state))
  	   (sgml-next-sub-and (sgml-and-state-dfas state)
  			      token
  			      (sgml-and-state-next state))))))
diff -c --recursive --new-file psgml-1a11/psgml.el psgml-1a12/psgml.el
*** psgml-1a11/psgml.el	Sun Sep  8 16:52:22 1996
--- psgml-1a12/psgml.el	Tue Sep 10 17:47:31 1996
***************
*** 1,7 ****
  ;;; psgml.el --- SGML-editing mode with parsing support
! ;; $Id: psgml.el,v 2.17 1996/05/20 21:33:59 lenst Exp $
  
! ;; Copyright (C) 1993, 1994, 1995 Lennart Staflin
  ;; Copyright (C) 1992 Free Software Foundation, Inc.
  
  ;; Author: Lennart Staflin <lenst@lysator.liu.se>
--- 1,7 ----
  ;;; psgml.el --- SGML-editing mode with parsing support
! ;; $Id: psgml.el,v 2.18 1996/09/01 01:21:25 lenst Exp $
  
! ;; Copyright (C) 1993, 1994, 1995, 1996 Lennart Staflin
  ;; Copyright (C) 1992 Free Software Foundation, Inc.
  
  ;; Author: Lennart Staflin <lenst@lysator.liu.se>
***************
*** 50,56 ****
  
  ;;; Code:
  
! (defconst psgml-version "1.0a11"
    "Version of psgml package.")
  
  (defconst psgml-maintainer-address "lenst@lysator.liu.se")
--- 50,56 ----
  
  ;;; Code:
  
! (defconst psgml-version "1.0a12"
    "Version of psgml package.")
  
  (defconst psgml-maintainer-address "lenst@lysator.liu.se")
***************
*** 453,459 ****
  ;;; Its error messages can be parsed by next-error.
  ;;; The -s option suppresses output.
  
! (defvar sgml-validate-command "sgmls -s %s %s"
    "*The shell command to validate an SGML document.
  
  This is a `format' control string that by default should contain two
--- 453,459 ----
  ;;; Its error messages can be parsed by next-error.
  ;;; The -s option suppresses output.
  
! (defvar sgml-validate-command "nsgmls -s %s %s"
    "*The shell command to validate an SGML document.
  
  This is a `format' control string that by default should contain two
***************
*** 481,488 ****
  format control string instead of the defaults.")
  
  (defvar sgml-validate-error-regexps
!   '(("\\(error\\|warning\\) at \\([^,]+\\), line \\([0-9]+\\)" 2 3)
!     ("^\\(.+\\):\\([0-9]+\\):\\([0-9]+\\):E: " 1 2 3))
    "Alist of regexps to recognize error messages from `sgml-validate'.
  See `compilation-error-regexp-alist'.")
  
--- 481,490 ----
  format control string instead of the defaults.")
  
  (defvar sgml-validate-error-regexps
!   '((":\\(.+\\):\\([0-9]+\\):\\([0-9]+\\):[EX]: " 1 2 3)
!     ("\\(error\\|warning\\) at \\([^,]+\\), line \\([0-9]+\\)" 2 3)
!     ("\n[a-zA-Z]?:?[^0-9 \n\t:]+:[ \t]*\\([^ \n\t:]+\\):\
! \\([0-9]+\\):\\(\\([0-9]+\\)[: \t]\\)?" 1 2 4))
    "Alist of regexps to recognize error messages from `sgml-validate'.
  See `compilation-error-regexp-alist'.")
  

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 10 23:59:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA01612 for xemacs-beta-people; Tue, 10 Sep 1996 23:59:09 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA01609 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 10 Sep 1996 23:59:08 -0500 (CDT)
Received: from gsenm5.gsen.goldstar.co.kr ([156.147.207.106]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA15778 for <xemacs-beta@cs.uiuc.edu>; Tue, 10 Sep 1996 23:58:56 -0500 (CDT)
Received: (from jwchoi@localhost) by gsenm5.gsen.goldstar.co.kr (8.6.9H1/8.6.12) id NAA28676; Wed, 11 Sep 1996 13:52:46 +1000
Date: Wed, 11 Sep 1996 13:52:46 +1000
Message-Id: <199609110352.NAA28676@gsenm5.gsen.goldstar.co.kr>
From: "Choi jong won (DM-4338-96.8.1)" <jwchoi@gsen.goldstar.co.kr>
To: xemacs-beta@cs.uiuc.edu
Subject: B28 - Hangs on help

Hello Xemacsers,

I just built b28(applied patch from b27). My problem is after I click
"Chuck Thompson" or "And many other contributors..." on "About
Xemacs..." of "Help" menu, always hangs! Only the above two items
cause the hang. And about Jamie and about Wing don't hang but I
couldn't see their nice pictures no more(I can see Richard Mlynarik's
picture, though). 

Followings are my configuration and error message of Xemacs.

Regards,

- jwchoi

---

Configured for `sparc-sun-sunos4.1.3_U1'.

  Where should the build process find the source code?    /user1/jwc/XEMACS/xemacs-20.0-b28
  What installation prefix should install use?		  /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sunos4-1-3shr.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/local/X11R6/include
  Where do we find X Windows libraries?                   /usr/local/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

---

Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
*MAKE SURE* to include as much configuration information as
possible; at the very least what OS and hardware you are running
on, and hopefully also what compiler and compiler options the
binary was compiled with, what options XEmacs was compiled with,
whether you are using a prebuilt binary from ftp.xemacs.org or
compiled XEmacs yourself for your system, etc.

If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb /usr/local/bin/emacs core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  # (unwind-protect ...)
  # (catch #<INTERNAL EMACS BUG (opaque, size=4) 0x35cc40> ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (inhibit-quit)
  # (condition-case ... . error)
  # (catch top-level ...)

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 02:25:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA01990 for xemacs-beta-people; Wed, 11 Sep 1996 02:25:45 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA01987 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 02:25:44 -0500 (CDT)
Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA02700 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 02:25:39 -0500 (CDT)
Received: from sun.rhrk.uni-kl.de by stepsun.uni-kl.de id aa04122;
          11 Sep 96 9:24 MET DST
Received: from aix8.rhrk.uni-kl.de by sun.rhrk.uni-kl.de id aa25240;
          11 Sep 96 9:24 MET DST
Received: by aix8 (Smail3.1.28.1 #7)
	id m0v0jep-0000alC; Wed, 11 Sep 96 09:24 CETDST
Message-Id: <m0v0jep-0000alC@aix8>
Date: Wed, 11 Sep 96 09:24 CETDST
From: thiessel@rhrk.uni-kl.de
To: Laura Harding <harding@sde.hp.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: XEmacs 20.0 beta28
In-Reply-To: <3235E733.1686@sde.hp.com>
References: <199609092334.SAA26868@xemacs.cs.uiuc.edu>
	<3235E733.1686@sde.hp.com>

Tried --with-mule ?!?! On hpux 9.05 I ran into

Make:  Don't know how to make /disk2/stuff/xemacs-20.0-b28/src/../lisp/mule/vietnamese-hooks-2.elc.  Stop.


during compile. Anyway, without mule support everything works fine.

Configured for `hppa1.1-hp-hpux9'.

  Where should the build process find the source code?    /disk2/stuff/xemacs-20.0-b28
  What installation prefix should install use?            /usr/local/lib/X11/xemacs
  What operating system and machine description files should XEmacs use?
        `s/hpux9.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              gcc -g -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/include/X11
  Where do we find X Windows libraries?                   /usr/lib/X11R5
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

If I got enough time these days, I'll soon have look at those vietnamese-hooks!


-Marcus

____________________________________________________________________________
 Marcus Thiessel                                      I T W M 
 phone:  +49-631-205-3126 		             
 fax:    +49-631-205-3616                mail:   thiessel@rhrk.uni-kl.de
____________________________________________________________________________

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 03:11:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA05327 for xemacs-beta-people; Wed, 11 Sep 1996 03:11:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA05324 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 03:11:38 -0500 (CDT)
Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA02733 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 03:11:35 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id BAA27069 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 01:11:36 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id BAA16480 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 01:11:31 -0700
Date: Wed, 11 Sep 1996 01:11:31 -0700
Message-Id: <199609110811.BAA16480@shellx.best.com>
From: Ben Wing <wing@666.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>,
        Martin Buchholz
    <mrb@eng.sun.com>
Subject: Re:  XEmacs and X11 Programming.

If these changes will work out, feel free to make them ...  they are as
they are because I couldn't figure out any other way to get things to 
work.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 04:34:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA05619 for xemacs-beta-people; Wed, 11 Sep 1996 04:34:18 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA05616 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 04:34:17 -0500 (CDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA02828 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 04:34:12 -0500 (CDT)
Received: from deimos.darmstadt.gmd.de (deimos [141.12.63.54]) by sonne.darmstadt.gmd.de (8.7.3/8.7.3) with SMTP id LAA02111 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 11:33:39 +0200 (MET DST)
Date: Wed, 11 Sep 1996 11:33:39 +0200 (MET DST)
Message-Id: <199609110933.LAA02111@sonne.darmstadt.gmd.de>
From: Roland Rieke <rieke@darmstadt.gmd.de>
To: <xemacs-beta@xemacs.org>
Subject: success 19.15b1 on solaris 2.4


No problems yet. 
Most missing patch: mode-motion+-3.15 -> 3.16 from Russell.Ritchie
(Stop multiple highlighting lossage with 19.14 release.)


Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /local/gnu/xemacs-19.15-b1
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/local/X11R6/include
  Where do we find X Windows libraries?                   /usr/local/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

 


From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 04:41:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA05650 for xemacs-beta-people; Wed, 11 Sep 1996 04:41:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA05647 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 04:41:43 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA02848 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 04:41:40 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA23745; Wed, 11 Sep 1996 02:36:09 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA05999; Wed, 11 Sep 1996 11:35:35 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/05Aug96-0532PM)
	id AA14190; Wed, 11 Sep 1996 11:35:20 +0200
Date: Wed, 11 Sep 1996 11:35:20 +0200
Message-Id: <9609110935.AA14190@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: xemacs-beta@xemacs.org
Subject: Re: autoloading over the net [was: tm and lite distribution]
In-Reply-To: <kig91ai42k2.fsf@jagor.srce.hr>
References: <199609101816.AA012999386@martigny.ai.mit.edu>
	<kig91ai42k2.fsf@jagor.srce.hr>
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

hniksic@srce.hr (Hrvoje Niksic) writes, in <kig91ai42k2.fsf@jagor.srce.hr>:

>How would it deal with terribly slow connections, like mine? If I
>understand what is being proposed, each time a package is autoloaded,
>its home site would be looked up to see if there is a later
>version. Such a scheme should be optional, IMO.

In addition to slow connections, some folks are behind fire-walls which
can be annoying/difficult to configure for novice users.  However, I
also think it would make a neat optional feature.

        Steve

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 05:42:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA05780 for xemacs-beta-people; Wed, 11 Sep 1996 05:42:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA05776 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 05:42:55 -0500 (CDT)
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA02905 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 05:42:52 -0500 (CDT)
Received: from berne.ai.mit.edu by martigny.ai.mit.edu with SMTP
	(1.40.112.4/16.2) id AA160628567; Wed, 11 Sep 1996 06:42:47 -0400
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
Message-Id: <199609111042.AA160628567@martigny.ai.mit.edu>
Received: by berne.ai.mit.edu
	(1.40.112.4/16.2) id AA254618566; Wed, 11 Sep 1996 06:42:46 -0400
Date: Wed, 11 Sep 1996 06:42:46 -0400
To: xemacs-beta@xemacs.org
In-Reply-To: <199609110725.JAA18337@daedalus.tnt.uni-hannover.de> (message
	from Heiko Muenkel on Wed, 11 Sep 1996 09:25:22 +0200)
Subject: Re: autoloading over the net [was: tm and lite distribution]

:>>>>> "Bill" == Bill Dubuque <wgd@martigny.ai.mit.edu> writes:
:
:  Bill> ... What would be better than polling is some way for a
:  Bill> newsgroup or mail message to be able to automagically
:  Bill> communicate that a new version is available, so that the
:  Bill> next time you try to load it you get a message describing
:  Bill> the new release, and a menu allowing you to download it if
:  Bill> desired. It probably would be easy to add this capability to
:  Bill> GNUS.

Also nice would be a capability to automagically propagate patches
via e-mail or newsgroup messages. Similar capability has been around
for decades on Lispm's.

Of course this opens up the same security issues that EVAL file local
variable raises. Are there standards for this yet?  What security
mechanisms are used when downloading Java applets?

-Bill

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 06:32:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA05887 for xemacs-beta-people; Wed, 11 Sep 1996 06:32:01 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA05884 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 06:32:00 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA02963 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 06:31:55 -0500 (CDT)
Message-Id: <199609111131.GAA02963@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA047651472; Wed, 11 Sep 1996 12:31:12 +0100
Date: Wed, 11 Sep 1996 12:31:12 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@xemacs.org
Subject: 19.15 b1 success on HP hpux 10.10
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



./configure  --prefix=/home/cognot/APPS/tmp
--bindir=/home/cognot/APPS/tmp/bin/`./config.guess`
--site-includes=/home/cognot/APPS/include
--site-libraries=/home/cognot/APPS/lib/hp700 --verbose --extra-verbose
--cflags="+O3 +Onoinline -Ae" --error-checking=none --debug=no
--dynamic=yes --with-menubars=lucid --with-scrollbars=lucid
--with-dialogs=motif --with-png

X11R5, Motif1.2, XPM 3.4, jpeg, png, compface.

Configured for `hppa1.1-hp-hpux10.10'.

  Where should the build process find the source code?    /home/cognot/APPS/src/xemacs-19.15-b1
  What installation prefix should install use?            /home/cognot/APPS/tmp
  What operating system and machine description files should XEmacs use?
        `s/hpux10shr.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              cc +O3 +Onoinline -Ae
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/include/X11R5
  Where do we find X Windows libraries?                   /usr/lib/X11R5 -L/usr/lib/X11R4
  Additional header files:                                /home/cognot/APPS/include
  Additional libraries:                                   /home/cognot/APPS/lib/hp700
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.


Compiled optimized. Will compile for debugging should any problem
occur.

Note: sound support didn't make it in, although libAlib is there (in
/opt/audio/lib, which seems to be the standart place for it in
10.X...).

So far, so good.

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 06:59:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id GAA06029 for xemacs-beta-people; Wed, 11 Sep 1996 06:59:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA06026 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 06:59:31 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id GAA03026 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 06:59:25 -0500 (CDT)
Message-Id: <199609111159.GAA03026@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA047703120; Wed, 11 Sep 1996 12:58:40 +0100
Date: Wed, 11 Sep 1996 12:58:40 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@xemacs.org
Subject: Couple of things on 19.15b1
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



Firstly, this is the first time I actually see this: delete is
extremely slow. My setup didn't change at all between 19.14 and
19.15b1, so this must be an XEmacs problem somewhere. Don't know how
to track that, though.

Second, the newer smiley.el seem to be more error-prone than
before. In particular, it takes |---------| (with any number of
dashes) for a smiley. It also tend to recognize a lot of false
smileys. I'd vote to have smiley-regexp-alist be
smiley-nosey-regexp-alist as default, intead of
smiley-deformed-regexp-alist. The regexps probably need a good look,
but unfortunately that's chinese to me...

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 07:06:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA06042 for xemacs-beta-people; Wed, 11 Sep 1996 07:06:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA06039 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 07:06:25 -0500 (CDT)
Received: from fronsac.ensg.u-nancy.fr (fronsac.ensg.u-nancy.fr [192.93.48.17]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA03041 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 07:06:20 -0500 (CDT)
Message-Id: <199609111206.HAA03041@xemacs.cs.uiuc.edu>
Received: by fronsac.ensg.u-nancy.fr
	(1.40.112.4/16.2) id AA047723536; Wed, 11 Sep 1996 13:05:36 +0100
Date: Wed, 11 Sep 1996 13:05:36 +0100
From: Richard Cognot <cognot@ensg.u-nancy.fr>
To: xemacs-beta@xemacs.org
Subject: More on delete slowness.
Reply-To: cognot@ensg.u-nancy.fr
X-Face:  .|{6#t`YCBNfg_E.8;@IFK9kd'Ol7>~2S7U!o3+g)+\`hV5&I]k,UwC%g%Y\,-KV+[eEgZm
 i(NgMB@L_n/A!jk;}@!?$<t5Aw`B$R=xJSv[F$2&sz*cwxF!|B3)MH,6YBDNU!$9;91N_p*>}</%ZO
 +EYRSc{a_#KXB)sJlPpxQq,/:}\*noO!;(5PY~MTnspl;&XA$JccP;N~;v5E>Yh.



Right. Seems to have something to do with multiple frames/gnus. I.e.:
my usual setup is to have at least 2 frames open: one for VM, the
second for gnus.

If I open a 3rd frame to edit a file and the gnus frame is exposed
(the group buffer, that is), then there is a huge slow down. If I
iconify the gnus frame, everything OK.

I can get the same thing by making the vm summarry buffer occupy the
whole vm frame.

Could that be somehow linked with the highlighting?

Richard.

-- 
|-------------------------------------------------------------|
| Richard Cognot           | Proceed, with fingers crossed... |
|                          |           /\^^/\                 |
| <cognot@ensg.u-nancy.fr> |             `'                   |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot                          |
|-------------------------------------------------------------|

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 07:22:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id HAA06076 for xemacs-beta-people; Wed, 11 Sep 1996 07:22:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id HAA06073 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 07:22:27 -0500 (CDT)
Received: from eik (eik.ii.uib.no [129.177.16.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id HAA03078 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 07:22:18 -0500 (CDT)
Received: from haukugle.ii.uib.no (haukugle) by eik with SMTP id AA00143
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Wed, 11 Sep 1996 14:21:56 +0200
Received: by haukugle.ii.uib.no; (5.65/1.1.8.2/02Mar95-0520PM)
	id AA16009; Wed, 11 Sep 1996 14:21:50 +0200
Sender: ketil@ii.uib.no
To: Pete Ware <ware@cis.ohio-state.edu>
Cc: xemacs-beta@xemacs.org
Subject: Re: tm and lite distribution
References: <199609101536.KAA00957@xemacs.cs.uiuc.edu>
	<vwmloeigswk.fsf@calico.cis.ohio-state.edu>
From: Ketil Z Malde <ketil@ii.uib.no>
In-Reply-To: Pete Ware's message of 10 Sep 1996 13:51:39 -0400
Date: 11 Sep 1996 14:21:47 +0200
Message-Id: <KETIL-eg7mq15jj8.fsf@haukugle.ii.uib.no>
Lines: 25
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Pete Ware <ware@cis.ohio-state.edu> writes:

> How about doing a "lite" distribution by adding ange-ftp like
> behaviour to load-path?

Cool idea, but some caveats - could we (very-very-please) avoid the
location based scheme that WWW suffers from?   In other words, we need
some kind of distribution system, like mirrored FTP maybe.

Currently, I'm glaring at a screen that glares back at me:

ncftp>get xemacs.tar.gz
Receiving file: xemacs.tar.gz 
  0%  0                                              16377171 bytes. ETA:773:08

That's more than ten hours of downloading time; I don't want the same to
be the case for any old library, just because I have a lousy connection
to the  US.

(setq xemacs-library-repository '("ftp.server.no:/pub/xemacs/lib"
					"ftp.alt.server.se:/pub/applications/xemacs/lib"
					"ftp.xemacs.org:/pub/lib" ))

~kzm


From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 08:35:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA06262 for xemacs-beta-people; Wed, 11 Sep 1996 08:35:06 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA06259 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 08:35:05 -0500 (CDT)
Received: from omega.IntraNet.com (omega.IntraNet.com [192.148.106.20]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA03187 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 08:35:02 -0500 (CDT)
Received: by omega.IntraNet.com; (5.65/1.1.8.3/20May95-0100AM)
	id AA08176; Wed, 11 Sep 1996 09:40:45 -0400
Received: by giant.IntraNet.com (DECUS UUCP /2.0/2.0/2.0/);
          Wed, 11 Sep 96 09:27:50 EDT
Received: from blight.IntraNet.com by titan.intranet.com (MX V4.2 VAX) with
          SMTP; Wed, 11 Sep 1996 09:27:45 EDT
Received: (from edwards@localhost) by blight.IntraNet.com (AIX4.2/UCB 8.7/8.7)
          id JAA36312; Wed, 11 Sep 1996 09:26:55 -0400 (EDT)
Date: Wed, 11 Sep 1996 09:26:55 -0400 (EDT)
Message-Id: <199609111326.JAA36312@blight.IntraNet.com>
From: Jonathan Edwards <edwards@blight.IntraNet.com>
To: cognot@ensg.u-nancy.fr
Cc: xemacs-beta@xemacs.org
Subject: More on delete slowness.
In-Reply-To: <199609111206.HAA03041@xemacs.cs.uiuc.edu>
References: <199609111206.HAA03041@xemacs.cs.uiuc.edu>

Richard Cognot writes:
> Right. Seems to have something to do with multiple frames/gnus. I.e.:
> my usual setup is to have at least 2 frames open: one for VM, the
> second for gnus.

The key seems to be the number mouse-sensitive regions visible. I have
seen this dramatic slowdown ever since 19.14. I have a test: do a
hyper-apropos on "mouse", maximize the frame, and then lean on the
right-arrow key and monitor CPU usage. 19.14 & 15 use (I seem to
recall) 5 times as much CPU as 19.13.

No one has come up with any suggestions of causes or cures. Not
everyone sees this problem. Doesn't seem to be registered in the bug
database.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 08:40:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA06323 for xemacs-beta-people; Wed, 11 Sep 1996 08:40:53 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA06320 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 08:40:51 -0500 (CDT)
Received: from gol1.gol.com (root@gol1.gol.com [202.243.48.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA03210 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 08:40:48 -0500 (CDT)
Received: from pentagana (jhod@tky1-35.gol.com [202.243.51.35]) by gol1.gol.com (8.7.5/8.6.9) with SMTP id WAA13449 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 22:40:39 +0900 (JST)
Sender: jhod@gol.com
Message-ID: <3236BB31.4075B7F8@po.iijnet.or.jp>
Date: Wed, 11 Sep 1996 22:14:25 +0900
From: "Jareth \"JHod\" Hein" <jhod@po.iijnet.or.jp>
Organization: Sonic Software Planning, Japan
X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.17 i586)
MIME-Version: 1.0
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 20.0b28 mule tests
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all. I haven't fallen of the planet, just feel like it.

Have managed to get 20.0b28 to compile and run on IRIX5.3, HPUX 10.20
and Linux 2.0.17 with the following:

../configure  --with-gnu-make --with-mule --srcdir=..
--site-includes="/usr/local/include /usr/include/wnn"
--site-libraries=/usr/local/lib --debug --error-checking=none

as well as the usual suspects of XPM 3.4h, libFaces, libPNG, Motif, etc.

However, XIM still fails miserably on all three platforms with Xwnmo,
ATOK-8, KInput2 or XJIM Input Methods. In all cases and on all
platforms, it dies inside of XtMalloc or XtRealloc somewhere below a
call to XIC_SetSpotLocation. After we get this current crunch out of the
way (looking like the end of the month, but not sure) I'll dig deeper.
Also, the WNN/Egg support I'm working on is still just that-- being
worked on. I've gotten it to the point that it will pass the wrong data
back and forth between JServer and XEmacs. Someyear I'll get it right.

Also still can't cut and paste MULE-ized text...

Is it just me, or is the redisplay code getting slower? In a fully
font-locked C-mode, scrolling occasionally is a real dog.

Anywho, gotta get back to work.

--Jareth Hein
Sonic Software Planning, Tokyo


From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 08:29:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA06248 for xemacs-beta-people; Wed, 11 Sep 1996 08:29:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA06245 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 08:29:26 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA03172 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 08:29:19 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id JAA28960; Wed, 11 Sep 1996 09:29:04 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp028949; Wed Sep 11 09:28:22 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA20114; Wed, 11 Sep 96 09:28:22 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA03677; Wed, 11 Sep 96 09:28:20 EDT
Message-Id: <9609111328.AA03677@cfdevx1.lehman.com>
Reply-To: Rick Campbell <campbell@c2.net>
X-Windows: Even your dog won't like it.
Organization: Lehman Brothers Inc.
From: Rick Campbell <campbell@c2.net>
To: Bill Dubuque <wgd@martigny.ai.mit.edu>
Cc: xemacs-beta@xemacs.org
Subject: Re: autoloading over the net [was: tm and lite distribution] 
In-Reply-To: Your message of "Wed, 11 Sep 1996 06:42:46 EDT."
             <199609111042.AA160628567@martigny.ai.mit.edu> 
Date: Wed, 11 Sep 1996 09:28:19 -0400
Sender: rickc@lehman.com

-----BEGIN PGP SIGNED MESSAGE-----

    From: Bill Dubuque <wgd@martigny.ai.mit.edu>
    Date: Wed, 11 Sep 1996 06:42:46 -0400

    What security mechanisms are used when downloading Java applets?

The security of downloading a Java applet is directly related to the
security of the Java system that you are using.  In theory, your Java
environment should not execute unsafe code.  In practice, people
continue to find new and interesting ways to convince other people's
Java environments to execute arbitrary code.

Automatically executing code that's distributed over the net is
inherently subject to attacks on the end user's machines.  The
safe-language model is one way to combat it.  I don't think that this
is practical for elisp -- safe-elisp would not be permitted to modify
files, for example.  Other ways to protect against attack involve
digital signatures made by keys that you trust.

In general, I think that the default for any automated mechanism for
Emacs should be that it requires some amount of action by the end user
to approve an update.  Of course, users who choose to do so should be
able to have the mechanism run fully automated.  That way, the rest of
us can find out about security attacks from those people :-)

			Rick

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMja+IRj0UvMeUesFAQGAPQP+Mn4Zz4Y/IvuxSfVh36Huj0pAMNqRpIqG
zK4CNxczVPN7UiWffEbm0B11eqcAbDtxiqCn1MaUkfEqilRNrLNy/vxt3kvLpRGJ
txj7Ez3rpR8JJrX5FEXDiYw9daDFXfViMKMoKstL96AF80EHgBNanHuUP7/PMje5
8jquS5r3l6A=
=mnQA
-----END PGP SIGNATURE-----

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 09:28:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA06585 for xemacs-beta-people; Wed, 11 Sep 1996 09:28:27 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA06582 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 09:28:26 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA27441 for <xemacs-beta@cs.uiuc.edu>; Wed, 11 Sep 1996 09:28:25 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA03315; Wed, 11 Sep 1996 09:28:06 -0500 (CDT)
Message-Id: <199609111428.JAA03315@xemacs.cs.uiuc.edu>
To: Russell Ritchie <ritchier@msc.ie>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: mouse drag resizing for horizontally split windows 
In-reply-to: Your message of "Wed, 11 Sep 1996 15:21:10 BST."
             <9609111421.AA20558@decalpha.msc.ie> 
Date: Wed, 11 Sep 1996 09:28:05 -0500
From: Chuck Thompson <cthomp@xemacs.org>

    Russell> I know, I know, 19.15 is in feature freeze.  I don't
    Russell> currently have access to a box I can compile XEmacs on,
    Russell> so I'm limited to Emacs-Lisp level hacking on other
    Russell> people's binaries for the moment.

Come on.  You've been a beta tester long enough to know how well
XEmacs feature freezes usually work :-)


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 09:20:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA06521 for xemacs-beta-people; Wed, 11 Sep 1996 09:20:43 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA06518 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 09:20:40 -0500 (CDT)
Received: from gateway.msc.ie (root@[194.125.117.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA27308 for <xemacs-beta@cs.uiuc.edu>; Wed, 11 Sep 1996 09:20:30 -0500 (CDT)
Received: from decalpha.msc.ie ([194.125.117.250]) by gateway.msc.ie 
	  Sendmail (v8.7.5) with SMTP id PAA16485 for <xemacs-beta@cs.uiuc.edu>;
	  Wed, 11 Sep 1996 15:20:20 +0100
Received: by decalpha.msc.ie; (5.65v3.2/1.1.8.2/08Jul96-0453PM)
	id AA20558; Wed, 11 Sep 1996 15:21:10 +0100
Date: Wed, 11 Sep 1996 15:21:10 +0100
Message-Id: <9609111421.AA20558@decalpha.msc.ie>
From: Russell Ritchie <ritchier@msc.ie>
To: xemacs-beta@cs.uiuc.edu
Subject: mouse drag resizing for horizontally split windows

I know, I know, 19.15 is in feature freeze.  I don't currently have access to
a box I can compile XEmacs on, so I'm limited to Emacs-Lisp level hacking on
other people's binaries for the moment.

Anyway, the web page asked for contributions and for some way to resize
horizontally split windows with the mouse, so here you go.

(If someone can show me how to attach an extent, or even just a keymap, to the
square that appears when you have both horizontal and vertical scrollbars on
a window, this could be made a lot less of a hack.)

;; Make horizontally-split windows resizable with the mouse.
;; Russell Ritchie <Russell.Ritchie@msc.ie>, Wed Sep 11 14:43:34 BST 1996.

;; I know I could [should perhaps] do this with advice, but I'd rather
;; not load something that large for something this gross.  Your
;; mileage may vary, Jersey barriers ahoy etc.

(defvar separator-drag-mouse-button 'button1
  "*The mouse button to overload with horizontal window resize drag behavior.
While this mouse button is pressed in the square where horizontal and vertical
scrollbars meet, you can drag to resize the window, release it to stop.")

(defconst separator-drag-mouse-button-original-command
  (global-key-binding separator-drag-mouse-button)
  "The command run by the global binding of separator-drag-mouse-button.
This is the command that will be run whenever mouse-on-separator-p is nil.")

(defun mouse-on-separator-p (event)
  "t if EVENT in the square below a vertical scrollbar.
This square only exists in windows with horizontal and vertical scrollbars."
  (interactive "e")
  (> (event-x-pixel event)
     (- (nth 2 (window-pixel-edges (event-window event))) 
	(specifier-instance scrollbar-width))))

(defun mouse-drag-separator (event)
  "Resize the current window horizontally by dragging the mouse."
  (interactive "e")
  (if (not (mouse-on-separator-p event))
      (funcall separator-drag-mouse-button-original-command event)
    (or (button-press-event-p event)
	(error "%s must be invoked by a mouse-press" this-command))
    (let ((mouse-down t)
	  (window (event-window event))
	  (def-line-width (face-width 'default))
	  (prior-drag-event-time 0)
	  (delta 0))
      (while mouse-down
	(setq event (next-event event))
	(cond ((motion-event-p event)
	       (if (window-rightmost-p window)
		   (error "can't drag rightmost window"))
	       (cond ((> (- (event-timestamp event) prior-drag-event-time)
			 drag-modeline-event-lag)
		      (setq prior-drag-event-time (event-timestamp event)
			    delta (+ delta
				     (/ (- (event-x-pixel event)
					   (nth 2 (window-pixel-edges window)))
					def-line-width)))
		      (if (= delta 0)
			  nil
			(select-window window)
			(if (>= (+ (window-width window) delta)
				window-min-width)
			    (enlarge-window-horizontally delta))
			(sit-for 0)))))
	      ((button-release-event-p event)
	       (setq mouse-down nil))
	      ((or (button-press-event-p event) (key-press-event-p event))
	       (error ""))
	      (t (dispatch-event event)))))))

(defvar mouse-sep-loaded nil)

(if (not mouse-sep-loaded)
    (progn				; In case someone loads us twice...
      (global-set-key separator-drag-mouse-button 'mouse-drag-separator)
      (setq mouse-sep-loaded t)))

(provide 'mouse-sep)



From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 09:27:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA06568 for xemacs-beta-people; Wed, 11 Sep 1996 09:27:24 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA06561 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 09:27:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA03308; Wed, 11 Sep 1996 09:27:20 -0500 (CDT)
Message-Id: <199609111427.JAA03308@xemacs.cs.uiuc.edu>
To: "Jareth \"JHod\" Hein" <jhod@po.iijnet.or.jp>
cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: 20.0b28 mule tests 
In-reply-to: Your message of "Wed, 11 Sep 1996 22:14:25 +0900."
             <3236BB31.4075B7F8@po.iijnet.or.jp> 
Date: Wed, 11 Sep 1996 09:27:18 -0500
From: Chuck Thompson <cthomp@xemacs.org>

    Jareth> Is it just me, or is the redisplay code getting slower? In
    Jareth> a fully font-locked C-mode, scrolling occasionally is a
    Jareth> real dog.

Remember that the betas have the extra debug code enabled by default.
The redisplay engine is probably hit harder by these extra checks than
almost any other part of the code.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 09:42:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA06645 for xemacs-beta-people; Wed, 11 Sep 1996 09:42:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA06642 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 09:42:18 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA27870 for <xemacs-beta@cs.uiuc.edu>; Wed, 11 Sep 1996 09:42:17 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id PAA04881 for <xemacs-beta@cs.uiuc.edu>; Wed, 11 Sep 1996 15:42:08 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id PAA20404 for <xemacs-beta@cs.uiuc.edu>; Wed, 11 Sep 1996 15:44:01 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id PAA09511; Wed, 11 Sep 1996 15:48:25 +0100
Date: Wed, 11 Sep 1996 15:48:25 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199609111448.PAA09511@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: XEmacs logo
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: /8nNGwa/gsPdSGNbHFxYyQ==

I have converted my spinning xemacs logo to an animated gif so that you can see 
it in netscape. Anyone interested? (The xemacs home page FI?).

Its 175K.

andy

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 11:53:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA07260 for xemacs-beta-people; Wed, 11 Sep 1996 11:53:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA07257 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 11:53:06 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA04183 for <xemacs-beta@cs.uiuc.edu>; Wed, 11 Sep 1996 11:53:05 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id JAA25355; Wed, 11 Sep 1996 09:56:43 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: More on delete slowness.
References: <199609111206.HAA03041@xemacs.cs.uiuc.edu> <199609111326.JAA36312@blight.IntraNet.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Jonathan Edwards's message of Wed, 11 Sep 1996 09:26:55 -0400 (EDT)
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 11 Sep 1996 09:56:41 -0700
Message-ID: <m2g24pm1me.fsf@deanna.miranova.com>
Lines: 26
X-Mailer: Red Gnus v0.32/XEmacs 19.15

>>>>> "Jonathan" == Jonathan Edwards <edwards@blight.IntraNet.com> writes:

> Richard Cognot writes:

Richard> Right. Seems to have something to do with multiple
Richard> frames/gnus. I.e.: my usual setup is to have at least 2
Richard> frames open: one for VM, the second for gnus.

Jonathan> The key seems to be the number mouse-sensitive regions
Jonathan> visible. I have seen this dramatic slowdown ever since
Jonathan> 19.14. I have a test: do a hyper-apropos on "mouse",
Jonathan> maximize the frame, and then lean on the right-arrow key and
Jonathan> monitor CPU usage. 19.14 & 15 use (I seem to recall) 5 times
Jonathan> as much CPU as 19.13.

I don't think it's as simple as that.  Gnus has tons of mouse
sensitive regions, but I've never experienced a slowdown with it.
However, in recent experiences with dired (a package I do not normally
use) I've seen a dramatic performance hit with dired buffers (even
when the dired buffer is in the only frame).  What does dired do
differently than Gnus?
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 11:55:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA07265 for xemacs-beta-people; Wed, 11 Sep 1996 11:55:13 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA07262 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 11:55:12 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA04386 for <xemacs-beta@cs.uiuc.edu>; Wed, 11 Sep 1996 11:55:12 -0500 (CDT)
Received: from kramer.aventail.com (root@newman [192.168.1.1]) by newman (8.6.12/8.6.9) with SMTP id JAA15690; Wed, 11 Sep 1996 09:53:12 -0700
Date: Wed, 11 Sep 1996 09:53:12 -0700
Message-Id: <199609111653.JAA15690@newman>
From: William Perry <wmperry@aventail.com>
To: andyp@parallax.co.uk (Andy Piper)
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: XEmacs logo
In-Reply-To: <199609111448.PAA09511@wrath.parallax.co.uk>
References: <199609111448.PAA09511@wrath.parallax.co.uk>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Andy Piper writes:
>Content-MD5: /8nNGwa/gsPdSGNbHFxYyQ==
>
>I have converted my spinning xemacs logo to an animated gif so that you
>can see it in netscape. Anyone interested? (The xemacs home page FI?).
>
>Its 175K.

  Only if you extend the redisplay code to actually be able to show
animated gifs.  :)  Actually only half kidding.

-Bill P.


From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 12:11:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA07294 for xemacs-beta-people; Wed, 11 Sep 1996 12:11:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA07291 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 12:11:24 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA05681 for <xemacs-beta@cs.uiuc.edu>; Wed, 11 Sep 1996 12:11:20 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA25702; Wed, 11 Sep 1996 10:15:01 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: mouse drag resizing for horizontally split windows
References: <199609111428.JAA03315@xemacs.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Wed, 11 Sep 1996 09:28:05 -0500
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 11 Sep 1996 10:14:59 -0700
Message-ID: <m2afuxm0rw.fsf@deanna.miranova.com>
Lines: 15
X-Mailer: Red Gnus v0.32/XEmacs 19.15

>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

Chuck> Come on.  You've been a beta tester long enough to know how well
Chuck> XEmacs feature freezes usually work :-)

O.K. :-)

I would nominate then the OffiX drag and drop patches posted just
after the 19.14 release.  I don't know what CDE is, but I do know I'd
love to have drag and drop capabilities in XEmacs.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 18:07:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA08464 for xemacs-beta-people; Wed, 11 Sep 1996 18:07:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA08461 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 18:07:58 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA04434 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 18:07:53 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.7.5/8.7.3) with ESMTP id SAA30248 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 18:05:57 -0500
Message-Id: <199609112305.SAA30248@nvwls.cc.purdue.edu>
Reply-to: nuspl@purdue.edu
X-Mailer: MH-E 5.0.2
X-Attribution: JJN
X-Face: K'Q`VIQx)c-;TPHDA`.,kBQq(WyNe3AdopJ?B(.4yT%n|F?4>+?x]pQ4XC83s-4;|U{%9x]
 =yr4dko
To: xemacs-beta@xemacs.org
Subject: lisp/iso sync w/ 19.34 patch
Date: Wed, 11 Sep 1996 18:05:52 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


--- /opt/xemacs/lisp/iso/iso-ascii.el	Wed Jul  5 08:39:03 1995
+++ iso-ascii.el	Mon Sep  9 16:47:09 1996
@@ -1,26 +1,29 @@
 ;;; iso-ascii.el --- set up char tables for ISO 8859/1 on ASCII terminals.
 
-;; Copyright (C) 1987 Free Software Foundation, Inc.
+;; Copyright (C) 1987, 1995 Free Software Foundation, Inc.
 
 ;; Author: Howard Gayle
 ;; Maintainer: FSF
 ;; Keywords: i18n
 
-;; This file is part of GNU Emacs.
+;; This file is part of XEmacs.
 
-;; GNU Emacs is free software; you can redistribute it and/or modify
+;; XEmacs is free software; you can redistribute it and/or modify
 ;; it under the terms of the GNU General Public License as published by
 ;; the Free Software Foundation; either version 2, or (at your option)
 ;; any later version.
 
-;; GNU Emacs is distributed in the hope that it will be useful,
+;; XEmacs is distributed in the hope that it will be useful,
 ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
 ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 ;; GNU General Public License for more details.
 
 ;; You should have received a copy of the GNU General Public License
-;; along with GNU Emacs; see the file COPYING.  If not, write to
-;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+;; along with XEmacs; see the file COPYING.  If not, write to the
+;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+;; Boston, MA 02111-1307, USA.
+
+;;; Synched up with: FSF 19.34.
 
 ;;; Commentary:
 
@@ -34,102 +37,111 @@
 
 (require 'disp-table)
 
-(standard-display-ascii 160 "{_}")   ; NBSP (no-break space)
-(standard-display-ascii 161 "{!}")   ; inverted exclamation mark
-(standard-display-ascii 162 "{c}")   ; cent sign
-(standard-display-ascii 163 "{GBP}") ; pound sign
-(standard-display-ascii 164 "{$}")   ; general currency sign
-(standard-display-ascii 165 "{JPY}") ; yen sign
-(standard-display-ascii 166 "{|}")   ; broken vertical line
-(standard-display-ascii 167 "{S}")   ; section sign
-(standard-display-ascii 168 "{\"}")  ; diaeresis
-(standard-display-ascii 169 "{C}")   ; copyright sign
-(standard-display-ascii 170 "{_a}")  ; ordinal indicator, feminine
-(standard-display-ascii 171 "{<<}")  ; left angle quotation mark
-(standard-display-ascii 172 "{~}")   ; not sign
-(standard-display-ascii 173 "{-}")   ; soft hyphen
-(standard-display-ascii 174 "{R}")   ; registered sign
-(standard-display-ascii 175 "{=}")   ; macron
-(standard-display-ascii 176 "{o}")   ; degree sign
-(standard-display-ascii 177 "{+-}")  ; plus or minus sign
-(standard-display-ascii 178 "{2}")   ; superscript two
-(standard-display-ascii 179 "{3}")   ; superscript three
-(standard-display-ascii 180 "{'}")   ; acute accent
-(standard-display-ascii 181 "{u}")   ; micro sign
-(standard-display-ascii 182 "{P}")   ; pilcrow
-(standard-display-ascii 183 "{.}")   ; middle dot
-(standard-display-ascii 184 "{,}")   ; cedilla
-(standard-display-ascii 185 "{1}")   ; superscript one
-(standard-display-ascii 186 "{_o}")  ; ordinal indicator, masculine
-(standard-display-ascii 187 "{>>}")  ; right angle quotation mark
-(standard-display-ascii 188 "{1/4}") ; fraction one-quarter
-(standard-display-ascii 189 "{1/2}") ; fraction one-half
-(standard-display-ascii 190 "{3/4}") ; fraction three-quarters
-(standard-display-ascii 191 "{?}")   ; inverted question mark
-(standard-display-ascii 192 "{`A}")  ; A with grave accent
-(standard-display-ascii 193 "{'A}")  ; A with acute accent
-(standard-display-ascii 194 "{^A}")  ; A with circumflex accent
-(standard-display-ascii 195 "{~A}")  ; A with tilde
-(standard-display-ascii 196 "{\"A}") ; A with diaeresis or umlaut mark
-(standard-display-ascii 197 "{AA}")  ; A with ring
-(standard-display-ascii 198 "{AE}")  ; AE diphthong
-(standard-display-ascii 199 "{,C}")  ; C with cedilla
-(standard-display-ascii 200 "{`E}")  ; E with grave accent
-(standard-display-ascii 201 "{'E}")  ; E with acute accent
-(standard-display-ascii 202 "{^E}")  ; E with circumflex accent
-(standard-display-ascii 203 "{\"E}") ; E with diaeresis or umlaut mark
-(standard-display-ascii 204 "{`I}")  ; I with grave accent
-(standard-display-ascii 205 "{'I}")  ; I with acute accent
-(standard-display-ascii 206 "{^I}")  ; I with circumflex accent
-(standard-display-ascii 207 "{\"I}") ; I with diaeresis or umlaut mark
-(standard-display-ascii 208 "{-D}")  ; D with stroke, Icelandic eth
-(standard-display-ascii 209 "{~N}")  ; N with tilde
-(standard-display-ascii 210 "{`O}")  ; O with grave accent
-(standard-display-ascii 211 "{'O}")  ; O with acute accent
-(standard-display-ascii 212 "{^O}")  ; O with circumflex accent
-(standard-display-ascii 213 "{~O}")  ; O with tilde
-(standard-display-ascii 214 "{\"O}") ; O with diaeresis or umlaut mark
-(standard-display-ascii 215 "{x}")   ; multiplication sign
-(standard-display-ascii 216 "{/O}")  ; O with slash
-(standard-display-ascii 217 "{`U}")  ; U with grave accent
-(standard-display-ascii 218 "{'U}")  ; U with acute accent
-(standard-display-ascii 219 "{^U}")  ; U with circumflex accent
-(standard-display-ascii 220 "{\"U}") ; U with diaeresis or umlaut mark
-(standard-display-ascii 221 "{'Y}")  ; Y with acute accent
-(standard-display-ascii 222 "{TH}")  ; capital thorn, Icelandic
-(standard-display-ascii 223 "{ss}")  ; small sharp s, German
-(standard-display-ascii 224 "{`a}")  ; a with grave accent
-(standard-display-ascii 225 "{'a}")  ; a with acute accent
-(standard-display-ascii 226 "{^a}")  ; a with circumflex accent
-(standard-display-ascii 227 "{~a}")  ; a with tilde
-(standard-display-ascii 228 "{\"a}") ; a with diaeresis or umlaut mark
-(standard-display-ascii 229 "{aa}")  ; a with ring
-(standard-display-ascii 230 "{ae}")  ; ae diphthong
-(standard-display-ascii 231 "{,c}")  ; c with cedilla
-(standard-display-ascii 232 "{`e}")  ; e with grave accent
-(standard-display-ascii 233 "{'e}")  ; e with acute accent
-(standard-display-ascii 234 "{^e}")  ; e with circumflex accent
-(standard-display-ascii 235 "{\"e}") ; e with diaeresis or umlaut mark
-(standard-display-ascii 236 "{`i}")  ; i with grave accent
-(standard-display-ascii 237 "{'i}")  ; i with acute accent
-(standard-display-ascii 238 "{^i}")  ; i with circumflex accent
-(standard-display-ascii 239 "{\"i}") ; i with diaeresis or umlaut mark
-(standard-display-ascii 240 "{-d}")  ; d with stroke, Icelandic eth
-(standard-display-ascii 241 "{~n}")  ; n with tilde
-(standard-display-ascii 242 "{`o}")  ; o with grave accent
-(standard-display-ascii 243 "{'o}")  ; o with acute accent
-(standard-display-ascii 244 "{^o}")  ; o with circumflex accent
-(standard-display-ascii 245 "{~o}")  ; o with tilde
-(standard-display-ascii 246 "{\"o}") ; o with diaeresis or umlaut mark
-(standard-display-ascii 247 "{/}")   ; division sign
-(standard-display-ascii 248 "{/o}")  ; o with slash
-(standard-display-ascii 249 "{`u}")  ; u with grave accent
-(standard-display-ascii 250 "{'u}")  ; u with acute accent
-(standard-display-ascii 251 "{^u}")  ; u with circumflex accent
-(standard-display-ascii 252 "{\"u}") ; u with diaeresis or umlaut mark
-(standard-display-ascii 253 "{'y}")  ; y with acute accent
-(standard-display-ascii 254 "{th}")  ; small thorn, Icelandic
-(standard-display-ascii 255 "{\"y}") ; small y with diaeresis or umlaut mark
+(defvar iso-ascii-convenient nil
+  "*Non-nil means `iso-ascii' should aim for convenience, not precision.")
+
+(defun iso-ascii-display (code string &optional convenient-string)
+  (if iso-ascii-convenient
+      (setq string (or convenient-string string))
+    (setq string (concat "{" string "}")))
+  (standard-display-ascii code string))
+
+(iso-ascii-display 160 "_" " ")   ; NBSP (no-break space)
+(iso-ascii-display 161 "!")   ; inverted exclamation mark
+(iso-ascii-display 162 "c")   ; cent sign
+(iso-ascii-display 163 "GBP") ; pound sign
+(iso-ascii-display 164 "$")   ; general currency sign
+(iso-ascii-display 165 "JPY") ; yen sign
+(iso-ascii-display 166 "|")   ; broken vertical line
+(iso-ascii-display 167 "S" "(S)")   ; section sign
+(iso-ascii-display 168 "\"")  ; diaeresis
+(iso-ascii-display 169 "C" "(C)")   ; copyright sign
+(iso-ascii-display 170 "_a")  ; ordinal indicator, feminine
+(iso-ascii-display 171 "<<")  ; left angle quotation mark
+(iso-ascii-display 172 "~")   ; not sign
+(iso-ascii-display 173 "-")   ; soft hyphen
+(iso-ascii-display 174 "R" "(R)")   ; registered sign
+(iso-ascii-display 175 "=")   ; macron
+(iso-ascii-display 176 "o")   ; degree sign
+(iso-ascii-display 177 "+-")  ; plus or minus sign
+(iso-ascii-display 178 "2")   ; superscript two
+(iso-ascii-display 179 "3")   ; superscript three
+(iso-ascii-display 180 "'")   ; acute accent
+(iso-ascii-display 181 "u")   ; micro sign
+(iso-ascii-display 182 "P" "{P}")   ; pilcrow
+(iso-ascii-display 183 ".")   ; middle dot
+(iso-ascii-display 184 ",")   ; cedilla
+(iso-ascii-display 185 "1")   ; superscript one
+(iso-ascii-display 186 "_o")  ; ordinal indicator, masculine
+(iso-ascii-display 187 ">>")  ; right angle quotation mark
+(iso-ascii-display 188 "1/4") ; fraction one-quarter
+(iso-ascii-display 189 "1/2") ; fraction one-half
+(iso-ascii-display 190 "3/4") ; fraction three-quarters
+(iso-ascii-display 191 "?")   ; inverted question mark
+(iso-ascii-display 192 "`A")  ; A with grave accent
+(iso-ascii-display 193 "'A")  ; A with acute accent
+(iso-ascii-display 194 "^A")  ; A with circumflex accent
+(iso-ascii-display 195 "~A")  ; A with tilde
+(iso-ascii-display 196 "\"A") ; A with diaeresis or umlaut mark
+(iso-ascii-display 197 "AA")  ; A with ring
+(iso-ascii-display 198 "AE")  ; AE diphthong
+(iso-ascii-display 199 ",C")  ; C with cedilla
+(iso-ascii-display 200 "`E")  ; E with grave accent
+(iso-ascii-display 201 "'E")  ; E with acute accent
+(iso-ascii-display 202 "^E")  ; E with circumflex accent
+(iso-ascii-display 203 "\"E") ; E with diaeresis or umlaut mark
+(iso-ascii-display 204 "`I")  ; I with grave accent
+(iso-ascii-display 205 "'I")  ; I with acute accent
+(iso-ascii-display 206 "^I")  ; I with circumflex accent
+(iso-ascii-display 207 "\"I") ; I with diaeresis or umlaut mark
+(iso-ascii-display 208 "-D")  ; D with stroke, Icelandic eth
+(iso-ascii-display 209 "~N")  ; N with tilde
+(iso-ascii-display 210 "`O")  ; O with grave accent
+(iso-ascii-display 211 "'O")  ; O with acute accent
+(iso-ascii-display 212 "^O")  ; O with circumflex accent
+(iso-ascii-display 213 "~O")  ; O with tilde
+(iso-ascii-display 214 "\"O") ; O with diaeresis or umlaut mark
+(iso-ascii-display 215 "x")   ; multiplication sign
+(iso-ascii-display 216 "/O")  ; O with slash
+(iso-ascii-display 217 "`U")  ; U with grave accent
+(iso-ascii-display 218 "'U")  ; U with acute accent
+(iso-ascii-display 219 "^U")  ; U with circumflex accent
+(iso-ascii-display 220 "\"U") ; U with diaeresis or umlaut mark
+(iso-ascii-display 221 "'Y")  ; Y with acute accent
+(iso-ascii-display 222 "TH")  ; capital thorn, Icelandic
+(iso-ascii-display 223 "ss")  ; small sharp s, German
+(iso-ascii-display 224 "`a")  ; a with grave accent
+(iso-ascii-display 225 "'a")  ; a with acute accent
+(iso-ascii-display 226 "^a")  ; a with circumflex accent
+(iso-ascii-display 227 "~a")  ; a with tilde
+(iso-ascii-display 228 "\"a") ; a with diaeresis or umlaut mark
+(iso-ascii-display 229 "aa")  ; a with ring
+(iso-ascii-display 230 "ae")  ; ae diphthong
+(iso-ascii-display 231 ",c")  ; c with cedilla
+(iso-ascii-display 232 "`e")  ; e with grave accent
+(iso-ascii-display 233 "'e")  ; e with acute accent
+(iso-ascii-display 234 "^e")  ; e with circumflex accent
+(iso-ascii-display 235 "\"e") ; e with diaeresis or umlaut mark
+(iso-ascii-display 236 "`i")  ; i with grave accent
+(iso-ascii-display 237 "'i")  ; i with acute accent
+(iso-ascii-display 238 "^i")  ; i with circumflex accent
+(iso-ascii-display 239 "\"i") ; i with diaeresis or umlaut mark
+(iso-ascii-display 240 "-d")  ; d with stroke, Icelandic eth
+(iso-ascii-display 241 "~n")  ; n with tilde
+(iso-ascii-display 242 "`o")  ; o with grave accent
+(iso-ascii-display 243 "'o")  ; o with acute accent
+(iso-ascii-display 244 "^o")  ; o with circumflex accent
+(iso-ascii-display 245 "~o")  ; o with tilde
+(iso-ascii-display 246 "\"o") ; o with diaeresis or umlaut mark
+(iso-ascii-display 247 "/")   ; division sign
+(iso-ascii-display 248 "/o")  ; o with slash
+(iso-ascii-display 249 "`u")  ; u with grave accent
+(iso-ascii-display 250 "'u")  ; u with acute accent
+(iso-ascii-display 251 "^u")  ; u with circumflex accent
+(iso-ascii-display 252 "\"u") ; u with diaeresis or umlaut mark
+(iso-ascii-display 253 "'y")  ; y with acute accent
+(iso-ascii-display 254 "th")  ; small thorn, Icelandic
+(iso-ascii-display 255 "\"y") ; small y with diaeresis or umlaut mark
 
 (provide 'iso-ascii)
 
--- /opt/xemacs/lisp/iso/iso-cvt.el	Wed Jul  5 08:39:03 1995
+++ iso-cvt.el	Mon Sep  9 16:35:06 1996
@@ -1,65 +1,70 @@
-;; iso-cvt.el -- translate to ISO 8859-1 from/to net/TeX conventions
-;; Copyright  1993, 1994 Free Software Foundation, Inc.
-;; Was formerly called gm-lingo.el.
+;;; iso-cvt.el --- translate to ISO 8859-1 from/to net/TeX conventions
+;; This file was formerly called gm-lingo.el.
+
+;; Copyright (C) 1993, 1994 Free Software Foundation, Inc.
 
 ;; Author: Michael Gschwind <mike@vlsivie.tuwien.ac.at>
 ;; Keywords: tex, iso, latin, i18n
 
-;; This file is part of GNU Emacs.
+;; This file is part of XEmacs.
 
-;; GNU Emacs is free software; you can redistribute it and/or modify
+;; XEmacs is free software; you can redistribute it and/or modify
 ;; it under the terms of the GNU General Public License as published by
 ;; the Free Software Foundation; either version 2, or (at your option)
 ;; any later version.
 
-;; GNU Emacs is distributed in the hope that it will be useful,
+;; XEmacs is distributed in the hope that it will be useful,
 ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
 ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 ;; GNU General Public License for more details.
 
 ;; You should have received a copy of the GNU General Public License
-;; along with GNU Emacs; see the file COPYING.  If not, write to
-;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+;; along with XEmacs; see the file COPYING.  If not, write to the
+;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+;; Boston, MA 02111-1307, USA.
+
+;;; Synched up with: FSF 19.34.
 
 ;;; Commentary: 
+
 ;; This lisp code serves two purposes, both of which involve 
 ;; the translation of various conventions for representing European 
 ;; character sets to ISO 8859-1.
 
-; Net support: 
-; Various conventions exist in Newsgroups on how to represent national 
-; characters. The functions provided here translate these net conventions 
-; to ISO.
-;
-; Calling `iso-german' will turn the net convention for umlauts ("a etc.) 
-; into ISO latin1 umlaute for easy reading.
-; 'iso-spanish' will turn net conventions for representing spanish 
-; to ISO latin1. (Note that accents are omitted in news posts most 
-; of the time, only enye is escaped.)
-
-; TeX support
-; This mode installs hooks which change TeX files to ISO Latin-1 for 
-; simplified editing. When the TeX file is saved, ISO latin1 characters are
-; translated back to escape sequences.
-;
-; An alternative is a TeX style that handles 8 bit ISO files 
-; (available on ftp.vlsivie.tuwien.ac.at in /pub/8bit)  
-; - but these files are difficult to transmit ... so while the net is  
-; still @ 7 bit this may be useful
-
-;; TO DO:
-; The net support should install hooks (like TeX support does) 
-; which recognizes certains news groups and translates all articles from 
-; those groups. 
-;
-; Cover more cases for translation (There is an infinite number of ways to 
-; represent accented characters in TeX)
-
-;; SEE ALSO:
-; If you are interested in questions related to using the ISO 8859-1 
-; characters set (configuring emacs, Unix, etc. to use ISO), then you
-; can get the ISO 8859-1 FAQ via anonymous ftp from 
-; ftp.vlsivie.tuwien.ac.at in /pub/bit/FAQ-ISO-8859-1
+;; Net support: 
+;; Various conventions exist in Newsgroups on how to represent national 
+;; characters. The functions provided here translate these net conventions 
+;; to ISO.
+;;
+;; Calling `iso-german' will turn the net convention for umlauts ("a etc.) 
+;; into ISO latin1 umlauts for easy reading.
+;; 'iso-spanish' will turn net conventions for representing spanish 
+;; to ISO latin1. (Note that accents are omitted in news posts most 
+;; of the time, only enye is escaped.)
+
+;; TeX support
+;; This mode installs hooks which change TeX files to ISO Latin-1 for 
+;; simplified editing. When the TeX file is saved, ISO latin1 characters are
+;; translated back to escape sequences.
+;;
+;; An alternative is a TeX style that handles 8 bit ISO files 
+;; (available on ftp.vlsivie.tuwien.ac.at in /pub/8bit)  
+;; - but these files are difficult to transmit ... so while the net is  
+;; still @ 7 bit this may be useful
+
+;;; TO DO:
+;; The net support should install hooks (like TeX support does) 
+;; which recognizes certain news groups and translates all articles from 
+;; those groups. 
+;;
+;; Cover more cases for translation (There is an infinite number of ways to 
+;; represent accented characters in TeX)
+
+;;; SEE ALSO:
+;; If you are interested in questions related to using the ISO 8859-1 
+;; characters set (configuring emacs, Unix, etc. to use ISO), then you
+;; can get the ISO 8859-1 FAQ via anonymous ftp from 
+;; ftp.vlsivie.tuwien.ac.at in /pub/bit/FAQ-ISO-8859-1
 
 ;;; Code:
 
@@ -682,7 +687,7 @@
 
 (defun iso-fix-tex2iso ()
   "Turn TeX sequences into ISO 8859-1 (aka. ISO Latin-1) characters.
-This function recognices German TeX buffers."
+This function recognizes German TeX buffers."
   (if (or (equal major-mode 'latex-mode)
 	  (equal major-mode 'Latex-mode)) ; AucTeX wants this
       (if (iso-german-tex-p)
--- /opt/xemacs/lisp/iso/iso-insert.el	Wed Jul  5 08:39:03 1995
+++ iso-insert.el	Mon Sep  9 16:18:21 1996
@@ -6,21 +6,24 @@
 ;; Maintainer: FSF
 ;; Keywords: i18n
 
-;; This file is part of GNU Emacs.
+;; This file is part of XEmacs.
 
-;; GNU Emacs is free software; you can redistribute it and/or modify
+;; XEmacs is free software; you can redistribute it and/or modify
 ;; it under the terms of the GNU General Public License as published by
 ;; the Free Software Foundation; either version 2, or (at your option)
 ;; any later version.
 
-;; GNU Emacs is distributed in the hope that it will be useful,
+;; XEmacs is distributed in the hope that it will be useful,
 ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
 ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 ;; GNU General Public License for more details.
 
 ;; You should have received a copy of the GNU General Public License
-;; along with GNU Emacs; see the file COPYING.  If not, write to
-;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+;; along with XEmacs; see the file COPYING.  If not, write to the
+;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+;; Boston, MA 02111-1307, USA.
+
+;;; Synched up with: FSF 19.34.
 
 ;;; Commentary:
 
--- /opt/xemacs/lisp/iso/iso-swed.el	Wed Jul  5 08:39:03 1995
+++ iso-swed.el	Mon Sep  9 16:15:55 1996
@@ -6,21 +6,24 @@
 ;; Maintainer: FSF
 ;; Keywords: i18n
 
-;; This file is part of GNU Emacs.
+;; This file is part of XEmacs.
 
-;; GNU Emacs is free software; you can redistribute it and/or modify
+;; XEmacs is free software; you can redistribute it and/or modify
 ;; it under the terms of the GNU General Public License as published by
 ;; the Free Software Foundation; either version 2, or (at your option)
 ;; any later version.
 
-;; GNU Emacs is distributed in the hope that it will be useful,
+;; XEmacs is distributed in the hope that it will be useful,
 ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
 ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 ;; GNU General Public License for more details.
 
 ;; You should have received a copy of the GNU General Public License
-;; along with GNU Emacs; see the file COPYING.  If not, write to
-;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+;; along with XEmacs; see the file COPYING.  If not, write to the
+;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+;; Boston, MA 02111-1307, USA.
+
+;;; Synched up with: FSF 19.34.
 
 ;;; Commentary:
 
--- /opt/xemacs/lisp/iso/iso-syntax.el	Wed Jul  5 08:39:03 1995
+++ iso-syntax.el	Mon Sep  9 16:21:16 1996
@@ -6,21 +6,24 @@
 ;; Maintainer: FSF
 ;; Keywords: i18n
 
-;; This file is part of GNU Emacs.
+;; This file is part of XEmacs.
 
-;; GNU Emacs is free software; you can redistribute it and/or modify
+;; XEmacs is free software; you can redistribute it and/or modify
 ;; it under the terms of the GNU General Public License as published by
 ;; the Free Software Foundation; either version 2, or (at your option)
 ;; any later version.
 
-;; GNU Emacs is distributed in the hope that it will be useful,
+;; XEmacs is distributed in the hope that it will be useful,
 ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
 ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 ;; GNU General Public License for more details.
 
 ;; You should have received a copy of the GNU General Public License
-;; along with GNU Emacs; see the file COPYING.  If not, write to
-;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+;; along with XEmacs; see the file COPYING.  If not, write to the
+;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+;; Boston, MA 02111-1307, USA.
+
+;;; Synched up with: FSF 19.34.
 
 ;;; Commentary:
 
@@ -97,7 +100,8 @@
   (set-case-syntax 223 "w" downcase)	; small sharp s, German
   (set-case-syntax 247 "_" downcase)	; division sign
   (set-case-syntax 255 "w" downcase)	; small y with diaeresis or umlaut mark
-  (set-standard-case-table downcase))
+  (set-standard-case-table downcase)
+)
 
 (provide 'iso-syntax)
 
--- /opt/xemacs/lisp/iso/swedish.el	Wed Jul  5 08:39:03 1995
+++ swedish.el	Mon Sep  9 15:54:55 1996
@@ -6,21 +6,24 @@
 ;; Maintainer: FSF
 ;; Keywords: i18n
 
-;; This file is part of GNU Emacs.
+;; This file is part of XEmacs.
 
-;; GNU Emacs is free software; you can redistribute it and/or modify
+;; XEmacs is free software; you can redistribute it and/or modify
 ;; it under the terms of the GNU General Public License as published by
 ;; the Free Software Foundation; either version 2, or (at your option)
 ;; any later version.
 
-;; GNU Emacs is distributed in the hope that it will be useful,
+;; XEmacs is distributed in the hope that it will be useful,
 ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
 ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 ;; GNU General Public License for more details.
 
 ;; You should have received a copy of the GNU General Public License
-;; along with GNU Emacs; see the file COPYING.  If not, write to
-;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+;; along with XEmacs; see the file COPYING.  If not, write to the
+;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+;; Boston, MA 02111-1307, USA.
+
+;;; Synched up with: FSF 19.34.
 
 ;;; Code:
 

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 20:29:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA08854 for xemacs-beta-people; Wed, 11 Sep 1996 20:29:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA08851 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 20:29:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA04866 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 20:28:58 -0500 (CDT)
Message-Id: <199609120128.UAA04866@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: web access to ftp site fixed
Date: Wed, 11 Sep 1996 20:28:57 -0500
From: Chuck Thompson <cthomp@xemacs.org>

Obviously there have been few betas and fewer people who access the
ftp site through the web because it's been broken since the 19.14
release.  Fixed now.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 23:17:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA09172 for xemacs-beta-people; Wed, 11 Sep 1996 23:17:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA09169 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 11 Sep 1996 23:17:04 -0500 (CDT)
Received: from gol1.gol.com (root@gol1.gol.com [202.243.48.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA05033 for <xemacs-beta@xemacs.org>; Wed, 11 Sep 1996 23:16:55 -0500 (CDT)
Received: from pentagana (jhod@tky5-187.gol.com [202.243.51.187]) by gol1.gol.com (8.7.5/8.6.9) with SMTP id NAA14565 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 13:16:51 +0900 (JST)
Sender: jhod@gol.com
Message-ID: <3237889A.55E414D9@po.iijnet.or.jp>
Date: Thu, 12 Sep 1996 12:50:50 +0900
From: "Jareth \"JHod\" Hein" <jhod@po.iijnet.or.jp>
Organization: Sonic Software Planning, Japan
X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.17 i586)
MIME-Version: 1.0
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: 20.0b28 mule tests
References: <199609111427.JAA03308@xemacs.cs.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chuck Thompson wrote:
> 
>     Jareth> Is it just me, or is the redisplay code getting slower? In
>     Jareth> a fully font-locked C-mode, scrolling occasionally is a
>     Jareth> real dog.
> 
> Remember that the betas have the extra debug code enabled by default.
> The redisplay engine is probably hit harder by these extra checks than
> almost any other part of the code.
> 

Ya, but then again I have been running since 20.0b17 with --debug
--error-checking=none in order to catch my more stupid errors in playing
with InputManagers, etc. and this version seems quite a bit slower on my
IRIX 5.3 Indigo2 then previously.

Hmmm...
--Jareth


From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 03:27:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id DAA12950 for xemacs-beta-people; Thu, 12 Sep 1996 03:27:57 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id DAA12947 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 03:27:55 -0500 (CDT)
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id DAA28686 for <xemacs-beta@cs.uiuc.edu>; Thu, 12 Sep 1996 03:27:50 -0500 (CDT)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Thu, 12 Sep 1996 10:27:16 +0200
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id KAA14769; Thu, 12 Sep 1996 10:27:03 +0200
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id KAA21535;
          Thu, 12 Sep 1996 10:24:32 +0200
Date: Thu, 12 Sep 1996 10:24:32 +0200
Message-Id: <199609120824.KAA21535@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: mouse drag resizing for horizontally split windows
In-Reply-To: <m2afuxm0rw.fsf@deanna.miranova.com>
References: <199609111428.JAA03315@xemacs.cs.uiuc.edu> <m2afuxm0rw.fsf@deanna.miranova.com>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:
    Chuck> Come on.  You've been a beta tester long enough to know how
    Chuck> well XEmacs feature freezes usually work :-)

    Steven> O.K. :-)

    Steven> I would nominate then the OffiX drag and drop patches
    Steven> posted just after the 19.14 release.  I don't know what
    Steven> CDE is, but I do know I'd love to have drag and drop

I would also like to see this and it should probably easier to include
it now than in later releases, because there are already patches for
XEmacs 19.14. 

-- 

Heiko Muenkel
muenkel@tnt.uni-hannover.de
<A href="http://www.tnt.uni-hannover.de/wiss/muenkel.html">M&uuml;nkel</A>
PGP-KeyID: 0x05CC063D

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 09:06:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA13688 for xemacs-beta-people; Thu, 12 Sep 1996 09:06:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA13685 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 09:06:58 -0500 (CDT)
Received: from eik (eik.ii.uib.no [129.177.16.3]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA05601 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 09:06:54 -0500 (CDT)
Received: from haukugle.ii.uib.no (haukugle) by eik with SMTP id AA00108
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Thu, 12 Sep 1996 16:06:48 +0200
Received: by haukugle.ii.uib.no; (5.65/1.1.8.2/02Mar95-0520PM)
	id AA17687; Thu, 12 Sep 1996 16:06:44 +0200
Sender: ketil@ii.uib.no
To: xemacs-beta@xemacs.org
Subject: Compile FAILURE of 15b1 on Linux/Alpha
From: Ketil Z Malde <ketil@ii.uib.no>
Date: 12 Sep 1996 16:06:41 +0200
Message-Id: <KETIL-eg3f0nesjy.fsf@haukugle.ii.uib.no>
Lines: 40
X-Mailer: Gnus v5.2.25/XEmacs 19.14


Hi,

don't know if this has been mentioned, but I noticed the following
problem trying to compile xemacs-19.15b1 on a Digital Mulita/UDB Alpha
box with Linux on it, all fairly recent versions of stuff (compilers
etc)

Here's what I got:

    make[1]: Entering directory `/local/src/xemacs-19.15-b1/src'
    gcc -c -Demacs -DHAVE_CONFIG_H  -I.        -I/local/src/xemacs-19.15-b1/src     -DFUNCPROTO=11 -DNARROWPROTO -D_BSD_SOURCE           -I/usr/X11R6/include           -I/local/src/xemacs-19.15-b1/src/../lwlib    -Wall -O4 gmalloc.c
    gmalloc.c:1300: conflicting types for `__sbrk'
    /usr/include/unistd.h:605: previous declaration of `__sbrk'
    make[1]: *** [gmalloc.o] Error 1
    make[1]: Leaving directory `/local/src/xemacs-19.15-b1/src'
    make: *** [src] Error 2

Here are the relevant lines from unistd.h:

[root@heilo src]# cat -n /usr/include/unistd.h | grep 60\[0-9\]
   600
   601  #include <sys/types.h>
   602
   603  extern int      __brk __P ((void* __end_data_segment));
   604  extern int      brk __P ((void* __end_data_segment));
   605  extern void*    __sbrk __P ((ptrdiff_t __increment));
   606  extern void*    sbrk __P ((ptrdiff_t __increment));
   607
   608  extern char*    crypt __P((__const char *__key, __const char *__salt));
   609  extern void     encrypt __P((char __block[64], int __edflag));

Now don't go away, while I comment out the line in gmalloc.c, and try a
recompile...well, the compilation continues, so it might work.

Hope this has been of some use, and drop me a mail if you need any
further information (I usually just skim this list, however a followup
to this has a 99% chance of being noticed :-)

~kzm

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 10:41:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA13957 for xemacs-beta-people; Thu, 12 Sep 1996 10:41:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA13954 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 10:41:31 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA05905 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 10:41:26 -0500 (CDT)
Received: from mordor.rsn.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA259902880; Thu, 12 Sep 1996 08:41:20 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id KAA02597; Thu, 12 Sep 1996 10:46:08 -0500 (CDT)
Date: Thu, 12 Sep 1996 10:46:08 -0500 (CDT)
Message-Id: <199609121546.KAA02597@mordor.rsn.hp.com>
From: Shane Holder <holder@mordor.rsn.hp.com>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.15 on HP/UX and buffered keys.


There's under problem on HP/UX with keybuffering. If you pull up a
large file 20000 lines will do, and hold down the page-down key, until
about 1/4 of the file has paged, then release the key, it will
continue to page for quite a while.  I know this is true on HPUX
10.10, and 10.20.

Darryl Okahata submitted a fix to sysdep.c on the comp.emacs.xemacs
group, I've included it here.  I think it should be considered for
inclusion in 19.15.

He has also made changes to some other files for the 300 series.  I
haven't verified these patches, but several other people are using
them internally.  The diffs are against 19.14.

Shane

*** xemacs-19.14.orig/src/ecrt0.c	Sun Mar 31 16:20:50 1996
--- xemacs-19.14/src/ecrt0.c	Tue Sep 10 15:38:12 1996
***************
*** 521,526 ****
--- 521,527 ----
  	asm("	comm	float_soft, 4");
  	asm("	comm	flag_68881, 4");
  	asm("	comm	flag_68010, 4");
+ 	asm("	comm	flag_68040, 4");
  	asm("	comm	flag_fpa, 4");
  
  #endif /* new hp assembler */
*** xemacs-19.14.orig/src/hpplay.c	Sun Mar 31 16:17:56 1996
--- xemacs-19.14/src/hpplay.c	Mon Jun 24 17:34:39 1996
***************
*** 106,122 ****
  
      playParams.priority = APriorityNormal;          /* normal priority */
  
-     speaker = (char *) (string_data (XSYMBOL (Vhp_play_speaker)->name));
-     
      /*
!      * setup the playback parameters
       */
  
!     /* speaker selection */
!     if ( strcmp(speaker,"external") == 0 ) {
!       gainEntry.u.o.out_dst = AODTMonoJack;
!     } else {
!       gainEntry.u.o.out_dst = AODTMonoIntSpeaker;
      }
  
      gainEntry.u.o.out_ch = AOCTMono;
--- 106,136 ----
  
      playParams.priority = APriorityNormal;          /* normal priority */
  
      /*
!      * We can't signal an error, because all h*ll would break loose if
!      * we did.
       */
+     if (SYMBOLP (Vhp_play_speaker))
+     {
+ 	speaker = (char *) (string_data (XSYMBOL (Vhp_play_speaker)->name));
+     
+ 	/*
+ 	 * setup the playback parameters
+ 	 */
  
! 	/* speaker selection */
! 	if ( strcmp(speaker,"external") == 0 ) {
! 	    gainEntry.u.o.out_dst = AODTMonoJack;
! 	} else {
! 	    gainEntry.u.o.out_dst = AODTMonoIntSpeaker;
! 	}
!     }
!     else
!     {
! 	/*
! 	 * Quietly revert to the internal speaker
! 	 */
! 	gainEntry.u.o.out_dst = AODTMonoIntSpeaker;
      }
  
      gainEntry.u.o.out_ch = AOCTMono;
*** xemacs-19.14.orig/src/sysdep.c	Thu Jun 20 10:46:56 1996
--- xemacs-19.14/src/sysdep.c	Thu Jul 11 09:59:56 1996
***************
*** 908,914 ****
  {
    int filedesc = DEVICE_INFD (d);
  
! #if defined (I_SETSIG)
    ioctl (filedesc, I_GETSIG, &DEVICE_OLD_SIGIO_FLAG (d));
    DEVICE_OLD_SIGIO_FLAG (d) &= ~S_INPUT;
  #elif defined (FASYNC)
--- 908,914 ----
  {
    int filedesc = DEVICE_INFD (d);
  
! #if defined (I_SETSIG) && !defined(HPUX10)
    ioctl (filedesc, I_GETSIG, &DEVICE_OLD_SIGIO_FLAG (d));
    DEVICE_OLD_SIGIO_FLAG (d) &= ~S_INPUT;
  #elif defined (FASYNC)
***************
*** 929,936 ****
  #ifdef HAVE_WINDOW_SYSTEM
      else if (!DEVICE_STREAM_P (d))
        {
- 	/* Process group for socket should be -pid for delivery to self. */
- 	owner = -owner;
  	ioctl_status = ioctl (filedesc, SIOCGPGRP,
  			      &DEVICE_OLD_FCNTL_OWNER (d));
  	ioctl_status = ioctl (filedesc, SIOCSPGRP, &owner);
--- 929,934 ----
***************
*** 965,972 ****
  #ifdef HAVE_WINDOW_SYSTEM
      else if (!DEVICE_STREAM_P (d))
        {
- 	/* Process group for socket should be -pid for delivery to self. */
- 	owner = -owner;
  	ioctl_status = ioctl (filedesc, SIOCSPGRP,
  			      &DEVICE_OLD_FCNTL_OWNER (d));
        }
--- 963,968 ----
***************
*** 987,993 ****
    if (d->sigio_enabled)
      return;
  
! #if defined (I_SETSIG)
    ioctl (filedesc, I_SETSIG, DEVICE_OLD_SIGIO_FLAG (d) | S_INPUT);
  #elif defined (FASYNC)
    fcntl (filedesc, F_SETFL, DEVICE_OLD_SIGIO_FLAG (d) | FASYNC);
--- 983,989 ----
    if (d->sigio_enabled)
      return;
  
! #if defined (I_SETSIG) && !defined(HPUX10)
    ioctl (filedesc, I_SETSIG, DEVICE_OLD_SIGIO_FLAG (d) | S_INPUT);
  #elif defined (FASYNC)
    fcntl (filedesc, F_SETFL, DEVICE_OLD_SIGIO_FLAG (d) | FASYNC);
***************
*** 999,1005 ****
  	 use the following crud to do the appropriate thing. */
      int on = 1;
      int ioctl_status;		/* ####DG: check if IOCTL succeeds here. */
-     int socket_pgroup = -getpid ();
  
      if (DEVICE_TTY_P (d))
        {
--- 995,1000 ----
***************
*** 1009,1015 ****
      else if (!DEVICE_STREAM_P (d))
        {
  	ioctl_status = ioctl (filedesc, FIOASYNC, &on);
- 	ioctl_status = ioctl (filedesc, SIOCSPGRP, &socket_pgroup);
        }
  #endif
    }
--- 1004,1009 ----
***************
*** 1037,1043 ****
    if (!d->sigio_enabled)
      return;
  
! #if defined (I_SETSIG)
    ioctl (filedesc, I_SETSIG, DEVICE_OLD_SIGIO_FLAG (d));
  #elif defined (FASYNC)
    fcntl (filedesc, F_SETFL, DEVICE_OLD_SIGIO_FLAG (d));
--- 1031,1037 ----
    if (!d->sigio_enabled)
      return;
  
! #if defined (I_SETSIG) && !defined(HPUX10)
    ioctl (filedesc, I_SETSIG, DEVICE_OLD_SIGIO_FLAG (d));
  #elif defined (FASYNC)
    fcntl (filedesc, F_SETFL, DEVICE_OLD_SIGIO_FLAG (d));
***************
*** 1049,1055 ****
  	 use the following crud to do the appropriate thing. */
  
      int off = 0;
-     int socket_pgroup = 0;
      int ioctl_status;
  
      /* See comment for request_sigio_on_device */
--- 1043,1048 ----
***************
*** 1061,1067 ****
      else 
        {
  	ioctl_status = ioctl (filedesc, FIOASYNC, &off);
- 	ioctl_status = ioctl (filedesc, SIOCSPGRP, &socket_pgroup);
        }
    }
  #elif defined (FIOASYNC)
--- 1054,1059 ----
*** xemacs-19.14.orig/src/unexhp9k3.c	Sun Mar 31 16:20:06 1996
--- xemacs-19.14/src/unexhp9k3.c	Mon Jun 24 12:23:10 1996
***************
*** 41,46 ****
--- 41,49 ----
  #include <string.h>
  #include <stdio.h>
  #include <signal.h>
+ #ifdef __hp9000s300
+ # include </usr/include/debug.h>
+ #endif
  #include <a.out.h>
  #include <unistd.h>
  #include <ctype.h>
***************
*** 382,387 ****
--- 385,398 ----
      unexec_pad (new_fd, old_dataddr - old_hdr.a_text);
  
      /*
+      * Update debug header spoo
+      */
+     if (new_hdr.a_extension > 0)
+     {
+ 	new_hdr.a_extension += LESYM_OFFSET(new_hdr) - LESYM_OFFSET(old_hdr);
+     }
+ 
+     /*
       * go back and write the new header.
       */
      unexec_write (new_fd, 0, (char *) &new_hdr, sizeof (new_hdr));
***************
*** 448,455 ****
  #endif
      unexec_copy (new_fd, old_fd, old_mcaloff, new_mcaloff,
                   old_buf.st_size - old_mcaloff);
    }
!      
       
    /* make the output file executable -- then quit */
    unexec_fchmod (new_fd, 0755);
--- 459,501 ----
  #endif
      unexec_copy (new_fd, old_fd, old_mcaloff, new_mcaloff,
                   old_buf.st_size - old_mcaloff);
+ 
+     {
+ 	long			curpos, offset;
+ 	struct _debug_header	dhdr;
+ 	int			new_header_delta;
+ 
+ 	new_header_delta = LESYM_OFFSET(new_hdr) - LESYM_OFFSET(old_hdr);
+ 	if ((new_header_delta > 0) &&
+ 	    ((offset = EXT_OFFSET(old_hdr)) > 0))
+ 	{
+ 	    curpos = lseek(new_fd, 0, SEEK_CUR);
+ 	    lseek(old_fd, offset, 0);
+ 	    if (read(old_fd, &dhdr, sizeof(dhdr)) == sizeof(dhdr))
+ 	    {
+ 		dhdr.header_offset += new_header_delta;
+ 		dhdr.gntt_offset += new_header_delta;
+ 		dhdr.lntt_offset += new_header_delta;
+ 		dhdr.slt_offset += new_header_delta;
+ 		dhdr.vt_offset += new_header_delta;
+ 		dhdr.xt_offset += new_header_delta;
+ 		lseek(new_fd, EXT_OFFSET(new_hdr), SEEK_SET);
+ 		if (write(new_fd, &dhdr, sizeof(dhdr)) != sizeof(dhdr))
+ 		{
+ 		    unexec_error("Unable to write debug information to \"%s\"\n",
+ 				 1, new_name);
+ 		}
+ 		lseek(new_fd, curpos, SEEK_SET);
+ 	    }
+ 	    else
+ 	    {
+ 		unexec_error("Unable to read debug information from \"%s\"\n",
+ 			     1, old_name);
+ 	    }
+ 	}
+     }
    }
!   
       
    /* make the output file executable -- then quit */
    unexec_fchmod (new_fd, 0755);
*** xemacs-19.14.orig/src/s/hpux9.h	Sat Jun  1 17:11:52 1996
--- xemacs-19.14/src/s/hpux9.h	Wed Jul 10 11:55:15 1996
***************
*** 31,37 ****
  #define C_SWITCH_SYSTEM -Wp,-H200000 -D_BSD
  */
  #undef C_SWITCH_SYSTEM
! #define C_SWITCH_SYSTEM -Ae -Wp,-H100000
  /* XEmacs: commented out
  #else
  #define C_SWITCH_SYSTEM -D_BSD
--- 31,41 ----
  #define C_SWITCH_SYSTEM -Wp,-H200000 -D_BSD
  */
  #undef C_SWITCH_SYSTEM
! # ifdef __hp9000s300
! #  define C_SWITCH_SYSTEM -Aa -D_HPUX_SOURCE
! # else
! #  define C_SWITCH_SYSTEM -Ae -Wp,-H100000
! # endif
  /* XEmacs: commented out
  #else
  #define C_SWITCH_SYSTEM -D_BSD
*** xemacs-19.14.orig/src/s/hpux9shr.h	Sat Jun  1 17:11:53 1996
--- xemacs-19.14/src/s/hpux9shr.h	Mon Jul  1 22:54:09 1996
***************
*** 5,11 ****
  #define ORDINARY_LINK
  
  /* XEmacs change */
! /* Only support for hp9000s300 currently */
  #if !defined(__hp9000s300)
  /* #ifndef USE_GCC */
  #define HPUX_USE_SHLIBS
--- 5,11 ----
  #define ORDINARY_LINK
  
  /* XEmacs change */
! /* Only support for hp9000s700 currently */
  #if !defined(__hp9000s300)
  /* #ifndef USE_GCC */
  #define HPUX_USE_SHLIBS


From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 14:40:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA14805 for xemacs-beta-people; Thu, 12 Sep 1996 14:40:25 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14802 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 14:40:23 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA06527 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 14:40:19 -0500 (CDT)
Received: from mordor.rsn.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA080267219; Thu, 12 Sep 1996 12:40:19 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id OAA05327; Thu, 12 Sep 1996 14:45:05 -0500 (CDT)
Date: Thu, 12 Sep 1996 14:45:05 -0500 (CDT)
Message-Id: <199609121945.OAA05327@mordor.rsn.hp.com>
From: Shane Holder <holder@mordor.rsn.hp.com>
To: xemacs-beta@xemacs.org
Subject: Xemacs and Edebug


I've got a really weird problem.  I've got an interface to cscope that
I am trying to debug.  I'd run eval-defun with a prefix arg to setup
edebug on a function, and when I ran the function, it wouldn't do
*anything*.  I narrowed it down to a parameter I was setting for a
frame, I set "unsplittable" to t.  When I took this out of my frame
parameters, edebug worked just fine.  

The interesting thing is that the function I was "edebugging" didn't
use the variable in any way, and it doesn't call any functions that
use the variable.

Any suggestions?

Shane


From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 14:50:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA14853 for xemacs-beta-people; Thu, 12 Sep 1996 14:50:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14850 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 14:49:59 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA06559 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 14:49:53 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id MAA24615; Thu, 12 Sep 1996 12:48:37 -0700
Received: from zeppo.East.Sun.COM by East.Sun.COM (5.x/SMI-5.3)
	id AA22070; Thu, 12 Sep 1996 15:48:19 -0400
Received: by zeppo.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id PAA13845; Thu, 12 Sep 1996 15:47:40 -0400
Date: Thu, 12 Sep 1996 15:47:40 -0400
From: gra@zeppo.East.Sun.COM (Gary Adams - Sun Microsystems Labs BOS)
Message-Id: <199609121947.PAA13845@zeppo.East.Sun.COM>
To: thiessel@rhrk.uni-kl.de
Subject: Re: XEmacs 20.0 beta28
Cc: xemacs-beta@xemacs.org
X-Sun-Charset: US-ASCII


> From xemacs-beta-request@cs.uiuc.edu  Wed Sep 11 03:29:47 1996
> Date: Wed, 11 Sep 96 09:24 CETDST
> From: thiessel@rhrk.uni-kl.de
> To: Laura Harding <harding@sde.hp.com>
> Cc: xemacs-beta@xemacs.org
> Subject: Re: XEmacs 20.0 beta28
> 
> Tried --with-mule ?!?! On hpux 9.05 I ran into
> 
> Make:  Don't know how to make /disk2/stuff/xemacs-20.0-b28/src/../lisp/mule/vietnamese-hooks-2.elc.  Stop.
> 
> 

Same problem shows up in the build on Solaris 2.5.1.
I got around the problem running "make all-elc".

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 13:32:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA14649 for xemacs-beta-people; Thu, 12 Sep 1996 13:32:41 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA14646 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 13:32:40 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA16278 for <xemacs-beta@cs.uiuc.edu>; Thu, 12 Sep 1996 13:32:26 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA07720; Thu, 12 Sep 1996 11:36:01 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: `Somebody needs to port sh-script.el to XEmacs'
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Sep_12_11:35:56_1996-1"
Content-Transfer-Encoding: 7bit
Date: 12 Sep 1996 11:35:57 -0700
Message-ID: <m23f0ninsi.fsf@deanna.miranova.com>
Lines: 1668
X-Mailer: Red Gnus v0.32/XEmacs 19.15

--Multipart_Thu_Sep_12_11:35:56_1996-1
Content-Type: text/plain; charset=US-ASCII

There doesn't appear to be a lot of porting required other than a
minor spelling correction.  sh-script.el requires the dependent
package executable.el as well.


--Multipart_Thu_Sep_12_11:35:56_1996-1
Content-Type: application/octet-stream; type=emacs-lisp
Content-Disposition: attachment; filename="sh-script.el"
Content-Transfer-Encoding: 7bit

;;; sh-script.el --- shell-script editing commands for Emacs

;; Copyright (C) 1993, 1994, 1995, 1996 by Free Software Foundation, Inc.

;; Author: Daniel.Pfeiffer@Informatik.START.dbp.de, fax (+49 69) 7588-2389
;; Version: 2.0e
;; Maintainer: FSF
;; Keywords: languages, unix

;; This file is part of XEmacs.

;; XEmacs is free software; you can redistribute it and/or modify it
;; under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; XEmacs is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with XEmacs; see the file COPYING.  If not, write to the Free
;; Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
;; 02111-1307, USA.

;;; Synched up with: FSF 19.34.

;;; Commentary:

;; Major mode for editing shell scripts.  Bourne, C and rc shells as well
;; as various derivatives are supported and easily derived from.  Structured
;; statements can be inserted with one command or abbrev.  Completion is
;; available for filenames, variables known from the script, the shell and
;; the environment as well as commands.

;;; Known Bugs:

;; - In Bourne the keyword `in' is not anchored to case, for, select ...
;; - Variables in `"' strings aren't fontified because there's no way of
;;   syntactically distinguishing those from `'' strings.

;;; Code:

;; page 1:	variables and settings
;; page 2:	mode-command and utility functions
;; page 3:	statement syntax-commands for various shells
;; page 4:	various other commands

(require 'executable)

(defvar sh-ancestor-alist
  '((ash . sh)
    (bash . jsh)
    (dtksh . ksh)
    (es . rc)
    (itcsh . tcsh)
    (jcsh . csh)
    (jsh . sh)
    (ksh . ksh88)
    (ksh88 . jsh)
    (oash . sh)
    (pdksh . ksh88)
    (posix . sh)
    (tcsh . csh)
    (wksh . ksh88)
    (wsh . sh)
    (zsh . ksh88))
  "*Alist showing the direct ancestor of various shells.
This is the basis for `sh-feature'.  See also `sh-alias-alist'.
By default we have the following three hierarchies:

csh		C Shell
  jcsh		C Shell with Job Control
  tcsh		Toronto C Shell
    itcsh	? Toronto C Shell
rc		Plan 9 Shell
  es		Extensible Shell
sh		Bourne Shell
  ash		? Shell
  jsh		Bourne Shell with Job Control
    bash	GNU Bourne Again Shell
    ksh88	Korn Shell '88
      ksh	Korn Shell '93
	dtksh	CDE Desktop Korn Shell
      pdksh	Public Domain Korn Shell
      wksh	Window Korn Shell
      zsh	Z Shell
  oash		SCO OA (curses) Shell
  posix		IEEE 1003.2 Shell Standard
  wsh		? Shell")


(defvar sh-alias-alist
  ;; XEmacs: Linux is spelled `linux'
  (nconc (if (eq system-type 'linux)
	     '((csh . tcsh)
	       (ksh . pdksh)))
	 ;; for the time being
	 '((ksh . ksh88)
	   (sh5 . sh)))
  "*Alist for transforming shell names to what they really are.
Use this where the name of the executable doesn't correspond to the type of
shell it really is.")


(defvar sh-shell-file (or (getenv "SHELL") "/bin/sh")
  "*The executable file name for the shell being programmed.")


(defvar sh-shell-arg
  ;; bash does not need any options when run in a shell script,
  '((bash)
    (csh . "-f")
    (pdksh)
    ;; Bill_Mann@praxisint.com says -p with ksh can do harm.
    (ksh88)
    ;; -p means don't initialize functions from the environment.
    (rc . "-p")
    ;; Someone proposed -motif, but we don't want to encourage
    ;; use of a non-free widget set.
    (wksh)
    ;; -f means don't run .zshrc.
    (zsh . "-f"))
  "*Single argument string for the magic number.  See `sh-feature'.")

(defvar sh-shell-variables nil
  "Alist of shell variable names that should be included in completion.
These are used for completion in addition to all the variables named
in `process-environment'.  Each element looks like (VAR . VAR), where
the car and cdr are the same symbol.")

(defvar sh-shell-variables-initialized nil
  "Non-nil if `sh-shell-variables' is initialized.")

(defun sh-canonicalize-shell (shell)
  "Convert a shell name SHELL to the one we should handle it as."
  (or (symbolp shell)
      (setq shell (intern shell)))
  (or (cdr (assq shell sh-alias-alist))
      shell))

(defvar sh-shell (sh-canonicalize-shell (file-name-nondirectory sh-shell-file))
  "The shell being programmed.  This is set by \\[sh-set-shell].")

;;; I turned off this feature because it doesn't permit typing commands
;;; in the usual way without help.
;;;(defvar sh-abbrevs
;;;  '((csh eval sh-abbrevs shell
;;;	 "switch" 'sh-case
;;;	 "getopts" 'sh-while-getopts)

;;;    (es eval sh-abbrevs shell
;;;	"function" 'sh-function)

;;;    (ksh88 eval sh-abbrevs sh
;;;	   "select" 'sh-select)

;;;    (rc eval sh-abbrevs shell
;;;	"case" 'sh-case
;;;	"function" 'sh-function)

;;;    (sh eval sh-abbrevs shell
;;;	"case" 'sh-case
;;;	"function" 'sh-function
;;;	"until" 'sh-until
;;;	"getopts" 'sh-while-getopts)

;;;    ;; The next entry is only used for defining the others
;;;    (shell "for" sh-for
;;;	   "loop" sh-indexed-loop
;;;	   "if" sh-if
;;;	   "tmpfile" sh-tmp-file
;;;	   "while" sh-while)

;;;    (zsh eval sh-abbrevs ksh88
;;;	 "repeat" 'sh-repeat))
;;;  "Abbrev-table used in Shell-Script mode.  See `sh-feature'.
;;;Due to the internal workings of abbrev tables, the shell name symbol is
;;;actually defined as the table for the like of \\[edit-abbrevs].")



(defvar sh-mode-syntax-table
  '((csh eval identity sh)
    (sh eval sh-mode-syntax-table ()
	;; #'s meanings depend on context which can't be expressed here
	;; ?\# "<"
	;; ?\^l ">#"
	;; ?\n ">#"
	?\" "\"\""
	?\' "\"'"
	?\` ".`"
	?$ "_"
	?! "_"
	?% "_"
	?: "_"
	?. "_"
	?^ "_"
	?~ "_")
    (rc eval sh-mode-syntax-table sh
	?\" "_"
	?\` "."))
  "Syntax-table used in Shell-Script mode.  See `sh-feature'.")



(defvar sh-mode-map
  (let ((map (make-sparse-keymap))
	(menu-map (make-sparse-keymap "Insert")))
    (define-key map "\C-c(" 'sh-function)
    (define-key map "\C-c\C-w" 'sh-while)
    (define-key map "\C-c\C-u" 'sh-until)
    (define-key map "\C-c\C-t" 'sh-tmp-file)
    (define-key map "\C-c\C-s" 'sh-select)
    (define-key map "\C-c\C-r" 'sh-repeat)
    (define-key map "\C-c\C-o" 'sh-while-getopts)
    (define-key map "\C-c\C-l" 'sh-indexed-loop)
    (define-key map "\C-c\C-i" 'sh-if)
    (define-key map "\C-c\C-f" 'sh-for)
    (define-key map "\C-c\C-c" 'sh-case)

    (define-key map "=" 'sh-assignment)
    (define-key map "\C-c+" 'sh-add)
    (define-key map "\C-\M-x" 'sh-execute-region)
    (define-key map "\C-c\C-x" 'executable-interpret)
    (define-key map "<" 'sh-maybe-here-document)
    (define-key map "(" 'skeleton-pair-insert-maybe)
    (define-key map "{" 'skeleton-pair-insert-maybe)
    (define-key map "[" 'skeleton-pair-insert-maybe)
    (define-key map "'" 'skeleton-pair-insert-maybe)
    (define-key map "`" 'skeleton-pair-insert-maybe)
    (define-key map "\"" 'skeleton-pair-insert-maybe)

    (define-key map "\t" 'sh-indent-line)
    (substitute-key-definition 'complete-tag 'comint-dynamic-complete
			       map (current-global-map))
    (substitute-key-definition 'newline-and-indent 'sh-newline-and-indent
			       map (current-global-map))
    (substitute-key-definition 'delete-backward-char
			       'backward-delete-char-untabify
			       map (current-global-map))
    (define-key map "\C-c:" 'sh-set-shell)
    (substitute-key-definition 'beginning-of-defun
			       'sh-beginning-of-compound-command
			       map (current-global-map))
    (substitute-key-definition 'backward-sentence 'sh-beginning-of-command
			       map (current-global-map))
    (substitute-key-definition 'forward-sentence 'sh-end-of-command
			       map (current-global-map))
    (define-key map [menu-bar insert] (cons "Insert" menu-map))
    (define-key menu-map [sh-while]	'("While Loop" . sh-while))
    (define-key menu-map [sh-until]	'("Until Loop" . sh-until))
    (define-key menu-map [sh-tmp-file]	'("Temporary File" . sh-tmp-file))
    (define-key menu-map [sh-select]	'("Select Statement" . sh-select))
    (define-key menu-map [sh-repeat]	'("Repeat Loop" . sh-repeat))
    (define-key menu-map [sh-while-getopts]
					'("Options Loop" . sh-while-getopts))
    (define-key menu-map [sh-indexed-loop]
					'("Indexed Loop" . sh-indexed-loop))
    (define-key menu-map [sh-if]	'("If Statement" . sh-if))
    (define-key menu-map [sh-for]	'("For Loop" . sh-for))
    (define-key menu-map [sh-case]	'("Case Statement" . sh-case))
    map)
  "Keymap used in Shell-Script mode.")



(defvar sh-dynamic-complete-functions
  '(shell-dynamic-complete-environment-variable
    shell-dynamic-complete-command
    comint-dynamic-complete-filename)
  "*Functions for doing TAB dynamic completion.")


(defvar sh-require-final-newline
  '((csh . t)
    (pdksh . t)
    (rc eval . require-final-newline)
    (sh eval . require-final-newline))
  "*Value of `require-final-newline' in Shell-Script mode buffers.
See `sh-feature'.")


(defvar sh-comment-prefix
  '((csh . "\\(^\\|[^$]\\|\\$[^{]\\)")
    (rc eval identity csh)
    (sh . "\\(^\\|[ \t|&;()]\\)"))
  "*Regexp matching what may come before a comment `#'.
This must contain one \\(grouping\\) since it is the basis for fontifying
comments as well as for `comment-start-skip'.
See `sh-feature'.")


(defvar sh-assignment-regexp
  '((csh . "\\<\\([a-zA-Z0-9_]+\\)\\(\\[.+\\]\\)?[ \t]*[-+*/%^]?=")
    ;; actually spaces are only supported in let/(( ... ))
    (ksh88 . "\\<\\([a-zA-Z0-9_]+\\)\\(\\[.+\\]\\)?[ \t]*\\([-+*/%&|~^]\\|<<\\|>>\\)?=")
    (rc . "\\<\\([a-zA-Z0-9_*]+\\)[ \t]*=")
    (sh . "\\<\\([a-zA-Z0-9_]+\\)="))
  "*Regexp for the variable name and what may follow in an assignment.
First grouping matches the variable name.  This is upto and including the `='
sign.  See `sh-feature'.")


(defvar sh-indentation 4
  "The width for further indentation in Shell-Script mode.")


(defvar sh-remember-variable-min 3
  "*Don't remember variables less than this length for completing reads.")


(defvar sh-header-marker nil
  "When non-`nil' is the end of header for prepending by \\[sh-execute-region].
That command is also used for setting this variable.")


(defvar sh-beginning-of-command
  "\\([;({`|&]\\|\\`\\|[^\\]\n\\)[ \t]*\\([/~a-zA-Z0-9:]\\)"
  "*Regexp to determine the beginning of a shell command.
The actual command starts at the beginning of the second \\(grouping\\).")


(defvar sh-end-of-command
  "\\([/~a-zA-Z0-9:]\\)[ \t]*\\([;#)}`|&]\\|$\\)"
  "*Regexp to determine the end of a shell command.
The actual command ends at the end of the first \\(grouping\\).")



(defvar sh-here-document-word "EOF"
  "Word to delimit here documents.")

(defvar sh-test
  '((sh "[  ]" . 3)
    (ksh88 "[[  ]]" . 4))
  "Initial input in Bourne if, while and until skeletons.  See `sh-feature'.")


(defvar sh-builtins
  '((bash eval sh-append posix
	  "alias" "bg" "bind" "builtin" "declare" "dirs" "enable" "fc" "fg"
	  "help" "history" "jobs" "kill" "let" "local" "popd" "pushd" "source"
	  "suspend" "typeset" "unalias")

    ;; The next entry is only used for defining the others
    (bourne eval sh-append shell
	    "eval" "export" "getopts" "newgrp" "pwd" "read" "readonly"
	    "times" "ulimit")

    (csh eval sh-append shell
	 "alias" "chdir" "glob" "history" "limit" "nice" "nohup" "rehash"
	 "setenv" "source" "time" "unalias" "unhash")

    (dtksh eval identity wksh)

    (es "access" "apids" "cd" "echo" "eval" "false" "let" "limit" "local"
	"newpgrp" "result" "time" "umask" "var" "vars" "wait" "whatis")

    (jsh eval sh-append sh
	 "bg" "fg" "jobs" "kill" "stop" "suspend")

    (jcsh eval sh-append csh
	 "bg" "fg" "jobs" "kill" "notify" "stop" "suspend")

    (ksh88 eval sh-append bourne
	   "alias" "bg" "false" "fc" "fg" "jobs" "kill" "let" "print" "time"
	   "typeset" "unalias" "whence")

    (oash eval sh-append sh
	  "checkwin" "dateline" "error" "form" "menu" "newwin" "oadeinit"
	  "oaed" "oahelp" "oainit" "pp" "ppfile" "scan" "scrollok" "wattr"
	  "wclear" "werase" "win" "wmclose" "wmmessage" "wmopen" "wmove"
	  "wmtitle" "wrefresh")

    (pdksh eval sh-append ksh88
	   "bind")

    (posix eval sh-append sh
	   "command")

    (rc "builtin" "cd" "echo" "eval" "limit" "newpgrp" "shift" "umask" "wait"
	"whatis")

    (sh eval sh-append bourne
	"hash" "test" "type")

    ;; The next entry is only used for defining the others
    (shell "cd" "echo" "eval" "set" "shift" "umask" "unset" "wait")

    (wksh eval sh-append ksh88
	  "Xt[A-Z][A-Za-z]*")

    (zsh eval sh-append ksh88
	 "autoload" "bindkey" "builtin" "chdir" "compctl" "declare" "dirs"
	 "disable" "disown" "echotc" "enable" "functions" "getln" "hash"
	 "history" "integer" "limit" "local" "log" "popd" "pushd" "r"
	 "readonly" "rehash" "sched" "setopt" "source" "suspend" "true"
	 "ttyctl" "type" "unfunction" "unhash" "unlimit" "unsetopt" "vared"
	 "which"))
  "*List of all shell builtins for completing read and fontification.
Note that on some systems not all builtins are available or some are
implemented as aliases.  See `sh-feature'.")



(defvar sh-leading-keywords
  '((csh "else")

    (es "true" "unwind-protect" "whatis")

    (rc "else")

    (sh "do" "elif" "else" "if" "then" "trap" "type" "until" "while"))
  "*List of keywords that may be immediately followed by a builtin or keyword.
Given some confusion between keywords and builtins depending on shell and
system, the distinction here has been based on whether they influence the
flow of control or syntax.  See `sh-feature'.")


(defvar sh-other-keywords
  '((bash eval sh-append bourne
	  "bye" "logout")

    ;; The next entry is only used for defining the others
    (bourne eval sh-append shell
	    "done" "esac" "fi" "for" "function" "in" "return")

    (csh eval sh-append shell
	 "breaksw" "default" "end" "endif" "endsw" "foreach" "goto"
	 "if" "logout" "onintr" "repeat" "switch" "then" "while")

    (es "break" "catch" "exec" "exit" "fn" "for" "forever" "fork" "if"
	"return" "throw" "while")

    (ksh88 eval sh-append bourne
	   "select")

    (rc "break" "case" "exec" "exit" "fn" "for" "if" "in" "return" "switch"
	"while")

    ;; The next entry is only used for defining the others
    (shell "break" "case" "continue" "exec" "exit")

    (zsh eval sh-append bash
	 "select"))
  "*List of keywords not in `sh-leading-keywords'.
See `sh-feature'.")



(defvar sh-variables
  '((bash eval sh-append sh
	  "allow_null_glob_expansion" "auto_resume" "BASH" "BASH_VERSION"
	  "cdable_vars" "ENV" "EUID" "FCEDIT" "FIGNORE" "glob_dot_filenames"
	  "histchars" "HISTFILE" "HISTFILESIZE" "history_control" "HISTSIZE"
	  "hostname_completion_file" "HOSTTYPE" "IGNOREEOF" "ignoreeof"
	  "LINENO" "MAIL_WARNING" "noclobber" "nolinks" "notify"
	  "no_exit_on_failed_exec" "NO_PROMPT_VARS" "OLDPWD" "OPTERR" "PPID"
	  "PROMPT_COMMAND" "PS4" "pushd_silent" "PWD" "RANDOM" "REPLY"
	  "SECONDS" "SHLVL" "TMOUT" "UID")

    (csh eval sh-append shell
	 "argv" "cdpath" "child" "echo" "histchars" "history" "home"
	 "ignoreeof" "mail" "noclobber" "noglob" "nonomatch" "path" "prompt"
	 "shell" "status" "time" "verbose")

    (es eval sh-append shell
	"apid" "cdpath" "CDPATH" "history" "home" "ifs" "noexport" "path"
	"pid" "prompt" "signals")

    (jcsh eval sh-append csh
	 "notify")

    (ksh88 eval sh-append sh
	   "ENV" "ERRNO" "FCEDIT" "FPATH" "HISTFILE" "HISTSIZE" "LINENO"
	   "OLDPWD" "PPID" "PS3" "PS4" "PWD" "RANDOM" "REPLY" "SECONDS"
	   "TMOUT")

    (oash eval sh-append sh
	  "FIELD" "FIELD_MAX" "LAST_KEY" "OALIB" "PP_ITEM" "PP_NUM")

    (rc eval sh-append shell
	"apid" "apids" "cdpath" "CDPATH" "history" "home" "ifs" "path" "pid"
	"prompt" "status")

    (sh eval sh-append shell
	"CDPATH" "IFS" "OPTARG" "OPTIND" "PS1" "PS2")

    ;; The next entry is only used for defining the others
    (shell "COLUMNS" "EDITOR" "HOME" "HUSHLOGIN" "LANG" "LC_COLLATE"
	   "LC_CTYPE" "LC_MESSAGES" "LC_MONETARY" "LC_NUMERIC" "LC_TIME"
	   "LINES" "LOGNAME" "MAIL" "MAILCHECK" "MAILPATH" "PAGER" "PATH"
	   "SHELL" "TERM" "TERMCAP" "TERMINFO" "VISUAL")

    (tcsh eval sh-append csh
	  "addsuffix" "ampm" "autocorrect" "autoexpand" "autolist"
	  "autologout" "chase_symlinks" "correct" "dextract" "edit" "el"
	  "fignore" "gid" "histlit" "HOST" "HOSTTYPE" "HPATH"
	  "ignore_symlinks" "listjobs" "listlinks" "listmax" "matchbeep"
	  "nobeep" "NOREBIND" "oid" "printexitvalue" "prompt2" "prompt3"
	  "pushdsilent" "pushdtohome" "recexact" "recognize_only_executables"
	  "rmstar" "savehist" "SHLVL" "showdots" "sl" "SYSTYPE" "tcsh" "term"
	  "tperiod" "tty" "uid" "version" "visiblebell" "watch" "who"
	  "wordchars")

    (zsh eval sh-append ksh88
	 "BAUD" "bindcmds" "cdpath" "DIRSTACKSIZE" "fignore" "FIGNORE" "fpath"
	 "HISTCHARS" "hostcmds" "hosts" "HOSTS" "LISTMAX" "LITHISTSIZE"
	 "LOGCHECK" "mailpath" "manpath" "NULLCMD" "optcmds" "path" "POSTEDIT"
	 "prompt" "PROMPT" "PROMPT2" "PROMPT3" "PROMPT4" "psvar" "PSVAR"
	 "READNULLCMD" "REPORTTIME" "RPROMPT" "RPS1" "SAVEHIST" "SPROMPT"
	 "STTY" "TIMEFMT" "TMOUT" "TMPPREFIX" "varcmds" "watch" "WATCH"
	 "WATCHFMT" "WORDCHARS" "ZDOTDIR"))
  "List of all shell variables available for completing read.
See `sh-feature'.")



(defvar sh-font-lock-keywords
  '((csh eval sh-append shell
	 '("\\${?[#?]?\\([A-Za-z_][A-Za-z0-9_]*\\|0\\)" 1
	   font-lock-variable-name-face))

    (es eval sh-append executable-font-lock-keywords
	'("\\$#?\\([A-Za-z_][A-Za-z0-9_]*\\|[0-9]+\\)" 1
	  font-lock-variable-name-face))

    (rc eval identity es)

    (sh eval sh-append shell
	'("\\$\\({#?\\)?\\([A-Za-z_][A-Za-z0-9_]*\\|[-#?@!]\\)" 2
	  font-lock-variable-name-face))

    ;; The next entry is only used for defining the others
    (shell eval sh-append executable-font-lock-keywords
	   '("\\\\[^A-Za-z0-9]" 0 font-lock-string-face)
	   '("\\${?\\([A-Za-z_][A-Za-z0-9_]*\\|[0-9]+\\|[$*_]\\)" 1
	     font-lock-variable-name-face)))
  "*Rules for highlighting shell scripts.  See `sh-feature'.")

(defvar sh-font-lock-keywords-1
  '((sh "[ \t]in\\>"))
  "*Additional rules for highlighting shell scripts.  See `sh-feature'.")

(defvar sh-font-lock-keywords-2 ()
  "*Yet more rules for highlighting shell scripts.  See `sh-feature'.")

(defvar sh-font-lock-keywords-only t
  "*Value of `font-lock-keywords-only' for highlighting shell scripts.
Default value is `t' because Emacs' syntax is not expressive enough to
detect that $# does not start a comment.  Thus comments are fontified by
regexp which means that a single apostrophe in a comment turns everything
upto the next one or end of buffer into a string.")

;; mode-command and utility functions

;;;###autoload
(put 'sh-mode 'mode-class 'special)

;;;###autoload
(defun sh-mode ()
  "Major mode for editing shell scripts.
This mode works for many shells, since they all have roughly the same syntax,
as far as commands, arguments, variables, pipes, comments etc. are concerned.
Unless the file's magic number indicates the shell, your usual shell is
assumed.  Since filenames rarely give a clue, they are not further analyzed.

This mode adapts to the variations between shells (see `sh-set-shell') by
means of an inheritance based feature lookup (see `sh-feature').  This
mechanism applies to all variables (including skeletons) that pertain to
shell-specific features.

The default style of this mode is that of Rosenblatt's Korn shell book.
The syntax of the statements varies with the shell being used.  The
following commands are available, based on the current shell's syntax:

\\[sh-case]	 case statement
\\[sh-for]	 for loop
\\[sh-function]	 function definition
\\[sh-if]	 if statement
\\[sh-indexed-loop]	 indexed loop from 1 to n
\\[sh-while-getopts]	 while getopts loop
\\[sh-repeat]	 repeat loop
\\[sh-select]	 select loop
\\[sh-until]	 until loop
\\[sh-while]	 while loop

\\[backward-delete-char-untabify]	 Delete backward one position, even if it was a tab.
\\[sh-newline-and-indent]	 Delete unquoted space and indent new line same as this one.
\\[sh-end-of-command]	 Go to end of successive commands.
\\[sh-beginning-of-command]	 Go to beginning of successive commands.
\\[sh-set-shell]	 Set this buffer's shell, and maybe its magic number.
\\[sh-execute-region]	 Have optional header and region be executed in a subshell.

\\[sh-maybe-here-document]	 Without prefix, following an unquoted < inserts here document.
{, (, [, ', \", `
	Unless quoted with \\, insert the pairs {}, (), [], or '', \"\", ``.

If you generally program a shell different from your login shell you can
set `sh-shell-file' accordingly.  If your shell's file name doesn't correctly
indicate what shell it is use `sh-alias-alist' to translate.

If your shell gives error messages with line numbers, you can use \\[executable-interpret]
with your script for an edit-interpret-debug cycle."
  (interactive)
  (kill-all-local-variables)
  (use-local-map sh-mode-map)
  (make-local-variable 'indent-line-function)
  (make-local-variable 'indent-region-function)
  (make-local-variable 'skeleton-end-hook)
  (make-local-variable 'paragraph-start)
  (make-local-variable 'paragraph-separate)
  (make-local-variable 'comment-start)
  (make-local-variable 'comment-start-skip)
  (make-local-variable 'require-final-newline)
  (make-local-variable 'sh-header-marker)
  (make-local-variable 'sh-shell-file)
  (make-local-variable 'sh-shell)
  (make-local-variable 'skeleton-pair-alist)
  (make-local-variable 'skeleton-pair-filter)
  (make-local-variable 'comint-dynamic-complete-functions)
  (make-local-variable 'comint-prompt-regexp)
  (make-local-variable 'font-lock-keywords)
  (make-local-variable 'font-lock-defaults)
  (make-local-variable 'skeleton-filter)
  (make-local-variable 'skeleton-newline-indent-rigidly)
  (make-local-variable 'sh-shell-variables)
  (make-local-variable 'sh-shell-variables-initialized)
  (setq major-mode 'sh-mode
	mode-name "Shell-script"
	indent-line-function 'sh-indent-line
	;; not very clever, but enables wrapping skeletons around regions
	indent-region-function (lambda (b e)
				 (save-excursion
				   (goto-char b)
				   (skip-syntax-backward "-")
				   (setq b (point))
				   (goto-char e)
				   (skip-syntax-backward "-")
				   (indent-rigidly b (point) sh-indentation)))
	skeleton-end-hook (lambda ()
			    (or (eolp) (newline) (indent-relative)))
	paragraph-start (concat page-delimiter "\\|$")
	paragraph-separate paragraph-start
	comment-start "# "
	comint-dynamic-complete-functions sh-dynamic-complete-functions
	;; we can't look if previous line ended with `\'
	comint-prompt-regexp "^[ \t]*"
	font-lock-defaults
	  `((sh-font-lock-keywords
	     sh-font-lock-keywords-1
	     sh-font-lock-keywords-2)
	    ,sh-font-lock-keywords-only
	    nil
	    ((?/ . "w") (?~ . "w") (?. . "w") (?- . "w") (?_ . "w")))
	skeleton-pair-alist '((?` _ ?`))
	skeleton-pair-filter 'sh-quoted-p
	skeleton-further-elements '((< '(- (min sh-indentation
						(current-column)))))
	skeleton-filter 'sh-feature
	skeleton-newline-indent-rigidly t)
  (save-excursion
    ;; parse or insert magic number for exec() and set all variables depending
    ;; on the shell thus determined
    (goto-char (point-min))
    (and (zerop (buffer-size))
	 (not buffer-read-only)
	 (sh-set-shell sh-shell-file)))
  (run-hooks 'sh-mode-hook))
;;;###autoload
(defalias 'shell-script-mode 'sh-mode)


(defun sh-font-lock-keywords (&optional keywords)
  "Function to get simple fontification based on `sh-font-lock-keywords'.
This adds rules for comments and assignments."
  (sh-feature sh-font-lock-keywords
	      (lambda (list)
		`((,(concat (sh-feature sh-comment-prefix) "\\(#.*\\)")
		   2 font-lock-comment-face t)
		  (,(sh-feature sh-assignment-regexp)
		   1 font-lock-variable-name-face)
		  ,@keywords
		  ,@list))))

(defun sh-font-lock-keywords-1 (&optional builtins)
  "Function to get better fontification including keywords."
  (let ((keywords (concat "\\([;(){}`|&]\\|^\\)[ \t]*\\(\\(\\("
			  (mapconcat 'identity
				     (sh-feature sh-leading-keywords)
				     "\\|")
			  "\\)[ \t]+\\)?\\("
			  (mapconcat 'identity
				     (append (sh-feature sh-leading-keywords)
					     (sh-feature sh-other-keywords))
				     "\\|")
			  "\\)")))
    (sh-font-lock-keywords
     `(,@(if builtins
	     `((,(concat keywords "[ \t]+\\)?\\("
			 (mapconcat 'identity (sh-feature sh-builtins) "\\|")
			 "\\)\\>")
		(2 font-lock-keyword-face nil t)
		(6 font-lock-function-name-face))
	       ,@(sh-feature sh-font-lock-keywords-2)))
	 (,(concat keywords "\\)\\>")
	  2 font-lock-keyword-face)
	 ,@(sh-feature sh-font-lock-keywords-1)))))

(defun sh-font-lock-keywords-2 ()
  "Function to get better fontification including keywords and builtins."
  (sh-font-lock-keywords-1 t))


(defun sh-set-shell (shell &optional no-query-flag insert-flag)
  "Set this buffer's shell to SHELL (a string).
Makes this script executable via `executable-set-magic'.
Calls the value of `sh-set-shell-hook' if set."
  (interactive (list (completing-read "Name or path of shell: "
				      interpreter-mode-alist
				      (lambda (x) (eq (cdr x) 'sh-mode)))
		     (eq executable-query 'function)
		     t))
  (setq sh-shell (intern (file-name-nondirectory shell))
	sh-shell (or (cdr (assq sh-shell sh-alias-alist))
		     sh-shell))
  (setq sh-shell-file (executable-set-magic shell (sh-feature sh-shell-arg)))
  (setq require-final-newline (sh-feature sh-require-final-newline)
;;;	local-abbrev-table (sh-feature sh-abbrevs)
	font-lock-keywords nil		; force resetting
	font-lock-syntax-table nil
	comment-start-skip (concat (sh-feature sh-comment-prefix) "#+[\t ]*")
	mode-line-process (format "[%s]" sh-shell)
	sh-shell-variables nil
	sh-shell-variables-initialized nil
	shell (sh-feature sh-variables))
  (set-syntax-table (sh-feature sh-mode-syntax-table))
  (while shell
    (sh-remember-variable (car shell))
    (setq shell (cdr shell)))
  (and (boundp 'font-lock-mode)
       font-lock-mode
       (font-lock-mode (font-lock-mode 0)))
  (run-hooks 'sh-set-shell-hook))



(defun sh-feature (list &optional function)
  "Index ALIST by the current shell.
If ALIST isn't a list where every element is a cons, it is returned as is.
Else indexing follows an inheritance logic which works in two ways:

  - Fall back on successive ancestors (see `sh-ancestor-alist') as long as
    the alist contains no value for the current shell.

  - If the value thus looked up is a list starting with `eval' its `cdr' is
    first evaluated.  If that is also a list and the first argument is a
    symbol in ALIST it is not evaluated, but rather recursively looked up in
    ALIST to allow the function called to define the value for one shell to be
    derived from another shell.  While calling the function, is the car of the
    alist element is the current shell.
    The value thus determined is physically replaced into the alist.

Optional FUNCTION is applied to the determined value and the result is cached
in ALIST."
  (or (if (consp list)
	  (let ((l list))
	    (while (and l (consp (car l)))
	      (setq l (cdr l)))
	    (if l list)))
      (if function
	  (cdr (assoc (setq function (cons sh-shell function)) list)))
      (let ((sh-shell sh-shell)
	    elt val)
	(while (and sh-shell
		    (not (setq elt (assq sh-shell list))))
	  (setq sh-shell (cdr (assq sh-shell sh-ancestor-alist))))
	(if (and (consp (setq val (cdr elt)))
		 (eq (car val) 'eval))
	    (setcdr elt
		    (setq val
			  (eval (if (consp (setq val (cdr val)))
				    (let ((sh-shell (car (cdr val)))
					  function)
				      (if (assq sh-shell list)
					  (setcar (cdr val)
						  (list 'quote
							(sh-feature list))))
				      val)
				  val)))))
	(if function
	    (nconc list
		   (list (cons function
			       (setq sh-shell (car function)
				     val (funcall (cdr function) val))))))
	val)))



;;; I commented this out because nobody calls it -- rms.
;;;(defun sh-abbrevs (ancestor &rest list)
;;;  "Iff it isn't, define the current shell as abbrev table and fill that.
;;;Abbrev table will inherit all abbrevs from ANCESTOR, which is either an abbrev
;;;table or a list of (NAME1 EXPANSION1 ...).  In addition it will define abbrevs
;;;according to the remaining arguments NAMEi EXPANSIONi ...
;;;EXPANSION may be either a string or a skeleton command."
;;;  (or (if (boundp sh-shell)
;;;	  (symbol-value sh-shell))
;;;      (progn
;;;	(if (listp ancestor)
;;;	    (nconc list ancestor))
;;;	(define-abbrev-table sh-shell ())
;;;	(if (vectorp ancestor)
;;;	    (mapatoms (lambda (atom)
;;;			(or (eq atom 0)
;;;			    (define-abbrev (symbol-value sh-shell)
;;;			      (symbol-name atom)
;;;			      (symbol-value atom)
;;;			      (symbol-function atom))))
;;;		      ancestor))
;;;	(while list
;;;	  (define-abbrev (symbol-value sh-shell)
;;;	    (car list)
;;;	    (if (stringp (car (cdr list)))
;;;		(car (cdr list))
;;;	      "")
;;;	    (if (symbolp (car (cdr list)))
;;;		(car (cdr list))))
;;;	  (setq list (cdr (cdr list)))))
;;;      (symbol-value sh-shell)))


(defun sh-mode-syntax-table (table &rest list)
  "Copy TABLE and set syntax for successive CHARs according to strings S."
  (setq table (copy-syntax-table table))
  (while list
    (modify-syntax-entry (car list) (car (cdr list)) table)
    (setq list (cdr (cdr list))))
  table)


(defun sh-append (ancestor &rest list)
  "Return list composed of first argument (a list) physically appended to rest."
  (nconc list ancestor))


(defun sh-modify (skeleton &rest list)
  "Modify a copy of SKELETON by replacing I1 with REPL1, I2 with REPL2 ..."
  (setq skeleton (copy-sequence skeleton))
  (while list
    (setcar (or (nthcdr (car list) skeleton)
		(error "Index %d out of bounds" (car list)))
	    (car (cdr list)))
    (setq list (nthcdr 2 list)))
  skeleton)


(defun sh-indent-line ()
  "Indent as far as preceding non-empty line, then by steps of `sh-indentation'.
Lines containing only comments are considered empty."
  (interactive)
  (let ((previous (save-excursion
		    (while (and (not (bobp))
				(progn
				  (forward-line -1)
				  (back-to-indentation)
				  (or (eolp)
				      (eq (following-char) ?#)))))
		    (current-column)))
	current)
    (save-excursion
      (indent-to (if (eq this-command 'newline-and-indent)
		     previous
		   (if (< (current-column)
			  (setq current (progn (back-to-indentation)
					       (current-column))))
		       (if (eolp) previous 0)
		     (delete-region (point)
				    (progn (beginning-of-line) (point)))
		     (if (eolp)
			 (max previous (* (1+ (/ current sh-indentation))
					  sh-indentation))
		       (* (1+ (/ current sh-indentation)) sh-indentation))))))
    (if (< (current-column) (current-indentation))
	(skip-chars-forward " \t"))))


(defun sh-execute-region (start end &optional flag)
  "Pass optional header and region to a subshell for noninteractive execution.
The working directory is that of the buffer, and only environment variables
are already set which is why you can mark a header within the script.

With a positive prefix ARG, instead of sending region, define header from
beginning of buffer to point.  With a negative prefix ARG, instead of sending
region, clear header."
  (interactive "r\nP")
  (if flag
      (setq sh-header-marker (if (> (prefix-numeric-value flag) 0)
				 (point-marker)))
    (if sh-header-marker
	(save-excursion
	  (let (buffer-undo-list)
	    (goto-char sh-header-marker)
	    (append-to-buffer (current-buffer) start end)
	    (shell-command-on-region (point-min)
				     (setq end (+ sh-header-marker
						  (- end start)))
				     sh-shell-file)
	    (delete-region sh-header-marker end)))
      (shell-command-on-region start end (concat sh-shell-file " -")))))


(defun sh-remember-variable (var)
  "Make VARIABLE available for future completing reads in this buffer."
  (or (< (length var) sh-remember-variable-min)
      (getenv var)
      (assoc var sh-shell-variables)
      (setq sh-shell-variables (cons (cons var var) sh-shell-variables)))
  var)



(defun sh-quoted-p ()
  "Is point preceded by an odd number of backslashes?"
  (eq -1 (% (save-excursion (skip-chars-backward "\\\\")) 2)))

;; statement syntax-commands for various shells

;; You are welcome to add the syntax or even completely new statements as
;; appropriate for your favorite shell.

(define-skeleton sh-case
  "Insert a case/switch statement.  See `sh-feature'."
  (csh "expression: "
       "switch( " str " )" \n
       > "case " (read-string "pattern: ") ?: \n
       > _ \n
       "breaksw" \n
       ( "other pattern, %s: "
	 < "case " str ?: \n
	 > _ \n
	 "breaksw" \n)
       < "default:" \n
       > _ \n
       resume:
       < < "endsw")
  (es)
  (rc "expression: "
      "switch( " str " ) {" \n
      > "case " (read-string "pattern: ") \n
      > _ \n
      ( "other pattern, %s: "
	< "case " str \n
	> _ \n)
      < "case *" \n
      > _ \n
      resume:
      < < ?})
  (sh "expression: "
      "case " str " in" \n
      > (read-string "pattern: ") ?\) \n
      > _ \n
      ";;" \n
      ( "other pattern, %s: "
	< str ?\) \n
	> _ \n
	";;" \n)
      < "*)" \n
      > _ \n
      resume:
      < < "esac"))
(put 'sh-case 'menu-enable '(sh-feature sh-case))



(define-skeleton sh-for
  "Insert a for loop.  See `sh-feature'."
  (csh eval sh-modify sh
       1 "foreach "
       3 " ( "
       5 " )"
       15 "end")
  (es eval sh-modify rc
      3 " = ")
  (rc eval sh-modify sh
      1 "for( "
      5 " ) {"
      15 ?})
  (sh "Index variable: "
      "for " str " in " _ "; do" \n
      > _ | ?$ & (sh-remember-variable str) \n
      < "done"))



(define-skeleton sh-indexed-loop
  "Insert an indexed loop from 1 to n.  See `sh-feature'."
  (bash eval identity posix)
  (csh "Index variable: "
       "@ " str " = 1" \n
       "while( $" str " <= " (read-string "upper limit: ") " )" \n
       > _ ?$ str \n
       "@ " str "++" \n
       < "end")
  (es eval sh-modify rc
      3 " =")
  (ksh88 "Index variable: "
	 "integer " str "=0" \n
	 "while (( ( " str " += 1 ) <= "
	 (read-string "upper limit: ")
	 " )); do" \n
	 > _ ?$ (sh-remember-variable str) \n
	 < "done")
  (posix "Index variable: "
	 str "=1" \n
	 "while [ $" str " -le "
	 (read-string "upper limit: ")
	 " ]; do" \n
	 > _ ?$ str \n
	 str ?= (sh-add (sh-remember-variable str) 1) \n
	 < "done")
  (rc "Index variable: "
      "for( " str " in" " `{awk 'BEGIN { for( i=1; i<="
      (read-string "upper limit: ")
      "; i++ ) print i }'}) {" \n
      > _ ?$ (sh-remember-variable str) \n
      < ?})
  (sh "Index variable: "
      "for " str " in `awk 'BEGIN { for( i=1; i<="
      (read-string "upper limit: ")
      "; i++ ) print i }'`; do" \n
      > _ ?$ (sh-remember-variable str) \n
      < "done"))


(defun sh-shell-initialize-variables ()
  "Scan the buffer for variable assignments.
Add these variables to `sh-shell-variables'."
  (message "Scanning buffer `%s' for variable assignments..." (buffer-name))
  (save-excursion
    (goto-char (point-min))
    (setq sh-shell-variables-initialized t)
    (while (search-forward "=" nil t)
      (sh-assignment 0)))
  (message "Scanning buffer `%s' for variable assignments...done"
	   (buffer-name)))

(defvar sh-add-buffer)

(defun sh-add-completer (string predicate code)
  "Do completion using `sh-shell-variables', but initialize it first.
This function is designed for use as the \"completion table\",
so it takes three arguments:
  STRING, the current buffer contents;
  PREDICATE, the predicate for filtering possible matches;
  CODE, which says what kind of things to do.
CODE can be nil, t or `lambda'.
nil means to return the best completion of STRING, or nil if there is none.
t means to return a list of all possible completions of STRING.
`lambda' means to return t if STRING is a valid completion as it stands."
  (let ((sh-shell-variables
	 (save-excursion
	   (set-buffer sh-add-buffer)
	   (or sh-shell-variables-initialized
	       (sh-shell-initialize-variables))
	   (nconc (mapcar (lambda (var)
			    (let ((name
				   (substring var 0 (string-match "=" var))))
			      (cons name name)))
			  process-environment)
		  sh-shell-variables))))
    (cond ((null code)
	   (try-completion string sh-shell-variables predicate))
	  ((eq code t)
	   (all-completions string sh-shell-variables predicate))
	  ((eq code 'lambda)
	   (assoc string sh-shell-variables)))))

(defun sh-add (var delta)
  "Insert an addition of VAR and prefix DELTA for Bourne (type) shell."
  (interactive
   (let ((sh-add-buffer (current-buffer)))
     (list (completing-read "Variable: " 'sh-add-completer)
	   (prefix-numeric-value current-prefix-arg))))
  (insert (sh-feature '((bash . "$[ ")
			(ksh88 . "$(( ")
			(posix . "$(( ")
			(rc . "`{expr $")
			(sh . "`expr $")
			(zsh . "$[ ")))
	  (sh-remember-variable var)
	  (if (< delta 0) " - " " + ")
	  (number-to-string (abs delta))
	  (sh-feature '((bash . " ]")
			(ksh88 . " ))")
			(posix . " ))")
			(rc . "}")
			(sh . "`")
			(zsh . " ]")))))



(define-skeleton sh-function
  "Insert a function definition.  See `sh-feature'."
  (bash eval sh-modify ksh88
	3 "() {")
  (ksh88 "name: "
	 "function " str " {" \n
	 > _ \n
	 < "}")
  (rc eval sh-modify ksh88
	1 "fn ")
  (sh ()
      "() {" \n
      > _ \n
      < "}"))



(define-skeleton sh-if
  "Insert an if statement.  See `sh-feature'."
  (csh "condition: "
       "if( " str " ) then" \n
       > _ \n
       ( "other condition, %s: "
	 < "else if( " str " ) then" \n
	 > _ \n)
       < "else" \n
       > _ \n
       resume:
       < "endif")
  (es "condition: "
      "if { " str " } {" \n
       > _ \n
       ( "other condition, %s: "
	 < "} { " str " } {" \n
	 > _ \n)
       < "} {" \n
       > _ \n
       resume:
       < ?})
  (rc eval sh-modify csh
      3 " ) {"
      8 '( "other condition, %s: "
	   < "} else if( " str " ) {" \n
	   > _ \n)
      10 "} else {"
      17 ?})
  (sh "condition: "
      '(setq input (sh-feature sh-test))
      "if " str "; then" \n
      > _ \n
      ( "other condition, %s: "
	< "elif " str "; then" \n
	> _ \n)
      < "else" \n
      > _ \n
      resume:
      < "fi"))



(define-skeleton sh-repeat
  "Insert a repeat loop definition.  See `sh-feature'."
  (es nil
      "forever {" \n
      > _ \n
      < ?})
  (zsh "factor: "
      "repeat " str "; do"\n
      > _ \n
      < "done"))
(put 'sh-repeat 'menu-enable '(sh-feature sh-repeat))



(define-skeleton sh-select
  "Insert a select statement.  See `sh-feature'."
  (ksh88 "Index variable: "
	 "select " str " in " _ "; do" \n
	 > ?$ str \n
	 < "done"))
(put 'sh-select 'menu-enable '(sh-feature sh-select))



(define-skeleton sh-tmp-file
  "Insert code to setup temporary file handling.  See `sh-feature'."
  (bash eval identity ksh88)
  (csh (file-name-nondirectory (buffer-file-name))
       "set tmp = /tmp/" str ".$$" \n
       "onintr exit" \n _
       (and (goto-char (point-max))
	    (not (bolp))
	    ?\n)
       "exit:\n"
       "rm $tmp* >&/dev/null" >)
  (es (file-name-nondirectory (buffer-file-name))
      "local( signals = $signals sighup sigint; tmp = /tmp/" str ".$pid ) {" \n
      > "catch @ e {" \n
      > "rm $tmp^* >[2]/dev/null" \n
      "throw $e" \n
      < "} {" \n
      > _ \n
      < ?} \n
      < ?})
  (ksh88 eval sh-modify sh
	 6 "EXIT")
  (rc (file-name-nondirectory (buffer-file-name))
       "tmp = /tmp/" str ".$pid" \n
       "fn sigexit { rm $tmp^* >[2]/dev/null }")
  (sh (file-name-nondirectory (buffer-file-name))
      "TMP=/tmp/" str ".$$" \n
      "trap \"rm $TMP* 2>/dev/null\" " ?0))



(define-skeleton sh-until
  "Insert an until loop.  See `sh-feature'."
  (sh "condition: "
      '(setq input (sh-feature sh-test))
      "until " str "; do" \n
      > _ \n
      < "done"))
(put 'sh-until 'menu-enable '(sh-feature sh-until))



(define-skeleton sh-while
  "Insert a while loop.  See `sh-feature'."
  (csh eval sh-modify sh
       2 "while( "
       4 " )"
       10 "end")
  (es eval sh-modify rc
      2 "while { "
      4 " } {")
  (rc eval sh-modify csh
      4 " ) {"
      10 ?})
  (sh "condition: "
      '(setq input (sh-feature sh-test))
      "while " str "; do" \n
      > _ \n
      < "done"))



(define-skeleton sh-while-getopts
  "Insert a while getopts loop.  See `sh-feature'.
Prompts for an options string which consists of letters for each recognized
option followed by a colon `:' if the option accepts an argument."
  (bash eval sh-modify sh
	18 "${0##*/}")
  (csh nil
       "while( 1 )" \n
       > "switch( \"$1\" )" \n
       '(setq input '("- x" . 2))
       > >
       ( "option, %s: "
	 < "case " '(eval str)
	 '(if (string-match " +" str)
	      (setq v1 (substring str (match-end 0))
		    str (substring str 0 (match-beginning 0)))
	    (setq v1 nil))
	 str ?: \n
	 > "set " v1 & " = $2" | -4 & _ \n
	 (if v1 "shift") & \n
	 "breaksw" \n)
       < "case --:" \n
       > "shift" \n
       < "default:" \n
       > "break" \n
       resume:
       < < "endsw" \n
       "shift" \n
       < "end")
  (ksh88 eval sh-modify sh
	 16 "print"
	 18 "${0##*/}"
	 36 "OPTIND-1")
  (posix eval sh-modify sh
	 18 "$(basename $0)")
  (sh "optstring: "
      "while getopts :" str " OPT; do" \n
      > "case $OPT in" \n
      > >
      '(setq v1 (append (vconcat str) nil))
      ( (prog1 (if v1 (char-to-string (car v1)))
	  (if (eq (nth 1 v1) ?:)
	      (setq v1 (nthcdr 2 v1)
		    v2 "\"$OPTARG\"")
	    (setq v1 (cdr v1)
		  v2 nil)))
	< str "|+" str ?\) \n
	> _ v2 \n
	";;" \n)
      < "*)" \n
      > "echo" " \"usage: " "`basename $0`"
      " [+-" '(setq v1 (point)) str
      '(save-excursion
	 (while (search-backward ":" v1 t)
	   (replace-match " ARG] [+-" t t)))
      (if (eq (preceding-char) ?-) -5)
      "] [--] ARGS...\"" \n
      "exit 2" \n
      < < "esac" \n
      < "done" \n
      "shift " (sh-add "OPTIND" -1)))
(put 'sh-while-getopts 'menu-enable '(sh-feature sh-while-getopts))



(defun sh-assignment (arg)
  "Remember preceding identifier for future completion and do self-insert."
  (interactive "p")
  (self-insert-command arg)
  (if (<= arg 1)
      (sh-remember-variable
       (save-excursion
	 (if (re-search-forward (sh-feature sh-assignment-regexp)
				(prog1 (point)
				  (beginning-of-line 1))
				t)
	     (match-string 1))))))



(defun sh-maybe-here-document (arg)
  "Inserts self.  Without prefix, following unquoted `<' inserts here document.
The document is bounded by `sh-here-document-word'."
  (interactive "*P")
  (self-insert-command (prefix-numeric-value arg))
  (or arg
      (not (eq (char-after (- (point) 2)) last-command-char))
      (save-excursion
	(backward-char 2)
	(sh-quoted-p))
      (progn
	(insert sh-here-document-word)
	(or (eolp) (looking-at "[ \t]") (insert ? ))
	(end-of-line 1)
	(while
	    (sh-quoted-p)
	  (end-of-line 2))
	(newline)
	(save-excursion (insert ?\n sh-here-document-word)))))


;; various other commands

(autoload 'comint-dynamic-complete "comint"
  "Dynamically perform completion at point." t)

(autoload 'shell-dynamic-complete-command "shell"
  "Dynamically complete the command at point." t)

(autoload 'comint-dynamic-complete-filename "comint"
  "Dynamically complete the filename at point." t)

(autoload 'shell-dynamic-complete-environment-variable "shell"
  "Dynamically complete the environment variable at point." t)



(defun sh-newline-and-indent ()
  "Strip unquoted whitespace, insert newline, and indent like current line."
  (interactive "*")
  (indent-to (prog1 (current-indentation)
	       (delete-region (point)
			      (progn
				(or (zerop (skip-chars-backward " \t"))
				    (if (sh-quoted-p)
					(forward-char)))
				(point)))
	       (newline))))



(defun sh-beginning-of-command ()
  "Move point to successive beginnings of commands."
  (interactive)
  (if (re-search-backward sh-beginning-of-command nil t)
      (goto-char (match-beginning 2))))


(defun sh-end-of-command ()
  "Move point to successive ends of commands."
  (interactive)
  (if (re-search-forward sh-end-of-command nil t)
      (goto-char (match-end 1))))

(provide 'sh-script)
;; sh-script.el ends here

--Multipart_Thu_Sep_12_11:35:56_1996-1
Content-Type: application/octet-stream; type=emacs-lisp
Content-Disposition: attachment; filename="executable.el"
Content-Transfer-Encoding: 7bit

;;; executable.el --- base functionality for executable interpreter scripts

;; Copyright (C) 1994, 1995, 1996 by Free Software Foundation, Inc.

;; Author: Daniel.Pfeiffer@Informatik.START.dbp.de, fax (+49 69) 7588-2389
;; Keywords: languages, unix

;; This file is part of XEmacs.

;; XEmacs is free software; you can redistribute it and/or modify it
;; under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; XEmacs is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with XEmacs; see the file COPYING.  If not, write to the Free
;; Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
;; 02111-1307, USA.

;;; Synched up with: FSF 19.34.

;;; Commentary:

;; executable.el is used by certain major modes to insert a suitable
;; #! line at the beginning of the file, if the file does not already
;; have one.

;; Unless it has a magic number, a Unix file with executable mode is passed to
;; a new instance of the running shell (or to a Bourne shell if a csh is
;; running and the file starts with `:').  Only a shell can start such a file,
;; exec() cannot, which is why it is important to have a magic number in every
;; executable script.  Such a magic number is made up by the characters `#!'
;; the filename of an interpreter (in COFF, ELF or somesuch format) and one
;; optional argument.

;; This library is for certain major modes like sh-, awk-, perl-, tcl- or
;; makefile-mode to insert or update a suitable #! line at the beginning of
;; the file, if the file does not already have one and the file is not a
;; default file of that interpreter (like .profile or makefile).  It also
;; makes the file executable if it wasn't, as soon as it's saved.

;; It also allows debugging scripts, with an adaptation of compile, as far
;; as interpreters give out meaningful error messages.

;; Modes that use this should nconc `executable-map' to the end of their own
;; keymap and `executable-font-lock-keywords' to the end of their own font
;; lock keywords.  Their mode-setting commands should call
;; `executable-set-magic'.

;;; Code:

(defvar executable-insert 'not-modified
  "*What to do when newly found file has no or wrong magic number:
	nil	do nothing
	t	insert or update magic number
	other	insert or update magic number, but mark as unmodified.
When the insertion is marked as unmodified, you can save it with  \\[write-file] RET.
This variable is used when `executable-set-magic' is called as a function,
e.g. when Emacs sets some Un*x interpreter script mode.
With \\[executable-set-magic], this is always treated as if it were `t'.")


(defvar executable-query 'function
  "*If non-`nil', ask user before inserting or changing magic number.
When this is `function', only ask when called non-interactively.")


(defvar executable-magicless-file-regexp "/[Mm]akefile$\\|/\\.\\(z?profile\\|bash_profile\\|z?login\\|bash_login\\|z?logout\\|bash_logout\\|.+shrc\\|esrc\\|rcrc\\|[kz]shenv\\)$"
  "*On files with this kind of name no magic is inserted or changed.")


(defvar executable-prefix "#! "
  "*Interpreter magic number prefix inserted when there was no magic number.")



(defvar executable-chmod 73
  "*After saving, if the file is not executable, set this mode.
This mode passed to `set-file-modes' is taken absolutely when negative, or
relative to the files existing modes.  Do nothing if this is nil.
Typical values are 73 (+x) or -493 (rwxr-xr-x).")


(defvar executable-command nil)

(defvar executable-self-display "tail"
  "*Command you use with argument `+2' to make text files self-display.
Note that the like of `more' doesn't work too well under Emacs  \\[shell].")


(defvar executable-font-lock-keywords
  '(("\\`#!.*/\\([^ \t\n]+\\)" 1 font-lock-keyword-face t))
  "*Rules for highlighting executable scripts' magic number.
This can be included in `font-lock-keywords' by modes that call `executable'.")


(defvar executable-error-regexp-alist
  '(;; /bin/xyz: syntax error at line 14: `(' unexpected
    ;; /bin/xyz[5]: syntax error at line 8 : ``' unmatched
    ("^\\(.*[^[/]\\)\\(\\[[0-9]+\\]\\)?: .* error .* line \\([0-9]+\\)" 1 3)
    ;; /bin/xyz[27]: ehco:  not found
    ("^\\(.*[^/]\\)\\[\\([0-9]+\\)\\]: .*: " 1 2)
    ;; /bin/xyz: syntax error near unexpected token `)'
    ;; /bin/xyz: /bin/xyz: line 2: `)'
    ("^\\(.*[^/]\\): [^0-9\n]+\n\\1: \\1: line \\([0-9]+\\):" 1 2)
    ;; /usr/bin/awk: syntax error at line 5 of file /bin/xyz
    (" error .* line \\([0-9]+\\) of file \\(.+\\)$" 2 1)
    ;; /usr/bin/awk: calling undefined function toto
    ;;  input record number 3, file awktestdata
    ;;  source line 4 of file /bin/xyz
    ("^[^ ].+\n\\( .+\n\\)* line \\([0-9]+\\) of file \\(.+\\)$" 3 2)
    ;; makefile:1: *** target pattern contains no `%'.  Stop.
    ("^\\(.+\\):\\([0-9]+\\): " 1 2))
  "Alist of regexps used to match script errors.
See `compilation-error-regexp-alist'.")

;; The C function openp slightly modified would do the trick fine
(defun executable-find (command)
  "Search for COMMAND in exec-path and return the absolute file name.
Return nil if COMMAND is not found anywhere in `exec-path'."
  (let ((list exec-path)
	file)
    (while list
      (setq list (if (and (setq file (expand-file-name command (car list)))
			  (file-executable-p file)
			  (not (file-directory-p file)))
		     nil
		   (setq file nil)
		   (cdr list))))
    file))


(defun executable-chmod ()
  "This gets called after saving a file to assure that it be executable.
You can set the absolute or relative mode in variable `executable-chmod' for
non-executable files."
  (and executable-chmod
       buffer-file-name
       (or (file-executable-p buffer-file-name)
	   (set-file-modes buffer-file-name
			   (if (< executable-chmod 0)
			       (- executable-chmod)
			     (logior executable-chmod
				     (file-modes buffer-file-name)))))))


(defun executable-interpret (command)
  "Run script with user-specified args, and collect output in a buffer.
While script runs asynchronously, you can use the \\[next-error] command
to find the next error."
  (interactive (list (read-string "Run script: "
				  (or executable-command
				      buffer-file-name))))
  (require 'compile)
  (save-some-buffers (not compilation-ask-about-save))
  (make-local-variable 'executable-command)
  (compile-internal (setq executable-command command)
		    "No more errors." "Interpretation"
		    ;; Give it a simpler regexp to match.
		    nil executable-error-regexp-alist))



;;;###autoload
(defun executable-set-magic (interpreter &optional argument
					 no-query-flag insert-flag)
  "Set this buffer's interpreter to INTERPRETER with optional ARGUMENT.
The variables `executable-magicless-file-regexp', `executable-prefix',
`executable-insert', `executable-query' and `executable-chmod' control
when and how magic numbers are inserted or replaced and scripts made
executable."
  (interactive
   (let* ((name (read-string "Name or file name of interpreter: "))
	  (arg (read-string (format "Argument for %s: " name))))
     (list name arg (eq executable-query 'function) t)))
  (setq interpreter (if (file-name-absolute-p interpreter)
			interpreter
		      (or (executable-find interpreter)
			  (error "Interpreter %s not recognized" interpreter)))
	argument (concat interpreter
			 (and argument (string< "" argument) " ")
			 argument))
  (or buffer-read-only
      (if buffer-file-name
	  (string-match executable-magicless-file-regexp
			buffer-file-name))
      (not (or insert-flag executable-insert))
      (> (point-min) 1)
      (save-excursion
	(let ((point (point-marker))
	      (buffer-modified-p (buffer-modified-p)))
	  (goto-char (point-min))
	  (make-local-hook 'after-save-hook)
	  (add-hook 'after-save-hook 'executable-chmod nil t)
	  (if (looking-at "#![ \t]*\\(.*\\)$")
	      (and (goto-char (match-beginning 1))
		   ;; If the line ends in a space,
		   ;; don't offer to change it.
		   (not (= (char-after (1- (match-end 1))) ?\ ))
		   (not (string= argument
				 (buffer-substring (point) (match-end 1))))
		   (if (or (not executable-query) no-query-flag
			   (save-window-excursion
			     ;; Make buffer visible before question.
			     (switch-to-buffer (current-buffer))
			     (y-or-n-p (concat "Replace magic number by `"
					       executable-prefix argument "'? "))))
		       (progn
			 (replace-match argument t t nil 1)
			 (message "Magic number changed to `%s'"
				  (concat executable-prefix argument)))))
	    (insert executable-prefix argument ?\n)
	    (message "Magic number changed to `%s'"
		     (concat executable-prefix argument)))
;;;	  (or insert-flag
;;;	      (eq executable-insert t)
;;;	      (set-buffer-modified-p buffer-modified-p))
	  )))
  interpreter)



;;;###autoload
(defun executable-self-display ()
  "Turn a text file into a self-displaying Un*x command.
The magic number of such a command displays all lines but itself."
  (interactive)
  (if (eq this-command 'executable-self-display)
      (setq this-command 'executable-set-magic))
  (executable-set-magic executable-self-display "+2"))



(provide 'executable)

;; executable.el ends here


--Multipart_Thu_Sep_12_11:35:56_1996-1
Content-Type: text/plain; charset=US-ASCII

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

--Multipart_Thu_Sep_12_11:35:56_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 17:37:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA15451 for xemacs-beta-people; Thu, 12 Sep 1996 17:37:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA15448 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 17:37:40 -0500 (CDT)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA06759 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 17:37:20 -0500 (CDT)
Received: from hniksic@localhost by jagor.srce.hr (8.7.5/8.6.12.CI)
	id AAA29157; Fri, 13 Sep 1996 00:36:38 +0200 (MET DST)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: Re: `Somebody needs to port sh-script.el to XEmacs'
References: <m23f0ninsi.fsf@deanna.miranova.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/geturl/geturl.tar.gz
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 13 Sep 1996 00:36:37 +0200
In-Reply-To: Steven L Baur's message of 12 Sep 1996 11:35:57 -0700
Message-ID: <kigpw3ruzre.fsf@jagor.srce.hr>
Lines: 17
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Steven L Baur (steve@miranova.com) wrote:
[...]
>     ;; -f means don't run .zshrc.
>     (zsh . "-f"))

I don't think zsh runs .zshrc when executing scripts. It runs .zshenv
only (if present). Thus it doesn't need "-f" (since .zshenv is used
for PATH and similar settings). Or, the comment should describe -f
accurately ("-f means don't run .zshenv").

-- 
hniksic@srce.hr              |  Student of electrical engineering
hniksic@fly.cc.fer.hr        |  University of Zagreb, Croatia
------------------------------------------------------------------
The IDIOT.  Usually a cretin, morpohodite, or old COBOL programmer
selected to be the system administrator by a committee of cretins,
morphodites, and old COBOL programmers.

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 18:11:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA15524 for xemacs-beta-people; Thu, 12 Sep 1996 18:11:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA15521 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 18:11:56 -0500 (CDT)
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA06818 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 18:11:50 -0500 (CDT)
Received: from charney by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id RAA12872; Thu, 12 Sep 1996 17:11:52 -0600
Received: by charney (SMI-8.6) id RAA19432; Thu, 12 Sep 1996 17:11:49 -0600
Date: Thu, 12 Sep 1996 17:11:49 -0600
Message-Id: <199609122311.RAA19432@charney.cdc.noaa.gov>
From: Mark Borges <mdb@cdc.noaa.gov>
To: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: [19.15b1] process termination bugs?
Organization: CIRES, University of Colorado
X-Attribution: mb

Sometimes I'll start a process and it won't exit. For instance, I'll
do
	M-x grep -n foo *

while in a dired buffer, and sometimes the process never exits (other
times it will exit if I put the cursor in the *grep* buffer, e.g., via
\C-x o). Another user (using 19.14) has reported this happening with
compiling, using compile(), as well.

M-x list-processes shows

Proc         Status   Buffer         Tty         Command
----         ------   ------         ---         -------
grep         run      *grep*	     /dev/pts/10 /bin/sh -c grep -n RCS * /dev/null
nntpd        open      *nntpd*	     (none)	 network stream connection nntp@news.colorado.edu

How can I debug this further? How can I kill the process? I looked up
kill-process() and interrupt-process(), and neither worked though I'm
not confident I did it correctly.

I realize this is a crappy report, but I don't know how to gather more
info at present.

Thanks for any help.

-- 
  -mb-

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 19:41:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA15804 for xemacs-beta-people; Thu, 12 Sep 1996 19:41:52 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA15801 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 19:41:50 -0500 (CDT)
Received: from mhost.mri.com (mri-gw.mri.com [149.147.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA26283 for <xemacs-beta@cs.uiuc.edu>; Thu, 12 Sep 1996 19:41:50 -0500 (CDT)
Received: from mri.com (mailhost.mri.com [192.9.201.130]) by mhost.mri.com (8.7.5/8.7.3) with ESMTP id RAA21178 for <xemacs-beta@cs.uiuc.edu>; Thu, 12 Sep 1996 17:41:48 -0700 (PDT)
Received: from allez.mri.com by mri.com (8.6.12/SMI-4.1-1.16)
        id RAA21244; Thu, 12 Sep 1996 17:41:48 -0700
Message-Id: <199609130041.RAA21244@mri.com>
To: xemacs-beta@cs.uiuc.edu
Subject: XEmacs 19.15-b1 failures on Solaris 2.4 (but success on Linux 2.0.19/i586.)
Reply-To: Vladimir.Ivanovic@mri.com
Date: Thu, 12 Sep 1996 17:41:46 -0700
From: "Vladimir G. Ivanovic" <Vladimir.Ivanovic@mri.com>

I haven't been able to `make install' from a full distribution an XEmacs
which accepts input.  The compile completes, but when I run it, I run
through my ~/.emacs and then the only thing I can do is bring down menu
items.  No text shows up in *scratch* and the menu items selected don't
take effect.

I'm retrying with site-runtime-libraries instead of site-libraries to
see if that has any effect.

-- Vladimir

1.) Success on Linux 2.0.19/i586.

2.) On Solaris 2.4 I have:

  Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /mnt/local.src/xemacs-19.15-b1
  What installation prefix should install use?		  ${srcdir}
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              cc -v -g -O -DNeedFunctionPrototypes
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /home/vladimir/src/xpm-3.4f /home/vladimir/src/socks.cstc.4.2beta/include /usr/dt/include
  Additional libraries:                                   /home/vladimir/src/xpm-3.4f/lib /home/vladimir/src/socks.cstc.4.2beta/lib /usr/dt/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 19:57:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA15893 for xemacs-beta-people; Thu, 12 Sep 1996 19:57:36 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA15890 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 19:57:35 -0500 (CDT)
Received: from ethanol.gnu.ai.mit.edu (rms@ethanol.gnu.ai.mit.edu [128.52.46.64]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA06995 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 19:57:30 -0500 (CDT)
Received: by ethanol.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id UAA27246; Thu, 12 Sep 1996 20:57:28 -0400
Date: Thu, 12 Sep 1996 20:57:28 -0400
Message-Id: <199609130057.UAA27246@ethanol.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: wing@666.com
CC: xemacs-beta@xemacs.org
In-reply-to: <199609081118.EAA04932@shellx.best.com> (message from Ben Wing on
	Sun, 8 Sep 1996 04:18:49 -0700)
Subject: Re: Versions of Emacs

    This is a completely disingenuous position to take!  Linux, for example,
    is distributed with *exactly identical* legal terms to XEmacs.  Are
    you willing to claim that Linux is detrimental to the free software
    community?

There is a certain amount of similarity between these two situations,
but also a lot of difference, and the analogy doesn't go very far.
For example, XEmacs is to Emacs as Linux is to what?  There's no
answer that fits.

Some of what I said about XEmacs is applicable to Linux as well.  I
think that Linus is taking an unnecessary risk by not getting legal
papers for code contributed to Linux.  But I'm not involved in the
matter in any way, so all I can do is hope that the possible problems
don't actually arise.  (I feel the same about XEmacs.)

The rest of what I said just isn't applicable to Linux.





  

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 20:54:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA16019 for xemacs-beta-people; Thu, 12 Sep 1996 20:54:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA16016 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 20:54:48 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA01203 for <xemacs-beta@cs.uiuc.edu>; Thu, 12 Sep 1996 20:54:48 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id SAA17567; Thu, 12 Sep 1996 18:54:12 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id SAA16282; Thu, 12 Sep 1996 18:54:08 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA04276; Thu, 12 Sep 1996 18:54:07 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA22631; Thu, 12 Sep 1996 18:54:06 -0700
Date: Thu, 12 Sep 1996 18:54:06 -0700
Message-Id: <199609130154.SAA22631@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b25 OK on Solaris 
In-Reply-To: <199606181754.MAA10845@nvwls.cc.purdue.edu>
References: <199606181641.JAA10120@xemacs.eng.sun.com>
	<199606181754.MAA10845@nvwls.cc.purdue.edu>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Joe" == Joseph J Nuspl <nuspl@nvwls.cc.purdue.edu> writes:

>>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:

>>>>> "Georg" == Georg Nikodym <georgn@detlev.Canada> writes:

Georg> Of course, I could be confused in thinking that the
Georg> asterisks are required in the names that I create for
Georg> shell-mode...

Martin> I've used shell buffers named `shell-1', `shell-2',
Martin> etc. for years.  I think this ought to be the default
Martin> behaviour, i.e. one should never have to manually rename a
Martin> shell-buffer to get a new one.

Joe> How about using the pty the shell is on for the buffer name?

The pty number is pretty meaningless to the user - it's only purpose
is uniqueness.  At least starting counting at 1 gives the user some
idea of how many shell buffers they have - and for many the first
buffer their XEmacs starts is somehow `primary'.

Martin


From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 21:12:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA16070 for xemacs-beta-people; Thu, 12 Sep 1996 21:12:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA16067 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 21:12:00 -0500 (CDT)
Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA07046 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 21:11:56 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id TAA04457 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 19:11:56 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id TAA09981 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 19:09:20 -0700
Date: Thu, 12 Sep 1996 19:09:20 -0700
Message-Id: <199609130209.TAA09981@shellx.best.com>
From: Ben Wing <wing@666.com>
To: Richard Stallman <rms@gnu.ai.mit.edu>
Subject: Re: Versions of Emacs
Cc: xemacs-beta@xemacs.org

>There is a certain amount of similarity between these two situations,
>but also a lot of difference, and the analogy doesn't go very far.
>For example, XEmacs is to Emacs as Linux is to what?  There's no
>answer that fits.
>
>Some of what I said about XEmacs is applicable to Linux as well.  I
>think that Linus is taking an unnecessary risk by not getting legal
>papers for code contributed to Linux.  But I'm not involved in the
>matter in any way, so all I can do is hope that the possible problems
>don't actually arise.  (I feel the same about XEmacs.)

If you really feel this way about XEmacs, then please don't make
statements like "Please help to improve GNU Emacs to the point where
XEmacs will disappear." This sounds like active antagonism rather than
merely disapproval at the decision of the XEmacs developers not to
follow your (IMHO overly restrictive) legal-papers standards.

BTW Linux would not exist if Linus insisted on the same legal-paper
assignment that you do.  In my opinion this would be far more harmful
to free software than the current situation.

I also believe that your continuing to argue with other members of the
free software community, and the many inflammatory statements you've
made about various non-GNU free software packages, serve no constructive
purpose other than to divide the free software community and turn
otherwise sympathetic people away from the community.  Is this really
your intention?

ben

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 21:11:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA16060 for xemacs-beta-people; Thu, 12 Sep 1996 21:11:16 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA16057 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 21:11:15 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA01375 for <xemacs-beta@cs.uiuc.edu>; Thu, 12 Sep 1996 21:11:12 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA15109; Thu, 12 Sep 1996 19:14:31 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: 19.15-b1 Crash (Linux 2.0/ELF)
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 12 Sep 1996 19:14:28 -0700
Message-ID: <m24tl32mbf.fsf@deanna.miranova.com>
Lines: 128
X-Mailer: Red Gnus v0.34/XEmacs 19.15

The crash came when filling a comment paragraph in lisp mode (I was
changing the copyright notice in ada.el to read XEmacs instead of GNU
Emacs).  I've synched a lot of packages with 19.34, but not fill,
filladapt, text mode, or lisp mode.  The C backtrace is enormously
helpful :-(.

Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Please report this bug to the address `crashes@xemacs.org'.
*MAKE SURE* to include as much configuration information as
possible; at the very least what OS and hardware you are running
on, and hopefully also what compiler and compiler options the
binary was compiled with, what options XEmacs was compiled with,
whether you are using a prebuilt binary from ftp.xemacs.org or
compiled XEmacs yourself for your system, etc.

If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started XEmacs, or maybe in your home
directory), and type

  gdb /i/xemacs-19.15-b1/src/xemacs core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  # bind (fpre)
  # (unwind-protect ...)
  # bind (fill-prefix nosqueeze justify to from)
  #<compiled-function (from "fill.elc") (from to &optional justify nosqueeze) "...(683)" [buffer-undo-list t from to " 	\n" nil oneleft from-plus-indent 0 10 use-hard-newlines get-text-property hard delete-backward-char 1 backward-char newline justify current-justification fill-prefix maybe-adapt-fill-prefix current-indentation current-left-margin indent-to-left-margin remove-text-properties (hard nil) (right center) "" "[ 	]*" regexp-quote fpre current-fill-column error "fill-prefix too long for specified width" looking-at indent-region re-search-forward "[.?!][])}\"']*$" 32 " 	" subst-char-in-region nosqueeze full canonically-space-region delete-horizontal-space " " linebeg prefixcol move-to-column "^ \n" sentence-end-double-space 2 46 -2 first -1 "\\. " "\\.  " "^ \n	" nchars fill-point move-to-left-margin "^ 	\n" set-text-properties text-properties-at justify-current-line] 6 773631 (byte-code "  #  E" [barf-if-buffer-read-only nil region-beginning region-end cu!
!
rrent-prefix-arg full] 4)>(282 513 nil nil)
  apply(#<compiled-function (from "fill.elc") (from to &optional justify nosqueeze) "...(683)" [buffer-undo-list t from to " 	\n" nil oneleft from-plus-indent 0 10 use-hard-newlines get-text-property hard delete-backward-char 1 backward-char newline justify current-justification fill-prefix maybe-adapt-fill-prefix current-indentation current-left-margin indent-to-left-margin remove-text-properties (hard nil) (right center) "" "[ 	]*" regexp-quote fpre current-fill-column error "fill-prefix too long for specified width" looking-at indent-region re-search-forward "[.?!][])}\"']*$" 32 " 	" subst-char-in-region nosqueeze full canonically-space-region delete-horizontal-space " " linebeg prefixcol move-to-column "^ \n" sentence-end-double-space 2 46 -2 first -1 "\\. " "\\.  " "^ \n	" nchars fill-point move-to-left-margin "^ 	\n" set-text-properties text-properties-at justify-current-line] 6 773631 (byte-code "  #  E" [barf-if-buffer-read-only nil region-beginning region-!
!
end current-prefix-arg full] 4)> (282 513 nil nil))
  # bind (args function)
  filladapt-funcall(fill-region-as-paragraph 282 513 nil nil)
  byte-code("\n
%" [filladapt-funcall fill-region-as-paragraph beg end justify nosqueeze] 6)
  # (condition-case ... . ((wrong-number-of-arguments (byte-code "\n$" ... 5))))
  byte-code("" [nil (byte-code "\n
%" [filladapt-funcall fill-region-as-paragraph beg end justify nosqueeze] 6) ((wrong-number-of-arguments ...))] 3)
  # bind (squeeze-after nosqueeze justify end beg)
  fill-region-as-paragraph(282 513 nil)
  # bind (end beg)
  # (unwind-protect ...)
  # bind (before arg)
  #<compiled-function (from "fill.elc") (arg) "...(60)" [fill-paragraph-function nil function arg before forward-paragraph newline 1 backward-paragraph beg end use-hard-newlines fill-region fill-region-as-paragraph] 5 774398 (list (if current-prefix-arg ...))>(nil)
  apply(#<compiled-function (from "fill.elc") (arg) "...(60)" [fill-paragraph-function nil function arg before forward-paragraph newline 1 backward-paragraph beg end use-hard-newlines fill-region fill-region-as-paragraph] 5 774398 (list (if current-prefix-arg ...))> nil)
  # bind (args function)
  filladapt-funcall(fill-paragraph nil)
  byte-code("	\"\"!\".\"" [filladapt-mode fill-prefix nil t retval comment-multi-line adaptive-fill-regexp adaptive-fill-mode paragraph-ignore-fill-prefix filladapt-adapt filladapt-funcall function arg run-hooks filladapt-fill-paragraph-post-hook throw done] 6)
  # (catch done ...)
  # bind (arg function)
  filladapt-fill-paragraph(fill-paragraph nil)
  # bind (filladapt-inside-filladapt arg)
  fill-paragraph(nil)
  # bind (paragraph-start paragraph-separate fill-prefix)
  # (unwind-protect ...)
  # bind (has-comment comment-fill-prefix justify)
  #<compiled-function (from "lisp-mode.elc") (&optional justify) "...(144)" [nil comment-fill-prefix has-comment 0 looking-at "[ 	]*;[; 	]*" t ";\\|$" "^;\n\"\\\\?" 92 2 (34 63) forward-sexp 1 ";+[	 ]*" make-string 32 fill-paragraph justify -1 "^[ 	]*;" paragraph-start "\\|[ 	;]*$" fill-prefix paragraph-separate] 3 769384 "P">(nil)
  apply(#<compiled-function (from "lisp-mode.elc") (&optional justify) "...(144)" [nil comment-fill-prefix has-comment 0 looking-at "[ 	]*;[; 	]*" t ";\\|$" "^;\n\"\\\\?" 92 2 (34 63) forward-sexp 1 ";+[	 ]*" make-string 32 fill-paragraph justify -1 "^[ 	]*;" paragraph-start "\\|[ 	;]*$" fill-prefix paragraph-separate] 3 769384 "P"> nil)
  # bind (args function)
  filladapt-funcall(lisp-fill-paragraph nil)
  byte-code("	\"\"!\".\"" [filladapt-mode fill-prefix nil t retval comment-multi-line adaptive-fill-regexp adaptive-fill-mode paragraph-ignore-fill-prefix filladapt-adapt filladapt-funcall function arg run-hooks filladapt-fill-paragraph-post-hook throw done] 6)
  # (catch done ...)
  # bind (arg function)
  filladapt-fill-paragraph(lisp-fill-paragraph nil)
  # bind (filladapt-inside-filladapt arg)
  lisp-fill-paragraph(nil)
  # bind (function fill-paragraph-function arg)
  #<compiled-function (from "fill.elc") (arg) "...(60)" [fill-paragraph-function nil function arg before forward-paragraph newline 1 backward-paragraph beg end use-hard-newlines fill-region fill-region-as-paragraph] 5 774398 (list (if current-prefix-arg ...))>(nil)
  apply(#<compiled-function (from "fill.elc") (arg) "...(60)" [fill-paragraph-function nil function arg before forward-paragraph newline 1 backward-paragraph beg end use-hard-newlines fill-region fill-region-as-paragraph] 5 774398 (list (if current-prefix-arg ...))> nil)
  # bind (args function)
  filladapt-funcall(fill-paragraph nil)
  byte-code("	\"\"!\".\"" [filladapt-mode fill-prefix nil t retval comment-multi-line adaptive-fill-regexp adaptive-fill-mode paragraph-ignore-fill-prefix filladapt-adapt filladapt-funcall function arg run-hooks filladapt-fill-paragraph-post-hook throw done] 6)
  # (catch done ...)
  # bind (arg function)
  filladapt-fill-paragraph(fill-paragraph nil)
  # bind (filladapt-inside-filladapt arg)
  fill-paragraph(nil)
  # bind (arg)
  fill-paragraph-or-region(nil)
  # bind (command-debug-status)
  call-interactively(fill-paragraph-or-region)
  # (condition-case ... . error)
  # (catch top-level ...)

Configured for `i486-unknown-linux2.0.18'.

  Where should the build process find the source code?    /i/xemacs-19.15-b1
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


(gdb) where
#0  0x40204741 in __kill ()
#1  0x8081289 in fatal_error_signal (sig=11) at emacs.c:191
#2  0xbfffd7cc in __ypbindlist ()


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 21:41:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA16168 for xemacs-beta-people; Thu, 12 Sep 1996 21:41:01 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA16165 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 21:41:01 -0500 (CDT)
Received: from sandman.cisco.com (sandman.cisco.com [171.68.209.51]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA07101 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 21:40:57 -0500 (CDT)
Received: (from drich@localhost) by sandman.cisco.com (8.6.11/CA/950118) id TAA24869 for xemacs-beta@xemacs.org; Thu, 12 Sep 1996 19:40:26 -0700
Date: Thu, 12 Sep 1996 19:40:26 -0700
From: Dan Rich <drich@cisco.com>
Message-Id: <199609130240.TAA24869@sandman.cisco.com>
To: xemacs-beta@xemacs.org
Subject: xemacs 19.15b1 crash on SunOS 4.1.3u1

I just had my first xemacs crash in a long time.  I was reading news, went 
into a group, and the next thing I knew all of my XEmacs frames were gone.

This is XEmacs 19.15b1, the gnus that comes with it, tm 7.84 (I'm betting
the crash was caused by tm, as the last error I saw was regarding a bad
jpeg in an article).

Anyway, here's the dump info:

Lisp backtrace follows:

  # (unwind-protect ...)
  # (unwind-protect ...)
  specifier-instance(#<image-specifier global=((... . ...) (... . ...) (... . ...)) fallback=((nil . ...)) 0x145e7> nil nil nil)
  # bind (value no-fallback default domain property glyph)
  glyph-property-instance(#<glyph (buffer) #<image-specifier global=(... ... ...) fallback=(...) 0x145e7>0x145e6> image nil nil nil)
  # bind (no-fallback default domain glyph)
  glyph-image-instance(#<glyph (buffer) #<image-specifier global=(... ... ...) fallback=(...) 0x145e7>0x145e6>)
  # bind (data minor gl end beg charset m mode encoding params ctype)
  mime-preview/filter-for-inline-image("image/jpeg" (("name" . "3r.jpg")) "base64")
  # bind (f)
  # (unwind-protect ...)
  # bind (encoding subj params ctype cinfo rcnum end beg)
  mime-preview/display-body(1564 244791 (1) [mime::content-info nil 1 244822 "multipart/mixed" (("boundary" . "------------3D0F43CE49CD")) nil ([mime::content-info ... 1149 1414 "text/plain" ... "7bit" nil] [mime::content-info ... 1442 244791 "image/jpeg" ... "base64" nil])] "image/jpeg" (("name" . "3r.jpg")) "3r.jpg" "base64")
  # bind (subj ne nb e he rcnum encoding params ctype end beg obuf ibuf cinfo content)
  mime-preview/display-content([mime::content-info (1) 1442 244791 "image/jpeg" (("name" . "3r.jpg")) "base64" nil] [mime::content-info nil 1 244822 "multipart/mixed" (("boundary" . "------------3D0F43CE49CD")) nil ([mime::content-info ... 1149 1414 "text/plain" ... "7bit" nil] [mime::content-info ... 1442 244791 "image/jpeg" ... "base64" nil])] #<buffer " *Original Article*"> "*Article*")
  # bind (drest mode the-buf dest pcl cinfo obuf)
  mime-viewer/make-preview-buffer("*Article*")
  # bind (obuf ibuf encoding ctl)
  mime-viewer/setup-buffer(nil nil " *Original Article*" "*Article*")
  # bind (mother-keymap obuf ibuf encoding ctl mother)
  mime/viewer-mode(nil nil nil " *Original Article*" "*Article*" #<keymap 346 entries 0xaa56>)
  byte-code("\n

                 &" [mime/viewer-mode nil gnus-original-article-buffer gnus-article-buffer gnus-article-mode-map] 7)
  # (unwind-protect ...)
  # bind (mime-viewer/ignored-field-regexp default-mime-charset)
  gnus-article-preview-mime-message()
  # bind (buffer-read-only)
  # (unwind-protect ...)
  # bind (result group internal-hook summary-buffer article)
  # (unwind-protect ...)
  # bind (header all-headers article)
  gnus-article-prepare(80834 nil)
  # bind (all-header article)
  gnus-summary-display-article(80834)
  gnus-summary-first-unread-article()
  # bind (did-select quit-config new-group no-display kill-buffer no-article show-all group)
  gnus-summary-read-group("alt.sex.masturbation" nil nil)
  # bind (group number active marked entry group no-article all)
  gnus-group-read-group(nil)
  # bind (e)
  gnus-mouse-pick-group(#<buttondown-event button2>)
  # bind (command-debug-status)
  call-interactively(gnus-mouse-pick-group)
  # (condition-case ... . error)
  # (catch top-level ...)

[1]+  Segmentation fault      (core dumped) /local/beta/bin/xemacs


and the backtrace

drich@sandman|542> gdb /local/beta/bin/xemacs core
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (sparc-sun-sunos4.1), Copyright 1996 Free Software Foundation, Inc...
Core was generated by `xemacs-19.15-b1'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/X11R6/lib/libXaw.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libXpm.so.4.3...done.
Reading symbols from /usr/local/X11R6/lib/libXmu.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libXt.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libSM.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libICE.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libXext.so.6.0...done.
Reading symbols from /usr/local/X11R6/lib/libX11.so.6.1...done.
Reading symbols from /usr/lib/libc.so.1.9.8...done.
Reading symbols from /usr/lib/libdl.so.1.0...done.
#0  0xef5ef138 in kill ()
(gdb) where
#0  0xef5ef138 in kill ()
#1  0x4c830 in fatal_error_signal (sig=11) at emacs.c:191
#2  <signal handler called>
#3  jpeg_instantiate (image_instance=-268453400, instantiator=
Cannot access memory at address 0x2107cf68.
) at glyphs-x.c:1314
Cannot access memory at address 0x2107d354.
(gdb) 




From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 22:22:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA16262 for xemacs-beta-people; Thu, 12 Sep 1996 22:22:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA16259 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 22:22:41 -0500 (CDT)
Received: from maildeliver1.tiac.net (maildeliver1.tiac.net [199.0.65.213]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA07120 for <xemacs-beta@xemacs.org>; Thu, 12 Sep 1996 22:22:38 -0500 (CDT)
Received: from legacy.pajato.com (legacy.pajato.com [207.60.29.10]) by maildeliver1.tiac.net (8.6.12/8.7.4) with ESMTP id XAA04106; Thu, 12 Sep 1996 23:24:03 -0400
Received: by legacy.pajato.com (8.6.10/200.12.1.1)
	id XAA01872; Thu, 12 Sep 1996 23:17:32 -0400
Date: Thu, 12 Sep 1996 23:17:32 -0400
Message-Id: <199609130317.XAA01872@legacy.pajato.com>
From: Paul Michael Reilly <pmr@legacy.pajato.com>
To: Ben Wing <wing@666.com>
Cc: Richard Stallman <rms@gnu.ai.mit.edu>, xemacs-beta@xemacs.org
Subject: Re: Versions of Emacs
In-Reply-To: <199609130209.TAA09981@shellx.best.com>
References: <199609130209.TAA09981@shellx.best.com>

Ben Wing writes:
 > >There is a certain amount of similarity between these two situations,
 > >but also a lot of difference, and the analogy doesn't go very far.
 > >For example, XEmacs is to Emacs as Linux is to what?  There's no
 > >answer that fits.
 > >
 > >Some of what I said about XEmacs is applicable to Linux as well.  I
 > >think that Linus is taking an unnecessary risk by not getting legal
 > >papers for code contributed to Linux.  But I'm not involved in the
 > >matter in any way, so all I can do is hope that the possible problems
 > >don't actually arise.  (I feel the same about XEmacs.)
 > 
 > If you really feel this way about XEmacs, then please don't make
 > statements like "Please help to improve GNU Emacs to the point where
 > XEmacs will disappear." This sounds like active antagonism rather than
 > merely disapproval at the decision of the XEmacs developers not to
 > follow your (IMHO overly restrictive) legal-papers standards.
 > 
 > BTW Linux would not exist if Linus insisted on the same legal-paper
 > assignment that you do.  In my opinion this would be far more harmful
 > to free software than the current situation.
 > 
 > I also believe that your continuing to argue with other members of the
 > free software community, and the many inflammatory statements you've
 > made about various non-GNU free software packages, serve no constructive
 > purpose other than to divide the free software community and turn
 > otherwise sympathetic people away from the community.  Is this really
 > your intention?

How distressing.  Man do I wish this pissing contest would end and we
could see positive, constructive energy expended to make both versions
better, via sharing of code such that the legal issue is covered.

Is there any way that either you or Richard can publish, to this list
and the Emacs news groups, the names and abstracts for the pieces of
code that make sense to integrate into Emacs such that the authors can
be identified, along with their willingness to generate legal papers?
And if the authors are not willing to generate papers, then maybe
interested developers might rewrite the pieces so that THEY can legally 
contribute the code.

=pmr

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 12 23:35:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA16414 for xemacs-beta-people; Thu, 12 Sep 1996 23:35:19 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA16411 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 12 Sep 1996 23:35:18 -0500 (CDT)
Received: from sweden.aosi.com (mail.aosi.com [206.98.255.22]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA03426 for <xemacs-beta@cs.uiuc.edu>; Thu, 12 Sep 1996 23:35:16 -0500 (CDT)
Received: from hlork (47.aosi.com [206.98.255.47]) by sweden.aosi.com
          (post.office MTA v1.9.3b ID# 0-16356) with SMTP id AAA55
          for <xemacs-beta@cs.uiuc.edu>; Fri, 13 Sep 1996 00:38:40 -0500
Sender: root@.aosi.com
Message-ID: <3238E5D2.2441DB65@aosi.com>
Date: Fri, 13 Sep 1996 00:40:50 -0400
From: Joel Peterson <tarzan@aosi.com>
Organization: Me Tarzan, you Jane?
X-Mailer: Mozilla 3.0 (X11; U; Linux 1.3.97 i586)
MIME-Version: 1.0
To: xemacs-beta@cs.uiuc.edu
Subject: Patch to enable menu accelerator keys
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is a patch against XEmacs 19.14 that also installs cleanly and has been
tested against 19.15 beta 1 to enable MS-Windoze style accelerators for
XEmacs.  Currently, it's only implemented for the Lucid menubar.  Someone
else will need to write the support functions for it to work with other
toolkits (Motif and tty?) since I don't have the time or the Motif library.
Support for Motif menus should probably only entail adding support for
underlining the accelerator key.  Support for tty is more complicated since
it involves writing a lwlib lookalike.

This release should be considered a BETA implementation.  Bug reports, fixes
and comments can be sent to tarzan@aosi.com.  (my real name is
Joel Peterson, not Tarzan).

This release does not modify any of the menu definitions included with emacs.
To test the menu accelerators, either click on the menubar to bring it up then
traverse it with keystrokes (arrow keys) or define and install your own
menu that has accelerators.  An example of such a menu is

(add-submenu nil '("%_Accelerator"
		   ["%_Find file" find-file t]
		   ["Exit %_emacs" save-buffers-kill-emacs t]))

You also need to set menu-accelerator-enabled to either 'menu-force or 
'menu-fallback.

How it works (user):

See MS-Windoze.  It currently allows selection and traversal of ghosted menu
items.  This will probably be removed from the final version (see the TODO
section).

How it works (elisp):

The current menubar specification can contain accelerator keys.  The 
accelerator for a particular menu item is specified either in its name by
preceding the accelerator with `%_' or by using the keyword `:accelerator'.
In the former case, the accelerator will also be underlined in the menu name.

There are several emacs variables that control when top level submenus
(eg "File") can be popped up directly from their accelerator.

menu-accelerator-enabled defaults to nil and controls where emacs will check
for the initial menu accelerator.  It can be 'menu-force, which means that
emacs attempts to match keystrokes to the menu accelerator before checking the
keymap, or 'menu-fallback, which means that emacs attempts to match keystrokes
to the menu accelerator after failing to find a binding in the keymap.  Any
other value will disable menu accelerators for top level submenus.

menu-accelerator-prefix defaults to nil and is a list of prefix keys that
must be matched prior to the accelerator key.  These keys must also be bound as
prefix keys in the normal emacs keymap, or the menu accelerators will be
unreachable.  See the TODO section about this.

menu-accelerator-modifiers defaults to (meta) and is a list of modifier keys
that must be pressed in addition to the initial accelerator.

The function accelerate-menu will send emacs to the top level of the menubar
even if no menu accelerators have been defined.  This function can be bound
to a key (maybe C-x C-m).

Once emacs has entered the top level of the menu tree, any defined
menu accelerator keys and the keymap menu-accelerator-map are checked for
actions.  The documentation for menu-accelerator-map contains a list of special
actions that can be bound to keys in order to traverse the menu tree (see TODO).

How it works (other toolkits):

In order for menu accelerators to work with other toolkits there needs to be
support for replacing `%_' in the menu name by underlining the next character.
The following functions also need to be implemented/ported/tested with the
toolkit.  The names 'lw_*' are #define'ed in lwlib.h from their actual toolkit
specific names.  The same calls that work with Lucid menubars *should* also
work with Motif menubars, but that hasn't been tested.

void lw_set_menu (Widget w, widget_value *val);

	initialization call.  Prepares to display the menu item pointed to by
	VAL, which must be the widget_value structure for a top level submenu.
	W is the X11 menubar widget or equivalent.

void lw_map_menu (Time t);

	Another initialization call which must be called after lw_set_menu but
	before the first lw_display_menu.  This needs to set the variable
	lw_menu_active to True.  This takes care of things like grabbing the
	mouse pointer and initializing fields in the XlwMenuWidget structure.

void lw_push_menu (widget_value *val);

	Add VAL to the menu tree.  All previous values in the tree must be
	submenus.  VAL will become the highlighed item in the current submenu.

int lw_pop_menu ();

	pop an item off the menu tree.  Return True if there was an item to 
	pop.

void lw_set_item (widget_value *val);

	The same as 
		lw_pop_item ();
		lw_push_item (val);

void lw_display_menu (Time t);

	Display or re-display the menu tree taking into account the changes
	made by the other functions.  The value t is passed to lwlib internal
	routines.  It's usually just set to CurrentTime.  It should probably
	be copied from the emacs event structure somehow.  This needs to set
	lw_menu_accelerate to True.  Whatever gets called to destroy the menus
	should reset this variable and lw_menu_active to False.  These variables
	are used by the code in event-stream.c to determine how to handle
	accelerator keypresses.

void lw_kill_menus (widget_value *val);

	Undisplay the menus and invoke the callback function for VAL (if NULL,
	just kill the menus).

widget_value *lw_get_entries (int allp);

	If allp is True, return a list of all entries in the current submenu.
	If allp is False, return the currently highlighted item.

int lw_menu_level ();

	return the menu level.  The very top level of the menu tree, which is 
	displayed all the time, is 1.  If a top level submenu is the current
	highlighted item, the level is 2.  If an item in a top level submenu is
	the current highlighted item, the level is 3, and so on.


The following C visible variables are defined and used by the modules and are
needed by the actual accelerator handling code in event-stream.c:

int lw_menu_active;

	boolean variable indicating whether the menus are currently
	active or not.

int lw_menu_accelerate;

	boolean variable indicating whether a keyboard accelerator or a
	mouse action was responsible for the last menu operation.  Mouse
	operations leave the lwlib menu structures in a different state
	than do keyboard operations (mouse operations automatically open
	and display submenus when they are highlighted, while keyboard
	operations do not)

TODO
----

1.	Test test test.
	run the tests at the end of event-stream.c for each of these cases and
	just put it through its paces.
		Emacs with accelerators (menu_force)
		Emacs with accelerators (menu_fallback)
		Emacs without accelerators
	Also test :accelerator keyword and menu-accelerator-prefix.
	Currently, menu_force has gotten the most testing.
2.	Write version of default menubar that has accelerators (underlined
	char) and figure out when to use it.  I think the best solution is to
	have the code that draws menus figure out that menu acceleration is
	disabled, and not to draw underlines even though accelerator keys are
	indicated.
3.	Find something better way than menu-accelerator-prefix to specify a
	prefix key for top level menu accelerators.
4.	Find a better way to find the upper left corner of the menubar widget
	(see lwlib/xlwmenu.c)
5.	Create DEFUNS for the basic menu actions so that people can customize
	functions on menu-accelerator-map.
6.	Do something about ghosted items.  If we allow traversal, then they
	should be highlighted somehow.  If not, then traversal should be 
	turned off.
7.	Fix the non-echoing of menu accelerating keystrokes.  Currently, the
	most recent key is echoed.

-- 
 ^^^^^
(o   o)   "I'm Living a Fractured Fairy Tale life."
/  v  \            - Joel Peterson
\ --- /                  Supreme Deputy of scratching Dogbert behind the
 \___/                   ears until he has little leg spasms.


Here is the patch:
Hopefully, Netscape mail won't have screwed it up by deciding that the lines
need to be wrapped even though I think I told it not too.  We'll see.
Install it by cd'ing to the top of the xemacs source tree (the directory that
contains src/ and lisp/) and typing
  patch -p1 <[whatever you called this file]
--------------------------------------------------------------------------

diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/lisp/prim/menubar.el xemacs-19.14-accel/lisp/prim/menubar.el
*** xemacs-19.14/lisp/prim/menubar.el	Sun Apr  7 18:58:36 1996
--- xemacs-19.14-accel/lisp/prim/menubar.el	Sun Jul  7 17:20:30 1996
***************
*** 65,73 ****
      (setq menu (cdr menu)))
    (let (menuitem item)
      (while (keywordp (setq item (car menu)))
!       (or (memq item '(:config :included :filter))
  	  (signal 'error
! 		  (list "menu keyword must be :config, :included, or :filter"
  			item)))
        (if (or (not (cdr menu))
  	      (vectorp (nth 1 menu))
--- 65,73 ----
      (setq menu (cdr menu)))
    (let (menuitem item)
      (while (keywordp (setq item (car menu)))
!       (or (memq item '(:config :included :filter :accelerator))
  	  (signal 'error
! 		  (list "menu keyword must be :config, :included, :accelerator or :filter"
  			item)))
        (if (or (not (cdr menu))
  	      (vectorp (nth 1 menu))
***************
*** 132,138 ****
  		(while (< i L)
  		  (setq item (aref menuitem i))
  		  (cond ((not (memq item '(:active :suffix :keys :style
! 						   :full :included :selected)))
  			 (signal 'error
  				 (list (if (keywordp item)
  					   "unknown menu item keyword"
--- 132,139 ----
  		(while (< i L)
  		  (setq item (aref menuitem i))
  		  (cond ((not (memq item '(:active :suffix :keys :style
! 						   :full :included :selected
! 						   :accelerator)))
  			 (signal 'error
  				 (list (if (keywordp item)
  					   "unknown menu item keyword"
***************
*** 480,485 ****
--- 481,498 ----
  			    (event-window event)))
  	   (funcall (event-function response)
  		    (event-object response))))))
+ 
+ ;; provide default bindings for menu accelerator map
+ (and (boundp 'menu-accelerator-map)
+      (keymapp menu-accelerator-map)
+      (progn
+        (define-key menu-accelerator-map "\e" 'menu-escape)
+        (define-key menu-accelerator-map [left] 'menu-left)
+        (define-key menu-accelerator-map [right] 'menu-right)
+        (define-key menu-accelerator-map [up] 'menu-up)
+        (define-key menu-accelerator-map [down] 'menu-down)
+        (define-key menu-accelerator-map [return] 'menu-select)
+        (define-key menu-accelerator-map "\C-g" 'menu-quit)))
  
  
  (provide 'menubar)
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/lwlib/lwlib.c xemacs-19.14-accel/lwlib/lwlib.c
*** xemacs-19.14/lwlib/lwlib.c	Thu Jun 20 13:47:20 1996
--- xemacs-19.14-accel/lwlib/lwlib.c	Sun Jul  7 17:20:31 1996
***************
*** 74,79 ****
--- 74,88 ----
     */
  static widget_info *all_widget_info = NULL;
  
+ /* boolean flag indicating that the menubar is active */
+ int lw_menu_active = 0;
+ 
+ /* X11 menubar widget */
+ Widget lw_menubar_widget = NULL;
+ 
+ /* whether the last menu operation was a keyboard accelerator */
+ int lw_menu_accelerate = False;
+ 
  
  /* Forward declarations */
  static void
***************
*** 261,266 ****
--- 270,276 ----
        copy->name = safe_strdup (val->name);
        copy->value = safe_strdup (val->value);
        copy->key = safe_strdup (val->key);
+       copy->accel = val->accel;
        copy->enabled = val->enabled;
        copy->selected = val->selected;
        copy->edited = False;
***************
*** 553,558 ****
--- 563,575 ----
        change = max (change, VISIBLE_CHANGE);
        safe_free_str (val1->key);
        val1->key = safe_strdup (val2->key);
+     }
+   if (val1->accel != val2->accel)
+     {
+       EXPLAIN (val1->name, change, VISIBLE_CHANGE, "accelerator change",
+ 	       val1->accel, val2->accel);
+       change = max (change, VISIBLE_CHANGE);
+       val1->accel = val2->accel;
      }
    if (val1->enabled != val2->enabled)
      {
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/lwlib/lwlib.h xemacs-19.14-accel/lwlib/lwlib.h
*** xemacs-19.14/lwlib/lwlib.h	Sun Jan  7 18:56:30 1996
--- xemacs-19.14-accel/lwlib/lwlib.h	Sun Aug 11 11:33:59 1996
***************
*** 105,110 ****
--- 105,112 ----
    int scrollbar_x, scrollbar_y;
  } scrollbar_values;
  
+ typedef long accel_type;
+ 
  typedef struct _widget_value
  {
    /* This slot is only partially utilized right now. */
***************
*** 116,121 ****
--- 118,129 ----
    char*		value;
    /* keyboard equivalent. no implications for XtTranslations */ 
    char*		key;
+   /* accelerator key.  For XEmacs, this should be a Lisp_Object holding a
+      char or symbol suitable for passing to event_matches_key_specifier_p.
+      lwlib provides support functions for keyboard traversal of menus.  Actual
+      implementation of those accelerators is up to the application.
+      */
+   accel_type	accel;
    /* true if enabled */
    Boolean	enabled;
    /* true if selected */
***************
*** 147,152 ****
--- 155,190 ----
  
  
  typedef void (*lw_callback) (Widget w, LWLIB_ID id, XtPointer data);
+ 
+ /* menu stuff */
+ /* this should go somewhere else, probably */
+ 
+ extern int lw_menu_active;
+ 
+ /* the #define's are used to obfuscate the fact that these are X menus
+    the same interface should work with other window managers or even
+    tty menus as long as some of the semantics of lwlib are followed.
+    I check for Lucid menubars because those are the only ones that I
+    know work.  If you want to try the accelerators with Motif, add
+    `|| defined (LWLIB_MENUBARS_MOTIF)' to this #if
+       -jip
+    */
+ 
+ #if defined (LWLIB_MENUBARS_LUCID)
+ #include "xlwmenu.h"
+ #define lw_set_menu xlw_set_menu
+ #define lw_push_menu xlw_push_menu
+ #define lw_pop_menu xlw_pop_menu
+ #define lw_set_item xlw_set_item
+ #define lw_map_menu xlw_map_menu
+ #define lw_display_menu xlw_display_menu
+ #define lw_kill_menus xlw_kill_menus
+ #define lw_get_entries xlw_get_entries
+ #define lw_menu_level xlw_menu_level
+ #else /* MENUBARS_LUCID */
+ /* do this for the other toolkits too */
+ 
+ #endif /* MENUBARS_LUCID */
  
  void  lw_register_widget (CONST char* type, CONST char* name, LWLIB_ID id,
  			  widget_value* val, lw_callback pre_activate_cb,
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/lwlib/xlwmenu.c xemacs-19.14-accel/lwlib/xlwmenu.c
*** xemacs-19.14/lwlib/xlwmenu.c	Sun Jun 16 15:38:29 1996
--- xemacs-19.14-accel/lwlib/xlwmenu.c	Sat Aug 10 22:36:43 1996
***************
*** 38,43 ****
--- 38,48 ----
  #endif
  #include "xlwmenuP.h"
  
+ /* simple, naieve integer maximum */
+ #ifndef max
+ #define max(a,b) ((a)>(b)?(a):(b))
+ #endif
+ 
  static char 
  xlwMenuTranslations [] = 
  "<BtnDown>:	start()\n\
***************
*** 45,50 ****
--- 50,57 ----
  <BtnUp>:	select()\n\
  ";
  
+ extern Widget lw_menubar_widget;
+ 
  #define offset(field) XtOffset(XlwMenuWidget, field)
  static XtResource 
  xlwMenuResources[] =
***************
*** 189,194 ****
--- 196,203 ----
  
  WidgetClass xlwMenuWidgetClass = (WidgetClass) &xlwMenuClassRec;
  
+ extern int lw_menu_accelerate;
+ 
  /* Utilities */
  #if 0 /* Apparently not used anywhere */
  
***************
*** 313,326 ****
  {
    if (!mw->menu.old_stack)
      {
!       mw->menu.old_stack_length = 10;
        mw->menu.old_stack =
  	(widget_value**)XtCalloc (mw->menu.old_stack_length,
  				  sizeof (widget_value*));
      }
    else if (mw->menu.old_stack_length < n)
      {
!       mw->menu.old_stack_length *= 2;
        mw->menu.old_stack =
  	(widget_value**)XtRealloc ((char*)mw->menu.old_stack,
  				   mw->menu.old_stack_length *
--- 322,337 ----
  {
    if (!mw->menu.old_stack)
      {
!       mw->menu.old_stack_length = max (10, n);
        mw->menu.old_stack =
  	(widget_value**)XtCalloc (mw->menu.old_stack_length,
  				  sizeof (widget_value*));
      }
    else if (mw->menu.old_stack_length < n)
      {
!       while (mw->menu.old_stack_length < n)
! 	mw->menu.old_stack_length *= 2;
!       
        mw->menu.old_stack =
  	(widget_value**)XtRealloc ((char*)mw->menu.old_stack,
  				   mw->menu.old_stack_length *
***************
*** 358,363 ****
--- 369,407 ----
  #endif
  }
  
+ static int
+ string_width_u (XlwMenuWidget mw,
+ #ifdef NEED_MOTIF
+ 	      XmString s
+ #else
+ 	      char *string
+ #endif
+ 	      )
+ {
+ #ifdef NEED_MOTIF
+   Dimension width, height;
+   XmStringExtent (mw->menu.font_list, s, &width, &height);
+   return width;
+ #else
+   XCharStruct xcs;
+   int i,s=0,w=0;
+   int drop;
+   for (i=0;string[i];++i) {
+ 	  if (string[i]=='%'&&string[i+1]=='_') {
+ 		  XTextExtents (mw->menu.font, &string[s], i-s, &drop, &drop, &drop, &xcs);
+ 		  w += xcs.width;
+ 		  s = i + 2;
+ 		  ++i;
+ 	  }
+   }
+   if (string[s]) {
+ 	  XTextExtents (mw->menu.font, &string[s], i-s, &drop, &drop, &drop, &xcs);
+ 	  w += xcs.width;
+   }
+   return w;
+ #endif
+ }
+ 
  static void
  massage_resource_name (CONST char *in, char *out)
  {
***************
*** 699,704 ****
--- 743,804 ----
  #endif
  }
  
+ static void
+ string_draw_u (
+ 	    XlwMenuWidget mw,
+ 	    Window window,
+ 	    int x, int y,
+ 	    GC gc,
+ #ifdef NEED_MOTIF
+ 	    XmString string
+ #else
+ 	    char *string
+ #endif
+ ) {
+ #ifdef NEED_MOTIF
+   XmStringDraw (XtDisplay (mw), window,
+ 		mw->menu.font_list,
+ 		string, gc,
+ 		x, y,
+ 		1000,	/* ???? width */
+ 		XmALIGNMENT_BEGINNING,
+ 		0, /* ???? layout_direction */
+ 		0);
+ #else
+   int i,s=0;
+   for (i=0;string[i];++i) {
+       if (string[i]=='%'&&string[i+1]=='_') {
+ 	  XCharStruct xcs;
+ 	  int drop;
+ 	  /* underline next character */
+ 	  if (i>s)
+ 	      XDrawString (XtDisplay (mw), window, gc,
+ 			   x, y + mw->menu.font_ascent, &string[s], i-s);
+ 	  
+ 	  XTextExtents (mw->menu.font, &string[s], i-s, &drop, &drop, &drop, &xcs);
+ 	  x += xcs.width;
+ 	  
+ 	  s=i+3;
+ 	  i+=2;
+ 	  
+ 	  XDrawString (XtDisplay (mw), window, gc,
+ 		       x, y + mw->menu.font_ascent, &string[i], 1);
+ 	  
+ 	  XTextExtents (mw->menu.font, &string[i], 1, &drop, &drop, &drop, &xcs);
+ 	  
+ 	  XDrawLine (XtDisplay (mw), window, gc, x - 1, y + mw->menu.font_ascent + 1,
+ 		     x + xcs.width - 1, y + mw->menu.font_ascent + 1 );
+ 	  
+ 	  x += xcs.width;
+       }
+   }
+   if (string[s]) 
+       XDrawString (XtDisplay (mw), window, gc,
+ 		   x, y + mw->menu.font_ascent, &string[s], strlen (&string[s]));
+       
+ #endif
+ }
+ 
  static void 
  binding_draw (XlwMenuWidget mw, Window w, int x, int y, GC gc, char *value)
  {
***************
*** 1365,1371 ****
    /* no left column decoration */
    *toggle_width = mw->menu.horizontal_margin + mw->menu.shadow_thickness;;
    
!   *label_width  = string_width (mw, resource_widget_value (mw, val));
    *bindings_width =  mw->menu.horizontal_margin + mw->menu.shadow_thickness;
  }
  
--- 1465,1471 ----
    /* no left column decoration */
    *toggle_width = mw->menu.horizontal_margin + mw->menu.shadow_thickness;;
    
!   *label_width  = string_width_u (mw, resource_widget_value (mw, val));
    *bindings_width =  mw->menu.horizontal_margin + mw->menu.shadow_thickness;
  }
  
***************
*** 1391,1397 ****
    /*
     *    Draw the label string.
     */
!   string_draw (
  	       mw,
  	       window,
  	       x + label_offset, y + y_offset, 
--- 1491,1497 ----
    /*
     *    Draw the label string.
     */
!   string_draw_u (
  	       mw,
  	       window,
  	       x + label_offset, y + y_offset, 
***************
*** 1473,1479 ****
  	gc = mw->menu.inactive_gc;
      }
  
!   string_draw (
  	       mw,
  	       window,
  	       x + label_offset, y + y_offset, 
--- 1573,1579 ----
  	gc = mw->menu.inactive_gc;
      }
  
!   string_draw_u (
  	       mw,
  	       window,
  	       x + label_offset, y + y_offset, 
***************
*** 2080,2087 ****
  
    if (level < mw->menu.old_depth - 1)
      following_item = mw->menu.old_stack [level + 1];
!   else 
!     following_item = NULL;
  
  #if SLOPPY_TYPES == 1
    puts("===================================================================");
--- 2180,2193 ----
  
    if (level < mw->menu.old_depth - 1)
      following_item = mw->menu.old_stack [level + 1];
!   else
!     {
!       if (lw_menu_accelerate
! 	  && level == mw->menu.old_depth - 1
! 	  && mw->menu.old_stack [level]->type == CASCADE_TYPE)
! 	just_compute_p = True;
!       following_item = NULL;
!     }
  
  #if SLOPPY_TYPES == 1
    puts("===================================================================");
***************
*** 2340,2346 ****
      if (old_stack [i] != new_stack [i])
        break;
    last_same = i - 1;
! 
    /* Memorize the previously selected item to be able to refresh it */
    old_selection = last_same + 1 < old_depth ? old_stack [last_same + 1] : NULL;
    if (old_selection && !old_selection->enabled)
--- 2446,2458 ----
      if (old_stack [i] != new_stack [i])
        break;
    last_same = i - 1;
!   
!   if (lw_menu_accelerate
!       && last_same
!       && last_same == old_depth - 1
!       && old_stack [last_same]->contents)
!     last_same--;
!   
    /* Memorize the previously selected item to be able to refresh it */
    old_selection = last_same + 1 < old_depth ? old_stack [last_same + 1] : NULL;
    if (old_selection && !old_selection->enabled)
***************
*** 2353,2358 ****
--- 2465,2471 ----
       display_menu (called below) uses the old_stack to know what to display. */
    for (i = last_same + 1; i < new_depth; i++)
      old_stack [i] = new_stack [i];
+   
    mw->menu.old_depth = new_depth;
  
    /* refresh the last seletion */
***************
*** 2366,2372 ****
      {
        window_state *previous_ws = &windows [i - 1];
        window_state *ws = &windows [i];
! 
        ws->x = previous_ws->x + selection_position.x;
        ws->y = previous_ws->y + selection_position.y;
  
--- 2479,2488 ----
      {
        window_state *previous_ws = &windows [i - 1];
        window_state *ws = &windows [i];
!       
!       if (lw_menu_accelerate && i == new_depth - 1)
! 	break;
!       
        ws->x = previous_ws->x + selection_position.x;
        ws->y = previous_ws->y + selection_position.y;
  
***************
*** 2385,2392 ****
      }
  
    /* unmap the menus that popped down */
!   for (i = new_depth - 1; i < old_depth; i++)
!     if (i >= new_depth || !new_stack [i]->contents)
        XUnmapWindow (XtDisplay (mw), windows [i].window);
  }
  
--- 2501,2515 ----
      }
  
    /* unmap the menus that popped down */
!   
!   last_same = new_depth;
!   if (lw_menu_accelerate
!       && last_same > 1
!       && new_stack [last_same - 1]->contents)
!     last_same--;
!   
!   for (i = last_same - 1; i < old_depth; i++)
!     if (i >= last_same || !new_stack [i]->contents)
        XUnmapWindow (XtDisplay (mw), windows [i].window);
  }
  
***************
*** 3097,3102 ****
--- 3220,3226 ----
        event = &dummy;
      }
  
+   lw_menu_accelerate = False;
    handle_single_motion_event (mw, event, select_p);
  }
  
***************
*** 3104,3110 ****
  Start (Widget w, XEvent *ev, String *params, Cardinal *num_params)
  {
    XlwMenuWidget mw = (XlwMenuWidget)w;
! 
    if (!mw->menu.pointer_grabbed)
      {
        mw->menu.menu_post_time = ev->xbutton.time;
--- 3228,3238 ----
  Start (Widget w, XEvent *ev, String *params, Cardinal *num_params)
  {
    XlwMenuWidget mw = (XlwMenuWidget)w;
!   
!   lw_menubar_widget = w;
!   
!   lw_menu_active = True;
!   
    if (!mw->menu.pointer_grabbed)
      {
        mw->menu.menu_post_time = ev->xbutton.time;
***************
*** 3143,3148 ****
--- 3271,3278 ----
    XlwMenuWidget mw = (XlwMenuWidget)w;
    widget_value *selected_item = mw->menu.old_stack [mw->menu.old_depth - 1];
    
+   lw_menu_accelerate = False;
+   
    /* If user releases the button quickly, without selecting anything,
       after the initial down-click that brought the menu up,
       do nothing. */
***************
*** 3171,3179 ****
--- 3301,3475 ----
        mw->menu.popped_up = False;
        XtPopdown (XtParent (mw));
      }
+ 
+   lw_menu_active = False;
    
    /* callback */
    XtCallCallbackList ((Widget)mw, mw->menu.select, (XtPointer)selected_item);
+ }
+ 
+ /* Action procedures for keyboard accelerators */
+ 
+ /* set the menu */
+ void
+ xlw_set_menu (Widget w, widget_value *val)
+ {
+   lw_menubar_widget = w;
+   set_new_state ((XlwMenuWidget)w, val, 1);
+ }
+ 
+ /* prepare the menu structure via the call-backs */
+ void
+ xlw_map_menu (Time t)
+ {
+   XlwMenuWidget mw = (XlwMenuWidget)lw_menubar_widget;
+ 
+   lw_menu_accelerate = True;
+   
+   if (!mw->menu.pointer_grabbed)
+     {
+       XWindowAttributes ret;
+       Window parent,root;
+       Window *waste;
+       unsigned int num_waste;
+       
+       lw_menu_active = True;
+       
+       mw->menu.menu_post_time = t;
+       mw->menu.menu_bounce_time = 0;
+       
+       mw->menu.next_release_must_exit = True;
+       mw->menu.last_selected_val = NULL;
+       
+       XtCallCallbackList ((Widget)mw, mw->menu.open, NULL);
+ 
+       /* Mouse activated menubar does this: */
+       
+       /* notes the absolute position of the menubar window */
+       /*
+       mw->menu.windows [0].x = ev->xmotion.x_root - ev->xmotion.x;
+       mw->menu.windows [0].y = ev->xmotion.y_root - ev->xmotion.y;
+       */
+ 
+       /* We get to do this: */
+       
+       /* get the geometry of the menubar */
+       
+       /* there has to be a better way than this. */
+       
+       mw->menu.windows [0].x = 0;
+       mw->menu.windows [0].y = 0;
+       
+       parent = XtWindow (lw_menubar_widget);
+       do
+ 	{
+ 	  XGetWindowAttributes (XtDisplay (lw_menubar_widget), parent, &ret);
+ 	  mw->menu.windows [0].x += ret.x;
+ 	  mw->menu.windows [0].y += ret.y;
+ 	  
+ 	  if (parent)
+ 	    XQueryTree (XtDisplay (lw_menubar_widget), parent, &root, &parent, &waste,
+ 			&num_waste);
+ 	  if (waste)
+ 	    {
+ 	      XFree (waste);
+ 	    }
+ 	}
+       while (parent != root);
+       
+       XtGrabPointer ((Widget)mw, False,
+ 		     (ButtonMotionMask | ButtonReleaseMask | ButtonPressMask),
+ 		     GrabModeAsync, GrabModeAsync,
+ 		     None, mw->menu.cursor_shape, t);
+       mw->menu.pointer_grabbed = True;
+     }
+ }
+ 
+ /* display the stupid menu already */
+ void
+ xlw_display_menu (Time t)
+ {
+   XlwMenuWidget mw = (XlwMenuWidget)lw_menubar_widget;
+ 
+   lw_menu_accelerate = True;
+   
+   remap_menubar (mw);
+   
+   /* Sync with the display.  Makes it feel better on X terms. */
+   XFlush (XtDisplay (mw));
+ }
+ 
+ /* push a sub menu */
+ void
+ xlw_push_menu (widget_value *val)
+ {
+   push_new_stack ((XlwMenuWidget)lw_menubar_widget, val);
+ }
+ 
+ /* pop a sub menu */
+ int
+ xlw_pop_menu (void)
+ {
+   if (((XlwMenuWidget)lw_menubar_widget)->menu.new_depth > 0)
+     ((XlwMenuWidget)lw_menubar_widget)->menu.new_depth --;
+   else
+     return 0;
+   return 1;
+ }
+ 
+ void
+ xlw_kill_menus (widget_value *val)
+ {
+   XlwMenuWidget mw = (XlwMenuWidget)lw_menubar_widget;
+   
+   lw_menu_accelerate = False;
+   
+   mw->menu.new_depth = 1;
+   remap_menubar (mw);
+       
+   if (mw->menu.pointer_grabbed)
+     {
+       XtUngrabPointer (lw_menubar_widget, CurrentTime);
+       mw->menu.pointer_grabbed = False;
+     }
+ 
+   lw_menu_active = False;
+   
+   XtCallCallbackList (lw_menubar_widget, mw->menu.select, (XtPointer)val);
+ }
+ 
+ /* set the menu item */
+ void
+ xlw_set_item (widget_value *val)
+ {
+   if (((XlwMenuWidget)lw_menubar_widget)->menu.new_depth > 0)
+     ((XlwMenuWidget) lw_menubar_widget)->menu.new_depth --;
+   push_new_stack ((XlwMenuWidget) lw_menubar_widget, val);
+ }
+ 
+ /* get either the current entry or a list of all entries in the current submenu */
+ widget_value *
+ xlw_get_entries (int allp)
+ {
+   XlwMenuWidget mw = (XlwMenuWidget)lw_menubar_widget;
+   if (allp)
+     {
+       if (mw->menu.new_depth >= 2)
+ 	return mw->menu.new_stack [mw->menu.new_depth - 2]->contents;
+       else
+ 	return mw->menu.new_stack[0];
+     }
+   else
+     if (mw->menu.new_depth >= 1)
+       return mw->menu.new_stack [mw->menu.new_depth - 1];
+   
+   return NULL;
+ }
+ 
+ int
+ xlw_menu_level (void)
+ {
+   return ((XlwMenuWidget)lw_menubar_widget)->menu.new_depth;
  }
  
  
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/lwlib/xlwmenu.h xemacs-19.14-accel/lwlib/xlwmenu.h
*** xemacs-19.14/lwlib/xlwmenu.h	Tue Mar 21 00:00:40 1995
--- xemacs-19.14-accel/lwlib/xlwmenu.h	Sun Jul  7 17:20:31 1996
***************
*** 74,77 ****
--- 74,89 ----
  void
  xlw_pop_up_menu (XlwMenuWidget mw, XButtonPressedEvent* event);
  
+ /* menu accelerator */
+ 
+ void xlw_set_menu (Widget w, widget_value *val);
+ void xlw_push_menu (widget_value *val);
+ int xlw_pop_menu (void);
+ void xlw_set_item (widget_value *val);
+ void xlw_map_menu (Time t);
+ void xlw_display_menu (Time t);
+ void xlw_kill_menus (widget_value *val);
+ widget_value *xlw_get_entries (int allp);
+ int xlw_menu_level (void);
+ 
  #endif /* _XlwMenu_h */
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/emacs.c xemacs-19.14-accel/src/emacs.c
*** xemacs-19.14/src/emacs.c	Fri Jun 21 18:55:43 1996
--- xemacs-19.14-accel/src/emacs.c	Sun Jul  7 17:20:31 1996
***************
*** 1122,1129 ****
        /* Calls Fmake_range_table(). */
        complex_vars_of_search ();
  
-       /* Calls Fmake_hashtable(). */
-       complex_vars_of_event_stream ();
        /* Calls make_lisp_hashtable(). */
        complex_vars_of_extents ();
        
--- 1122,1127 ----
***************
*** 1197,1202 ****
--- 1195,1202 ----
  	 initialized in the vars_of_*() section) and possibly other
  	 stuff. */
        complex_vars_of_keymap ();
+       /* Calls Fmake_hashtable() and creates a keymap */
+       complex_vars_of_event_stream ();
  
        if (always_gc)                /* purification debugging hack */
  	garbage_collect_1 ();
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/emacsfns.h xemacs-19.14-accel/src/emacsfns.h
*** xemacs-19.14/src/emacsfns.h	Thu Jun 20 20:56:16 1996
--- xemacs-19.14-accel/src/emacsfns.h	Sun Jul  7 17:20:31 1996
***************
*** 1402,1407 ****
--- 1402,1408 ----
  extern Lisp_Object Qmouse_event_p; /* events.c */
  extern Lisp_Object Q_active, Q_suffix, Q_keys, Q_style, Q_selected;
  extern Lisp_Object Q_filter, Q_config, Q_included;
+ extern Lisp_Object Q_accelerator;
  extern Lisp_Object Qtoggle, Qradio;
  extern Lisp_Object Vmenubar_configuration;
  extern int menubar_show_keybindings;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/event-stream.c xemacs-19.14-accel/src/event-stream.c
*** xemacs-19.14/src/event-stream.c	Tue Jun 18 18:26:41 1996
--- xemacs-19.14-accel/src/event-stream.c	Tue Aug 13 17:53:37 1996
***************
*** 38,43 ****
--- 38,51 ----
  #include <config.h>
  #include "lisp.h"
  
+ #include "console-x.h"
+ #include "EmacsManager.h"
+ #include "EmacsFrame.h"
+ #include "EmacsShell.h"
+ #include "gui-x.h"
+ 
+ #include "lwlib.h"
+ 
  #include "buffer.h"
  #include "commands.h"
  #include "device.h"
***************
*** 174,179 ****
--- 182,214 ----
  /* File in which we write all commands we read; an lstream */
  static Lisp_Object Vdribble_file;
  
+ /* prefix key(s) that must match in order to activate menu.
+    This is ugly.  fix me.
+    */
+ Lisp_Object Vmenu_accelerator_prefix;
+ 
+ /* list of modifier keys to match accelerator for top level menus */
+ Lisp_Object Vmenu_accelerator_modifiers;
+ 
+ /* whether menu accelerators are enabled */
+ Lisp_Object Vmenu_accelerator_enabled;
+ 
+ /* keymap for auxillary menu accelerator functions */
+ Lisp_Object Vmenu_accelerator_map;
+ 
+ Lisp_Object Qmenu_force;
+ Lisp_Object Qmenu_fallback;
+ Lisp_Object Qmenu_quit;
+ Lisp_Object Qmenu_up;
+ Lisp_Object Qmenu_down;
+ Lisp_Object Qmenu_left;
+ Lisp_Object Qmenu_right;
+ Lisp_Object Qmenu_select;
+ Lisp_Object Qmenu_escape;
+ 
+ /* this is in keymap.c */
+ extern Lisp_Object Fmake_keymap (Lisp_Object name);
+ 
  #ifdef DEBUG_XEMACS
  int debug_emacs_events;
  #endif
***************
*** 2099,2104 ****
--- 2134,2141 ----
        goto RETURN;
      case button_release_event:
      case misc_user_event:
+       /* don't echo menu accelerator keys */
+       reset_key_echo (command_builder, True);
        goto EXECUTE_KEY;
      case button_press_event:	/* key or mouse input can trigger prompting */
        goto STORE_AND_EXECUTE_KEY;
***************
*** 2870,2875 ****
--- 2907,3356 ----
    return event_binding (event0, 1);
  }
  
+ static void
+ menu_move_up (void)
+ {
+   widget_value *current, *prev;
+   widget_value *entries;
+   
+   current = lw_get_entries (False);
+   entries = lw_get_entries (True);
+   prev = NULL;
+   if (current != entries)
+     {
+       while (entries != current)
+ 	{
+ 	  if (entries->name /*&& entries->enabled*/) prev = entries;
+ 	  entries = entries->next;
+ 	  assert (entries);
+ 	}
+     }
+ 
+   if (!prev)
+     /* move to last item */
+     {
+       while (entries->next)
+ 	{
+ 	  if (entries->name /*&& entries->enabled*/) prev = entries;
+ 	  entries = entries->next;
+ 	}
+       if (prev)
+ 	{
+ 	  if (entries->name /*&& entries->enabled*/)
+ 	    prev = entries;
+ 	}
+       else
+ 	{
+ 	  /* no selectable items in this menu, pop up to previous level */
+ 	  lw_pop_menu ();
+ 	  return;
+ 	}
+     }
+   lw_set_item (prev);
+ }
+ 
+ static void
+ menu_move_down (void)
+ {
+   widget_value *current;
+   widget_value *new;
+   
+   current = lw_get_entries (False);
+   new = current;
+   
+   while (new->next)
+     {
+       new = new->next;
+       if (new->name /*&& new->enabled*/) break;
+     }
+   
+   if (new==current||!(new->name/*||new->enabled*/))
+     {
+       new = lw_get_entries (True);
+       while (new!=current)
+ 	{
+ 	  if (new->name /*&& new->enabled*/) break;
+ 	  new = new->next;
+ 	}
+       if (new==current&&!(new->name /*|| new->enabled*/))
+ 	{
+ 	  lw_pop_menu ();
+ 	  return;
+ 	}
+     }
+   
+   lw_set_item (new);
+ }
+ 
+ static void
+ menu_move_left (void)
+ {
+   int level = lw_menu_level ();
+   int l = level;
+   widget_value *current;
+   
+   while (level >= 3)
+     {
+       --level;
+       lw_pop_menu ();
+     }
+   menu_move_up ();
+   current = lw_get_entries (False);
+   if (l > 2 && current->contents)
+     lw_push_menu (current->contents);
+ }
+ 
+ static void
+ menu_move_right (void)
+ {
+   int level = lw_menu_level ();
+   int l = level;
+   widget_value *current;
+   
+   while (level >= 3)
+     {
+       --level;
+       lw_pop_menu ();
+     }
+   menu_move_down ();
+   current = lw_get_entries (False);
+   if (l > 2 && current->contents)
+     lw_push_menu (current->contents);
+ }
+ 
+ static void
+ menu_select_item (widget_value *val)
+ {
+   if (val == NULL)
+     val = lw_get_entries (False);
+   
+   /* is match a submenu? */
+   
+   if (val->contents)
+     {
+       /* enter the submenu */
+       
+       lw_set_item (val);
+       lw_push_menu (val->contents);
+     }
+   else
+     {
+       /* Execute the menu entry by calling the menu's `select'
+ 	 callback function
+ 	 */
+       lw_kill_menus (val);
+     }
+ }
+ 
+ static Lisp_Object
+ command_builder_operate_menu_accelerator (struct command_builder *builder)
+ {
+   /* this function can GC */
+   
+   struct console *con = XCONSOLE (Vselected_console);
+   Lisp_Object evee = builder->most_current_event;
+   Lisp_Object binding;
+   widget_value *entries;
+   struct gcpro gcpro1;
+   
+   extern int lw_menu_accelerate; /* lwlib.c */
+ 
+ #if 0
+   {
+     int i;
+     Lisp_Object t;
+     char buf[50];
+     
+     t = builder->current_events;
+     i = 0;
+     while (!NILP (t))
+       {
+ 	i++;
+ 	sprintf(buf,"OPERATE (%d): ",i);
+ 	write_c_string (buf,Qexternal_debugging_output);
+ 	print_internal (t, Qexternal_debugging_output, 1);
+ 	write_c_string ("\n", Qexternal_debugging_output);
+ 	t = XEVENT_NEXT (t);
+       }
+   }
+ #endif
+   
+   /* menu accelerator keys don't go into keyboard macros */
+   if (!NILP (con->defining_kbd_macro) && NILP (Vexecuting_macro))
+     con->kbd_macro_ptr = con->kbd_macro_end;
+   
+   /* don't echo menu accelerator keys */
+   /*reset_key_echo (builder, True);*/
+   
+   if (!lw_menu_accelerate)
+     {
+       /* `convert' mouse display to keyboard display
+ 	 by entering the open submenu
+ 	 */
+       entries = lw_get_entries (False);
+       if (entries->contents)
+ 	{
+ 	  lw_push_menu (entries->contents);
+ 	  lw_display_menu (CurrentTime);
+ 	}
+     }
+   
+   /* compare event to the current menu accelerators */
+   
+   entries=lw_get_entries (True);
+   
+   while (entries)
+     {
+       Lisp_Object accel = (Lisp_Object) entries->accel;
+       if (entries->name && !NILP (accel))
+ 	{
+ 	  if (event_matches_key_specifier_p (XEVENT (evee), accel))
+ 	    {
+ 	      /* a match! */
+ 	      
+ 	      menu_select_item (entries);
+ 	      
+ 	      if (lw_menu_active) lw_display_menu (CurrentTime);
+ 	      
+ 	      reset_this_command_keys (Vselected_console, 1);
+ 	      /*reset_command_builder_event_chain (builder);*/
+ 	      return Vmenu_accelerator_map;
+ 	    }
+ 	}
+       entries = entries->next;
+     }
+   
+   /* try to look up event in menu-accelerator-map */
+   
+   binding = event_binding_in (evee, Vmenu_accelerator_map, 1);
+   
+   if (NILP (binding))
+     {
+       /* beep at user for undefined key */
+       return Qnil;
+     }
+   else
+     {
+       if (EQ (binding, Qmenu_quit))
+ 	{
+ 	  /* turn off menus and set quit flag */
+ 	  lw_kill_menus (NULL);
+ 	  Vquit_flag = Qt;
+ 	}
+       else if (EQ (binding, Qmenu_up))
+ 	{
+ 	  int level = lw_menu_level ();
+ 	  if (level > 2)
+ 	    menu_move_up ();
+ 	}
+       else if (EQ (binding, Qmenu_down))
+ 	{
+ 	  int level = lw_menu_level ();
+ 	  if (level > 2)
+ 	    menu_move_down ();
+ 	  else
+ 	    menu_select_item (NULL);
+ 	}
+       else if (EQ (binding, Qmenu_left))
+ 	{
+ 	  int level = lw_menu_level ();
+ 	  if (level > 3)
+ 	    {
+ 	      lw_pop_menu ();
+ 	      lw_display_menu (CurrentTime);
+ 	    }
+ 	  else
+ 	    menu_move_left ();
+ 	}
+       else if (EQ (binding, Qmenu_right))
+ 	{
+ 	  int level = lw_menu_level ();
+ 	  if (level > 2 &&
+ 	      lw_get_entries (False)->contents)
+ 	    {
+ 	      widget_value *current = lw_get_entries (False);
+ 	      if (current->contents)
+ 		menu_select_item (NULL);
+ 	    }
+ 	  else
+ 	    menu_move_right ();
+ 	}
+       else if (EQ (binding, Qmenu_select))
+ 	menu_select_item (NULL);
+       else if (EQ (binding, Qmenu_escape))
+ 	{
+ 	  int level = lw_menu_level ();
+ 	  
+ 	  if (level > 2)
+ 	    {
+ 	      lw_pop_menu ();
+ 	      lw_display_menu (CurrentTime);
+ 	    }
+ 	  else
+ 	    {
+ 	      /* turn off menus quietly */
+ 	      lw_kill_menus (NULL);
+ 	    }
+ 	}
+       else if (KEYMAPP (binding))
+ 	{
+ 	  /* prefix key */
+ 	  reset_this_command_keys (Vselected_console, 1);
+ 	  /*reset_command_builder_event_chain (builder);*/
+ 	  return binding;
+ 	}
+       else
+ 	{
+ 	  /* turn off menus and execute binding */
+ 	  lw_kill_menus (NULL);
+ 	  reset_this_command_keys (Vselected_console, 1);
+ 	  /*reset_command_builder_event_chain (builder);*/
+ 	  return binding;
+ 	}
+     }
+   
+   if (lw_menu_active) lw_display_menu (CurrentTime);
+   
+   reset_this_command_keys (Vselected_console, 1);
+   /*reset_command_builder_event_chain (builder);*/
+   
+   return Vmenu_accelerator_map;
+ }
+ 
+ static Lisp_Object
+ command_builder_find_menu_accelerator (struct command_builder *builder)
+ {
+   /* this function can GC */
+   Lisp_Object event0 = builder->current_events;
+   struct console *con = XCONSOLE (Vselected_console);
+   struct frame *f = XFRAME (CONSOLE_SELECTED_FRAME (con));
+   Widget menubar_widget;
+   
+   /* compare entries in event0 against the menu prefix */
+   
+   if (NILP (Vdefault_x_device) || NILP (event0) ||
+       XEVENT (event0)->event_type != key_press_event)
+     return Qnil;
+   
+   if (!NILP (Vmenu_accelerator_prefix))
+     {
+       if (CONSP (Vmenu_accelerator_prefix))
+ 	{
+ 	  Lisp_Object t;
+ 	  t=Vmenu_accelerator_prefix;
+ 	  while (!NILP (t)
+ 		 && !NILP (event0)
+ 		 && event_matches_key_specifier_p (XEVENT (event0), Fcar (t)))
+ 	    {
+ 	      t = Fcdr (t);
+ 	      event0 = XEVENT_NEXT (event0);
+ 	    }
+ 	  if (!NILP (t))
+ 	    return Qnil;
+ 	}
+       else if (NILP (event0))
+ 	return Qnil;
+       else if (event_matches_key_specifier_p (XEVENT (event0), Vmenu_accelerator_prefix))
+ 	event0 = XEVENT_NEXT (event0);
+       else
+ 	return Qnil;
+     }
+   
+   if (NILP (event0))
+     return Qnil;
+   
+   menubar_widget = FRAME_X_MENUBAR_WIDGET (f);
+   if (menubar_widget
+       && CONSP (Vmenu_accelerator_modifiers))
+     {
+       Lisp_Object fake;
+       Lisp_Object last;
+       int i;
+       struct gcpro gcpro1;
+       
+       widget_value *val;
+       LWLIB_ID id = XPOPUP_DATA (f->menubar_data)->id;
+       
+       val = lw_get_all_values (id);
+       if (val)
+ 	{
+ 	  val = val->contents;
+ 	  
+ 	  fake = Fcopy_sequence (Vmenu_accelerator_modifiers);
+ 	  last = fake;
+ 	  
+ 	  while (!NILP (Fcdr (last)))
+ 	    last = Fcdr (last);
+ 	  
+ 	  Fsetcdr (last, Fcons (Qnil, Qnil));
+ 	  last = Fcdr (last);
+ 	}
+       
+       GCPRO1 (fake);
+       
+       while (val)
+ 	{
+ 	  Lisp_Object accel = (Lisp_Object) val->accel;
+ 	  if (val->name && !NILP (accel))
+ 	    {
+ 	      Fsetcar (last, accel);
+ 	      
+ 	      if (event_matches_key_specifier_p (XEVENT (event0), fake))
+ 		{
+ 		  /* we found one! */
+ 		  
+ 		  lw_set_menu (menubar_widget, val);
+ 		  /* yah - yet another hack.
+ 		     pretend emacs timestamp is the same as an X timestamp,
+ 		     which for the moment it is.  (read events.h)
+ 		     */
+ 		  lw_map_menu (XEVENT (event0)->timestamp);
+ 		  
+ 		  if (val->contents)
+ 		    lw_push_menu (val->contents);
+ 		  
+ 		  lw_display_menu (CurrentTime);
+ 		  
+ 		  /* menu accelerator keys don't go into keyboard macros */
+ 		  if (!NILP (con->defining_kbd_macro) && NILP (Vexecuting_macro))
+ 		    con->kbd_macro_ptr = con->kbd_macro_end;
+ 		  
+ 		  /* don't echo menu accelerator keys */
+ 		  /*reset_key_echo (builder, True);*/
+ 		  reset_this_command_keys (Vselected_console, 1);
+ 		  UNGCPRO;
+ 		  
+ 		  return Vmenu_accelerator_map;
+ 		}
+ 	    }
+ 	  
+ 	  val = val->next;
+ 	}
+       
+       UNGCPRO;
+     }
+   return Qnil;
+ }
+ 
+ void
+ event_menu_accelerate ()
+ {
+   struct console *con = XCONSOLE (Vselected_console);
+   struct frame *f = XFRAME (CONSOLE_SELECTED_FRAME (con));
+   LWLIB_ID id = XPOPUP_DATA (f->menubar_data)->id;
+   widget_value *val = lw_get_all_values (id);
+   
+   val = val->contents;
+   lw_set_menu (FRAME_X_MENUBAR_WIDGET (f), val);
+   lw_map_menu (CurrentTime);
+   
+   lw_display_menu (CurrentTime);
+   
+   /* menu accelerator keys don't go into keyboard macros */
+   if (!NILP (con->defining_kbd_macro) && NILP (Vexecuting_macro))
+     con->kbd_macro_ptr = con->kbd_macro_end;
+ }
+ 
  /* See if we can do function-key-map or key-translation-map translation
     on the current events in the command builder.  If so, do this, and
     return the resulting binding, if any. */
***************
*** 2993,3004 ****
        Lisp_Object arg = XEVENT (evee)->event.eval.object;
        return (list2 (fn, arg));
      }
  
!   else if (XEVENT_TYPE (evee) == misc_user_event)
!     return Qnil;
! 
!   result = command_builder_find_leaf_1 (builder);
  
    /* Check to see if we have a potential function-key-map match. */
    if (NILP (result))
      {
--- 3474,3502 ----
        Lisp_Object arg = XEVENT (evee)->event.eval.object;
        return (list2 (fn, arg));
      }
+   
+   /* if we're currently in a menu accelerator, check there for further events */
+   if (lw_menu_active)
+     {
+       result = command_builder_operate_menu_accelerator (builder);
+       return result;
+     }
+   else
+     {
  
!       if (XEVENT_TYPE (evee) == misc_user_event)
! 	return Qnil;
  
+       result=Qnil;
+       if (EQ (Vmenu_accelerator_enabled, Qmenu_force))
+ 	result = command_builder_find_menu_accelerator (builder);
+       if (NILP (result))
+ 	result = command_builder_find_leaf_1 (builder);
+       if (NILP (result)
+ 	  && EQ (Vmenu_accelerator_enabled, Qmenu_fallback))
+ 	result = command_builder_find_menu_accelerator (builder);
+     }
+   
    /* Check to see if we have a potential function-key-map match. */
    if (NILP (result))
      {
***************
*** 3807,3812 ****
--- 4305,4313 ----
  	  /* Huh? */
  	  Vthis_command = Qnil;
  
+ 	/* clear the echo area */
+ 	reset_key_echo (command_builder, True);
+ 	
  	command_builder->self_insert_countdown = 0;
  	if (NILP (XCONSOLE (console)->prefix_arg)
  	    && NILP (Vexecuting_macro)
***************
*** 4072,4077 ****
--- 4573,4589 ----
  	     "retry-undefined-key-binding-unshifted");
    defsymbol (&Qauto_show_make_point_visible,
  	     "auto-show-make-point-visible");
+ 
+   defsymbol (&Qmenu_force, "menu-force");
+   defsymbol (&Qmenu_fallback, "menu-fallback");
+   
+   defsymbol (&Qmenu_quit, "menu-quit");
+   defsymbol (&Qmenu_up, "menu-up");
+   defsymbol (&Qmenu_down, "menu-down");
+   defsymbol (&Qmenu_left, "menu-left");
+   defsymbol (&Qmenu_right, "menu-right");
+   defsymbol (&Qmenu_select, "menu-select");
+   defsymbol (&Qmenu_escape, "menu-escape");
  }
  
  void
***************
*** 4371,4382 ****
--- 4883,4937 ----
  */ );
    debug_emacs_events = 0;
  #endif
+ 
+   DEFVAR_LISP("menu-accelerator-prefix", &Vmenu_accelerator_prefix /*
+ Prefix key(s) that must be typed before menu accelerators will be activated.
+ Set this to a value acceptable by define-key.
+ */ );
+   Vmenu_accelerator_prefix = Qnil;
+ 
+   DEFVAR_LISP ("menu-accelerator-modifiers", &Vmenu_accelerator_modifiers /*
+ Modifier keys which must be pressed to get to the top level menu accelerators.
+ If this variable is set to anything other than a vector, the top level menus
+ will not be directly accessible by keyboard accelerator.
+ */ );
+   Vmenu_accelerator_modifiers = list1 (Qmeta);
+   
+   DEFVAR_LISP ("menu-accelerator-enabled", &Vmenu_accelerator_enabled /*
+ Either 'menu-force or 'menu-fallback will enable menu accelerators.
+ If menu-force, menu accelerators override the current keymap.  If menu-fallback,
+ the current keymap overrides menu accelerators.
+ */ );
+   Vmenu_accelerator_enabled = Qmenu_force;
  }
  
  void
  complex_vars_of_event_stream (void)
  {
    Vkeyboard_translate_table = Fmake_hashtable (make_int (100), Qnil);
+ 
+   DEFVAR_LISP ("menu-accelerator-map", &Vmenu_accelerator_map /*
+ Keymap for use when the menu has been invoked using keyboard accelerators.
+ The actions menu-quit, menu-up, menu-down, menu-left, menu-right,
+ menu-select and menu-escape can be mapped to keys in this map.
+ 
+ menu-quit    exit the menus without selecting any item.
+ menu-up      move up one row in the current menu.
+ menu-down    move down one row in the current menu.  If executed while the
+              cursor is in the top level menu, move down into the selected menu.
+ menu-left    traverse menus to the left.  Moves to the previous top level
+              submenu on the left or wrap around to the farthest one on the
+              right.
+ menu-right   traverse menus to the right.  Moves to the next top level submenu
+              on the right or wrap around to the farthest one on the left.
+ menu-select  select the currently highlighted item.
+ menu-escape  pop up to the next level of menus.  Moves from a submenu into its
+              parent menu.
+ 
+ if this map contains any command bindings, the menu is exited and the
+ specified command is executed.
+ */ );
+   Vmenu_accelerator_map = Fmake_keymap(Qnil);
  }
  
  void
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/events.h xemacs-19.14-accel/src/events.h
*** xemacs-19.14/src/events.h	Wed May 15 21:20:36 1996
--- xemacs-19.14-accel/src/events.h	Sun Jul  7 17:20:32 1996
***************
*** 531,536 ****
--- 531,538 ----
  					struct console *c, int fd);
  #endif /* HAVE_UNIXOID_EVENT_LOOP */
  
+ void event_menu_accelerate (void);
+ 
  extern int emacs_is_blocking;
  
  extern Lisp_Object Vcontrolling_terminal;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/gui-x.c xemacs-19.14-accel/src/gui-x.c
*** xemacs-19.14/src/gui-x.c	Mon May  6 18:22:52 1996
--- xemacs-19.14-accel/src/gui-x.c	Sun Jul  7 17:20:32 1996
***************
*** 348,353 ****
--- 348,370 ----
    return NULL;
  }
  
+ /* set menu accelerator key to first underlined character in menu name */
+ 
+ accel_type
+ menu_name_to_accelerator (char *name)
+ {
+   while (*name) {
+     if (*name=='%') {
+       ++name;
+       if (!(*name)) return (accel_type) Qnil;
+       if (*name=='_'&&*(name+1))
+ 	return (accel_type) make_char (tolower(*(name+1)));
+     }
+     ++name;
+   }
+   return (accel_type) Qnil;
+ }
+ 
  /* This does the dirty work.  gc_currently_forbidden is 1 when this is called.
   */
  
***************
*** 367,377 ****
    Lisp_Object keys = Qnil;
    Lisp_Object style = Qnil;
    Lisp_Object config_tag = Qnil;
    int length = vector_length (XVECTOR (desc));
    Lisp_Object *contents = vector_data (XVECTOR (desc));
    int plist_p;
    int selected_spec = 0, included_spec = 0;
! 
    if (length < 3)
      signal_simple_error ("button descriptors must be at least 3 long", desc);
  
--- 384,395 ----
    Lisp_Object keys = Qnil;
    Lisp_Object style = Qnil;
    Lisp_Object config_tag = Qnil;
+   accel_type accel = (accel_type) Qnil;
    int length = vector_length (XVECTOR (desc));
    Lisp_Object *contents = vector_data (XVECTOR (desc));
    int plist_p;
    int selected_spec = 0, included_spec = 0;
!   
    if (length < 3)
      signal_simple_error ("button descriptors must be at least 3 long", desc);
  
***************
*** 416,421 ****
--- 434,448 ----
  	  else if (EQ (key, Q_selected)) selected_p = val, selected_spec = 1;
  	  else if (EQ (key, Q_included)) include_p = val, included_spec = 1;
  	  else if (EQ (key, Q_config))	 config_tag = val;
+ 	  else if (EQ (key, Q_accelerator))
+ 	    {
+ 	      if ( SYMBOLP (val)
+ 		   || CHARP (val))
+ 		/* evil cast -- see also menubar-x.c */
+ 		accel = (accel_type) val;
+ 	      else
+ 		signal_simple_error ("bad keyboard accelerator", val);
+ 	    }
  	  else if (EQ (key, Q_filter))
  	    signal_simple_error(":filter keyword not permitted on leaf nodes", desc);
  	  else 
***************
*** 435,440 ****
--- 462,470 ----
    CHECK_STRING (name);
    wv->name = (char *) string_data (XSTRING (name));
  
+   if (accel == (accel_type) Qnil) accel = menu_name_to_accelerator (wv->name);
+   wv->accel = accel;
+   
    if (!NILP (suffix))
      {
        CONST char *const_bogosity;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/gui-x.h xemacs-19.14-accel/src/gui-x.h
*** xemacs-19.14/src/gui-x.h	Sun Mar 31 19:20:52 1996
--- xemacs-19.14-accel/src/gui-x.h	Sun Jul  7 17:20:32 1996
***************
*** 75,80 ****
--- 75,81 ----
  			       XtPointer client_data);
  int button_item_to_widget_value (Lisp_Object desc, widget_value *wv,
  				 int allow_text_field_p, int no_keys_p);
+ accel_type menu_name_to_accelerator (char *name);
  Boolean separator_string_p (CONST char *s);
  char *menu_separator_style (CONST char *s);
  Lisp_Object widget_value_unwind (Lisp_Object closure);
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/gui.c xemacs-19.14-accel/src/gui.c
*** xemacs-19.14/src/gui.c	Sun Apr 28 17:10:58 1996
--- xemacs-19.14-accel/src/gui.c	Sun Jul  7 17:20:32 1996
***************
*** 27,46 ****
  
  Lisp_Object Q_active, Q_suffix, Q_keys, Q_style, Q_selected;
  Lisp_Object Q_filter, Q_config, Q_included;
  Lisp_Object Qtoggle, Qradio;
  
  void
  syms_of_gui (void)
  {
!   defkeyword (&Q_active,   ":active");
!   defkeyword (&Q_suffix,   ":suffix");
!   defkeyword (&Q_keys,     ":keys");
!   defkeyword (&Q_style,    ":style");
!   defkeyword (&Q_selected, ":selected");
!   defkeyword (&Q_filter,   ":filter");
!   defkeyword (&Q_config,   ":config");
!   defkeyword (&Q_included, ":included");
! 
    defsymbol (&Qtoggle, "toggle");
    defsymbol (&Qradio, "radio");
  }
--- 27,48 ----
  
  Lisp_Object Q_active, Q_suffix, Q_keys, Q_style, Q_selected;
  Lisp_Object Q_filter, Q_config, Q_included;
+ Lisp_Object Q_accelerator;
  Lisp_Object Qtoggle, Qradio;
  
  void
  syms_of_gui (void)
  {
!   defkeyword (&Q_active,      ":active");
!   defkeyword (&Q_suffix,      ":suffix");
!   defkeyword (&Q_keys,        ":keys");
!   defkeyword (&Q_style,       ":style");
!   defkeyword (&Q_selected,    ":selected");
!   defkeyword (&Q_filter,      ":filter");
!   defkeyword (&Q_config,      ":config");
!   defkeyword (&Q_included,    ":included");
!   defkeyword (&Q_accelerator, ":accelerator");
!   
    defsymbol (&Qtoggle, "toggle");
    defsymbol (&Qradio, "radio");
  }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/keymap.c xemacs-19.14-accel/src/keymap.c
*** xemacs-19.14/src/keymap.c	Sun Jun  9 11:48:50 1996
--- xemacs-19.14-accel/src/keymap.c	Sun Jul  7 17:20:32 1996
***************
*** 2619,2624 ****
--- 2619,2640 ----
  	  (lookup_events (event0, nmaps, maps, accept_default)));
  }
  
+ /* like event_binding, but specify a keymap to search */
+ 
+ Lisp_Object
+ event_binding_in (Lisp_Object event0, Lisp_Object keymap, int accept_default)
+ {
+   /* This function can GC */
+   Lisp_Object maps[1];
+   
+   if (!KEYMAPP (keymap))
+     return Qnil;
+   
+   maps[0] = keymap;
+   return process_event_binding_result (lookup_events (event0, 1, maps,
+ 						      accept_default));
+ }
+ 
  /* Attempts to find a function key mapping corresponding to the
     event-sequence whose head is event0 (sequence is threaded through
     event_next).  The return value will be the same as for event_binding(). */
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/keymap.h xemacs-19.14-accel/src/keymap.h
*** xemacs-19.14/src/keymap.h	Sun Mar 31 19:17:36 1996
--- xemacs-19.14-accel/src/keymap.h	Sun Jul  7 17:20:32 1996
***************
*** 34,39 ****
--- 34,41 ----
  
  extern Lisp_Object get_keymap (Lisp_Object object, int errorp, int autoload);
  extern Lisp_Object event_binding (Lisp_Object event0, int accept_default);
+ extern Lisp_Object event_binding_in (Lisp_Object event0, Lisp_Object keymap,
+ 				     int accept_default);
  extern Lisp_Object munging_key_map_event_binding (Lisp_Object event0,
  						  enum munge_me_out_the_door
  						  munge);
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/menubar-x.c xemacs-19.14-accel/src/menubar-x.c
*** xemacs-19.14/src/menubar-x.c	Sun Jun 16 15:36:47 1996
--- xemacs-19.14-accel/src/menubar-x.c	Sun Jul  7 17:20:33 1996
***************
*** 152,157 ****
--- 152,160 ----
  	  wv->enabled = 1;
  	  wv->name =
  	    (char *) string_data (XSTRING (LISP_GETTEXT (XCAR (desc))));
+ 	  
+ 	  wv->accel = menu_name_to_accelerator (wv->name);
+ 	  
  	  desc = Fcdr (desc);
  
  	  while (key = Fcar (desc), KEYWORDP (key))
***************
*** 169,174 ****
--- 172,187 ----
  		config_tag = val;
  	      else if (EQ (key, Q_filter))
  		hook_fn = val;
+ 	      else if (EQ (key, Q_accelerator))
+ 		{
+ 		  if ( SYMBOLP (val)
+ 		       || CHARP (val))
+ 		    /* Let's hope that Lisp_Object fits in a long and that
+ 		       the symbol doesn't get removed from obarray. */
+ 		    wv->accel = (accel_type) val;
+ 		  else
+ 		    signal_simple_error ("bad keyboard accelerator", val);
+ 		}
  	      else 
  		signal_simple_error ("unknown menu cascade keyword", cascade);
  	    }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.14/src/menubar.c xemacs-19.14-accel/src/menubar.c
*** xemacs-19.14/src/menubar.c	Sun Jun 16 15:36:42 1996
--- xemacs-19.14-accel/src/menubar.c	Sun Jul  7 17:20:33 1996
***************
*** 45,50 ****
--- 45,51 ----
  static Lisp_Object Vcurrent_menubar; /* DO NOT ever reference this.
  					Always go through Qcurrent_menubar.
  					See below. */
+ 
  Lisp_Object Vblank_menubar;
  
  int popup_menu_titles;
***************
*** 91,96 ****
--- 92,107 ----
    update_frame_menubars (f);
  }
  
+ DEFUN ("accelerate-menu", Faccelerate_menu, Saccelerate_menu,
+        0, 0, "_" /*
+ Make the menubar active.  Menu items can be selected using menu accelerators
+ or by actions defined in menu-accelerator-map.
+ */ )
+   ()
+ {
+   event_menu_accelerate ();
+ }
+ 
  DEFUN ("popup-menu", Fpopup_menu, Spopup_menu, 1, 2, 0 /*
  Pop up the given menu.
  A menu description is a list of menu items, strings, and submenus.
***************
*** 183,188 ****
--- 194,200 ----
  {
    defsymbol (&Qcurrent_menubar, "current-menubar");
    defsubr (&Spopup_menu);
+   defsubr (&Saccelerate_menu);
  }
  
  void

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 13 04:05:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id EAA20327 for xemacs-beta-people; Fri, 13 Sep 1996 04:05:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id EAA20324 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 13 Sep 1996 04:05:12 -0500 (CDT)
Received: from ethanol.gnu.ai.mit.edu (rms@ethanol.gnu.ai.mit.edu [128.52.46.64]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id EAA07456 for <xemacs-beta@xemacs.org>; Fri, 13 Sep 1996 04:05:07 -0500 (CDT)
Received: by ethanol.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id FAA29370; Fri, 13 Sep 1996 05:05:07 -0400
Date: Fri, 13 Sep 1996 05:05:07 -0400
Message-Id: <199609130905.FAA29370@ethanol.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
to: wing@666.com
To: xemacs-beta@xemacs.org
cc: rms@gnu.ai.mit.edu
Subject: Inflammatory doesn't just mean someone takes offense

     > I also believe that your continuing to argue with other members of the
     > free software community, and the many inflammatory statements you've
     > made about various non-GNU free software packages, serve no constructive
     > purpose other than to divide the free software community and turn
     > otherwise sympathetic people away from the community.

Sometimes I say things that other people disagree with.  When I do,
some of the people who disagree may become hostile.  Sometimes they
attack me personally even though I have not attacked anyone.  For
example, when I pointed out the problems caused by identifying whole
Linux-based GNU systems with Linux proper, some people were wildly
angry, even though I had not criticized them.  I think it's a mistake
when people identify those two, but I don't condemn people for being
misinformed about it.  They condemned me, not I them.

These people are responsible for their own actions.  We mustn't blame
the dissenter for the behavior of those who resent his dissenting views.

But it's true that controversy can be bad for working together.  So I
have not said controversial things in public about very many free
software packages.

As I recall, there are just two free software topics on which I've
made controversial public statements this year or last year: XEmacs,
and the naming of Linux-based GNU systems.  (Neither one is exactly a
non-GNU free software package.)

My aim in writing my recent messages about XEmacs was not to make
anyone angry.  It was to ask for help in reaching the goals I've
stated, and to explain the reasons for decisions which others had
criticized.

It looks like you felt offended even though that wasn't my aim.  I can
understand that.  I was criticizing an activity you participate in,
and I can see why you could feel offended.  There is no way I could
talk about the problem without a risk of offending, but I did what I
could to try to make it less likely.  I focused on practical problems
and solutions, not on criticizing any person.




From xemacs-beta-request@cs.uiuc.edu  Fri Sep 13 13:06:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA21716 for xemacs-beta-people; Fri, 13 Sep 1996 13:06:09 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA21713 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 13 Sep 1996 13:06:03 -0500 (CDT)
Received: from mhost.mri.com (mri-gw.mri.com [149.147.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA27006 for <xemacs-beta@cs.uiuc.edu>; Fri, 13 Sep 1996 13:06:02 -0500 (CDT)
Received: from mri.com (mailhost.mri.com [192.9.201.130]) by mhost.mri.com (8.7.5/8.7.3) with ESMTP id LAA06682 for <xemacs-beta@cs.uiuc.edu>; Fri, 13 Sep 1996 11:05:53 -0700 (PDT)
Received: from allez.mri.com by mri.com (8.6.12/SMI-4.1-1.16)
        id LAA03450; Fri, 13 Sep 1996 11:05:51 -0700
Message-Id: <199609131805.LAA03450@mri.com>
To: xemacs-beta@cs.uiuc.edu
Subject: 19.15-b1 on Solaris 2.4
Reply-To: Vladimir.Ivanovic@mri.com
Date: Fri, 13 Sep 1996 11:05:48 -0700
From: "Vladimir G. Ivanovic" <Vladimir.Ivanovic@mri.com>

Compiling without optimization and adding site-runtime-libraries
finally allowed me to use XEmacs 19.15.  I don't know which of these two
changes (or whether both together) are responsible for getting XEmacs to
work.

However, it is sloooooow on startup.  Very, very, very slow.  It pegs my
CPU (already a pathetic LX).

-- Vladimir

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 13 18:45:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA22713 for xemacs-beta-people; Fri, 13 Sep 1996 18:45:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA22710 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 13 Sep 1996 18:45:13 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA08563 for <xemacs-beta@xemacs.org>; Fri, 13 Sep 1996 18:45:09 -0500 (CDT)
Received: from mordor.rsn.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA299608309; Fri, 13 Sep 1996 16:45:09 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id SAA20515; Fri, 13 Sep 1996 18:49:57 -0500 (CDT)
Date: Fri, 13 Sep 1996 18:49:57 -0500 (CDT)
Message-Id: <199609132349.SAA20515@mordor.rsn.hp.com>
From: Shane Holder <holder@mordor.rsn.hp.com>
To: xemacs-beta@xemacs.org
Subject: (frame-list) seems to be wrong.


Forgive me if this has already been discussed.

It seems wrong to place newly created frames (or anything else) on the
"END" of a list.  Is there a reason for this?

Emacs puts new frames on the beginning of the list, and I just spent
several hours chasing down why some code I have didn't work.

Shane

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 13 20:43:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA22966 for xemacs-beta-people; Fri, 13 Sep 1996 20:43:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA22963 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 13 Sep 1996 20:43:41 -0500 (CDT)
Received: from mhost.mri.com (mri-gw.mri.com [149.147.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA21091 for <xemacs-beta@cs.uiuc.edu>; Fri, 13 Sep 1996 20:43:40 -0500 (CDT)
Received: from mri.com (mailhost.mri.com [192.9.201.130]) by mhost.mri.com (8.7.5/8.7.3) with ESMTP id SAA26090 for <xemacs-beta@cs.uiuc.edu>; Fri, 13 Sep 1996 18:43:39 -0700 (PDT)
Received: from allez.mri.com by mri.com (8.6.12/SMI-4.1-1.16)
        id SAA11979; Fri, 13 Sep 1996 18:43:38 -0700
Message-Id: <199609140143.SAA11979@mri.com>
To: xemacs-beta@cs.uiuc.edu
Subject: Error in `pre-idle-hook' (19.15-b1 on Solaris & Linux)
Reply-To: Vladimir.Ivanovic@mri.com
Date: Fri, 13 Sep 1996 18:43:37 -0700
From: "Vladimir G. Ivanovic" <Vladimir.Ivanovic@mri.com>

I keep on getting every now and then a *Warnings* buffer which pops up
with

    (1) (error/warning) Error in `pre-idle-hook' (setting hook to nil):
        (error Stack overflow in regexp matcher)

while I have a compilation going.  Nothing in the buffer should be
causing regexp grief....

-- Vladimir

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 13 21:16:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA23004 for xemacs-beta-people; Fri, 13 Sep 1996 21:16:56 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA23001 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 13 Sep 1996 21:16:55 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA21342 for <xemacs-beta@cs.uiuc.edu>; Fri, 13 Sep 1996 21:16:52 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA31357; Fri, 13 Sep 1996 19:20:35 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: 19.15-b1 Crash Linux 2.0.18/ELF
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 13 Sep 1996 19:20:34 -0700
Message-ID: <m2iv9hsuq5.fsf@deanna.miranova.com>
Lines: 69
X-Mailer: Red Gnus v0.34/XEmacs 19.15

The crash came while incorporating new mail in Gnus -- an operation
which had succeeded at least a dozen times earlier in the session,
this XEmacs had been up all day sitting in Gnus.  Hmmm.  And on a
message from `fatalerror@juno.com' ...

(Red Gnus v0.34/tm 7.84)

Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Lisp backtrace follows:

  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  insert-file-contents-internal("/home/steve/Mail/firewalls/.overview" t nil nil nil)
  # bind (replace end beg visit filename)
  ange-ftp-real-insert-file-contents("/home/steve/Mail/firewalls/.overview" t nil nil nil)
  # bind (parsed replace end beg visit filename)
  insert-file-contents("/home/steve/Mail/firewalls/.overview" t)
  # (condition-case ... . ((file-error (byte-code "!\n" ... 2))))
  # (unwind-protect ...)
  # bind (error number buf rawfile nowarn filename)
  find-file-noselect("/home/steve/Mail/firewalls/.overview")
  # bind (group)
  nnml-open-nov("firewalls")
  # (unwind-protect ...)
  # bind (headers article group)
  nnml-add-nov("firewalls" 1686 [nil "Re: Removal from mail lists" "fatalerror@juno.com (Fatal Error)" "Fri, 13 Sep 1996 19:07:44 EDT" "<19960913.182348.11398.2.fatalerror@juno.com>" "<199609102335.IAA05868@star.elim.net>" 372 16 "deanna.miranova.com firewalls:1686"])
  # bind (ga chars headers group-art)
  nnml-save-mail((("firewalls" . 1686)))
  # bind (group-art action duplication artnum-func func message-id)
  nnmail-check-duplication("<19960913.182348.11398.2.fatalerror@juno.com>" nnml-save-mail nnml-active-number)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (case-fold-search delim start message-id content-length end skip head-end artnum-func func)
  nnmail-process-unix-mail-format(nnml-save-mail nnml-active-number)
  # (unwind-protect ...)
  # bind (nnmail-split-methods artnum-func group exit-func func incoming)
  nnmail-split-incoming("~/.gnus-crash-box" nnml-save-mail nil "firewalls" nnml-active-number)
  # bind (spool incomings incoming group-in spools spool-func group temp exit-func method)
  nnmail-get-new-mail(nnml nnml-save-nov "~/Mail/" "firewalls")
  # bind (server group)
  nnml-request-scan("firewalls" "")
  # bind (method method group)
  gnus-request-scan("nnml:firewalls" (nnml ""))
  # bind (method active method dont-check scan group)
  gnus-activate-group("nnml:firewalls" scan)
  # bind (method active group info foreign-level level newsrc level)
  gnus-get-unread-articles(nil)
  # bind (arg)
  gnus-group-get-new-news(nil)
  # bind (command-debug-status)
  call-interactively(gnus-group-get-new-news)
  # (condition-case ... . error)
  # (catch top-level ...)

The C Backtrace is unhelpful:
(gdb) where
#0  0x40204741 in __kill ()
#1  0x8081289 in fatal_error_signal (sig=11) at emacs.c:191
#2  0xbfff23b0 in __ypbindlist ()

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Sat Sep 14 21:33:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA28684 for xemacs-beta-people; Sat, 14 Sep 1996 21:33:07 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA28681 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 14 Sep 1996 21:33:06 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA14918 for <xemacs-beta@xemacs.org>; Sat, 14 Sep 1996 21:33:02 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA10602; Sat, 14 Sep 1996 19:36:45 -0700
Date: Sat, 14 Sep 1996 19:36:45 -0700
Message-Id: <199609150236.TAA10602@deanna.miranova.com>
From: Steven L Baur <steve@miranova.com>
To: xemacs-beta@xemacs.org
Subject: Lisp Mode font locking bug report Emacs 19.34, XEmacs 19.14 & 19.15
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: multipart/mixed;
 boundary="Multipart_Sat_Sep_14_19:36:42_1996-1"
Content-Transfer-Encoding: 7bit

--Multipart_Sat_Sep_14_19:36:42_1996-1
Content-Type: text/plain; charset=US-ASCII

In XEmacs 19.15 [Lucid] (i486-unknown-linux2.0.18) of Sat Sep 14 1996 on deanna.miranova.com

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

[Testing emacsbug.el by sending a real bug report]

The attached file does not font lock correctly.  When I do insertions
around the bottom of the file, XEmacs gets confused and starts
coloring everything except the string in re-search-forward as a
string.  This bug is present in GNU Emacs 19.34, XEmacs 19.14 and
(now) XEmacs 19.15 with lisp-mode synched with GNU Emacs 19.34.


--Multipart_Sat_Sep_14_19:36:42_1996-1
Content-Type: application/octet-stream; type=emacs-lisp
Content-Disposition: attachment; filename="bug.el"
Content-Transfer-Encoding: 7bit

(defun canonically-space-region (beg end)
  "Remove extra spaces between words in region.
Leave one space between words, two at end of sentences or after colons
(depending on values of `sentence-end-double-space' and `colon-double-space').
 Remove indentation from each line."
  (interactive "r")
  (save-excursion
    (goto-char beg)
    ;; XEmacs - (ENE/stig from fa-extras.el): Skip the start of a comment.
    (and comment-start-skip
	 (looking-at comment-start-skip)
	 (goto-char (match-end 0)))
    ;; Nuke tabs; they get screwed up in a fill.
    ;; This is quick, but loses when a tab follows the end of a sentence.
    ;; Actually, it is difficult to tell that from "Mr.\tSmith".
    ;; Blame the typist.
    (subst-char-in-region beg end ?\t ?\ )
    (while (and (< (point) end)
		(re-search-forward "   *" end t))
      (delete-region
       (+ (match-beginning 0)
	  ;; Determine number of spaces to leave:
	  (save-excursion
	    (skip-chars-backward " ]})\"'")
	    (cond ((and sentence-end-double-space
			(memq (preceding-char) '(?. ?? ?!)))  2)
		  ((and colon-double-space
			(= (preceding-char) ?:))  2)
		  ((char-equal (preceding-char) ?\n)  0)
		  (t 1))))
       (match-end 0)))
    ;; Make sure sentences ending at end of line get an extra space.
    ;; loses on split abbrevs ("Mr.\nSmith")
    (goto-char beg)
    (while (and (< (point) end)
		(re-search-forward "[.?!][])}\"']*$" end t))
      ;; We insert before markers in case a caller such as
      ;; do-auto-fill has done a save-excursion with point at the end
      ;; of the line and wants it to stay at the end of the line.
      (insert ? ))))
;; XEmacs: we don't have this function.
;; (insert-before-markers-and-inherit ? ))))

;; XEmacs -- added DONT-SKIP-FIRST.  Port of older code changes by Stig.
;; #### probably this junk is broken -- do-auto-fill doesn't actually use
;; it.  If so, it should be removed.


--Multipart_Sat_Sep_14_19:36:42_1996-1
Content-Type: text/plain; charset=US-ASCII


Recent input:
C-p C-p C-p C-l M-x r e p o r t - e m a c s 0 b DEL 
DEL - b u g RET L i s p SPC M o d e SPC f o n t SPC 
l o c k i n g SPC b u g SPC r e p o r t SPC E m a c 
s SPC 9 1 . 3 4 C-b C-b C-b C-b C-t C-e , SPC X E m 
a c s SPC 1 9 . 1 4 Sh-SPC & Sh-SPC 1 9 . 1 5 RET

Recent messages:
Killing 103 characters
Wrote /i/xemacs-19.15-b1/lisp/packages/emacsbug.el
Entering debugger...

Wrote /i/xemacs-19.15-b1/lisp/packages/emacsbug.el
report-xemacs-bug
Type C-c C-x C-z to exit MIME mode, and type C-c C-x ? to get help.
Exit MIME editor mode.
Sending...
Sending...done

--Multipart_Sat_Sep_14_19:36:42_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Sun Sep 15 10:22:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA03457 for xemacs-beta-people; Sun, 15 Sep 1996 10:22:19 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA03454 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 15 Sep 1996 10:22:17 -0500 (CDT)
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA16064 for <xemacs-beta@xemacs.org>; Sun, 15 Sep 1996 10:22:15 -0500 (CDT)
Received: from berne.ai.mit.edu by martigny.ai.mit.edu with SMTP
	(1.40.112.4/16.2) id AA289417687; Sun, 15 Sep 1996 10:28:07 -0400
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
Message-Id: <199609151428.AA289417687@martigny.ai.mit.edu>
Received: by berne.ai.mit.edu
	(1.40.112.4/16.2) id AA021077659; Sun, 15 Sep 1996 10:27:39 -0400
Date: Sun, 15 Sep 1996 10:27:39 -0400
To: steve@miranova.com
Cc: xemacs-beta@xemacs.org
In-Reply-To: <199609150236.TAA10602@deanna.miranova.com> (message from Steven
	L Baur on Sat, 14 Sep 1996 19:36:45 -0700)
Subject: Re: Lisp Mode font locking bug report Emacs 19.34, XEmacs 19.14 & 19.15

:Date: Sat, 14 Sep 1996 19:36:45 -0700
:From: Steven L Baur <steve@miranova.com>
:
:The attached file does not font lock correctly. ...
:
:(defun canonically-space-region (beg end)
:  "Remove extra spaces between words in region.
:Leave one space between words, two at end of sentences or after colons
:(depending on values of `sentence-end-double-space' and `colon-double-space').
: Remove indentation from each line." ...

Most likely this is due to the '(' in column 0 in your comment string.
Recall the convention in lisp modes that a '(' in column 0 is used to 
anchor toplevel syntax (e.g. by beginning-of-defun).

Problems like these go away if you compute true syntax (or even a
closer approximation, e.g. sectionization). Someday when I find some 
spare time I'll extend FontiFly in this manner. A cheap hack to
alleviate the above problem could have beginning-of-defun etc.
ensure that it is not in a non-code font-lock extent (e.g. a string).

-Bill

From xemacs-beta-request@cs.uiuc.edu  Sun Sep 15 12:31:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA03596 for xemacs-beta-people; Sun, 15 Sep 1996 12:31:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA03593 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 15 Sep 1996 12:30:57 -0500 (CDT)
Received: from jagor.srce.hr (root@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA27144 for <xemacs-beta@xemacs.org>; Sun, 15 Sep 1996 12:30:32 -0500 (CDT)
Received: from hniksic@localhost by jagor.srce.hr (8.7.5/8.6.12.CI)
	id SAA06649; Sun, 15 Sep 1996 18:13:05 +0200 (MET DST)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: [comp.emacs] Re: Informative tip
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/geturl/
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 15 Sep 1996 18:13:03 +0200
Message-ID: <kigvidfhi40.fsf@jagor.srce.hr>
Lines: 54
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Is anybody taking notice of this thread? This looks to me like the
behaviour I'd like to see in XEmacs too.

------- Start of forwarded message -------
From: Carsten Dominik <dominik@strw.LeidenUniv.nl>
Newsgroups: comp.emacs
Subject: Re: Informative tip
Date: 12 Sep 1996 09:57:29 +0200
Organization: Leiden Observatory, The Netherlands
Message-ID: <k020g82mja.fsf@regge.i-have-a-misconfigured-system-so-shoot-me>
References: <u03f0rr8dg.fsf@eurisko.nlm.nih.gov> <dvdsafuzyrkp.fsf@eden.com>
	<3051389877436619@arcana.naggum.no>

Erik Naggum <erik@naggum.no> writes:

> 
> [David Vanderschel]
> 
> |   There was posted in gnu.emacs.sources within the last two days a
> |   package that purports to address this very 'problem' by offering the
> |   'tip' _after_ command completion (so you do not have to wait).
> 
> this suggestion was picked up by RMS and will be the default behavior on
> 19.35.  

Before this is implemented for 19.35, I have another suggestion to
make (but I don't know enough elisp to implement is myself). 

Whenever I execute a command with M-x, I use minibuffer
completion. Therefore, the most usefull version of the "tip" would be
to be displayed in the minibuffer when completion was succesfull. So
you would see it just before you hit return to execute the
command, like that:

I type:

   M-x forward-w

and hit TAB to complete. Then the minibuffer should show:

M-x forward-word (is at M-f)

This is the best time to display it since you are looking at the
minibuffer anyway...


-Carsten

Carsten dominik@strw.LeidenUniv.nl                  \ _ /
Sterrewacht, P.O. Box 9513                           |X|                 
NL-2300 RA Leiden (The Netherlands)                 /| |\            _
phone +31 (71) 527-5845; FAX +31 (71) 527-5819 ______|o|____   _____/ \_
                                                            ~~~         ~~~~
------- End of forwarded message -------

From xemacs-beta-request@cs.uiuc.edu  Sun Sep 15 21:01:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA04289 for xemacs-beta-people; Sun, 15 Sep 1996 21:01:33 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA04286 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 15 Sep 1996 21:01:32 -0500 (CDT)
Received: from deanna.miranova.com (deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA01603 for <xemacs-beta@cs.uiuc.edu>; Sun, 15 Sep 1996 21:01:09 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id RAA20367; Sun, 15 Sep 1996 17:05:54 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Showing keybindings at completion time (Patch to icomplete.el)
References: <kigvidfhi40.fsf@jagor.srce.hr>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Hrvoje Niksic's message of 15 Sep 1996 18:13:03 +0200
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 15 Sep 1996 17:05:51 -0700
Message-ID: <m2d8znz5ls.fsf@deanna.miranova.com>
Lines: 546
X-Mailer: Red Gnus v0.34/XEmacs 19.15

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrvoje> Is anybody taking notice of this thread? This looks to me like the
Hrvoje> behaviour I'd like to see in XEmacs too.

suggbind.el works, but is unexciting.  It also has the bug that the
key binding is looked up after the command is executed (just as in
font-lock, printing something trying to be helpful but wrong is a
total waste, IMHO).  However ...

> [David Vanderschel]

David> There was posted in gnu.emacs.sources within the last two days a
David> package that purports to address this very 'problem' by offering the
David> 'tip' _after_ command completion (so you do not have to wait).

> From: Carsten Dominik <dominik@strw.LeidenUniv.nl>

Carsten> Before this is implemented for 19.35, I have another
Carsten> suggestion to make (but I don't know enough elisp to
Carsten> implement is myself).

Carsten> Whenever I execute a command with M-x, I use minibuffer
Carsten> completion. Therefore, the most usefull version of the "tip"
Carsten> would be to be displayed in the minibuffer when completion
Carsten> was succesfull. So you would see it just before you hit
Carsten> return to execute the command, like that:

Carsten> I type:

Carsten> M-x forward-w

Carsten> and hit TAB to complete. Then the minibuffer should show:

Carsten> M-x forward-word (is at M-f)

I like Carsten's idea better.  We already have a package
(packages/icomplete.el) that has code to preview stuff in the
minibuffer as you type.  When it works, it's pretty nice.  And as it
turns out, implementing Carsten's suggestion is pretty easy.

Here's a patch for icomplete.el (against 19.15-b1) that implements it:
NB:  Includes the minor changes to sync icomplete.el up to Emacs 19.34

*** packages/icomplete.el.0	Sun Jan 21 19:51:09 1996
--- packages/icomplete.el	Sun Sep 15 16:52:24 1996
***************
*** 1,6 ****
  ;;; icomplete.el --- minibuffer completion with incremental feedback
  
! ;;; Copyright (C) 1992, 1993, 1994, 1995 Free Software Foundation, Inc.
  
  ;;; Author: Ken Manheimer <klm@nist.gov>
  ;;; Maintainer: Ken Manheimer <klm@nist.gov>
--- 1,6 ----
  ;;; icomplete.el --- minibuffer completion with incremental feedback
  
! ;;; Copyright (C) 1992, 1993, 1994 Free Software Foundation, Inc.
  
  ;;; Author: Ken Manheimer <klm@nist.gov>
  ;;; Maintainer: Ken Manheimer <klm@nist.gov>
***************
*** 10,69 ****
  
  ;;; Hacked for XEmacs: David Hughes 7th September 1995
  
! ;; This file is part of GNU Emacs.
  
! ;; GNU Emacs is free software; you can redistribute it and/or modify
! ;; it under the terms of the GNU General Public License as published by
  ;; the Free Software Foundation; either version 2, or (at your option)
  ;; any later version.
  
! ;; GNU Emacs is distributed in the hope that it will be useful,
! ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
! ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
! ;; GNU General Public License for more details.
  
  ;; You should have received a copy of the GNU General Public License
! ;; along with GNU Emacs; see the file COPYING.  If not, write to
! ;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
  
! ;;; Synched up with: FSF 19.29.
  
  ;;; Commentary:
  
! ;;; Loading this package implements a more fine-grained minibuffer
! ;;; completion feedback scheme.  Prospective completions are concisely
! ;;; indicated within the minibuffer itself, with each successive
! ;;; keystroke.
! 
! ;;; See 'icomplete-completions' docstring for a description of the
! ;;; icomplete display format.
! 
! ;;; See the `icomplete-minibuffer-setup-hook' docstring for a means to
! ;;; customize icomplete setup for interoperation with other
! ;;; minibuffer-oriented packages.
! 
! ;;; To activate icomplete mode, simply load the package.  You can
! ;;; subsequently deactivate it by invoking the function icomplete-mode
! ;;; with a negative prefix-arg (C-U -1 ESC-x icomplete-mode).  Also,
! ;;; you can prevent activation of the mode during package load by
! ;;; first setting the variable `icomplete-mode' to nil.  Icompletion
! ;;; can be enabled any time after the package is loaded by invoking
! ;;; icomplete-mode without a prefix arg.
! 
! ;;; This version of icomplete runs on Emacs 19.18 and later.  (It
! ;;; depends on the incorporation of minibuffer-setup-hook.)  The elisp
! ;;; archives, ftp://archive.cis.ohio-state.edu/pub/gnu/emacs/elisp-archive,
! ;;; probably still has a version that works in GNU Emacs v18.
! 
! ;;; Thanks to everyone for their suggestions for refinements of this
! ;;; package.  I particularly have to credit Michael Cook, who
! ;;; implemented an incremental completion style in his 'iswitch'
! ;;; functions that served as a model for icomplete.  Some other
! ;;; contributors: Noah Freidman (restructuring as minor mode), Colin
! ;;; Rafferty (lemacs reconciliation), Lars Lindberg, RMS, and
! ;;; others.
  
! ;;; klm.
  
  ;;; Code:
  
--- 10,70 ----
  
  ;;; Hacked for XEmacs: David Hughes 7th September 1995
  
! ;; This file is part of XEmacs.
  
! ;; XEmacs is free software; you can redistribute it and/or modify it
! ;; under the terms of the GNU General Public License as published by
  ;; the Free Software Foundation; either version 2, or (at your option)
  ;; any later version.
  
! ;; XEmacs is distributed in the hope that it will be useful, but
! ;; WITHOUT ANY WARRANTY; without even the implied warranty of
! ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
! ;; General Public License for more details.
  
  ;; You should have received a copy of the GNU General Public License
! ;; along with XEmacs; see the file COPYING.  If not, write to the Free
! ;; Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
! ;; 02111-1307, USA.
  
! ;;; Synched up with: FSF 19.34.
  
  ;;; Commentary:
  
! ;; Loading this package implements a more fine-grained minibuffer
! ;; completion feedback scheme.  Prospective completions are concisely
! ;; indicated within the minibuffer itself, with each successive
! ;; keystroke.
! 
! ;; See 'icomplete-completions' docstring for a description of the
! ;; icomplete display format.
! 
! ;; See the `icomplete-minibuffer-setup-hook' docstring for a means to
! ;; customize icomplete setup for interoperation with other
! ;; minibuffer-oriented packages.
! 
! ;; To activate icomplete mode, simply load the package.  You can
! ;; subsequently deactivate it by invoking the function icomplete-mode
! ;; with a negative prefix-arg (C-U -1 ESC-x icomplete-mode).  Also,
! ;; you can prevent activation of the mode during package load by
! ;; first setting the variable `icomplete-mode' to nil.  Icompletion
! ;; can be enabled any time after the package is loaded by invoking
! ;; icomplete-mode without a prefix arg.
! 
! ;; This version of icomplete runs on Emacs 19.18 and later.  (It
! ;; depends on the incorporation of minibuffer-setup-hook.)  The elisp
! ;; archives, ftp://archive.cis.ohio-state.edu/pub/gnu/emacs/elisp-archive,
! ;; probably still has a version that works in GNU Emacs v18.
! 
! ;; Thanks to everyone for their suggestions for refinements of this
! ;; package.  I particularly have to credit Michael Cook, who
! ;; implemented an incremental completion style in his 'iswitch'
! ;; functions that served as a model for icomplete.  Some other
! ;; contributors: Noah Freidman (restructuring as minor mode), Colin
! ;; Rafferty (lemacs reconciliation), Lars Lindberg, RMS, and
! ;; others.
  
! ;; klm.
  
  ;;; Code:
  
***************
*** 71,83 ****
  (provide 'icomplete)
  
  ;;;_* User Customization variables
- (defvar icomplete-compute-delay .3
-   "*Completions-computation stall, used only with large-number
- completions - see `icomplete-delay-completions-threshold'.")
- (defvar icomplete-delay-completions-threshold 400
-   "*Pending-completions number over which to apply icomplete-compute-delay.")
- (defvar icomplete-max-delay-chars 3
-   "*Maximum number of initial chars to apply icomplete compute delay.")
  
  ;;;_* Initialization
  ;;;_  = icomplete-minibuffer-setup-hook
--- 72,77 ----
***************
*** 123,135 ****
  minibuffer completion.")
  (add-hook 'icomplete-post-command-hook 'icomplete-exhibit)
  
! ;;;_ > icomplete-run-pre-command-hooks
! (defun icomplete-run-pre-command-hooks ()
!   (run-hooks 'icomplete-pre-command-hook))
! 
! ;;;_ > icomplete-run-post-command-hooks
! (defun icomplete-run-post-command-hooks ()
!   (run-hooks 'icomplete-post-command-hook))
  
  ;;;_ > icomplete-mode (&optional prefix)
  ;;;###autoload
--- 117,142 ----
  minibuffer completion.")
  (add-hook 'icomplete-post-command-hook 'icomplete-exhibit)
  
! ;; XEmacs addition
! (defvar icomplete-show-key-bindings t
!   "When non-nil show key bindings as well as completion when matching
! a command.")
! 
! ;; XEmacs addition
! (defun icomplete-get-keys (func-name)
!   "Return the keys `func-name' is bound to as a string."
!   (when (commandp func-name)
!     (let* ((sym (intern func-name))
! 	   (keys (where-is-internal sym)))
!       (concat "<"
! 	      (if keys
! 		  (mapconcat 'key-description
! 			     (sort '([next] [kp_next] [(control v)])
! 				   #'(lambda (x y)
! 				       (< (length x) (length y))))
! 			     ", ")
! 		"Unbound")
! 	      ">"))))
  
  ;;;_ > icomplete-mode (&optional prefix)
  ;;;###autoload
***************
*** 154,187 ****
     the selected window is a minibuffer,
     and not in the middle of macro execution,
     and minibuffer-completion-table is not a symbol (which would
!        indicate some non-standard, non-simple completion mechansm,
         like file-name and other custom-func completions)."
  
    (and (window-minibuffer-p (selected-window))
!        (not executing-macro)
         (not (symbolp minibuffer-completion-table))))
  ;;;_ > icomplete-minibuffer-setup ()
  ;;;###autoload
  (defun icomplete-minibuffer-setup ()
- 
    "Run in minibuffer on activation to establish incremental completion.
! 
! Usually run by inclusion in minibuffer-setup-hook."
! 
    (cond ((and icomplete-mode (icomplete-simple-completing-p))
  	 (make-local-hook 'pre-command-hook)
! 	 (add-hook 'pre-command-hook 'icomplete-run-pre-command-hooks nil t)
  	 (make-local-hook 'post-command-hook)
! 	 (add-hook 'post-command-hook 'icomplete-run-post-command-hooks nil t)
  	 (run-hooks 'icomplete-minibuffer-setup-hook))))
! 
  ;;;_* Completion
  
  ;;;_ > icomplete-tidy ()
  (defun icomplete-tidy ()
    "Remove completions display \(if any) prior to new user input.
! 
! Should be run in on the minibuffer pre-command-hook.  See `icomplete-mode'
  and `minibuffer-setup-hook'."
    (if (icomplete-simple-completing-p)
        (if (and (boundp 'icomplete-eoinput)
--- 161,197 ----
     the selected window is a minibuffer,
     and not in the middle of macro execution,
     and minibuffer-completion-table is not a symbol (which would
!        indicate some non-standard, non-simple completion mechanism,
         like file-name and other custom-func completions)."
  
    (and (window-minibuffer-p (selected-window))
!        (not executing-kbd-macro)
         (not (symbolp minibuffer-completion-table))))
+ 
  ;;;_ > icomplete-minibuffer-setup ()
  ;;;###autoload
  (defun icomplete-minibuffer-setup ()
    "Run in minibuffer on activation to establish incremental completion.
! Usually run by inclusion in `minibuffer-setup-hook'."
    (cond ((and icomplete-mode (icomplete-simple-completing-p))
  	 (make-local-hook 'pre-command-hook)
! 	 (add-hook 'pre-command-hook
! 		   (function (lambda ()
! 			       (run-hooks 'icomplete-pre-command-hook)))
! 		   nil t)
  	 (make-local-hook 'post-command-hook)
! 	 (add-hook 'post-command-hook
! 		   (function (lambda ()
! 			       (run-hooks 'icomplete-post-command-hook)))
! 		   nil t)
  	 (run-hooks 'icomplete-minibuffer-setup-hook))))
! 
  ;;;_* Completion
  
  ;;;_ > icomplete-tidy ()
  (defun icomplete-tidy ()
    "Remove completions display \(if any) prior to new user input.
! Should be run in on the minibuffer `pre-command-hook'.  See `icomplete-mode'
  and `minibuffer-setup-hook'."
    (if (icomplete-simple-completing-p)
        (if (and (boundp 'icomplete-eoinput)
***************
*** 196,210 ****
  	;; Reestablish the local variable 'cause minibuffer-setup is weird:
  	(make-local-variable 'icomplete-eoinput)
  	(setq icomplete-eoinput 1))))
  ;;;_ > icomplete-exhibit ()
  (defun icomplete-exhibit ()
    "Insert icomplete completions display.
! 
! Should be run via minibuffer post-command-hook.  See `icomplete-mode'
  and `minibuffer-setup-hook'."
    (if (icomplete-simple-completing-p)
!       (let* ((contents (buffer-substring (point-min)(point-max)))
! 	     (buffer-undo-list t))
  	(save-excursion
  	  (goto-char (point-max))
                                          ; Register the end of input, so we
--- 206,220 ----
  	;; Reestablish the local variable 'cause minibuffer-setup is weird:
  	(make-local-variable 'icomplete-eoinput)
  	(setq icomplete-eoinput 1))))
+ 
  ;;;_ > icomplete-exhibit ()
  (defun icomplete-exhibit ()
    "Insert icomplete completions display.
! Should be run via minibuffer `post-command-hook'.  See `icomplete-mode'
  and `minibuffer-setup-hook'."
    (if (icomplete-simple-completing-p)
!       (let ((contents (buffer-substring (point-min)(point-max)))
! 	    (buffer-undo-list t))
  	(save-excursion
  	  (goto-char (point-max))
                                          ; Register the end of input, so we
***************
*** 215,242 ****
  	      (make-local-variable 'icomplete-eoinput))
  	  (setq icomplete-eoinput (point))
                                          ; Insert the match-status information:
! 	  (if (and (> (point-max) 1)
! 		   (or
! 		    ;; Don't bother with delay after certain number of chars:
! 		    (> (point-max) icomplete-max-delay-chars)
! 		    ;; Don't delay if alternatives number is small enough:
! 		    (if minibuffer-completion-table
! 			(cond ((numberp minibuffer-completion-table)
! 			       (< minibuffer-completion-table
! 				  icomplete-delay-completions-threshold))
! 			      ((sequencep minibuffer-completion-table)
! 			       (< (length minibuffer-completion-table)
! 				  icomplete-delay-completions-threshold))
! 			      ))
! 		    ;; Delay - give some grace time for next keystroke, before
! 		    ;; embarking on computing completions:
!                     (sit-for icomplete-compute-delay)))
  	      (insert-string
  	       (icomplete-completions contents
  				      minibuffer-completion-table
  				      minibuffer-completion-predicate
  				      (not
  				       minibuffer-completion-confirm))))))))
  ;;;_ > icomplete-completions (name candidates predicate require-match)
  (defun icomplete-completions (name candidates predicate require-match)
    "Identify prospective candidates for minibuffer completion.
--- 225,238 ----
  	      (make-local-variable 'icomplete-eoinput))
  	  (setq icomplete-eoinput (point))
                                          ; Insert the match-status information:
! 	  (if (> (point-max) 1)
  	      (insert-string
  	       (icomplete-completions contents
  				      minibuffer-completion-table
  				      minibuffer-completion-predicate
  				      (not
  				       minibuffer-completion-confirm))))))))
+ 
  ;;;_ > icomplete-completions (name candidates predicate require-match)
  (defun icomplete-completions (name candidates predicate require-match)
    "Identify prospective candidates for minibuffer completion.
***************
*** 250,259 ****
    \(...) - a single prospect is identified and matching is enforced,
    \[...] - a single prospect is identified but matching is optional, or
    \{...} - multiple prospects, separated by commas, are indicated, and
!           further input is required to distingish a single one.
  
! The displays for disambiguous matches have \" [Matched]\" appended
! \(whether complete or not), or \" \[No matches]\", if no eligible
  matches exist."
  
    (let ((comps (all-completions name candidates predicate))
--- 246,255 ----
    \(...) - a single prospect is identified and matching is enforced,
    \[...] - a single prospect is identified but matching is optional, or
    \{...} - multiple prospects, separated by commas, are indicated, and
!           further input is required to distinguish a single one.
  
! The displays for unambiguous matches have ` [Matched]' appended
! \(whether complete or not), or ` \[No matches]', if no eligible
  matches exist."
  
    (let ((comps (all-completions name candidates predicate))
***************
*** 264,327 ****
          (open-bracket-prospects "{")
          (close-bracket-prospects "}")
          )
!     (catch 'input
!       (cond ((null comps) (format " %sNo matches%s"
! 				  open-bracket-determined
  				  close-bracket-determined))
! 	    ((null (cdr comps))		;one match
! 	     (concat (if (and (> (length (car comps))
! 				 (length name)))
! 			 (concat open-bracket-determined
! 				 (substring (car comps) (length name))
! 				 close-bracket-determined)
! 		       "")
! 		     " [Matched]"))
! 	    (t				;multiple matches
! 	     (let* ((most
! 		     (try-completion name candidates
! 				     (and predicate
! 					  ;; Wrap predicate in impatience - ie,
! 					  ;; `throw' up when pending input is
! 					  ;; noticed.  Adds some overhead to
! 					  ;; predicate, but should be worth it.
! 					  (function
! 					   (lambda (item)
!                                              (if (input-pending-p)
! 						 (throw 'input "")
! 					       (apply predicate
! 						      item nil)))))))
! 		    (most-len (length most))
! 		    most-is-exact
! 		    (alternatives
! 		     (substring
! 		      (apply (function concat)
! 			     (mapcar (function
! 				      (lambda (com)
!                                         (if (input-pending-p)
! 					    (throw 'input ""))
! 					(if (= (length com) most-len)
! 					    ;; Most is one exact match,
! 					    ;; note that and leave out
! 					    ;; for later indication:
! 					    (progn
! 					      (setq most-is-exact t)
! 					      ())
! 					  (concat ","
! 						  (substring com
! 							     most-len)))))
! 				     comps))
! 		      1)))
! 	       (concat (and (> most-len (length name))
! 			    (concat open-bracket-determined
! 				    (substring most (length name))
! 				    close-bracket-determined))
! 		       open-bracket-prospects
! 		       (if most-is-exact
! 			   ;; Add a ',' at the front to indicate "complete but
! 			   ;; not unique":
! 			   (concat "," alternatives)
! 			 alternatives)
! 		       close-bracket-prospects)))))))
  
  ;;;_ + Initialization
  ;;; If user hasn't setq-default icomplete-mode to nil, then setup for
--- 260,312 ----
          (open-bracket-prospects "{")
          (close-bracket-prospects "}")
          )
!     (cond ((null comps) (format " %sNo matches%s"
! 				open-bracket-determined
! 				close-bracket-determined))
! 	  ((null (cdr comps))           ;one match
! 	   (concat (if (and (> (length (car comps))
! 			       (length name)))
! 		       (concat open-bracket-determined
! 			       (substring (car comps) (length name))
! 			       close-bracket-determined)
! 		     "")
! 		   " [Matched]"
! 	   ;; XEmacs
! 		   (if (and icomplete-show-key-bindings
! 			    (commandp (car comps)))
! 		       (icomplete-get-keys (car comps))
! 		     "")
! 		   ))
! 	  (t                            ;multiple matches
! 	   (let* ((most (try-completion name candidates predicate))
! 		  (most-len (length most))
! 		  most-is-exact
! 		  (alternatives
! 		   (apply
! 		    (function concat)
! 		    (cdr (apply
! 			  (function nconc)
! 			  (mapcar '(lambda (com)
! 				     (if (= (length com) most-len)
! 					 ;; Most is one exact match,
! 					 ;; note that and leave out
! 					 ;; for later indication:
! 					 (progn
! 					   (setq most-is-exact t)
! 					   ())
! 				       (list ","
! 					     (substring com
! 							most-len))))
! 				  comps))))))
! 	     (concat (and (> most-len (length name))
! 			  (concat open-bracket-determined
! 				  (substring most (length name))
  				  close-bracket-determined))
! 		     open-bracket-prospects
! 		     (if most-is-exact
! 			 (concat "," alternatives)
! 		       alternatives)
! 		     close-bracket-prospects))))))
  
  ;;;_ + Initialization
  ;;; If user hasn't setq-default icomplete-mode to nil, then setup for



-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Sun Sep 15 22:35:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA04500 for xemacs-beta-people; Sun, 15 Sep 1996 22:35:10 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA04497 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 15 Sep 1996 22:35:09 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA02545 for <xemacs-beta@cs.uiuc.edu>; Sun, 15 Sep 1996 22:34:32 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id UAA22712; Sun, 15 Sep 1996 20:37:13 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: mic-paren.el for XEmacs
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: multipart/mixed;
 boundary="Multipart_Sun_Sep_15_20:37:09_1996-1"
Content-Transfer-Encoding: 7bit
Date: 15 Sep 1996 20:37:09 -0700
Message-ID: <m2g24jxh96.fsf@deanna.miranova.com>
Lines: 600
X-Mailer: Red Gnus v0.34/XEmacs 19.15

--Multipart_Sun_Sep_15_20:37:09_1996-1
Content-Type: text/plain; charset=US-ASCII

Modified from the mic-paren.el posted on gnu.emacs.sources recently to
work for XEmacs ...


--Multipart_Sun_Sep_15_20:37:09_1996-1
Content-Type: application/octet-stream; type=emacs-lisp
Content-Disposition: attachment; filename="mic-paren.el"
Content-Transfer-Encoding: 7bit

;;; mic-paren.el --- highlight matching paren.
;;; Version 1.0 - 96-08-16
;;; Copyright (C) 1996 Mikael Sjdin (mic@docs.uu.se)
;;;
;;; Author: Mikael Sjdin  --  mic@docs.uu.se
;;; Keywords: languages, faces
;;;
;;; This file is NOT part of GNU Emacs.
;;; You may however redistribute it and/or modify it under the terms of the GNU
;;; General Public License as published by the Free Software Foundation; either
;;; version 2, or (at your option) any later version.
;;;
;;; mic-paren is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.

;;; ----------------------------------------------------------------------
;;; Short Description:
;;;
;;; Load this file and Emacs will display highlighting on whatever
;;; parenthesis matches the one before or after point.  This is an extension to
;;; the paren.el file distributed with Emacs.  The default behaviour is similar
;;; to paren.el but try the authors favourite options:
;;;   (setq paren-face 'bold)
;;;   (setq paren-sexp-mode t)

;;; ----------------------------------------------------------------------
;;; Installation:
;;;
;;; o Place this file in a directory in your 'load-path.
;;; o Put the following in your .emacs file:
;;;     (if window-system
;;;         (require 'mic-paren))
;;; o Restart your Emacs. mic-paren is now installed and activated!
;;; o To list the possible customisation enter `C-h f paren-activate'

;;; ----------------------------------------------------------------------
;;; Long Description:
;;;
;;; mic-paren.el is an extension to the packages paren.el and stig-paren.el for
;;; Emacs.  When mic-paren is active (it is activated when loaded) Emacs normal
;;; parenthesis matching is deactivated.  Instead parenthesis matching will be
;;; performed as soon as the cursor is positioned at a parenthesis.  The
;;; matching parenthesis (or the entire expression between the parenthesises)
;;; is highlighted until the cursor is moved away from the parenthesis.
;;; Features include:
;;; o Both forward and backward parenthesis matching (_simultaneously_ if
;;;   cursor is between two expressions).
;;; o Indication of mismatched parenthesises.
;;; o Option to select if only the matching parenthesis or the entire
;;;   expression should be highlighted.
;;; o Message describing the match when the matching parenthesis is
;;;   off-screen. 
;;; o Optional delayed highlighting (useful on slow systems), 
;;; o Functions to activate/deactivate mic-paren.el is provided.
;;; o Numerous options to control the behaviour and appearance of
;;;   mic-paren.el. 
;;;
;;; mic-paren.el is developed and tested under Emacs 19.28 - 19.31.  It should
;;; work on earlier and forthcoming Emacs versions.
;;;
;;; This file can be obtained from http://www.docs.uu.se/~mic/emacs.html

;; Ported to XEmacs 15-September, 1996 Steve Baur <steve@miranova.com>
;;; ======================================================================
;;; User Options:

(defvar paren-priority nil
  "*Defines the behaviour of mic-paren when point is between a closing and an
  opening parenthesis.

A value of 'close means highlight the parenthesis matching the
close-parenthesis before the point.

A value of 'open means highlight the parenthesis matching the open-parenthesis
after the point.

Any other value means highlight both parenthesis matching the parenthesis
beside the point.")


;;; ------------------------------

(defvar paren-sexp-mode nil
  "*If nil only the matching parenthesis is highlighted.
If non-nil the whole s-expression between the matching parenthesis is
highlighted.")

;;; ------------------------------

(defvar paren-highlight-at-point t
  "*If non-nil and point is after a close parenthesis, both the close and
open parenthesis is highlighted. If nil, only the open parenthesis is
highlighted.")

;;; ------------------------------

(defvar paren-highlight-offscreen nil
  "*If non-nil stig-paren will highlight text which is not visible in the
current buffer.  

This is useful if you regularly display the current buffer in multiple windows
or frames. For instance if you use follow-mode (by andersl@csd.uu.se), however
it may slow down your Emacs.

(This variable is ignored (treated as non-nil) if you set paren-sexp-mode to
non-nil.)")

;;; ------------------------------

(defvar paren-message-offscreen t
  "*Display message if matching parenthesis is off-screen.")

;;; ------------------------------

(defvar paren-message-no-match t
  "*Display message if no matching parenthesis is found.")

;;; ------------------------------

(defvar paren-ding-unmatched nil
  "*Make noise if the cursor is at an unmatched parenthesis or no matching
parenthesis is found.

Even if nil, typing an unmatched parenthesis produces a ding.")

;;; ------------------------------

(defvar paren-delay nil
  "*This variable controls when highlighting is done.  The variable has
different meaning in different versions of Emacs.

In Emacs 19.29 and below: 
  This variable is ignored.

In Emacs 19.30:
  A value of nil will make highlighting happen immediately (this may slow down
  your Emacs if running on a slow system).  Any non-nil value will delay
  highlighting for the time specified by post-command-idle-delay.  

In Emacs 19.31 and above:
  A value of nil will make highlighting happen immediately (this may slow down
  your Emacs if running on a slow system).  If not nil, the value should be a
  number (possible a floating point number if your Emacs support floating point
  numbers).  The number is the delay before mic-paren performs highlighting.

If you change this variable when mic-paren is active you have to re-activate
(with M-x paren-activate) mic-paren for the change to take effect.")


;;; ------------------------------

(defvar paren-dont-touch-blink nil
  "*If non-nil mic-paren will not change the value of blink-matching-paren when
activated of deactivated.

If nil mic-paren turns of blinking when activated and turns on blinking when
deactivated.")

;;; ------------------------------

(defvar paren-dont-activate-on-load nil
 "*If non-nil mic-paren will not activate itself when loaded.")

;;; ------------------------------

(defvar paren-face (if (x-display-color-p) 'highlight 'underline)
  "*Face to use for showing the matching parenthesis.")

;;; ------------------------------

(defvar paren-mismatch-face (if (x-display-color-p)
				(let ((fn 'paren-mismatch-face))
				  (copy-face 'default fn)
				  (set-face-background fn "DeepPink")
				  fn)
			      'modeline)
  "*Face to use when highlighting a mismatched parenthesis.")

;;; ======================================================================
;;; User Functions:

;; XEmacs compatibility
(eval-and-compile
  (if (fboundp 'make-extent)
      (progn
	(fset 'mic-make-overlay 'make-extent)
	(fset 'mic-delete-overlay 'delete-extent)
	(fset 'mic-overlay-put 'set-extent-property)
	(defun mic-cancel-timer (timer) (delete-itimer timer))
	(fset 'mic-run-with-idle-timer 'start-itimer)
	)
    (fset 'mic-make-overlay 'make-overlay)
    (fset 'mic-delete-overlay 'delete-overlay)
    (fset 'mic-overlay-put 'overlay-put)
    (fset 'mic-cancel-timer 'cancel-timer)
    (fset 'mic-run-with-idle-timer 'run-with-idle-timer)
    ))


(defun paren-activate ()
  "Activates mic-paren parenthesis highlighting.
paren-activate deactivates the paren.el and stig-paren.el packages if they are
active 
Options:
  paren-priority
  paren-sexp-mode
  paren-highlight-at-point
  paren-highlight-offscreen
  paren-message-offscreen
  paren-message-no-match
  paren-ding-unmatched
  paren-delay
  paren-dont-touch-blink
  paren-dont-activate-on-load
  paren-face
  paren-mismatch-face"
  (interactive)
  ;; Deactivate mic-paren.el (To remove redundant hooks)
  (paren-deactivate)
  ;; Deactivate paren.el if loaded
  (if (boundp 'post-command-idle-hook)
      (remove-hook 'post-command-idle-hook 'show-paren-command-hook))
  (remove-hook 'post-command-hook 'show-paren-command-hook)
  (and (boundp 'show-paren-overlay)
       show-paren-overlay
       (mic-delete-overlay show-paren-overlay))
  (and (boundp 'show-paren-overlay-1)
       show-paren-overlay-1
       (mic-delete-overlay show-paren-overlay-1))
  ;; Deactivate stig-paren.el if loaded
  (if (boundp 'post-command-idle-hook)
      (remove-hook 'post-command-idle-hook 'stig-paren-command-hook))
  (remove-hook 'post-command-hook 'stig-paren-command-hook)
  (remove-hook 'post-command-hook 'stig-paren-safe-command-hook)
  (remove-hook 'pre-command-hook 'stig-paren-delete-overlay)
  ;; Deactivate Emacs standard parenthesis blinking
  (or paren-dont-touch-blink
      (setq blink-matching-paren nil))

  (cond
	;; If timers are available use them
	;; (Emacs 19.31 and above)
	((or (featurep 'timer) (featurep 'itimer))
	 (if (numberp paren-delay)
	     (setq mic-paren-idle-timer 
		   (mic-run-with-idle-timer paren-delay t
					    'mic-paren-command-idle-hook))
	   (add-hook 'post-command-hook 'mic-paren-command-hook)))
       ;; If the idle hook exists assume it is functioning and use it 
       ;; (Emacs 19.30)
       ((and (boundp 'post-command-idle-hook) 
	     (boundp 'post-command-idle-delay))
	(if paren-delay
	    (add-hook 'post-command-idle-hook 'mic-paren-command-idle-hook)
	  (add-hook 'post-command-hook 'mic-paren-command-hook)))
       ;; Check if we (at least) have a post-comand-hook, and use it
       ;; (Emacs 19.29 and below)
       ((boundp 'post-command-hook) 
	(add-hook 'post-command-hook 'mic-paren-command-hook))
       ;; Not possible to install mic-paren hooks
       (t (error "Cannot activate mic-paren in this Emacs version"))))



(defun paren-deactivate ()
  "Deactivates mic-paren parenthesis highlighting"
  (interactive)
  ;; Deactivate (don't bother to check where/if mic-paren is acivte, just
  ;; delete all possible hooks and timers)
  (if (boundp 'post-command-idle-hook)
      (remove-hook 'post-command-idle-hook 'mic-paren-command-idle-hook))
  (if mic-paren-idle-timer
      (mic-cancel-timer mic-paren-idle-timer))
  (remove-hook 'post-command-hook 'mic-paren-command-hook)

  ;; Remove any old highlighs
  (mic-delete-overlay mic-paren-backw-overlay)
  (mic-delete-overlay mic-paren-point-overlay)
  (mic-delete-overlay mic-paren-forw-overlay)

  ;; Reactivate Emacs standard parenthesis blinking
  (or paren-dont-touch-blink
      (setq blink-matching-paren t))
  )

;;; ======================================================================
;;; Internal variables:

(defvar mic-paren-backw-overlay (mic-make-overlay (point-min) (point-min))
  "Overlay for the open-paren which matches the close-paren before
point. When in sexp-mode this is the overlay for the expression before point.")

(defvar mic-paren-point-overlay (mic-make-overlay (point-min) (point-min))
  "Overlay for the close-paren before point.
(Not used when is sexp-mode.)")

(defvar mic-paren-forw-overlay (mic-make-overlay (point-min) (point-min))
  "Overlay for the close-paren which matches the open-paren after
point. When in sexp-mode this is the overlay for the expression after point.")

(defvar mic-paren-idle-timer nil
  "Idle-timer.  Used only in Emacs 19.31 and above (and if paren-delay is nil)")




;;; ======================================================================
;;; Internal function:



(defun mic-paren-command-hook ()
  (or executing-kbd-macro
      (input-pending-p)			;[This might cause trouble since the
                                        ; function is unreliable]
      (condition-case paren-error
	  (mic-paren-highligt)
	(error 
	 (if (not (window-minibuffer-p (selected-window)))
	     (message "mic-paren catched error (please report): %s"
		      paren-error))))))

(defun mic-paren-command-idle-hook ()
  (condition-case paren-error
      (mic-paren-highligt)
    (error 
     (if (not (window-minibuffer-p (selected-window)))
	 (message "mic-paren catched error (please report): %s" 
		  paren-error)))))


(defun mic-paren-highligt ()
  "The main-function of mic-paren. Does all highlighting, dinging, messages,
cleaning-up."
  ;; Remove any old highlighting
  (mic-delete-overlay mic-paren-forw-overlay)
  (mic-delete-overlay mic-paren-point-overlay)
  (mic-delete-overlay mic-paren-backw-overlay)

  ;; Handle backward highlighting (when after a close-paren):
  ;; If positioned after a close-paren, and
  ;;    not before an open-paren when priority=open, and
  ;;    the close-paren is not escaped then
  ;;      perform highlighting
  ;; else
  ;;      remove any old backward highlights
  (if (and (eq (char-syntax (preceding-char)) ?\))
	   (not (and (eq (char-syntax (following-char)) ?\()
		     (eq paren-priority 'open)))
	   (paren-evenp (paren-backslashes-before-char (1- (point)))))
       (let (open)
	 ;; Find the position for the open-paren
	 (save-excursion
	   (save-restriction
	     (if blink-matching-paren-distance
		 (narrow-to-region 
		  (max (point-min)
		       (- (point) blink-matching-paren-distance))
		  (point-max)))
	     (condition-case ()
		 (setq open (scan-sexps (point) -1))
	       (error nil))))

	 ;; If match found
	 ;;    highlight and/or print messages
	 ;; else
	 ;;    print no-match message
	 ;;    remove any old highlights
	 (if open
	     (let ((mismatch (/= (matching-paren (preceding-char)) 
				 (char-after open)))
		   (visible (pos-visible-in-window-p open)))
	       ;; If highlight is appropriate
	       ;;    highligt
	       ;; else
	       ;;    remove any old highlight
	       (if (or visible paren-highlight-offscreen paren-sexp-mode)
		   ;; If sexp-mode
		   ;;    highlight sexp
		   ;; else
		   ;;    highlight the two parens
		   (if paren-sexp-mode
		       (progn
			 (setq mic-paren-backw-overlay
			       (mic-make-overlay open (point)))
			 (if mismatch
			     (mic-overlay-put mic-paren-backw-overlay 
					      'face paren-mismatch-face)
			   (mic-overlay-put mic-paren-backw-overlay 
					    'face paren-face)))
		     (setq mic-paren-backw-overlay
			   (mic-make-overlay open (1+ open)))
		     (and paren-highlight-at-point
			  (setq mic-paren-point-overlay
				(mic-make-overlay (1- (point)) (point))))
		     (if mismatch
			 (progn
			   (mic-overlay-put mic-paren-backw-overlay 
					    'face paren-mismatch-face)
			   (and paren-highlight-at-point
				(mic-overlay-put mic-paren-point-overlay 
						 'face paren-mismatch-face)))
		       (mic-overlay-put mic-paren-backw-overlay 
					'face paren-face)
		       (and paren-highlight-at-point 
			    (mic-overlay-put mic-paren-point-overlay 
					     'face paren-face)))))
	       ;; Print messages if match is offscreen
	       (and paren-message-offscreen
		    (not visible)
		    (not (window-minibuffer-p (selected-window)))
		    (message "%s %s" 
			     (if mismatch "MISMATCH:" "Matches")
			     (mic-paren-get-matching-open-text open)))
	       ;; Ding if mismatch
	       (and mismatch
		    paren-ding-unmatched
		    (ding)))
	   (and paren-message-no-match
		(not (window-minibuffer-p (selected-window)))
		(message "No opening parenthesis found"))
	   (and paren-message-no-match
		paren-ding-unmatched
		(ding)))))

  ;; Handle forward highlighting (when before an open-paren):
  ;; If positioned before an open-paren, and
  ;;    not after a close-paren when priority=close, and
  ;;    the open-paren is not escaped then
  ;;      perform highlighting
  ;; else
  ;;      remove any old forward highlights
  (if (and (eq (char-syntax (following-char)) ?\()
	   (not (and (eq (char-syntax (preceding-char)) ?\))
		     (eq paren-priority 'close)))
	   (paren-evenp (paren-backslashes-before-char (point))))
       (let (close)
	 ;; Find the position for the close-paren
	 (save-excursion
	   (save-restriction
	     (if blink-matching-paren-distance
		 (narrow-to-region 
		  (point-min)
		  (min (point-max)
		       (+ (point) blink-matching-paren-distance))))
      	     (condition-case ()
		 (setq close (scan-sexps (point) 1))
	       (error nil))))
	 ;; If match found
	 ;;    highlight and/or print messages
	 ;; else
	 ;;    print no-match message
	 ;;    remove any old highlights
	 (if close
	     (let ((mismatch (/= (matching-paren (following-char)) 
				 (char-after (1- close))))
		   (visible (pos-visible-in-window-p close)))
	       ;; If highlight is appropriate
	       ;;    highligt
	       ;; else
	       ;;    remove any old highlight
	       (if (or visible paren-highlight-offscreen paren-sexp-mode)
		   ;; If sexp-mode
		   ;;    highlight sexp
		   ;; else
		   ;;    highlight the two parens
		   (if paren-sexp-mode
		       (progn
			 (setq mic-paren-forw-overlay
			       (mic-make-overlay (point) close))
			 (if mismatch
			     (mic-overlay-put mic-paren-forw-overlay 
					      'face paren-mismatch-face)
			   (mic-overlay-put mic-paren-forw-overlay 
					    'face paren-face)))
		     (setq mic-paren-forw-overlay
			   (mic-make-overlay (1- close) close))
		     (if mismatch
			 (mic-overlay-put mic-paren-forw-overlay 
					  'face paren-mismatch-face)
		       (mic-overlay-put mic-paren-forw-overlay 
					'face paren-face))))

	       ;; Print messages if match is offscreen
	       (and paren-message-offscreen
		    (not visible)
		    (not (window-minibuffer-p (selected-window)))
		    (message "%s %s" 
			     (if mismatch "MISMATCH:" "Matches")
			     (mic-paren-get-matching-close-text close)))
	       ;; Ding if mismatch
	       (and mismatch
		    paren-ding-unmatched
		    (ding)))
	   (and paren-message-no-match
		(not (window-minibuffer-p (selected-window)))
		(message "No closing parenthesis found"))
	   (and paren-message-no-match
		paren-ding-unmatched
		(ding))))))

;;; --------------------------------------------------

(defun mic-paren-get-matching-open-text (open)
  "Returns a string with the context around OPEN-paren."
  ;; If there's stuff on this line preceding the paren, then display text from
  ;; beginning of line to paren.
  ;;
  ;; If, however, the paren is at the beginning of a line, then skip whitespace
  ;; forward and display text from paren to end of the next line containing
  ;; non-space text.
  ;;
  ;; (Same as in stig-paren.el)
  (save-excursion
    (goto-char open)
    (if (save-excursion
	  (skip-chars-backward " \t")
	  (not (bolp)))
	(progn
	  (beginning-of-line)
	  (concat (buffer-substring (point) (1+ open)) "..."))
      (forward-char 1)			;From the beginning-of-line
      (skip-chars-forward "\n \t")
      (end-of-line)
      (buffer-substring open (point)))))


(defun mic-paren-get-matching-close-text (close)
  "Returns a string with the context around CLOSE-paren."
  ;; The whole line up until the close-paren with "..." appended if there are
  ;; more text after the close-paren
  (save-excursion
    (goto-char close)
    (beginning-of-line)
    (concat
     (buffer-substring (point) close)
     (progn 
       (goto-char close)
       (if (looking-at "[ \t]*$")
	   ""
	 "...")))))
  

(defun paren-evenp (number)
  "Returns t if NUMBER is an even number, nil otherwise"
  (eq 0 (% number 2)))

(defun paren-backslashes-before-char (pnt)
  (setq pnt (1- pnt))
  (let ((n 0))
    (while (and (>= pnt (point-min))
		(eq (char-syntax (char-after pnt)) ?\\))
      (setq n (1+ n))
      (setq pnt (1- pnt)))
    n))

    

;;; ======================================================================
;;; Initialisation when loading:


(or paren-dont-activate-on-load
    (paren-activate))

;;; This is in case mic-paren.el is preloaded. [Does this work? /Mic]
(add-hook 'window-setup-hook
	  (function (lambda ()
		      (and window-system
			   (not paren-dont-activate-on-load)
			   (paren-activate)))))

(provide 'mic-paren)
(provide 'paren)

--Multipart_Sun_Sep_15_20:37:09_1996-1
Content-Type: text/plain; charset=US-ASCII


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

--Multipart_Sun_Sep_15_20:37:09_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 00:05:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA04681 for xemacs-beta-people; Mon, 16 Sep 1996 00:05:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA04678 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 00:05:23 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA03364 for <xemacs-beta@cs.uiuc.edu>; Mon, 16 Sep 1996 00:05:21 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id WAA23283; Sun, 15 Sep 1996 22:08:52 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Request for 19.15 -- webjump.el
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 15 Sep 1996 22:08:50 -0700
Message-ID: <m2sp8jvyfx.fsf@deanna.miranova.com>
Lines: 14
X-Mailer: Red Gnus v0.34/XEmacs 19.15

I respectfully request consideration of including webjump.el (recently
posted to gnu.emacs.sources) into 19.15.  It works off of browse-url,
has no major lisp compatibility problems, and is a very handy package.

I've corresponded with the author, and he will be adding our URL into
the default hotlist.

A URL for webjump.el is:
	http://www.cs.brown.edu/people/nwv/
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 05:05:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA08866 for xemacs-beta-people; Mon, 16 Sep 1996 05:05:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA08863 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 05:05:14 -0500 (CDT)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA18941 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 05:04:52 -0500 (CDT)
Received: from hniksic@localhost by jagor.srce.hr (8.7.5/8.6.12.CI)
	id MAA10497; Mon, 16 Sep 1996 12:04:17 +0200 (MET DST)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: Re: Showing keybindings at completion time (Patch to icomplete.el)
References: <kigvidfhi40.fsf@jagor.srce.hr>
	<m2d8znz5ls.fsf@deanna.miranova.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/geturl/
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Sep 1996 12:04:17 +0200
In-Reply-To: Steven L Baur's message of 15 Sep 1996 17:05:51 -0700
Message-ID: <kigpw3msrmm.fsf@jagor.srce.hr>
Lines: 22
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Steven L Baur (steve@miranova.com) wrote:
> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:
> Hrvoje> Is anybody taking notice of this thread? This looks to me like the
> Hrvoje> behaviour I'd like to see in XEmacs too.
> suggbind.el works, but is unexciting.  It also has the bug that the
> key binding is looked up after the command is executed (just as in
> font-lock, printing something trying to be helpful but wrong is a
> total waste, IMHO).  However ...
[...]

I have tried the vanilla icomplete.el without the patch, but I don't
like its "normal" behaviour (printing messages in the minibuffer). Can
I turn them off and retain *only* the minibuffer suggestions? Is there
a chance of the patch being included to 19.15 as default instead of
teach-extended-commands?

-- 
hniksic@srce.hr              |  Student of electrical engineering
hniksic@fly.cc.fer.hr        |  University of Zagreb, Croatia
------------------------------------------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 10:22:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA09713 for xemacs-beta-people; Mon, 16 Sep 1996 10:22:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA09710 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 10:22:41 -0500 (CDT)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA05650 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 10:22:37 -0500 (CDT)
Received: from jaguar.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id JAA03842; Mon, 16 Sep 1996 09:19:56 -0600
Received: by jaguar.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id JAA06857; Mon, 16 Sep 1996 09:19:49 -0600
Date: Mon, 16 Sep 1996 09:19:49 -0600
From: eeide@jaguar.cs.utah.edu (Eric Eide)
Message-Id: <199609161519.JAA06857@jaguar.cs.utah.edu>
To: holder@mordor.rsn.hp.com, xemacs-beta@xemacs.org
In-reply-to: Shane Holder's message of Fri, Sep 13 <199609132349.SAA20515@mordor.rsn.hp.com>
Subject: Re: (frame-list) seems to be wrong.

Shane Holder <holder@mordor.rsn.hp.com> writes:

	Shane> It seems wrong to place newly created frames (or anything else)
	Shane> on the "END" of a list.  Is there a reason for this?

Perhaps the list is constructed from some other data structure on request
(e.g., a hash table) and your new frame just happens to end up at the end?  Or
perhaps the internal list is duplicated in a way that effectively reverses the
list?  I don't know; I haven't looked; but both are reasonable, possible
explanations.

I would say that unless the behavior is documented (i.e., the the newly created
frame is always prepended to the list), it is incorrect for code to assume a
particular behavior.  Is the behavior documented in GNU Emacs by the FSF?

	Shane> Emacs puts new frames on the beginning of the list, and I just
	Shane> spent several hours chasing down why some code I have didn't
	Shane> work.

But now your code is presumably more correct, in that it will always locate the
desired frame even when some future version of XEmacs or the not-XEmacs-Emacs
changes the way `frame-list' is constructed.

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 11:34:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA09897 for xemacs-beta-people; Mon, 16 Sep 1996 11:34:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA09894 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 11:34:25 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA09468 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 11:34:20 -0500 (CDT)
Received: from mordor.rsn.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA101981654; Mon, 16 Sep 1996 09:34:14 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id LAA22630; Mon, 16 Sep 1996 11:39:04 -0500 (CDT)
To: eeide@jaguar.cs.utah.edu (Eric Eide)
Cc: xemacs-beta@xemacs.org
Subject: Re: (frame-list) seems to be wrong.
References: <199609161519.JAA06857@jaguar.cs.utah.edu>
From: Shane Holder <holder@mordor.rsn.hp.com>
Date: 16 Sep 1996 11:39:04 -0500
In-Reply-To: eeide@jaguar.cs.utah.edu's message of Mon, 16 Sep 1996 09:19:49 -0600
Message-Id: <fawohj6mn2v.fsf@mordor.rsn.hp.com>
Lines: 55
X-Mailer: Red Gnus v0.34/XEmacs 19.15

>>>>> "Eric" == Eric Eide <eeide@jaguar.cs.utah.edu> writes:

  Eric> Shane Holder <holder@mordor.rsn.hp.com> writes:
  Shane> It seems wrong to place newly created frames (or anything else)
  Shane> on the "END" of a list.  Is there a reason for this?

  Eric> Perhaps the list is constructed from some other data structure
  Eric> on request (e.g., a hash table) and your new frame just
  Eric> happens to end up at the end?  Or perhaps the internal list is
  Eric> duplicated in a way that effectively reverses the list?  I
  Eric> don't know; I haven't looked; but both are reasonable,
  Eric> possible explanations.

  Eric> I would say that unless the behavior is documented (i.e., the
  Eric> the newly created frame is always prepended to the list), it
  Eric> is incorrect for code to assume a particular behavior.  Is the
  Eric> behavior documented in GNU Emacs by the FSF?

>From the lispref info file:

frame-list:

     The function `frame-list' returns a list of all the frames that
     have not been deleted.  It is analogous to `buffer-list' for
     buffers.  The list that you get is newly created, so modifying the
     list doesn't have any effect on the internals of XEmacs.

buffer-list:

   The "buffer list" is a list of all live buffers.  Creating a buffer
adds it to this list, and killing a buffer deletes it.  The order of
the buffers in the list is based primarily on how recently each buffer
has been displayed in the selected window.  Buffers move to the front
of the list when they are selected and to the end when they are buried.
Several functions, notably `other-buffer', use this ordering.  A
buffer list displayed for the user also follows this order.

  Shane> Emacs puts new frames on the beginning of the list, and I just
  Shane> spent several hours chasing down why some code I have didn't
  Shane> work.

  Eric> But now your code is presumably more correct, in that it will
  Eric> always locate the desired frame even when some future version
  Eric> of XEmacs or the not-XEmacs-Emacs changes the way `frame-list'
  Eric> is constructed.

Unfortunately not yet.  There's no easy way to get the "last frame
created" without saving it in a variable somewhere, and I don't have
time to do the re-write to make it "correct"

-- 
Shane Holder                                 e-mail: holder@rsn.hp.com
Hewlett Packard                               phone:     (214)497-4182
3000 Waterview                       Never underestimate the bandwidth
Richardson, TX 75083                 of a truck moving at 70 MPH.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 13:03:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA10206 for xemacs-beta-people; Mon, 16 Sep 1996 13:03:14 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA10203 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 13:03:11 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA14604 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 13:03:07 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa23416;
          16 Sep 96 13:54 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id NAA13535; Mon, 16 Sep 1996 13:52:16 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4 (Bouncing Bass Player Edition))
	id NAA05382; Mon, 16 Sep 1996 13:52:16 -0400
Date: Mon, 16 Sep 1996 13:52:16 -0400
Message-Id: <199609161752.NAA05382@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: Bill Dubuque <wgd@martigny.ai.mit.edu>
Cc: steve@miranova.com, xemacs-beta@xemacs.org
Subject: Re: Lisp Mode font locking bug report Emacs 19.34, XEmacs 19.14 & 19.15
References: <199609150236.TAA10602@deanna.miranova.com>
	<199609151428.AA289417687@martigny.ai.mit.edu>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: A very small object. Its center
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "BD" == Bill Dubuque <wgd@martigny.ai.mit.edu> writes:

    BD> Most likely this is due to the '(' in column 0 in your comment
    BD> string. Recall the convention in lisp modes that a '(' in
    BD> column 0 is used to anchor toplevel syntax (e.g. by
    BD> beginning-of-defun).

Not just lisp modes.  I think all language modes assume this for any
character with open-paren syntax in column zero.  Its especially bogus
for languages like Python which don't use such bracing structures!

-Barry

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 12:43:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA10146 for xemacs-beta-people; Mon, 16 Sep 1996 12:43:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA10143 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 12:43:57 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA14232 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 12:43:52 -0500 (CDT)
Received: from kramer.aventail.com (root@newman [192.168.1.1]) by newman (8.6.12/8.6.9) with SMTP id KAA06996; Mon, 16 Sep 1996 10:41:47 -0700
Date: Mon, 16 Sep 1996 10:41:47 -0700
Message-Id: <199609161741.KAA06996@newman>
From: William Perry <wmperry@aventail.com>
To: Shane Holder <holder@mordor.rsn.hp.com>
Cc: eeide@jaguar.cs.utah.edu (Eric Eide), xemacs-beta@xemacs.org
Subject: Re: (frame-list) seems to be wrong.
In-Reply-To: <fawohj6mn2v.fsf@mordor.rsn.hp.com>
References: <199609161519.JAA06857@jaguar.cs.utah.edu>
	<fawohj6mn2v.fsf@mordor.rsn.hp.com>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Shane Holder writes:
>>>>>> "Eric" == Eric Eide <eeide@jaguar.cs.utah.edu> writes:
>
>  Eric> Shane Holder <holder@mordor.rsn.hp.com> writes:
>  Shane> It seems wrong to place newly created frames (or anything else)
>  Shane> on the "END" of a list.  Is there a reason for this?
>
>  Eric> Perhaps the list is constructed from some other data structure
>  Eric> on request (e.g., a hash table) and your new frame just
>  Eric> happens to end up at the end?  Or perhaps the internal list is
>  Eric> duplicated in a way that effectively reverses the list?  I
>  Eric> don't know; I haven't looked; but both are reasonable,
>  Eric> possible explanations.
>
>  Eric> I would say that unless the behavior is documented (i.e., the
>  Eric> the newly created frame is always prepended to the list), it
>  Eric> is incorrect for code to assume a particular behavior.  Is the
>  Eric> behavior documented in GNU Emacs by the FSF?
>
>>From the lispref info file:
>
>frame-list:
>
>     The function `frame-list' returns a list of all the frames that
>     have not been deleted.  It is analogous to `buffer-list' for
>     buffers.  The list that you get is newly created, so modifying the
>     list doesn't have any effect on the internals of XEmacs.
>
>buffer-list:
>
>   The "buffer list" is a list of all live buffers.  Creating a buffer
>adds it to this list, and killing a buffer deletes it.  The order of
>the buffers in the list is based primarily on how recently each buffer
>has been displayed in the selected window.  Buffers move to the front
>of the list when they are selected and to the end when they are buried.
>Several functions, notably `other-buffer', use this ordering.  A
>buffer list displayed for the user also follows this order.

  So even if you followed the behaviour of buffer-list, you would not get
the most recently created frame at the front, but the most recently
displayed frame.  Gack.

>  Shane> Emacs puts new frames on the beginning of the list, and I just
>  Shane> spent several hours chasing down why some code I have didn't
>  Shane> work.
>
>  Eric> But now your code is presumably more correct, in that it will
>  Eric> always locate the desired frame even when some future version
>  Eric> of XEmacs or the not-XEmacs-Emacs changes the way `frame-list'
>  Eric> is constructed.
>
>Unfortunately not yet.  There's no easy way to get the "last frame
>created" without saving it in a variable somewhere, and I don't have
>time to do the re-write to make it "correct"

(add-hook 'create-frame-hook (lambda (x) (setq newest-frame x)))

M-x query-replace [ret] (car (frame-list))[ret] newest-frame

:)

-Bill P.


From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 14:25:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA10521 for xemacs-beta-people; Mon, 16 Sep 1996 14:25:15 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA10518 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 14:25:14 -0500 (CDT)
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA14962 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 14:25:10 -0500 (CDT)
Received: from mordor.rsn.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA159451364; Mon, 16 Sep 1996 12:16:04 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id OAA23018; Mon, 16 Sep 1996 14:20:54 -0500 (CDT)
To: wmperry@aventail.com
Cc: Shane Holder <holder@mordor.rsn.hp.com>,
        eeide@jaguar.cs.utah.edu (Eric Eide), xemacs-beta@xemacs.org
Subject: Re: (frame-list) seems to be wrong.
References: <199609161519.JAA06857@jaguar.cs.utah.edu> 	<fawohj6mn2v.fsf@mordor.rsn.hp.com> <199609161741.KAA06996@newman>
From: Shane Holder <holder@mordor.rsn.hp.com>
Date: 16 Sep 1996 14:20:54 -0500
In-Reply-To: William Perry's message of Mon, 16 Sep 1996 10:41:47 -0700
Message-Id: <fawk9tumfl5.fsf@mordor.rsn.hp.com>
Lines: 50
X-Mailer: Red Gnus v0.34/XEmacs 19.15

>>>>> "Bill" == William Perry <wmperry@aventail.com> writes:

  Bill> Shane Holder writes:
  >>>>>>> "Eric" == Eric Eide <eeide@jaguar.cs.utah.edu> writes:

  Eric> Shane Holder <holder@mordor.rsn.hp.com> writes:

  >>> From the lispref info file:

  >> frame-list:

  >> The function `frame-list' returns a list of all the frames that
  >> have not been deleted.  It is analogous to `buffer-list' for
  >> buffers.  The list that you get is newly created, so modifying the
  >> list doesn't have any effect on the internals of XEmacs.

  >> buffer-list:

  >> The "buffer list" is a list of all live buffers.  Creating a buffer
  >> adds it to this list, and killing a buffer deletes it.  The order of
  >> the buffers in the list is based primarily on how recently each buffer
  >> has been displayed in the selected window.  Buffers move to the front
  >> of the list when they are selected and to the end when they are buried.
  >> Several functions, notably `other-buffer', use this ordering.  A
  >> buffer list displayed for the user also follows this order.

  Bill> So even if you followed the behaviour of buffer-list, you
  Bill> would not get the most recently created frame at the front,
  Bill> but the most recently displayed frame.  Gack.

Correct, but it should only be a problem if emacs ever goes multi
threaded.  There's not much chance that the frame list will get
changed out from under my code (i don't think), so if I do a
(make-frame) I should be able to rely on it's position in the list.

  >> Unfortunately not yet.  There's no easy way to get the "last frame
  >> created" without saving it in a variable somewhere, and I don't have
  >> time to do the re-write to make it "correct"

  Bill> (add-hook 'create-frame-hook (lambda (x) (setq newest-frame x)))

  Bill> M-x query-replace [ret] (car (frame-list))[ret] newest-frame

Ooh, I like that, I'll have to give it a shot.  Thanks.

-- 
Shane Holder                                 e-mail: holder@rsn.hp.com
Hewlett Packard                               phone:     (214)497-4182
3000 Waterview                       Never underestimate the bandwidth
Richardson, TX 75083                 of a truck moving at 70 MPH.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 14:38:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA10544 for xemacs-beta-people; Mon, 16 Sep 1996 14:38:38 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA10541 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 14:38:37 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA23837 for <xemacs-beta@cs.uiuc.edu>; Mon, 16 Sep 1996 14:38:35 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id MAA28449; Mon, 16 Sep 1996 12:42:03 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Showing keybindings at completion time (Patch to icomplete.el)
References: <kigvidfhi40.fsf@jagor.srce.hr> 	<m2d8znz5ls.fsf@deanna.miranova.com> <kigpw3msrmm.fsf@jagor.srce.hr>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Hrvoje Niksic's message of 16 Sep 1996 12:04:17 +0200
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 16 Sep 1996 12:42:01 -0700
Message-ID: <m2sp8ifdrq.fsf@deanna.miranova.com>
Lines: 28
X-Mailer: Red Gnus v0.35/XEmacs 19.15

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrvoje> I have tried the vanilla icomplete.el without the patch, but I
Hrvoje> don't like its "normal" behaviour (printing messages in the
Hrvoje> minibuffer). Can I turn them off and retain *only* the
Hrvoje> minibuffer suggestions? Is there a chance of the patch being
Hrvoje> included to 19.15 as default instead of
Hrvoje> teach-extended-commands?

You mean, turn off the completion help stuff, and put in only the
matching keybinding?  That can be arranged.  How about a flag and a
toggle command?

The completion help is worse than useless in the case of matching
buffer names for a switch buffer, since a common initial substring of
an existing buffer name can be used to create a new buffer and
*doesn't* match the longer existing buffer name. :-( Similar bad
behavior also exists when minibuffer-confirm-incomplete is t.

There's also a real bug in it that's activated with certain Gnus
prompts -- the prefix offered by Gnus is ignored, and GNU Emacs 19.34
gets it right.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 16:13:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA10764 for xemacs-beta-people; Mon, 16 Sep 1996 16:13:01 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA10761 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 16:13:00 -0500 (CDT)
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA26423 for <xemacs-beta@cs.uiuc.edu>; Mon, 16 Sep 1996 16:12:59 -0500 (CDT)
Received: (qmail 1346 invoked by uid 1000); 16 Sep 1996 21:13:35 -0000
To: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Subject: Re: Showing keybindings at completion time (Patch to icomplete.el)
References: <kigvidfhi40.fsf@jagor.srce.hr> 	<m2d8znz5ls.fsf@deanna.miranova.com> <kigpw3msrmm.fsf@jagor.srce.hr> <m2sp8ifdrq.fsf@deanna.miranova.com>
From: Sudish Joseph <sj@atreides.mindspring.com>
In-Reply-To: Steven L Baur's message of 16 Sep 1996 12:42:01 -0700
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 16 Sep 1996 17:13:34 -0400
Message-ID: <87n2yqi2o1.fsf@atreides.mindspring.com>
Lines: 37
X-Mailer: Red Gnus v0.32/XEmacs 19.15

Steven L Baur <steve@miranova.com> writes:
> There's also a real bug in it that's activated with certain Gnus
> prompts -- the prefix offered by Gnus is ignored, and GNU Emacs 19.34
> gets it right.

This is a general problem with the interaction between completing-read
and icomplete.  Here's the bug report I posted to comp.emacs.xemacs
some time back.

-Sudish
(c'n'p'ed from dejanews)
--------------------------------------------------
Subject:      completing-read drops initial-contents
From:         Sudish Joseph <sudish@mindspring.com>
Date:         1996/08/17
Message-Id:   <m2ivahzdhd.fsf@atreides.erehwon.org>
Organization: MindSpring Enterprises
Newsgroups:   comp.emacs.xemacs


... when it's table arg is non-nil and icomplete-mode is active.  This
is highly irritating as you tend to type as if the initial-contents
were there.

To reproduce: xemacs -q then run this in scratch or from an Eval: prompt.
(completing-read "foo: " '(("bogus" "")) nil nil "bar")

Anything you type will have bar as a prefix. Now, M-x icomplete-mode
and repeat.  The initial-contents are dropped as soon as you touch a
key.

GNU Emacs leaves "bar" in there in both cases.

Does anyone have a fix/workaround?

-Sudish


From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 18:56:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA11092 for xemacs-beta-people; Mon, 16 Sep 1996 18:56:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA11089 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 18:56:12 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA25207 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 18:56:06 -0500 (CDT)
Message-Id: <199609162356.SAA25207@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.15 beta2
Date: Mon, 16 Sep 1996 18:56:03 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/beta/xemacs-19.15.  Next release is
beta3 out Monday, September 23.

tm is not in this release but it should be in the next one.  This is
mostly 19.34 syncing courtesy Steven Baur.  I now have only a little
over 100 messages left to go through.  It is pretty much now a case of
if it isn't in this beta and it isn't in the bug database, then I've
archived it for better or worse.  I'll be doing almost nothing but
performance testing for beta4 (not beta3) so save reports about
performance problems for a couple of weeks.


			-Chuck


-- fast-lock.el 3.10.01
-- ksh-mode.el 2.9
-- mode-motion+.el 3.16
-- psgml-1a12
-- executable.el, imenu.el, sh-script.el and uniquify.el now included
-- rfc1521 patches to VM from Jamie
-- OffiX support added
-- lots of 19.34 syncing, most by Steven Baur
-- NetBSD on sparc platform fixes
-- additional featurep checks on 'scrollbar and 'menubar
-- configure changes to allow sunos4shr args to be picked up correctly

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 19:10:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA11138 for xemacs-beta-people; Mon, 16 Sep 1996 19:10:22 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA11135 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 19:10:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA25421 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 19:10:17 -0500 (CDT)
Message-Id: <199609170010.TAA25421@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: XEmacs 20.0 beta29
Date: Mon, 16 Sep 1996 19:10:15 -0500
From: Chuck Thompson <cthomp@xemacs.org>

is now at ftp.xemacs.org:/pub/beta/xemacs-20.0.  Next release is
beta30 out Monday, September 23.


			-Chuck


-- fast-lock.el 3.10.01
-- ksh-mode.el 2.9
-- mode-motion+.el 3.16
-- psgml-1a12
-- executable.el, imenu.el, sh-script.el and uniquify.el now included
-- rfc1521 patches to VM from Jamie
-- OffiX support added
-- lots of 19.34 syncing, most by Steven Baur
-- NetBSD on sparc platform fixes
-- additional featurep checks on 'scrollbar and 'menubar
-- configure changes to allow sunos4shr args to be picked up correctly

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 19:55:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA11257 for xemacs-beta-people; Mon, 16 Sep 1996 19:55:50 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA11254 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 19:55:48 -0500 (CDT)
Received: from wayback.uoregon.edu (wayback.uoregon.edu [128.223.156.117]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA03620 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 19:55:42 -0500 (CDT)
Received: (from meyer@localhost) by wayback.uoregon.edu (8.7.5/8.7.1) id RAA02019; Mon, 16 Sep 1996 17:51:44 -0700 (PDT)
Date: Mon, 16 Sep 1996 17:51:44 -0700 (PDT)
Message-Id: <199609170051.RAA02019@wayback.uoregon.edu>
From: "David M. Meyer 541/346-1747" <meyer@network-services.uoregon.edu>
To: xemacs-beta@xemacs.org
Subject: 20.0-beta29 success on Solaris 2.5.1


	Configure with:

	./configure  --verbose --cflags="-O2" --with-gcc=yes
	--site-includes=/usr/dt/include
	--site-libraries=/usr/dt/lib
	--site-runtime-libraries=/usr/dt/lib
	--x-includes=/usr/openwin/include
	--x-libraries=/usr/openwin/lib --with-xpm 



	Dave

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 19:56:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA11262 for xemacs-beta-people; Mon, 16 Sep 1996 19:56:10 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA11259 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 19:56:09 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA03187 for <xemacs-beta@cs.uiuc.edu>; Mon, 16 Sep 1996 19:56:07 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id RAA01609; Mon, 16 Sep 1996 17:59:48 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Bug Report #151 lisp:utils pp.el needs some updating
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 16 Sep 1996 17:59:46 -0700
Message-ID: <m2zq2qdkhp.fsf@deanna.miranova.com>
Lines: 64
X-Mailer: Red Gnus v0.35/XEmacs 19.15

You can close this one with my sync-to-19.34 patch to pp.el, as it is
fixed for me.  :-) [I'm still downloading beta2]

C-h v modeline-format
modeline-format's value is ("" (#<extent [detached) help-echo keymap 0x82ea100 from no buffer> . modeline-modified) (#<extent [detached) 0x82ea0ac from no buffer> . modeline-buffer-identification) " " global-mode-string "   %[(" (#<extent [detached) keymap 0x82ea090 from no buffer> "" mode-name minor-mode-alist) (#<extent [detached) help-echo keymap 0x82ea11c from no buffer> . "%n") modeline-process ")%]----" (line-number-mode "L%l--") (-3 . "%p") "-%-")
  -- a built-in buffer-local variable.
This value is specific to the current buffer.
Its default-value is ("" (#<extent [detached) help-echo keymap 0x82ea100 from no buffer> . modeline-modified) (#<extent [detached) 0x82ea0ac from no buffer> . modeline-buffer-identification) "   " global-mode-string "   %[(" (#<extent [detached) keymap 0x82ea090 from no buffer> "" mode-name minor-mode-alist) (#<extent [detached) help-echo keymap 0x82ea11c from no buffer> . "%n") modeline-process ")%]----" (line-number-mode "L%l--") (-3 . "%p") "-%-")

Documentation:
Template for displaying modeline for current buffer.
Each buffer has its own value of this variable.
Value may be a string, a symbol or a list or cons cell.
For a symbol, its value is used (but it is ignored if t or nil).
 A string appearing directly as the value of a symbol is processed verbatim
 in that the %-constructs below are not recognized.
For a glyph, it is inserted as is.
For a list whose car is a symbol, the symbol's value is taken,
 and if that is non-nil, the cadr of the list is processed recursively.
 Otherwise, the caddr of the list (if there is one) is processed.
For a list whose car is a string or list, each element is processed
 recursively and the results are effectively concatenated.
For a list whose car is an integer, the cdr of the list is processed
  and padded (if the number is positive) or truncated (if negative)
  to the width specified by that number.
For a list whose car is an extent, the cdr of the list is processed
 normally but the results are displayed using the face of the
 extent, and mouse clicks over this section are processed using the
 keymap of the extent. (In addition, if the extent has a help-echo
 property, that string will be echoed when the mouse moves over this
 section.) See `generated-modeline-string' for more information.
For a list whose car is a face, the cdr of the list is processed
 normally but the results will be displayed using the face in the car.
For a list whose car is a keymap, the cdr of the list is processed
 normally but the keymap will apply for mouse clicks over the results,
 in addition to `modeline-map'.  Nested keymap specifications are
 handled properly.
A string is printed verbatim in the modeline except for %-constructs:
  (%-constructs are processed when the string is the entire modeline-format
   or when it is found in a cons-cell or a list)
  %b -- print buffer name.      %c -- print the current column number.
  %f -- print visited file name.
  %* -- print %, * or hyphen.   %+ -- print *, % or hyphen.
	% means buffer is read-only and * means it is modified.
	For a modified read-only buffer, %* gives % and %+ gives *.
  %s -- print process status.   %l -- print the current line number.
  %S -- print name of selected frame (only meaningful under X Windows).
  %p -- print percent of buffer above top of window, or Top, Bot or All.
  %P -- print percent of buffer above bottom of window, perhaps plus Top,
        or print Bottom or All.
  %n -- print Narrow if appropriate.
  %t -- Under MS-DOS, print T if files is text, B if binary.
  %[ -- print one [ for each recursive editing level.  %] similar.
  %% -- print %.                %- -- print infinitely many dashes.
Decimal digits after the % specify field width to which to pad.  */ );

  DEFVAR_BUFFER_DEFAULTS ("default-major-mode", major_mode /*
*Major mode for new buffers.  Defaults to `fundamental-mode'.
nil here means use current buffer's major mode.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 21:03:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA11490 for xemacs-beta-people; Mon, 16 Sep 1996 21:03:16 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA11487 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 21:03:15 -0500 (CDT)
Received: from big.aa.net (root@big.aa.net [204.157.220.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA04554 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 21:03:08 -0500 (CDT)
Received: from sym.primuscorp.com ([204.137.132.34]) by big.aa.net (8.7/8.7.5) with ESMTP id TAA09953 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 19:03:02 -0700
X-Intended-For: <xemacs-beta@xemacs.org>
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id TAA19103 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 19:03:21 -0700
Received: from roy by horus (SMI-8.6/SMI-SVR4)
	id TAA13757; Mon, 16 Sep 1996 19:02:56 -0700
Received: by roy (SMI-8.6/SMI-SVR4)
	id TAA11329; Mon, 16 Sep 1996 19:03:00 -0700
Date: Mon, 16 Sep 1996 19:03:00 -0700
Message-Id: <199609170203.TAA11329@roy>
From: Damon Lipparelli <lipp@primus.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 19.15-b2: success under Solaris 2.4
Reply-To: Damon Lipparelli <lipp@primus.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.15 (beta2) ]

./configure --verbose --with-gcc --with-gnu-make --site-includes=/usr/local/include --site-libraries=/usr/local/sun4/lib --prefix=/users/lipp/xemacs-beta/19.x --exec-prefix=/users/lipp/xemacs-beta/19.x/sun4 --with-dialogs=athena --with-menubars=lucid --with-scrollbars=lucid --with-xpm --with-xface --with-jpeg --with-gif --with-png --with-tooltalk --with-sparcworks --with-sound=none

Configured for `sparc-sun-solaris2.4'.

  Where should the build process find the source code?    /users/lipp/src/xemacs-beta/19.x/xemacs-19.15-b2
  What installation prefix should install use?            /users/lipp/xemacs-beta/19.x
  What operating system and machine description files should XEmacs use?
        `s/sol2-4.h' and `m/sparc.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/openwin/include
  Where do we find X Windows libraries?                   /usr/openwin/lib
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/sun4/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in support for SparcWorks.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

So far, looks great.
-lipp
---

YOW!!  What should the entire human race DO??  Consume a fifth
 of CHIVAS REGAL, ski NUDE down MT. EVEREST, and have a wild
 SEX WEEKEND!

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 21:17:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA11531 for xemacs-beta-people; Mon, 16 Sep 1996 21:17:12 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA11528 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 21:17:11 -0500 (CDT)
Received: from bayserve.net (bay1.bayserve.net [206.148.244.200]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA04584 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 21:17:08 -0500 (CDT)
Received: from localhost (jmiller@localhost) by  bayserve.net (8.7.2/8.7.2) with SMTP id WAA00698 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 22:20:46 -0400 (EDT)
Date: Mon, 16 Sep 1996 22:20:45 -0400 (EDT)
From: Jeff Miller <jmiller@bay1.bayserve.net>
To: xemacs-beta@xemacs.org
Subject: Success 19.15b2 on Linux 2.0.20
Message-ID: <Pine.SUN.3.95.960916221403.29597B-100000@bay1.bayserve.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

 
Slackware 3.1/Linux kernel 2.0.20

using beta1-beta2 patch.

Configured for `i486-unknown-linux2.0.20'.

  Where should the build process find the source code?
/mnt2/jmiller/source/x
emacs-19.15-b1
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?
/usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Additional header files:
/usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.




From xemacs-beta-request@cs.uiuc.edu  Mon Sep 16 22:19:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA11749 for xemacs-beta-people; Mon, 16 Sep 1996 22:19:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA11746 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 16 Sep 1996 22:19:55 -0500 (CDT)
Received: from wmperry.oz.net (wmperry@wmperry.oz.net [207.13.185.53]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA04746 for <xemacs-beta@xemacs.org>; Mon, 16 Sep 1996 22:19:39 -0500 (CDT)
Received: (from wmperry@localhost) by wmperry.oz.net (8.7.4/8.7.3) id UAA06260; Mon, 16 Sep 1996 20:29:02 -0700
Date: Mon, 16 Sep 1996 20:29:02 -0700
Message-Id: <199609170329.UAA06260@wmperry.oz.net>
From: William Perry <wmperry@aventail.com>
To: xemacs-beta@xemacs.org
Subject: Success: 20.0b29 on Linux 2.0.20
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

patched up from b28, w/the keyboard-menu-navigation patches.
GIF, PNG, XPM, JPEG libraries.

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 02:15:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA12176 for xemacs-beta-people; Tue, 17 Sep 1996 02:15:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA12173 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 02:15:39 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA12105 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 02:15:38 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id AAA09134; Tue, 17 Sep 1996 00:19:20 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Bug in ps-print.el [19.15-b2]
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Sep 1996 00:19:19 -0700
Message-ID: <m2loe9fw20.fsf@deanna.miranova.com>
Lines: 12
X-Mailer: Red Gnus v0.35/XEmacs 19.15

(This was pointed out to me Monday by Jacques Duthen Prestataire
<duthen@cegelec-red.fr>, the maintainer of ps-print)

Ps-print will happily feed evil control characters (of the type no
longer printed in the prolog in the current ps-print) to the laser
printer, killing certain versions of the LaserWriter.  I'll submit a
patch to fix this as soon as I can.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 02:15:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA12169 for xemacs-beta-people; Tue, 17 Sep 1996 02:15:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA12166 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 02:15:36 -0500 (CDT)
Received: from nukkekoti.cs.hut.fi (nukkekoti.cs.hut.fi [130.233.40.128]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA05010 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 02:15:33 -0500 (CDT)
Received: from torvi.cs.hut.fi (pema@torvi.cs.hut.fi [130.233.40.149]) by nukkekoti.cs.hut.fi (8.7.5/8.7.3) with ESMTP id KAA11339 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 10:15:32 +0300 (EET DST)
Received: (from pema@localhost) by torvi.cs.hut.fi (8.7.5/8.7.3) id KAA06787; Tue, 17 Sep 1996 10:15:31 +0300 (EETDST)
Sender: pema@niksula.hut.fi
To: xemacs-beta@xemacs.org
Subject: 19.15-b2 success on HP-UX 9.05
From: Pekka Marjola <pema@iki.fi>
X-Face: 8>EVnZ'MSz2dI{N`dzbBND,clpk$+(a>y[d"rnI,}HfS4x!)hp+1H&ha6Rj93tVlirvJ;Z@@MSpFN[;;X)aF\mDDlk6N&0t*B^C\]|<z,S8:j26ZbN:WmvgP-DV?l|'C<(|DacsbwYal'dmuMifMOXszyo]J:k{BSASbF-R
X-Attribution: PeMa
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Sep 1996 10:15:30 +0300
Message-ID: <k9wk9ttr4rx.fsf@torvi.cs.hut.fi>
Lines: 36
X-Mailer: Gnus v5.2.40/XEmacs 19.14


Compiled using b1-b2 patch.


Configured for `hppa1.1-hp-hpux9.05'.

  Where should the build process find the source code?    /tmp_mnt/net/frodo/sha
re/contrib/src/xemacs-19.15-b2
  What installation prefix should install use?            /net/share/contrib
  What operating system and machine description files should XEmacs use?
        `s/hpux9shr.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              gcc -g -O2
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/include/X11R5
  Where do we find X Windows libraries?                   /usr/lib/X11R5
  Additional header files:                                /net/share/contrib/inc
lude /usr/local/include
  Additional libraries:                                   /net/share/contrib/lib
 /usr/local/lib
  Compiling in support for XPM.
  No Xmu; substituting equivalent routines.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

-- 
Pekka Marjola * pema@iki.fi * http://www.iki.fi/pema/ * +358-40-551 4842
PGP: 0x2865206D/C46E6452206FDB42A87D44F4E0E54E65 * GCS U+++$ L+++ E++...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Quidquid latine dictum sit, altum viditur.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 02:11:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA12146 for xemacs-beta-people; Tue, 17 Sep 1996 02:11:31 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA12143 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 02:11:30 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA12096 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 02:11:28 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id AAA09104; Tue, 17 Sep 1996 00:15:04 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [19.15-b2] Success - Linux 2.0.18
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Sep 1996 00:15:03 -0700
Message-ID: <m2ohj5fw94.fsf@deanna.miranova.com>
Lines: 39
X-Mailer: Red Gnus v0.35/XEmacs 19.15

"XEmacs 19.15 [Lucid] (i486-unknown-linux2.0.18) of Mon Sep 16 1996 on deanna.miranova.com"
emacs-version
"19.15 XEmacs Lucid (beta2)"

Configured for `i486-unknown-linux2.0.18'.

  Where should the build process find the source code?    /i/xemacs-19.15-b2
  What installation prefix should install use?            ${srcdir}
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in support for OffiX.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.


Everything looks O.K. so far.  I can't wait to try out OffiX drag &
drop. :-)
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 02:24:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA12194 for xemacs-beta-people; Tue, 17 Sep 1996 02:24:13 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA12191 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 02:24:12 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA12123 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 02:24:10 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id AAA09205; Tue, 17 Sep 1996 00:27:52 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: PATCH: Bug in icomplete.el [19.15-b2]
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Sep 1996 00:27:50 -0700
Message-ID: <m2iv9dfvnt.fsf@deanna.miranova.com>
Lines: 30
X-Mailer: Red Gnus v0.35/XEmacs 19.15

This last minute fix didn't make it in time.  The keybinding patch
should only print out keybinding status when it is completing a
command, but I botched the test. :-(

*** packages/icomplete.el~	Mon Sep 16 12:39:14 1996
--- packages/icomplete.el	Sun Sep 15 20:57:35 1996
***************
*** 273,279 ****
  		   " [Matched]"
  	   ;; XEmacs
  		   (if (and icomplete-show-key-bindings
! 			    (commandp (car comps)))
  		       (icomplete-get-keys (car comps))
  		     "")
  		   ))
--- 273,279 ----
  		   " [Matched]"
  	   ;; XEmacs
  		   (if (and icomplete-show-key-bindings
! 			    (commandp (intern-soft (car comps))))
  		       (icomplete-get-keys (car comps))
  		     "")
  		   ))


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 05:03:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA16037 for xemacs-beta-people; Tue, 17 Sep 1996 05:03:17 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA16034 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 05:03:16 -0500 (CDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id FAA05366 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 05:03:10 -0500 (CDT)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA13642; Tue, 17 Sep 1996 02:57:11 -0700
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA10715; Tue, 17 Sep 1996 11:56:47 +0200
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/05Aug96-0532PM)
	id AA08707; Tue, 17 Sep 1996 11:56:38 +0200
Date: Tue, 17 Sep 1996 11:56:38 +0200
Message-Id: <9609170956.AA08707@fornet.gvc.dec.com>
From: Stephen Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: XEmacs 19.15-b2 build success on Digital UNIX V3.2D
Reply-To: carney@gvc.dec.com
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: text/plain; charset=US-ASCII
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

Hardware  : DEC 3000-500
OS        : Digital UNIX V3.2D (41)
Compiler  : gcc-2.7.2
Libraries : X11R5, Motif
XEmacs    : 19.15-b2 (full kit)

Configured for `alpha-dec-osf3.2'.
  Where should the build process find the source code?    /kits/install/xemacs/xemacs-19.15-b2
  What installation prefix should install use?            /usr/local/xemacs-beta
  What operating system and machine description files should XEmacs use?
        `s/decosf3-2.h' and `m/alpha.h'
  What compiler should XEmacs be built with?              gcc -g2 -O3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? no
  What window system should XEmacs use?                   x11
  Additional header files:                                /kits/install/jpegsrc/release /usr/local/i
nclude
  Additional libraries:                                   /kits/install/jpegsrc/release /usr/local/l
ib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Motif scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Carney        TEL:[41](22)782.90.60  http://www-digital.cern.ch/carney/
carney@gvc.dec.com  FAX:[41](22)782.94.92 

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 09:40:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA16746 for xemacs-beta-people; Tue, 17 Sep 1996 09:40:07 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA16743 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 09:40:06 -0500 (CDT)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA22255 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 09:40:03 -0500 (CDT)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id PAA29061; Tue, 17 Sep 1996 15:39:43 +0100
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id PAA01385; Tue, 17 Sep 1996 15:41:38 +0100 (BST)
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id PAA27747; Tue, 17 Sep 1996 15:46:05 +0100
Date: Tue, 17 Sep 1996 15:46:05 +0100
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199609171446.PAA27747@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu, neal@ctd.comsat.com
Subject: Re: 19.15b2 patchup failure
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: CGef4//cPR7JCYjbDcC2qg==

I see this as well on solaris 2.4

andy

> 19.15b2 hpux9.05 patchup from b1:
> 
> 2 problems:
> 
> make all-elc:
> [...]
> [PROBLEM #1]
> Loading hm--html-keys...
> While compiling toplevel forms in file 
/u2/src/xemacs-19.15-b2/lisp/hm--html-menus/hm--html-mode.el:
>   !! Symbol's value as variable is void ((hm--html-mode-prefix-key))
> [...]
> [PROBLEM #2]
> -n Compiling VM...
> make[1]: Entering directory `/u2/src/xemacs-19.15-b2/lisp/vm'
> scanning sources to build autoload definitions...
> /bin/sh: vm-autoload.el: cannot create
> make[1]: *** [vm-autoload.elc] Error 1
> make[1]: Leaving directory `/u2/src/xemacs-19.15-b2/lisp/vm'
> make: *** [all-elc] Error 2
> 

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 09:05:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA16595 for xemacs-beta-people; Tue, 17 Sep 1996 09:05:22 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA16592 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 09:05:21 -0500 (CDT)
Received: from chekov.ctd.comsat.com (exim@chekov.ctd.comsat.com [134.133.40.22]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA21595 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 09:05:20 -0500 (CDT)
Received: from neal by chekov.ctd.comsat.com with local (Exim 0.56 #3)
	id E0v30m6-0006LW-00; Tue, 17 Sep 1996 10:05:18 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: 19.15b2 patchup failure
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0v30m6-0006LW-00@chekov.ctd.comsat.com>
Date: Tue, 17 Sep 1996 10:05:18 -0400

19.15b2 hpux9.05 patchup from b1:

2 problems:

make all-elc:
[...]
[PROBLEM #1]
Loading hm--html-keys...
While compiling toplevel forms in file /u2/src/xemacs-19.15-b2/lisp/hm--html-menus/hm--html-mode.el:
  !! Symbol's value as variable is void ((hm--html-mode-prefix-key))
[...]
[PROBLEM #2]
-n Compiling VM...
make[1]: Entering directory `/u2/src/xemacs-19.15-b2/lisp/vm'
scanning sources to build autoload definitions...
/bin/sh: vm-autoload.el: cannot create
make[1]: *** [vm-autoload.elc] Error 1
make[1]: Leaving directory `/u2/src/xemacs-19.15-b2/lisp/vm'
make: *** [all-elc] Error 2

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 10:19:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA16915 for xemacs-beta-people; Tue, 17 Sep 1996 10:19:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA16912 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 10:19:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA23478 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 10:19:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA10511; Tue, 17 Sep 1996 10:08:54 -0500 (CDT)
Message-Id: <199609171508.KAA10511@xemacs.cs.uiuc.edu>
To: Neal Becker <neal@ctd.comsat.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.15b2 patchup failure 
In-reply-to: Your message of "Tue, 17 Sep 1996 10:05:18 EDT."
             <E0v30m6-0006LW-00@chekov.ctd.comsat.com> 
Date: Tue, 17 Sep 1996 10:08:52 -0500
From: Chuck Thompson <cthomp@xemacs.org>

    Neal> make all-elc:
    Neal> [...]
    Neal> [PROBLEM #1]
    Neal> Loading hm--html-keys...
    Neal> While compiling toplevel forms in file /u2/src/xemacs-19.15-b2/lisp/hm--html-menus/hm--html-mode.el:
    Neal>   !! Symbol's value as variable is void ((hm--html-mode-prefix-key))
    Neal> [...]

Remove all of the .elc files in hm--html-menus and recompile.  I
definitely fixed this bug (unless I did it in the wrong workspace).


    Neal> [PROBLEM #2]
    Neal> -n Compiling VM...
    Neal> make[1]: Entering directory `/u2/src/xemacs-19.15-b2/lisp/vm'
    Neal> scanning sources to build autoload definitions...
    Neal> /bin/sh: vm-autoload.el: cannot create
    Neal> make[1]: *** [vm-autoload.elc] Error 1
    Neal> make[1]: Leaving directory `/u2/src/xemacs-19.15-b2/lisp/vm'
    Neal> make: *** [all-elc] Error 2

Try chmod 644 lisp/vm/vm-autoload.el



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 09:03:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id JAA16584 for xemacs-beta-people; Tue, 17 Sep 1996 09:03:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id JAA16581 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 09:03:37 -0500 (CDT)
Received: from gatekeeper.abs.alcatel.co.uk (firewall-user@gatekeeper.abs.alcatel.co.uk [194.34.58.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id JAA05829 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 09:03:33 -0500 (CDT)
Received: from unknown(194.36.210.121) by gatekeeper.abs.alcatel.co.uk via smap (g3.0.3)
	id xma007907; Tue, 17 Sep 96 14:53:56 +0100
Received: from ariel.uk.abs by rd.abs.alcatel.co.uk  (4.1/SMI-4.1)
	id AA21935; Tue, 17 Sep 96 15:00:25 BST
Received: by ariel.uk.abs (SMI-8.6/SMI-SVR4)
	id PAA08533; Tue, 17 Sep 1996 15:00:23 +0100
Date: Tue, 17 Sep 1996 15:00:23 +0100
Message-Id: <199609171400.PAA08533@ariel.uk.abs>
From: Ian MacKinnon <imac@rd.abs.alcatel.co.uk>
To: xemacs-beta@xemacs.org
Subject: 19.15b2 OK

Patched up from b1, then added the patch for menu accelerations all OK


./configure  --site-libraries=/home/imac/lib --site-includes=/home/imac/includ
e --with-sound=both --native-sound-lib=/usr/demo/SOUND/lib/libaudio.a
On Sun Sparc 2.5


Ian

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 12:19:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA17261 for xemacs-beta-people; Tue, 17 Sep 1996 12:19:56 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA17258 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 12:19:54 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA25763 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 12:18:55 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA12707; Tue, 17 Sep 1996 10:21:25 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.15b2 patchup failure
References: <E0v30m6-0006LW-00@chekov.ctd.comsat.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Neal Becker's message of Tue, 17 Sep 1996 10:05:18 -0400
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Sep 1996 10:21:24 -0700
Message-ID: <m2loe9ys4r.fsf@deanna.miranova.com>
Lines: 18
X-Mailer: Red Gnus v0.35/XEmacs 19.15

>>>>> "Neal" == Neal Becker <neal@ctd.comsat.com> writes:

Neal> 19.15b2 hpux9.05 patchup from b1:
Neal> 2 problems:

Neal> make all-elc:
Neal> [...]
Neal> [PROBLEM #1]
Neal> Loading hm--html-keys...
Neal> While compiling toplevel forms in file /u2/src/xemacs-19.15-b2/lisp/hm--html-menus/hm--html-mode.el:
Neal>   !! Symbol's value as variable is void ((hm--html-mode-prefix-key))

This was present in beta1 as well, so nothing has really changed.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 12:16:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA17243 for xemacs-beta-people; Tue, 17 Sep 1996 12:16:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA17239 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 12:16:01 -0500 (CDT)
Received: from ns1.eds.com (ns1.eds.com [192.85.154.78]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA10816 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 12:15:57 -0500 (CDT)
Received: from nnsa.eds.com (nnsa.eds.com [130.174.31.78]) by ns1.eds.com (8.7.5/8.7.3) with ESMTP id LAA03042 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 11:30:17 -0400 (EDT)
Received: from kocrsv04.delcoelect.com (kocrsv04.delcoelect.com [144.250.100.205]) by nnsa.eds.com (8.7.5/8.7.3) with ESMTP id LAA02802 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 11:30:17 -0400 (EDT)
Received: from kocrsw12.delcoelect.com (kocrsw12.delcoelect.com [144.250.106.18]) by kocrsv04.delcoelect.com (8.7.5/8.7.3) with SMTP id KAA27862 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 10:30:15 -0500 (EST)
Received: from kocrsw12 by kocrsw12.delcoelect.com (SMI-8.6/SMI-SVR4)
	id KAA09061; Tue, 17 Sep 1996 10:30:12 -0500
X-Mailer: exmh version 1.6.6 3/24/96
To: xemacs-beta@xemacs.org
Subject: Question about DOC* files
X-Face: 4tk3bJx]I+QTZ|=]*1+Z){9+;5u_hK*NBeZK6[+B+iB%bVuOJ%^uK~fIG}O-}%WLX*D^aW>
 Gv8E3Xtz0\N&fQl^:pj<K{xM`:d>pPt:9lF-YXB%O)?@rd?*/jE!s94`?]:jJ#C5RDP:;Mr.3lwo`0
 {vIT+<{%IRwe]vLd]7>\X|*z{TUX_t;?TPcOLBMIv8_V92!Vk(*DJVU~0M[`5D^PAWLniO1?YYWArM
 U*j9o+>?1MWi.lO?F-?aVt:qQ8OaG?R}B:I!7S_+KuzxZ.f9M@$z#n\bG2$Q2{od
Date: Tue, 17 Sep 1996 10:30:12 -0500
Message-ID: <9059.842974212@kocrsw12>
From: Mike Scheidler <c23mts@eng.delcoelect.com>

Here's something I've always found strange, but never really questioned
until now.  Why are there two separate DOC files in the lib-src directory?
>From all I've seen they're always identical, and each is about 1.2 meg in
size. I could maybe understand having one as a hard link to the other to
allow them to be referenced under different names, but the current setup
just doesn't make much sense to me.

Does anybody have an explanation?  Is this something that could/should be
changed to save some disk space?

--
Mike Scheidler                     INTERNET:  c23mts@eng.delcoelect.com
Software Development Tools         UUCP:      deaes!c23mts
Delco Electronics Corporation      PHONE:     (317) 451-0319
Kokomo, IN 46904-9005              GMNET:     8-322-0319



From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 12:04:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA17175 for xemacs-beta-people; Tue, 17 Sep 1996 12:04:10 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA17169 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 12:04:05 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id MAA25270 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 12:04:02 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id LAA03371; Tue, 17 Sep 1996 11:19:58 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp003353; Tue Sep 17 11:19:14 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA10282; Tue, 17 Sep 96 11:19:13 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA05054; Tue, 17 Sep 96 11:19:12 EDT
Message-Id: <9609171519.AA05054@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: Ignorance is our most important resource.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>, xemacs-beta@cs.uiuc.edu
Subject: Re: 19.14b25 OK on Solaris 
In-Reply-To: Your message of "Thu, 12 Sep 1996 18:54:06 PDT."
             <199609130154.SAA22631@xemacs.eng.sun.com> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMj7BaFtTztlqB385AQE9pwQArqL+YrG69UXgn9NJcyXiO73y0hZI2muk
	      JQx9ZAr9X+IwL3Rzfm/AA4uk44f//eJWRY0wwlokQUB9kAJAtf9419UBkH3iLMwM
	      w/s6HiYFV92vv+hCuHH2vZrAFf8aI1ZModgGAkAuc9KaF+36FT+wHOx/cVbxzlgS
	      ZXGEsJovNXI=
	      =lUr+
Date: Tue, 17 Sep 1996 11:19:10 -0400
Sender: rickc@lehman.com

    Date: Thu, 12 Sep 1996 18:54:06 -0700
    From: Martin Buchholz <mrb@eng.sun.com>
    
    Martin> I've used shell buffers named `shell-1', `shell-2',
    Martin> etc. for years.  I think this ought to be the default
    Martin> behaviour, i.e. one should never have to manually rename a
    Martin> shell-buffer to get a new one.

I've used the attached function for some time.  It "*shell*" for the
buffer name and follows the standard convention for handling
collisions, i. e. the second one is called "*shell*<2>".

			Rick

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

(defun rick:new-shell ()
  (interactive)
  (let ((existing-shell-buffer (get-buffer "*shell*")))
    (cond (existing-shell-buffer
	   (set-buffer existing-shell-buffer)
	   (rename-uniquely)
	   (let ((new-name (buffer-name existing-shell-buffer)))
	     (shell)
	     (let ((new-buffer (get-buffer "*shell*")))
	       (set-buffer new-buffer)
	       (rename-uniquely)
	       (let ((temporary-name (buffer-name new-buffer)))
		 (set-buffer existing-shell-buffer)
		 (rename-buffer "*shell*" nil)
		 (set-buffer new-buffer)
		 (rename-buffer new-name))
	       (switch-to-buffer new-buffer))))
	  (t (shell)))))

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 13:01:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA17439 for xemacs-beta-people; Tue, 17 Sep 1996 13:01:27 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA17436 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 13:01:26 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA29904 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 13:01:25 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA13564; Tue, 17 Sep 1996 11:05:07 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: PATCH: [19.15-b2] Mouse button2 click in *apropos* buffer is broken
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Sep 1996 11:05:05 -0700
Message-ID: <m2iv9dyq3y.fsf@deanna.miranova.com>
Lines: 27
X-Mailer: Red Gnus v0.35/XEmacs 19.15

(My fault in synching to 19.34, sorry).

*** packages/apropos.el~	Sun Sep 15 11:32:01 1996
--- packages/apropos.el	Tue Sep 17 10:58:56 1996
***************
*** 94,100 ****
    (let ((map (make-sparse-keymap)))
      (define-key map [(control m)] 'apropos-follow)
      (define-key map [(button2up)] 'apropos-mouse-follow)
!     (define-key map [(button2down)] 'undefined)
      map)
    "Keymap used in Apropos mode.")
  
--- 94,100 ----
    (let ((map (make-sparse-keymap)))
      (define-key map [(control m)] 'apropos-follow)
      (define-key map [(button2up)] 'apropos-mouse-follow)
!     (define-key map [(button2)] 'undefined)
      map)
    "Keymap used in Apropos mode.")
  

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 13:23:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA17545 for xemacs-beta-people; Tue, 17 Sep 1996 13:23:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA17542 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 13:23:23 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA01658 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 13:23:20 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id LAA13915; Tue, 17 Sep 1996 11:26:41 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.15b2 patchup failure
References: <199609171508.KAA10511@xemacs.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Tue, 17 Sep 1996 10:08:52 -0500
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Sep 1996 11:26:40 -0700
Message-ID: <m2sp8hxajj.fsf@deanna.miranova.com>
Lines: 28
X-Mailer: Red Gnus v0.35/XEmacs 19.15

[NOTE:  I downloaded the full distribution]
>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

Neal> make all-elc:
Neal> [...]
Neal> [PROBLEM #1]
Neal> Loading hm--html-keys...
Neal> While compiling toplevel forms in file /u2/src/xemacs-19.15-b2/lisp/hm--html-menus/hm--html-mode.el:
Neal> !! Symbol's value as variable is void ((hm--html-mode-prefix-key))
Neal> [...]

Chuck> Remove all of the .elc files in hm--html-menus and recompile.
Chuck> I definitely fixed this bug (unless I did it in the wrong
Chuck> workspace).

I did and ...
Compiling /i/xemacs-19.15-b2/lisp/hm--html-menus/html-view.el...
Loading cl-macs...
Loading hm--html...
While compiling toplevel forms in file /i/xemacs-19.15-b2/lisp/hm--html-menus/html-view.el:
  !! Symbol's function definition is void ((adapt-emacs19p))
Done

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 14:31:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA17978 for xemacs-beta-people; Tue, 17 Sep 1996 14:31:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA17975 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 14:31:22 -0500 (CDT)
Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA11202 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 14:31:13 -0500 (CDT)
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id PAA17854; Tue, 17 Sep 1996 15:30:27 -0400
Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3)
	id tmp017799; Tue Sep 17 15:29:16 1996
Received: from cfdevx1.lehman.com by relay.lehman.com (4.1/LB-0.6)
	id AA02037; Tue, 17 Sep 96 15:29:13 EDT
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA13943; Tue, 17 Sep 96 15:29:12 EDT
Message-Id: <9609171929.AA13943@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Windows: More than enough rope.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Richard Stallman <rms@gnu.ai.mit.edu>
Cc: wing@666.com, xemacs-beta@xemacs.org
Subject: Re: Inflammatory doesn't just mean someone takes offense 
In-Reply-To: Your message of "Fri, 13 Sep 1996 05:05:07 EDT."
             <199609130905.FAA29370@ethanol.gnu.ai.mit.edu> 
X-Pgp-Version: 2.6.2
X-Pgp-Signed: iQCVAwUBMj7781tTztlqB385AQHutgQAum/Loy7fTC1i46VRwuQWjPPEjbK/UpSa
	      ZWM85Gy8N5CcCrP83s7LLaUx/TU78cDfMwdfkwRcPNZWo/mNYtzGL+BDP0jHbGcP
	      Y9rJdwPNeOtKpRgDGhW5P2FsFm3cFs0Wd9QL0mTpdDZk9doMAshWRaUbMRw8PD+2
	      DJl75mhcVkw=
	      =eeNJ
Date: Tue, 17 Sep 1996 15:28:56 -0400
Sender: rickc@lehman.com

Recently we saw:

    Date: Fri, 13 Sep 1996 05:05:07 -0400
    From: Richard Stallman <rms@gnu.ai.mit.edu>

    I focused on practical problems and solutions, not on criticizing
    any person.

Whereas, earlier we saw:

    From: rms@gnu.ai.mit.edu (Richard Stallman)
    Date: Thu, 29 Aug 1996 17:07:39 -0400

    XEmacs arose as a separate forked version because some of the
    developers--starting with Zawinski--were unwilling to do that.

Neither are fully accurate.

			Rick

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 14:17:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA17884 for xemacs-beta-people; Tue, 17 Sep 1996 14:17:36 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA17881 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 14:17:35 -0500 (CDT)
Received: from bnr.ca (x400gate.nortel.ca [192.58.194.73]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA11183 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 14:17:29 -0500 (CDT)
Received: from bcarsfbb by bnr.ca id <19960917191706-0@bnr.ca>; Tue, 17 Sep 1996 15:17:08 -0400 
Received: from nquah6f (actually nquah6f.ott.bnr.ca) by bcarsfbb.ott.bnr.ca; Tue, 17 Sep 1996 15:13:15 -0400 
Received: by nquah6f 
	(1.38.193.4/16.2 BNR V4.2 P1) id AA28357; Tue, 17 Sep 1996 15:10:04 -0400 
From: "barry (b.l.) friedman" <friedman@nortel.ca>
Message-Id: <9609171910.AA28357@nquah6f> 
Subject: W3 problem in 19.15 
To: xemacs-beta@xemacs.org
Date: Tue, 17 Sep 1996 15:10:04 -0400 (EDT) 
Reply-To: friedman@nquah6f.ott.bnr.ca
X-Mailer: ELM [version 2.4.1 PL23] 
Content-Type: text 

After patchup and build on hpux 9.03 when I start w3 either from the
help menu or manually, it displays the message "Using proxy for http"
and goes into a tight loop.  No redisplay.  (cover frame and remove -
never redrawn)  Unable to abort with ^G  or ^].

A lisp backtrace was produced when I killed the process.


From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 16:53:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA18530 for xemacs-beta-people; Tue, 17 Sep 1996 16:53:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA18527 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 16:53:31 -0500 (CDT)
Received: from tau.space.thiokol.com ([146.168.22.26]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id QAA11539 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 16:53:22 -0500 (CDT)
Received: by tau.space.thiokol.com (940816.SGI.8.6.9/940406.SGI)
	for xemacs-beta@xemacs.org id PAA28147; Tue, 17 Sep 1996 15:51:28 -0600
From: daveb@tau.space.thiokol.com (David P. Boswell)
Message-Id: <199609172151.PAA28147@tau.space.thiokol.com>
Subject: xemacs-20.0-b29 success IRIX 5.3
To: xemacs-beta@xemacs.org
Date: Tue, 17 Sep 1996 15:51:28 -0600 (MDT)
X-Mailer: ELM [version 2.4 PL24 PGP2]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Built from full src dist.  Looks ok for what I use so far...

Configured for `mips-sgi-irix5.3'.

  Where should the build process find the source code?    /usr/local/src/xemacs-20.0-b29
  What installation prefix should install use?            ${srcdir}
  What operating system and machine description files should XEmacs use?
        `s/irix5-3.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              gcc  -g -O
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 17:14:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA18577 for xemacs-beta-people; Tue, 17 Sep 1996 17:14:18 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA18574 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 17:14:17 -0500 (CDT)
Received: from ethanol.gnu.ai.mit.edu (rms@ethanol.gnu.ai.mit.edu [128.52.46.64]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id RAA11606 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 17:14:14 -0500 (CDT)
Received: by ethanol.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id SAA01044; Tue, 17 Sep 1996 18:14:32 -0400
Date: Tue, 17 Sep 1996 18:14:32 -0400
Message-Id: <199609172214.SAA01044@ethanol.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: wing@666.com
CC: xemacs-beta@xemacs.org, rms@gnu.ai.mit.edu
In-reply-to: <199609130209.TAA09977@shellx.best.com> (message from Ben Wing on
	Thu, 12 Sep 1996 19:09:19 -0700)
Subject: Re: Versions of Emacs

    BTW Linux would not exist if Linus insisted on the same legal-paper
    assignment that you do.

I'm sure Linus could develop Linux following careful practice with
legal papers if he wanted to.  There are a number of large GNU
programs, and the practice of getting legal papers hasn't made it hard
to maintain them.  Once in a while a contributor says no, but carrying
out the process itself is not a lot of work.


From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 18:29:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA18819 for xemacs-beta-people; Tue, 17 Sep 1996 18:29:41 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA18816 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 18:29:40 -0500 (CDT)
Received: from ethanol.gnu.ai.mit.edu (rms@ethanol.gnu.ai.mit.edu [128.52.46.64]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id SAA11747 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 18:29:36 -0500 (CDT)
Received: by ethanol.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id TAA01215; Tue, 17 Sep 1996 19:30:14 -0400
Date: Tue, 17 Sep 1996 19:30:14 -0400
Message-Id: <199609172330.TAA01215@ethanol.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
to: xemacs-beta@xemacs.org
cc: rms@gnu.ai.mit.edu
Subject: Re: Versions of Emacs

In this discussion, I've been focusing on the practical alternatives
and their effects on the community, not on attacking individuals.  But
one part of one of my messages did criticize an individual by
explaining that his decision to make a split was a choice.  So it's
true that I have not 100% avoided criticizing any individual.

The point of that part of the message was not criticism, though.  The
point was to respond to the assertion that splits like this are an
inevitable result of making software free; that there is no point,
after the software is made free, where people have a choice about how
much effort to make to work together.  Even in that part, I was
focusing on the alternatives and their effects on the community.

However, what I said did criticize a person, so I apologize for not
completely avoiding such criticism in my messages.

Over the years, some people have repeatedly attacked me harshly,
saying that the split is entirely my fault because I am unreasonable,
stubborn, foolish and/or incompetent.  On a few instances I responded
to this, but usually I kept silent.  I was thought that public
argument would be counterproductive for furthering cooperation.

These accusations were repeated again recently, so I wrote an
explanation of the events leading up to the Lucid Emacs split.  The
focus is on clearing my name, not on attacking anyone, and the tone is
not bitter or harsh.  But it does describe other people's actions
which I think were less than helpful.  To show why my actions were
reasonable, I have to explain what other people did.  And that could
be taken as criticism even though it is not written as criticism.

To avoid causing friction, and to focus on the practical needs of the
situation, I've decided not to post that explanation.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 20:41:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA19144 for xemacs-beta-people; Tue, 17 Sep 1996 20:41:39 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA19141 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 20:41:38 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA19737 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 20:41:37 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id SAA19943; Tue, 17 Sep 1996 18:45:13 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: cl-read.el -- Unbytecompilable?
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Sep 1996 18:45:11 -0700
Message-ID: <m2k9tswq8o.fsf@deanna.miranova.com>
Lines: 23
X-Mailer: Red Gnus v0.35/XEmacs 19.15

>From an unmodified distribution 19.14: (It does the same thing in
19.15 beta1 and beta2)

$ xemacs -batch -f batch-byte-compile cl-read.el
Loading bytecomp...
Compiling /tmp/cl-read.el...
Loading cl-macs...
Loading byte-optimize...
Loading cl-read...
Loading eval-reg...
Loading advice...
While compiling toplevel forms in file /tmp/cl-read.el:
  ** (setq ad-return-value (if (interactive-p) (call-interactively (quote ad-Orig-eval-region)) (ad-Orig-eval-region b e printflag))) is a malformed function
Loading cl-seq...
Wrote /tmp/cl-read.elc
Done

What does this mean, and should we care?
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 21:09:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA19212 for xemacs-beta-people; Tue, 17 Sep 1996 21:09:06 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA19209 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 21:09:05 -0500 (CDT)
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA20041 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 21:09:04 -0500 (CDT)
Received: from camelot.ai.mit.edu by martigny.ai.mit.edu with SMTP
	(1.40.112.4/16.2) id AA156932540; Tue, 17 Sep 1996 22:09:00 -0400
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
Message-Id: <199609180209.AA156932540@martigny.ai.mit.edu>
Received: by camelot.ai.mit.edu
	(1.40.112.4/16.2) id AA070642539; Tue, 17 Sep 1996 22:08:59 -0400
Date: Tue, 17 Sep 1996 22:08:59 -0400
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu
In-Reply-To: <m2k9tswq8o.fsf@deanna.miranova.com> (message from Steven L Baur
	on 17 Sep 1996 18:45:11 -0700)
Subject: Re: cl-read.el -- Unbytecompilable?

:From: Steven L Baur <steve@miranova.com>
:Date: 17 Sep 1996 18:45:11 -0700
:
:$ xemacs -batch -f batch-byte-compile cl-read.el
:Loading bytecomp...
:Compiling /tmp/cl-read.el...
:Loading cl-macs...
:Loading byte-optimize...
:Loading cl-read...
:Loading eval-reg...
:Loading advice...
:While compiling toplevel forms in file /tmp/cl-read.el:
:  ** (setq ad-return-value (if (interactive-p) (call-interactively (quote ad-Orig-eval-region)) (ad-Orig-eval-region b e printflag))) is a malformed function
:
:What does this mean, and should we care?

Yes. The warning means the compiler encountered a function call of form

((setq ...) ...)

i.e. an improper value (setq ... ) in a functional position.

One common cause is that some macro is lacking a definition at
compile-time and is hence being compiled as a function.

-Bill

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 21:54:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA19359 for xemacs-beta-people; Tue, 17 Sep 1996 21:54:53 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA19356 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 21:54:52 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA20720 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 21:54:49 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id TAA20937; Tue, 17 Sep 1996 19:58:22 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: cl-read.el -- Unbytecompilable?
References: <199609180209.AA156932540@martigny.ai.mit.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Bill Dubuque's message of Tue, 17 Sep 1996 22:08:59 -0400
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Sep 1996 19:58:22 -0700
Message-ID: <m2enk0wmup.fsf@deanna.miranova.com>
Lines: 28
X-Mailer: Red Gnus v0.35/XEmacs 19.15

>>>>> "Bill" == Bill Dubuque <wgd@martigny.ai.mit.edu> writes:

>While compiling toplevel forms in file /tmp/cl-read.el:
>  ** (setq ad-return-value (if (interactive-p) (call-interactively (quote ad-Orig-eval-region)) (ad-Orig-eval-region b e printflag))) is a malformed function

> What does this mean, and should we care?

Bill> Yes. The warning means the compiler encountered a function call of form

Bill> ((setq ...) ...)

Bill> i.e. an improper value (setq ... ) in a functional position.

Bill> One common cause is that some macro is lacking a definition at
Bill> compile-time and is hence being compiled as a function.

I recognize the ad- prefix, that smells of defadvice.  The only
pertinent printflag parameter in lisp/*/*.el is in
prim/simple.el:eval-current-buffer.  And there's advice set for
eval-region, so that may be it, but it doesn't help isolate where.

What can I do to find the line it's breaking on (other than hand
bytecompiling)?
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 22:33:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA19419 for xemacs-beta-people; Tue, 17 Sep 1996 22:33:24 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA19416 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 22:33:23 -0500 (CDT)
Received: from gol1.gol.com (root@gol1.gol.com [202.243.48.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA12144 for <xemacs-beta@xemacs.org>; Tue, 17 Sep 1996 22:33:20 -0500 (CDT)
Received: from pentagana (jhod@tky1-37.gol.com [202.243.51.37]) by gol1.gol.com (8.7.5/8.6.9) with SMTP id MAA22627 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 12:33:18 +0900 (JST)
Sender: jhod@gol.com
Message-ID: <323F6707.4A602037@po.iijnet.or.jp>
Date: Wed, 18 Sep 1996 12:05:43 +0900
From: Jareth Hein <jhod@po.iijnet.or.jp>
Organization: Sonic Software Planning, Japan
X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.13 i586)
MIME-Version: 1.0
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 20.29 with mule success on IRIX5.3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Title pretty much says it all. With the exceptions of the hanging
spectres of XIM and improper coded cut-n-paste, what I use daily seems
to work... The file coding stuff has definatly become more Mule-like.


Configured for `mips-sgi-irix5.3'.

  Where should the build process find the source code?   
/localdev/xemacs
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/irix5-3.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              cc -g 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                               
/usr/local/include /usr/include/wnn
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.
  Compiling in code for checking XEmacs memory usage.

--Jareth Hein
jhod@po.iijnet.or.jp

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 17 23:38:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA19537 for xemacs-beta-people; Tue, 17 Sep 1996 23:38:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA19534 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 17 Sep 1996 23:38:46 -0500 (CDT)
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA21841 for <xemacs-beta@cs.uiuc.edu>; Tue, 17 Sep 1996 23:38:46 -0500 (CDT)
Received: from camelot.ai.mit.edu by martigny.ai.mit.edu with SMTP
	(1.40.112.4/16.2) id AA173371522; Wed, 18 Sep 1996 00:38:42 -0400
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
Message-Id: <199609180438.AA173371522@martigny.ai.mit.edu>
Received: by camelot.ai.mit.edu
	(1.40.112.4/16.2) id AA071331521; Wed, 18 Sep 1996 00:38:41 -0400
Date: Wed, 18 Sep 1996 00:38:41 -0400
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu
In-Reply-To: <m2enk0wmup.fsf@deanna.miranova.com> (message from Steven L Baur
	on 17 Sep 1996 19:58:22 -0700)
Subject: howto break on byte-compiler error/warn [was: cl-read.el -- Unbytecompilable?]

:From: Steven L Baur <steve@miranova.com>
:Date: 17 Sep 1996 19:58:22 -0700
:
: ... What can I do to find the line it's breaking on ...

M-x set-variable RET byte-compile-error-on-warn RET t RET
M-x set-variable RET debug-on-error RET t RET

Then byte compile the file (or function) and poke around in the
 *Backtrace* buffer to see what was happening.

You might find the following debugger "p" command useful to
print out the full frame. Be sure to compile it as below.

(define-key debugger-mode-map "p" 'debugger-frame-print)

(defun debugger-frame-print ()
  "Print fully frame at point."
  (interactive)
  (beginning-of-line)
  (with-output-to-temp-buffer "*Frame*"
    (prin1 (cdr (backtrace-frame
		  (+ debugger-frame-offset (debugger-frame-number)))))
    (print-help-return-message)
    (save-excursion (set-buffer standard-output) (buffer-string))))

;; Must be compiled so frame-offset is correct.
(byte-compile 'debugger-frame-print)

-Bill

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 08:08:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA23781 for xemacs-beta-people; Wed, 18 Sep 1996 08:08:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA23778 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 08:08:45 -0500 (CDT)
Received: from omega.IntraNet.com (omega.IntraNet.com [192.148.106.20]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA12990 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 08:08:43 -0500 (CDT)
Received: by omega.IntraNet.com; (5.65/1.1.8.3/20May95-0100AM)
	id AA32261; Wed, 18 Sep 1996 09:14:28 -0400
Received: by giant.IntraNet.com (DECUS UUCP /2.0/2.0/2.0/);
          Wed, 18 Sep 96 09:07:18 EDT
Received: from blight.IntraNet.com by titan.intranet.com (MX V4.2 VAX) with
          SMTP; Wed, 18 Sep 1996 09:07:16 EDT
Received: (from edwards@localhost) by blight.IntraNet.com (AIX4.2/UCB 8.7/8.7)
          id JAA35026; Wed, 18 Sep 1996 09:01:50 -0400 (EDT)
Date: Wed, 18 Sep 1996 09:01:50 -0400 (EDT)
Message-Id: <199609181301.JAA35026@blight.IntraNet.com>
From: Jonathan Edwards <edwards@blight.IntraNet.com>
To: xemacs-beta@xemacs.org
Subject: 19.15-b2 success on aix4.2
X-Face: #bA9Kpw-a@xMyaNJ-2wie(5Lje^S*i^8!VUOF84U!/jSPG*y@3s4Qu+\-FBQ?vQpE1S1<Vo
          TeWVx=wH}wf_WC]x:D%qd,r*|!~q=gVAWEA;T~3V4};X$r7W!FA(#Zj'E7M^(Tv)

Configured for `powerpc-ibm-aix4.2.0.0'.

  Where should the build process find the source code?    /usr/src/xemacs-19.15-b2
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/aix4.h' and `m/ibmrs6000.h'
  What compiler should XEmacs be built with?              cc -O3
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in network sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 08:29:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA23829 for xemacs-beta-people; Wed, 18 Sep 1996 08:29:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA23826 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 08:29:28 -0500 (CDT)
Received: from chekov.ctd.comsat.com (exim@chekov.ctd.comsat.com [134.133.40.22]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA00233 for <xemacs-beta@cs.uiuc.edu>; Wed, 18 Sep 1996 08:29:28 -0500 (CDT)
Received: from neal by chekov.ctd.comsat.com with local (Exim 0.56 #3)
	id E0v3Mgw-0006WN-00; Wed, 18 Sep 1996 09:29:26 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: 19.15b2 hpux9.05 crash
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0v3Mgw-0006WN-00@chekov.ctd.comsat.com>
Date: Wed, 18 Sep 1996 09:29:26 -0400

19.15b2 hpux9.05 crash

Lisp backtrace follows:

  # bind (frame-being-created)
  make-frame((width 60 height 20 popup #<x-frame "emacs" 0x8bb> initially-unmapped t menubar-visible-p nil has-modeline-p nil default-toolbar-visible-p nil modeline-shadow-thickness 0 left 141 top 232))
  # bind (dfwidth dfheight props fontw fonth fheight fwidth fleft ftop parent props)
  make-dialog-frame()
  # bind (butbuff dirbuff filebuf file-p completer initial-contents must-match default dir prompt history)
  mouse-read-file-name-1(file-name-history "Insert file as MIME message: " nil nil 0 nil read-file-name-internal)
  # bind (completer initial-contents must-match default dir prompt history)
  read-file-name-1(file-name-history "Insert file as MIME message: " nil nil 0 nil read-file-name-internal)
  # bind (history initial-contents must-match default dir prompt)
  read-file-name("Insert file as MIME message: " nil nil 0)
  call-interactively(mime-editor/insert-file)
  # (condition-case ... . error)
  # (catch top-level ...)

(gdb) where
#0  0x807d8d80 in kill ()
#1  0x9d5fc in fatal_error_signal (sig=268489292) at emacs.c:191
#2  <signal handler called>
#3  0x807e42b4 in _strcmp ()
#4  0x1b4e94 in x_set_icon_name_from_bufbyte (f=0x40518c00, 
    name=0x40591300 "*news on comp.soft-sys.ptolemy*") at frame-x.c:627
#5  0xffd58 in update_frame_title (f=0x40518c00) at frame.c:2807
#6  0x1b4f2c in x_init_frame_2 (f=0x40518c00, props=805400432)
    at frame-x.c:1783
#7  0xf743c in Fmake_frame (props=541351116, device=270318080) at frame.c:495
#8  0xa6ebc in primitive_funcall (fn=0x807e4268 <strcmp>, nargs=805400432, 
    args=0x404ed858) at eval.c:3486
#9  0xa715c in funcall_subr (subr=0x40591304, args=0x30016f70) at eval.c:3526
#10 0xa635c in funcall_recording_as (recorded_as=1079579396, nargs=1, 
    args=0x7b035170) at eval.c:3231
#11 0xa6400 in Ffuncall (nargs=1079579396, args=0x30016f70) at eval.c:3253
#12 0x74428 in Fbyte_code (bytestr=2063814004, vector=2063814672, 
    maxdepth=270214612) at bytecode.c:450
#13 0x400c78d0 in MHASH_HITS ()
(gdb) 

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 08:30:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA23840 for xemacs-beta-people; Wed, 18 Sep 1996 08:30:18 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA23837 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 08:30:17 -0500 (CDT)
Received: from gol1.gol.com (root@gol1.gol.com [202.243.48.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA13020 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 08:30:13 -0500 (CDT)
Received: from pentagana (jhod@tky1-54.gol.com [202.243.51.54]) by gol1.gol.com (8.7.5/8.6.9) with SMTP id WAA25134 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 22:30:06 +0900 (JST)
Sender: jhod@gol.com
Message-ID: <323FB50C.3D100525@po.iijnet.or.jp>
Date: Wed, 18 Sep 1996 17:38:36 +0900
From: Jareth Hein <jhod@po.iijnet.or.jp>
Organization: Sonic Software Planning, Japan
X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.13 i586)
MIME-Version: 1.0
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 20.0-b29 crash
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The following crash was observed under IRIX5.3 with MULE enabled. I had
just kick started perl-cvs with 'CVS Update Directory' from the menu-bar,
and *poof*.  Since the crash seems to have something to do with the new
encoding stuff, I wondered if it has anything to do with the default
coding stuff I've put in my .emacs, but running with xemacs -q causes
the same result.

Lisp backtrace follows:

  # bind (frame-being-created)
  make-frame((width 60 height 20 popup #<x-frame "emacs" 0xad8>
initially-unmapped t menubar-visible-p nil has-modeline-p nil
default-toolbar-visible-p nil modeline-shadow-thickness 0 left 377 top
338))
  # bind (dfwidth dfheight props fontw fonth fheight fwidth fleft ftop
parent props)
  make-dialog-frame()
  # bind (butbuff dirbuff filebuf file-p completer initial-contents
must-match default dir prompt history)
  mouse-read-file-name-1(file-name-history "CVS Update (directory): "
nil "/localdev/wumpus/" nil nil read-file-name-internal)
  # bind (completer initial-contents must-match default dir prompt
history)
  read-file-name-1(file-name-history "CVS Update (directory): " nil
"/localdev/wumpus/" nil nil read-file-name-internal)
  # bind (history initial-contents must-match default dir prompt)
  read-file-name("CVS Update (directory): " nil "/localdev/wumpus/" nil)
  (list (read-file-name "CVS Update (directory): " nil default-directory
nil) current-prefix-arg)
)
  call-interactively(cvs-update)
  # (condition-case ... . error)
  # (catch top-level ...)

C backtrace follows:

Core from signal SIGBUS: Bus error
(dbx) where
>  0 _kill(0x30be, 0xa, 0x0, 0x0) ["kill.s":15, 0xfae25d4]
   1 fatal_error_signal(sig = 10) ["/localdev/xemacs/src/emacs.c":191,
0x4ace18]
   2 _sigtramp(0x30be, 0xa, 0x7fff8f98, 0x0) ["sigtramp.s":59,
0xfad5958]
   3 strcmp(0x10380110, 0xffffffff, 0xfffffffe, 0x104810c0)
["strcmp.s":35, 0xfabf76c]
   4 x_set_frame_text_value(f = 0x105dcf00, value = 0x10380110 =
"Interface.cc", Xt_resource_name = 0x5d521f7c = "iconName",
Xt_resource_encoding_name = 0x5d522072 = "iconNameEncoding")
["/localdev/xemacs/src/frame-x.c":640, 0x637c04]
   5 x_set_icon_name_from_bufbyte(f = 0x105dcf00, name = 0x10380110 =
"Interface.cc") ["/localdev/xemacs/src/frame-x.c":657, 0x637d20]
   6 update_frame_title(f = 0x105dcf00)
["/localdev/xemacs/src/frame.c":2807, 0x52e5bc]
   7 x_init_frame_2(f = 0x105dcf00, props = 542458124)
["/localdev/xemacs/src/frame-x.c":1801, 0x63aba0]
   8 Fmake_frame(props = 542458124, device = 270625024)
["/localdev/xemacs/src/frame.c":495, 0x526370]
   9 primitive_funcall(fn = 0x525b68, nargs = 2, args = 0x7fff94e4)
["/localdev/xemacs/src/eval.c":3486, 0x4bb458]
   10 funcall_subr(subr = 0x10030bd0, args = 0x7fff94e4)
["/localdev/xemacs/src/eval.c":3526, 0x4bb7fc]
   11 funcall_recording_as(recorded_as = 269759380, nargs = 1, args =
0x7fff9798) ["/localdev/xemacs/src/eval.c":3204, 0x4ba378]
   12 Ffuncall(nargs = 2, args = 0x7fff9798)
["/localdev/xemacs/src/eval.c":3253, 0x4ba608]
   13 Fbyte_code(bytestr = 806151752, vector = 1074587416, maxdepth =
22) ["/localdev/xemacs/src/bytecode.c":419, 0x460e60]
   14 funcall_lambda(fun = 269281248, nargs = 0, arg_vector =
0x7fff9ca4) ["/localdev/xemacs/src/eval.c":3636, 0x4bbfb0]
   15 funcall_recording_as(recorded_as = 270304844, nargs = 0, args =
0x7fff9ca0) ["/localdev/xemacs/src/eval.c":3210, 0x4ba408]
   16 Ffuncall(nargs = 1, args = 0x7fff9ca0)
["/localdev/xemacs/src/eval.c":3253, 0x4ba608]
   17 Fbyte_code(bytestr = 805774768, vector = 1074210508, maxdepth = 8)
["/localdev/xemacs/src/bytecode.c":419, 0x460e60]
   18 funcall_lambda(fun = 268904708, nargs = 7, arg_vector =
0x7fff9f1c) ["/localdev/xemacs/src/eval.c":3636, 0x4bbfb0]
More (n if no)?
   19 funcall_recording_as(recorded_as = 270304220, nargs = 7, args =
0x7fff9f18) ["/localdev/xemacs/src/eval.c":3210, 0x4ba408]
   20 Ffuncall(nargs = 8, args = 0x7fff9f18)
["/localdev/xemacs/src/eval.c":3253, 0x4ba608]
   21 Fbyte_code(bytestr = 805769384, vector = 1074204912, maxdepth = 8)
["/localdev/xemacs/src/bytecode.c":419, 0x460e60]
   22 funcall_lambda(fun = 268898688, nargs = 7, arg_vector =
0x7fffa15c) ["/localdev/xemacs/src/eval.c":3636, 0x4bbfb0]
   23 funcall_recording_as(recorded_as = 270304196, nargs = 7, args =
0x7fffa158) ["/localdev/xemacs/src/eval.c":3210, 0x4ba408]
   24 Ffuncall(nargs = 8, args = 0x7fffa158)
["/localdev/xemacs/src/eval.c":3253, 0x4ba608]
   25 Fbyte_code(bytestr = 805769688, vector = 1074205204, maxdepth = 8)
["/localdev/xemacs/src/bytecode.c":419, 0x460e60]
   26 funcall_lambda(fun = 268898884, nargs = 4, arg_vector =
0x7fffa278) ["/localdev/xemacs/src/eval.c":3636, 0x4bbfb0]
   27 apply_lambda(fun = 268898884, numargs = 4, unevalled_args =
269660164) ["/localdev/xemacs/src/eval.c":3559, 0x4bb9e0]
   28 Feval(form = 541743788) ["/localdev/xemacs/src/eval.c":3068,
0x4b9c74]
   29 Feval(form = 541743780) ["/localdev/xemacs/src/eval.c":3010,
0x4b997c]
   30 Fcall_interactively(function = 270567524, record_flag = 269660164,
keys = 269660164) ["/localdev/xemacs/src/callint.c":339, 0x465e78]
   31 primitive_funcall(fn = 0x46584c, nargs = 3, args = 0x7fffa794)
["/localdev/xemacs/src/eval.c":3488, 0x4bb480]
   32 funcall_subr(subr = 0x1002c388, args = 0x7fffa794)
["/localdev/xemacs/src/eval.c":3526, 0x4bb7fc]
   33 funcall_recording_as(recorded_as = 269736372, nargs = 1, args =
0x7fffa824) ["/localdev/xemacs/src/eval.c":3204, 0x4ba378]
   34 Ffuncall(nargs = 2, args = 0x7fffa824)
["/localdev/xemacs/src/eval.c":3253, 0x4ba608]
   35 call1(fn = 269736372, arg0 = 270567524)
["/localdev/xemacs/src/eval.c":3998, 0x4bce98]
   36 execute_command_event(command_builder = 0x101697c0, event =
271472104) ["/localdev/xemacs/src/event-stream.c":3486, 0x4d5568]
   37 Fdispatch_event(event = 271472104)
["/localdev/xemacs/src/event-stream.c":3833, 0x4d63d0]
   38 Fcommand_loop_1() ["/localdev/xemacs/src/cmdloop.c":542, 0x479cc4]
More (n if no)?
   39 command_loop_1(dummy = 269660164)
["/localdev/xemacs/src/cmdloop.c":462, 0x4798f4]
   40 condition_case_1(handlers = 269660260, bfun = 0x4798a8, barg =
269660164, hfun = 0x478b00, harg = 269660164)
["/localdev/xemacs/src/eval.c":1672, 0x4b5b2c]
   41 command_loop_3() ["/localdev/xemacs/src/cmdloop.c":224, 0x478d30]
   42 command_loop_2(dummy = 269660164)
["/localdev/xemacs/src/cmdloop.c":235, 0x478da4]
   43 internal_catch(tag = 269737956, func = 0x478d7c, arg = 269660164,
threw = (nil)) ["/localdev/xemacs/src/eval.c":1347, 0x4b534c]
   44 initial_command_loop(load_me = 269660164)
["/localdev/xemacs/src/cmdloop.c":273, 0x47916c]
   45 main_1(argc = 1, argv = 0x7fffaee4, envp = 0x7fffaeec)
["/localdev/xemacs/src/emacs.c":1372, 0x4af37c]
   46 main(argc = 1, argv = 0x7fffaee4, envp = 0x7fffaeec)
["/localdev/xemacs/src/emacs.c":1516, 0x4afba4]
   47 __start() ["crt1text.s":133, 0x4406dc]
(dbx) 

--Jareth Hein
jhod@po.iijnet.or.jp



From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 13:01:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA24639 for xemacs-beta-people; Wed, 18 Sep 1996 13:01:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA24636 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 13:01:57 -0500 (CDT)
Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA13450 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 13:01:53 -0500 (CDT)
Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.Beta.4/8.8.Beta.4) with ESMTP id OAA45368 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 14:01:54 -0400
Message-Id: <199609181801.OAA45368@black-ice.cc.vt.edu>
X-Mailer: exmh version 1.6.7 5/3/96
To: xemacs-beta@xemacs.org
Subject: Foo.. a buglet...
From: Valdis.Kletnieks@vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="===_-1_Wed_Sep_18_14:01:53_EDT_1996";
	micalc=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Wed, 18 Sep 1996 14:01:53 -0400

--===_-1_Wed_Sep_18_14:01:53_EDT_1996
Content-Type: text/plain; charset=us-ascii

Xemacs 20.0-b29, AIX 4.2, ksh (if that matters ;)

This works:

xemacs -unmapped -bg \#a8d8ff -fg black &
(it goes into the background, and doesn't open a window until I launch
a gnuclient)

This fails:

xemacs -bg \#a8d8ff -fg black -unmapped &

It opens a frame, and starts editing a file called '-unmapped'.

Any ideas, or should I start hacking at the code?
-- 
				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech



--===_-1_Wed_Sep_18_14:01:53_EDT_1996
Content-Type: application/pgp-signature

-----BEGIN PGP MESSAGE-----
Version: 2.6.2

iQCVAwUBMkA5D9QBOOoptg9JAQHeMAP7Bq1Ateo50tlwrzNmf9v9lbV5gWgAofdw
Avh+bJSJVz2xJoSHGWOpBzKRfxH9CM3R93W7LZ2qjGWLp0nVP57g3jd6hH4mhQ/7
JL+XrcQWqb3Ojr3rp15k4u15WsRHNmI4lUqIkYgMUcHa7wneyoOuB0Mv10oV2kSD
IZBvIY1YYAI=
=hQMm
-----END PGP MESSAGE-----

--===_-1_Wed_Sep_18_14:01:53_EDT_1996--

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 12:57:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA24627 for xemacs-beta-people; Wed, 18 Sep 1996 12:57:04 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA24624 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 12:57:03 -0500 (CDT)
Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA13435 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 12:57:00 -0500 (CDT)
Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.Beta.4/8.8.Beta.4) with ESMTP id NAA50134 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 13:57:01 -0400
Message-Id: <199609181757.NAA50134@black-ice.cc.vt.edu>
To: xemacs-beta@xemacs.org
Subject: Xemacs 20.0-b29 sucess on AIX 4.2
From: Valdis.Kletnieks@vt.edu
X-URL: http://black-ice.cc.vt.edu/~valdis/
Pgp-Action: signclearpem; rfc822=off; originator="<Valdis.Kletnieks@vt.edu>"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <38094.843069420.1@black-ice.cc.vt.edu>
Date: Wed, 18 Sep 1996 13:57:01 -0400

Configured with:

./configure -with-gcc=no --cflags="-O3 -DNO_ANSI_KEYWORDS" --dynamic \
   --with-tooltalk --with-cde \
   --site-includes="/usr/local/include /usr/dt/include/Tt /usr/dt/include" \
   --site-libraries=/usr/local/lib

Configured for `powerpc-ibm-aix4.2.0.0'.

  Where should the build process find the source code?    /home/spd/valdis/src/xemacs-20.0-b27/src
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/aix4.h' and `m/ibmrs6000.h'
  What compiler should XEmacs be built with?              cc -O3 -DNO_ANSI_KEYWORDS
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include /usr/dt/include/Tt /usr/dt/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in support for GNU DBM.
  Compiling in support for ToolTalk.
  Compiling in support for CDE.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

Seems to be basically working.... (and yes, I know there's a -b27 in the source tree pathname ;)

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 12:51:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA24594 for xemacs-beta-people; Wed, 18 Sep 1996 12:51:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA24591 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 12:51:50 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA15389 for <xemacs-beta@cs.uiuc.edu>; Wed, 18 Sep 1996 12:51:49 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id KAA24641; Wed, 18 Sep 1996 10:55:23 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: howto break on byte-compiler error/warn [was: cl-read.el -- Unbytecompilable?]
References: <199609180438.AA173371522@martigny.ai.mit.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Bill Dubuque's message of Wed, 18 Sep 1996 00:38:41 -0400
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 18 Sep 1996 10:55:23 -0700
Message-ID: <m2wwxrwvw4.fsf@deanna.miranova.com>
Lines: 72
X-Mailer: Red Gnus v0.35/XEmacs 19.15

>>>>> "Bill" == Bill Dubuque <wgd@martigny.ai.mit.edu> writes:

Bill> M-x set-variable RET byte-compile-error-on-warn RET t RET
Bill> M-x set-variable RET debug-on-error RET t RET

Bill> Then byte compile the file (or function) and poke around in the
Bill>  *Backtrace* buffer to see what was happening.

Bill> You might find the following debugger "p" command useful to
Bill> print out the full frame. Be sure to compile it as below.

Bill> (define-key debugger-mode-map "p" 'debugger-frame-print)

Bill> (defun debugger-frame-print ()
Bill>   "Print fully frame at point."

(Why isn't this part of debug.el?  Should it be?)

Thanks for the advice Bill, but it didn't work.  I was able to get a
lisp backtrace with: (debug-on-entry 'byte-compile-warn).

The message is coming from cl-reader-install/elisp-eval-region-install
at the specific line ``(defalias 'eval-region 'elisp-eval-region)''
(in eval-reg.el).

eval-region gets defadvice added during byte compilation, and that
seems to be the root cause of the error message.

I've tried pulling out the defadvice code into its own package, and
putting a (require 'advise-eval-region) right above the offensive
defalias line, but it does not help.

Any further clues?  Hopefully this is obvious to someone.

Here is the backtrace:

Entering:
* byte-compile-warn("%s is a malformed function" "(setq ad-return-value (ad-Orig-eval-region elisp-start elisp-end elisp-output))")
  byte-optimize-form-code-walker(((setq ad-return-value (ad-Orig-eval-region elisp-start elisp-end elisp-output))) nil)
  byte-optimize-form(((setq ad-return-value (ad-Orig-eval-region elisp-start elisp-end elisp-output))) nil)
  byte-optimize-form-code-walker((progn ((setq ad-return-value ...))) nil)
  byte-optimize-form((progn ((setq ad-return-value ...))) nil)
  byte-compile-top-level((progn ((setq ad-return-value ...))) nil lambda)
  byte-compile-lambda((lambda nil ((setq ad-return-value ...))))
  byte-compile-function-form((function (lambda nil (...))))
  byte-compile-form((function (lambda nil (...))))
  byte-compile-let((let ((elisp-code ...)) (if (not ...) (unwind-protect ... ...) (funcall elisp-code))))
  byte-compile-form((let ((elisp-code ...)) (if (not ...) (unwind-protect ... ...) (funcall elisp-code))) t)
  byte-compile-body(((let (...) (if ... ... ...)) ad-return-value) nil)
  byte-compile-let((let (ad-return-value) (let (...) (if ... ... ...)) ad-return-value))
  byte-compile-form((let (ad-return-value) (let (...) (if ... ... ...)) ad-return-value) nil)
  byte-compile-top-level((progn (let (ad-return-value) (with-elisp-eval-region ... ...) ad-return-value)) nil lambda)
  byte-compile-lambda((lambda (elisp-start elisp-end &optional elisp-output) "$ad-doc: eval-region$" (interactive "r") (let (ad-return-value) (with-elisp-eval-region ... ...) ad-return-value)))
  byte-code("	!
=\n
9!K=A=!B!9\"*> ." [copy-alist byte-compile-initial-macro-environment nil byte-compile-verbose byte-optimize byte-compile-emacs18-compatibility byte-compile-dynamic byte-compile-dynamic-docstrings byte-compile-warnings t byte-compile-default-warnings byte-compile-file-domain byte-compile-free-assignments byte-compile-free-references byte-compile-bound-variables byte-compile-unresolved-functions byte-compile-autoload-environment byte-compile-function-environment byte-compile-macro-environment form fboundp fun macro lambda byte-compile-lambda defalias unused-vars byte-compile-warn-about-unused-variables] 15)
  byte-compile(eval-region)
  ad-compile-function(eval-region)
  ad-activate-advised-definition(eval-region nil)
  ad-activate(eval-region nil)
  defalias(eval-region elisp-eval-region)
  elisp-eval-region-install()
  cl-reader-install()
  eval-buffer("cl-read.el")
  call-interactively(eval-buffer)
  command-execute(eval-buffer t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 16:14:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id QAA25686 for xemacs-beta-people; Wed, 18 Sep 1996 16:14:18 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25683 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 16:14:16 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id QAA25590 for <xemacs-beta@cs.uiuc.edu>; Wed, 18 Sep 1996 16:14:05 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id OAA27203; Wed, 18 Sep 1996 14:17:39 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: edebug/cl-read.el mystery solved.
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Sep 1996 14:17:29 -0700
Message-ID: <m2685br09h.fsf@deanna.miranova.com>
Lines: 30
X-Mailer: Red Gnus v0.35/XEmacs 19.15

In case anybody cares, here's the explanation of the problem with
bytecompiling cl-read.el.

There were two problems.

One was that the advice for eval-region:
(defadvice eval-region (around cl-read activate)
  "Use the reader::read instead of the original read if cl-read-active."
  (with-elisp-eval-region (not cl-read-active)
    (ad-do-it)))

is wrong.  The last line should read:

    ad-do-it))

ad-do-it is a keyword and macro expanded and not a function (thank you
Bill for the correct diagnosis :-).  Also, due to the odd way
cl-read.el reads itself twice when bytecompiling, it loses to have the
defadvice done twice.  So, I pulled that out into a separate file, and
now edebug bytecompiles cleanly. :-)

When the patches for these changes get into the next beta, you will
need to remove cl-read.elc manually before bytecompiling, or you will
continue to get the old error message.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 17:50:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA26106 for xemacs-beta-people; Wed, 18 Sep 1996 17:50:05 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA26103 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 17:50:04 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA00665 for <xemacs-beta@cs.uiuc.edu>; Wed, 18 Sep 1996 17:49:55 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id PAA28766; Wed, 18 Sep 1996 15:53:35 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: 19.15-b2 crash on Linux 2.0.18
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 18 Sep 1996 15:53:34 -0700
Message-ID: <m2ohj3e8pd.fsf@deanna.miranova.com>
Lines: 57
X-Mailer: Red Gnus v0.35/XEmacs 19.15

During incorporation of new mail in Red Gnus.  This XEmacs was not up
for very long, and was only being used for Gnus.

The C Backtrace shows stack corruption.

Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Lisp backtrace follows:

  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  insert-file-contents-internal("/home/steve/Mail/active" nil nil nil nil)
  # bind (replace end beg visit filename)
  ange-ftp-real-insert-file-contents("/home/steve/Mail/active" nil nil nil nil)
  # bind (parsed replace end beg visit filename)
  insert-file-contents("~/Mail/active")
  byte-code("	!" [insert-file-contents file t] 2)
  # (condition-case ... . ((file-error)))
  # bind (format-alist after-insert-file-functions file)
  nnmail-find-file("~/Mail/active")
  # (unwind-protect ...)
  # bind (server)
  nnml-request-list()
  # (unwind-protect ...)
  # bind (file timestamp file-time force backend)
  nnmail-activate(nnml)
  # bind (dont-check server group)
  nnml-request-group("hwg-design-bounces" "" nil)
  # bind (method method dont-check group)
  gnus-request-group("nnml:hwg-design-bounces" nil (nnml ""))
  # (condition-case ... . ((quit)))
  # bind (method active method dont-check scan group)
  gnus-activate-group("nnml:hwg-design-bounces" scan)
  # bind (method active group info foreign-level level newsrc level)
  gnus-get-unread-articles(nil)
  # bind (arg)
  gnus-group-get-new-news(nil)
  # bind (command-debug-status)
  call-interactively(gnus-group-get-new-news)
  # (condition-case ... . error)
  # (catch top-level ...)

(gdb) where
#0  0x40204741 in __kill ()
#1  0x8081439 in fatal_error_signal (sig=11) at emacs.c:191
#2  0xbfff27a8 in __ypbindlist ()
#3  0x31203431 in lwlib_does_not_use_motif_1_2 ()
Cannot access memory at address 0x20313132.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 22:15:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA26728 for xemacs-beta-people; Wed, 18 Sep 1996 22:15:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA26725 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 22:15:02 -0500 (CDT)
Received: from bayserve.net (bay1.bayserve.net [206.148.244.200]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA14409 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 22:15:00 -0500 (CDT)
Received: from localhost (jmiller@localhost) by  bayserve.net (8.7.2/8.7.2) with SMTP id XAA18318 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 23:18:47 -0400 (EDT)
Date: Wed, 18 Sep 1996 23:18:47 -0400 (EDT)
From: Jeff Miller <jmiller@bay1.bayserve.net>
To: xemacs-beta@xemacs.org
Subject: bug report - 19.15b2 
Message-ID: <Pine.SUN.3.95.960918231221.17893A-100000@bay1.bayserve.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


When using the --with-scrollbars=none configure option, the compile ends
up with:

--snip--
ell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o
-llw -lXaw -lXpm -lcompface -ljpeg     -lXmu -lXt -lSM -lICE  -lXext -lX11
-lncurses            -lgdbm  -ldb      -lm  -lgcc -lc -lgcc
/usr/lib/crtn.o   
/usr/i486-linux/bin/ld: cannot open -llw: No such file or directory
make[1]: *** [temacs] Error 1
make[1]: Leaving directory `/mnt2/jmiller/source/xemacs-19.15-b1/src'

I looked in lwlib and no files are compiled and lwlib.a is not made.

I believe this at least compiled under 19.15b1 but wouldn't run because
one of the lisp routines wasn't checking to see if scrollbar was present.

configure \
--site-includes=/usr/local/include \
--site-libraries=/usr/local/lib \
--cflags="-O4" \
--with-scrollbars=none \
--with-menubars=none \
--with-dialogs=none \
--with-toolbars=no \

Changing the scrollbars=none to scrollbars=lucid yields a good xemacs
binary albeit with scrollbars.


From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 23:20:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA26867 for xemacs-beta-people; Wed, 18 Sep 1996 23:20:20 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA26864 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 23:20:19 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA14522; Wed, 18 Sep 1996 23:20:17 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id VAA01590; Wed, 18 Sep 1996 21:19:45 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id VAA23531; Wed, 18 Sep 1996 21:19:43 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA12764; Wed, 18 Sep 1996 21:19:44 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA02275; Wed, 18 Sep 1996 21:19:40 -0700
Date: Wed, 18 Sep 1996 21:19:40 -0700
Message-Id: <199609190419.VAA02275@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: BUG REPORT: Selection code doesn't handle non-Latin1 text.
Reply-To: Martin Buchholz <mrb@eng.sun.com>

Category: I18N

Reproduce: Build --with-mule --with-xim.  Enter non-Latin1 text in the
buffer. Select the text with the mouse.  Paste it using the mouse
(button 2).  That first one worked.  Paste it again.  This time only
tildes appear instead of the desired characters.

This appears to be related to whether XEmacs `owns' the selection.

Maritn

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 18 23:15:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id XAA26852 for xemacs-beta-people; Wed, 18 Sep 1996 23:15:34 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id XAA26849 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 18 Sep 1996 23:15:33 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id XAA14505 for <xemacs-beta@xemacs.org>; Wed, 18 Sep 1996 23:15:30 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id VAA00787; Wed, 18 Sep 1996 21:15:01 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id VAA23042; Wed, 18 Sep 1996 21:14:58 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA12716; Wed, 18 Sep 1996 21:14:59 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA02267; Wed, 18 Sep 1996 21:14:55 -0700
Date: Wed, 18 Sep 1996 21:14:55 -0700
Message-Id: <199609190414.VAA02267@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: State of XEmacs/MULE
Reply-To: Martin Buchholz <mrb@eng.sun.com>

Real Soon Now (sorry, dates not available), Sun Developer Products is
putting out a CD that will have XEmacs 20.0 on it.  It will come with
2 xemacs binaries, `regular' (`Western') and `Mule' (`Japanese').  The
Mule support has gotten a lot more solid lately.  I have been using
Mule-enabled XEmacs for all my personal work lately, and it is
definitely usable, and (on Solaris at least) quite stable.

Editing of files with native filenames should work
(using pathname-coding-system).

Non-Latin1 characters can be displayed in the window manager title and
icon name, although the window manager will have to help out a little.
Most window managers will only be able to display text in the current
locale (of the window manager!).

Non-Latin1 characters are now supported in the `suffix' part of menu
entries (e.g. the buffer names in the File menu).

If you run in a japanese locale, you will (soon) have most menu items
translated.

Options->Language Environment is no longer completely non-functional.


However, lots of work remains.

For some reason, the xemacs in my personal workspace can successfully
edit non-Latin1 filenames, while 20.0-b29 cannot.  So some patch must
have gone awry.  Under investigation.

My attempted fix for the crash
(string-match "[^a]" str)
when str contains non-ASCII characters didn't work, and I had to back
it out.  Deep mule-izing of the Boyer-Moore search algorithm in
search.c may be required.

-------------- XIM --------------------------------------------------
It is unfortunate that no one seems to have gotten XIM to work except
on Solaris.  The crash shouldn't be too hard to track down with a
debug build, but I can't do it myself because I can't reproduce it.
In the mean time, one can disable the crashing feature by using
root-window conversion with XIM:

Here is an excerpt from sample.Xdefaults:

! XIM input method style 
! ======================= 

! ximStyles is a (whitespace or comma-separated) list of XIMStyles in
! order of user's preference.  
! Choose a subset of the following styles or reorder to taste
Emacs*ximStyles: XIMPreeditPosition|XIMStatusArea\
            XIMPreeditPosition|XIMStatusNothing\
            XIMPreeditPosition|XIMStatusNone\
            XIMPreeditNothing|XIMStatusArea\
            XIMPreeditNothing|XIMStatusNothing\
            XIMPreeditNothing|XIMStatusNone\
            XIMPreeditNone|XIMStatusArea\
            XIMPreeditNone|XIMStatusNothing\
            XIMPreeditNone|XIMStatusNone

If you build --with-xim and add to your $HOME/Emacs file:

Emacs*ximStyles: XIMPreeditNothing|XIMStatusNothing\
            XIMPreeditNothing|XIMStatusNone\
            XIMPreeditNone|XIMStatusNothing\
            XIMPreeditNone|XIMStatusNone

then XIM should no longer crash in the XIM geometry code.
It would be nice if someone could report success at least with this.

Some of the XIM implementation is still fairly kludgy, although it is
no longer horrible.  Hopefully I will have the time to clean it up.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 01:20:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA27122 for xemacs-beta-people; Thu, 19 Sep 1996 01:20:08 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA27119 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 01:20:07 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA14709 for <xemacs-beta@xemacs.org>; Thu, 19 Sep 1996 01:20:00 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id XAA19978; Wed, 18 Sep 1996 23:19:30 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id XAA02995; Wed, 18 Sep 1996 23:19:28 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id XAA13819; Wed, 18 Sep 1996 23:19:27 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id XAA03197; Wed, 18 Sep 1996 23:19:25 -0700
Date: Wed, 18 Sep 1996 23:19:25 -0700
Message-Id: <199609190619.XAA03197@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Mike Scheidler <c23mts@eng.delcoelect.com>
Cc: xemacs-beta@xemacs.org
Subject: Question about DOC* files
In-Reply-To: <9059.842974212@kocrsw12>
References: <9059.842974212@kocrsw12>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Mike" == Mike Scheidler <c23mts@eng.delcoelect.com> writes:

Mike> Here's something I've always found strange, but never really questioned
Mike> until now.  Why are there two separate DOC files in the lib-src directory?
Mike> From all I've seen they're always identical, and each is about 1.2 meg in
Mike> size. I could maybe understand having one as a hard link to the other to
Mike> allow them to be referenced under different names, but the current setup
Mike> just doesn't make much sense to me.

Mike> Does anybody have an explanation?  Is this something that could/should be
Mike> changed to save some disk space?

I think this is historical.  Note that the file named `DOC' is not
installed.  It should be easy to not ever create it either.

Martin



From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 01:09:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id BAA27100 for xemacs-beta-people; Thu, 19 Sep 1996 01:09:17 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id BAA27097 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 01:09:16 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id BAA14668 for <xemacs-beta@xemacs.org>; Thu, 19 Sep 1996 01:09:14 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id XAA18601; Wed, 18 Sep 1996 23:08:43 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id XAA02213; Wed, 18 Sep 1996 23:08:41 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id XAA13723; Wed, 18 Sep 1996 23:08:39 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id XAA03169; Wed, 18 Sep 1996 23:08:37 -0700
Date: Wed, 18 Sep 1996 23:08:37 -0700
Message-Id: <199609190608.XAA03169@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Jareth Hein <jhod@po.iijnet.or.jp>
Cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: 20.0-b29 crash
In-Reply-To: <323FB50C.3D100525@po.iijnet.or.jp>
References: <323FB50C.3D100525@po.iijnet.or.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "Jareth" == Jareth Hein <jhod@po.iijnet.or.jp> writes:

Jareth> The following crash was observed under IRIX5.3 with MULE enabled.

Try this patch:

*** /tmp/geta3157	Wed Sep 18 22:59:06 1996
--- frame-x.c	Wed Sep 18 22:57:21 1996
***************
*** 617,623 ****
  {
    Atom encoding = XA_STRING;
    String new_XtValue = (String) value;
!   String old_XtValue;
    Bufbyte *ptr;
    Arg av[2];
  
--- 617,623 ----
  {
    Atom encoding = XA_STRING;
    String new_XtValue = (String) value;
!   String old_XtValue = NULL;
    Bufbyte *ptr;
    Arg av[2];
  

For bonus points, you can explain why this should be necessary.  The
only way I can imagine this should crash is if the XtNiconName
resource doesn't apply to the TopLevelShell widget.  Does the icon
label in fact get set properly on IRIX??

If this doesn't fix the problem, then XtGetValues is retrieving a bad
value for the XtNiconName resource, which X is not allowed to do.  In
this case we'd need a flag to remember whether this is the `first' time.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 05:37:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id FAA01169 for xemacs-beta-people; Thu, 19 Sep 1996 05:37:31 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA01166 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 05:37:30 -0500 (CDT)
Received: from sys3.cambridge.uk.psi.net (sys3.cambridge.uk.psi.net [154.32.106.10]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id FAA14976 for <xemacs-beta@xemacs.org>; Thu, 19 Sep 1996 05:37:27 -0500 (CDT)
Received: from arrow by sys3.cambridge.uk.psi.net (8.7.5/SMI-5.5-UKPSINet)
	id LAA01679; Thu, 19 Sep 1996 11:20:47 +0100 (BST)
Received: by arrow (5.x/SMI-SVR4)
	id AA22449; Thu, 19 Sep 1996 11:22:40 +0100
>Received: from dx2.delcam.com by delcam.com; Thu, 19 Sep 96 11:22:50 BST
Received: from delcam by arrow.delcam.com; Thu, 19 Sep 1996 11:22 BST
Received: from dx2.delcam.com by delcam.com; Thu, 19 Sep 96 11:22:50 BST
Received: by dx2.delcam.com; Thu, 19 Sep 1996 11:19:43 +0100
Message-Id: <11418.199609191019@dx2.delcam.com>
Date: Thu, 19 Sep 1996 11:19:43 +0100
From: Paul Bibilo <peb@delcam.com>
To: xemacs-beta@xemacs.org
Subject: 19.15b2 success
X-Face:  "+N/{>9S5,OIk<0$%[)LGd}<Mh,R;qNhl+C]O!g9wsh6Q65Wiv,#M#&,MjgG1?&]jTbwsn*
 _yj,NR}PT7"irWSgi|(H5w)Q1C0.dO:qt?=S`eF/EcT!L_1D7eJ&b-J5d#AoLu&}b#'}nq(^pr2+u*
 7'RvZp0xv:q/K&%WDOQ(+H?AJw7[|DcUK{}5S!;I4^9vFe$A2%G_oz3K#2d{m#[MnE,-hxq9Po9v]R
 t]j*0md[y/3R~J
Content-Type: text


Patched up from b1 and

Configured for `mips-sgi-irix5.3'.

  Where should the build process find the source code?    /local/ducdev/local/projects/emacs/beta/xemacs-19.15-b2
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/irix5-3.h' and `m/iris4d.h'
  What compiler should XEmacs be built with?              cc -g 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.

I needed to
chmod 644 lisp/vm/vm-autoload.el
rm lisp/hm--html-menus/*.elc

before make all-elc would play ball.

O.K. so far.

-- 
Paul Bibilo, Delcam International plc, |     Tel: +44 121 766 5544
Talbot Way, Small Heath, Birmingham,   |     Fax: +44 121 766 5511
England, B10 0HJ.                 _____|_____ICBM-mail: 52 17N  1 30W
#include <disclaimer.h>          | BLAT FOOP |


From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 11:57:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA02056 for xemacs-beta-people; Thu, 19 Sep 1996 11:57:44 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA02053 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 11:57:42 -0500 (CDT)
Received: from mimbres.cs.unm.edu (mimbres.cs.unm.edu [198.59.151.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id LAA15575 for <xemacs-beta@xemacs.org>; Thu, 19 Sep 1996 11:57:38 -0500 (CDT)
Received: from hawaii.cs.unm.edu by mimbres.cs.unm.edu (5.65/033093) with SMTP
	id <AA10092@mimbres.cs.unm.edu>; Thu, 19 Sep 96 10:57:38 -0600
Received: by hawaii.cs.unm.edu (Smail3.1.28.1 #1)
	id m0v3mPx-000456C; Thu, 19 Sep 96 10:57 MDT
To: xemacs-beta@xemacs.org
Subject: [Lars Magne Ingebrigtsen <larsi@ifi.uio.no>] Re: ange-ftp, Gnus5, and XEmacs -- revisited
From: Jason Stewart <jasons@cs.unm.edu>
Date: 19 Sep 1996 10:57:34 -0600
Message-Id: <xjnenjycuip.fsf@hawaii.cs.unm.edu>
Lines: 50
X-Mailer: Gnus v5.2.34/XEmacs 19.14

Hi,

This is from a series of exchanges between Lars and I trying to get
ange-ftp working with Gnus5 under XEmacs19.13/14. It works perfectly
under GNU Emacs and we narrowed it down to the following:

(load "/jasons@chaco.cs.unm.edu:.newsrc-lynx.unm.edu.eld" t t t)

Which returned nil...


------- Start of forwarded message -------
To: Jason Stewart <jasons@cs.unm.edu>
Subject: Re: ange-ftp, Gnus5, and XEmacs -- revisited
References: <m0v0D9m-0001WyC@hawaii.cs.unm.edu> <x6afuowsai.fsf@eyesore.no> <xjnohj3cw1m.fsf@hawaii.cs.unm.edu>
Date: 19 Sep 1996 04:21:28 +0200
Message-Id: <x64tkvnt1z.fsf@eyesore.no>
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>

Jason Stewart <jasons@cs.unm.edu> writes:

> It returns nil.
> 
> the ftp buffer looks as follows:
> 
> ftp> open chaco.cs.unm.edu
> Connected to chaco.cs.unm.edu.
> 220 chaco.cs.unm.edu FTP server (ULTRIX Version 4.1 Fri Jul 24 13:34:28 EDT 1992) ready.
> user "jasons" Turtle Power!
> ftp> 331 Password required for jasons.
> 230 User jasons logged in.
> ftp> hash
> Hash mark printing on (1024 bytes/hash mark).
> ftp> pwd
> 257 "/nfs/u8/jasons" is current directory.
> ftp> 

[...]

> > (load "/jasons@chaco.cs.unm.edu:.newsrc-lynx.unm.edu.eld" t t t)

It would then seem that the `load' function under XEmacs doesn't like
ange-ftp file names?  Perhaps you should report this as a bug to the
XEmacs maintainers?

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

------- End of forwarded message -------

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 13:10:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA02334 for xemacs-beta-people; Thu, 19 Sep 1996 13:10:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA02331 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 13:10:51 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA15832 for <xemacs-beta@xemacs.org>; Thu, 19 Sep 1996 13:10:47 -0500 (CDT)
Received: from mordor.rsn.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA079376647; Thu, 19 Sep 1996 11:10:47 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id NAA03767; Thu, 19 Sep 1996 13:15:38 -0500 (CDT)
Date: Thu, 19 Sep 1996 13:15:38 -0500 (CDT)
Message-Id: <199609191815.NAA03767@mordor.rsn.hp.com>
From: Shane Holder <holder@mordor.rsn.hp.com>
To: xemacs-beta@xemacs.org
Subject: 19.15.beta2 success on HP-UX 10.20


Configured for `hppa1.1-hp-hpux10.20'.

  Where should the build process find the source code?    /home/src/xemacs-19.15-b2
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/hpux10.h' and `m/hp800.h'
  What compiler should XEmacs be built with?              gcc  -g -O 
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Additional header files:                                /usr/local/include
  Additional libraries:                                   /usr/local/lib
  Compiling in support for XPM.
  Compiling in support for GIF image conversion.
  Compiling in support for DBM.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Motif dialog boxes.
  Compiling in extra code for debugging.


Also works compiled with CFLAGS="-O3 -g -mschedule=7100"

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 14:03:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA02544 for xemacs-beta-people; Thu, 19 Sep 1996 14:03:46 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA02541 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 14:03:45 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA07581 for <xemacs-beta@cs.uiuc.edu>; Thu, 19 Sep 1996 14:03:38 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id MAA05564; Thu, 19 Sep 1996 12:07:12 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: 19.15-b2 crash on Linux 2.0.18
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: text/plain; charset=US-ASCII
Date: 19 Sep 1996 12:07:04 -0700
Message-ID: <m2g24exr1i.fsf@deanna.miranova.com>
Lines: 119
X-Mailer: Red Gnus v0.35/XEmacs 19.15

This occurred while starting a fresh XEmacs.

Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

Lisp backtrace follows:

  # bind (frame-being-created)
  make-frame((width 60 height 20 popup #<x-frame "emacs" 0x8b8> initially-unmapped t menubar-visible-p nil has-modeline-p nil default-toolbar-visible-p nil modeline-shadow-thickness 0 left 192 top 280))
  # bind (dfwidth dfheight props fontw fonth fheight fwidth fleft ftop parent props)
  make-dialog-frame()
  # bind (butbuff dirbuff filebuf file-p completer initial-contents must-match default dir prompt history)
  mouse-read-file-name-1(file-name-history "Dired (directory): " nil "/home/steve/" nil nil read-file-name-internal)
  # bind (completer initial-contents must-match default dir prompt history)
  read-file-name-1(file-name-history "Dired (directory): " nil "/home/steve/" nil nil read-file-name-internal)
  # bind (history initial-contents must-match default dir prompt)
  read-file-name("Dired (directory): " nil "/home/steve/" nil)
  # bind (str)
  dired-read-dir-and-switches("")
  call-interactively(dired)
  # bind (callback button event)
  release-and-activate-toolbar-button(#<buttonup-event button1up>)
  # bind (command-debug-status)
  call-interactively(release-and-activate-toolbar-button)
  # (condition-case ... . error)
  # (catch top-level ...)

C Backtrace follows:

#0  0x40204741 in __kill ()
#1  0x8081439 in fatal_error_signal (sig=11) at emacs.c:191
#2  0xbfffeda4 in __ypbindlist ()
#3  0x80cd18b in update_frame_title (f=0x8599800) at frame.c:2807
#4  0x815ee35 in x_init_frame_2 (f=0x8599800, props=675435308)
    at frame-x.c:1783
#5  0x80c60a1 in Fmake_frame (props=675435308, device=406354688) at frame.c:495
#6  0x8087971 in primitive_funcall (fn=0x80c5aac <Fmake_frame>, nargs=2, 
    args=0xbfffef4c) at eval.c:3486
#7  0x8087b20 in funcall_subr (subr=0x81d93a8, args=0xbfffef4c) at eval.c:3526
#8  0x80870f5 in funcall_recording_as (recorded_as=405569484, nargs=2, 
    args=0xbfffefac) at eval.c:3207
#9  0x808727b in Ffuncall (nargs=2, args=0xbfffefac) at eval.c:3253
#10 0x806239a in Fbyte_code (bytestr=942022724, vector=1210458336, maxdepth=22)
    at bytecode.c:450
#11 0x8088014 in funcall_lambda (fun=405152168, nargs=0, arg_vector=0xbffff114)
    at eval.c:3636
#12 0x8087176 in funcall_recording_as (recorded_as=405613364, nargs=1, 
    args=0xbffff110) at eval.c:3223
#13 0x808727b in Ffuncall (nargs=1, args=0xbffff110) at eval.c:3253
#14 0x806239a in Fbyte_code (bytestr=941711424, vector=1210147088, maxdepth=8)
    at bytecode.c:450
#15 0x8088014 in funcall_lambda (fun=404841268, nargs=7, #arg_vector=0xbffff240)
    at eval.c:3636
#16 0x8087176 in funcall_recording_as (recorded_as=405612740, nargs=8, 
    args=0xbffff23c) at eval.c:3223
#17 0x808727b in Ffuncall (nargs=8, args=0xbffff23c) at eval.c:3253
#18 0x806239a in Fbyte_code (bytestr=941706460, vector=1210141976, maxdepth=8)
    at bytecode.c:450
#19 0x8088014 in funcall_lambda (fun=404835748, nargs=7, arg_vector=0xbffff36c)
    at eval.c:3636
#20 0x8087176 in funcall_recording_as (recorded_as=405612716, nargs=8, 
    args=0xbffff368) at eval.c:3223
#21 0x808727b in Ffuncall (nargs=8, args=0xbffff368) at eval.c:3253
#22 0x806239a in Fbyte_code (bytestr=941706748, vector=1210142248, maxdepth=8)
    at bytecode.c:450
#23 0x8088014 in funcall_lambda (fun=404835928, nargs=4, arg_vector=0xbffff4a0)
    at eval.c:3636
#24 0x8087176 in funcall_recording_as (recorded_as=405547492, nargs=5, 
    args=0xbffff49c) at eval.c:3223
#25 0x808727b in Ffuncall (nargs=5, args=0xbffff49c) at eval.c:3253
#26 0x806239a in Fbyte_code (bytestr=942664344, vector=1212140032, maxdepth=7)
    at bytecode.c:450
#27 0x8088014 in funcall_lambda (fun=406386948, nargs=1, arg_vector=0xbffff548)
    at eval.c:3636
#28 0x8087bdf in apply_lambda (fun=406386948, numargs=1, 
    unevalled_args=405471236) at eval.c:3559
#29 0x8086ce9 in Feval (form=675048044) at eval.c:3086
#30 0x8063991 in Fcall_interactively (function=406130660, 
    record_flag=405471236, keys=405471236) at callint.c:332
#31 0x8087985 in primitive_funcall (fn=0x8063540 <Fcall_interactively>, 
    nargs=3, args=0xbffff79c) at eval.c:3488
#32 0x8087b20 in funcall_subr (subr=0x81d5078, args=0xbffff79c) at eval.c:3526
#33 0x80870f5 in funcall_recording_as (recorded_as=405547420, nargs=2, 
    args=0xbffff7fc) at eval.c:3207
#34 0x808727b in Ffuncall (nargs=2, args=0xbffff7fc) at eval.c:3253
#35 0x806239a in Fbyte_code (bytestr=942012324, vector=1210447872, maxdepth=4)
    at bytecode.c:450
#36 0x8088014 in funcall_lambda (fun=405141616, nargs=1, arg_vector=0xbffff924)
    at eval.c:3636
#37 0x8087176 in funcall_recording_as (recorded_as=406335388, nargs=2, 
    args=0xbffff920) at eval.c:3223
#38 0x808727b in Ffuncall (nargs=2, args=0xbffff920) at eval.c:3253
#39 0x80652c5 in Fcall_interactively (function=406335388, 
    record_flag=405471236, keys=405471236) at callint.c:902
#40 0x8085e10 in Fcommand_execute (cmd=406335388, record=405471236, 
    keys=405471236) at eval.c:2628
#41 0x80993aa in execute_command_event (command_builder=0x82f2ec0, 
    event=406587744) at event-stream.c:3474
#42 0x809a58b in Fdispatch_event (event=406587744) at event-stream.c:3813
#43 0x8068c57 in Fcommand_loop_1 () at cmdloop.c:542
#44 0x8068973 in command_loop_1 (dummy=405471236) at cmdloop.c:462
#45 0x80844c2 in condition_case_1 (handlers=405471332, 
    bfun=0x8068908 <command_loop_1>, barg=405471236, 
    hfun=0x8067d0c <cmd_error>, harg=405471236) at eval.c:1672
#46 0x8068e08 in command_loop_2 (dummy=405471236) at cmdloop.c:224
#47 0x80842dd in internal_catch (tag=405548452, 
    func=0x8068de8 <command_loop_2>, arg=405471236, threw=0x0) at eval.c:1347
#48 0x80681d2 in initial_command_loop (load_me=405471236) at cmdloop.c:273
#49 0x8081f00 in Frunning_temacs_p () at emacs.c:1315
#50 0x808226e in main (argc=1, argv=0xbffffc1c, envp=0xbffffc24)
    at emacs.c:1459
#51 0x804ee7b in _start ()

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 14:18:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA02592 for xemacs-beta-people; Thu, 19 Sep 1996 14:18:30 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA02589 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 14:18:29 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA07874 for <xemacs-beta@cs.uiuc.edu>; Thu, 19 Sep 1996 14:18:24 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.5/8.6.9) id MAA05830; Thu, 19 Sep 1996 12:20:40 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: Jason Stewart <jasons@cs.unm.edu>
Subject: Re: [Lars Magne Ingebrigtsen <larsi@ifi.uio.no>] Re: ange-ftp, Gnus5, and XEmacs -- revisited
References: <xjnenjycuip.fsf@hawaii.cs.unm.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Jason Stewart's message of 19 Sep 1996 10:57:34 -0600
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: text/plain; charset=US-ASCII
Date: 19 Sep 1996 12:20:39 -0700
Message-ID: <m2d8zixqew.fsf@deanna.miranova.com>
Lines: 128
X-Mailer: Red Gnus v0.35/XEmacs 19.15

>>>>> "Jason" == Jason Stewart <jasons@cs.unm.edu> writes:

Jason> Hi,
Jason> This is from a series of exchanges between Lars and I trying to get
Jason> ange-ftp working with Gnus5 under XEmacs19.13/14. It works perfectly
Jason> under GNU Emacs and we narrowed it down to the following:

Jason> (load "/jasons@chaco.cs.unm.edu:.newsrc-lynx.unm.edu.eld" t t t)

Jason> Which returned nil...

It returns nil for the simple reason that XEmacs does not support this
operation (see the documentation at the top of ange-ftp.el).

Attached is an unofficial patch that adds ange-ftp overloading to the
`load' operation.  Apply this patch, byte compile ange-ftp.el, and
*restart XEmacs* for this to take effect.  This patch will work
against 19.14.

*** ange-ftp.el.orig	Sun Sep  8 16:48:16 1996
--- ange-ftp.el	Thu Sep 19 11:56:48 1996
***************
*** 1461,1466 ****
--- 1461,1547 ----
  		    directory))))
  
  ;;;; ------------------------------------------------------------
+ ;;;; Remote file name syntax support.
+ ;;;; ------------------------------------------------------------
+ (defvar ange-ftp-name-format
+   '("^/\\(\\([^@/:]*\\)@\\)?\\([^@/:]*[^@/:.]\\):\\(.*\\)" . (3 2 4))
+   "*Format of a fully expanded remote file name.
+ This is a list of the form \(REGEXP HOST USER NAME\),
+ where REGEXP is a regular expression matching
+ the full remote name, and HOST, USER, and NAME are the numbers of
+ parenthesized expressions in REGEXP for the components (in that order).")
+ 
+ (defun ange-ftp-real-load (&rest args)
+   (ange-ftp-run-real-handler 'load args))
+ 
+ (defmacro ange-ftp-ftp-name-component (n ns name)
+   "Extract the Nth ftp file name component from NS."
+   (` (let ((elt (nth (, n) (, ns))))
+        (if (match-beginning elt)
+ 	   (substring (, name) (match-beginning elt) (match-end elt))))))
+ 
+ (defvar ange-ftp-ftp-name-arg "")
+ (defvar ange-ftp-ftp-name-res nil)
+ 
+ ;; Parse NAME according to `ange-ftp-name-format' (which see).
+ ;; Returns a list (HOST USER NAME), or nil if NAME does not match the format.
+ (defun ange-ftp-ftp-name (name)
+   (if (string-equal name ange-ftp-ftp-name-arg)
+       ange-ftp-ftp-name-res
+     (setq ange-ftp-ftp-name-arg name
+ 	  ange-ftp-ftp-name-res
+ 	  (save-match-data
+ 	    (if (posix-string-match (car ange-ftp-name-format) name)
+ 		(let* ((ns (cdr ange-ftp-name-format))
+ 		       (host (ange-ftp-ftp-name-component 0 ns name))
+ 		       (user (ange-ftp-ftp-name-component 1 ns name))
+ 		       (name (ange-ftp-ftp-name-component 2 ns name)))
+ 		  (if (zerop (length user))
+ 		      (setq user (ange-ftp-get-user host)))
+ 		  (list host user name))
+ 	      nil)))))
+ 
+ ;; Take a FULLNAME that matches according to ange-ftp-name-format and
+ ;; replace the name component with NAME.
+ (defun ange-ftp-replace-name-component (fullname name)
+   (save-match-data
+     (if (posix-string-match (car ange-ftp-name-format) fullname)
+ 	(let* ((ns (cdr ange-ftp-name-format))
+ 	       (elt (nth 2 ns)))
+ 	  (concat (substring fullname 0 (match-beginning elt))
+ 		  name
+ 		  (substring fullname (match-end elt)))))))
+ 
+ (defun ange-ftp-file-local-copy (file)
+   (let* ((fn1 (expand-file-name file))
+ 	 (pa1 (ange-ftp-ftp-name fn1)))
+     (if pa1
+ 	(let ((tmp1 (ange-ftp-make-tmp-name (car pa1))))
+ 	  (ange-ftp-copy-file-internal fn1 tmp1 t nil
+ 				       (format "Getting %s" fn1))
+ 	  tmp1))))
+ 
+ (defun ange-ftp-load (file &optional noerror nomessage nosuffix)
+   (if (ange-ftp-ftp-name file)
+       (let ((tryfiles (if nosuffix
+ 			  (list file)
+ 			(list (concat file ".elc") (concat file ".el") file)))
+ 	    copy)
+ 	(while (and tryfiles (not copy))
+ 	  (condition-case error
+ 	      (setq copy (ange-ftp-file-local-copy (car tryfiles)))
+ 	    (ftp-error nil))
+ 	  (setq tryfiles (cdr tryfiles)))
+ 	(if copy
+ 	    (unwind-protect
+ 		(funcall 'load copy noerror nomessage nosuffix)
+ 	      (delete-file copy))
+ 	  (or noerror
+ 	      (signal 'file-error (list "Cannot open load file" file)))))
+     (ange-ftp-real-load file noerror nomessage nosuffix)))
+ (put 'load 'ange-ftp 'ange-ftp-load)
+ 
+ ;;;; ------------------------------------------------------------
  ;;;; FTP process filter support.
  ;;;; ------------------------------------------------------------
  
***************
*** 4958,4963 ****
--- 5039,5045 ----
  (ange-ftp-overwrite-fn 'expand-file-name)
  (ange-ftp-overwrite-fn 'file-name-all-completions)
  (ange-ftp-overwrite-fn 'file-name-completion)
+ (ange-ftp-overwrite-fn 'load)
  
  (or (memq 'ange-ftp-set-buffer-mode find-file-hooks)
      (setq find-file-hooks

Regards,
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 18:38:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA03609 for xemacs-beta-people; Thu, 19 Sep 1996 18:38:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA03606 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 18:38:55 -0500 (CDT)
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA16481 for <xemacs-beta@xemacs.org>; Thu, 19 Sep 1996 18:38:51 -0500 (CDT)
Received: from mordor.rsn.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA108516328; Thu, 19 Sep 1996 16:38:48 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id SAA04693; Thu, 19 Sep 1996 18:43:41 -0500 (CDT)
Date: Thu, 19 Sep 1996 18:43:41 -0500 (CDT)
Message-Id: <199609192343.SAA04693@mordor.rsn.hp.com>
From: Shane Holder <holder@mordor.rsn.hp.com>
To: xemacs-beta@xemacs.org
Subject: Info files should be updated

In XEmacs 19.15 [Lucid] (hppa1.1-hp-hpux10.20) of Tue Sep 17 1996 on mordor

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

There are lots of references to frame parameters in the info files,
but from the looks of things XEmacs is moving to using properties.
The info files should be updated.

For example there is no reference to frame-property in the Lispref
files, but the help for frame-parameters say to use frame-property
instead of frame-parameter.

Shane

Recent input:
e C-a m RET C-s p r o p C-f C-s p a r a m C-a m RET 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n m RET M-x g n u s - b u TAB C-a C-k x e 
m TAB b u TAB BS DEL BS DEL TAB C-a C-k r e p TAB o 
TAB r TAB RET I n f o SPC f i l e s SPC s h o u l d 
SPC b e SPC u p d a t e d RET

Recent messages:
Continue...

Saving file /home/holder/lib/xelisp/cscope.el...
Wrote /home/holder/lib/xelisp/cscope.el
Note: file is write protected
CSCOPE: Function: <global>
Note: file is write protected
CSCOPE: Function: <global>
Loading emacsbug...
Loading emacsbug...done

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 21:48:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA04066 for xemacs-beta-people; Thu, 19 Sep 1996 21:48:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA04063 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 21:48:53 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA16627 for <xemacs-beta@xemacs.org>; Thu, 19 Sep 1996 21:48:50 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id TAA22603; Thu, 19 Sep 1996 19:48:21 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id TAA17273; Thu, 19 Sep 1996 19:48:16 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA22979; Thu, 19 Sep 1996 12:12:14 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA04208; Thu, 19 Sep 1996 12:12:13 -0700
Date: Thu, 19 Sep 1996 12:12:13 -0700
Message-Id: <199609191912.MAA04208@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Editing Japanese filenames
In-Reply-To: <199609190414.VAA02267@xemacs.eng.sun.com>
References: <199609190414.VAA02267@xemacs.eng.sun.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>

>>>>> "me" == Martin Buchholz <mrb@Eng> writes:

me> For some reason, the xemacs in my personal workspace can successfully
me> edit non-Latin1 filenames, while 20.0-b29 cannot.  So some patch must
me> have gone awry.  Under investigation.

Apparently, in a ja locale, 20.0-b29 doesn't have
pathname-coding-system to 'euc-japan.  A beta coming soon will have
this rectified, and will also have a function
`set-pathname-coding-system' which does the obvious thing.

If you want to edit files with names encoded in your locale today, do
something like:

(setq pathname-coding-system my-operating-system-coding-system)

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 21:56:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id VAA04079 for xemacs-beta-people; Thu, 19 Sep 1996 21:56:35 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id VAA04076 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 21:56:34 -0500 (CDT)
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id VAA00346 for <xemacs-beta@cs.uiuc.edu>; Thu, 19 Sep 1996 21:56:34 -0500 (CDT)
Received: (qmail 7618 invoked by uid 52477); 20 Sep 1996 02:56:32 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Subject: Success on Linux 2.0.20 and FreeBSD 2.1.0-RELEASE
From: Sudish Joseph <sudish@mindspring.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Date: 19 Sep 1996 22:56:32 -0400
Message-ID: <yviawwxprj1b.fsf@atreides.mindspring.com>
Lines: 7
X-Mailer: Red Gnus v0.37/XEmacs 19.15

Both compiled with:

CFLAGS='-g -O2' ./configure  --with-gcc --with-gnu-make --dynamic=yes \
  --const-is-losing=no --run-in-place --with-x --debug --use-union-type \
  --rel-alloc

-Sudish

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 19 22:38:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA04198 for xemacs-beta-people; Thu, 19 Sep 1996 22:38:22 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA04195 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 19 Sep 1996 22:38:21 -0500 (CDT)
Received: from gol1.gol.com (root@gol1.gol.com [202.243.48.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA16673 for <xemacs-beta@xemacs.org>; Thu, 19 Sep 1996 22:38:18 -0500 (CDT)
Received: from pentagana (jhod@tky3-115.gol.com [202.243.51.115]) by gol1.gol.com (8.7.5/8.6.9) with SMTP id MAA28719; Fri, 20 Sep 1996 12:38:13 +0900 (JST)
Sender: jhod@gol.com
Message-ID: <32420B20.727070D1@po.iijnet.or.jp>
Date: Fri, 20 Sep 1996 12:10:24 +0900
From: Jareth Hein <jhod@po.iijnet.or.jp>
Organization: Sonic Software Planning, Japan
X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.13 i586)
MIME-Version: 1.0
To: Martin Buchholz <mrb@eng.sun.com>,
        XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: 20.0-b29 crash
References: <323FB50C.3D100525@po.iijnet.or.jp> <199609190608.XAA03169@xemacs.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Martin Buchholz wrote:
> 
> >>>>> "Jareth" == Jareth Hein <jhod@po.iijnet.or.jp> writes:
> 
> Jareth> The following crash was observed under IRIX5.3 with MULE enabled.
> 
> Try this patch:
<snip>

That seems to have fixed the problem.
 
> For bonus points, you can explain why this should be necessary.  The
> only way I can imagine this should crash is if the XtNiconName
> resource doesn't apply to the TopLevelShell widget.  Does the icon
> label in fact get set properly on IRIX??

I'll look into this in the near future.

> Martin

--Jareth

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 20 12:44:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA10381 for xemacs-beta-people; Fri, 20 Sep 1996 12:44:23 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA10378 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 20 Sep 1996 12:44:22 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA00893 for <xemacs-beta@cs.uiuc.edu>; Fri, 20 Sep 1996 12:44:21 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id KAA18742; Fri, 20 Sep 1996 10:47:58 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: cc-mode-help@python.org
Subject: [jpabisz@jaguar.East.Sun.COM (John Pabisz - HW Engineer)] http://www.xemacs.org/faq/index.html
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: multipart/mixed;
 boundary="Multipart_Fri_Sep_20_10:47:57_1996-1"
Content-Transfer-Encoding: 7bit
Date: 20 Sep 1996 10:47:57 -0700
Message-ID: <m2iv99ulgy.fsf@deanna.miranova.com>
Lines: 40
X-Mailer: Red Gnus v0.35/XEmacs 19.15

--Multipart_Fri_Sep_20_10:47:57_1996-1
Content-Type: text/plain; charset=US-ASCII

I'm not sure what to do with this, other than forward it here ...

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

--Multipart_Fri_Sep_20_10:47:57_1996-1
Content-Type: message/rfc822

Date: Thu, 19 Sep 1996 12:36:08 -0400
From: jpabisz@jaguar.East.Sun.COM (John Pabisz - HW Engineer)
Message-Id: <199609191636.MAA01054@jaguar.East.Sun.COM>
To: steve@miranova.com
Subject: http://www.xemacs.org/faq/index.html


Hi

A couple things I think would be real nice, and all the engineers I work
with that use xemacs agree:

1.  editing Cfiles - provide a way for xemacs to learn typedefs.  The
    formatting of the syntax with color is simply AWESOME, and would be
    even better if typedefs were highlighted too (we use them often)

2.  editing Verilog files - a huge task I'm sure, but we wish xemacs could
    format verilog files like it does with C/C++ (again, we all use verilog here).


thanks
John Pabisz (EE - Workgroup Servers)
Sun Microsystems, Chemlsford, MA


--Multipart_Fri_Sep_20_10:47:57_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 20 13:24:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA10517 for xemacs-beta-people; Fri, 20 Sep 1996 13:24:54 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA10514 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 20 Sep 1996 13:24:53 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id NAA02553 for <xemacs-beta@cs.uiuc.edu>; Fri, 20 Sep 1996 13:24:51 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id LAA05482; Fri, 20 Sep 1996 11:24:16 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA11995; Fri, 20 Sep 96 14:24:10 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id OAA25064; Fri, 20 Sep 1996 14:24:07 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id OAA00383; Fri, 20 Sep 1996 14:23:43 -0400
Date: Fri, 20 Sep 1996 14:23:43 -0400
Message-Id: <199609201823.OAA00383@detlev.canada.sun.com>
From: Georg Nikodym <georgn@canada.sun.com>
To: xemacs-beta@cs.uiuc.edu, cc-mode-help@python.org
Cc: jpabisz@jaguar.East.Sun.COM
Subject: Re: [jpabisz@jaguar.East.Sun.COM (John Pabisz - HW Engineer)] http://www.xemacs.org/faq/index.html
In-Reply-To: <m2iv99ulgy.fsf@deanna.miranova.com>
References: <m2iv99ulgy.fsf@deanna.miranova.com>
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII

>>>>> "JP" == John Pabisz <jpabisz@jaguar.East.Sun.COM> writes:

 JP> 1.  editing Cfiles - provide a way for xemacs to learn typedefs.
 JP> The formatting of the syntax with color is simply AWESOME, and
 JP> would be even better if typedefs were highlighted too (we use
 JP> them often)

The way John describes this is too hard.  Any halfway decent software
engineer doesn't put typedefs into the same file they're used.
They're generally in headers.  The idea of XEmacs grubbing through the
tangled web of included headers upon loading a file is frightening
(though it might have the side-effect of people only including that
which they need as opposed to everything ;-) .

However, the notion of more colorization is appealing to me so I'll
submit that the various API standards do reserve namespaces for
various things.  For example, POSIX.1a reserves *_t for types.  We
could, in theory, have a font-lock-posix-types-face which matches on
that pattern.  Heck, if I had more time I'd hack that in now!  But I
don't :-(

Anybody out there with a little spare time and some familiarity with
standards?

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 20 17:54:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA11592 for xemacs-beta-people; Fri, 20 Sep 1996 17:54:46 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA11589 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 20 Sep 1996 17:54:45 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA29508 for <xemacs-beta@cs.uiuc.edu>; Fri, 20 Sep 1996 17:54:45 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id RAA12774 for <xemacs-beta@cs.uiuc.edu>; Fri, 20 Sep 1996 17:54:14 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id RAA28274 for <xemacs-beta@cs.uiuc.edu>; Fri, 20 Sep 1996 17:54:14 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id SAA26962 for <xemacs-beta@cs.uiuc.edu>; Fri, 20 Sep 1996 18:54:37 -0400
To: XEmacs Mailing List <xemacs-beta@cs.uiuc.edu>
Subject: 19.15 b2 success on Solaris 2.5
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 20 Sep 1996 18:51:13 -0400
Message-ID: <12371.843259873@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>


Just to say that 19.15 b2 was compiled successfully by patching from
b1 on Solaris 2.5 using gcc 2.7.2, X11R6.1 via

	../../xemacs-19.15/configure  --verbose
	--prefix=/home/unix/toy/apps/XEmacs --with-sound=both
	--srcdir=../../xemacs-19.15
	--site-includes=/apps/public/solaris2.5/include
	/apps/public/solaris2.4/include
	--site-runtime-libraries=/apps/public/solaris2.5/lib
	/apps/public/solaris2.4/lib 

Everything looks just fine, so far.

Ray

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 20 17:52:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id RAA11587 for xemacs-beta-people; Fri, 20 Sep 1996 17:52:27 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA11584 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 20 Sep 1996 17:52:25 -0500 (CDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id RAA29276 for <xemacs-beta@cs.uiuc.edu>; Fri, 20 Sep 1996 17:52:24 -0500 (CDT)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.7.1/8.7.1) with ESMTP id RAA12726; Fri, 20 Sep 1996 17:51:50 -0500 (CDT)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id RAA28256; Fri, 20 Sep 1996 17:51:49 -0500 (CDT)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id SAA26950; Fri, 20 Sep 1996 18:52:13 -0400
To: georgn@canada.sun.com
cc: xemacs-beta@cs.uiuc.edu, cc-mode-help@python.org,
        jpabisz@jaguar.East.Sun.COM
References: <m2iv99ulgy.fsf@deanna.miranova.com>  <199609201823.OAA00383@detlev.canada.sun.com> 
Subject: Re: [jpabisz@jaguar.East.Sun.COM (John Pabisz - HW Engineer)] http://www.xemacs.org/faq/index.html 
In-reply-to: (Your message of Fri, 20 Sep 1996 14:23:43 EDT.)
             <199609201823.OAA00383@detlev.canada.sun.com> 
Mime-Version: 1.0 (generated by tm-edit 7.75)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 20 Sep 1996 18:48:48 -0400
Message-ID: <12363.843259728@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Georg" == Georg Nikodym <georgn@canada.sun.com> writes:

    Georg> However, the notion of more colorization is appealing to me
    Georg> so I'll submit that the various API standards do reserve
    Georg> namespaces for various things.  For example, POSIX.1a
    Georg> reserves *_t for types.  We could, in theory, have a
    Georg> font-lock-posix-types-face which matches on that pattern.
    Georg> Heck, if I had more time I'd hack that in now!  But I don't
    Georg> :-(

I've thought some about this, because it would be nice to have such
highlighting.  My thoughts on how to do this were much simpler: have a
simple API to the fontlock keywords and embed the appropriate lisp
stuff into the file local variables (or whatever they're called---the
stuff that goes at the end of the file to set up some lisp variables, etc.).

The advantage is that it works for whatever strange language I might
be working on.  The disadvantage is that I have to use file local
variables and lisp instead of being automatic.

Is there an API to fontlock to be able to add new fontlock patterns?
There didn't seem to be any when I last looked.  Any thoughts on what
such an API would be like?  Something like (add-to-font-lock-face
facename pattern)?

Ray


From xemacs-beta-request@cs.uiuc.edu  Fri Sep 20 20:41:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id UAA11872 for xemacs-beta-people; Fri, 20 Sep 1996 20:41:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id UAA11869 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 20 Sep 1996 20:41:10 -0500 (CDT)
Received: from omega.IntraNet.com (omega.IntraNet.com [192.148.106.20]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id UAA13509 for <xemacs-beta@cs.uiuc.edu>; Fri, 20 Sep 1996 20:41:07 -0500 (CDT)
Received: by omega.IntraNet.com; (5.65/1.1.8.3/20May95-0100AM)
	id AA00131; Fri, 20 Sep 1996 21:46:57 -0400
Received: by giant.IntraNet.com (DECUS UUCP /2.0/2.0/2.0/);
          Fri, 20 Sep 96 21:41:38 EDT
Received: from blight.IntraNet.com by titan.intranet.com (MX V4.2 VAX) with
          SMTP; Fri, 20 Sep 1996 21:41:36 EDT
Received: (from edwards@localhost) by blight.IntraNet.com (AIX4.2/UCB 8.7/8.7)
          id VAA34294; Fri, 20 Sep 1996 21:36:15 -0400 (EDT)
Date: Fri, 20 Sep 1996 21:36:15 -0400 (EDT)
Message-Id: <199609210136.VAA34294@blight.IntraNet.com>
From: Jonathan Edwards <edwards@blight.IntraNet.com>
To: georgn@canada.sun.com
Cc: xemacs-beta@cs.uiuc.edu, cc-mode-help@python.org,
        jpabisz@jaguar.east.sun.com
Subject: Re: [jpabisz@jaguar.East.Sun.COM (John Pabisz - HW Engineer)]
          http://www.xemacs.org/faq/index.html
In-Reply-To: <199609201823.OAA00383@detlev.canada.sun.com>
References: <m2iv99ulgy.fsf@deanna.miranova.com>
          <199609201823.OAA00383@detlev.canada.sun.com>
X-Face: #bA9Kpw-a@xMyaNJ-2wie(5Lje^S*i^8!VUOF84U!/jSPG*y@3s4Qu+\-FBQ?vQpE1S1<Vo
          TeWVx=wH}wf_WC]x:D%qd,r*|!~q=gVAWEA;T~3V4};X$r7W!FA(#Zj'E7M^(Tv)

Georg Nikodym writes:
> However, the notion of more colorization is appealing to me so I'll
> submit that the various API standards do reserve namespaces for
> various things.  For example, POSIX.1a reserves *_t for types.  We
> could, in theory, have a font-lock-posix-types-face which matches on
> that pattern.  Heck, if I had more time I'd hack that in now!  But I
> don't :-(

The following hack to font-lock.el will treat *_t as a type
name. I find this very useful. 


*** custom-font-lock.el	Fri Jul  5 12:29:00 1996
--- /usr/src/xemacs-19.14/lisp/packages/font-lock.el	Sun Jun  9 11:49:39 1996
***************
*** 1766,1775 ****
         (concat "auto\\|c\\(har\\|onst\\)\\|double\\|e\\(num\\|xtern\\)\\|"
  	       "float\\|int\\|long\\|register\\|"
  	       "s\\(hort\\|igned\\|t\\(atic\\|ruct\\)\\)\\|typedef\\|"
! 	       "un\\(ion\\|signed\\)\\|vo\\(id\\|latile\\)\\|"
! ; CUSTOM: treat _t suffixed names as types.
! 	       "\\sw+_t"
! 	       ))	; 6 ()s deep.
        (c++-keywords
  ;      ("break" "continue" "do" "else" "for" "if" "return" "switch" "while"
  ;	"asm" "catch" "delete" "new" "operator" "sizeof" "this" "throw" "try"
--- 1766,1772 ----
         (concat "auto\\|c\\(har\\|onst\\)\\|double\\|e\\(num\\|xtern\\)\\|"
  	       "float\\|int\\|long\\|register\\|"
  	       "s\\(hort\\|igned\\|t\\(atic\\|ruct\\)\\)\\|typedef\\|"
! 	       "un\\(ion\\|signed\\)\\|vo\\(id\\|latile\\)"))	; 6 ()s deep.
        (c++-keywords
  ;      ("break" "continue" "do" "else" "for" "if" "return" "switch" "while"
  ;	"asm" "catch" "delete" "new" "operator" "sizeof" "this" "throw" "try"
***************
*** 1908,1919 ****
         (1 (if (match-beginning 4)
  	      font-lock-function-name-face
  	    font-lock-variable-name-face))))
- 
-     ;; CUSTOM: Fontify typedefs of _t types properly.
-     (list (concat "^typedef[ \t\\*]+\\(\\sw+[ \t\\*]+\\)+\\(\\sw+\\)[ \t]*;")
- 	  2 'font-lock-variable-name-face t)
- 
- 
      )))
  
   (setq c++-font-lock-keywords-1
--- 1905,1910 ----




From xemacs-beta-request@cs.uiuc.edu  Sat Sep 21 02:42:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA12527 for xemacs-beta-people; Sat, 21 Sep 1996 02:42:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA12524 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 21 Sep 1996 02:42:38 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA18780 for <xemacs-beta@xemacs.org>; Sat, 21 Sep 1996 02:42:36 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id AAA29976; Sat, 21 Sep 1996 00:42:06 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id AAA00209; Sat, 21 Sep 1996 00:42:05 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA21454; Sat, 21 Sep 1996 00:42:04 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA16604; Sat, 21 Sep 1996 00:42:02 -0700
Date: Sat, 21 Sep 1996 00:42:02 -0700
Message-Id: <199609210742.AAA16604@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: big-menubar & friends

I was majorly annoyed that big-menubar was broken, so I broke down and
fixed it.

(add-menu-button) now accepts any valid leaf node, not just vectors.
In particular, you can now add a separator line with 

(add-menu-button menu-path "-----")

I also made big-menubar more rational - many things used to be
duplicated with the `regular' menubar, and there were too many
top-level menus, resulting in exhaustion of screen real estate.

With this change, bugs 3, 135, and 9 will be fixed.

The changes won't be in the next beta, but should be in the one after
that.  So don't go and fix these bugs yourself - there's no shortage
of other juicy bugs :)

Martin



From xemacs-beta-request@cs.uiuc.edu  Sat Sep 21 22:49:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA17905 for xemacs-beta-people; Sat, 21 Sep 1996 22:49:39 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA17902 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 21 Sep 1996 22:49:38 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA24617 for <xemacs-beta@cs.uiuc.edu>; Sat, 21 Sep 1996 22:49:35 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id UAA09153; Sat, 21 Sep 1996 20:52:57 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: forward-to-indentation & backward-to-indentation in simple.el
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: text/plain; charset=US-ASCII
Date: 21 Sep 1996 20:52:52 -0700
Message-ID: <m2d8zfmciz.fsf@deanna.miranova.com>
Lines: 8
X-Mailer: Red Gnus v0.35/XEmacs 19.15

Why aren't these functions defined to keep the zmacs region, or am I
missing something fundamental about zmacs regions?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Sun Sep 22 22:45:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id WAA23711 for xemacs-beta-people; Sun, 22 Sep 1996 22:45:49 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id WAA23708 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 22 Sep 1996 22:45:48 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id WAA20886; Sun, 22 Sep 1996 22:45:45 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id UAA28526; Sun, 22 Sep 1996 20:45:16 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA20032; Sun, 22 Sep 1996 20:45:14 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA09275; Sun, 22 Sep 1996 20:45:13 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA02536; Sun, 22 Sep 1996 20:45:11 -0700
Date: Sun, 22 Sep 1996 20:45:11 -0700
Message-Id: <199609230345.UAA02536@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Chuck Thompson <cthomp@xemacs.org>
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: FIX for Bug 28: modeline %P can cause crash
Reply-To: Martin Buchholz <mrb@eng.sun.com>

I can get XEmacs to crash every time by doing:

(setq modeline-modified '("%P "))
then arrange the scratch buffer so that (point) is at top, and the
bottom of the buffer is not visible.  Then do M-x erase-buffer. BOOM.

This patch removes the crash.  This is not the end of it, however.  It
is disquieting that the value of w->window_end_pos[type] cannot be
relied upon to give a correct value.  

Chuck: perhaps a more fundamental fix is in order (I think this is
your code?)

BTW, this patch also adds in a non-critical missing break statement.

Martin

*** /tmp/geta2519	Sun Sep 22 20:27:34 1996
--- redisplay.c	Sun Sep 22 18:12:21 1996
***************
*** 5805,5810 ****
--- 5805,5811 ----
  #else /* not MSDOS */
        str = "T";
  #endif /* not MSDOS */
+       break;
  
        /* print percent of buffer above top of window, or Top, Bot or All */
      case 'p':
***************
*** 5852,5857 ****
--- 5853,5864 ----
        Bufpos botpos = BUF_Z (b) - w->window_end_pos[type];
        Charcount total = BUF_ZV (b) - BUF_BEGV (b);
  
+       /* botpos is only accurate as of the last redisplay, so we can
+          only treat it as a hint.  In particular, after erase-buffer,
+          botpos may be negative. */
+       if (botpos < toppos)
+ 	botpos = toppos;
+       
        if (botpos >= BUF_ZV (b))
  	{
  	  if (toppos <= BUF_BEGV (b))
***************
*** 5940,5946 ****
    Dynarr_add (mode_spec_bufbyte_string, '\0');
  }
  
! /* Given a display line, free all if its data structures. */
  
  static void
  free_display_line (struct display_line *dl)
--- 5947,5953 ----
    Dynarr_add (mode_spec_bufbyte_string, '\0');
  }
  
! /* Given a display line, free all of its data structures. */
  
  static void
  free_display_line (struct display_line *dl)

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 23 00:26:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id AAA23881 for xemacs-beta-people; Mon, 23 Sep 1996 00:26:29 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA23878 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 23 Sep 1996 00:26:28 -0500 (CDT)
Received: from gol1.gol.com (root@gol1.gol.com [202.243.48.4]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id AAA17572 for <xemacs-beta@cs.uiuc.edu>; Mon, 23 Sep 1996 00:26:28 -0500 (CDT)
Received: from pentagana (jhod@tky2-75.gol.com [202.243.51.75]) by gol1.gol.com (8.7.5/8.6.9) with SMTP id OAA16369; Mon, 23 Sep 1996 14:26:01 +0900 (JST)
Sender: jhod@gol.com
Message-ID: <324618D0.51C29FB2@po.iijnet.or.jp>
Date: Mon, 23 Sep 1996 13:57:52 +0900
From: Jareth Hein <jhod@po.iijnet.or.jp>
Organization: Sonic Software Planning, Japan
X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.13 i586)
MIME-Version: 1.0
To: Raymond Toy <toy@rtp.ericsson.se>
CC: georgn@canada.sun.com, xemacs-beta@cs.uiuc.edu, cc-mode-help@python.org,
        jpabisz@jaguar.East.Sun.COM
Subject: Re: [jpabisz@jaguar.East.Sun.COM (John Pabisz - HW Engineer)] http://www.xemacs.org/faq/index.html
References: <m2iv99ulgy.fsf@deanna.miranova.com>  <199609201823.OAA00383@detlev.canada.sun.com> <12363.843259728@rtp.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Raymond Toy wrote:
> 
> >>>>> "Georg" == Georg Nikodym <georgn@canada.sun.com> writes:
> 
>     Georg> However, the notion of more colorization is appealing to me
>     Georg> so I'll submit that the various API standards do reserve
>     Georg> namespaces for various things.  For example, POSIX.1a
>     Georg> reserves *_t for types.  We could, in theory, have a
>     Georg> font-lock-posix-types-face which matches on that pattern.
>     Georg> Heck, if I had more time I'd hack that in now!  But I don't
>     Georg> :-(
> 
> I've thought some about this, because it would be nice to have such
> highlighting.  My thoughts on how to do this were much simpler: have a
> simple API to the fontlock keywords and embed the appropriate lisp
> stuff into the file local variables (or whatever they're called---the
> stuff that goes at the end of the file to set up some lisp variables, etc.).
> 
> The advantage is that it works for whatever strange language I might
> be working on.  The disadvantage is that I have to use file local
> variables and lisp instead of being automatic.
> 
> Is there an API to fontlock to be able to add new fontlock patterns?
> There didn't seem to be any when I last looked.  Any thoughts on what
> such an API would be like?  Something like (add-to-font-lock-face
> facename pattern)?
> 
> Ray

What about the posibility of doing things similar to the way ispell.el
deals with file local dictionaries in TeX mode? At the end of the tex
file you can create a comment line that contains the cookie "Localwords:
" and anything else on the line is treated as a word for the spell
process. This could be extended into font lock as a "Fontlock
(modename): " type cookie that would allow keys of all kinds to be given
a specific face in a user-friendly, non-obtrusive manner. Hmmm. I'll
look into adding this...

--Jareth

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 23 10:51:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA28772 for xemacs-beta-people; Mon, 23 Sep 1996 10:51:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA28769 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 23 Sep 1996 10:51:39 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id KAA05054 for <xemacs-beta@cs.uiuc.edu>; Mon, 23 Sep 1996 10:51:38 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id IAA13491; Mon, 23 Sep 1996 08:51:02 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
	id AA22236; Mon, 23 Sep 96 10:54:51 EDT
Received: from detlev.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id KAA17760; Mon, 23 Sep 1996 10:54:48 -0400
Received: by detlev.canada.sun.com (SMI-8.6/SMI-SVR4)
	id KAA02109; Mon, 23 Sep 1996 10:54:24 -0400
Date: Mon, 23 Sep 1996 10:54:24 -0400
Message-Id: <199609231454.KAA02109@detlev.canada.sun.com>
From: Georg Nikodym <georgn@canada.sun.com>
To: xemacs-beta@cs.uiuc.edu
Cc: jpabisz@jaguar.East.Sun.COM
Subject: Re: [jpabisz@jaguar.East.Sun.COM (John Pabisz - HW Engineer)] http://www.xemacs.org/faq/index.html
In-Reply-To: <324618D0.51C29FB2@po.iijnet.or.jp>
References: <m2iv99ulgy.fsf@deanna.miranova.com>
	<199609201823.OAA00383@detlev.canada.sun.com>
	<12363.843259728@rtp.ericsson.se>
	<324618D0.51C29FB2@po.iijnet.or.jp>
Reply-To: georgn@canada.sun.com
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo
Mime-Version: 1.0 (generated by tm-edit 7.64)
Content-Type: text/plain; charset=US-ASCII

>>>>> "JH" == Jareth Hein <jhod@po.iijnet.or.jp> writes:

 JH> What about the posibility of doing things similar to the way
 JH> ispell.el deals with file local dictionaries in TeX mode? At the
 JH> end of the tex file you can create a comment line that contains
 JH> the cookie "Localwords: " and anything else on the line is
 JH> treated as a word for the spell process. This could be extended
 JH> into font lock as a "Fontlock (modename): " type cookie that
 JH> would allow keys of all kinds to be given a specific face in a
 JH> user-friendly, non-obtrusive manner. Hmmm. I'll look into adding
 JH> this...

Sir, as stated this idea is unworkable for two reasons.

  a) Program source code tends to be a little more voluminous that TeX
     files.  The OS & Net portion of the source for Solaris lives in
     approximately 16000 files.  Your proposition simply does not
     scale.
  b) For code that you don't own, littering little turds that are of
     interest to *emacs weenies like us would likely be seen as rude.

However, your idea has re-awakened a need in XEmacs for the notion of
projects or worksets or some other mode of partitioning.  With the
notion of discreet environments, there could be a configuration file
associated with each environment and it would be in this file that the
guts of your idea would belong and be useful.

With all the work that went into specifiers, I think that this could
actually be done.  I'm thinking that things like font-lock-keywords
could be specifiers instead of buffer local variables and the unique
bits would be associated with the specifiers locale (or project ;-)

Am I nuts?

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 23 12:25:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id MAA29206 for xemacs-beta-people; Mon, 23 Sep 1996 12:25:13 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA29203 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 23 Sep 1996 12:25:12 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id MAA08032 for <xemacs-beta@cs.uiuc.edu>; Mon, 23 Sep 1996 12:25:09 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id KAA23180; Mon, 23 Sep 1996 10:28:25 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Showing keybindings at completion time (Patch to icomplete.el)
References: <kigvidfhi40.fsf@jagor.srce.hr> 	<m2d8znz5ls.fsf@deanna.miranova.com> <kigpw3msrmm.fsf@jagor.srce.hr> <m2sp8ifdrq.fsf@deanna.miranova.com> <87n2yqi2o1.fsf@atreides.mindspring.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Sudish Joseph's message of 16 Sep 1996 17:13:34 -0400
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: text/plain; charset=US-ASCII
Date: 23 Sep 1996 10:28:23 -0700
Message-ID: <m2sp8916q0.fsf@deanna.miranova.com>
Lines: 48
X-Mailer: Red Gnus v0.40/XEmacs 19.15

>>>>> "Sudish" == Sudish Joseph <sj@atreides.mindspring.com> writes:

Sudish> Steven L Baur <steve@miranova.com> writes:
sb> There's also a real bug in it that's activated with certain Gnus
sb> prompts -- the prefix offered by Gnus is ignored, and GNU Emacs 19.34
sb> gets it right.

Sudish> This is a general problem with the interaction between completing-read
Sudish> and icomplete.  Here's the bug report I posted to comp.emacs.xemacs
Sudish> some time back.
 [*Excellent* bug report deleted]
Sudish> Does anyone have a fix/workaround?

I do not pretend to deep understanding of how this portion of XEmacs
and GNU Emacs works, but I was able to trace the problem and come up
with a work around.

For whatever reason, GNU Emacs arranges to have post-command-hook
called prior to accepting minibuffer input, and XEmacs does not.  When
processing minibuffer input with an initial value, icomplete loses
horribly unless icomplete-exhibit (bound to post-command-hook) is
called first, otherwise, icomplete-tidy (bound to pre-command-hook)
gets called and thinks that the initial value is garbage left over
from icomplete-exhibit and silently deletes it. :-(

Please apply the following patch to icomplete.el and see if it works
any better for you.

*** packages/icomplete.el.1	Tue Sep 17 11:05:00 1996
--- packages/icomplete.el	Mon Sep 23 10:13:37 1996
***************
*** 91,96 ****
--- 91,99 ----
  will constrain rsz-mini to a maximum minibuffer height of 3 lines when
  icompletion is occurring.")
  
+ (if (string-match "XEmacs\\|Lucid" emacs-version)
+     (add-hook 'icomplete-minibuffer-setup-hook 'icomplete-exhibit))
+ 
  ;;;_ + Internal Variables
  ;;;_  = icomplete-mode
  (defvar icomplete-mode t

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 23 14:14:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id OAA29641 for xemacs-beta-people; Mon, 23 Sep 1996 14:14:27 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id OAA29638 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 23 Sep 1996 14:14:16 -0500 (CDT)
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id OAA11937 for <xemacs-beta@cs.uiuc.edu>; Mon, 23 Sep 1996 14:14:12 -0500 (CDT)
Received: (qmail 954 invoked by uid 52477); 23 Sep 1996 19:14:03 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Subject: Re: Showing keybindings at completion time (Patch to icomplete.el)
References: <kigvidfhi40.fsf@jagor.srce.hr> 	<m2d8znz5ls.fsf@deanna.miranova.com> <kigpw3msrmm.fsf@jagor.srce.hr> <m2sp8ifdrq.fsf@deanna.miranova.com> <87n2yqi2o1.fsf@atreides.mindspring.com> <m2sp8916q0.fsf@deanna.miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sudish@mindspring.com>
Date: 23 Sep 1996 15:14:03 -0400
In-Reply-To: Steven L Baur's message of 23 Sep 1996 10:28:23 -0700
Message-ID: <yviapw3d3uys.fsf@atreides.mindspring.com>
Lines: 8
X-Mailer: Red Gnus v0.37/XEmacs 19.15

Steven L Baur <steve@miranova.com> writes:
> Please apply the following patch to icomplete.el and see if it works
> any better for you.

The patch fixes things for me.  Major coolness.

Tx,
-Sudish

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 23 18:41:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id SAA00594 for xemacs-beta-people; Mon, 23 Sep 1996 18:41:24 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA00591 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 23 Sep 1996 18:41:23 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id SAA25058 for <xemacs-beta@cs.uiuc.edu>; Mon, 23 Sep 1996 18:41:21 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id QAA26547; Mon, 23 Sep 1996 16:44:45 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: 2 Identical crashes, XEmacs 19.15-b2 (sort of), Linux 2.0.21
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.86)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 23 Sep 1996 16:44:44 -0700
Message-ID: <m23f08hk43.fsf@deanna.miranova.com>
Lines: 66
X-Mailer: Red Gnus v0.41/XEmacs 19.15

I have experienced the same identical crash today after logging in via
xdm, and starting XEmacs, and Red Gnus.  No coredump in either case,
so no C stack backtrace. :-(  Immediately restarting a fresh copy of
XEmacs and Red Gnus works as usual.

misc-mail-0 is a 1.9 MB Unix mail folder, last modified in late May.
I have a 5 MB mail folder that XEmacs has never crashed on.  No
coredump, no messages in syslog, etc.  Signal 7 is SIGBUS in Linux 2.

Fatal error (7).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
 ...
Lisp backtrace follows:

  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  insert-file-contents-internal("/home/steve/Mail/archive/misc-mail-0" t nil nil nil)
  # bind (replace end beg visit filename)
  ange-ftp-real-insert-file-contents("/home/steve/Mail/archive/misc-mail-0" t nil nil nil)
  # bind (parsed replace end beg visit filename)
  insert-file-contents("/home/steve/Mail/archive/misc-mail-0" t nil nil nil)
  # bind (format-alist after-insert-file-functions replace end beg visit filename)
  nnheader-insert-file-contents-literally("/home/steve/Mail/archive/misc-mail-0" t)
  # (condition-case ... . ((file-error (byte-code "" ... 1))))
  # (unwind-protect ...)
  # bind (error other number truename buf rawfile nowarn filename)
  nnheader-find-file-noselect("/home/steve/Mail/archive/misc-mail-0" nil raw)
  # (unwind-protect ...)
  # bind (scantime modtime scanning file)
  nnfolder-read-folder("/home/steve/Mail/archive/misc-mail-0" t)
  # (unwind-protect ...)
  # bind (inf file scanning server group)
  nnfolder-possibly-change-group("misc-mail-0" "archive" t)
  # bind (server group)
  nnfolder-request-scan("misc-mail-0" "archive")
  # bind (method method group)
  gnus-request-scan("nnfolder+archive:misc-mail-0" (nnfolder "archive" (nnfolder-directory "~/Mail/archive/") (nnfolder-active-file "~/Mail/archive/active") (nnfolder-get-new-mail nil) (nnfolder-inhibit-expiry t) (nnfolder-address "archive")))
  # bind (method active method dont-check scan group)
  gnus-activate-group("nnfolder+archive:misc-mail-0" scan)
  # bind (method active group info foreign-level level newsrc level)
  gnus-get-unread-articles(nil)
  # bind (gnus-read-active-file init dont-connect level rawfile)
  gnus-setup-news(nil nil nil)
  byte-code("	 !!	  \"#! ! ч" [dont-connect did-connect gnus-group-quit run-hooks gnus-startup-hook gnus-make-newsrc-file gnus-startup-file gnus-current-startup-file gnus-slave gnus-use-dribble-file gnus-dribble-read-file gnus-use-grouplens bbb-login add-hook gnus-summary-mode-hook gnus-grouplens-mode gnus-setup-news nil level gnus-group-list-groups gnus-group-first-unread-group gnus-configure-windows group gnus-group-set-mode-line] 4)
  # bind (level did-connect slave dont-connect arg)
  gnus-1(nil nil nil)
  # bind (slave dont-connect arg)
  gnus(nil)
  # bind (command-debug-status)
  call-interactively(gnus)
  command-execute(gnus t)
  # bind (prefix-arg)
  execute-extended-command(nil)
  # bind (command-debug-status)
  call-interactively(execute-extended-command)
  # (condition-case ... . error)
  # (catch top-level ...)


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 23 19:28:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA00675 for xemacs-beta-people; Mon, 23 Sep 1996 19:28:34 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA00672 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 23 Sep 1996 19:28:33 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA29114 for <xemacs-beta@cs.uiuc.edu>; Mon, 23 Sep 1996 19:28:29 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA00348; Mon, 23 Sep 1996 17:27:58 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA18385; Mon, 23 Sep 1996 17:27:03 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA27742; Mon, 23 Sep 1996 17:26:43 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA05829; Mon, 23 Sep 1996 17:26:43 -0700
Date: Mon, 23 Sep 1996 17:26:43 -0700
Message-Id: <199609240026.RAA05829@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: georgn@canada.sun.com
Cc: xemacs-beta@cs.uiuc.edu, jpabisz@jaguar.East.Sun.COM
Subject: Re: [jpabisz@jaguar.East.Sun.COM (John Pabisz - HW Engineer)] http://www.xemacs.org/faq/index.html
In-Reply-To: <199609231454.KAA02109@detlev.canada.sun.com>
References: <m2iv99ulgy.fsf@deanna.miranova.com>
	<199609201823.OAA00383@detlev.canada.sun.com>
	<12363.843259728@rtp.ericsson.se>
	<324618D0.51C29FB2@po.iijnet.or.jp>
	<199609231454.KAA02109@detlev.canada.sun.com>
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Georg" == Georg Nikodym <georgn@canada> writes:


Georg> With all the work that went into specifiers, I think that this could
Georg> actually be done.  I'm thinking that things like font-lock-keywords
Georg> could be specifiers instead of buffer local variables and the unique
Georg> bits would be associated with the specifiers locale (or project ;-)

Georg> Am I nuts?

I'm not sure what the gain would be from using specifiers instead of
simply buffer-local variables.  These really are just
buffer-dependent, and not window, frame, or device-dependent.
Implementing a hook to modify font-lock-keywords in a
project-dependent (== pathname-dependent?) way shouldn't be too hard.

Martin

From xemacs-beta-request@cs.uiuc.edu  Mon Sep 23 19:53:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id TAA00738 for xemacs-beta-people; Mon, 23 Sep 1996 19:53:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id TAA00735 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 23 Sep 1996 19:53:41 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id TAA22694 for <xemacs-beta@xemacs.org>; Mon, 23 Sep 1996 19:53:37 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id RAA06807; Mon, 23 Sep 1996 17:53:08 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA24558; Mon, 23 Sep 1996 17:52:15 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA26055; Mon, 23 Sep 1996 16:11:25 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA05292; Mon, 23 Sep 1996 16:11:23 -0700
Date: Mon, 23 Sep 1996 16:11:23 -0700
Message-Id: <199609232311.QAA05292@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: PATCH: (string-match "[^a]" non-ascii-string) crash
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: text/plain; charset=US-ASCII

This is, I believe, the REAL fix for the crash reported by MORIOKA
Tomohiko.  This is very important for tm support in XEmacs 20.0.
In a beta sometime, perhaps not right away.

Martin

*** /tmp/geta5281	Mon Sep 23 16:08:36 1996
--- regex.c	Sun Sep 22 23:19:14 1996
***************
*** 4566,4572 ****
  	    if (!not) goto fail;
              
  	    SET_REGS_MATCHED ();
!             d++;
  	    break;
  	  }
  
--- 4566,4572 ----
  	    if (!not) goto fail;
              
  	    SET_REGS_MATCHED ();
!             INC_CHARPTR (d); /* XEmacs change */
  	    break;
  	  }
  

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 24 02:36:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id CAA01543 for xemacs-beta-people; Tue, 24 Sep 1996 02:36:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id CAA01540 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 24 Sep 1996 02:36:38 -0500 (CDT)
Received: from maes.esrin.esa.it (maes.esrin.esa.it [192.106.252.50]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id CAA21271 for <xemacs-beta@cs.uiuc.edu>; Tue, 24 Sep 1996 02:36:15 -0500 (CDT)
Received: from mail.esrin.esa.it (plod.esrin.esa.it) by maes.esrin.esa.it with SMTP id AA28757
  (5.65c/IDA-1.4.4 for <xemacs-beta@cs.uiuc.edu>); Tue, 24 Sep 1996 09:36:24 +0200
Received: from penelope.esa.it by mail.esrin.esa.it (4.1/SMI-4.1)
	id AA03190; Tue, 24 Sep 96 07:39:00 GMT
Date: Tue, 24 Sep 96 07:39:00 GMT
Message-Id: <9609240739.AA03190@mail.esrin.esa.it>
Received: by penelope.esa.it (4.1/SMI-4.1)
	id AA01009; Tue, 24 Sep 96 09:39:07 +0200
From: Simon Marshall <Simon.Marshall@esrin.esa.it>
To: mrb@eng.sun.com
Cc: georgn@canada.sun.com, xemacs-beta@cs.uiuc.edu,
        jpabisz@jaguar.east.sun.com
In-Reply-To: <199609240026.RAA05829@xemacs.eng.sun.com> (message from Martin
	Buchholz on Mon, 23 Sep 1996 17:26:43 -0700)
Subject: Re: [jpabisz@jaguar.East.Sun.COM (John Pabisz - HW Engineer)] http://www.xemacs.org/faq/index.html
Reply-To: Simon Marshall <Simon.Marshall@esrin.esa.it>

Georg> With all the work that went into specifiers, I think that this
Georg> could actually be done.  I'm thinking that things like
Georg> font-lock-keywords could be specifiers instead of buffer local
Georg> variables and the unique bits would be associated with the
Georg> specifiers locale (or project ;-)

Martin> I'm not sure what the gain would be from using specifiers instead
Martin> of simply buffer-local variables.  These really are just
Martin> buffer-dependent, and not window, frame, or device-dependent.
Martin> Implementing a hook to modify font-lock-keywords in a
Martin> project-dependent (== pathname-dependent?) way shouldn't be too
Martin> hard.

Right, and the functionality (to allow per-buffer processing to snarf up
keywords) already exists.  It's just that noone has bothered writing code
to, say, parse a C file to find all types defined in the file or in files
included from it.  Probably you can guess why!

Functionality for adding keywords easily does not exist, though I've
played around with it in the past.

Simon.


From xemacs-beta-request@cs.uiuc.edu  Tue Sep 24 08:06:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id IAA05742 for xemacs-beta-people; Tue, 24 Sep 1996 08:06:27 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id IAA05739 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 24 Sep 1996 08:06:26 -0500 (CDT)
Received: from chekov.ctd.comsat.com (exim@chekov.ctd.comsat.com [134.133.40.22]) by a.cs.uiuc.edu (8.7.5/8.7.3) with SMTP id IAA27362 for <xemacs-beta@cs.uiuc.edu>; Tue, 24 Sep 1996 08:06:26 -0500 (CDT)
Received: from neal by chekov.ctd.comsat.com with local (Exim 0.56 #3)
	id E0v5XBw-0007JM-00; Tue, 24 Sep 1996 09:06:24 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: Gnus v5.2.40 buglet
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0v5XBw-0007JM-00@chekov.ctd.comsat.com>
Date: Tue, 24 Sep 1996 09:06:24 -0400

It appears that if:

1) You need movemail setgid mail

2) You use gnusv5.2.40 to get mail

3) You forget to move movemail setgid mail

Then gnus silently fails to get your mail, instead of giving a loud
warning (like VM does).

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 24 10:52:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA06258 for xemacs-beta-people; Tue, 24 Sep 1996 10:52:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA06255 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 24 Sep 1996 10:52:50 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA01971 for <xemacs-beta@cs.uiuc.edu>; Tue, 24 Sep 1996 10:52:47 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id IAA29899; Tue, 24 Sep 1996 08:56:11 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: 2 More crashes, 19.15-b2
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.86)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 24 Sep 1996 08:56:10 -0700
Message-ID: <m2ybhz29gl.fsf@deanna.miranova.com>
Lines: 158
X-Mailer: Red Gnus v0.41/XEmacs 19.15

[This is similar to the two crashes documented yesterday, complete
with no core file].

Fatal error (7).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

 ...

Lisp backtrace follows:

  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  insert-file-contents-internal("/home/steve/Mail/archive/misc-mail-2" t nil nil nil)
  # bind (replace end beg visit filename)
  ange-ftp-real-insert-file-contents("/home/steve/Mail/archive/misc-mail-2" t nil nil nil)
  # bind (parsed replace end beg visit filename)
  insert-file-contents("/home/steve/Mail/archive/misc-mail-2" t nil nil nil)
  # bind (format-alist after-insert-file-functions replace end beg visit filename)
  nnheader-insert-file-contents-literally("/home/steve/Mail/archive/misc-mail-2" t)
  # (condition-case ... . ((file-error (byte-code "" ... 1))))
  # (unwind-protect ...)
  # bind (error other number truename buf rawfile nowarn filename)
  nnheader-find-file-noselect("/home/steve/Mail/archive/misc-mail-2" nil raw)
  # (unwind-protect ...)
  # bind (scantime modtime scanning file)
  nnfolder-read-folder("/home/steve/Mail/archive/misc-mail-2" t)
  # (unwind-protect ...)
  # bind (inf file scanning server group)
  nnfolder-possibly-change-group("misc-mail-2" "archive" t)
  # bind (server group)
  nnfolder-request-scan("misc-mail-2" "archive")
  # bind (method method group)
  gnus-request-scan("nnfolder+archive:misc-mail-2" (nnfolder "archive" (nnfolder-directory "~/Mail/archive/") (nnfolder-active-file "~/Mail/archive/active") (nnfolder-get-new-mail nil) (nnfolder-inhibit-expiry t) (nnfolder-address "archive")))
  # bind (method active method dont-check scan group)
  gnus-activate-group("nnfolder+archive:misc-mail-2" scan)
  # bind (method active group info foreign-level level newsrc level)
  gnus-get-unread-articles(nil)
  # bind (gnus-read-active-file init dont-connect level rawfile)
  gnus-setup-news(nil nil nil)
  byte-code("	 !!	  \"#! ! ч" [dont-connect did-connect gnus-group-quit run-hooks gnus-startup-hook gnus-make-newsrc-file gnus-startup-file gnus-current-startup-file gnus-slave gnus-use-dribble-file gnus-dribble-read-file gnus-use-grouplens bbb-login add-hook gnus-summary-mode-hook gnus-grouplens-mode gnus-setup-news nil level gnus-group-list-groups gnus-group-first-unread-group gnus-configure-windows group gnus-group-set-mode-line] 4)
  # bind (level did-connect slave dont-connect arg)
  gnus-1(nil nil nil)
  # bind (slave dont-connect arg)
  gnus(nil)
  # bind (command-debug-status)
  call-interactively(gnus)
  command-execute(gnus t)
  # bind (prefix-arg)
  execute-extended-command(nil)
  # bind (command-debug-status)
  call-interactively(execute-extended-command)
  # (condition-case ... . error)
  # (catch top-level ...)


Crash #2.  Obtained when attempting to insert a MIME file with tm7.86.


Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

 ...

Lisp backtrace follows:

  # bind (frame-being-created)
  make-frame((width 60 height 20 popup #<x-frame "emacs" 0x8ca> initially-unmapped t menubar-visible-p nil has-modeline-p nil default-toolbar-visible-p nil modeline-shadow-thickness 0 left 582 top 225))
  # bind (dfwidth dfheight props fontw fonth fheight fwidth fleft ftop parent props)
  make-dialog-frame()
  # bind (butbuff dirbuff filebuf file-p completer initial-contents must-match default dir prompt history)
  mouse-read-file-name-1(file-name-history "Insert file as MIME message: " nil nil 0 nil read-file-name-internal)
  # bind (completer initial-contents must-match default dir prompt history)
  read-file-name-1(file-name-history "Insert file as MIME message: " nil nil 0 nil read-file-name-internal)
  # bind (history initial-contents must-match default dir prompt)
  read-file-name("Insert file as MIME message: " nil nil 0)
  call-interactively(mime-editor/insert-file)
  # (condition-case ... . error)
  # (catch top-level ...)


C Backtrace follows:

#0  0x40204741 in __kill ()
#1  0x8081439 in fatal_error_signal (sig=11) at emacs.c:191
#2  0xbffff180 in __ypbindlist ()
#3  0x80cd18b in update_frame_title (f=0x88fc800) at frame.c:2807
#4  0x815ee35 in x_init_frame_2 (f=0x88fc800, props=680056940)
    at frame-x.c:1783
#5  0x80c60a1 in Fmake_frame (props=680056940, device=406277376) at frame.c:495
#6  0x8087971 in primitive_funcall (fn=0x80c5aac <Fmake_frame>, nargs=2, 
    args=0xbffff328) at eval.c:3486
#7  0x8087b20 in funcall_subr (subr=0x81d93a8, args=0xbffff328) at eval.c:3526
#8  0x80870f5 in funcall_recording_as (recorded_as=405569484, nargs=2, 
    args=0xbffff388) at eval.c:3207
#9  0x808727b in Ffuncall (nargs=2, args=0xbffff388) at eval.c:3253
#10 0x806239a in Fbyte_code (bytestr=942032176, vector=1210467788, maxdepth=22)
    at bytecode.c:450
#11 0x8088014 in funcall_lambda (fun=405161620, nargs=0, arg_vector=0xbffff4f0)
    at eval.c:3636
#12 0x8087176 in funcall_recording_as (recorded_as=406132084, nargs=1, 
    args=0xbffff4ec) at eval.c:3223
#13 0x808727b in Ffuncall (nargs=1, args=0xbffff4ec) at eval.c:3253
#14 0x806239a in Fbyte_code (bytestr=941713224, vector=1210148888, maxdepth=8)
    at bytecode.c:450
#15 0x8088014 in funcall_lambda (fun=404843068, nargs=7, arg_vector=0xbffff61c)
    at eval.c:3636
#16 0x8087176 in funcall_recording_as (recorded_as=406131460, nargs=8, 
    args=0xbffff618) at eval.c:3223
#17 0x808727b in Ffuncall (nargs=8, args=0xbffff618) at eval.c:3253
#18 0x806239a in Fbyte_code (bytestr=941708260, vector=1210143776, maxdepth=8)
    at bytecode.c:450
#19 0x8088014 in funcall_lambda (fun=404837548, nargs=7, arg_vector=0xbffff748)
    at eval.c:3636
#20 0x8087176 in funcall_recording_as (recorded_as=406131436, nargs=8, 
    args=0xbffff744) at eval.c:3223
#21 0x808727b in Ffuncall (nargs=8, args=0xbffff744) at eval.c:3253
#22 0x806239a in Fbyte_code (bytestr=941708548, vector=1210144048, maxdepth=8)
    at bytecode.c:450
#23 0x8088014 in funcall_lambda (fun=404837728, nargs=4, arg_vector=0xbffff870)
    at eval.c:3636
#24 0x8087176 in funcall_recording_as (recorded_as=405547492, nargs=5, 
    args=0xbffff86c) at eval.c:3223
#25 0x8088911 in call4 (fn=405547492, arg0=947855976, arg1=405471236, 
    arg2=405471236, arg3=0) at eval.c:3253
#26 0x80647d6 in Fcall_interactively (function=408294820, 
    record_flag=405471236, keys=405471236) at callint.c:691
#27 0x8087985 in primitive_funcall (fn=0x8063540 <Fcall_interactively>, 
    nargs=3, args=0xbffff9c0) at eval.c:3488
#28 0x8087b20 in funcall_subr (subr=0x81d5078, args=0xbffff9c0) at eval.c:3526
#29 0x80870f5 in funcall_recording_as (recorded_as=405547420, nargs=2, 
    args=0xbffffa10) at eval.c:3207
#30 0x80887ec in call1 (fn=405547420, arg0=408294820) at eval.c:3253
#31 0x8099390 in execute_command_event (command_builder=0x82f2ec0, 
    event=411125764) at event-stream.c:3467
#32 0x809a58b in Fdispatch_event (event=411125764) at event-stream.c:3813
#33 0x8068c57 in Fcommand_loop_1 () at cmdloop.c:542
#34 0x8068973 in command_loop_1 (dummy=405471236) at cmdloop.c:462
#35 0x80844c2 in condition_case_1 (handlers=405471332, 
    bfun=0x8068908 <command_loop_1>, barg=405471236, 
    hfun=0x8067d0c <cmd_error>, harg=405471236) at eval.c:1672
#36 0x8068e08 in command_loop_2 (dummy=405471236) at cmdloop.c:224
#37 0x80842dd in internal_catch (tag=405548452, 
    func=0x8068de8 <command_loop_2>, arg=405471236, threw=0x0) at eval.c:1347
#38 0x80681d2 in initial_command_loop (load_me=405471236) at cmdloop.c:273
#39 0x8081f00 in Frunning_temacs_p () at emacs.c:1315
#40 0x808226e in main (argc=1, argv=0xbffffc1c, envp=0xbffffc24)
    at emacs.c:1459
#41 0x804ee7b in _start ()


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 24 10:56:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id KAA06270 for xemacs-beta-people; Tue, 24 Sep 1996 10:56:06 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA06267 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 24 Sep 1996 10:56:05 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id KAA02062 for <xemacs-beta@cs.uiuc.edu>; Tue, 24 Sep 1996 10:55:59 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id IAA29919; Tue, 24 Sep 1996 08:59:24 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Emacs 19.34 and smtpmail.el
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.86)
Content-Type: multipart/mixed;
 boundary="Multipart_Tue_Sep_24_08:59:23_1996-1"
Content-Transfer-Encoding: 7bit
Date: 24 Sep 1996 08:59:23 -0700
Message-ID: <m2vid329b8.fsf@deanna.miranova.com>
Lines: 551
X-Mailer: Red Gnus v0.41/XEmacs 19.15

--Multipart_Tue_Sep_24_08:59:23_1996-1
Content-Type: text/plain; charset=US-ASCII

We need this feature.  Here is a version adapted for XEmacs 19.15.


--Multipart_Tue_Sep_24_08:59:23_1996-1
Content-Type: application/octet-stream; type=emacs-lisp
Content-Disposition: attachment; filename="smtpmail.el"
Content-Transfer-Encoding: 7bit

;; Simple SMTP protocol (RFC 821) for sending mail

;; Copyright (C) 1995, 1996 Free Software Foundation, Inc.

;; Author: Tomoji Kagatani <kagatani@rbc.ncl.omron.co.jp>
;; Maintainer: Brian D. Carlstrom <bdc@ai.mit.edu>
;; Keywords: mail

;; This file is part of XEmacs.

;; XEmacs is free software; you can redistribute it and/or modify it
;; under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; XEmacs is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with XEmacs; see the file COPYING.  If not, write to the Free
;; Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
;; 02111-1307, USA.

;;; Synched up with: FSF 19.34.

;;; Commentary:

;; Send Mail to smtp host from smtpmail temp buffer.

;; Please add these lines in your .emacs(_emacs).
;;
;;(setq send-mail-function 'smtpmail-send-it)
;;(setq smtpmail-default-smtp-server "YOUR SMTP HOST")
;;(setq smtpmail-smtp-service "smtp")
;;(setq smtpmail-local-domain "YOUR DOMAIN NAME")
;;(setq smtpmail-debug-info t)
;;(load-library "smtpmail")
;;(setq smtpmail-code-conv-from nil)
;;(setq user-full-name "YOUR NAME HERE")

;;; Code:

(require 'sendmail)

;;;
(defvar smtpmail-default-smtp-server nil
  "*Specify default SMTP server.")

(defvar smtpmail-smtp-server 
  (or (getenv "SMTPSERVER") smtpmail-default-smtp-server)
  "*The name of the host running SMTP server.")

(defvar smtpmail-smtp-service 25
  "*SMTP service port number. smtp or 25 .")

(defvar smtpmail-local-domain nil
  "*Local domain name without a host name.
If the function (system-name) returns the full internet address,
don't define this value.")

(defvar smtpmail-debug-info nil
  "*smtpmail debug info printout. messages and process buffer.")

(defvar smtpmail-code-conv-from nil ;; *junet*
  "*smtpmail code convert from this code to *internal*..for tiny-mime..")

;;;
;;;
;;;

(defun smtpmail-send-it ()
  (require 'mail-utils)
  (let ((errbuf (if mail-interactive
		    (generate-new-buffer " smtpmail errors")
		  0))
	(tembuf (generate-new-buffer " smtpmail temp"))
	(case-fold-search nil)
	resend-to-addresses
	delimline
	(mailbuf (current-buffer)))
    (unwind-protect
	(save-excursion
	  (set-buffer tembuf)
	  (erase-buffer)
	  (insert-buffer-substring mailbuf)
	  (goto-char (point-max))
	  ;; require one newline at the end.
	  (or (= (preceding-char) ?\n)
	      (insert ?\n))
	  ;; Change header-delimiter to be what sendmail expects.
	  (goto-char (point-min))
	  (re-search-forward
	    (concat "^" (regexp-quote mail-header-separator) "\n"))
	  (replace-match "\n")
	  (backward-char 1)
	  (setq delimline (point-marker))
;;	  (sendmail-synch-aliases)
	  (if (and mail-aliases (fboundp expand-mail-aliases)) ; XEmacs
	      (expand-mail-aliases (point-min) delimline))
	  (goto-char (point-min))
	  ;; ignore any blank lines in the header
	  (while (and (re-search-forward "\n\n\n*" delimline t)
		      (< (point) delimline))
	    (replace-match "\n"))
	  (let ((case-fold-search t))
	    (goto-char (point-min))
	    (goto-char (point-min))
	    (while (re-search-forward "^Resent-to:" delimline t)
	      (setq resend-to-addresses
		    (save-restriction
		      (narrow-to-region (point)
					(save-excursion
					  (end-of-line)
					  (point)))
		      (append (mail-parse-comma-list)
			      resend-to-addresses))))
;;; Apparently this causes a duplicate Sender.
;;;	    ;; If the From is different than current user, insert Sender.
;;;	    (goto-char (point-min))
;;;	    (and (re-search-forward "^From:"  delimline t)
;;;		 (progn
;;;		   (require 'mail-utils)
;;;		   (not (string-equal
;;;			 (mail-strip-quoted-names
;;;			  (save-restriction
;;;			    (narrow-to-region (point-min) delimline)
;;;			    (mail-fetch-field "From")))
;;;			 (user-login-name))))
;;;		 (progn
;;;		   (forward-line 1)
;;;		   (insert "Sender: " (user-login-name) "\n")))
	    ;; Don't send out a blank subject line
	    (goto-char (point-min))
	    (if (re-search-forward "^Subject:[ \t]*\n" delimline t)
		(replace-match ""))
	    ;; Put the "From:" field in unless for some odd reason
	    ;; they put one in themselves.
	    (goto-char (point-min))
	    (if (not (re-search-forward "^From:" delimline t))
		(let* ((login user-mail-address)
		       (fullname (user-full-name)))
		  (cond ((eq mail-from-style 'angles)
			 (insert "From: " fullname)
			 (let ((fullname-start (+ (point-min) 6))
			       (fullname-end (point-marker)))
			   (goto-char fullname-start)
			   ;; Look for a character that cannot appear unquoted
			   ;; according to RFC 822.
			   (if (re-search-forward "[^- !#-'*+/-9=?A-Z^-~]"
						  fullname-end 1)
			       (progn
				 ;; Quote fullname, escaping specials.
				 (goto-char fullname-start)
				 (insert "\"")
				 (while (re-search-forward "[\"\\]"
							   fullname-end 1)
				   (replace-match "\\\\\\&" t))
				 (insert "\""))))
			 (insert " <" login ">\n"))
			((eq mail-from-style 'parens)
			 (insert "From: " login " (")
			 (let ((fullname-start (point)))
			   (insert fullname)
			   (let ((fullname-end (point-marker)))
			     (goto-char fullname-start)
			     ;; RFC 822 says \ and nonmatching parentheses
			     ;; must be escaped in comments.
			     ;; Escape every instance of ()\ ...
			     (while (re-search-forward "[()\\]" fullname-end 1)
			       (replace-match "\\\\\\&" t))
			     ;; ... then undo escaping of matching parentheses,
			     ;; including matching nested parentheses.
			     (goto-char fullname-start)
			     (while (re-search-forward 
				     "\\(\\=\\|[^\\]\\(\\\\\\\\\\)*\\)\\\\(\\(\\([^\\]\\|\\\\\\\\\\)*\\)\\\\)"
				     fullname-end 1)
			       (replace-match "\\1(\\3)" t)
			       (goto-char fullname-start))))
			 (insert ")\n"))
			((null mail-from-style)
			 (insert "From: " login "\n")))))
	    ;; Insert an extra newline if we need it to work around
	    ;; Sun's bug that swallows newlines.
	    (goto-char (1+ delimline))
	    (if (eval mail-mailer-swallows-blank-line)
		(newline))
	    ;; Find and handle any FCC fields.
	    (goto-char (point-min))
	    (if (re-search-forward "^FCC:" delimline t)
		(mail-do-fcc delimline))
	    (if mail-interactive
		(save-excursion
		  (set-buffer errbuf)
		  (erase-buffer))))
	  ;;
	  ;;
	  ;;
	  (setq smtpmail-address-buffer (generate-new-buffer "*smtp-mail*"))
	  (setq smtpmail-recipient-address-list
		(or resend-to-addresses
		    (smtpmail-deduce-address-list tembuf (point-min) delimline)))
	  (kill-buffer smtpmail-address-buffer)

	  (smtpmail-do-bcc delimline)

	  (if (not (null smtpmail-recipient-address-list))
	      (if (not (smtpmail-via-smtp smtpmail-recipient-address-list tembuf))
		  (error "Sending failed; SMTP protocol error"))
	    (error "Sending failed; no recipients"))
	  )
      (kill-buffer tembuf)
      (if (bufferp errbuf)
	  (kill-buffer errbuf)))))


;(defun smtpmail-via-smtp (host,port,sender,destination,smtpmail-text-buffer)

(defun smtpmail-fqdn ()
  (if smtpmail-local-domain
      (concat (system-name) "." smtpmail-local-domain)
    (system-name)))

(defun smtpmail-via-smtp (recipient smtpmail-text-buffer)
  (let ((process nil)
	(host smtpmail-smtp-server)
	(port smtpmail-smtp-service)
	response-code
	greeting
	process-buffer)
    (unwind-protect
	(catch 'done
	  ;; get or create the trace buffer
	  (setq process-buffer
		(get-buffer-create (format "*trace of SMTP session to %s*" host)))

	  ;; clear the trace buffer of old output
	  (save-excursion
	    (set-buffer process-buffer)
	    (erase-buffer))

	  ;; open the connection to the server
	  (setq process (open-network-stream "SMTP" process-buffer host port))
	  (and (null process) (throw 'done nil))

	  ;; set the send-filter
	  (set-process-filter process 'smtpmail-process-filter)

	  (save-excursion
	    (set-buffer process-buffer)
	    (make-local-variable 'smtpmail-read-point)
	    (setq smtpmail-read-point (point-min))

	    
	    (if (or (null (car (setq greeting (smtpmail-read-response process))))
		    (not (integerp (car greeting)))
		    (>= (car greeting) 400))
		(throw 'done nil)
	      )

	    ;; HELO
	    (smtpmail-send-command process (format "HELO %s" (smtpmail-fqdn)))

	    (if (or (null (car (setq response-code (smtpmail-read-response process))))
		    (not (integerp (car response-code)))
		    (>= (car response-code) 400))
		(throw 'done nil)
	      )

	    ;; MAIL FROM: <sender>
;	    (smtpmail-send-command process (format "MAIL FROM:%s@%s" (user-login-name) (smtpmail-fqdn)))
	    (smtpmail-send-command process (format "MAIL FROM: <%s>" user-mail-address))

	    (if (or (null (car (setq response-code (smtpmail-read-response process))))
		    (not (integerp (car response-code)))
		    (>= (car response-code) 400))
		(throw 'done nil)
	      )
	    
	    ;; RCPT TO: <recipient>
	    (let ((n 0))
	      (while (not (null (nth n recipient)))
		(smtpmail-send-command process (format "RCPT TO: <%s>" (nth n recipient)))
		(setq n (1+ n))

		(if (or (null (car (setq response-code (smtpmail-read-response process))))
			(not (integerp (car response-code)))
			(>= (car response-code) 400))
		    (throw 'done nil)
		  )
		))
	    
	    ;; DATA
	    (smtpmail-send-command process "DATA")

	    (if (or (null (car (setq response-code (smtpmail-read-response process))))
		    (not (integerp (car response-code)))
		    (>= (car response-code) 400))
		(throw 'done nil)
	      )

	    ;; Mail contents
	    (smtpmail-send-data process smtpmail-text-buffer)

	    ;;DATA end "."
	    (smtpmail-send-command process ".")

	    (if (or (null (car (setq response-code (smtpmail-read-response process))))
		    (not (integerp (car response-code)))
		    (>= (car response-code) 400))
		(throw 'done nil)
	      )

	    ;;QUIT
;	    (smtpmail-send-command process "QUIT")
;	    (and (null (car (smtpmail-read-response process)))
;		 (throw 'done nil))
	    t ))
      (if process
	  (save-excursion
	    (set-buffer (process-buffer process))
	    (smtpmail-send-command process "QUIT")
	    (smtpmail-read-response process)

;	    (if (or (null (car (setq response-code (smtpmail-read-response process))))
;		    (not (integerp (car response-code)))
;		    (>= (car response-code) 400))
;		(throw 'done nil)
;	      )
	    (delete-process process))))))


(defun smtpmail-process-filter (process output)
  (save-excursion
    (set-buffer (process-buffer process))
    (goto-char (point-max))
    (insert output)))

(defun smtpmail-read-response (process)
  (let ((case-fold-search nil)
	(response-string nil)
	(response-continue t)
	(return-value '(nil ""))
	match-end)

;    (setq response-string nil)
;    (setq response-continue t)
;    (setq return-value '(nil ""))

    (while response-continue
      (goto-char smtpmail-read-point)
      (while (not (search-forward "\r\n" nil t))
	(accept-process-output process)
	(goto-char smtpmail-read-point))

      (setq match-end (point))
      (if (null response-string)
	  (setq response-string
		(buffer-substring smtpmail-read-point (- match-end 2))))
	
      (goto-char smtpmail-read-point)
      (if (looking-at "[0-9]+ ")
	  (progn (setq response-continue nil)
;		 (setq return-value response-string)

		 (if smtpmail-debug-info
		     (message response-string))

		 (setq smtpmail-read-point match-end)
		 (setq return-value
		       (cons (string-to-int 
			      (buffer-substring (match-beginning 0) (match-end 0))) 
			     response-string)))
	
	(if (looking-at "[0-9]+-")
	    (progn (setq smtpmail-read-point match-end)
		   (setq response-continue t))
	  (progn
	    (setq smtpmail-read-point match-end)
	    (setq response-continue nil)
	    (setq return-value 
		  (cons nil response-string))
	    )
	  )))
    (setq smtpmail-read-point match-end)
    return-value))


(defun smtpmail-send-command (process command)
  (goto-char (point-max))
  (if (= (aref command 0) ?P)
      (insert "PASS <omitted>\r\n")
    (insert command "\r\n"))
  (setq smtpmail-read-point (point))
  (process-send-string process command)
  (process-send-string process "\r\n"))

(defun smtpmail-send-data-1 (process data)
  (goto-char (point-max))

  (if (not (null smtpmail-code-conv-from))
      (setq data (code-convert-string data smtpmail-code-conv-from *internal*)))
	
  (if smtpmail-debug-info
      (insert data "\r\n"))

  (setq smtpmail-read-point (point))
  ;; Escape "." at start of a line
  (if (eq (string-to-char data) ?.)
      (process-send-string process "."))
  (process-send-string process data)
  (process-send-string process "\r\n")
  )

(defun smtpmail-send-data (process buffer)
  (let
      ((data-continue t)
       (sending-data nil)
       this-line
       this-line-end)

    (save-excursion
      (set-buffer buffer)
      (goto-char (point-min)))

    (while data-continue
      (save-excursion
	(set-buffer buffer)
	(beginning-of-line)
	(setq this-line (point))
	(end-of-line)
	(setq this-line-end (point))
	(setq sending-data nil)
	(setq sending-data (buffer-substring this-line this-line-end))
	(if (/= (forward-line 1) 0)
	    (setq data-continue nil)))

      (smtpmail-send-data-1 process sending-data)
      )
    )
  )
    

(defun smtpmail-deduce-address-list (smtpmail-text-buffer header-start header-end)
  "Get address list suitable for smtp RCPT TO: <address>."
  (require 'mail-utils)  ;; pick up mail-strip-quoted-names
  (let
      ((case-fold-search t)
       (simple-address-list "")
       this-line
       this-line-end
       addr-regexp)
    
    (unwind-protect
	(save-excursion
	  ;;
	  (set-buffer smtpmail-address-buffer) (erase-buffer)
	  (insert-buffer-substring smtpmail-text-buffer header-start header-end)
	  (goto-char (point-min))
	  ;; RESENT-* fields should stop processing of regular fields.
	  (save-excursion
	    (if (re-search-forward "^RESENT-TO:" header-end t)
		(setq addr-regexp "^\\(RESENT-TO:\\|RESENT-CC:\\|RESENT-BCC:\\)")
	      (setq addr-regexp  "^\\(TO:\\|CC:\\|BCC:\\)")))

	  (while (re-search-forward addr-regexp header-end t)
	    (replace-match "")
	    (setq this-line (match-beginning 0))
	    (forward-line 1)
	    ;; get any continuation lines
	    (while (and (looking-at "^[ \t]+") (< (point) header-end))
	      (forward-line 1))
	    (setq this-line-end (point-marker))
	    (setq simple-address-list
		  (concat simple-address-list " "
			  (mail-strip-quoted-names (buffer-substring this-line this-line-end))))
	    )
	  (erase-buffer)
	  (insert-string " ")
	  (insert-string simple-address-list)
	  (insert-string "\n")
	  (subst-char-in-region (point-min) (point-max) 10 ?  t);; newline --> blank
	  (subst-char-in-region (point-min) (point-max) ?, ?  t);; comma   --> blank
	  (subst-char-in-region (point-min) (point-max)  9 ?  t);; tab     --> blank

	  (goto-char (point-min))
	  ;; tidyness in case hook is not robust when it looks at this
	  (while (re-search-forward "[ \t]+" header-end t) (replace-match " "))

	  (goto-char (point-min))
	  (let (recipient-address-list)
	    (while (re-search-forward " \\([^ ]+\\) " (point-max) t)
	      (backward-char 1)
	      (setq recipient-address-list (cons (buffer-substring (match-beginning 1) (match-end 1))
						 recipient-address-list))
	      )
	    (setq smtpmail-recipient-address-list recipient-address-list))

	  )
      )
    )
  )


(defun smtpmail-do-bcc (header-end)
  "Delete BCC: and their continuation lines from the header area.
There may be multiple BCC: lines, and each may have arbitrarily
many continuation lines."
  (let ((case-fold-search t))
	(save-excursion (goto-char (point-min))
	  ;; iterate over all BCC: lines
	  (while (re-search-forward "^BCC:" header-end t)
	        (delete-region (match-beginning 0) (progn (forward-line 1) (point)))
		;; get rid of any continuation lines
		(while (and (looking-at "^[ \t].*\n") (< (point) header-end))
		  (replace-match ""))
		)
	  ) ;; save-excursion
	) ;; let
  )



(provide 'smtpmail)

;; smtpmail.el ends here

--Multipart_Tue_Sep_24_08:59:23_1996-1
Content-Type: text/plain; charset=US-ASCII



-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

--Multipart_Tue_Sep_24_08:59:23_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 24 11:12:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id LAA06317 for xemacs-beta-people; Tue, 24 Sep 1996 11:12:50 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA06314 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 24 Sep 1996 11:12:48 -0500 (CDT)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.255.59.2]) by a.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id LAA02395 for <xemacs-beta@cs.uiuc.edu>; Tue, 24 Sep 1996 11:12:07 -0500 (CDT)
Received: from vecdg.hpl.hp.com by hplb.hpl.hp.com; Tue, 24 Sep 1996 17:11:44 +0100
Date: Tue, 24 Sep 1996 17:11:44 +0100
Message-Id: <199609241611.AA203131504@hplb.hpl.hp.com>
From: Dipankar Gupta <dg@hplb.hpl.hp.com>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Emacs 19.34 and smtpmail.el
In-Reply-To: <m2vid329b8.fsf@deanna.miranova.com>
References: <m2vid329b8.fsf@deanna.miranova.com>


I include a hack I wrote when I couldn't get smtpmail to work a few
months ago.  I haven't submitted it to FSF on account of the legalese,
but it should do the job.  One caveat: it uses the feedmail package
(which is included in the XEmacs distribution) to do the grungy work
of talking to sendmail.el.

It would be cool if someone wrote a hack that could optionally spool
requests and send them off when connected to the network.

Cheers,
Dipankar
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;;; -*- mode: Emacs-Lisp -*-
;;; A quick-and-dirty SMTP client in e-lisp.
;;;
;;; Copyright (C) 1996 Dipankar Gupta <dg@hplb.hpl.hp.com>
;;;
;;; Author: Dipankar Gupta <dg@hplb.hpl.hp.com>
;;; Version: 0.17
;;; Keywords: mail
;;;
;;; This program is free software; you can redistribute it and/or modify
;;; it under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 1, or (at your option)
;;; any later version.
;;;
;;; This program is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with this program; if not, write to the Free Software
;;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
;;;

;;; Perpetrator:	Dipankar Gupta <dg@hplb.hpl.hp.com>

;;; Deficiencies:
;;; - Minimal error handling.
;;; - Optionally uses vm-misc and mail-extr to do the dirty work.
;;; - Assumes that any response under 400 is kosher.
;;; - Doesn't talk ESMTP properly.
;;;   (assumes that 8BITMIME extension is always available if EHLO works)

;;; Changes:
;;; - Added synchronous mode in which the client waits indefinitely for
;;;   some response to appear from the server. (18jun96)
;;; - Added code to receive process output right after the connection
;;;   is established. (11jun96)
;;; - Replaced VM address parser with mail-strip-quoted-names.
;;; - Uses feedmail if at all possible.  Handles BCC ok. (07jun96)
;;; - Clean up temporary buffers on unwinding. Trace now appended to the
;;;   error buffer passed by sendmail-send-it. Copied VM address parser
;;;   from version 5.95beta in case user does not have VM installed. (06jun96)
;;; - Increased default accept-process-output timeout to 2 seconds.  (05jun96)

;;; Checked on XEmacs 19.14 (HP-UX) and Gnu Emacs 19.31 (Windows NT) with
;;; an HP sendmail-based SMTP server.

;;; We always need sendmail.
(require 'sendmail)

;Get the value for a header field.
(autoload 'mail-fetch-field "mail-utils")
;Extract address components.
(autoload 'mail-extract-address-components "mail-extr")


;;;; INSTRUCTIONS

;;; You should have feedmail installed; otherwise this package
;;; needs a patched sendmail.el to work (this patch not in emacs 19.31).
;;; Feedmail is shipped in the XEmacs distribution.

;;; Feedmail provides a nicer interface to sendmail.el.  It is written
;;; by William J. Carpenter <billc@pegasus.attmail.com> and is available
;;; at:
;;; ftp://ftp.cis.ohio-state.edu/pub/gnu/emacs/elisp-archive/misc/feedmail.el.Z

;;; After byte-compiling and installing, you should only need to
;;; set smtp-smtp-server.  
;;;	(require 'esmtp) 
;;;	(setq smtp-smtp-server "foobar.dom.org")

;;; If using VM, you may also want to add:
;;;	(setq smtp-use-vm-parser-p t)
;;; to use the native address parser.

;;; With feedmail, you might be interested in looking at:
;;; (setq feedmail-last-chance-hook 'feedmail-confirm-addresses-hook-example)
;;; which shows the address(es) being sent to, and allows you to
;;; abort.

;;; The from address is derived from user-mail-address.  If not
;;; defined, the package attempts to build it using user-login-name
;;; and system-name.

;;;; BACKGROUND

;;; There is another package called `smtpmail' by Tomoji Kagatani
;;; <kagatani@rbc.ncl.omron.co.jp> which does more than this one.  I
;;; only wrote this because the local SMTP server returned random
;;; errors when I tried using smtpmail.  This package optionally
;;; reuses the address handling code in VM and mail-extr.  It also
;;; uses 8bit messages for servers that allow them.

;;; Note that the buffer must be ready to be mailed in toto before
;;; calling smtp-mail-buffer!.  In particular, things like FCC 
;;; must be handled in advance of calling this.  No alias expansion is
;;; attempted following the general rule of not mucking about behind
;;; the user's back.  Use BBDB or something else that expands aliases
;;; as you type.  The only change this code should make to the contents
;;; would be to change lines containing only a single `.' in them, as this
;;; is treated specially by the SMTP protocol (cf. RFC 821).

;;; Each SMTP process is attached to a buffer called
;;; *SMTP-<server-name>*.  This is where the input is optionally
;;; copied.  The output is snarfed by a filter into another buffer
;;; called "*Trace of SMTP session with <server-name>*"

;;; The process-buffer has a local variable *smtp-output* which points
;;; to the buffer *Trace ... . The output is read line-by-line by the
;;; smtp-process-server-output function.

;;; All throws use the tag smtp-error, and the value is a string that
;;; contains the server's suspicious response.  We don't use global
;;; variables to preserve state, so multiple SMTP connections should
;;; work OK if required.


;;;; CONFIGURABLE STUFF

(defvar smtp-smtp-server "mail"
  "SMTP server that we wish to use to send mail.")

(defvar smtp-smtp-port 25
  "Port that the SMTP server uses. (port #25 in RFC 1869).")

(defvar smtp-transmit-lines-separately-p nil
  "Should we pour the contents of the mail composition buffer
into the stream line-by-line? Zap the entire contents in one call
if set to nil (suggested setting).")

(defvar smtp-synchronous-p t
  "Run a synchronous protocol with the server?  In this case, the
client does not proceed to the next message unless it has received 
some response from the server.  The setting for smtp-timeout-sec 
is ignored if this is set.")

(defvar smtp-timeout-sec 2
  "Number of seconds to wait for the SMTP server's response to
each protocol message before timing out.  Bump this up if you have
a slow TCP connection or the server appears confused.")

(defvar smtp-echo-input-p nil
  "Should we echo the input into the process buffer?  Setting this to t
will incur significant bloat for large messages.")

(defvar smtp-try-8bit-p t
  "Should we try to use the 8bit-clean protocol?  This tries to use ESMTP
(RFC 1869) first, reverting to RFC821 if that fails.")

(defvar smtp-use-vm-parser-p nil
  "Should we use the address parser in VM?  If not, use a simple one
from mail-utils.")

(defvar smtp-use-feedmail-p t
  "Should we use feedmail by default?  If set to t, we never try using
sendmail directly.  If nil, feedmail is used if sendmail doesn't have the
patch allowing us to replace the mail dispatcher.")


;;;; IMPLEMENTATION

;;; Keep the byte compiler happy.  These are buffer-local variables
;;; that capture SMTP server output.
(defvar *smtp-output*)
(defvar *smtp-output-cursor*)

;;; Finalize an open network stream.  Shouldn't barf if passed a 
;;; dead stream or nil.
(defun smtp-finalize (strm)
  (if (processp strm)
      (progn
	(if (eq 'open (process-status strm)) (process-send-eof strm))
	(and (process-buffer strm) (kill-buffer (process-buffer strm)))
	(delete-process strm))))

;;; Sentinel: only knows about closing a network stream.
;;;	Throws: smtp-error
(defun smtp-sentinel (proc strg)
  (if (not (eq (process-status proc) 'closed))
      (throw 'smtp-error 
	     (format "Bad process status %s:`%s'" 
		     (process-status proc) strg))))

;;; Copy the server's response into the buffer pointed to
;;; by the *smtp-output* local variable corresponding to
;;; the process.  This will be eaten later by 
;;; smtp-process-server-output.
(defun smtp-filter (stream strg)
  (let ((obuf (current-buffer)))
    (unwind-protect
	(progn
	  (set-buffer (process-buffer stream))
	  (set-buffer *smtp-output*)
	  (goto-char (process-mark stream))
	  (insert strg)
	  (set-marker (process-mark stream) (point)))
      (set-buffer obuf))))

;;; Process the server's output, if we have received a CR/LF
;;; since the last time we visited here.  smtp-filter stuffs
;;; the data into the server's output buffer.  
;;;	Throws: smtp-error
(defun smtp-process-server-output (stream)
  (let ((obuf (current-buffer)))
    (unwind-protect
	(progn
	  ;;; Let SMTP server output be sucked into the buffer.
	  (accept-process-output stream 
				 (if smtp-synchronous-p nil
				   smtp-timeout-sec))

	  ;;; Go to the right position within the output buffer.
	  (set-buffer (process-buffer stream))
	  (set-buffer *smtp-output*)
	  (goto-char *smtp-output-cursor*)	;This is a valid local variable for this buffer.

	  ;;; Now hack the new complete lines since the last visit.
	  (while (search-forward "\r\n" nil t)
	    (let* ((response (buffer-substring *smtp-output-cursor* (match-end 0)))
		   (status-code (string-to-number (substring response 0 3))))
	      (setq *smtp-output-cursor* (match-end 0))

	      ;;; Needs refinement ####
	      (if (>= status-code 400)
		  (progn
		    (throw 'smtp-error 
			   (format "Status: %s, resp = `%s'" 
			   status-code response))
		    (set-process-filter stream nil))))))
      ;;; Unwind: revert to saved buffer.
      (set-buffer obuf))))


;;; Connect to an SMTP server.  Creates a buffer called *SMTP-<name>*
;;; which is tied to the process, and another called `*Trace of SMTP
;;; ...' which contains the responses received from the server.  The
;;; local variable *smtp-output-cursor* contains the last position where we
;;; found an end-of-line.
(defun smtp-connect (server port)
  (let* ((obuf (current-buffer))
	 (bname  (get-buffer-create (concat "*SMTP-" server "*")))
	 (outbuf (get-buffer-create 
		  (concat "*Trace of SMTP session with " server "*")))
	 (strm nil))

    (unwind-protect
	(progn
	  ;;; Go to the buffer associated with the process and clean it up.
	  (set-buffer bname)
	  (erase-buffer)
	  (setq strm (open-network-stream "smtp" bname server port))
	  (or (eq 'open (process-status strm))
	      (throw 'smtp-error "Failed to open SMTP connection to %s at port %d" 
		     server port))

	  (make-variable-buffer-local '*smtp-output*)
	  (setq *smtp-output* outbuf)

	  ;;; Fix up the output buffer.
	  (set-buffer outbuf)
	  (erase-buffer)

	  ;;; Set the sentinel/filter functions.
	  (set-process-sentinel strm 'smtp-sentinel)
	  (set-process-filter strm 'smtp-filter)

	  ;;; Set up the process marker to point to the insertion
	  ;;; point of the output buffer.
	  (set-marker (process-mark strm) (point-min))

	  ;;; Set up the last newline found as a local variable.
	  (make-variable-buffer-local '*smtp-output-cursor*)
	  (setq *smtp-output-cursor* (point-min))
	  ;;; Gobble any output from the server so far.
	  (smtp-process-server-output strm))

      ;;; Unwind restore the old buffer.
      (set-buffer obuf))
      strm))


;;; A synchronous send/recv pair built up using send-foo and the
;;; filter.  Process-server-output will call accept-process-output
;;; to let the filter do it's work.
(defun smtp-send-recv (stream strg)
  (let ((obuf (current-buffer)))
    (unwind-protect
	(progn
	  (process-send-string stream strg)
	  (if smtp-echo-input-p
	      (progn
		(set-buffer (process-buffer stream))
		(goto-char (point-max))
		(insert strg)))
	  (smtp-process-server-output stream))
      (set-buffer obuf))))

;;; Disconnect from server.
(defun smtp-disconnect (stream)
  ;; (smtp-send-recv stream "NOOP\r\n")
  (smtp-send-recv stream "QUIT\r\n"))

;;; Initial HELO string.
(defun smtp-helo-server (stream)
  (smtp-send-recv stream (concat "HELO " (system-name) "\r\n")))

;;; Attempt EHLO, and return t if it didn't barf on us.
(defun smtp-attempt-ehlo (stream)
  (if (not smtp-try-8bit-p) nil
    (let ((resp
	   (catch 'smtp-error
	     (smtp-send-recv stream (concat "EHLO " (system-name) "\r\n"))
	     t)))
      (eq resp t))))

;;; Do the from, with 8bit clean indicator if doing ESMTP.
(defun smtp-from-me (stream clean-str)
  (smtp-send-recv stream (format "MAIL FROM: <%s> %s\r\n"
				 (or user-mail-address
				     (format "%s@%s"
					     (user-login-name) 
					     (or mail-host-address 
						 (system-name))))
				 clean-str)))

;;; Do the recipient list.
(defun smtp-recipients (stream recipient-list)
  (and (= 0 (length recipient-list)) 
       (throw 'smtp-error "Bogus empty recipient list!"))
  (mapcar (lambda (x) 
	    (smtp-send-recv stream (format "RCPT TO: <%s>\r\n" x))) 
	  recipient-list))


;;; Send mail buffer to network stream.
(defun smtp-send-buffer (stream buffer)
  (let ((obuf (current-buffer)))
    (unwind-protect
	;;; Attempt to send the buffer contents.
	(progn
	  (set-buffer buffer)
	  (if smtp-transmit-lines-separately-p
	      ;;; Transfer each line, doing the CR/LF mapping in turn.
	      (progn
		(let ((s-start (point-min))
		      (s-max (point-max))
		      s-end)
		  (while (< s-start s-max)
		    (goto-char s-start)
		    (if (search-forward "\n" nil t)
			(setq s-end (match-end 0))	;Line terminated by newline.
		      (setq s-end (+ 1 s-max)))	;Last line not terminated by newline.
		    
		    ;; Don't send the newline if we found one.
		    (process-send-region stream s-start (- s-end 1))
		    ;; Send the CR/LF, always.
		    (process-send-string stream "\r\n")

		    ;; Optionally, copy the line to the process buffer too.
		    (if smtp-echo-input-p
			(let ((mail-buf (current-buffer)))
			  (unwind-protect
			      (progn
				(set-buffer (process-buffer stream))
				(goto-char (point-max))
				(insert-buffer-substring mail-buf s-start (- s-end 1))
				(insert "\r\n"))
			    ;; Unwind: revert to mail buffer
			    (set-buffer mail-buf))))

		    (setq s-start s-end))))

	    ;;; Send the contents in one fell swoop.
	    (progn
	      (process-send-region stream (point-min) (point-max))
	      ;;; Copy contents to the process buffer optionally.
	      (if smtp-echo-input-p
		  (let ((mail-buf (current-buffer)))
		    (unwind-protect
			(progn
			  (set-buffer (process-buffer stream))
			  (goto-char (point-max))
			  (insert-buffer mail-buf))
		      ;; Unwind revert to mail buffer
		      (set-buffer mail-buf)))))))
      ;; Unwind: go back to the buffer at the beginning of procedure.
      (set-buffer obuf))))

;;; Send the data.
(defun smtp-data (stream buffer)
  (smtp-send-recv stream (format "DATA\r\n"))
  (smtp-send-buffer stream buffer)
  (smtp-send-recv stream ".\r\n"))


;;; Parse feedmail's address string, generating a list of addresses.
(defun smtp-parse-bare-addresses (string)
  (save-excursion
    (let ((start 0)
	  (addr-list '()))
      (while (string-match "[^ \t\f\r\n\]+" string start)
	(setq addr-list (cons (substring string (match-beginning 0)
					 (match-end 0)) addr-list))
	(setq start (match-end 0)))
      (nreverse addr-list))))

;;; Build recipient list: optionally uses mail-extr and VM's parser.
;;; See the documentation for mail-extract-address-components.
;;; Returns a list containing the canonical addresses of each
;;; recipient.
(defun smtp-build-recipient-list (buffer &optional address-string)
  (save-excursion
    (let ((smtp-address-parser
	   ;; Parser that generates a list of addresses from a string.
	   (if smtp-use-vm-parser-p
	       (progn (require 'vm-misc) 
		      (function (lambda (x)
				  (mapcar (lambda (y) 
					    (nth 1 (mail-extract-address-components y)))
					  (vm-parse-addresses x)))))
	     'smtp-alternate-parse-addresses))
	  (addr-list '())		;empty
	  to
	  cc
	  bcc)
      (if (not (stringp address-string))
	  (progn
	    (set-buffer buffer)
	    ;; Do it ourselves.
	    ;; Unnecessary consing as mapc is not available in GNU emacs.
	    (mapcar (lambda (x)
		      (setq addr-list 
			    (append addr-list 
				    (funcall smtp-address-parser (mail-fetch-field x)))))
		    '("To" "CC" "BCC"))
	    addr-list)
	;;; Using feedmail's bare addresses (already parsed)
	(smtp-parse-bare-addresses address-string)))))

;;; SMTP will truncate any data if a line with a single period `.' is
;;; found.  I don't know if VM's machinations already take care of
;;; this, hopefully this will stop the server truncating the message.
(defun smtp-mogrify-buffer(buffer)
  (save-excursion
    (set-buffer buffer)
    (goto-char (point-min))
    (while (search-forward "\n.\n" nil t)
      (replace-match "\n..\n" nil t))))


;;; JFDI: perform SMTP protocol run.  Intended as a replacement
;;; for the top-level mail-send type function.
(defun smtp-mail-buffer! (errbuf &optional buffer address-string server)
  "Attempt to run [E]SMTP protocol with SERVER to send contents of
BUFFER.  BUFFER should already have had processing done to it so
that this guy can send it's entire contents without further mucking
about.  Thus, any  FCC fields should have been hacked out
prior to calling this function.  The parameter ERRBUF will have a short
description of the failure, to be used by sendmail-send-it.  If the
previous step has kindly parsed the addresses, it should be sent as
the parameter ADDRESS-STRING.  Specify SERVER to use a non-default
SMTP server."
  (let ((old-buf (current-buffer)))
    (unwind-protect
	(progn
	  (or buffer (setq buffer (current-buffer)))
	  (or server (setq server smtp-smtp-server))
	  (smtp-mogrify-buffer buffer)		;Remove lines with a single period in them.
	  (let* ((outbuf nil)
		 (stream nil)
		 (failed-p 'ok))

	    ;;; The following may cause errors in dealing with the
	    ;;; server.  Handle all throws with tag smtp-error.
	    (unwind-protect
		(setq failed-p
		      (catch 'smtp-error
			;;; address-string will be set if feedmail is being used.
		      (let* ((recipients (smtp-build-recipient-list buffer address-string))
			     (8bit-clean ""))
			(setq stream (smtp-connect server smtp-smtp-port))
			(setq outbuf (marker-buffer (process-mark stream)))
			
			;; Attempt extended SMTP, falling back to the standard one.
			(if (smtp-attempt-ehlo stream)
			    (setq 8bit-clean " BODY=8BITMIME")
			  (smtp-helo-server stream))

			;; Do the protocol components.
			(smtp-from-me stream 8bit-clean)
			(smtp-recipients stream recipients)
			(smtp-data stream buffer)
			(smtp-disconnect stream))
		      'ok))

	      ;; Unwind: Always attempt to finalize the stream, so that
	      ;; processes don't linger on.
	      (smtp-finalize stream))

	    ;;; (and outbuf (pop-to-buffer outbuf)) ;; uncomment to debug.
	    (if (not (eq failed-p 'ok))
		(progn
		  (set-buffer errbuf)
		  (insert (format "While talking to SMTP server %s:\n%s\n" server failed-p))
		  (insert ">>> Trace of SMTP server output <<<\n")
		  (and outbuf (insert-buffer outbuf))))
	    (kill-buffer outbuf)))
      ;; Unwind: restore old buffer
      (set-buffer old-buf))))


;;; We can use a patched sendmail or the nice feedmail package.
;;; Connect with the right stuff...
(if (or smtp-use-feedmail-p
	(not (boundp 'mail-dispatcher-function)))
  (progn
    ;; The feedmail package insulates us from sendmail.el's nightmares.
    ;; I wonder if we can use the address parsing in feedmail!
    (require 'feedmail)
    (setq send-mail-function 'feedmail-send-it)
    (setq feedmail-from-line nil)	;Override default.
    (setq feedmail-buffer-eating-function
	  (lambda (buffer errbuf address-string)
	    (smtp-mail-buffer! errbuf buffer address-string))))

  ;; We have a patched sendmail.el, so we'll try and get by.
  (setq mail-dispatcher-function 
	(lambda(errbuf &rest parms) (smtp-mail-buffer! errbuf))))

    
(provide 'esmtp);;; End of implementation proper.
;;;;;;;;;;;; An alternate simple parser ;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Default parser.
(defun smtp-alternate-parse-addresses (string)
  "Parse addresses, returning a list."
  (smtp-parse-bare-addresses (mail-strip-quoted-names string)))

;;; EOF
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;




From xemacs-beta-request@cs.uiuc.edu  Tue Sep 24 13:11:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.5/8.7.3) id NAA06797 for xemacs-beta-people; Tue, 24 Sep 1996 13:11:49 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA06794 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 24 Sep 1996 13:11:48 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by xemacs.cs.uiuc.edu (8.7.5/8.7.3) with ESMTP id NAA24161 for <xemacs-beta@xemacs.org>; Tue, 24 Sep 1996 13:11:42 -0500 (CDT)
Received: from mordor.rsn.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA156238699; Tue, 24 Sep 1996 11:11:39 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id NAA23264; Tue, 24 Sep 1996 13:15:21 -0500 (CDT)
Date: Tue, 24 Sep 1996 13:15:21 -0500 (CDT)
Message-Id: <199609241815.NAA23264@mordor.rsn.hp.com>
From: Shane Holder <holder@mordor.rsn.hp.com>
To: xemacs-beta@xemacs.org
Subject: XEmacs 4 days 20 hours of uptime


With the few "Crash" mails I thought I'd let everyone know that my
xemacs has been running very well for almost 5 days.  I do everything
in it, mail/news, shell stuff, ftp it's running at about 20M right now.

(I'd still like to see some more speed improvements in the display
area though, scrolling, cursor movement, character insertion)

Shane

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 24 19:56:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA08366 for xemacs-beta-people; Tue, 24 Sep 1996 19:56:19 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA08363 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 24 Sep 1996 19:56:18 -0500 (CDT)
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA25559 for <xemacs-beta@xemacs.org>; Tue, 24 Sep 1996 19:56:15 -0500 (CDT)
Received: from mordor.rsn.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA283962977; Tue, 24 Sep 1996 17:56:17 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id UAA25129; Tue, 24 Sep 1996 20:01:13 -0500 (CDT)
Date: Tue, 24 Sep 1996 20:01:13 -0500 (CDT)
Message-Id: <199609250101.UAA25129@mordor.rsn.hp.com>
From: Shane Holder <holder@mordor.rsn.hp.com>
To: xemacs-beta@xemacs.org
Subject: man.el won't get CGI::Base

In XEmacs 19.15 [Lucid] (hppa1.1-hp-hpux10.20) of Tue Sep 17 1996 on mordor

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

The man.el shipped with XEmacs won't pull up manpages with :'s in the
name, CGI::Base for example.  The man.el under bug id 144 does, but
lacks the functionality of the shipping man.el

Recent input:
g RET M-x b u g TAB C-h a b u g RET C-s C-v C-v C-v 
C-v C-v C-v C-v M-x r e p o r t - e m a c s C-b C-b 
C-b C-b C-b x C-e TAB RET m a n . e l SPC w o n ' t 
SPC r e c o g n i z e SPC C G I : : B a s e C-b C-b 
C-b C-b C-b C-b C-b C-b C-b C-b C-f C-d C-d C-d M-BS 
M-DEL g e t SPC C G I C-e RET

Recent messages:

Opening nntp server on news.eng.convex.com...

Opening nntp server on news.corp.hp.com...

Opening nntp server on news.eng.convex.com...

Opening nntp server on news.corp.hp.com...

Opening nntp server on news.eng.convex.com...

From xemacs-beta-request@cs.uiuc.edu  Tue Sep 24 22:07:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id WAA08667 for xemacs-beta-people; Tue, 24 Sep 1996 22:07:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id WAA08664 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 24 Sep 1996 22:07:52 -0500 (CDT)
Received: from gol1.gol.com (root@gol1.gol.com [202.243.48.4]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id WAA25695 for <xemacs-beta@xemacs.org>; Tue, 24 Sep 1996 22:07:49 -0500 (CDT)
Received: from pentagana (jhod@tky5-185.gol.com [202.243.51.185]) by gol1.gol.com (8.7.5/8.6.9) with SMTP id MAA21913 for <xemacs-beta@xemacs.org>; Wed, 25 Sep 1996 12:07:42 +0900 (JST)
Sender: jhod@gol.com
Message-ID: <32489B2A.14C23701@po.iijnet.or.jp>
Date: Wed, 25 Sep 1996 11:39:51 +0900
From: Jareth Hein <jhod@po.iijnet.or.jp>
Organization: Sonic Software Planning, Japan
X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.13 i586)
MIME-Version: 1.0
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Mule woes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Update on my continuing quest for mule-ness. Unfortunatly, attempting
to use an XIM-ized Mule with any type of XIM setting (over-the-spot or
root-window) goes boom on my system. I found one buglet that I include a
patch below, but it still will rather quickly go down in flames. An
interesting note: All of my systems are X11R6 based, whereas I believe
Solaris 2.5 (and therefore presumably Martin's development space???) is
X11R5 based. Problem here? After doing a bit of rooting around in Xlib,
I have found that for whatever reason, R6 is calling _XimDisconnect
inside of emacs_Xt_next_event after processing a single character, and
then when it starts to handle the next Xim related event (spot moving,
focus change, whatever), _XimReCreateIC goes up in flames trying to
malloc zero bytes. Now, I haven't had the time to dig up exactly what
the purpose of Disconnecting/Reconnecting is, nor why it should fail,
but something smells to me like memory stomping. Especially since that
very frequently Mule will attempt to start up, and issue a "Warning:
XOpenIM() failed...no input server available" (and usually subsequently
crash in a seemingly unrelated place) when nothing has changed in my
environment, and then just by typing again 'src/xemacs' it will find my
IM. Hmmm...

I have also recently experienced Mule not saving an SJIS encoded file in
a readable format (what remained on disk was neither SJIS, EUC or
anything I could decode...). Had to revert to the backup.

Also I found a very interesting interaction: if there are any file-local
variables contained in a SJIS-encoded file (maybe others, haven't
checked), upon loading XEmacs will ask me for a password to decrypt the
file, and refuse to recognize the file coding. Ideas?

--Jareth
jhod@po.iijnet.or.jp

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 25 09:34:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id JAA13265 for xemacs-beta-people; Wed, 25 Sep 1996 09:34:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA13262 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 25 Sep 1996 09:34:41 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id JAA26543 for <xemacs-beta@xemacs.org>; Wed, 25 Sep 1996 09:34:37 -0500 (CDT)
Received: from kramer.aventail.com (root@newman [192.168.1.1]) by newman (8.6.12/8.6.9) with SMTP id HAA27675; Wed, 25 Sep 1996 07:32:34 -0700
Date: Wed, 25 Sep 1996 07:32:34 -0700
Message-Id: <199609251432.HAA27675@newman>
From: William Perry <wmperry@aventail.com>
To: rms@gnu.ai.mit.edu
Subject: New function: add-face-to-region
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

I've been wanting something like this in Emacs/XEmacs for a while (ever
since they started supporting a list-of-faces as the value of the 'face
property.  This currently works in both Emacsen.

Basically, this allows you to add a face to a region of text without
completely destroying the faces already in effect.  So if you have a buffer
like:

This text is red
This text is blue

And you wanted to turn those two lines 'bold', but retain the colors, you
couldn't do it without explicitly checking existing 'face properties on
ranges of text, etc.  I think its rather wasteful to replicate this code
all over the place in the different packages that need it.

Perhaps it would be useful to generalize this?  Something like
append-text-property that would work similarly for any property?

I think this will be really useful once you can specify font properties in
chunks like we have talked about briefly before (I really need to find time
to flesh that out more).  You would merge the 'font-style property, while
still keeping the 'font-weight, 'font-height, and 'font-family properties.

BTW: I'm working on getting the copyright disclaimers for my work on
     Emacs.  Been very very busy at work - not much time for emacs hacking
     until this morning.  Insomnia can be such a boon. :)

-Bill P.

(defun add-face-to-region (st nd face &optional object)
  "Add FACE to all characters between ST and ND in OBJECT.
ST, ND, and OBJECT have the same possible values as in put-text-property.
FACE can be either a single face or a list of faces.

This preserves other faces that might be currently active in the region.
This is useful for turning a region 'bold' but still retain any color
formatting that is already in effect."
  (let (tmp old-face done new-faces)
    (while (not done)
      (setq tmp (next-single-property-change st 'face object nd)
	    old-face (get-text-property st 'face object))
      (cond
       ((null old-face)			; First face to be put in
	(setq new-faces
	      (if (listp face)
		  face
		(list face))))
       ((facep old-face)		; Single face existing already
	(setq new-faces (if (listp face)
			   (append face (list old-face))
			 (list face old-face))))
       ((listp old-face)		; Multiple faces existing already
	(setq new-faces (if (listp face)
			   (append face old-face)
			 (cons face old-face))))
       (t
	(error "add-face-to-region: I'm very confused!")))
      (put-text-property st tmp 'face new-faces object)
      (setq st tmp
	    done (= nd st)))))


From xemacs-beta-request@cs.uiuc.edu  Wed Sep 25 10:40:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA13496 for xemacs-beta-people; Wed, 25 Sep 1996 10:40:44 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA13493 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 25 Sep 1996 10:40:43 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA14856 for <xemacs-beta@cs.uiuc.edu>; Wed, 25 Sep 1996 10:40:41 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id IAA09953; Wed, 25 Sep 1996 08:43:48 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: New function: add-face-to-region
References: <199609251432.HAA27675@newman>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: William Perry's message of Wed, 25 Sep 1996 07:32:34 -0700
Mime-Version: 1.0 (generated by tm-edit 7.87)
Content-Type: text/enriched; charset=US-ASCII
Date: 25 Sep 1996 08:43:47 -0700
Message-ID: <m2ranq38i4.fsf@deanna.miranova.com>
Lines: 27
X-Mailer: Red Gnus v0.41/XEmacs 19.15

>>>>> "William" == William Perry <<wmperry@aventail.com> writes:

William> I've been wanting something like this in Emacs/XEmacs for a
William> while ...

William> Basically, this allows you to add a face to a region of text
William> without completely destroying the faces already in effect.
William> So if you have a buffer like:

William> <x-color><param>red</param>This text is red</x-color>
William> <x-color><param>blue</param>This text is blue</x-color>

There is already code to do this in <italic>enriched mode</italic>.


<x-color><param>red</param><bold>This text is red</bold></x-color><bold>
<x-color><param>blue</param>This text is blue</x-color>
</bold>
I changed the above two lines to bold after setting the colors by

selecting them, and hitting `M-g b'.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Wed Sep 25 11:06:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id LAA13716 for xemacs-beta-people; Wed, 25 Sep 1996 11:06:51 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA13713 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 25 Sep 1996 11:06:50 -0500 (CDT)
Received: from newman (root@aventail.seanet.com [199.181.165.9]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id LAA18867 for <xemacs-beta@cs.uiuc.edu>; Wed, 25 Sep 1996 11:06:49 -0500 (CDT)
Received: from kramer.aventail.com (root@newman [192.168.1.1]) by newman (8.6.12/8.6.9) with SMTP id JAA28088; Wed, 25 Sep 1996 09:04:52 -0700
Date: Wed, 25 Sep 1996 09:04:52 -0700
Message-Id: <199609251604.JAA28088@newman>
From: William Perry <wmperry@aventail.com>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: New function: add-face-to-region
In-Reply-To: <m2ranq38i4.fsf@deanna.miranova.com>
References: <199609251432.HAA27675@newman>
	<m2ranq38i4.fsf@deanna.miranova.com>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Steven L. Baur writes:
>>>>>> "William" == William Perry <<wmperry@aventail.com> writes:
>
>William> I've been wanting something like this in Emacs/XEmacs for a
>William> while ...
>
>William> Basically, this allows you to add a face to a region of text
>William> without completely destroying the faces already in effect.
>William> So if you have a buffer like:
>
>William> <x-color><param>red</param>This text is red</x-color>
>William> <x-color><param>blue</param>This text is blue</x-color>
>
>There is already code to do this in <italic>enriched mode</italic>.

  But its not very general.

-Bill P.


From xemacs-beta-request@cs.uiuc.edu  Thu Sep 26 02:40:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id CAA16586 for xemacs-beta-people; Thu, 26 Sep 1996 02:40:29 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id CAA16583 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 26 Sep 1996 02:40:28 -0500 (CDT)
Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id CAA28280 for <xemacs-beta@xemacs.org>; Thu, 26 Sep 1996 02:40:20 -0500 (CDT)
Received: from sun.rhrk.uni-kl.de by stepsun.uni-kl.de id aa10218;
          26 Sep 96 9:40 MET DST
Received: from aix8.rhrk.uni-kl.de by sun.rhrk.uni-kl.de id aa02750;
          26 Sep 96 9:40 MET DST
Received: by aix8 (Smail3.1.28.1 #7)
	id m0v6B3F-0000YtC; Thu, 26 Sep 96 09:40 CETDST
Message-Id: <m0v6B3F-0000YtC@aix8>
Date: Thu, 26 Sep 96 09:40 CETDST
From: thiessel@rhrk.uni-kl.de
To: xemacs-beta@xemacs.org
Subject: Mule on HP 9.05

Hi everybody,

I built 20.0 Beta29 with the following options on HP-UX 9.05

./configure CONFIGURATION-NAME hppa1.1-hp-hpux9 --dynamic=no \
        --prefix=/usr/local/lib/X11/xemacs --with-x \
        --with-dialogs=motif \
        --with-scrollbars=motif --with-menubars=lucid \
        --x-includes=/usr/include/X11 \
        --x-libraries=/usr/lib/X11R5 \
	--with-xpm --with-sound=no --with-gif \
        --with-gcc --with-mule=no \
	--cflags="-g -O2" --with-database=dbm

and everything is fine. No problem encountered me on running XEmacs so
far. If change configuration than and add mule support then things are
getting worse when running XEmacs. Sometimes I get

(1) (memory/critical) Warning: memory in use exceeds lisp pointer size
Killing some buffers may delay running out of memory.
However, certainly by the time you receive the 95% warning,
you should clean up, kill this Emacs, and start a new one.

(2) (memory/critical) Warning: memory in use exceeds lisp pointer size
Killing some buffers may delay running out of memory.
However, certainly by the time you receive the 95% warning,
you should clean up, kill this Emacs, and start a new one.

CCL: Invalid command (7).

BTW, there were only two buffers in there!! 

Anyone?!?!

--Marcus

____________________________________________________________________________
 Marcus Thiessel                                      I T W M 
 phone:  +49-631-205-3126 		             
 fax:    +49-631-205-3616                mail:   thiessel@itwm.uni-kl.de
____________________________________________________________________________

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 26 10:41:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA21220 for xemacs-beta-people; Thu, 26 Sep 1996 10:41:40 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA21217 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 26 Sep 1996 10:41:39 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA20617 for <xemacs-beta@cs.uiuc.edu>; Thu, 26 Sep 1996 10:41:38 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id IAA26623; Thu, 26 Sep 1996 08:45:02 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: man.el won't get CGI::Base
References: <199609250101.UAA25129@mordor.rsn.hp.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Shane Holder's message of Tue, 24 Sep 1996 20:01:13 -0500 (CDT)
Mime-Version: 1.0 (generated by tm-edit 7.88)
Content-Type: text/plain; charset=US-ASCII
Date: 26 Sep 1996 08:45:01 -0700
Message-ID: <m2u3sljn5u.fsf@deanna.miranova.com>
Lines: 21
X-Mailer: Red Gnus v0.42/XEmacs 19.15

>>>>> "Shane" == Shane Holder <holder@mordor.rsn.hp.com> writes:

Shane> The man.el shipped with XEmacs won't pull up manpages with :'s
Shane> in the name, CGI::Base for example.  The man.el under bug id
Shane> 144 does, but lacks the functionality of the shipping man.el

Please clarify.

The current, shipping man.el is a dead end:
;;; Synched up with: Not synched with FSF.
;;; ICK!  This file is almost completely different from FSF.
;;; Someone clarify please.

Our best options at this point are either to switch to Jamie's
submission in #144, or to replace the current man.el with whatever is
in 19.34, IMO.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 26 19:40:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA22786 for xemacs-beta-people; Thu, 26 Sep 1996 19:40:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA22783 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 26 Sep 1996 19:40:56 -0500 (CDT)
Received: from sym.primuscorp.com (root@[204.137.132.34]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id TAA00124 for <xemacs-beta@xemacs.org>; Thu, 26 Sep 1996 19:40:53 -0500 (CDT)
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id RAA11643 for <xemacs-beta@xemacs.org>; Thu, 26 Sep 1996 17:41:09 -0700
Received: from roy by horus (SMI-8.6/SMI-SVR4)
	id RAA18067; Thu, 26 Sep 1996 17:40:41 -0700
Received: by roy (SMI-8.6/SMI-SVR4)
	id RAA24625; Thu, 26 Sep 1996 17:40:45 -0700
Date: Thu, 26 Sep 1996 17:40:45 -0700
Message-Id: <199609270040.RAA24625@roy>
From: Damon Lipparelli <lipp@primus.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: I'm going into withdrawals....
Reply-To: Damon Lipparelli <lipp@primus.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.15 (beta2) ]

Sorry to be impatient, but any ETA for the next betas?

Thanks,
-lipp

---

Hand me a pair of leather pants and a CASIO keyboard
 -- I'm living for today!

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 26 19:25:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA22728 for xemacs-beta-people; Thu, 26 Sep 1996 19:25:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA22725 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 26 Sep 1996 19:25:42 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id TAA00090 for <xemacs-beta@xemacs.org>; Thu, 26 Sep 1996 19:25:38 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa02209;
          26 Sep 96 20:22 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id UAA27477; Thu, 26 Sep 1996 20:21:56 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id UAA03285; Thu, 26 Sep 1996 20:21:56 -0400
Date: Thu, 26 Sep 1996 20:21:56 -0400
Message-Id: <199609270021.UAA03285@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: rms@gnu.ai.mit.edu
CC: xemacs-beta@xemacs.org
Subject: A Constructive Proposal (was: Re: Versions of Emacs)
References: <Pine.LNX.3.91.960905130616.1997D-100000@icemark.thenet.ch>
	<199609062129.RAA24259@psilocin.gnu.ai.mit.edu>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Accept advice
X-WWW-Homepage: http://www.python.org/~bwarsaw


The reasons behind the Emacs split are many, and are colored by the
points of view of the many participants.  Everyone sees different
parts of history and as usual the `truth' (for whatever that's worth)
is somewhere in between.  I personally doubt that there ever will be a
merge of the two branches, and from my perspective I don't care one
way or the other.  I've made my decision and try to get on with
things.

>>>>> "RS" == Richard Stallman <rms@gnu.ai.mit.edu> writes:

    RS> Still, if the competition between Emacs and XEmacs were fair,
    RS> it would not be such a big problem.  With nothing to disagree
    RS> about except technical matters, there would be no reason for
    RS> rancour when we disagree.

Let me try to focus in on a topic where (as I see it) *only* technical
issues matter, where the legal status of the code shouldn't enter into
it, and where (I hope) the two camps can begin to productively work
together.  I want to talk about Interface Skew; the differences in
APIs to various features.

Interface design seems to me to be purely technical; RMS doesn't need
papers from me for an API design of mine, if he gets someone else to
implement it.  But too often the APIs to useful features are different
in the two Emacsen, usually because there was little or no dialog
between the two camps while the API was being designed or feature was
being implemented.  Even when a feature was copied from one to the
other (and probably reimplemented) the existing API was not always
adopted.

Putting on my module author hat, this is the worst of all worlds
because I have to now become an expert for two different APIs with
different semantics and feature sets.  Now, I know its hard based on
the big differences in the way the two Emacsen are implemented, to get
100% compatibility, but I really do think we can do better.

A couple of examples:

1. I originally implemented dual-comments (in syntax.c to support C
   and C++ comments) in Emacs 18.  My first design of the lisp-level
   interface wasn't great, but it mostly worked and was a good first
   shot.  When Lucid Emacs 19 came out, I set about porting my changes
   to it and had some discussions with Jamie about ways to improve the
   implementation and API.  These changes eventually made it into
   Lemacs.  When Emacs 19 came out, it had my first attempt, which I'd
   submitted to RMS.  I'd offered at the time to update Emacs 19 to my
   new approach, but I think RMS didn't think it was necessary at the
   time.  Later he did ask me to update to the L/XEmacs API, but by
   then I didn't have the time (or truth be told) desire to do that
   work.  So now we have two different APIs to this feature.
   Admittedly I take blame for that, and in reality it probably only
   affects me in my role of cc-mode maintainer, but I've long had code
   to work around it so it seems pointless to waste time worrying
   about it.

2. Menus are another feature that's had different APIs.  I'm not a
   menu expert; I don't like them for Emacs, nor do I use them, so I
   never really wanted to spend time learning all about them.  I
   especially didn't want to become an expert in two different APIs!
   Thankfully, this story has a happy ending with the excellent
   easymenu.el package.  Now I have one API I need to worry about, its
   pretty easy to learn and code up, so now python-mode.el has simple
   working menus.  Joy!

I want us to identify other features that suffer from Interface Skew.
I can think of text-extents/overlays as one area, keymaps maybe as
another.  What else?

To (eventually) correct this problem, and to prevent future needless
Interface Skew, I propose we:

1. Identify those APIs that are different between the two Emacsen.

2. Create a neutral mailing list that both the Emacs and XEmacs
   developers/maintainers would be part of that would discuss and hash
   out, (hopefully in a cooperative manner :-) the differences.

3. Have some semi-formal method for adopting API proposals which
   wouldn't be subject to the whim of any one developer.  I'm thinking
   of a sort-of mini IETF WG for Emacs. :-) But it needn't be that
   formal.

4. Let the various X/Emacs developers go off and implement the
   features to the API however they wish.

5. Use this new forum for generating consensus for new APIs *before*
   new features get implemented.

Let's see if we really can have a constructive, positive, cooperative
discussion on the technical merits.

On a related note.  Its been my observation that XEmacs development is
much more open in the sense that while a limited number of people do
the actual coding of the internals, there is very lively discussion
among those who care about the design of features and their APIs.  I
contrast this with the FSF's development of Emacs which seems to be
much more closed w.r.t. to feature and API development.  Perhaps, I'm
on the wrong GNU mailing list, but I do not see any kind of forum for
discussion of Emacs development, like I do on the XEmacs developers
mailing list.  So let me add:

6. Open up Emacs development discussions to a wider audience.

-Barry

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 26 20:02:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA22824 for xemacs-beta-people; Thu, 26 Sep 1996 20:02:42 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA22821 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 26 Sep 1996 20:02:41 -0500 (CDT)
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA11143 for <xemacs-beta@cs.uiuc.edu>; Thu, 26 Sep 1996 20:02:40 -0500 (CDT)
Received: (qmail 18660 invoked by uid 52477); 27 Sep 1996 01:02:38 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Subject: Re: man.el won't get CGI::Base
References: <199609250101.UAA25129@mordor.rsn.hp.com> <m2u3sljn5u.fsf@deanna.miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sudish@mindspring.com>
Date: 26 Sep 1996 21:02:37 -0400
In-Reply-To: Steven L Baur's message of 26 Sep 1996 08:45:01 -0700
Message-ID: <yviaybhwkbwy.fsf@atreides.mindspring.com>
Lines: 16
X-Mailer: Red Gnus v0.41/XEmacs 19.15

Steven L Baur <steve@miranova.com> writes:
> Our best options at this point are either to switch to Jamie's
> submission in #144, or to replace the current man.el with whatever is
> in 19.34, IMO.

I've been using the one that comes with 19.31 with 19.14 and 15b2.
I'd vote for making it the default man.el for XEmacs. 

It has all the bells and whistles, is very frame aware, fast, does the
translation to faces very well, groks sections, groks SEE ALSO, groks
args passed by the user to man (M-x man "3 syslog"), runs
asynchronously, and offers 6 ways to interrupt what you're doing when
it's got the page ready to display.  All in all, a very well designed
package.

-Sudish

From xemacs-beta-request@cs.uiuc.edu  Thu Sep 26 21:26:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id VAA23039 for xemacs-beta-people; Thu, 26 Sep 1996 21:26:18 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id VAA23036 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 26 Sep 1996 21:26:17 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id VAA18145 for <xemacs-beta@cs.uiuc.edu>; Thu, 26 Sep 1996 21:26:14 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id TAA01672; Thu, 26 Sep 1996 19:29:37 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: man.el won't get CGI::Base
References: <199609250101.UAA25129@mordor.rsn.hp.com> <m2u3sljn5u.fsf@deanna.miranova.com> <yviaybhwkbwy.fsf@atreides.mindspring.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Sudish Joseph's message of 26 Sep 1996 21:02:37 -0400
Mime-Version: 1.0 (generated by tm-edit 7.88)
Content-Type: text/plain; charset=US-ASCII
Date: 26 Sep 1996 19:29:35 -0700
Message-ID: <m2pw38d71s.fsf@deanna.miranova.com>
Lines: 43
X-Mailer: Red Gnus v0.43/XEmacs 19.15

>>>>> "Sudish" == Sudish Joseph <sudish@mindspring.com> writes:
>>>>> "sb" == Steven L Baur <steve@miranova.com> writes:

sb> Our best options at this point are either to switch to Jamie's
sb> submission in #144, or to replace the current man.el with whatever is
sb> in 19.34, IMO.

Sudish> I've been using the one that comes with 19.31 with 19.14 and 15b2.
Sudish> I'd vote for making it the default man.el for XEmacs. 

Sudish> It has all the bells and whistles, is very frame aware, fast,
Sudish> does the translation to faces very well, groks sections, groks
Sudish> SEE ALSO, groks args passed by the user to man (M-x man "3
Sudish> syslog"), runs asynchronously, and offers 6 ways to interrupt
Sudish> what you're doing when it's got the page ready to display.
Sudish> All in all, a very well designed package.

O.K.  I went out and checked all three side by side by side for the
first time.

I hadn't checked authorship of man.el in Emacs 19.34 before:
;;; man.el --- browse UNIX manual pages

;; Copyright (C) 1993, 1994, 1996 Free Software Foundation, Inc.

;; Author:		Barry A. Warsaw <bwarsaw@cen.com>

It does indeed work copied straight from 19.34, and without all the
cruft left by either man.el-19.14 or man.el-jwz (both of which manage
to invoke less(1) in my environment). :-(

Two minor problems with it are that it trashes the color in the mode
line, and the SEE ALSO references should be mouse clickable.  One of
which will be fixed by making the thing work with view-less, the other
should be an easy fix.

I'm now strongly in favor of using Barry's version.  The output is
cleaner and the resulting man.el will be closely synched with 19.34.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 27 07:55:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id HAA27704 for xemacs-beta-people; Fri, 27 Sep 1996 07:55:29 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA27701 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 27 Sep 1996 07:55:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA00896; Fri, 27 Sep 1996 07:55:25 -0500 (CDT)
Message-Id: <199609271255.HAA00896@xemacs.cs.uiuc.edu>
To: Damon Lipparelli <lipp@primus.com>
cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: I'm going into withdrawals.... 
In-reply-to: Your message of "Thu, 26 Sep 1996 17:40:45 PDT."
             <199609270040.RAA24625@roy> 
Date: Fri, 27 Sep 1996 07:55:23 -0500
From: Chuck Thompson <cthomp@xemacs.org>

    Damon> Sorry to be impatient, but any ETA for the next betas?

Before about 5:00 on Saturday.  I'm leaving for LISA then and I
definitely don't want to leave people hanging for yet another week.
Sorry for the delay.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 27 08:04:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA27734 for xemacs-beta-people; Fri, 27 Sep 1996 08:04:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA27731 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 27 Sep 1996 08:04:03 -0500 (CDT)
Received: from chekov.ctd.comsat.com (exim@chekov.ctd.comsat.com [134.133.40.22]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id IAA06723 for <xemacs-beta@cs.uiuc.edu>; Fri, 27 Sep 1996 08:04:02 -0500 (CDT)
Received: from neal by chekov.ctd.comsat.com with local (Exim 0.56 #3)
	id E0v6caH-00005L-00; Fri, 27 Sep 1996 09:04:01 -0400
To: xemacs-beta@cs.uiuc.edu
Subject: Re: man.el won't get CGI::Base
References: <199609250101.UAA25129@mordor.rsn.hp.com>
	<m2u3sljn5u.fsf@deanna.miranova.com>
	<yviaybhwkbwy.fsf@atreides.mindspring.com>
	<m2pw38d71s.fsf@deanna.miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.88)
Content-Type: text/plain; charset=US-ASCII
From: Neal Becker <neal@ctd.comsat.com>
Date: 27 Sep 1996 09:04:00 -0400
In-Reply-To: Steven L Baur's message of 26 Sep 1996 19:29:35 -0700
Message-ID: <u9pw38p0sf.fsf@chekov.ctd.comsat.com>
Lines: 2
X-Mailer: Gnus v5.2.40/XEmacs 19.15

Whichever version you choose, please include my rman patch.  This
makes it so much faster and more reliable on my hpux system.

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 27 10:22:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA28203 for xemacs-beta-people; Fri, 27 Sep 1996 10:22:56 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA28200 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 27 Sep 1996 10:22:55 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA17596 for <xemacs-beta@cs.uiuc.edu>; Fri, 27 Sep 1996 10:22:53 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id IAA04315; Fri, 27 Sep 1996 08:26:18 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [Oliver Imbusch <flabes@inform-ac.com>] got no ack from XEmacs mailing list/Chuck Thompson
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.88)
Content-Type: multipart/mixed;
 boundary="Multipart_Fri_Sep_27_08:26:16_1996-1"
Content-Transfer-Encoding: 7bit
Date: 27 Sep 1996 08:26:16 -0700
Message-ID: <m24tkk9dyf.fsf@deanna.miranova.com>
Lines: 85
X-Mailer: Red Gnus v0.43/XEmacs 19.15

--Multipart_Fri_Sep_27_08:26:16_1996-1
Content-Type: text/plain; charset=US-ASCII

This is becoming a FAQ for which I don't have a good answer.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

--Multipart_Fri_Sep_27_08:26:16_1996-1
Content-Type: message/rfc822

Date: Fri, 27 Sep 1996 09:26:26 +0200
Message-Id: <199609270726.JAA06464@pumpkin.>
To: "Steven L. Baur" <steve@miranova.com>
Subject: got no ack from XEmacs mailing list/Chuck Thompson
From: Oliver Imbusch <flabes@inform-ac.com>
Organization: INFORM GmbH, Aachen, Germany

Hi Steve,

some days ago I've posted some toubles with core dumping XEmacs and
difficulties in building a purified XEmacs to the mailing list and --
after I didn't get any reaction -- to Chuck Thompson, who also didn't
even send an ack. Since you often post to the list and appear to be
actively envolved in the XEmacs development I am asking you: Did you
see my message in the list? Is Chuck on holiday/completely overloaded?
I would at least expect "this is an old problem but we currently have
no solution" response.

Thanx in advance
	Oliver


--Multipart_Fri_Sep_27_08:26:16_1996-1
Content-Type: message/rfc822

To: Oliver Imbusch <flabes@inform-ac.com>
Subject: We're lurking (was Re: got no ack from XEmacs mailing list/Chuck Thompson)
From: Steven L Baur <steve@miranova.com>
Date: 27 Sep 1996 08:20:14 -0700
Message-ID: <m27mpg9e8h.fsf@deanna.miranova.com>

>>>>> "Oliver" == Oliver Imbusch <flabes@inform-ac.com> writes:

Oliver> Hi Steve,

Oliver> some days ago I've posted some toubles with core dumping
Oliver> XEmacs and difficulties in building a purified XEmacs to the
Oliver> mailing list and -- after I didn't get any reaction -- to
Oliver> Chuck Thompson, who also didn't even send an ack. Since you
Oliver> often post to the list and appear to be actively envolved in
Oliver> the XEmacs development I am asking you: Did you see my message
Oliver> in the list? Is Chuck on holiday/completely overloaded?  I
Oliver> would at least expect "this is an old problem but we currently
Oliver> have no solution" response.

Chuck is on total overload right now.  I saw your message, and I
archive the newsgroup (as Chuck and others do).  I just tend not to
respond to messages where my only answer is ``I don't know'', as it is
in your case.

At any rate, if you don't get an answer in the newsgroup you are no
more likely to get an answer sending personal email (less likely for
example if you send it to me, since I prefer to respond on the
newsgroup so I don't end up answering the same question several times,
like I will with this response :-( ).  If I saw your question on the
newsgroup and don't respond that generally means ``I don't know'', and
it would take too long to pore through the source code to figure out a
response.

The basic answer is the XEmacs developers see everything that goes by
in this newsgroup, but there are only so many hours in a day.  We're
all volunteers and are doing the best we can.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.


--Multipart_Fri_Sep_27_08:26:16_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 27 10:35:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA28257 for xemacs-beta-people; Fri, 27 Sep 1996 10:35:02 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA28254 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 27 Sep 1996 10:35:01 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA20167 for <xemacs-beta@cs.uiuc.edu>; Fri, 27 Sep 1996 10:34:58 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id IAA04456; Fri, 27 Sep 1996 08:38:23 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: man.el won't get CGI::Base
References: <199609250101.UAA25129@mordor.rsn.hp.com> 	<m2u3sljn5u.fsf@deanna.miranova.com> 	<yviaybhwkbwy.fsf@atreides.mindspring.com> 	<m2pw38d71s.fsf@deanna.miranova.com> <u9pw38p0sf.fsf@chekov.ctd.comsat.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Neal Becker's message of 27 Sep 1996 09:04:00 -0400
Mime-Version: 1.0 (generated by tm-edit 7.88)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 27 Sep 1996 08:38:21 -0700
Message-ID: <m2ybhw7ytu.fsf@deanna.miranova.com>
Lines: 15
X-Mailer: Red Gnus v0.43/XEmacs 19.15

>>>>> "Neal" == Neal Becker <neal@ctd.comsat.com> writes:

Neal> Whichever version you choose, please include my rman patch.
Neal> This makes it so much faster and more reliable on my hpux
Neal> system.

O.K.  Warsaw/Potort/et.al. man.el from 19.34 it is, patched up for
view-less, mousable SEE ALSOs, and Neal's rman flag.  Anything else
I'm missing?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 27 14:18:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA29268 for xemacs-beta-people; Fri, 27 Sep 1996 14:18:12 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA29265 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 27 Sep 1996 14:18:11 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA11398 for <xemacs-beta@cs.uiuc.edu>; Fri, 27 Sep 1996 14:18:08 -0500 (CDT)
Received: from mordor.rsn.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA148061885; Fri, 27 Sep 1996 12:18:05 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id OAA07893; Fri, 27 Sep 1996 14:23:04 -0500 (CDT)
To: xemacs-beta@cs.uiuc.edu
Subject: Re: man.el won't get CGI::Base
References: <199609250101.UAA25129@mordor.rsn.hp.com> 	<m2u3sljn5u.fsf@deanna.miranova.com> 	<yviaybhwkbwy.fsf@atreides.mindspring.com> 	<m2pw38d71s.fsf@deanna.miranova.com> <u9pw38p0sf.fsf@chekov.ctd.comsat.com> <m2ybhw7ytu.fsf@deanna.miranova.com>
From: Shane Holder <holder@mordor.rsn.hp.com>
Date: 27 Sep 1996 14:23:03 -0500
In-Reply-To: Steven L Baur's message of 27 Sep 1996 08:38:21 -0700
Message-Id: <fawg243n4o8.fsf@mordor.rsn.hp.com>
Lines: 19
X-Mailer: Red Gnus v0.42/XEmacs 19.15

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

>>>>> "Neal" == Neal Becker <neal@ctd.comsat.com> writes:

  Neal> Whichever version you choose, please include my rman patch.
  Neal> This makes it so much faster and more reliable on my hpux
  Neal> system.

  Steven> O.K.  Warsaw/Potort/et.al. man.el from 19.34 it is, patched
  Steven> up for view-less, mousable SEE ALSOs, and Neal's rman flag.
  Steven> Anything else I'm missing?

Wow, if only everything was that easy. :)

-- 
Shane Holder                                 e-mail: holder@rsn.hp.com
Hewlett Packard                               phone:     (214)497-4182
3000 Waterview                       Never underestimate the bandwidth
Richardson, TX 75083                 of a truck moving at 70 MPH.

From xemacs-beta-request@cs.uiuc.edu  Fri Sep 27 18:26:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA29981 for xemacs-beta-people; Fri, 27 Sep 1996 18:26:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA29978 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 27 Sep 1996 18:26:38 -0500 (CDT)
Received: from ethanol.gnu.ai.mit.edu (rms@ethanol.gnu.ai.mit.edu [128.52.46.64]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id SAA01839 for <xemacs-beta@xemacs.org>; Fri, 27 Sep 1996 18:26:35 -0500 (CDT)
Received: by ethanol.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id TAA05343; Fri, 27 Sep 1996 19:27:24 -0400
Date: Fri, 27 Sep 1996 19:27:24 -0400
Message-Id: <199609272327.TAA05343@ethanol.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: bwarsaw@cnri.reston.va.us
CC: xemacs-beta@xemacs.org
In-reply-to: <199609270021.UAA03285@anthem.CNRI.Reston.Va.US>
	(bwarsaw@anthem.cnri.reston.va.us)
Subject: Re: A Constructive Proposal (was: Re: Versions of Emacs)

I don't like discussions by email because that is much slower than
voice, misunderstandings tend to grow and deepen, and also typing
hurts my hands.  So I generally do it only when I see a specific
reason it is useful.  I usually have the discussion with specific
people who I know are experts on the matter.

Barry, if you'd like me to explain more, please phone me.

From xemacs-beta-request@cs.uiuc.edu  Sat Sep 28 15:32:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id PAA06334 for xemacs-beta-people; Sat, 28 Sep 1996 15:32:24 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA06331 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 28 Sep 1996 15:32:22 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA02834 for <xemacs-beta@xemacs.org>; Sat, 28 Sep 1996 15:32:20 -0500 (CDT)
Message-Id: <199609282032.PAA02834@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: no beta for another week and a half
Date: Sat, 28 Sep 1996 15:32:18 -0500
From: Chuck Thompson <cthomp@xemacs.org>

And my sincere apologies for that being the case...



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Sat Sep 28 23:03:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA07268 for xemacs-beta-people; Sat, 28 Sep 1996 23:03:50 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA07265 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 28 Sep 1996 23:03:49 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA17918 for <xemacs-beta@cs.uiuc.edu>; Sat, 28 Sep 1996 23:03:49 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id VAA23036; Sat, 28 Sep 1996 21:07:14 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [David Masterson <davidm@maui.kla.com>] Package Standards (was Re: WHere can I find the X OO Browser)
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.88)
Content-Type: multipart/mixed;
 boundary="Multipart_Sat_Sep_28_21:07:13_1996-1"
Content-Transfer-Encoding: 7bit
Date: 28 Sep 1996 21:07:13 -0700
Message-ID: <m2ohiq55hq.fsf@deanna.miranova.com>
Lines: 88
X-Mailer: Red Gnus v0.45/XEmacs 19.15

--Multipart_Sat_Sep_28_21:07:13_1996-1
Content-Type: text/plain; charset=US-ASCII

This should be of interest for future development, even if not for 19.15.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

--Multipart_Sat_Sep_28_21:07:13_1996-1
Content-Type: message/rfc822

To: Steven L Baur <steve@miranova.com>
Subject: Package Standards (was Re: WHere can I find the X OO Browser)
References: <529o3j$mf@soenews.ucsd.edu> <m2ohiu1l8h.fsf@deanna.miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.85)
Content-Type: text/plain; charset=US-ASCII
From: David Masterson <davidm@maui.kla.com>
Date: 27 Sep 1996 11:02:59 -0700
Message-Id: <tzn2yb25v0.fsf_-_@baldy.kla.com>

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

>>>>> "Sean" == Sean O'Keeffe <sokeeffe@ucsd.edu> writes:

Sean> The OO Browser Info pages describes a graphical X browser called
Sean> xoobr.  Where can I find it?  I have looked through the
Sean> distribution and I can't find any reference to it.  I am using
Sean> XEmacs under Solaris 2.5.

> It's in a tough place to find.  Look in `lisp/oobr/tree-x' and
> `lisp/oobr/tree-nx'.  I believe it will be moved to a more logical place in
> 19.15.

Do you know if a packaging standard is being addressed for 19.15+ (I'd also
like to see this addressed in GNU Emacs, but that's another story)?  In the
past, installing a new package into Emacs typically involved:

* untar the package in a temporary directory
* adjust the Makefile for the site accordingly
* run 'make' to build elc files and special stuff
* either:
** run 'make install' to install in your home directory
** have the owner of Emacs run the Makefile to generally install
* hand adjust either or both:
** your .emacs for custom setup
** the site-start/default for global setup

Having done this for several releases of Emacs, I find this to be error prone
and would like to see a standard something like the following:

1. As is currently done, Emacs should automatically configure the load-path to
   include all the first-level subdirectories of the lisp and site-lisp
   directories.
2. Before running the site-start file, Emacs should automatically run any
   pkg-start files in these subdirectories.  Through the use of require and
   autoload, these files should be structured to make Emacs aware of each
   package and the commands that they implement.
3. Emacs should automatically add any 'info' subdirectories in these package
   directories to Info-directory-list.  It will be expected that the package
   has a dir/localdir file in the info directory so that Info will know about
   the package's Info files.
4. After running the default.el file, Emacs should automatically run the
   pkg-default.el files in the package directories.  These files will setup
   special variables for the package.
5. The execution of #2 and #4 should still be inhibitable as is currently done
   ('-no-site-file' and '-no-init-file', as well as 'inhibit-default-init').

The one question left is how to adapt this for the case of special xbm (etc.)
files for toolbars and special (system-specific) executables.  If a standard
like this is adopted, then installing new packages would be trivial -- just
untar the directory in pkg-lisp and run 'make' (individual users still do
their customizations in their .emacs).

What do you think?  Could something like this be adopted?

-- 
==================================================================
David Masterson				KLA Instruments
408-456-6836				P.O. Box 49055 M/S F1-9440
davidm@prism.kla.com			San Jose, CA 95161-9055
==================================================================
      I only speak for myself -- it keeps me out of trouble


--Multipart_Sat_Sep_28_21:07:13_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Sun Sep 29 18:28:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA12561 for xemacs-beta-people; Sun, 29 Sep 1996 18:28:20 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA12558 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 29 Sep 1996 18:28:19 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA01667 for <xemacs-beta@cs.uiuc.edu>; Sun, 29 Sep 1996 18:28:17 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id QAA26062; Sun, 29 Sep 1996 16:31:22 -0700
Sender: steve@miranova.com
To: cthmop@xemacs.org
Cc: xemacs-beta@cs.uiuc.edu
Subject: PATCH: cperl-mode.el (was Re: cperl-mode menu not loading)
References: <4t5hg6$8b3@mordred.gatech.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: william@amber.biology.gatech.edu's message of 24 Jul 1996 16:03:18 GMT
Mime-Version: 1.0 (generated by tm-edit 7.88)
Content-Type: text/plain; charset=US-ASCII
Date: 29 Sep 1996 16:30:52 -0700
Message-ID: <m2ybhslx03.fsf@deanna.miranova.com>
Lines: 62
X-Mailer: Red Gnus v0.44/XEmacs 19.15

This is a reasonable enough request.  Here's a patch to fix it:

*** modes/cperl-mode.el~	Sun Sep  8 16:49:30 1996
--- modes/cperl-mode.el	Sun Sep 29 16:20:48 1996
***************
*** 709,714 ****
--- 709,716 ----
  ;; provide an alias for working with emacs 19.  the perl-mode that comes
  ;; with it is really bad, and this lets us seamlessly replace it.
  (fset 'perl-mode 'cperl-mode)
+ 
+ ;;;###autoload
  (defun cperl-mode ()
    "Major mode for editing Perl code.
  Expression and list commands understand all C brackets.
***************
*** 928,933 ****
--- 930,938 ----
    (and (boundp 'msb-menu-cond)
         (not cperl-msb-fixed)
         (cperl-msb-fix))
+   ;; XEmacs
+   (when (featurep 'menubar)
+     (easy-menu-add cperl-menu))
    (run-hooks 'cperl-mode-hook)
    ;; After hooks since fontification will break this
    (if cperl-pod-here-scan (cperl-find-pods-heres)))
***************
*** 3034,3036 ****
--- 3039,3044 ----
    (message "Parentheses will %sbe auto-doubled now." 
  	   (if (cperl-val 'cperl-electric-parens) "" "not ")))
  
+ (provide 'cperl-mode)
+ 
+ ;;; cperl-mode.el ends here


>>>>> "William" == William S Hayes <william@amber.biology.gatech.edu> writes:

William> It doesn't automatically load when I enter a perl program.  It
William> does font-lock it and CPerl shows in the modeline at the bottom.
William> I also have cperl-hairy set to t (true).

William> I can get the menu loaded when I M-x load-file ~/.emacs

William> I am running Emacs 19.14 on a Solaris 2.4 using a Sparc 5.

William> Thanks for any assistance.





William> BTW: 19.14 is a nice upgrade on a great editor.  


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Oct  1 10:20:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA26343 for xemacs-beta-people; Tue, 1 Oct 1996 10:20:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA26340 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 1 Oct 1996 10:20:41 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA07136 for <xemacs-beta@xemacs.org>; Tue, 1 Oct 1996 10:20:36 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.7.5/8.7.3) with ESMTP id KAA26110 for <xemacs-beta@xemacs.org>; Tue, 1 Oct 1996 10:17:47 -0500
Message-Id: <199610011517.KAA26110@nvwls.cc.purdue.edu>
Reply-to: nuspl@purdue.edu
X-Mailer: MH-E 5.0.2
X-Attribution: JJN
X-Face: K'Q`VIQx)c-;TPHDA`.,kBQq(WyNe3AdopJ?B(.4yT%n|F?4>+?x]pQ4XC83s-4;|U{%9x]
 =yr4dko
To: xemacs-beta@xemacs.org
Subject: Key names: XEmacs vs. RMS
Date: Tue, 01 Oct 1996 10:17:42 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


XEmacs uses an underscore in the names of extended keys while the RMS
version uses dashes (i.e. kp_add vs kp-add).

Is there a history behind this?  Is there any reason why they should
be named with an underscore instead of a dash?  If not, I vote for
changing them to dashes.

Joe

From xemacs-beta-request@cs.uiuc.edu  Tue Oct  1 11:32:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id LAA26744 for xemacs-beta-people; Tue, 1 Oct 1996 11:32:39 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA26741 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 1 Oct 1996 11:32:38 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA11370 for <xemacs-beta@cs.uiuc.edu>; Tue, 1 Oct 1996 11:32:35 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id JAA07290; Tue, 1 Oct 1996 09:35:46 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Key names: XEmacs vs. RMS
References: <199610011517.KAA26110@nvwls.cc.purdue.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: "Joseph J. Nuspl Jr."'s message of Tue, 01 Oct 1996 10:17:42 -0500
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Date: 01 Oct 1996 09:35:44 -0700
Message-ID: <m27mpay74v.fsf@deanna.miranova.com>
Lines: 16
X-Mailer: Red Gnus v0.46/XEmacs 19.15

>>>>> "JJN" == Joseph J Nuspl <nuspl@nvwls.cc.purdue.edu> writes:

JJN> XEmacs uses an underscore in the names of extended keys while the RMS
JJN> version uses dashes (i.e. kp_add vs kp-add).

JJN> Is there a history behind this?  Is there any reason why they should
JJN> be named with an underscore instead of a dash?  If not, I vote for
JJN> changing them to dashes.

Seconded.  Should I go ahead and change them?  There are a lot of
files involved.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Thu Oct  3 04:21:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA10229 for xemacs-beta-people; Thu, 3 Oct 1996 04:21:47 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA10226 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 3 Oct 1996 04:21:44 -0500 (CDT)
Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id EAA14360 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 04:21:38 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id CAA03312 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 02:21:17 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id CAA27999 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 02:21:14 -0700
Date: Thu, 3 Oct 1996 02:21:14 -0700
Message-Id: <199610030921.CAA27999@shellx.best.com>
From: Ben Wing <wing@666.com>
To: xemacs-beta@cs.uiuc.edu, Steven L Baur <steve@miranova.com>
Subject: Re: Key names: XEmacs vs. RMS
References: <199610011517.KAA26110@nvwls.cc.purdue.edu>

	>>>>> "JJN" == Joseph J Nuspl <nuspl@nvwls.cc.purdue.edu> writes:
	
	JJN> XEmacs uses an underscore in the names of extended keys while the RMS
	JJN> version uses dashes (i.e. kp_add vs kp-add).
	
	JJN> Is there a history behind this?  Is there any reason why they should
	JJN> be named with an underscore instead of a dash?  If not, I vote for
	JJN> changing them to dashes.
	
	Seconded.  Should I go ahead and change them?  There are a lot of
	files involved.

The underscores exist because that's how they're represented in the
X keysyms.  However, there's no reason we have to be bound to those
keysyms (and good reasons not to be, so that we have some semblance
of device-independence); so go ahead and make the change.

ben

From xemacs-beta-request@cs.uiuc.edu  Thu Oct  3 04:28:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA10245 for xemacs-beta-people; Thu, 3 Oct 1996 04:28:00 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA10242 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 3 Oct 1996 04:27:59 -0500 (CDT)
Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id EAA14394 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 04:27:53 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id CAA03767 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 02:27:36 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id CAA00041 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 02:27:34 -0700
Date: Thu, 3 Oct 1996 02:27:34 -0700
Message-Id: <199610030927.CAA00041@shellx.best.com>
From: Ben Wing <wing@666.com>
To: xemacs-beta@cs.uiuc.edu, Steven L Baur <steve@miranova.com>
Subject: Re: man.el won't get CGI::Base
References: <199609250101.UAA25129@mordor.rsn.hp.com> 
    <m2u3sljn5u.fsf@deanna.miranova.com> 
    <yviaybhwkbwy.fsf@atreides.mindspring.com> 
    <m2pw38d71s.fsf@deanna.miranova.com> <u9pw38p0sf.fsf@chekov.ctd.comsat.com>

If you're feeling truly masochistic, try doing the same to etags.el.
Whatever you come up with will be better than the current situation.

If you're feeling even more masochistic, try info.el.

If your name is Leopold von Sacher-Masoch, then you might try
ange-ftp.el, dired, and vc.

Seriously, there's some desperate package-synching that needs to happen,
and anything you can do to help would be immensely appreciated.

ben

From xemacs-beta-request@cs.uiuc.edu  Thu Oct  3 04:34:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA10261 for xemacs-beta-people; Thu, 3 Oct 1996 04:34:09 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA10258 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 3 Oct 1996 04:34:06 -0500 (CDT)
Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id EAA14425 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 04:34:06 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id CAA01596 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 02:31:47 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id CAA01055 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 02:31:37 -0700
Date: Thu, 3 Oct 1996 02:31:37 -0700
Message-Id: <199610030931.CAA01055@shellx.best.com>
From: Ben Wing <wing@666.com>
To: xemacs-beta@cs.uiuc.edu, Steven L Baur <steve@miranova.com>
Subject: Re:  [Oliver Imbusch <flabes@inform-ac.com>] got no ack from XEmacs
    mailing list/Chuck Thompson

I don't ever do this but I think the short answer is that you can't
dump out a purified or quantified XEmacs.  Instead, you use a purified
or quantified temacs, and do `run-emacs-from-temacs' like this:

temacs -batch -l loadup.el run-temacs [regular XEmacs options ...]

ben

From xemacs-beta-request@cs.uiuc.edu  Thu Oct  3 10:22:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA11062 for xemacs-beta-people; Thu, 3 Oct 1996 10:22:01 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA11059 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 3 Oct 1996 10:21:43 -0500 (CDT)
Received: from ives.phx.mcd.mot.com ([144.191.22.44]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA25510 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 10:21:42 -0500 (CDT)
Received: by ives.phx.mcd.mot.com (8.6.8.2/1.34.ives)
	id IAA19147; Thu, 3 Oct 1996 08:22:27 -0700
Date: Thu, 3 Oct 1996 08:22:27 -0700
Message-Id: <199610031522.IAA19147@ives.phx.mcd.mot.com>
From: "Lynn D. Newton" <lnewton@ives.phx.mcd.mot.com>
To: Ben Wing <wing@666.com>
Cc: xemacs-beta@cs.uiuc.edu, Steven L Baur <steve@miranova.com>
Subject: Re: Key names: XEmacs vs. RMS
In-Reply-To: <199610030921.CAA27999@shellx.best.com>
References: <199610011517.KAA26110@nvwls.cc.purdue.edu>
	<199610030921.CAA27999@shellx.best.com>
Reply-To: lnewton@phx.mcd.mot.com
Comments: Hyperbole mail buttons accepted, v04.01.
X-Face:  FVNLrR&aQu[q[N3kO<A5Au*4b"pWyOi13$\H%OVNM8&P{?7;KTRLXSU)c'&Gg3{7GD.p:05
 To5$NCN#r-;vs&Qi@jhk\a@l;bMgx77!GI>4+!:X-+LgxFf'("(:8&7z+:!,24n1@j?C25:p>hno)_
 hPa5S&WgH"E-!{{N^-Cx}MiI_O'dU0


  JJN> XEmacs uses an underscore in the names of extended keys while the RMS
  JJN> version uses dashes (i.e. kp_add vs kp-add).
	
  JJN> Is there a history behind this?  Is there any reason why they should
  JJN> be named with an underscore instead of a dash?  If not, I vote for
  JJN> changing them to dashes.

  Ben> The underscores exist because that's how they're represented in the
  Ben> X keysyms.  However, there's no reason we have to be bound to those
  Ben> keysyms (and good reasons not to be, so that we have some semblance
  Ben> of device-independence); so go ahead and make the change.

Ummm. This means that everyone's bindings to those keys
will break in the next beta, and for those who don't
get the betas, in the next release, right? If so, don't
forget to feature that point prominently in the release
notes.

Lynn

From xemacs-beta-request@cs.uiuc.edu  Thu Oct  3 11:53:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id LAA11318 for xemacs-beta-people; Thu, 3 Oct 1996 11:53:03 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA11315 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 3 Oct 1996 11:53:02 -0500 (CDT)
Received: from deanna.miranova.com (steve@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA27580 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 11:53:01 -0500 (CDT)
Received: (from steve@localhost) by deanna.miranova.com (8.7.6/8.6.9) id JAA25889; Thu, 3 Oct 1996 09:56:25 -0700
Sender: steve@miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: Ben Wing <wing@666.com>
Subject: Re: man.el won't get CGI::Base
References: <199609250101.UAA25129@mordor.rsn.hp.com>      <m2u3sljn5u.fsf@deanna.miranova.com>      <yviaybhwkbwy.fsf@atreides.mindspring.com>      <m2pw38d71s.fsf@deanna.miranova.com> <u9pw38p0sf.fsf@chekov.ctd.comsat.com> <199610030927.CAA00041@shellx.best.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Ben Wing's message of Thu, 3 Oct 1996 02:27:34 -0700
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Date: 03 Oct 1996 09:56:22 -0700
Message-ID: <m2pw30c7gp.fsf@deanna.miranova.com>
Lines: 46
X-Mailer: Red Gnus v0.47/XEmacs 19.15

>>>>> "Ben" == Ben Wing <wing@666.com> writes:

Ben> If you're feeling truly masochistic, try doing the same to etags.el.
Ben> Whatever you come up with will be better than the current situation.

Noted.

Ben> If you're feeling even more masochistic, try info.el.

Noted.  I had already identified those as `problem files', thanks for
the confirmation.

Ben> If your name is Leopold von Sacher-Masoch, then you might try
Ben> ange-ftp.el, dired, and vc.

A 19th century author noted for bondage and masochism, hmm ...

Ben> Seriously, there's some desperate package-synching that needs to
Ben> happen, and anything you can do to help would be immensely
Ben> appreciated.

I've made pretty good progress on the Lisp side (AFAICT beta 3 will
have Lucid/XEmacs' first working EDT/TPU modes, for example).  I'm
also working on getting our minor changes merged into the official
versions of other packages (ispell and printing right now).

Besides the packages you mentioned, two other biggies that haven't been
addressed yet are rmail and font-lock.

I like the way font-lock works in XEmacs better, but if Simon Marshall
is maintaining the version in 19.34, and no one is maintaining the
version in 19.14, my vote goes to switching to the maintained version.

As to rmail, would it really pain people to throw out the version we
have now and replace it en toto with the rmail in 19.34?  Does anyone
still use rmail?

Unless we have a huge influx of people willing to maintain variant
code, we're going to get killed on maintenance unless we ruthlessly
throw out gratuitous changes and synch with FSF on everything that
doesn't make XEmacs a clearly better program than GNU Emacs (IMHO).
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Thu Oct  3 12:15:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA11410 for xemacs-beta-people; Thu, 3 Oct 1996 12:15:45 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA11406 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 3 Oct 1996 12:15:44 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA11078 for <xemacs-beta@xemacs.org>; Thu, 3 Oct 1996 12:15:40 -0500 (CDT)
Received: from mordor.rsn.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA111722939; Thu, 3 Oct 1996 10:15:39 -0700
Received: (from holder@localhost) by mordor.rsn.hp.com (8.7.1/8.7.1) id MAA19175; Thu, 3 Oct 1996 12:20:40 -0500 (CDT)
To: xemacs-beta@xemacs.org
Subject: XEmacs and Loads of Signals >4000 in 7 min
From: Shane Holder <holder@mordor.rsn.hp.com>
Date: 03 Oct 1996 12:20:38 -0500
Message-Id: <fawohikm0bd.fsf@mordor.rsn.hp.com>
Lines: 14
X-Mailer: Red Gnus v0.42/XEmacs 19.15


I've been using GlancePlus (an HP system monitoring package) to watch
XEmacs, and I've noticed that XEmacs seems to be very signal
intensive.  Even while I'm not doing anything, it accumulates at least
1/second, and up to 10/sec.  While typing this e-mail, the count has
more than doubled to >10000 signals received.  Is there a reason
XEmacs is doing so much with signals?  I haven't checked the source
yet, but I will.

-- 
Shane Holder                                 e-mail: holder@rsn.hp.com
Hewlett Packard                               phone:     (214)497-4182
3000 Waterview                       Never underestimate the bandwidth
Richardson, TX 75083                 of a truck moving at 70 MPH.

From xemacs-beta-request@cs.uiuc.edu  Thu Oct  3 12:52:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA11525 for xemacs-beta-people; Thu, 3 Oct 1996 12:52:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA11522 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 3 Oct 1996 12:52:24 -0500 (CDT)
Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA29342 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 12:52:23 -0500 (CDT)
Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.0/8.8.0) with ESMTP id NAA36680; Thu, 3 Oct 1996 13:52:11 -0400
Message-Id: <199610031752.NAA36680@black-ice.cc.vt.edu>
X-Mailer: exmh version 1.6.9 8/22/96
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu, Ben Wing <wing@666.com>
Subject: Re: man.el won't get CGI::Base 
In-Reply-To: Your message of "03 Oct 1996 09:56:22 PDT."
             <m2pw30c7gp.fsf@deanna.miranova.com> 
From: Valdis.Kletnieks@vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199609250101.UAA25129@mordor.rsn.hp.com> 
 <m2u3sljn5u.fsf@deanna.miranova.com> <yviaybhwkbwy.fsf@atreides.mindspring.com> <m2pw38d71s.fsf@deanna.miranova.com> <u9pw38p0sf.fsf@chekov.ctd.comsat.com> <199610030927.CAA00041@shellx.best.com>
            <m2pw30c7gp.fsf@deanna.miranova.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-2147005392P";
	micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 03 Oct 1996 13:52:09 -0400

--==_Exmh_-2147005392P
Content-Type: text/plain; charset=us-ascii

On 03 Oct 1996 09:56:22 PDT, Steven L Baur said:
> Unless we have a huge influx of people willing to maintain variant
> code, we're going to get killed on maintenance unless we ruthlessly
> throw out gratuitous changes and synch with FSF on everything that
> doesn't make XEmacs a clearly better program than GNU Emacs (IMHO).

Well.. can anybody in the know create a list of packages involved, and
an approximate guess as to how much time would be involved for each?
-- 
				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech



--==_Exmh_-2147005392P
Content-Type: application/pgp-signature

-----BEGIN PGP MESSAGE-----
Version: 2.6.2

iQCVAwUBMlP9RtQBOOoptg9JAQHBnQP9ETKZkWub2nV/CrGkvGBzsfIY565QInky
jTzi6E9a+/9mTW0wAq8ycHmnu0aP6Fi4/MdXGdo3oIf3/fOV0tVhcZWnI2Oau1vR
VOSmbPDxnrWhveJ8UaMQBKM9FRrhSUUH3i+nzh3SRV1UAkiYfkZ0Nfc8s+fRN/np
8SvZDw+NHWA=
=MWGe
-----END PGP MESSAGE-----

--==_Exmh_-2147005392P--

From xemacs-beta-request@cs.uiuc.edu  Thu Oct  3 13:41:01 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA11687 for xemacs-beta-people; Thu, 3 Oct 1996 13:41:01 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA11684 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 3 Oct 1996 13:41:00 -0500 (CDT)
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA00127 for <xemacs-beta@cs.uiuc.edu>; Thu, 3 Oct 1996 13:41:00 -0500 (CDT)
Received: by martigny.ai.mit.edu
	(1.40.112.4/16.2) id AA275138051; Thu, 3 Oct 1996 14:40:51 -0400
Date: Thu, 3 Oct 1996 14:40:51 -0400
Message-Id: <199610031840.AA275138051@martigny.ai.mit.edu>
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu, wing@666.com
In-Reply-To: <m2pw30c7gp.fsf@deanna.miranova.com> (message from Steven L Baur
	on 03 Oct 1996 09:56:22 -0700)
Subject: etags, syncing with FSF [was: man.el won't get CGI::Base]

  From: Steven L Baur <steve@miranova.com>
  Date: 03 Oct 1996 09:56:22 -0700

  >>>>> "Ben" == Ben Wing <wing@666.com> writes:

  Ben> If you're feeling truly masochistic, try doing the same to etags.el.
  Ben> Whatever you come up with will be better than the current situation.

  Noted.

The current FSF etags.el is really warped, and lacks some important
features, e.g. tag-table-alist.  If I can find some spare time I'd
like to get my auto-tags package running in both Emacs & XEmacs
and propose that as a unified solution.

In any case, if anyone decides to work on this please contact me
since I may be able to help out etc.

-Bill

From xemacs-beta-request@cs.uiuc.edu  Fri Oct  4 05:42:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id FAA17194 for xemacs-beta-people; Fri, 4 Oct 1996 05:42:46 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id FAA17191 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 4 Oct 1996 05:42:44 -0500 (CDT)
Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id FAA12382 for <xemacs-beta@xemacs.org>; Fri, 4 Oct 1996 05:42:40 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id DAA01653 for <xemacs-beta@xemacs.org>; Fri, 4 Oct 1996 03:27:31 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id DAA08079 for <xemacs-beta@xemacs.org>; Fri, 4 Oct 1996 03:27:21 -0700
Date: Fri, 4 Oct 1996 03:27:21 -0700
Message-Id: <199610041027.DAA08079@shellx.best.com>
From: Ben Wing <wing@666.com>
To: xemacs-beta@xemacs.org, Shane Holder <holder@mordor.rsn.hp.com>
Subject: Re:  XEmacs and Loads of Signals >4000 in 7 min

XEmacs receives a timer signal every 0.25 seocnd if SIGIO/SIGPOLL or
SIGCHLD is broken.  Lots of systems have broken SIGIO; yours is probably
among them.  This is necessary in order for C-g to work reliably.
It's possible to turn the timer off when XEmacs is idle, but probably
not worth it.

4000 in 7 minutes is a bit high though; try truss/trace/strace to see
what's going on.

ben

From xemacs-beta-request@cs.uiuc.edu  Fri Oct  4 15:47:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id PAA18595 for xemacs-beta-people; Fri, 4 Oct 1996 15:47:11 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA18592 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 4 Oct 1996 15:47:10 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id PAA13106 for <xemacs-beta@xemacs.org>; Fri, 4 Oct 1996 15:47:06 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa20519;
          4 Oct 96 16:47 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id QAA26768; Fri, 4 Oct 1996 16:47:02 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id QAA18259; Fri, 4 Oct 1996 16:47:01 -0400
Date: Fri, 4 Oct 1996 16:47:01 -0400
Message-Id: <199610042047.QAA18259@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
To: nuspl@purdue.edu
Cc: xemacs-beta@xemacs.org
Subject: Re: Key names: XEmacs vs. RMS
References: <199610011517.KAA26110@nvwls.cc.purdue.edu>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Ghost echoes
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "JJN" == Joseph J Nuspl <nuspl@nvwls.cc.purdue.edu> writes:

    JJN> XEmacs uses an underscore in the names of extended keys while
    JJN> the RMS version uses dashes (i.e. kp_add vs kp-add).

    JJN> Is there a history behind this?  Is there any reason why they
    JJN> should be named with an underscore instead of a dash?  If
    JJN> not, I vote for changing them to dashes.

Do you intend to disallow underscored keysyms?  I'd say, allow them
for the 19.15 release, but issue warnings and give people one major
release cycle to change their code.

-Barry

From xemacs-beta-request@cs.uiuc.edu  Fri Oct  4 16:48:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA18775 for xemacs-beta-people; Fri, 4 Oct 1996 16:48:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA18769 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 4 Oct 1996 16:48:22 -0500 (CDT)
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA13158 for <xemacs-beta@xemacs.org>; Fri, 4 Oct 1996 16:48:18 -0500 (CDT)
Received: by martigny.ai.mit.edu
	(1.40.112.4/16.2) id AA257335683; Fri, 4 Oct 1996 17:48:03 -0400
Date: Fri, 4 Oct 1996 17:48:03 -0400
Message-Id: <199610042148.AA257335683@martigny.ai.mit.edu>
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
To: bwarsaw@cnri.reston.va.us
Cc: nuspl@purdue.edu, xemacs-beta@xemacs.org
In-Reply-To: <199610042047.QAA18259@anthem.CNRI.Reston.Va.US>
	(bwarsaw@cnri.reston.va.us)
Subject: Re: Key names: XEmacs vs. RMS

  Date: Fri, 4 Oct 1996 16:47:01 -0400
  From: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>

  >>>>> "JJN" == Joseph J Nuspl <nuspl@nvwls.cc.purdue.edu> writes:

      JJN> XEmacs uses an underscore in the names of extended keys while
      JJN> the RMS version uses dashes (i.e. kp_add vs kp-add).

      JJN> Is there a history behind this?  Is there any reason why they
      JJN> should be named with an underscore instead of a dash?  If
      JJN> not, I vote for changing them to dashes.

  Do you intend to disallow underscored keysyms?  I'd say, allow them
  for the 19.15 release, but issue warnings and give people one major
  release cycle to change their code.

A general way to do this is to extend the byte-compiler to allow
global symbol-macros (which should be trivial to do). E.g.

(defsym kp_add 'kp-add)		; alias for backward compatibility 

Recall that symbol-macros allow you to associate a macro definition
with any symbol reference; the macroexpansion phase of the compiler
simply replaces such a symbol with the result of evaluating the 
macro definition of the symbol.  E.g. the above is analogous to

(defmacro kp_foo () 'kp-foo)

except that the former symbol-macro is invoked simply as  kp_foo
versus the latter functional macro which is invoked as   (kp_foo).

I.e. a symbol-macro is essentially a nullary macro, but you don't
have to surround the macro-call in paren's. This is the same 
convention used in algebra, where constant operators are written 
simply as symbols instead of as nullary function calls. Thus in
a ring one writes 0 for the additive identity, not (0) or 0(),
and in Lisp one denotes the empty list via nil, not (nil), etc.

-Bill

From xemacs-beta-request@cs.uiuc.edu  Fri Oct  4 17:28:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id RAA18906 for xemacs-beta-people; Fri, 4 Oct 1996 17:28:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA18903 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 4 Oct 1996 17:28:36 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id RAA13203 for <xemacs-beta@xemacs.org>; Fri, 4 Oct 1996 17:28:33 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id PAA02837; Fri, 4 Oct 1996 15:28:04 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id PAA05824; Fri, 4 Oct 1996 15:27:53 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA14626; Fri, 4 Oct 1996 14:32:21 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA14678; Fri, 4 Oct 1996 14:32:21 -0700
Date: Fri, 4 Oct 1996 14:32:21 -0700
Message-Id: <199610042132.OAA14678@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: debug-on-foo variables
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII

Here is a message forward that may be of interest:

From: friedman@splode.com (Noah Friedman)
To: cvieri@ai.mit.edu
Cc: omv@ai.mit.edu, system-hackers@ai.mit.edu
Subject: *Backtrace* buffer under xemacs
Date: Fri, 4 Oct 1996 15:49:00 -0500

>There are a series of debug-on-foo variables (debug-on-error,
>debug-on-next-call, debug-on-quit, debug-on-signal).  The one you're
>interested in is debug-on-error.  Just add
>(setq debug-on-error nil)
>near the end of your .emacs.

You can set debug-on-error to be a list of conditions for which you want to
be thrown in into the debugger.  The intention was this would modify the
behavior of the default exception handler for conditions that weren't
explicitly handled by another condition-case.

In versions of Lemacs and XEmacs prior to (and possible including) 19.13,
debug-on-error had semantics such that setting it overrode all exception
handlers; it wasn't just a feature of the top-level handler.  I whinged
about this change because it broke my horribly complicated environment, and
convinced the XEmacs folks to use a differently-named variable
(debug-on-signal, though that wasn't my suggested name) for the new
behavior, changing debug-on-error back to the old behavior that has always
been exhibited in the FSF branch of Emacs 19.  Anyway, you might want to
check to see which of the two are being set, and which version of xemacs
you're running.

(In the forthcoming emacs 19.35, the variable `debug-force' will behave
like `debug-on-signal' in XEmacs.  Hooray for gratuitous incompatibility in
nomenclature!)

From xemacs-beta-request@cs.uiuc.edu  Fri Oct  4 17:50:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id RAA19004 for xemacs-beta-people; Fri, 4 Oct 1996 17:50:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA19001 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 4 Oct 1996 17:50:39 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id RAA13241 for <xemacs-beta@xemacs.org>; Fri, 4 Oct 1996 17:50:35 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa23419;
          4 Oct 96 18:47 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id SAA29214; Fri, 4 Oct 1996 18:47:23 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id SAA18522; Fri, 4 Oct 1996 18:47:23 -0400
Date: Fri, 4 Oct 1996 18:47:23 -0400
Message-Id: <199610042247.SAA18522@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Cc: rms@prep.ai.mit.edu
Subject: Re: debug-on-foo variables
References: <199610042132.OAA14678@xemacs.eng.sun.com>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Fill every beat with something
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "MB" == Martin Buchholz <mrb@eng.sun.com> writes:

    MB> (In the forthcoming emacs 19.35, the variable `debug-force'
    MB> will behave like `debug-on-signal' in XEmacs.  Hooray for
    MB> gratuitous incompatibility in nomenclature!)

This was exactly the point of my `Constructive Proposal' message a
while back.  I had hoped that such incompatibilities could be
avoided.  <sigh>

From xemacs-beta-request@cs.uiuc.edu  Sat Oct  5 01:59:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id BAA20051 for xemacs-beta-people; Sat, 5 Oct 1996 01:59:55 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id BAA20048 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 5 Oct 1996 01:59:54 -0500 (CDT)
Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id BAA13745 for <xemacs-beta@xemacs.org>; Sat, 5 Oct 1996 01:59:52 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id XAA00407 for <xemacs-beta@xemacs.org>; Fri, 4 Oct 1996 23:44:24 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id XAA12055 for <xemacs-beta@xemacs.org>; Fri, 4 Oct 1996 23:44:16 -0700
Date: Fri, 4 Oct 1996 23:44:16 -0700
Message-Id: <199610050644.XAA12055@shellx.best.com>
From: Ben Wing <wing@666.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>,
        Martin Buchholz
    <mrb@eng.sun.com>
Subject: Re:  debug-on-foo variables
Cc: rms@gnu.ai.mit.edu

Why the hell can't RMS *ever* try to check whether a feature exists in XEmacs
before implementing it in an incompatible way in FSF Emacs?

>From: friedman@splode.com (Noah Friedman)
>To: cvieri@ai.mit.edu
>Cc: omv@ai.mit.edu, system-hackers@ai.mit.edu
>Subject: *Backtrace* buffer under xemacs
>Date: Fri, 4 Oct 1996 15:49:00 -0500
>
>>There are a series of debug-on-foo variables (debug-on-error,
>>debug-on-next-call, debug-on-quit, debug-on-signal).  The one you're
>>interested in is debug-on-error.  Just add
>>(setq debug-on-error nil)
>>near the end of your .emacs.
>
>You can set debug-on-error to be a list of conditions for which you want to
>be thrown in into the debugger.  The intention was this would modify the
>behavior of the default exception handler for conditions that weren't
>explicitly handled by another condition-case.
>
>In versions of Lemacs and XEmacs prior to (and possible including) 19.13,
>debug-on-error had semantics such that setting it overrode all exception
>handlers; it wasn't just a feature of the top-level handler.  I whinged
>about this change because it broke my horribly complicated environment, and
>convinced the XEmacs folks to use a differently-named variable
>(debug-on-signal, though that wasn't my suggested name) for the new
>behavior, changing debug-on-error back to the old behavior that has always
>been exhibited in the FSF branch of Emacs 19.  Anyway, you might want to
>check to see which of the two are being set, and which version of xemacs
>you're running.
>
>(In the forthcoming emacs 19.35, the variable `debug-force' will behave
>like `debug-on-signal' in XEmacs.  Hooray for gratuitous incompatibility in
>nomenclature!)
>

From xemacs-beta-request@cs.uiuc.edu  Sun Oct  6 14:29:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA00357 for xemacs-beta-people; Sun, 6 Oct 1996 14:29:39 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA00354 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 6 Oct 1996 14:29:38 -0500 (CDT)
Received: from sudish.users.MindSpring.COM (qmailr@user-168-121-167-78.dialup.mindspring.com [168.121.167.78]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id OAA16566 for <xemacs-beta@cs.uiuc.edu>; Sun, 6 Oct 1996 14:29:37 -0500 (CDT)
Received: (qmail-queue invoked by uid 501); 6 Oct 1996 19:30:25 -0000
Sender: sj@atreides2.erehwon.org
To: kifer@cs.sunysb.edu
Cc: xemacs-beta@cs.uiuc.edu
Subject: vip-want-ctl-h-help clobbers the binding of [backspace] [Patch]
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sudish@mindspring.com>
Date: 06 Oct 1996 15:30:23 -0400
Message-ID: <m24tk76gc0.fsf@atreides2.erehwon.org>
Lines: 41

When vip-want-ctl-h-help is bound to 't, viper uses the form "\C-h" to
access the help keymap.  This clobbers the binding of [backspace] in
XEmacs.  The patch that follows fixes stuff for me.  This might be
XEmacs-specific, I do not know.  I'm cc'ing the xemacs-beta list.

Tx, 
-Sudish

Emacs  : XEmacs 19.14 [Lucid] (i586-unknown-linux2.0.8) of Tue Aug  6 1996 on atreides
Package: Viper version is 2.90 of June 19, 1996

[ snipped ]

--- viper.el~	Sun Oct  6 15:27:59 1996
+++ viper.el	Sun Oct  6 15:27:59 1996
@@ -1150,18 +1150,18 @@
 		   
 	 (if vip-want-ctl-h-help
 	     (progn 
-	       (define-key vip-insert-basic-map "C-h" 'help-command)
-	       (define-key vip-replace-map "C-h" 'help-command))
+	       (define-key vip-insert-basic-map [(control h)] 'help-command)
+	       (define-key vip-replace-map [(control h)] 'help-command))
 	   (define-key vip-insert-basic-map 
-	     "\C-h" 'vip-del-backward-char-in-insert)
+	     [(control h)] 'vip-del-backward-char-in-insert)
 	   (define-key vip-replace-map
-	     "\C-h" 'vip-del-backward-char-in-replace)))
+	     [(control h)] 'vip-del-backward-char-in-replace)))
 		     
 	(t
 	 (setq vip-vi-diehard-minor-mode (not vip-want-emacs-keys-in-vi))
 	 (if vip-want-ctl-h-help
-	     (define-key vip-vi-basic-map "\C-h" 'help-command)
-	   (define-key vip-vi-basic-map "\C-h" 'vip-backward-char)))
+	     (define-key vip-vi-basic-map [(control h)] 'help-command)
+	   (define-key vip-vi-basic-map [(control h)] 'vip-backward-char)))
 	))
 	     
     


From xemacs-beta-request@cs.uiuc.edu  Sun Oct  6 17:25:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id RAA00636 for xemacs-beta-people; Sun, 6 Oct 1996 17:25:44 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA00633 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 6 Oct 1996 17:25:43 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id RAA18639 for <xemacs-beta@cs.uiuc.edu>; Sun, 6 Oct 1996 17:25:42 -0500 (CDT)
Received: from sbkifer.cs.sunysb.edu (sbkifer.cs.sunysb.edu [130.245.1.35]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id SAA16137; Sun, 6 Oct 1996 18:31:50 -0400
Message-Id: <199610062231.SAA16137@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: Sudish Joseph <sudish@mindspring.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: vip-want-ctl-h-help clobbers the binding of [backspace] [Patch] 
In-reply-to: "Sudish Joseph" of 06 Oct 1996 15:30:23 EDT
             <m24tk76gc0.fsf@atreides2.erehwon.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 06 Oct 1996 18:23:36 -0400
Sender: kifer@cs.sunysb.edu

> When vip-want-ctl-h-help is bound to 't, viper uses the form "\C-h" to
> access the help keymap.  This clobbers the binding of [backspace] in
> XEmacs.  The patch that follows fixes stuff for me.  This might be
> XEmacs-specific, I do not know.  I'm cc'ing the xemacs-beta list.
> 

I don't understand why XEmacs translates [backspace] into C-h.
FSF Emacs doesn't do this (and the aforesaid problem doesn't arise).

Is there a good reason for the decision to convert backspace into C-h?
Or is it a bug?



	--michael  

From xemacs-beta-request@cs.uiuc.edu  Sun Oct  6 20:39:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA01014 for xemacs-beta-people; Sun, 6 Oct 1996 20:39:21 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA01011 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 6 Oct 1996 20:39:19 -0500 (CDT)
Received: from ethanol.gnu.ai.mit.edu (rms@ethanol.gnu.ai.mit.edu [128.52.46.64]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA15658 for <xemacs-beta@xemacs.org>; Sun, 6 Oct 1996 20:39:15 -0500 (CDT)
Received: by ethanol.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id VAA22710; Sun, 6 Oct 1996 21:40:10 -0400
Date: Sun, 6 Oct 1996 21:40:10 -0400
Message-Id: <199610070140.VAA22710@ethanol.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: bwarsaw@cnri.reston.va.us
CC: mrb@eng.sun.com, xemacs-beta@xemacs.org
In-reply-to: <199610042247.SAA18522@anthem.CNRI.Reston.Va.US>
	(bwarsaw@anthem.cnri.reston.va.us)
Subject: Re: debug-on-foo variables

    This was exactly the point of my `Constructive Proposal' message a
    while back.  I had hoped that such incompatibilities could be
    avoided.  <sigh>

All else being equal, I'd rather make Emacs compatible with XEmacs
than not.  Sometimes I've asked XEmacs developers to show me their
interface spec, so I could make a new feature compatible.  But I can
only do that if I know XEmacs has a feature like the one I'm adding.
I'm not generally familiar with XEmacs and I don't have extra time to
spend keeping track of it.

If someone working with me on Emacs knew at the existing features of
XEmacs, perhaps he could help point out opportunities for
compatibility.


From xemacs-beta-request@cs.uiuc.edu  Sun Oct  6 22:22:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id WAA01191 for xemacs-beta-people; Sun, 6 Oct 1996 22:22:25 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id WAA01188 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 6 Oct 1996 22:22:23 -0500 (CDT)
Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id WAA15719 for <xemacs-beta@xemacs.org>; Sun, 6 Oct 1996 22:21:57 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id UAA20424 for <xemacs-beta@xemacs.org>; Sun, 6 Oct 1996 20:21:48 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id UAA29409 for <xemacs-beta@xemacs.org>; Sun, 6 Oct 1996 20:21:37 -0700
Date: Sun, 6 Oct 1996 20:21:37 -0700
Message-Id: <199610070321.UAA29409@shellx.best.com>
From: Ben Wing <wing@666.com>
To: bwarsaw@cnri.reston.va.us, Richard Stallman <rms@gnu.ai.mit.edu>
Subject: Re: debug-on-foo variables
Cc: xemacs-beta@xemacs.org, mrb@eng.sun.com

>All else being equal, I'd rather make Emacs compatible with XEmacs
>than not.  Sometimes I've asked XEmacs developers to show me their
>interface spec, so I could make a new feature compatible.  But I can
>only do that if I know XEmacs has a feature like the one I'm adding.
>I'm not generally familiar with XEmacs and I don't have extra time to
>spend keeping track of it.
>
>If someone working with me on Emacs knew at the existing features of
>XEmacs, perhaps he could help point out opportunities for
>compatibility.

Your arguments are disingenuous because in reality you make almost no
effort to keep things compatible, while we make quite a lot of effort.
If you're not going to make a minimal effort to determine whether
a feature is already in XEmacs, how are you going to possibly
know whether it exists?  We're not mind-readers and can't magically
figure out when you're going to add something, so as to warn you
ahead of time.

Why don't you do this:

1) change `debug-force' to `debug-on-signal', as it exists in XEmacs.
2) you keep a detailed change log of things you're adding, so send
   it to xemacs-beta@xemacs.org every two weeks (or right before
   you're preparing a release), so we can tell you if a feature
   is being incompatibly duplicated.

ben

From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 04:18:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA05353 for xemacs-beta-people; Mon, 7 Oct 1996 04:18:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA05350 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 04:18:01 -0500 (CDT)
Received: from ethanol.gnu.ai.mit.edu (rms@ethanol.gnu.ai.mit.edu [128.52.46.64]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id EAA16080 for <xemacs-beta@xemacs.org>; Mon, 7 Oct 1996 04:17:59 -0500 (CDT)
Received: by ethanol.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id FAA23904; Mon, 7 Oct 1996 05:18:28 -0400
Date: Mon, 7 Oct 1996 05:18:28 -0400
Message-Id: <199610070918.FAA23904@ethanol.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: wing@666.com
CC: bwarsaw@cnri.reston.va.us, xemacs-beta@xemacs.org, mrb@eng.sun.com
In-reply-to: <199610070321.UAA29405@shellx.best.com> (message from Ben Wing on
	Sun, 6 Oct 1996 20:21:37 -0700)
Subject: Re: debug-on-foo variables

    Your arguments are disingenuous because in reality you make almost no
    effort to keep things compatible, while we make quite a lot of effort.

You have other reasons to keep track of what is changed in Emacs--for
example, you can copy the code from Emacs.  Also I think all of you
have more time available to put into XEmacs than I have for Emacs.  I
cannot do a number of things that I consider very important.

    1) change `debug-force' to `debug-on-signal', as it exists in XEmacs.

I think debug-force is a better name, but the name isn't terribly
important, so I'll change it.

    2) you keep a detailed change log of things you're adding, so send
       it to xemacs-beta@xemacs.org every two weeks (or right before
       you're preparing a release), so we can tell you if a feature
       is being incompatibly duplicated.

I can't promise, but I might be able to send you the NEWS file shortly
before a release.


From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 08:06:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA05712 for xemacs-beta-people; Mon, 7 Oct 1996 08:06:57 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA05709 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 08:06:56 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA16330 for <XEmacs-Beta@XEmacs.org>; Mon, 7 Oct 1996 08:06:54 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.7.5/8.7.3) with ESMTP id IAA02901 for <XEmacs-Beta@XEmacs.org>; Mon, 7 Oct 1996 08:03:43 -0500
Message-Id: <199610071303.IAA02901@nvwls.cc.purdue.edu>
To: XEmacs-Beta@xemacs.org
Subject: Re: debug-on-foo variables 
In-reply-to: Your message of "Sun, 06 Oct 1996 21:40:10 -0400."
             <199610070140.VAA22710@ethanol.gnu.ai.mit.edu> 
Date: Mon, 07 Oct 1996 08:03:39 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


>>>>> "RMS" == Richard Stallman <rms@gnu.ai.mit.edu> writes:

    RMS> All else being equal, I'd rather make Emacs compatible with
    RMS> XEmacs than not.  Sometimes I've asked XEmacs developers to
    RMS> show me their interface spec, so I could make a new feature
    RMS> compatible.  But I can only do that if I know XEmacs has a
    RMS> feature like the one I'm adding.  I'm not generally familiar
    RMS> with XEmacs and I don't have extra time to spend keeping
    RMS> track of it.

    RMS> If someone working with me on Emacs knew at the existing
    RMS> features of XEmacs, perhaps he could help point out
    RMS> opportunities for compatibility.

This is the first time that I have heard Stallman be reasonable.  Has
someone compromised his account?  No seriously.

Maybe now I can get my changes into texinfo for better groff support.

Joe

From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 08:51:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA05842 for xemacs-beta-people; Mon, 7 Oct 1996 08:51:24 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA05839 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 08:51:23 -0500 (CDT)
Received: from newman.aventail.com (root@newman.aventail.com [38.225.141.10]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id IAA16392 for <xemacs-beta@xemacs.org>; Mon, 7 Oct 1996 08:51:20 -0500 (CDT)
Received: from wmperry.oz.net.aventail.com (root@newman [192.168.1.1]) by newman.aventail.com (8.6.12/8.6.9) with SMTP id GAA08583; Mon, 7 Oct 1996 06:49:07 -0700
Date: Mon, 7 Oct 1996 06:49:07 -0700
Message-Id: <199610071349.GAA08583@newman.aventail.com>
From: William Perry <wmperry@aventail.com>
To: Richard Stallman <rms@gnu.ai.mit.edu>
Cc: wing@666.com, bwarsaw@cnri.reston.va.us, xemacs-beta@xemacs.org,
        mrb@eng.sun.com
Subject: Re: debug-on-foo variables
In-Reply-To: <199610070918.FAA23904@ethanol.gnu.ai.mit.edu>
References: <199610070321.UAA29405@shellx.best.com>
	<199610070918.FAA23904@ethanol.gnu.ai.mit.edu>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Richard Stallman writes:
>    Your arguments are disingenuous because in reality you make almost no
>    effort to keep things compatible, while we make quite a lot of effort.
>
>You have other reasons to keep track of what is changed in Emacs--for
>example, you can copy the code from Emacs.  Also I think all of you have
>more time available to put into XEmacs than I have for Emacs.  I cannot do
>a number of things that I consider very important.

  I'm not sure I would agree with the assertion we have more time or not.
:)  I'm having enough problems finding time to sleep.

  I think compatibility should be one of the highest goals of the two
Emacsen right now.  Look what's happening in the web, with netscape and
microsoft making ridiculous and incompatible extensions to things that have
been implemented before.  I don't think we are anywhere near being as bad
as they are, but the danger is there.

  I've recently been trying to get Emacs-W3 to work under Mule 2.4, but
still maintain compatibility with Mule 2.3, and XEmacs 20.0 with Mule
support.  Its a gigantic pain - *noconv* vs. 'noconv vs. 'no-conversion.
*groan*

[...]
>    2) you keep a detailed change log of things you're adding, so send
>       it to xemacs-beta@xemacs.org every two weeks (or right before
>       you're preparing a release), so we can tell you if a feature
>       is being incompatibly duplicated.
>
>I can't promise, but I might be able to send you the NEWS file shortly
>before a release.

 Since I am a beta tester of both emacsen, I will try to run through the
ChangeLog carefully as soon as the first publicly available Emacs 19.35
beta is up, and try to distill a list of things that look equivalent.

 Is anyone else on the xemacs-beta list doing double duty on the Emacs beta
testers list as well?  Perhaps we could double up on the work to make sure
we don't miss anything.

-Bill P.


From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 09:58:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id JAA06135 for xemacs-beta-people; Mon, 7 Oct 1996 09:58:57 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA06132 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 09:58:56 -0500 (CDT)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id JAA10243 for <xemacs-beta@cs.uiuc.edu>; Mon, 7 Oct 1996 09:58:55 -0500 (CDT)
Received: (qmail 24149 invoked from smtpd); 7 Oct 1996 15:02:00 -0000
Received: from geordi.miranova.com (qmailr@206.190.83.3)
  by deanna.miranova.com with SMTP; 7 Oct 1996 15:02:00 -0000
Received: (qmail 15871 invoked from smtpd); 7 Oct 1996 15:03:43 -0000
Received: from deanna.miranova.com (steve@206.190.83.1)
  by geordi.miranova.com with SMTP; 7 Oct 1996 15:03:43 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Cc: Richard Stallman <rms@gnu.ai.mit.edu>, Mark Hood <hood@eng.sun.com>
Subject: man-xref.el (was Re: debug-on-foo variables)
References: <199610070918.FAA23904@ethanol.gnu.ai.mit.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Richard Stallman's message of Mon, 7 Oct 1996 05:18:28 -0400
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Date: 07 Oct 1996 08:01:58 -0700
Message-ID: <m2ybhikec9.fsf@deanna.miranova.com>
Lines: 24
X-Mailer: Red Gnus v0.47/XEmacs 19.15

I just saw an announcement for man-xref.el which adds an XEmacs
feature to man.el.  May I request that the portable code in Gnus at
least be consulted prior to its introduction?

We have already planned on synching with 19.34 man.el, and were going
to add back in our original code for this.

> From: Mark Hood <hood@eng.sun.com>
> Newsgroups: comp.emacs,gnu.emacs.sources
> Subject: man-xref.el v1.15 for Emacs 19.34
> Date: 03 Oct 1996 18:59:40 -0700
 ...
> It has been suggested that I submit this code to rms as a clean
> patch to man.el for a future release of Emacs.  If it is accepted, I
> will post a notice here so that users of man-xref.el can remove this
> code from their initialization files.

> -- Mark Hood
 ...
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.


From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 10:11:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA06192 for xemacs-beta-people; Mon, 7 Oct 1996 10:11:10 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA06189 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 10:11:08 -0500 (CDT)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA10770 for <xemacs-beta@cs.uiuc.edu>; Mon, 7 Oct 1996 10:11:07 -0500 (CDT)
Received: (qmail 24209 invoked from smtpd); 7 Oct 1996 15:14:13 -0000
Received: from geordi.miranova.com (qmailr@206.190.83.3)
  by deanna.miranova.com with SMTP; 7 Oct 1996 15:14:13 -0000
Received: (qmail 15897 invoked from smtpd); 7 Oct 1996 15:15:57 -0000
Received: from deanna.miranova.com (steve@206.190.83.1)
  by geordi.miranova.com with SMTP; 7 Oct 1996 15:15:57 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: XEmacs 20.0-b29 - Linux 2.0.21/libc 5.4.7
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Date: 07 Oct 1996 08:14:11 -0700
Message-ID: <m2vicmkdrw.fsf@deanna.miranova.com>
Lines: 57
X-Mailer: Red Gnus v0.47/XEmacs 19.15

[Also with ld.so 1.8.2, binutils 2.7.0.3]

Patched up from 20.0-b28 and built with `make beta'.

The build produced no error messages until the very end:

Loading psgml...
While compiling toplevel forms in file /i/xemacs-20.0-b28/lisp/psgml/psgml-debug.el:
  !! error (("invalid lazy-loaded byte code" symbol))
Compiling /i/xemacs-20.0-b28/lisp/psgml/psgml-lfix.el...
Wrote /i/xemacs-20.0-b28/lisp/psgml/psgml-lfix.elc
Compiling /i/xemacs-20.0-b28/lisp/psgml/psgml-parse.el...
Loading psgml...
While compiling toplevel forms in file /i/xemacs-20.0-b28/lisp/psgml/psgml-parse.el:
  !! error (("invalid lazy-loaded byte code" symbol))
Compiling /i/xemacs-20.0-b28/lisp/psgml/psgml.el...
While compiling toplevel forms in file /i/xemacs-20.0-b28/lisp/psgml/psgml.el:
  !! error (("Invalid data in documentation file -- ^A followed by weird code" 13))
Done (Total of 5 files compiled)

These files bytecompiled fine when done manually.  psgml.el should
probably not be the last one bytecompiled, but the Makefile that
originally came with that package has been removed.

Original output from configure:
Configured for `i486-unknown-linux2.0.18'.

  Where should the build process find the source code?    /i/xemacs-20.0-b28
  What installation prefix should install use?            /usr/local
  What operating system and machine description files should XEmacs use?
        `s/linux.h' and `m/intel386.h'
  What compiler should XEmacs be built with?              gcc -g -O4
  Should XEmacs use the GNU version of malloc?            yes
  Should XEmacs use the relocating allocator for buffers? yes
  What window system should XEmacs use?                   x11
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib
  Compiling in support for XAUTH.
  Compiling in support for XPM.
  Compiling in support for X-Face headers.
  Compiling in support for GIF image conversion.
  Compiling in support for JPEG image conversion.
  Compiling in support for PNG image conversion.
  Compiling in native sound support.
  Compiling in support for Berkeley DB.
  Compiling in support for GNU DBM.
  Compiling in Mule (multi-lingual) support.
  Using the Lucid menubar.
  Using the Lucid scrollbar.
  Using the Athena dialog boxes.
  Compiling in extra code for debugging.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.


From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 12:18:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA06569 for xemacs-beta-people; Mon, 7 Oct 1996 12:18:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA06566 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 12:18:53 -0500 (CDT)
Received: from icemark.thenet.ch (root@[193.135.252.47]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id MAA16857 for <xemacs-beta@xemacs.org>; Mon, 7 Oct 1996 12:18:48 -0500 (CDT)
Received: from localhost by icemark.thenet.ch
	 with smtp id m0vAJA0-0003ekC
	(Debian /\oo/\ Smail3.1.29.1 #29.37); Mon, 7 Oct 96 19:08 MET DST
Date: Mon, 7 Oct 1996 19:08:08 +0200 (MET DST)
From: Benedikt Eric Heinen <beh@icemark.thenet.ch>
Reply-To: Benedikt Eric Heinen <beh@icemark.thenet.ch>
To: Richard Stallman <rms@gnu.ai.mit.edu>
cc: wing@666.com, bwarsaw@cnri.reston.va.us, xemacs-beta@xemacs.org,
        mrb@eng.sun.com
Subject: Re: debug-on-foo variables
In-Reply-To: <199610070918.FAA23904@ethanol.gnu.ai.mit.edu>
Message-ID: <Pine.LNX.3.95.961007183250.7862B-100000@icemark.thenet.ch>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

>     Your arguments are disingenuous because in reality you make almost no
>     effort to keep things compatible, while we make quite a lot of effort.
> You have other reasons to keep track of what is changed in Emacs--for
> example, you can copy the code from Emacs.  Also I think all of you
> have more time available to put into XEmacs than I have for Emacs.  I
> cannot do a number of things that I consider very important.
Hmm, am I alone with that thought or is this discussion tending to become
more and more childish? ;-(

As I wrote before, IMHO the competition here is good for all users of each
of the two Emacsens. BUT, arguing that you don't care about rebuilding
features from XEmacs code to be incompatible with XEmacs, because
otherwise everyone could copy it too easily IS a childish thing.

I mean, there's two reasons against this:

  a) Free Software IS about making people able to change/copy source 
     nearly just like they want.

  b) By making code incompatible you do not only annoy the XEmacs
     developers, but also those people that contributed to XEmacs, writing
     additinal elisp code for it, which they now need to rewrite to work
     with the FSF Emacs. Ultimately that could probably avert people from
     continuing work on their elisp packages because they need to write 
     parts of it twice - OR you'll force some of them to decide which 
     Emacs to support and at the moment I'd personally doubt that the FSF
     Emacs will profit from such a division as more and more people (at 
     least of those that I know) switch over to XEmacs [including some
     vi purists of which I never thought I'd be possible to make them
     change to something new].

I mean, bearing in mind what you sort-of imply, how come the GNU ls uses
-l for long format? I mean, it'd give commercial Unix vendors the
possibility to copy part of your code... [OK, this example is pure
exaggeration, but I think in the way it exaggerates, it should show the
point].


> I can't promise, but I might be able to send you the NEWS file shortly
> before a release.
That'd be a start for something good. Is the same happening towards GNU
(FSF) Emacs? Is someone supplying Richard with more detailed information
about the changes done in XEmacs?

Please, Richard, when you are going to rewrite code for FSF Emacs that is
already in XEmacs, please try to make a 'drop-in' replacement for that
piece of code. I mean the XEmacs people also seem interested in keeping
most of XEmacs compatible with FSF Emacs.

just my $0.02

Benedikt

signoff

---
 Benedikt Eric Heinen  -  Muehlemattstrasse 53  -  CH3007 Bern  -   SWITZERLAND
 email: beh@icemark.thenet.ch				 phone: ++41.31.3714460


RIOT, n.  A popular entertainment given to the military by innocent bystanders.

				     Ambrose Bierce  ``The Devil's Dictionary''




From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 17:48:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id RAA07488 for xemacs-beta-people; Mon, 7 Oct 1996 17:48:36 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA07485 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 17:48:35 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id RAA28756 for <xemacs-beta@cs.uiuc.edu>; Mon, 7 Oct 1996 17:48:34 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id PAA20930; Mon, 7 Oct 1996 15:48:02 -0700
Received: from jadeite.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id PAA15523; Mon, 7 Oct 1996 15:47:51 -0700
Received: from klia.eng.sun.com by jadeite.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA15210; Mon, 7 Oct 1996 15:47:15 -0700
Received: by klia.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA11462; Mon, 7 Oct 1996 15:46:43 -0700
Date: Mon, 7 Oct 1996 15:46:43 -0700
Message-Id: <199610072246.PAA11462@klia.eng.sun.com>
From: Mark Hood <hood@eng.sun.com>
To: steve@miranova.com
CC: xemacs-beta@cs.uiuc.edu, rms@gnu.ai.mit.edu
In-reply-to: <m2ybhikec9.fsf@deanna.miranova.com> (message from Steven L Baur
	on 07 Oct 1996 08:01:58 -0700)
Subject: Re: man-xref.el (was Re: debug-on-foo variables)
Reply-to: hood@eng.sun.com

> Sender: steve@deanna.miranova.com
> Cc: Richard Stallman <rms@gnu.ai.mit.edu>, Mark Hood <hood@Eng>
> References: <199610070918.FAA23904@ethanol.gnu.ai.mit.edu>
> I just saw an announcement for man-xref.el which adds an XEmacs
> feature to man.el.  May I request that the portable code in Gnus at
> least be consulted prior to its introduction?
> 
> We have already planned on synching with 19.34 man.el, and were going
> to add back in our original code for this.

I am open to guidance on the man-xref.el code.  I am not emotionally
attached to it, so if comparable cross reference features are going into the
next man.el anyway, I'd just as soon hold back on submitting the patch.

I don't know what is meant by the `portable code in Gnus' reference; if
someone could give me a more explicit clue I'll be happy to consult it.  I
will start reading more of the Gnus elisp anyway, for my own edification.

If I don't get any further guidance, I'll go ahead and submit the patch to
rms, assuming he'll make the ultimate decision of which way to go.

-- Mark Hood

From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 18:05:49 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA07515 for xemacs-beta-people; Mon, 7 Oct 1996 18:05:49 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA07512 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 18:05:48 -0500 (CDT)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id SAA29144 for <xemacs-beta@cs.uiuc.edu>; Mon, 7 Oct 1996 18:05:47 -0500 (CDT)
Received: (qmail 28018 invoked from smtpd); 7 Oct 1996 23:08:41 -0000
Received: from geordi.miranova.com (qmailr@206.190.83.3)
  by deanna.miranova.com with SMTP; 7 Oct 1996 23:08:41 -0000
Received: (qmail 16586 invoked from smtpd); 7 Oct 1996 23:10:29 -0000
Received: from deanna.miranova.com (steve@206.190.83.1)
  by geordi.miranova.com with SMTP; 7 Oct 1996 23:10:29 -0000
Sender: steve@deanna.miranova.com
To: hood@eng.sun.com
Cc: xemacs-beta@cs.uiuc.edu, rms@gnu.ai.mit.edu
Subject: Re: man-xref.el (was Re: debug-on-foo variables)
References: <199610072246.PAA11462@klia.eng.sun.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Mark Hood's message of Mon, 7 Oct 1996 15:46:43 -0700
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Date: 07 Oct 1996 16:08:39 -0700
Message-ID: <m2zq1ymky0.fsf@deanna.miranova.com>
Lines: 24
X-Mailer: Red Gnus v0.47/XEmacs 19.15

>>>>> "Mark" == Mark Hood <hood@Eng.Sun.COM> writes:

sb> May I request that the portable code in Gnus at
sb> least be consulted prior to its introduction?

Mark> I am open to guidance on the man-xref.el code.  I am not
Mark> emotionally attached to it, so if comparable cross reference
Mark> features are going into the next man.el anyway, I'd just as soon
Mark> hold back on submitting the patch.

Mark> I don't know what is meant by the `portable code in Gnus'
Mark> reference; if someone could give me a more explicit clue I'll be
Mark> happy to consult it.  I will start reading more of the Gnus
Mark> elisp anyway, for my own edification.

Take a look at how Gnus does URL highlighting when displaying
messages.  The method that it uses to invoke browse-url on a mouse
click is portable across emacsen.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.


From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 20:02:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA07757 for xemacs-beta-people; Mon, 7 Oct 1996 20:02:03 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA07754 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 20:01:57 -0500 (CDT)
Received: from pixar.com (pixar.pixar.com [138.72.10.20]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA17463 for <xemacs-beta@xemacs.org>; Mon, 7 Oct 1996 20:01:53 -0500 (CDT)
Received: from zule.pixar.com (gate-zule.pixar.com) by pixar.com with SMTP id AA29040
  (5.67b/IDA-1.5 for xemacs-beta@xemacs.org); Mon, 7 Oct 1996 18:01:24 -0700
Received: by zule.pixar.com (Smail3.1.28.1 #12)
	id m0vAQY0-0007r7C; Mon, 7 Oct 96 18:01 PDT
Message-Id: <m0vAQY0-0007r7C@zule.pixar.com>
Date: Mon, 7 Oct 96 18:01 PDT
From: Hunter Kelly <retnuh@zule.pixar.com>
To: xemacs-beta@xemacs.org
Subject: Bug #68
Mime-Version: 1.0 (generated by tm-edit 7.87)
Content-Type: text/plain; charset=US-ASCII



68    misc   B    medium  serious  open   unable to visit files in directories with $ in
		                                           their names


I think that this is more a documentation bug than anything else.
It turns out that you can do

/some/path/with/a/$$dollar/sign

for the path name '/some/path/with/a/$dollar/sign'. 

Maybe the docs should point that out somewhere?

Or should we modify the code so that 

/some/path/with/a/\$dollar/sign

would work too?  I'm willing to make a stab at it, I'm just wondering
if it is worth the time.

Hunter

From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 20:12:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA07774 for xemacs-beta-people; Mon, 7 Oct 1996 20:12:05 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA07771 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 20:12:01 -0500 (CDT)
Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA17488 for <xemacs-beta@xemacs.org>; Mon, 7 Oct 1996 20:11:58 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id SAA07432 for <xemacs-beta@xemacs.org>; Mon, 7 Oct 1996 18:07:35 -0700
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id SAA24017 for <xemacs-beta@xemacs.org>; Mon, 7 Oct 1996 18:05:56 -0700
Date: Mon, 7 Oct 1996 18:05:56 -0700
Message-Id: <199610080105.SAA24017@shellx.best.com>
From: Ben Wing <wing@666.com>
To: Richard Stallman <rms@gnu.ai.mit.edu>
Subject: Re: debug-on-foo variables
Cc: mrb@eng.sun.com, xemacs-beta@xemacs.org, bwarsaw@cnri.reston.va.us

>    Your arguments are disingenuous because in reality you make almost no
>    effort to keep things compatible, while we make quite a lot of effort.
>
>You have other reasons to keep track of what is changed in Emacs--for
>example, you can copy the code from Emacs.  Also I think all of you
>have more time available to put into XEmacs than I have for Emacs.

Not any more.  Chuck and I are occupied otherwise and I cannot even
type any more. (This message is being typed completely with one hand.)

>    2) you keep a detailed change log of things you're adding, so send
>       it to xemacs-beta@xemacs.org every two weeks (or right before
>       you're preparing a release), so we can tell you if a feature
>       is being incompatibly duplicated.
>
>I can't promise, but I might be able to send you the NEWS file shortly
>before a release.

Can't you set up a cron job that sends the new entries in the
various CHANGELOG files to xemacs-beta@xemacs.org each week?  Won't you
make at least this minimal effort towards compatibility?

ben

From xemacs-beta-request@cs.uiuc.edu  Mon Oct  7 20:53:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA07867 for xemacs-beta-people; Mon, 7 Oct 1996 20:53:28 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA07864 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 7 Oct 1996 20:53:27 -0500 (CDT)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA05545 for <xemacs-beta@cs.uiuc.edu>; Mon, 7 Oct 1996 20:53:26 -0500 (CDT)
Received: (qmail 30468 invoked from smtpd); 8 Oct 1996 01:56:23 -0000
Received: from geordi.miranova.com (qmailr@206.190.83.3)
  by deanna.miranova.com with SMTP; 8 Oct 1996 01:56:23 -0000
Received: (qmail 16738 invoked from smtpd); 8 Oct 1996 01:58:13 -0000
Received: from deanna.miranova.com (steve@206.190.83.1)
  by geordi.miranova.com with SMTP; 8 Oct 1996 01:58:13 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Bug #68
References: <m0vAQY0-0007r7C@zule.pixar.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Hunter Kelly's message of Mon, 7 Oct 96 18:01 PDT
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Date: 07 Oct 1996 18:56:20 -0700
Message-ID: <m2g23qmd6i.fsf@deanna.miranova.com>
Lines: 43
X-Mailer: Red Gnus v0.47/XEmacs 19.15

I didn't know you could do this; this feature is demented:

(find-file "/tmp/$fred/foo")

Finds a file named foo in a directory literally named, `/tmp/$fred',
as expected.

But C-x C-f "/tmp/$fred/foo" beeps and says "fred" is a nonexistent
environment variable.

>>>>> "Hunter" == Hunter Kelly <retnuh@zule.pixar.com> writes:

Hunter> 68    misc   B    medium  serious  open
Hunter> unable to visit files in directories with $ in their names

Hunter> I think that this is more a documentation bug than anything
Hunter> else.  It turns out that you can do

Hunter> /some/path/with/a/$$dollar/sign

Hunter> for the path name '/some/path/with/a/$dollar/sign'. 

Hunter> Maybe the docs should point that out somewhere?

Hunter> Or should we modify the code so that 

Hunter> /some/path/with/a/\$dollar/sign

Hunter> would work too?

That ought to work as well.  If expansion fails, the string ought to
be passed through so no quoting is required at all.

Hunter> I'm willing to make a stab at it, I'm just wondering
Hunter> if it is worth the time.

Probably not.  The current behavior matches 19.34, and
substitute-in-file-name is pretty hairy C Code. :-( :-(
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.


From xemacs-beta-request@cs.uiuc.edu  Tue Oct  8 06:53:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id GAA12710 for xemacs-beta-people; Tue, 8 Oct 1996 06:53:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id GAA12707 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 8 Oct 1996 06:53:31 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id GAA18262 for <xemacs-beta@xemacs.org>; Tue, 8 Oct 1996 06:53:26 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA09776; Tue, 8 Oct 1996 12:51:07 +0100
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA22494; Tue, 8 Oct 1996 13:51:00 +0200
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@xemacs.org
Cc: steve@miranova.com
Subject: 19.15b2, psgml-html: HTML DTD not found
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 08 Oct 1996 13:50:59 +0200
Message-Id: <y9lbued3c9o.fsf@modas.informatik.uni-tuebingen.de>
Lines: 27


Hi there,

I had to apply the attached patch to make psgml-html work.  I'm almost
certain it's not the Right Thing, but something needs to be done.

In sgml-setup-doctype, it says this:

	   (sgml-push-to-entity (sgml-make-entity docname 'dtd external))

... which makes it look for "DOCTYPE" entries in CATALOG, but there
are none.

Steve?

Cheers =8-} Mike

*** etc/sgml/CATALOG~	Mon Sep  9 18:08:32 1996
--- etc/sgml/CATALOG	Tue Oct  8 13:47:14 1996
***************
*** 47,49 ****
--- 47,51 ----
  PUBLIC "-//Microsoft//DTD Internet Explorer 2.0 Tables//EN"     ietables.dtd
  PUBLIC "-//W3C//DTD HTML 3.2//EN"                       html-3.2.dtd
  PUBLIC "-//W3C//DTD HTML Experimental 19960712//EN"	html-cougar.dtd
+ DOCTYPE HTML						html-3.2.dtd
+ DOCTYPE HTML-3						html-3.dtd

From xemacs-beta-request@cs.uiuc.edu  Tue Oct  8 07:26:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id HAA12741 for xemacs-beta-people; Tue, 8 Oct 1996 07:26:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA12738 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 8 Oct 1996 07:25:59 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id HAA18293 for <xemacs-beta@xemacs.org>; Tue, 8 Oct 1996 07:25:38 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA14966; Tue, 8 Oct 1996 13:04:22 +0100
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA15110; Tue, 8 Oct 1996 14:04:22 +0200
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@xemacs.org
Subject: 19.15b2: w3 push widget does not get defined
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 08 Oct 1996 14:04:21 +0200
Message-Id: <y9l919h3bne.fsf@modas.informatik.uni-tuebingen.de>
Lines: 8


Subject says (almost) all.  All other widgets get defined, just that
one doesn't.  Reloading a recompiled widget-edit does not help.  Only
manually executing the define-widget form there does.  Maybe there's
some evil interaction with CL or something?  (It doesn't happen with
xemacs -q, only my local setup exhibits this.)

Cheers =8-} Mike

From xemacs-beta-request@cs.uiuc.edu  Tue Oct  8 07:25:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id HAA12736 for xemacs-beta-people; Tue, 8 Oct 1996 07:25:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA12733 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 8 Oct 1996 07:25:39 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id HAA18290 for <xemacs-beta@xemacs.org>; Tue, 8 Oct 1996 07:25:29 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA15228; Tue, 8 Oct 1996 13:06:51 +0100
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA14862; Tue, 8 Oct 1996 14:06:51 +0200
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@xemacs.org
Subject: Re: 19.15b2: push widget
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 08 Oct 1996 14:06:50 +0200
Message-Id: <y9l7mp13bj9.fsf@modas.informatik.uni-tuebingen.de>
Lines: 5


Ooops, I just saw Red Gnus 0.48 also includes a widget-edit.el which
doesn't define a push widget.

Cheers =8-} Mike

From xemacs-beta-request@cs.uiuc.edu  Tue Oct  8 08:50:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA12997 for xemacs-beta-people; Tue, 8 Oct 1996 08:50:33 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA12994 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 8 Oct 1996 08:50:32 -0500 (CDT)
Received: from newman.aventail.com (root@newman.aventail.com [38.225.141.10]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id IAA18402 for <xemacs-beta@xemacs.org>; Tue, 8 Oct 1996 08:50:29 -0500 (CDT)
Received: from wmperry.oz.net.aventail.com (root@newman [192.168.1.1]) by newman.aventail.com (8.6.12/8.6.9) with SMTP id GAA11746; Tue, 8 Oct 1996 06:48:22 -0700
Date: Tue, 8 Oct 1996 06:48:22 -0700
Message-Id: <199610081348.GAA11746@newman.aventail.com>
From: William Perry <wmperry@aventail.com>
To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Cc: xemacs-beta@xemacs.org
Subject: Re: 19.15b2: w3 push widget does not get defined
In-Reply-To: <y9l919h3bne.fsf@modas.informatik.uni-tuebingen.de>
References: <y9l919h3bne.fsf@modas.informatik.uni-tuebingen.de>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Michael Sperber writes:
>
>Subject says (almost) all.  All other widgets get defined, just that
>one doesn't.  Reloading a recompiled widget-edit does not help.  Only
>manually executing the define-widget form there does.  Maybe there's
>some evil interaction with CL or something?  (It doesn't happen with
>xemacs -q, only my local setup exhibits this.)

  We need to upgrade to w3 3.0.24, which should be out in a few hours.
I'll mail a patch if you like.

-bill P.


From xemacs-beta-request@cs.uiuc.edu  Tue Oct  8 10:23:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA13226 for xemacs-beta-people; Tue, 8 Oct 1996 10:23:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA13223 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 8 Oct 1996 10:23:24 -0500 (CDT)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA22088 for <xemacs-beta@cs.uiuc.edu>; Tue, 8 Oct 1996 10:23:18 -0500 (CDT)
Received: (qmail 1166 invoked by uid 501); 8 Oct 1996 15:26:23 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: 19.15b2, psgml-html: HTML DTD not found
References: <y9lbued3c9o.fsf@modas.informatik.uni-tuebingen.de>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: sperber@informatik.uni-tuebingen.de's message of 08 Oct 1996 13:50:59 +0200
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Date: 08 Oct 1996 08:26:21 -0700
Message-ID: <m2ran9lboi.fsf@deanna.miranova.com>
Lines: 31
X-Mailer: Red Gnus v0.47/XEmacs 19.15

>>>>> "Michael" == Michael Sperber [Mr Preprocessor] <sperber@informatik.uni-tuebingen.de> writes:

Michael> I had to apply the attached patch to make psgml-html work.

What exactly fails?  I see a definite problem with data-directory and
compiling for running in place, which is fixed by making a symbolic
link ~/sgml point to etc/sgml.

Michael> I'm almost certain it's not the Right Thing, but something
Michael> needs to be done.

Michael> In sgml-setup-doctype, it says this:

   (sgml-push-to-entity (sgml-make-entity docname 'dtd external))

Michael> ... which makes it look for "DOCTYPE" entries in CATALOG, but
Michael> there are none.

Michael> Steve?

+ DOCTYPE HTML						html-3.2.dtd
+ DOCTYPE HTML-3						html-3.dtd

Please note that neither the expired HTML 3 draft, nor HTML 3.2 Wilbur
carry any official status, and HTML Cougar doesn't work due its use
of multibyte characters.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Oct  8 10:32:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA13249 for xemacs-beta-people; Tue, 8 Oct 1996 10:32:21 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA13246 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 8 Oct 1996 10:32:19 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA22633 for <xemacs-beta@cs.uiuc.edu>; Tue, 8 Oct 1996 10:32:18 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.56 #3)
	id E0vAe8n-0001bG-00; Tue, 8 Oct 1996 11:32:17 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: pcl-cvs.el
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0vAe8n-0001bG-00@neal.ctd.comsat.com>
Date: Tue, 8 Oct 1996 11:32:17 -0400

I have attempted to merge in the latest pcl-cvs.el from cvs-1.9.  The
changes seem pretty minor.   I haven't tested it yet.

The merged version is at ftp.ctd.comsat.com:/pub/pcl-cvs.el.

From xemacs-beta-request@cs.uiuc.edu  Tue Oct  8 14:43:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA14109 for xemacs-beta-people; Tue, 8 Oct 1996 14:43:09 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA14093 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 8 Oct 1996 14:42:55 -0500 (CDT)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA19137 for <xemacs-beta@xemacs.org>; Tue, 8 Oct 1996 14:42:26 -0500 (CDT)
Received: from hniksic@localhost by jagor.srce.hr (8.8.0/8.6.12.CI)
	id VAA18948; Tue, 8 Oct 1996 21:41:25 +0200 (MET DST)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: {backward,forward}-char at the edges
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/geturl/
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 08 Oct 1996 21:41:24 +0200
Message-ID: <kigviclxmzf.fsf@jagor.srce.hr>
Lines: 15
X-Mailer: Gnus v5.2.25/XEmacs 19.14

Is there a reason why back and forward-char signal errors at the
beginning (end) of buffer?

In GNU Emacs those two do not count as errors when debug-on-error is
t.  I have noticed that XEmacs-19.13 also signalled an error on
next/previous line, whereas they do not in 19.14.  Why has this
behaviour changed, and the behaviour of back/forward char has remained
the same?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The IDIOT.  Usually a cretin, morpohodite, or old COBOL programmer
selected to be the system administrator by a committee of cretins,
morphodites, and old COBOL programmers.

From xemacs-beta-request@cs.uiuc.edu  Tue Oct  8 15:26:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id PAA14292 for xemacs-beta-people; Tue, 8 Oct 1996 15:26:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA14289 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 8 Oct 1996 15:26:03 -0500 (CDT)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id PAA02683 for <xemacs-beta@cs.uiuc.edu>; Tue, 8 Oct 1996 15:25:59 -0500 (CDT)
Received: (qmail 708 invoked by uid 501); 8 Oct 1996 20:28:48 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Red Gnus v0.48 (was Re: 19.15b2: push widget)
References: <y9l7mp13bj9.fsf@modas.informatik.uni-tuebingen.de>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: sperber@informatik.uni-tuebingen.de's message of 08 Oct 1996 14:06:50 +0200
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Date: 08 Oct 1996 13:28:47 -0700
Message-ID: <m2g23p19q8.fsf@deanna.miranova.com>
Lines: 12
X-Mailer: Red Gnus v0.47/XEmacs 19.15

>>>>> "Michael" == Michael Sperber [Mr Preprocessor] <sperber@informatik.uni-tuebingen.de> writes:

Michael> Ooops, I just saw Red Gnus 0.48 also includes a
Michael> widget-edit.el which doesn't define a push widget.

Red Gnus v0.48 is quite divergent from Gnus 5.2.40 (<= v0.47 has
manageable differences).  I'm not sure what to recommend.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Wed Oct  9 18:09:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA21812 for xemacs-beta-people; Wed, 9 Oct 1996 18:09:16 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA21809 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 9 Oct 1996 18:09:15 -0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id SAA23101 for <xemacs-beta@xemacs.org>; Wed, 9 Oct 1996 18:09:12 -0500 (CDT)
Received: by mercury.Sun.COM (Sun.COM)
	id QAA20148; Wed, 9 Oct 1996 16:07:37 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA09266; Wed, 9 Oct 1996 16:06:49 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA00776; Wed, 9 Oct 1996 16:06:24 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA11260; Wed, 9 Oct 1996 16:06:21 -0700
Date: Wed, 9 Oct 1996 16:06:21 -0700
Message-Id: <199610092306.QAA11260@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Steven L Baur <steve@miranova.com>,
        XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: apropos.el
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII

Stephen, button2 in apropos-mode has stopped working properly, likely
because of your FSF merging.

Here is a patch (in my workspace) that makes apropos happy:

*** /tmp/geta11253	Wed Oct  9 16:03:28 1996
--- apropos.el	Wed Oct  9 12:55:49 1996
***************
*** 93,100 ****
  (defvar apropos-mode-map
    (let ((map (make-sparse-keymap)))
      (define-key map [(control m)] 'apropos-follow)
!     (define-key map [(button2up)] 'apropos-mouse-follow)
!     (define-key map [(button2down)] 'undefined)
      map)
    "Keymap used in Apropos mode.")
  
--- 93,99 ----
  (defvar apropos-mode-map
    (let ((map (make-sparse-keymap)))
      (define-key map [(control m)] 'apropos-follow)
!     (define-key map [(button2)] 'apropos-mouse-follow)
      map)
    "Keymap used in Apropos mode.")
  

From xemacs-beta-request@cs.uiuc.edu  Wed Oct  9 18:45:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA21885 for xemacs-beta-people; Wed, 9 Oct 1996 18:45:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA21882 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 9 Oct 1996 18:45:24 -0500 (CDT)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id SAA14790 for <xemacs-beta@cs.uiuc.edu>; Wed, 9 Oct 1996 18:45:16 -0500 (CDT)
Received: (qmail 14928 invoked by uid 501); 9 Oct 1996 23:48:13 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: apropos.el
References: <199610092306.QAA11260@xemacs.eng.sun.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Martin Buchholz's message of Wed, 9 Oct 1996 16:06:21 -0700
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Date: 09 Oct 1996 16:48:12 -0700
Message-ID: <m24tk3vgw3.fsf@deanna.miranova.com>
Lines: 158
X-Mailer: Red Gnus v0.47/XEmacs 19.15

[fooled by the carbon copy to a mailing list again :-( ]

>>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:

Martin> Stephen, button2 in apropos-mode has stopped working properly,
Martin> likely because of your FSF merging.

Martin> Here is a patch (in my workspace) that makes apropos happy:

This patch will conflict with the one I posted on September 17 which
basically does the same fix.  If you already applied that patch, you
should not apply Martin's.

While we're discussing apropos.el, here are my further changes to that
file that are waiting for release in beta3.  You may apply this patch
after you have applied either Martin's button2 fix, or mine.  The big
item is #4 -- I like colored buffers :-).

[Duplicate of patch sent to Chuck on September 22]

This patch does the following:
1.  Fixes the bug where if apropos-label-face is actually defined as
    face, apropos bombs with an error (due to the lack of data
    abstraction of GNU Emacs, as faces are just lists to them).

2.  Does a (provide 'apropos), like all packages should.

3.  Provides an apropos-mode-hook for Apropos Mode buffers (otherwise
    customization is unnecessarily painful).

4.  Redefines the default faces for the various apropos faces so they
    come out in color by default (defaults are based on various
    standard font-lock faces).

*** packages/apropos.el.1	Tue Sep 17 10:58:56 1996
--- packages/apropos.el	Sun Sep 22 21:39:48 1996
***************
*** 66,87 ****
    "*Whether the apropos commands should do more.
  Slows them down more or less.  Set this non-nil if you have a fast machine.")
  
! (defvar apropos-symbol-face 'bold
    "*Face for symbol name in apropos output or `nil'.  
  This looks good, but slows down the commands several times.")
  
! (defvar apropos-keybinding-face 'underline
    "*Face for keybinding display in apropos output or `nil'.  
  This looks good, but slows down the commands several times.")
  
! (defvar apropos-label-face 'italic
    "*Face for label (Command, Variable ...) in apropos output or `nil'.
  If this is `nil' no mouse highlighting occurs.
  This looks good, but slows down the commands several times.
  When this is a face name, as it is initially, it gets transformed to a
  text-property list for efficiency.")
  
! (defvar apropos-property-face 'bold-italic
    "*Face for property name in apropos output or `nil'.  
  This looks good, but slows down the commands several times.")
  
--- 66,99 ----
    "*Whether the apropos commands should do more.
  Slows them down more or less.  Set this non-nil if you have a fast machine.")
  
! ;; XEmacs addition
! (defvar apropos-symbol-face (if (boundp 'font-lock-keyword-face)
! 				font-lock-keyword-face
! 			      'bold)
    "*Face for symbol name in apropos output or `nil'.  
  This looks good, but slows down the commands several times.")
  
! ;; XEmacs addition
! (defvar apropos-keybinding-face (if (boundp 'font-lock-doc-string-face)
! 				    font-lock-doc-string-face
! 				  'underline)
    "*Face for keybinding display in apropos output or `nil'.  
  This looks good, but slows down the commands several times.")
  
! ;; XEmacs addition
! (defvar apropos-label-face (if (boundp 'font-lock-comment-face)
! 			       font-lock-comment-face
! 			     'italic)
    "*Face for label (Command, Variable ...) in apropos output or `nil'.
  If this is `nil' no mouse highlighting occurs.
  This looks good, but slows down the commands several times.
  When this is a face name, as it is initially, it gets transformed to a
  text-property list for efficiency.")
  
! ;; XEmacs addition
! (defvar apropos-property-face (if (boundp 'font-lock-variable-name-face)
! 				  font-lock-variable-name-face
! 				'bold-italic)
    "*Face for property name in apropos output or `nil'.  
  This looks good, but slows down the commands several times.")
  
***************
*** 111,116 ****
--- 123,130 ----
  (defvar apropos-item ()
    "Current item in or for apropos-accumulator.")
  
+ (defvar apropos-mode-hook nil) ; XEmacs
+ 
  (defun apropos-mode ()
    "Major mode for following hyperlinks in output of apropos commands.
  
***************
*** 119,125 ****
    (kill-all-local-variables)
    (use-local-map apropos-mode-map)
    (setq major-mode 'apropos-mode
! 	mode-name "Apropos"))
  
  
  ;; For auld lang syne:
--- 133,140 ----
    (kill-all-local-variables)
    (use-local-map apropos-mode-map)
    (setq major-mode 'apropos-mode
! 	mode-name "Apropos")
!   (run-hooks 'apropos-mode-hook)) ; XEmacs
  
  
  ;; For auld lang syne:
***************
*** 461,467 ****
  	  (sort apropos-accumulator (lambda (a b)
  				      (string-lessp (car a) (car b)))))
      (and apropos-label-face
! 	 (symbolp apropos-label-face)
  	 (setq apropos-label-face `(face ,apropos-label-face
  					 mouse-face highlight)))
      (with-output-to-temp-buffer "*Apropos*"
--- 476,483 ----
  	  (sort apropos-accumulator (lambda (a b)
  				      (string-lessp (car a) (car b)))))
      (and apropos-label-face
! 	 (or (symbolp apropos-label-face)
! 	     (facep apropos-label-face)) ; XEMacs
  	 (setq apropos-label-face `(face ,apropos-label-face
  					 mouse-face highlight)))
      (with-output-to-temp-buffer "*Apropos*"
***************
*** 628,632 ****
--- 644,650 ----
      (insert (apropos-format-plist symbol "\n  "))
      (princ ")")
      (print-help-return-message)))
+ 
+ (provide 'apropos) ; XEmacs
  
  ;;; apropos.el ends here

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 10 09:42:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id JAA26778 for xemacs-beta-people; Thu, 10 Oct 1996 09:42:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA26775 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 10 Oct 1996 09:42:25 -0500 (CDT)
Received: from icemark.thenet.ch (root@icemark.TheNet.CH [193.135.252.47]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id JAA24169 for <xemacs-beta@xemacs.org>; Thu, 10 Oct 1996 09:42:17 -0500 (CDT)
Received: from localhost by icemark.thenet.ch
	 with smtp id m0vBM2q-0003elC
	(Debian /\oo/\ Smail3.1.29.1 #29.37); Thu, 10 Oct 96 16:25 MET DST
Date: Thu, 10 Oct 1996 16:25:04 +0200 (MET DST)
From: Benedikt Eric Heinen <beh@icemark.thenet.ch>
To: XEmacs Beta mailing list <xemacs-beta@xemacs.org>
Subject: Bug in tutorial...
Message-ID: <Pine.LNX.3.95.961010162242.26974B-100000@icemark.thenet.ch>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



A new colleague of mine tried the xemacs tutorial in 19.14 today and found
a 'bug' in there. As an example for a disabled command <ESC><ESC> is
given, but eval-expression has been relocated...

This is still wrong in the current betas as well.


Benedikt


signoff

---
 Benedikt Eric Heinen  -  Muehlemattstrasse 53  -  CH3007 Bern  -   SWITZERLAND
 email: beh@icemark.thenet.ch				 phone: ++41.31.3714460


RIOT, n.  A popular entertainment given to the military by innocent bystanders.

				     Ambrose Bierce  ``The Devil's Dictionary''



From xemacs-beta-request@cs.uiuc.edu  Thu Oct 10 17:46:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id RAA28218 for xemacs-beta-people; Thu, 10 Oct 1996 17:46:33 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA28215 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 10 Oct 1996 17:46:31 -0500 (CDT)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id RAA25892 for <xemacs-beta@xemacs.org>; Thu, 10 Oct 1996 17:46:24 -0500 (CDT)
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM [129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA27146; Thu, 10 Oct 1996 15:45:54 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id PAA02074; Thu, 10 Oct 1996 15:45:38 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA21598; Thu, 10 Oct 1996 15:45:28 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA15305; Thu, 10 Oct 1996 15:45:25 -0700
Date: Thu, 10 Oct 1996 15:45:25 -0700
Message-Id: <199610102245.PAA15305@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>,
        MORIOKA Tomohiko <morioka@jaist.ac.jp>
Subject: defun-when-void
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII

Packages that try to maintain compatibility between emacs versions
often need to define functions possibly missing in some of those
versions, and often use (or should use) the idiom

(unless (fboundp 'foo)
  (defun foo ...))

To make this a little easier, I just added these macros to XEmacs (can
someone suggest better names?).  They have the significant advantage
of being correctly hilited by font-lock.

(defmacro defun-when-void (&rest args)
  "Define a function, just like `defun', unless it's already defined.
Used for compatibility among different emacs variants."
  `(if (fboundp ',(car args))
       nil
     (defun ,@args)))

(defmacro define-function-when-void (&rest args)
  "Define a function, just like `define-function', unless it's already defined.
Used for compatibility among different emacs variants."
  `(if (fboundp ,(car args))
       nil
     (define-function ,@args)))


From xemacs-beta-request@cs.uiuc.edu  Thu Oct 10 20:28:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA28606 for xemacs-beta-people; Thu, 10 Oct 1996 20:28:50 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA28603 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 10 Oct 1996 20:28:48 -0500 (CDT)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA26089 for <xemacs-beta@xemacs.org>; Thu, 10 Oct 1996 20:28:44 -0500 (CDT)
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM [129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA05255; Thu, 10 Oct 1996 18:27:21 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id SAA10645; Thu, 10 Oct 1996 18:27:20 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA24708; Thu, 10 Oct 1996 18:27:18 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA15636; Thu, 10 Oct 1996 18:27:17 -0700
Date: Thu, 10 Oct 1996 18:27:17 -0700
Message-Id: <199610110127.SAA15636@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Benedikt Eric Heinen <beh@icemark.thenet.ch>
Cc: XEmacs Beta mailing list <xemacs-beta@xemacs.org>
Subject: Bug in tutorial...
In-Reply-To: <Pine.LNX.3.95.961010162242.26974B-100000@icemark.thenet.ch>
References: <Pine.LNX.3.95.961010162242.26974B-100000@icemark.thenet.ch>
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Benedikt" == Benedikt Eric Heinen <beh@icemark.thenet.ch> writes:

Benedikt> A new colleague of mine tried the xemacs tutorial in 19.14 today and found
Benedikt> a 'bug' in there. As an example for a disabled command <ESC><ESC> is
Benedikt> given, but eval-expression has been relocated...

Benedikt> This is still wrong in the current betas as well.

Thanks for the bug report.  I have fixed up the reported bug, as well
as a few other inaccuracies in the TUTORIAL.  It will be in an
upcoming beta.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 10 20:19:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA28579 for xemacs-beta-people; Thu, 10 Oct 1996 20:19:00 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA28576 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 10 Oct 1996 20:18:59 -0500 (CDT)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA26080 for <xemacs-beta@xemacs.org>; Thu, 10 Oct 1996 20:18:55 -0500 (CDT)
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM [129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA04714 for <xemacs-beta@xemacs.org>; Thu, 10 Oct 1996 18:18:27 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id SAA09282; Thu, 10 Oct 1996 18:18:26 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA24621; Thu, 10 Oct 1996 18:18:24 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA15623; Thu, 10 Oct 1996 18:18:23 -0700
Date: Thu, 10 Oct 1996 18:18:23 -0700
Message-Id: <199610110118.SAA15623@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Bug Report: forwarded from John West
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Oct_10_18:18:22_1996-1"
Content-Transfer-Encoding: 7bit

--Multipart_Thu_Oct_10_18:18:22_1996-1
Content-Type: text/plain; charset=US-ASCII

Here's a bug report from a Sun user:

--Multipart_Thu_Oct_10_18:18:22_1996-1
Content-Type: message/rfc822

From: John West <John.West@Corp>

1. make a new buffer
2. insert/paste in a piece of source code
3. switch the mode to c-mode
4. select options->syntax_highlighting->colors

If, as I do, you've already customized the colors you like when
highlighting C code, you'll be suprised to find that this action
doesn't pick up the colors you've saved into your .xemacs-options
file.  

Correct behavior is exhibited by options->syntax_highlighting->in_this_buffer
(probably the proper choice, but ....)

emacs-version says:
XEmacs 20.0 [Lucid] (sparc-sun-solaris2.4) of Mon Sep 30 1996 on etude


--Multipart_Thu_Oct_10_18:18:22_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 10 20:34:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA28618 for xemacs-beta-people; Thu, 10 Oct 1996 20:34:02 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA28615 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 10 Oct 1996 20:34:01 -0500 (CDT)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA26100 for <xemacs-beta@xemacs.org>; Thu, 10 Oct 1996 20:33:57 -0500 (CDT)
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM [129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA05591; Thu, 10 Oct 1996 18:31:58 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id SAA11353; Thu, 10 Oct 1996 18:31:56 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA24744; Thu, 10 Oct 1996 18:31:54 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA15648; Thu, 10 Oct 1996 18:31:53 -0700
Date: Thu, 10 Oct 1996 18:31:53 -0700
Message-Id: <199610110131.SAA15648@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: Heiko Muenkel <muenkel@tnt.uni-hannover.de>,
        bug-tm-en@chamonix.jaist.ac.jp,
        XEmacs Beta Test <xemacs-beta@xemacs.org>
Cc: stenman@isy.liu.se
Subject: Re: Tip: XEmacs/CDE and tm
Newsgroups: zxr.comp.emacs.tm-english
In-Reply-To: <199610101126.NAA07717@daedalus.tnt.uni-hannover.de>
References: <199610100924.LAA12541@ludde.isy.liu.se>
	<199610101126.NAA07717@daedalus.tnt.uni-hannover.de>
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Heiko" == Heiko Muenkel <muenkel@tnt.uni-hannover.de> writes:

>>>>> "Anders" == Anders Stenman <stenman@isy.liu.se> writes:
Anders> Note: I'm using a patched version of the CDE support that
Anders> was distributed on comp.emacs.xemacs a couple of months
Anders> ago.

Heiko> Could you please send me the needed patch?

The CDE support in XEmacs is a little in flux right now.  The next
XEmacs beta should have new CDE code beyond that provided by Bryan
O'Sullivan. 

Martin

From xemacs-beta-request@cs.uiuc.edu  Fri Oct 11 09:12:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id JAA03941 for xemacs-beta-people; Fri, 11 Oct 1996 09:12:45 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA03938 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 11 Oct 1996 09:12:43 -0500 (CDT)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id JAA22356 for <xemacs-beta@cs.uiuc.edu>; Fri, 11 Oct 1996 09:12:39 -0500 (CDT)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.56 #3)
	id E0vBiK1-00013Z-00; Fri, 11 Oct 1996 10:12:17 -0400
From: Neal Becker <neal@ctd.comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: vc vs. ange-ftp
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0vBiK1-00013Z-00@neal.ctd.comsat.com>
Date: Fri, 11 Oct 1996 10:12:17 -0400

I thought we had a patch for this, but it's not in 19.14.  It's very
annoying that if you have used vc at all, every time you try to
retrieve a file via ange-ftp it tries also to retrieve every
conceivable version-controlled permutation of the file.  Anyone have a
patch?

From xemacs-beta-request@cs.uiuc.edu  Fri Oct 11 10:12:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA04099 for xemacs-beta-people; Fri, 11 Oct 1996 10:12:03 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA04096 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 11 Oct 1996 10:12:02 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA23664 for <xemacs-beta@cs.uiuc.edu>; Fri, 11 Oct 1996 10:12:01 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa11199;
          11 Oct 96 11:07 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id LAA09015; Fri, 11 Oct 1996 11:07:16 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id LAA04465; Fri, 11 Oct 1996 11:07:14 -0400
Date: Fri, 11 Oct 1996 11:07:14 -0400
Message-Id: <199610111507.LAA04465@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: Neal Becker <neal@ctd.comsat.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: vc vs. ange-ftp
References: <E0vBiK1-00013Z-00@neal.ctd.comsat.com>
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: Overtly resist change
X-WWW-Homepage: http://www.python.org/~bwarsaw

>>>>> "NB" == Neal Becker <neal@ctd.comsat.com> writes:

    NB> I thought we had a patch for this, but it's not in 19.14.
    NB> It's very annoying that if you have used vc at all, every time
    NB> you try to retrieve a file via ange-ftp it tries also to
    NB> retrieve every conceivable version-controlled permutation of
    NB> the file.  Anyone have a patch?

There's another strange interaction between vc and ange-ftp.  Whenever
I first visit a local RCS'd file, I end up with a weird modified
.netrc buffer.  Sometimes this buffer is actually called .netrc,
i.e. (switch-to-buffer ".netrc") works, and other times its really
called "*ftp-.netrc*".

I haven't been able to track the exact set of circumstances that cause
this, but I think it is related to the first, or one of the first
visits of a VC'd file.  At some point early in my XEmacs session, I
start seeing offers to save the modified ".netrc" file.  If I kill the
buffer, I'll never see those messages again.  Yes I do have a ~/.netrc
file laying around, but it is usually RCS unlocked so saving it would
fail.

I have a feeling the bogosity is somewhere in ange-ftp since the only
reference to *ftp-.netrc* I've found is in dired/ange-ftp.el.  But
that's as far as I've gotten.

Anybody else see this?

-Barry

From xemacs-beta-request@cs.uiuc.edu  Fri Oct 11 17:43:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id RAA05580 for xemacs-beta-people; Fri, 11 Oct 1996 17:43:04 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA05577 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 11 Oct 1996 17:43:02 -0500 (CDT)
Received: from newman.aventail.com (root@newman.aventail.com [38.225.141.10]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id RAA27809 for <xemacs-beta@xemacs.org>; Fri, 11 Oct 1996 17:42:58 -0500 (CDT)
Received: from wmperry.oz.net.aventail.com (root@newman [192.168.1.1]) by newman.aventail.com (8.6.12/8.6.9) with SMTP id PAA23960; Fri, 11 Oct 1996 15:36:44 -0700
Date: Fri, 11 Oct 1996 15:36:44 -0700
Message-Id: <199610112236.PAA23960@newman.aventail.com>
From: William Perry <wmperry@aventail.com>
To: Martin Buchholz <mrb@eng.sun.com>
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>,
        MORIOKA Tomohiko <morioka@jaist.ac.jp>
Subject: Re: defun-when-void
In-Reply-To: <199610102245.PAA15305@xemacs.eng.sun.com>
References: <199610102245.PAA15305@xemacs.eng.sun.com>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Martin Buchholz writes:
>Packages that try to maintain compatibility between emacs versions
>often need to define functions possibly missing in some of those
>versions, and often use (or should use) the idiom

  Hmmmm... I would just use the sysdep.el lingo.

(sysdep-defun ...)
(sysdep-defvar ...)
(sysdep-defconst ...)
(sysdep-fset ...)
(sysdep-defalias ...)

  The problem is just how exactly do you determine if you have a 'real'
version of a function, or one that was previously sysdep-defun'd, but yours
is really newer / better.

-Bill P.


From xemacs-beta-request@cs.uiuc.edu  Sat Oct 12 07:41:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id HAA10768 for xemacs-beta-people; Sat, 12 Oct 1996 07:41:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA10765 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 12 Oct 1996 07:41:26 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA28542 for <xemacs-beta@xemacs.org>; Sat, 12 Oct 1996 07:41:23 -0500 (CDT)
Received: from is18e0s01.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id VAA26223; Sat, 12 Oct 1996 21:41:10 +0900 (JST)
Message-Id: <199610121241.VAA26223@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.71, tm-view 7.77
X-Face: %yc?f+O/cVKlH*K(H2X/6-d''suf|"1{S:Y0}_9$t@0G3:5M2:-Ck^[8+4^iSLeGc[Ey[WP
 PF]2M#Q9C'u~[=7TJP72J`PZdWvP=s-'-/LhFneC->=ILc~H#$lf2%hLL5U8?psIp`<[>d&@$Pm%~(
 A'"CJ.zuX@TXh\Ra4,b7M&`f"hexU-a4,#X\]Bfp'JI+MGUDRA%_$&UnWAem4}1R"4%uivgn;xFZ%"
 NS>)eCuFYNHc/:W^:{7H>bGQS],x5z[Cy~C;7j#:8y9q|"~9~UWjE<Vm_;)o<Q4S5NweLc(cl7-suY
 NF|_O*xodbmQavM
X-Emacs: Mule 2.4 =?ISO-2022-JP?B?KBskQjlITVUybBsoQik=?=
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: "Ken'ichi Handa" <handa@etl.go.jp>, Martin Buchholz <mrb@eng.sun.com>
cc: mule@etl.go.jp, XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: mule API of Emacs and XEmacs (Re: caesar-region)
In-reply-to: Your message of "Sat, 12 Oct 1996 16:28:55 JST."
             <199610120728.QAA18867@mikan.jaist.ac.jp> 
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Sat_Oct_12_21:41:01_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Sat, 12 Oct 1996 21:41:18 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Sat_Oct_12_21:41:01_1996-1
Content-Type: text/plain; charset=US-ASCII

  Dear Ken'ich,

  I'm afraid of increasing of difference API between Emacs variants,
in particular about mule, now there are 3 implementation, traditional
MULE, Emacs/mule (MULE 2.4; Emacs including mule features) and
XEmacs/mule, and their APIs are different.

  It is hard to make emacs applications. I'm developing a package
``emu'' (EMulation Utility) for compatibility between emacs variants,
and a lot of emacs packages has such kind of modules.

  I think it is unfortunate to spend time to solve incompatibility. So
we should try to unify the emacs API. At the least, I would like to
unify new mule API. So if possible, please corporate.


  XEmacs/mule seems basically based on traditional MULE and some
features are influenced by alpha version of Emacs/mule. And some
features are originally arranged. XEmacs/mule is reformed data
expressions. Every characters occupy one element. So non-mule
application does not split non-ASCII characters.

  Emacs/mule uses traditional packed data expressions, but some
features were arranged. And coding-system mechanism is reformed.


** abstraction for character access

  I like XEmacs/mule data expressions, but it is hard to use in
Emacs/mule. So I propose to add `sref', `char-bytes',
`string-embed-string' into XEmacs/mule, and `map-char' for Emacs/mule
and XEmacs/mule. Implementation of XEmacs/mule is simply alias of
`mapcar'. For Emacs/mule, like following:

(defun map-char (function string)
  "Apply FUNCTION to each character of STRING, and make a list of the results.
The result is a list just as long as number of characters in STRING."
  (let ((len (length string))
	(i 0)
	dest)
    (while (< i len)
      (let* ((chr (sref string i))
	     (b (char-bytes chr))
	     )
	(setq dest (cons (funcall function chr) dest))
	(setq i (+ i (if (> b 0)
			 b
		       1)))
	))
    (nreverse dest)
    ))

Similarly, I propose `map-char-concat' for for Emacs/mule and
XEmacs/mule. Implementation of XEmacs/mule is simply alias of
`mapconcat'. For Emacs/mule, like following:

(defun map-char-concat (function string separator)
  "Apply FUNCTION to each character of STRING, and concat the results as strings.
In between each pair of results, stick in SEPARATOR.  Thus, \" \" as
SEPARATOR results in spaces between the values returned by FUNCTION."
  (let ((len (length string))
	(i 0)
	)
    (if (< i len)
	(let* ((chr (sref string i))
	       (dest (funcall function chr))
	       (b (char-bytes chr))
	       )
	  (setq i (+ i (if (> b 0)
			   b
			 1)))
	  (while (< i len)
	    (setq chr (sref string i)
		  b (char-bytes chr))
	    (setq dest (concat dest separator (funcall function chr)))
	    (setq i (+ i (if (> b 0)
			     b
			   1)))
	    )
	  dest)
      "")))


** charset

  I don't like feature name of `charset'. Charset means normally coded
character set, but `charset' of Emacs/mule and XEmacs/mule is not
coded character set, it is plane of character table. It is very
confusing between MIME charset. If possible, I would like to change to
other name, like `char-plane'.

  Anyway please unify name of charsets.

Emacs/mule				XEmacs/mule
----------------------------------------------------------------------
charset-arabic				arabic
charset-arabic-1-column			arabic-1
charset-arabic-2-column			arabic-2
charset-arabic-digit			arabic-0
charset-ascii				ascii
charset-ascii-right-to-left
charset-chinese-big5-1			chinese-big5-1
charset-chinese-big5-2			chinese-big5-2
charset-chinese-cns11643-1		chinese-cns-1
charset-chinese-cns11643-14
charset-chinese-cns11643-2		chinese-cns-2
charset-chinese-cns11643-3		chinese-cns-3
charset-chinese-cns11643-4		chinese-cns-4
charset-chinese-cns11643-5		chinese-cns-5
charset-chinese-cns11643-6		chinese-cns-6
charset-chinese-cns11643-7		chinese-cns-7
charset-chinese-gb2312			chinese-gb
charset-chinese-sisheng			sisheng
charset-cyrillic			cyrillic
charset-ethiopic			ethiopic
charset-greek				greek
charset-hebrew				hebrew
charset-ipa				ipa
charset-japanese-jisx0201-kana		japanese-kana
charset-japanese-jisx0201-roman		japanese-roman
charset-japanese-jisx0208		japanese
charset-japanese-jisx0208-1978		japanese-old
charset-japanese-jisx0212		japanese-2
charset-korean-ksc5601			korean
charset-latin-1				latin-1
charset-latin-2				latin-2
charset-latin-3				latin-3
charset-latin-4				latin-4
charset-latin-5				latin-5
charset-thai				thai
charset-vietnamese-lower		vietnamese-1
charset-vietnamese-upper		vietnamese-2
					control-1
					composite
----------------------------------------------------------------------

  I think it is better to rename XEmacs/mule like `charset-ascii'.

  At least, non prefix part should be same.

  In addition, now there are 2 styles in both emacsen. First one is
like `charset-latin-1' or `cyrillic'. Second one is like
`charset-chinese-gb2312'. I think it is better to unify one style.

  By the way, charset-japanese-jisx0201-roman or japanese-roman are
not good name, I think. Because JIS X0201-roman will be renamed to
`JIS X0201-Latin' in JIS X0201-1996?. And
`charset-japanese-jisx0201-roman' is strange. JIS X0201-Latin is a
Latin character set and it is a variant of ISO 646. So
`charset-latin-jisx0201' is better, I think.

  `japanese-2' of XEmacs/mule is not good because JIS plans to be
obsolete JIS X0212 and define JIS X0213? to supplement JIS
X0208. After JIS X0213? will be defined, Japanese character set will
be following planes:

Name					prefix		final-char
==================================================================
level-1 + level-2
------------------------------------------------------------------
JIS X0208-1983				None		`B'
JIS X0208-1990				ESC `&' `@'	`B'
==================================================================
level-1 + level-2 + level-3
------------------------------------------------------------------
JIS X0208-1990+JIS X0213-1998? level-3	None		?
==================================================================
level-4
------------------------------------------------------------------
JIS X0213-1998? level-4			None		?
==================================================================
obsolete
------------------------------------------------------------------
JIS X0208-1978				None		`@'
JIS X0212-1990				None		`D'
==================================================================

  If using `charset-japanese' or `charset-japanese-old' style, it is
better to use `charset-japanese-supplement' for JIS X0212-1990.

  In addition, I would like to define plane for CCITT extended GB
(ISO-IR 165).

*** functions

Emacs/mule			XEmacs/mule
----------------------------------------------------------------------
char-charset			char-charset
charset-bytes
				charset-ccl-program
				charset-chars
				charset-dimension
charset-description		charset-doc-string
charset-direction		charset-direction
				charset-final
				charset-from-attributes
				charset-graphic
charset-info			
charset-iso-class
charset-list			charset-list
				charset-name
charset-plist
				charset-registry
				charsetp
charset-table
charset-width			charset-chars
declare-equiv-charset
define-charset			make-charset	(*)
				make-reverse-direction-charset
find-charset-region		charsets-in-region
find-charset-string		charsets-in-string
				coding-system-charset
(symbol-value)			find-charset
get-charset-property		charset-property
(symbol-value)			get-charset
get-undefined-private-charset	
put-charset-property
set-charset-plist
				set-charset-ccl-program
				set-charset-registry

(*) different arguments format
----------------------------------------------------------------------

  I request `charsetp', `find-charset' and `get-charset' for
Emacs/mule, like:

(defun charsetp (object)
  "Return non-nil if OBJECT is a charset."
  (and (numberp object)
       (> (charset-bytes object) 0)
       ))

(defun find-charset (object)
  "Retrieve the charset of the given name.
If OBJECT is a charset object, it is simply returned.
Otherwise, OBJECT should be a symbol.  If there is no such charset,
nil is returned.  Otherwise the associated charset object is returned."
  (cond ((numberp object) object)
	((and (symbolp object)
	      (boundp object))
	 (let ((cs (symbol-value object)))
	   (if (charsetp cs)
	       cs
	     ))
	 )))

(defalias 'get-charset 'eval)

and I request `charset-name' for Emacs/mule.


  I request to rename `charsets-in-{string|region}' to
find-charset-{string|region}' to XEmacs/mule.


  I request to unify `charset-iso-class' of Emacs/mule and
`charset-chars' and `charset-dimension' of XEmacs/mule. I like
XEmacs/mule way, but compatibility is more important.


** coding-system

  This is similar to charset. Emacs/mule uses `charset-iso-2022-jp'
style.  XEmacs/mule uses `iso-2022-jp' style.  I like XEmacs/mule
style, but RMS does not like it.  So I would like to change
XEmacs/mule to Emacs/mule style.

  Anyway, we can translate a lot of coding-systems to add or delete
prefix `coding-system-'.  But some coding-systems are not.

Emacs/mule				XEmacs/mule
----------------------------------------------------------------------
					alternativnyj
					alternativnyj-dos
					alternativnyj-mac
					alternativnyj-unix
automatic-conversion			autodetect
automatic-conversion-dos		autodetect-dos
automatic-conversion-mac		autodetect-mac
automatic-conversion-unix		autodetect-unix
(obsolete)				big5-eten
					binary
					ctext-hebrew
					ctext-hebrew-dos
					ctext-hebrew-mac
					ctext-hebrew-unix
					escape-quoted
coding-system-euc-korea-dos
coding-system-euc-korea-mac
coding-system-euc-korea-unix
coding-system-hz-dos
coding-system-hz-mac
coding-system-hz-unix
					iso-2022-8
					iso-2022-8-dos
					iso-2022-8-mac
					iso-2022-8-unix
coding-system-internal
coding-system-internal-dos
coding-system-internal-mac
coding-system-internal-unix
coding-system-iso-2022-cn
coding-system-iso-2022-cn-dos
coding-system-iso-2022-cn-mac
coding-system-iso-2022-cn-unix
coding-system-iso-2022-int		iso-2022-int-1
coding-system-iso-2022-int-dos		iso-2022-int-1-dos
coding-system-iso-2022-int-mac		iso-2022-int-1-mac
coding-system-iso-2022-int-unix		iso-2022-int-1-unix
coding-system-iso-2022-int-2
coding-system-iso-2022-int-2-dos
coding-system-iso-2022-int-2-mac
coding-system-iso-2022-int-2-unix
					iso-2022-jp-dos
					iso-2022-jp-mac
					iso-2022-jp-unix
coding-system-iso-2022-kr-dos
coding-system-iso-2022-kr-mac
coding-system-iso-2022-kr-unix
coding-system-iso-8859-1		ctext
coding-system-iso-8859-1-dos
coding-system-iso-8859-1-mac
coding-system-iso-8859-1-unix
					koi8
					koi8-dos
					koi8-mac
					koi8-unix
coding-system-iso-2022-kr		korean-mail
no-conversion				noconv
					noconv-dos
					noconv-mac
					noconv-unix
coding-system-old-jis			oldjis
coding-system-old-jis-dos		oldjis-dos
coding-system-old-jis-mac		oldjis-mac
coding-system-old-jis-unix		oldjis-unix
coding-system-sjis			shift-jis
coding-system-sjis-dos			shift-jis-dos
coding-system-sjis-mac			shift-jis-mac		
coding-system-sjis-unix			shift-jis-unix
coding-system-viqr-dos			
coding-system-viqr-mac
coding-system-viqr-unix
----------------------------------------------------------------------

  I think major part of coding-system name should be same as MIME
charset is it is registered.

  And for XEmacs/mule, please change `noconv' and `autodetect' to
`no-conversion' and `automatic-conversion', and add `iso-8859-1'.

  In addition, coding-system encoder/decoder is rewrote in Emacs/mule.
Old mule can not encode iso-2022-cn* like coding-system. If possible,
XEmacs/mule should sync with Emacs/mule.


*** functions and variables

[Functions]

Emacs/mule				XEmacs/mule
----------------------------------------------------------------------
after-insert-file-set-buffer-file-coding-system
check-coding-system
					coding-system-ccl-decode
					coding-system-ccl-encode
					coding-system-charset
coding-system-docstring			coding-system-doc-string
					
coding-system-eoltype			coding-system-eol-type
					coding-system-eol-cr
					coding-system-eol-crlf
					coding-system-eol-lf
coding-system-eoltype-mnemonic
					coding-system-eoltype-mnemonic
coding-system-flags
coding-system-list			coding-system-list
					coding-system-lock-shift
coding-system-mnemonic			coding-system-mnemonic
					coding-system-name
					coding-system-no-ascii-cntl
					coding-system-no-ascii-eol
					coding-system-no-iso6429
coding-system-p				coding-system-p
coding-system-post-read-conversion	coding-system-post-read-conversion
coding-system-pre-write-conversion	coding-system-pre-write-conversion
					coding-system-property
					coding-system-seven
					coding-system-short
coding-system-type			coding-system-type
					coding-system-use-japanese-old
					coding-system-use-japanese-roman
					convert-mbox-coding-system
coding-system-vector
define-coding-system-alias		copy-coding-system
describe-coding-system
describe-current-coding-system
describe-current-coding-system-briefly
find-coding-system
find-new-buffer-file-coding-system
(identity)				find-coding-system
					find-coding-system-magic-cookie
keyboard-coding-system
list-coding-systems
make-coding-system			make-coding-system (*)
print-coding-system
print-coding-system-briefly
process-coding-system
					process-input-coding-system
					process-output-coding-system
read-coding-system			read-coding-system
read-non-nil-coding-system		read-non-nil-coding-system
set-buffer-file-coding-system		set-file-coding-system
					set-file-coding-system-for-read
set-coding-system-alist
set-current-process-coding-system
					set-default-file-coding-system
set-keyboard-coding-system
set-process-coding-system		
					set-process-input-coding-system
					set-process-output-coding-system
set-terminal-coding-system		set-display-coding-system
					subsidiary-coding-system
terminal-coding-system
					what-coding-system
----------------------------------------------------------------------

[Variables]

Emacs/mule				XEmacs/mule
----------------------------------------------------------------------
buffer-file-coding-system		file-coding-system
coding-system-alist
					file-coding-system-alist
coding-system-for-read			file-coding-system-for-read
coding-system-for-write			file-coding-system
default-process-coding-system
					keyboard-coding-system
					locale-coding-system
					overriding-file-coding-system
					pathname-coding-system
					process-input-coding-system
					process-output-coding-system
last-coding-system-used
----------------------------------------------------------------------

  Coding-system API is completely changed in Emacs/mule. If possible,
XEmacs/mule should sync with Emacs/mule. In particular,
coding-system-alist feature and `coding-system-for-{read|write}' are
very important.


** language environment, locale

  XEmacs/mule introduced locale model.  I basically don't think locale
is bad, but current behavior is very bad.

  In Japanese, there are 3 major coding-system, iso-2022-jp,
euc-japanese, shift_jis. So locale-coding-system may be not useful.

  In Japanese environment, XEmacs/mule changes font registry for
charset-ascii to JISX0201 to display JIS X0201-Latin for
charset-ascii.  I think it is very bad behavior, a lot of people will
be angry or shocked.  ASCII and JIS X0201-Latin are different
character-set and mule can distinguish these character-set.

  Of course, sometimes we want to unify ASCII and JIS X0201-Latin by
code-point (as same as other ISO 646 variants).  But to solve by font
registry, it influences every buffers and we can not distinguish
REVERSE SOLIDUS (backslash) and YEN SIGN.  I think it should be solved
by coding-system.


  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
--- I protest Chinese nuclear testing --------------------------------
----------------- and virtual testing of United States and France. ---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key
--pgp-sign-Multipart_Sat_Oct_12_21:41:01_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMl+R6BnuUGV7wuH5AQHYxwP9Flj3C+Ct4xuhxtIoWjatkk98HttVjjho
MzXBywSecfzoiTmH367+7LqvyJ8bCFGK2hyrBk7zfWgbG1VLyw50febJOltcws0K
iH1T/XGF9kMkSxi/ucO7ZjxaONw1uN9Yca6Jcpv/F9VvvgsFGo803bgQlr4U4PL8
PeZjt8Qt3bo=
=VSRg
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Sat_Oct_12_21:41:01_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 14 00:22:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA18508 for xemacs-beta-people; Mon, 14 Oct 1996 00:22:54 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA18505 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 14 Oct 1996 00:22:53 -0500 (CDT)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id AAA00497 for <xemacs-beta@xemacs.org>; Mon, 14 Oct 1996 00:22:49 -0500 (CDT)
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM [129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA10365; Sun, 13 Oct 1996 22:21:28 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA10425; Sun, 13 Oct 1996 22:21:26 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA01705; Sun, 13 Oct 1996 22:21:26 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA23056; Sun, 13 Oct 1996 22:21:21 -0700
Date: Sun, 13 Oct 1996 22:21:21 -0700
Message-Id: <199610140521.WAA23056@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko
 <morioka@jaist.ac.jp>,
        "Ken'ichi Handa" <handa@etl.go.jp>
Cc: mule@etl.go.jp, XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: mule API of Emacs and XEmacs (Re: caesar-region)
In-Reply-To: <199610121241.VAA26223@mikan.jaist.ac.jp>
References: <199610120728.QAA18867@mikan.jaist.ac.jp>
	<199610121241.VAA26223@mikan.jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII

>>>>> "MT" == MORIOKA Tomohiko <MORIOKA> writes:

MT>   I'm afraid of increasing of difference API between Emacs variants,
MT> in particular about mule, now there are 3 implementation, traditional
MT> MULE, Emacs/mule (MULE 2.4; Emacs including mule features) and
MT> XEmacs/mule, and their APIs are different.

MT>   It is hard to make emacs applications. I'm developing a package
MT> ``emu'' (EMulation Utility) for compatibility between emacs variants,
MT> and a lot of emacs packages has such kind of modules.

MT>   I think it is unfortunate to spend time to solve incompatibility. So
MT> we should try to unify the emacs API. At the least, I would like to
MT> unify new mule API. So if possible, please corporate.

I am willing to co-operate with a unification of the API.  However,
this should be the API that is currently being created for the merge
of Mule and GNU Emacs, which does not quite exist yet... Adding
new compatibility functions is easy, and I see no reason not to.

Most of the design decisions of the Mule support in XEmacs were made
by Ben Wing, but he is doing other things now, and I am the current
maintainer.  My employer is particularily focused on making XEmacs an
editor that will interoperate well with other products being sold into
the Japanese Solaris market.

MT>   XEmacs/mule seems basically based on traditional MULE and some
MT> features are influenced by alpha version of Emacs/mule. And some

Very little from Emacs/mule alpha versions has made its way into
XEmacs, I think.  mule-19.33-gamma doesn't compile for me (yet).

MT> charset-latin-4				latin-4
MT> charset-latin-5				latin-5
MT> charset-thai				thai
MT>   I think it is better to rename XEmacs/mule like `charset-ascii'.

Faces have names like 'italic, not 'face-italic, so charsets should
have names like 'latin-4,not 'charset-latin-4.  Maybe.

MT>   In addition, I would like to define plane for CCITT extended GB
MT> (ISO-IR 165).

MT>   I think major part of coding-system name should be same as MIME
MT> charset is it is registered.

Agreed.

MT>   And for XEmacs/mule, please change `noconv' and `autodetect' to
MT> `no-conversion' and `automatic-conversion', and add `iso-8859-1'.

Agreed.

MT>   XEmacs/mule introduced locale model.  I basically don't think locale
MT> is bad, but current behavior is very bad.

MT>   In Japanese, there are 3 major coding-system, iso-2022-jp,
MT> euc-japanese, shift_jis. So locale-coding-system may be not useful.

locale-coding-system is not actually implemented yet. (like many other
things in XEmacs/Mule.)

It's hard for me to understand the Japanese enviroment, not being
Japanese.  But on Japanese Solaris 2.5, everything that comes with the
OS tends to be encoded in EUC, with the exception of Mail and News.
So XIM input, filenames, file contents, shell input/output,
etc... should be in EUC.

MT>   In Japanese environment, XEmacs/mule changes font registry for
MT> charset-ascii to JISX0201 to display JIS X0201-Latin for
MT> charset-ascii.  I think it is very bad behavior, a lot of people will
MT> be angry or shocked.  ASCII and JIS X0201-Latin are different
MT> character-set and mule can distinguish these character-set.

MT>   Of course, sometimes we want to unify ASCII and JIS X0201-Latin by
MT> code-point (as same as other ISO 646 variants).  But to solve by font
MT> registry, it influences every buffers and we can not distinguish
MT> REVERSE SOLIDUS (backslash) and YEN SIGN.  I think it should be solved
MT> by coding-system.

I think I need an education on this.  My requirements come mostly from
the Sun Japanese Scientific Center, and they were quite vocal about
wanting to see JISX0201 for all Roman text, in particular because it
is impossible to get a Solaris ISO8859-1 monospaced font that is
exactly half the width of the user's JISX0208 font, and they REALLY
care about having their text line up properly. Many Japanese users
complain that some applications on Solaris use ISO8859-1 fonts
together with JISX0208.  When I used a Japanese workstation (Sony
NEWS) for the first time in 1989, it displayed the backslash as a Yen
sign.

If you have a buffer containing Japanese-Roman characters, and you
type 'A', do you get an ASCII 'A' in the buffer, or a Japanese-Roman
'A' ?  If an ASCII 'A', won't this look really weird?  To have a
keypress insert different characters in different buffers would also
be really weird.

Of course, you can do

(setf (charset-registry 'ascii) 'ISO8859-1")

to reset the font used for ASCII characters.

Martin


From xemacs-beta-request@cs.uiuc.edu  Mon Oct 14 04:35:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA22520 for xemacs-beta-people; Mon, 14 Oct 1996 04:35:55 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA22517 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 14 Oct 1996 04:35:54 -0500 (CDT)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA00975 for <xemacs-beta@xemacs.org>; Mon, 14 Oct 1996 04:35:36 -0500 (CDT)
Received: from hniksic@localhost by jagor.srce.hr (8.8.0/8.6.12.CI)
	id LAA18827; Mon, 14 Oct 1996 11:35:15 +0200 (MET DST)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: Crashes on multi-device stuff
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 14 Oct 1996 11:35:13 +0200
Message-ID: <kign2xpc2i5.fsf@jagor.srce.hr>
Lines: 23

XEmacs crashes on me whenever I try to do multi-device stuff with more
than 1 X display.  This accounts for even the relatively simple
things.

Say I have two frames on a display aaa.  Now I log to the display bbb
and want to move there.  I eval:
(make-frame-on-display "bbb")

and kill the two frames on "aaa" with C-x 5 0.  Now I sit at "bbb" and
click on the news icon to start Gnus, and XEmacs opens the new frame
and crashes.  The same happens even trying to work with XEmacs.  I
will try the same with 19.15b2 and produce a C backtrace.

Until then, I know this is a crappy bug report, but these crashes
render the multi-device support practically useless.

Anyone had similar expirience?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 14 05:43:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id FAA22725 for xemacs-beta-people; Mon, 14 Oct 1996 05:43:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id FAA22722 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 14 Oct 1996 05:43:55 -0500 (CDT)
Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id FAA01046 for <xemacs-beta@xemacs.org>; Mon, 14 Oct 1996 05:43:38 -0500 (CDT)
Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
          id <00645-0@josef.ifi.unizh.ch>; Mon, 14 Oct 1996 12:27:43 +0100
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)
To: mule@etl.go.jp
Date: Mon, 14 Oct 1996 12:27:42 +0100 (MET)
Cc: handa@etl.go.jp, mrb@eng.sun.com, xemacs-beta@xemacs.org
In-Reply-To: <199610121241.VAA26223@mikan.jaist.ac.jp> from "=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko" at Oct 12, 96 09:41:18 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: Martin J Duerst <mduerst@ifi.unizh.ch>
Sender: mduerst@ifi.unizh.ch
Message-ID: <"josef.ifi..739:14.09.96.11.27.44"@ifi.unizh.ch>

Morioka Tomohiko <morioka@jaist.ac.jp> wrote:

>** charset
>
>  I don't like feature name of `charset'. Charset means normally coded
>character set, but `charset' of Emacs/mule and XEmacs/mule is not
>coded character set, it is plane of character table. It is very
>confusing between MIME charset. If possible, I would like to change to
>other name, like `char-plane'.

The name "charset" may be a problem because it's use does not
coincide with MIME. However, according to the definition in
ISO 2022, a "coded character set" is exactly what mule
means with "charset", namely a character set with a one-to-one
allocation of bit combinations. So mule is right, and MIME
is wrong; MIME actually should use a term such as encoding
or coding system. When writing about MIME "charset"s, I
recommend to always add "MIME" and to put "charset" into
quotes to show that this term is MIME-specific and not
very accurate.

Regards,	Martin Du"rst.


From xemacs-beta-request@cs.uiuc.edu  Mon Oct 14 08:09:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA22923 for xemacs-beta-people; Mon, 14 Oct 1996 08:09:06 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA22920 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 14 Oct 1996 08:09:04 -0500 (CDT)
Received: from etlpost (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id IAA01149 for <xemacs-beta@xemacs.org>; Mon, 14 Oct 1996 08:08:57 -0500 (CDT)
Received: from etlpom.etl.go.jp by etlpost (8.6.9+2.4W/2.7W)
	id WAA20677; Mon, 14 Oct 1996 22:08:53 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA21886; Mon, 14 Oct 96 22:08:52 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id WAA09619; Mon, 14 Oct 1996 22:09:52 +0900
Date: Mon, 14 Oct 1996 22:09:52 +0900
Message-Id: <199610141309.WAA09619@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: mrb@eng.sun.com, mule@etl.go.jp, xemacs-beta@xemacs.org
In-Reply-To: <199610121241.VAA26223@mikan.jaist.ac.jp> (message from
	=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko on
	Sat, 12 Oct 1996 21:41:18 JST)
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
   Date: Sat, 12 Oct 1996 21:41:18 JST

     I'm afraid of increasing of difference API between Emacs variants,
   in particular about mule, now there are 3 implementation, traditional
   MULE, Emacs/mule (MULE 2.4; Emacs including mule features) and
   XEmacs/mule, and their APIs are different.

Thank you very very much for the detailed survey on the differences
among various versions of Emacs(Mule), and I'm sorry for the current
confusion.  Most of the changes of symbol names are requested by RMS
(Mr. Stallman) (e.g. prepending "charset-" and "coding-system-").
Especially, he haste putting `*' in front of coding system names.

     I think it is unfortunate to spend time to solve incompatibility. So
   we should try to unify the emacs API. At the least, I would like to
   unify new mule API. So if possible, please corporate.

I do agree with you, and I'm willing to corporate.

     XEmacs/mule seems basically based on traditional MULE and some
   features are influenced by alpha version of Emacs/mule. And some
   features are originally arranged. XEmacs/mule is reformed data
   expressions. Every characters occupy one element. So non-mule
   application does not split non-ASCII characters.

I once discussed on this issue with Mr. Wing (Ben), and read his early
code.  I agree that XEmacs/mule's approach helps emacslisp programmer
a lot, but also agree with RMS's opinion that it makes Emacs slooow
and emacslisp programmer can overcome the difficulty of handling
Mule's multi-byte form with appropriate APIs.

Mr. Wing told me that even if XEmacs/mule's approach was untolerably
slow, it could be aboided by implementing some kind of cashing
mechanism.  Does the current XEmacs/mule have cash for buffer
positioning?  ... anyway, this is not the current discussion point ...

   ** abstraction for character access
     I like XEmacs/mule data expressions, but it is hard to use in
   Emacs/mule. So I propose to add `sref', `char-bytes',
   `string-embed-string' into XEmacs/mule, and `map-char' for Emacs/mule
   and XEmacs/mule. Implementation of XEmacs/mule is simply alias of
   `mapcar'. For Emacs/mule, like following:
   ...
   Similarly, I propose `map-char-concat' for for Emacs/mule and
   XEmacs/mule. Implementation of XEmacs/mule is simply alias of
   `mapconcat'. For Emacs/mule, like following:
   ...

I agree with adding these functions.

   ** charset
     I don't like feature name of `charset'. Charset means normally coded
   character set, but `charset' of Emacs/mule and XEmacs/mule is not
   coded character set, it is plane of character table. It is very
   confusing between MIME charset. If possible, I would like to change to
   other name, like `char-plane'.

No, no.  Mule's charset is surely `coded character set' in the sense
of ISO 2022 as Mr. Du"rst wrote.

     Anyway please unify name of charsets.

I agree.  But, as I wrote above, RMS insists on putting
`charset-LANGUAGE-' at heads.  So, I hope XEmacs/mule compromises on
this point.

     At least, non prefix part should be same.

Ok.

     In addition, now there are 2 styles in both emacsen. First one is
   like `charset-latin-1' or `cyrillic'. Second one is like
   `charset-chinese-gb2312'. I think it is better to unify one style.

Sure.  I think the latter form is better.

     By the way, charset-japanese-jisx0201-roman or japanese-roman are
   not good name, I think. Because JIS X0201-roman will be renamed to
   `JIS X0201-Latin' in JIS X0201-1996?. And
   `charset-japanese-jisx0201-roman' is strange. JIS X0201-Latin is a
   Latin character set and it is a variant of ISO 646. So
   `charset-latin-jisx0201' is better, I think.

Hmmm, ok.  Then how to do with charset-japanese-jisx0201-kana?  Keep
it as is?  How about using the following format:

	charset-LANGUAGE_OR_SCRIPT_NAME-CHARSET_NAME[-ADDITIONAL_INFO]

Then, charset-latin-N are renamed to charset-latin-iso8859-N,
charset-greek to charset-greek-iso8859-7, etc.

Perhaps charset-ascii can be the same instead of renaming to
charset-latin-ascii.

     `japanese-2' of XEmacs/mule is not good because JIS plans to be
   obsolete JIS X0212 and define JIS X0213? to supplement JIS
   X0208. After JIS X0213? will be defined, Japanese character set will
   be following planes:

I myself is against this policy of JIS because there already exist
several implementations of JISX0212.  We can't get rid of this charset.

     In addition, I would like to define plane for CCITT extended GB
   (ISO-IR 165).

Sorry, I don't know about this charset.

   *** functions
     I request `charsetp', `find-charset' and `get-charset' for
   Emacs/mule, like:
   ...
   and I request `charset-name' for Emacs/mule.

I agree.

     I request to unify `charset-iso-class' of Emacs/mule and
   `charset-chars' and `charset-dimension' of XEmacs/mule. I like
   XEmacs/mule way, but compatibility is more important.

If XEmacs/mule uses `charset-dimension' for returning information of
number of characters in a charset (i.e. 94, 96, 94x94, 96x96), yes, I
agree that the word `dimension' is better than `iso-class'.

But, for the width (column number occupied on screen), I think
charset-width is better.

   ** coding-system
     Anyway, we can translate a lot of coding-systems to add or delete
   prefix `coding-system-'.  But some coding-systems are not.
   ...
     I think major part of coding-system name should be same as MIME
   charset is it is registered.

Ok, could you give us your total proposal for naming them.

   *** functions and variables
   [Functions]

   Emacs/mule				XEmacs/mule
   ----------------------------------------------------------------------
					   coding-system-eol-cr
					   coding-system-eol-crlf
					   coding-system-eol-lf
					   coding-system-no-ascii-cntl
					   coding-system-no-ascii-eol
					   coding-system-no-iso6429
					   coding-system-property
					   coding-system-seven
					   coding-system-short
					   coding-system-use-japanese-roman

It seems that these are for checking flags of each coding system.  Do
you think it is really worth implementing them?

   [Variables]
   Emacs/mule				XEmacs/mule
   ----------------------------------------------------------------------
   buffer-file-coding-system		file-coding-system

This is also suggested by RMS.

   coding-system-for-read			file-coding-system-for-read
   coding-system-for-write			file-coding-system

Now Emacs/mule uses them not only for file I/O but also for process
I/O, so, prefix `file-' is not appropriate.

And, I renamed display-coding-system to terminal-coding-system because
the latter is more appropriate.  Many peaple tried to change
`display-coding-system' in vain when then can't see correct characters
on Emacs running under X.  In addition, now terminal-coding-system and
keyboard-coding-system are not variables but functions returning
coding systems.  This change avoids frequent check of coding system
specified by variable while displaying on terminal.

   XEmacs/mule should sync with Emacs/mule. In particular,
   coding-system-alist feature and `coding-system-for-{read|write}' are
   very important.

We are now discussing on mule-jp@etl.go.jp about the spec of
coding-system-alist.  If XEmacs/mule also implements them, I think we
should wait for the result of the discussion.

   ** language environment, locale

     In Japanese environment, XEmacs/mule changes font registry for
   charset-ascii to JISX0201 to display JIS X0201-Latin for
   charset-ascii.  I think it is very bad behavior, a lot of people will
   be angry or shocked.  ASCII and JIS X0201-Latin are different
   character-set and mule can distinguish these character-set.

     Of course, sometimes we want to unify ASCII and JIS X0201-Latin by
   code-point (as same as other ISO 646 variants).  But to solve by font
   registry, it influences every buffers and we can not distinguish
   REVERSE SOLIDUS (backslash) and YEN SIGN.  I think it should be solved
   by coding-system.

I plan to unify characters of JISX0201 to ASCII except for the
different two characters (yen and backslash) while reading into Emacs.
But, I have not yet decided how to implement it.  I also plan to unify
most of JISX0208-1978 characters to JISX0208.

     Thanks,

Thank you very much again for your very important suggestion.

---
Ken'ichi HANDA
handa@etl.go.jp

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 14 09:27:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id JAA23155 for xemacs-beta-people; Mon, 14 Oct 1996 09:27:13 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA23152 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 14 Oct 1996 09:27:07 -0500 (CDT)
Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id JAA01277 for <xemacs-beta@xemacs.org>; Mon, 14 Oct 1996 09:27:03 -0500 (CDT)
Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
          id <01041-0@josef.ifi.unizh.ch>; Mon, 14 Oct 1996 16:26:27 +0100
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)
To: mule@etl.go.jp
Date: Mon, 14 Oct 1996 16:26:26 +0100 (MET)
Cc: mrb@eng.sun.com, xemacs-beta@xemacs.org
In-Reply-To: <199610141309.WAA09619@etlken.etl.go.jp> from "Kenichi Handa" at Oct 14, 96 10:09:52 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: Martin J Duerst <mduerst@ifi.unizh.ch>
Sender: mduerst@ifi.unizh.ch
Message-ID: <"josef.ifi..364:14.09.96.15.26.28"@ifi.unizh.ch>

Ken'ichi Handa wrote:

>   ** charset
>     I don't like feature name of `charset'. Charset means normally coded
>   character set, but `charset' of Emacs/mule and XEmacs/mule is not
>   coded character set, it is plane of character table. It is very
>   confusing between MIME charset. If possible, I would like to change to
>   other name, like `char-plane'.
>
>No, no.  Mule's charset is surely `coded character set' in the sense
>of ISO 2022 as Mr. Du"rst wrote.

I wrote that Mule's "charset" is NOT a 'coded character set' in the
sense of ISO 2022. But I guess that's what you wanted to say.


>I agree.  But, as I wrote above, RMS insists on putting
>`charset-LANGUAGE-' at heads.  So, I hope XEmacs/mule compromises on
>this point.

"LANGUAGE" looks really strange to me. You can write Greek or Russian
with JIS 208, but it probably still makes some sense to tag it as
"japanese" because this helps a general user to get an idea of what
it is about. But if you write charset-latin-8859-1, it becomes clear
that "SCRIPT" is more appropriate than "LANGUAGE", althoug still not
exacly correct depending on the definition you use.


>     By the way, charset-japanese-jisx0201-roman or japanese-roman are
>   not good name, I think. Because JIS X0201-roman will be renamed to
>   `JIS X0201-Latin' in JIS X0201-1996?. And
>   `charset-japanese-jisx0201-roman' is strange. JIS X0201-Latin is a
>   Latin character set and it is a variant of ISO 646. So
>   `charset-latin-jisx0201' is better, I think.
>
>Hmmm, ok.  Then how to do with charset-japanese-jisx0201-kana?  Keep
>it as is?  How about using the following format:
>
>	charset-LANGUAGE_OR_SCRIPT_NAME-CHARSET_NAME[-ADDITIONAL_INFO]
>
>Then, charset-latin-N are renamed to charset-latin-iso8859-N,
>charset-greek to charset-greek-iso8859-7, etc.

Looks very structured and informative. But maybe users get tired
inputing such long strings?

>     `japanese-2' of XEmacs/mule is not good because JIS plans to be
>   obsolete JIS X0212 and define JIS X0213? to supplement JIS
>   X0208. After JIS X0213? will be defined, Japanese character set will
>   be following planes:
>
>I myself is against this policy of JIS because there already exist
>several implementations of JISX0212.  We can't get rid of this charset.

Definitely. The current JIS committee is thinking that it is smart, and
that it wants to correct "mistakes" of the past. But there has already
been a mistake in 1983, when they exchanged codepoints in JIS 208.
They should have learned by now that character sets should never be
changed or abolished.

>I plan to unify characters of JISX0201 to ASCII except for the
>different two characters (yen and backslash) while reading into Emacs.
>But, I have not yet decided how to implement it.

Why not use Unicode :-)? But anyway, to find out where to change
to a real backslash (because bitwise identity is concerned) and
where to change to a real Yen sign (because character identity
is concerned) is a problem that cannot be fully automated.

>I also plan to unify
>most of JISX0208-1978 characters to JISX0208.

What do you mean by "most"? Which ones would you not unify?


Regards,	Martin.

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 14 21:24:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id VAA24930 for xemacs-beta-people; Mon, 14 Oct 1996 21:24:28 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id VAA24927 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 14 Oct 1996 21:24:26 -0500 (CDT)
Received: from etlpost (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id VAA02345 for <xemacs-beta@xemacs.org>; Mon, 14 Oct 1996 21:24:15 -0500 (CDT)
Received: from etlpom.etl.go.jp by etlpost (8.6.9+2.4W/2.7W)
	id LAA02282; Tue, 15 Oct 1996 11:24:07 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA18505; Tue, 15 Oct 96 11:24:07 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id LAA10223; Tue, 15 Oct 1996 11:25:08 +0900
Date: Tue, 15 Oct 1996 11:25:08 +0900
Message-Id: <199610150225.LAA10223@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: morioka@jaist.ac.jp, mule@etl.go.jp, xemacs-beta@xemacs.org
In-Reply-To: <199610140521.WAA23056@xemacs.eng.sun.com> (message from Martin
	Buchholz on Sun, 13 Oct 1996 22:21:21 -0700)
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   Date: Sun, 13 Oct 1996 22:21:21 -0700
   From: Martin Buchholz <mrb@Eng.Sun.COM>
   ...
   I think I need an education on this.  My requirements come mostly from
   the Sun Japanese Scientific Center, and they were quite vocal about
   wanting to see JISX0201 for all Roman text, in particular because it
   is impossible to get a Solaris ISO8859-1 monospaced font that is
   exactly half the width of the user's JISX0208 font, and they REALLY

??? Both Sun's OpenWindow and XC's X contains fonts 8x16 (iso8859-1),
8x16rk (jisx0201), 12x24 (iso8859-1), 12x24rk (jisx0201).

   If you have a buffer containing Japanese-Roman characters, and you
   type 'A', do you get an ASCII 'A' in the buffer, or a Japanese-Roman
   'A' ?  If an ASCII 'A', won't this look really weird?  To have a
   keypress insert different characters in different buffers would also
   be really weird.

I think all `A' in ISO 646 variants should have the same character
code in Emacs.  So, as I wrote in my previous mail, I'm planning to
map jisx0201-roman characters to ASCII except for backslash and tilda
which are recognized as jisx0201-roman characters and displayed by
jisx0201 font.  When one hit `\' on keyboard, backslash should be
inserted by default.  If one want to enter `yen' by hitting `\', we
can provide such a minor mode.

---
Ken'ichi HANDA
handa@etl.go.jp

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 14 23:26:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA25229 for xemacs-beta-people; Mon, 14 Oct 1996 23:26:32 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA25226 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 14 Oct 1996 23:26:31 -0500 (CDT)
Received: from etlpost (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id XAA02474 for <xemacs-beta@xemacs.org>; Mon, 14 Oct 1996 23:26:25 -0500 (CDT)
Received: from etlpom.etl.go.jp by etlpost (8.6.9+2.4W/2.7W)
	id NAA05922; Tue, 15 Oct 1996 13:26:23 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA25507; Tue, 15 Oct 96 13:26:22 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id NAA10407; Tue, 15 Oct 1996 13:27:22 +0900
Date: Tue, 15 Oct 1996 13:27:22 +0900
Message-Id: <199610150427.NAA10407@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: mule@etl.go.jp, mrb@eng.sun.com, xemacs-beta@xemacs.org
In-Reply-To: <"josef.ifi..364:14.09.96.15.26.28"@ifi.unizh.ch> (message from
	Martin J Duerst on Mon, 14 Oct 1996 16:26:26 +0100 (MET))
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   Date: Mon, 14 Oct 1996 16:26:26 +0100 (MET)
   From: Martin J Duerst <mduerst@ifi.unizh.ch>
   I wrote that Mule's "charset" is NOT a 'coded character set' in the
   sense of ISO 2022. But I guess that's what you wanted to say.

I'm confused by the above sentence.  You wrote in your previous mail:
------------------------------------------------------------
However, according to the definition in
ISO 2022, a "coded character set" is exactly what mule
means with "charset", namely a character set with a one-to-one
allocation of bit combinations. So mule is right, and MIME
------------------------------------------------------------

   >Then, charset-latin-N are renamed to charset-latin-iso8859-N,
   >charset-greek to charset-greek-iso8859-7, etc.

   Looks very structured and informative. But maybe users get tired
   inputing such long strings?

Users don't input charset names, only elisp programmers do, and they
can use combinent tools such as abbrev or dabbrev.

   >I plan to unify characters of JISX0201 to ASCII except for the
   >different two characters (yen and backslash) while reading into Emacs.
   >But, I have not yet decided how to implement it.

   Why not use Unicode :-)?

Actually, we (me and Stallman) have a plan of supporting non-CJK part
of Unicode.  But it will be done after Emacs/mule gets stable.

   But anyway, to find out where to change
   to a real backslash (because bitwise identity is concerned) and
   where to change to a real Yen sign (because character identity
   is concerned) is a problem that cannot be fully automated.

My current plan is as follows:

When reading a file, all characters after ESC ( J (jisx0201-roman
designation) are at first regarded as JISX0201-roman characters.  Then
they are looked up in some mapping table.   If JISX0201-roman `A' has
a mapping to ASCII `A', it is inserted as ASCII `A'.  Since `yen'
character won't be in the table, it is inserted as is.

When writing a file, wheather to map ASCII `A' to JISX0201-roman `A'
or to map `yen' to ASCII backslash, or not to do any mapping depends
on a specified coding system.

As for EUC-Japan, we may have to provide two types, one designates
JISX0201-roman to G0 initially (this conform to JISX0208-1996), and
one designates ASCII to G0.  When reading a file of the former format,
yen (0x5c) is inserted as JISC0201-roman yen, and when reading a file
of the latter format, backslash (0x5c) is inserted as ASCII backslash.
In any case, `A' (0x41) is inserted as ASCII `A'.

   >I also plan to unify
   >most of JISX0208-1978 characters to JISX0208.

   What do you mean by "most"? Which ones would you not unify?

The following characters were changed in JISX0208-1983.

$B03192)3B3I3v4C4R6F7[9\<I?YA(D[EWEnEsFvGhI0KjKyLyMZO6PVTdYx[X[m^9^u`vbh(B
$Bbjc^dFi"i.iZj$k]lMmnpWptrMrt0"1k2*3z6"6m7R849m<H=+>U>_A_AiDOE6E?ExFBG9(B
$BH.H0KKLMMiO9Z9(B

---
Ken'ichi HANDA
handa@etl.go.jp

From xemacs-beta-request@cs.uiuc.edu  Tue Oct 15 03:22:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id DAA29177 for xemacs-beta-people; Tue, 15 Oct 1996 03:22:56 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id DAA29174 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 15 Oct 1996 03:22:54 -0500 (CDT)
Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id DAA02786 for <xemacs-beta@xemacs.org>; Tue, 15 Oct 1996 03:22:21 -0500 (CDT)
Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
          id <00307-0@josef.ifi.unizh.ch>; Tue, 15 Oct 1996 10:18:25 +0100
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)
To: mule@etl.go.jp
Date: Tue, 15 Oct 1996 10:18:23 +0100 (MET)
Cc: mrb@eng.sun.com, xemacs-beta@xemacs.org
In-Reply-To: <199610150427.NAA10407@etlken.etl.go.jp> from "Kenichi Handa" at Oct 15, 96 01:27:22 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: Martin J Duerst <mduerst@ifi.unizh.ch>
Sender: mduerst@ifi.unizh.ch
Message-ID: <"josef.ifi..154:15.09.96.09.18.26"@ifi.unizh.ch>

Hello Ken'ichi,

>   Date: Mon, 14 Oct 1996 16:26:26 +0100 (MET)
>   From: Martin J Duerst <mduerst@ifi.unizh.ch>
>   I wrote that Mule's "charset" is NOT a 'coded character set' in the
>   sense of ISO 2022. But I guess that's what you wanted to say.
>
>I'm confused by the above sentence.  You wrote in your previous mail:
>------------------------------------------------------------
>However, according to the definition in
>ISO 2022, a "coded character set" is exactly what mule
>means with "charset", namely a character set with a one-to-one
>allocation of bit combinations. So mule is right, and MIME
>------------------------------------------------------------

I am very sorry for this confusion. Of course what I wrote
originally is true. When I saw your answer, I somehow
misread Mule for MIME, and got confused.

>   >I plan to unify characters of JISX0201 to ASCII except for the
>   >different two characters (yen and backslash) while reading into Emacs.
>   >But, I have not yet decided how to implement it.
>
>   Why not use Unicode :-)?
>
>Actually, we (me and Stallman) have a plan of supporting non-CJK part
>of Unicode.  But it will be done after Emacs/mule gets stable.

Very nice. It's an old plan, and I hope it will finally become true.

>   But anyway, to find out where to change
>   to a real backslash (because bitwise identity is concerned) and
>   where to change to a real Yen sign (because character identity
>   is concerned) is a problem that cannot be fully automated.
>
>My current plan is as follows:
>
>When reading a file, all characters after ESC ( J (jisx0201-roman
>designation) are at first regarded as JISX0201-roman characters.  Then
>they are looked up in some mapping table.   If JISX0201-roman `A' has
>a mapping to ASCII `A', it is inserted as ASCII `A'.  Since `yen'
>character won't be in the table, it is inserted as is.
>
>When writing a file, wheather to map ASCII `A' to JISX0201-roman `A'
>or to map `yen' to ASCII backslash, or not to do any mapping depends
>on a specified coding system.
>
>As for EUC-Japan, we may have to provide two types, one designates
>JISX0201-roman to G0 initially (this conform to JISX0208-1996), and
>one designates ASCII to G0.  When reading a file of the former format,
>yen (0x5c) is inserted as JISC0201-roman yen, and when reading a file
>of the latter format, backslash (0x5c) is inserted as ASCII backslash.
>In any case, `A' (0x41) is inserted as ASCII `A'.

So this means that you want to map as much as possible to ASCII, but
you leave those characters you cannot map in JIS X 201. This will
help as long as a Yen sign in JIS X 201 is really a Yen sign, but
could cause some problems if it should actually be a backslash
(e.g. in C printf("\n");).

In general, I would suggest that you wait with such unifications
until you move to Unicode, because there you have to reconsider
this again. If you do it now, it will probably mean double work.

Another question: You mention JIS X 0208-1996. Last time I heard
from somebody from the commitee, they said that it would be very
improbably that they would complete in 1996, and that the year
of the new standard would most probably be 1997. If you know any
details, please tell me.

>   >I also plan to unify
>   >most of JISX0208-1978 characters to JISX0208.
>
>   What do you mean by "most"? Which ones would you not unify?
>
>The following characters were changed in JISX0208-1983.
>
>$@03192)3B3I3v4C4R6F7[9\<I?YA(D[EWEnEsFvGhI0KjKyLyMZO6PVTdYx[X[m^9^u`vbh(J
>$@bjc^dFi"i.iZj$k]lMmnpWptrMrt0"1k2*3z6"6m7R849m<H=+>U>_A_AiDOE6E?ExFBG9(J
>$@H.H0KKLMMiO9Z9(J

It's difficult from the list to check back which cases you actually
include. But quite a few of the ones you list have been EXchanged,
so they could be mapped to JIS 1983 without problems. Examples
are $@4R(J and $@k](J, $@mn(J and $@Fv(J, and so on.

Regards,	Martin.

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 17 02:21:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id CAA10246 for xemacs-beta-people; Thu, 17 Oct 1996 02:21:38 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id CAA10243 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 17 Oct 1996 02:21:33 -0500 (CDT)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id CAA06579 for <xemacs-beta@xemacs.org>; Thu, 17 Oct 1996 02:21:22 -0500 (CDT)
Received: from is18e0s01.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id QAA26100; Thu, 17 Oct 1996 16:21:08 +0900 (JST)
Message-Id: <199610170721.QAA26100@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.71, tm-view 7.77
X-Face: %yc?f+O/cVKlH*K(H2X/6-d''suf|"1{S:Y0}_9$t@0G3:5M2:-Ck^[8+4^iSLeGc[Ey[WP
 PF]2M#Q9C'u~[=7TJP72J`PZdWvP=s-'-/LhFneC->=ILc~H#$lf2%hLL5U8?psIp`<[>d&@$Pm%~(
 A'"CJ.zuX@TXh\Ra4,b7M&`f"hexU-a4,#X\]Bfp'JI+MGUDRA%_$&UnWAem4}1R"4%uivgn;xFZ%"
 NS>)eCuFYNHc/:W^:{7H>bGQS],x5z[Cy~C;7j#:8y9q|"~9~UWjE<Vm_;)o<Q4S5NweLc(cl7-suY
 NF|_O*xodbmQavM
X-Emacs: Mule 2.4 =?ISO-2022-JP?B?KBskQjlITVUybBsoQik=?=
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: Kenichi Handa <handa@etlken.etl.go.jp>
cc: mule@etl.go.jp, mrb@eng.sun.com, xemacs-beta@xemacs.org
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region) 
In-reply-to: Your message of "Mon, 14 Oct 1996 22:09:52 JST."
             <199610141309.WAA09619@etlken.etl.go.jp> 
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Thu_Oct_17_16:20:53_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Thu, 17 Oct 1996 16:21:08 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Thu_Oct_17_16:20:53_1996-1
Content-Type: text/plain; charset=US-ASCII

>>>>> In <199610141309.WAA09619@etlken.etl.go.jp>,
>>>>>	Kenichi Handa <handa@etlken.etl.go.jp> writes:

Ken'ichi>    MORIOKA Tomohiko <morioka@jaist.ac.jp>
Ken'ichi>    Date: Sat, 12 Oct 1996 21:41:18 JST

Ken'ichi>    ** charset

Ken'ichi>      I don't like feature name of `charset'. Charset means
Ken'ichi>    normally coded character set, but `charset' of Emacs/mule
Ken'ichi>    and XEmacs/mule is not coded character set, it is plane
Ken'ichi>    of character table. It is very confusing between MIME
Ken'ichi>    charset. If possible, I would like to change to other
Ken'ichi>    name, like `char-plane'.

Ken'ichi> No, no.  Mule's charset is surely `coded character set' in
Ken'ichi> the sense of ISO 2022 as Mr. Du"rst wrote.

  Sorry for my terribly bad description.  I agree ``charset'' of
Emacs/mule and XEmacs/mule is `coded character set' indeed.  I wanted
to write is MIME charset is coded character set too.  Because
character code and coded character set is same feature.  Of course
there are some ``bad'' charset, which there are several code point for
a character, such as iso-2022-jp.  But I think it is historical
problem and ISO 2022 don't want such character code.  Anyway MIME
charset is (or should be) coded character set consists of limited
characters.

  By the way, coding-system of mule is not coded character set, a
encoding mechanism.  However it is used to handle coded character set.
And mule does not support mechanism to select encoding by character
set.  User must select coding system by character set.

  Anyway I think ``charset'' of Emacs/mule is graphic character set.



Ken'ichi>      Anyway please unify name of charsets.

Ken'ichi> I agree.  But, as I wrote above, RMS insists on putting
Ken'ichi> `charset-LANGUAGE-' at heads.  So, I hope XEmacs/mule
Ken'ichi> compromises on this point.

  I hope.

Ken'ichi>      At least, non prefix part should be same.

Ken'ichi> Ok.

  Thanks.

Ken'ichi>      In addition, now there are 2 styles in both
Ken'ichi>    emacsen. First one is like `charset-latin-1' or
Ken'ichi>    `cyrillic'. Second one is like
Ken'ichi>    `charset-chinese-gb2312'. I think it is better to unify
Ken'ichi>    one style.

Ken'ichi> Sure.  I think the latter form is better.

Ken'ichi>      By the way, charset-japanese-jisx0201-roman or
Ken'ichi>    japanese-roman are not good name, I think. Because JIS
Ken'ichi>    X0201-roman will be renamed to `JIS X0201-Latin' in JIS
Ken'ichi>    X0201-1996?. And `charset-japanese-jisx0201-roman' is
Ken'ichi>    strange. JIS X0201-Latin is a Latin character set and it
Ken'ichi>    is a variant of ISO 646. So `charset-latin-jisx0201' is
Ken'ichi>    better, I think.

Ken'ichi> Hmmm, ok.  Then how to do with
Ken'ichi> charset-japanese-jisx0201-kana?  Keep it as is?  How about
Ken'ichi> using the following format:

Ken'ichi> 	charset-LANGUAGE_OR_SCRIPT_NAME-CHARSET_NAME[-ADDITIONAL_INFO]

  I agree for

	charset-SCRIPT_NAME-CHARSET_NAME[-ADDITIONAL_INFO]

  JIS X0201-Katakana is character set for Katakana script so I propose:

	charset-katakana-jisx0201

# I think `japanese' in this sense is not language.  Ideographic
# character of Chinese simplified, Chinese traditional or Taiwanese,
# Japanese and Korean may be different script system like relation
# between Greek, Cyrillic and Latin script.


Ken'ichi> Then, charset-latin-N are renamed to charset-latin-iso8859-N,
Ken'ichi> charset-greek to charset-greek-iso8859-7, etc.

Ken'ichi> Perhaps charset-ascii can be the same instead of renaming to
Ken'ichi> charset-latin-ascii.

  I think it is better.


Ken'ichi>      `japanese-2' of XEmacs/mule is not good because JIS
Ken'ichi>    plans to be obsolete JIS X0212 and define JIS X0213? to
Ken'ichi>    supplement JIS X0208. After JIS X0213? will be defined,
Ken'ichi>    Japanese character set will be following planes:

Ken'ichi> I myself is against this policy of JIS because there already
Ken'ichi> exist several implementations of JISX0212.  We can't get rid
Ken'ichi> of this charset.

  I like JIS X0212-1990. Maybe some characters will be included in
JIS X0213? but some characters will be left.  But maybe some
characters not included in JIS X0208 or X0212 will be coded and it is
designed for Microsoft or Apple world so it might have more users than
JIS X0212.  I think mule should support JIS X0213?.  Of course I don't
want to get rid of JIS X0212.


Ken'ichi>      In addition, I would like to define plane for CCITT
Ken'ichi>    extended GB (ISO-IR 165).

Ken'ichi> Sorry, I don't know about this charset.

  GB 2312-80 + GB 8865.2-88 + about 150 characters.  Final character
is `E'.  Free font by Mr.YASUOKA is available at:

ftp://ftp.jaist.ac.jp/pub/misc/character/fonts/yasuoka/guobiao16.bdf.Z


Ken'ichi>    *** functions
Ken'ichi>      I request `charsetp', `find-charset' and `get-charset' for
Ken'ichi>    Emacs/mule, like:
Ken'ichi>    ...
Ken'ichi>    and I request `charset-name' for Emacs/mule.

Ken'ichi> I agree.

Ken'ichi>      I request to unify `charset-iso-class' of Emacs/mule and
Ken'ichi>    `charset-chars' and `charset-dimension' of XEmacs/mule. I like
Ken'ichi>    XEmacs/mule way, but compatibility is more important.

Ken'ichi> If XEmacs/mule uses `charset-dimension' for returning
Ken'ichi> information of number of characters in a charset (i.e. 94,
Ken'ichi> 96, 94x94, 96x96), yes, I agree that the word `dimension' is
Ken'ichi> better than `iso-class'.

  In XEmacs/mule, function `charset-chars' returns 94 or 96, function
`charset-dimension' returns 1 or 2.

	(charset-chars 'japanese) -> 94
	(charset-dimension 'japanese) -> 2

	(charset-chars 'latin-1) -> 96
	(charset-dimension 'latin-1) -> 1


Ken'ichi> But, for the width (column number occupied on screen), I
Ken'ichi> think charset-width is better.

  I think compatibility is most important.  I hope Emacs and XEmacs
have same functions.  So, I hope Emacs/mule or XEmacs/mule compromise
on this point.

	
Ken'ichi>    ** coding-system
Ken'ichi>      Anyway, we can translate a lot of coding-systems to add
Ken'ichi>    or delete prefix `coding-system-'.  But some
Ken'ichi>    coding-systems are not.

Ken'ichi>    ...
Ken'ichi>      I think major part of coding-system name should be same
Ken'ichi>    as MIME charset is it is registered.

Ken'ichi> Ok, could you give us your total proposal for naming them.

  Following is proposal for changing:

	coding-system-big5	-> coding-system-cn-big5
	coding-system-euc-china	-> coding-system-cn-gb
				   coding-system-cn-gb-isoir165
	coding-system-hz	-> coding-system-hz-gb-2312
	coding-system-sjis	-> coding-system-shift_jis
	coding-system-iso-2022-ss2-7 -> coding-system-iso-2022-jp-2

  big5 is registered too, so it may be better to define both.

  Similarly, gb2312 is registered as Chinese EUC. In addition, RFC
1922 defines cn-gb-<number> for GB variants, such as cn-gb-2312,
cn-gb-12345 (using GB 12345, traditional version of GB 2312) and
cn-gb-isoir165. So Chinese EUC using GB 2312 has three names,
`gb2312', `cn-gb' and `cn-gb-2312'.

  For Korean EUC, coding-system-euc-kr is already existed and there is
non registered name, coding-system-euc-korea.  I don't know it should
be existed or not.  One way may be to define alias like following:

	coding-system-euc-<script>

Registered name of charsets are not systematic.  So systematic named
alias may be comfortable for users.  Charset defined in RFC 1922 is
systematic.  One way is to use this naming rule, like:

	coding-system-<script>-<charset>-<edition>

For example:

	coding-system-ja-jis-1978
	coding-system-ja-jis-1990
	coding-system-ja-sjis-1978
	coding-system-ja-sjis-1990
	coding-system-kr

  By the way, is it impossible to share coding.c of Emacs/mule and
mule-coding.c?


Ken'ichi> Now Emacs/mule uses them not only for file I/O but also for
Ken'ichi> process I/O, so, prefix `file-' is not appropriate.

Ken'ichi> And, I renamed display-coding-system to
Ken'ichi> terminal-coding-system because the latter is more
Ken'ichi> appropriate.  Many peaple tried to change
Ken'ichi> `display-coding-system' in vain when then can't see correct
Ken'ichi> characters on Emacs running under X.  In addition, now
Ken'ichi> terminal-coding-system and keyboard-coding-system are not
Ken'ichi> variables but functions returning coding systems.  This
Ken'ichi> change avoids frequent check of coding system specified by
Ken'ichi> variable while displaying on terminal.

  I think `terminal-coding-system' is good name.  And basically, news
coding-system API is good.


Ken'ichi>    XEmacs/mule should sync with Emacs/mule. In particular,
Ken'ichi>    coding-system-alist feature and
Ken'ichi>    `coding-system-for-{read|write}' are very important.

Ken'ichi> We are now discussing on mule-jp@etl.go.jp about the spec of
Ken'ichi> coding-system-alist.  If XEmacs/mule also implements them, I
Ken'ichi> think we should wait for the result of the discussion.

  I know. But I think it is better if XEmacs people join to the
discussion.


Ken'ichi>    ** language environment, locale

Ken'ichi> I plan to unify characters of JISX0201 to ASCII except for
Ken'ichi> the different two characters (yen and backslash) while
Ken'ichi> reading into Emacs. But, I have not yet decided how to
Ken'ichi> implement it.  I also plan to unify most of JISX0208-1978
Ken'ichi> characters to JISX0208.

  I hope it will be implemented.

  But I think current implementation `alternate-charset-table' is
better than MULE 2.3.  So it may be a solution to implement in
XEmacs/mule.


  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
--- I protest Chinese nuclear testing --------------------------------
----------------- and virtual testing of United States and France. ---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key
--pgp-sign-Multipart_Thu_Oct_17_16:20:53_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMmXeXxnuUGV7wuH5AQEgoAP+P3q1yQrTG00Eq6FELPihzonPLuQDQO+m
8ShL81PJA9Wr0w7sAJQsmU8tsh7urPPqip0lVxKMwefBghw7kEmQJoazkYy6morp
GG+KfhGezYfsBs0zuPq2/MYGZvEdl+/FtiQCGU427mdxQL6eCob+ryY9ef0GkJvB
QC4NugH2cN4=
=1R6u
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Oct_17_16:20:53_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 17 09:31:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id JAA14985 for xemacs-beta-people; Thu, 17 Oct 1996 09:31:30 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA14982 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 17 Oct 1996 09:31:29 -0500 (CDT)
Received: from wine.mickey.ai.kyutech.ac.jp (wine.mickey.ai.kyutech.ac.jp [131.206.21.99]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA07876 for <xemacs-beta@xemacs.org>; Thu, 17 Oct 1996 09:31:24 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by wine.mickey.ai.kyutech.ac.jp (8.8.0/8.7.3) with ESMTP id OAA00765; Thu, 17 Oct 1996 14:30:59 GMT
To: mule@etl.go.jp
Cc: xemacs-beta@xemacs.org
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region) 
In-Reply-To: Your message of "Thu, 17 Oct 1996 16:21:08 JST"
References: <199610170721.QAA26100@mikan.jaist.ac.jp>
Mime-Version: 1.0
From: Murata Shuuichirou <mrt@mickey.ai.kyutech.ac.jp>
X-Mailer: Mew version 1.06 on Emacs 19.33.2, Mule 2.4
Content-Type: Text/Plain; charset=us-ascii
Message-Id: <19961017143058I/mrt@mickey.ai.kyutech.ac.jp>
Date: Thu, 17 Oct 1996 14:30:58 GMT
X-Dispatcher: impost version 0.91 (Jun 5,1996)
Lines: 38

In message <199610170721.QAA26100@mikan.jaist.ac.jp>,
 MORIOKA Tomohiko <morioka@jaist.ac.jp> wrote:
> Ken'ichi>    XEmacs/mule should sync with Emacs/mule. In particular,
> Ken'ichi>    coding-system-alist feature and
> Ken'ichi>    `coding-system-for-{read|write}' are very important.
> 
> Ken'ichi> We are now discussing on mule-jp@etl.go.jp about the spec of
> Ken'ichi> coding-system-alist.  If XEmacs/mule also implements them, I
> Ken'ichi> think we should wait for the result of the discussion.
> 
>   I know. But I think it is better if XEmacs people join to the
> discussion.

I think so, too.

Now, I think coding-system-alist should be as follows:

*Alist of elements
(REGEXP OPERATION CODING-SYSTEM-FOR-READ [CODING-SYSTM-FOR-WRITE
[CODING-SYSTEM-FOR-PROCESS-ARGUMENTS]]).

If a target of I/O primitive operation OPERATION matches REGEXP,
CODING-SYSTEM is used for the OPERATION.

TARGET varies depending on OPERATION as follows:
	OPERATION		TARGET
	---------		------
	file			name of a file to be inserted or to be
written
	process			name of a program to be called
	network			name of a service for the network stream
--

file: write-region, insert-file-contents
process: start-process, call-process, call-process-region
network: open-network-stream
--------
Murata Shuuichirou

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 17 14:59:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA16287 for xemacs-beta-people; Thu, 17 Oct 1996 14:59:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA16284 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 17 Oct 1996 14:59:22 -0500 (CDT)
Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id OAA11266 for <xemacs-beta@xemacs.org>; Thu, 17 Oct 1996 14:59:20 -0500 (CDT)
Received: from calico.cis.ohio-state.edu (calico.cis.ohio-state.edu [164.107.142.11]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id PAA08683; Thu, 17 Oct 1996 15:39:07 -0400
Received: (ware@localhost) by calico.cis.ohio-state.edu (8.7.5/8.6.4) id PAA11633; Thu, 17 Oct 1996 15:39:06 -0400 (EDT)
To: xemacs-beta@xemacs.org
Subject: gnuattach problems on HP-UX
From: Pete Ware <ware@cis.ohio-state.edu>
Date: 17 Oct 1996 15:39:04 -0400
Message-ID: <vwmenixwfc7.fsf@calico.cis.ohio-state.edu>
Lines: 11
X-Mailer: Gnus v5.2.40/XEmacs 19.15

HP-UX calico A.09.05 A 9000/715 2003622816 two-user license
XEmacs 19.15 [Lucid] (hppa1.1-hp-hpux9.05) of Thu Oct 17 1996 on guts

"gnuattach" quickly gets in a state where '^c' generates an interrupt
sent to gnuattach but other keys continue going to XEmacs.  It also
doesn't appear to handle dsusp (delayed suspend) which for some
unimaginable reason, gets set to to '^y'

Anyone else seeing similar problems?

--pete

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 17 16:16:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA16625 for xemacs-beta-people; Thu, 17 Oct 1996 16:16:16 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA16622 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 17 Oct 1996 16:16:15 -0500 (CDT)
Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id QAA11847 for <xemacs-beta@xemacs.org>; Thu, 17 Oct 1996 16:16:12 -0500 (CDT)
Received: from calico.cis.ohio-state.edu (calico.cis.ohio-state.edu [164.107.142.11]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id QAA10774; Thu, 17 Oct 1996 16:33:25 -0400
Received: (ware@localhost) by calico.cis.ohio-state.edu (8.7.5/8.6.4) id QAA20649; Thu, 17 Oct 1996 16:33:24 -0400 (EDT)
To: xemacs-beta@xemacs.org
Subject: Scrolling on ttys
From: Pete Ware <ware@cis.ohio-state.edu>
Date: 17 Oct 1996 16:33:20 -0400
Message-ID: <vwmd8yhwctr.fsf@calico.cis.ohio-state.edu>
Lines: 7
X-Mailer: Gnus v5.2.40/XEmacs 19.15

A couple months ago Ben (I think) posted some ideas on what was needed
to get scrolling to work on ttys.  Anybody save that and could you
forward it to me?

Also, could someone re-post the goals for 19.15?

--pete

From xemacs-beta-request@cs.uiuc.edu  Fri Oct 18 05:33:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id FAA22667 for xemacs-beta-people; Fri, 18 Oct 1996 05:33:23 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id FAA22664 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 18 Oct 1996 05:33:22 -0500 (CDT)
Received: from etlpost (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id FAA12908 for <xemacs-beta@xemacs.org>; Fri, 18 Oct 1996 05:33:17 -0500 (CDT)
Received: from etlpom.etl.go.jp by etlpost (8.6.9+2.4W/2.7W)
	id TAA20628; Fri, 18 Oct 1996 19:33:17 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA13325; Fri, 18 Oct 96 19:33:16 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id TAA22159; Fri, 18 Oct 1996 19:34:17 +0900
Date: Fri, 18 Oct 1996 19:34:17 +0900
Message-Id: <199610181034.TAA22159@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: xemacs-beta@xemacs.org
In-Reply-To: <19961017143058I/mrt@mickey.ai.kyutech.ac.jp> (message from
	Murata Shuuichirou on Thu, 17 Oct 1996 14:30:58 GMT)
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   From: Murata Shuuichirou <mrt@mickey.ai.kyutech.ac.jp>
   Date: Thu, 17 Oct 1996 14:30:58 GMT

   Now, I think coding-system-alist should be as follows:

   *Alist of elements
   (REGEXP OPERATION CODING-SYSTEM-FOR-READ [CODING-SYSTM-FOR-WRITE
   [CODING-SYSTEM-FOR-PROCESS-ARGUMENTS]]).

I'v just implemented it as follows.  Please consider this
specification.

---- coding-system-alist -----------------------------------------
coding-system-alist's value is (("\\.elc$" file no-conversion no-conversion) ("" file automatic-conversion))

Documentation:
Alist to decide a coding system for a specific I/O operation.
Format of elements is (REGEXP TARGET-TYPE . CODING-SYSTEM-LIST),
 where
REGEXP is a regular expression matching a target of I/O operation,
TARGET-TYPE is a symbol `file', `process', or `network',
CODING-SYSTEM-LIST is a list of coding systems READ-CODING-SYSTEM,
WRITE-CODING-SYSTEM, and GIVE-ARGS-CODING-SYSTEM.

READ-CODING is for read operation, WRITE-CODING-SYSTEM is for write
operation, GIVE-ARGS-CODING-SYSTEM is for giving arguments to a
process.  The last two may be omited.

If TARGET-TYPE is `file', REGEXP should match a file name.
If TARGET-TYPE is `process', REGEXP should match a program name to be
called (synchronously) or started (asynchronously) as a process.
If TARGET-TYPE is `network', REGEXP should match a service name
to connect to.  In this case only, REGEXP may be a number for the case
that a port number is specified for an operation.

---- find-coding-system ----------------------------------------
find-coding-system: a built-in function.

Return TARGET's coding system for I/O operation.
TARGET-TYPE specifies type of TARGET: `file', `process', or `network'.
OPERATION-TYPE speficies type of operation: `read', `write', or `give-args'.
ARGS is a list of arguments supplied for the I/O operation.

If TARGET-TYPE is `file', TARGET should be a file name.
If TARGET-TYPE is `process', TARGET should be a program name.
If TARGET-TYPE is `network', TARGET should be a network service name, or
a port number to connect to.
OPERATION-TYPE `give-args' is valid iff TARGET-TYPE is `process'.

A coding system entry corresponding to TARGET, TARGET-TYPE, and
OPERATION-TYPE in the alist `coding-system-alist' is returned.
However, if a found entry is not a valid coding system, but is a
function symbol, return value of the function called with the same
arguments is returned.

See the documentation of `coding-system-alist' for more detail.

(find-coding-system TARGET TARGET-TYPE OPERATION-TYPE ARGS)

---- set-coding-system-alist ----------------------------------------
set-coding-system-alist: a compiled Lisp function.
(set-coding-system-alist REGEXP TARGET-TYPE &rest CODING-SYSTEMS)

Set REGEXP, TARGET-TYPE, and the remaining args in `coding-system-alist'.
REGEXP is a regular expression string matching a target of I/O operation,
TARGET-TYPE is a symbol `file', `process', or `network',
The remaining args are coding systems READ-CODING-SYSTEM,
WRITE-CODING-SYSTEM, and GIVE-ARGS-CODING-SYSTEM.  The last two are
optional.
See the documentation of `coding-system-alist' for the meanings of
the arguments.

------------------------------------------------------------

---
Ken'ichi HANDA
handa@etl.go.jp

From xemacs-beta-request@cs.uiuc.edu  Fri Oct 18 06:19:24 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id GAA22766 for xemacs-beta-people; Fri, 18 Oct 1996 06:19:24 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id GAA22763 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 18 Oct 1996 06:19:22 -0500 (CDT)
Received: from etlpost (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id GAA12946 for <xemacs-beta@xemacs.org>; Fri, 18 Oct 1996 06:19:18 -0500 (CDT)
Received: from etlpom.etl.go.jp by etlpost (8.6.9+2.4W/2.7W)
	id UAA21513; Fri, 18 Oct 1996 20:19:18 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA14893; Fri, 18 Oct 96 20:19:18 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id UAA22219; Fri, 18 Oct 1996 20:20:18 +0900
Date: Fri, 18 Oct 1996 20:20:18 +0900
Message-Id: <199610181120.UAA22219@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: mrb@eng.sun.com, xemacs-beta@xemacs.org
In-Reply-To: <199610170721.QAA26100@mikan.jaist.ac.jp> (message from
	=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko on
	Thu, 17 Oct 1996 16:21:08 JST)
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
   Date: Thu, 17 Oct 1996 16:21:08 JST

     By the way, coding-system of mule is not coded character set, a
   encoding mechanism.  However it is used to handle coded character set.
   And mule does not support mechanism to select encoding by character
   set.  User must select coding system by character set.

I don't understand what you mean.  Yes, Mule's coding-system is an
encoding mechanism.  It defines how characters of each character set
should be encoded.  Some coding-systems can encode any character sets
supported by Mule.  Some can encode only one or two character sets.
But, I can't understand the meaning of "selecting coding system by
character set".

     I agree for
	   charset-SCRIPT_NAME-CHARSET_NAME[-ADDITIONAL_INFO]
     JIS X0201-Katakana is character set for Katakana script so I propose:
	   charset-katakana-jisx0201

Ok.  Let's follow this convention.

     GB 2312-80 + GB 8865.2-88 + about 150 characters.  Final character
   is `E'.  Free font by Mr.YASUOKA is available at:
   ftp://ftp.jaist.ac.jp/pub/misc/character/fonts/yasuoka/guobiao16.bdf.Z

Ah!  I recalled it.  I want to support it also by mapping
GB2312-80 part to GB2312-80 if they have the same code point.

     In XEmacs/mule, function `charset-chars' returns 94 or 96, function
   `charset-dimension' returns 1 or 2.
	   (charset-chars 'japanese) -> 94
	   (charset-dimension 'japanese) -> 2
	   (charset-chars 'latin-1) -> 96
	   (charset-dimension 'latin-1) -> 1

I see.  Sound resonable.  Ok, let's implement them.

   Ken'ichi> But, for the width (column number occupied on screen), I
   Ken'ichi> think charset-width is better.

     I think compatibility is most important.  I hope Emacs and XEmacs
   have same functions.  So, I hope Emacs/mule or XEmacs/mule compromise
   on this point.

Yes, but you wrote:
   Emacs/mule			XEmacs/mule
   ----------------------------------------------------------------------
   ...
   charset-width		charset-chars

So, I was confused.  What's the name of a function in XEmacs/mule
corresponding to Emacs/mule's charset-width?  Mule 2.3 uses char-width
for both character and charset.  Emacs/mule has both of charset-width
and char-width.

     Following is proposal for changing:

	   coding-system-big5	-> coding-system-cn-big5
	   coding-system-euc-china	-> coding-system-cn-gb
				      coding-system-cn-gb-isoir165
	   coding-system-hz	-> coding-system-hz-gb-2312
	   coding-system-sjis	-> coding-system-shift_jis
	   coding-system-iso-2022-ss2-7 -> coding-system-iso-2022-jp-2

     big5 is registered too, so it may be better to define both.

Ok.  And I also keep coding-system-sjis as an alias because Mule 2.3
also adopted *sjis*.

   Registered name of charsets are not systematic.  So systematic named
   alias may be comfortable for users.  Charset defined in RFC 1922 is
   systematic.  One way is to use this naming rule, like:
	   coding-system-<script>-<charset>-<edition>
   For example:
	   coding-system-ja-jis-1978
	   coding-system-ja-jis-1990
	   coding-system-ja-sjis-1978
	   coding-system-ja-sjis-1990
	   coding-system-kr

Why `jis' is not `jisx0208', `kr' is not `kr-ksc5601'?

     By the way, is it impossible to share coding.c of Emacs/mule and
   mule-coding.c?

Perhaps, most part can be shared, but not all.

     I know. But I think it is better if XEmacs people join to the
   discussion.

Please consider the specification in my previous mail.

     But I think current implementation `alternate-charset-table' is
   better than MULE 2.3.  So it may be a solution to implement in
   XEmacs/mule.

In the near future, I want to change it to char-table, Emacs's new
Lisp Object.

---
Ken'ichi HANDA
handa@etl.go.jp

From xemacs-beta-request@cs.uiuc.edu  Fri Oct 18 06:51:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id GAA22843 for xemacs-beta-people; Fri, 18 Oct 1996 06:51:20 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id GAA22840 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 18 Oct 1996 06:51:19 -0500 (CDT)
Received: from etlpost (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id GAA12975 for <xemacs-beta@xemacs.org>; Fri, 18 Oct 1996 06:51:14 -0500 (CDT)
Received: from etlpom.etl.go.jp by etlpost (8.6.9+2.4W/2.7W)
	id UAA22234; Fri, 18 Oct 1996 20:51:15 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA15704; Fri, 18 Oct 96 20:51:14 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id UAA22268; Fri, 18 Oct 1996 20:52:16 +0900
Date: Fri, 18 Oct 1996 20:52:16 +0900
Message-Id: <199610181152.UAA22268@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: mrb@eng.sun.com, xemacs-beta@xemacs.org
In-Reply-To: <"josef.ifi..154:15.09.96.09.18.26"@ifi.unizh.ch> (message from
	Martin J Duerst on Tue, 15 Oct 1996 10:18:23 +0100 (MET))
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   Date: Tue, 15 Oct 1996 10:18:23 +0100 (MET)
   From: Martin J Duerst <mduerst@ifi.unizh.ch>
   ...
   So this means that you want to map as much as possible to ASCII, but
   you leave those characters you cannot map in JIS X 201. This will
   help as long as a Yen sign in JIS X 201 is really a Yen sign, but
   could cause some problems if it should actually be a backslash
   (e.g. in C printf("\n");).

If one really want to read-in JISX0201-roman as ASCSII, I'll implement
a coding system to do that.

   In general, I would suggest that you wait with such unifications
   until you move to Unicode, because there you have to reconsider
   this again. If you do it now, it will probably mean double work.

I won't do that just now, but perhaps after Emacs/mule is officially
released.

   Another question: You mention JIS X 0208-1996. Last time I heard
   from somebody from the commitee, they said that it would be very
   improbably that they would complete in 1996, and that the year
   of the new standard would most probably be 1997. If you know any
   details, please tell me.

I don't know, but I also heard the same rumor.

   >   >I also plan to unify
   >   >most of JISX0208-1978 characters to JISX0208.
   >
   >   What do you mean by "most"? Which ones would you not unify?
   >
   >The following characters were changed in JISX0208-1983.
   >
   >$B03192)3B3I3v4C4R6F7[9\<I?YA(D[EWEnEsFvGhI0KjKyLyMZO6PVTdYx[X[m^9^u`vbh(B
   >$Bbjc^dFi"i.iZj$k]lMmnpWptrMrt0"1k2*3z6"6m7R849m<H=+>U>_A_AiDOE6E?ExFBG9(B
   >$BH.H0KKLMMiO9Z9(B

   It's difficult from the list to check back which cases you actually
   include. But quite a few of the ones you list have been EXchanged,
   so they could be mapped to JIS 1983 without problems. Examples
   are $B4R(B and $Bk](B, $Bmn(B and $BFv(B, and so on.

Some characters in JISX0208-1978 (or more precisely, JIS C 6226-1978)
is not int JISX0208-1983.  You can check it (but not easily) by the
fonts:
ftp://ginkaku.kudpc.kyoto-u.ac.jp/fonts/ 
    276515 Aug 23 15:26  jiskan16-1978.bdf.Z
    278194 Aug 23 15:26  jiskan16-1983.bdf.Z
And, it is worth looking into the file cccii64.bdf.Z in the same
directory.
  19970517 Jan 11  1996  cccii64.bdf.Z
  ^^^^^^^^
"http://www.kudpc.kyoto-u.ac.jp/~yasuoka/CJK.html" is a very
interesting page.

---
Ken'ichi HANDA
handa@etl.go.jp

From xemacs-beta-request@cs.uiuc.edu  Fri Oct 18 07:34:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id HAA22971 for xemacs-beta-people; Fri, 18 Oct 1996 07:34:52 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA22968 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 18 Oct 1996 07:34:51 -0500 (CDT)
Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id HAA13008 for <xemacs-beta@xemacs.org>; Fri, 18 Oct 1996 07:34:13 -0500 (CDT)
Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
          id <00975-0@josef.ifi.unizh.ch>; Fri, 18 Oct 1996 14:24:32 +0100
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)
To: mule@etl.go.jp
Date: Fri, 18 Oct 1996 14:24:32 +0100 (MET)
Cc: mrb@eng.sun.com, xemacs-beta@xemacs.org
In-Reply-To: <199610181152.UAA22268@etlken.etl.go.jp> from "Kenichi Handa" at Oct 18, 96 08:52:16 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: Martin J Duerst <mduerst@ifi.unizh.ch>
Sender: mduerst@ifi.unizh.ch
Message-ID: <"josef.ifi..838:18.09.96.13.24.33"@ifi.unizh.ch>


Ken'ichi Handa wrote:

>   Date: Tue, 15 Oct 1996 10:18:23 +0100 (MET)
>   From: Martin J Duerst <mduerst@ifi.unizh.ch>
>   ...
>   So this means that you want to map as much as possible to ASCII, but
>   you leave those characters you cannot map in JIS X 201. This will
>   help as long as a Yen sign in JIS X 201 is really a Yen sign, but
>   could cause some problems if it should actually be a backslash
>   (e.g. in C printf("\n");).
>
>If one really want to read-in JISX0201-roman as ASCSII, I'll implement
>a coding system to do that.

Yes, that would be easy. But what do you do about
	printf("It costs %d\\.\n");
The first two backslashes should become a Yen sign, and the last
backslash a real backslash.

>   >   >I also plan to unify
>   >   >most of JISX0208-1978 characters to JISX0208.
>   >
>   >   What do you mean by "most"? Which ones would you not unify?
>   >
>   >The following characters were changed in JISX0208-1983.
>   >
>   >$@03192)3B3I3v4C4R6F7[9\<I?YA(D[EWEnEsFvGhI0KjKyLyMZO6PVTdYx[X[m^9^u`vbh(J
>   >$@bjc^dFi"i.iZj$k]lMmnpWptrMrt0"1k2*3z6"6m7R849m<H=+>U>_A_AiDOE6E?ExFBG9(J
>   >$@H.H0KKLMMiO9Z9(J
>
>   It's difficult from the list to check back which cases you actually
>   include. But quite a few of the ones you list have been EXchanged,
>   so they could be mapped to JIS 1983 without problems. Examples
>   are $@4R(J and $@k](J, $@mn(J and $@Fv(J, and so on.
>
>Some characters in JISX0208-1978 (or more precisely, JIS C 6226-1978)
>is not int JISX0208-1983.  You can check it (but not easily) by the
>fonts:
>ftp://ginkaku.kudpc.kyoto-u.ac.jp/fonts/ 
>    276515 Aug 23 15:26  jiskan16-1978.bdf.Z
>    278194 Aug 23 15:26  jiskan16-1983.bdf.Z
>And, it is worth looking into the file cccii64.bdf.Z in the same
>directory.
>  19970517 Jan 11  1996  cccii64.bdf.Z
>  ^^^^^^^^
>"http://www.kudpc.kyoto-u.ac.jp/~yasuoka/CJK.html" is a very
>interesting page.

I know Koichi Yasuoka personally, and he indeed has some very
interesting data. But for this question, it's easier to consult
Ken Lunde's book, Understanding Japanese Information Processing,
by O'Reilly. It has also been translated into Japanese.
The changes are very well documented in Appendix J.
In particular, it lists all the exchanged characters. Of the list
of characters for which the glyph shape printed in the standard
changed, most of them are minor differences that don't show up in
your list. Most others turned up again in JIS 212. An example
is the traditional form of $@2*(J.

Regards,	Martin.

From xemacs-beta-request@cs.uiuc.edu  Sat Oct 19 18:52:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA01495 for xemacs-beta-people; Sat, 19 Oct 1996 18:52:48 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA01492 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 19 Oct 1996 18:52:46 -0500 (CDT)
Received: from mail.ba2.so-net.or.jp (mail.ba2.so-net.or.jp [202.238.95.33]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA15666 for <xemacs-beta@xemacs.org>; Sat, 19 Oct 1996 18:52:41 -0500 (CDT)
Received: from pavlov.enami.ba2.so-net.or.jp (ppp58a0.pppp.ap.so-net.or.jp [202.238.88.160]) by mail.ba2.so-net.or.jp (8.7.5/3.4W396052919) with ESMTP id IAA26146; Sun, 20 Oct 1996 08:52:40 +0900
Received: from plants-doll.enami.ba2.so-net.or.jp (plants-doll.enami.ba2.so-net.or.jp [192.168.1.7]) by pavlov.enami.ba2.so-net.or.jp (8.7.5/3.4W4-pavlov) with ESMTP id IAA24367; Sun, 20 Oct 1996 08:40:24 +0900 (JST)
Received: (from enami@localhost) by plants-doll.enami.ba2.so-net.or.jp (8.7.5/3.4W4-client) id IAA20795; Sun, 20 Oct 1996 08:40:29 +0900 (JST)
Sender: enami@enami.ba2.so-net.or.jp
To: mule@etl.go.jp
Cc: xemacs-beta@xemacs.org
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)
References: <199610181034.TAA22159@etlken.etl.go.jp>
From: enami tsugutomo <enami@ba2.so-net.or.jp>
Date: 20 Oct 1996 08:40:28 +0900
In-Reply-To: Kenichi Handa's message of Fri, 18 Oct 1996 19:34:17 +0900
Message-ID: <87lod2r09f.fsf@plants-doll.enami.ba2.so-net.or.jp>
Lines: 15
X-Mailer: Red Gnus v0.52/Emacs 19.34

Kenichi Handa <handa@etlken.etl.go.jp> writes:

> Alist to decide a coding system for a specific I/O operation.
> Format of elements is (REGEXP TARGET-TYPE . CODING-SYSTEM-LIST),
>  where
> REGEXP is a regular expression matching a target of I/O operation,
> TARGET-TYPE is a symbol `file', `process', or `network',
> CODING-SYSTEM-LIST is a list of coding systems READ-CODING-SYSTEM,
> WRITE-CODING-SYSTEM, and GIVE-ARGS-CODING-SYSTEM.

I like CODING-SYSTEM-LIST to be CODING-SYSTEM-LIST-OR-FUNCTION as
previous version (i.e., allow it to be a function).  It may leave user
to specify coding-system dynamically or more preciously.

enami.

From xemacs-beta-request@cs.uiuc.edu  Sun Oct 20 22:31:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id WAA08287 for xemacs-beta-people; Sun, 20 Oct 1996 22:31:27 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id WAA08284 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 20 Oct 1996 22:31:22 -0500 (CDT)
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id WAA18012 for <xemacs-beta@xemacs.org>; Sun, 20 Oct 1996 22:31:20 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.7.6/8.7.3) with ESMTP id UAA05832 for <xemacs-beta@xemacs.org>; Sun, 20 Oct 1996 20:30:23 -0700 (PDT)
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id UAA27472 for <xemacs-beta@xemacs.org>; Sun, 20 Oct 1996 20:30:13 -0700
Date: Sun, 20 Oct 1996 20:30:13 -0700
Message-Id: <199610210330.UAA27472@shellx.best.com>
From: Ben Wing <wing@666.com>
To: mule@etl.go.jp, Kenichi Handa <handa@etlken.etl.go.jp>
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)
Cc: xemacs-beta@xemacs.org, mule@etl.go.jp, mrb@eng.sun.com

>
>Thank you very very much for the detailed survey on the differences
>among various versions of Emacs(Mule), and I'm sorry for the current
>confusion.  Most of the changes of symbol names are requested by RMS
>(Mr. Stallman) (e.g. prepending "charset-" and "coding-system-").
>Especially, he haste putting `*' in front of coding system names.

I agree that there should not be any asterisks -- it is inconsistent
with standard Emacs Lisp conventions.  (In fact, there are/were a
great number of such inconsistencies in the namings of symbols in
traditional MULE, which accounts for many of the naming changes that
I made in XEmacs/mule.)

In traditional MULE, the charsets and coding systems were also stored
in variables, which might explain why Stallman insisted on the prefixes
for the symbols.  XEmacs/mule does not have any such thing, which explains
why the prefixes are not necessary.  I think it's a bad idea to have
variables containing coding systems and charsets.

>Mr. Wing told me that even if XEmacs/mule's approach was untolerably
>slow, it could be aboided by implementing some kind of cashing
>mechanism.  Does the current XEmacs/mule have cash for buffer
>positioning?  ... anyway, this is not the current discussion point ...

Yes.

>If XEmacs/mule uses `charset-dimension' for returning information of
>number of characters in a charset (i.e. 94, 96, 94x94, 96x96), yes, I
>agree that the word `dimension' is better than `iso-class'.
>
>But, for the width (column number occupied on screen), I think
>charset-width is better.

How about charset-columns?  "width" is too generic a term -- it could
refer to pixel width, for example.

As for the naming of the individual charsets and coding systems, I
do not much care -- whatever you think is best I will accept.

>Ok, could you give us your total proposal for naming them.
>
>   *** functions and variables
>   [Functions]
>
>   Emacs/mule				XEmacs/mule
>   ----------------------------------------------------------------------
>					   coding-system-eol-cr
>					   coding-system-eol-crlf
>					   coding-system-eol-lf
>					   coding-system-no-ascii-cntl
>					   coding-system-no-ascii-eol
>					   coding-system-no-iso6429
>					   coding-system-property
>					   coding-system-seven
>					   coding-system-short
>					   coding-system-use-japanese-roman
>
>It seems that these are for checking flags of each coding system.  Do
>you think it is really worth implementing them?

These are the same flags that exist in traditional MULE; I just cleaned
them up somewhat.

>   [Variables]
>   Emacs/mule				XEmacs/mule
>   ----------------------------------------------------------------------
>   buffer-file-coding-system		file-coding-system
>
>This is also suggested by RMS.

This is ok with me.

>   coding-system-for-read			file-coding-system-for-read
>   coding-system-for-write			file-coding-system
>
>Now Emacs/mule uses them not only for file I/O but also for process
>I/O, so, prefix `file-' is not appropriate.
>
>And, I renamed display-coding-system to terminal-coding-system because
>the latter is more appropriate.  Many peaple tried to change
>`display-coding-system' in vain when then can't see correct characters
>on Emacs running under X.  In addition, now terminal-coding-system and
>keyboard-coding-system are not variables but functions returning
>coding systems.  This change avoids frequent check of coding system
>specified by variable while displaying on terminal.
>
>   XEmacs/mule should sync with Emacs/mule. In particular,
>   coding-system-alist feature and `coding-system-for-{read|write}' are
>   very important.

These changes all sound fine with me although I won't be implementing
them because I'm not working on XEmacs/mule anymore -- Martin will have
to implement them.
 
ben
--
(This message composed by voice)

From xemacs-beta-request@cs.uiuc.edu  Sun Oct 20 23:27:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA08379 for xemacs-beta-people; Sun, 20 Oct 1996 23:27:53 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA08376 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 20 Oct 1996 23:27:52 -0500 (CDT)
Received: from etlpost (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id XAA18084 for <xemacs-beta@xemacs.org>; Sun, 20 Oct 1996 23:27:48 -0500 (CDT)
Received: from etlpom.etl.go.jp by etlpost (8.6.9+2.4W/2.7W)
	id NAA24087; Mon, 21 Oct 1996 13:27:44 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA26924; Mon, 21 Oct 96 13:27:43 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id NAA24093; Mon, 21 Oct 1996 13:28:44 +0900
Date: Mon, 21 Oct 1996 13:28:44 +0900
Message-Id: <199610210428.NAA24093@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: xemacs-beta@xemacs.org, mrb@eng.sun.com
In-Reply-To: <199610210330.UAA27463@shellx.best.com> (message from Ben Wing on
	Sun, 20 Oct 1996 20:30:12 -0700)
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   Date: Sun, 20 Oct 1996 20:30:12 -0700
   From: Ben Wing <wing@666.com>

   In traditional MULE, the charsets and coding systems were also stored
   in variables, which might explain why Stallman insisted on the prefixes
   for the symbols.

Perhaps.

   XEmacs/mule does not have any such thing, which explains
   why the prefixes are not necessary.  I think it's a bad idea to have
   variables containing coding systems and charsets.

Coding systems are symbols both in Mule and Emacs/mule.  Mule just
binded those symbols with corresponding variables.  Emacs/mule doesn't
give these binding.

As for a charset, yes, I agree that making it a symbol is better.
But, I fear the slow down of Emacs Lisp codes frequenty accessing
those symbols.

If XEmacs/mule developpers don't like preceding "charset-", how about
providing variables `charset-XXXX' which are binded to symbols `XXXX'
in the compatibility package, which, at least, makes Emacs/mule
oriented code to run under XEmacs/mule.

   How about charset-columns?  "width" is too generic a term -- it could
   refer to pixel width, for example.

Many Emacs Lisp functions and variables already adopted the term
"width" for columns: i.e. tab-width, frame-width, screen-width.  To
refer pixel width, Emacs uses the term "XXX-pixel-width":
i.e. frame-pixel-width, x-display-pixel-width.  There surely exist
several functions/variables/symbols which uses just "width" for
"pixels", but, it seems that they are a few: i.e. border-width,
frame-char-width.

Since it is difficult to change all "width" refereing columuns to
"columns", I think we had better keep using "width" for columns, and
change the small number of exceptions as listed above to
"XXX-pixel-width".

---
Ken'ichi HANDA
handa@etl.go.jp

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 21 03:10:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id DAA12166 for xemacs-beta-people; Mon, 21 Oct 1996 03:10:42 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id DAA12163 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 21 Oct 1996 03:10:40 -0500 (CDT)
Received: from etlpost (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id DAA18283 for <xemacs-beta@xemacs.org>; Mon, 21 Oct 1996 03:10:36 -0500 (CDT)
Received: from etlpom.etl.go.jp by etlpost (8.6.9+2.4W/2.7W)
	id RAA01495; Mon, 21 Oct 1996 17:10:34 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA12254; Mon, 21 Oct 96 17:10:30 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id RAA24565; Mon, 21 Oct 1996 17:11:35 +0900
Date: Mon, 21 Oct 1996 17:11:35 +0900
Message-Id: <199610210811.RAA24565@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: mule@etl.go.jp, xemacs-beta@xemacs.org
In-Reply-To: <87lod2r09f.fsf@plants-doll.enami.ba2.so-net.or.jp> (message from
	enami tsugutomo on 20 Oct 1996 08:40:28 +0900)
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   From: enami tsugutomo <enami@ba2.so-net.or.jp>
   Date: 20 Oct 1996 08:40:28 +0900
   I like CODING-SYSTEM-LIST to be CODING-SYSTEM-LIST-OR-FUNCTION as
   previous version (i.e., allow it to be a function).  It may leave user
   to specify coding-system dynamically or more preciously.

Ah! Yes.  I forgot to mention about that in the doc-string.  If we
write as below, I think CODING-SYSTEM-LIST is good enough.

Format of elements is (REGEXP TARGET-TYPE . CODING-SYSTEM-LIST),\n\
 where\n\
REGEXP is a regular expression matching a target of I/O operation,\n\
TARGET-TYPE is a symbol `file', `process', or `network',\n\
CODING-SYSTEM-LIST is a list of coding systems READ-CODING-SYSTEM,\n\
WRITE-CODING-SYSTEM, and GIVE-ARGS-CODING-SYSTEM.\n\
\n\
READ-CODING-SYSTEM is for read operation, WRITE-CODING-SYSTEM is for\n\
write operation, GIVE-ARGS-CODING-SYSTEM is for giving arguments to a\n\
process.  The last two may be omited.\n\
Any of them can be a function symbol, in which case, the function is called\n\
to decide a coding system.  See the documentation of `find-coding-system'\n\
for the detail.\n\

---
Ken'ichi HANDA
handa@etl.go.jp

From xemacs-beta-request@cs.uiuc.edu  Tue Oct 22 13:15:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA20746 for xemacs-beta-people; Tue, 22 Oct 1996 13:15:04 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA20743 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 22 Oct 1996 13:15:03 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA21598 for <XEmacs-Beta@XEmacs.org>; Tue, 22 Oct 1996 13:14:57 -0500 (CDT)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.7.5/8.7.3) with ESMTP id NAA28631 for <XEmacs-Beta@XEmacs.org>; Tue, 22 Oct 1996 13:11:01 -0500
Message-Id: <199610221811.NAA28631@nvwls.cc.purdue.edu>
Reply-to: nuspl@purdue.edu
X-Mailer: MH-E 5.0.2
X-Attribution: JJN
X-Face: K'Q`VIQx)c-;TPHDA`.,kBQq(WyNe3AdopJ?B(.4yT%n|F?4>+?x]pQ4XC83s-4;|U{%9x]
 =yr4dko
To: XEmacs-Beta@xemacs.org
Subject: dired vs. DIR_COLORS
Date: Tue, 22 Oct 1996 13:10:54 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


Has anyone written a script to translate /etc/DIR_COLORS into font lock
specification for dired?

I didn't want to re-implement this is someone has already done this.

Thanks.

From xemacs-beta-request@cs.uiuc.edu  Tue Oct 22 20:28:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA22100 for xemacs-beta-people; Tue, 22 Oct 1996 20:28:04 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA22097 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 22 Oct 1996 20:28:03 -0500 (CDT)
Received: from infodock.com (weiner@[206.13.40.192]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA13187 for <xemacs-beta@cs.uiuc.edu>; Tue, 22 Oct 1996 20:27:44 -0500 (CDT)
Received: (from weiner@localhost) by infodock.com (8.8.0/8.7.3) id SAA01384 for xemacs-beta@cs.uiuc.edu; Tue, 22 Oct 1996 18:29:53 -0700
Date: Tue, 22 Oct 1996 18:29:53 -0700
From: Bob Weiner <weiner@infodock.com>
Message-Id: <199610230129.SAA01384@infodock.com>
To: xemacs-beta@cs.uiuc.edu
Subject: Error in my lesstif b2 build config problem


Apologies on my last message.  I sent in the errors from when I
tried to link without Xmu, not the errors when Xmu and Xm were
both included.  Unfortunately, I lost those for now and am
rebuilding with just the Xmu compatibility routines (--no-xmu)
to see how that fairs.

Bob

From xemacs-beta-request@cs.uiuc.edu  Wed Oct 23 09:46:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id JAA27030 for xemacs-beta-people; Wed, 23 Oct 1996 09:46:43 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA27027 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 23 Oct 1996 09:46:42 -0500 (CDT)
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id JAA23482 for <xemacs-beta@xemacs.org>; Wed, 23 Oct 1996 09:46:39 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa12007;
          23 Oct 96 10:45 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id KAA21249; Wed, 23 Oct 1996 10:45:32 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id KAA01013; Wed, 23 Oct 1996 10:45:31 -0400
Date: Wed, 23 Oct 1996 10:45:31 -0400
Message-Id: <199610231445.KAA01013@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: xemacs-beta@xemacs.org
Subject: Latest version of elp.el
Reply-To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
X-Attribution: BAW
X-Oblique-Strategy: The most important thing is the thing most easily forgotten
X-WWW-Homepage: http://www.python.org/~bwarsaw


I just sent RMS the latest version of elp.el.  I notice 19.14 has a
slightly older version so please grab version 2.37 from

    <ftp://ftp.python.org/pub/emacs/elp.el>

-Barry

From xemacs-beta-request@cs.uiuc.edu  Wed Oct 23 18:15:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA28732 for xemacs-beta-people; Wed, 23 Oct 1996 18:15:55 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA28729 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 23 Oct 1996 18:15:54 -0500 (CDT)
Received: from paloalto.access.hp.com (daemon@paloalto.access.hp.com [15.254.56.2]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA24315 for <xemacs-beta@xemacs.org>; Wed, 23 Oct 1996 18:15:50 -0500 (CDT)
Received: from harding.sde.hp.com by paloalto.access.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA154352545; Wed, 23 Oct 1996 16:15:46 -0700
Received: from harding (localhost) by harding.sde.hp.com with SMTP
	(1.39.111.2/16.2) id AA159922710; Wed, 23 Oct 1996 17:18:30 -0600
Sender: harding@sde.hp.com
Message-Id: <326EA7C5.3105@sde.hp.com>
Date: Wed, 23 Oct 1996 17:18:29 -0600
From: Laura Harding <harding@sde.hp.com>
Organization: Hewlett-Packard Company
X-Mailer: Mozilla 3.0b7Gold (X11; I; HP-UX B.10.10 9000/712)
Mime-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: Ebola warning?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Does anyone have any information about the Ebola warnings that come to
the term window where I started up XEmacs?

laura

From xemacs-beta-request@cs.uiuc.edu  Wed Oct 23 18:34:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA28773 for xemacs-beta-people; Wed, 23 Oct 1996 18:34:40 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA28770 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 23 Oct 1996 18:34:39 -0500 (CDT)
Received: from hp.com (hp.com [15.255.152.4]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA24328 for <xemacs-beta@xemacs.org>; Wed, 23 Oct 1996 18:34:34 -0500 (CDT)
Received: from harding.sde.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA096803596; Wed, 23 Oct 1996 16:33:17 -0700
Received: from harding (localhost) by harding.sde.hp.com with SMTP
	(1.39.111.2/16.2) id AA161773757; Wed, 23 Oct 1996 17:35:57 -0600
Sender: harding@sde.hp.com
Message-Id: <326EABDC.223C@sde.hp.com>
Date: Wed, 23 Oct 1996 17:35:56 -0600
From: Laura Harding <harding@sde.hp.com>
Organization: Hewlett-Packard Company
X-Mailer: Mozilla 3.0b7Gold (X11; I; HP-UX B.10.10 9000/712)
Mime-Version: 1.0
To: Dipankar Gupta <dg@hplb.hpl.hp.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: Ebola warning?
References: <326EA7C5.3105@sde.hp.com> <199610232324.AA147873060@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> If you mean the dire warnings about Meta and Mode_switch, this is a
> bug in VUE, and the workaround is covered in the faq.
> 
> Regards,
> Dipankar

The messages seem XEmacs related. Here are some sample error messages:

Ebola warning!! (0 and ?\()
   [memq, make-frame, make-dialog-frame, mouse-read-file-name-1,
read-file-name-1, read-file-name, if, list]
Ebola warning!! (0 and ?\[)
   [memq, make-frame, make-dialog-frame, mouse-read-file-name-1,
read-file-name-1, read-file-name, if, list]
Ebola warning!! (0 and ?\{)
   [memq, make-frame, make-dialog-frame, mouse-read-file-name-1,
read-file-name-1, read-file-name, if, list]

Any help?
laura

From xemacs-beta-request@cs.uiuc.edu  Wed Oct 23 23:59:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA29494 for xemacs-beta-people; Wed, 23 Oct 1996 23:59:59 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA29491 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 23 Oct 1996 23:59:58 -0500 (CDT)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id XAA24690 for <xemacs-beta@xemacs.org>; Wed, 23 Oct 1996 23:59:54 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA28088; Wed, 23 Oct 1996 21:59:21 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id VAA10466; Wed, 23 Oct 1996 21:59:18 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA00218; Wed, 23 Oct 1996 21:59:19 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA29307; Wed, 23 Oct 1996 21:59:15 -0700
Date: Wed, 23 Oct 1996 21:59:15 -0700
Message-Id: <199610240459.VAA29307@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
Cc: xemacs-beta@xemacs.org
Subject: Latest version of elp.el
In-Reply-To: <199610231445.KAA01013@anthem.CNRI.Reston.Va.US>
References: <199610231445.KAA01013@anthem.CNRI.Reston.Va.US>
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII

>>>>> "BAW" == Barry A Warsaw <bwarsaw@anthem.cnri.reston.va.us> writes:

BAW> I just sent RMS the latest version of elp.el.  I notice 19.14 has a
BAW> slightly older version so please grab version 2.37 from

BAW>     <ftp://ftp.python.org/pub/emacs/elp.el>

I've updated elp.el and python.el in my workspace.
Any other Barryware that should be updated?

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 24 02:42:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id CAA29783 for xemacs-beta-people; Thu, 24 Oct 1996 02:42:51 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id CAA29780 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 24 Oct 1996 02:42:50 -0500 (CDT)
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id CAA24876 for <xemacs-beta@xemacs.org>; Thu, 24 Oct 1996 02:42:37 -0500 (CDT)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.7.6/8.7.3) with ESMTP id AAA23908 for <xemacs-beta@xemacs.org>; Thu, 24 Oct 1996 00:42:14 -0700 (PDT)
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id AAA16492 for <xemacs-beta@xemacs.org>; Thu, 24 Oct 1996 00:41:54 -0700
Date: Thu, 24 Oct 1996 00:41:54 -0700
Message-Id: <199610240741.AAA16492@shellx.best.com>
From: Ben Wing <wing@666.com>
To: xemacs-beta@xemacs.org, Laura Harding <harding@sde.hp.com>
Subject: Re:  Ebola warning?

I put those warnings in to catch certain old Lisp code.  You should probably
send them in to this list but otherwise ignore them.
 
ben
--
(This message composed by voice)

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 24 04:48:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA03826 for xemacs-beta-people; Thu, 24 Oct 1996 04:48:34 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA03823 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 24 Oct 1996 04:48:33 -0500 (CDT)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id EAA25163 for <xemacs-beta@xemacs.org>; Thu, 24 Oct 1996 04:48:29 -0500 (CDT)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 3.2/UCB 5.64/4.03)
          id AA17335; Thu, 24 Oct 1996 10:48:20 +0100
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA23048; Thu, 24 Oct 1996 11:48:17 +0200
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@xemacs.org
Subject: psgml-html fix
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 24 Oct 1996 11:48:16 +0200
Message-Id: <y9l7mogpuan.fsf@modas.informatik.uni-tuebingen.de>
Lines: 17


Steve Baur encouraged me to post this patch.  Without it, psgml-html
doesn't quite work.

Cheers =8-} Mike

*** etc/sgml/CATALOG.orig	Thu Oct 24 11:45:16 1996
--- etc/sgml/CATALOG	Thu Oct 24 11:45:18 1996
***************
*** 47,49 ****
--- 47,51 ----
  PUBLIC "-//Microsoft//DTD Internet Explorer 2.0 Tables//EN"     ietables.dtd
  PUBLIC "-//W3C//DTD HTML 3.2//EN"                       html-3.2.dtd
  PUBLIC "-//W3C//DTD HTML Experimental 19960712//EN"	html-cougar.dtd
+ DOCTYPE HTML						html.dtd
+ DOCTYPE HTML-3						html-3.dtd


From xemacs-beta-request@cs.uiuc.edu  Thu Oct 24 11:21:25 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id LAA04936 for xemacs-beta-people; Thu, 24 Oct 1996 11:21:25 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA04933 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 24 Oct 1996 11:21:24 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id LAA01538 for <xemacs-beta@cs.uiuc.edu>; Thu, 24 Oct 1996 11:21:23 -0500 (CDT)
Received: from sbkifer.cs.sunysb.edu (sbkifer.cs.sunysb.edu [130.245.1.35]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id MAA19709 for <xemacs-beta@cs.uiuc.edu>; Thu, 24 Oct 1996 12:27:53 -0400
Message-Id: <199610241627.MAA19709@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: xemacs-beta@cs.uiuc.edu
Subject: keymaping/warning
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Oct 1996 12:19:13 -0400
Sender: kifer@cs.sunysb.edu

I remapped my caps-lock key to work as Control key, because I don't use it
and because of the difference in the various kbds.

Now I am getting the annoying warnings below.

    (2) (key-mapping/warning) 
	The semantics of the modifier bits ModShift, ModLock, and ModControl
	are predefined.  It does not make sense to assign ModControl to any
	keysym other than Control_L or Control_R, or to assign any modifier
	bits to the "control" keysyms other than ModControl.  You can't
	turn a "control" key into a "meta" key (or vice versa) by simply
	assigning the key a different modifier bit.  You must also make that
	key generate an appropriate keysym (Control_L, Meta_L, etc).

    (3) (key-mapping/warning) XEmacs:  Caps_Lock (0x7e) generates ModControl,
	which is nonsensical.

I don't think it is XEmacs' business to issue such warnings, especially
since people who remap caps-lock tend to know what they are doing.
If it is believed that having such messages is essential (which I don't
agree with), please don't make the *Warnings* window pop up each time one
starts XEmacs.



	--michael  

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 24 09:17:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id JAA04502 for xemacs-beta-people; Thu, 24 Oct 1996 09:17:39 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA04499 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 24 Oct 1996 09:17:28 -0500 (CDT)
Received: from infodock.com (root@[206.13.40.192]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA25538 for <xemacs-beta@xemacs.org>; Thu, 24 Oct 1996 09:17:19 -0500 (CDT)
Received: (from weiner@localhost) by infodock.com (8.8.0/8.7.3) id RAA10965; Sat, 19 Oct 1996 17:08:46 -0700
Date: Sat, 19 Oct 1996 17:08:46 -0700
From: Bob Weiner <weiner@infodock.com>
Message-Id: <199610200008.RAA10965@infodock.com>
To: gnu-emacs-sources@gnu.ai.mit.edu, xemacs-beta@xemacs.org
Subject: id-select.el - advanced syntactic region selections

This is a radically cool, drop in mouse and keyboard-based library for
selecting successively bigger syntactical regions  within a buffer.  Simply
load this library and you are ready to try it out by double-clicking
on various kinds of characters in different buffer major modes.  You'll
quickly get the hang of it.

There is a small problem with the Emacs mouse support (InfoDock and XEmacs
work fine), as described in the DESCRIPTION section below.  Read that section
for full installation instructions.

A great deal of smarts are built-in so that it does the right thing almost
all of the time; many other attempts at similar behavior such as thing.el
fail to deal with many file format complexities.

Double clicks of the Selection Key (left mouse key) at the same point will
select bigger and bigger regions with each successive use.  The first double
click selects a region based upon the character at the point of the click.
For example, with the point over an opening or closing grouping character,
such as { or }, the whole grouping is selected, e.g. a C function.  When on
an _ or - within a programming language variable name, the whole name is
selected.  The type of selection is displayed in the minibuffer as feedback.
When using a language based mainly on indenting, like Bourne shell, a double
click on the first alpha character of a line, such as an if statement,
selects the whole statement.

;;!emacs
;;
;; LCD-ENTRY:    id-select.el|Bob Weiner|weiner@infodock.com|Syntactical region selecting|10/19/96|1.0|
;;
;; FILE:         id-select.el
;; SUMMARY:      Select larger and larger syntax-driven regions in a buffer.
;; USAGE:        XEmacs and Emacs Lisp Library
;; KEYWORDS:     
;;
;; AUTHOR:       Bob Weiner
;;                 derived in part from Martin Boyer's imouse package
;;                 and from Heinz Schmidt's thing.el within the sky-mouse package
;; ORG:          InfoDock Associates
;;
;; ORIG-DATE:    19-Oct-96 at 02:25:27
;; LAST-MOD:     19-Oct-96 at 17:06:18 by Bob Weiner
;;
;; Copyright (C) 1996  Free Software Foundation, Inc.
;; Copyright (C) 1991  International Computer Science Institute
;;
;; This file is part of InfoDock.
;; It is available for use and distribution under the terms of the GNU Public
;; License.
;;
;; DESCRIPTION:  
;;
;;   (NOTE: The mouse setup part of this package (search for 'global-set-key')
;;    works beautifully under InfoDock and XEmacs.  There is some minor
;;    configuration problem under Emacs that I have not resolved.  You can
;;    use the keyboard command for now under Emacs.)
;;
;;   This is a radically cool, drop in mouse and keyboard-based library for
;;   selecting successively bigger syntactical regions  within a buffer.  Simply
;;   load this library and you are ready to try it out by double-clicking
;;   on various kinds of characters in different buffer major modes.  You'll
;;   quickly get the hang of it.
;;   
;;   A great deal of smarts are built-in so that it does the right thing almost
;;   all of the time; many other attempts at similar behavior such as thing.el
;;   fail to deal with many file format complexities.
;;   
;;   Double clicks of the Selection Key (left mouse key) at the same point will
;;   select bigger and bigger regions with each successive use.  The first double
;;   click selects a region based upon the character at the point of the click.
;;   For example, with the point over an opening or closing grouping character,
;;   such as { or }, the whole grouping is selected, e.g. a C function.  When on
;;   an _ or - within a programming language variable name, the whole name is
;;   selected.  The type of selection is displayed in the minibuffer as feedback.
;;   When using a language based mainly on indenting, like Bourne shell, a double
;;   click on the first alpha character of a line, such as an if statement,
;;   selects the whole statement.
;;
;;   ---------------
;;
;;   This whole package is driven by a single function, available in mouse
;;   and keyboard forms, that first marks a region based on the syntax
;;   category of the character following point.  Successive invocations mark
;;   larger and larger regions until the whole buffer is marked.  See 
;;   the documentation for the function, id-select-syntactical-region, for
;;   the kinds of syntax categories handled.
;;
;;   Loading this package automatically installs its functionalty on
;;   double-clicks (or higher) of the left mouse key.  (See the documentation
;;   for the variable, mouse-track-click-hook, for how this is done.)  A single
;;   click of the left button will remove the region and reset point.
;;
;;   The function, id-select-thing, may be bound to a key to provide the
;;   same syntax-driven region selection functionality.  Use {C-g} to unmark
;;   the region when done.  Use, id-select-thing-with-mouse, if you want
;;   to bind this to a mouse key and thereby use single clicks instead of
;;   double clicks.
;;
;;   Two other related commands are also provided:
;;    id-select-and-copy-thing - mark and copy the syntactical unit to the kill ring
;;    id-select-and-kill-thing - kill the syntactical unit at point
;;
;;   ---------------
;;
;;   To autoload this package under XEmacs or InfoDock via mouse usage, add
;;   the following line to one of your initialization files.  (Don't do this
;;   for GNU Emacs.)
;;
;;      (add-hook 'mouse-track-click-hook 'id-select-double-click-hook)
;;
;;   You may also have to add the following autoload entries at your site.
;;
;;      (autoload 'id-select-and-kill-thing    "id-select" "Kill syntactical region selection" t)
;;      (autoload 'id-select-and-copy-thing    "id-select" "Select and copy syntactical region" t)
;;      (autoload 'id-select-double-click-hook "id-select" "Double mouse click syntactical region selection" nil)
;;      (autoload 'id-select-thing             "id-select" "Keyboard-driven syntactical region selection" t)
;;      (autoload 'id-select-thing-with-mouse  "id-select" "Single mouse click syntactical region selection" t)
;;
;; DESCRIP-END.

;;; ************************************************************************
;;; Other required Elisp libraries
;;; ************************************************************************

;;; ************************************************************************
;;; Public variables
;;; ************************************************************************

(defvar id-select-brace-modes
  '(c++-mode c-mode java-mode objc-mode perl-mode tcl-mode)
  "*List of language major modes which define things with brace delimiters.")

(defvar id-select-indent-modes
  '(csh-mode eiffel-mode ksh-mode python-mode pascal-mode sather-mode)
  "*List of language major modes which use mostly indentation to define syntactic structure.")

(defvar id-select-indent-non-end-regexp-alist
  '((csh-mode    "\\(then\\|elsif\\|else\\)[ \t\]*$")
    (eiffel-mode "\\(then\\|else if\\|else\\)[ \t\]*$")
    (ksh-mode    "\\(then\\|elif\\|else\\)[ \t\]*$")
    (pascal-mode "\\(then\\|else\\)[ \t\]*$")
    (sather-mode "\\(then\\|else if\\|else\\)[ \t\]*$"))
  "List of (major-mode . non-terminator-line-regexp) elements used to avoid early dropoff when marking indented code.")

(defvar id-select-indent-end-regexp-alist
  '((csh-mode "end\\while")
    (eiffel-mode "end")
    (ksh-mode "\\(fi\\|esac\\|until\\|done\\)[ \t\n]")
    (pascal-mode "end")
    (sather-mode "end"))
  "List of (major-mode . terminator-line-regexp) elements used to include a final line when marking indented code.")

(defvar id-select-char-p t
  "*If t, return single character boundaries when all else fails.")

(defvar id-select-display-type t
  "*If t, display the thing selected with each mouse click.")

(defvar id-select-whitespace t
  "*If t, groups of whitespace are considered as things.")

(if (string-match "XEmacs" emacs-version)
    (add-hook 'mouse-track-click-hook 'id-select-double-click-hook)
  (if (string-match "^19\\." emacs-version)
      (progn (transient-mark-mode 1)
	     (global-set-key [mouse-1] 'mouse-set-point)
	     (global-set-key [double-mouse-1] 'id-select-thing-with-mouse)
	     (global-set-key [triple-mouse-1] 'id-select-thing-with-mouse))))

;;; ************************************************************************
;;; Public functions
;;; ************************************************************************

;;
;; Commands
;;

;;;###autoload
(defun id-select-thing ()
  "Highlight the region selected by the syntax of the thing at point."
  (interactive
   (cond ((and (fboundp 'region-active-p) (region-active-p))
	  nil)
	 ((and (boundp 'transient-mark-mode) transient-mark-mode mark-active)
	  nil)
	 (t
	  ;; Reset selection based on the syntax of character at point.
	  (setq id-select-prior-point (point)
		id-select-prior-buffer (current-buffer)
		id-select-previous 'char
		id-select-type 'char)
	  (id-select-set-region nil nil)
	  nil)))
  (let ((region (id-select-boundaries (point))))
    (if region
	(progn (goto-char (car region))
	       (set-mark (cdr region))
	       (if (fboundp 'activate-region) (activate-region))
	       (if (and (boundp 'transient-mark-mode)
			transient-mark-mode)
		   (setq mark-active t))
	       (and (interactive-p) id-select-display-type
		    (message "%s" id-select-previous))
	       t))))

;;;###autoload
(defun id-select-thing-with-mouse (event)
  "Select a region based on the syntax of the character from a mouse click.
If the click occurs at the same point as the last click, select
the next larger syntactic structure.  If id-select-display-type is non-nil,
the type of selection is displayed in the minibuffer."
  (interactive "@e")
  (cond ((and (eq id-select-prior-point (point))
	      (eq id-select-prior-buffer (current-buffer)))
	 ;; Prior click was at the same point as before, so enlarge
	 ;; selection to the next bigger item.
	 (if (and (id-select-bigger-thing) id-select-display-type)
	     (message "%s" id-select-previous))
	 t)
	(t (id-select-reset event)
	   (id-select-thing-with-mouse event))))


;;;###autoload
(defun id-select-and-copy-thing ()
  "Copy the region surrounding the syntactical unit at point."
  (interactive)
  (let ((bounds (id-select-boundaries (point))))
    (if bounds (copy-region-as-kill (car bounds) (cdr bounds)))))

;;;###autoload
(defun id-select-and-kill-thing ()
  "Kill the region surrounding the syntactical unit at point."
  (interactive)
  (let ((bounds (id-select-boundaries (point))))
    (if bounds (kill-region (car bounds) (cdr bounds)))))


;;
;; Functions
;;

(defun id-select-boundaries (pos)
  "Return the (start . end) of a syntactically defined region based upon the last region selected or on position POS.
The character at POS is selected if no other thing is matched."
  (setq zmacs-region-stays t)
  (setcar id-select-old-region (car id-select-region))
  (setcdr id-select-old-region (cdr id-select-region))
  (let ((pair) (found) (alist) elt)
    (if (eq id-select-previous 'char)
	(id-select-syntactical-region pos)
      (if (and (car id-select-old-region)
	       (memq id-select-previous
		     '(sexp sexp-start sexp-end sexp-up))
	       (id-select-sexp-up pos)
	       (id-select-region-bigger-p id-select-old-region id-select-region))
	  id-select-region
	(setq alist id-select-bigger-alist)
	(while (and alist (not (and (id-select-region-bigger-p 
				     id-select-old-region id-select-region)
				    found)))
	  (setq found nil pair nil)
	  (while (and (not found) (setq elt (car alist)))
	    (setq alist (cdr alist))
	    (if (and alist (eq (car elt) id-select-previous))
		(progn (if (car (cdr (car alist)))
			   (setq pair (car alist)
				 id-select-previous (car pair)
				 found t)
			 ;; Skip entries whose selection function is nil.
			 (setq id-select-previous (car (car alist)))))))
	  (if found (funcall (car (cdr pair)) pos)))
	(if found
	    id-select-region
	  (beep)
	  (message "(id-select-boundaries): `%s' is the largest selectable region"
		   id-select-previous)
	  nil)))))

;;;###autoload
(defun id-select-double-click-hook (event click-count)
  "Select a region based on the syntax of the character wherever the mouse is multi-clicked.
If the multi-click occurs at the same point as the last multi-click, select
the next larger syntactic structure.  If id-select-display-type is non-nil,
the type of selection is displayed in the minibuffer."
  (cond ((= click-count 1)
	 ;; Return nil so any other hooks are performed.
	 nil)
	(t (id-select-thing-with-mouse event))))

(defun id-select-syntactical-region (pos)
  "Return the (start . end) of a syntactically defined region based upon the buffer position POS.
Uses 'id-select-syntax-alist' and the current buffer's syntax table to
determine syntax groups.

Typically:
 Open or close grouping character syntax marks an s-expression.
 The end of a line marks the line, including its trailing newline.
 Word syntax marks the current word.
 Symbol syntax (such as _ or - ) marks a symbol.
 The fallback default is to mark the character at POS.

If an error occurs during syntax scanning, it returns nil."
  (interactive "d")
  (setq id-select-previous 'char)
  (if (save-excursion (goto-char pos) (eolp))
      (id-select-line pos)
    (let* ((syntax (char-syntax (char-after pos)))
           (pair (assq syntax id-select-syntax-alist)))
      (cond ((and pair
		  (or id-select-whitespace
		      (not (eq (car (cdr pair)) 'thing-whitespace))))
             (funcall (car (cdr pair)) pos))
            (id-select-char-p
             (setq id-select-previous 'char)
             (id-select-set-region pos (1+ pos)))
            (t
             nil)))))

;;; ************************************************************************
;;; Private functions
;;; ************************************************************************

(defun id-select-region-bigger-p (old-region new-region)
  "Return t if OLD-REGION is smaller than NEW-REGION and NEW-REGION subsumes OLD-REGION."
  (if (null (car old-region))
      t
    (and (> (abs (- (cdr new-region) (car new-region)))
	    (abs (- (cdr old-region) (car old-region))))
	 (<= (min (cdr new-region) (car new-region))
	     (min (cdr old-region) (car old-region)))
	 (>= (max (cdr new-region) (car new-region))
	     (max (cdr old-region) (car old-region))))))

(defun id-select-bigger-thing ()
  "Select a bigger object where point is."
  (prog1
      (id-select-thing)
    (setq id-select-type id-select-previous)
    (setq this-command 'select-thing)))

(defun id-select-reset (event)
  ;; Reset mouse-driven syntactic selection.
  (setq id-select-prior-point (point)
	id-select-prior-buffer (current-buffer)
	id-select-previous 'char
	id-select-type 'char
	this-command 'mouse-start-selection)
  (id-select-set-region nil nil))

(defun id-select-set-region (beginning end)
  "Make BEGINNING the car and END the cdr of the cons cell in the
variable 'id-select-region'.  Return the updated cons cell."
  (setcar id-select-region beginning)
  (setcdr id-select-region end)
  id-select-region)

(defun id-select-string-p (&optional start-delim end-delim)
  "Returns (start . end) of string whose first line point is within.
Positions include delimiters.  String is delimited by double quotes unless
optional START-DELIM and END-DELIM (strings) are given.
Returns nil if not within a string."
  (let ((opoint (point))
	(quoted "\\(^\\|[^\\{]\\)")
	bol start)
    (or start-delim (setq start-delim "\""))
    (or end-delim (setq end-delim "\""))
    (save-excursion
      (beginning-of-line)
      (setq bol (point))
      (goto-char opoint)
      (if (re-search-backward (regexp-quote start-delim) bol t)
	  (progn
	    (setq start (point))
	    (goto-char opoint)
	    (if (re-search-forward (concat quoted (regexp-quote end-delim))
				   nil t)
		(id-select-set-region start (point))))))))

;;;
;;; Code-related selections
;;;

(defun id-select-brace-def (pos)
  "If POS is at the first character, opening brace or closing brace of a brace delimited language definition, return (start . end) region, else nil.
The major mode for each supported brace language must be included in the
list, id-select-brace-modes."
  (interactive)
  (goto-char pos)
  (if (and (featurep 'cc-mode) (memq major-mode id-select-brace-modes))
      (let ((at-def-brace (or (looking-at "^{") (looking-at "^}")))
	    (opoint (point))
	    ;; there should be a c-point position for 'eod
	    (eod  (save-excursion (end-of-defun) (point)))
	    (state (c-parse-state))
	    brace)
	(while state
	  (setq brace (car state))
	  (if (consp brace)
	      (goto-char (cdr brace))
	    (goto-char brace))
	  (setq state (cdr state)))
	(if (= (following-char) ?{)
	    (progn
	      (forward-line -1)
	      (while (not (or (bobp)
			      (looking-at "[ \t]*$")))
		(forward-line -1)))
	  (forward-line 1)
	  (skip-chars-forward " \t\n"))
	(if (or at-def-brace (= (point) opoint) (= (point) eod))
	    ;; Mark the whole definition
	    (progn
	      (setq id-select-previous 'brace-def)
	      (id-select-set-region (point) eod))
	  (goto-char opoint)
	  nil))))

(defun id-select-indent-def (pos)
  "If POS is at the first character, opening brace or closing brace of a brace delimited language definition, return (start . end) region, else nil.
The major mode for each supported brace language must be included in the
list, id-select-brace-modes."
  (interactive)
  (if (and (memq major-mode id-select-indent-modes)
	   ;; After indent, must be on an alpha character.
	   (looking-at "[a-zA-z]")
	   ;; Must be at the first non-whitespace character in the line.
	   (= (point) (save-excursion (back-to-indentation) (point))))
      (let ((opoint (point))
	    (start-col (current-column)))
	(while (and (= (forward-line 1) 0)
		    (or (looking-at "^[ \t]*$")
			(progn (back-to-indentation)
				(> (current-column) start-col))
			(and (= (current-column) start-col)
			     (looking-at
			      (or (car (cdr (assq
					     major-mode
					     id-select-indent-non-end-regexp-alist)))
				  "\\'"))))))
	(if (looking-at
	     (or (car (cdr (assq major-mode
				 id-select-indent-end-regexp-alist)))
		 "\\'"))
	    (forward-line 1))
	(beginning-of-line)
	;; Mark the whole definition
	(setq id-select-previous 'indent-def)
	(id-select-set-region opoint (point)))))

(defun id-select-symbol (pos)
  "Return the start and end of a symbol at POS."
  (setq id-select-previous 'symbol)
  (condition-case ()
      (let ((end (scan-sexps pos 1)))
	(id-select-set-region (min pos (scan-sexps end -1)) end))
    (error nil)))

(defun id-select-sexp-start (pos)
  "Return start and end of sexp starting at POS."
  (or (id-select-brace-def pos)
      (progn (setq id-select-previous 'sexp-start)
	     (condition-case ()
		 (id-select-set-region pos (scan-sexps pos 1))
	       (error nil)))))

(defun id-select-sexp-end (pos)
  "Return start and end of sexp ending at POS."
  (or (id-select-brace-def pos)
      (progn (setq id-select-previous 'sexp-end)
	     (condition-case ()
		 (id-select-set-region (scan-sexps (1+ pos) -1) (1+ pos))
	       (error nil)))))

(defun id-select-sexp (pos)
  "Return start and end of the sexp that POS is within."
  (setq id-select-previous 'sexp)
  (save-excursion 
    (goto-char pos)
    (condition-case ()
	(id-select-set-region (progn (backward-up-list 1) (point))
			      (progn (forward-list 1) (point)))
      (error nil))))

(defun id-select-sexp-up (pos)
  "Return start and end of the sexp enclosing the selected area or nil."
  (setq id-select-previous 'sexp-up)
  ;; Keep going up and backward in sexps.  This means that id-select-sexp-up
  ;; can only be called after id-select-sexp or after itself.
  (setq pos (or (car id-select-region) pos))
  (save-excursion 
    (goto-char pos)
    (condition-case ()
	(id-select-set-region (progn (backward-up-list 1) (point))
			      (progn (forward-list 1) (point)))
      (error nil))))

;; Allow punctuation marks not followed by white-space to include
;; the subsequent sexpression. Useful in contexts such as 'foo.bar(x).baz'.
(defun id-select-punctuation (pos)
  "Return (start . end) region from POS to the end of the sexp, when at a punctuation character."
  (setq id-select-previous 'punctuation)
  (if (= (char-syntax (char-after (1+ pos))) ? )
      (id-select-set-region pos (1+ pos))
    (goto-char pos)
    (id-select-set-region
     (save-excursion (backward-sexp) (point))
     (save-excursion (forward-sexp) (point)))))

;;; Allow click to comment-char to extend to end of line
(defun id-select-comment (pos)
  "Return rest of line from POS to newline."
  (setq id-select-previous 'comment)
  (save-excursion (goto-char pos)
		  (end-of-line)
		  (id-select-set-region pos (point))))

;;;
;;; Textual selections
;;;

(defun id-select-word (pos)
  "Return start and end of word at POS."
  (or (id-select-brace-def pos)
      (id-select-indent-def pos)
      (progn (setq id-select-previous 'word)
	     (save-excursion
	       (goto-char pos)
	       (forward-word 1)
	       (let ((end (point)))
		 (forward-word -1)
		 (id-select-set-region (point) end))))))

(defun id-select-string (pos)
  "Returns (start . end) of string at POS or nil.  Pos include delimiters.
Delimiters may be single, double or open and close quotes."
  (setq id-select-previous 'string)
  (save-excursion
    (goto-char pos)
    (or (id-select-string-p) (id-select-string-p "'" "'")
	(id-select-string-p "`" "'"))))

(defun id-select-sentence (pos)
  "Return start and end of the sentence at POS."
  (setq id-select-previous 'sentence)
  (save-excursion 
    (goto-char pos)
    (id-select-set-region (progn (backward-sentence) (point))
			  (progn (forward-sentence) (point)))))

(defun id-select-whitespace (pos)
  "Return start to end of all but one char of whitespace POS, unless 
there is only one char of whitespace.  Then return start to end of it."
  (setq id-select-previous 'whitespace)
  (save-excursion
    (let ((start (progn (skip-chars-backward " \t") (1+ (point))))
	  (end (progn (skip-chars-forward " \t") (point))))
      (if (= start end)
	  (id-select-set-region (1- start) end)
	(id-select-set-region start end)))))

;;;
;;; Document-related selections
;;;

(defun id-select-line (pos)
  "Return whole of line POS is in, with newline unless at eob."
  (setq id-select-previous 'line)
  (save-excursion
    (goto-char pos)
    (let* ((start (progn (beginning-of-line 1) (point)))
	   (end (progn (forward-line 1) (point))))
      (id-select-set-region start end))))

(defun id-select-paragraph (pos)
  "Return start and end of the paragraph at POS."
  (setq id-select-previous 'paragraph)
  (save-excursion 
    (goto-char pos)
    (id-select-set-region (progn (backward-paragraph) (point))
			  (progn (forward-paragraph) (point)))))

(defun id-select-page (pos)
  "Return start and end of the page at POS."
  (setq id-select-previous 'page)
  (save-excursion 
    (goto-char pos)
    (id-select-set-region (progn (backward-page) (point))
			  (progn (forward-page) (point)))))

(defun id-select-buffer (pos)
  "Return start and end of the buffer at POS."
  (setq id-select-previous 'buffer)
  (id-select-set-region (point-min) (point-max)))

;;; ************************************************************************
;;; Private variables
;;; ************************************************************************

(defvar id-select-bigger-alist
  '((char nil)
    (whitespace nil)
    (word id-select-word)
    (symbol id-select-symbol)
    (punctuation nil)
    (string id-select-string)
    (comment nil)
    (sexp id-select-sexp)
    (sexp-start nil)
    (sexp-end nil)
    (sexp-up id-select-sexp-up)
    (line id-select-line)
    (sentence id-select-sentence)
    (brace-def id-select-brace-def)
    (indent-def id-select-indent-def)
    (paragraph id-select-paragraph)
    (page id-select-page)
    (buffer id-select-buffer)
    )
  "List of pairs to go from one thing to a bigger thing.
See id-select-bigger-thing.")

(defvar id-select-prior-buffer nil)
(defvar id-select-prior-point nil)

(defvar id-select-previous 'char
  "The last type of thing found by id-select-boundaries.")

(defvar id-select-region (cons 'nil 'nil)
  "Cons cell that contains a region (<beginning> . <end>).
The function 'id-select-set-region' updates and returns it.")

(defvar id-select-old-region (cons 'nil 'nil)
  "Cons cell that contains a region (<beginning> . <end>).")

(defvar  id-select-syntax-alist
  '((?w  id-select-word)
    (?_  id-select-symbol)
    (?\( id-select-sexp-start)
    (?\$ id-select-sexp-start)
    (?'  id-select-sexp-start)
    (?\" id-select-sexp-start)
    (?\) id-select-sexp-end)
    (?   id-select-whitespace)
    (?<  id-select-comment)
    (?.  id-select-punctuation))
  "*List of pairs of the form (SYNTAX-CHAR FUNCTION) used by the function 'id-select-syntactical-region'.
Each FUNCTION takes a single position argument and returns a region
(start . end) delineating the boundaries of the thing at that position.")

(defvar id-select-type nil
  "Current type of selection.  Must be set by all selection functions.")


(provide 'id-select)

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 24 12:12:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA05170 for xemacs-beta-people; Thu, 24 Oct 1996 12:12:56 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA05167 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 24 Oct 1996 12:12:55 -0500 (CDT)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id MAA02934 for <xemacs-beta@cs.uiuc.edu>; Thu, 24 Oct 1996 12:12:50 -0500 (CDT)
Received: (qmail 12830 invoked by uid 501); 24 Oct 1996 17:15:22 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: id-select.el - advanced syntactic region selections
References: <199610200008.RAA10965@infodock.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Bob Weiner's message of Sat, 19 Oct 1996 17:08:46 -0700
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: text/plain; charset=US-ASCII
Date: 24 Oct 1996 10:15:21 -0700
Message-ID: <m2ramol1w6.fsf@deanna.miranova.com>
Lines: 18
X-Mailer: Red Gnus v0.52/XEmacs 19.15


;;                 derived in part from Martin Boyer's imouse package
;;                 and from Heinz Schmidt's thing.el within the
;;                 sky-mouse package


Does this imply that we can now dump the thing.el currently in XEmacs?

;;; Synched up with: Not in FSF.
;;; #### FSF has thingatpt.el, which does the same thing.  Should merge
;;; or toss this.

I'd vote for tossing it ...
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 24 12:09:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA05162 for xemacs-beta-people; Thu, 24 Oct 1996 12:09:03 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA05159 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 24 Oct 1996 12:09:03 -0500 (CDT)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id MAA02843 for <xemacs-beta@cs.uiuc.edu>; Thu, 24 Oct 1996 12:08:39 -0500 (CDT)
Received: (qmail 12814 invoked by uid 501); 24 Oct 1996 17:11:13 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: keymaping/warning
References: <199610241627.MAA19709@cs.sunysb.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: kifer@cs.sunysb.edu's message of Thu, 24 Oct 1996 12:19:13 -0400
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: text/plain; charset=US-ASCII
Date: 24 Oct 1996 10:11:11 -0700
Message-ID: <m2u3rkl234.fsf@deanna.miranova.com>
Lines: 24
X-Mailer: Red Gnus v0.52/XEmacs 19.15

>>>>> "Michael" == Michael Kifer <kifer@cs.sunysb.edu> writes:

Michael> I remapped my caps-lock key to work as Control key, because I
Michael> don't use it and because of the difference in the various
Michael> kbds.

Michael> Now I am getting the annoying warnings below.

How did you do the remapping?  I remap those keys with this in
.Xmodmap and don't get any warnings:

remove Lock = Caps_Lock
remove Control = Control_L
! keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 24 12:34:48 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA05276 for xemacs-beta-people; Thu, 24 Oct 1996 12:34:48 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA05273 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 24 Oct 1996 12:34:47 -0500 (CDT)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id MAA03587 for <xemacs-beta@cs.uiuc.edu>; Thu, 24 Oct 1996 12:34:46 -0500 (CDT)
Received: from sbkifer.cs.sunysb.edu (sbkifer.cs.sunysb.edu [130.245.1.35]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id NAA20763; Thu, 24 Oct 1996 13:41:13 -0400
Message-Id: <199610241741.NAA20763@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: keymaping/warning 
In-reply-to: "Steven L Baur" of 24 Oct 1996 10:11:11 PDT
             <m2u3rkl234.fsf@deanna.miranova.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Oct 1996 13:32:32 -0400
Sender: kifer@cs.sunysb.edu

>>>>> "Steven" == Steven L Baur <of 24 Oct 1996 10:11:11 PDT> writes:

>>>>> "Michael" == Michael Kifer <kifer@cs.sunysb.edu> writes:

    Michael> I remapped my caps-lock key to work as Control key, because I
    Michael> don't use it and because of the difference in the various
    Michael> kbds.

    Michael> Now I am getting the annoying warnings below.

    Steven> How did you do the remapping?  I remap those keys with this in
    Steven> .Xmodmap and don't get any warnings:

    Steven> remove Lock = Caps_Lock
    Steven> remove Control = Control_L
    Steven> ! keysym Control_L = Caps_Lock
    Steven> keysym Caps_Lock = Control_L
    Steven> add Lock = Caps_Lock
    Steven> add Control = Control_L

I do practically the same thing:

xmodmap -e "remove Lock = Caps_Lock"	# stop locking -- less drastic
xmodmap -e "add Control = Caps_Lock"	# add control modifier to Caps_Lock

The only difference is that I am not changingt the keysym, but I don't
think it should matter.


	--michael  

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 24 13:27:11 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA05504 for xemacs-beta-people; Thu, 24 Oct 1996 13:27:11 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA05501 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 24 Oct 1996 13:27:10 -0500 (CDT)
Received: from corona.pixar.com (corona.pixar.com [138.72.20.84]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id NAA05171 for <xemacs-beta@cs.uiuc.edu>; Thu, 24 Oct 1996 13:27:09 -0500 (CDT)
Received: by corona.pixar.com (Smail3.1.29.1 #2)
	id m0vGUTU-00011iC; Thu, 24 Oct 96 11:25 PDT
Message-Id: <m0vGUTU-00011iC@corona.pixar.com>
Date: Thu, 24 Oct 96 11:25 PDT
From: Hunter Kelly <retnuh@corona.pixar.com>
To: kifer@cs.sunysb.edu (Michael Kifer)
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: keymaping/warning 
In-Reply-To: <199610241741.NAA20763@cs.sunysb.edu>
References: <m2u3rkl234.fsf@deanna.miranova.com>
	<199610241741.NAA20763@cs.sunysb.edu>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII

I think that because you don't add the keysym, that is why XEmacs is
complaining.  As far as it can tell, the CapsLock key is generating a
CapsLock keysymbol, but it is also setting the control modifier.  I
think that you'd be better off adding the Control_L keysym to the caps
lock key, too.

Hunter

Michael Kifer writes:
 > Date: Thu, 24 Oct 1996 13:32:32 -0400
 > To: Steven L Baur <steve@miranova.com>
 > Cc: xemacs-beta@cs.uiuc.edu
 > From: kifer@cs.sunysb.edu (Michael Kifer)
 > Subject: Re: keymaping/warning 
 > 
 > >>>>> "Steven" == Steven L Baur <of 24 Oct 1996 10:11:11 PDT> writes:
 > 
 > >>>>> "Michael" == Michael Kifer <kifer@cs.sunysb.edu> writes:
 > 
 >     Michael> I remapped my caps-lock key to work as Control key, because I
 >     Michael> don't use it and because of the difference in the various
 >     Michael> kbds.
 > 
 >     Michael> Now I am getting the annoying warnings below.
 > 
 >     Steven> How did you do the remapping?  I remap those keys with this in
 >     Steven> .Xmodmap and don't get any warnings:
 > 
 >     Steven> remove Lock = Caps_Lock
 >     Steven> remove Control = Control_L
 >     Steven> ! keysym Control_L = Caps_Lock
 >     Steven> keysym Caps_Lock = Control_L
 >     Steven> add Lock = Caps_Lock
 >     Steven> add Control = Control_L
 > 
 > I do practically the same thing:
 > 
 > xmodmap -e "remove Lock = Caps_Lock"	# stop locking -- less drastic
 > xmodmap -e "add Control = Caps_Lock"	# add control modifier to Caps_Lock
 > 
 > The only difference is that I am not changingt the keysym, but I don't
 > think it should matter.
 > 
 > 
 > 	--michael  

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 24 16:15:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA06147 for xemacs-beta-people; Thu, 24 Oct 1996 16:15:58 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA06139 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 24 Oct 1996 16:15:49 -0500 (CDT)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id QAA26163 for <xemacs-beta@xemacs.org>; Thu, 24 Oct 1996 16:15:46 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA15501; Thu, 24 Oct 1996 14:15:09 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA21860; Thu, 24 Oct 1996 14:15:06 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA12031; Thu, 24 Oct 1996 14:15:04 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA00605; Thu, 24 Oct 1996 14:15:03 -0700
Date: Thu, 24 Oct 1996 14:15:03 -0700
Message-Id: <199610242115.OAA00605@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Cc: xemacs-beta@xemacs.org
Subject: psgml-html fix
In-Reply-To: <y9l7mogpuan.fsf@modas.informatik.uni-tuebingen.de>
References: <y9l7mogpuan.fsf@modas.informatik.uni-tuebingen.de>
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Michael" == Michael Sperber [Mr Preprocessor] <sperber@informatik.uni-tuebingen.de> writes:

Michael> Steve Baur encouraged me to post this patch.  Without it, psgml-html
Michael> doesn't quite work.

This patch has been applied to my workspace.

Martin

Michael> *** etc/sgml/CATALOG.orig	Thu Oct 24 11:45:16 1996
Michael> --- etc/sgml/CATALOG	Thu Oct 24 11:45:18 1996
Michael> ***************
Michael> *** 47,49 ****
Michael> --- 47,51 ----
Michael>   PUBLIC "-//Microsoft//DTD Internet Explorer 2.0 Tables//EN"     ietables.dtd
Michael>   PUBLIC "-//W3C//DTD HTML 3.2//EN"                       html-3.2.dtd
Michael>   PUBLIC "-//W3C//DTD HTML Experimental 19960712//EN"	html-cougar.dtd
Michael> + DOCTYPE HTML						html.dtd
Michael> + DOCTYPE HTML-3						html-3.dtd



From xemacs-beta-request@cs.uiuc.edu  Thu Oct 24 16:09:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA06131 for xemacs-beta-people; Thu, 24 Oct 1996 16:09:32 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA06128 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 24 Oct 1996 16:09:31 -0500 (CDT)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id QAA08793 for <xemacs-beta@cs.uiuc.edu>; Thu, 24 Oct 1996 16:09:25 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA15034; Thu, 24 Oct 1996 14:07:48 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA20767; Thu, 24 Oct 1996 14:07:45 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA11840; Thu, 24 Oct 1996 14:07:44 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA00541; Thu, 24 Oct 1996 14:07:43 -0700
Date: Thu, 24 Oct 1996 14:07:43 -0700
Message-Id: <199610242107.OAA00541@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@eng.sun.com>
To: kifer@cs.sunysb.edu (Michael Kifer)
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu
Subject: Re: keymaping/warning 
In-Reply-To: <199610241741.NAA20763@cs.sunysb.edu>
References: <m2u3rkl234.fsf@deanna.miranova.com>
	<199610241741.NAA20763@cs.sunysb.edu>
Reply-To: Martin Buchholz <mrb@eng.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Michael" == Michael Kifer <kifer@cs.sunysb.edu> writes:

Michael> I do practically the same thing:

Michael> xmodmap -e "remove Lock = Caps_Lock"	# stop locking -- less drastic
Michael> xmodmap -e "add Control = Caps_Lock"	# add control modifier to Caps_Lock

Michael> The only difference is that I am not changingt the keysym, but I don't
Michael> think it should matter.

The ICCCM specifically says it DOES matter:

ICCCM> Clients should determine the meaning of a modifier bit from the
ICCCM> KeySyms being used to control it.


Complete text follows:


A client that needs to use one of the preassigned  modifiers
should  assume  that  the  modifier  table  has  been set up
correctly to control these  modifiers.   The  Lock  modifier
should  be  interpreted as Caps Lock or Shift Lock according
as the keycodes in its controlling set include  XK_Caps_Lock
or XK_Shift_Lock.  Clients should determine the meaning of a
modifier bit from the KeySyms being used to control it.

A client that needs to use an extra modifier  (for  example,
META) should do the following:

o    Scan the existing modifier mappings.   If  it  finds  a
    modifier  that  contains  a keycode whose set of KeySyms
    includes XK_Meta_L or  XK_Meta_R,  it  should  use  that
    modifier bit.

 o    If  there  is  no  existing  modifier  controlled   by
    XK_Meta_L  or  XK_Meta_R,  it  should  select  an unused
    modifier bit (one with an empty controlling set) and  do
    the following:

    -     If there is a keycode with XL_Meta_L in its set of
         KeySyms, add that keycode to the set for the chosen
         modifier.

    -     If there is a keycode with XL_Meta_R in its set of
         KeySyms, add that keycode to the set for the chosen
         modifier.

    -     If the controlling set is  still  empty,  interact
         with  the  user  to  select  one or more keys to be
         META.

                             65

Inter-Client Communication Conventions        X11, Release 6

o    If there are no unused modifier bits, ask the  user  to
    take corrective action.

1.   Clients needing a modifier not currently in use  should
     assign  keycodes carrying suitable KeySyms to an unused
     modifier bit.

2.   Clients assigning their own modifier  bits  should  ask
     the  user  politely to remove his or her hands from the
     key in question if their request returns a status.

There is no good  solution  to  the  problem  of  reclaiming
assignments  to  the five nonpreassigned modifiers when they
are no longer being used.  The user must use or  some  other
utility to deassign obsolete modifier mappings by hand.

When a client succeeds in performing a request, all  clients
will  receive  events.  There is no mechanism for preventing
these events from being received.  A client that uses one of
the  nonpreassigned  modifiers  that  receives  one of these
events should do a request to discover the new mapping,  and
if  the  modifier  it  is  using has been cleared, it should
reinstall the modifier.


From xemacs-beta-request@cs.uiuc.edu  Fri Oct 25 05:54:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id FAA11557 for xemacs-beta-people; Fri, 25 Oct 1996 05:54:03 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id FAA11554 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 25 Oct 1996 05:54:02 -0500 (CDT)
Received: from sys4.cambridge.uk.psi.net (sys4.cambridge.uk.psi.net [154.32.106.14]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id FAA26930 for <xemacs-beta@cs.uiuc.edu>; Fri, 25 Oct 1996 05:54:01 -0500 (CDT)
From: rritchie@britannia-life.co.uk
Received: by sys4.cambridge.uk.psi.net (8.7.5/SMI-5.5-UKPSINet)
	id LAA21572; Fri, 25 Oct 1996 11:40:52 +0100 (BST)
Message-Id: <199610251040.LAA21572@sys4.cambridge.uk.psi.net>
Date: Fri, 25 Oct 1996 11:33:29 +0000
To: xemacs-beta@cs.uiuc.edu
Subject: Re: id-select.el - advanced syntactic re
MIME-version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
X-Mailer: TFS Gateway /222000000/222041150/222002160/222090538/

> Does this imply that we can now dump the thing.el currently in XEmacs?

> ;;; Synched up with: Not in FSF.
> ;;; #### FSF has thingatpt.el, which does the same thing.  Should merge
> ;;; or toss this.

> I'd vote for tossing it ...

I'd vote for keeping it.  mode-motion+ relies on it and I don't have time=20
right now
to port it to Bob's new world, however radically cool it is.  Perhaps soon,=
=20
perhaps not.

From xemacs-beta-request@cs.uiuc.edu  Fri Oct 25 08:52:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA11955 for xemacs-beta-people; Fri, 25 Oct 1996 08:52:53 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA11952 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 25 Oct 1996 08:52:52 -0500 (CDT)
Received: from nim.Positron.Qc.Ca (marcpa@[199.84.137.3]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id IAA02789 for <xemacs-beta@cs.uiuc.edu>; Fri, 25 Oct 1996 08:52:51 -0500 (CDT)
Received: (from marcpa@localhost) by nim.Positron.Qc.Ca (8.6.12/8.6.9) id JAA16296; Fri, 25 Oct 1996 09:52:55 -0400
Date: Fri, 25 Oct 1996 09:52:55 -0400
Message-Id: <199610251352.JAA16296@nim.Positron.Qc.Ca>
From: Paquette <marcpa@nim.Positron.Qc.Ca>
To: rritchie@britannia-life.co.uk
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: id-select.el - advanced syntactic re
In-Reply-To: <199610251040.LAA21572@sys4.cambridge.uk.psi.net>
References: <199610251040.LAA21572@sys4.cambridge.uk.psi.net>


rritchie@britannia-life.co.uk writes:
 > > Does this imply that we can now dump the thing.el currently in XEmacs?
 > 
 > > ;;; Synched up with: Not in FSF.
 > > ;;; #### FSF has thingatpt.el, which does the same thing.  Should merge
 > > ;;; or toss this.
 > 
 > > I'd vote for tossing it ...
 > 
 > I'd vote for keeping it.  mode-motion+ relies on it and I don't have time=20
 > right now
 > to port it to Bob's new world, however radically cool it is.  Perhaps soon,=
 > =20
 > perhaps not.
 >

Seconded (i.e. keep it), if anybody is counting.

-- 
Marc Paquette                              |  Positron Inc.
Concepteur de Logiciel/Software Engineer   |  Montreal, Quebec
marcpa@positron.qc.ca                      |  www.positroninc.com



From xemacs-beta-request@cs.uiuc.edu  Fri Oct 25 14:27:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA13295 for xemacs-beta-people; Fri, 25 Oct 1996 14:27:08 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA13292 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 25 Oct 1996 14:27:07 -0500 (CDT)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id OAA13274 for <xemacs-beta@cs.uiuc.edu>; Fri, 25 Oct 1996 14:27:01 -0500 (CDT)
Received: (qmail 25420 invoked by uid 501); 25 Oct 1996 19:29:44 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: How about session.el then? (was Re: id-select.el - advanced syntactic re)
References: <199610251040.LAA21572@sys4.cambridge.uk.psi.net> <199610251352.JAA16296@nim.Positron.Qc.Ca>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Paquette's message of Fri, 25 Oct 1996 09:52:55 -0400
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: text/plain; charset=US-ASCII
Date: 25 Oct 1996 12:29:43 -0700
Message-ID: <m2918uvo48.fsf_-_@deanna.miranova.com>
Lines: 19
X-Mailer: Red Gnus v0.52/XEmacs 19.15

>>>>> "Paquette" == Paquette  <marcpa@nim.Positron.Qc.Ca> writes:

Paquette> Seconded (i.e. keep it), if anybody is counting.

O.K.  You win.

Continuing in the same vein, how about eliminating
packages/session.el?

;;; Synched up with: Not in FSF.
;;; #### Chuck -- I think we should remove this.  It's dumb and stupid
;;; and there are at least two other packages we provide that do the
;;; same thing.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Fri Oct 25 15:19:07 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id PAA13499 for xemacs-beta-people; Fri, 25 Oct 1996 15:19:07 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA13496 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 25 Oct 1996 15:19:05 -0500 (CDT)
Received: from nim.Positron.Qc.Ca (marcpa@[199.84.137.3]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id PAA14737 for <xemacs-beta@cs.uiuc.edu>; Fri, 25 Oct 1996 15:19:05 -0500 (CDT)
Received: (from marcpa@localhost) by nim.Positron.Qc.Ca (8.6.12/8.6.9) id QAA27444; Fri, 25 Oct 1996 16:19:05 -0400
Date: Fri, 25 Oct 1996 16:19:05 -0400
Message-Id: <199610252019.QAA27444@nim.Positron.Qc.Ca>
From: Paquette <marcpa@nim.Positron.Qc.Ca>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: How about session.el then? (was Re: id-select.el - advanced syntactic re)
In-Reply-To: <m2918uvo48.fsf_-_@deanna.miranova.com>
References: <199610251040.LAA21572@sys4.cambridge.uk.psi.net>
	<199610251352.JAA16296@nim.Positron.Qc.Ca>
	<m2918uvo48.fsf_-_@deanna.miranova.com>

Steven L. Baur writes:
 > >>>>> "Paquette" == Paquette  <marcpa@nim.Positron.Qc.Ca> writes:
 > 
 > Paquette> Seconded (i.e. keep it), if anybody is counting.
 > 
 > O.K.  You win.
 > 
 > Continuing in the same vein, how about eliminating
 > packages/session.el?
 > 
 > ;;; Synched up with: Not in FSF.
 > ;;; #### Chuck -- I think we should remove this.  It's dumb and stupid
 > ;;; and there are at least two other packages we provide that do the
 > ;;; same thing.
 > 
 > -- 
 > steve@miranova.com baur
 > Unsolicited commercial e-mail will be billed at $250/message.
 > What are the last two letters of "doesn't" and "can't"?
 > Coincidence?  I think not.
 > 
-- 
Marc Paquette                              |  Positron Inc.
Concepteur de Logiciel/Software Engineer   |  Montreal, Quebec
marcpa@positron.qc.ca                      |  www.positroninc.com

From xemacs-beta-request@cs.uiuc.edu  Fri Oct 25 15:20:53 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id PAA13520 for xemacs-beta-people; Fri, 25 Oct 1996 15:20:53 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA13517 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 25 Oct 1996 15:20:52 -0500 (CDT)
Received: from nim.Positron.Qc.Ca (marcpa@[199.84.137.3]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id PAA14788 for <xemacs-beta@cs.uiuc.edu>; Fri, 25 Oct 1996 15:20:51 -0500 (CDT)
Received: (from marcpa@localhost) by nim.Positron.Qc.Ca (8.6.12/8.6.9) id QAA27480; Fri, 25 Oct 1996 16:20:40 -0400
Date: Fri, 25 Oct 1996 16:20:40 -0400
Message-Id: <199610252020.QAA27480@nim.Positron.Qc.Ca>
From: Paquette <marcpa@nim.Positron.Qc.Ca>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: How about session.el then? (was Re: id-select.el - advanced syntactic re)
In-Reply-To: <m2918uvo48.fsf_-_@deanna.miranova.com>
References: <199610251040.LAA21572@sys4.cambridge.uk.psi.net>
	<199610251352.JAA16296@nim.Positron.Qc.Ca>
	<m2918uvo48.fsf_-_@deanna.miranova.com>


Sorry about my previous message.

I vote for nuking session.el.

Steven L. Baur writes:
 > >>>>> "Paquette" == Paquette  <marcpa@nim.Positron.Qc.Ca> writes:
 > 
 > Paquette> Seconded (i.e. keep it), if anybody is counting.
 > 
 > O.K.  You win.
 > 
 > Continuing in the same vein, how about eliminating
 > packages/session.el?
 > 
 > ;;; Synched up with: Not in FSF.
 > ;;; #### Chuck -- I think we should remove this.  It's dumb and stupid
 > ;;; and there are at least two other packages we provide that do the
 > ;;; same thing.
 > 
 > -- 
 > steve@miranova.com baur
 > Unsolicited commercial e-mail will be billed at $250/message.
 > What are the last two letters of "doesn't" and "can't"?
 > Coincidence?  I think not.
 > 
-- 
Marc Paquette                              |  Positron Inc.
Concepteur de Logiciel/Software Engineer   |  Montreal, Quebec
marcpa@positron.qc.ca                      |  www.positroninc.com

From xemacs-beta-request@cs.uiuc.edu  Sat Oct 26 00:15:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA14804 for xemacs-beta-people; Sat, 26 Oct 1996 00:15:37 -0500 (CDT)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA14801 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 26 Oct 1996 00:15:35 -0500 (CDT)
Received: from sweden.aosi.com (mail.aosi.com [206.98.255.22]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA28571 for <xemacs-beta@xemacs.org>; Sat, 26 Oct 1996 00:15:30 -0500 (CDT)
Received: from hlork ([206.98.254.36]) by sweden.aosi.com
          (post.office MTA v1.9.3b ID# 0-16356) with SMTP id AAA103
          for <xemacs-beta@xemacs.org>; Sat, 26 Oct 1996 01:20:38 -0500
Sender: root@.aosi.com
Message-ID: <3271A01B.30B90253@aosi.com>
Date: Sat, 26 Oct 1996 01:22:36 -0400
From: Joel Peterson <tarzan@aosi.com>
Organization: Me Tarzan, you Jane?
X-Mailer: Mozilla 3.0 (X11; U; Linux 1.3.97 i586)
MIME-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: Window geometry
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I realize that 19.15 is in feature freeze, but I just wrote this and I thought
it was really cool.  I guess just place it in the database and consider it for
a future release.

Here's a patch that allows XEmacs to maintain window geometry when a frame is
resized.  It allows hints to be set for minimum size and for malleability (the
relative amount by which a window's size will change when the frame size is
changed).  Increasing the malleability of a window will cause XEmacs to try to
assign more of a frame resize to that window (and correspondingly less to the
rest of the windows).

The size minimums apply only to the window geometry and are treated as hints.
window-min-width and window-min-height are still the absolute minimums.
For that reason, I called the functions that set or return these values
by the opposite order; e.g. window-width-min.  Now that I think about it, I
probably should have the word `hint' in there.  I think this is a step in the
right direction, but ultimately, I think that the absolute minimum window height
and width should be a window specific parameter (ideally a specifier for frame
or window).  The global variables could still be used as limits on the window
specific minimums.

The goal of this was to fix the problem with, for example, the file dialog box,
where resizing the file dialog window could cause the window showing the `OK'
and `CANCEL' buttons to disappear.  This by itself is only a partial solution.
The final solution is some remake of window-min-width/window-min-height.  If
these are set to small values, then the new window geometry manager is an actual
solution to the problem.  The fix for the file dialog box is to set
window-min-height to 2 (the smallest value actually allowed by Emacs); then
call set-window-height-malleability to 0 for the button window in
mouse-read-file-name-1 in lisp/prim/minibuf.el.

This patch adds several new functions:

set-window-height-min
set-window-width-min
set-window-height-malleability
set-window-width-malleability
window-width-min
window-height-min
window-width-malleability
window-height-malleability
frame-window-width-min
frame-window-height-min

For more information on the use of these functions, see the documentation
strings in the source code.  All of the functions except the last two are related
directly to the window geometry hints.  The last two compute the minimum size
that a frame may be and still satisfy all of the constraints on the windows
displayed in that frame.

The patch also adds 2 new frame properties: min-width and min-height, which
specify the  minimum height and width that a frame may become.  It works
pre-emptively with X frames by telling the window manager not to allow frame
resizes to a size less than that given.  The minimums are also stored in the
frame structure in case other devices want to do something with them.
The values returned by frame-window-width-min and frame-window-height-min
are perfect for setting these properties.

The algorithm:
If the window geometry manager calculates that it cannot meet the minimum width
or height constraint, it immediately `punts' and uses the old algorithm instead.
Otherwise, it uses a three pass algorithm.  The first pass applies the frame
size recursively through the window tree.  It applies a weighted percentage of
the frame size change to each child of a window.  The weight is computed from
the malleability of each window.  The first pass continues until it finds a
window in which it cannot satisfy a width or height constraint.  If it can
satisfy all the constraints, it is done and returns.  If it finds a window that
it can't satisfy the constraint for, it stops and temporarily computes new
malleability factors for each window.  The new factors are re-weighted according
to the difference between each window's actual size and its minimum size hint.
It then repeats the first pass.  If that again fails, it loops through the
windows and repeatedly sets the most malleable window to its minimum size until
it reaches a point where the other windows will fit.

With no furthur ado, here's the patch:
--------------------------------------------------------------
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15-b2/src/emacsfns.h xemacs-19.15-b2-made/src/emacsfns.h
*** xemacs-19.15-b2/src/emacsfns.h      Thu Jun 20 20:56:16 1996
--- xemacs-19.15-b2-made/src/emacsfns.h Fri Oct 25 22:56:13 1996
***************
*** 1109,1114 ****
--- 1109,1116 ----
  
  extern Lisp_Object Qminibuffer;
  extern Lisp_Object Qunsplittable;
+ extern Lisp_Object Qmin_width;
+ extern Lisp_Object Qmin_height;
  extern Lisp_Object Qinternal_border_width;
  extern Lisp_Object Qtop_toolbar_shadow_color;
  extern Lisp_Object Qbottom_toolbar_shadow_color;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15-b2/src/frame-x.c xemacs-19.15-b2-made/src/frame-x.c
*** xemacs-19.15-b2/src/frame-x.c       Mon Sep 16 17:47:37 1996
--- xemacs-19.15-b2-made/src/frame-x.c  Sat Oct 26 00:04:12 1996
***************
*** 444,449 ****
--- 444,451 ----
    defi(Qborder_width, XtNborderWidth);
    defi(Qwidth, XtNwidth);
    defi(Qheight, XtNheight);
+   defi (Qmin_width, XtNminWidthCells);
+   defi (Qmin_height, XtNminHeightCells);
    defi(Qleft, XtNx);
    defi(Qtop, XtNy);
    
***************
*** 701,706 ****
--- 703,709 ----
    Bool x_position_specified_p = False;
    Bool y_position_specified_p = False;
    Bool internal_border_width_specified = False;
+   Bool minsize_specified_p = False;
    Lisp_Object tail;
    Widget w = FRAME_X_TEXT_WIDGET (f);
    
***************
*** 792,797 ****
--- 795,821 ----
              y_position_specified_p = True;
              continue;
            }
+         /* if minimum width or height changes, we need to change
+            the resources for the shell widget as well and call
+            EmacsShellUpdateSizeHints.
+            */
+         if (!strcmp ((char *) string_data (XSTRING (str)), "minWidthCells"))
+           {
+             minsize_specified_p = True;
+             CHECK_INT (val);
+             XtVaSetValues (FRAME_X_SHELL_WIDGET (f),
+                            (char *) string_data (XSTRING (str)),
+                            XINT (val), 0);
+           }
+         if (!strcmp ((char *) string_data (XSTRING (str)), "minHeightCells"))
+           {
+             minsize_specified_p = True;
+             CHECK_INT (val);
+             XtVaSetValues (FRAME_X_SHELL_WIDGET (f),
+                            (char *) string_data (XSTRING (str)),
+                            XINT (val), 0);
+           }
+         
          /* Have you figured out by now that this entire function is
               one gigantic kludge? */
          if (!strcmp ((char *) string_data (XSTRING (str)),
***************
*** 886,891 ****
--- 910,917 ----
          }
        }
    }
+   if (minsize_specified_p)
+     EmacsShellUpdateSizeHints (FRAME_X_SHELL_WIDGET (f));
  }
  
  static int frame_title_format_already_set;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15-b2/src/frame-x.c~ xemacs-19.15-b2-made/src/frame-x.c~
*** xemacs-19.15-b2/src/frame-x.c~      Wed Dec 31 19:00:00 1969
--- xemacs-19.15-b2-made/src/frame-x.c~ Fri Oct 25 22:56:13 1996
***************
*** 0 ****
--- 1,2402 ----
+ /* Functions for the X window system.
+    Copyright (C) 1989, 1992, 1993, 1994, 1995 Free Software Foundation, Inc.
+    Copyright (C) 1995, 1996 Ben Wing.
+ 
+ This file is part of XEmacs.
+ 
+ XEmacs is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+ 
+ XEmacs is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+ 
+ You should have received a copy of the GNU General Public License
+ along with XEmacs; see the file COPYING.  If not, write to
+ the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA.  */
+ 
+ /* Synched up with: Not synched with FSF. */
+ 
+ /* Substantially rewritten for XEmacs.  */
+ 
+ #include <config.h>
+ #include "lisp.h"
+ 
+ #include "console-x.h"
+ #include "xintrinsicp.h"      /* CoreP.h needs this */
+ #include <X11/CoreP.h>                /* Numerous places access the fields of
+                                  a core widget directly.  We could
+                                  use XtVaGetValues(), but ... */
+ #include <X11/Shell.h>
+ #include <X11/ShellP.h>
+ #include "xmu.h"
+ #include "EmacsManager.h"
+ #include "EmacsFrameP.h"
+ #include "EmacsShell.h"
+ #ifdef EXTERNAL_WIDGET
+ #include "ExternalShell.h"
+ #endif
+ #include "glyphs-x.h"
+ #include "objects-x.h"
+ #include "scrollbar-x.h"
+ 
+ #include "buffer.h"
+ #include "events.h"
+ #include "extents.h"
+ #include "faces.h"
+ #include "frame.h"
+ #include "window.h"
+ 
+ /* Default properties to use when creating frames.  */
+ Lisp_Object Vdefault_x_frame_plist;
+ 
+ Lisp_Object Qwindow_id;
+ Lisp_Object Qpopup;
+ Lisp_Object Qx_resource_name;
+ 
+ 
+ /************************************************************************/
+ /*                          helper functions                            */
+ /************************************************************************/
+ 
+ /* Return the Emacs frame-object corresponding to an X window */
+ struct frame *
+ x_window_to_frame (struct device *d, Window wdesc)
+ {
+   Lisp_Object tail, frame;
+   struct frame *f;
+ 
+   /* This function was previously written to accept only a window argument
+      (and to loop over all devices looking for a matching window), but
+      that is incorrect because window ID's are not unique across displays. */
+ 
+   for (tail = DEVICE_FRAME_LIST (d); CONSP (tail); tail = XCDR (tail))
+     {
+       frame = XCAR (tail);
+       if (!FRAMEP (frame))
+       continue;
+       f = XFRAME (frame);
+       if (FRAME_X_P (f) && XtWindow (FRAME_X_TEXT_WIDGET (f)) == wdesc)
+       return f;
+     }
+   return 0;
+ }
+ 
+ /* Like x_window_to_frame but also compares the window with the widget's
+    windows */
+ struct frame *
+ x_any_window_to_frame (struct device *d, Window wdesc)
+ {
+   Lisp_Object tail, frame;
+   struct frame *f;
+ 
+   assert (DEVICE_X_P (d));
+ 
+   /* This function was previously written to accept only a window argument
+      (and to loop over all devices looking for a matching window), but
+      that is incorrect because window ID's are not unique across displays. */
+ 
+   for (tail = DEVICE_FRAME_LIST (d); CONSP (tail); tail = XCDR (tail))
+     {
+       int i;
+ 
+       frame = XCAR (tail);
+       f = XFRAME (frame);
+       /* This frame matches if the window is any of its widgets. */
+       if (wdesc == XtWindow (FRAME_X_SHELL_WIDGET (f)) ||
+         wdesc == XtWindow (FRAME_X_CONTAINER_WIDGET (f)) ||
+         wdesc == XtWindow (FRAME_X_TEXT_WIDGET (f)))
+       return f;
+ 
+       /* Match if the window is one of the widgets at the top of the frame
+        (menubar, Energize psheets). */
+ 
+       /* Note: Jamie once said
+ 
+        "Do *not* match if the window is this frame's psheet."
+ 
+        But this is wrong and will screw up some functions that expect
+        x_any_window_to_frame() to work as advertised.  I think the reason
+        for this statement is that, in the old (broken) event loop, where
+        not all events went through XtDispatchEvent(), psheet events
+        would incorrectly get sucked away by Emacs if this function matched
+        on psheet widgets. */
+ 
+       for (i = 0; i < FRAME_X_NUM_TOP_WIDGETS (f); i++)
+       {
+         Widget wid = FRAME_X_TOP_WIDGETS (f)[i];
+         if (wid && XtIsManaged (wid) && wdesc == XtWindow (wid))
+           return f;
+       }
+ 
+ #ifdef HAVE_SCROLLBARS
+       /* Match if the window is one of this frame's scrollbars. */
+       if (x_window_is_scrollbar (f, wdesc))
+       return f;
+ #endif
+     }
+ 
+   return 0;
+ }
+ 
+ struct frame *
+ x_any_widget_or_parent_to_frame (struct device *d, Widget widget)
+ {
+   while (widget)
+     {
+       struct frame *f = x_any_window_to_frame (d, XtWindow (widget));
+       if (f)
+       return f;
+       widget = XtParent (widget);
+     }
+ 
+   return 0;
+ }
+ 
+ struct frame *
+ decode_x_frame (Lisp_Object frame)
+ {
+   if (NILP (frame))
+     XSETFRAME (frame, selected_frame ());
+   CHECK_LIVE_FRAME (frame);
+   /* this will also catch dead frames, but putting in the above check
+      results in a more useful error */
+   CHECK_X_FRAME (frame);
+   return XFRAME (frame);
+ }
+ 
+ 
+ /************************************************************************/
+ /*                    window-manager interactions                     */
+ /************************************************************************/
+ 
+ #if 0
+ /* Not currently used. */
+ 
+ void
+ x_wm_mark_shell_size_user_specified (Widget wmshell)
+ {
+   if (! XtIsWMShell (wmshell)) abort ();
+   EmacsShellSetSizeUserSpecified (wmshell);
+ }
+ 
+ void
+ x_wm_mark_shell_position_user_specified (Widget wmshell)
+ {
+   if (! XtIsWMShell (wmshell)) abort ();
+   EmacsShellSetPositionUserSpecified (wmshell);
+ }
+ 
+ #endif
+ 
+ void
+ x_wm_set_shell_iconic_p (Widget shell, int iconic_p)
+ {
+   if (! XtIsWMShell (shell)) abort ();
+ 
+   /* Because of questionable logic in Shell.c, this sequence can't work:
+ 
+        w = XtCreatePopupShell (...);
+        XtVaSetValues (w, XtNiconic, True, 0);
+        XtRealizeWidget (w);
+ 
+      The iconic resource is only consulted at initialization time (when
+      XtCreatePopupShell is called) instead of at realization time (just
+      before the window gets created, which would be more sensible) or
+      at management-time (just before the window gets mapped, which would
+      be most sensible of all).
+ 
+      The bug is that Shell's SetValues method doesn't do anything to
+      w->wm.wm_hints.initial_state until after the widget has been realized.
+      Calls to XtSetValues are ignored in the window between creation and
+      realization.  This is true of MIT X11R5 patch level 25, at least.
+      (Apparently some other versions of Xt don't have this bug?)
+    */
+   XtVaSetValues (shell, XtNiconic, iconic_p, 0);
+   EmacsShellSmashIconicHint (shell, iconic_p);
+ }
+ 
+ void
+ x_wm_set_cell_size (Widget wmshell, int cw, int ch)
+ {
+   if (!XtIsWMShell (wmshell))
+     abort ();
+   if (cw <= 0 || ch <= 0)
+     abort ();
+ 
+   XtVaSetValues (wmshell,
+                XtNwidthInc, cw, 
+                XtNheightInc, ch,
+                0);
+ }
+ 
+ void
+ x_wm_set_variable_size (Widget wmshell, int width, int height)
+ {
+   if (!XtIsWMShell (wmshell))
+     abort ();
+ #ifdef DEBUG_GEOMETRY_MANAGEMENT
+   /* See comment in EmacsShell.c */
+   printf ("x_wm_set_variable_size: %d %d\n", width, height);
+   fflush (stdout);
+ #endif
+   XtVaSetValues (wmshell,
+                XtNwidthCells, width,
+                XtNheightCells, height,
+                0);
+ }
+ 
+ /* If the WM_PROTOCOLS property does not already contain WM_TAKE_FOCUS
+    and WM_DELETE_WINDOW, then add them.  (They may already be present
+    because of the toolkit (Motif adds them, for example, but Xt doesn't).
+  */
+ static void
+ x_wm_hack_wm_protocols (Widget widget)
+ {
+   Display *dpy = XtDisplay (widget);
+   struct device *d = get_device_from_display (dpy);
+   Window w = XtWindow (widget);
+   int need_delete = 1;
+   int need_focus = 1;
+ 
+   if (!XtIsWMShell (widget))
+     abort ();
+ 
+   {
+     Atom type, *atoms = 0;
+     int format = 0;
+     unsigned long nitems = 0;
+     unsigned long bytes_after;
+ 
+     if (Success == XGetWindowProperty (dpy, w, DEVICE_XATOM_WM_PROTOCOLS (d),
+                                      0, 100, False, XA_ATOM,
+                                      &type, &format, &nitems, &bytes_after,
+                                      (unsigned char **) &atoms)
+       && format == 32 && type == XA_ATOM)
+       while (nitems > 0)
+       {
+         nitems--;
+         if (atoms [nitems] == DEVICE_XATOM_WM_DELETE_WINDOW (d))
+           need_delete = 0;
+         else if (atoms [nitems] == DEVICE_XATOM_WM_TAKE_FOCUS (d))
+           need_focus = 0;
+       }
+     if (atoms) XFree ((char *) atoms);
+   }
+   {
+     Atom props [10];
+     int count = 0;
+     if (need_delete) props[count++] = DEVICE_XATOM_WM_DELETE_WINDOW (d);
+     if (need_focus)  props[count++] = DEVICE_XATOM_WM_TAKE_FOCUS (d);
+     if (count)
+       XChangeProperty (dpy, w, DEVICE_XATOM_WM_PROTOCOLS (d), XA_ATOM, 32,
+                      PropModeAppend, (unsigned char *) props, count);
+   }
+ }
+ 
+ static void
+ x_wm_store_class_hints (Widget shell, char *frame_name)
+ {
+   Display *dpy = XtDisplay (shell);
+   char *app_name, *app_class;
+   XClassHint classhint;
+ 
+   if (!XtIsWMShell (shell))
+     abort ();
+ 
+   XtGetApplicationNameAndClass (dpy, &app_name, &app_class);
+   classhint.res_name = frame_name;
+   classhint.res_class = app_class;
+   XSetClassHint (dpy, XtWindow (shell), &classhint);
+ }
+ 
+ static void
+ x_wm_maybe_store_wm_command (struct frame *f)
+ {
+   Widget w = FRAME_X_SHELL_WIDGET (f);
+   struct device *d = XDEVICE (FRAME_DEVICE (f));
+ 
+   if (!XtIsWMShell (w))
+     abort ();
+ 
+   if (NILP (DEVICE_X_WM_COMMAND_FRAME (d)))
+     {
+       int argc;
+       char **argv;
+       make_argc_argv (Vcommand_line_args, &argc, &argv);
+       XSetCommand (XtDisplay (w), XtWindow (w), argv, argc);
+       free_argc_argv (argv);
+       XSETFRAME (DEVICE_X_WM_COMMAND_FRAME (d), f);
+     }
+ }
+ 
+ /* If we're deleting the frame on which the WM_COMMAND property has been
+    set, then move that property to another frame so that there is exactly
+    one frame that has that property set.
+  */
+ static void
+ x_wm_maybe_move_wm_command (struct frame *f)
+ {
+   struct device *d = XDEVICE (FRAME_DEVICE (f));
+ 
+   /* There may not be a frame in DEVICE_X_WM_COMMAND_FRAME()
+      if we C-c'ed at startup at the right time. */
+   if (FRAMEP (DEVICE_X_WM_COMMAND_FRAME (d))
+       && f == XFRAME (DEVICE_X_WM_COMMAND_FRAME (d)))
+     {
+       Lisp_Object rest = DEVICE_FRAME_LIST (d);
+       DEVICE_X_WM_COMMAND_FRAME (d) = Qnil;
+       /* find some random other X frame that is not this one, or give up */
+       /* skip non-top-level (ExternalClient) frames */
+       while (!NILP (rest) &&
+            (f == XFRAME (XCAR (rest)) ||
+             !FRAME_X_TOP_LEVEL_FRAME_P (XFRAME (XCAR (rest)))))
+       rest = XCDR (rest);
+       if (NILP (rest))
+       return;
+       f = XFRAME (XCAR (rest));
+       x_wm_maybe_store_wm_command (f);
+     }
+ }
+ 
+ static int
+ x_frame_iconified_p (struct frame *f)
+ {
+   Atom actual_type;
+   int actual_format;
+   unsigned long nitems, bytesafter;
+   unsigned long *datap = 0;
+   Widget widget;
+   int result = 0;
+   struct device *d = XDEVICE (FRAME_DEVICE (f));
+ 
+   widget = FRAME_X_SHELL_WIDGET (f);
+   if (Success == XGetWindowProperty (XtDisplay (widget), XtWindow (widget),
+                                    DEVICE_XATOM_WM_STATE (d), 0, 2, False,
+                                    DEVICE_XATOM_WM_STATE (d), &actual_type,
+                                    &actual_format, &nitems, &bytesafter,
+                                    (unsigned char **) &datap)
+       && datap)
+     {
+       if (nitems <= 2 /* "suggested" by ICCCM version 1 */
+         && datap[0] == IconicState)
+       result = 1;
+       XFree ((char *) datap);
+     }
+   return result;
+ }
+ 
+ 
+ /************************************************************************/
+ /*                          frame properties                            */
+ /************************************************************************/
+ 
+ /* Connect the frame-property names (symbols) to the corresponding
+    X Resource Manager names.  The name of a property, as a Lisp symbol,
+    has an `x-resource-name' property which is a Lisp_String. */
+ 
+ static void
+ init_x_prop_symbols (void)
+ {
+ #define def(sym, rsrc) \
+    pure_put (sym, Qx_resource_name, build_string (rsrc))
+ #define defi(sym,rsrc) \
+    def (sym, rsrc); pure_put (sym, Qintegerp, Qt)
+ 
+ #if 0 /* this interferes with things. #### fix this right */
+   def (Qminibuffer, XtNminibuffer);
+   def (Qunsplittable, XtNunsplittable);
+ #endif
+   defi(Qinternal_border_width, XtNinternalBorderWidth);
+ #ifdef HAVE_TOOLBARS
+   def (Qtop_toolbar_shadow_color, XtNtopToolBarShadowColor);
+   def (Qbottom_toolbar_shadow_color, XtNbottomToolBarShadowColor);
+   def (Qbackground_toolbar_color, XtNbackgroundToolBarColor);
+   def (Qtop_toolbar_shadow_pixmap, XtNtopToolBarShadowPixmap);
+   def (Qbottom_toolbar_shadow_pixmap, XtNbottomToolBarShadowPixmap);
+   defi(Qtoolbar_shadow_thickness, XtNtoolBarShadowThickness);
+ #endif
+   def (Qscrollbar_placement, XtNscrollBarPlacement);
+   defi(Qinter_line_space, XtNinterline);
+   /* font, foreground */
+   def (Qiconic, XtNiconic);
+   def (Qbar_cursor, XtNbarCursor);
+   def (Qvisual_bell, XtNvisualBell);
+   defi(Qbell_volume, XtNbellVolume);
+   def (Qpointer_background, XtNpointerBackground);
+   def (Qpointer_color, XtNpointerColor);
+   def (Qtext_pointer, XtNtextPointer);
+   def (Qspace_pointer, XtNspacePointer);
+   def (Qmodeline_pointer, XtNmodeLinePointer);
+   def (Qgc_pointer, XtNgcPointer);
+   /* geometry, initial_geometry */
+   def (Qinitially_unmapped, XtNinitiallyUnmapped);
+   /* preferred_width, preferred_height */
+   def (Quse_backing_store, XtNuseBackingStore);
+ 
+   /* inherited: */
+ 
+   def (Qborder_color, XtNborderColor);
+   defi(Qborder_width, XtNborderWidth);
+   defi(Qwidth, XtNwidth);
+   defi(Qheight, XtNheight);
+   defi (Qmin_width, XtNminWidthCells);
+   defi (Qmin_height, XtNminHeightCells);
+   defi(Qleft, XtNx);
+   defi(Qtop, XtNy);
+   
+ #undef def
+ }
+ 
+ static Lisp_Object
+ color_to_string (Widget w, unsigned long pixel)
+ {
+   char buf[255];
+ 
+   XColor color;
+   color.pixel = pixel;
+   XQueryColor (XtDisplay (w), w->core.colormap, &color);
+   sprintf (buf, "#%04x%04x%04x", color.red, color.green, color.blue);
+   return build_string (buf);
+ }
+ 
+ static void
+ x_get_top_level_position (Display *d, Window w, Position *x, Position *y)
+ {
+   Window root, parent = w, *children;
+   unsigned int nchildren;
+   XWindowAttributes xwa;
+ 
+   do
+     {
+       w = parent;
+       if (!XQueryTree (d, w, &root, &parent, &children, &nchildren))
+       {
+         *x = 0;
+         *y = 0;
+         return;
+       }
+       XFree (children);
+     }
+   while (root != parent);
+   XGetWindowAttributes (d, w, &xwa);
+   *x = xwa.x;
+   *y = xwa.y;
+ }
+ 
+ static void
+ x_smash_bastardly_shell_position (Widget shell)
+ {
+   /* Naturally those bastards who wrote Xt couldn't be bothered
+      to learn about race conditions and such.  We can't trust
+      the X and Y values to have any semblance of correctness,
+      so we smash the right values in place. */
+  
+  /* We might be called before we've actually realized the window (if
+      we're checking for the minibuffer resource).  This will bomb in
+      that case so we don't bother calling it. */
+   if (XtWindow (shell))
+     x_get_top_level_position (XtDisplay (shell), XtWindow (shell),
+                             &shell->core.x, &shell->core.y);
+ }
+ 
+ static Lisp_Object
+ x_frame_property (struct frame *f, Lisp_Object property)
+ {
+   Widget shell = FRAME_X_SHELL_WIDGET (f);
+   EmacsFrame w = (EmacsFrame) FRAME_X_TEXT_WIDGET (f);
+   Widget gw = (Widget) w;
+ 
+ #define FROB(propprop, value)         \
+ do {                          \
+   if (EQ (property, propprop))        \
+     {                         \
+       return (value);         \
+     }                         \
+ } while (0)
+ 
+   if (EQ (property, Qleft) || EQ (property, Qtop))
+     x_smash_bastardly_shell_position (shell);
+   FROB (Qleft, make_int (shell->core.x));
+   FROB (Qtop, make_int (shell->core.y));
+   FROB (Qborder_width, make_int (w->core.border_width));
+   FROB (Qinternal_border_width,
+       make_int (w->emacs_frame.internal_border_width));
+   FROB (Qborder_color, color_to_string (gw, w->core.border_pixel));
+ #ifdef HAVE_TOOLBARS
+   FROB (Qtop_toolbar_shadow_color,
+       color_to_string (gw, w->emacs_frame.top_toolbar_shadow_pixel));
+   FROB (Qbottom_toolbar_shadow_color,
+       color_to_string (gw, w->emacs_frame.bottom_toolbar_shadow_pixel));
+   FROB (Qbackground_toolbar_color,
+       color_to_string (gw, w->emacs_frame.background_toolbar_pixel));
+   FROB (Qtoolbar_shadow_thickness,
+       make_int (w->emacs_frame.toolbar_shadow_thickness));
+ #endif
+   FROB (Qinter_line_space, make_int (w->emacs_frame.interline));
+   FROB (Qwindow_id, Fx_window_id (make_frame (f)));
+ 
+ #undef FROB
+ 
+   return Qunbound;
+ }
+ 
+ static int
+ x_internal_frame_property_p (struct frame *f, Lisp_Object property)
+ {
+   if (EQ (property, Qleft)
+       || EQ (property, Qtop)
+       || EQ (property, Qborder_width)
+       || EQ (property, Qinternal_border_width)
+       || EQ (property, Qborder_color)
+ #ifdef HAVE_TOOLBARS
+       || EQ (property, Qtop_toolbar_shadow_color)
+       || EQ (property, Qbottom_toolbar_shadow_color)
+       || EQ (property, Qbackground_toolbar_color)
+       || EQ (property, Qtoolbar_shadow_thickness)
+ #endif
+       || EQ (property, Qinter_line_space)
+       || EQ (property, Qwindow_id)
+       || STRINGP (property))
+     return 1;
+ 
+   return 0;
+ }
+ 
+ static Lisp_Object
+ x_frame_properties (struct frame *f)
+ {
+   Lisp_Object result = Qnil;
+   Widget shell = FRAME_X_SHELL_WIDGET (f);
+   EmacsFrame w = (EmacsFrame) FRAME_X_TEXT_WIDGET (f);
+   Widget gw = (Widget) w;
+ 
+ #define FROB(propprop, value)                         \
+ do {                                                  \
+   Lisp_Object temtem = (value);                               \
+   if (!NILP (temtem))                                 \
+     /* backwards order; we reverse it below */                \
+     result = Fcons (temtem, Fcons (propprop, result));        \
+ } while (0)
+ 
+   x_smash_bastardly_shell_position (shell);
+   FROB (Qleft, make_int (shell->core.x));
+   FROB (Qtop, make_int (shell->core.y));
+   FROB (Qborder_width, make_int (w->core.border_width));
+   FROB (Qinternal_border_width,
+       make_int (w->emacs_frame.internal_border_width));
+   FROB (Qborder_color, color_to_string (gw, w->core.border_pixel));
+ #ifdef HAVE_TOOLBARS
+   FROB (Qtop_toolbar_shadow_color,
+       color_to_string (gw, w->emacs_frame.top_toolbar_shadow_pixel));
+   FROB (Qbottom_toolbar_shadow_color,
+       color_to_string (gw, w->emacs_frame.bottom_toolbar_shadow_pixel));
+   FROB (Qbackground_toolbar_color,
+       color_to_string (gw, w->emacs_frame.background_toolbar_pixel));
+   FROB (Qtoolbar_shadow_thickness,
+       make_int (w->emacs_frame.toolbar_shadow_thickness));
+ #endif
+   FROB (Qinter_line_space, make_int (w->emacs_frame.interline));
+   FROB (Qwindow_id, Fx_window_id (make_frame (f)));
+ 
+ #undef FROB
+ 
+   return result;
+ }
+ 
+ 
+ /* Functions called only from `x_set_frame_properties' to set
+    individual properties. */
+ 
+ static void
+ x_set_frame_text_value (struct frame *f, Bufbyte *value,
+                       String Xt_resource_name,
+                       String Xt_resource_encoding_name)
+ {
+   Atom encoding = XA_STRING;
+   String new_XtValue = (String) value;
+   String old_XtValue;
+   Bufbyte *ptr;
+   Arg av[2];
+ 
+   /* ### Caching is device-independent - belongs in update_frame_title. */
+   XtSetArg (av[0], Xt_resource_name, &old_XtValue);
+   XtGetValues (FRAME_X_SHELL_WIDGET (f), av, 1);
+   if (!old_XtValue || strcmp (new_XtValue, old_XtValue))
+     {
+       XtSetArg (av[0], Xt_resource_name, new_XtValue);
+       XtSetArg (av[1], Xt_resource_encoding_name, encoding);
+       XtSetValues (FRAME_X_SHELL_WIDGET (f), av, 2);
+     }
+ }
+ 
+ static void 
+ x_set_title_from_bufbyte (struct frame *f, Bufbyte *name)
+ {
+   x_set_frame_text_value (f, name, XtNtitle, XtNtitleEncoding);
+ }
+ 
+ static void
+ x_set_icon_name_from_bufbyte (struct frame *f, Bufbyte *name)
+ {
+   x_set_frame_text_value (f, name, XtNiconName, XtNiconNameEncoding);
+ }
+ 
+ /* Set the initial frame size as specified.  This function is used
+    when the frame's widgets have not yet been realized.  In this
+    case, it is not sufficient just to set the width and height of
+    the EmacsFrame widget, because they will be ignored when the
+    widget is realized (instead, the shell's geometry resource is
+    used). */
+ 
+ static void
+ x_set_initial_frame_size (struct frame *f, int flags, int x, int y,
+                         unsigned int w, unsigned int h)
+ {
+   char shell_geom [255];
+   int xval, yval;
+   char xsign, ysign;
+   char uspos = !!(flags & (XValue | YValue));
+   char ussize = !!(flags & (WidthValue | HeightValue));
+   char *temp;
+ 
+   /* assign the correct size to the EmacsFrame widget ... */
+   EmacsFrameSetCharSize (FRAME_X_TEXT_WIDGET (f), w, h);
+ 
+   /* and also set the WMShell's geometry */
+   (flags & XNegative) ? (xval = -x, xsign = '-') : (xval = x, xsign = '+');
+   (flags & YNegative) ? (yval = -y, ysign = '-') : (yval = y, ysign = '+');
+   
+   if (uspos && ussize)
+     sprintf (shell_geom, "=%dx%d%c%d%c%d", w, h, xsign, xval, ysign, yval);
+   else if (uspos)
+     sprintf (shell_geom, "=%c%d%c%d", xsign, xval, ysign, yval);
+   else if (ussize)
+     sprintf (shell_geom, "=%dx%d", w, h);
+   
+   if (uspos || ussize)
+     {
+       temp = xmalloc (1 + strlen (shell_geom));
+       strcpy (temp, shell_geom);
+       FRAME_X_GEOM_FREE_ME_PLEASE (f) = temp;
+     }
+   else
+     temp = NULL;
+   XtVaSetValues (FRAME_X_SHELL_WIDGET (f), XtNgeometry, temp, 0);
+ }
+ 
+ /* Report to X that a frame property of frame S is being set or changed.
+    If the property is not specially recognized, do nothing.
+  */
+ 
+ static void
+ x_set_frame_properties (struct frame *f, Lisp_Object plist)
+ {
+   int x = 0, y = 0;
+   Dimension width = 0, height = 0;
+   Bool width_specified_p = False;
+   Bool height_specified_p = False;
+   Bool x_position_specified_p = False;
+   Bool y_position_specified_p = False;
+   Bool internal_border_width_specified = False;
+   Bool minsize_specified_p = False;
+   Lisp_Object tail;
+   Widget w = FRAME_X_TEXT_WIDGET (f);
+   
+   for (tail = plist; !NILP (tail); tail = Fcdr (Fcdr (tail)))
+     {
+       Lisp_Object prop = Fcar (tail);
+       Lisp_Object val = Fcar (Fcdr (tail));
+       
+       if (STRINGP (prop))
+       {
+         CONST char *extprop;
+         
+         if (string_length (XSTRING (prop)) == 0)
+           continue;
+ 
+         GET_C_STRING_CTEXT_DATA_ALLOCA (prop, extprop);
+         if (STRINGP (val))
+           {
+             Extbyte *extval;
+             Extcount extvallen;
+ 
+             GET_STRING_CTEXT_DATA_ALLOCA (val, extval, extvallen);
+             XtVaSetValues (w, XtVaTypedArg, extprop,
+                            XtRString, extval, extvallen + 1, 0);
+           }
+         else
+           XtVaSetValues (w, XtVaTypedArg,
+                          extprop, XtRInt, XINT (val),
+                          sizeof (int),
+                          0);
+       }
+       else if (SYMBOLP (prop))
+       {
+         Lisp_Object str = Fget (prop, Qx_resource_name, Qnil);
+         int int_p = !NILP (Fget (prop, Qintegerp, Qnil));
+ 
+         if (NILP (prop) || NILP (str))
+           {
+             /* Kludge to handle the font property. */
+             if (EQ (prop, Qfont))
+               {
+                 /* If the value is not a string we silently ignore it. */
+                 if (STRINGP (val))
+                   {
+                     Lisp_Object frm, font_spec;
+ 
+                     XSETFRAME (frm, f);
+                     font_spec = Fget (Fget_face (Qdefault), Qfont, Qnil);
+ 
+                     Fadd_spec_to_specifier (font_spec, val, frm, Qnil, Qnil);
+                     update_frame_face_values (f);
+                   }
+ 
+                 continue;
+               }
+             else
+               continue;
+           }
+         CHECK_STRING (str);
+ 
+         /* Kludge the width/height so that we interpret them in characters
+            instead of pixels.  Yuck yuck yuck. */
+         if (!strcmp ((char *) string_data (XSTRING (str)), "width"))
+           {
+             CHECK_INT (val);
+             width = XINT (val);
+             width_specified_p = True;
+             continue;
+           }
+         if (!strcmp ((char *) string_data (XSTRING (str)), "height"))
+           {
+             CHECK_INT (val);
+             height = XINT (val);
+             height_specified_p = True;
+             continue;
+           }
+         /* Further kludge the x/y. */
+         if (!strcmp ((char *) string_data (XSTRING (str)), "x"))
+           {
+             CHECK_INT (val);
+             x = XINT (val);
+             x_position_specified_p = True;
+             continue;
+           }
+         if (!strcmp ((char *) string_data (XSTRING (str)), "y"))
+           {
+             CHECK_INT (val);
+             y = XINT (val);
+             y_position_specified_p = True;
+             continue;
+           }
+         /* if minimum width or height changes, we need to change
+            the resources for the shell widget as well and call
+            EmacsShellUpdateSizeHints.
+            */
+         if (!strcmp ((char *) string_data (XSTRING (str)), "minWidthCells"))
+           {
+             minsize_specified_p = True;
+             CHECK_INT (val);
+             XtVaSetValues (FRAME_X_SHELL_WIDGET (f),
+                            (char *) string_data (XSTRING (str)),
+                            XINT (val), 0);
+           }
+         if (!strcmp ((char *) string_data (XSTRING (str)), "minHeightCells"))
+           {
+             minsize_specified_p = True;
+             CHECK_INT (val);
+             XtVaSetValues (FRAME_X_SHELL_WIDGET (f),
+                            (char *) string_data (XSTRING (str)),
+                            XINT (val), 0);
+           }
+         
+         /* Have you figured out by now that this entire function is
+              one gigantic kludge? */
+         if (!strcmp ((char *) string_data (XSTRING (str)),
+                      "internalBorderWidth"))
+           {
+             internal_border_width_specified = True;
+           }
+ 
+         if (int_p)
+           {
+             CHECK_INT (val);
+             XtVaSetValues (w, (char *) string_data (XSTRING (str)),
+                            XINT (val), 0);
+           }
+         else if (EQ (val, Qt))
+           XtVaSetValues (w,
+                          /* XtN... */
+                          (char *) string_data (XSTRING (str)),
+                          True,
+                          0);
+         else if (EQ (val, Qnil))
+           XtVaSetValues (w,
+                          /* XtN... */
+                          (char *) string_data (XSTRING (str)),
+                          False,
+                          0);
+         else
+           {
+             CHECK_STRING (val);
+             XtVaSetValues (w, XtVaTypedArg,
+                            /* XtN... */
+                            (char *) string_data (XSTRING (str)),
+                            XtRString,
+                            string_data (XSTRING (val)),
+                            string_length (XSTRING (val)) + 1,
+                            0);
+           }
+ 
+ #ifdef HAVE_SCROLLBARS
+         if (!strcmp ((char *) string_data (XSTRING (str)), "scrollBarWidth")
+             || !strcmp ((char *) string_data (XSTRING (str)),
+                         "scrollBarHeight"))
+           {
+             x_update_frame_scrollbars (f);
+           }
+ #endif
+       }
+     }
+ 
+   /* Kludge kludge kludge.   We need to deal with the size and position
+    specially. */
+   {
+     int size_specified_p = width_specified_p || height_specified_p;
+     int position_specified_p = x_position_specified_p ||
+       y_position_specified_p;
+ 
+     if (!width_specified_p)
+       width = FRAME_WIDTH (f);
+     if (!height_specified_p)
+       height = FRAME_HEIGHT (f);
+     
+     /* Kludge kludge kludge kludge. */
+     if (!x_position_specified_p)
+       x = (int) (FRAME_X_SHELL_WIDGET (f)->core.x);
+     if (!y_position_specified_p)
+       y = (int) (FRAME_X_SHELL_WIDGET (f)->core.y);
+       
+     if (!f->init_finished)
+       {
+       int flags = (size_specified_p ? WidthValue | HeightValue : 0) |
+         (position_specified_p ? XValue | YValue : 0) |
+         (x < 0 ? XNegative : 0) | (y < 0 ? YNegative : 0);
+       if (size_specified_p
+           || position_specified_p
+           || internal_border_width_specified)
+         x_set_initial_frame_size (f, flags, x, y, width, height);
+       }
+     else
+       {
+       if (size_specified_p || internal_border_width_specified)
+         {
+           Lisp_Object frame;
+           XSETFRAME (frame, f);
+           Fset_frame_size (frame, make_int (width),
+                             make_int (height), Qnil);
+         }
+       if (position_specified_p)
+         {
+           Lisp_Object frame;
+           XSETFRAME (frame, f);
+           Fset_frame_position (frame, make_int (x), make_int (y));
+         }
+       }
+   }
+   if (minsize_specified_p)
+     {
+       /* MARK ??? */
+       EmacsShellUpdateSizeHints (FRAME_X_SHELL_WIDGET (f));
+     }
+ }
+ 
+ static int frame_title_format_already_set;
+ 
+ static void
+ maybe_set_frame_title_format (Widget shell)
+ {
+ 
+   /* Only do this if this is the first X frame we're creating.
+      
+      If the *title resource (or -title option) was specified, then
+      set frame-title-format to its value.
+      */
+ 
+   if (!frame_title_format_already_set)
+     {
+       /* No doubt there's a less stupid way to do this. */
+       char *results [2];
+       XtResource resources [2];
+       results [0] = results [1] = 0;
+       resources [0].resource_name = XtNtitle;
+       resources [0].resource_class = XtCTitle;
+       resources [0].resource_type = XtRString;
+       resources [0].resource_size = sizeof (String);
+       resources [0].resource_offset = 0;
+       resources [0].default_type = XtRString;
+       resources [0].default_addr = 0;
+       resources [1].resource_name = XtNiconName;
+       resources [1].resource_class = XtCIconName;
+       resources [1].resource_type = XtRString;
+       resources [1].resource_size = sizeof (String);
+       resources [1].resource_offset = sizeof (char *);
+       resources [1].default_type = XtRString;
+       resources [1].default_addr = 0;
+       XtGetSubresources (XtParent (shell), (XtPointer) results,
+                        shell->core.name,
+                        shell->core.widget_class->core_class.class_name,
+                        resources, XtNumber (resources), 0, 0);
+       if (results[0])
+       Vframe_title_format = build_string (results[0]);
+       if (results[1])
+       Vframe_icon_title_format = build_string (results[1]);
+     }
+ 
+   frame_title_format_already_set = 1;
+ }
+ 
+ #ifdef HAVE_CDE
+ #include <Dt/Dt.h>
+ #include <Dt/Dnd.h>
+ 
+ void
+ x_cde_transfer_callback (Widget widget, XtPointer clientData,
+                        XtPointer callData)
+ {
+   char *filePath, *buf, *data;
+   int ii;
+   Lisp_Object path = Qnil;
+   Lisp_Object frame = Qnil;
+   struct gcpro gcpro1, gcpro2;
+     
+   DtDndTransferCallbackStruct *transferInfo =
+     (DtDndTransferCallbackStruct *) callData;
+ 
+   if (transferInfo == NULL)
+     return;
+       
+   GCPRO2 (path, frame);
+     
+   frame = make_frame ((struct frame *) clientData);
+   if (transferInfo->dropData->protocol == DtDND_FILENAME_TRANSFER)
+     {
+       for (ii = 0; ii < transferInfo->dropData->numItems; ii++) 
+       {
+         filePath = transferInfo->dropData->data.files[ii];
+         path = make_string (filePath, strlen (filePath));
+         va_run_hook_with_args (Qdrag_and_drop_functions, 2, frame, path);
+       }
+     }
+   else if (transferInfo->dropData->protocol == DtDND_BUFFER_TRANSFER)
+     {
+       for (ii = 0; ii < transferInfo->dropData->numItems; ii++)
+       {
+         filePath = transferInfo->dropData->data.buffers[ii].name;
+         path = (filePath != NULL) ?
+             make_string (filePath, strlen (filePath)) : Qnil;
+         buf = transferInfo->dropData->data.buffers[ii].bp;
+         data = make_string (buf, transferInfo->dropData->data.buffers[ii].size);
+         va_run_hook_with_args(Qdrag_and_drop_functions, 3, frame, path, data);
+       }
+     }
+ 
+   UNGCPRO;
+   return;
+ }
+ #endif
+ 
+ #ifdef HAVE_OFFIX_DND
+ #include <OffiX/DragAndDrop.h>
+ 
+ void 
+ x_offix_drop_event_handler (Widget widget, XtPointer data, XEvent *event,
+                           Boolean *b)
+ {
+   int i, len, Type;   
+   unsigned char *Data;
+   unsigned long Size;
+ 
+   Lisp_Object path = Qnil;
+   Lisp_Object frame = Qnil;
+ 
+   struct gcpro gcpro1, gcpro2;
+ 
+   Type = DndDataType (event); 
+   if ((Type != DndFile) && (Type != DndFiles) && (Type != DndExe))
+     return;
+   DndGetData (&Data, &Size);
+   
+   GCPRO2 (path, frame);
+ 
+   frame = make_frame ((struct frame *) data);
+ 
+   if (Type == DndFiles)
+     {
+       while (*Data)
+       {
+         len = strlen ((char*) Data);
+         path = make_string ((char*) Data, len);
+         va_run_hook_with_args (Qdrag_and_drop_functions, 2, frame, path);
+         Data += len+1;
+       }
+     }
+   else
+     {
+       path = make_string ((char*) Data, strlen (Data));    
+       va_run_hook_with_args (Qdrag_and_drop_functions, 2, frame, path);
+     }
+ 
+   UNGCPRO;
+   return;
+ }
+ #endif /* HAVE_OFFIX_DND */
+ 
+ 
+ /************************************************************************/
+ /*                            widget creation                         */
+ /************************************************************************/
+ 
+ /* The widget hierarchy is
+ 
+       argv[0]                 shell           container       FRAME-NAME
+       ApplicationShell        EmacsShell      EmacsManager    EmacsFrame
+ 
+    We accept geometry specs in this order:
+ 
+       *FRAME-NAME.geometry
+       *EmacsFrame.geometry
+       Emacs.geometry
+ 
+    Other possibilities for widget hierarchies might be
+ 
+       argv[0]                 frame           container       FRAME-NAME
+       ApplicationShell        EmacsShell      EmacsManager    EmacsFrame
+    or
+       argv[0]                 FRAME-NAME      container       FRAME-NAME
+       ApplicationShell        EmacsShell      EmacsManager    EmacsFrame
+    or
+       argv[0]                 FRAME-NAME      container       emacsTextPane
+       ApplicationShell        EmacsShell      EmacsManager    EmacsFrame
+ 
+ #ifdef EXTERNAL_WIDGET
+    The ExternalShell widget is simply a replacement for the Shell widget 
+    which is able to deal with using an externally-supplied window instead
+    of always creating its own.
+ #endif
+ 
+ */
+ 
+ #ifdef EXTERNAL_WIDGET
+ 
+ static int
+ is_valid_window (Window w, struct device *d)
+ {
+   XWindowAttributes xwa;
+   Display *dpy = DEVICE_X_DISPLAY (d);
+ 
+   expect_x_error (dpy);
+   XGetWindowAttributes (dpy, w, &xwa);
+   return !x_error_occurred_p (dpy);
+ }
+ 
+ #endif /* EXTERNAL_WIDGET */
+ 
+ /* This sends a synthetic mouse-motion event to the frame, if the mouse
+    is over the frame.  This ensures that the cursor gets set properly
+    before the user moves the mouse for the first time. */
+ 
+ static void
+ x_send_synthetic_mouse_event (struct frame *f)
+ {
+   /* #### write this function. */
+ }
+ 
+ static int
+ first_x_frame_p (struct frame *f)
+ {
+   Lisp_Object rest = DEVICE_FRAME_LIST (XDEVICE (f->device));
+   while (!NILP (rest) &&
+        (f == XFRAME (XCAR (rest)) ||
+         !FRAME_X_P (XFRAME (XCAR (rest)))))
+     rest = XCDR (rest);
+   return (NILP (rest));
+ }
+ 
+ /* Figure out what size the EmacsFrame widget should initially be,
+    and set it.  Should be called after the default font has been
+    determined but before the widget has been realized. */
+ 
+ static void
+ x_initialize_frame_size (struct frame *f)
+ {
+   /* Geometry of the AppShell */
+   int app_flags = 0;
+   int app_x = 0;
+   int app_y = 0;
+   unsigned int app_w = 0;
+   unsigned int app_h = 0;
+   
+   /* Geometry of the EmacsFrame */
+   int frame_flags = 0;
+   int frame_x = 0;
+   int frame_y = 0;
+   unsigned int frame_w = 0;
+   unsigned int frame_h = 0;
+   
+   /* Hairily merged geometry */
+   int x = 0;
+   int y = 0;
+   unsigned int w = 80;
+   unsigned int h = 40;
+   int flags = 0;
+ 
+   char *geom = 0, *ew_geom = 0;
+   Boolean iconic_p = False, ew_iconic_p = False;
+ 
+   Widget wmshell = FRAME_X_SHELL_WIDGET (f);
+   /* #### This may not be an ApplicationShell any more, with the 'popup
+      frame property. */
+   Widget app_shell = XtParent (wmshell);
+   Widget ew = FRAME_X_TEXT_WIDGET (f);
+ 
+ /* set the position of the frame's root window now.  When the
+    frame was created, the position was initialized to (0,0). */
+   {
+     struct window *win = XWINDOW (f->root_window);
+ 
+     WINDOW_LEFT (win) = FRAME_LEFT_BORDER_END (f);
+     WINDOW_TOP (win) = FRAME_TOP_BORDER_END (f);
+ 
+     if (!NILP (f->minibuffer_window))
+       {
+       win = XWINDOW (f->minibuffer_window);
+       WINDOW_LEFT (win) = FRAME_LEFT_BORDER_END (f);
+       }
+   }
+ 
+ #ifdef EXTERNAL_WIDGET
+   /* If we're an external widget, then the size of the frame is predetermined
+      (by the client) and is not our decision to make. */
+   if (FRAME_X_EXTERNAL_WINDOW_P (f))
+     return;
+ #endif
+ 
+ #if 0
+   /* #### this junk has not been tested; therefore it's
+      probably wrong.  Doesn't really matter at this point because
+      currently all frames are either top-level or external widgets. */
+ 
+   /* If we're not our own top-level window, then we shouldn't go messing around
+      with top-level shells or "Emacs.geometry" or any such stuff.  Therefore,
+      we do as follows to determine the size of the frame:
+ 
+      1) If a value for the frame's "geometry" resource was specified, then
+         use it.  (This specifies a size in characters.)
+      2) Else, if the "width" and "height" resources were specified, then
+         leave them alone.  (This is a value in pixels.  Sorry, we can't break
+       Xt conventions here.)
+      3) Else, assume a size of 64x12.  (This is somewhat arbitrary, but
+         it's unlikely that a size of 80x40 is desirable because we're probably
+       inside of a dialog box.)
+ 
+      Set the widget's x, y, height, and width as determined.  Don't set the
+      top-level container widget, because we don't necessarily know what it
+      is. (Assume it is smart and pays attention to our values.)
+   */
+ 
+   if (!FRAME_X_TOP_LEVEL_FRAME_P (f))
+     {
+       XtVaGetValues (ew, XtNgeometry, &ew_geom, 0);
+       if (ew_geom)
+       frame_flags = XParseGeometry (ew_geom, &frame_x, &frame_y,
+                                      &frame_w, &frame_h);
+       if (! (frame_flags & (WidthValue | HeightValue)))
+       {
+         XtVaGetValues (ew, XtNwidth, &frame_w,
+                        XtNheight, &frame_h, 0);
+         if (!frame_w && !frame_h)
+           {
+             frame_w = 64;
+             frame_h = 12;
+             frame_flags |= WidthValue | HeightValue;
+           }
+       }
+       if (frame_flags & (WidthValue | HeightValue))
+       EmacsFrameSetCharSize (ew, frame_w, frame_h);
+       if (frame_flags & (XValue | YValue))
+       {
+         XtVaGetValues (ew, XtNwidth, &frame_w,
+                        XtNheight, &frame_h, 0);
+         if (frame_flags & XNegative)
+           frame_x += frame_w;
+         if (frame_flags & YNegative)
+           frame_y += frame_h;
+         XtVaSetValues (ew, XtNx, frame_x, XtNy, frame_y, 0);
+       }
+       return;
+     }
+ #endif
+ 
+   /* OK, we're a top-level shell. */
+ 
+   if (!XtIsWMShell (wmshell))
+     abort ();
+ 
+   /* If the EmacsFrame doesn't have a geometry but the shell does,
+      treat that as the geometry of the frame.  (Is this bogus?
+      I'm not sure.) */
+ 
+   XtVaGetValues (ew, XtNgeometry, &ew_geom, 0);
+   if (!ew_geom)
+     {
+       XtVaGetValues (wmshell, XtNgeometry, &geom, 0);
+       if (geom)
+       {
+         ew_geom = geom;
+         XtVaSetValues (ew, XtNgeometry, ew_geom, 0);
+       }
+     }
+ 
+   /* If the Shell is iconic, then the EmacsFrame is iconic.  (Is
+      this bogus? I'm not sure.) */
+   XtVaGetValues (ew, XtNiconic, &ew_iconic_p, 0);
+   if (!ew_iconic_p)
+     {
+       XtVaGetValues (wmshell, XtNiconic, &iconic_p, 0);
+       if (iconic_p)
+       {
+         ew_iconic_p = iconic_p;
+         XtVaSetValues (ew, XtNiconic, iconic_p, 0);
+       }
+     }
+   
+   XtVaGetValues (app_shell, XtNgeometry, &geom, 0);
+   if (geom)
+     app_flags = XParseGeometry (geom, &app_x, &app_y, &app_w, &app_h);
+ 
+   if (ew_geom)
+     frame_flags = XParseGeometry (ew_geom, &frame_x, &frame_y,
+                                  &frame_w, &frame_h);
+   
+   if (first_x_frame_p (f))
+     {
+       /* If this is the first frame created:
+          ====================================
+ 
+          - Use the ApplicationShell's size/position, if specified.
+            (This is "Emacs.geometry", or the "-geometry" command line arg.)
+          - Else use the EmacsFrame's size/position.
+            (This is "*FRAME-NAME.geometry")
+ 
+        - If the AppShell is iconic, the frame should be iconic.
+ 
+        AppShell comes first so that -geometry always applies to the first
+        frame created, even if there is an "every frame" entry in the
+        resource database.
+        */
+       if (app_flags & (XValue | YValue))
+       {
+         x = app_x; y = app_y;
+         flags |= (app_flags & (XValue | YValue | XNegative | YNegative));
+       }
+       else if (frame_flags & (XValue | YValue))
+       {
+         x = frame_x; y = frame_y;
+         flags |= (frame_flags & (XValue | YValue | XNegative | YNegative));
+       }
+ 
+       if (app_flags & (WidthValue | HeightValue))
+       {
+         w = app_w; h = app_h;
+         flags |= (app_flags & (WidthValue | HeightValue));
+       }
+       else if (frame_flags & (WidthValue | HeightValue))
+       {
+         w = frame_w; h = frame_h;
+         flags |= (frame_flags & (WidthValue | HeightValue));
+       }
+ 
+       /* If the AppShell is iconic, then the EmacsFrame is iconic. */
+       if (!ew_iconic_p)
+       {
+         XtVaGetValues (app_shell, XtNiconic, &iconic_p, 0);
+         if (iconic_p)
+           {
+             ew_iconic_p = iconic_p;
+             XtVaSetValues (ew, XtNiconic, iconic_p, 0);
+           }
+       }
+     }
+   else
+     {
+       /* If this is not the first frame created:
+          ========================================
+ 
+          - use the EmacsFrame's size/position if specified
+          - Otherwise, use the ApplicationShell's size, but not position.
+ 
+          So that means that one can specify the position of the first frame
+          with "Emacs.geometry" or `-geometry'; but can only specify the
+        position of subsequent frames with "*FRAME-NAME.geometry".
+ 
+        AppShell comes second so that -geometry does not apply to subsequent
+        frames when there is an "every frame" entry in the resource db,
+        but does apply to the first frame.
+        */
+       if (frame_flags & (XValue | YValue))
+       {
+         x = frame_x; y = frame_y;
+         flags |= (frame_flags & (XValue | YValue | XNegative | YNegative));
+       }
+ 
+       if (frame_flags & (WidthValue | HeightValue))
+       {
+         w = frame_w; h = frame_h;
+         flags |= (frame_flags & (WidthValue | HeightValue));
+       }
+       else if (app_flags & (WidthValue | HeightValue))
+       {
+         w = app_w;
+         h = app_h;
+         flags |= (app_flags & (WidthValue | HeightValue));
+       }
+     }
+ 
+   x_set_initial_frame_size (f, flags, x, y, w, h);
+ }
+ 
+ static void
+ x_get_layout_sizes (struct frame *f, Dimension *topbreadth)
+ {
+   int i;
+ 
+   /* compute height of all top-area widgets */
+   for (i=0, *topbreadth = 0; i<FRAME_X_NUM_TOP_WIDGETS (f); i++)
+     {
+       Widget wid = FRAME_X_TOP_WIDGETS (f)[i];
+       if (wid && XtIsManaged (wid))
+       *topbreadth += wid->core.height + 2*wid->core.border_width;
+     }
+ }
+ 
+ static void
+ x_layout_widgets (Widget w, XtPointer client_data, XtPointer call_data)
+ {
+   struct frame *f = (struct frame *) client_data;
+   EmacsManagerResizeStruct *emst = (EmacsManagerResizeStruct *) call_data;
+   Dimension width = emst->width;
+   Dimension height = emst->height;
+   Widget text = FRAME_X_TEXT_WIDGET (f);
+   Dimension textbord = text->core.border_width;
+   Dimension topbreadth;
+   Position text_x = 0, text_y = 0;
+   int i;
+ 
+   x_get_layout_sizes (f, &topbreadth);
+ 
+   /* first the menubar and psheets ... */
+   for (i=0; i<FRAME_X_NUM_TOP_WIDGETS (f); i++)
+     {
+       Widget wid = FRAME_X_TOP_WIDGETS (f)[i];
+       if (wid && XtIsManaged (wid))
+       {
+         Dimension bord = wid->core.border_width;
+         XtConfigureWidget (wid, 0, text_y,
+                            width - 2*bord, wid->core.height,
+                            bord);
+         text_y += wid->core.height + 2*bord;
+       }
+     }
+ 
+ #ifdef HAVE_SCROLLBARS
+   {
+     /* The scrollbar positioning is completely handled by redisplay.  We
+        just need to know which sides they are supposed to go on. */
+     unsigned char scrollbar_placement;
+     XtVaGetValues (text, XtNscrollBarPlacement, &scrollbar_placement, 0);
+     f->scrollbar_on_left = (scrollbar_placement == XtTOP_LEFT ||
+                             scrollbar_placement == XtBOTTOM_LEFT);
+     f->scrollbar_on_top  = (scrollbar_placement == XtTOP_LEFT ||
+                             scrollbar_placement == XtTOP_RIGHT);
+     f->scrollbar_y_offset = topbreadth + textbord;
+   }
+ #endif
+ 
+   /* finally the text area */
+   XtConfigureWidget (text, text_x, text_y,
+                    width - 2*textbord,
+                    height - text_y - 2*textbord,
+                    textbord);
+ }
+ 
+ static void
+ x_do_query_geometry (Widget w, XtPointer client_data, XtPointer call_data)
+ {
+   struct frame *f = (struct frame *) client_data;
+   EmacsManagerQueryGeometryStruct *emst =
+     (EmacsManagerQueryGeometryStruct *) call_data;
+   Widget text = FRAME_X_TEXT_WIDGET (f);
+   Dimension textbord = text->core.border_width;
+   Dimension topbreadth;
+   XtWidgetGeometry req, repl;
+   int mask = emst->request_mode & (CWWidth | CWHeight);
+ 
+   x_get_layout_sizes (f, &topbreadth);
+ 
+   /* strip away menubar from suggested size, and ask the text widget
+      what size it wants to be */
+   req.request_mode = mask;
+   if (mask & CWWidth)
+     req.width = emst->proposed_width - 2*textbord;
+   if (mask & CWHeight)
+     req.height = emst->proposed_height - topbreadth - 2*textbord;
+   XtQueryGeometry (text, &req, &repl);
+ 
+   /* Now add the menubar back again */
+   emst->proposed_width = repl.width + 2*textbord;
+   emst->proposed_height = repl.height + topbreadth + 2*textbord;
+ }
+ 
+ /* Creates the widgets for a frame.
+    lisp_window_id is a Lisp description of an X window or Xt
+    widget to parse.
+ 
+    This function does not create or map the windows.  (That is
+    done by x_popup_frame().)
+  */
+ static void
+ x_create_widgets (struct frame *f, Lisp_Object lisp_window_id,
+                 Lisp_Object parent)
+ {
+   struct device *d = XDEVICE (f->device);
+ #ifdef EXTERNAL_WIDGET
+   Window window_id = 0;
+ #endif
+   CONST char *name;
+   Arg av [25];
+   int ac = 0;
+   Widget text, container, shell;
+   Widget parentwid = 0;
+ #ifdef HAVE_MENUBARS
+   int menubar_visible;
+   Widget menubar;
+ #endif
+ 
+   if (STRINGP (f->name))
+     GET_C_STRING_CTEXT_DATA_ALLOCA (f->name, name);
+   else
+     name = "emacs";
+        
+   /* The widget hierarchy is
+ 
+       argv[0]                 shell           pane            FRAME-NAME
+       ApplicationShell        EmacsShell      EmacsManager    EmacsFrame
+ 
+       (the type of the shell is ExternalShell if this frame is running
+       in another client's window)
+ 
+       However the EmacsShell widget has WM_CLASS of FRAME-NAME/Emacs.
+       Normally such shells have name/class shellname/appclass, which in this
+       case would be "shell/Emacs" instead of "frame-name/Emacs".  We could
+       also get around this by naming the shell "frame-name", but that would
+       be confusing because the text area (the EmacsFrame widget inferior of
+       the shell) is also called that.  So we just set the WM_CLASS property.
+    */
+ 
+ #ifndef EXTERNAL_WIDGET
+   if (!NILP (lisp_window_id))
+     error ("support for external widgets was not enabled at compile-time");
+ #else
+   if (!NILP (lisp_window_id))
+     {
+       char *string;
+ 
+       CHECK_STRING (lisp_window_id);
+       string = (char *) (string_data (XSTRING (lisp_window_id)));
+       if (string[0] == '0' && (string[1] == 'x' || string[1] == 'X'))
+       sscanf (string+2, "%lxu", &window_id);
+ #if 0
+       else if (string[0] == 'w')
+       {
+         sscanf (string+1, "%x", &parent_widget);
+         if (parent_widget)
+           window_id = XtWindow (parent_widget);
+       }
+ #endif
+       else
+       sscanf (string, "%lu", &window_id);
+       if (!is_valid_window (window_id, d))
+       error ("Invalid window %lu", (unsigned long) window_id);
+       FRAME_X_EXTERNAL_WINDOW_P (f) = 1;
+     } else
+ #endif /* EXTERNAL_WIDGET */
+       FRAME_X_TOP_LEVEL_FRAME_P (f) = 1;
+ 
+   ac = 0;
+   XtSetArg (av[ac], XtNallowShellResize, True); ac++;
+ #ifdef LWLIB_USES_MOTIF
+   /* Motif sucks beans.  Without this in here, it will delete the window
+      out from under us when it receives a WM_DESTROY_WINDOW message
+      from the WM. */
+   XtSetArg (av[ac], XmNdeleteResponse, XmDO_NOTHING); ac++;
+ #endif
+ 
+ #ifdef EXTERNAL_WIDGET
+   if (window_id)
+     {
+       XtSetArg (av[ac], XtNwindow, window_id); ac++;
+     }
+   else
+ #endif
+     {
+       XtSetArg (av[ac], XtNinput, True); ac++;
+       XtSetArg (av[ac], (String) XtNminWidthCells, 10); ac++;
+       XtSetArg (av[ac], (String) XtNminHeightCells, 1); ac++;
+     }
+ 
+   if (!NILP (parent))
+     {
+       parentwid = FRAME_X_SHELL_WIDGET (XFRAME (parent));
+       XtSetArg (av[ac], XtNtransientFor, parentwid); ac++;
+     }
+ 
+   shell = XtCreatePopupShell ("shell",
+                             (
+ #ifdef EXTERNAL_WIDGET
+                              window_id ? externalShellWidgetClass :
+ #endif
+                              parentwid ? transientEmacsShellWidgetClass :
+                              topLevelEmacsShellWidgetClass
+                              ),
+                             parentwid ? parentwid :
+                             DEVICE_XT_APP_SHELL (d),
+                             av, ac);
+   FRAME_X_SHELL_WIDGET (f) = shell;
+   maybe_set_frame_title_format (shell);
+ 
+   /* Create the manager widget */
+   container = XtVaCreateWidget ("container",
+                               emacsManagerWidgetClass,
+                               shell, 0);
+   FRAME_X_CONTAINER_WIDGET (f) = container;
+   XtAddCallback (container, XtNresizeCallback, x_layout_widgets,
+                (XtPointer) f);
+   XtAddCallback (container, XtNqueryGeometryCallback, x_do_query_geometry,
+                (XtPointer) f);
+ 
+   /* Create the text area */
+   ac = 0;
+   XtSetArg (av[ac], XtNborderWidth, 0); ac++; /* should this be settable? */
+   XtSetArg (av[ac], (String) XtNemacsFrame, f); ac++;
+   text = XtCreateWidget (name,
+                        emacsFrameClass,
+                        container, av, ac);
+   FRAME_X_TEXT_WIDGET (f) = text;
+ 
+ #ifdef HAVE_MENUBARS  
+   /* Create the initial menubar widget. */
+   menubar_visible = x_initialize_frame_menubar (f);
+   FRAME_X_TOP_WIDGETS (f)[0] = menubar = FRAME_X_MENUBAR_WIDGET (f);
+   FRAME_X_NUM_TOP_WIDGETS (f) = 1;
+   
+   if (menubar_visible)
+     XtManageChild (menubar);
+ #endif
+   XtManageChild (text);
+   XtManageChild (container);
+ }
+ 
+ /* We used to call XtPopup() in x_popup_frame, but that doesn't give
+    you control over whether the widget is initially mapped or not
+    because XtPopup() makes an unconditional call to XMapRaised().
+    Boy, those Xt designers were clever.
+ 
+    When we first removed it we only kept the XtRealizeWidget call in
+    XtPopup.  For everything except HP's that was enough.  For HP's,
+    though, the failure to call the popup callbacks resulted in XEmacs
+    not accepting any input.  Bizarre but true.  Stupid but true.
+ 
+    So, in case there are any other gotches floating out there along
+    the same lines I've duplicated the majority of XtPopup here.  It
+    assumes no grabs and that the widget is not already popped up, both
+    valid assumptions for the one place this is called from. */
+ static void
+ xemacs_XtPopup (Widget widget)
+ {
+   ShellWidget shell_widget = (ShellWidget) widget;
+   XtGrabKind call_data = XtGrabNone;
+ 
+   XtCallCallbacks (widget, XtNpopupCallback, (XtPointer)&call_data);
+ 
+   shell_widget->shell.popped_up = TRUE;
+   shell_widget->shell.grab_kind = XtGrabNone;
+   shell_widget->shell.spring_loaded = False;
+ 
+   if (shell_widget->shell.create_popup_child_proc != NULL)
+     (*(shell_widget->shell.create_popup_child_proc))(widget);
+ 
+   /* The XtVaSetValues below are not in XtPopup menu.  We just want to
+      make absolutely sure... */
+   XtVaSetValues (widget, XtNmappedWhenManaged, False, NULL);
+   XtRealizeWidget (widget);
+   XtVaSetValues (widget, XtNmappedWhenManaged, True, NULL);
+ }
+ 
+ #ifdef HAVE_CDE
+ /* Does this have to be non-automatic? */
+ /* hack frame to respond to dnd messages */
+ static XtCallbackRec dnd_transfer_cb_rec[2];
+ #endif
+ 
+ /* create the windows for the specified frame and display them.
+    Note that the widgets have already been created, and any
+    necessary geometry calculations have already been done. */
+ static void
+ x_popup_frame (struct frame *f)
+ {
+   Widget shell_widget = FRAME_X_SHELL_WIDGET (f);
+   Widget frame_widget = FRAME_X_TEXT_WIDGET (f);
+   struct device *d = XDEVICE (FRAME_DEVICE (f));
+ 
+   /* Before mapping the window, make sure that the WMShell's notion of
+      whether it should be iconified is synchronized with the EmacsFrame's
+      notion.
+      */
+   if (FRAME_X_TOP_LEVEL_FRAME_P (f))
+     x_wm_set_shell_iconic_p (shell_widget,
+                            ((EmacsFrame) frame_widget)
+                            ->emacs_frame.iconic);
+ 
+   xemacs_XtPopup (shell_widget);
+ 
+   if (!((EmacsFrame) frame_widget)->emacs_frame.initially_unmapped)
+     XtMapWidget (shell_widget);
+   else
+     {
+       /* We may have set f->visible to 1 in x_init_frame(), so undo
+        that now. */
+       FRAME_X_TOTALLY_VISIBLE_P (f) = 0;
+       f->visible = 0;
+     }
+ 
+ #ifdef EXTERNAL_WIDGET
+   if (FRAME_X_EXTERNAL_WINDOW_P (f))
+     ExternalShellReady (shell_widget, XtWindow (frame_widget), KeyPressMask);
+   else
+ #endif
+     if (FRAME_X_TOP_LEVEL_FRAME_P (f))
+       {
+       /* tell the window manager about us. */
+       x_wm_store_class_hints (shell_widget, XtName (frame_widget));
+       x_wm_maybe_store_wm_command (f);
+       x_wm_hack_wm_protocols (shell_widget);
+       }
+ 
+ #ifdef HACK_EDITRES
+   /* Allow XEmacs to respond to EditRes requests.  See the O'Reilly Xt */
+   /* Instrinsics Programming Manual, Motif Edition, Aug 1993, Sect 14.14, */
+   /* pp. 483-493. */
+   XtAddEventHandler (shell_widget,           /* the shell widget in question */
+                    (EventMask) NoEventMask,/* OR with existing mask */
+                    True,                   /* called on non-maskable events? */
+                    _XEditResCheckMessages, /* the handler */
+                    NULL);
+ #endif
+ 
+ #ifdef HAVE_CDE
+   {
+     dnd_transfer_cb_rec[0].callback = x_cde_transfer_callback;
+     dnd_transfer_cb_rec[0].closure = (XtPointer) f;
+     dnd_transfer_cb_rec[1].callback = NULL;
+     dnd_transfer_cb_rec[1].closure = NULL;
+ 
+     DtDndVaDropRegister (FRAME_X_TEXT_WIDGET (f),
+                        DtDND_FILENAME_TRANSFER | DtDND_BUFFER_TRANSFER,
+                        XmDROP_COPY, dnd_transfer_cb_rec,
+                        DtNtextIsBuffer, True,
+                        DtNpreserveRegistration, False,
+                        NULL);
+   }
+ #endif
+ 
+ #ifdef HAVE_OFFIX_DND
+   {
+     DndInitialize (FRAME_X_SHELL_WIDGET (f));
+     DndRegisterDropWidget (FRAME_X_TEXT_WIDGET (f),
+                          x_offix_drop_event_handler, 
+                          (XtPointer) f);
+ 
+   }
+ #endif
+ 
+   /* Do a stupid property change to force the server to generate a
+      propertyNotify event so that the event_stream server timestamp will
+      be initialized to something relevant to the time we created the window.
+      */
+   XChangeProperty (XtDisplay (frame_widget), XtWindow (frame_widget),
+                  DEVICE_XATOM_WM_PROTOCOLS (d), XA_ATOM, 32, PropModeAppend,
+                  (unsigned char*) NULL, 0);
+   
+   x_send_synthetic_mouse_event (f);
+ }
+ 
+ static void
+ allocate_x_frame_struct (struct frame *f)
+ {
+   /* zero out all slots. */
+   f->frame_data = malloc_type_and_zero (struct x_frame);
+ 
+   /* yeah, except the lisp ones */
+   FRAME_X_ICON_PIXMAP (f) = Qnil;
+   FRAME_X_ICON_PIXMAP_MASK (f) = Qnil;
+ #ifdef ENERGIZE
+   FRAME_X_CURRENT_PSHEET_BUFFER (f) = Qnil;
+   FRAME_X_DESIRED_PSHEET_BUFFER (f) = Qnil;
+ #endif
+ }
+ 
+ 
+ /************************************************************************/
+ /*                            Lisp functions                          */
+ /************************************************************************/
+ 
+ static void
+ x_init_frame_1 (struct frame *f, Lisp_Object props)
+ {
+   /* This function can GC */
+   Lisp_Object device = FRAME_DEVICE (f);
+   struct device *d = XDEVICE (device);
+   Lisp_Object lisp_window_id;
+   Lisp_Object popup;
+ 
+   lisp_window_id = Fplist_get (props, Qwindow_id, Qnil);
+   popup = Fplist_get (props, Qpopup, Qnil);
+   if (!NILP (popup))
+     {
+       if (EQ (popup, Qt))
+       popup = Fselected_frame (device);
+       CHECK_LIVE_FRAME (popup);
+       if (!EQ (device, FRAME_DEVICE (XFRAME (popup))))
+       signal_simple_error_2 ("Parent must be on same device as frame",
+                              device, popup);
+     }
+ 
+   if (NILP (DEVICE_SELECTED_FRAME (d)))
+     {
+       /* This means that this is the first frame on the device.
+        So short-ciruit the delay in processing the initial MapNotify
+        event so that output on the first frame shows up right
+        away... */
+       f->visible = 1;
+     }
+ 
+   allocate_x_frame_struct (f);
+   x_create_widgets (f, lisp_window_id, popup);
+ }
+ 
+ static void
+ x_init_frame_2 (struct frame *f, Lisp_Object props)
+ {
+   /* Set up the values of the widget/frame.  A case could be made for putting
+      this inside of the widget's initialize method. */
+ 
+   update_frame_face_values (f);
+   x_initialize_frame_size (f);
+   update_frame_title (f);
+ }
+ 
+ static void
+ x_init_frame_3 (struct frame *f)
+ {
+   /* Pop up the frame. */
+ 
+   x_popup_frame (f);
+ }
+ 
+ static void
+ x_mark_frame (struct frame *f, void (*markobj) (Lisp_Object))
+ {
+   ((markobj) (FRAME_X_ICON_PIXMAP (f)));
+   ((markobj) (FRAME_X_ICON_PIXMAP_MASK (f)));
+ #ifdef ENERGIZE
+   ((markobj) (FRAME_X_CURRENT_PSHEET_BUFFER (f)));
+   ((markobj) (FRAME_X_DESIRED_PSHEET_BUFFER (f)));
+ #endif
+ }
+ 
+ static void
+ x_set_frame_icon (struct frame *f)
+ {
+   Pixmap x_pixmap, x_mask;
+ 
+   if (IMAGE_INSTANCEP (f->icon)
+       && IMAGE_INSTANCE_PIXMAP_TYPE_P (XIMAGE_INSTANCE (f->icon)))
+     {
+       x_pixmap = XIMAGE_INSTANCE_X_PIXMAP (f->icon);
+       x_mask = XIMAGE_INSTANCE_X_MASK (f->icon);
+     }
+   else
+     {
+       x_pixmap = 0;
+       x_mask = 0;
+     }
+ 
+   /* Store the X data into the widget. */
+   {
+     Arg av [10];
+     int ac = 0;
+     XtSetArg (av [ac], XtNiconPixmap, x_pixmap); ac++;
+     XtSetArg (av [ac], XtNiconMask, x_mask); ac++;
+     XtSetValues (FRAME_X_SHELL_WIDGET (f), av, ac);
+   }
+ }
+ 
+ static void
+ x_set_frame_pointer (struct frame *f)
+ {
+   XDefineCursor (XtDisplay (FRAME_X_TEXT_WIDGET (f)),
+                XtWindow (FRAME_X_TEXT_WIDGET (f)),
+                XIMAGE_INSTANCE_X_CURSOR (f->pointer));
+   XSync (XtDisplay (FRAME_X_TEXT_WIDGET (f)), 0);
+ }
+ 
+ static Lisp_Object
+ x_get_frame_parent (struct frame *f)
+ {
+   Widget parentwid = 0;
+   Arg av[1];
+ 
+   XtSetArg (av[0], XtNtransientFor, &parentwid);
+   XtGetValues (FRAME_X_SHELL_WIDGET (f), av, 1);
+   /* find the frame whose wid is parentwid */
+   if (parentwid)
+     {
+       Lisp_Object frmcons;
+       DEVICE_FRAME_LOOP (frmcons, XDEVICE (FRAME_DEVICE (f)))
+       {
+         Lisp_Object frame = XCAR (frmcons);
+         if (FRAME_X_SHELL_WIDGET (XFRAME (frame)) == parentwid)
+           return frame;
+       }
+     }
+   return Qnil;
+ }
+ 
+ DEFUN ("x-window-id", Fx_window_id, Sx_window_id, 0, 1, 0 /*
+ Get the ID of the X11 window.
+ This gives us a chance to manipulate the Emacs window from within a
+ different program.  Since the ID is an unsigned long, we return it as
+ a string.
+ */ )
+   (frame)
+   Lisp_Object frame;
+ {
+   char str[255];
+   struct frame *f = decode_x_frame (frame);
+ 
+   sprintf (str, "%lu", XtWindow (FRAME_X_TEXT_WIDGET (f)));
+   return build_string (str);
+ }
+ 
+ 
+ /************************************************************************/
+ /*                    manipulating the X window                       */
+ /************************************************************************/
+ 
+ static void
+ x_set_frame_position (struct frame *f, int xoff, int yoff)
+ {
+   Widget w = FRAME_X_SHELL_WIDGET (f);
+   Display *dpy = XtDisplay (w);
+   Dimension frame_w = DisplayWidth (dpy, DefaultScreen (dpy));
+   Dimension frame_h = DisplayHeight (dpy, DefaultScreen (dpy));
+   Dimension shell_w, shell_h, shell_bord;
+   int win_gravity;
+ 
+   XtVaGetValues (w,
+                XtNwidth, &shell_w,
+                XtNheight, &shell_h,
+                XtNborderWidth, &shell_bord,
+                0);
+ 
+   win_gravity =
+     xoff >= 0 && yoff >= 0 ? NorthWestGravity :
+     xoff >= 0 ? SouthWestGravity :
+     yoff >= 0 ? NorthEastGravity :
+     SouthEastGravity;
+   if (xoff < 0)
+     xoff += frame_w - shell_w - 2*shell_bord;
+   if (yoff < 0)
+     yoff += frame_h - shell_h - 2*shell_bord;
+ 
+   /* Update the hints so that, if this window is currently iconified, it will
+      come back at the right place.  We can't look at s->visible to determine
+      whether it is iconified because it might not be up-to-date yet (the queue
+      might not be processed). */
+   XtVaSetValues (w,
+                XtNwinGravity, win_gravity,
+                XtNx, xoff,
+                XtNy, yoff,
+                0);
+   /* Sometimes you will find that
+ 
+      (set-frame-position (selected-frame) -50 -50)
+ 
+      doesn't put the frame where you expect it to:
+      i.e. it's closer to the lower-right corner than
+      it should be, and it appears that the size of
+      the WM decorations was not taken into account.
+      This is *not* a problem with this function.
+      Both mwm and twm have bugs in handling this
+      situation. (mwm ignores the window gravity
+      and always assumes NorthWest, except the first
+      time you map the window; twm gets things almost
+      right, but forgets to account for the border
+      width of the top-level window.) This function
+      does what it's supposed to according to the ICCCM,
+      and I'm not about to hack around window-manager
+      bugs. */
+ 
+ #if 0
+   /* This is not necessary under either mwm or twm */
+   x_wm_mark_shell_position_user_specified (w);
+ #endif
+ }
+ 
+ /* Call this to change the size of frame S's x-window. */
+ 
+ static void
+ x_set_frame_size (struct frame *f, int cols, int rows)
+ {
+   EmacsFrameSetCharSize (FRAME_X_TEXT_WIDGET (f), cols, rows);
+ #if 0
+     /* this is not correct.  x_set_frame_size() is called from
+        Fset_frame_size(), which may or may not have been called
+        by the user (e.g. update_EmacsFrame() calls it when the font
+        changes).  For now, don't bother with getting this right. */
+   x_wm_mark_shell_size_user_specified (FRAME_X_SHELL_WIDGET (f));
+ #endif
+ }
+ 
+ static void
+ x_set_mouse_position (struct window *w, int x, int y)
+ {
+   struct frame *f = XFRAME (w->frame);
+ 
+   Display *display = DEVICE_X_DISPLAY (XDEVICE (f->device));
+   XWarpPointer (display, None, XtWindow (FRAME_X_TEXT_WIDGET (f)),
+                 0, 0, 0, 0, w->pixel_left + x, w->pixel_top + y);
+ }
+ 
+ static int
+ x_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y)
+ {
+   Display *display = DEVICE_X_DISPLAY (d);
+   Window child_window;
+   Window root_window;
+   Window win;
+   int root_x, root_y;
+   int win_x, win_y;
+   unsigned int keys_and_buttons;
+   struct frame *f;
+ 
+   if (XQueryPointer (display, RootWindow (display, DefaultScreen (display)),
+                    &root_window, &child_window, &root_x, &root_y,
+                    &win_x, &win_y, &keys_and_buttons) == False)
+     return 0;
+ 
+   if (child_window == None)
+     return 0; /* not over any window. */
+ 
+   while (1)
+     {
+       win = child_window;
+       if (XTranslateCoordinates (display, root_window, win, root_x, root_y,
+                                &win_x, &win_y, &child_window) == False)
+       /* Huh? */
+       return 0;
+ 
+       if (child_window == None)
+       break;
+     }
+ 
+   /* At this point, win is the innermost window containing the pointer
+      and win_x and win_y are the coordinates of that window. */
+   f = x_any_window_to_frame (d, win);
+   if (!f)
+     return 0;
+   XSETFRAME (*frame, f);
+ 
+   if (XTranslateCoordinates (display, win,
+                            XtWindow (FRAME_X_TEXT_WIDGET (f)),
+                            win_x, win_y, x, y, &child_window) == False)
+     /* Huh? */
+     return 0;
+ 
+   return 1;
+ }
+ 
+ static void
+ x_cant_notify_wm_error (void)
+ {
+   error ("Can't notify window manager of iconification.");
+ }
+ 
+ /* Raise frame F.  */
+ static void
+ x_raise_frame_1 (struct frame *f, int force)
+ {
+   Widget bottom_dialog;
+   Window emacs_window;
+   XWindowChanges xwc;
+   unsigned int flags;
+   Display *display = DEVICE_X_DISPLAY (XDEVICE (f->device));
+ 
+   if (f->visible || force)
+     {
+       emacs_window = XtWindow (FRAME_X_SHELL_WIDGET (f));
+       /* first raises all the dialog boxes, then put emacs just below the 
+        * bottom most dialog box */
+       bottom_dialog = lw_raise_all_pop_up_widgets ();
+       if (bottom_dialog && XtWindow (bottom_dialog))
+       {
+         xwc.sibling = XtWindow (bottom_dialog);
+         xwc.stack_mode = Below;
+         flags = CWSibling | CWStackMode;
+       }
+       else
+       {
+         xwc.stack_mode = Above;
+         flags = CWStackMode;
+       }
+ 
+       if (!XReconfigureWMWindow (display, emacs_window,
+                                DefaultScreen (display),
+                                flags, &xwc))
+       x_cant_notify_wm_error ();
+     }
+ }
+ 
+ static void
+ x_raise_frame (struct frame *f)
+ {
+   x_raise_frame_1 (f, 1);
+ }
+ 
+ /* Lower frame F.  */
+ static void
+ x_lower_frame (struct frame *f)
+ {
+   Display *display = DEVICE_X_DISPLAY (XDEVICE (f->device));
+   XWindowChanges xwc;
+   unsigned int flags;
+   
+   if (f->visible)
+     {
+       xwc.stack_mode = Below;
+       flags = CWStackMode;
+       if (!XReconfigureWMWindow (display, XtWindow (FRAME_X_SHELL_WIDGET (f)),
+                                DefaultScreen (display), flags, &xwc))
+       x_cant_notify_wm_error ();
+     }
+ }
+ 
+ /* Change from withdrawn state to mapped state. */
+ static void
+ x_make_frame_visible (struct frame *f)
+ {
+   Display *display = DEVICE_X_DISPLAY (XDEVICE (f->device));
+ 
+   if (!f->visible)
+     XMapRaised (display, XtWindow (FRAME_X_SHELL_WIDGET (f)));
+   else
+     x_raise_frame_1 (f, 0);
+ }
+ 
+ /* Change from mapped state to withdrawn state. */
+ static void
+ x_make_frame_invisible (struct frame *f)
+ {
+   Display *display = DEVICE_X_DISPLAY (XDEVICE (f->device));
+ 
+   if (!f->visible)
+     return;
+ 
+   if (!XWithdrawWindow (display,
+                       XtWindow (FRAME_X_SHELL_WIDGET (f)),
+                       DefaultScreen (display)))
+     x_cant_notify_wm_error ();
+ }
+ 
+ static int
+ x_frame_visible_p (struct frame *f)
+ {
+   Display *display = DEVICE_X_DISPLAY (XDEVICE (f->device));
+   XWindowAttributes xwa;
+   int result;
+ 
+   if (!XGetWindowAttributes (display,
+                            XtWindow (FRAME_X_SHELL_WIDGET (f)),
+                            &xwa))
+     result = 0;
+   else
+     result = xwa.map_state == IsViewable;
+ 
+   f->visible = result;
+   return result;
+ }
+ 
+ static int
+ x_frame_totally_visible_p (struct frame *f)
+ {
+   return FRAME_X_TOTALLY_VISIBLE_P (f);
+ }
+ 
+ /* Change window state from mapped to iconified. */
+ static void
+ x_iconify_frame (struct frame *f)
+ {
+   Display *display = DEVICE_X_DISPLAY (XDEVICE (f->device));
+ 
+   if (!XIconifyWindow (display,
+                      XtWindow (FRAME_X_SHELL_WIDGET (f)),
+                      DefaultScreen (display)))
+     x_cant_notify_wm_error ();
+ 
+   f->iconified = 1;
+ }
+ 
+ /* Sets the X focus to frame f. */
+ static void
+ x_focus_on_frame (struct frame *f)
+ {
+   XWindowAttributes xwa;
+   Widget shell_widget;
+ 
+   assert (FRAME_X_P (f));
+ 
+   shell_widget = FRAME_X_SHELL_WIDGET (f);
+   if (!XtWindow (shell_widget))
+     return;
+ 
+ #ifdef EXTERNAL_WIDGET
+   if (FRAME_X_EXTERNAL_WINDOW_P (f))
+     ExternalShellSetFocus (shell_widget);
+ #endif /* EXTERNAL_WIDGET */
+ 
+   /* Do the ICCCM focus change if the window is still visible.
+      The s->visible flag might not be up-to-date, because we might
+      not have processed magic events recently.  So make a server
+      round-trip to find out whether it's really mapped right now.
+      We grab the server to do this, because that's the only way to
+      eliminate the race condition.
+    */
+   XGrabServer (XtDisplay (shell_widget));
+   if (XGetWindowAttributes (XtDisplay (shell_widget),
+                           XtWindow (shell_widget),
+                           &xwa))
+     f->visible = xwa.map_state == IsViewable;
+       
+   if (f->visible)
+     {
+       Window focus;
+       int revert_to;
+       XGetInputFocus (XtDisplay (shell_widget), &focus, &revert_to);
+       /* Don't explicitly set the focus on this window unless the focus
+        was on some other window (not PointerRoot).  Note that, even when
+        running a point-to-type window manager like *twm, there is always
+        a focus window; the window manager maintains that based on the
+        mouse position.  If you set the "NoTitleFocus" option in these
+        window managers, then the server itself maintains the focus via
+        PointerRoot, and changing that to focus on the window would make
+        the window grab the focus.  Very bad.
+        */
+       if (focus != PointerRoot)
+       {
+         XSetInputFocus (XtDisplay (shell_widget),
+                         XtWindow (shell_widget),
+                         RevertToParent,
+                         DEVICE_X_MOUSE_TIMESTAMP
+                         (XDEVICE (FRAME_DEVICE (f))));
+         XFlush (XtDisplay (shell_widget));
+       }
+     }
+   XUngrabServer (XtDisplay (shell_widget));
+   XFlush (XtDisplay (shell_widget)); /* hey, I'd like to DEBUG this... */
+ }
+ 
+ /* Destroy the X window of frame S.  */
+ static void
+ x_delete_frame (struct frame *f)
+ {
+   Widget w = FRAME_X_SHELL_WIDGET (f);
+   Lisp_Object popup, frame;
+ 
+   if (FRAME_X_TOP_LEVEL_FRAME_P (f))
+     x_wm_maybe_move_wm_command (f);
+ 
+   /* Frames with the popup property are using other frames as their
+      widget parent.  Deleting them are their parent has already been
+      deleted can lead to crashes. */
+   XSETFRAME (frame, f);
+   popup = Fframe_property (frame, Qpopup, Qnil);
+   if (!NILP (popup))
+     {
+       /* If popup isn't nil then it means the frame has that property
+          and the value is supposed to be the parent frame.  The FRAMEP
+          check is to safeguard against it not being a frame. */
+       if (!FRAMEP (popup) || !FRAME_LIVE_P (XFRAME (popup)))
+       popup = Qt;
+       else
+       popup = Qnil;
+     }
+ 
+ #ifdef EXTERNAL_WIDGET
+   {
+     Display *dpy = XtDisplay (w);
+     expect_x_error (dpy);
+     /* for obscure reasons having (I think) to do with the internal
+        window-to-widget hierarchy maintained by Xt, we have to call
+        XtUnrealizeWidget() here.  Xt can really suck. */
+     if (f->being_deleted)
+       XtUnrealizeWidget (w);
+     if (NILP (popup))
+       XtDestroyWidget (w);
+     x_error_occurred_p (dpy);
+   }
+ #else
+   if (NILP (popup))
+     XtDestroyWidget (w);
+ #endif /* EXTERNAL_WIDGET */
+ 
+   if (FRAME_X_GEOM_FREE_ME_PLEASE (f))
+     xfree (FRAME_X_GEOM_FREE_ME_PLEASE (f));
+   xfree (f->frame_data);
+   f->frame_data = 0;
+ }
+ 
+ 
+ /************************************************************************/
+ /*                            initialization                            */
+ /************************************************************************/
+ 
+ void
+ syms_of_frame_x (void)
+ {
+   defsymbol (&Qwindow_id, "window-id");
+   defsymbol (&Qpopup, "popup");
+   defsymbol (&Qx_resource_name, "x-resource-name");
+ 
+   defsubr (&Sx_window_id);
+ }
+ 
+ void
+ console_type_create_frame_x (void)
+ {
+   /* frame methods */
+   CONSOLE_HAS_METHOD (x, init_frame_1);
+   CONSOLE_HAS_METHOD (x, init_frame_2);
+   CONSOLE_HAS_METHOD (x, init_frame_3);
+   CONSOLE_HAS_METHOD (x, mark_frame);
+   CONSOLE_HAS_METHOD (x, focus_on_frame);
+   CONSOLE_HAS_METHOD (x, delete_frame);
+   CONSOLE_HAS_METHOD (x, get_mouse_position);
+   CONSOLE_HAS_METHOD (x, set_mouse_position);
+   CONSOLE_HAS_METHOD (x, raise_frame);
+   CONSOLE_HAS_METHOD (x, lower_frame);
+   CONSOLE_HAS_METHOD (x, make_frame_visible);
+   CONSOLE_HAS_METHOD (x, make_frame_invisible);
+   CONSOLE_HAS_METHOD (x, iconify_frame);
+   CONSOLE_HAS_METHOD (x, set_frame_size);
+   CONSOLE_HAS_METHOD (x, set_frame_position);
+   CONSOLE_HAS_METHOD (x, frame_property);
+   CONSOLE_HAS_METHOD (x, internal_frame_property_p);
+   CONSOLE_HAS_METHOD (x, frame_properties);
+   CONSOLE_HAS_METHOD (x, set_frame_properties);
+   CONSOLE_HAS_METHOD (x, set_title_from_bufbyte);
+   CONSOLE_HAS_METHOD (x, set_icon_name_from_bufbyte);
+   CONSOLE_HAS_METHOD (x, frame_visible_p);
+   CONSOLE_HAS_METHOD (x, frame_totally_visible_p);
+   CONSOLE_HAS_METHOD (x, frame_iconified_p);
+   CONSOLE_HAS_METHOD (x, set_frame_pointer);
+   CONSOLE_HAS_METHOD (x, set_frame_icon);
+   CONSOLE_HAS_METHOD (x, get_frame_parent);
+ }
+ 
+ void
+ vars_of_frame_x (void)
+ {
+ #ifdef EXTERNAL_WIDGET
+   Fprovide (intern ("external-widget"));
+ #endif
+ 
+   /* this call uses only safe functions from emacs.c */
+   init_x_prop_symbols ();
+ 
+   DEFVAR_LISP ("default-x-frame-plist", &Vdefault_x_frame_plist /*
+ Plist of default frame-creation properties for X frames.
+ These override what is specified in the resource database and in
+ `default-frame-plist', but are overridden by the arguments to the
+ particular call to `make-frame'.
+ 
+ Note: In many cases, properties of a frame are available as specifiers
+ instead of through the frame-properties mechanism.
+ 
+ Here is a list of recognized frame properties, other than those
+ documented in `set-frame-properties' (they can be queried and
+ set at any time, except as otherwise noted):
+ 
+   window-id                   The X window ID corresponding to the
+                               frame.  May be set only at startup, and
+                               only if external widget support was
+                               compiled in; doing so causes the frame
+                               to be created as an \"external widget\"
+                               in another program that uses an existing
+                               window in the program rather than creating
+                               a new one.
+   initially-unmapped          If non-nil, the frame will not be visible
+                               when it is created.  In this case, you
+                               need to call `make-frame-visible' to make
+                               the frame appear.
+   popup                               If non-nil, it should be a frame, and this
+                               frame will be created as a \"popup\" frame
+                               whose parent is the given frame.  This
+                               will make the window manager treat the
+                               frame as a dialog box, which may entail
+                               doing different things (e.g. not asking
+                               for positioning, and not iconifying
+                               separate from its parent).
+   inter-line-space            Not currently implemented.
+   toolbar-shadow-thickness    Thickness of toolbar shadows.
+   background-toolbar-color    Color of toolbar background.
+   bottom-toolbar-shadow-color Color of bottom shadows on toolbars.
+                               (*Not* specific to the bottom-toolbar.)
+   top-toolbar-shadow-color    Color of top shadows on toolbars.
+                               (*Not* specifier to the top-toolbar.)
+   internal-border-width               Width of internal border around text area.
+   border-width                        Width of external border around text area.
+   top                         Y position (in pixels) of the upper-left
+                               outermost corner of the frame (i.e. the
+                               upper-left of the window-manager
+                               decorations).
+   left                                X position (in pixels) of the upper-left
+                               outermost corner of the frame (i.e. the
+                               upper-left of the window-manager
+                               decorations).
+   border-color                        Color of external border around text area.
+   cursor-color                        Color of text cursor.
+ 
+ See also `default-frame-plist', which specifies properties which apply
+ to all frames, not just X frames.
+ */ );
+   Vdefault_x_frame_plist = Qnil;
+ 
+   x_console_methods->device_specific_frame_props = &Vdefault_x_frame_plist;
+ }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15-b2/src/frame.c xemacs-19.15-b2-made/src/frame.c
*** xemacs-19.15-b2/src/frame.c Mon Sep 16 17:48:15 1996
--- xemacs-19.15-b2-made/src/frame.c    Fri Oct 25 22:56:14 1996
***************
*** 91,96 ****
--- 91,99 ----
  Lisp_Object Qborder_color;
  Lisp_Object Qborder_width;
  
+ Lisp_Object Qmin_width;
+ Lisp_Object Qmin_height;
+ 
  Lisp_Object Qframep, Qframe_live_p;
  Lisp_Object Qframe_x_p, Qframe_tty_p;
  Lisp_Object Qdelete_frame;
***************
*** 2152,2157 ****
--- 2155,2164 ----
  
   width                Width of the frame, in characters.
  
+  min-height     Minimum height of the frame, in lines.
+ 
+  min-width      Minimum width of the frame, in characters.
+  
   minibuffer   Gives the minibuffer behavior for this frame.  Either
                t (frame has its own minibuffer), `only' (frame is
                a minibuffer-only frame), or a window (frame uses that
***************
*** 2235,2240 ****
--- 2242,2251 ----
        store_minibuf_frame_prop (f, val);
        if (EQ (prop, Qunsplittable))
        f->no_split = !NILP (val);
+       if (EQ (prop, Qmin_width))
+       f->minwidth = XINT (val);
+       if (EQ (prop, Qmin_height))
+       f->minheight = XINT (val);
        if (EQ (prop, Qbuffer_predicate))
        f->buffer_predicate = val;
        if (SYMBOLP (prop) && EQ (Fbuilt_in_variable_type (prop),
***************
*** 2271,2276 ****
--- 2282,2289 ----
          || EQ (prop, Qbuffer_predicate)
          || EQ (prop, Qheight)
          || EQ (prop, Qwidth)
+         || EQ (prop, Qmin_height)
+         || EQ (prop, Qmin_width)
          || (SYMBOLP (prop) && EQ (Fbuilt_in_variable_type (prop),
                                    Qconst_specifier))
          || (SYMBOLP (prop) && !NILP (Fget (prop, Qconst_glyph_variable,
***************
*** 2317,2322 ****
--- 2330,2337 ----
                      FRAME_MINIBUF_ONLY_P (f) ? Qonly :
                      FRAME_MINIBUF_WINDOW (f)));
    FROB (Qunsplittable, FRAME_NO_SPLIT_P (f) ? Qt : Qnil);
+   FROB (Qmin_width, FRAME_MINWIDTH (f));
+   FROB (Qmin_height, FRAME_MINHEIGHT (f));
    FROB (Qbuffer_predicate, f->buffer_predicate);
  
  #undef FROB
***************
*** 2386,2391 ****
--- 2401,2408 ----
                        FRAME_MINIBUF_ONLY_P (f) ? Qonly :
                      FRAME_MINIBUF_WINDOW (f)));
    FROB (Qunsplittable, FRAME_NO_SPLIT_P (f) ? Qt : Qnil);
+   FROB (Qmin_width, FRAME_MINWIDTH (f));
+   FROB (Qmin_height, FRAME_MINHEIGHT (f));
    FROB (Qbuffer_predicate, f->buffer_predicate);
  
  #undef FROB
***************
*** 2905,2910 ****
--- 2922,2929 ----
  
    defsymbol (&Qminibuffer, "minibuffer");
    defsymbol (&Qunsplittable, "unsplittable");
+   defsymbol (&Qmin_width, "min-width");
+   defsymbol (&Qmin_height, "min-height");
    defsymbol (&Qinternal_border_width, "internal-border-width");
    defsymbol (&Qtop_toolbar_shadow_color, "top-toolbar-shadow-color");
    defsymbol (&Qbottom_toolbar_shadow_color, "bottom-toolbar-shadow-color");
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15-b2/src/frame.h xemacs-19.15-b2-made/src/frame.h
*** xemacs-19.15-b2/src/frame.h Sun Jun  9 11:48:54 1996
--- xemacs-19.15-b2-made/src/frame.h    Fri Oct 25 22:57:41 1996
***************
*** 59,64 ****
--- 59,67 ----
    int pixheight;
    int pixwidth;
  
+   int minheight;
+   int minwidth;
+   
    /* Width of the internal border.  This is a line of background color
       just inside the window's border.  It is normally only non-zero on
       X frames, but we put it here to avoid introducing window system
***************
*** 317,322 ****
--- 320,327 ----
  #define FRAME_HAS_MINIBUF_P(f) ((f)->has_minibuffer)
  #define FRAME_HEIGHT(f) ((f)->height)
  #define FRAME_WIDTH(f) ((f)->width)
+ #define FRAME_MINHEIGHT(f) ((f)->minheight)
+ #define FRAME_MINWIDTH(f) ((f)->minwidth)
  #define FRAME_PIXHEIGHT(f) ((f)->pixheight)
  #define FRAME_PIXWIDTH(f) ((f)->pixwidth)
  #ifdef HAVE_SCROLLBARS
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15-b2/src/window.c xemacs-19.15-b2-made/src/window.c
*** xemacs-19.15-b2/src/window.c        Sun Sep  8 19:45:45 1996
--- xemacs-19.15-b2-made/src/window.c   Fri Oct 25 22:56:14 1996
***************
*** 353,358 ****
--- 353,365 ----
    p->windows_changed = 1;
    p->shadow_thickness_changed = 1;
  
+   /* #### these should be protected from garbage collection */
+   p->min_width = make_int (0);
+   p->min_height = make_int (0);
+   p->malleability_width = 100;
+   p->malleability_height = 100;
+   p->factors_needed = 1;
+   
    return (val);
  }
  #undef INIT_DISP_VARIABLE
***************
*** 1639,1644 ****
--- 1646,1829 ----
    return w->dedicated;
  }
  
+ DEFUN ("set-window-height-min", Fset_window_height_min,
+        Sset_window_height_min, 2, 2, 0 /*
+ Set the minimum desired height for WINDOW to MIN.  This is not a hard limit.
+ It also does nothing to prevent the user from explicitly resizing the window to
+ a height smaller than this.  It does constrain the Emacs geometry manager when
+ the frame is resized.  The Emacs geometry manager will attempt to keep the
+ window at least this tall, but if the frame is too small, it can violate this
+ minimum in order to continue displaying all windows.  window-min-height still
+ determines the absolute minimum height that a window can have.
+ 
+ MIN can be either an integer or a symbol.  If it is a symbol, it can either be
+ a variable or a function.  If it is a variable, then its value is taken and
+ used as the minimum.  If it is a function, then the function is a called with
+ a single argument, the window, and its return value is the minimum.  In either
+ case, the symbol is evaluated whenever the frame is resized.
+ */ )
+   (window, min)
+   Lisp_Object window, min;
+ {
+   struct window *w = decode_window (window);
+   w->min_height = min;
+   return min;
+ }
+ 
+ DEFUN ("set-window-width-min", Fset_window_width_min,
+        Sset_window_width_min, 2, 2, 0 /*
+ Set the minimum desired width for WINDOW to MIN.  This is not a hard limit.
+ It also does nothing to prevent the user from explicitly resizing the window to
+ a width smaller than this.  It does constrain the Emacs geometry manager when
+ the frame is resized.  The Emacs geometry manager will attempt to keep the
+ window at least this wide, but if the frame is too small, it can violate this
+ minimum in order to continue displaying all windows.  window-min-width still
+ determines the absolute minimum width that a window can have.
+ 
+ MIN can be either an integer or a symbol.  If it is a symbol, it can either be
+ a variable or a function.  If it is a variable, then its value is taken and
+ used as the minimum.  If it is a function, then the function is a called with
+ a single argument, the window, and its return value is the minimum.  In either
+ case, the symbol is evaluated whenever the frame is resized.
+ */ )
+   (window, min)
+   Lisp_Object window, min;
+ {
+   struct window *w = decode_window (window);
+   w->min_width = min;
+   return min;
+ }
+ 
+ DEFUN ("set-window-width-malleability", Fset_window_width_malleability,
+        Sset_window_width_malleability, 2, 2, 0 /*
+ Set the amount by which frame resizes are absorbed by WINDOW to MALLEABILITY.
+ The malleability factor defaults to 100 for all windows.  A larger value means
+ that more of a frame resize will be absorbed by this window.  A smaller value
+ means that less of a frame resize will be absorbed by this window.  A value of
+ 0 means that, if possible, the window won't be resized at all in response to
+ a frame resize.  Malleability is a relative measure; the absolute value of the
+ malleability doesn't matter except in relation to the malleability factors of
+ the other windows in the frame.
+ */ )
+   (window, malleability)
+   Lisp_Object window, malleability;
+ {
+   struct window *w = decode_window (window);
+   int xmalleability = XINT (malleability);
+   if (xmalleability < 0)
+     w->malleability_width = 0;
+   else
+     w->malleability_width = xmalleability;
+   return make_int (w->malleability_width);
+ }
+ 
+ DEFUN ("set-window-height-malleability", Fset_window_height_malleability,
+        Sset_window_height_malleability, 2, 2, 0 /*
+ Set the amount by which frame resizes are absorbed by WINDOW to MALLEABILITY.
+ The malleability factor defaults to 100 for all windows.  A larger value means
+ that more of a frame resize will be absorbed by this window.  A smaller value
+ means that less of a frame resize will be absorbed by this window.  A value of
+ 0 means that, if possible, the window won't be resized at all in response to
+ a frame resize.  Malleability is a relative measure; the absolute value of the
+ malleability doesn't matter except in relation to the malleability factors of
+ the other windows in the frame.
+ */ )
+   (window, malleability)
+   Lisp_Object window, malleability;
+ {
+   struct window *w = decode_window (window);
+   int xmalleability = XINT (malleability);
+   if (xmalleability < 0)
+     w->malleability_height = 0;
+   else
+     w->malleability_height = xmalleability;
+   return make_int (w->malleability_height);
+ }
+ 
+ DEFUN ("window-height-min", Fwindow_height_min,
+        Swindow_height_min, 1, 1, 0 /*
+ Return the minimum desired height for WINDOW as set by set-window-height-min.
+ */ )
+   (window)
+   Lisp_Object window;
+ {
+   struct window *w = decode_window (window);
+   return w->min_height;
+ }
+ 
+ DEFUN ("window-width-min", Fwindow_width_min,
+        Swindow_width_min, 1, 1, 0 /*
+ Return the minimum desired width for WINDOW as set by set-window-width-min.
+ */ )
+   (window)
+   Lisp_Object window;
+ {
+   struct window *w = decode_window (window);
+   return w->min_width;
+ }
+ 
+ DEFUN ("frame-window-width-min", Fframe_window_width_min,
+        Sframe_window_width_min, 1, 2, 0 /*
+ Return width of FRAME such that all windows satisfy their width constraint.
+ With optional arg EXACTP non-nil, do not count window-min-width as a constraint.
+ Normally both window-min-width and the per window value set by
+ set-window-width-min are counted.  The return value of this function can be
+ used as a value to the frame property min-width to ensure that the frame will
+ always be large enough to hold its windows.
+ */ )
+   (frame, exactp)
+   Lisp_Object frame, exactp;
+ {
+   struct frame *f = XFRAME (frame);
+   Lisp_Object window = FRAME_ROOT_WINDOW (f);
+   struct window *w = XWINDOW (window);
+   
+   compute_window_size_factors (window, NILP (exactp) ? 1 : 0);
+   return make_int (w->minw);
+ }
+ 
+ DEFUN ("frame-window-height-min", Fframe_window_height_min,
+        Sframe_window_height_min, 1, 2, 0 /*
+ Return height of FRAME such that all windows satisfy their height constraint.
+ With optional arg EXACTP non-nil, do not count window-min-height as a
+ onstraint.  Normally both window-min-height and the per window value set by
+ set-window-height-min are counted.  The return value of this function can be
+ used as a value to the frame property min-height to ensure that the frame will
+ always be large enough to hold its windows.
+ */ )
+   (frame, exactp)
+   Lisp_Object frame, exactp;
+ {
+   struct frame *f = XFRAME (frame);
+   Lisp_Object window = FRAME_ROOT_WINDOW (f);
+   struct window *w = XWINDOW (window);
+   
+   compute_window_size_factors (window, NILP (exactp) ? 1 : 0);
+   return make_int (w->minh);
+ }
+ 
+ DEFUN ("window-width-malleability", Fwindow_width_malleability,
+        Swindow_width_malleability, 1, 1, 0 /*
+ Return the malleability of WINDOW as set by set-window-width-malleability.
+ */ )
+   (window)
+   Lisp_Object window;
+ {
+   struct window *w = decode_window (window);
+   return make_int (w->malleability_width);
+ }
+ 
+ DEFUN ("window-height-malleability", Fwindow_height_malleability,
+        Swindow_height_malleability, 1, 1, 0 /*
+ Return the malleability of WINDOW as set by set-window-height-malleability.
+ */ )
+   (window)
+   Lisp_Object window;
+ {
+   struct window *w = decode_window (window);
+   return make_int (w->malleability_height);
+ }
+ 
  /* FSFmacs has window-display-table here.  We have display table as a
     specifier. */
  
***************
*** 2965,2970 ****
--- 3150,3684 ----
      *cols = MIN_SAFE_WINDOW_WIDTH;
  }
  
+ static int
+ compute_window_size_minimum (Lisp_Object window, Lisp_Object min)
+ {
+   struct window *w = XWINDOW (window);
+   
+   /* rather than signal an error, which could be bad here,
+      we'll just set the minimum to 0 if something is wrong.
+      Of course, this is kind of silly, since we don't do anything to
+      catch errors while evaluating the function call. */
+   
+   /* should this also check for FLOATP??? */
+   
+   if (INTP (min))
+     return XINT (min);
+   else if (SYMBOLP (min))
+     {
+       /* inhibit GC here */
+       int old_gc_currently_forbidden = gc_currently_forbidden;
+       gc_currently_forbidden = 1;
+         
+       if (Ffboundp (min))
+       min = Ffuncall (1, &window);
+       else
+       min = symbol_value_in_buffer (min, w->buffer);
+       
+       gc_currently_forbidden = old_gc_currently_forbidden;
+       
+       if (INTP (min))
+       return XINT (min);
+     }
+   return 0;
+ }
+ 
+ /* recursively compute all window size factors for window w */
+ void
+ compute_window_size_factors (Lisp_Object window, int adjustp)
+ {
+   struct window *w = XWINDOW (window);
+   struct window *c;
+   Lisp_Object child;
+   int dir = 0;
+   int minw,minh;
+   unsigned long int malw,malh;
+   unsigned long int weight = 0;
+   int first = 1;
+ 
+ #if 0
+   {
+     char buf[80];
+     sprintf (buf, "WINDOW %X\n", w);
+     write_c_string (buf, Qexternal_debugging_output);
+   }
+ #endif
+   
+   child = w->hchild;
+   if (NILP (child))
+     {
+       child = w->vchild;
+       dir = 1;
+     }
+   if (NILP (child))
+     {
+       Lisp_Object val;
+ 
+       /* leaf, compute values directly */
+       
+       w->minw = compute_window_size_minimum (window, w->min_width);
+       w->minh = compute_window_size_minimum (window, w->min_height);
+ 
+       if (adjustp)
+       {
+         if (w->minw < window_min_width) w->minw = window_min_width;
+         if (w->minh < window_min_height) w->minh = window_min_height;
+       }
+     }
+   else
+     {
+       minw = 0;
+       minh = 0;
+       malw = 0;
+       malh = 0;
+   
+       while (!NILP (child))
+       {
+         c = XWINDOW (child);
+         
+         compute_window_size_factors(child, adjustp);
+         
+         if (dir)
+           {
+             minh = minh + c->minh;
+             if (first || c->minw > minw)
+               minw = c->minw;
+             
+             weight = weight + c->pixel_width;
+             malh = malh + c->pixel_width * c->malleability_height;
+             if (first || c->malleability_width < malw)
+               malw = c->malleability_width;
+           }
+         else
+           {
+             /* vertically split windows */
+             if (first || c->minh > minh)
+               minh = c->minh;
+             minw = minw + c->minw;
+             
+             if (first || c->malleability_height < malh)
+               malh = c->malleability_height;
+             weight = weight + c->pixel_height;
+             malw = malw + c->pixel_height * c->malleability_width;
+           }
+         
+         first = 0;
+         child = c->next;
+       }
+       w->minh = minh;
+       w->minw = minw;
+       if (dir)
+       malh = malh / weight;
+       else
+       malw = malw / weight;
+       
+       w->malleability_width = malw;
+       w->malleability_height = malh;
+     }
+ #if 0
+   {
+     char buf[80];
+     sprintf (buf, "       minimum width = %d\n", w->minw);
+     write_c_string (buf, Qexternal_debugging_output);
+       
+     sprintf (buf, "       minimum height = %d\n", w->minh);
+     write_c_string (buf, Qexternal_debugging_output);
+     
+     sprintf (buf, "       malleability width = %d\n", w->malleability_width);
+     write_c_string (buf, Qexternal_debugging_output);
+       
+     sprintf (buf, "       malleability height = %d\n", w->malleability_height);
+     write_c_string (buf, Qexternal_debugging_output);
+   }
+ #endif
+   w->factors_needed = 0;
+ }
+ 
+ /* Compute the pixel size of each child window in window from the window
+    specific minimum sizes and the malleability factors */
+ static void
+ compute_window_pixsize (Lisp_Object window, int new_pixsize, int old_pixsize,
+                       int set_height, int line_size)
+ {
+   struct window *w = XWINDOW (window);
+   struct window *c;
+   Lisp_Object child;
+   Lisp_Object first_child;
+   long int weight;
+   int cursize, minsize;
+   int remaining_size;
+   int needed = 0;
+   int size, trial, pixels;
+   int tries = 0;
+   int time_to_punt = 0;
+   
+   /* This function is only called if major_kid in
+      set_window_pixsize is non-nil. */
+   
+   if (w->factors_needed)
+     {
+       compute_window_size_factors (window, 1);
+     }
+   
+   if (set_height)
+     first_child = w->vchild;
+   else
+     first_child = w->hchild;
+   child = first_child;
+ 
+   assert (!NILP (child));
+   
+   size = pixels = new_pixsize - old_pixsize;
+ 
+ #if 0
+   {
+     char buf[80];
+     sprintf (buf, "WINDOW %X\n", w);
+     write_c_string (buf, Qexternal_debugging_output);
+     
+     sprintf (buf, "  NEXT %X\n", w->next);
+     write_c_string (buf, Qexternal_debugging_output);
+ 
+     if (NILP (w->hchild))
+       sprintf (buf, "  HCHILD (nil)\n");
+     else
+       sprintf (buf, "  HCHILD %X\n", w->hchild);
+     write_c_string (buf, Qexternal_debugging_output);
+     
+     if (NILP (w->vchild))
+       sprintf (buf, "  VCHILD (nil)\n");
+     else
+       sprintf (buf, "  VCHILD %X\n", w->vchild);
+     write_c_string (buf, Qexternal_debugging_output);
+     
+     sprintf (buf, "COMPUTING: change = %d\n",size);
+     write_c_string (buf, Qexternal_debugging_output);
+     
+     sprintf (buf, "           new_pixsize = %d\n",new_pixsize);
+     write_c_string (buf, Qexternal_debugging_output);
+     
+     sprintf (buf, "           set_height = %d\n",set_height);
+     write_c_string (buf, Qexternal_debugging_output);
+     
+     sprintf (buf, "           line_size = %d\n",line_size);
+     write_c_string (buf, Qexternal_debugging_output);
+   }
+ #endif
+ 
+   while (!NILP (child))
+     {
+       weight = 0;
+       if (set_height)
+       while (!NILP (child))
+         {
+           c = XWINDOW (child);
+           weight = weight + c->malleability_height;
+           c->malh = c->malleability_height;
+           needed = needed + c->minh;
+           child = c->next;
+         }
+       else
+       while (!NILP (child))
+         {
+           c = XWINDOW (child);
+           weight = weight + c->malleability_width;
+           c->malw = c->malleability_width;
+           needed = needed + c->minw;
+           child = c->next;
+         }
+ 
+       if (weight == 0)
+       {
+         child = first_child;
+         while (!NILP (child))
+           {
+             c = XWINDOW (child);
+             c->malw = 1;
+             c->malh = 1;
+             weight = weight + 1;
+             child = c->next;
+           }
+       }
+   
+       needed = needed * line_size;
+ 
+       if (new_pixsize < needed)
+       {
+         /* punt */
+         if (time_to_punt)
+           goto cwp_punt;
+         
+         /* recompute minimum sizes without adjusting for
+            window_min_{height,width} variables */
+         time_to_punt = 1;
+         compute_window_size_factors (window, 0);
+         needed = 0;
+         child = first_child;
+       }
+     }
+   while (tries<2)
+     {
+ #if 0
+       {
+       char buf[80];
+       sprintf (buf, "           needed = %d\n",needed);
+       write_c_string (buf, Qexternal_debugging_output);
+       
+       sprintf (buf, "           weight = %u\n",weight);
+       write_c_string (buf, Qexternal_debugging_output);
+       }
+ #endif
+       
+       child = first_child;
+       remaining_size  = new_pixsize;
+       
+       while (!NILP (child))
+       {
+         c = XWINDOW (child);
+         
+         if (set_height)
+           {
+             cursize = c->pixel_height;
+             minsize = c->minh * line_size;
+             
+             if (!NILP (c->next))
+               {
+                 trial = (pixels * c->malh + (weight >> 1)) / weight;
+                 trial = (trial / line_size) * line_size;
+               }
+             else
+               trial = size;
+           }
+         else
+           {
+             cursize = c->pixel_width;
+             minsize = c->minw * line_size;
+             
+             if (!NILP (c->next))
+               {
+                 trial = (pixels * c->malw + (weight >> 1)) / weight;
+                 trial = (trial / line_size) * line_size;
+               }
+             else
+               trial = size;
+           }
+ #if 0
+         {
+           char buf[80];
+           sprintf (buf, "           CHILD: %X\n",c);
+           write_c_string (buf, Qexternal_debugging_output);
+           
+           sprintf (buf, "                  cursize = %d\n",cursize);
+           write_c_string (buf, Qexternal_debugging_output);
+           
+           sprintf (buf, "                  minsize = %d\n",minsize);
+           write_c_string (buf, Qexternal_debugging_output);
+           
+           sprintf (buf, "                  remaining_size = %d\n",remaining_size);
+           write_c_string (buf, Qexternal_debugging_output);
+           
+           sprintf (buf, "                  trial = %d\n",trial);
+           write_c_string (buf, Qexternal_debugging_output);
+         }
+ #endif
+   
+         if (trial + cursize < minsize)
+           {
+             if (remaining_size < minsize)
+               break;
+             trial = minsize - cursize;
+             if (!NILP (c->next))
+               {
+                 trial = (trial / line_size) * line_size;
+                 if (trial + cursize < minsize) trial = trial + 1;
+                 if (trial + cursize > remaining_size) break;
+               }
+           }
+ 
+ #if 0
+         {
+           char buf[80];
+           sprintf (buf, "                  trial = %d\n",trial);
+           write_c_string (buf, Qexternal_debugging_output);
+           
+           sprintf (buf, "                  new size = %d\n",trial + cursize);
+           write_c_string (buf, Qexternal_debugging_output);
+           
+           sprintf (buf, "                  remaining = %d\n",size - trial);
+           write_c_string (buf, Qexternal_debugging_output);
+         }
+ #endif
+         
+         c->new_pixsize = trial + cursize;
+         size = size - trial;
+         remaining_size = remaining_size - c->new_pixsize;
+         
+         child = c->next;
+       }
+   
+       if (NILP (child))
+       break;
+       else
+       {
+ #if 0
+         {
+           char buf[80];
+           sprintf (buf, "FAILED: tries = %d\n",tries);
+           write_c_string (buf, Qexternal_debugging_output);
+         }
+ #endif
+         
+         /* resize failed */
+         if (tries)
+           {
+             struct window *mal_child;
+             int mal;
+             int old_pixels;
+             
+             /* second re-try: set most malleable to minimum size
+                until we have enough space for the remaining windows.
+                This should never fail. */
+             while (1)
+               {
+                 child = first_child;
+                 mal_child = NULL;
+                 mal = 0;
+                 while (!NILP (child))
+                   {
+                     c = XWINDOW (child);
+                     
+                     if (set_height)
+                       {
+                         if (c->malh >= mal)
+                           {
+                             mal_child = c;
+                             mal = c->malh;
+                           }
+                       }
+                     else
+                       {
+                         if (c->malw >= mal)
+                           {
+                             mal_child = c;
+                             mal = c->malw;
+                           }
+                       }
+                     child = c->next;
+                   }
+                 if (!mal_child)
+                   goto cwp_punt;
+                 
+                 old_pixels = pixels;
+                 
+                 if (set_height)
+                   {
+                     mal_child->malh = -1;
+                     mal_child->new_pixsize = mal_child->minh * line_size;
+                     pixels = pixels + mal_child->pixel_height -
+                       mal_child->new_pixsize;
+                   }
+                 else
+                   {
+                     mal_child->malw = -1;
+                     mal_child->new_pixsize = mal_child->minw * line_size;
+                     pixels = pixels + mal_child->pixel_width -
+                       mal_child->new_pixsize;
+                   }
+                 
+                 if (pixels * old_pixels <= 0)
+                   {
+                     /* done: rearrange other windows as normal */
+                     child = first_child;
+                     while (!NILP (child))
+                       {
+                         c = XWINDOW (child);
+                         if (c->malw < 0)
+                           c->malw = 0;
+                         if (c->malh < 0)
+                           c->malh = 0;
+                         child = c->next;
+                       }
+                     --tries;
+                   }
+               }
+           }
+         else
+           {
+             /* first re-try: re-weight by minimum size */
+             weight = 0;
+             child = first_child;
+             while (!NILP (child))
+               {
+                 c = XWINDOW (child);
+                 
+                 if (set_height)
+                   {
+                     if (c->pixel_height > c->minh * line_size)
+                       c->malh = (c->malh * (c->pixel_height - c->minh * line_size)) / line_size;
+                     else
+                       c->malh = 0;
+                     weight = weight + c->malh;
+                   }
+                 else
+                   {
+                     if (c->pixel_width > c->minw * line_size)
+                       c->malw = (c->malw * (c->pixel_width - c->minw * line_size)) / line_size;
+                     else
+                       c->malw = 0;
+                         
+                     weight = weight + c->malw;
+                   }
+                 child = c->next;
+               }
+           }
+         size = pixels;
+         ++tries;
+       }
+     }
+   if (!NILP (child))
+     {
+       int old_trial;
+     cwp_punt:
+ #if 0
+       {
+       char buf[80];
+       write_c_string ("PUNT!\n", Qexternal_debugging_output);
+       sprintf (buf, "           needed = %d\n",needed);
+       write_c_string (buf, Qexternal_debugging_output);
+       }
+ #endif
+       /* resize failed to meet criteria: punt */
+       cursize = 0;
+       old_trial = 0;
+       for (child = first_child; !NILP (child); child = c->next)
+       {
+         c = XWINDOW (child);
+         if (set_height)
+           cursize = cursize + WINDOW_HEIGHT (c);
+         else
+           cursize = cursize + WINDOW_WIDTH (c);
+         
+         trial = (((cursize * new_pixsize) << 1) + old_pixsize) /
+           (old_pixsize << 1);
+         
+         /* All but the last window should have a height which is
+            a multiple of the default line height. */
+         
+         if (!NILP (c->next))
+           trial = (trial / line_size) * line_size;
+         
+         c->new_pixsize = trial - old_trial;
+         old_trial = trial;
+       }
+     }
+ #if 0
+   {
+     write_c_string ("DONE\n\n", Qexternal_debugging_output);
+   }
+ #endif
+   w->factors_needed = 1;
+ }
+ 
  /* Normally the window is deleted if it gets too small.
     nodelete nonzero means do not do this.
     (The caller should check later and do so if appropriate)  */
***************
*** 3041,3046 ****
--- 3755,3763 ----
        last_pos = first = (set_height ? WINDOW_TOP (w) : WINDOW_LEFT (w));
        last_old_pos = 0;
  
+       compute_window_pixsize (window, new_pixsize, old_pixsize,
+                             set_height, line_size);
+       
        for (child = major_kid; !NILP (child); child = c->next)
        {
          c = XWINDOW (child);
***************
*** 3055,3071 ****
              old_pos = last_old_pos + WINDOW_WIDTH (c);
              WINDOW_LEFT (c) = last_pos;
            }
  
!         pos = (((old_pos * new_pixsize) << 1) + old_pixsize) / div_val;
!         /* All but the last window should have a height which is
!              a multiple of the default line height. */
!         if (!NILP (c->next))
!           pos = (pos / line_size) * line_size;
! 
          /* Avoid confusion: don't delete child if it becomes too small */
!         set_window_pixsize (child, pos + first - last_pos, 1, set_height);
  
!         last_pos = pos + first;
          last_old_pos = old_pos;
        }
  
--- 3772,3801 ----
              old_pos = last_old_pos + WINDOW_WIDTH (c);
              WINDOW_LEFT (c) = last_pos;
            }
+         
+         pos = c->new_pixsize;
  
! #if 0
!         {
!           char buf[80];
!           sprintf (buf, "WINDOW %X\n", c);
!           write_c_string (buf, Qexternal_debugging_output);
!           
!           sprintf (buf, "SET SIZE: pos = %d\n", pos);
!           write_c_string (buf, Qexternal_debugging_output);
!           
!           sprintf (buf, "          first = %d\n", first);
!           write_c_string (buf, Qexternal_debugging_output);
!           
!           sprintf (buf, "          last_pos = %d\n", last_pos);
!           write_c_string (buf, Qexternal_debugging_output);
!         }
! #endif
!         
          /* Avoid confusion: don't delete child if it becomes too small */
!         set_window_pixsize (child, pos, 1, set_height);
  
!         last_pos = last_pos + pos;
          last_old_pos = old_pos;
        }
  
***************
*** 5531,5536 ****
--- 6261,6276 ----
    defsubr (&Sset_window_start);
    defsubr (&Swindow_dedicated_p);
    defsubr (&Sset_window_dedicated_p);
+   defsubr (&Sset_window_height_min);
+   defsubr (&Sset_window_width_min);
+   defsubr (&Sframe_window_width_min);
+   defsubr (&Sframe_window_height_min);
+   defsubr (&Sset_window_width_malleability);
+   defsubr (&Sset_window_height_malleability);
+   defsubr (&Swindow_height_min);
+   defsubr (&Swindow_width_min);
+   defsubr (&Swindow_width_malleability);
+   defsubr (&Swindow_height_malleability);
    defsubr (&Snext_window);
    defsubr (&Sprevious_window);
    defsubr (&Snext_vertical_window);
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15-b2/src/window.h xemacs-19.15-b2-made/src/window.h
*** xemacs-19.15-b2/src/window.h        Sun Mar 31 19:20:42 1996
--- xemacs-19.15-b2-made/src/window.h   Fri Oct 25 22:56:14 1996
***************
*** 221,226 ****
--- 221,261 ----
  #endif
    Lisp_Object text_cursor_visible_p;
  
+   /* values used to recompute window sizes when a change is made to the frame.
+      These only affect resizes of non-leaf windows, which typically occur
+      because the frame was resized.  The algorithm tries to resize the windows
+      in such a way that these minimums are adhered to.  If the minimums given
+      here are smaller than window_min_width or window_min_height, then the
+      window can still be deleted.  If the frame is too small to meet the
+      minimums, then they will be ignored.  The malleability values determine
+      how much of a resize event will be absorbed by a particular window and
+      default to 100.  Larger values mean that the window will change size more
+      than other windows.  Smaller values mean that the window will change size
+      less than other windows.  A value of 0 will prevent the windows size from
+      changing `automatically'.  For non-leaf windows, these values are computed
+      recursively from the window's children.  Currently, this is done on an
+      as-needed basis from within set_window_pixsize.
+      note that min_width and min_height can be set to symbols; either a variable
+      or a function that is called with the window as an argument to determine
+      the actual minimums.  This implies that set_window_pixsize can garbage
+      collect.  Instead of allowing this, I've disabled GC while computing
+      these values.   -jip */
+ 
+   /* #### these should be protected from garbage collection while they are
+      stored here, but currently nothing is done to ensure this! */
+   Lisp_Object min_width;
+   Lisp_Object min_height;
+   int malleability_width;
+   int malleability_height;
+ 
+   /* used to cache the new size of the window and associated values while they
+      are being computed */
+   int minw;
+   int minh;
+   int malw;
+   int malh;
+   int new_pixsize;
+   
    /* one-bit flags: */
  
    /* marker used when restoring a window configuration */
***************
*** 238,244 ****
    /* new redisplay flag */
    unsigned int windows_changed :1;
    unsigned int shadow_thickness_changed :1;
!   };
  
  #define CURRENT_DISP          0
  #define DESIRED_DISP          1
--- 273,282 ----
    /* new redisplay flag */
    unsigned int windows_changed :1;
    unsigned int shadow_thickness_changed :1;
!   
!   /* Whether window size factors need to be recomputed */
!   unsigned int factors_needed :1;
! };
  
  #define CURRENT_DISP          0
  #define DESIRED_DISP          1
***************
*** 344,349 ****
--- 382,389 ----
  
  /* Depth in minibuffer invocations */
  extern int minibuf_level;
+ 
+ void compute_window_size_factors (Lisp_Object window,int adjustp);
  
  Lisp_Object allocate_window (void);
  int window_char_width (struct window *, int include_margins_p);

From xemacs-beta-request@cs.uiuc.edu  Sat Oct 26 05:25:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id FAA18695 for xemacs-beta-people; Sat, 26 Oct 1996 05:25:43 -0500 (CDT)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id FAA18692 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 26 Oct 1996 05:25:42 -0500 (CDT)
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id FAA28023 for <xemacs-beta@cs.uiuc.edu>; Sat, 26 Oct 1996 05:25:41 -0500 (CDT)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0vH5vu-0000BKC>; Sat, 26 Oct 96 12:25 MET DST
Message-Id: <m0vH5vu-0000BKC@susan.logware.de>
Date: Sat, 26 Oct 96 12:25 MET DST
From: Michael Diers <mdiers@logware.de>
To: XEmacs beta list <xemacs-beta@cs.uiuc.edu>
Subject: [19.15-b2] packages/etags.el bug and suggested fix

The etags package does not allow for non-pair entries in
auto-mode-alist. Other packages, notably jka-compr, insert
non-pair entries into auto-mode-alist.

This bug is also in 19.14.

*** etags.el	1996/10/26 09:56:48	1.1
--- etags.el	1996/10/26 10:11:58
***************
*** 640,649 ****
  	  (let ((alist auto-mode-alist)
  		(case-fold-search (eq system-type 'vax-vms)))
  	    ;; loop over pairs of regexps and major-modes
  	    (while (and (not file-type) alist)
  	      (if (string-match (car (car alist)) filename)
! 		  (setq file-type (cdr (car alist))))
! 	      (setq alist (cdr alist))))
  	  ;; try to find a syntax table whose name begins with the major-mode
  	  (if file-type
  	      (setq file-type-syntax-table
--- 640,656 ----
  	  (let ((alist auto-mode-alist)
  		(case-fold-search (eq system-type 'vax-vms)))
  	    ;; loop over pairs of regexps and major-modes
+             ;; NOTE: not necessarily only pairs, but three-element
+             ;;   lists as well!
  	    (while (and (not file-type) alist)
  	      (if (string-match (car (car alist)) filename)
!                   (let
!                       ((file-action (cdr (car alist))))
!                     (setq file-type
!                           (if (listp file-action)
!                               (car (cdr file-action))
!                             file-action)))
!                 (setq alist (cdr alist)))))
  	  ;; try to find a syntax table whose name begins with the major-mode
  	  (if file-type
  	      (setq file-type-syntax-table

-- 
   Michael Diers    LOGWARE GmbH             email:  mdiers@logware.de
                    Schwedenstrasse 9
                    13359 Berlin - Wedding     Tel: +49 (30) 49901-214
                    Germany                    Fax:               -139

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 28 13:27:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA01948 for xemacs-beta-people; Mon, 28 Oct 1996 13:27:15 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA01945 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 28 Oct 1996 13:27:14 -0600 (CST)
Received: from gcm.com (gcm.com [146.121.48.2]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id NAA02490 for <xemacs-beta@xemacs.org>; Mon, 28 Oct 1996 13:27:10 -0600 (CST)
Received: (from uucp@localhost) by gcm.com (8.6.9/8.6.9) with UUCP id OAA07148 for xemacs-beta@xemacs.org; Mon, 28 Oct 1996 14:27:21 -0500
Received: from gsdws133.it.gcm.com by gcm.com (4.1/GCM-2.0m)
	id AA12241; Mon, 28 Oct 96 14:26:26 EST
Received: by gsdws133.it.gcm.com (4.1/SMI-4.1)
	id AA16094; Mon, 28 Oct 96 14:26:17 EST
Message-Id: <9610281926.AA16094@gsdws133.it.gcm.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Any word on b3?
From: David Worenklein <dcw@gcm.com>
Date: 28 Oct 1996 14:26:17 -0500
Lines: 9
X-Mailer: Gnus v5.2.19/XEmacs 19.13

Anyone heard anything?

--
 David C. Worenklein                                       GREENWICH   CAPITAL
 Operations Support                                        M a r k e t s,  Inc
 =============================================================================
 phone: 203-625-2945                                                      ====
 fax:   203-629-2535                                                      ====
 e-mail: dcw@gcm.com                                                      ====

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 28 13:45:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA01994 for xemacs-beta-people; Mon, 28 Oct 1996 13:45:28 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA01991 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 28 Oct 1996 13:45:26 -0600 (CST)
Received: from sym.primuscorp.com ([207.14.28.20]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id NAA02522 for <xemacs-beta@xemacs.org>; Mon, 28 Oct 1996 13:45:23 -0600 (CST)
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id LAA02869; Mon, 28 Oct 1996 11:45:03 -0800
Received: from roy by horus (SMI-8.6/SMI-SVR4)
	id LAA25864; Mon, 28 Oct 1996 11:44:42 -0800
Received: by roy (SMI-8.6/SMI-SVR4)
	id LAA03942; Mon, 28 Oct 1996 11:44:50 -0800
Date: Mon, 28 Oct 1996 11:44:50 -0800
Message-Id: <199610281944.LAA03942@roy>
From: Damon Lipparelli <lipp@primus.com>
To: David Worenklein <dcw@gcm.com>
Cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Any word on b3?
In-Reply-To: <9610281926.AA16094@gsdws133.it.gcm.com>
References: <9610281926.AA16094@gsdws133.it.gcm.com>
Reply-To: Damon Lipparelli <lipp@primus.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.15 (beta2) ]

>>>>> David Worenklein <dcw@gcm.com> writes:

    > Anyone heard anything?

Last word from Chuck (9/28/96) was that the next beta was a week and a half
away....

-lipp

---

Not SENSUOUS...  only ``FROLICSOME''...
 and in need of DENTAL WORK...  in PAIN!!!

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 28 14:21:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA02133 for xemacs-beta-people; Mon, 28 Oct 1996 14:21:20 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA02130 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 28 Oct 1996 14:21:18 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id OAA23025 for <xemacs-beta@cs.uiuc.edu>; Mon, 28 Oct 1996 14:21:16 -0600 (CST)
Received: (qmail 5792 invoked by uid 501); 28 Oct 1996 20:23:42 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Any word on b3?
References: <9610281926.AA16094@gsdws133.it.gcm.com> <199610281944.LAA03942@roy>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Damon Lipparelli's message of Mon, 28 Oct 1996 11:44:50 -0800
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: text/plain; charset=US-ASCII
Date: 28 Oct 1996 12:23:41 -0800
Message-ID: <m23eyyq1ma.fsf@deanna.miranova.com>
Lines: 12
X-Mailer: Red Gnus v0.52/XEmacs 19.15

>>>>> "Damon" == Damon Lipparelli <lipp@primus.com> writes:

Damon> Last word from Chuck (9/28/96) was that the next beta was a
Damon> week and a half away....

And that the release of 19.15 was to be by the end of October.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 28 14:40:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA02225 for xemacs-beta-people; Mon, 28 Oct 1996 14:40:23 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA02222 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 28 Oct 1996 14:40:22 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA23517 for <xemacs-beta@cs.uiuc.edu>; Mon, 28 Oct 1996 14:40:22 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA02663; Mon, 28 Oct 1996 14:40:11 -0600 (CST)
Message-Id: <199610282040.OAA02663@xemacs.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Any word on b3? 
In-reply-to: Your message of "28 Oct 1996 12:23:41 PST."
             <m23eyyq1ma.fsf@deanna.miranova.com> 
Date: Mon, 28 Oct 1996 14:40:10 -0600
From: Chuck Thompson <cthomp@xemacs.org>

    Damon> Last word from Chuck (9/28/96) was that the next beta was a
    Damon> week and a half away....

    Steven> And that the release of 19.15 was to be by the end of
    Steven> October.

None of which obviously happened :-) I have been in a severe XEmacs
funk and hadn't done crap with it in over a month until this past
weekend when I finally dug in a little and sorted my 1600+ message
backlog.  If you check the beta web page you'll also notice that I
have listed a tentative beta release date of this Wednesday.  We'll
see how things go from there.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 28 15:22:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id PAA02445 for xemacs-beta-people; Mon, 28 Oct 1996 15:22:31 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA02442 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 28 Oct 1996 15:22:30 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id PAA28022 for <xemacs-beta@cs.uiuc.edu>; Mon, 28 Oct 1996 15:22:24 -0600 (CST)
Received: (qmail 6543 invoked by uid 501); 28 Oct 1996 21:24:56 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Any word on b3?
References: <199610282040.OAA02663@xemacs.cs.uiuc.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Chuck Thompson's message of Mon, 28 Oct 1996 14:40:10 -0600
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: text/plain; charset=US-ASCII
Date: 28 Oct 1996 13:24:55 -0800
Message-ID: <m2wwwaok7s.fsf@deanna.miranova.com>
Lines: 29
X-Mailer: Red Gnus v0.52/XEmacs 19.15

>>>>> "Chuck" == Chuck Thompson <cthomp@xemacs.org> writes:

Damon> Last word from Chuck (9/28/96) was that the next beta was a
Damon> week and a half away....

Steven> And that the release of 19.15 was to be by the end of
Steven> October.

Chuck> None of which obviously happened :-) I have been in a severe XEmacs
Chuck> funk and hadn't done crap with it in over a month

Shoot, I was sure you were rewriting XEmacs in Java ;-).

Chuck> until this past weekend when I finally dug in a little and
Chuck> sorted my 1600+ message backlog.

Chuck> If you check the beta web page you'll also notice that I have
Chuck> listed a tentative beta release date of this Wednesday.  We'll
Chuck> see how things go from there.

What can we do to help you get out of the funk?  I've been running
with beta2 + my patches for beta3 for over a month now and still feel
fairly good about 19.15 (except for the fact that we should have
gotten it released a month ago).
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Mon Oct 28 15:41:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id PAA02521 for xemacs-beta-people; Mon, 28 Oct 1996 15:41:55 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA02518 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 28 Oct 1996 15:41:54 -0600 (CST)
Received: from neal.ctd.comsat.com (exim@[134.133.40.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id PAA28696 for <xemacs-beta@cs.uiuc.edu>; Mon, 28 Oct 1996 15:41:52 -0600 (CST)
Received: from neal by neal.ctd.comsat.com with local (Exim 0.56 #3)
	id E0vHzRD-0002YG-00; Mon, 28 Oct 1996 16:41:39 -0500
From: Neal Becker <neal@ctd.comsat.com>
To: xemacs-beta@cs.uiuc.edu
Subject: libgr-2.0.10 available
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0vHzRD-0002YG-00@neal.ctd.comsat.com>
Date: Mon, 28 Oct 1996 16:41:39 -0500

I just released libgr-2.0.10.  It now supports hpux and alpha/os1 in
addition to Linux/ELF.

You must use gnu make.

Anyone want to add more ports?  Shouldn't be hard, just edit
Make.Rules.

libgr contains the following graphics libs:
fbm, jpeg, pbm, pgm, png, pnm, ppm, rle, tiff, zlib.

libgr-2.0.10 is available from:
ftp.ctd.comsat.com:/pub/linux/ELF
sunsite.unc.edu:/pub/Linux/Incoming

From xemacs-beta-request@cs.uiuc.edu  Tue Oct 29 05:22:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id FAA07884 for xemacs-beta-people; Tue, 29 Oct 1996 05:22:57 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id FAA07881 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 29 Oct 1996 05:22:56 -0600 (CST)
Received: from gatekeeper.abs.alcatel.co.uk (firewall-user@gatekeeper.abs.alcatel.co.uk [194.34.58.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id FAA07085 for <xemacs-beta@cs.uiuc.edu>; Tue, 29 Oct 1996 05:22:54 -0600 (CST)
Received: by gatekeeper.abs.alcatel.co.uk; id LAA00368; Tue, 29 Oct 1996 11:12:47 GMT
Received: from unknown(194.36.210.121) by gatekeeper.abs.alcatel.co.uk via smap (V3.1.1)
	id xma000337; Tue, 29 Oct 96 11:12:28 GMT
Received: from ariel.uk.abs by rd.abs.alcatel.co.uk  (4.1/SMI-4.1)
	id AA12094; Mon, 28 Oct 96 09:57:23 GMT
Received: by ariel.uk.abs (SMI-8.6/SMI-SVR4)
	id JAA14683; Mon, 28 Oct 1996 09:57:17 GMT
Date: Mon, 28 Oct 1996 09:57:17 GMT
Message-Id: <199610280957.JAA14683@ariel.uk.abs>
From: Ian MacKinnon <imac@rd.abs.alcatel.co.uk>
To: rritchie@britannia-life.co.uk
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: id-select.el - advanced syntactic re
In-Reply-To: <199610251040.LAA21572@sys4.cambridge.uk.psi.net>
References: <199610251040.LAA21572@sys4.cambridge.uk.psi.net>

>>>>> "rritchie" == rritchie  <rritchie@britannia-life.co.uk> writes:

    >> Does this imply that we can now dump the thing.el currently in
    >> XEmacs?  ;;; Synched up with: Not in FSF.  ;;; #### FSF has
    >> thingatpt.el, which does the same thing.  Should merge ;;; or
    >> toss this.

    >> I'd vote for tossing it ...

    rritchie> I'd vote for keeping it.  mode-motion+ relies on it and
    rritchie> I don't have time right now to port it to Bob's new
    rritchie> world, however radically cool it is.  Perhaps soon,
    rritchie> perhaps not.
Some thoughts after a few days playing ...
I'm used to the more clicks the more is selected. But I can move to
the more double clicks the more is selected.

I like being able to select whole lines in my C++ code so I changed
the order of the elements in id-select-bigger-alist so I can. Is this
the correct way to do this. Does anyone else care about the order of
this list ?.

Anyway seems like is-select is useful

-- 
                       \|/
                      (o o)
+==================oOO-(_)-OOo==========================+
|If you don't care where you are, you can't be lost     |
|                                                       |
|_______________________________________________________|
| Ian MacKinnon               imac@rd.abs.alcatel.co.uk |
| (44) 171 293 1413                                     |
|_______________________________________________________|

From xemacs-beta-request@cs.uiuc.edu  Tue Oct 29 08:51:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA08336 for xemacs-beta-people; Tue, 29 Oct 1996 08:51:18 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA08333 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 29 Oct 1996 08:51:17 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA04392 for <xemacs-beta@xemacs.org>; Tue, 29 Oct 1996 08:51:03 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id PAA05042; Tue, 29 Oct 1996 15:50:21 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: XEmacs redisplay engine
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/fetch/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 29 Oct 1996 15:50:20 +0100
Message-ID: <kiglocp4yfn.fsf@jagor.srce.hr>
Lines: 25
X-Mailer: Red Gnus v0.52/XEmacs 19.14

While playing with XEmacs I have noticed a thing with the redisplay
engine that seems strange.

When XEmacs is within a time-consuming operation, the screen is not
redisplayed.  E.g. try entering a large group with Gnus and search the
article bodies for string "fgisud" (`M-s fgisud RET').  Then go to
another virtual desktop and return (or do something else to force
XEmacs to redisplay the frame).  However, the frame is *not*
redisplayed while the command is working.

Furthermore, changes to the frame *are* redisplayed, e.g. article
number counting in the minibuffer.  I have tried the same thing in GNU
Emacs 19.13b and was quite "disappointed" when I found out that it
handles the situation correctly -- after about a second or two it
redisplays the frame no matter what Emacs is doing.

Is this a bug?  Should XEmacs always redisplay, no matter how complex
its operation is?  I find this very annoying, because it looks quite
ugly e.g. when I start Gnus or use other time-consuming functions that
use buffers a lot.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The end of the world is coming...  SAVE YOUR BUFFERS!

From xemacs-beta-request@cs.uiuc.edu  Tue Oct 29 13:05:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA09223 for xemacs-beta-people; Tue, 29 Oct 1996 13:05:23 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA09220 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 29 Oct 1996 13:05:22 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA04863 for <xemacs-beta@xemacs.org>; Tue, 29 Oct 1996 13:05:09 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id UAA00360; Tue, 29 Oct 1996 20:04:58 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: toolbar-news
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/fetch/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 29 Oct 1996 20:04:57 +0100
Message-ID: <kighgndfv6u.fsf@jagor.srce.hr>
Lines: 42
X-Mailer: Red Gnus v0.52/XEmacs 19.14

The toolbar-news function can be pretty annoying.  When there is only
one frame left, Gnus cannot exit because it tries to close the only
existing frame.

I think this small patch makes it behave much better.  When applied,
toolbar-news (actually gnus-exit-gnus-hook) will check if the news
frame is the only frame left, and will not delete it if it is.  After
quitting Gnus, you can normally click on the `News' icon again and get
a new frame.

What do you think?

*** x-toolbar.el	Tue Oct 29 19:56:34 1996
--- x-toolbar.el.orig	Tue Oct 29 19:43:01 1996
***************
*** 128,137 ****
  	(setq toolbar-news-frame (make-frame))
  	(add-hook 'gnus-exit-gnus-hook
  		  '(lambda ()
! 		     (when (frame-live-p toolbar-news-frame)
! 		       (if (cdr (frame-list))
! 			   (delete-frame toolbar-news-frame))
! 		       (setq toolbar-news-frame nil))))
  	(select-frame toolbar-news-frame)
  	(raise-frame toolbar-news-frame)
  	(gnus)))
--- 128,135 ----
  	(setq toolbar-news-frame (make-frame))
  	(add-hook 'gnus-exit-gnus-hook
  		  '(lambda ()
! 		     (if (frame-live-p toolbar-news-frame)
! 			 (delete-frame toolbar-news-frame))))
  	(select-frame toolbar-news-frame)
  	(raise-frame toolbar-news-frame)
  	(gnus)))


-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"What is the sound of Perl?  Is it not the sound of a wall that
people have stopped banging their heads against?" -- Larry Wall

From xemacs-beta-request@cs.uiuc.edu  Tue Oct 29 13:46:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA09385 for xemacs-beta-people; Tue, 29 Oct 1996 13:46:19 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA09382 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 29 Oct 1996 13:46:18 -0600 (CST)
Received: from newman.in.aventail.com (root@newman.aventail.com [38.225.141.10]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id NAA04953 for <xemacs-beta@xemacs.org>; Tue, 29 Oct 1996 13:46:09 -0600 (CST)
Received: from kramer.in.aventail.com.aventail.com (root@newman [192.168.1.1]) by newman.in.aventail.com (8.6.12/8.6.9) with SMTP id LAA31740 for <xemacs-beta@xemacs.org>; Tue, 29 Oct 1996 11:45:55 -0800
Date: Tue, 29 Oct 1996 11:45:55 -0800
Message-Id: <199610291945.LAA31740@newman.in.aventail.com>
From: William Perry <wmperry@aventail.com>
To: xemacs-beta@xemacs.org
Subject: Bogus (?) EBOLA in 20.0
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Just fired up Gnus in 20.0 for the first time in a while and NNTP starting
bleeding from every orifice (Ebola).  The problem appears to be that
(following-char) still returns '0', so something like:

(memq (following-char) '(?0 ?1 ?2 ?3))

chokes big time if you are at the end of a buffer.  The code is _TRYING_ to
behave, but following-char is being a bad boy and returning an integer
instead of a char (or nil).  This is apparently the documented behaviour of
following-char (return 0 at EOB).

Should this be changed to return 'nil' on EOB?  But then (=
(following-char) ?9) would die.  Perhaps a magic value for a char that
never matches anything?  (equivalent of ?(-1), or something equally
impossible to specify in lisp or accidentally insert into a buffer).

-Bill P.

following-char: (&optional BUFFER)
  -- a built-in function.
Return the character following point, as a number.
At the end of the buffer or accessible region, return 0.
If BUFFER is nil, the current buffer is assumed.



From xemacs-beta-request@cs.uiuc.edu  Tue Oct 29 19:03:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA10528 for xemacs-beta-people; Tue, 29 Oct 1996 19:03:27 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA10525 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 29 Oct 1996 19:03:26 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id TAA05403 for <xemacs-beta@xemacs.org>; Tue, 29 Oct 1996 19:03:22 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA01569; Tue, 29 Oct 1996 17:02:51 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA13280; Tue, 29 Oct 1996 17:02:36 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA03968; Tue, 29 Oct 1996 17:02:37 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA09314; Tue, 29 Oct 1996 17:02:33 -0800
Date: Tue, 29 Oct 1996 17:02:33 -0800
Message-Id: <199610300102.RAA09314@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: wmperry@aventail.com
Cc: xemacs-beta@xemacs.org
Subject: Bogus (?) EBOLA in 20.0
In-Reply-To: <199610291945.LAA31740@newman.in.aventail.com>
References: <199610291945.LAA31740@newman.in.aventail.com>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Bill" == William Perry <wmperry@aventail.com> writes:

Bill> Just fired up Gnus in 20.0 for the first time in a while and
Bill> NNTP starting bleeding from every orifice (Ebola).  The problem
Bill> appears to be that (following-char) still returns '0', so
Bill> something like:

Bill> (memq (following-char) '(?0 ?1 ?2 ?3))

One could argue this code is buggy, and should check for (eobp) before
calling (following-char).  For example, (forward-char) gives an error
at (eobp).  (following-char) is somewhat more lenient, and simply
returns a value that will cause problems later.  If (following-char)
returns an `impossible' value of type char, then what should this code
do at eob?

(insert (following-char))

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Oct 30 04:23:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA15259 for xemacs-beta-people; Wed, 30 Oct 1996 04:23:30 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA15256 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 30 Oct 1996 04:23:29 -0600 (CST)
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA06106 for <xemacs-beta@xemacs.org>; Wed, 30 Oct 1996 04:23:25 -0600 (CST)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.7.6/8.7.3) with ESMTP id CAA28736 for <xemacs-beta@xemacs.org>; Wed, 30 Oct 1996 02:22:56 -0800 (PST)
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id CAA17978 for <xemacs-beta@xemacs.org>; Wed, 30 Oct 1996 02:22:40 -0800
Date: Wed, 30 Oct 1996 02:22:40 -0800
Message-Id: <199610301022.CAA17978@shellx.best.com>
From: Ben Wing <ben@666.com>
To: xemacs-beta@xemacs.org, wmperry@aventail.com
Subject: Re:  Bogus (?) EBOLA in 20.0

>From xemacs-beta-request@cs.uiuc.edu  Tue Oct 29 11:48:00 1996
>Date: Tue, 29 Oct 1996 11:45:55 -0800
>From: William Perry <wmperry@aventail.com>
>To: xemacs-beta@xemacs.org
>Subject: Bogus (?) EBOLA in 20.0
>X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
> x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
> [WJopW_J.WY;
>
>Just fired up Gnus in 20.0 for the first time in a while and NNTP starting
>bleeding from every orifice (Ebola).  The problem appears to be that
>(following-char) still returns '0', so something like:
>
>(memq (following-char) '(?0 ?1 ?2 ?3))
>
>chokes big time if you are at the end of a buffer.  The code is _TRYING_ to
>behave, but following-char is being a bad boy and returning an integer
>instead of a char (or nil).  This is apparently the documented behaviour of
>following-char (return 0 at EOB).

?0 is not the same as 0; it's actually 48.

ben

From xemacs-beta-request@cs.uiuc.edu  Wed Oct 30 07:50:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id HAA15599 for xemacs-beta-people; Wed, 30 Oct 1996 07:50:41 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA15596 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 30 Oct 1996 07:50:39 -0600 (CST)
Received: from wmperry.in.aventail.com (wmperry@wmperry.oz.net [207.13.185.53]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA06273 for <xemacs-beta@xemacs.org>; Wed, 30 Oct 1996 07:50:36 -0600 (CST)
Received: (from wmperry@localhost) by wmperry.in.aventail.com (8.7.6/8.7.3) id FAA02572; Wed, 30 Oct 1996 05:49:56 -0800
Date: Wed, 30 Oct 1996 05:49:56 -0800
Message-Id: <199610301349.FAA02572@wmperry.in.aventail.com>
From: "William M. Perry" <wmperry@aventail.com>
To: Ben Wing <ben@666.com>
Cc: xemacs-beta@xemacs.org, wmperry@aventail.com
Subject: Re:  Bogus (?) EBOLA in 20.0
In-Reply-To: <199610301022.CAA17979@shellx.best.com>
References: <199610301022.CAA17979@shellx.best.com>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Ben Wing writes:

>>Just fired up Gnus in 20.0 for the first time in a while and NNTP starting
>>bleeding from every orifice (Ebola).  The problem appears to be that
>>(following-char) still returns '0', so something like:
>>
>>(memq (following-char) '(?0 ?1 ?2 ?3))
>>
>>chokes big time if you are at the end of a buffer.  The code is _TRYING_ to
>>behave, but following-char is being a bad boy and returning an integer
>>instead of a char (or nil).  This is apparently the documented behaviour of
>>following-char (return 0 at EOB).
>
>?0 is not the same as 0; it's actually 48.

  Yes, I know, but it seems odd that a function that normally returns a
char can return a non-char instead of nil on 'failure' or bad input.  I use
this little ditty to get around it in GNUS for now:

(defun following-char (&optional buffer)
  (if buffer
     (save-excursion
        (set-buffer buffer)
        (char-after (point)))
   (char-after (point))))

But this will break a lot of stuff. A grep of lisp/*/*.el reveals lots of
places that use (/= (following-char) ...)

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 31 02:09:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id CAA18860 for xemacs-beta-people; Thu, 31 Oct 1996 02:09:33 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id CAA18857 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 31 Oct 1996 02:09:32 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id CAA07754; Thu, 31 Oct 1996 02:09:29 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA10855; Thu, 31 Oct 1996 00:08:29 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id AAA08186; Thu, 31 Oct 1996 00:08:27 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA20494; Thu, 31 Oct 1996 00:08:26 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA18138; Thu, 31 Oct 1996 00:08:24 -0800
Date: Thu, 31 Oct 1996 00:08:24 -0800
Message-Id: <199610310808.AAA18138@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Ben Wing <wing@666.com>, Chuck Thompson <cthomp@xemacs.org>,
        XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Why 2 DOC files and 2 executables?
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: text/plain; charset=US-ASCII

Currently XEmacs creates 2 (identical, linked) executables:
emacs-20.0-xemacs-beta29
xemacs

I think the original idea was that the version number of the long name
was incremented once for EVERY MAKE, allowing you to run one of the
emacsen without fear of being overwritten.  Now, even this reason is
gone, and the presence of the 2 executables seems to only cause trouble.

Similarily, 2 doc files are created:
DOC
DOC-20.0-xemacs-beta29

If no one has any objections, I will simplify things so that only
`xemacs' and `DOC'
are created at build time.

The disk space and time to copy for a second DOC file is also saved.

Martin

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 31 07:43:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id HAA23120 for xemacs-beta-people; Thu, 31 Oct 1996 07:43:22 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA23117 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 31 Oct 1996 07:43:21 -0600 (CST)
Received: from gcm.com (gcm.com [146.121.48.2]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id HAA08076; Thu, 31 Oct 1996 07:43:19 -0600 (CST)
Received: (from uucp@localhost) by gcm.com (8.6.9/8.6.9) with UUCP id IAA05495; Thu, 31 Oct 1996 08:43:23 -0500
Received: from gsdws133.it.gcm.com by gcm.com (4.1/GCM-2.0m)
	id AA15768; Thu, 31 Oct 96 08:42:12 EST
Received: by gsdws133.it.gcm.com (4.1/SMI-4.1)
	id AA29278; Thu, 31 Oct 96 08:42:04 EST
Message-Id: <9610311342.AA29278@gsdws133.it.gcm.com>
To: Martin Buchholz <mrb@Eng.Sun.COM>
Cc: Ben Wing <wing@666.com>, Chuck Thompson <cthomp@xemacs.org>,
        XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: Why 2 DOC files and 2 executables?
References: <199610310808.AAA18138@xemacs.eng.sun.com>
From: David Worenklein <dcw@gcm.com>
Date: 31 Oct 1996 08:42:03 -0500
In-Reply-To: Martin Buchholz's message of Thu, 31 Oct 1996 00:08:24 -0800
Lines: 14
X-Mailer: Gnus v5.2.19/XEmacs 19.13

On the Unix side, at least, xemacs is a hard link to xemacs-version,
so it only takes up about 6 bytes for the file listing information.

(I'm being facetious - it takes more than 6 bytes, but it's still
small. :-) )

Correct me if I'm wrong.
--
 David C. Worenklein                                       GREENWICH   CAPITAL
 Operations Support                                        M a r k e t s,  Inc
 =============================================================================
 phone: 203-625-2945                                                      ====
 fax:   203-629-2535                                                      ====
 e-mail: dcw@gcm.com                                                      ====

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 31 08:39:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA23262 for xemacs-beta-people; Thu, 31 Oct 1996 08:39:31 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA23259 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 31 Oct 1996 08:39:30 -0600 (CST)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA08179 for <xemacs-beta@xemacs.org>; Thu, 31 Oct 1996 08:39:27 -0600 (CST)
Received: from is18e0s01.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id XAA13345; Thu, 31 Oct 1996 23:39:04 +0900 (JST)
Message-Id: <199610311439.XAA13345@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + tm-mh-e 7.71, tm-view 7.77
X-Face: %yc?f+O/cVKlH*K(H2X/6-d''suf|"1{S:Y0}_9$t@0G3:5M2:-Ck^[8+4^iSLeGc[Ey[WP
 PF]2M#Q9C'u~[=7TJP72J`PZdWvP=s-'-/LhFneC->=ILc~H#$lf2%hLL5U8?psIp`<[>d&@$Pm%~(
 A'"CJ.zuX@TXh\Ra4,b7M&`f"hexU-a4,#X\]Bfp'JI+MGUDRA%_$&UnWAem4}1R"4%uivgn;xFZ%"
 NS>)eCuFYNHc/:W^:{7H>bGQS],x5z[Cy~C;7j#:8y9q|"~9~UWjE<Vm_;)o<Q4S5NweLc(cl7-suY
 NF|_O*xodbmQavM
X-Emacs: Mule 2.4 =?ISO-2022-JP?B?KBskQjlITVUybBsoQik=?=
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: Jens Krinke <krinke@ips.cs.tu-bs.de>, bug-tm-en@chamonix.jaist.ac.jp
cc: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: Wrong setup 
In-reply-to: Your message of "30 Oct 1996 19:14:41 JST."
             <199610301013.LAA02569@infbssts.ips.cs.tu-bs.de> 
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Thu_Oct_31_23:38:41_1996-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Thu, 31 Oct 1996 23:38:57 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Thu_Oct_31_23:38:41_1996-1
Content-Type: text/plain; charset=US-ASCII

>>>>> In [tm(en) / tm ML (English Version) : No.903] 
>>>>>	Jens Krinke <krinke@ips.cs.tu-bs.de> wrote:

Jens> I have some problems with the installation of tm7.92: the method
Jens> directory isn't appended to the exec directory.  IMHO the
Jens> problem lies with in inst-tm where the setting of
Jens> mime-viewer/external-progs is appended to mime-setup.el.  The
Jens> result of
Jens> (file-relative-name METHOD_DIR data-directory)
Jens> which is 
Jens> (file-relative-name "/usr/local/share/tm"
Jens>    "/usr/usr/local/lib/xemacs-19.14/etc/")
Jens> and results in
Jens> "share/tm" or sometimes in "local/share/tm".
Jens> This looks really buggy -- for xemacs...
Jens> Probably one should change inst-tm, because many of us are using
Jens> xemacs 19.14.

  I think it is bug of XEmacs.  If it is true, I modify to redefine
`file-relative-name' for XEmacs 19.14.

  Regards,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
--- I protest Chinese nuclear testing --------------------------------
----------------- and virtual testing of United States and France. ---
# PGP public key: http://www-ks.jaist.ac.jp/~morioka/tomohiko/pgp.key
--pgp-sign-Multipart_Thu_Oct_31_23:38:41_1996-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMni5+RnuUGV7wuH5AQFK0AQAs1KBZaDfQBaP/S26nw5PNlXiUG5Me3kj
mKoY9kvf/aiQ4fUEtWbLGVK21/5CXRYpM7oX1P6uIinjENLOr/pLbi+/2aB4w3aX
aoSzs4P1l7VTDJHmgXwI6ZCcydiVx0DoRbICNfGJd8/uzcdsAZbAVru0V5pYvZ6t
JkDFYuuw7pU=
=n0Vp
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Oct_31_23:38:41_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 31 08:57:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA23363 for xemacs-beta-people; Thu, 31 Oct 1996 08:57:31 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA23360 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 31 Oct 1996 08:57:30 -0600 (CST)
Received: from infbssys.ips.cs.tu-bs.de (root@infbssys.ips.cs.tu-bs.de [134.169.32.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA08212 for <xemacs-beta@xemacs.org>; Thu, 31 Oct 1996 08:57:27 -0600 (CST)
Received: from infbssts.ips.cs.tu-bs.de (infbssts.ips.cs.tu-bs.de [134.169.32.75]) by infbssys.ips.cs.tu-bs.de with ESMTP id PAA18178
  (8.6.13/IDA-1.6); Thu, 31 Oct 1996 15:56:47 +0100
Date: Thu, 31 Oct 1996 15:56:46 +0100 (MET)
Message-Id: <199610311456.PAA08389@infbssts.ips.cs.tu-bs.de>
From: Jens Krinke <krinke@ips.cs.tu-bs.de>
To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
Cc: bug-tm-en@chamonix.jaist.ac.jp,
        XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: Wrong setup 
In-Reply-To: <199610311439.XAA13345@mikan.jaist.ac.jp>
References: <199610301013.LAA02569@infbssts.ips.cs.tu-bs.de>
	<199610311439.XAA13345@mikan.jaist.ac.jp>
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: text/plain; charset=US-ASCII

Tomohiko>   I think it is bug of XEmacs.  If it is true, I modify to
Tomohiko> redefine `file-relative-name' for XEmacs 19.14.

Meanwhile I have compared the result to Emacs 19.33 -- where it is
"../../../tm/share".  Therefore I consider that an error of XEmacs.
(I have already posted that to comp.emacs.xemacs).

Regards,
Jens
--
______________________________________________________________________
 Jens Krinke                                        j.krinke@tu-bs.de 
 +49 531 391 7583                      http://www.cs.tu-bs.de/~krinke

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 31 10:16:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA23709 for xemacs-beta-people; Thu, 31 Oct 1996 10:16:20 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA23706 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 31 Oct 1996 10:16:19 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA08402 for <xemacs-beta@cs.uiuc.edu>; Thu, 31 Oct 1996 10:16:15 -0600 (CST)
Received: (qmail 10071 invoked by uid 501); 31 Oct 1996 16:18:58 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [Chris Pratico <pratico@divnc.com>] XEmacs FAQ -- Marking text via the keyboard
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Oct_31_08:18:55_1996-1"
Content-Transfer-Encoding: 7bit
Date: 31 Oct 1996 08:18:56 -0800
Message-ID: <m2g22vqf7z.fsf@deanna.miranova.com>
Lines: 629
X-Mailer: Red Gnus v0.53/XEmacs 19.15

--Multipart_Thu_Oct_31_08:18:55_1996-1
Content-Type: text/plain; charset=US-ASCII

Does somebody want to try this out?  It's not going to be put into the
FAQ.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

--Multipart_Thu_Oct_31_08:18:55_1996-1
Content-Type: message/rfc822

Date: Thu, 31 Oct 1996 09:24:25 -0500
From: Chris Pratico <pratico@divnc.com>
Organization: Hewlett-Packard Company
To: steve@miranova.com
Subject: XEmacs FAQ -- Marking text via the keyboard 

Q:  Does anyone have a keyboard mapping that will allow me 
to mark text similar to how MS Windows and Macs can?

A:  The following package provides the reqested capabilities.
It was originally provided from version 19.33 of emacs running
on Windows NT, I modified it slightly so that it would work
under Xemacs V19.14 on my HP workstation.  I have not 
exhaustively tested it yet, but so far seems to work fine.
I thought that I would send it to you for possible inclusion
in the FAQ.

Regards,

-Chris



-- 
====================================================
Christopher J. Pratico
Software Design Engineer    Hewlett-Packard Company
pratico@chapelhill.hp.com   Chapel Hill Graphics Lab
                            The Courtyard #10 
                            431 W. Franklin Street 
Tel: 919/969-1029           Chapel Hill, NC 27514
Fax: 919/968-7890
====================================================

;;; pc-select.el --- emulate mark, cut, copy and paste from motif
;;;		     (or MAC GUI) or MS-windoze (bah)) look-and-feel
;;;		     including key bindings

;; Copyright (C) 1995, 1996 Free Software Foundation, Inc.

;; Author: Michael Staats <michael@thp.Uni-Duisburg.DE>
;; Created: 26 Sep 1995

;; This file is part of GNU Emacs.

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.

;;; Commentary:

;; This package emulates the mark, copy, cut and paste look-and-feel of motif
;; programs (which is the same as the MAC gui and (sorry for that) MS-Windows).
;; It modifies the keybindings of the cursor keys and the next, prior,
;; home and end keys. They will modify mark-active.
;; You can still get the old behaviour of cursor moving with the
;; control sequences C-f, C-b, etc.
;; This package uses transient-mark-mode and
;; delete-selection-mode.
;;
;; In addition to that all key-bindings from the pc-mode are 
;; done here too (as suggested by RMS).
;;
;; As I found out after I finished the first version, s-region.el tries
;; to do the same.... But my code is a little more complete and using
;; delete-selection-mode is very important for the look-and-feel.
;; Pete Forman <pete.forman@airgun.wg.waii.com> provided some motif
;; compliant keybindings which I added. I had to modify them a little
;; to add the -mark and -nomark functionality of cursor moving.
;;
;; Credits:
;; Many thanks to all who made comments.
;; Thanks to RMS and Ralf Muschall <prm@rz.uni-jena.de> for criticism.
;; Kevin Cutts <cutts@ukraine.corp.mot.com> added the beginning-of-buffer
;; and end-of-buffer functions which I modified a little.
;; David Biesack <sasdjb@unx.sas.com> suggested some more cleanup.
;; Thanks to Pete Forman <pete.forman@airgun.wg.waii.com>
;; for additional motif keybindings.
;; Thanks to jvromans@squirrel.nl (Johan Vromans) for a bug report
;; concerning setting of this-command.
;;
;;
;; Ok, some details about the idea of pc-selection-mode:
;;
;;  o The standard keys for moving around (right, left, up, down, home, end,
;;    prior, next, called "move-keys" from now on) will always de-activate
;;    the mark.
;;  o If you press "Shift" together with the "move-keys", the region
;;    you pass along is activated
;;  o You have the copy, cut and paste functions (as in many other programs)
;;    which will operate on the active region
;;    It was not possible to bind them to C-v, C-x and C-c for obvious
;;    emacs reasons.
;;    They will be bound according to the "old" behaviour to S-delete (cut),
;;    S-insert (paste) and C-insert (copy). These keys do the same in many
;;    other programs.

;;; Code:

;;;;
;; misc
;;;;

(provide 'pc-select)

(defun copy-region-as-kill-nomark (beg end)
  "Save the region as if killed; but don't kill it; deactivate mark.
If `interprogram-cut-function' is non-nil, also save the text for a window
system cut and paste.\n
Deactivating mark is to avoid confusion with delete-selection-mode
and transient-mark-mode."
 (interactive "r")
 (copy-region-as-kill beg end)
 (setq mark-active nil)
 (message "Region saved"))

;;;;
;; non-interactive
;;;;
(defun ensure-mark()
  ;; make sure mark is active
  ;; test if it is active, if it isn't, set it and activate it
;;  (and (not mark-active) (set-mark-command nil)))
  (setq zmacs-region-stays t)
  (if (not (region-exists-p)) (set-mark-command nil)))

;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;; forward and mark
;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defun forward-char-mark (&optional arg)
  "Ensure mark is active; move point right ARG characters (left if ARG negative).
On reaching end of buffer, stop and signal error."
  (interactive "p")
  (ensure-mark)
  (forward-char arg))

(defun forward-word-mark (&optional arg)
  "Ensure mark is active; move point right ARG words (backward if ARG is negative).
Normally returns t.
If an edge of the buffer is reached, point is left there
and nil is returned."
  (interactive "p")
  (ensure-mark)
  (forward-word arg))

(defun forward-paragraph-mark (&optional arg)
  "Ensure mark is active; move forward to end of paragraph.
With arg N, do it N times; negative arg -N means move backward N paragraphs.\n
A line which `paragraph-start' matches either separates paragraphs
\(if `paragraph-separate' matches it also) or is the first line of a paragraph.
A paragraph end is the beginning of a line which is not part of the paragraph
to which the end of the previous line belongs, or the end of the buffer."
  (interactive "p")
  (ensure-mark)
  (forward-paragraph arg))
 
(defun next-line-mark (&optional arg)
  "Ensure mark is active; move cursor vertically down ARG lines.
If there is no character in the target line exactly under the current column,
the cursor is positioned after the character in that line which spans this
column, or at the end of the line if it is not long enough.
If there is no line in the buffer after this one, behavior depends on the
value of `next-line-add-newlines'.  If non-nil, it inserts a newline character
to create a line, and moves the cursor to that line.  Otherwise it moves the
cursor to the end of the buffer \(if already at the end of the buffer, an error
is signaled).\n
The command C-x C-n can be used to create
a semipermanent goal column to which this command always moves.
Then it does not try to move vertically.  This goal column is stored
in `goal-column', which is nil when there is none."
  (interactive "p")
  (ensure-mark)
  (next-line arg)
  (setq this-command 'next-line))

(defun end-of-line-mark (&optional arg)
  "Ensure mark is active; move point to end of current line.
With argument ARG not nil or 1, move forward ARG - 1 lines first.
If scan reaches end of buffer, stop there without error."
  (interactive "p")
  (ensure-mark)
  (end-of-line arg)
  (setq this-command 'end-of-line))

(defun scroll-down-mark (&optional arg)
  "Ensure mark is active; scroll down ARG lines; or near full screen if no ARG.
A near full screen is `next-screen-context-lines' less than a full screen.
Negative ARG means scroll upward.
When calling from a program, supply a number as argument or nil."
  (interactive "P") 
  (ensure-mark)
  (scroll-down arg))

(defun end-of-buffer-mark (&optional arg)
  "Ensure mark is active; move point to the end of the buffer.
With arg N, put point N/10 of the way from the end.\n
If the buffer is narrowed, this command uses the beginning and size
of the accessible part of the buffer.\n
Don't use this command in Lisp programs!
\(goto-char \(point-max)) is faster and avoids clobbering the mark."
  (interactive "P")
  (ensure-mark)
  (let ((size (- (point-max) (point-min))))
    (goto-char (if arg
		   (- (point-max)
		      (if (> size 10000)
			  ;; Avoid overflow for large buffer sizes!
			  (* (prefix-numeric-value arg)
			     (/ size 10))
			(/ (* size (prefix-numeric-value arg)) 10)))
		 (point-max))))
  ;; If we went to a place in the middle of the buffer,
  ;; adjust it to the beginning of a line.
  (if arg (forward-line 1)
    ;; If the end of the buffer is not already on the screen,
    ;; then scroll specially to put it near, but not at, the bottom.
    (if (let ((old-point (point)))
	  (save-excursion
		    (goto-char (window-start))
		    (vertical-motion (window-height))
		    (< (point) old-point)))
	(progn
;	  (overlay-recenter (point))
	  (recenter -3)))))

;;;;;;;;;
;;;;; no mark
;;;;;;;;;

(defun forward-char-nomark (&optional arg)
  "Deactivate mark; move point right ARG characters \(left if ARG negative).
On reaching end of buffer, stop and signal error."
  (interactive "p")
  (setq mark-active nil)
  (forward-char arg))

(defun forward-word-nomark (&optional arg)
  "Deactivate mark; move point right ARG words \(backward if ARG is negative).
Normally returns t.
If an edge of the buffer is reached, point is left there
and nil is returned."
  (interactive "p")
  (setq mark-active nil)
  (forward-word arg))

(defun forward-paragraph-nomark (&optional arg)
  "Deactivate mark; move forward to end of paragraph.
With arg N, do it N times; negative arg -N means move backward N paragraphs.\n
A line which `paragraph-start' matches either separates paragraphs
\(if `paragraph-separate' matches it also) or is the first line of a paragraph.
A paragraph end is the beginning of a line which is not part of the paragraph
to which the end of the previous line belongs, or the end of the buffer."
  (interactive "p")
  (setq mark-active nil)
  (forward-paragraph arg))

(defun next-line-nomark (&optional arg)
  "Deactivate mark; move cursor vertically down ARG lines.
If there is no character in the target line exactly under the current column,
the cursor is positioned after the character in that line which spans this
column, or at the end of the line if it is not long enough.
If there is no line in the buffer after this one, behavior depends on the
value of `next-line-add-newlines'.  If non-nil, it inserts a newline character
to create a line, and moves the cursor to that line.  Otherwise it moves the
cursor to the end of the buffer (if already at the end of the buffer, an error
is signaled).\n
The command C-x C-n can be used to create
a semipermanent goal column to which this command always moves.
Then it does not try to move vertically.  This goal column is stored
in `goal-column', which is nil when there is none."
  (interactive "p")
  (setq mark-active nil)
  (next-line arg)
  (setq this-command 'next-line))

(defun end-of-line-nomark (&optional arg)
  "Deactivate mark; move point to end of current line.
With argument ARG not nil or 1, move forward ARG - 1 lines first.
If scan reaches end of buffer, stop there without error."
  (interactive "p")
  (setq mark-active nil)
  (end-of-line arg)
  (setq this-command 'end-of-line))

(defun scroll-down-nomark (&optional arg)
  "Deactivate mark; scroll down ARG lines; or near full screen if no ARG.
A near full screen is `next-screen-context-lines' less than a full screen.
Negative ARG means scroll upward.
When calling from a program, supply a number as argument or nil."
  (interactive "P")
  (setq mark-active nil)
  (scroll-down arg))

(defun end-of-buffer-nomark (&optional arg)
  "Deactivate mark; move point to the end of the buffer.
With arg N, put point N/10 of the way from the end.\n
If the buffer is narrowed, this command uses the beginning and size
of the accessible part of the buffer.\n
Don't use this command in Lisp programs!
\(goto-char (point-max)) is faster and avoids clobbering the mark."
  (interactive "P")
  (setq mark-active nil)
  (let ((size (- (point-max) (point-min))))
    (goto-char (if arg
		   (- (point-max)
		      (if (> size 10000)
			  ;; Avoid overflow for large buffer sizes!
			  (* (prefix-numeric-value arg)
			     (/ size 10))
			(/ (* size (prefix-numeric-value arg)) 10)))
		 (point-max))))
  ;; If we went to a place in the middle of the buffer,
  ;; adjust it to the beginning of a line.
  (if arg (forward-line 1)
    ;; If the end of the buffer is not already on the screen,
    ;; then scroll specially to put it near, but not at, the bottom.
    (if (let ((old-point (point)))
	  (save-excursion
		    (goto-char (window-start))
		    (vertical-motion (window-height))
		    (< (point) old-point)))
	(progn
	  (overlay-recenter (point))
	  (recenter -3)))))


;;;;;;;;;;;;;;;;;;;;
;;;;;; backwards and mark
;;;;;;;;;;;;;;;;;;;;

(defun backward-char-mark (&optional arg)
"Ensure mark is active; move point left ARG characters (right if ARG negative).
On attempt to pass beginning or end of buffer, stop and signal error."
  (interactive "p")
  (ensure-mark)
  (backward-char arg))

(defun backward-word-mark (&optional arg)
  "Ensure mark is active; move backward until encountering the end of a word.
With argument, do this that many times."
  (interactive "p")
  (ensure-mark)
  (backward-word arg))

(defun backward-paragraph-mark (&optional arg)
  "Ensure mark is active; move backward to start of paragraph.
With arg N, do it N times; negative arg -N means move forward N paragraphs.\n
A paragraph start is the beginning of a line which is a
`first-line-of-paragraph' or which is ordinary text and follows a
paragraph-separating line; except: if the first real line of a
paragraph is preceded by a blank line, the paragraph starts at that
blank line.\n
See `forward-paragraph' for more information."
  (interactive "p")
  (ensure-mark)
  (backward-paragraph arg))

(defun previous-line-mark (&optional arg)
  "Ensure mark is active; move cursor vertically up ARG lines.
If there is no character in the target line exactly over the current column,
the cursor is positioned after the character in that line which spans this
column, or at the end of the line if it is not long enough.\n
The command C-x C-n can be used to create
a semipermanent goal column to which this command always moves.
Then it does not try to move vertically.\n
If you are thinking of using this in a Lisp program, consider using
`forward-line' with a negative argument instead.  It is usually easier
to use and more reliable (no dependence on goal column, etc.)."
  (interactive "p")
  (ensure-mark)
  (previous-line arg)
  (setq this-command 'previous-line))

(defun beginning-of-line-mark (&optional arg)
  "Ensure mark is active; move point to beginning of current line.
With argument ARG not nil or 1, move forward ARG - 1 lines first.
If scan reaches end of buffer, stop there without error."
  (interactive "p")
  (ensure-mark)
  (beginning-of-line arg))


(defun scroll-up-mark (&optional arg)
"Ensure mark is active; scroll upward ARG lines; or near full screen if no ARG.
A near full screen is `next-screen-context-lines' less than a full screen.
Negative ARG means scroll downward.
When calling from a program, supply a number as argument or nil."
  (interactive "P")
  (ensure-mark)
  (scroll-up arg))

(defun beginning-of-buffer-mark (&optional arg)
  "Ensure mark is active; move point to the beginning of the buffer.
With arg N, put point N/10 of the way from the beginning.\n
If the buffer is narrowed, this command uses the beginning and size
of the accessible part of the buffer.\n
Don't use this command in Lisp programs!
\(goto-char (p\oint-min)) is faster and avoids clobbering the mark."
  (interactive "P")
  (ensure-mark) 
  (let ((size (- (point-max) (point-min))))
    (goto-char (if arg
		   (+ (point-min)
		      (if (> size 10000)
			  ;; Avoid overflow for large buffer sizes!
			  (* (prefix-numeric-value arg)
			     (/ size 10))
			(/ (+ 10 (* size (prefix-numeric-value arg))) 10)))
		 (point-min))))
  (if arg (forward-line 1)))

;;;;;;;;
;;; no mark
;;;;;;;;

(defun backward-char-nomark (&optional arg)
  "Deactivate mark; move point left ARG characters (right if ARG negative).
On attempt to pass beginning or end of buffer, stop and signal error."
  (interactive "p")
  (setq mark-active nil)
  (backward-char arg))

(defun backward-word-nomark (&optional arg)
  "Deactivate mark; move backward until encountering the end of a word.
With argument, do this that many times."
  (interactive "p")
  (setq mark-active nil)
  (backward-word arg))

(defun backward-paragraph-nomark (&optional arg)
  "Deactivate mark; move backward to start of paragraph.
With arg N, do it N times; negative arg -N means move forward N paragraphs.\n
A paragraph start is the beginning of a line which is a
`first-line-of-paragraph' or which is ordinary text and follows a
paragraph-separating line; except: if the first real line of a
paragraph is preceded by a blank line, the paragraph starts at that
blank line.\n
See `forward-paragraph' for more information."
  (interactive "p")
  (setq mark-active nil)
  (backward-paragraph arg))

(defun previous-line-nomark (&optional arg)
  "Deactivate mark; move cursor vertically up ARG lines.
If there is no character in the target line exactly over the current column,
the cursor is positioned after the character in that line which spans this
column, or at the end of the line if it is not long enough.\n
The command C-x C-n can be used to create
a semipermanent goal column to which this command always moves.
Then it does not try to move vertically."
  (interactive "p")
  (setq mark-active nil)
  (previous-line arg)
  (setq this-command 'previous-line))

(defun beginning-of-line-nomark (&optional arg)
  "Deactivate mark; move point to beginning of current line.
With argument ARG not nil or 1, move forward ARG - 1 lines first.
If scan reaches end of buffer, stop there without error."
  (interactive "p")
  (setq mark-active nil)
  (beginning-of-line arg))

(defun scroll-up-nomark (&optional arg)
  "Deactivate mark; scroll upward ARG lines; or near full screen if no ARG.
A near full screen is `next-screen-context-lines' less than a full screen.
Negative ARG means scroll downward.
When calling from a program, supply a number as argument or nil."
  (interactive "P")
  (setq mark-active nil)
  (scroll-up arg))

(defun beginning-of-buffer-nomark (&optional arg)
  "Deactivate mark; move point to the beginning of the buffer.
With arg N, put point N/10 of the way from the beginning.\n
If the buffer is narrowed, this command uses the beginning and size
of the accessible part of the buffer.\n
Don't use this command in Lisp programs!
\(goto-char (point-min)) is faster and avoids clobbering the mark."
  (interactive "P")
  (setq mark-active nil)
  (let ((size (- (point-max) (point-min))))
    (goto-char (if arg
		   (+ (point-min)
		      (if (> size 10000)
			  ;; Avoid overflow for large buffer sizes!
			  (* (prefix-numeric-value arg)
			     (/ size 10))
			(/ (+ 10 (* size (prefix-numeric-value arg))) 10)))
		 (point-min))))
  (if arg (forward-line 1)))

;;;###autoload
(defun pc-selection-mode ()
  "Change mark behaviour to emulate motif, MAC or MS-Windows cut and paste style.\n
This mode will switch on delete-selection-mode and
transient-mark-mode.\n
The cursor keys (and others) are bound to new functions
which will modify the status of the mark. It will be
possible to select regions with shift-cursorkeys. All this
tries to emulate the look-and-feel of GUIs like motif,
the MAC GUI or MS-Windows (sorry for the last one)."
  (interactive)
  ;;
  ;; keybindings
  ;;

  ;; This is to avoid confusion with the delete-selection-mode
  ;; On simple displays you can't see that a region is active and
  ;; will be deleted on the next keypress. IMHO especially for
  ;; copy-region-as-kill this is confusing
  (define-key global-map "\M-w" 'copy-region-as-kill-nomark) 


  ;; The following keybindings are for standard ISO keyboards
  ;; as they are used with IBM compatible PCs, IBM RS/6000,
  ;; MACs, many X-Stations and probably more
  (define-key global-map [(shift right)]   'forward-char-mark)
  (define-key global-map [(right)]     'forward-char-nomark)
  (define-key global-map [(control shift right)] 'forward-word-mark)
  (define-key global-map [(control right)]   'forward-word-nomark)
  (define-key global-map [(meta shift right)] 'forward-word-mark)
  (define-key global-map [(meta right)]   'forward-word-nomark)

  (define-key global-map [(shift down)]    'next-line-mark)
  (define-key global-map [(down)]      'next-line-nomark)

  (define-key global-map [(shift end)]     'end-of-line-mark)
  (define-key global-map [(end)]       'end-of-line-nomark)
  (global-set-key [(shift control end)]          'end-of-buffer-mark)
  (global-set-key [(control end)]            'end-of-buffer-nomark)
  (global-set-key [(shift meta end)]          'end-of-buffer-mark)
  (global-set-key [(meta end)]            'end-of-buffer-nomark)

  (define-key global-map [(shift next)]    'scroll-up-mark)
  (define-key global-map [(next)]      'scroll-up-nomark)

  (define-key global-map [(shift left)]    'backward-char-mark)
  (define-key global-map [(left)]      'backward-char-nomark)
  (define-key global-map [(control shift left)]  'backward-word-mark)
  (define-key global-map [(control left)]    'backward-word-nomark)
  (define-key global-map [(meta shift left)]  'backward-word-mark)
  (define-key global-map [(meta left)]    'backward-word-nomark)

  (define-key global-map [(shift up)]      'previous-line-mark)
  (define-key global-map [(up)]        'previous-line-nomark)

  (define-key global-map [(shift home)]    'beginning-of-line-mark)
  (define-key global-map [(home)]      'beginning-of-line-nomark)
  (global-set-key [(shift control home)]         'beginning-of-buffer-mark)
  (global-set-key [(control home)]           'beginning-of-buffer-nomark)
  (global-set-key [(shift meta home)]         'beginning-of-buffer-mark)
  (global-set-key [(meta home)]           'beginning-of-buffer-nomark)

  (define-key global-map [(shift prior)]   'scroll-down-mark)
  (define-key global-map [(prior)]     'scroll-down-nomark)

  (define-key global-map [(shift insert)]  'yank)
  (define-key global-map [(control insert)]  'copy-region-as-kill)
  (define-key global-map [(shift delete)]  'kill-region)

  ;; The following bindings are useful on Sun Type 3 keyboards
  ;; They implement the Get-Delete-Put (copy-cut-paste)
  ;; functions from sunview on the L6, L8 and L10 keys
  (define-key global-map [f16]  'yank)
  (define-key global-map [f18]  'copy-region-as-kill)
  (define-key global-map [f20]  'kill-region)

  ;; The following bindings are from Pete Forman.
  ;; I modified them a little to work together with the
  ;; mark functionality I added.

  (global-set-key [f1] 'help)		; KHelp         F1
  (global-set-key [f6] 'other-window)	; KNextPane     F6
;; uncommenting this seemed to cause backspace not to work in minibuffer??????
;  (global-set-key [(delete)] 'delete-char) ; KDelete       Del
  (global-set-key [(control delete)] 'kill-line) ; KEraseEndLine cDel
  (global-set-key [(meta backspace)] 'undo)	; KUndo         aBS
  (global-set-key [(control down)] 'forward-paragraph-nomark) ; KNextPara     cDn
  (global-set-key [(control up)] 'backward-paragraph-nomark) ; KPrevPara     cUp
  (global-set-key [(shift control down)] 'forward-paragraph-mark)
  (global-set-key [(shift control up)] 'backward-paragraph-mark) 

  ;; The following bindings are taken from pc-mode.el
  ;; as suggested by RMS.
  ;; I only used the ones that are not covered above.
  (define-key function-key-map  [(meta delete)] [?\M-d])
  (global-set-key [(control meta delete)]  'kill-sexp)
  (global-set-key [(control backspace)] 'backward-kill-word)
  (global-set-key [(control escape)]    'list-buffers)

  ;;        
  ;; setup
  ;;
  (setq transient-mark-mode t)
  (setq mark-even-if-inactive t)
	(require 'pending-del) ; delete selected text
;;  (delete-selection-mode 1))
	)
;;; pc-select.el ends here

--Multipart_Thu_Oct_31_08:18:55_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 31 13:27:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA24299 for xemacs-beta-people; Thu, 31 Oct 1996 13:27:04 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA24296 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 31 Oct 1996 13:27:03 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id NAA15126 for <xemacs-beta@cs.uiuc.edu>; Thu, 31 Oct 1996 13:27:01 -0600 (CST)
Received: (qmail 12492 invoked by uid 501); 31 Oct 1996 19:29:45 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Why 2 DOC files and 2 executables?
References: <199610310808.AAA18138@xemacs.eng.sun.com> <9610311342.AA29278@gsdws133.it.gcm.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: David Worenklein's message of 31 Oct 1996 08:42:03 -0500
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: text/plain; charset=US-ASCII
Date: 31 Oct 1996 11:29:44 -0800
Message-ID: <m2budjrkyf.fsf@deanna.miranova.com>
Lines: 15
X-Mailer: Red Gnus v0.53/XEmacs 19.15

>>>>> "David" == David Worenklein <dcw@gcm.com> writes:

David> On the Unix side, at least, xemacs is a hard link to
David> xemacs-version, so it only takes up about 6 bytes for the file
David> listing information.

That's true, however, the duplicate DOC files are copies and the
second copy isn't useful because build numbers aren't tracked.

Eliminating the duplicates sounds like a good idea to me.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Thu Oct 31 16:31:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA24954 for xemacs-beta-people; Thu, 31 Oct 1996 16:31:03 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA24951 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 31 Oct 1996 16:31:01 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id QAA09040; Thu, 31 Oct 1996 16:30:58 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA04933; Thu, 31 Oct 1996 14:29:55 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA01270; Thu, 31 Oct 1996 14:29:51 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA29417; Thu, 31 Oct 1996 14:29:49 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA19232; Thu, 31 Oct 1996 14:29:48 -0800
Date: Thu, 31 Oct 1996 14:29:48 -0800
Message-Id: <199610312229.OAA19232@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: David Worenklein <dcw@gcm.com>
Cc: Ben Wing <wing@666.com>, Chuck Thompson <cthomp@xemacs.org>,
        XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: Why 2 DOC files and 2 executables?
In-Reply-To: <9610311342.AA29278@gsdws133.it.gcm.com>
References: <199610310808.AAA18138@xemacs.eng.sun.com>
	<9610311342.AA29278@gsdws133.it.gcm.com>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: text/plain; charset=US-ASCII

>>>>> "David" == David Worenklein <dcw@gcm.com> writes:

David> On the Unix side, at least, xemacs is a hard link to xemacs-version,
David> so it only takes up about 6 bytes for the file listing information.

David> (I'm being facetious - it takes more than 6 bytes, but it's still
David> small. :-) )

David> Correct me if I'm wrong.

You are correct, of course.

However, hard links are hard to understand, and generally more trouble
than they're worth.  I wouldn't complain much if hard links were
simply outlawed.  People think of things in terms of names and
nicknames, not multiple equivalent names - reflected in the use of

What is THE name of ...?

If you run out of disk space, and decide to reclaim some using
rm xemacs
then you will be sorely disappointed - and it may not be immediately
apparent why you've failed.

I'm not suggesting we eliminate version numbers in file names completely.
Install time is different - there certainly is something to be said
for a SYMlink

public-bin/xemacs-20.0-beta29 -> /some/long/path/bin/xemacs

The DOC file, however, is in a version-specific directory - we only
need one.

Martin

From xemacs-beta-request@cs.uiuc.edu  Fri Nov  1 08:17:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA00532 for xemacs-beta-people; Fri, 1 Nov 1996 08:17:41 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA00529 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 1 Nov 1996 08:17:41 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA11085 for <xemacs-beta@cs.uiuc.edu>; Fri, 1 Nov 1996 08:17:32 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id PAA27717; Fri, 1 Nov 1996 15:17:15 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [Chris Pratico <pratico@divnc.com>] XEmacs FAQ -- Marking text via the keyboard
References: <m2g22vqf7z.fsf@deanna.miranova.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/fetch/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 01 Nov 1996 15:17:14 +0100
In-Reply-To: Steven L Baur's message of 31 Oct 1996 08:18:56 -0800
Message-ID: <kig3eytsxw5.fsf@jagor.srce.hr>
Lines: 11
X-Mailer: Red Gnus v0.53/XEmacs 19.14

Steven L. Baur (steve@miranova.com) wrote:
> Does somebody want to try this out?  It's not going to be put into the
> FAQ.

Works perfectly for me.  Maybe we should ship it with XEmacs?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
* Q: What is an experienced Emacs user?
* A: A person who wishes that the terminal had pedals.

From xemacs-beta-request@cs.uiuc.edu  Fri Nov  1 18:43:04 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA02405 for xemacs-beta-people; Fri, 1 Nov 1996 18:43:04 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA02402 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 1 Nov 1996 18:43:03 -0600 (CST)
Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA24283 for <xemacs-beta@cs.uiuc.edu>; Fri, 1 Nov 1996 18:42:59 -0600 (CST)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.7.6/8.7.3) with ESMTP id QAA28096 for <xemacs-beta@cs.uiuc.edu>; Fri, 1 Nov 1996 16:41:09 -0800 (PST)
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id QAA08947 for <xemacs-beta@cs.uiuc.edu>; Fri, 1 Nov 1996 16:41:08 -0800
Date: Fri, 1 Nov 1996 16:41:08 -0800
Message-Id: <199611020041.QAA08947@shellx.best.com>
From: Ben Wing <ben@666.com>
To: xemacs-beta@cs.uiuc.edu, Steven L Baur <steve@miranova.com>
Subject: Re:  [Chris Pratico <pratico@divnc.com>] XEmacs FAQ -- Marking text
    via the keyboard

I think this code is much too bulky for what it's trying to accomplish.
Here's some code I use in my .emacs file to get the "Shift-key-marks-region"
behavior.

(defun do-shift-fun (keys)
  (or (region-exists-p) (set-mark-command nil))
  (command-execute (key-binding keys)))

(mapcar #'(lambda (keys)
	    (let ((newkeys (cons 'shift keys)))
	    (global-set-key newkeys `(lambda () (interactive "_")
				       (do-shift-fun [,keys])))))
	'((up)
	  (down)
	  (left)
	  (right)
	  (home)
	  (end)
	  (prior)
	  (next)
	  (control up)
	  (control down)
	  (control left)
	  (control right)
	  (control home)
	  (control end)
	  (control prior)
	  (control next)
	  (meta up)
	  (meta down)
	  (meta left)
	  (meta right)
	  (meta home)
	  (meta end)
	  (meta prior)
	  (meta next)
	  (meta control up)
	  (meta control down)
	  (meta control left)
	  (meta control right)
	  (meta control home)
	  (meta control end)
	  (meta control prior)
	  (meta control next)))

From xemacs-beta-request@cs.uiuc.edu  Fri Nov  1 18:52:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA02476 for xemacs-beta-people; Fri, 1 Nov 1996 18:52:05 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA02468 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 1 Nov 1996 18:51:57 -0600 (CST)
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA10923 for <xemacs-beta@xemacs.org>; Fri, 1 Nov 1996 18:51:54 -0600 (CST)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.7.6/8.7.3) with ESMTP id QAA24696 for <xemacs-beta@xemacs.org>; Fri, 1 Nov 1996 16:50:50 -0800 (PST)
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id QAA25581 for <xemacs-beta@xemacs.org>; Fri, 1 Nov 1996 16:50:40 -0800
Date: Fri, 1 Nov 1996 16:50:40 -0800
Message-Id: <199611020050.QAA25581@shellx.best.com>
From: Ben Wing <ben@666.com>
To: xemacs-beta@xemacs.org, gnu-emacs-sources@gnu.ai.mit.edu,
        Bob Weiner
    <weiner@infodock.com>
Subject: Re:  id-select.el - advanced syntactic region selections

This is a good package.  Here are some patches to fix a few problems:

*** id-select.el.orig	Sun Oct 27 18:33:51 1996
--- id-select.el	Fri Nov  1 15:43:23 1996
***************
*** 189,195 ****
  	 ;; Prior click was at the same point as before, so enlarge
  	 ;; selection to the next bigger item.
  	 (if (and (id-select-bigger-thing) id-select-display-type)
! 	     (message "%s" id-select-previous))
  	 t)
  	(t (id-select-reset event)
  	   (id-select-thing-with-mouse event))))
--- 189,200 ----
  	 ;; Prior click was at the same point as before, so enlarge
  	 ;; selection to the next bigger item.
  	 (if (and (id-select-bigger-thing) id-select-display-type)
! 	     (progn
! 	       ;; #### bleh! hack so that things still work after the
! 	       ;; region is deselected
! 	       (and (fboundp 'x-store-cutbuffer)
! 		    (x-store-cutbuffer (buffer-substring (point) (mark))))
! 	       (message "%s" id-select-previous)))
  	 t)
  	(t (id-select-reset event)
  	   (id-select-thing-with-mouse event))))
***************
*** 257,263 ****
  If the multi-click occurs at the same point as the last multi-click, select
  the next larger syntactic structure.  If id-select-display-type is non-nil,
  the type of selection is displayed in the minibuffer."
!   (cond ((= click-count 1)
  	 ;; Return nil so any other hooks are performed.
  	 nil)
  	(t (id-select-thing-with-mouse event))))
--- 262,268 ----
  If the multi-click occurs at the same point as the last multi-click, select
  the next larger syntactic structure.  If id-select-display-type is non-nil,
  the type of selection is displayed in the minibuffer."
!   (cond ((/= click-count 2)
  	 ;; Return nil so any other hooks are performed.
  	 nil)
  	(t (id-select-thing-with-mouse event))))
***************
*** 365,371 ****
        (let ((at-def-brace (or (looking-at "^{") (looking-at "^}")))
  	    (opoint (point))
  	    ;; there should be a c-point position for 'eod
! 	    (eod  (save-excursion (end-of-defun) (point)))
  	    (state (c-parse-state))
  	    brace)
  	(while state
--- 370,380 ----
        (let ((at-def-brace (or (looking-at "^{") (looking-at "^}")))
  	    (opoint (point))
  	    ;; there should be a c-point position for 'eod
! 	    (eod  (save-excursion
! 		    (condition-case nil
! 			(progn
! 			  (end-of-defun) (point))
! 		      (error (point-max)))))
  	    (state (c-parse-state))
  	    brace)
  	(while state

From xemacs-beta-request@cs.uiuc.edu  Fri Nov  1 18:57:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA02487 for xemacs-beta-people; Fri, 1 Nov 1996 18:57:52 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA02484 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 1 Nov 1996 18:57:51 -0600 (CST)
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA10933 for <xemacs-beta@xemacs.org>; Fri, 1 Nov 1996 18:57:48 -0600 (CST)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.7.6/8.7.3) with ESMTP id QAA25371 for <xemacs-beta@xemacs.org>; Fri, 1 Nov 1996 16:55:50 -0800 (PST)
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id QAA04397 for <xemacs-beta@xemacs.org>; Fri, 1 Nov 1996 16:55:41 -0800
Date: Fri, 1 Nov 1996 16:55:41 -0800
Message-Id: <199611020055.QAA04397@shellx.best.com>
From: Ben Wing <ben@666.com>
To: David Worenklein <dcw@gcm.com>, Martin Buchholz <mrb@Eng.Sun.COM>
Subject: Re: Why 2 DOC files and 2 executables?
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>,
        Chuck Thompson
    <cthomp@xemacs.org>
References: <199610310808.AAA18138@xemacs.eng.sun.com>
    <9610311342.AA29278@gsdws133.it.gcm.com>

Hard links are the spawn of the devil.

Either change both DOC and executable so that one name is a symbolic link
to the other, or eliminate the second name/copy.


ben
--
(This message composed by voice)

From xemacs-beta-request@cs.uiuc.edu  Fri Nov  1 19:36:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA02621 for xemacs-beta-people; Fri, 1 Nov 1996 19:36:54 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA02618 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 1 Nov 1996 19:36:53 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA25115 for <xemacs-beta@cs.uiuc.edu>; Fri, 1 Nov 1996 19:36:51 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id CAA00667; Sat, 2 Nov 1996 02:35:50 +0100 (MET)
Sender: hniksic@public.srce.hr
To: Ben Wing <ben@666.com>
Cc: xemacs-beta@cs.uiuc.edu, Steven L Baur <steve@miranova.com>
Subject: Re: [Chris Pratico <pratico@divnc.com>] XEmacs FAQ -- Marking text     via the keyboard
References: <199611020041.QAA08947@shellx.best.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/fetch/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 02 Nov 1996 02:35:48 +0100
In-Reply-To: Ben Wing's message of Fri, 1 Nov 1996 16:41:08 -0800
Message-ID: <kigaft1gtxn.fsf@jagor.srce.hr>
Lines: 12
X-Mailer: Red Gnus v0.53/XEmacs 19.14

Ben Wing (ben@666.com) wrote:
> I think this code is much too bulky for what it's trying to accomplish.
> Here's some code I use in my .emacs file to get the "Shift-key-marks-region"
> behavior.

But your code doesn't handle deactivating a region when a "normal"
cursor key is pressed.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}

From xemacs-beta-request@cs.uiuc.edu  Sun Nov  3 03:33:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id DAA12692 for xemacs-beta-people; Sun, 3 Nov 1996 03:33:52 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id DAA12689 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 3 Nov 1996 03:33:49 -0600 (CST)
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id DAA25309 for <xemacs-beta@cs.uiuc.edu>; Sun, 3 Nov 1996 03:33:49 -0600 (CST)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.7.6/8.7.3) with ESMTP id BAA26607 for <xemacs-beta@cs.uiuc.edu>; Sun, 3 Nov 1996 01:33:12 -0800 (PST)
Received: from  (shellx.best.com [206.86.0.11]) by shellx.best.com (8.6.12/8.6.5) with SMTP id BAA20026 for <xemacs-beta@cs.uiuc.edu>; Sun, 3 Nov 1996 01:33:04 -0800
Date: Sun, 3 Nov 1996 01:33:04 -0800
Message-Id: <199611030933.BAA20026@shellx.best.com>
From: Ben Wing <ben@666.com>
To: Ben Wing <ben@666.com>, Hrvoje Niksic <hniksic@srce.hr>
Subject: Re: [Chris Pratico <pratico@divnc.com>] XEmacs FAQ -- Marking text    
    via the keyboard
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu
References: <199611020041.QAA08947@shellx.best.com>

>> I think this code is much too bulky for what it's trying to accomplish.
>> Here's some code I use in my .emacs file to get the "Shift-key-marks-region"
>> behavior.
>
>But your code doesn't handle deactivating a region when a "normal"
>cursor key is pressed.

But I consider that a feature, not a bug. (I use sticky modifiers, and
it's a necessity in this case.)

ben

From xemacs-beta-request@cs.uiuc.edu  Sun Nov  3 20:11:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA14621 for xemacs-beta-people; Sun, 3 Nov 1996 20:11:59 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA14618 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 3 Nov 1996 20:11:58 -0600 (CST)
Received: from freya.yggdrasil.com (freya.yggdrasil.com [192.216.244.52]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA13228 for <xemacs-beta@xemacs.org>; Sun, 3 Nov 1996 20:11:53 -0600 (CST)
Received: from infodock.com(really [206.13.40.192]) by freya.yggdrasil.com
	via sendmail with esmtp
	id <m0vKEUs-000DxTC@freya.yggdrasil.com>
	for <xemacs-beta@xemacs.org>; Sun, 3 Nov 1996 18:10:42 -0800 (PST)
	(Smail-3.2 1996-Jul-4 #15 built 1996-Aug-18)
Received: (from weiner@localhost) by infodock.com (8.8.0/8.7.3) id TAA00378; Sun, 3 Nov 1996 19:05:32 -0800
Date: Sun, 3 Nov 1996 19:05:32 -0800
From: Bob Weiner <weiner@infodock.com>
Message-Id: <199611040305.TAA00378@infodock.com>
To: xemacs-beta@infodock.com
Subject: eval-interactive should return the result of the eval.


This should happen even when a defvar is treated as a defconst,
but as of b2, it does not.  The fix is simply to change the 'progn'
to a 'prog1'.

With this change, the symbol name of the defvar is returned
which I think is enough feedback to know that the defvar was
actually re-evaluated, eliminating the need for the 'defvar
treated as defconst' message and its ensuing delay.

------
R. Weiner			<info@infodock.com>
InfoDock Associates delivers industrial quality support and development
for InfoDock, Emacs, and XEmacs.


From xemacs-beta-request@cs.uiuc.edu  Sun Nov  3 21:00:19 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id VAA14729 for xemacs-beta-people; Sun, 3 Nov 1996 21:00:19 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id VAA14726 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 3 Nov 1996 21:00:18 -0600 (CST)
Received: from freya.yggdrasil.com (freya.yggdrasil.com [192.216.244.52]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id VAA13258 for <xemacs-beta@xemacs.org>; Sun, 3 Nov 1996 21:00:15 -0600 (CST)
Received: from infodock.com(really [206.13.40.192]) by freya.yggdrasil.com
	via sendmail with esmtp
	id <m0vKFFe-000DxUC@freya.yggdrasil.com>
	for <xemacs-beta@xemacs.org>; Sun, 3 Nov 1996 18:59:02 -0800 (PST)
	(Smail-3.2 1996-Jul-4 #15 built 1996-Aug-18)
Received: (from weiner@localhost) by infodock.com (8.8.0/8.7.3) id UAA00564; Sun, 3 Nov 1996 20:01:23 -0800
Date: Sun, 3 Nov 1996 20:01:23 -0800
From: Bob Weiner <weiner@infodock.com>
Message-Id: <199611040401.UAA00564@infodock.com>
To: xemacs-beta@infodock.com
Subject: Suggestion that {C-h m} minor mode documentation come at the end.
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII

I would like to suggest that describe-mode be rewritten to show the minor
mode documentation after the major mode documentation, since I find that
most of the time (90% at least) when I ask for help on a mode, I am most
interested in reading about the major mode, with only a secondary interest
in the keybindings and description of the active minor modes.

When 2 or 3 minor modes are active, I often have to scroll the help window
to see the beginning of the major mode description.

Although minor modes can override things from major modes, they are called
major and minor for a reason, notably that the user-centric view is of
working in a major mode, modified in minor ways, so the first level of
mode help should reflect the major mode behavior.  (Starting with the
minor mode doc is more of an implementors' view, I would say.)

Bob

From xemacs-beta-request@cs.uiuc.edu  Mon Nov  4 02:32:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id CAA15489 for xemacs-beta-people; Mon, 4 Nov 1996 02:32:05 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id CAA15486 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 4 Nov 1996 02:32:04 -0600 (CST)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id CAA13551 for <xemacs-beta@xemacs.org>; Mon, 4 Nov 1996 02:32:02 -0600 (CST)
Received: from clusaz.gvc.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA13326; Mon, 4 Nov 1996 00:26:45 -0800
Received: from fornet.gvc.dec.com by clusaz.gvc.dec.com; (5.65/1.1.8.2/19Sep95-8.2MPM)
	id AA07827; Mon, 4 Nov 1996 09:26:37 +0100
Received: by fornet.gvc.dec.com; (5.65v3.2/1.1.8.2/23Sep96-1024AM)
	id AA19406; Mon, 4 Nov 1996 09:26:32 +0100
Date: Mon, 4 Nov 1996 09:26:32 +0100
Message-Id: <9611040826.AA19406@fornet.gvc.dec.com>
From: Steve Carney <carney@gvc.dec.com>
To: xemacs-beta@xemacs.org
Subject: 15b2 w3 dump
Reply-To: carney@gvc.dec.com
X-Face: (d*XRr}%:j,s*8+_o];-"-<<Sd1>H?Ds*>_vV}6DVjhNkjSRW0z^9[WBrbtMma>lyW6u>r(
 9U_m6J0kh7U=q?(h[7<YtS!Cu[Yl)D_XSCy5+tw>_2qr&4S=n|A*ScV]5BR{3]YXk$!,4l2vh9B]}&
 0p"&#\I

I got the following dump when using w3 in 15b2 from a tty interface.
>From a web page displayed by w3, I just hit return to fetch
<http://www-digital.cern.ch/digital-at-cern/>.

Lisp backtrace follows:

  open-network-stream-internal("WWW" " *URL*" "www-digital.cern.ch" 80)
  # bind (service host buffer name)
  open-network-stream("WWW" " *URL*" "www-digital.cern.ch" 80)
  byte-code("@  \n

                  $@" [open-network-stream name buffer host service conn] 5)
  # (condition-case ... . ((error (byte-code "@ !B" ... 2))))
  # bind (max-retries cur-retries retry errobj conn tmp-gateway-method
tcp-binary-process-output-services service host buffer name)
  url-open-stream("WWW" " *URL*" "www-digital.cern.ch" 80)
  # bind (request dest file port server ref-url urlobj proxy-info url)
  url-http("http://www-digital.cern.ch/digital-at-cern/")
  # bind (tmp cached original-url handler url-using-proxy type urlobj
no-cache url)
  url-retrieve-internally("http://www-digital.cern.ch/digital-at-cern/" nil)
  # bind (expected-md5 no-cache url)
  url-retrieve("http://www-digital.cern.ch/digital-at-cern/")
  # bind (x lastbuf buf url)
  w3-fetch("http://www-digital.cern.ch/digital-at-cern/")
  # bind (faces old-face face args tag href target ignore widget)
  w3-follow-hyperlink((push :args nil :value "" :tag "" :notify
w3-follow-hyperlink 
:from #<marker at 566 in Steve Carney's Internal Home Page> 
:to #<marker at 578 in Steve Carney's Internal Home Page> 
href "http://www-digital.cern.ch/digital-at-cern/") (push :args nil
:value "" :tag "" :notify w3-follow-hyperlink 
:from #<marker at 566 in Steve Carney's Internal Home Page> 
:to #<marker at 578 in Steve Carney's Internal Home Page> href
"http://www-digital.cern.ch/digital-at-cern/") nil)
  apply(w3-follow-hyperlink (push :args nil :value "" :tag "" :notify
w3-follow-hyperlink 
:from #<marker at 566 in Steve Carney's Internal Home Page> 
:to #<marker at 578 in Steve Carney's Internal Home Page> 
href "http://www-digital.cern.ch/digital-at-cern/") ((push :args
nil :value "" :tag "" :notify w3-follow-hyperlink 
:from #<marker at 566 in Steve Carney's Internal Home Page> 
:to #<marker at 578 in Steve Carney's Internal Home Page>
href "http://www-digital.cern.ch/digital-at-cern/") nil))
  # bind (args property widget)
  widget-apply((push :args nil :value "" :tag "" :notify
w3-follow-hyperlink 
:from #<marker at 566 in Steve Carney's Internal Home Page> 
:to #<marker at 578 in Steve Carney's Internal Home Page> 
href "http://www-digital.cern.ch/digital-at-cern/") :notify (push :args nil
:value "" :tag "" :notify w3-follow-hyperlink 
:from #<marker at 566 in Steve Carney's Internal Home Page> 
:to #<marker at 578 in Steve Carney's Internal Home Page> href
"http://www-digital.cern.ch/digital-at-cern/") nil)
  # bind (event widget)
  widget-item-action((push :args nil :value "" :tag "" :notify
w3-follow-hyperlink 
:from #<marker at 566 in Steve Carney's Internal Home Page> 
:to #<marker at 578 in Steve Carney's Internal Home Page>
href "http://www-digital.cern.ch/digital-at-cern/") nil)
  apply(widget-item-action (push :args nil :value "" :tag "" :notify
w3-follow-hyperlink 
:from #<marker at 566 in Steve Carney's Internal Home Page> 
:to #<marker at 578 in Steve Carney's Internal Home Page> 
href "http://www-digital.cern.ch/digital-at-cern/") nil)
  # bind (args property widget)
  widget-apply((push :args nil :value "" :tag "" :notify
w3-follow-hyperlink 
:from #<marker at 566 in Steve Carney's Internal Home Page> 
:to #<marker at 578 in Steve Carney's Internal Home Page> href
"http://www-digital.cern.ch/digital-at-cern/") :action nil)
  # bind (button event pos)
  widget-button-press(574)
  #<compiled-function (from "w3.elc") nil "...(9)" 
[widget-at widget-button-press] 2 nil nil>()
  call-interactively(w3-widget-button-press)
  # (condition-case ... . error)
  # (catch top-level ...)
Abort (core dumped)


% dbx /usr/local/xemacs-beta/bin/alpha-dec-osf3.2/xemacs core
dbx /usr/local/xemacs-beta/bin/alpha-dec-osf3.2/xemacs core
dbx version 3.11.8
Type 'help' for help.
Core file created by program "xemacs-19.15-b2"

signal IOT/Abort trap at >*[__kill, 0x3ff8010ce68] 	beq	r19, 0x3ff8010ce80
(dbx) where
>  0 __kill(0x7c04, 0x3ff800f0348, 0x8, 0x0, 0x12009d14c) [0x3ff8010ce68]
   1 fatal_error_signal(sig = 1) ["emacs.c":191, 0x12009d148]
   2 __kill(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff8010ce64]
   3 raise(0x6, 0x0, 0x2, 0x11fff93b8, 0x57) [0x3ff80121830]
   4 abort(0x7c04, 0x3ff800e0ca8, 0x57, 0x12009cfc0, 0x0) [0x3ff8010fc80]
   5 assert_failed(file = 0x4b86, line = 6, expr = 0x11fff99a8 = "\300\317\t ^A") ["emacs.c":1838, 0x12009fb44]
   6 start_async_timeouts() ["signal.c":243, 0x120197794]
   7 start_interrupts() ["signal.c":618, 0x12019881c]
   8 speed_up_interrupts() ["signal.c":288, 0x120197904]
   9 Fopen_network_stream_internal(name = (...), buffer = (...), host = (...), service = (...)) ["process.c":1454, 0x12015daa4]
  10 primitive_funcall(fn = 0x3ff8010fc20, nargs = 536844712, args = (nil)) ["eval.c":3490, 0x1200a9da4]
  11 funcall_subr(subr = 0x6, args = 0x11fff99a8) ["eval.c":3526, 0x1200aa058]
  12 funcall_recording_as(recorded_as = (...), nargs = 4, args = 0x11fff9c70) ["eval.c":3207, 0x1200a8d24]
  13 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  14 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  15 funcall_lambda(fun = (...), nargs = 4, arg_vector = 0x11fffa1e0) ["eval.c":3636, 0x1200aaa6c]
  16 funcall_recording_as(recorded_as = (...), nargs = 4, args = 0x11fffa1d8) ["eval.c":3223, 0x1200a8ed8]
  17 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  18 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  19 primitive_funcall(fn = 0x3ff8010fc20, nargs = 536844712, args = (nil)) ["eval.c":3488, 0x1200a9d80]
  20 funcall_subr(subr = 0x6, args = 0x11fff99a8) ["eval.c":3526, 0x1200aa058]
  21 Feval(form = (...)) ["eval.c":3064, 0x1200a84d8]
  22 condition_case_1(handlers = (...), bfun = 0x1200a7a00, barg = (...), hfun = 0x1200a3410, harg = (...)) ["eval.c":1672, 0x1200a3360]
  23 Fcondition_case_3(bodyform = (...), var = (...), handlers = (...)) ["eval.c":1735, 0x1200a37c0]
  24 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":655, 0x12006b41c]
  25 funcall_lambda(fun = (...), nargs = 4, arg_vector = 0x11fffb140) ["eval.c":3636, 0x1200aaa6c]
  26 funcall_recording_as(recorded_as = (...), nargs = 4, args = 0x11fffb138) ["eval.c":3223, 0x1200a8ed8]
  27 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  28 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  29 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffb6d8) ["eval.c":3636, 0x1200aaa6c]
  30 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffb6d0) ["eval.c":3223, 0x1200a8ed8]
  31 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  32 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  33 funcall_lambda(fun = (...), nargs = 2, arg_vector = 0x11fffbc80) ["eval.c":3636, 0x1200aaa6c]
  34 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffbc78) ["eval.c":3223, 0x1200a8ed8]
  35 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  36 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  37 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffc1f0) ["eval.c":3636, 0x1200aaa6c]
  38 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffc1e8) ["eval.c":3223, 0x1200a8ed8]
  39 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  40 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  41 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffc760) ["eval.c":3636, 0x1200aaa6c]
  42 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffc758) ["eval.c":3223, 0x1200a8ed8]
  43 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  44 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  45 funcall_lambda(fun = (...), nargs = 3, arg_vector = 0x11fffccb8) ["eval.c":3636, 0x1200aaa6c]
  46 funcall_recording_as(recorded_as = (...), nargs = 3, args = 0x11fffccb0) ["eval.c":3223, 0x1200a8ed8]
  47 Fapply(nargs = 3, args = 0x11fffce48) ["eval.c":3471, 0x1200a9c8c]
  48 funcall_recording_as(recorded_as = (...), nargs = 3, args = 0x11fffce40) ["eval.c":3191, 0x1200a8c94]
  49 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  50 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  51 funcall_lambda(fun = (...), nargs = 4, arg_vector = 0x11fffd3a8) ["eval.c":3636, 0x1200aaa6c]
  52 funcall_recording_as(recorded_as = (...), nargs = 4, args = 0x11fffd3a0) ["eval.c":3223, 0x1200a8ed8]
  53 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  54 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  55 funcall_lambda(fun = (...), nargs = 2, arg_vector = 0x11fffda68) ["eval.c":3636, 0x1200aaa6c]
  56 funcall_recording_as(recorded_as = (...), nargs = 2, args = 0x11fffda60) ["eval.c":3223, 0x1200a8ed8]
  57 Fapply(nargs = 3, args = 0x11fffda60) ["eval.c":3414, 0x1200a9a00]
  58 funcall_recording_as(recorded_as = (...), nargs = 3, args = 0x11fffda58) ["eval.c":3191, 0x1200a8c94]
  59 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  60 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  61 funcall_lambda(fun = (...), nargs = 3, arg_vector = 0x11fffdfc0) ["eval.c":3636, 0x1200aaa6c]
  62 funcall_recording_as(recorded_as = (...), nargs = 3, args = 0x11fffdfb8) ["eval.c":3223, 0x1200a8ed8]
  63 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  64 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  65 funcall_lambda(fun = (...), nargs = 1, arg_vector = 0x11fffe528) ["eval.c":3636, 0x1200aaa6c]
  66 funcall_recording_as(recorded_as = (...), nargs = 1, args = 0x11fffe520) ["eval.c":3223, 0x1200a8ed8]
  67 Ffuncall(nargs = 6, args = 0x11fff99a8) ["eval.c":3253, 0x1200a8fb4]
  68 Fbyte_code(bytestr = (...), vector = (...), maxdepth = (...)) ["bytecode.c":450, 0x12006ae54]
  69 funcall_lambda(fun = (...), nargs = 0, arg_vector = 0x11fffea90) ["eval.c":3636, 0x1200aaa6c]
  70 funcall_recording_as(recorded_as = (...), nargs = 0, args = 0x11fffea88) ["eval.c":3223, 0x1200a8ed8]
  71 apply1(fn = (...), arg = (...)) ["eval.c":3963, 0x1200ab708]
  72 Fcall_interactively(function = (...), record_flag = (...), keys = (...)) ["callint.c":390, 0x12006d94c]
  73 Fcommand_execute(cmd = (...), record = (...), keys = (...)) ["eval.c":2628, 0x1200a6e44]
  74 execute_command_event(command_builder = 0x140244b00, event = (...)) ["event-stream.c":3474, 0x1200c536c]
  75 Fdispatch_event(event = (...)) ["event-stream.c":3768, 0x1200c65bc]
  76 Fcommand_loop_1() ["cmdloop.c":542, 0x1200758dc]
  77 command_loop_1(dummy = (...)) ["cmdloop.c":462, 0x12007544c]
  78 condition_case_1(handlers = (...), bfun = 0x1200753a0, barg = (...), hfun = 0x120075b40, harg = (...)) ["eval.c":1672, 0x1200a3360]
  79 command_loop_2(dummy = (...)) ["cmdloop.c":235, 0x120075d1c]
  80 internal_catch(tag = (...), func = 0x11fff99a8, arg = (...), threw = (nil)) ["eval.c":1347, 0x1200a2e4c]
  81 initial_command_loop(load_me = (...)) ["cmdloop.c":273, 0x12007494c]
  82 Frunning_temacs_p() ["emacs.c":1315, 0x12009eb64]
(dbx) 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Carney        TEL:[41](22)782.90.60  http://www-digital.cern.ch/carney/
carney@gvc.dec.com  FAX:[41](22)782.94.92 

From xemacs-beta-request@cs.uiuc.edu  Mon Nov  4 06:34:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id GAA19366 for xemacs-beta-people; Mon, 4 Nov 1996 06:34:59 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id GAA19363 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 4 Nov 1996 06:34:58 -0600 (CST)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id GAA20211 for <xemacs-beta@cs.uiuc.edu>; Mon, 4 Nov 1996 06:34:52 -0600 (CST)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id MAA19471 for <xemacs-beta@cs.uiuc.edu>; Mon, 4 Nov 1996 12:34:31 GMT
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id MAA16174 for <xemacs-beta@cs.uiuc.edu>; Mon, 4 Nov 1996 12:36:44 GMT
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id MAA21667; Mon, 4 Nov 1996 12:41:46 GMT
Date: Mon, 4 Nov 1996 12:41:46 GMT
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199611041241.MAA21667@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: really sloooowwww things in 19.15
X-Sun-Charset: US-ASCII

One thing that really bugs me is the speed of error message parsing
in compile mode. The rest of XEmacs goes adeuately quickly but I have
to wait an unreasonably long time it seems for the error messages
to be parsed. I think this is the standard beta build.

The other thing that seems really slow is java-mode, but I can't get
so excited about this.

andy

From xemacs-beta-request@cs.uiuc.edu  Mon Nov  4 06:41:35 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id GAA19386 for xemacs-beta-people; Mon, 4 Nov 1996 06:41:35 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id GAA19383 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 4 Nov 1996 06:41:34 -0600 (CST)
Received: from red.parallax.co.uk (root@red.parallax.co.uk [194.159.4.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id GAA20341 for <xemacs-beta@cs.uiuc.edu>; Mon, 4 Nov 1996 06:41:31 -0600 (CST)
Received: from dumbo.parallax.co.uk (dumbo.parallax.co.uk [172.16.1.12]) by red.parallax.co.uk (8.6.12/8.6.12) with ESMTP id MAA19863 for <xemacs-beta@cs.uiuc.edu>; Mon, 4 Nov 1996 12:41:28 GMT
Received: from wrath.parallax.co.uk (wrath.parallax.co.uk [192.168.1.2]) by dumbo.parallax.co.uk (8.7.1/8.7.1) with SMTP id MAA16403 for <xemacs-beta@cs.uiuc.edu>; Mon, 4 Nov 1996 12:43:40 GMT
Received: by wrath.parallax.co.uk (SMI-8.6/SMI-SVR4)
	id MAA21797; Mon, 4 Nov 1996 12:48:41 GMT
Date: Mon, 4 Nov 1996 12:48:41 GMT
From: andyp@parallax.co.uk (Andy Piper)
Message-Id: <199611041248.MAA21797@wrath.parallax.co.uk>
To: xemacs-beta@cs.uiuc.edu
Subject: eos and jdb ?
X-Sun-Charset: US-ASCII

Are Sun going to do any integration between eos and jdb?

andy

From xemacs-beta-request@cs.uiuc.edu  Mon Nov  4 13:09:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA20583 for xemacs-beta-people; Mon, 4 Nov 1996 13:09:00 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA20580 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 4 Nov 1996 13:08:59 -0600 (CST)
Received: from dres.elam.org (root@cola41.scsn.net [206.25.247.41]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA03566 for <xemacs-beta@cs.uiuc.edu>; Mon, 4 Nov 1996 13:08:54 -0600 (CST)
Received: from dres.elam.org (localhost [127.0.0.1]) by dres.elam.org (8.7.6/8.7.3) with ESMTP id OAA07642 for <xemacs-beta@cs.uiuc.edu>; Mon, 4 Nov 1996 14:06:03 -0500
Message-Id: <199611041906.OAA07642@dres.elam.org>
To: XEmacs Beta List <xemacs-beta@cs.uiuc.edu>
reply-to: dres@scsn.net
Subject: two little doc typos
Date: Mon, 04 Nov 1996 14:05:58 -0500
From: James LewisMoss <dres@dres.elam.org>

I found two little documentation typos in the lispref manual (reading
info version).  15b2 version.
They are:

node: comparison of numbers
/= should say not equal

node: range table type
#s(range-table  missing ) at the end here.


-- 
@James LewisMoss                 | moss@cs.sc.edu | Blessed Be!
@    http://www.cs.sc.edu/~moss  | dres@scsn.net  | Linux is cool!
@"Argue for your limitations and sure enough, they're yours." Bach

From xemacs-beta-request@cs.uiuc.edu  Mon Nov  4 16:50:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA21546 for xemacs-beta-people; Mon, 4 Nov 1996 16:50:41 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA21543 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 4 Nov 1996 16:50:40 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id QAA12145 for <xemacs-beta@cs.uiuc.edu>; Mon, 4 Nov 1996 16:50:40 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA00661; Mon, 4 Nov 1996 14:50:03 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA02367; Mon, 4 Nov 1996 14:49:59 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA08029; Mon, 4 Nov 1996 14:49:57 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA15382; Mon, 4 Nov 1996 14:49:57 -0800
Date: Mon, 4 Nov 1996 14:49:57 -0800
Message-Id: <199611042249.OAA15382@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: dres@scsn.net
Cc: XEmacs Beta List <xemacs-beta@cs.uiuc.edu>
Subject: two little doc typos
In-Reply-To: <199611041906.OAA07642@dres.elam.org>
References: <199611041906.OAA07642@dres.elam.org>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: text/plain; charset=US-ASCII

>>>>> "James" == James LewisMoss <dres@dres.elam.org> writes:

James> I found two little documentation typos in the lispref manual (reading
James> info version).  15b2 version.
James> They are:

James> node: comparison of numbers
James> /= should say not equal

Strictly speaking, the current documentation is accurate.  However,
I've made the following change, which should make it a little clearer.

*** /tmp/geta15345	Mon Nov  4 14:40:35 1996
--- numbers.texi	Mon Nov  4 14:40:33 1996
***************
*** 261,268 ****
  @end defun
  
  @defun /= number-or-marker1 number-or-marker2
! This function tests whether its arguments are numerically equal, and
! returns @code{t} if they are not, and @code{nil} if they are.
  @end defun
  
  @defun <  number-or-marker1 number-or-marker2
--- 261,268 ----
  @end defun
  
  @defun /= number-or-marker1 number-or-marker2
! This function tests whether its arguments are numerically not equal.  It
! returns @code{t} if so, and @code{nil} otherwise.
  @end defun
  
  @defun <  number-or-marker1 number-or-marker2


James> node: range table type
James> #s(range-table  missing ) at the end here.

I don't see any missing `)'

Martin

From xemacs-beta-request@cs.uiuc.edu  Mon Nov  4 18:04:08 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA21861 for xemacs-beta-people; Mon, 4 Nov 1996 18:04:08 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA21858 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 4 Nov 1996 18:04:07 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id SAA13910 for <xemacs-beta@cs.uiuc.edu>; Mon, 4 Nov 1996 18:04:05 -0600 (CST)
Received: (qmail 545 invoked by uid 501); 5 Nov 1996 00:06:43 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: eval-interactive should return the result of the eval.
References: <199611040305.TAA00378@infodock.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Bob Weiner's message of Sun, 3 Nov 1996 19:05:32 -0800
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: text/plain; charset=US-ASCII
Date: 04 Nov 1996 16:06:42 -0800
Message-ID: <m2g22pxv59.fsf@deanna.miranova.com>
Lines: 45
X-Mailer: Red Gnus v0.53/XEmacs 19.15

>>>>> "Bob" == Bob Weiner <weiner@infodock.com> writes:

Bob> This should happen even when a defvar is treated as a defconst,
Bob> but as of b2, it does not.  The fix is simply to change the 'progn'
Bob> to a 'prog1'.

Bob> With this change, the symbol name of the defvar is returned
Bob> which I think is enough feedback to know that the defvar was
Bob> actually re-evaluated, eliminating the need for the 'defvar
Bob> treated as defconst' message and its ensuing delay.

Sounds good to me.  Seeing "" returned is confusing.  Having the name
returned is also consistent with the return value of defun, so I think
this is O.K.

[Patch is against 19.15-b2]

*** lisp-mode.el~	Sun Sep 15 11:31:31 1996
--- lisp-mode.el	Mon Nov  4 15:53:40 1996
***************
*** 367,376 ****
    (if (and (consp expr)
  	   (eq (car expr) 'defvar)
  	   (> (length expr) 2))
!       (progn (eval (cons 'defconst (cdr expr)))
! 	     (message "defvar treated as defconst")
! 	     (sit-for 1)
! 	     (message ""))
      (eval expr)))
  
  (defun eval-last-sexp (eval-last-sexp-arg-internal)
--- 367,373 ----
    (if (and (consp expr)
  	   (eq (car expr) 'defvar)
  	   (> (length expr) 2))
!       (eval (cons 'defconst (cdr expr)))
      (eval expr)))
  
  (defun eval-last-sexp (eval-last-sexp-arg-internal)

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Nov  5 16:43:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA29203 for xemacs-beta-people; Tue, 5 Nov 1996 16:43:31 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA29200 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 5 Nov 1996 16:43:30 -0600 (CST)
Received: from nvwls.cc.purdue.edu (root@nvwls.cc.purdue.edu [128.210.7.3]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA17113 for <XEmacs-beta@XEmacs.org>; Tue, 5 Nov 1996 16:43:26 -0600 (CST)
Received: from nvwls.cc.purdue.edu (nuspl@localhost [127.0.0.1]) by nvwls.cc.purdue.edu (8.7.5/8.7.3) with ESMTP id RAA01294 for <XEmacs-beta@XEmacs.org>; Tue, 5 Nov 1996 17:39:04 -0500
Message-Id: <199611052239.RAA01294@nvwls.cc.purdue.edu>
Reply-to: nuspl@purdue.edu
X-Mailer: MH-E 5.0.2
X-Attribution: JJN
X-Face: K'Q`VIQx)c-;TPHDA`.,kBQq(WyNe3AdopJ?B(.4yT%n|F?4>+?x]pQ4XC83s-4;|U{%9x]
 =yr4dko
To: XEmacs-beta@xemacs.org
Subject: posix c font-lock'ing
Date: Tue, 05 Nov 1996 17:39:01 -0500
From: "Joseph J. Nuspl Jr." <nuspl@nvwls.cc.purdue.edu>


POSIX reserves all symbols starting with pw_ for struct passwd.  For
font-lock'ing purposes, would font-lock-other-type-face be the
appropriate face for struct members?




From xemacs-beta-request@cs.uiuc.edu  Wed Nov  6 13:46:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA06088 for xemacs-beta-people; Wed, 6 Nov 1996 13:46:36 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA06085 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 6 Nov 1996 13:46:35 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA18798 for <xemacs-beta@xemacs.org>; Wed, 6 Nov 1996 13:46:20 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id UAA12877; Wed, 6 Nov 1996 20:45:43 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: Emacs inferior blah blah...
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 06 Nov 1996 20:45:43 +0100
Message-ID: <kigzq0vt3bs.fsf@jagor.srce.hr>
Lines: 10
X-Mailer: Red Gnus v0.54/XEmacs 19.14

Does anyone knowledgable care to answer to Naggum's message
<3056268466467465@naggum.no>, please?  I do not know enough about
XEmacs internals to do so, and the casual observers will probably
think he is right, if noone answers.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Wed Nov  6 15:09:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id PAA06536 for xemacs-beta-people; Wed, 6 Nov 1996 15:09:30 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA06533 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 6 Nov 1996 15:09:29 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA18944 for <xemacs-beta@xemacs.org>; Wed, 6 Nov 1996 15:09:20 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id WAA23814; Wed, 6 Nov 1996 22:09:10 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: bug when parsing command-line arguments in batch mode?
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 06 Nov 1996 22:09:09 +0100
Message-ID: <kign2wvszgq.fsf@jagor.srce.hr>
Lines: 14
X-Mailer: Red Gnus v0.54/XEmacs 19.14

How come that this simple code doesn't work in XEmacs 19.14:
$ xemacs -batch a.c -eval '(insert "x")' -eval '(save-buffer)'

But the following works:
$ xemacs -batch -eval '(find-file "a.c")' -eval '(insert "x")' \
  -eval '(save-buffer)'

Is it a bug?  Note that the same thing worked fine in 19.13.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Wed Nov  6 18:34:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA07364 for xemacs-beta-people; Wed, 6 Nov 1996 18:34:42 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA07361 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 6 Nov 1996 18:34:41 -0600 (CST)
Received: from sym.primuscorp.com (root@[207.14.28.20]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id SAA19300 for <xemacs-beta@xemacs.org>; Wed, 6 Nov 1996 18:34:37 -0600 (CST)
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id QAA17483 for <xemacs-beta@xemacs.org>; Wed, 6 Nov 1996 16:36:08 -0800
Received: from roy by horus (SMI-8.6/SMI-SVR4)
	id QAA18872; Wed, 6 Nov 1996 16:34:52 -0800
Received: by roy (SMI-8.6/SMI-SVR4)
	id QAA17345; Wed, 6 Nov 1996 16:35:09 -0800
Date: Wed, 6 Nov 1996 16:35:09 -0800
Message-Id: <199611070035.QAA17345@roy>
From: Damon Lipparelli <lipp@primus.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: ediff-files not autoload'd
Reply-To: Damon Lipparelli <lipp@primus.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.15 (beta2) ]

(I don't remember seeing this one go by....)

With the SPARCworks stuff compiled in at least, ediff-files isn't
autoload'd under 19.15b2.

-lipp

---

I left my WALLET in the BATHROOM!!

From xemacs-beta-request@cs.uiuc.edu  Thu Nov  7 12:07:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA13895 for xemacs-beta-people; Thu, 7 Nov 1996 12:07:16 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA13892 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 7 Nov 1996 12:07:15 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id MAA00411 for <xemacs-beta@cs.uiuc.edu>; Thu, 7 Nov 1996 12:07:06 -0600 (CST)
Received: (qmail 23647 invoked by uid 501); 7 Nov 1996 18:09:23 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [PATCH] Easing the customization of the ToolBar
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 07 Nov 1996 10:09:22 -0800
Message-ID: <m2k9rxdbfx.fsf@deanna.miranova.com>
Lines: 90
X-Mailer: Red Gnus v0.55/XEmacs 19.15

This patch is driven from a request I got last weekend for a good
method of making the toolbar print function use ps-print instead of
lpr-buffer (lpr-buffer doesn't really work for me either), and the
posting on comp.emacs.xemacs requesting query-replace-regexp instead
of query-replace.  Both of those functions are hard coded into the
declaration of the default toolbar, and thus fairly difficult to
customize.

This patch adds two functions `toolbar-print' and `toolbar-replace',
with corresponding variables `toolbar-print-command' and
`toolbar-replace-command' (defaulting to the previous values) to
x-toolbar.el.

I've already run this proposal by Ben, and it is consistent with the
treatment of other toolbar functions like mail (which needs to be
fixed due to hardcoding the setting of 'vm-exit-hook when multiple
frames are in use).  The patch is against XEmacs 19.15 beta 2.


*** x11/x-toolbar.el~	Wed Nov  6 08:37:00 1996
--- x11/x-toolbar.el	Thu Nov  7 09:32:49 1996
***************
*** 142,147 ****
--- 142,170 ----
    (select-frame toolbar-news-frame)
    (raise-frame toolbar-news-frame))
  
+ ;;
+ ;; toolbar printing variable and defun
+ ;;
+ (defvar toolbar-print-command 'lpr-buffer
+   "Command to run when the Print Icon is selected from the toolbar.
+ Set this to `ps-print-buffer-with-faces' if you primarily print with
+ a postscript printer.")
+ 
+ (defun toolbar-print ()
+   "Print current buffer."
+   (funcall toolbar-print-command))
+ 
+ ;;
+ ;; toolbar replacement variable and defun
+ ;;
+ (defvar toolbar-replace-command 'query-replace
+   "Command to run when the Replace Icon is selected from the toolbar.
+ One possibility for a different value would be `query-replace-regexp'.")
+ 
+ (defun toolbar-replace ()
+   "Run a query-replace -type function on the current buffer."
+   (funcall toolbar-replace-command))
+ 
  (defvar toolbar-last-win-icon nil "A `last-win' icon set.")
  (defvar toolbar-next-win-icon nil "A `next-win' icon set.")
  (defvar toolbar-file-icon     nil "A `file' icon set.")
***************
*** 230,243 ****
      [toolbar-file-icon		find-file	t	"Open a file"	]
      [toolbar-folder-icon	dired		t	"View directory"]
      [toolbar-disk-icon		save-buffer	t	"Save buffer"	]
!     [toolbar-printer-icon	lpr-buffer	t	"Print buffer"	]
      [toolbar-cut-icon		x-kill-primary-selection t "Kill region"]
      [toolbar-copy-icon		x-copy-primary-selection t "Copy region"]
      [toolbar-paste-icon		x-yank-clipboard-selection t
  				"Paste from clipboard"]
      [toolbar-undo-icon		undo		t	"Undo edit"	]
      [toolbar-spell-icon		toolbar-ispell	t	"Spellcheck"	]
!     [toolbar-replace-icon	query-replace	t	"Replace text"	]
      [toolbar-mail-icon		toolbar-mail	t	"Mail"		]
      [toolbar-info-icon		toolbar-info	t	"Information"	]
      [toolbar-compile-icon	toolbar-compile	t	"Compile"	]
--- 253,266 ----
      [toolbar-file-icon		find-file	t	"Open a file"	]
      [toolbar-folder-icon	dired		t	"View directory"]
      [toolbar-disk-icon		save-buffer	t	"Save buffer"	]
!     [toolbar-printer-icon	toolbar-print	t	"Print buffer"	]
      [toolbar-cut-icon		x-kill-primary-selection t "Kill region"]
      [toolbar-copy-icon		x-copy-primary-selection t "Copy region"]
      [toolbar-paste-icon		x-yank-clipboard-selection t
  				"Paste from clipboard"]
      [toolbar-undo-icon		undo		t	"Undo edit"	]
      [toolbar-spell-icon		toolbar-ispell	t	"Spellcheck"	]
!     [toolbar-replace-icon	toolbar-replace	t	"Replace text"	]
      [toolbar-mail-icon		toolbar-mail	t	"Mail"		]
      [toolbar-info-icon		toolbar-info	t	"Information"	]
      [toolbar-compile-icon	toolbar-compile	t	"Compile"	]

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Fri Nov  8 02:47:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id CAA16575 for xemacs-beta-people; Fri, 8 Nov 1996 02:47:52 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id CAA16572 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 8 Nov 1996 02:47:51 -0600 (CST)
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id CAA28711 for <xemacs-beta@cs.uiuc.edu>; Fri, 8 Nov 1996 02:47:50 -0600 (CST)
Received: (qmail 10529 invoked by uid 52477); 8 Nov 1996 08:47:46 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Cc: Per Bothner <bothner@cygnus.com>
Subject: Eterm patch
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sudish@mindspring.com>
Date: 08 Nov 1996 03:47:45 -0500
Message-ID: <yviad8xpq8ge.fsf@atreides.mindspring.com>
Lines: 32
X-Mailer: Red Gnus v0.56/XEmacs 19.15

XEmacs 19.15 [Lucid] (i586-unknown-linux2.0.20)

listify-key-sequence is a GNU Emacs-ism which isn't needed in
XEmacs.  The other bit strips ^M's from tgdb completion buffers.

BTW, I'd love to see t{gdb|perldb|dbx|etc} become the default.  Or a
large blurb encouraging people to use eterm's stuff, perhaps?

--Sudish

--- term.el~	Sun Sep  8 19:51:25 1996
+++ term.el	Fri Nov  8 03:34:36 1996
@@ -3197,7 +3197,7 @@
 	    (set-window-configuration conf))
 	(if (eq first ?\ )
 	    (set-window-configuration conf)
-	  (setq unread-command-events (listify-key-sequence key)))))))
+	  (setq unread-command-events (append key nil)))))))
 
 ;;; Converting process modes to use term mode
 ;;; ===========================================================================
--- tgud.el~	Mon Jun 12 22:07:06 1995
+++ tgud.el	Fri Nov  8 03:38:31 1996
@@ -285,7 +285,7 @@
 ;; output of GDB up to the next prompt and build the completion list.
 (defun tgud-gdb-complete-filter (string)
   (setq string (concat tgud-gdb-complete-string string))
-  (while (string-match "\n" string)
+  (while (string-match "\r?\n" string)
     (setq tgud-gdb-complete-list
 	  (cons (substring string tgud-gdb-complete-break (match-beginning 0))
 		tgud-gdb-complete-list))

From xemacs-beta-request@cs.uiuc.edu  Fri Nov  8 08:08:30 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id IAA20736 for xemacs-beta-people; Fri, 8 Nov 1996 08:08:30 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA20733 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 8 Nov 1996 08:08:29 -0600 (CST)
Received: from dowjones.com (firewall-user@gateway.dowjones.com [143.131.189.4]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id IAA22174 for <xemacs-beta@xemacs.org>; Fri, 8 Nov 1996 08:08:26 -0600 (CST)
Received: by dowjones.com; id JAA29461; Fri, 8 Nov 1996 09:10:35 -0500 (EST)
Received: from wsj.dowjones.com(143.131.186.4) by gateway.dowjones.com via smap (V3.1.1)
	id xma029424; Fri, 8 Nov 96 09:10:15 -0500
Received: from nss_interbox.dowjones.com ([143.131.190.35]) by wsj.dowjones.com (5.x/SMI-SVR4)
	id AA06068; Fri, 8 Nov 1996 09:01:13 -0500
Message-Id: <32835B5B.233B@nrs.dowjones.com>
Date: Fri, 08 Nov 1996 10:10:03 -0600
From: wkirk <wkirk@wsj.dowjones.com>
Organization: Dow Jones & Company, Inc.
X-Mailer: Mozilla 2.0 (Win16; U)
Mime-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: end-of-buffer broken when a large glyph is displayed (19.15b2)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

end-of-buffer (control end) fails to move point to end of buffer when a 
large glyph is displayed.  Specifically, the problem is the call
  (recenter -3)

Repeat by: (tested in a frame with geometry 81x40)
Evaluate the following at the top of a Lisp Interaction buffer

(let ((extent (make-extent 1 2))
      (glyph (make-glyph (concat data-directory "xemacs.xpm"))))
  (set-extent-begin-glyph extent glyph))

Then split the window (C-x 2) and insert a bunch of newlines until the 
window has scrolled.  Now go to the end of the first line in the buffer 
and do a control end.  Point will end up in the middle of the junk that 
the eval printed.

- Joel Peterson

From xemacs-beta-request@cs.uiuc.edu  Fri Nov  8 19:40:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA23204 for xemacs-beta-people; Fri, 8 Nov 1996 19:40:52 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA23201 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 8 Nov 1996 19:40:51 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id TAA03961 for <xemacs-beta@cs.uiuc.edu>; Fri, 8 Nov 1996 19:40:48 -0600 (CST)
Received: (qmail 4345 invoked by uid 501); 9 Nov 1996 01:43:20 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Performance Issues
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 08 Nov 1996 17:43:19 -0800
Message-ID: <m2bud8rqko.fsf@deanna.miranova.com>
Lines: 24
X-Mailer: Red Gnus v0.56/XEmacs 19.15

(Ignoring display issues for the moment)  Two very striking examples
of the performance difference between GNU Emacs 19.34 and XEmacs 19.1[45]
are the speed of batch byte-compilation and the speed of minibuffer
operations (accented by use of the wonderful icomplete package).

In the case of the command-loop (which I assume to be largely
responsible for the slow speed of batch byte-compilation), it is
implemented in lisp with the comment:

;; Putting this in lisp slows things down.


The minibuffer is largely implemented in lisp.  Both of these
functions are coded in C in GNU Emacs.

Could someone enlighten me on the design decisions that led to the
current implementation?  What are we getting in return for the reduced
performance and the inconvenience of variant code from Emacs?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov  9 11:29:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id LAA28640 for xemacs-beta-people; Sat, 9 Nov 1996 11:29:44 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA28637 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 9 Nov 1996 11:29:43 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA24072 for <xemacs-beta@xemacs.org>; Sat, 9 Nov 1996 11:29:36 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id SAA18430; Sat, 9 Nov 1996 18:29:09 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org, steve@miranova.com
Subject: Dired highlighting
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 09 Nov 1996 18:29:08 +0100
Message-ID: <kigram3w523.fsf@jagor.srce.hr>
Lines: 36
X-Mailer: Red Gnus v0.57/XEmacs 19.14

According to Steve's descriptions, I have put the following in my
.emacs:

;; Dired beautification:
(if running-xemacs
    (add-hook 'dired-load-hook
    (lambda ()
      (require 'dired-xemacs-highlight)
      (set-face-foreground 'dired-face-boring "DarkGoldenrod")
      (set-face-foreground 'dired-face-socket "DarkCyan"))
    t))

It works like a charm, but when I use XEmacs on tty-s, I get the
following error:

Signalling: (wrong-type-argument symbolp 32)
  check-valid-instantiator([32 2 "UUUU"] image)
  canonicalize-spec-list([32 2 "UUUU"] image)
  set-specifier(#<image-specifier global=<unspecified> fallback=#<image-specifier global=<unspecified> 0x17a> 0x989> [32 2 "UUUU"] nil nil nil)
  set-face-property(dired-face-boring background-pixmap [32 2 "UUUU"] nil nil nil)
  set-face-background-pixmap(dired-face-boring [32 2 "UUUU"])
  byte-code("!\"!!!! =!\"\"\"!!! =!\"\"\"!!! =!\"!!!!! =\"!!!! =\"!!!! =\"!!!! =\"!!!!! =\"\"" [require dired dired-extra "dired-x" provide dired-xemacs-highlight find-face dired-face-marked make-face face-differs-from-default-p device-class color set-face-foreground face-foreground default set-face-background "PaleVioletRed" set-face-underline-p t dired-face-deleted "LightSlateGray" dired-face-directory make-face-bold make-face-bold-italic dired-face-executable "SeaGreen" dired-face-setuid "Red" dired-face-socket "Gold" make-face-italic dired-face-symlink "MediumBlue" dired-face-boring "Grey" set-face-background-pixmap [32 2 "UUUU"]] 4)
  load-internal("dired-xemacs-highlight" nil t nil)
  load("dired-xemacs-highlight" nil t nil)
  require(dired-xemacs-highlight)
  (lambda nil (require (quote dired-xemacs-highlight)) (set-face-foreground (quote dired-face-boring) "DarkGoldenrod") (set-face-foreground (quote dired-face-socket) "DarkCyan"))()
  run-hooks(dired-load-hook)
  byte-code("=!\"!!" [system-type vax-vms load "dired-vms" string-match "XEmacs" emacs-version "dired-xemacs-menu" run-hooks dired-load-hook] 3)
  load-internal("dired" nil nil nil)
  load("dired" nil nil nil)

-- 
WWW:          World-Wide-Waste.  Waste management corporation, which
              handles the billions of tons of garbage generated by just
              about everybody these days.
You owe the Oracle a good book.  In HyperText, please.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov  9 13:59:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA29167 for xemacs-beta-people; Sat, 9 Nov 1996 13:59:00 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA29164 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 9 Nov 1996 13:58:59 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id NAA25544 for <xemacs-beta@cs.uiuc.edu>; Sat, 9 Nov 1996 13:58:51 -0600 (CST)
Received: (qmail 11008 invoked by uid 501); 9 Nov 1996 20:00:39 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Dired highlighting
References: <kigram3w523.fsf@jagor.srce.hr>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Hrvoje Niksic's message of 09 Nov 1996 18:29:08 +0100
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 09 Nov 1996 12:00:38 -0800
Message-ID: <m27mnvyr6h.fsf@deanna.miranova.com>
Lines: 33
X-Mailer: Red Gnus v0.57/XEmacs 19.15

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> According to Steve's descriptions, I have put the following in my
Hrv> .emacs:

Hrv> ;; Dired beautification:
Hrv> (if running-xemacs
Hrv>     (add-hook 'dired-load-hook
Hrv>     (lambda ()
Hrv>       (require 'dired-xemacs-highlight)
Hrv>       (set-face-foreground 'dired-face-boring "DarkGoldenrod")
Hrv>       (set-face-foreground 'dired-face-socket "DarkCyan"))
Hrv>     t))

That code sequence contains a typo.  My version of it looks like:

(if (and running-xemacs
         (console-on-window-system-p))
    (add-hook 'dired-load-hook
              #'(lambda ()
                  (require 'dired-xemacs-highlight)
                  (set-face-foreground 'dired-face-boring "DarkGoldenrod")
                  (set-face-foreground 'dired-face-socket "DarkCyan"))
              t))

It looks like the set-face-foreground stuff is bombing on you with X11
support.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov  9 14:20:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA29228 for xemacs-beta-people; Sat, 9 Nov 1996 14:20:17 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA29225 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 9 Nov 1996 14:20:16 -0600 (CST)
Received: from sweden.aosi.com (mail.aosi.com [206.98.255.22]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA24225; Sat, 9 Nov 1996 14:20:13 -0600 (CST)
Received: from hlork ([206.98.254.53]) by sweden.aosi.com
          (post.office MTA v1.9.3b ID# 0-16356) with SMTP id AAA94;
          Sat, 9 Nov 1996 15:20:21 -0500
Sender: root@.aosi.com
Message-ID: <3284EA10.152206EC@aosi.com>
Date: Sat, 09 Nov 1996 15:31:12 -0500
From: Joel Peterson <tarzan@aosi.com>
Organization: Me Tarzan, you Jane?
X-Mailer: Mozilla 3.0 (X11; U; Linux 1.3.97 i586)
MIME-Version: 1.0
To: cthomp@xemacs.org
CC: xemacs-beta@xemacs.org
Subject: Frame in a glyph
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chuck -

A couple of weeks ago I volunteered the idea of placing an emacs frame
in a glyph and offered to write the code to do so.  Well, I have done
that using 19.15 beta 2 (with my two previous feature patches applied:
menubar accelerator, window geometry manager) as my code base.  This
involved the creation of a new console type (glyph) along with changes
to the calling conventions of most redisplay console methods and the
addition of some new console methods.  It also required changing much of
the X device and event code to be aware of the fact that it might be
called with a frame or device that is not an X device, but that lives
inside of another frame which is.  It adds a new glyph type (sub-frame)
which can be instanced as a color-pixmap.  Thus I was able to use the
existing X console methods and redisplay code to implement the glyph
device.  The glyph device supports most features of the X device (even
mouse and selection support) with the exception of those requiring an X
widget (e.g. scrollbars).  It should be `easy' to be implement the glyph
device within other console types.

The question is ... what now?

I would like to post it for people to play with.  However, the patch
file for frame in a glyph approaches 300K and involves 6 new files which
implement the glyph console type.  When new betas start coming out
again, it will be necessary to hand patch the frame in a glyph code up
to each new beta level (due to all the mainly cosmetic changes to the X
and redisplay code).  Integrating the frame in a glyph with the main
code base is also problematic.  There is a need for info documentation
to be written and for generic lisp code and default specifier settings
(some settings are already in place) to support working with frames in a
glyph.  Therefore, I'm guessing it won't be an easy integration into the
main code base.  Plus it represents a pretty major addition of
functionality (at least in terms of code changes).

There are bound to still be bugs in the code; since there are a lot of
places where a frame or device is just assumed to be an X frame or an X
device, where now it might not be.  I should be able to ferret out many
of these in the next week.  Some optional packages might be broken by
this patch (energize, external widget, epoch, ???) although that seems
unlikely unless the frame in a glyph is actually used.

-- 
And on the Eighth day, the Lord said "Let there be Advertisements."
And lo, there were advertisements.  And the Lord saw the
advertisements.  And the Lord went to the kitchen for a snack.
                - Joel Peterson
                       Supreme Deputy of scratching Dogbert behind the
                       ears until he has little leg spasms.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov  9 14:32:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA29269 for xemacs-beta-people; Sat, 9 Nov 1996 14:32:13 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA29266 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 9 Nov 1996 14:32:12 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA26348 for <xemacs-beta@cs.uiuc.edu>; Sat, 9 Nov 1996 14:32:09 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id VAA03597; Sat, 9 Nov 1996 21:32:04 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Dired highlighting
References: <kigram3w523.fsf@jagor.srce.hr> <m27mnvyr6h.fsf@deanna.miranova.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 09 Nov 1996 21:32:04 +0100
In-Reply-To: Steven L Baur's message of 09 Nov 1996 12:00:38 -0800
Message-ID: <kigbud7vwl7.fsf@jagor.srce.hr>
Lines: 27
X-Mailer: Red Gnus v0.57/XEmacs 19.14

Steven L. Baur (steve@miranova.com) wrote:
> That code sequence contains a typo.  My version of it looks like:
> (if (and running-xemacs
>          (console-on-window-system-p))
>     (add-hook 'dired-load-hook
>               #'(lambda ()
>                   (require 'dired-xemacs-highlight)
>                   (set-face-foreground 'dired-face-boring "DarkGoldenrod")
>                   (set-face-foreground 'dired-face-socket "DarkCyan"))
>               t))
> 
> It looks like the set-face-foreground stuff is bombing on you with X11
> support.

Hmm, I don't think that's what I want, because then I get *no*
highlighting on tty-s.  I believe highlighting should work on tty-s
too.

BTW, why is in dired C-n bound to dired-next-line, whereas [down] is
bound to next-line.  Is it a bug or a feature?  In GNU Emacs both are
bound to dired-next-line.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov  9 15:50:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id PAA29505 for xemacs-beta-people; Sat, 9 Nov 1996 15:50:03 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA29502 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 9 Nov 1996 15:50:02 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id PAA00487 for <xemacs-beta@cs.uiuc.edu>; Sat, 9 Nov 1996 15:50:00 -0600 (CST)
Received: (qmail 12802 invoked by uid 501); 9 Nov 1996 21:52:20 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Frame in a glyph
References: <3284EA10.152206EC@aosi.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Joel Peterson's message of Sat, 09 Nov 1996 15:31:12 -0500
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 09 Nov 1996 13:52:19 -0800
Message-ID: <m2wwvvx7fw.fsf@deanna.miranova.com>
Lines: 19
X-Mailer: Red Gnus v0.57/XEmacs 19.15

>>>>> "Joel" == Joel Peterson <tarzan@aosi.com> writes:

Joel> The question is ... what now?

Joel> I would like to post it for people to play with.  However, the
Joel> patch file for frame in a glyph approaches 300K and involves 6
Joel> new files which implement the glyph console type.

Go ahead and post it.  The patch for 19.15 beta2 -> beta3 is already
enormous so that is not particularly an issue.  What is at issue is
that we have to get a 19.15 released as quickly as possible, so the
quicker the integration issues with the baseline can be identified,
the better.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov  9 17:58:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id RAA29832 for xemacs-beta-people; Sat, 9 Nov 1996 17:58:40 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA29829 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 9 Nov 1996 17:58:39 -0600 (CST)
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id RAA02074 for <xemacs-beta@cs.uiuc.edu>; Sat, 9 Nov 1996 17:58:38 -0600 (CST)
Received: (qmail 5760 invoked by uid 52477); 9 Nov 1996 23:58:37 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Subject: zmacs-regions, x selections, and tty's
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sudish@mindspring.com>
Date: 09 Nov 1996 18:58:37 -0500
Message-ID: <yviabud6vn0y.fsf@atreides.mindspring.com>
Lines: 39
X-Mailer: Red Gnus v0.56/XEmacs 19.15

The x-selection stuff hanging off the zmacs-*-hooks causes havoc on
tty's attached to XEmacsen started on X displays.  Particularly
problematic with viper's d commands and with the bug in message.el
that brings up reply buffers with the region active.

Making the add-hook's conditional on X being present seems wrong,
since one may attach either type of display at any time.  So, I
kludged around this in the hook.  

It seems like this is a pretty generic problem with the (extremely
useful) simultaneous tty's+x stuff.  Is there a generic solution?

-Sudish

--- x11/x-init.el~	Sat Nov  9 18:50:23 1996
+++ x11/x-init.el	Sat Nov  9 18:50:23 1996
@@ -150,10 +150,18 @@
     (if (featurep 'toolbar)
         (init-x-toolbar))
     ;; these are only ever called if zmacs-regions is true.
-    (add-hook 'zmacs-deactivate-region-hook 'x-disown-selection)
-    (add-hook 'zmacs-activate-region-hook   'x-activate-region-as-selection)
-    (add-hook 'zmacs-update-region-hook     'x-activate-region-as-selection)
-
+    (add-hook 'zmacs-deactivate-region-hook 
+	      (lambda () 
+		(if (console-on-window-system-p) 
+		    (x-disown-selection))))
+    (add-hook 'zmacs-activate-region-hook
+	      (lambda () 
+		(if (console-on-window-system-p) 
+		    (x-activate-region-as-selection))))
+    (add-hook 'zmacs-update-region-hook
+	      (lambda ()
+		  (if (console-on-window-system-p)
+		      (x-activate-region-as-selection))))
     ;; Motif-ish bindings
     ;; The following two were generally unliked.
     ;;(define-key global-map '(shift delete)   'x-kill-primary-selection)

From xemacs-beta-request@cs.uiuc.edu  Sat Nov  9 18:33:05 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA29980 for xemacs-beta-people; Sat, 9 Nov 1996 18:33:05 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA29977 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 9 Nov 1996 18:33:04 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA02509 for <xemacs-beta@cs.uiuc.edu>; Sat, 9 Nov 1996 18:32:50 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id BAA27949; Sun, 10 Nov 1996 01:32:08 +0100 (MET)
Sender: hniksic@public.srce.hr
To: Sudish Joseph <sudish@mindspring.com>
Cc: XEmacs beta <xemacs-beta@cs.uiuc.edu>, larsi@ifi.uio.no
Subject: Re: zmacs-regions, x selections, and tty's
References: <yviabud6vn0y.fsf@atreides.mindspring.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 10 Nov 1996 01:32:08 +0100
In-Reply-To: Sudish Joseph's message of 09 Nov 1996 18:58:37 -0500
Message-ID: <kig683ex01j.fsf@jagor.srce.hr>
Lines: 15
X-Mailer: Red Gnus v0.57/XEmacs 19.14

Sudish Joseph (sudish@mindspring.com) wrote:
> problematic with viper's d commands and with the bug in message.el
> that brings up reply buffers with the region active.

It's not a bug -- it's a feature.  Disable it with
(setq message-xmas-dont-activate-region t)

Or lobby Lars to do it by default.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The IDIOT.  Usually a cretin, morpohodite, or old COBOL programmer
selected to be the system administrator by a committee of cretins,
morphodites, and old COBOL programmers.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov  9 19:15:15 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA00245 for xemacs-beta-people; Sat, 9 Nov 1996 19:15:15 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA00242 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 9 Nov 1996 19:15:14 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id TAA03000 for <xemacs-beta@cs.uiuc.edu>; Sat, 9 Nov 1996 19:14:59 -0600 (CST)
Received: (qmail 14358 invoked by uid 501); 10 Nov 1996 01:17:14 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: zmacs-regions, x selections, and tty's
References: <yviabud6vn0y.fsf@atreides.mindspring.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Sudish Joseph's message of 09 Nov 1996 18:58:37 -0500
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 09 Nov 1996 17:17:13 -0800
Message-ID: <m2683eyciu.fsf@deanna.miranova.com>
Lines: 22
X-Mailer: Red Gnus v0.57/XEmacs 19.15

>>>>> "Sudish" == Sudish Joseph <sudish@mindspring.com> writes:

Sudish> The x-selection stuff hanging off the zmacs-*-hooks causes
Sudish> havoc on tty's attached to XEmacsen started on X displays.
Sudish> Particularly problematic with viper's d commands and with the
Sudish> bug in message.el that brings up reply buffers with the region
Sudish> active.

That's actually a feature, but Lars has already provided a way to turn
it off:

(setq message-xmas-dont-activate-region t)

You're certainly right about the havoc ...

I also notice gnuattach run from an xterm & zsh doesn't completely
restore the terminal modes.  I thought that bug was fixed. :-(
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov  9 22:05:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id WAA00648 for xemacs-beta-people; Sat, 9 Nov 1996 22:05:37 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id WAA00645 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 9 Nov 1996 22:05:35 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id WAA24640 for <xemacs-beta@xemacs.org>; Sat, 9 Nov 1996 22:05:25 -0600 (CST)
Received: from infodock.com ([206.13.40.192]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id UAA21588 for <xemacs-beta@xemacs.org>; Sat, 9 Nov 1996 20:04:55 -0800
Received: (from weiner@localhost) by infodock.com (8.8.0/8.7.3) id UAA00219; Sat, 9 Nov 1996 20:59:22 -0800
Date: Sat, 9 Nov 1996 20:59:22 -0800
From: Bob Weiner <weiner@infodock.com>
Message-Id: <199611100459.UAA00219@infodock.com>
To: xemacs-beta@infodock.com
Subject: New java font lock support for consideration in XEmacs 19.15.

The only change is a complete revamp of the Java support using 
code posted by Anders Lindgren and further modified by me.  This
handles Java code extremely well and looks very nice with appropriate
colors or other font-lock settings, especially when font-lock-keywords
are set to the highest level, java-font-lock-keywords-3.  The speed
seems quite acceptable, especially since Java files tend not to be
very large, e.g. over 25k.

Try it out and send feedback to me.  Let me know if a decision is
made to use it for the next release.

Bob


;;; font-lock.el --- decorating source files with fonts/colors based on syntax

;; Copyright (C) 1992, 1993, 1994, 1995 Free Software Foundation, Inc.
;; Copyright (C) 1995 Amdahl Corporation.
;; Copyright (C) 1996 Ben Wing.

;; Author: Jamie Zawinski <jwz@lucid.com>, for the LISPM Preservation Society.
;; Then (partially) synched with FSF 19.30, leading to:
;; Next Author: RMS
;; Next Author: Simon Marshall <simon@gnu.ai.mit.edu>
;; Latest XEmacs Author: Ben Wing
;; Maintainer: FSF (well, maybe)
;; Keywords: languages, faces

;; This file is part of XEmacs.

;; XEmacs is free software; you can redistribute it and/or modify it
;; under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; XEmacs is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with XEmacs; see the file COPYING.  If not, write to the Free
;; Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.

;;; Synched up with: FSF 19.30 except for the code to initialize the faces.

;;; Commentary:

;; Font-lock-mode is a minor mode that causes your comments to be
;; displayed in one face, strings in another, reserved words in another,
;; documentation strings in another, and so on.
;;
;; Comments will be displayed in `font-lock-comment-face'.
;; Strings will be displayed in `font-lock-string-face'.
;; Doc strings will be displayed in `font-lock-doc-string-face'.
;; Function and variable names (in their defining forms) will be
;;  displayed in `font-lock-function-name-face'.
;; Reserved words will be displayed in `font-lock-keyword-face'.
;;
;; Don't let the name fool you: you can highlight things using different
;; colors or background stipples instead of fonts, though that is not the
;; default.  See the variables `font-lock-use-colors' and
;; `font-lock-use-fonts' for broad control over this, or see the
;; documentation on faces and how to change their attributes for
;; fine-grained control.
;;
;; To make the text you type be fontified, use M-x font-lock-mode.  When
;; this minor mode is on, the fonts of the current line will be updated
;; with every insertion or deletion.
;;
;; By default, font-lock will automatically put newly loaded files
;; into font-lock-mode if it knows about the file's mode.  See the
;; variables `font-lock-auto-fontify', `font-lock-mode-enable-list',
;; and `font-lock-mode-disable-list' for control over this.
;;
;; The `font-lock-keywords' variable defines other patterns to highlight.
;; The default font-lock-mode-hook sets it to the value of the variables
;; lisp-font-lock-keywords, c-font-lock-keywords, etc, as appropriate.
;; The easiest way to change the highlighting patterns is to change the
;; values of c-font-lock-keywords and related variables.  See the doc
;; string of the variable `font-lock-keywords' for the appropriate syntax.
;;
;; The default value for `lisp-font-lock-keywords' is the value of the variable
;; `lisp-font-lock-keywords-1'.  You may like `lisp-font-lock-keywords-2' 
;; better; it highlights many more words, but is slower and makes your buffers
;; be very visually noisy.
;;
;; The same is true of `c-font-lock-keywords-1' and `c-font-lock-keywords-2';
;; the former is subdued, the latter is loud.
;;
;; You can make font-lock default to the gaudier variety of keyword
;; highlighting by setting the variable `font-lock-maximum-decoration'
;; before loading font-lock, or by calling the functions
;; `font-lock-use-default-maximal-decoration' or
;; `font-lock-use-default-minimal-decoration'.
;;
;; On a Sparc10, the initial fontification takes about 6 seconds for a typical
;; 140k file of C code, using the default configuration.  The actual speed
;; depends heavily on the type of code in the file, and how many non-syntactic
;; patterns match; for example, Xlib.h takes 23 seconds for 101k, because many
;; patterns match in it.  You can speed this up substantially by removing some
;; of the patterns that are highlighted by default.  Fontifying lisp code is
;; significantly faster, because lisp has a more regular syntax than C, so the
;; regular expressions don't have to be as complicated.
;;
;; It's called font-lock-mode here because on the Lispms it was called
;; "Electric Font Lock Mode."  It was called that because there was an older
;; mode called "Electric Caps Lock Mode" which had the function of causing all
;; of your source code to be in upper case except for strings and comments,
;; without you having to blip the caps lock key by hand all the time (thus the
;; "electric", as in `electric-c-brace'.)

;; See also the related packages `fast-lock' and `lazy-lock'.  Both
;; attempt to speed up the initial fontification.  `fast-lock' saves
;; the fontification info when you exit Emacs and reloads it next time
;; you load the file, so that the file doesn't have to be fontified
;; again.  `lazy-lock' does "lazy" fontification -- i.e. it only
;; fontifies the text as it becomes visible rather than fontifying
;; the whole file when it's first loaded in.

;; Further comments from the FSF:

;; Nasty regexps of the form "bar\\(\\|lo\\)\\|f\\(oo\\|u\\(\\|bar\\)\\)\\|lo"
;; are made thusly: (make-regexp '("foo" "fu" "fubar" "bar" "barlo" "lo")) for
;; efficiency.  See /pub/gnu/emacs/elisp-archive/functions/make-regexp.el.Z on
;; archive.cis.ohio-state.edu for this and other functions.

;; What is fontification for?  You might say, "It's to make my code look nice."
;; I think it should be for adding information in the form of cues.  These cues
;; should provide you with enough information to both (a) distinguish between
;; different items, and (b) identify the item meanings, without having to read
;; the items and think about it.  Therefore, fontification allows you to think
;; less about, say, the structure of code, and more about, say, why the code
;; doesn't work.  Or maybe it allows you to think less and drift off to sleep.
;;
;; So, here are my opinions/advice/guidelines:
;; 
;; - Use the same face for the same conceptual object, across all modes.
;;   i.e., (b) above, all modes that have items that can be thought of as, say,
;;   keywords, should be highlighted with the same face, etc.
;; - Keep the faces distinct from each other as far as possible.
;;   i.e., (a) above.
;; - Make the face attributes fit the concept as far as possible.
;;   i.e., function names might be a bold colour such as blue, comments might
;;   be a bright colour such as red, character strings might be brown, because,
;;   err, strings are brown (that was not the reason, please believe me).
;; - Don't use a non-nil OVERRIDE unless you have a good reason.
;;   Only use OVERRIDE for special things that are easy to define, such as the
;;   way `...' quotes are treated in strings and comments in Emacs Lisp mode.
;;   Don't use it to, say, highlight keywords in commented out code or strings.
;; - Err, that's it.


;;; Code:

(require 'fontl-hooks)

;;;;;;;;;;;;;;;;;;;;;;      user variables       ;;;;;;;;;;;;;;;;;;;;;;

(defvar font-lock-verbose t
  "*If non-nil, means show status messages when fontifying.
See also `font-lock-message-threshold'.")

(defvar font-lock-message-threshold 6000
  "*Minimum size of region being fontified for status messages to appear.

The size is measured in characters.  This affects `font-lock-fontify-region'
but not `font-lock-fontify-buffer'. (In other words, when you first visit
a file and it gets fontified, you will see status messages no matter what
size the file is.  However, if you do something else like paste a
chunk of text or revert a buffer, you will see status messages only if the
changed region is large enough.)

Note that setting `font-lock-verbose' to nil disables the status
messages entirely.")

;;;###autoload
(defvar font-lock-auto-fontify t
  "*Whether font-lock should automatically fontify files as they're loaded.
This will only happen if font-lock has fontifying keywords for the major
mode of the file.  You can get finer-grained control over auto-fontification
by using this variable in combination with `font-lock-mode-enable-list' or
`font-lock-mode-disable-list'.")

;;;###autoload
(defvar font-lock-mode-enable-list nil
  "*List of modes to auto-fontify, if `font-lock-auto-fontify' is nil.")

;;;###autoload
(defvar font-lock-mode-disable-list nil
  "*List of modes not to auto-fontify, if `font-lock-auto-fontify' is t.")

;;;###autoload
(defvar font-lock-use-colors '(color)
  "*Specification for when Font Lock will set up color defaults.
Normally this should be '(color), meaning that Font Lock will set up
color defaults that are only used on color displays.  Set this to nil
if you don't want Font Lock to set up color defaults at all.  This
should be one of

-- a list of valid tags, meaning that the color defaults will be used
   when all of the tags apply. (e.g. '(color x))
-- a list whose first element is 'or and whose remaining elements are
   lists of valid tags, meaning that the defaults will be used when
   any of the tag lists apply.
-- nil, meaning that the defaults should not be set up at all.

\(If you specify face values in your init file, they will override any
that Font Lock specifies, regardless of whether you specify the face
values before or after loading Font Lock.)

See also `font-lock-use-fonts'.  If you want more control over the faces
used for fontification, see the documentation of `font-lock-mode' for
how to do it.")

;;;###autoload
(defvar font-lock-use-fonts '(or (mono) (grayscale))
  "*Specification for when Font Lock will set up non-color defaults.

Normally this should be '(or (mono) (grayscale)), meaning that Font
Lock will set up non-color defaults that are only used on either mono
or grayscale displays.  Set this to nil if you don't want Font Lock to
set up non-color defaults at all.  This should be one of

-- a list of valid tags, meaning that the non-color defaults will be used
   when all of the tags apply. (e.g. '(grayscale x))
-- a list whose first element is 'or and whose remaining elements are
   lists of valid tags, meaning that the defaults will be used when
   any of the tag lists apply.
-- nil, meaning that the defaults should not be set up at all.

\(If you specify face values in your init file, they will override any
that Font Lock specifies, regardless of whether you specify the face
values before or after loading Font Lock.)

See also `font-lock-use-colors'.  If you want more control over the faces
used for fontification, see the documentation of `font-lock-mode' for
how to do it.")

;;;###autoload
(defvar font-lock-maximum-decoration nil
  "*If non-nil, the maximum decoration level for fontifying.
If nil, use the minimum decoration (equivalent to level 0).
If t, use the maximum decoration available.
If a number, use that level of decoration (or if not available the maximum).
If a list, each element should be a cons pair of the form (MAJOR-MODE . LEVEL),
where MAJOR-MODE is a symbol or t (meaning the default).  For example:
 ((c++-mode . 2) (c-mode . t) (t . 1))
means use level 2 decoration for buffers in `c++-mode', the maximum decoration
available for buffers in `c-mode', and level 1 decoration otherwise.")

;;;###autoload
(defvar font-lock-maximum-size (* 250 1024)
  "*If non-nil, the maximum size for buffers for fontifying.
Only buffers less than this can be fontified when Font Lock mode is turned on.
If nil, means size is irrelevant.
If a list, each element should be a cons pair of the form (MAJOR-MODE . SIZE),
where MAJOR-MODE is a symbol or t (meaning the default).  For example:
 ((c++-mode . 256000) (c-mode . 256000) (rmail-mode . 1048576))
means that the maximum size is 250K for buffers in `c++-mode' or `c-mode', one
megabyte for buffers in `rmail-mode', and size is irrelevant otherwise.")

;; Fontification variables:

;;;###autoload
(defvar font-lock-keywords nil
  "*A list of the keywords to highlight.
Each element should be of the form:

 MATCHER
 (MATCHER . MATCH)
 (MATCHER . FACENAME)
 (MATCHER . HIGHLIGHT)
 (MATCHER HIGHLIGHT ...)

where HIGHLIGHT should be either MATCH-HIGHLIGHT or MATCH-ANCHORED.

For highlighting single items, typically only MATCH-HIGHLIGHT is required.
However, if an item or (typically) items is to be hightlighted following the
instance of another item (the anchor) then MATCH-ANCHORED may be required.

MATCH-HIGHLIGHT should be of the form:

 (MATCH FACENAME OVERRIDE LAXMATCH)

Where MATCHER can be either the regexp to search for, or the function name to
call to make the search (called with one argument, the limit of the search).
MATCH is the subexpression of MATCHER to be highlighted.  FACENAME is either
a symbol naming a face, or an expression whose value is the face name to use.
If you want FACENAME to be a symbol that evaluates to a face, use a form
like \"(progn sym)\".

OVERRIDE and LAXMATCH are flags.  If OVERRIDE is t, existing fontification may
be overwritten.  If `keep', only parts not already fontified are highlighted.
If `prepend' or `append', existing fontification is merged with the new, in
which the new or existing fontification, respectively, takes precedence.
If LAXMATCH is non-nil, no error is signalled if there is no MATCH in MATCHER.

For example, an element of the form highlights (if not already highlighted):

 \"\\\\\\=<foo\\\\\\=>\"		Discrete occurrences of \"foo\" in the value of the
			variable `font-lock-keyword-face'.
 (\"fu\\\\(bar\\\\)\" . 1)	Substring \"bar\" within all occurrences of \"fubar\" in
			the value of `font-lock-keyword-face'.
 (\"fubar\" . fubar-face)	Occurrences of \"fubar\" in the value of `fubar-face'.
 (\"foo\\\\|bar\" 0 foo-bar-face t)
			Occurrences of either \"foo\" or \"bar\" in the value
			of `foo-bar-face', even if already highlighted.

MATCH-ANCHORED should be of the form:

 (MATCHER PRE-MATCH-FORM POST-MATCH-FORM MATCH-HIGHLIGHT ...)

Where MATCHER is as for MATCH-HIGHLIGHT with one exception.  The limit of the
search is currently guaranteed to be (no greater than) the end of the line.
PRE-MATCH-FORM and POST-MATCH-FORM are evaluated before the first, and after
the last, instance MATCH-ANCHORED's MATCHER is used.  Therefore they can be
used to initialise before, and cleanup after, MATCHER is used.  Typically,
PRE-MATCH-FORM is used to move to some position relative to the original
MATCHER, before starting with MATCH-ANCHORED's MATCHER.  POST-MATCH-FORM might
be used to move, before resuming with MATCH-ANCHORED's parent's MATCHER.

For example, an element of the form highlights (if not already highlighted):

 (\"\\\\\\=<anchor\\\\\\=>\" (0 anchor-face) (\"\\\\\\=<item\\\\\\=>\" nil nil (0 item-face)))

 Discrete occurrences of \"anchor\" in the value of `anchor-face', and subsequent
 discrete occurrences of \"item\" (on the same line) in the value of `item-face'.
 (Here PRE-MATCH-FORM and POST-MATCH-FORM are nil.  Therefore \"item\" is
 initially searched for starting from the end of the match of \"anchor\", and
 searching for subsequent instance of \"anchor\" resumes from where searching
 for \"item\" concluded.)

Note that the MATCH-ANCHORED feature is experimental; in the future, we may
replace it with other ways of providing this functionality.

These regular expressions should not match text which spans lines.  While
\\[font-lock-fontify-buffer] handles multi-line patterns correctly, updating
when you edit the buffer does not, since it considers text one line at a time.

Be very careful composing regexps for this list;
the wrong pattern can dramatically slow things down!")
;;;###autoload
(make-variable-buffer-local 'font-lock-keywords)

(defvar font-lock-defaults nil
  "The defaults font Font Lock mode for the current buffer.
Normally, do not set this directly.  If you are writing a major mode,
put a property of `font-lock-defaults' on the major-mode symbol with
the desired value.

It should be a list

\(KEYWORDS KEYWORDS-ONLY CASE-FOLD SYNTAX-ALIST SYNTAX-BEGIN)

KEYWORDS may be a symbol (a variable or function whose value is the keywords
to use for fontification) or a list of symbols.  If KEYWORDS-ONLY is non-nil,
syntactic fontification (strings and comments) is not performed.  If CASE-FOLD
is non-nil, the case of the keywords is ignored when fontifying.  If
SYNTAX-ALIST is non-nil, it should be a list of cons pairs of the form (CHAR
. STRING) used to set the local Font Lock syntax table, for keyword and
syntactic fontification (see `modify-syntax-entry').

If SYNTAX-BEGIN is non-nil, it should be a function with no args used to move
backwards outside any enclosing syntactic block, for syntactic fontification.
Typical values are `beginning-of-line' (i.e., the start of the line is known to
be outside a syntactic block), or `beginning-of-defun' for programming modes or
`backward-paragraph' for textual modes (i.e., the mode-dependent function is
known to move outside a syntactic block).  If nil, the beginning of the buffer
is used as a position outside of a syntactic block, in the worst case.

These item elements are used by Font Lock mode to set the variables
`font-lock-keywords', `font-lock-keywords-only',
`font-lock-keywords-case-fold-search', `font-lock-syntax-table' and
`font-lock-beginning-of-syntax-function', respectively.

Alternatively, if the value is a symbol, it should name a major mode,
and the defaults for that mode will apply.")
(make-variable-buffer-local 'font-lock-defaults)

;; FSF uses `font-lock-defaults-alist' and expects the major mode to
;; set a value for `font-lock-defaults', but I don't like either of
;; these -- requiring the mode to set `font-lock-defaults' makes it
;; impossible to have defaults for a minor mode, and using an alist is
;; generally a bad idea for information that really should be
;; decentralized. (Who knows what strange modes might want
;; font-locking?)

(defvar font-lock-keywords-only nil
  "Non-nil means Font Lock should not do syntactic fontification.
This is normally set via `font-lock-defaults'.

This should be nil for all ``language'' modes, but other modes, like
dired, do not have anything useful in the syntax tables (no comment
or string delimiters, etc) and so there is no need to use them and
this variable should have a value of t.

You should not set this variable directly; its value is computed
from `font-lock-defaults', or (if that does not specify anything)
by examining the syntax table to see whether it appears to contain
anything useful.")
(make-variable-buffer-local 'font-lock-keywords-only)

(defvar font-lock-keywords-case-fold-search nil
  "Whether the strings in `font-lock-keywords' should be case-folded.
This variable is automatically buffer-local, as the correct value depends
on the language in use.")
(make-variable-buffer-local 'font-lock-keywords-case-fold-search)

(defvar font-lock-after-fontify-buffer-hook nil
  "Function or functions to run after completion of font-lock-fontify-buffer.")

(defvar font-lock-syntax-table nil
  "Non-nil means use this syntax table for fontifying.
If this is nil, the major mode's syntax table is used.
This is normally set via `font-lock-defaults'.")
(make-variable-buffer-local 'font-lock-syntax-table)

;; These are used in the FSF version in syntactic font-locking.
;; We do this all in C.
;;; These record the parse state at a particular position, always the
;;; start of a line.  Used to make
;;; `font-lock-fontify-syntactically-region' faster.
;(defvar font-lock-cache-position nil)
;(defvar font-lock-cache-state nil)
;(make-variable-buffer-local 'font-lock-cache-position)
;(make-variable-buffer-local 'font-lock-cache-state)

;; If this is nil, we only use the beginning of the buffer if we can't use
;; `font-lock-cache-position' and `font-lock-cache-state'.
(defvar font-lock-beginning-of-syntax-function nil
  "Non-nil means use this function to move back outside of a syntactic block.
If this is nil, the beginning of the buffer is used (in the worst case).
This is normally set via `font-lock-defaults'.")
(make-variable-buffer-local 'font-lock-beginning-of-syntax-function)

;;;###autoload
(defvar font-lock-mode nil) ; for modeline
(defvar font-lock-fontified nil) ; whether we have hacked this buffer
(put 'font-lock-fontified 'permanent-local t)

;;;###autoload
(defvar font-lock-mode-hook nil
  "Function or functions to run on entry to font-lock-mode.")

; whether font-lock-set-defaults has already been run.
(defvar font-lock-defaults-computed nil)
(make-variable-buffer-local 'font-lock-defaults-computed)

;; #### barf gag retch.  Horrid FSF lossage that we need to
;; keep around for compatibility with font-lock-keywords that
;; forget to properly quote their faces.
(defvar font-lock-comment-face 'font-lock-comment-face
  "Don't even think of using this.")
(defvar font-lock-doc-string-face 'font-lock-doc-string-face
  "Don't even think of using this.")
(defvar font-lock-string-face 'font-lock-string-face
  "Don't even think of using this.")
(defvar font-lock-keyword-face 'font-lock-keyword-face
  "Don't even think of using this.")
(defvar font-lock-function-name-face 'font-lock-function-name-face
  "Don't even think of using this.")
(defvar font-lock-variable-name-face 'font-lock-variable-name-face
  "Don't even think of using this.")
(defvar font-lock-type-face 'font-lock-type-face
  "Don't even think of using this.")
(defvar font-lock-reference-face 'font-lock-reference-face
  "Don't even think of using this.")
(defvar font-lock-preprocessor-face 'font-lock-preprocessor-face
  "Don't even think of using this.")


;;;;;;;;;;;;;;;;;;;;;;        actual code        ;;;;;;;;;;;;;;;;;;;;;;

;;; To fontify the whole buffer by language syntax, we go through it a
;;; character at a time, creating extents on the boundary of each syntactic
;;; unit (that is, one extent for each block comment, one for each line
;;; comment, one for each string, etc.)  This is done with the C function
;;; syntactically-sectionize.  It's in C for speed (the speed of lisp function
;;; calls was a real bottleneck for this task since it involves examining each
;;; character in turn.)
;;;
;;; Then we make a second pass, to fontify the buffer based on other patterns
;;; specified by regexp.  When we find a match for a region of text, we need
;;; to change the fonts on those characters.  This is done with the
;;; put-text-property function, which knows how to efficiently share extents.
;;; Conceptually, we are attaching some particular face to each of the
;;; characters in a range, but the implementation of this involves creating
;;; extents, or resizing existing ones.
;;;
;;; Each time a modification happens to a line, we re-fontify the entire line.
;;; We do this by first removing the extents (text properties) on the line,
;;; and then doing the syntactic and keyword passes again on that line.  (More
;;; generally, each modified region is extended to include the preceeding and
;;; following BOL or EOL.)
;;;
;;; This means that, as the user types, we repeatedly go back to the beginning
;;; of the line, doing more work the longer the line gets.  This doesn't cost
;;; much in practice, and if we don't, then we incorrectly fontify things when,
;;; for example, inserting spaces into `intfoo () {}'.
;;;


;; The user level functions

;;;###autoload
(defun font-lock-mode (&optional arg)
  "Toggle Font Lock Mode.
With arg, turn font-lock mode on if and only if arg is positive.

When Font Lock mode is enabled, text is fontified as you type it:

 - Comments are displayed in `font-lock-comment-face';
 - Strings are displayed in `font-lock-string-face';
 - Documentation strings (in Lisp-like languages) are displayed in
   `font-lock-doc-string-face';
 - Language keywords (\"reserved words\") are displayed in
   `font-lock-keyword-face';
 - Function names in their defining form are displayed in
   `font-lock-function-name-face';
 - Variable names in their defining form are displayed in
   `font-lock-variable-name-face';
 - Type names are displayed in `font-lock-type-face';
 - References appearing in help files and the like are displayed
   in `font-lock-reference-face';
 - Preprocessor declarations are displayed in
  `font-lock-preprocessor-face';

   and

 - Certain other expressions are displayed in other faces according
   to the value of the variable `font-lock-keywords'.

Where modes support different levels of fontification, you can use the variable
`font-lock-maximum-decoration' to specify which level you generally prefer.
When you turn Font Lock mode on/off the buffer is fontified/defontified, though
fontification occurs only if the buffer is less than `font-lock-maximum-size'.
To fontify a buffer without turning on Font Lock mode, and regardless of buffer
size, you can use \\[font-lock-fontify-buffer].

See the variable `font-lock-keywords' for customization."
  (interactive "P")
  (let ((on-p (if arg (> (prefix-numeric-value arg) 0) (not font-lock-mode)))
	(maximum-size (if (not (consp font-lock-maximum-size))
			  font-lock-maximum-size
			(cdr (or (assq major-mode font-lock-maximum-size)
				 (assq t font-lock-maximum-size))))))
    ;; Font-lock mode will refuse to turn itself on if in batch mode, or if
    ;; the current buffer is "invisible".  The latter is because packages
    ;; sometimes put their temporary buffers into some particular major mode
    ;; to get syntax tables and variables and whatnot, but we don't want the
    ;; fact that the user has font-lock-mode on a mode hook to slow these
    ;; things down.
    (if (or noninteractive (eq (aref (buffer-name) 0) ?\ ))
	(setq on-p nil))
    (if (equal (buffer-name) " *Compiler Input*") ; hack for bytecomp...
	(setq on-p nil))
    (cond (on-p
	   (make-local-hook 'after-change-functions)
	   (add-hook 'after-change-functions
		     'font-lock-after-change-function nil t)
	   (add-hook 'pre-idle-hook 'font-lock-pre-idle-hook))
	  (t
	   (remove-hook 'after-change-functions
			'font-lock-after-change-function t)
	   (remove-hook 'pre-idle-hook 'font-lock-pre-idle-hook)
	   ))
    (set (make-local-variable 'font-lock-mode) on-p)
    (cond (on-p
	   (font-lock-set-defaults-1)
	   (make-local-hook 'before-revert-hook)
	   (make-local-hook 'after-revert-hook)
	   ;; If buffer is reverted, must clean up the state.
	   (add-hook 'before-revert-hook 'font-lock-revert-setup nil t)
	   (add-hook 'after-revert-hook 'font-lock-revert-cleanup nil t)
	   (run-hooks 'font-lock-mode-hook)
	   (cond (font-lock-fontified
		  nil)
		 ((or (null maximum-size) (<= (buffer-size) maximum-size))
		  (font-lock-fontify-buffer))
		 (font-lock-verbose
		  (message "Fontifying %s... buffer too big." (buffer-name)))))
	  (font-lock-fontified
	   (setq font-lock-fontified nil)
	   (remove-hook 'before-revert-hook 'font-lock-revert-setup t)
	   (remove-hook 'after-revert-hook 'font-lock-revert-cleanup t)
	   (font-lock-unfontify-region (point-min) (point-max))
	   (font-lock-thing-lock-cleanup))
	  (t
	   (remove-hook 'before-revert-hook 'font-lock-revert-setup t)
	   (remove-hook 'after-revert-hook 'font-lock-revert-cleanup t)
	   (font-lock-thing-lock-cleanup)))
    (redraw-modeline)))

;; For init-file hooks
;;;###autoload
(defun turn-on-font-lock ()
  "Unconditionally turn on Font Lock mode."
  (font-lock-mode 1))

;;;###autoload
(defun turn-off-font-lock ()
  "Unconditionally turn off Font Lock mode."
  (font-lock-mode 0))

;;;###autoload
(defun font-lock-fontify-buffer ()
  "Fontify the current buffer the way `font-lock-mode' would.
See `font-lock-mode' for details.

This can take a while for large buffers."
  (interactive)
  (let ((was-on font-lock-mode)
	(font-lock-verbose (or font-lock-verbose (interactive-p)))
	(font-lock-message-threshold 0)
	(aborted nil))
    ;; Turn it on to run hooks and get the right font-lock-keywords.
    (or was-on (font-lock-mode 1))
    (font-lock-unfontify-region (point-min) (point-max) t)
;;    (buffer-syntactic-context-flush-cache)
    
    ;; If a ^G is typed during fontification, abort the fontification, but
    ;; return normally (do not signal.)  This is to make it easy to abort
    ;; fontification if it's taking a long time, without also causing the
    ;; buffer not to pop up.  If a real abort is desired, the user can ^G
    ;; again.
    ;;
    ;; Possibly this should happen down in font-lock-fontify-region instead
    ;; of here, but since that happens from the after-change-hook (meaning
    ;; much more frequently) I'm afraid of the bad consequences of stealing
    ;; the interrupt character at inopportune times.
    ;;
    (condition-case nil
	(save-excursion
	  (font-lock-fontify-region (point-min) (point-max)))
      (quit
       (setq aborted t)))

    (or was-on		; turn it off if it was off.
	(let ((font-lock-fontified nil)) ; kludge to prevent defontification
	  (font-lock-mode 0)))
    (set (make-local-variable 'font-lock-fontified) t)
    (if (and aborted font-lock-verbose)
	(message "Fontifying %s... aborted." (buffer-name)))
    )
  (run-hooks 'font-lock-after-fontify-buffer-hook))

;; Fontification functions.

;; We first define some defsubsts to encapsulate the way we add
;; faces to a region of text.  I am planning on modifying the
;; text-property mechanism so that multiple independent classes
;; of text properties can exist.  That way, for example, ediff's
;; face text properties don't interfere with font lock's face
;; text properties.  Due to the XEmacs implementation of text
;; properties in terms of extents, doing this is fairly trivial:
;; instead of using the `text-prop' property, you just use a
;; specified property.

(defsubst font-lock-set-face (start end face)
  ;; Set the face on the characters in the range.
  (put-nonduplicable-text-property start end 'face face)
  (put-nonduplicable-text-property start end 'font-lock t))

(defsubst font-lock-remove-face (start end)
  ;; Remove any syntax highlighting on the characters in the range.
  (put-nonduplicable-text-property start end 'face nil)
  (put-nonduplicable-text-property start end 'font-lock nil))

(defsubst font-lock-any-faces-p (start end)
  ;; Return non-nil if we've put any syntax highlighting on
  ;; the characters in the range.
  ;;
  ;; used to look for 'text-prop property, but this has problems if
  ;; you put any other text properties in the vicinity.  Simon
  ;; Marshall suggested looking for the 'face property (this is what
  ;; FSF Emacs does) but that's equally bogus.  Only reliable way is
  ;; for font-lock to specially mark its extents.
  ;;
  ;; FSF's (equivalent) definition of this defsubst would be
  ;; (text-property-not-all start end 'font-lock nil)
  ;;
  ;; Perhaps our `map-extents' is faster than our definition
  ;; of `text-property-not-all'.  #### If so, `text-property-not-all'
  ;; should be fixed ...
  ;;
  (map-extents 'extent-property (current-buffer) start (1- end) 'font-lock))


;; Fontification functions.

;; We use this wrapper.  However, `font-lock-fontify-region' used to be the
;; name used for `font-lock-fontify-syntactically-region', so a change isn't
;; back-compatible.  But you shouldn't be calling these directly, should you?
(defun font-lock-fontify-region (beg end &optional loudly)
  (let ((modified (buffer-modified-p))
	(buffer-undo-list t) (inhibit-read-only t)
	(old-syntax-table (syntax-table))
	buffer-file-name buffer-file-truename)
    (unwind-protect
	(progn
	  ;; Use the fontification syntax table, if any.
	  (if font-lock-syntax-table (set-syntax-table font-lock-syntax-table))
	  ;; Now do the fontification.
	  (if font-lock-keywords-only
	      (font-lock-unfontify-region beg end)
	    (font-lock-fontify-syntactically-region beg end loudly))
	  (font-lock-fontify-keywords-region beg end loudly))
      ;; Clean up.
      (set-syntax-table old-syntax-table)
      (and (not modified) (buffer-modified-p) (set-buffer-modified-p nil)))))

;; The following must be rethought, since keywords can override fontification.
;      ;; Now scan for keywords, but not if we are inside a comment now.
;      (or (and (not font-lock-keywords-only)
;	       (let ((state (parse-partial-sexp beg end nil nil 
;						font-lock-cache-state)))
;		 (or (nth 4 state) (nth 7 state))))
;	  (font-lock-fontify-keywords-region beg end))

(defun font-lock-unfontify-region (beg end &optional maybe-loudly)
  (if (and maybe-loudly font-lock-verbose
	   (>= (- end beg) font-lock-message-threshold))
      (message "Fontifying %s..." (buffer-name)))
  (let ((modified (buffer-modified-p))
	(buffer-undo-list t) (inhibit-read-only t)
	buffer-file-name buffer-file-truename)
    (font-lock-remove-face beg end)
    (and (not modified) (buffer-modified-p) (set-buffer-modified-p nil))))

;; Following is the original FSF version (similar to our original
;; version, before all the crap I added below).
;;
;; Probably that crap should either be fixed up so it works better,
;; or tossed away.
;;
;; I think that lazy-lock v2 tries to do something similar.
;; Those efforts should be merged.

;; Called when any modification is made to buffer text.
;(defun font-lock-after-change-function (beg end old-len)
;  (save-excursion
;    (save-match-data
;      ;; Rescan between start of line from `beg' and start of line after `end'.
;      (font-lock-fontify-region
;	(progn (goto-char beg) (beginning-of-line) (point))
;	(progn (goto-char end) (forward-line 1) (point))))))

(defvar font-lock-old-extent nil)
(defvar font-lock-old-len 0)

(defun font-lock-fontify-glumped-region ()
  ;; even if something goes wrong in the fontification, mark the glumped
  ;; region as fontified; otherwise, the same error might get signaled
  ;; after every command.
  (unwind-protect
      ;; buffer may be deleted.
      (if (buffer-live-p (extent-buffer font-lock-old-extent))
	  (save-excursion
	    (set-buffer (extent-buffer font-lock-old-extent))
	    (font-lock-after-change-function-1
	     (extent-start-position font-lock-old-extent)
	     (extent-end-position font-lock-old-extent)
	     font-lock-old-len)))
    (detach-extent font-lock-old-extent)
    (setq font-lock-old-extent nil)))

(defun font-lock-pre-idle-hook ()
  (if font-lock-old-extent
      (font-lock-fontify-glumped-region)))

(defvar font-lock-always-fontify-immediately nil
  "Set this to non-nil to disable font-lock deferral.")

;;; called when any modification is made to buffer text.  This function
;;; attempts to glump adjacent changes together so that excessive
;;; fontification is avoided.  This function could easily be adapted
;;; to other after-change-functions.

(defun font-lock-after-change-function (beg end old-len)
  (let ((obeg (and font-lock-old-extent
		   (extent-start-position font-lock-old-extent)))
	(oend (and font-lock-old-extent
		   (extent-end-position font-lock-old-extent)))
	(bc-end (+ beg old-len)))

    ;; If this change can't be merged into the glumped one,
    ;; we need to fontify the glumped one right now.
    (if (and font-lock-old-extent
	     (or (not (eq (current-buffer)
			  (extent-buffer font-lock-old-extent)))
		 (< bc-end obeg)
		 (> beg oend)))
	(font-lock-fontify-glumped-region))
  
    (if font-lock-old-extent
	;; Update glumped region.
	(progn
	  ;; Any characters in the before-change region that are
	  ;; outside the glumped region go into the glumped
	  ;; before-change region.
	  (if (> bc-end oend)
	      (setq font-lock-old-len (+ font-lock-old-len (- bc-end oend))))
	  (if (> obeg beg)
	      (setq font-lock-old-len (+ font-lock-old-len (- obeg beg))))
	  ;; New glumped region is the union of the glumped region
	  ;; and the new region.
	  (set-extent-endpoints font-lock-old-extent
				(min obeg beg)
				(max oend end)))

      ;; No glumped region, so create one.
      (setq font-lock-old-extent (make-extent beg end))
      (set-extent-property font-lock-old-extent 'detachable nil)
      (set-extent-property font-lock-old-extent 'end-open nil)
      (setq font-lock-old-len old-len))

    (if font-lock-always-fontify-immediately
	(font-lock-fontify-glumped-region))))

(defun font-lock-after-change-function-1 (beg end old-len)
  (if (null font-lock-mode)
      nil
    (save-excursion
      (save-restriction
	;; if we don't widen, then fill-paragraph (and any command that
	;; operates on a narrowed region) confuses things, because the C
	;; code will fail to realize that we're inside a comment.
	(widen)
	(save-match-data
	  (let ((zmacs-region-stays zmacs-region-stays)) ; protect from change!
	    (goto-char beg)
	    ;; Maybe flush the internal cache used by syntactically-sectionize.
	    ;; (It'd be nice if this was more automatic.)  Any deletions mean
	    ;; the cache is invalid, and insertions at beginning or end of line
	    ;; mean that the bol cache might be invalid.
;;	    (if (or (> old-len 0) (bobp) (= (preceding-char) ?\n))
;;		(buffer-syntactic-context-flush-cache))

	    ;; Always recompute the whole line.
	    (goto-char end)
	    (forward-line 1)
	    (setq end (point))
	    (goto-char beg)
	    (beginning-of-line)
	    (setq beg (point))
	    ;; Rescan between start of line from `beg' and start of line after
	    ;; `end'.
	    (font-lock-fontify-region beg end)))))))


;; Syntactic fontification functions.

;; Note: Here is the FSF version.  Our version is much faster because
;; of the C support we provide.  This may be useful for reference,
;; however, and perhaps there is something useful here that should
;; be merged into our version.
;;
;(defun font-lock-fontify-syntactically-region (start end &optional loudly)
;  "Put proper face on each string and comment between START and END.
;START should be at the beginning of a line."
;  (let ((synstart (if comment-start-skip
;		       (concat "\\s\"\\|" comment-start-skip)
;		     "\\s\""))
;	 (comstart (if comment-start-skip
;		       (concat "\\s<\\|" comment-start-skip)
;		     "\\s<"))
;	 state prev prevstate)
;    (if loudly (message "Fontifying %s... (syntactically...)" (buffer-name)))
;    (save-restriction
;      (widen)
;      (goto-char start)
;      ;;
;      ;; Find the state at the `beginning-of-line' before `start'.
;      (if (eq start font-lock-cache-position)
;	   ;; Use the cache for the state of `start'.
;	   (setq state font-lock-cache-state)
;	 ;; Find the state of `start'.
;	 (if (null font-lock-beginning-of-syntax-function)
;	     ;; Use the state at the previous cache position, if any, or
;	     ;; otherwise calculate from `point-min'.
;	     (if (or (null font-lock-cache-position)
;		     (< start font-lock-cache-position))
;		 (setq state (parse-partial-sexp (point-min) start))
;	       (setq state (parse-partial-sexp font-lock-cache-position start
;					       nil nil font-lock-cache-state)))
;	   ;; Call the function to move outside any syntactic block.
;	   (funcall font-lock-beginning-of-syntax-function)
;	   (setq state (parse-partial-sexp (point) start)))
;	 ;; Cache the state and position of `start'.
;	 (setq font-lock-cache-state state
;	       font-lock-cache-position start))
;      ;;
;      ;; If the region starts inside a string, show the extent of it.
;      (if (nth 3 state)
;	   (let ((beg (point)))
;	     (while (and (re-search-forward "\\s\"" end 'move)
;			 (nth 3 (parse-partial-sexp beg (point)
;						    nil nil state))))
;	     (put-text-property beg (point) 'face font-lock-string-face)
;	     (setq state (parse-partial-sexp beg (point) nil nil state))))
;      ;;
;      ;; Likewise for a comment.
;      (if (or (nth 4 state) (nth 7 state))
;	   (let ((beg (point)))
;	     (save-restriction
;	       (narrow-to-region (point-min) end)
;	       (condition-case nil
;		   (progn
;		     (re-search-backward comstart (point-min) 'move)
;		     (forward-comment 1)
;		     ;; forward-comment skips all whitespace,
;		     ;; so go back to the real end of the comment.
;		     (skip-chars-backward " \t"))
;		 (error (goto-char end))))
;	     (put-text-property beg (point) 'face font-lock-comment-face)
;	     (setq state (parse-partial-sexp beg (point) nil nil state))))
;      ;;
;      ;; Find each interesting place between here and `end'.
;      (while (and (< (point) end)
;		   (setq prev (point) prevstate state)
;		   (re-search-forward synstart end t)
;		   (progn
;		     ;; Clear out the fonts of what we skip over.
;		     (remove-text-properties prev (point) '(face nil))
;		     ;; Verify the state at that place
;		     ;; so we don't get fooled by \" or \;.
;		     (setq state (parse-partial-sexp prev (point)
;						     nil nil state))))
;	 (let ((here (point)))
;	   (if (or (nth 4 state) (nth 7 state))
;	       ;;
;	       ;; We found a real comment start.
;	       (let ((beg (match-beginning 0)))
;		 (goto-char beg)
;		 (save-restriction
;		   (narrow-to-region (point-min) end)
;		   (condition-case nil
;		       (progn
;			 (forward-comment 1)
;			 ;; forward-comment skips all whitespace,
;			 ;; so go back to the real end of the comment.
;			 (skip-chars-backward " \t"))
;		     (error (goto-char end))))
;		 (put-text-property beg (point) 'face
;				    font-lock-comment-face)
;		 (setq state (parse-partial-sexp here (point) nil nil state)))
;	     (if (nth 3 state)
;		 ;;
;		 ;; We found a real string start.
;		 (let ((beg (match-beginning 0)))
;		   (while (and (re-search-forward "\\s\"" end 'move)
;			       (nth 3 (parse-partial-sexp here (point)
;							  nil nil state))))
;		   (put-text-property beg (point) 'face font-lock-string-face)
;		   (setq state (parse-partial-sexp here (point)
;						   nil nil state))))))
;	 ;;
;	 ;; Make sure `prev' is non-nil after the loop
;	 ;; only if it was set on the very last iteration.
;	 (setq prev nil)))
;    ;;
;    ;; Clean up.
;    (and prev (remove-text-properties prev end '(face nil)))))

(defun font-lock-fontify-syntactically-region (start end &optional loudly)
  "Put proper face on each string and comment between START and END.
START should be at the beginning of a line."
  (if font-lock-keywords-only
      nil
    (if (and font-lock-verbose
	     (>= (- end start) font-lock-message-threshold))
	(message "Fontifying %s... (syntactically...)" (buffer-name)))
    (font-lock-unfontify-region start end loudly)
    (goto-char start)
    (if (> end (point-max)) (setq end (point-max)))
    (syntactically-sectionize
      #'(lambda (s e context depth)
	  (let (face)
	    (cond ((eq context 'string)
		   ;;#### Should only do this is Lisp-like modes!
		   (setq face
			 (if (= depth 1)
			     ;; really we should only use this if
			     ;;  in position 3 depth 1, but that's
			     ;;  too expensive to compute.
			     'font-lock-doc-string-face
			   'font-lock-string-face)))
		  ((or (eq context 'comment)
		       (eq context 'block-comment))
		   (setq face 'font-lock-comment-face)
;		 ;; Don't fontify whitespace at the beginning of lines;
;		 ;;  otherwise comment blocks may not line up with code.
;		 ;; (This is sometimes a good idea, sometimes not; in any
;		 ;; event it should be in C for speed --jwz)
;		 (save-excursion
;		     (goto-char s)
;		     (while (prog1 (search-forward "\n" (1- e) 'move)
;			      (setq face 'font-lock-comment-face)
;			      (setq e (point)))
;		       (skip-chars-forward " \t\n")
;		       (setq s (point)))
		   ))
	    (font-lock-set-face s e face)))
      start end)
    ))

;;; Additional text property functions.

;; The following three text property functions are not generally available (and
;; it's not certain that they should be) so they are inlined for speed.
;; The case for `fillin-text-property' is simple; it may or not be generally
;; useful.  (Since it is used here, it is useful in at least one place.;-)
;; However, the case for `append-text-property' and `prepend-text-property' is
;; more complicated.  Should they remove duplicate property values or not?  If
;; so, should the first or last duplicate item remain?  Or the one that was
;; added?  In our implementation, the first duplicate remains.

;; XEmacs: modified all these functions to use
;; `put-nonduplicable-text-property' instead of `put-text-property', and
;; the first one to take both SETPROP and MARKPROP, in accordance with the
;; changed definitions of `font-lock-any-faces-p' and `font-lock-set-face'.

(defsubst font-lock-fillin-text-property (start end setprop markprop value &optional object)
  "Fill in one property of the text from START to END.
Arguments PROP and VALUE specify the property and value to put where none are
already in place.  Therefore existing property values are not overwritten.
Optional argument OBJECT is the string or buffer containing the text."
  (let ((start (text-property-any start end markprop nil object)) next)
    (while start
      (setq next (next-single-property-change start markprop object end))
      (put-nonduplicable-text-property start next setprop value object)
      (put-nonduplicable-text-property start next markprop value object)
      (setq start (text-property-any next end markprop nil object)))))

;; This function (from simon's unique.el) is rewritten and inlined for speed.
;(defun unique (list function)
;  "Uniquify LIST, deleting elements using FUNCTION.
;Return the list with subsequent duplicate items removed by side effects.
;FUNCTION is called with an element of LIST and a list of elements from LIST,
;and should return the list of elements with occurrences of the element removed,
;i.e., a function such as `delete' or `delq'.
;This function will work even if LIST is unsorted.  See also `uniq'."
;  (let ((list list))
;    (while list
;      (setq list (setcdr list (funcall function (car list) (cdr list))))))
;  list)

(defsubst font-lock-unique (list)
  "Uniquify LIST, deleting elements using `delq'.
Return the list with subsequent duplicate items removed by side effects."
  (let ((list list))
    (while list
      (setq list (setcdr list (delq (car list) (cdr list))))))
  list)

;; A generalisation of `facemenu-add-face' for any property, but without the
;; removal of inactive faces via `facemenu-discard-redundant-faces' and special
;; treatment of `default'.  Uses `unique' to remove duplicate property values.
(defsubst font-lock-prepend-text-property (start end prop value &optional object)
  "Prepend to one property of the text from START to END.
Arguments PROP and VALUE specify the property and value to prepend to the value
already in place.  The resulting property values are always lists, and unique.
Optional argument OBJECT is the string or buffer containing the text."
  (let ((val (if (listp value) value (list value))) next prev)
    (while (/= start end)
      (setq next (next-single-property-change start prop object end)
	    prev (get-text-property start prop object))
      (put-text-property
       start next prop
       (font-lock-unique (append val (if (listp prev) prev (list prev))))
       object)
      (setq start next))))

(defsubst font-lock-append-text-property (start end prop value &optional object)
  "Append to one property of the text from START to END.
Arguments PROP and VALUE specify the property and value to append to the value
already in place.  The resulting property values are always lists, and unique.
Optional argument OBJECT is the string or buffer containing the text."
  (let ((val (if (listp value) value (list value))) next prev)
    (while (/= start end)
      (setq next (next-single-property-change start prop object end)
	    prev (get-text-property start prop object))
      (put-text-property
       start next prop
       (font-lock-unique (append (if (listp prev) prev (list prev)) val))
       object)
      (setq start next))))

;;; Regexp fontification functions.

(defsubst font-lock-apply-highlight (highlight)
  "Apply HIGHLIGHT following a match.
HIGHLIGHT should be of the form MATCH-HIGHLIGHT, see `font-lock-keywords'."
  (let* ((match (nth 0 highlight))
	 (start (match-beginning match)) (end (match-end match))
	 (override (nth 2 highlight)))
    (and end
	 (goto-char end)) ;; tlp00 hack to allow for back to back fonts
    (let ((newface (nth 1 highlight)))
      (or (symbolp newface)
	  (setq newface (eval newface)))
      (cond ((not start)
	     ;; No match but we might not signal an error.
	     (or (nth 3 highlight)
		 (error "No match %d in highlight %S" match highlight)))
	    ((= start end) nil)
	    ((not override)
	     ;; Cannot override existing fontification.
	     (or (font-lock-any-faces-p start end)
		 (font-lock-set-face start end newface)))
	    ((eq override t)
	     ;; Override existing fontification.
	     (font-lock-set-face start end newface))
	    ((eq override 'keep)
	     ;; Keep existing fontification.
	     (font-lock-fillin-text-property start end 'face 'font-lock
					     newface))
	    ((eq override 'prepend)
	     ;; Prepend to existing fontification.
	     (font-lock-prepend-text-property start end 'face newface))
	    ((eq override 'append)
	     ;; Append to existing fontification.
	     (font-lock-append-text-property start end 'face newface))))))

(defsubst font-lock-fontify-anchored-keywords (keywords limit)
  "Fontify according to KEYWORDS until LIMIT.
KEYWORDS should be of the form MATCH-ANCHORED, see `font-lock-keywords'."
  (let ((matcher (nth 0 keywords)) (lowdarks (nthcdr 3 keywords)) highlights)
    ;; Until we come up with a cleaner solution, we make LIMIT the end of line.
    (save-excursion (end-of-line) (setq limit (min limit (point))))
    ;; Evaluate PRE-MATCH-FORM.
    (eval (nth 1 keywords))
    (save-match-data
      ;; Find an occurrence of `matcher' before `limit'.
      (while (if (stringp matcher)
		 (re-search-forward matcher limit t)
	       (funcall matcher limit))
	;; Apply each highlight to this instance of `matcher'.
	(setq highlights lowdarks)
	(while highlights
	  (font-lock-apply-highlight (car highlights))
	  (setq highlights (cdr highlights)))))
    ;; Evaluate POST-MATCH-FORM.
    (eval (nth 2 keywords))))

(defun font-lock-fontify-keywords-region (start end &optional loudvar)
  "Fontify according to `font-lock-keywords' between START and END.
START should be at the beginning of a line."
  (let ((loudly (and font-lock-verbose
		     (>= (- end start) font-lock-message-threshold))))
    (let ((case-fold-search font-lock-keywords-case-fold-search)
	  (keywords (cdr (if (eq (car-safe font-lock-keywords) t)
			     font-lock-keywords
			   (font-lock-compile-keywords))))
	  (bufname (buffer-name)) (count 0)
	  keyword matcher highlights)
      ;;
      ;; Fontify each item in `font-lock-keywords' from `start' to `end'.
      (while keywords
	(if loudly (message "Fontifying %s... (regexps..%s)" bufname
			    (make-string (setq count (1+ count)) ?.)))
	;;
	;; Find an occurrence of `matcher' from `start' to `end'.
	(setq keyword (car keywords) matcher (car keyword))
	(goto-char start)
	(while (if (stringp matcher)
		   (re-search-forward matcher end t)
		 (funcall matcher end))
	  ;; Apply each highlight to this instance of `matcher', which may be
	  ;; specific highlights or more keywords anchored to `matcher'.
	(setq highlights (cdr keyword))
	(while highlights
	  (if (numberp (car (car highlights)))
	      (font-lock-apply-highlight (car highlights))
	    (font-lock-fontify-anchored-keywords (car highlights) end))
	  (setq highlights (cdr highlights))))
	(setq keywords (cdr keywords))))
    (if loudly (message "Fontifying %s... done." (buffer-name)))))


;; Various functions.

;; Turn off other related packages if they're on.  I prefer a hook. --sm.
;; These explicit calls are easier to understand
;; because people know what they will do.
;; A hook is a mystery because it might do anything whatever. --rms.
(defun font-lock-thing-lock-cleanup ()
  (cond ((and (boundp 'fast-lock-mode) fast-lock-mode)
	 (fast-lock-mode -1))
	((and (boundp 'lazy-lock-mode) lazy-lock-mode)
	 (lazy-lock-mode -1))))

;; Do something special for these packages after fontifying.  I prefer a hook.
(defun font-lock-after-fontify-buffer ()
  (cond ((and (boundp 'fast-lock-mode) fast-lock-mode)
	 (fast-lock-after-fontify-buffer))
	((and (boundp 'lazy-lock-mode) lazy-lock-mode)
	 (lazy-lock-after-fontify-buffer))))

;; If the buffer is about to be reverted, it won't be fontified afterward.
(defun font-lock-revert-setup ()
  (setq font-lock-fontified nil))

;; If the buffer has just been reverted, normally that turns off
;; Font Lock mode.  So turn the mode back on if necessary.
(defalias 'font-lock-revert-cleanup 'turn-on-font-lock)

(defun font-lock-compile-keywords (&optional keywords)
  ;; Compile `font-lock-keywords' into the form (t KEYWORD ...) where KEYWORD
  ;; is the (MATCHER HIGHLIGHT ...) shown in the variable's doc string.
  (let ((keywords (or keywords font-lock-keywords)))
    (setq font-lock-keywords 
     (if (eq (car-safe keywords) t)
	 keywords
       (cons t
	(mapcar
	 (function (lambda (item)
	    (cond ((nlistp item)
		   (list item '(0 font-lock-keyword-face)))
		  ((numberp (cdr item))
		   (list (car item) (list (cdr item) 'font-lock-keyword-face)))
		  ((symbolp (cdr item))
		   (list (car item) (list 0 (cdr item))))
		  ((nlistp (nth 1 item))
		   (list (car item) (cdr item)))
		  (t
		   item))))
	 keywords))))))

(defun font-lock-choose-keywords (keywords level)
  ;; Return LEVELth element of KEYWORDS.  A LEVEL of nil is equal to a
  ;; LEVEL of 0, a LEVEL of t is equal to (1- (length KEYWORDS)).
  (let ((level (if (not (consp level))
		   level
		 (cdr (or (assq major-mode level) (assq t level))))))
    (cond ((symbolp keywords)
	   keywords)
	  ((numberp level)
	   (or (nth level keywords) (car (reverse keywords))))
	  ((eq level t)
	   (car (reverse keywords)))
	  (t
	   (car keywords)))))


;;; Determining which set of font-lock keywords to use.

(defun font-lock-find-font-lock-defaults (modesym)
  ;; Get the defaults based on the major mode.
  (let (raw-defaults)
    ;; I want a do-while loop!
    (while (progn
	     (setq raw-defaults (get modesym 'font-lock-defaults))
	     (and raw-defaults (symbolp raw-defaults)
		  (setq modesym raw-defaults)))
      )
    raw-defaults))

(defun font-lock-examine-syntax-table ()
  ; Computes the value of font-lock-keywords-only for this buffer.
  (if (eq (syntax-table) (standard-syntax-table))
      ;; Assume that modes which haven't bothered to install their own
      ;; syntax table don't do anything syntactically interesting.
      ;; Really, the standard-syntax-table shouldn't have comments and
      ;; strings in it, but changing that now might break things.
      nil
    ;; else map over the syntax table looking for strings or comments.
    (let (got-one)
      ;; older Emacsen.
      (let ((i (1- (length (syntax-table)))))
	(while (>= i 0)
	  (if (memq (char-syntax i) '(?\" ?\< ?\> ?\$))
	      (setq got-one t i 0))
	  (setq i (1- i))))
      (set (make-local-variable 'font-lock-keywords-only) (not got-one)))))

;; font-lock-set-defaults is in fontl-hooks.el.

(defun font-lock-set-defaults-1 (&optional explicit-defaults)
  ;; does everything that font-lock-set-defaults does except
  ;; enable font-lock-mode.  This is called by `font-lock-mode'.
  ;; Note that the return value is used!

  (if (and font-lock-defaults-computed (not explicit-defaults))
      ;; nothing to do.
      nil

    (or font-lock-keywords
	(let* ((defaults (or (and (not (eq t explicit-defaults))
				  explicit-defaults)
			     ;; in case modes decide to set
			     ;; `font-lock-defaults' themselves,
			     ;; as in FSF Emacs.
			     font-lock-defaults
			     (font-lock-find-font-lock-defaults major-mode)))
	       (keywords (font-lock-choose-keywords
			  (nth 0 defaults) font-lock-maximum-decoration)))
	  
	  ;; Keywords?
	  (setq font-lock-keywords (if (fboundp keywords)
				       (funcall keywords)
				     (eval keywords)))
	  (or font-lock-keywords
	      ;; older way:
	      ;; try to look for a variable `foo-mode-font-lock-keywords',
	      ;; or similar.
	      (let ((major (symbol-name major-mode))
		    (try #'(lambda (n)
			     (if (stringp n) (setq n (intern-soft n)))
			     (if (and n
				      (boundp n))
				 n
			       nil))))
		(setq font-lock-keywords 
		      (symbol-value
		       (or (funcall try (get major-mode 'font-lock-keywords))
			   (funcall try (concat major "-font-lock-keywords"))
			   (funcall try (and (string-match "-mode\\'" major)
					     (concat (substring 
						      major 0 
						      (match-beginning 0))
						     "-font-lock-keywords")))
			   'font-lock-keywords)))))

	  ;; Case fold?
	  (if (>= (length defaults) 3)
	      (setq font-lock-keywords-case-fold-search (nth 2 defaults))
	    ;; older way:
	    ;; look for a property 'font-lock-keywords-case-fold-search on
	    ;; the major-mode symbol.
	    (let* ((nonexist (make-symbol ""))
		   (value (get major-mode 'font-lock-keywords-case-fold-search
			       nonexist)))
	      (if (not (eq nonexist value))
		  (setq font-lock-keywords-case-fold-search value))))

	  ;; Syntactic?
	  (if (>= (length defaults) 2)
	      (setq font-lock-keywords-only (nth 1 defaults))
	    ;; older way:
	    ;; cleverly examine the syntax table.
	    (font-lock-examine-syntax-table))
	   
	  ;; Syntax table?
	  (if (nth 3 defaults)
	      (let ((slist (nth 3 defaults)))
		(setq font-lock-syntax-table
		      (copy-syntax-table (syntax-table)))
		(while slist
		  (modify-syntax-entry (car (car slist)) (cdr (car slist))
				       font-lock-syntax-table)
		  (setq slist (cdr slist)))))

	  ;; Syntax function?
	  (cond (defaults
		  (setq font-lock-beginning-of-syntax-function
			(nth 4 defaults)))
		(t
		 ;; older way:
		 ;; defaults not specified at all, so use `beginning-of-defun'.
		 (setq font-lock-beginning-of-syntax-function
		       'beginning-of-defun)))))

    (setq font-lock-defaults-computed t)))


;;; Initialization of faces.

(defconst font-lock-face-list
  '(font-lock-comment-face
    font-lock-doc-string-face
    font-lock-string-face
    font-lock-keyword-face
    font-lock-function-name-face
    font-lock-variable-name-face
    font-lock-type-face
    font-lock-reference-face
    font-lock-preprocessor-face))

(defun font-lock-reset-face (face)
  "Reset FACE its default state (from the X resource database).
Returns whether it is indistinguishable from the default face."
  (reset-face face)
  (init-face-from-resources face)
  (face-differs-from-default-p face))

(defun font-lock-reset-all-faces ()
  (mapcar 'font-lock-reset-face font-lock-face-list))

(defun font-lock-add-fonts (tag-list)
  ;; Underling comments looks terrible on tty's
  (if (featurep 'tty)
      (progn
	(set-face-underline-p 'font-lock-comment-face nil 'global
			      (append '(tty) tag-list) 'append)
	(set-face-highlight-p 'font-lock-comment-face t 'global
			      (append '(tty) tag-list)  'append)))
  (set-face-font 'font-lock-comment-face [italic] 'global tag-list 'append)
  (set-face-font 'font-lock-string-face [italic] 'global tag-list 'append)
  (set-face-font 'font-lock-doc-string-face [italic] 'global tag-list 'append)
  (set-face-font 'font-lock-function-name-face [bold] 'global tag-list 'append)
  (set-face-font 'font-lock-variable-name-face [bold] 'global tag-list 'append)
  (set-face-font 'font-lock-keyword-face [bold] 'global tag-list 'append)
  (set-face-font 'font-lock-preprocessor-face [bold-italic] 'global tag-list
		  'append)
  (set-face-font 'font-lock-type-face [italic] 'global tag-list 'append)
  (set-face-font 'font-lock-reference-face [bold] 'global tag-list 'append)
  nil)

(defun font-lock-add-colors (tag-list)
  (set-face-foreground 'font-lock-comment-face "red" 'global tag-list 'append)
  ;(set-face-font 'font-lock-comment-face [italic] 'global tag-list 'append)
  (set-face-foreground 'font-lock-string-face "green4" 'global tag-list
		       'append)
  (set-face-foreground 'font-lock-string-face "green" 'global tag-list
		       'append)
  (set-face-foreground 'font-lock-doc-string-face "green4" 'global tag-list
		       'append)
  (set-face-foreground 'font-lock-doc-string-face "green" 'global tag-list
		       'append)
  (set-face-foreground 'font-lock-function-name-face "blue3" 'global tag-list
		       'append)
  (set-face-foreground 'font-lock-function-name-face "blue" 'global tag-list
		       'append)
  (set-face-foreground 'font-lock-variable-name-face "blue3" 'global tag-list
		       'append)
  (set-face-foreground 'font-lock-variable-name-face "blue" 'global tag-list
		       'append)
  (set-face-foreground 'font-lock-reference-face "red3" 'global
		       tag-list 'append)
  (set-face-foreground 'font-lock-reference-face "red" 'global tag-list
		       'append)
  (set-face-foreground 'font-lock-keyword-face "orange" 'global tag-list
		       'append)
  ;(set-face-font 'font-lock-keyword-face [bold] 'global tag-list 'append)
  (set-face-foreground 'font-lock-preprocessor-face "blue3" 'global tag-list
		       'append)
  (set-face-foreground 'font-lock-preprocessor-face "blue" 'global tag-list
		       'append)
  ;(set-face-font 'font-lock-preprocessor-face [bold] 'global tag-list 'append)
  (set-face-foreground 'font-lock-type-face "#6920ac" 'global tag-list 'append)
  nil)

(defun font-lock-apply-defaults (function tag-list)
  (if (and (listp tag-list)
	   (eq 'or (car tag-list)))
      (mapcar #'(lambda (x)
		  (font-lock-apply-defaults function x))
	      (cdr tag-list))
    (if tag-list
	(if (not (valid-specifier-tag-set-p tag-list))
	    (warn "Invalid tag set found: %s" tag-list)
	  (funcall function tag-list)))))

(defun font-lock-recompute-variables ()
  ;; Is this a Draconian thing to do?
  (mapcar #'(lambda (buffer)
	      (save-excursion
		(set-buffer buffer)
		(font-lock-mode 0)
		(font-lock-set-defaults t)))
	  (buffer-list)))

;; Backwards-compatible crud.

(defun font-lock-use-default-fonts ()
  "Reset the font-lock faces to a default set of fonts."
  (interactive)
  (font-lock-reset-all-faces)
  (font-lock-add-fonts nil))

(defun font-lock-use-default-colors ()
  "Reset the font-lock faces to a default set of colors."
  (interactive)
  (font-lock-reset-all-faces)
  (font-lock-add-colors nil))

(defun font-lock-use-default-minimal-decoration ()
  "Reset the font-lock patterns to a fast, minimal set of decorations."
  (and font-lock-maximum-decoration
       (setq font-lock-maximum-decoration nil)
       (font-lock-recompute-variables)))

(defun font-lock-use-default-maximal-decoration ()
  "Reset the font-lock patterns to a larger set of decorations."
  (and (not (eq t font-lock-maximum-decoration))
       (setq font-lock-maximum-decoration t)
       (font-lock-recompute-variables)))


;;;;;;;;;;;;;;;;;;;;;;         keywords         ;;;;;;;;;;;;;;;;;;;;;;

;;; Various major-mode interfaces.
;;; Probably these should go in with the source of the respective major modes.

;; The defaults and keywords listed here should perhaps be moved into
;; mode-specific files.

;; For C and Lisp modes we use `beginning-of-defun', rather than nil,
;; for SYNTAX-BEGIN.  Thus the calculation of the cache is usually
;; faster but not infallible, so we risk mis-fontification.  --sm.

(put 'c-mode 'font-lock-defaults 
     '((c-font-lock-keywords
	c-font-lock-keywords-1 c-font-lock-keywords-2 c-font-lock-keywords-3)
       nil nil ((?_ . "w")) beginning-of-defun))
(put 'c++-c-mode 'font-lock-defaults 'c-mode)
(put 'elec-c-mode 'font-lock-defaults 'c-mode)

(put 'c++-mode 'font-lock-defaults
     '((c++-font-lock-keywords
	c++-font-lock-keywords-1 c++-font-lock-keywords-2
	c++-font-lock-keywords-3)
       nil nil ((?_ . "w") (?~ . "w")) beginning-of-defun))

(put 'java-mode 'font-lock-defaults 
     '((java-font-lock-keywords
	java-font-lock-keywords-1 java-font-lock-keywords-2
	java-font-lock-keywords-3)
       nil nil ((?_ . "w")) beginning-of-defun
       (font-lock-mark-block-function . mark-defun)))

(put 'lisp-mode 'font-lock-defaults
     '((lisp-font-lock-keywords
	lisp-font-lock-keywords-1 lisp-font-lock-keywords-2)
       nil nil
       ((?: . "w") (?- . "w") (?* . "w") (?+ . "w") (?. . "w") (?< . "w")
	(?> . "w") (?= . "w") (?! . "w") (?? . "w") (?$ . "w") (?% . "w")
	(?_ . "w") (?& . "w") (?~ . "w") (?^ . "w") (?/ . "w"))
       beginning-of-defun))
(put 'emacs-lisp-mode 'font-lock-defaults 'lisp-mode)
(put 'lisp-interaction-mode 'font-lock-defaults 'lisp-mode)

(put 'scheme-mode 'font-lock-defaults
     '(scheme-font-lock-keywords
       nil t
       ((?: . "w") (?- . "w") (?* . "w") (?+ . "w") (?. . "w") (?< . "w")
	(?> . "w") (?= . "w") (?! . "w") (?? . "w") (?$ . "w") (?% . "w")
	(?_ . "w") (?& . "w") (?~ . "w") (?^ . "w") (?/ . "w"))
       beginning-of-defun))
(put 'inferior-scheme-mode 'font-lock-defaults 'scheme-mode)
(put 'scheme-interaction-mode 'font-lock-defaults 'scheme-mode)

(put 'tex-mode 'font-lock-defaults
     ;; For TeX modes we could use `backward-paragraph' for the same reason.
     '(tex-font-lock-keywords nil nil ((?$ . "\""))))
;; the nine billion names of TeX mode...
(put 'bibtex-mode	'font-lock-defaults 'tex-mode)
(put 'plain-tex-mode	'font-lock-defaults 'tex-mode)
(put 'slitex-tex-mode	'font-lock-defaults 'tex-mode)
(put 'SliTeX-mode	'font-lock-defaults 'tex-mode)
(put 'slitex-mode	'font-lock-defaults 'tex-mode)
(put 'latex-tex-mode	'font-lock-defaults 'tex-mode)
(put 'LaTex-tex-mode	'font-lock-defaults 'tex-mode)
(put 'latex-mode        'font-lock-defaults 'tex-mode)
(put 'LaTeX-mode        'font-lock-defaults 'tex-mode)
(put 'japanese-LaTeX-mode 'font-lock-defaults 'tex-mode)
(put 'japanese-SliTeX-mode 'font-lock-defaults 'tex-mode)
(put 'FoilTeX-mode	'font-lock-defaults 'tex-mode)
(put 'LATeX-MoDe	'font-lock-defaults 'tex-mode)
(put 'lATEx-mODe	'font-lock-defaults 'tex-mode)
;; ok, this is getting a bit silly ...
(put 'eDOm-xETAl	'font-lock-defaults 'tex-mode)

;;; Various regexp information shared by several modes.
;;; Information specific to a single mode should go in its load library.

(defconst lisp-font-lock-keywords-1
  (list
   ;; Anything not a variable or type declaration is fontified as a function.
   ;; It would be cleaner to allow preceding whitespace, but it would also be
   ;; about five times slower.
   (list (concat "^(\\(def\\("
		  ;; Variable declarations.
		  "\\(const\\(\\|ant\\)\\|ine-key\\(\\|-after\\)\\|var\\)\\|"
		  ;; Structure declarations.
		  "\\(class\\|struct\\|type\\)\\|"
		  ;; Everything else is a function declaration.
		  "\\([^ \t\n\(\)]+\\)"
		  "\\)\\)\\>"
		  ;; Any whitespace and declared object.
		  "[ \t'\(]*"
		  "\\([^ \t\n\)]+\\)?")
	  '(1 font-lock-keyword-face)
	  '(8 (cond ((match-beginning 3) 'font-lock-variable-name-face)
		    ((match-beginning 6) 'font-lock-type-face)
		    (t 'font-lock-function-name-face))
	      nil t))
   )
 "Subdued level highlighting Lisp modes.")

(defconst lisp-font-lock-keywords-2
  (append lisp-font-lock-keywords-1
   (list
    ;;
    ;; Control structures.  ELisp and CLisp combined.
;      (make-regexp
;       '("cond" "if" "while" "let\\*?" "prog[nv12*]?" "catch" "throw"
;	 "save-restriction" "save-excursion" "save-window-excursion"
;	 "save-selected-window" "save-match-data" "unwind-protect"
;	 "condition-case" "track-mouse"
;	 "eval-after-load" "eval-and-compile" "eval-when-compile"
;	 "when" "unless" "do" "flet" "labels" "return" "return-from"))
    (cons
     (concat
      "(\\("
      "\\(c\\(atch\\|ond\\(\\|ition-case\\)\\)\\|do\\|"
      "eval-\\(a\\(fter-load\\|nd-compile\\)\\|when-compile\\)\\|flet\\|"
      "if\\|l\\(abels\\|et\\*?\\)\\|prog[nv12*]?\\|return\\(\\|-from\\)\\|"
      "save-\\(excursion\\|match-data\\|restriction\\|selected-window\\|"
      "window-excursion\\)\\|t\\(hrow\\|rack-mouse\\)\\|"
      "un\\(less\\|wind-protect\\)\\|wh\\(en\\|ile\\)\\)"
      "\\)\\>") 1)
    ;;
    ;; Words inside \\[] tend to be for `substitute-command-keys'.
    '("\\\\\\\\\\[\\(\\sw+\\)]" 1 font-lock-reference-face prepend)
    ;;
    ;; Words inside `' tend to be symbol names.
    '("`\\(\\sw\\sw+\\)'" 1 font-lock-reference-face prepend)
    ;;
    ;; CLisp `:' keywords as references.
    '("\\<:\\sw+\\>" 0 font-lock-reference-face prepend)
    ;;
    ;; ELisp and CLisp `&' keywords as types.
    '("\\<\\&\\(optional\\|rest\\|whole\\)\\>" . font-lock-type-face)
    ))
  "Gaudy level highlighting for Lisp modes.")

(defvar lisp-font-lock-keywords lisp-font-lock-keywords-1
  "Default expressions to highlight in Lisp modes.")

;; The previous version, before replacing it with the FSF version.
;(defconst lisp-font-lock-keywords-1 (purecopy
; '(;;
;   ;; highlight defining forms.  This doesn't work too nicely for
;   ;; (defun (setf foo) ...) but it does work for (defvar foo) which
;   ;; is more important.
;   ("^(def[-a-z]+\\s +\\([^ \t\n\)]+\\)" 1 font-lock-function-name-face)
;   ;;
;   ;; highlight CL keywords (three clauses seems faster than one)
;   ("\\s :\\(\\(\\sw\\|\\s_\\)+\\)\\>" . 1)
;   ("(:\\(\\(\\sw\\|\\s_\\)+\\)\\>" . 1)
;   ("':\\(\\(\\sw\\|\\s_\\)+\\)\\>" . 1)
;   ;;
;   ;; this is highlights things like (def* (setf foo) (bar baz)), but may
;   ;; be slower (I haven't really thought about it)
;;   ("^(def[-a-z]+\\s +\\(\\s(\\S)*\\s)\\|\\S(\\S *\\)"
;;    1 font-lock-function-name-face)
;   ))
; "For consideration as a value of `lisp-font-lock-keywords'.
;This does fairly subdued highlighting.")
;
;(defconst lisp-font-lock-keywords-2 (purecopy
;  (append lisp-font-lock-keywords-1
;   '(;;
;     ;; Highlight control structures
;     ("(\\(cond\\|if\\|when\\|unless\\|[ec]?\\(type\\)?case\\)[ \t\n]" . 1)
;     ("(\\(while\\|do\\|let\\*?\\|flet\\|labels\\|prog[nv12*]?\\)[ \t\n]" . 1)
;     ("(\\(do\\*\\|dotimes\\|dolist\\|loop\\)[ \t\n]" . 1)
;     ("(\\(catch\\|\\throw\\|block\\|return\\|return-from\\)[ \t\n]" . 1)
;     ("(\\(save-restriction\\|save-window-restriction\\)[ \t\n]" . 1)
;     ("(\\(save-excursion\\|unwind-protect\\|condition-case\\)[ \t\n]" . 1)
;     ;;
;     ;; highlight function names in emacs-lisp docstrings (in the syntax
;     ;; that substitute-command-keys understands.)
;     ("\\\\\\\\\\[\\([^]\\\n]+\\)]" 1 font-lock-keyword-face t)
;     ;;
;     ;; highlight words inside `' which tend to be function names
;     ("`\\([-a-zA-Z0-9_][-a-zA-Z0-9_][-a-zA-Z0-9_.]+\\)'"
;      1 font-lock-keyword-face t)
;     )))
; "For consideration as a value of `lisp-font-lock-keywords'.
;
;This does a lot more highlighting.")

(defvar scheme-font-lock-keywords
  (eval-when-compile
    (list
     ;;
     ;; Declarations.  Hannes Haug <hannes.haug@student.uni-tuebingen.de> says
     ;; this works for SOS, STklos, SCOOPS, Meroon and Tiny CLOS.
     (list (concat "(\\(define\\("
		   ;; Function names.
		   "\\(\\|-\\(generic\\(\\|-procedure\\)\\|method\\)\\)\\|"
		   ;; Macro names, as variable names.  A bit dubious, this.
		   "\\(-syntax\\)\\|"
		   ;; Class names.
		   "\\(-class\\)"
		   "\\)\\)\\>"
		   ;; Any whitespace and declared object.
		   "[ \t]*(?"
		   "\\(\\sw+\\)?")
	   '(1 font-lock-keyword-face)
	   '(8 (cond ((match-beginning 3) 'font-lock-function-name-face)
		     ((match-beginning 6) 'font-lock-variable-name-face)
		     (t 'font-lock-type-face))
	       nil t))
     ;;
     ;; Control structures.
;(make-regexp '("begin" "call-with-current-continuation" "call/cc"
;	       "call-with-input-file" "call-with-output-file" "case" "cond"
;	       "do" "else" "for-each" "if" "lambda"
;	       "let\\*?" "let-syntax" "letrec" "letrec-syntax"
;	       ;; Hannes Haug <hannes.haug@student.uni-tuebingen.de> wants:
;	       "and" "or" "delay"
;	       ;; Stefan Monnier <stefan.monnier@epfl.ch> says don't bother:
;	       ;;"quasiquote" "quote" "unquote" "unquote-splicing"
;	       "map" "syntax" "syntax-rules"))
     (cons
      (concat "(\\("
	      "and\\|begin\\|c\\(a\\(ll\\(-with-\\(current-continuation\\|"
	      "input-file\\|output-file\\)\\|/cc\\)\\|se\\)\\|ond\\)\\|"
	      "d\\(elay\\|o\\)\\|else\\|for-each\\|if\\|"
	      "l\\(ambda\\|et\\(-syntax\\|\\*?\\|rec\\(\\|-syntax\\)\\)\\)\\|"
	      "map\\|or\\|syntax\\(\\|-rules\\)"
	      "\\)\\>") 1)
     ;;
     ;; David Fox <fox@graphics.cs.nyu.edu> for SOS/STklos class specifiers.
     '("\\<<\\sw+>\\>" . font-lock-type-face)
     ;;
     ;; Scheme `:' keywords as references.
     '("\\<:\\sw+\\>" . font-lock-reference-face)
     ))
"Default expressions to highlight in Scheme modes.")

;; The previous version, before replacing it with the FSF version.
;(defconst scheme-font-lock-keywords (purecopy
; '(("(define[ \t]+(?\\([^ \t\n\)]+\\)" 1 font-lock-function-name-face)
;   ("(\\(cond\\|lambda\\|begin\\|if\\|else\\|case\\|do\\)[ \t\n]" . 1)
;   ("(\\(\\|letrec\\|let\\*?\\|set!\\|and\\|or\\)[ \t\n]" . 1)
;   ("(\\(quote\\|unquote\\|quasiquote\\|unquote-splicing\\)[ \t\n]" . 1)
;   ("(\\(syntax\\|syntax-rules\\|define-syntax\\|let-syntax\\|letrec-syntax\\)[ \t\n]" . 1)))
;  "Expressions to highlight in Scheme buffers.")

(defconst c-font-lock-keywords-1 nil
  "Subdued level highlighting for C modes.")

(defconst c-font-lock-keywords-2 nil
  "Medium level highlighting for C modes.")

(defconst c-font-lock-keywords-3 nil
  "Gaudy level highlighting for C modes.")

(defconst c++-font-lock-keywords-1 nil
  "Subdued level highlighting for C++ modes.")

(defconst c++-font-lock-keywords-2 nil
  "Medium level highlighting for C++ modes.")

(defconst c++-font-lock-keywords-3 nil
  "Gaudy level highlighting for C++ modes.")

(defun font-lock-match-c++-style-declaration-item-and-skip-to-next (limit)
  ;; Match, and move over, any declaration/definition item after point.
  ;; The expect syntax of an item is "word" or "word::word", possibly ending
  ;; with optional whitespace and a "(".  Everything following the item (but
  ;; belonging to it) is expected to by skip-able by `forward-sexp', and items
  ;; are expected to be separated with a "," or ";".
  (if (looking-at "[ \t*&]*\\(\\sw+\\)\\(::\\(\\sw+\\)\\)?[ \t]*\\((\\)?")
      (save-match-data
	(condition-case nil
	    (save-restriction
	      ;; Restrict to the end of line, currently guaranteed to be LIMIT.
	      (narrow-to-region (point-min) limit)
	      (goto-char (match-end 1))
	      ;; Move over any item value, etc., to the next item.
	      (while (not (looking-at "[ \t]*\\([,;]\\|$\\)"))
		(goto-char (or (scan-sexps (point) 1) (point-max))))
	      (goto-char (match-end 0)))
	  (error t)))))

(let ((c-keywords
;      ("break" "continue" "do" "else" "for" "if" "return" "switch" "while")
       "break\\|continue\\|do\\|else\\|for\\|if\\|return\\|switch\\|while")
      (c-type-types
;      ("auto" "extern" "register" "static" "typedef" "struct" "union" "enum"
;	"signed" "unsigned" "short" "long" "int" "char" "float" "double"
;	"void" "volatile" "const")
       (concat "auto\\|c\\(har\\|onst\\)\\|double\\|e\\(num\\|xtern\\)\\|"
	       "float\\|int\\|long\\|register\\|"
	       "s\\(hort\\|igned\\|t\\(atic\\|ruct\\)\\)\\|typedef\\|"
	       "un\\(ion\\|signed\\)\\|vo\\(id\\|latile\\)"))	; 6 ()s deep.
      (c++-keywords
;      ("break" "continue" "do" "else" "for" "if" "return" "switch" "while"
;	"asm" "catch" "delete" "new" "operator" "sizeof" "this" "throw" "try"
;       "protected" "private" "public")
       (concat "asm\\|break\\|c\\(atch\\|ontinue\\)\\|d\\(elete\\|o\\)\\|"
	       "else\\|for\\|if\\|new\\|"
	       "p\\(r\\(ivate\\|otected\\)\\|ublic\\)\\|return\\|"
	       "s\\(izeof\\|witch\\)\\|t\\(h\\(is\\|row\\)\\|ry\\)\\|while"))
      (c++-type-types
;      ("auto" "extern" "register" "static" "typedef" "struct" "union" "enum"
;	"signed" "unsigned" "short" "long" "int" "char" "float" "double"
;	"void" "volatile" "const" "class" "inline" "friend" "bool"
;	"virtual" "complex" "template")
       (concat "auto\\|bool\\|c\\(har\\|lass\\|o\\(mplex\\|nst\\)\\)\\|"
	       "double\\|e\\(num\\|xtern\\)\\|f\\(loat\\|riend\\)\\|"
	       "in\\(line\\|t\\)\\|long\\|register\\|"
	       "s\\(hort\\|igned\\|t\\(atic\\|ruct\\)\\)\\|"
	       "t\\(emplate\\|ypedef\\)\\|un\\(ion\\|signed\\)\\|"
	       "v\\(irtual\\|o\\(id\\|latile\\)\\)"))		; 11 ()s deep.
      (ctoken "\\(\\sw\\|\\s_\\|[:~*&]\\)+")
      )
 (setq c-font-lock-keywords-1
  (list
   ;;
   ;; These are all anchored at the beginning of line for speed.
   ;;
   ;; Fontify function name definitions (GNU style; without type on line).
   
   ;; In FSF this has the simpler definition of "\\sw+" for ctoken.
   ;; I'm not sure if ours is more correct.
   (list (concat "^\\(" ctoken "\\)[ \t]*(") 1 'font-lock-function-name-face)
   ;;
   ;; fontify the names of functions being defined.
   ;; FSF doesn't have this but I think it should be fast for us because
   ;; our regexp routines are more intelligent than FSF's about handling
   ;; anchored-at-newline. (When I added this hack in regex.c, it halved
   ;; the time to do the regexp phase of font-lock for a C file!) Not
   ;; including this discriminates against those who don't follow the
   ;; GNU coding style. --ben
   (list (concat
          "^\\(" ctoken "[ \t]+\\)?"	; type specs; there can be no
          "\\(" ctoken "[ \t]+\\)?"	; more than 3 tokens, right?
          "\\(" ctoken "[ \t]+\\)?"
          "\\([*&]+[ \t]*\\)?"		; pointer
          "\\(" ctoken "\\)[ \t]*(")	; name
         8 'font-lock-function-name-face)
   ;;
   ;; This is faster but not by much.  I don't see why not.
   ;(list (concat "^\\(" ctoken "\\)[ \t]*(") 1 'font-lock-function-name-face)
   ;;
   ;; Added next two; they're both jolly-good fastmatch candidates so
   ;; should be fast. --ben
   ;;
   ;; Fontify structure names (in structure definition form).
   (list (concat "^\\(typedef[ \t]+struct\\|struct\\|static[ \t]+struct\\)"
      	   "[ \t]+\\(" ctoken "\\)[ \t]*\\(\{\\|$\\)")
         2 'font-lock-function-name-face)
   ;;
   ;; Fontify case clauses.  This is fast because its anchored on the left.
   '("case[ \t]+\\(\\(\\sw\\|\\s_\\)+\\):". 1)
   ;;
   '("\\<\\(default\\):". 1)
   ;; Fontify filenames in #include <...> preprocessor directives as strings.
   '("^#[ \t]*include[ \t]+\\(<[^>\"\n]+>\\)" 1 font-lock-string-face)
   ;;
   ;; Fontify function macro names.
   '("^#[ \t]*define[ \t]+\\(\\(\\sw+\\)(\\)" 2 font-lock-function-name-face)
   ;;
   ;; Fontify symbol names in #if ... defined preprocessor directives.
   '("^#[ \t]*if\\>"
     ("\\<\\(defined\\)\\>[ \t]*(?\\(\\sw+\\)?" nil nil
      (1 font-lock-preprocessor-face) (2 font-lock-variable-name-face nil t)))
   ;;
   ;; Fontify symbol names in #elif ... defined preprocessor directives.
   '("^#[ \t]*elif\\>"
     ("\\<\\(defined\\)\\>[ \t]*(?\\(\\sw+\\)?" nil nil
      (1 font-lock-preprocessor-face) (2 font-lock-variable-name-face nil t)))
   ;;
   ;; Fontify otherwise as symbol names, and the preprocessor directive names.
   '("^\\(#[ \t]*[a-z]+\\)\\>[ \t]*\\(\\sw+\\)?"
     (1 font-lock-preprocessor-face) (2 font-lock-variable-name-face nil t))
   ))

 (setq c-font-lock-keywords-2
  (append c-font-lock-keywords-1
   (list
    ;;
    ;; Simple regexps for speed.
    ;;
    ;; Fontify all type specifiers.
    (cons (concat "\\<\\(" c-type-types "\\)\\>") 'font-lock-type-face)
    ;;
    ;; Fontify all builtin keywords (except case, default and goto; see below).
    (cons (concat "\\<\\(" c-keywords "\\)\\>") 'font-lock-keyword-face)
    ;;
    ;; Fontify case/goto keywords and targets, and case default/goto tags.
    '("\\<\\(case\\|goto\\)\\>[ \t]*\\([^ \t\n:;]+\\)?"
      (1 font-lock-keyword-face) (2 font-lock-reference-face nil t))
    '("^[ \t]*\\(\\sw+\\)[ \t]*:" 1 font-lock-reference-face)
    )))

 (setq c-font-lock-keywords-3
  (append c-font-lock-keywords-2
   ;;
   ;; More complicated regexps for more complete highlighting for types.
   ;; We still have to fontify type specifiers individually, as C is so hairy.
   (list
    ;;
    ;; Fontify all storage classes and type specifiers, plus their items.
    (list (concat "\\<\\(" c-type-types "\\)\\>"
		  "\\([ \t*&]+\\sw+\\>\\)*")
	  ;; Fontify each declaration item.
	  '(font-lock-match-c++-style-declaration-item-and-skip-to-next
	    ;; Start with point after all type specifiers.
	    (goto-char (or (match-beginning 8) (match-end 1)))
	    ;; Finish with point after first type specifier.
	    (goto-char (match-end 1))
	    ;; Fontify as a variable or function name.
	    (1 (if (match-beginning 4)
		   font-lock-function-name-face
		 font-lock-variable-name-face))))
    ;;
    ;; Fontify structures, or typedef names, plus their items.
    '("\\(}\\)[ \t*]*\\sw"
      (font-lock-match-c++-style-declaration-item-and-skip-to-next
       (goto-char (match-end 1)) nil
       (1 (if (match-beginning 4)
	      font-lock-function-name-face
	    font-lock-variable-name-face))))
    ;;
    ;; Fontify anything at beginning of line as a declaration or definition.
    '("^\\(\\sw+\\)\\>\\([ \t*]+\\sw+\\>\\)*"
      (1 font-lock-type-face)
      (font-lock-match-c++-style-declaration-item-and-skip-to-next
       (goto-char (or (match-beginning 2) (match-end 1))) nil
       (1 (if (match-beginning 4)
	      font-lock-function-name-face
	    font-lock-variable-name-face))))
    )))

 (setq c++-font-lock-keywords-1
  (append
   ;;
   ;; The list `c-font-lock-keywords-1' less that for function names.
   (cdr c-font-lock-keywords-1)
   ;;
   ;; Fontify function name definitions, possibly incorporating class name.
   (list
    '("^\\(\\sw+\\)\\(::\\(\\sw+\\)\\)?[ \t]*("
      (1 (if (match-beginning 2)
	     font-lock-type-face
	   font-lock-function-name-face))
      (3 (if (match-beginning 2) font-lock-function-name-face) nil t))
    )))

 (setq c++-font-lock-keywords-2
  (append c++-font-lock-keywords-1
   (list
    ;;
    ;; The list `c-font-lock-keywords-2' for C++ plus operator overloading.
    (cons (concat "\\<\\(" c++-type-types "\\)\\>") 'font-lock-type-face)
    ;;
    ;; Fontify operator function name overloading.
    '("\\<\\(operator\\)\\>[ \t]*\\([][)(><!=+-][][)(><!=+-]?\\)?"
      (1 font-lock-keyword-face) (2 font-lock-function-name-face nil t))
    ;;
    ;; Fontify case/goto keywords and targets, and case default/goto tags.
    '("\\<\\(case\\|goto\\)\\>[ \t]*\\([^ \t\n:;]+\\)?"
      (1 font-lock-keyword-face) (2 font-lock-reference-face nil t))
    '("^[ \t]*\\(\\sw+\\)[ \t]*:[^:]" 1 font-lock-reference-face)
    ;;
    ;; Fontify other builtin keywords.
    (cons (concat "\\<\\(" c++-keywords "\\)\\>") 'font-lock-keyword-face)
    )))

 (setq c++-font-lock-keywords-3
  (append c++-font-lock-keywords-2
   ;;
   ;; More complicated regexps for more complete highlighting for types.
   (list
    ;;
    ;; Fontify all storage classes and type specifiers, plus their items.
    (list (concat "\\<\\(" c++-type-types "\\)\\>"
		  "\\([ \t*&]+\\sw+\\>\\)*")
	  ;; Fontify each declaration item.
	  '(font-lock-match-c++-style-declaration-item-and-skip-to-next
	    ;; Start with point after all type specifiers.
	    (goto-char (or (match-beginning 13) (match-end 1)))
	    ;; Finish with point after first type specifier.
	    (goto-char (match-end 1))
	    ;; Fontify as a variable or function name.
	    (1 (cond ((match-beginning 2) 'font-lock-type-face)
		     ((match-beginning 4) 'font-lock-function-name-face)
		     (t 'font-lock-variable-name-face)))
	    (3 (if (match-beginning 4)
		   'font-lock-function-name-face
		 'font-lock-variable-name-face) nil t)))
    ;;
    ;; Fontify structures, or typedef names, plus their items.
    '("\\(}\\)[ \t*]*\\sw"
      (font-lock-match-c++-style-declaration-item-and-skip-to-next
       (goto-char (match-end 1)) nil
       (1 (if (match-beginning 4)
	      font-lock-function-name-face
	    font-lock-variable-name-face))))
    ;;
    ;; Fontify anything at beginning of line as a declaration or definition.
    '("^\\(\\sw+\\)\\>\\([ \t*]+\\sw+\\>\\)*"
      (1 font-lock-type-face)
      (font-lock-match-c++-style-declaration-item-and-skip-to-next
       (goto-char (or (match-beginning 2) (match-end 1))) nil
       (1 (cond ((match-beginning 2) 'font-lock-type-face)
		((match-beginning 4) 'font-lock-function-name-face)
		(t 'font-lock-variable-name-face)))
       (3 (if (match-beginning 4)
	      'font-lock-function-name-face
	    'font-lock-variable-name-face) nil t)))
    )))
 )

(defvar c-font-lock-keywords c-font-lock-keywords-1
  "Default expressions to highlight in C mode.")

(defvar c++-font-lock-keywords c++-font-lock-keywords-1
  "Default expressions to highlight in C++ mode.")

;; The previous version, before replacing it with the FSF version.
;(defconst c-font-lock-keywords-1 nil
; "For consideration as a value of `c-font-lock-keywords'.
;This does fairly subdued highlighting.")
;
;(defconst c-font-lock-keywords-2 nil
; "For consideration as a value of `c-font-lock-keywords'.
;This does a lot more highlighting.")
;
;(let ((storage "auto\\|extern\\|register\\|static\\|volatile")
;      (prefixes "unsigned\\|short\\|long\\|const")
;      (types (concat "int\\|long\\|char\\|float\\|double\\|void\\|struct\\|"
;		      "union\\|enum\\|typedef"))
;      (ctoken "\\(\\sw\\|\\s_\\|[:~*&]\\)+")
;      )
;  (setq c-font-lock-keywords-1 (purecopy
;   (list
;    ;; fontify preprocessor directives.
;    '("^#[ \t]*[a-z]+" . font-lock-preprocessor-face)
;    ;;
;    ;; fontify names being defined.
;    '("^#[ \t]*\\(define\\|undef\\)[ \t]+\\(\\(\\sw\\|\\s_\\)+\\)" 2
;      font-lock-function-name-face)
;    ;;
;    ;; fontify other preprocessor lines.
;    '("^#[ \t]*\\(if\\|ifn?def\\|elif\\)[ \t]+\\([^\n]+\\)"
;      2 font-lock-function-name-face t)
;    ;;
;    ;; fontify the filename in #include <...>
;    ;; don't need to do this for #include "..." because those were
;    ;; already fontified as strings by the syntactic pass.
;    ;; (Changed to not include the <> in the face, since "" aren't.)
;    '("^#[ \t]*include[ \t]+<\\([^>\"\n]+\\)>" 1 font-lock-string-face)
;    ;;
;    ;; fontify the names of functions being defined.
;    ;; I think this should be fast because it's anchored at bol, but it's not.
;    (list (concat
;	    "^\\(" ctoken "[ \t]+\\)?"	; type specs; there can be no
;	    "\\(" ctoken "[ \t]+\\)?"	; more than 3 tokens, right?
;	    "\\(" ctoken "[ \t]+\\)?"
;	    "\\([*&]+[ \t]*\\)?"		; pointer
;	    "\\(" ctoken "\\)[ \t]*(")	; name
;	   8 'font-lock-function-name-face)
;    ;;
;    ;; This is faster but not by much.  I don't see why not.
;;    (list (concat "^\\(" ctoken "\\)[ \t]*(") 1 'font-lock-function-name-face)
;    ;;
;    ;; Fontify structure names (in structure definition form).
;    (list (concat "^\\(typedef[ \t]+struct\\|struct\\|static[ \t]+struct\\)"
;		   "[ \t]+\\(" ctoken "\\)[ \t]*\\(\{\\|$\\)")
;	   2 'font-lock-function-name-face)
;    ;;
;    ;; Fontify case clauses.  This is fast because its anchored on the left.
;    '("case[ \t]+\\(\\(\\sw\\|\\s_\\)+\\):". 1)
;    '("\\<\\(default\\):". 1)
;    )))
;
;  (setq c-font-lock-keywords-2 (purecopy
;   (append c-font-lock-keywords-1
;    (list
;     ;;
;     ;; fontify all storage classes and type specifiers
;     ;; types should be surrounded by non alphanumerics (Raymond Toy)
;     (cons (concat "\\<\\(" storage "\\)\\>") 'font-lock-type-face)
;     (list (concat "\\([^a-zA-Z0-9_]\\|^\\)\\("
;		    types
;		    "\\)\\([^a-zA-Z0-9_]\\|$\\)")
;	    2 'font-lock-type-face)
;     ;; fontify the prefixes now.  The types should have been fontified
;     ;; previously.
;     (list (concat "\\<\\(" prefixes "\\)[ \t]+\\(" types "\\)\\>")
;	    1 'font-lock-type-face)
;     ;;
;     ;; fontify all builtin tokens
;     (cons (concat
;	     "[ \t]\\("
;	     (mapconcat 'identity
;	      '("for" "while" "do" "return" "goto" "case" "break" "switch"
;		"if" "then" "else if" "else" "return" "continue" "default"
;		)
;	      "\\|")
;	     "\\)[ \t\n(){};,]")
;	    1)
;     ;;
;     ;; fontify case targets and goto-tags.  This is slow because the
;     ;; expression is anchored on the right.
;     "\\(\\(\\sw\\|\\s_\\)+\\):"
;     ;;
;     ;; Fontify variables declared with structures, or typedef names.
;     '("}[ \t*]*\\(\\(\\sw\\|\\s_\\)+\\)[ \t]*[,;]"
;	1 font-lock-function-name-face)
;     ;;
;     ;; Fontify global variables without a type.
;;     '("^\\([_a-zA-Z0-9:~*]+\\)[ \t]*[[;={]" 1 font-lock-function-name-face)
;
;     ))))
;  )
;
;
;;; default to the gaudier variety?
;;(defconst c-font-lock-keywords c-font-lock-keywords-2
;;  "Additional expressions to highlight in C mode.")
;(defconst c-font-lock-keywords c-font-lock-keywords-1
;  "Additional expressions to highlight in C mode.")
;
;(defconst c++-font-lock-keywords-1 nil
; "For consideration as a value of `c++-font-lock-keywords'.
;This does fairly subdued highlighting.")
;
;(defconst c++-font-lock-keywords-2 nil
; "For consideration as a value of `c++-font-lock-keywords'.
;This does a lot more highlighting.")
;
;(let ((ctoken "\\(\\sw\\|\\s_\\|[:~*&]\\)+")
;      (c++-types (concat "complex\\|public\\|private\\|protected\\|virtual\\|"
;			  "friend\\|inline"))
;      c++-font-lock-keywords-internal-1
;      c++-font-lock-keywords-internal-2
;      )
;  (setq c++-font-lock-keywords-internal-1 (purecopy
;   (list
;    ;;
;    ;; fontify friend operator functions
;    '("^\\(operator[^(]*\\)(" 1 font-lock-function-name-face)
;    '("^\\(operator[ \\t]*([ \\t]*)[^(]*\\)(" 1 font-lock-function-name-face)
;
;    ;; fontify the class names only in the definition
;    (list (concat "^class[ \t]+" ctoken "[ \t\n{: ;]") 1
;	   'font-lock-function-name-face)
;
;    (list (concat
;	    "^\\(" ctoken "[ \t]+\\)?" ; type specs; there can be no
;	    "\\(" ctoken "[ \t]+\\)?" ; more than 3 tokens, right?
;	    "\\(" ctoken "[ \t]+\\)?"
;	    "\\(\\*+[ \t]*\\)?"	; pointer
;	    "\\(" ctoken "\\(::\\)?~?\\(\\(operator[ \t]*[^ \ta-zA-Z]+\\)\\|"
;	    ctoken "\\)\\)[ \t]*(") ; name
;	   8 'font-lock-function-name-face t)
;    )))
;
;  (setq c++-font-lock-keywords-internal-2 (purecopy
;   (list
;    ;; fontify extra c++ storage classes and type specifiers
;    (cons (concat "\\<\\(" c++-types "\\)\\>") 'font-lock-type-face)
;
;    ;;special check for class
;    '("^\\(\\<\\|template[ \t]+<[ \t]*\\)\\(class\\)[ \t\n]+" 2
;      font-lock-type-face)
;
;    ;; special handling of template
;    "^\\(template\\)\\>"
;    ;; fontify extra c++ builtin tokens
;    (cons (concat
;	    "[ \t]\\("
;	    (mapconcat 'identity
;		       '("asm" "catch" "throw" "try" "delete" "new" "operator"
;			 "sizeof" "this"
;			 )
;		       "\\|")
;	    "\\)[ \t\n(){};,]")
;	   1)
;    )))
;
;  (setq c++-font-lock-keywords-1 (purecopy
;   (append c-font-lock-keywords-1 c++-font-lock-keywords-internal-1)))
;
;  (setq c++-font-lock-keywords-2 (purecopy
;   (append c-font-lock-keywords-2 c++-font-lock-keywords-internal-1
;	    c++-font-lock-keywords-internal-2)))
;  )
;
;(defconst c++-font-lock-keywords c++-font-lock-keywords-1
;  "Additional expressions to highlight in C++ mode.")


;; Java support from Anders Lindgren and Bob Weiner

(defconst java-font-lock-keywords-1 nil
 "For consideration as a value of `java-font-lock-keywords'.
This does fairly subdued highlighting.")

(defconst java-font-lock-keywords-2 nil
 "For consideration as a value of `java-font-lock-keywords'.
This adds highlighting of types and identifier names.")

(defconst java-font-lock-keywords-3 nil
 "For consideration as a value of `java-font-lock-keywords'.
This adds highlighting of Java documentation tags, such as @see.")

(defvar java-font-lock-type-regexp
  (concat "\\<\\(boolean\\|byte\\|char\\|double\\|float\\|int"
	  "\\|long\\|short\\|void\\)\\>")
  "Regexp which should match a primitive type.")

(let ((capital-letter "A-Z\300-\326\330-\337")
      (letter "a-zA-Z_$\300-\326\330-\366\370-\377")
      (digit  "0-9"))
(defvar java-font-lock-identifier-regexp
  (concat "\\<\\([" letter "][" letter digit "]*\\)\\>")
  "Regexp which should match all Java identifiers.")

(defvar java-font-lock-class-name-regexp
  (concat "\\<\\([" capital-letter "][" letter digit "]*\\)\\>")
  "Regexp which should match a class or an interface name.
The name is assumed to begin with a capital letter.")
)
	

(let ((java-modifier-regexp
       (concat "\\<\\(abstract\\|const\\|final\\|native\\|"
	       "private\\|protected\\|public\\|"
	       "static\\|synchronized\\|transient\\|volatile\\)\\>")))

  ;; Basic font-lock support:
  (setq java-font-lock-keywords-1
	(list

	 ;; Keywords:
	 (list        
	  (concat
	   "\\<\\("
	   "break\\|byvalue\\|"
	   "case\\|cast\\|catch\\|class\\|continue\\|"
	   "do\\|else\\|extends\\|"
	   "finally\\|for\\|future\\|"
	   "generic\\|goto\\|"
	   "if\\|implements\\|import\\|"
	   "instanceof\\|interface\\|"
	   "new\\|package\\|return\\|switch\\|"
	   "throws?\\|try\\|while\\)\\>")
	  1 'font-lock-keyword-face)

	 ;; Modifiers:
	 (list java-modifier-regexp 1 font-lock-type-face)

	 ;; Special constants:
	 '("\\<\\(this\\|super\\)\\>" (1 font-lock-reference-face))
	 '("\\<\\(false\\|null\\|true\\)\\>" (1 font-lock-keyword-face))

	 ;; Class names:
	 (list (concat "\\<class\\>\\s *" java-font-lock-identifier-regexp)
	       1 'font-lock-function-name-face)
	 
	 ;; Package declarations:
	 (list (concat "\\<\\(package\\|import\\)\\>\\s *"
		       java-font-lock-identifier-regexp)
	       '(2 font-lock-reference-face)
	       (list (concat
		      "\\=\\.\\(" java-font-lock-identifier-regexp "\\)")
		     nil nil '(1 (if (= (char-after (match-end 0)) ?.)
				     'font-lock-reference-face
				   'font-lock-type-face))))

	 ;; Constructors:
	 (list (concat
		"^\\s *\\(" java-modifier-regexp "\\s +\\)*"
		java-font-lock-class-name-regexp "\\s *\(")
	       (list 3
		     '(condition-case nil
			  (save-excursion
			    (goto-char (scan-sexps (- (match-end 0) 1) 1))
			    (parse-partial-sexp (point) (point-max) nil t)
			    (and (looking-at "\\($\\|\\<throws\\>\\|{\\)")
				 'font-lock-function-name-face))
			(error 'font-lock-function-name-face))))

	 ;; Methods:
	 (list (concat "\\(" java-font-lock-type-regexp "\\|"
		       java-font-lock-class-name-regexp "\\)"
		       "\\s *\\(\\[\\s *\\]\\s *\\)*"
		       java-font-lock-identifier-regexp "\\s *\(")
	       5
	       'font-lock-function-name-face)

	 ;; Labels:
	 (list ":"
	       (list
		(concat "^\\s *" java-font-lock-identifier-regexp "\\s *:")
		'(beginning-of-line) '(end-of-line)
		'(1 font-lock-reference-face)))

	 ;; `break' and continue' destination labels:
	 (list (concat "\\<\\(break\\|continue\\)\\>\\s *"
		       java-font-lock-identifier-regexp)
	       2 'font-lock-reference-face)

	 ;; Case statements:
	 ;; In Java, any constant expression is allowed.
	 '("\\<case\\>\\s *\\(.*\\):" 1 font-lock-reference-face)))

  ;; Types and declared variable names:
  (setq java-font-lock-keywords-2
	(append 

	 java-font-lock-keywords-1

	 (list

	  ;; Keywords followed by a type:
	  (list (concat "\\<\\(extends\\|instanceof\\|new\\)\\>\\s *"
			java-font-lock-identifier-regexp)
		'(2 (if (= (char-after (match-end 0)) ?.)
			'font-lock-reference-face 'font-lock-type-face))
		(list (concat "\\=\\." java-font-lock-identifier-regexp)
		      '(goto-char (match-end 0)) nil
		      '(1 (if (= (char-after (match-end 0)) ?.)
			      'font-lock-reference-face 'font-lock-type-face))))

	  ;; Keywords followed by a type list:
	  (list (concat "\\<\\(implements\\|throws\\)\\>\\ s*"
			java-font-lock-identifier-regexp)
		'(2 (if (= (char-after (match-end 0)) ?.)
			font-lock-reference-face font-lock-type-face))
		(list (concat "\\=\\(\\.\\|\\s *\\(,\\)\\s *\\)"
			      java-font-lock-identifier-regexp)
		      '(goto-char (match-end 0)) nil
		      '(3 (if (= (char-after (match-end 0)) ?.)
			      font-lock-reference-face font-lock-type-face))))

	  ;; primitive types, can't be confused with anything else.
	  (list java-font-lock-type-regexp
		'(1 font-lock-type-face)
		'(font-lock-match-java-declarations
		  (goto-char (match-end 0))
		  (goto-char (match-end 0))
		  (0 font-lock-variable-name-face)))

	  ;; Declarations, class types and capitalized variables:
	  ;;
	  ;; Declarations are easy to recognize.  Capitalized words
	  ;; followed by a closing parenthesis are treated as casts if they
	  ;; also are followed by an expression.  Expressions beginning with
	  ;; a unary numerical operator, e.g. +, can't be cast to an object
	  ;; type.
	  ;;
	  ;; The path of a fully qualified type, e.g. java.lang.Foo, is
	  ;; fontified in the reference face.
	  ;;
	  ;; An access to a static field, e.g. System.out.println, is
	  ;; not fontified since it can't be distinguished from the
	  ;; usage of a capitalized variable, e.g. Foo.out.println.

	  (list (concat java-font-lock-class-name-regexp
			"\\s *\\(\\[\\s *\\]\\s *\\)*"
			"\\(\\<\\|$\\|)\\s *\\([\(\"]\\|\\<\\)\\)")
		'(1 (save-match-data
		      (save-excursion
			(goto-char
			 (match-beginning 3))
			(if (not (looking-at "\\<instanceof\\>"))
			    'font-lock-type-face))))
		(list (concat "\\=" java-font-lock-identifier-regexp "\\.")
		      '(progn
			 (goto-char (match-beginning 0))
			 (while (or (= (preceding-char) ?.)
				    (= (char-syntax (preceding-char)) ?w))
			   (backward-char)))
		      '(goto-char (match-end 0))
		      '(1 font-lock-reference-face)
		      '(0 nil))		; Workaround for bug in XEmacs.
		'(font-lock-match-java-declarations
		  (goto-char (match-end 1))
		  (goto-char (match-end 0))
		  (1 font-lock-variable-name-face))))))

  ;; Modifier keywords and Java doc tags
  (setq java-font-lock-keywords-3
	(append

	 '(
	   ;; Feature scoping:
	   ;; These must come first or the Modifiers from keywords-1 will
	   ;; catch them.  We don't want to use override fontification here
	   ;; because then these terms will be fontified within comments.
	   ("\\<private\\>"   0 font-lock-string-face)
	   ("\\<protected\\>" 0 font-lock-preprocessor-face)
	   ("\\<public\\>"    0 font-lock-reference-face))

	 java-font-lock-keywords-2

	 (list

	  ;; Java doc tags
	  '("@\\(author\\|exception\\|param\\|return\\|see\\|version\\)\\s "
	    0 font-lock-keyword-face t)

	  ;; Doc tag - Parameter identifiers
	  (list (concat "@param\\s +" java-font-lock-identifier-regexp)
		1 'font-lock-variable-name-face t)

	  ;; Doc tag - Exception types
	  (list (concat "@exception\\ s*"
			java-font-lock-identifier-regexp)
		'(1 (if (= (char-after (match-end 0)) ?.)
			font-lock-reference-face font-lock-type-face) t)
		(list (concat "\\=\\." java-font-lock-identifier-regexp)
		      '(goto-char (match-end 0)) nil
		      '(1 (if (= (char-after (match-end 0)) ?.)
			      'font-lock-reference-face 'font-lock-type-face) t)))

	  ;; Doc tag - Cross-references, usually to methods 
	  '("@see\\s +\\(\\S *[^][ \t\n\r\f(){},.;:]\\)"
	    1 font-lock-function-name-face t)

	  )))
  )

(defvar java-font-lock-keywords java-font-lock-keywords-1
  "Additional expressions to highlight in Java mode.")

;; Match and move over any declaration/definition item after
;; point.  Does not match items which look like a type declaration
;; (primitive types and class names, i.e. capitalized words.)
;; Should the variable name be followed by a comma, we reposition
;; the cursor to fontify more identifiers.
(defun font-lock-match-java-declarations (limit)
  "Match and skip over variable definitions."
  (if (looking-at "\\s *\\(\\[\\s *\\]\\s *\\)*")
      (goto-char (match-end 0)))
  (and
   (looking-at java-font-lock-identifier-regexp)
   (save-match-data
     (not (string-match java-font-lock-type-regexp
			(buffer-substring (match-beginning 1)
					  (match-end 1)))))
   (save-match-data
     (save-excursion
       (goto-char (match-beginning 1))
       (not (looking-at
	     (concat java-font-lock-class-name-regexp
		     "\\s *\\(\\[\\s *\\]\\s *\\)*\\<")))))
   (save-match-data
     (condition-case nil
	 (save-restriction
	   (narrow-to-region (point-min) limit)
	   (goto-char (match-end 0))
	   ;; Note: Both `scan-sexps' and the second goto-char can
	   ;; generate an error which is caught by the
	   ;; `condition-case' expression.
	   (while (not (looking-at "\\s *\\(\\(,\\)\\|;\\|$\\)"))
	     (goto-char (or (scan-sexps (point) 1) (point-max))))
	   (goto-char (match-end 2)))	; non-nil
       (error t)))))


(defvar tex-font-lock-keywords
;  ;; Regexps updated with help from Ulrik Dickow <dickow@nbi.dk>.
;  '(("\\\\\\(begin\\|end\\|newcommand\\){\\([a-zA-Z0-9\\*]+\\)}"
;     2 font-lock-function-name-face)
;    ("\\\\\\(cite\\|label\\|pageref\\|ref\\){\\([^} \t\n]+\\)}"
;     2 font-lock-reference-face)
;    ;; It seems a bit dubious to use `bold' and `italic' faces since we might
;    ;; not be able to display those fonts.
;    ("{\\\\bf\\([^}]+\\)}" 1 'bold keep)
;    ("{\\\\\\(em\\|it\\|sl\\)\\([^}]+\\)}" 2 'italic keep)
;    ("\\\\\\([a-zA-Z@]+\\|.\\)" . font-lock-keyword-face)
;    ("^[ \t\n]*\\\\def[\\\\@]\\(\\w+\\)" 1 font-lock-function-name-face keep))
  ;; Rewritten and extended for LaTeX2e by Ulrik Dickow <dickow@nbi.dk>.
  '(("\\\\\\(begin\\|end\\|newcommand\\){\\([a-zA-Z0-9\\*]+\\)}"
     2 font-lock-function-name-face)
    ("\\\\\\(cite\\|label\\|pageref\\|ref\\){\\([^} \t\n]+\\)}"
     2 font-lock-reference-face)
    ("^[ \t]*\\\\def\\\\\\(\\(\\w\\|@\\)+\\)" 1 font-lock-function-name-face)
    "\\\\\\([a-zA-Z@]+\\|.\\)"
    ;; It seems a bit dubious to use `bold' and `italic' faces since we might
    ;; not be able to display those fonts.
    ;; LaTeX2e: \emph{This is emphasized}.
    ("\\\\emph{\\([^}]+\\)}" 1 'italic keep)
    ;; LaTeX2e: \textbf{This is bold}, \textit{...}, \textsl{...}
    ("\\\\text\\(\\(bf\\)\\|it\\|sl\\){\\([^}]+\\)}"
     3 (if (match-beginning 2) 'bold 'italic) keep)
    ;; Old-style bf/em/it/sl. Stop at `\\' and un-escaped `&', for good tables.
    ("\\\\\\(\\(bf\\)\\|em\\|it\\|sl\\)\\>\\(\\([^}&\\]\\|\\\\[^\\]\\)+\\)"
     3 (if (match-beginning 2) 'bold 'italic) keep))
  "Default expressions to highlight in TeX modes.")

;; The previous version, before replacing it with the FSF version.
;(defconst tex-font-lock-keywords (purecopy
;  (list
;   ;; Lionel Mallet: Thu Oct 14 09:41:38 1993
;   ;; I've added an exit condition to the regexp below, and the other
;   ;; regexps for the second part.
;   ;; What would be useful here is something like:
;   ;; ("\\(\\\\\\w+\\)\\({\\(\\w+\\)}\\)+" 1 font-lock-keyword-face t 3
;   ;;  font-lock-function-name-face t)
;   '("\\(\\\\\\w+\\)\\W" 1 font-lock-keyword-face t)
;   '("\\(\\\\\\w+\\){\\([^}\n]+\\)}" 2 font-lock-function-name-face t)
;   '("\\(\\\\\\w+\\){\\(\\w+\\)}{\\(\\w+\\)}" 3
;     font-lock-function-name-face t)
;   '("\\(\\\\\\w+\\){\\(\\w+\\)}{\\(\\w+\\)}{\\(\\w+\\)}" 4
;     font-lock-function-name-face t)
;   '("{\\\\\\(em\\|tt\\)\\([^}]+\\)}" 2 font-lock-comment-face t)
;   '("{\\\\bf\\([^}]+\\)}" 1 font-lock-keyword-face t)
;   '("^[ \t\n]*\\\\def[\\\\@]\\(\\w+\\)\\W" 1 font-lock-function-name-face t)
;   ;; Lionel Mallet: Thu Oct 14 09:40:10 1993
;   ;; the regexp below is useless as it is now covered by the first 2 regexps
;   ;;   '("\\\\\\(begin\\|end\\){\\([a-zA-Z0-9\\*]+\\)}"
;   ;;     2 font-lock-function-name-face t)
;   '("[^\\\\]\\$\\([^$]*\\)\\$" 1 font-lock-string-face t)
;;   '("\\$\\([^$]*\\)\\$" 1 font-lock-string-face t)
;   ))
;  "Additional expressions to highlight in TeX mode.")

(defconst ksh-font-lock-keywords (purecopy
  (list
   '("\\(^\\|[^\$\\\]\\)#.*" . font-lock-comment-face)
   '("\\<\\(if\\|then\\|else\\|elif\\|fi\\|case\\|esac\\|for\\|do\\|done\\|foreach\\|in\\|end\\|select\\|while\\|repeat\\|time\\|function\\|until\\|exec\\|command\\|coproc\\|noglob\\|nohup\\|nocorrect\\|source\\|autoload\\|alias\\|unalias\\|export\\|set\\|echo\\|eval\\|cd\\|log\\|compctl\\)\\>" . font-lock-keyword-face)
   '("\\<\\[\\[.*\\]\\]\\>" . font-lock-type-face)
   '("\$\(.*\)" . font-lock-type-face)
   ))
  "Additional expressions to highlight in ksh-mode.")

(defconst sh-font-lock-keywords (purecopy
  (list
   '("\\(^\\|[^\$\\\]\\)#.*" . font-lock-comment-face)
   '("\\<\\(if\\|then\\|else\\|elif\\|fi\\|case\\|esac\\|for\\|do\\|done\\|in\\|while\\|exec\\|export\\|set\\|echo\\|eval\\|cd\\)\\>" . font-lock-keyword-face)
   '("\\[.*\\]" . font-lock-type-face)
   '("`.*`" . font-lock-type-face)
   ))
  "Additional expressions to highlight in sh-mode.")

(defconst python-font-lock-keywords
  (purecopy
   (list
    (cons (concat "\\b\\("
                  (mapconcat 'identity
                             '("access"     "del"        "from"
                               "lambda"     "return"     "and"
                               "elif"       "global"     "not"
                               "try:"       "break "     "else:"
                               "if"         "or"         "while"
                               "except"     "except:"    "import"
                               "pass"       "continue"   "finally:"
                               "in"         "print"      "for"
                               "is"         "raise")
                             "\\|")
                  "\\)[ \n\t(]")
          1)
    '("\\bclass[ \t]+\\([a-zA-Z_]+[a-zA-Z0-9_]*\\)"
      1 font-lock-type-face)
    '("\\bdef[ \t]+\\([a-zA-Z_]+[a-zA-Z0-9_]*\\)"
      1 font-lock-function-name-face)
    ))
  "Additional expressions to highlight in Python mode.")



;; Install ourselves:

(add-hook 'find-file-hooks 'font-lock-set-defaults t)

(make-face 'font-lock-comment-face "Face to use for comments.")
(make-face 'font-lock-doc-string-face "Face to use for documentation strings.")
(make-face 'font-lock-string-face "Face to use for strings.")
(make-face 'font-lock-keyword-face "Face to use for keywords.")
(make-face 'font-lock-function-name-face "Face to use for function names.")
(make-face 'font-lock-variable-name-face "Face to use for variable names.")
(make-face 'font-lock-type-face "Face to use for type names.")
(make-face 'font-lock-reference-face "Face to use for reference names.")
(make-face 'font-lock-preprocessor-face
	   "Face to use for preprocessor commands.")

;; Backwards compatibility?

(if (eq t font-lock-use-colors)
    (setq font-lock-use-colors '(color)))

(if (eq t font-lock-use-fonts)
    (setq font-lock-use-fonts '(or (mono) (grayscale))))

(font-lock-apply-defaults 'font-lock-add-fonts font-lock-use-fonts)
(font-lock-apply-defaults 'font-lock-add-colors font-lock-use-colors)

;;;###autoload
(add-minor-mode 'font-lock-mode " Font")

;; Provide ourselves:

(provide 'font-lock)

;;; font-lock.el ends here

From xemacs-beta-request@cs.uiuc.edu  Sat Nov  9 23:30:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA00802 for xemacs-beta-people; Sat, 9 Nov 1996 23:30:16 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA00799 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 9 Nov 1996 23:30:15 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id XAA09020 for <xemacs-beta@cs.uiuc.edu>; Sat, 9 Nov 1996 23:30:14 -0600 (CST)
Received: (qmail 17495 invoked by uid 501); 10 Nov 1996 05:32:39 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: New java font lock support for consideration in XEmacs 19.15.
References: <199611100459.UAA00219@infodock.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Bob Weiner's message of Sat, 9 Nov 1996 20:59:22 -0800
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 09 Nov 1996 21:32:38 -0800
Message-ID: <m2vibecy6h.fsf@deanna.miranova.com>
Lines: 54
X-Mailer: Red Gnus v0.57/XEmacs 19.15

> The only change is a complete revamp of the Java support using 
> code posted by Anders Lindgren and further modified by me.

 ...

> Try it out and send feedback to me.  Let me know if a decision is
> made to use it for the next release.

A couple of comments.
The (require 'fontl-hooks), is missing a provide in fontl-hooks.el.

You also changed calls to extent-object with extent-buffer in a couple
of places.  

  ** extent-buffer is an obsolete function; use extent-object instead.


Other than that it looks O.K. to me to go into 19.15.

*** packages/fontl-hooks.el~	Tue Jan 30 20:22:36 1996
--- packages/fontl-hooks.el	Sat Nov  9 21:26:56 1996
***************
*** 18,24 ****
  
  ;; You should have received a copy of the GNU General Public License
  ;; along with XEmacs; see the file COPYING.  If not, write to the Free
! ;; Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
  
  ;;; Synched up with: FSF 19.30. (font-lock.el)
  
--- 18,25 ----
  
  ;; You should have received a copy of the GNU General Public License
  ;; along with XEmacs; see the file COPYING.  If not, write to the Free
! ;; Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
! ;; 02111-1307, USA.
  
  ;;; Synched up with: FSF 19.30. (font-lock.el)
  
***************
*** 81,83 ****
--- 82,87 ----
  		 font-lock-keywords)
  	    (turn-on-font-lock)))))
  
+ (provide 'fontl-hooks)
+ 
+ ;;; fontl-hooks.el ends here

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

From xemacs-beta-request@cs.uiuc.edu  Tue Nov 12 18:07:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA22011 for xemacs-beta-people; Tue, 12 Nov 1996 18:07:47 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA22008 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 12 Nov 1996 18:07:46 -0600 (CST)
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id SAA12396 for <xemacs-beta@cs.uiuc.edu>; Tue, 12 Nov 1996 18:07:45 -0600 (CST)
Received: from sbkifer.cs.sunysb.edu (sbkifer.cs.sunysb.edu [130.245.1.35]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id TAA17633; Tue, 12 Nov 1996 19:14:37 -0500
Message-Id: <199611130014.TAA17633@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@cs.sunysb.edu (Michael Kifer)
To: Marc Paquette <paquette@crim.ca>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: A Toolbar for ediff in XEmacs 
In-reply-to: "Marc Paquette" of Tue, 12 Nov 1996 18:23:26 EST
             <199611122323.SAA01381@atomas.crim.ca> 
Date: Tue, 12 Nov 1996 19:05:28 -0500
Sender: kifer@cs.sunysb.edu



> 
> I really love ediff.  I think that it would be really nice to have a
> toolbar for it.
> 
> So, here it is.

This is what I was afraid of: people will start taking it seriously :-)

I think, though, that almost all of the patch should actually go in a new
file, say ediff-bar.el, `required' from ediff-init.




	--michael  

From xemacs-beta-request@cs.uiuc.edu  Tue Nov 12 17:59:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id RAA21901 for xemacs-beta-people; Tue, 12 Nov 1996 17:59:31 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA21898 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 12 Nov 1996 17:59:30 -0600 (CST)
Received: from atomas.crim.ca (atomas.crim.ca [132.218.7.2]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA12236 for <xemacs-beta@cs.uiuc.edu>; Tue, 12 Nov 1996 17:59:29 -0600 (CST)
Received: (from paquette@localhost) by atomas.crim.ca (8.8.2/8.8.2) id SAA01381; Tue, 12 Nov 1996 18:23:26 -0500 (EST)
Date: Tue, 12 Nov 1996 18:23:26 -0500 (EST)
From: Marc Paquette <paquette@crim.ca>
Message-Id: <199611122323.SAA01381@atomas.crim.ca>
To: kifer@cs.sunysb.edu, xemacs-beta@cs.uiuc.edu
Subject: A Toolbar for ediff in XEmacs


I really love ediff.  I think that it would be really nice to have a
toolbar for it.

So, here it is.

Of course, it is for XEmacs only, but I tried to make it so it does no
harm in GNU Emacs; I didn't tested it in GNU Emacs however.

These modifications to ediff (2.61, from XEmacs 19.14) add a toolbar
to the frame containing the ediff control buffer.  Buttons gives
access to next/previous difference, selecting A or B difference when
merging, copy diff from A to B or from B to A in normal diff sessions,
toggle split, save merge buffer when merging, quit ediff and toggle
help.

All icons have color (.xpm) and black&white (.xbm) versions, although
I haven't tested them on a monochrome display.  All icons are assumed
to be in etc/toolbar (i.e. toolbar-icon-directory).

Also, there is a bug fix for the definition of
`ediff-current-diff-face-Ancestor':
it wasn't returning the symbol 'ediff-current-diff-face-Ancestor.

I'd be glad if this could be included in next version of ediff and in
XEmacs 19.15.

Here is an uuencoded compressed tar file containing the patches to
ediff and the toolbar icons.

To install:

	1) Uudecode this into the top level directory of your XEmacs
	   distribution, i.e. the parent directory of lisp/, etc/, ...
	   and uncompress the .tar.gz file,
	2) Extract the tar file,
	3) Go in directory lisp/ediff,
	4) Apply the patches with "patch <ediff-patches",
	5) Byte recompile this directory,
	6) Re-load modified files, or re-start your emacs.



begin 644 ediff-toolbar.tar.gz
M'XL(`/`\AS(``^Q;!UA3U_O&:HN@8MTH*I%89LA>)I*P,8$0V<L0&6$I0X8@
M*!&U:K456ZFC5JB%HE`1)R@@<3&L"K^*:`79#A01$-F$^\\``B$$:WD0_T_>
MA^?&?.]WOGO.N9?SG?/QR@KU@(4&!FYT=PN&L3Q]O;QT#71#`W4-=<."H!'N
M_G+C`00<CD6C07(@$`B+Q@D^$1CA)Q\()`;%8Y`H#`*)0N(P/`L:AT/*@>#C
M<O<Q$!82ZA8,`LGYNP5[!+F-[N>Q.60BNC/1`'NRO'P#6""Q9\\,]_4,]0$A
M\8JC.?BP?+U]0OD>O`D,]?4`>?CPYE'<R]TW-,2%`=(#12F"X!%P.&3HQ6OX
M5^DVCZ$V?K"1UGX;BW]!(H;9D/P+>K@-Q;_@49#!GHFL<-1`"($-@>?;L'P;
M<L#F);#A^#;T$#]!,($G?G`T'@,7%%R"S6OT4?.#(44&OKL7OU/H01M>8./W
M%B]J/6B#BV;"0SAG(BMRL/7@K`@'XC&L/X)AB/FAA#T3NX]@(&(VL3[")8RE
M_VF.]09L(RI^ZE^5_Y=@25O_@R9D_4<B,!CA^H_$8M`H_OJ/@2-PLO5_(@#3
M!CFNI8&T8<.6<6VQ5Z%_"><Y"_-"_^(?$.;/]`C<&!@<(F@6P@QB!3.#?"-8
M&_D!U00/%R^Z\H$&#0%"#<*/V1^"WP0*\@"!X0+P.#4"[ZO[QC`6_]\\/Y!W
M,&L+1L"`>=_,@MVV\+8+(2!W-X\-WL&!80&>MKQ7V=`MV(@?41A<T!UA<+`4
M"&*."T\@_">>0!`Z0$?C!3\C'`9X?F."!`<)O-`!.HP74D,=Q'DAP(,.TMKS
MV6'\`#'$00H/%4!L_*-@D!\V:FTAAK6'#N.%3L/B0\5XL!@_9-XD\Z)YZX\_
MHO_00;Z_>^+C@TIO/S!OH_1O<-Y&Z9_T\0_C1\Z?9'P`OXWXJ1<[&49@U/P?
M$3&!^1\[D/\1:#A.D/^16%G^GPA,POS/3_+8P?0O^J8][)ML`R#;`$@:GVP#
M(-L`R/#!D)3_Q['T*\"8]5\4>K#^BT(*ZK\(K"S_3PC$R[O22K]C5GW'M>`[
MS#98\/U7K7&2;<,+OG!1-7=LF^<(&S^8IZ":BQCFB?]0&VN@WNPUM&=#K5)L
M@@*TX#+2]G%S-HI-PIQ]?$19P7?28+3U?YR.?@*,>?Y#P$7U7YXC;_U'PF7U
MWPF!M/,?TV#\SGW(L<]]`X7>R7NRFQA^\,CS<?R0,]-'\F!I/%3`0Z7P8##X
MXWEH/P\=G8>*C>#?\`/$4(=_PTN"C)>=[#Y;2,K_XUCZ%6#L_(_L/_^A,'"L
MX/R'E/W]=V(PB?*_-R_G3_;:[L3PLAV`;`?PF?&R'<#GB9'YWY#_1[]Q+0+_
M&_TO"HV3Z7\G$,-KO(//?K0BL,A!6B58Y/5QY6"OP3JIR":LG:+$R\%#K4-M
M2-3(UF+Z7\%=\.*E35&-5J3_%=U%I/\=8D,/:2L()K#B(2-&@Y(PZ@_7_XI:
MHR781/I?''Y81,$PT'BQ<K!@(!YB6E^T!)M`_\L7-(_0_PKJT4.L7B,]A1=!
MR1HUNDU6#OYTD+K^3[3^!X&"8^%8@?Y'5O^=&$C5_PR^"C+][X`\9:CX11(/
M%CA)Y24*@$;P$N4__?$%%DE'0'%MCK3VDN0_8OT;(?\9J>Z1P`\=_PCYC_C\
M29/W_'?YSX``9C3YCR1>3!_4[R!9_@/6%OR(]V^8_$>2O`<Z!M\_;R+UCF3Y
MC[9D><[@O$EI/W3LH\E_QN*'XH..B+(4/NDP:OZ?4/TO3J3_Q0GUORB9_F="
M,`GS_V36_\HV`,/[+]L`R#8`X)'CE\S+-@"3#Y+R_R?5_V($]5\$#BW+_Q,!
M\?*NM-+OF%7?R:;_%2IF1]@&:[3B*EPQ':T$&WZ$!G>P$BI1K2LIHI<$&TM4
M\!UIE=):TEV$-H1,_RO#V!AM_?\D^A^^_A<KU/\B9.O_A&",\]]X'OUD$N`/
MXT?(5_Z]`*;?2QH_NL!EW`0X8]X?*HT'_T=>6ORQ^B?^`";5^S$9>9G^YS.%
MI/P_\?I?]*#^%X$6ZG^1"%G^GPA,KOPODP`+(-L!R'8`GQLOVP%\EAB9_WT]
M`@-"H+RD"/6.')][C)'_,0BL4/^+A<,Q@O\+C.!]H&3Y?R*@NG_Z]#6*$<@O
MIHH]?;E&1DU@(G[AR];>!3Z=NY-=SRD8I[R]=:_B]=D'C94^WI=PITI2U*:5
M^:#\XY++[4]QRYO.W5BOXF%(-2S+S?1/SDG@GEN6GL#M?)*TGW7XQ+;5Y97Q
MVPC9S,2"KO`-/BUZL)E?E%_P)\Y4:T\G:_7]45NG<&>.A3I)'?\+_+ZG^Y/X
ML&E7.>7Y*N49N07'/9=EGC*/YEQT/8G?CW:I3-JLW;'S[I[G[E'^=:^R,Z8]
M?O7N=:2YS;-95QCJFX-/9";^XI?[M)+;0VY/>`/D7KQF5MP#BO9\]X?3D;T$
MOS,INF%:W.NY2;?>@P^&[8JVN+,GU?/R(_#3:25=-JDS4I1"&/FA<TJ_-"1X
M??_'K_:7*9WR+>BL,]<>/50^NP"]Q73&`MLLK9*_'U@V//VYZ$\7-:VR,X]J
MM<-+M4U,YJ:L/K.$2K".L[@Z^\^]O]O\5>_[VCKZ.$.O.K8U?&%A\T^I=4!W
M?1VY7>.0>V]!S4K0QM[9>C/K`,0S^<=][5T:Y5R#)?F,/USBC"+BKS3/>%[-
M#@&XR*N,BH"WCAG9=\.RKJZ#J98LP'3&;[M:TGV(NGY&+0?0]S^L[K/04R.C
M#G'G?,?%WN#<+/JKJBV$'K]#))IR[3,'=L5M>E=H35%\P9U`A^/E/<?S'I>7
MEYZ*:/7V.P\OVF>C'#[SYD:E'<5>Q3>]+ZI-\;OUA`Z>4N#[XIAZS%>PN2`%
M&`@1LV]1K:V"19>6=LW2K^<J!]U.\NXQO[QYQH_OP`JPN93V'W<0%:&7CB]/
M+T^[5*5)3FV^$.''/;B*')AY^)U=XR-K4@B76!;8!)#[\/+A465]0,NFE8!J
M,-`D[WJ[E].T$V`G]B40NLX%`VT_ZS!N3)-3EX-/V:X@5PCJ`_1/5E74<E:>
MKN5,*VGCJ-*N`[%S`<RWT<3$W)U?;=7SOY[I\'9-^J&IN:[+[C<^TEU"\-MX
MX_>KN7'!67]"G[>\L(`<.XVI=Y3[91LZK.>RTW[+$J\>EUW;FR@'@(9-^>PW
M/:[+@/OS'K20=W0VU3=P[L;>2NL)ZLB*E8^DA[/"E^8XOWNS9\:&9+U-!;O`
MN\%3H9#7W76G;UL1#\0M>7]C%4B]?B=G=U^8W%+[S;`*0%7S?78B4/"\.]8B
MYZ`>T%;=U72\%7"X6DQN^P=Z3V[]5W(HN:-3<I``\!VIOB="L9<YU_@ZL$RW
MSZ5M9P8HZ,3U^0IG;1H7*16EXGW3=-Q/&<^2W^]LM8>"RKP)L,*/I9Z\3S!U
M:64W9#_L91HLFK[E&$*MA=U0]C4M+?PE\.CJU!_.O@!,;8[=N*M\R^:;I?>T
M?])<5Z6?Z-%;M;8`8+7X&!S'V$0N..9<`U`)T^43_M=)5@<*-%SKO]W8NZ>S
M2:&9G1HPI9=I29]S!T;(^:U0>9.WQM+%;S(?L&T##FAQ#O0EQLT.JY[534_L
MF]4=6Q:M'EG<^HK\JUR)*?!WC2+YM,5OIP`\M&>3Q7O59=?DPZI9V:5OENEQ
M"TI+0E(WHYXM:J@T!5[=C(+-N?%M0@:@^@.@4MI;=;H:<*\&<NP`]E^]S*-R
MUX7//B*L#_#LY(1"];LX<SH!1"TG^7^!W@\['G9ROO3(./FG^R7M&0XU?_N%
MEGPEG[EOE]^3+,+^8Z9'M'N9E`V%:=GF)UMC@!D/`GM53P!&71RW.\"W+<#\
M1VPC*'?[%SDJE;^EO]>X'I=B<:4D9K;^]5<Y9&1-$6K3(>[9=RE,N:^W$H)X
M/0H"R%``=[J3$[WV'7MJ,Q!8#$S]4ME+#CYU^V*YPDU<H+W]M=_/\15I#G<;
MFT]6%W4&:MYF&RT!9IV;W<?>U9G^S^RRVNO62VQ6.U*O:,RYHK3EPNS-%Z:P
MSD:6['CRE_NO,4FZ10[3'\81ZY4K[`]=X.3AS]`+E]U40SVZB*UE)&WV]%^X
M&)QQ\D62PLV8[NKG#XXR\Y)0L6P[J^3D^26O(.^NG'M;^?4BTKM.#JFV,_:\
M:DN;JH+:S7QV[8U.<G<W_<W"6VE3;\5/6Y^E>;LR=WYUQ^P_OM-*=GC999?Q
M-*GU/K++OW/!RI^.+*QEQ1!I2G>VM#CHO-U<_5(^/ZH">*H77M':&Y+4$[N=
MJ%;9PFTJXSS=H=8&+ZF#/IZAX/?TA-Z]Y5=L/74.9*,>F]QD!QPSO-?TSF.Y
M=P"8$\H.]X)PB#MI2;`B8/9RQ;?MP"XRD+=<:08PNX&#:P`:-)LMLLKVR)W9
M!/RLT,RM[KG1L;.)?3?XQ%FEPMZ*/*`GKCVOCC,OX010';7B#;"X!"@)V)1!
MXZAVM*2?:SY567'G:,[KQ'A"\X&7!]>4&2:6[[X9G$EZZ3D=69O<^R9)\Q9W
MRYQ?7U;G)Z;&_T"L,/,/^R=<*1*PV5K4\_9N'CT!Z$L\$3MS29=?QV'Z(B:9
MN77#>5QC8-/+V"IH[C^Z[<WQ[5NOZ>4$=C4'M?=M;GG>0([N.L(MOA^<30M\
MTW6(V^AP'%2UOW';LX($P'WG]G[,U`#NYFFSNZIN[C&`Q-_VNU^*3E6[D/_3
M!<<T!5WSF#3MJ48N`39N]OLI)ZS:S92<NQ^XE#9"K(JAD/N-D!3(DML_O5[_
M761\W@6T72+NXNM]:TSW[W"T,S77W?O4SWW67]G[G%)_/<QR2F,F=6\(:U=O
M;%)BK.VYF*ZOO'":$,\*B]F/Y=E]*K^T`[6UO=[DQ[NG>!6S-8+Z6O\I9N^)
M>F\>J==]HLGT#;5SGGOZG>>_J.RJJ#W8:17(7`T*R+,R-+$`U>QU7T/]K7J^
M@=?3@^S*[2IM-M5Z00K+ER;<;:Y^GI!XH$<UNX>4W7-+*6W12I6,RZV_%9`W
M-_$>[$OV\]9I-XL`Q9K>],3I5>4N[W>^B*^R3J]ZZ;*C(BKJB4[0A4A56'G7
MXL)7]1FEZ*_;8R]L2YWEG])P+ZW^-"(DP'\QS^72RT7N]W.=VJV7S<8Q4Q-S
M6AF1%[>6>F5EEM8M8QZ.^RXJZH<TE;]_WW624M#ZR)MD[:_<C-($NS^X?$E7
MYUARF%M@4\KW0,./^>Q[15NU\P%-U:XG7?3HZ77`W@;.[R[?MY6I4OMH\;4J
MW1UJ0(\6(RU`M=XNH^#\VF,&1^_/O+SFVP;4#+QY[L&D194L3I'Z_+/RE6Z<
MQ+[@>*^>QKW@&H?CJBT)V!Y62EE3^G7N779GWPV?2[O[3N:%UZLJ%3NVQ[AV
MKN<F/HFN?LC<#I"?M<02.X%S9<!^A%N?ZCS>NG$7N.A!4G_*O:B;O3Q![F'4
M=K<OY.;)"98Z3U!'INOM\O?GB-O#8X&Y<^<DY+/O3.L%K.HX)F2??+;Y-5*?
MRPZ-MB+5$P>2LCH>K]RE&J?YS"L=RO0)38FT/%FU5:4XSJ>R:5[&SPC;6LZ;
M"&-Z-)>`2CZ,>%#_HFW.8<-KW.2\VR4Y1Z97=K4^*@#:8@K88&!/Q`)@3[6"
M"I"H\#T`/@OL"T`LG*KYXDB>(OR)Q_TCRKN>;-7%[POQ+9ASRW&?XYZ"4L[Y
M.71WU/+,ZCSNXC-YAY0;[=GS-[24!?FOR2M-U8QPSY\7$EV9I=N1;A[CZ@V4
MU`0=G3=].`KO%`)3SK^.`^0*/_6&5X9AD'[^@X:%C<,]QCC_X9`(T?D/A1.<
M_S`86?UW0N#.\O8-`/$?S\BGKTC3<+305%NIKTT":ZJMM\<8$["K3'6P)D9$
M>R<;'3.$P6I],`U'^H:^QD8?Z\2$K?L&:^1H0%U%LEAOLE*11B6Y@&UT':CF
M-!V:@ZF!&0U,,K-U-C9<H4M9`[&W1U-H-"R%Z4!T<0&OP*^@&<&-*6KVYLX.
M1`)AG2+-C&F_5H/@2F:2C591-&DF)A0[!DR73C+CQ;"T<S6R8IHX$.R-K&#(
M=9#U-$MK(LH"HDDGT&'69JZ*-`I)QTAMM3$"I89WU3(R)$`@=L9XFBE)#XYT
MHC/HZNH,2WNZ!8FX:H6]`\66YDIWT26M01GJZ'Y#)_%::^"I#$>8CH$KQI!D
M[V#D3+2T7Z%+IJRSI#@C[6#&8**!GI;9*FLS(LG(U)3JZJ#KPG"U8=J;\2Z*
M-+HYE(%8QW31U'`R7D?%K#)QU'<F4*TI.C@TA;E:S94"@=EJ.JVP,]!P@ECC
M2=15.CBL)F/M2ENF"8HW:_J6%+"9KIZ5&1QA!\>H04T)$,HJ*RP-;>:X@KG2
MUI)JS;"CP?'F!FA;$AJO\PT&Z:RM!T/8&KN8*](<M'!0JIV%H;8>U<+.4I.J
MQT!3$6@TDHJRME`W7N.,IB`@EG!7<T-M+92UI0'%V43+U=3.EN&HR;11I.E9
M$377:6E3'9E,9V<HA,DP)*'P=!L-1R1<GPA;"X/!;8R8-AK&*QAD5P;=V,R>
M:;="W6*5'@5CB5:DP1T,29:P]3I.I!7,U4PF`V)NHN>`=?D_]JZ]/U%D:>??
M]5,HJ"@JJ"`HJ'A71"Z""LBE,1FSF]]FDYS$[)SSZ<_;:DR,,2:9R<[LGM>*
M&NFGNKJK*;IHZ>I6F!3GZ"8S50J:BGGI0D9H5`6^2_EB!B\&:D,%7A"2^5*Q
MPT5*K:3#-]/ESM!S2+<L3:>4WQ6JE.1P8MJG<LV&':L`LYPC?9:J&Z*#Z8S'
MAN2.ISH=EV4GGEH0S:91FO2'Z?04IX=U$TTG!V@O198&`"DYZ4;`2.B$=IM!
MN2+:8JL3DFO9HAIM!,F4'@QKQ1YKM;-)BFR)N!(M1R.)8CF=;Y4`-&.VF&H)
MB2:2=_-Y@<O5F@,\)*>D/(_U`2_QE("C?M]-)2U.G60)RE-EF]<+59.AF[8!
M*)7C?0!(8%D1L^),5`=:B\M&6V#HZ<!W,79`N:KOH\#TFT!TISX?T0%@"OC8
MC$2"H!.@0:06M`(=07TP0NKP?'MF0]7S/4MRH?TP`!N9`;#</#"8F-!4FFHO
M'1?0L:RE*JS3:J@MC?#9.K372E$.R?&FV.?3\8;"3^FRU)=2"CNT6]J@P]7&
MTU@MZ'1'HXJ@C)FB3(PFO,-8^<`9=0C@R\.0/.R"@3^V*L`=42,U"FIJ4YT2
M"M`M@$J"K'E.GXR8(EF9%$PL->1<1<>0B=(A60P+R76$B">TM)(BI*DU;49I
M2B':$6FD4:U:4FF@JL7[E6Q0+G2+JBFX`D[FG1X`F"WTR9!,I?0L*8"Q17;5
M#FS1@M,E20!/ST`+BO`OK2'%@-=@Z_E)4FDZU4!RV6$RJI%N!9XQP>:](C%)
M8$A%BV234IN48YI#])MU4<K+#7&4S40LF:.+E63:$1``->AP_;I!B?&0S(`,
MF#HJ#6)>)*;5[0X5;;@LD";U2$9BA2[P.#NP)@KL:.*TW8WHPR9*ZW390/KY
MD(S'#"&+9YH@XV6'P&N[3#W2,0I4M<Z4&`4#^68O$;%!UD?=#G#+759IQ'A2
MQWS"34)KP?P^7\-<=F23T7)+)22]ID?JPY)>+L>KNCGJ>C3?LT35<OR>G24K
MU2#CMZ`UU<QI2&YZHI_L2J3KMT`W0*F<"G)6M@?Z4;TF`M=*J?*0(K,"QH^P
M2C725CQV@%&F-_18V#.5I^(D[6?9J6?'@=]%JKJ;TXJ,(*NNT!1<?BP80I]`
M05%!@1IC@>#"-K=K@19DX?6=7'YAZV.@>BT_Y8U2+=16AY@%^Y.&.N6S_$2@
M/8^R5*W0E/MQJ2AE^\A8J(\8<1221UH1DZU^E),[4Z*GE')BN0_;/\FY#5D9
M*777P@#B)540\2M@1-KJ!$L"BQV"(<6$9&&45D`Q0-2(6NWA8)1T$;I/Z];(
MBI+9-"JJJ*M;9<LHETA/4G&1A5464%&S2!]ZHC+I@I3JFGVR`80VJ@L:J8$)
M-#HM'8O'H:T%1!#/HHFR8`)/Y?N<R%1-;LSJOJF%Y%X5)?RXVQMB'AI7W<P@
M`+Y@49;DU<B)D@KHNDB1L3JN(.6<$MCVH.9-!K586^I*L,UK<A<OBGI$1$RB
MH#7I-JKVXIDQTW)PJ%H#]A>UBM9(&&,I/;':DU:EDY-C]19L00SV:V+016J"
M5+,K>)%UF5;:\D"A$.^(=8J:Y@U=2:&*60]84DU9JN$T_(0_Q``VQK16(R1K
M@Q*P!IA%`@GVPAJC34>H9EO18JK7&V:F?HQ`373*)'&NQ-J@79!EO>6Z(]UG
M3"LDQ_+Y?'O(-TK%J$-EG615B+&X;T\LHHP-NVH%>)I7\4P#8$3+M_R`T%-5
M5S#5B03*4.]&:IS.D,V47$XAC%3N4F8:@RZOA"B$8I!LKIP$O-A&#`+HQ:'=
MY1L$J&">66KHL$\EK$Q&1``!-+>**,X$6%D`7+J*UE2`^@K(^"J8ZDV-2DE<
M74,&9<$O(`(*7;X:"<G+?X(KZUW.(G32J`P%X+1)/F8Y+M6U36!A@SIT3J41
M`!3?C4\HWA4\$%<')-*%/3+TP9V4T>_9UM1-.-U6M,EE^R1?'R1UV7"ZI:"F
M6WW>=?!L3P-C.UHRNE:::_;%:0;6W!MC/,L6*YH]!>.,:ZBJHKL%L@L[LIX]
M(=&(9'-JE:&&%8$<>R[G1$V'`:IM`6'IB9QB2N"UKEIR56KB\J"KE4G8CZI8
M>VIXOE\2/,,=Z\IHK#IDAP+5,=O14:'AC[V0;*>K`IC@:`W>[*W?03H)0&J8
M%P&\JI#Z*#KH#G)]HT*/^@U<'XJXSN"C9(I68*M)^1Z:'<L*/8DQC5&G0@LE
M#&U+TU%;+3CY8<[0K8%1'0WZ>8T;)E/]8J(][0X8/0-O&D-RQB'[C58]WK"2
MQ0)=2J6*S3+7261T2<$9KE]N=PHEJ0![LHX\]AJ\[&AVA2850QH%16AKM6PT
M$BS?5$M/>V"L50"H*YRG@H:E#KND5XT'#$\*>D4#*EDT3!^K@ERJVESVBMVJ
M%W>BDA6=X*I>9;BX154L$;5HQA-()*(,"S$D1VLUJUAOY*/]FA7)14JRGA6\
M*>S7XJ!`6>A80W)6N>NJFD4P0L]R',R!32RICJ9-Y9B>Y66)-7KI,J@H``QS
M3E?P67C'%4FGH)5*=8#[320#>`;D45MT!+H/!'NL("8K.Y,\O!2[/2'EJ7:\
MW!2G*;Z0B:`3V)\[2:]?&\,[;34M51N]-)M1^%RWA)O(R!Y6&@9OE[QVHH(:
M%:'?)UQW/)X.3`,V9=\,R>-JNL+:'-V`932Y$3_B\&B/[F*N5^J2[:0<)P,#
M1S*-D<2,4GFE)'8+==[WQ2;L$$)RJUP"1MIV\0$/\`BP)T*;%&K-)K":DCI-
M\DV2Y;"1Y%,EIQ$'DIE0@8,7)C)?![V07.!Y;%!`2ME2,X.F"HEZ=6`@1CVE
MBD@KYMEMU;4Z,=S"S$X<]("M=SMPF%"L-:U"E8?C$A`7,JK<[E<D57)13X<7
M)1C$>G*"]WOE@CF-N(0Q;DYJ!<<JDI/FA'5JXY@?``.TH`\MNHY/^MI$]5-I
M!O.QX:H_3P$GTR0;?!GP:5D93H4@DW-J\2@21-+K6Z\@`G,GR*H)[]-X+Q4X
M-:Q*@F$B'RW!"KFM*""]G.5X,5AD7!@I'JG:?*TAC(VZ7VGV\]#6/*_<JD=\
M&B=R'4FW!0[+B]76M&Z:&F_8N9ZIN)0LTL,"@0,'JT<IT_&()M%I-S%X[S`E
M^'&T5$)48=(9EBE*3983IMHUQ@,!>$4,$W02U,U:`5A"#8'.O:=UTD"'MV26
MJ(3D=*Z(X@3'#F'',V'(3'O8B$Y83282HL&5RSEMW,"9A("->7\8I;U&>C@U
MK33KQ3DC!L_WL"D7NB[-`8PKQ\>)887IXUB],:QG#$&>3E-"5<U;L6H)]HH6
MBQ2CVE,_$J(WWY!T,ZF3;F10[=-`0Q-!$#%"06A^]>4XW?]GT,O??Q;7O_YZ
M.<_<W5Q>+#XG%.S-^"]F*_Z+6<9_,31U_/WGA]#S&*_M<_]:'-@SGD/Q8,\8
MOW$AL*>0I]7':F>#Y<I5V>6R5/F'&"?Z6>IZ?P5ZE_,=::OEMO9P?ESBC'G:
M(?<S)*Z$?5";[5*>M>.JS=B#$5O+5;QV=YJ@-L#3QLL/PG*/,6GGV<VI8L]W
M.;?Y]DG<Q(7M*_L8%_97T3OZ_^^>"O[6_.]\CMW,_Z9HEEKU_W3AV/__"#HX
M_WO;%#YO'CCSUBSPG07`EI/"\\]6`/G($F#(UP<1Q?SRB(='YQ>W\]/;B[/?
M/W\&.?%\:O'VX1I_9']:0X)??WL5Q]_`W\K_O?B'RN=Q'L=Y^/F3RO\).+J-
MOW'^#]`S'%\OD?*5VX_CF_0MAB<<Y[YR7S?TN-C*!L<Y'">V_O`'CNW\^&:;
M1PY_D?]9^?B^\I_2\5?J_XK^QRGD/YS>\/^?$@KVMO^G-O'?^6R>6?G_X_/_
M'T-_1___%`7&/3OZE@7`]KC_1Q%'WW_T_=^)H]OXT?=OIQ]]_S^!MOW_;_/+
M3U[Y:TV'_7]NN>S+YO??0FZU_P.59X_K?_X0>L7_+TTALYC_\6/#O[<&_DOO
MCIZOZ'\WSOMM_(TXY$T8]"LX\1`*_6J<\PHA#N*'\J]VBCI0_J8*K^OW#OS@
M5E7?C>_`+_,3;\E'_]+R=^FGX\M5/`U1U@;M,.P9]M!H7^)A:H@C3;1>D5?<
MEWB8E+HE&N%7Y.7W);Y#7FZ_O/RWUB__>?)ZHC%2=3MLWEXL%O.K\.E_PM8D
M3!&Y[.SCPB"UE=8WY3O2D8YTI",=Z4A'.M)^^B^DDX?WYOO6QP$ZV;"<O)KK
MI=!=Y'G*R;,LK]1BB9SLP">/&5;H*\4\8KM"-R+W"5U]@>#)<_ZGKR>[[(\'
M)WN*V]9OK]"39SJ<;*=OLIQLG[#':BQ5>%+DF=!U14X>,^Z<\(=\+]MDD_UY
MEL><)R<GN[G^^\2Y\W[#G%[)]6:FUU[?2C_KQZ\C'>E(1SK2D8YTI/^']/+Y
M[V>N_+VF-]?_SJ_W?\[!5(;.KY[_,L?YWS^$#CS__;Q'O]3VX/?-1[^G[YO8
M=;9Y0IQ].9?K]`"MBO@K\1]:_/H!\:LX<;:D;89G.+'$B&<,._@2(0[C!_*?
MOH!?Z+<#?P/^#/YT_/0Y_.GU/R7>*'^'_O;X<9O'?Q)M^__[FR^SQ?SS9X"]
M&?^;SS[&?[%4;NG_"VSVZ/]_!&UB>]?G_F7,[T/Z_CC?!_!OM>?COC1JOF__
MPC-J$RB[E7L9,IO]LB=M>R_&E;#<8TCMT^Z0U,NT=3SKOCH^1+X^UFP5'KL*
M&=[B/-]31W9/VFGZ,81Y2^_<2XEGCR*.>SX>:6___]DCP#?'?U3V<?Q'Y9?[
M/U%,[MC__Q!Z9?RW-H6?-0*<;0Z+V<U([Z-[09T=H)7,_Q6<F$%Z'2=6V(IC
MM@^?/?Z?'<3/9H?QV2OXNOP5O!<_FQ&']=L1]*+\1\%/@G;Q755V\%U5=O"S
MP_G/'EKWE?*?:O&DY]_*?OX*_!C,\X^ARXN[FW7@[T/X[\UL<?;;_%-]W6'_
M3]-Y9K7^!YUC*(:BEO&_="Z;/_K_'T'BU9?YO[GPS>^_DO^>_S$[N\OD2D2.
M)E_8Q6_7U[\3\\O0\B"<.7M_#BY'Y#[$G0_A./XQ^;^,[N=A]6P!30<:#U=@
M.7@;F2N5F%`FDWF_J%_,^9>P<OWG,D8YE^?@BRZNQ>#/:55#JIBFF?#J<%D*
M/&2+8?@M$PJ'$W#X_.=R):S5Y93Y8WYUGX3)/!^>7WT)W\S.+LXOYK<P)91:
M\=Y?/2R:M>3<Q%W_<7^YN#B_G?TQ#R>2D!&*O;A:S&]G9XN+/^>;E/-P8@9E
M)DZ7]T0W86PMY^SZ:G%[?9DYO3\_G]\N>7]9<E]=+^#'_>5E>"_;(]_\7WL9
MPHFS^]O;^=7B,<.Z%N%5GNV8\:>Z;S@24!2LYI/HKQ=77ZZ_9N[FB_N;#&P!
MJ-7UU:;^Z]0UR]V.M%4-(<._,K#E9A#ZN,";R]G%U4;=;ZO36L3G5&=+O^2Z
M30_9Q?W=//,P9GO#,%:G>RU@*U/F9ONTK8SGX3*8W3WRW-W?W%S?+B#OMHKA
M/<+"BT=QK_-<75P^*!9^KMC#A7EQ=;%8*7FW5"F\4>!\/EO<W\ZA62\Q*&J-
MK?";V^M?KY:52\R^?%DWT.G]8G&]2@MC"60Y0+A#UO5WD/'=/'P'K\=;.+`)
MKZ^J\^O;<'O5H3V8>7AMULA:Y4-7Y)J#NUO\YW(>7J.;I/GE_&PQ_Q+^7DOW
M5@*1;#;3N(70_)8@B+4V[U=X%MX8RM<+.(#[D+);)_!=VNXQLU=4"#^H<'=_
MNBQP>;Q5_:VJA!%5/9SUW?YK:6`?\U\/.=[IOYZXV7?ZKRWYW^N_'D3](D.S
M6OJO7"Z<+7%4D:.SK_LOFD[3I2?_!0\+],9_C7Z[N`O#%[S&_OR_]HZNN6W<
M^.S^"D0OEAK19RF.+2?39B0GN68FN:077Z\W?2DD0A+/),&0E&7UUW=W\4&0
MHB0ZD>VT9\Z=$Q/`+G:Q7U@LF,"'Y>49RI*(P";P=,52$09B2@H$*PZ[>`F_
M\(GP)CSA8Q`2'Z88\E4&L/(YS[7D^5)D\6'.KF*Y9!P\5J[65%N[:_OMR(J!
M(?/2^O.[*<N[&M0R`">V*(DXSB:?"RO?I$9',):HF2,)8'5`YH'1,@Y7#"S,
M2BX`)_*6:8N7L4L%+\.A%\K?A:LN^^<;ZH8T=$%W<H;6E=XIM53^?9@*MA0L
M7<1Q$,\4WY1R,YXD83#AI/PP5?C)V>7E;Z^T2021SHSO\,5U`-S,5XEP[:%J
M5**0U"[J:;][.E"+BJJB!@!C`!BN3]9Q7FLXK!V)Z(M18`=S!Y0RF:#9+L;<
M-!F4YRM&`V'H$Y@ZS5^QYS4=*V3L\V\?1A_?,[4FW+\6:1YD(&>AG/"0@2`$
M*$9'9M@GD0(1$3)3R4D75QI6\T9,%CG`^W?$KX1GQNGPQ"-HA\!IDO#3L^Z@
M9R3\^^`-_%?RAK4>&"7@B7'5953T7KG#PE5J`!VG$?]5'PE\D;%U1JL,U!E#
M`:=?=3IE-72GL35B.'AY`:L:Y*`K^/-5@:`V%CDX>/D:E(IT%ZT)6_(X5P,?
M7G#JE.QLT(-8WXG]S\Y/NKW>\6DA7%-PZ\;#7_,P\#U*=R(7LU4TAHBZB`-N
M=)LZ<O/5FA3KZD":B9Q$M08(!8`Q#VV?CH*R9EH-XV-QD],_]Z1BMTJX967(
MQHEF'/%+Q1T>.*+<]@"9N$E`-KQI`(R,:=M2!GJ31!W6"N*I).QXTM`J_3Z.
M5/1R<&",.LW0\X,4C+9,5V;#T?H)^C.D1X!Y!H9@-Q;$9IBVR)MH3U)02KG(
M"OKOF7R<@$N^^KTY^9\T`5_/@N'=THYD@/K]\HGBU3H^J.D,]2=F6^47AA,;
MV+`;\>N/O_[T4*C??1Z.WK]YO1.]^KC>UZ(WHO"9(G`2!#:\I1",O@\A&%57
M8G1O0G!GJ)L)P:@J!+=$7R<$HUM;@EQ^+Y*@Y[*FF/;M_1B&.Y]$4Q-!*-?L
MQ.TGLA]C`7B_$[>AY[*FN_;M_=B..Y]$4RM"*-=,R>TGL@][4OJ`['<A+36?
MM&]M;+L/R;GG"363HIH/_^YA4D:B+@D"(P@LDKY@8Y$O!6S%LL#'[:"'?S+<
M6\J8-JJY3#PY]7@L8<>V2^@R?BT>6MC\(+O"!%BQHJ4W=RM8=XY\EQ!9=%9T
MOFX"^S!!7Q9W;7JV[.W$C:O4Y5?-=WAO8(A.=68BRV"/OX-F^F3C`]!L;HVU
MS%^;T_AY+I>:1AJZG<!43%.1S1^"QJ(RLE7\TIS.G]7,31)<I<99FU]Q!ET%
M9FXZNXD/X@>W<'H65KB=W^_6NMTIXEV632.S=NUKD#NB@&7U^AC=3=^D8H:)
MO/&*3624+'(\/:"^V"<KB8?-SZ[ELQQXFT^&0Y'CF;?***9\[$42#U+HB%;/
M6+?6P>W5'U"7THI[GD85YHXI3&2RTKNDO:!WX17GV-N0J]![?\@UO&;(::87
M>Z;\XC:4[Q'YJ"%R-T#="W87X';4&'H:E*W/^`L>9$0BG0GGB+UN.F!\WN+Q
M$_X#!6.FII+)]3-,==@Y@[EC]3.U3^5DD4&O%$U-N#K:2EZNJ@9@,B!$JE6?
M<PR+EHMRRX5JT>5'YIC?,T4J968!&Z9>`(HJ\YK*(^H801##@2/((31M+G],
M80-UI$A>W("%Q*#'6E#@U8]`'=(>BR5#(T[^.I>,%L"%!X%B+KM,E^,@MERZ
M@%2OPXP-F;75M/,P4(\*/YH)4^S$B$N.BU7<QMFT4\$KCN7`"$-E8H2#O6`M
MW:EM1Q5^@[7U(I0APD-+J.J6RF-C&3<8CM/6(-0:HO_[`!$"RQ9T;GT(/V&.
M[IQ?@$A&(@]@`=D2C\YP"?R`AW*F`8SE#=8*@*3Y73S[QA*W18)P*M5C'-</
MJPHD+)`>W)[(1>C#9I!Q0#A3=2J(XNT_?OU@3LXC'H/L0)!$,EFW)`?M91KD
M@D@F`3D$W-,@C1Q954+LZ=J?0I`W*3;N(O9B2PC03A.&(?`^31?"VXY11]36
M>/VL@]%-]NH6<[!Q[:X)8(13X/_:X.C;)TQQLDR]*S"U'L5W!)H=4@,(9-2$
M%`A5A(]'N'8AZ;#\KZ::4E=/.I0=NQ&JZ<<7X/4TQ#"(`E(6:/?,;/&05T5H
M,HO9X9`="EL;L(ZDHX87Q*X/'XO9YN'EFL2US4FC#<EA^U_;=C0'M>RD!D7\
M2[`5EW-ABWW`C&#]#7(JPHM+/`RQ+(D$&LO1P/I0L53'CB;C]4*)1X(WE^(9
MF#2\]B2.F.[5WKJH"M8WB"G5PU7X4#V+KG*B)@9WV-+Z4:(+1(.9K)\)UV-T
M3_ZKV"JAMHMIZ%]S)%*CB\LG\/6HAIOP.)$EM1HM1,?C_2['FM5.$DBS>%B/
M:+05T>@K$(TV4>2>EFTF:Z2P.16X!4J-\P(ZETA#E[D!;?GP93.1P]NC'2':
M#6QUTZI5I-BVE:5UH7`]FDIJI\888+,KC,U2*HAK#5G=^80M@*WKI-HUXF_/
M8]=.JI2QK-*/C>J]_J/U=XPH*)82Y10A<1?<6PV3W01A%0.VN>PU5,YEFO\0
M2C!C*D%'X(M";K3Y"I"N*M,+@:92NS1;M6A+UK`\2M5NU]56G?<'W?-G)]42
MQCDRETJ?S`4'QTU1@S<$8<X@_E4E>3(%=X2OE:1G$/;)R%3H>TE#,$0":1?A
M_M,3[4<WCKYH`-B4=[7>(DRL6IT'LWF(=VMIKS+'0G5=5NWH::!";Z[!6(6B
M*B]6<<TV@M&XJ4RMUS\9='O]Y\^K19#_5]Q%,$VZW?L2-*Y5A\`AO%VMNA[1
ML%:]Z-WTKI4#OZ96_?0VM>H:5,U=J_,MM>IGS[HG9P.G6AU?G/>M(%L#KLRZ
M-D>F/%+W,([*WK'0ER_(6A4@EJ@-A26S&X7"VI4+6&G[:6^C4(;AEPS%:)+;
MK:\T4F&VQ'IGBZ+W_N/%\/T;*BS'F-8"6<KT"BOP$Y%BL7IL*M")L2]PISTG
M%RMQZVU&55,U1Q;<)<6(<AR*R.RR59$_%>CS>%5$D&.90UA=OOV!$\(T%.S4
MY;5(4V`21;H$!5Q=EWP>N"7JA0%(*CR>),(!P*<Y\F*1LDDH>*R2!)HOZH6'
M>:(CQMY1.7"*68$E7UD`0*LO62M99/,6X6LE,FF934'&7C&0"'65DS&]:<)T
M098(=>6N0AKL$(,L7\MOE;VCO2>V#9)W'60!5A`GFV#FG4Z3*7GZ*PL;H#P[
M,=,Q7IAD<R8A\J!O-[0IN^)%=+_-)+&N@H1:,ZQW7_+4[!67\R`76:+*A77O
M6@7L]\_.NOW^H%^H8+]_WNOVGQV?&R5T7+Y;([X6&C"5582=[36R"[5$9V/(
MM_A`,69R*$WC-CXU^;N_882EN&8/A(N%=]75F<:ZSJIN;JB\;A@Z?S#M+NEM
MC;ZB3CZ\>IK\S;<KI<K*N9JD%I+20#J-.N&P`5E@?D$O>5&=;P9IF:4(W]SE
MZS1W^#CB=@Y?CVCH\(O>31V^`_];';X&5;F<U@<P6QS^X/B\.^B=%-:&7O2M
MK:FJKM):O([BPXL)QR76Z\#:)AK09RFQ7Q@[>TD"S0H*=.[DF-17;W2FB6)"
M!0#?YCR\PGMQ>(FMT%X%"%D`(L.P]@,48K*((`A5][Y>H(<,U%T7,-%!Q$,-
M4"69P*,J&$3686;G@JJE=[D<O3"=Z&==,C$\9K!1"_X#Q@?`&8NHX+SS!:;&
M*#&_I%3[EX5(5R4ZS<4Y-1$).S8^F3-[MQ0=-^@R]WWL%:G+;^]@.C[>Y8,P
MU\`TX59F`F6@G1D0Q@@<X>U"X#0@A9CAG;[#I[\^%"^B,5J<J?F6#UDOV(;"
MQ!48/"CP?U]D&)F#A7?)F(D\@RTY+"+0$\H,LWLR$H971ZZ'*.5P5;*N<`^*
M#S85W^PB]7'AGRZ5:83_>_UBI8BI_8&A+.3I3`=-)%ISCL):`)&3R2()@(:^
M&4$`,+M0C`HY&#6%`:2J&)QB".$AF]`L@@_,)-U*%)E(P:DHJ3TY-I!1`*9H
M_E4HP/["3OHGNM&<A;4G(@C1[[5_P-:C8W#C('!>$,/:P8;(<(TV.Z46=J@W
MAIU.86OQ;E:*U[%IM<Q)1.G8LWI57/EDXV+UR:3CA7V1!;.85!]5RQR"J<\&
ML.(X0)L#Z&-BK5ZGW@@]?]8=/#\WN0C-VYZ2L1#SND9S,!&$+VS`A??@0[JP
MUNX]I4,N8(A^401H]N_\1E\E9&RJYT2=U99XJEG[U%Z[PU2./E$EJ%XHXED^
M[["^AF)TQ,,+[Q'X)O"^;?3J&!!1'1!CYD10D97(#'WE2F?&\400@AZ\+%\P
MLSR(;A6R0Z>9#/7IH#LX>^X:Z@=E&G1KRKDGS-#6WF(8.@_*XEHY/>L#RP<5
M.4754HC\(S<VWYB.>U(33V'RLG9C8@-S=FP8<HMMS>[1H9CF58/<<*@R?KO'
MDK0.0%K/3RO2NF_6K:&O[B]WL;X:QQ:0<C.:-@=_E*5[Z,\F/3Z/S^/S^#P^
5C\_C\_@\/H_/_^3S7\D3.3L`&`$`
`
end



From xemacs-beta-request@cs.uiuc.edu  Tue Nov 12 23:12:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA23140 for xemacs-beta-people; Tue, 12 Nov 1996 23:12:36 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA23137 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 12 Nov 1996 23:12:35 -0600 (CST)
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA22243 for <xemacs-beta@cs.uiuc.edu>; Tue, 12 Nov 1996 23:12:34 -0600 (CST)
Received: by martigny.ai.mit.edu
	(1.40.112.8/16.2) id AA289991946; Wed, 13 Nov 1996 00:12:26 -0500
Date: Wed, 13 Nov 1996 00:12:26 -0500
Message-Id: <199611130512.AA289991946@martigny.ai.mit.edu>
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu
In-Reply-To: <m2bud8rqko.fsf@deanna.miranova.com> (message from Steven L Baur
	on 08 Nov 1996 17:43:19 -0800)
Subject: Re: Performance Issues

  From: Steven L Baur <steve@miranova.com>
  Date: 08 Nov 1996 17:43:19 -0800

  (Ignoring display issues for the moment)  Two very striking examples
  of the performance difference between GNU Emacs 19.34 and XEmacs 19.1[45]
  are the speed of batch byte-compilation and the speed of minibuffer
  operations (accented by use of the wonderful icomplete package).

  In the case of the command-loop (which I assume to be largely
  responsible for the slow speed of batch byte-compilation), it is
  implemented in lisp with the comment:

  ;; Putting this in lisp slows things down.


  The minibuffer is largely implemented in lisp.  Both of these
  functions are coded in C in GNU Emacs.

  Could someone enlighten me on the design decisions that led to the
  current implementation?  What are we getting in return for the reduced
  performance and the inconvenience of variant code from Emacs?

Many important enhancements were made possible by the capability
to extend this code from the e-lisp level. Development of this
code would have been much more difficult if this functionality were
hard-coded in C. That is why many improvements in this area were
first designed and implement in XEmacs.

I would recommend that you meter some of this code and find the
bottlenecks, and consider C-coding only this code (and in a
manner that permits e-lisp level extensions, e.g. calling through
the function cell, etc.)

-Bill

From xemacs-beta-request@cs.uiuc.edu  Tue Nov 12 23:42:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA23251 for xemacs-beta-people; Tue, 12 Nov 1996 23:42:31 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA23248 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 12 Nov 1996 23:42:29 -0600 (CST)
Received: from sweden.aosi.com (mail.aosi.com [206.98.255.22]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA29965 for <xemacs-beta@xemacs.org>; Tue, 12 Nov 1996 23:42:17 -0600 (CST)
Received: from hlork ([206.98.254.57]) by sweden.aosi.com
          (post.office MTA v1.9.3b ID# 0-16356) with SMTP id AAA124
          for <xemacs-beta@xemacs.org>; Wed, 13 Nov 1996 00:40:36 -0500
Sender: root@.aosi.com
Message-ID: <3289620E.3DDE5887@aosi.com>
Date: Wed, 13 Nov 1996 00:52:15 -0500
From: Joel Peterson <tarzan@aosi.com>
Organization: Me Tarzan, you Jane?
X-Mailer: Mozilla 3.0 (X11; U; Linux 1.3.97 i586)
MIME-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: Patch for `frame in a glyph'
Content-Type: multipart/mixed; boundary="------------480E554CB1EEFB140DCA4A0"

This is a multi-part message in MIME format.

--------------480E554CB1EEFB140DCA4A0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Here it is, in the form of a Netscape attachment.  Hopefully, it's still
useable.  I don't know quite what Netscape does to its attachments, and
I don't trust it not to re-justify the entire patch to 75 columns per
line if I just paste it in.

This patch is actually a superset of the window geometry patch that I
submitted earlier.  I tried to untangle the two, but I had made quite a
few changes to that code as well.  It seemed best to just combine them
rather than risk creating new bugs by tearing them apart.

There are eight new files in the src directory: console-glyph.[ch],
device-glyph.c, frame-glyph.c, glyphs-glyph.[ch], objects-glyph.c and
redisplay-glyph.c.  Many changes to the redisplay and X code were made
to accomodate sub frames in general and glyph frames in particular.  I
would have liked all changes to apply to sub frames in general; but it
didn't work that way :-).  The patch to src/Makefile.in.in adds the
eight new files, but does not remake the dependencies.  Unless you are
making from a clean src/ directory, you will want to make sure that the
dependencies are up to date.  (Believe me, I know).

Here's some info about the new stuff.  I apologize that it's in such a
haphazard format right now.  As the `frame in a glyph' stuff evolves, I
expect that I'll be able to describe and explain it better.  If you'd
like to short circuit the explanations, try jumping directly to the
section labeled `Example:'.

Lisp visible feature changes:

new feature is provided: sub-frame
new console type: glyph
new glyph type: sub-frame
new image instantiator: sub-frame
new function: select-sub-frame
new function: pixel-to-position
new specifier type: frame
new variable: default-glyph-frame-plist
different behavior at boundary condition: window-min-height
new window specifier: has-vertical-divider-p

If a glyph frame is created without a minibuffer, the minibuffer in the
containing actual frame is used instead.  The old behaviour was to
either find a frame on the same device that had a minibuffer or to
create a minibuffer only frame.  It was illegal to specify a minibuffer
that appeared on a different device than the frame.

The event-window, event-position, etc. functions were changed to report
results within the glyph frame when the event's position was actually
over a glyph containing a glyph frame.

Most of these features are described in lisp-visible documentation.  If
that fails, consult the source code :-).  If that fails, consult me.

Many changes were made so that functions expecting to be called with an
X frame would do the right thing when called with a glyph frame.  If you
use glyph frames, you should be prepared to get errors or failed
assertions about frame type.  I don't know of any places where this can
still happen, but there are undoubtedly still some out there.

Terminology:

A sub-frame is a frame that lives inside another emacs frame.
The glyph console is an implementation of sub-frames that lives inside
glyph images.
A reference to a glyph frame is really a reference to a glyph
sub-frame.  However, it's often convenient to just call it a frame.

Bugs:

Currently, the size of a glyph frame is determined by the size of the
glyph device.  It seemed necessary at the time; but things evolved to
the point where it's now just plain stupid.  Expect this one to get
fixed.

There aren't many good color, font or image defaults for glyph frames
right now (unless you count black on white with no truncation, hscroll
or continuation glyphs).

Not much testing under stress conditions or on non-Linux platforms.

Shadow colors don't appear to work (goodbye 3-D modeline, hello pseudo
2-D modeline).  This is most obvious when comparing the result of
split-window-horizontally between an X frame with no scrollbars and a
glyph frame.

Bad and horrible things will happen if more than one glyph device is
created on a single glyph.  I don't know what, I've never tried it.

Some features remain to be implemented.  Scrollbars would be nice, but
difficult.  Menubars and toolbars should be `reparented' to the
containing X frame when the glyph frame is active.  Ouch, that doesn't
sound too easy either.

Notes:

Creating a glyph sub-frame
1.  create a glyph of type sub-frame (make-glyph-internal).
2.  make a device (make-device) with a connection being a cons of that
glyph and either an X frame or device (the locale of the glyph device). 
The property list supplied must contain settings for width and height.
3.  make a frame on the device (make-frame).  Glyph frame images are
kept in a specifier and therefore, each glyph frame has a locale.  The
locale property can be set to supply a locale for the glyph frame. 
Typically, a glyph frame exists inside of a single X frame and is local
to that frame.  Because it is a specifier, only one glyph frame can
exist for each combination of an X frame and sub-frame glyph.  If the
locale property isn't set, the new frame will be created in the same
locale as the glyph device.
A single glyph can contain multiple glyph frames, each with its own
locale.  Meaning that the same glyph, when displayed in different X
frames, will display different glyph frames.  While this is potentially
confusing, especially if the same buffer is being displayed in all the X
frames, glyph frames are
A glyph frame can exist in a locale of an X device, but redisplay of
that frame will not be properly performed unless it is selected for
input.  A glyph frame with the device as its locale will only be
displayed when the glyph is displayed in frames which do not have their
own glyph frame instance.  God, specifiers are easy to describe.
4.  display the glyph as the begin-glyph or end-glyph of an extent. 
When the buffer containing the extent is displayed in a locale for which
the glyph has a sub-frame instance, the sub-frame will be displayed.

The new functions:

select-sub-frame allows you to select a particular instance of a glyph
frame based on the frame and locale.  Usually, lisp code can just call
select-frame like for a normal frame; select-sub-frame is really only
there to select a particular X frame instance of a glyph frame that has
a locale of an X device.

pixel-to-position is a function that I added because I thought it would
be necessary for porting X mouse code to work with glyph frames. 
However, some judicious changes to events.c seem to have seemlessly
taken care of the problems that I envisioned pixel-to-position solving.

The new variables:

default-glyph-frame-plist is analagous to default-x-frame-plist.  Enough
said.

has-vertical-divider-p determines whether a window without a modeline
will be displayed with a vertical divider.  This was inspired by emacs's
insistence on drawing a vertical divider even for the window at the
bottom of a minibuffer-less frame; thus obscuring the baseline of the
last row of text.  This is entirely a bad hack meant so that I could
have a nice glyph frame that actually displays an even multiple number
of lines.  It would be nice to have a general solution to this problem
so that ugly, disgusting hacks like this aren't necessary; but from
looking at the source code, a general solution would be just plain hard.

Other stuff:

I changed window-min-height so that the standard for absolute minimum
window height was to have a single visible line of text.  Thus, a window
with no modeline and no horizontal scrollbar can be exactly one line
tall; while a window with both must be at least three lines tall,
regardless of the value of window-min-height.

The frame specifier type is used internally by the glyph device code to
track instances of glyph frames.  It mirrors the image specifier kept
within the glyph itself.

Example:

This is a snippet of code that I've been using be eval'ing it in the
*scratch* buffer to test the frame in a glyph code.

(let ((glyph (make-glyph-internal 'sub-frame))
      (extent (make-extent 1 2))
      device frame)
  (setq device (make-device 'glyph (cons glyph (selected-frame))
			    '(width 60 height 20)))
  (setq frame (make-frame (list 'locale (selected-frame)
				[text-cursor background] 
				(face-background-instance 'text-cursor)
				[text-cursor foreground]
				(face-foreground-instance 'text-cursor)
				[modeline background]
				(face-background-instance 'modeline)
				'truncation-glyph
				(glyph-image-instance truncation-glyph)
				'hscroll-glyph
				(glyph-image-instance hscroll-glyph)
				'continuation-glyph
				(glyph-image-instance continuation-glyph)
				'modeline-shadow-thickness 2
				'minibuffer 'none
				) device))
  (set-extent-begin-glyph extent glyph)
  (select-sub-frame frame (selected-frame))
  (switch-to-buffer (get-buffer-create "hi")))

It creates a minibuffer-less glyph frame 60 characters wide and 20
characters high at the top of the buffer.  Note that I explicitly
specified values for many of the built in specifiers.  See `Bugs' above.

--------------480E554CB1EEFB140DCA4A0
Content-Type: text/plain; charset=iso-8859-1; name="joel.patch-19.15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; filename="joel.patch-19.15"

diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/lisp/prim/faces.el xemacs-19.15-b2-made/lisp/prim/faces.el
*** xemacs-19.15-b2/lisp/prim/faces.el	Sun Sep  8 19:50:13 1996
--- xemacs-19.15-b2-made/lisp/prim/faces.el	Mon Nov 11 23:26:19 1996
***************
*** 713,719 ****
      (and (face-equal-loop common-props face1 face2 domain)
  	 (cond ((eq 'tty (device-type device))
  		(face-equal-loop tty-props face1 face2 domain))
! 	       ((eq 'x (device-type device))
  		(face-equal-loop x-props face1 face2 domain))
  	       (t t)))))
  =

--- 713,719 ----
      (and (face-equal-loop common-props face1 face2 domain)
  	 (cond ((eq 'tty (device-type device))
  		(face-equal-loop tty-props face1 face2 domain))
! 	       ((memq (device-type device) '(x glyph))
  		(face-equal-loop x-props face1 face2 domain))
  	       (t t)))))
  =

***************
*** 1088,1094 ****
      (let ((devtype (cond ((devicep locale) (device-type locale))
  			 ((framep locale) (frame-type locale))
  			 (t nil))))
!       (cond ((or (and (not devtype) (featurep 'x)) (eq 'x devtype))
  	     (x-init-face-from-resources face locale))
  	    ((or (not devtype) (eq 'tty devtype))
  	     ;; Nothing to do for TTYs?
--- 1088,1094 ----
      (let ((devtype (cond ((devicep locale) (device-type locale))
  			 ((framep locale) (frame-type locale))
  			 (t nil))))
!       (cond ((or (and (not devtype) (featurep 'x)) (memq devtype '(x gl=
yph)))
  	     (x-init-face-from-resources face locale))
  	    ((or (not devtype) (eq 'tty devtype))
  	     ;; Nothing to do for TTYs?
***************
*** 1101,1107 ****
        (init-face-from-resources (car faces) device)
        (setq faces (cdr faces))))
    ;; Then do any device-specific initialization.
!   (cond ((eq 'x (device-type device))
  	 (x-init-device-faces device))
  	;; Nothing to do for TTYs?
  	)
--- 1101,1107 ----
        (init-face-from-resources (car faces) device)
        (setq faces (cdr faces))))
    ;; Then do any device-specific initialization.
!   (cond ((memq (device-type device) '(x glyph))
  	 (x-init-device-faces device))
  	;; Nothing to do for TTYs?
  	)
***************
*** 1114,1120 ****
        (init-face-from-resources (car faces) frame)
        (setq faces (cdr faces))))
    ;; Then do any frame-specific initialization.
!   (cond ((eq 'x (frame-type frame))
  	 (x-init-frame-faces frame))
  	;; Is there anything which should be done for TTY's?
  	))
--- 1114,1120 ----
        (init-face-from-resources (car faces) frame)
        (setq faces (cdr faces))))
    ;; Then do any frame-specific initialization.
!   (cond ((memq (frame-type frame) '(x glyph))
  	 (x-init-frame-faces frame))
  	;; Is there anything which should be done for TTY's?
  	))
***************
*** 1361,1366 ****
--- 1361,1370 ----
  	     (or fg
  		 (set-face-foreground 'modeline-buffer-id "blue" 'global
  				      '(color x))))
+ 	(and (featurep 'sub-frame)
+ 	     (or fg
+ 		 (set-face-foreground 'modeline-buffer-id "blue" 'global
+ 				      'glyph)))
  	(if font
  	    nil
  	  (if (featurep 'x)
***************
*** 1379,1384 ****
--- 1383,1392 ----
  	     (or fg
  		 (set-face-foreground 'modeline-mousable "red" 'global
  				      '(color x))))
+ 	(and (featurep 'sub-frame)
+ 	     (or fg
+ 		 (set-face-foreground 'modeline-mousable "red" 'global
+ 				      'glyph)))
  	(if font
  	    nil
  	  (if (featurep 'x)
***************
*** 1395,1401 ****
  	     (or fg
  		 (set-face-foreground 'modeline-mousable-minor-mode
  				      '(((color x) . "green4")
! 					((color x) . "green")) 'global)))))
    (set-face-parent 'modeline-mousable-minor-mode 'modeline-mousable
  		   nil nil 'append)
    )
--- 1403,1414 ----
  	     (or fg
  		 (set-face-foreground 'modeline-mousable-minor-mode
  				      '(((color x) . "green4")
! 					((color x) . "green")) 'global)))
! 	(and (featurep 'sub-frame)
! 	     (or fg
! 		 (set-face-foreground 'modeline-mousable-minor-mode
! 				      '((glyph . "green4")
! 					(glyph . "green")) 'global)))))
    (set-face-parent 'modeline-mousable-minor-mode 'modeline-mousable
  		   nil nil 'append)
    )
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/lisp/prim/glyphs.el xemacs-19.15-b2-made/lisp/prim/glyphs.el
*** xemacs-19.15-b2/lisp/prim/glyphs.el	Sun Jun 16 15:37:38 1996
--- xemacs-19.15-b2-made/lisp/prim/glyphs.el	Mon Nov 11 23:26:19 1996
***************
*** 606,611 ****
--- 606,625 ----
         ,@(if (featurep 'jpeg) '(("^\377\330\340\000\020JFIF"
  				 [jpeg :data nil] 2)))
         ("" [autodetect :data nil] 2))))
+   (if (featurep 'sub-frame)
+     (set-console-type-image-conversion-list 'glyph
+      `(,@(if (featurep 'xpm) '(("\.xpm$" [xpm :file nil] 2)))
+        ,@(if (featurep 'xpm) '(("^/\\* XPM \\*/" [xpm :data nil] 2)))
+        ,@(if (featurep 'xface) '(("^X-Face:" [xface :data nil] 2)))
+        ,@(if (featurep 'gif) '(("\.gif$" [gif :file nil] 2)))
+        ,@(if (featurep 'gif) '(("^GIF87" [gif :data nil] 2)))
+        ,@(if (featurep 'jpeg) '(("\.jpeg$" [jpeg :file nil] 2)))
+        ,@(if (featurep 'jpeg) '(("\.jpg$" [jpeg :file nil] 2)))
+        ;; all of the JFIF-format JPEG's that I've seen begin with
+        ;; the following.  I have no idea if this is standard.
+        ,@(if (featurep 'jpeg) '(("^\377\330\340\000\020JFIF"
+ 				 [jpeg :data nil] 2)))
+        ("" [autodetect :data nil] 2))))
    ;; #### this should really be formatted-string, not string but we
    ;; don't have it implemented yet
    ;;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/Makefile.in.in xemacs-19.15-b2-made/src/Makefile.in.in
*** xemacs-19.15-b2/src/Makefile.in.in	Sun Sep 15 14:31:09 1996
--- xemacs-19.15-b2-made/src/Makefile.in.in	Mon Nov 11 23:25:42 1996
***************
*** 812,817 ****
--- 812,820 ----
  #define EVENT_UNIXOID_OBJS
  #endif
  =

+ #define GLYPH_OBJS console-glyph.o device-glyph.o frame-glyph.o \
+ 		   glyphs-glyph.o objects-glyph.o redisplay-glyph.o
+ =

  /* lastfile must follow all files whose initialized data areas should
     be dumped as pure by dump-emacs.
   */
***************
*** 841,846 ****
--- 844,850 ----
  	SCROLLBAR_OBJS search.o signal.o sound.o SOUND_OBJS specifier.o \
  	strftime.o SUNPRO_OBJS symbols.o syntax.o sysdep.o \
  	TOOLBAR_OBJS TOOLTALK_OBJS TTY_OBJS \
+ 	GLYPH_OBJS \
  	undo.o UNEXEC \
  	XOBJS XMU_OBJS \
  	window.o
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/conslots.h xemacs-19.15-b2-made/src/conslots.h
*** xemacs-19.15-b2/src/conslots.h	Mon Jun 17 10:07:47 1996
--- xemacs-19.15-b2-made/src/conslots.h	Mon Nov 11 23:26:19 1996
***************
*** 43,48 ****
--- 43,53 ----
      /* Currently selected device.  */
      MARKED_SLOT (selected_device);
  =

+     /* The sub-frame which should receive keystrokes that occur in this=

+        console, or nil if they should go to the console itself.  This i=
s
+        usually nil unless a sub-frame is the the selected frame. */
+     MARKED_SLOT (selected_sub_frame);
+ =

      /* Most-recently-selected non-minibuffer-only frame.  Always
         the same as the selected frame, unless that's a minibuffer-only
         frame. */
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/console-glyph.c xemacs-19.15-b2-made/src/console-glyph.c
*** xemacs-19.15-b2/src/console-glyph.c	Wed Dec 31 19:00:00 1969
--- xemacs-19.15-b2-made/src/console-glyph.c	Mon Nov 11 23:26:19 1996
***************
*** 0 ****
--- 1,117 ----
+ /* Console functions for glyphs
+    Copyright (C) 1996 Joel Peterson
+ =

+ This file is part of XEmacs.
+ =

+ XEmacs is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+ =

+ XEmacs is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+ =

+ You should have received a copy of the GNU General Public License
+ along with XEmacs; see the file COPYING.  If not, write to
+ the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA.  */
+ =

+ /* Synched up with: Not in FSF. */
+ =

+ /* Author: Joel Peterson (tarzan@aosi.com) */
+ =

+ #include <config.h>
+ #include "lisp.h"
+ =

+ #include "console-glyph.h"
+ #include "device.h"
+ #include "frame.h"
+ #include "glyphs.h"
+ #include "glyphs-glyph.h"
+ #include "process.h" /* canonicalize_host_name */
+ #include "redisplay.h" /* for display_arg */
+ #include "window.h"
+ =

+ DEFINE_CONSOLE_TYPE (glyph);
+ =

+ static int
+ glyph_initially_selected_for_input (struct console *con)
+ {
+   return 0;
+ }
+ =

+ /* Remember, in all of the following functions, we have to verify
+    the integrity of our input, because the generic functions don't. */
+ =

+ static Lisp_Object
+ glyph_device_to_console_connection (Lisp_Object connection,
+ 				    Error_behavior errb)
+ {
+   if (NILP (connection))
+     return Qnil;
+   else
+     {
+       Lisp_Object glyph;
+       Lisp_Object locale;
+       Lisp_Object frames;
+       =

+       if (!ERRB_EQ (errb, ERROR_ME))
+ 	{
+ 	  if (!CONSP (connection))
+ 	    return Qunbound;
+ 	  =

+ 	  glyph =3D Fcar (connection);
+ 	  locale =3D Fcdr (connection);
+ 	  =

+ 	  if (!(GLYPHP (glyph) && XGLYPH_SUB_FRAMEP (glyph)))
+ 	    return Qunbound;
+ 	  =

+ 	  frames =3D Fget (glyph, Qsub_frames, Qnil);
+ 	  if (!NILP (frames))	/* device already exists on this glyph */
+ 	    return Qunbound;
+ 	  =

+ 	  if (WINDOWP (locale))
+ 	    locale =3D XWINDOW(locale)->frame;
+ 	  if (!((FRAMEP (locale) && FRAME_LIVE_P (XFRAME (locale)))
+ 		|| (DEVICEP (locale) && DEVICE_LIVE_P (XDEVICE (locale)))))
+ 	    return Qunbound;
+ 	}
+       else
+ 	{
+ 	  CHECK_CONS (connection);
+ 	  =

+ 	  glyph =3D Fcar (connection);
+ 	  locale =3D Fcdr (connection);
+ 	  =

+ 	  CHECK_GLYPH (glyph);
+ 	  =

+ 	  if (!XGLYPH_SUB_FRAMEP (glyph))
+ 	    dead_wrong_type_argument (Qsub_framep, glyph);
+ 	  =

+ 	  frames =3D Fget (glyph, Qsub_frames, Qnil);
+ 	  if (!NILP (frames))
+ 	    signal_simple_error ("Device already exists on glyph", glyph);
+ 	  =

+ 	  if (WINDOWP (locale))
+ 	    locale =3D XWINDOW(locale)->frame;
+ 	  if (!((FRAMEP (locale) && FRAME_LIVE_P (XFRAME (locale)))
+ 		|| (DEVICEP (locale) && DEVICE_LIVE_P (XDEVICE (locale)))))
+ 	    signal_simple_error ("Invalid specifier locale or locale type",
+ 				 locale);
+ 	}
+       connection =3D Fcons (glyph, locale);
+     }
+ =

+   return connection;
+ }
+ =

+ void
+ console_type_create_glyph (void)
+ {
+   INITIALIZE_CONSOLE_TYPE (glyph, "glyph", "console-glyph-p");
+   =

+   CONSOLE_HAS_METHOD (glyph, initially_selected_for_input);
+   CONSOLE_HAS_METHOD (glyph, device_to_console_connection);
+ }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/console-glyph.h xemacs-19.15-b2-made/src/console-glyph.h
*** xemacs-19.15-b2/src/console-glyph.h	Wed Dec 31 19:00:00 1969
--- xemacs-19.15-b2-made/src/console-glyph.h	Mon Nov 11 23:26:19 1996
***************
*** 0 ****
--- 1,84 ----
+ /* Define GLYPH specific console, device, and frame object for XEmacs.
+    Copyright (C) 1989, 1992, 1993, 1994, 1995 Free Software Foundation,=
 Inc.
+    Copyright (C) 1994, 1995 Board of Trustees, University of Illinois.
+    Copyright (C) 1996 Joel Peterson
+ =

+ This file is part of XEmacs.
+ =

+ XEmacs is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+ =

+ XEmacs is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+ =

+ You should have received a copy of the GNU General Public License
+ along with XEmacs; see the file COPYING.  If not, write to
+ the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA.  */
+ =

+ /* Synched up with: Not in FSF. */
+ =

+ =

+ /* Authorship:
+    Joel Peterson (tarzan@aosi.com), November 1996
+  */
+ =

+ #ifndef _XEMACS_CONSOLE_GLYPH_H_
+ #define _XEMACS_CONSOLE_GLYPH_H_
+ =

+ #include "console.h"
+ =

+ DECLARE_CONSOLE_TYPE (glyph);
+ =

+ struct glyph_device
+ {
+   /* the glyph that this device lives in */
+   Lisp_Object glyph;
+   /* the locale that this device was created in */
+   Lisp_Object locale;
+   =

+   /* The locale that this device is currently selected in */
+   Lisp_Object selected_locale;
+   =

+   /* The containing frame for this glyph.  Set by redisplay immediately=
 before
+      redisplaying the frame. */
+   Lisp_Object container;
+   =

+   int height;
+   int width;
+ };
+ =

+ #define DEVICE_GLYPH_DATA(d) DEVICE_TYPE_DATA (d, glyph)
+ =

+ #define DEVICE_GLYPH_GLYPH(d) (DEVICE_GLYPH_DATA (d)->glyph)
+ #define DEVICE_GLYPH_LOCALE(d) (DEVICE_GLYPH_DATA (d)->locale)
+ #define DEVICE_GLYPH_HEIGHT(d) (DEVICE_GLYPH_DATA (d)->height)
+ #define DEVICE_GLYPH_CONTAINER(d) (DEVICE_GLYPH_DATA (d)->container)
+ #define DEVICE_GLYPH_WIDTH(d) (DEVICE_GLYPH_DATA (d)->width)
+ #define DEVICE_GLYPH_SELECTED_LOCALE(d) (DEVICE_GLYPH_DATA (d)->selecte=
d_locale)
+ =

+ /* One frame exists per instance of the glyph image.  This typically me=
ans
+    one frame per console that the glyph could be displayed on.  Note th=
at
+    glyphs are unusual in that a particular frame can be displayed in
+    multiple spots on a single device. */
+ struct glyph_frame
+ {
+   /* The locale that this frame was created in */
+   Lisp_Object locale;
+ };
+ =

+ #define FRAME_GLYPH_DATA(f) FRAME_TYPE_DATA (f, glyph)
+ =

+ #define FRAME_GLYPH_CONTAINER(f) \
+    (DEVICE_GLYPH_CONTAINER (XDEVICE (FRAME_DEVICE (f))))
+ #define FRAME_GLYPH_LOCALE(f) (FRAME_GLYPH_DATA (f)->locale)
+ #define FRAME_GLYPH_SELECTED_LOCALE(f) \
+    (DEVICE_GLYPH_SELECTED_LOCALE (XDEVICE (FRAME_DEVICE (f))))
+ =

+ extern Lisp_Object Qsub_frames;
+ =

+ #endif /* _XEMACS_DEVICE_GLYPH_H_ */
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/console-stream.c xemacs-19.15-b2-made/src/console-stream.c
*** xemacs-19.15-b2/src/console-stream.c	Sun Mar 31 19:20:24 1996
--- xemacs-19.15-b2-made/src/console-stream.c	Mon Nov 11 23:26:19 1996
***************
*** 168,175 ****
  =

  =0C
  static int
! stream_text_width (struct face_cachel *cachel, CONST Emchar *str,
! 		   Charcount len)
  {
    return len;
  }
--- 168,175 ----
  =

  =0C
  static int
! stream_text_width (struct frame *f, struct face_cachel *cachel,
! 		   CONST Emchar *str, Charcount len)
  {
    return len;
  }
***************
*** 187,205 ****
  }
  =

  static int
! stream_divider_width (void)
  {
    return 1;
  }
  =

  static int
! stream_divider_height (void)
  {
    return 1;
  }
  =

  static int
! stream_eol_cursor_width (void)
  {
    return 1;
  }
--- 187,205 ----
  }
  =

  static int
! stream_divider_width (struct frame *f)
  {
    return 1;
  }
  =

  static int
! stream_divider_height (struct frame *f)
  {
    return 1;
  }
  =

  static int
! stream_eol_cursor_width (struct frame *f)
  {
    return 1;
  }
***************
*** 223,240 ****
  }
  =

  static void
! stream_output_vertical_divider (struct window *w, int clear)
  {
  }
  =

  static void
! stream_clear_to_window_end (struct window *w, int ypos1, int ypos2)
  {
  }
  =

  static void
! stream_clear_region (Lisp_Object locale, face_index findex, int x, int =
y,
! 		       int width, int height)
  {
  }
  =

--- 223,243 ----
  }
  =

  static void
! stream_output_vertical_divider (Drawable drawing_area, struct window *w=
,
! 				struct frame *container, int clear)
  {
  }
  =

  static void
! stream_clear_to_window_end (Drawable drawing_area, struct window *w,
! 			    struct frame *container, int ypos1, int ypos2)
  {
  }
  =

  static void
! stream_clear_region (Drawable drawing_area, Lisp_Object locale,
! 		     struct frame *container, face_index findex, int x, int y,
! 		     int width, int height)
  {
  }
  =

***************
*** 244,262 ****
  }
  =

  static int
! stream_flash (struct device *d)
  {
    return 0; /* sorry can't do it */
  }
  =

  static void
! stream_ring_bell (struct device *d, int volume, int pitch, int duration=
)
  {
!   struct console *c =3D XCONSOLE (DEVICE_CONSOLE (d));
    fputc (07, CONSOLE_STREAM_DATA (c)->outfd);
    fflush (CONSOLE_STREAM_DATA (c)->outfd);
  }
  =

  =0C
  /**********************************************************************=
**/
  /*                            initialization                           =
 */
--- 247,271 ----
  }
  =

  static int
! stream_flash (struct frame *f)
  {
    return 0; /* sorry can't do it */
  }
  =

  static void
! stream_ring_bell (struct frame *f, int volume, int pitch, int duration)=

  {
!   struct console *c =3D XCONSOLE (FRAME_CONSOLE (f));
    fputc (07, CONSOLE_STREAM_DATA (c)->outfd);
    fflush (CONSOLE_STREAM_DATA (c)->outfd);
  }
  =

+ static Drawable
+ stream_drawable (struct frame *f)
+ {
+   return 0;
+ }
+ =

  =0C
  /**********************************************************************=
**/
  /*                            initialization                           =
 */
***************
*** 298,303 ****
--- 307,313 ----
    CONSOLE_HAS_METHOD (stream, output_end);
    CONSOLE_HAS_METHOD (stream, flash);
    CONSOLE_HAS_METHOD (stream, ring_bell);
+   CONSOLE_HAS_METHOD (stream, drawable);
  }
  =

  void
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/console-x.h xemacs-19.15-b2-made/src/console-x.h
*** xemacs-19.15-b2/src/console-x.h	Sun Sep  8 19:47:58 1996
--- xemacs-19.15-b2-made/src/console-x.h	Mon Nov 11 23:26:19 1996
***************
*** 393,417 ****
  int x_error_handler (Display *disp, XErrorEvent *event);
  void expect_x_error (Display *dpy);
  int x_error_occurred_p (Display *dpy);
  int signal_if_x_error (Display *dpy, int resumable_p);
  int x_IO_error_handler (Display *disp);
  =

  void x_redraw_exposed_area (struct frame *f, int x, int y,
  			    int width, int height);
  struct Lisp_Image_Instance;
! void x_output_string (struct window *w, struct display_line *dl,
! 		      emchar_dynarr *buf, int xpos, int xoffset,
! 		      int start_pixpos, int width, face_index findex,
! 		      int cursor, int cursor_start, int cursor_width,
! 		      int cursor_height);
! void x_output_x_pixmap (struct frame *f, struct Lisp_Image_Instance *p,=

! 			int x, int y, int clip_x, int clip_y,
! 			int clip_width, int clip_height, int width,
! 			int height, int pixmap_offset,
! 			unsigned long fg, unsigned long bg,
  			GC override_gc);
! void x_output_shadows (struct frame *f, int x, int y, int width,
! 		       int height, GC top_shadow_gc,
  		       GC bottom_shadow_gc, GC background_gc,
  		       int shadow_thickness);
  void x_generate_shadow_pixels (struct frame *f,
--- 393,419 ----
  int x_error_handler (Display *disp, XErrorEvent *event);
  void expect_x_error (Display *dpy);
  int x_error_occurred_p (Display *dpy);
+ unsigned char x_error_code (Display *dpy);
  int signal_if_x_error (Display *dpy, int resumable_p);
  int x_IO_error_handler (Display *disp);
  =

  void x_redraw_exposed_area (struct frame *f, int x, int y,
  			    int width, int height);
  struct Lisp_Image_Instance;
! void x_output_string (Drawable x_win, struct window *w,
! 		      struct frame *container, struct display_line *dl,
! 		      emchar_dynarr *buf, int xpos,
! 		      int xoffset, int clip_start,
! 		      int width, face_index findex, int cursor,
! 		      int cursor_start, int cursor_width, int cursor_height);
! void x_output_x_pixmap (Drawable x_win, struct frame *f,
! 			struct Lisp_Image_Instance *p, int x,
! 			int y, int clip_x, int clip_y, int clip_width,
! 			int clip_height, int width, int height,
! 			int pixmap_offset, unsigned long fg, unsigned long bg,
  			GC override_gc);
! void x_output_shadows (Drawable x_win, struct frame *f, int x, int y,
! 		       int width, int height, GC top_shadow_gc,
  		       GC bottom_shadow_gc, GC background_gc,
  		       int shadow_thickness);
  void x_generate_shadow_pixels (struct frame *f,
***************
*** 422,427 ****
--- 424,431 ----
  =

  int x_initialize_frame_menubar (struct frame *f);
  void x_init_modifier_mapping (struct device *d);
+ =

+ Lisp_Object x_sub_frame_device_to_x_device (Lisp_Object device);
  =

  #define X_ERROR_OCCURRED(dpy, body)	\
       (expect_x_error ((dpy)), (body), x_error_occurred_p (dpy))
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/console.h xemacs-19.15-b2-made/src/console.h
*** xemacs-19.15-b2/src/console.h	Mon Sep 16 17:48:54 1996
--- xemacs-19.15-b2-made/src/console.h	Mon Nov 11 23:26:19 1996
***************
*** 25,30 ****
--- 25,32 ----
  #ifndef _XEMACS_CONSOLE_H_
  #define _XEMACS_CONSOLE_H_
  =

+ #include "redisplay.h"
+ =

  /* Devices and consoles are similar entities.  The idea is that
     a console represents a physical keyboard/mouse/other-input-source
     while a device represents a display where frames appear on.
***************
*** 76,81 ****
--- 78,84 ----
    int (*device_mm_height_method) (struct device *);
    int (*device_bitplanes_method) (struct device *);
    int (*device_color_cells_method) (struct device *);
+   void (*deselect_device_method) (struct device *);
  =

    /* frame methods */
    Lisp_Object *device_specific_frame_props;
***************
*** 111,137 ****
    void (*set_frame_icon_method) (struct frame *f);
    void (*popup_menu_method) (Lisp_Object menu, Lisp_Object event);
    Lisp_Object (*get_frame_parent_method) (struct frame *f);
  =

    /* redisplay methods */
    int (*left_margin_width_method) (struct window *);
    int (*right_margin_width_method) (struct window *);
!   int (*text_width_method) (struct face_cachel *cachel,
  			    CONST Emchar *str, Charcount len);
    void (*output_display_block_method) (struct window *, struct display_=
line *,
  				       int, int, int, int, int, int, int);
!   int (*divider_width_method) (void);
!   int (*divider_height_method) (void);
!   int (*eol_cursor_width_method) (void);
!   void (*output_vertical_divider_method) (struct window *, int);
!   void (*clear_to_window_end_method) (struct window *, int, int);
!   void (*clear_region_method) (Lisp_Object, face_index, int, int, int, =
int);
    void (*clear_frame_method) (struct frame *);
    void (*output_begin_method) (struct device *);
    void (*output_end_method) (struct device *);
!   int (*flash_method) (struct device *);
!   void (*ring_bell_method) (struct device *, int volume, int pitch,
  			    int duration);
    void (*frame_redraw_cursor_method) (struct frame *f);
  =

    /* color methods */
    int (*initialize_color_instance_method) (struct Lisp_Color_Instance *=
,
--- 114,175 ----
    void (*set_frame_icon_method) (struct frame *f);
    void (*popup_menu_method) (Lisp_Object menu, Lisp_Object event);
    Lisp_Object (*get_frame_parent_method) (struct frame *f);
+   void (*select_frame_method) (struct device *d, Lisp_Object frame);
  =

    /* redisplay methods */
    int (*left_margin_width_method) (struct window *);
    int (*right_margin_width_method) (struct window *);
!   int (*text_width_method) (struct frame *f, struct face_cachel *cachel=
,
  			    CONST Emchar *str, Charcount len);
    void (*output_display_block_method) (struct window *, struct display_=
line *,
  				       int, int, int, int, int, int, int);
!   int (*divider_width_method) (struct frame *f);
!   int (*divider_height_method) (struct frame *f);
!   int (*eol_cursor_width_method) (struct frame *f);
!   void (*output_vertical_divider_method) (Drawable, struct window *,
! 					  struct frame *, int);
!   void (*clear_to_window_end_method) (Drawable, struct window *,
! 				      struct frame *, int, int);
!   void (*clear_region_method) (Drawable, Lisp_Object, struct frame *,
! 			       face_index, int, int, int, int);
    void (*clear_frame_method) (struct frame *);
    void (*output_begin_method) (struct device *);
    void (*output_end_method) (struct device *);
!   int (*flash_method) (struct frame *);
!   void (*ring_bell_method) (struct frame *, int volume, int pitch,
  			    int duration);
    void (*frame_redraw_cursor_method) (struct frame *f);
+   void (*set_container_frame_method) (struct frame *f, Lisp_Object cont=
ainer);
+   Lisp_Object (*container_frame_method) (struct frame *f);
+   Drawable (*drawable_method) (struct frame *f);
+ =

+   /* output primitive methods */
+ =

+   void (*output_primitive_string_method)
+     (Drawable drawing_area, struct window *w, struct frame *container,
+      struct display_line *dl, emchar_dynarr *buf, int xpos,
+      int xoffset, int clip_start,
+      int width, face_index findex, int cursor,
+      int cursor_start, int cursor_width, int cursor_height);
+   void (*output_primitive_eol_cursor_method)
+     (Drawable drawing_area, struct window *w, struct frame *container,
+      struct display_line *dl, int xpos);
+   void (*output_primitive_blank_method)
+     (Drawable drawing_area, struct window *w, struct frame *container,
+      struct display_line *dl, struct rune *rb, int start_pixpos,
+      int cursor_start, int cursor_width);
+   void (*output_primitive_hline_method)
+     (Drawable drawing_area, struct window *w, struct frame *container,
+      struct display_line *dl, struct rune *rb);
+   void (*output_primitive_pixmap_method)
+     (Drawable drawing_area, struct window *w, struct frame *container,
+      struct display_line *dl, Lisp_Object image_instance, int xpos,
+      int xoffset, int start_pixpos, int width, face_index findex,
+      int cursor_start, int cursor_width, int cursor_height);
+   /* this is bogusly specific for an `output primitive' */
+   void (*output_primitive_bevel_modeline_method)
+     (Drawable drawing_area, struct window *w,  struct frame *container,=

+      struct display_line *dl);
  =

    /* color methods */
    int (*initialize_color_instance_method) (struct Lisp_Color_Instance *=
,
***************
*** 302,307 ****
--- 340,352 ----
  #define MAYBE_LISP_CONMETH(c, m, args) \
    MAYBE_LISP_CONTYPE_METH ((c)->conmeths, m, args)
  =

+ #define HAS_CONMETH_OUTPUT_PRIMITIVE_P(c, m) \
+   HAS_CONMETH_P (c, output_primitive_##m)
+ #define CONMETH_OUTPUT_PRIMITIVE(c, m, args) \
+   CONTYPE_METH ((c)->conmeths, output_primitive_##m, args)
+ #define MAYBE_CONMETH_OUTPUT_PRIMITIVE(c, m, args) \
+   MAYBE_CONTYPE_METH ((c)->conmeths, output_primitive_##m, args)
+ =

  /******** Defining new console types ********/
  =

  struct console_type_entry
***************
*** 335,340 ****
--- 380,388 ----
  #define CONSOLE_HAS_METHOD(type, m) \
    (type##_console_methods->m##_method =3D type##_##m)
  =

+ #define CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD(type, m) \
+   (type##_console_methods->output_primitive_##m##_method =3D type##_out=
put_##m)
+ =

  struct console
  {
    struct lcrecord_header header;
***************
*** 449,454 ****
--- 497,504 ----
  #endif
  #define CONSOLE_TYPESYM_STREAM_P(typesym) EQ (typesym, Qstream)
  =

+ #define CONSOLE_TYPESYM_GLYPH_P(typesym) EQ (typesym, Qglyph)
+      =

  #define CONSOLE_TYPESYM_WIN_P(typesym) \
    (CONSOLE_TYPESYM_X_P (typesym) || CONSOLE_TYPESYM_NS_P (typesym))
  =

***************
*** 456,461 ****
--- 506,515 ----
  #define CHECK_X_CONSOLE(z) CHECK_CONSOLE_TYPE (z, x)
  #define CONCHECK_X_CONSOLE(z) CONCHECK_CONSOLE_TYPE (z, x)
  =

+ #define CONSOLE_GLYPH_P(con) CONSOLE_TYPESYM_GLYPH_P (CONSOLE_TYPE (con=
))
+ #define CHECK_GLYPH_CONSOLE(z) CHECK_CONSOLE_TYPE (z, x)
+ #define CONCHECK_GLYPH_CONSOLE(z) CONCHECK_CONSOLE_TYPE (z, x)
+ =

  #define CONSOLE_NS_P(con) CONSOLE_TYPESYM_NS_P (CONSOLE_TYPE (con))
  #define CHECK_NS_CONSOLE(z) CHECK_CONSOLE_TYPE (z, ns)
  #define CONCHECK_NS_CONSOLE(z) CONCHECK_CONSOLE_TYPE (z, ns)
***************
*** 500,506 ****
  =

  extern Lisp_Object Vconsole_type_list;
  =

! extern Lisp_Object Qtty, Qstream, Qdead;
  #ifdef HAVE_X_WINDOWS
  extern Lisp_Object Qx;
  #endif /* HAVE_X_WINDOWS */
--- 554,560 ----
  =

  extern Lisp_Object Vconsole_type_list;
  =

! extern Lisp_Object Qtty, Qstream, Qglyph, Qdead;
  #ifdef HAVE_X_WINDOWS
  extern Lisp_Object Qx;
  #endif /* HAVE_X_WINDOWS */
***************
*** 522,527 ****
--- 576,582 ----
    DEVICE_SELECTED_FRAME (XDEVICE ((con)->selected_device))
  #define CONSOLE_LAST_NONMINIBUF_FRAME(con) NON_LVALUE ((con)->_last_non=
minibuf_frame)
  #define CONSOLE_QUIT_CHAR(con) ((con)->quit_char)
+ #define CONSOLE_SELECTED_SUB_FRAME(con)  ((con)->selected_sub_frame)
  =

  #define CDFW_CONSOLE(obj)				\
     (WINDOWP  (obj) ? WINDOW_CONSOLE (XWINDOW (obj))	\
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/device-glyph.c xemacs-19.15-b2-made/src/device-glyph.c
*** xemacs-19.15-b2/src/device-glyph.c	Wed Dec 31 19:00:00 1969
--- xemacs-19.15-b2-made/src/device-glyph.c	Mon Nov 11 23:26:20 1996
***************
*** 0 ****
--- 1,167 ----
+ /* GLYPH device functions.
+    Copyright (C) 1994, 1995 Board of Trustees, University of Illinois.
+    Copyright (C) 1994, 1995 Free Software Foundation, Inc.
+    Copyright (C) 1996 Ben Wing.
+    Copyright (C) 1996 Joel Peterson
+ =

+ This file is part of XEmacs.
+ =

+ XEmacs is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+ =

+ XEmacs is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+ =

+ You should have received a copy of the GNU General Public License
+ along with XEmacs; see the file COPYING.  If not, write to
+ the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA.  */
+ =

+ /* Synched up with: Not in FSF. */
+ =

+ /* author: Joel Peterson (tarzan@aosi.com) */
+ =

+ #include <config.h>
+ #include "lisp.h"
+ =

+ #include "console-glyph.h"
+ #include "console-stream.h"
+ #include "events.h"
+ #include "faces.h"
+ #include "frame.h"
+ #include "glyphs.h"
+ #include "lstream.h"
+ #include "redisplay.h"
+ #include "sysdep.h"
+ =

+ #include <errno.h>
+ =

+ static void
+ allocate_glyph_device_struct (struct device *d)
+ {
+   d->device_data =3D
+     (struct glyph_device *) xmalloc (sizeof (struct glyph_device));
+ =

+   /* zero out all slots. */
+   memset (d->device_data, 0, sizeof (struct glyph_device));
+ }
+ =

+ static void
+ glyph_init_device (struct device *d, Lisp_Object props)
+ {
+   Lisp_Object width, height;
+   Lisp_Object frames, glyph, device;
+   =

+   /* punt on these, since they shouldn't be used */
+   DEVICE_INFD (d) =3D 0;
+   DEVICE_INFD (d) =3D 1;
+   =

+   allocate_glyph_device_struct (d);
+   init_baud_rate (d);
+   init_one_device (d);
+   =

+   glyph =3D Fcar (d->connection);
+   =

+   DEVICE_GLYPH_SELECTED_LOCALE (d) =3D Qnil;
+   DEVICE_GLYPH_LOCALE (d) =3D Fcdr (d->connection);
+   DEVICE_GLYPH_GLYPH (d) =3D glyph;
+   DEVICE_GLYPH_CONTAINER (d) =3D Qnil;
+   =

+   width =3D Fplist_get (props, Qwidth, make_int (0));
+   height =3D Fplist_get (props, Qheight, make_int (0));
+   =

+   DEVICE_GLYPH_WIDTH (d) =3D XINT (width);
+   DEVICE_GLYPH_HEIGHT (d) =3D XINT (height);
+ =

+   DEVICE_NAME (d) =3D build_translated_string ("glyph");
+   =

+   frames =3D Fmake_specifier (Qframe);
+   Fput (glyph, Qsub_frames, frames);
+   XSETDEVICE (device, d);
+   Fput (glyph, Qdevice, device);
+ }
+ =

+ static void
+ free_glyph_device_struct (struct device *d)
+ {
+   struct glyph_device *gd =3D (struct glyph_device *) d->device_data;
+   if (gd)
+     xfree (gd);
+ }
+ =

+ static void
+ glyph_delete_device (struct device *d)
+ {
+   Lisp_Object glyph =3D DEVICE_GLYPH_GLYPH (d);
+   if (GLYPHP (glyph))
+     {
+       Fremprop (glyph, Qsub_frames);
+       Fremprop (glyph, Qdevice);
+     }
+   free_glyph_device_struct (d);
+ }
+ =

+ static int
+ glyph_device_pixel_width (struct device *d)
+ {
+   int font_height, font_width;
+   Lisp_Object device;
+   =

+   XSETDEVICE (device, d);
+   default_face_height_and_width (device, &font_height, &font_width);
+   =

+   return (DEVICE_GLYPH_WIDTH (d) * font_width);
+ }
+ =

+ static int
+ glyph_device_pixel_height (struct device *d)
+ {
+   int font_height, font_width;
+   Lisp_Object device;
+   =

+   XSETDEVICE (device, d);
+   default_face_height_and_width (device, &font_height, &font_width);
+   =

+   return (DEVICE_GLYPH_HEIGHT (d) * font_height);
+ }
+ =

+ static void
+ glyph_mark_device (struct device *d, void (*markobj) (Lisp_Object))
+ {
+   ((markobj) (DEVICE_GLYPH_DATA (d)->locale));
+   ((markobj) (DEVICE_GLYPH_DATA (d)->selected_locale));
+ }
+ =

+ static void
+ glyph_deselect_device (struct device *d)
+ {
+   Lisp_Object locale;
+   struct frame *l;
+   locale =3D DEVICE_GLYPH_SELECTED_LOCALE (d);
+   assert (FRAMEP (locale));
+   l =3D XFRAME (locale);
+   FRAME_SELECTED_SUB_FRAME (l) =3D Qnil;
+   DEVICE_GLYPH_SELECTED_LOCALE (d) =3D Qnil;
+   /*d->_selected_frame =3D Qnil;*/
+ }
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*                            initialization                           =
 */
+ /**********************************************************************=
**/
+ =

+ void
+ console_type_create_device_glyph (void)
+ {
+   /* device methods */
+   CONSOLE_HAS_METHOD (glyph, init_device);
+   CONSOLE_HAS_METHOD (glyph, delete_device);
+   CONSOLE_HAS_METHOD (glyph, device_pixel_width);
+   CONSOLE_HAS_METHOD (glyph, device_pixel_height);
+   CONSOLE_HAS_METHOD (glyph, mark_device);
+   CONSOLE_HAS_METHOD (glyph, deselect_device);
+ }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/device-x.c xemacs-19.15-b2-made/src/device-x.c
*** xemacs-19.15-b2/src/device-x.c	Sun Sep 15 17:23:42 1996
--- xemacs-19.15-b2-made/src/device-x.c	Mon Nov 11 23:26:20 1996
***************
*** 27,32 ****
--- 27,33 ----
  #include <config.h>
  #include "lisp.h"
  =

+ #include "console-glyph.h"
  #include "console-x.h"
  #include "xintrinsicp.h"	/* CoreP.h needs this */
  #include <X11/CoreP.h>		/* Numerous places access the fields of
***************
*** 122,127 ****
--- 123,129 ----
  decode_x_device (Lisp_Object device)
  {
    XSETDEVICE (device, decode_device (device));
+   device =3D x_sub_frame_device_to_x_device (device);
    CHECK_X_DEVICE (device);
    return XDEVICE (device);
  }
***************
*** 546,551 ****
--- 548,559 ----
    return val;
  }
  =

+ unsigned char
+ x_error_code (Display *dpy)
+ {
+   return last_error.error_code;
+ }
+ =

  int
  signal_if_x_error (Display *dpy, int resumable_p)
  {
***************
*** 726,731 ****
--- 734,767 ----
      }
  }
  =

+ Lisp_Object
+ x_sub_frame_device_to_x_device (Lisp_Object device)
+ {
+   Lisp_Object locale;
+   struct device *d =3D XDEVICE (device);
+   =

+   while (DEVICE_GLYPH_P (d))
+     {
+       locale =3D DEVICE_GLYPH_SELECTED_LOCALE (d);
+       if (FRAMEP (locale))
+ 	locale =3D FRAME_DEVICE (XFRAME (locale));
+       else
+ 	{
+ 	  locale =3D DEVICE_GLYPH_LOCALE (d);
+ 	  if (FRAMEP (locale))
+ 	    locale =3D FRAME_DEVICE (XFRAME (locale));
+ 	}
+       if (DEVICEP (locale))
+ 	{
+ 	  device =3D locale;
+ 	  d =3D XDEVICE (locale);
+ 	}
+       else
+ 	break;
+     }
+   return device;
+ }
+ =

  /* Given a locale and device specification from x-get-resource or
  x-get-resource-prefix, return the resource prefix and display to
  fetch the resource on. */
***************
*** 750,762 ****
  =

    if (!NILP (device) && !DEVICEP (device))
      CHECK_DEVICE (device);
    if (DEVICEP (device) && !DEVICE_X_P (XDEVICE (device)))
!     device =3D Qnil;
    if (NILP (device))
      {
        device =3D DFW_DEVICE (locale);
        if (DEVICEP (device) && !DEVICE_X_P (XDEVICE (device)))
! 	device =3D Qnil;
        if (NILP (device))
  	device =3D Vdefault_x_device;
        if (NILP (device))
--- 786,807 ----
  =

    if (!NILP (device) && !DEVICEP (device))
      CHECK_DEVICE (device);
+   =

    if (DEVICEP (device) && !DEVICE_X_P (XDEVICE (device)))
!     {
!       device =3D x_sub_frame_device_to_x_device (device);
!       if (DEVICEP (device) && !DEVICE_X_P (XDEVICE (device)))
! 	device =3D Qnil;
!     }
    if (NILP (device))
      {
        device =3D DFW_DEVICE (locale);
        if (DEVICEP (device) && !DEVICE_X_P (XDEVICE (device)))
! 	{
! 	  device =3D x_sub_frame_device_to_x_device (device);
! 	  if (DEVICEP (device) && !DEVICE_X_P (XDEVICE (device)))
! 	    device =3D Qnil;
! 	}
        if (NILP (device))
  	device =3D Vdefault_x_device;
        if (NILP (device))
***************
*** 1195,1200 ****
--- 1240,1248 ----
    KeySym  keysym_KeySym;
    KeySym *keysym_ptr, *keysym_last;
    int min_code, max_code, keysyms_per_code;
+ =

+   device =3D x_sub_frame_device_to_x_device (device);
+   d =3D XDEVICE (device);
    =

    if (!DEVICE_X_P (d))
      signal_simple_error ("Not an X device", device);
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/device.c xemacs-19.15-b2-made/src/device.c
*** xemacs-19.15-b2/src/device.c	Thu Jun 20 20:56:17 1996
--- xemacs-19.15-b2-made/src/device.c	Mon Nov 11 23:26:20 1996
***************
*** 254,259 ****
--- 254,266 ----
    if (EQ (device, old_selected_device))
      return;
  =

+   /* run the old selected device's deselect method */
+   if (DEVICEP (old_selected_device))
+     {
+       struct device *old_dev =3D XDEVICE (old_selected_device);
+       MAYBE_DEVMETH (old_dev, deselect_device, (old_dev));
+     }
+   =

    /* now select the device's console */
    CONSOLE_SELECTED_DEVICE (XCONSOLE (DEVICE_CONSOLE (dev))) =3D device;=

    select_console_1 (DEVICE_CONSOLE (dev));
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/device.h xemacs-19.15-b2-made/src/device.h
*** xemacs-19.15-b2/src/device.h	Sun Sep  8 19:46:54 1996
--- xemacs-19.15-b2-made/src/device.h	Mon Nov 11 23:26:20 1996
***************
*** 221,226 ****
--- 221,228 ----
  =

  #define DEVICE_TYPE_P(d, type)	EQ (DEVICE_TYPE (d), Q##type)
  =

+ #define DEVICE_GLYPH_P(d)	DEVICE_TYPE_P (d, glyph)
+ =

  #ifdef ERROR_CHECK_TYPECHECK
  MAC_DECLARE_EXTERN (struct device *, MTdevice_data)
  # define DEVICE_TYPE_DATA(d, type)			\
***************
*** 307,313 ****
  #define DEVICE_OLD_FCNTL_OWNER(d) ((d)->old_fcntl_owner)
  #define DEVICE_ON_CONSOLE_P(d) ((d)->on_console_p)
  #define DEVICE_CONNECTED_TO_NAS_P(d) ((d)->connected_to_nas_p)
! =

  #define LOCK_DEVICE(d) do { (d)->locked =3D 1; } while (0)
  #define UNLOCK_DEVICE(d) do { (d)->locked =3D 0; } while (0)
  =

--- 309,316 ----
  #define DEVICE_OLD_FCNTL_OWNER(d) ((d)->old_fcntl_owner)
  #define DEVICE_ON_CONSOLE_P(d) ((d)->on_console_p)
  #define DEVICE_CONNECTED_TO_NAS_P(d) ((d)->connected_to_nas_p)
! #define DEVICE_SELECTED_SUB_FRAME(d) \
!      CONSOLE_SELECTED_SUB_FRAME (XCONSOLE (d->console))
  #define LOCK_DEVICE(d) do { (d)->locked =3D 1; } while (0)
  #define UNLOCK_DEVICE(d) do { (d)->locked =3D 0; } while (0)
  =

***************
*** 322,353 ****
--- 325,370 ----
  =

  #define MARK_DEVICE_FACES_CHANGED(d) do {				\
    faces_changed =3D 1;							\
+   if (DEVICE_GLYPH_P (d))						\
+     MARK_BUFFERS_CHANGED;						\
    (d)->faces_changed =3D 1; } while (0)
  =

  #define MARK_DEVICE_TOOLBARS_CHANGED(d) do {				\
    toolbar_changed =3D 1;							\
+   if (DEVICE_GLYPH_P (d))						\
+     MARK_BUFFERS_CHANGED;						\
    (d)->toolbar_changed =3D 1; } while (0)
  =

  #define MARK_DEVICE_SIZE_CHANGED(d) do {				\
    size_changed =3D 1;							\
+   if (DEVICE_GLYPH_P (d))						\
+     MARK_BUFFERS_CHANGED;						\
    (d)->size_changed =3D 1; } while (0)
  =

  #define MARK_DEVICE_FRAMES_FACES_CHANGED(d) do {			\
    Lisp_Object frmcons;							\
    DEVICE_FRAME_LOOP (frmcons, d)					\
      XFRAME (XCONS (frmcons)->car)->faces_changed =3D 1;			\
+   if (DEVICE_GLYPH_P (d))						\
+     MARK_BUFFERS_CHANGED;						\
    MARK_DEVICE_FACES_CHANGED (d); } while (0)
  =

  #define MARK_DEVICE_FRAME_CHANGED(d) do {				\
    frame_changed =3D 1;							\
+   if (DEVICE_GLYPH_P (d))						\
+     MARK_BUFFERS_CHANGED;						\
    (d)->frame_changed =3D 1; } while (0)
  =

  #define MARK_DEVICE_WINDOWS_CHANGED(d) do {				\
    windows_changed =3D 1;							\
+   if (DEVICE_GLYPH_P (d))						\
+     MARK_BUFFERS_CHANGED;						\
    (d)->windows_changed =3D 1; } while (0)
  =

  #define MARK_DEVICE_WINDOWS_STRUCTURE_CHANGED(d) do {			\
    windows_structure_changed =3D 1;					\
+   if (DEVICE_GLYPH_P (d))						\
+     MARK_BUFFERS_CHANGED;						\
    (d)->windows_structure_changed =3D 1; } while (0)
  =

  /* This turns out to be used heavily so we make it a macro to make it
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/emacs.c xemacs-19.15-b2-made/src/emacs.c
*** xemacs-19.15-b2/src/emacs.c	Sun Sep 15 15:37:57 1996
--- xemacs-19.15-b2-made/src/emacs.c	Mon Nov 11 23:08:22 1996
***************
*** 781,786 ****
--- 781,790 ----
        syms_of_scrollbar_ns ();
  #endif
  #endif /* HAVE_NEXTSTEP */
+       syms_of_frame_glyph ();
+       syms_of_glyphs_glyph ();
+       syms_of_objects_glyph ();
+       =

  =

  #ifdef SYMS_SYSTEM
        SYMS_SYSTEM;
***************
*** 856,861 ****
--- 860,873 ----
  #endif
  #endif /* HAVE_X_WINDOWS */
  =

+ =

+       console_type_create_glyph ();
+       console_type_create_device_glyph ();
+       console_type_create_frame_glyph ();
+       console_type_create_glyphs_glyph ();
+       console_type_create_objects_glyph ();
+       console_type_create_redisplay_glyph ();
+ =

        /* Now initialize the specifier types and associated symbols.
           Other than the first function below, the functions may
  	 make exactly the following function/macro calls:
***************
*** 870,875 ****
--- 882,888 ----
  =

        specifier_type_create_image ();
        specifier_type_create_objects ();
+       specifier_type_create_frame ();
  #ifdef HAVE_TOOLBARS
        specifier_type_create_toolbar ();
  #endif
***************
*** 903,908 ****
--- 916,922 ----
  #ifdef HAVE_X_WINDOWS
        image_instantiator_format_create_glyphs_x ();
  #endif /* HAVE_X_WINDOWS */
+       image_instantiator_format_create_glyphs_glyph ();
  =

        /* Now initialize the lstream types and associated symbols.
  	 Other than the first function below, the functions may
***************
*** 1071,1076 ****
--- 1085,1093 ----
  #endif
  #endif
  =

+       vars_of_frame_glyph ();
+       vars_of_glyphs_glyph ();
+ =

  #ifdef ENERGIZE
        vars_of_energize ();
  #endif
***************
*** 1133,1141 ****
  	 above. */
        complex_vars_of_glyphs ();
  =

!       /* This relies on the glyphs just created in the previous functio=
n,
! 	 and calls Fadd_spec_to_specifier(), which relies on various
  	 variables initialized above. */
  #ifdef HAVE_X_WINDOWS
        complex_vars_of_glyphs_x ();
  #endif
--- 1150,1159 ----
  	 above. */
        complex_vars_of_glyphs ();
  =

!       /* These rely on the glyphs just created in the previous function=
,
! 	 and call Fadd_spec_to_specifier(), which relies on various
  	 variables initialized above. */
+       complex_vars_of_glyphs_glyph ();
  #ifdef HAVE_X_WINDOWS
        complex_vars_of_glyphs_x ();
  #endif
***************
*** 1490,1495 ****
--- 1508,1519 ----
    if (!preparing_for_armageddon)
      {
        Lisp_Object concons;
+ =

+       /* Delete sub-consoles first, since they can depend on the
+ 	 parent console being in existence */
+       CONSOLE_LOOP (concons)
+ 	if (CONSOLE_GLYPH_P (XCONSOLE XCAR ((concons))))
+ 	  delete_console_internal (XCONSOLE (XCAR (concons)), 1, 1, 0);
  =

        /* Normally, go ahead and delete all the consoles now.
  	 Some unmentionably lame window systems (MS Wwwww...... eek,
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/emacsfns.h xemacs-19.15-b2-made/src/emacsfns.h
*** xemacs-19.15-b2/src/emacsfns.h	Thu Jun 20 20:56:16 1996
--- xemacs-19.15-b2-made/src/emacsfns.h	Tue Nov 12 09:02:24 1996
***************
*** 1109,1114 ****
--- 1109,1116 ----
  =

  extern Lisp_Object Qminibuffer;
  extern Lisp_Object Qunsplittable;
+ extern Lisp_Object Qmin_height;
+ extern Lisp_Object Qmin_width;
  extern Lisp_Object Qinternal_border_width;
  extern Lisp_Object Qtop_toolbar_shadow_color;
  extern Lisp_Object Qbottom_toolbar_shadow_color;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/event-Xt.c xemacs-19.15-b2-made/src/event-Xt.c
*** xemacs-19.15-b2/src/event-Xt.c	Mon Sep 16 17:48:04 1996
--- xemacs-19.15-b2-made/src/event-Xt.c	Mon Nov 11 23:26:20 1996
***************
*** 25,30 ****
--- 25,31 ----
  #include <config.h>
  #include "lisp.h"
  =

+ #include "console-glyph.h"
  #include "console-x.h"
  #include "lwlib.h"
  #include "EmacsFrame.h"
***************
*** 597,602 ****
--- 598,619 ----
  /*                  X to Emacs event conversion                        =
 */
  /**********************************************************************=
**/
  =

+ static struct frame *
+ x_maybe_forward_to_sub_frame (struct frame *f)
+ {
+   while (!NILP (FRAME_SELECTED_SUB_FRAME (f)))
+     f =3D XFRAME (FRAME_SELECTED_SUB_FRAME (f));
+   return f;
+ }
+ =

+ static struct frame *
+ x_maybe_unforward_from_sub_frame (struct frame *f)
+ {
+   while (FRAME_GLYPH_P (f))
+     f =3D XFRAME (FRAME_GLYPH_SELECTED_LOCALE (f));
+   return f;
+ }
+ =

  #if (defined(sun) || defined(__sun)) && defined(__GNUC__)
  # define SUNOS_GCC_L0_BUG
  #endif
***************
*** 795,808 ****
              Lisp_Object keysym;
              XKeyEvent *ev =3D &x_event->xkey;
              KeyCode keycode =3D ev->keycode;
! =

  =

              if (x_key_is_modifier_p (keycode, d)) /* it's a modifier ke=
y */
                return 0;
  =

              /* This used to compute the frame from the given X window a=
nd
                 store it here, but we really don't care about the frame.=
 */
!             emacs_event->channel =3D DEVICE_CONSOLE (d);
              keysym =3D x_to_emacs_keysym (x_event, 0);
  	      =

              /* If the emacs keysym is nil, then that means that the
--- 812,834 ----
              Lisp_Object keysym;
              XKeyEvent *ev =3D &x_event->xkey;
              KeyCode keycode =3D ev->keycode;
! 	    Lisp_Object sub, console;
  =

              if (x_key_is_modifier_p (keycode, d)) /* it's a modifier ke=
y */
                return 0;
  =

              /* This used to compute the frame from the given X window a=
nd
                 store it here, but we really don't care about the frame.=
 */
! 	    console =3D DEVICE_CONSOLE (d);
! 	    sub =3D CONSOLE_SELECTED_SUB_FRAME (XCONSOLE (console));
! 	    while (!NILP (sub))
! 	      {
! 		console =3D FRAME_CONSOLE (XFRAME (sub));
! 		if (EQ (console, Vselected_console))
! 		  break;
! 		sub =3D CONSOLE_SELECTED_SUB_FRAME (XCONSOLE (console));
! 	      }
!             emacs_event->channel =3D console;
              keysym =3D x_to_emacs_keysym (x_event, 0);
  	      =

              /* If the emacs keysym is nil, then that means that the
***************
*** 934,948 ****
        {
          struct frame *frame;
          Window w;
!     =

          switch (x_event->type)
            {
              /* Note: the number of cases could be reduced to two or
                 three by using xany.window, but it's perhaps clearer
                 and potentially more robust this way */
!           case SelectionRequest: w =3D x_event->xselectionrequest.owner=
; break;
!           case SelectionClear:   w =3D x_event->xselectionclear.window;=
  break;
!           case SelectionNotify:  w =3D x_event->xselection.requestor;  =
  break;
            case PropertyNotify:   w =3D x_event->xproperty.window;      =
  break;
            case ClientMessage:    w =3D x_event->xclient.window;        =
  break;
            case ConfigureNotify:  w =3D x_event->xconfigure.window;     =
  break;
--- 960,989 ----
        {
          struct frame *frame;
          Window w;
! 	int forward =3D 0;
! 	=

          switch (x_event->type)
            {
              /* Note: the number of cases could be reduced to two or
                 three by using xany.window, but it's perhaps clearer
                 and potentially more robust this way */
!           case SelectionRequest:
! 	    w =3D x_event->xselectionrequest.owner;
! 	    forward =3D 1;
! 	    break;
!           case SelectionClear:
! 	    w =3D x_event->xselectionclear.window;
! 	    forward =3D 1;
! 	    break;
!           case SelectionNotify:
! 	    w =3D x_event->xselection.requestor;
! 	    forward =3D 1;
! 	    break;
!           case FocusIn:
!           case FocusOut:
! 	    w =3D x_event->xfocus.window;
! 	    forward =3D 1;
! 	    break;
            case PropertyNotify:   w =3D x_event->xproperty.window;      =
  break;
            case ClientMessage:    w =3D x_event->xclient.window;        =
  break;
            case ConfigureNotify:  w =3D x_event->xconfigure.window;     =
  break;
***************
*** 952,963 ****
            case UnmapNotify:      w =3D x_event->xmap.window;           =
  break;
            case EnterNotify:
            case LeaveNotify:      w =3D x_event->xcrossing.window;      =
  break;
-           case FocusIn:
-           case FocusOut:         w =3D x_event->xfocus.window;         =
  break;
            case VisibilityNotify: w =3D x_event->xvisibility.window;    =
  break;
            default:               w =3D x_event->xany.window;           =
  break;
            }
          frame =3D x_any_window_to_frame (d, w);
         =

          if (!frame)
            return 0;
--- 993,1005 ----
            case UnmapNotify:      w =3D x_event->xmap.window;           =
  break;
            case EnterNotify:
            case LeaveNotify:      w =3D x_event->xcrossing.window;      =
  break;
            case VisibilityNotify: w =3D x_event->xvisibility.window;    =
  break;
            default:               w =3D x_event->xany.window;           =
  break;
            }
+ =

          frame =3D x_any_window_to_frame (d, w);
+ 	if (forward)
+ 	  frame =3D x_maybe_forward_to_sub_frame (frame);
         =

          if (!frame)
            return 0;
***************
*** 976,987 ****
  /*                           magic-event handling                      =
 */
  /**********************************************************************=
**/
  =

! static void
  handle_focus_event_1 (struct frame *f, int in_p)
  {
    /* On focus change, clear all memory of sticky modifiers
       to avoid non-intuitive behavior. */
!   clear_sticky_modifiers (XDEVICE (FRAME_DEVICE (f)));
  =

    /* We don't want to handle the focus change now, because we might
       be in an accept-process-output, sleep-for, or sit-for.  So
--- 1018,1030 ----
  /*                           magic-event handling                      =
 */
  /**********************************************************************=
**/
  =

! void
  handle_focus_event_1 (struct frame *f, int in_p)
  {
    /* On focus change, clear all memory of sticky modifiers
       to avoid non-intuitive behavior. */
!   clear_sticky_modifiers (XDEVICE (FRAME_DEVICE
! 				   (x_maybe_unforward_from_sub_frame (f))));
  =

    /* We don't want to handle the focus change now, because we might
       be in an accept-process-output, sleep-for, or sit-for.  So
***************
*** 995,1001 ****
      Lisp_Object frm;
      Lisp_Object conser;
      struct gcpro gcpro1;
-     =

      XSETFRAME (frm, f);
      conser =3D Fcons (frm, Fcons (FRAME_DEVICE (f), in_p ? Qt : Qnil));=

      GCPRO1 (conser);
--- 1038,1043 ----
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/event-stream.c xemacs-19.15-b2-made/src/event-stream.c
*** xemacs-19.15-b2/src/event-stream.c	Sun Sep  8 19:46:29 1996
--- xemacs-19.15-b2-made/src/event-stream.c	Mon Nov 11 23:25:41 1996
***************
*** 40,45 ****
--- 40,46 ----
  =

  #include "buffer.h"
  #include "commands.h"
+ #include "console-x.h"
  #include "device.h"
  #include "elhash.h"
  #include "events.h"
***************
*** 413,429 ****
       controlling terminal.  If that doesn't exist, however, then the
       user manually sent us a SIGINT, and we pretend the C-g came from
       the selected console. */
-   struct console *con;
- =

-   if (CONSOLEP (Vcontrolling_terminal) &&
-       CONSOLE_LIVE_P (XCONSOLE (Vcontrolling_terminal)))
-     con =3D XCONSOLE (Vcontrolling_terminal);
-   else
-     con =3D XCONSOLE (Fselected_console ());
  =

    if (sigint_happened)
      {
!       int ch =3D CONSOLE_QUIT_CHAR (con);
        sigint_happened =3D 0;
        Vquit_flag =3D Qnil;
        character_to_event (ch, event, con, 1);
--- 414,433 ----
       controlling terminal.  If that doesn't exist, however, then the
       user manually sent us a SIGINT, and we pretend the C-g came from
       the selected console. */
  =

    if (sigint_happened)
      {
!       struct console *con;
!       int ch;
! =

!       if (CONSOLEP (Vcontrolling_terminal) &&
! 	  CONSOLE_LIVE_P (XCONSOLE (Vcontrolling_terminal)))
! 	con =3D XCONSOLE (Vcontrolling_terminal);
!       else
! 	con =3D XCONSOLE (Fselected_console ());
! =

!       ch =3D CONSOLE_QUIT_CHAR (con);
! =

        sigint_happened =3D 0;
        Vquit_flag =3D Qnil;
        character_to_event (ch, event, con, 1);
***************
*** 1686,1699 ****
  =

        if (FRAMEP (focus_frame) && !EQ (frame, focus_frame))
  	{
  	  /* Oops, we missed a focus-out event. */
  	  DEVICE_FRAME_WITH_FOCUS_REAL (d) =3D Qnil;
! 	  redisplay_redraw_cursor (XFRAME (focus_frame), 1);
  	}
        DEVICE_FRAME_WITH_FOCUS_REAL (d) =3D frame;
        if (!EQ (frame, focus_frame))
  	{
! 	  redisplay_redraw_cursor (XFRAME (frame), 1);
  	}
      }
    else
--- 1690,1713 ----
  =

        if (FRAMEP (focus_frame) && !EQ (frame, focus_frame))
  	{
+ 	  struct frame *f;
+ 	  Drawable drw;
+ =

  	  /* Oops, we missed a focus-out event. */
  	  DEVICE_FRAME_WITH_FOCUS_REAL (d) =3D Qnil;
! 	  f =3D XFRAME (focus_frame);
! 	  drw =3D FRAMEMETH (f, drawable, (f));
! 	  redisplay_redraw_cursor (drw, f, 1);
  	}
        DEVICE_FRAME_WITH_FOCUS_REAL (d) =3D frame;
        if (!EQ (frame, focus_frame))
  	{
! 	  struct frame *f;
! 	  Drawable drw;
! 	  =

! 	  f =3D XFRAME (frame);
! 	  drw =3D FRAMEMETH (f, drawable, (f));
! 	  redisplay_redraw_cursor (drw, f, 1);
  	}
      }
    else
***************
*** 1704,1713 ****
        frame =3D DEVICE_FRAME_WITH_FOCUS_REAL (d);
        if (!NILP (frame))
  	{
! 	  DEVICE_FRAME_WITH_FOCUS_REAL (d) =3D Qnil;
! =

! 	  if (FRAME_LIVE_P (XFRAME (frame)))
! 	    redisplay_redraw_cursor (XFRAME (frame), 1);
  	}
      }
  }
--- 1718,1734 ----
        frame =3D DEVICE_FRAME_WITH_FOCUS_REAL (d);
        if (!NILP (frame))
  	{
! 	  struct frame *f;
! 	  =

! 	  f =3D XFRAME (frame);
!   	  DEVICE_FRAME_WITH_FOCUS_REAL (d) =3D Qnil;
!   =

! 	  if (FRAME_LIVE_P (f))
! 	    {
! 	      Drawable drw;
! 	      drw =3D FRAMEMETH (f, drawable, (f));
! 	      redisplay_redraw_cursor (drw, f, 1);
! 	    }
  	}
      }
  }
***************
*** 3637,3644 ****
    if (NILP (console))
      console =3D Vselected_console;
    else if (!EQ (console, Vselected_console))
!     Fselect_console (console);
! =

    command_builder =3D XCOMMAND_BUILDER (XCONSOLE (console)->command_bui=
lder);
    switch (XEVENT (event)->event_type) =

      {
--- 3658,3683 ----
    if (NILP (console))
      console =3D Vselected_console;
    else if (!EQ (console, Vselected_console))
!     {
!       Lisp_Object sub;
!   =

!       /* see if selected console is contained by console */
!       =

!       sub =3D CONSOLE_SELECTED_SUB_FRAME (XCONSOLE (console));
!       while (!NILP (sub))
! 	{
! 	  console =3D FRAME_CONSOLE (XFRAME (sub));
! 	  if (EQ (console, Vselected_console))
! 	    break;
! 	  sub =3D CONSOLE_SELECTED_SUB_FRAME (XCONSOLE (console));
! 	}
!       =

!       /* if console is not selected and does not contain selected conso=
le,
! 	 then select it here */
!       if (NILP (sub))
! 	Fselect_console (console);
!     }
!   =

    command_builder =3D XCOMMAND_BUILDER (XCONSOLE (console)->command_bui=
lder);
    switch (XEVENT (event)->event_type) =

      {
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/event-unixoid.c xemacs-19.15-b2-made/src/event-unixoid.c
*** xemacs-19.15-b2/src/event-unixoid.c	Mon May 27 18:33:39 1996
--- xemacs-19.15-b2-made/src/event-unixoid.c	Mon Nov 11 23:26:20 1996
***************
*** 90,95 ****
--- 90,96 ----
    else
      {
        character_to_event (ch, event, con, 1);
+       /* #### TTY SUB FRAMES ?? */
        event->channel =3D console;
        return 1;
      }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/events.c xemacs-19.15-b2-made/src/events.c
*** xemacs-19.15-b2/src/events.c	Sun Sep  8 19:46:35 1996
--- xemacs-19.15-b2-made/src/events.c	Mon Nov 11 23:26:20 1996
***************
*** 27,32 ****
--- 27,33 ----
  #include "lisp.h"
  #include "buffer.h"
  #include "console.h"
+ #include "console-glyph.h" /* for glyph_sub_frame_instance */
  #include "console-tty.h" /* for stuff in character_to_event */
  #include "device.h"
  #include "console-x.h"	/* for x_event_name prototype */
***************
*** 1396,1409 ****
    int pix_y =3D 0;
    int result;
    Lisp_Object frame;
! =

    int ret_x, ret_y, ret_obj_x, ret_obj_y;
    struct window *ret_w;
    Bufpos ret_bufp, ret_closest;
    Charcount ret_modeline_closest;
    Lisp_Object ret_obj1, ret_obj2;
!   =

    CHECK_LIVE_EVENT (event);
    if (XEVENT (event)->event_type =3D=3D pointer_motion_event)
      {
        pix_x =3D XEVENT (event)->event.motion.x;
--- 1397,1411 ----
    int pix_y =3D 0;
    int result;
    Lisp_Object frame;
!   =

    int ret_x, ret_y, ret_obj_x, ret_obj_y;
    struct window *ret_w;
    Bufpos ret_bufp, ret_closest;
    Charcount ret_modeline_closest;
    Lisp_Object ret_obj1, ret_obj2;
! =

    CHECK_LIVE_EVENT (event);
+   =

    if (XEVENT (event)->event_type =3D=3D pointer_motion_event)
      {
        pix_x =3D XEVENT (event)->event.motion.x;
***************
*** 1448,1453 ****
--- 1450,1518 ----
  			    || CONSP (ret_obj2)))
      abort ();
  =

+   if (GLYPHP (ret_obj1)
+       && XGLYPH_SUB_FRAMEP (ret_obj1))
+     {
+       /* recursively find event data for glyph sub frame */
+       Lisp_Object glyph =3D ret_obj1;
+       Lisp_Object frame;
+       int gresult;
+       int glyph_ret_x, glyph_ret_y, glyph_ret_obj_x, glyph_ret_obj_y;
+       struct window *glyph_ret_w;
+       Bufpos glyph_ret_bufp, glyph_ret_closest;
+       Charcount glyph_ret_modeline_closest;
+       Lisp_Object glyph_ret_obj1, glyph_ret_obj2;
+ =

+       while (1)
+ 	{
+ 	  frame =3D WINDOW_FRAME (ret_w);
+ 	  =

+ 	  frame =3D glyph_sub_frame_instance (glyph, frame);
+ 	  =

+ 	  if (NILP (frame))
+ 	    break;
+ 	  =

+ 	  gresult =3D pixel_to_glyph_translation (XFRAME (frame),
+ 						ret_obj_x, ret_obj_y,
+ 						&glyph_ret_x, &glyph_ret_y,
+ 						&glyph_ret_obj_x,
+ 						&glyph_ret_obj_y,
+ 						&glyph_ret_w, &glyph_ret_bufp,
+ 						&glyph_ret_closest,
+ 						&glyph_ret_modeline_closest,
+ 						&glyph_ret_obj1,
+ 						&glyph_ret_obj2);
+ 	  =

+ 	  if (gresult =3D=3D OVER_NOTHING || gresult =3D=3D OVER_OUTSIDE)
+ 	    glyph_ret_bufp =3D 0;
+ 	  else if (glyph_ret_w && NILP (glyph_ret_w->buffer))
+ 	    /* Why does this happen?  (Does it still happen?)
+ 	       I guess the window has gotten reused as a non-leaf... */
+ 	    glyph_ret_w =3D 0;
+ 	  =

+ 	  if (glyph_ret_w)
+ 	    {
+ 	      ret_x =3D glyph_ret_x;
+ 	      ret_y =3D glyph_ret_y;
+ 	      ret_w =3D glyph_ret_w;
+ 	      ret_obj_x =3D glyph_ret_obj_x;
+ 	      ret_obj_y =3D glyph_ret_obj_y;
+ 	      ret_bufp =3D glyph_ret_bufp;
+ 	      ret_closest =3D glyph_ret_closest;
+ 	      ret_modeline_closest =3D glyph_ret_modeline_closest;
+ 	      ret_obj1 =3D glyph_ret_obj1;
+ 	      ret_obj2 =3D glyph_ret_obj2;
+ 	      if (GLYPHP (ret_obj1)
+ 		  && XGLYPH_SUB_FRAMEP (ret_obj1))
+ 		glyph =3D ret_obj1;
+ 	      else
+ 		break;
+ 	    }
+ 	  else
+ 	    break;
+ 	}
+     }
+   =

    if (char_x)
      *char_x =3D ret_x;
    if (char_y)
***************
*** 1541,1547 ****
  =

    if (NILP (console))
      console =3D Vselected_console;
- =

    return XCONSOLE (console);
  }
  =

--- 1606,1611 ----
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/extents.c xemacs-19.15-b2-made/src/extents.c
*** xemacs-19.15-b2/src/extents.c	Sun Sep  8 19:45:30 1996
--- xemacs-19.15-b2-made/src/extents.c	Mon Nov 11 23:26:21 1996
***************
*** 421,426 ****
--- 421,428 ----
  Lisp_Object Qextentp;
  Lisp_Object Qextent_live_p;
  =

+ Lisp_Object Qextent;
+ =

  Lisp_Object Qend_closed;
  Lisp_Object Qstart_open;
  Lisp_Object Qall_extents_closed;
***************
*** 1578,1584 ****
     notify redisplay.  Maybe also recurse over all the extent's
     descendants. */
  =

! static void
  extent_changed_for_redisplay (EXTENT extent, int descendants_too)
  {
    Lisp_Object object;
--- 1580,1586 ----
     notify redisplay.  Maybe also recurse over all the extent's
     descendants. */
  =

! void
  extent_changed_for_redisplay (EXTENT extent, int descendants_too)
  {
    Lisp_Object object;
***************
*** 3634,3640 ****
  copy_extent (EXTENT original, Bytind from, Bytind to, Lisp_Object objec=
t)
  {
    EXTENT e;
! =

    e =3D make_extent_detached (object);
    if (from >=3D 0)
      set_extent_endpoints (e, from, to, Qnil);
--- 3636,3643 ----
  copy_extent (EXTENT original, Bytind from, Bytind to, Lisp_Object objec=
t)
  {
    EXTENT e;
!   Lisp_Object glyph;
!   =

    e =3D make_extent_detached (object);
    if (from >=3D 0)
      set_extent_endpoints (e, from, to, Qnil);
***************
*** 3676,3681 ****
--- 3679,3702 ----
      }
  #endif
  =

+   glyph =3D extent_begin_glyph (e);
+   if (GLYPHP (glyph) && XGLYPH_SUB_FRAMEP (glyph))
+     {
+       Lisp_Object extent;
+       XSETEXTENT (extent, e);
+       Fput (glyph, Qextent, Fcons (extent, Fget (glyph, Qextent, Qnil))=
);
+     }
+   else
+     {
+       glyph =3D extent_end_glyph (e);
+       if (GLYPHP (glyph) && XGLYPH_SUB_FRAMEP (glyph))
+ 	{
+ 	  Lisp_Object extent;
+ 	  XSETEXTENT (extent, e);
+ 	  Fput (glyph, Qextent, Fcons (extent, Fget (glyph, Qextent, Qnil)));
+ 	}
+     }
+   =

    return e;
  }
  =

***************
*** 4865,4875 ****
--- 4886,4943 ----
  =

    if (!endp)
      {
+       if (GLYPHP (glyph))
+ 	{
+ 	  Lisp_Object begin =3D extent_begin_glyph (extent);
+ =

+ 	  if (XGLYPH_SUB_FRAMEP (glyph))
+ 	    {
+ 	      if (!(GLYPHP (begin) && XGLYPH_SUB_FRAMEP (begin)))
+ 		{
+ 		  Lisp_Object e;
+ 		  XSETEXTENT (e, extent);
+ 		  Fput (glyph, Qextent,
+ 			Fcons (e, Fget (glyph, Qextent, Qnil)));
+ 		}
+ 	    }
+ 	  else if (GLYPHP (begin) && XGLYPH_SUB_FRAMEP (begin))
+ 	    {
+ 	      Lisp_Object e;
+ 	      XSETEXTENT (e, extent);
+ 	      Fput (glyph, Qextent, Fdelq (e,
+ 					   Fget (glyph, Qextent, Qnil)));
+ 	    }
+ 	}
        set_extent_begin_glyph (extent, glyph);
        extent_begin_glyph_layout (extent) =3D layout;
      }
    else
      {
+       if (GLYPHP (glyph))
+ 	{
+ 	  Lisp_Object end =3D extent_end_glyph (extent);
+       =

+ 	  if (XGLYPH_SUB_FRAMEP (glyph))
+ 	    {
+ 	      if (!(GLYPHP (end) && XGLYPH_SUB_FRAMEP (end)))
+ 		{
+ 		  Lisp_Object e;
+ 		  XSETEXTENT (e, extent);
+ 		  Fput (glyph, Qextent, Fcons (e,
+ 					       Fget (glyph, Qextent, Qnil)));
+ 		}
+ 	    }
+ 	  else
+ 	    {
+ 	      if (GLYPHP (end) && XGLYPH_SUB_FRAMEP (end))
+ 		{
+ 		  Lisp_Object e;
+ 		  XSETEXTENT (e, extent);
+ 		  Fput (glyph, Qextent, Fdelq (e,
+ 					       Fget (glyph, Qextent, Qnil)));
+ 		}
+ 	    }
+ 	}
        set_extent_end_glyph (extent, glyph);
        extent_end_glyph_layout (extent) =3D layout;
      }
***************
*** 6713,6718 ****
--- 6781,6788 ----
    defsymbol (&Qextentp, "extentp");
    defsymbol (&Qextent_live_p, "extent-live-p");
  =

+   defsymbol (&Qextent, "extent");
+   =

    defsymbol (&Qend_closed, "end-closed");
    defsymbol (&Qstart_open, "start-open");
    defsymbol (&Qall_extents_closed, "all-extents-closed");
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/extents.h xemacs-19.15-b2-made/src/extents.h
*** xemacs-19.15-b2/src/extents.h	Sun Apr 14 20:57:01 1996
--- xemacs-19.15-b2-made/src/extents.h	Mon Nov 11 23:26:22 1996
***************
*** 336,341 ****
--- 336,343 ----
  =

  extern Lisp_Object Qextent_live_p;
  =

+ extern Lisp_Object Qextent;
+ =

  extern int inside_undo;
  =

  struct extent_fragment *extent_fragment_new (Lisp_Object buffer_or_stri=
ng,
***************
*** 394,399 ****
--- 396,402 ----
  void detach_all_extents (Lisp_Object object);
  void set_extent_endpoints (EXTENT extent, Bytind s, Bytind e,
  			   Lisp_Object object);
+ void extent_changed_for_redisplay (EXTENT extent, int descendants_too);=

  =

  #ifdef ERROR_CHECK_EXTENTS
  void sledgehammer_extent_check (Lisp_Object obj);
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/faces.c xemacs-19.15-b2-made/src/faces.c
*** xemacs-19.15-b2/src/faces.c	Sun Sep  8 19:45:37 1996
--- xemacs-19.15-b2-made/src/faces.c	Mon Nov 11 23:26:22 1996
***************
*** 1936,1941 ****
--- 1936,1945 ----
      bg_inst_list =3D Fcons (Fcons (list1 (Qx), build_string ("white")),=

  			  bg_inst_list);
  #endif
+     fg_inst_list =3D Fcons (Fcons (list1 (Qglyph), build_string ("black=
")),
+ 			  fg_inst_list);
+     bg_inst_list =3D Fcons (Fcons (list1 (Qglyph), build_string ("white=
")),
+ 			  bg_inst_list);
  #ifdef HAVE_TTY
      fg_inst_list =3D Fcons (Fcons (list1 (Qtty), Fvector (0, 0)),
  			  fg_inst_list);
***************
*** 1978,1983 ****
--- 1982,1991 ----
  =

      for (--n; n >=3D 0; --n)
        inst_list =3D Fcons (Fcons (list1 (Qx), build_string (fonts[n])),=

+ 			 inst_list);
+ =

+     for (--n; n >=3D 0; --n)
+       inst_list =3D Fcons (Fcons (list1 (Qglyph), build_string (fonts[n=
])),
  			 inst_list);
  #endif
  #ifdef HAVE_TTY
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/frame-glyph.c xemacs-19.15-b2-made/src/frame-glyph.c
*** xemacs-19.15-b2/src/frame-glyph.c	Wed Dec 31 19:00:00 1969
--- xemacs-19.15-b2-made/src/frame-glyph.c	Mon Nov 11 23:26:22 1996
***************
*** 0 ****
--- 1,360 ----
+ /* Functions for GLYPH frames
+    Copyright (C) 1989, 1992, 1993, 1994, 1995 Free Software Foundation,=
 Inc.
+    Copyright (C) 1995, 1996 Ben Wing.
+    Copyright (C) 1996 Joel Peterson.
+ =

+ This file is part of XEmacs.
+ =

+ XEmacs is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+ =

+ XEmacs is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+ =

+ You should have received a copy of the GNU General Public License
+ along with XEmacs; see the file COPYING.  If not, write to
+ the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA.  */
+ =

+ /* Synched up with: Not in FSF. */
+ =

+ /* author: Joel Peterson (tarzan@aosi.com) */
+ =

+ #include <config.h>
+ #include "lisp.h"
+ =

+ #include "console-glyph.h"
+ #include "glyphs-glyph.h"
+ =

+ #include "buffer.h"
+ #include "events.h"
+ #include "extents.h"
+ #include "faces.h"
+ #include "frame.h"
+ #include "window.h"
+ =

+ /* Default properties to use when creating frames.  */
+ Lisp_Object Vdefault_glyph_frame_plist;
+ =

+ Lisp_Object Qlocale;
+ Lisp_Object Qsub_frames;
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*                          helper functions                           =
 */
+ /**********************************************************************=
**/
+ =

+ static void
+ allocate_glyph_frame_struct (struct frame *f)
+ {
+   f->frame_data =3D malloc_type_and_zero (struct glyph_frame);
+   FRAME_GLYPH_LOCALE (f) =3D Qnil;
+ }
+ =

+ struct frame *
+ decode_glyph_frame (Lisp_Object frame)
+ {
+   if (NILP (frame))
+     XSETFRAME (frame, selected_frame ());
+   CHECK_LIVE_FRAME (frame);
+   /* this will also catch dead frames, but putting in the above check
+      results in a more useful error */
+   CHECK_GLYPH_FRAME (frame);
+   return XFRAME (frame);
+ }
+ =

+ static Lisp_Object
+ make_sub_frame_image_instance (Lisp_Object device, struct device *d)
+ {
+   int font_height, font_width;
+   =

+   default_face_height_and_width (device, &font_height, &font_width);
+   =

+   /* device *d holds frame size -- silly */
+   /* device is the device in which this glyph will ultimately live */
+   return Fmake_image_instance (vector5 (Qsub_frame,
+ 					Q_height,
+ 					make_int (DEVICE_GLYPH_HEIGHT (d)
+ 						  * font_height),
+ 					Q_width,
+ 					make_int (DEVICE_GLYPH_WIDTH (d)
+ 						  * font_width)),
+ 			       device, Qnil, Qnil);
+ }
+ =

+ Lisp_Object
+ glyph_sub_frame_instance (Lisp_Object glyph, Lisp_Object locale)
+ {
+   Lisp_Object frames;
+   Lisp_Object frame;
+ =

+   frames =3D Fget (glyph, Qsub_frames, Qnil);
+   if (NILP (frames))
+     return Qnil;
+   frame =3D specifier_instance (frames, Qunbound, locale, ERROR_ME_NOT =
, 1,
+ 			      0, Qzero);
+   if (EQ (frame, Qunbound))
+     return Qnil;
+   return frame;
+ }
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*                          frame creation                             =
 */
+ /**********************************************************************=
**/
+ =

+ static void
+ glyph_init_frame_1 (struct frame *f, Lisp_Object props)
+ {
+   Lisp_Object device =3D FRAME_DEVICE (f);
+   struct device *d =3D XDEVICE (device);
+   struct frame *container;
+   Lisp_Object locale;
+   Lisp_Object frame;
+   Lisp_Object image;
+   Lisp_Object glyph;
+   /* specifiers */
+   Lisp_Object images;
+   Lisp_Object frames;
+   extern Lisp_Object Qremove_locale;
+ =

+   allocate_glyph_frame_struct (f);
+   =

+   locale =3D Fplist_get (props, Qlocale, Qnil);
+   if (NILP (locale))
+     {
+       /* set locale to locale of device */
+       locale =3D DEVICE_GLYPH_LOCALE (d);
+     }
+   =

+   glyph =3D DEVICE_GLYPH_GLYPH (d);
+ =

+   f->height =3D DEVICE_GLYPH_HEIGHT (d);
+   f->width =3D DEVICE_GLYPH_WIDTH (d);
+   =

+   f->visible =3D 1;
+ #ifdef HAVE_SCROLLBARS
+   f->scrollbar_on_left =3D 1;
+   f->scrollbar_on_top =3D 0;
+ #endif
+   SET_FRAME_CLEAR (f);
+   =

+   /* create an image instance in LOCALE for frame.
+      If one already exists, do we error (yes) or delete the old frame? =
*/
+   =

+   /* specifiers and images suck!!!  */
+   =

+   images =3D Fget (glyph, Qimage, Qnil);
+   image =3D Fspecifier_spec_list (images, locale, Qnil, Qt);
+   =

+   if (!NILP (image)
+       && Fassq (locale, image))
+     {
+       /* Error - see comment above */
+       signal_simple_error ("Sub frame already exists in locale", locale=
);
+     }
+ =

+   /* if we're not in a window or frame, then hope the device is an
+      X device, or we'll fail to instantiate the image.  If we are in
+      a window or frame, then climb up through all other containers unti=
l
+      we find the `root' frame; which will hopefully be an X frame. */
+   =

+   if (WINDOWP (locale))
+     {
+       container =3D XFRAME (XWINDOW (locale)->frame);
+     }
+   else if (FRAMEP (locale))
+     {
+       container =3D XFRAME (locale);
+     }
+   else if (BUFFERP (locale))
+     {
+       /* #### Should this be an error? */
+       container =3D NULL;
+     }
+   else
+     container =3D NULL;
+ =

+   if (container)
+     {
+       while (FRAME_GLYPH_P (container))
+ 	container =3D XFRAME (FRAME_GLYPH_CONTAINER (container));
+       device =3D container->device;
+     }
+   =

+   image =3D make_sub_frame_image_instance (device, d);
+   =

+   frames =3D Fget (glyph, Qsub_frames, Qnil);
+   =

+   FRAME_GLYPH_LOCALE (f) =3D locale;
+   XSETFRAME (frame, f);
+   Fadd_spec_to_specifier (images, image, locale, Qnil, Qremove_locale);=

+   Fadd_spec_to_specifier (frames, frame, locale, Qnil, Qremove_locale);=

+ }
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*                          frame properties                           =
 */
+ /**********************************************************************=
**/
+ =

+ static Lisp_Object
+ glyph_frame_property (struct frame *f, Lisp_Object property)
+ {
+   /* #### implement me! */
+   return Qunbound;
+ }
+ =

+ static int
+ glyph_internal_frame_property_p (struct frame *f, Lisp_Object property)=

+ {
+   /* #### implement me! */
+   return 0;
+ }
+ =

+ static Lisp_Object
+ glyph_frame_properties (struct frame *f)
+ {
+   /* #### implement me! */
+   Lisp_Object result =3D Qnil;
+ =

+   return result;
+ }
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*				Lisp functions				*/
+ /**********************************************************************=
**/
+ =

+ static void
+ glyph_mark_frame (struct frame *f, void (*markobj) (Lisp_Object))
+ {
+   ((markobj) (FRAME_GLYPH_LOCALE (f)));
+ }
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*			manipulating the GLYPH frame			*/
+ /**********************************************************************=
**/
+ =

+ static void
+ glyph_set_frame_size (struct frame *f, int cols, int rows)
+ {
+   /* #### implement me! */
+ }
+ =

+ static void
+ glyph_set_mouse_position (struct window *w, int x, int y)
+ {
+   /* #### implement me! - not possible without additional information
+      about which frame `w' is actually in since a single glyph frame ca=
n
+      get displayed in multiple places (or not at all). */
+ }
+ =

+ static int
+ glyph_get_mouse_position (struct device *d, Lisp_Object *frame, int *x,=
 int *y)
+ {
+   /* #### implement me! - not possible without additional information a=
bout
+      which parent frame `frame' is actually in since a single glyph fra=
me can
+      get displayed in multiple places (or not at all). */
+   =

+   return 0;
+ }
+ =

+ /* Destroy the glyph image instance of frame S.  */
+ static void
+ glyph_delete_frame (struct frame *f)
+ {
+   Lisp_Object locale =3D FRAME_GLYPH_LOCALE (f);
+   struct device *d =3D XDEVICE (f->device);
+   Lisp_Object glyph =3D DEVICE_GLYPH_GLYPH (d);
+   Lisp_Object frames;
+   Lisp_Object images;
+   =

+   images =3D Fget (glyph, Qimage, Qnil);
+   frames =3D Fget (glyph, Qsub_frames, Qnil);
+   =

+   Fremove_specifier (images, locale, Qnil, Qt);
+   Fremove_specifier (frames, locale, Qnil, Qt);
+   =

+   xfree (f->frame_data);
+   f->frame_data =3D 0;
+ }
+ =

+ /* Updates emacs focus */
+ static void
+ glyph_select_frame (struct device *d, Lisp_Object frame)
+ {
+   if (!EQ (frame, DEVICE_FRAME_WITH_FOCUS_REAL (d)))
+     handle_focus_event_1 (XFRAME (frame), 1);
+ }
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*                            initialization                           =
 */
+ /**********************************************************************=
**/
+ =

+ void
+ syms_of_frame_glyph (void)
+ {
+   defsymbol (&Qlocale, "locale");
+   defsymbol (&Qsub_frames, "sub-frames");
+ }
+ =

+ void
+ console_type_create_frame_glyph (void)
+ {
+   /* frame methods */
+   CONSOLE_HAS_METHOD (glyph, init_frame_1);
+   CONSOLE_HAS_METHOD (glyph, mark_frame);
+   /* CONSOLE_HAS_METHOD (glyph, focus_on_frame); */
+   CONSOLE_HAS_METHOD (glyph, delete_frame);
+   CONSOLE_HAS_METHOD (glyph, select_frame);
+   /* CONSOLE_HAS_METHOD (glyph, set_mouse_position); */
+   /* CONSOLE_HAS_METHOD (glyph, get_mouse_position);*/
+   /* CONSOLE_HAS_METHOD (glyph, set_frame_size); */
+   CONSOLE_HAS_METHOD (glyph, frame_property);
+   CONSOLE_HAS_METHOD (glyph, internal_frame_property_p);
+   CONSOLE_HAS_METHOD (glyph, frame_properties);
+   /*CONSOLE_HAS_METHOD (glyph, set_frame_properties);*/
+ }
+ =

+ void
+ vars_of_frame_glyph (void)
+ {
+   DEFVAR_LISP ("default-glyph-frame-plist", &Vdefault_glyph_frame_plist=
 /*
+ Plist of default frame-creation properties for frames that live in GLYP=
Hs.
+ These override what is specified in `default-frame-plist', but are over=
ridden
+ by the arguments to the particular call to `make-frame'.
+ =

+ Note: In many cases, properties of a frame are available as specifiers
+ instead of through the frame-properties mechanism.
+ =

+ Here is a list of recognized frame properties, other than those
+ documented in `set-frame-properties' (they can be queried and
+ set at any time, except as otherwise noted):
+ =

+   locale                        Locale of the frame.  This locale must =
reside
+ 				within the locale of the glyph device in which
+ 				the frame is being created; e.g. if the device
+ 				is in the locale of an X device, then the
+ 				glyph frame's locale may be any frame or window
+ 				located in that X device.  If locale is not
+ 				specified, it defaults to the locale of the
+ 				device.  This can only be set on frame
+ 				creation.
+   internal-border-width		Width of internal border around text area.
+   border-width			Width of external border around text area.
+   border-color			Color of external border around text area.
+   cursor-color			Color of text cursor.
+ =

+ See also `default-frame-plist', which specifies properties which apply
+ to all frames, not just GLYPH frames.
+ */ );
+   Vdefault_glyph_frame_plist =3D Qnil;
+ =

+   glyph_console_methods->device_specific_frame_props =3D &Vdefault_glyp=
h_frame_plist;
+ }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/frame-x.c xemacs-19.15-b2-made/src/frame-x.c
*** xemacs-19.15-b2/src/frame-x.c	Mon Sep 16 17:47:37 1996
--- xemacs-19.15-b2-made/src/frame-x.c	Mon Nov 11 23:36:09 1996
***************
*** 444,449 ****
--- 444,451 ----
    defi(Qborder_width, XtNborderWidth);
    defi(Qwidth, XtNwidth);
    defi(Qheight, XtNheight);
+   defi (Qmin_width, XtNminWidthCells);
+   defi (Qmin_height, XtNminHeightCells);
    defi(Qleft, XtNx);
    defi(Qtop, XtNy);
    =

***************
*** 701,706 ****
--- 703,709 ----
    Bool x_position_specified_p =3D False;
    Bool y_position_specified_p =3D False;
    Bool internal_border_width_specified =3D False;
+   Bool minsize_specified_p =3D False;
    Lisp_Object tail;
    Widget w =3D FRAME_X_TEXT_WIDGET (f);
    =

***************
*** 792,797 ****
--- 795,821 ----
  	      y_position_specified_p =3D True;
  	      continue;
  	    }
+ 	  /* if minimum width or height changes, we need to change
+ 	     the resources for the shell widget as well and call
+ 	     EmacsShellUpdateSizeHints.
+ 	     */
+ 	  if (!strcmp ((char *) string_data (XSTRING (str)), "minWidthCells"))=

+ 	    {
+ 	      minsize_specified_p =3D True;
+ 	      CHECK_INT (val);
+ 	      XtVaSetValues (FRAME_X_SHELL_WIDGET (f),
+ 			     (char *) string_data (XSTRING (str)),
+ 			     XINT (val), 0);
+ 	    }
+ 	  if (!strcmp ((char *) string_data (XSTRING (str)), "minHeightCells")=
)
+ 	    {
+ 	      minsize_specified_p =3D True;
+ 	      CHECK_INT (val);
+ 	      XtVaSetValues (FRAME_X_SHELL_WIDGET (f),
+ 			     (char *) string_data (XSTRING (str)),
+ 			     XINT (val), 0);
+ 	    }
+ 	  =

  	  /* Have you figured out by now that this entire function is
               one gigantic kludge? */
  	  if (!strcmp ((char *) string_data (XSTRING (str)),
***************
*** 886,891 ****
--- 910,917 ----
  	  }
        }
    }
+   if (minsize_specified_p)
+     EmacsShellUpdateSizeHints (FRAME_X_SHELL_WIDGET (f));
  }
  =

  static int frame_title_format_already_set;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/frame.c xemacs-19.15-b2-made/src/frame.c
*** xemacs-19.15-b2/src/frame.c	Mon Sep 16 17:48:15 1996
--- xemacs-19.15-b2-made/src/frame.c	Mon Nov 11 23:26:22 1996
***************
*** 27,32 ****
--- 27,34 ----
  #include <config.h>
  #include "lisp.h"
  =

+ #include "console-glyph.h"
+ =

  #include "buffer.h"             /* for Vbuffer_alist */
  #include "console.h"
  #include "events.h"
***************
*** 91,96 ****
--- 93,101 ----
  Lisp_Object Qborder_color;
  Lisp_Object Qborder_width;
  =

+ Lisp_Object Qmin_width;
+ Lisp_Object Qmin_height;
+ =

  Lisp_Object Qframep, Qframe_live_p;
  Lisp_Object Qframe_x_p, Qframe_tty_p;
  Lisp_Object Qdelete_frame;
***************
*** 308,316 ****
        if (!FRAMEP (con->default_minibuffer_frame)
  	  || ! FRAME_LIVE_P (XFRAME (con->default_minibuffer_frame)))
  	{
! 	  /* If there's no minibuffer frame to use, create one.  */
! 	  con->default_minibuffer_frame
! 	    =3D call1 (Qmake_initial_minibuffer_frame, device);
  	}
        mini_window =3D XFRAME (con->default_minibuffer_frame)->minibuffe=
r_window;
      }
--- 313,329 ----
        if (!FRAMEP (con->default_minibuffer_frame)
  	  || ! FRAME_LIVE_P (XFRAME (con->default_minibuffer_frame)))
  	{
! 	  if (FRAME_GLYPH_P (f))
! 	    {
! 	      Lisp_Object container;
! 	      container =3D CDFW_CONSOLE (FRAME_GLYPH_LOCALE (f));
! 	      con->default_minibuffer_frame =3D
! 		XCONSOLE (container)->default_minibuffer_frame;
! 	    }
! 	  else
! 	    /* If there's no minibuffer frame to use, create one.  */
! 	    con->default_minibuffer_frame
! 	      =3D call1 (Qmake_initial_minibuffer_frame, device);
  	}
        mini_window =3D XFRAME (con->default_minibuffer_frame)->minibuffe=
r_window;
      }
***************
*** 643,658 ****
  select_frame_1 (Lisp_Object frame)
  {
    struct frame *f =3D XFRAME (frame);
    Lisp_Object old_selected_frame =3D Fselected_frame (Qnil);
    =

    if (EQ (frame, old_selected_frame))
      return;
  =

    /* now select the frame's device */
!   set_device_selected_frame (XDEVICE (FRAME_DEVICE (f)), frame);
!   select_device_1 (FRAME_DEVICE (f));
  =

    update_frame_window_mirror (f);
  }
  =

  DEFUN ("select-frame", Fselect_frame, Sselect_frame, 1, 1, 0 /*
--- 656,715 ----
  select_frame_1 (Lisp_Object frame)
  {
    struct frame *f =3D XFRAME (frame);
+   Lisp_Object device =3D FRAME_DEVICE (f);
    Lisp_Object old_selected_frame =3D Fselected_frame (Qnil);
    =

    if (EQ (frame, old_selected_frame))
      return;
  =

    /* now select the frame's device */
!   set_device_selected_frame (XDEVICE (device), frame);
!   select_device_1 (device);
  =

    update_frame_window_mirror (f);
+   MAYBE_FRAMEMETH (f, select_frame, (XDEVICE (device), frame));
+ }
+ =

+ void
+ set_sub_frame_locale (Lisp_Object frame, Lisp_Object locale)
+ {
+   struct frame *f;
+   struct frame *l;
+   struct glyph_device *gd;
+   struct console *c;
+ =

+   f =3D XFRAME (frame);
+   =

+   if (NILP (locale))
+     {
+       locale =3D FRAME_GLYPH_LOCALE (f);
+       if (!FRAMEP (locale))
+ 	locale =3D Fselected_frame (Qnil);
+       =

+       assert (!NILP (locale));  /* this should never happen */
+     }
+   else
+     {
+       if (WINDOWP (locale))
+ 	{
+ 	  locale =3D XWINDOW (locale)->frame;
+ 	}
+       =

+       if (!FRAMEP (locale))
+ 	{
+ 	  signal_simple_error ("Locale must be a window or frame", locale);
+ 	}
+     }
+ =

+   /* make sure LOCALE is the selected frame on its device */
+   select_frame_1 (locale);
+   =

+   gd =3D DEVICE_GLYPH_DATA (XDEVICE (f->device));
+   gd->selected_locale =3D locale;
+   =

+   l =3D XFRAME (locale);
+   c =3D XCONSOLE (FRAME_CONSOLE (l));
+   c->selected_sub_frame =3D frame;
  }
  =

  DEFUN ("select-frame", Fselect_frame, Sselect_frame, 1, 1, 0 /*
***************
*** 671,685 ****
  {
    CHECK_LIVE_FRAME (frame);
  =

    /* select the frame's selected window.  This will call
!      selected_frame_1(). */
    Fselect_window (FRAME_SELECTED_WINDOW (XFRAME (frame)));
! =

    /* Nothing should be depending on the return value of this function.
       But, of course, there is stuff out there which is. */
    return frame;
  }
  =

  /* use this to retrieve the currently selected frame.  You should use
     this in preference to Fselected_frame (Qnil) unless you are prepared=

     to handle the possibility of there being no selected frame (this
--- 728,765 ----
  {
    CHECK_LIVE_FRAME (frame);
  =

+   if (FRAME_GLYPH_P (XFRAME (frame)))
+     set_sub_frame_locale (frame, Qnil);
+   =

    /* select the frame's selected window.  This will call
!      select_frame_1(). */
    Fselect_window (FRAME_SELECTED_WINDOW (XFRAME (frame)));
!   =

    /* Nothing should be depending on the return value of this function.
       But, of course, there is stuff out there which is. */
    return frame;
  }
  =

+ DEFUN ("select-sub-frame", Fselect_sub_frame, Sselect_sub_frame, 1, 2, =
0 /*
+ Select the sub-frame FRAME which lives in LOCALE.
+ LOCALE must be a window or frame.  If LOCALE is nil, then it is determi=
ned as
+ follows: if FRAME was created with a locale of frame, then FRAMEs local=
e is
+ used; otherwise, the currently selected frame is used.
+ =

+ See also select-frame.
+ */ )
+   (frame, locale)
+     Lisp_Object frame, locale;
+ {
+   CHECK_LIVE_FRAME (frame);
+   set_sub_frame_locale (frame, locale);
+   =

+   /* now select FRAME's selected window */
+   Fselect_window (FRAME_SELECTED_WINDOW (XFRAME (frame)));
+   =

+   return frame;
+ }
+ =

  /* use this to retrieve the currently selected frame.  You should use
     this in preference to Fselected_frame (Qnil) unless you are prepared=

     to handle the possibility of there being no selected frame (this
***************
*** 1643,1648 ****
--- 1723,1777 ----
    return val;
  }
  =

+ DEFUN ("pixel-to-position", Fpixel_to_position, Spixel_to_position,
+        2, 3, 0 /*
+ Return a list of position information giving the window and point of X =
and Y.
+ Nil is returned if pixel coordinates are not over a window.
+ List contents are
+   \(window point closest-point glyph extent glyph-position)
+ WINDOW is the window that pixel is over.
+ POINT is the buffer position that pixel is over.
+ CLOSEST-POINT is the closest buffer position that pixel is over.
+ GLYPH is the glyph \(if any) that pixel is over.
+ EXTENT is the extent \(if any) that pixel is over.
+ GLYPH-POSITION is a cons of X and Y pixel position relative to GLYPH.
+ =

+ X and Y are specified as pixel offsets from the upper left corner of FR=
AME.
+ */ )
+      (x, y, frame)
+      Lisp_Object x, y, frame;
+ {
+   int px, py, obj_x, obj_y;
+   struct window *w;
+   struct frame *f;
+   Bufpos bufpos, closest;
+   Charcount modeline_closest;
+   Lisp_Object window;
+   Lisp_Object obj1, obj2;
+ =

+   px =3D XINT (x);
+   py =3D XINT (y);
+   f =3D decode_frame (frame);
+ =

+   if (px >=3D 0 && py >=3D 0)
+     {
+       if (pixel_to_glyph_translation (f, px, py, &px, &py, &obj_x, &obj=
_y, &w,
+ 				      &bufpos, &closest, &modeline_closest,
+ 				      &obj1, &obj2)
+ 	  !=3D OVER_NOTHING)
+ 	{
+ 	  XSETWINDOW (window, w);
+ 	  return list6 (window,
+ 			bufpos ? make_int (bufpos):  Qnil,
+ 			closest ? make_int (closest):  Qnil,
+ 			obj1, obj2,
+ 			Fcons (obj_x, obj_y));
+ 	}
+     }
+ =

+   return Qnil;
+ }
+ =

  static int
  mouse_pixel_position_1 (struct device *d, Lisp_Object *frame,
  			int *x, int *y)
***************
*** 2152,2157 ****
--- 2281,2290 ----
  =

   width		Width of the frame, in characters.
  =

+  min-height     Minimum height of the frame, in lines.
+ =

+  min-width      Minimum width of the frame, in characters.
+  =

   minibuffer	Gives the minibuffer behavior for this frame.  Either
  		t (frame has its own minibuffer), `only' (frame is
  		a minibuffer-only frame), or a window (frame uses that
***************
*** 2235,2240 ****
--- 2368,2377 ----
  	store_minibuf_frame_prop (f, val);
        if (EQ (prop, Qunsplittable))
  	f->no_split =3D !NILP (val);
+       if (EQ (prop, Qmin_width))
+ 	f->minwidth =3D XINT (val);
+       if (EQ (prop, Qmin_height))
+ 	f->minheight =3D XINT (val);
        if (EQ (prop, Qbuffer_predicate))
  	f->buffer_predicate =3D val;
        if (SYMBOLP (prop) && EQ (Fbuilt_in_variable_type (prop),
***************
*** 2271,2276 ****
--- 2408,2415 ----
  	  || EQ (prop, Qbuffer_predicate)
  	  || EQ (prop, Qheight)
  	  || EQ (prop, Qwidth)
+ 	  || EQ (prop, Qmin_height)
+ 	  || EQ (prop, Qmin_width)
  	  || (SYMBOLP (prop) && EQ (Fbuilt_in_variable_type (prop),
  				    Qconst_specifier))
  	  || (SYMBOLP (prop) && !NILP (Fget (prop, Qconst_glyph_variable,
***************
*** 2317,2322 ****
--- 2456,2463 ----
  		      FRAME_MINIBUF_ONLY_P (f) ? Qonly :
  		      FRAME_MINIBUF_WINDOW (f)));
    FROB (Qunsplittable, FRAME_NO_SPLIT_P (f) ? Qt : Qnil);
+   FROB (Qmin_width, FRAME_MINWIDTH (f));
+   FROB (Qmin_height, FRAME_MINHEIGHT (f));
    FROB (Qbuffer_predicate, f->buffer_predicate);
  =

  #undef FROB
***************
*** 2386,2391 ****
--- 2527,2534 ----
                        FRAME_MINIBUF_ONLY_P (f) ? Qonly :
  		      FRAME_MINIBUF_WINDOW (f)));
    FROB (Qunsplittable, FRAME_NO_SPLIT_P (f) ? Qt : Qnil);
+   FROB (Qmin_width, FRAME_MINWIDTH (f));
+   FROB (Qmin_height, FRAME_MINHEIGHT (f));
    FROB (Qbuffer_predicate, f->buffer_predicate);
  =

  #undef FROB
***************
*** 2712,2717 ****
--- 2855,2862 ----
        FRAME_HEIGHT (f) =3D newheight;
        if (FRAME_TTY_P (f))
  	f->pixheight =3D newheight;
+       if (FRAME_GLYPH_P (f))
+ 	f->pixheight =3D new_pixheight;
      }
  =

    if (new_pixwidth)
***************
*** 2729,2734 ****
--- 2874,2881 ----
        FRAME_WIDTH (f) =3D newwidth;
        if (FRAME_TTY_P (f))
  	f->pixwidth =3D newwidth;
+       if (FRAME_GLYPH_P (f))
+ 	f->pixwidth =3D new_pixwidth;
      }
  =

    MARK_FRAME_TOOLBARS_CHANGED (f);
***************
*** 2905,2910 ****
--- 3052,3059 ----
  =

    defsymbol (&Qminibuffer, "minibuffer");
    defsymbol (&Qunsplittable, "unsplittable");
+   defsymbol (&Qmin_width, "min-width");
+   defsymbol (&Qmin_height, "min-height");
    defsymbol (&Qinternal_border_width, "internal-border-width");
    defsymbol (&Qtop_toolbar_shadow_color, "top-toolbar-shadow-color");
    defsymbol (&Qbottom_toolbar_shadow_color, "bottom-toolbar-shadow-colo=
r");
***************
*** 2978,2983 ****
--- 3127,3134 ----
    defsubr (&Sset_frame_size);
    defsubr (&Sset_frame_position);
    defsubr (&Sset_frame_pointer);
+   defsubr (&Sselect_sub_frame);
+   defsubr (&Spixel_to_position);
  }
  =

  void
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/frame.h xemacs-19.15-b2-made/src/frame.h
*** xemacs-19.15-b2/src/frame.h	Sun Jun  9 11:48:54 1996
--- xemacs-19.15-b2-made/src/frame.h	Mon Nov 11 23:26:22 1996
***************
*** 55,60 ****
--- 55,65 ----
    int height;
    int width;
  =

+   /* Minimum size of this frame, in units of characters.
+      This only makes sense for devices which can limit frame resizes */=

+   int minheight;
+   int minwidth;
+   =

    /* Size of this frame, in units of pixels. */
    int pixheight;
    int pixwidth;
***************
*** 245,250 ****
--- 250,261 ----
  #define CHECK_TTY_FRAME(z) CHECK_FRAME_TYPE (z, tty)
  #define CONCHECK_TTY_FRAME(z) CONCHECK_FRAME_TYPE (z, tty)
  =

+ #define FRAME_GLYPH_P(frm) CONSOLE_TYPESYM_GLYPH_P (FRAME_TYPE (frm))
+ #define CHECK_GLYPH_FRAME(z) CHECK_FRAME_TYPE (z, glyph)
+ #define CONCHECK_GLYPH_FRAME(z) CONCHECK_FRAME_TYPE (z, glyph)
+ =

+ #define FRAME_SUB_FRAME_P(frm) FRAME_GLYPH_P (frm)
+ =

  #define FRAME_STREAM_P(frm) CONSOLE_TYPESYM_STREAM_P (FRAME_TYPE (frm))=

  #define CHECK_STREAM_FRAME(z) CHECK_FRAME_TYPE (z, stream)
  #define CONCHECK_STREAM_FRAME(z) CONCHECK_FRAME_TYPE (z, stream)
***************
*** 317,322 ****
--- 328,335 ----
  #define FRAME_HAS_MINIBUF_P(f) ((f)->has_minibuffer)
  #define FRAME_HEIGHT(f) ((f)->height)
  #define FRAME_WIDTH(f) ((f)->width)
+ #define FRAME_MINHEIGHT(f) ((f)->minheight)
+ #define FRAME_MINWIDTH(f) ((f)->minwidth)
  #define FRAME_PIXHEIGHT(f) ((f)->pixheight)
  #define FRAME_PIXWIDTH(f) ((f)->pixwidth)
  #ifdef HAVE_SCROLLBARS
***************
*** 343,348 ****
--- 356,363 ----
    NON_LVALUE ((f)->last_nonminibuf_window)
  #define FRAME_SB_VCACHE(f) ((f)->sb_vcache)
  #define FRAME_SB_HCACHE(f) ((f)->sb_hcache)
+ #define FRAME_SELECTED_SUB_FRAME(f) \
+   (CONSOLE_SELECTED_SUB_FRAME (XCONSOLE (FRAME_CONSOLE (f))))
  =

  #if 0 /* FSFmacs */
  =

***************
*** 535,545 ****
--- 550,562 ----
  void hold_frame_size_changes (void);
  void unhold_one_frame_size_changes (struct frame *f);
  void unhold_frame_size_changes (void);
+ void set_sub_frame_locale (Lisp_Object frame, Lisp_Object locale);
  void select_frame_1 (Lisp_Object frame);
  struct frame *selected_frame (void);
  struct frame *device_selected_frame (struct device *d);
  struct frame *decode_frame (Lisp_Object frame);
  struct frame *decode_frame_or_selected (Lisp_Object cdf);
+ struct frame *decode_glyph_frame (Lisp_Object frame);
  Lisp_Object make_frame (struct frame *f);
  int other_visible_frames (struct frame *f);
  void delete_frame_internal (struct frame *f, int force,
***************
*** 555,559 ****
--- 572,583 ----
  void set_frame_selected_window (struct frame *f, Lisp_Object window);
  int is_surrogate_for_selected_frame (struct frame *f);
  void update_frame_icon (struct frame *f);
+ =

+ /* from frame-glyph.c */
+ =

+ Lisp_Object glyph_sub_frame_instance (Lisp_Object glyph, Lisp_Object lo=
cale);
+ =

+ /* frome event-Xt.c */
+ void handle_focus_event_1 (struct frame *f, int in_p);
  =

  #endif /* _XEMACS_FRAME_H_ */
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/general.c xemacs-19.15-b2-made/src/general.c
*** xemacs-19.15-b2/src/general.c	Wed May 15 21:20:27 1996
--- xemacs-19.15-b2-made/src/general.c	Mon Nov 11 23:34:45 1996
***************
*** 80,85 ****
--- 80,86 ----
  Lisp_Object Qgeneric;
  Lisp_Object Qgeometry;
  Lisp_Object Qglobal;
+ Lisp_Object Qglyph;
  Lisp_Object Qheight;
  Lisp_Object Qhighlight;
  Lisp_Object Qid;
***************
*** 203,208 ****
--- 204,210 ----
    defsymbol (&Qgeneric, "generic");
    defsymbol (&Qgeometry, "geometry");
    defsymbol (&Qglobal, "global");
+   defsymbol (&Qglyph, "glyph");
    defsymbol (&Qheight, "height");
    defsymbol (&Qhighlight, "highlight");
    defsymbol (&Qid, "id");
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/glyphs-glyph.c xemacs-19.15-b2-made/src/glyphs-glyph.c
*** xemacs-19.15-b2/src/glyphs-glyph.c	Wed Dec 31 19:00:00 1969
--- xemacs-19.15-b2-made/src/glyphs-glyph.c	Mon Nov 11 23:26:23 1996
***************
*** 0 ****
--- 1,356 ----
+ /* GLYPH-specific Lisp objects.
+    Copyright (C) 1993, 1994 Free Software Foundation, Inc.
+    Copyright (C) 1995 Board of Trustees, University of Illinois.
+    Copyright (C) 1995 Tinker Systems
+    Copyright (C) 1995, 1996 Ben Wing
+    Copyright (C) 1995 Sun Microsystems
+    Copyright (C) 1996 Joel Peterson.
+ =

+ This file is part of XEmacs.
+ =

+ XEmacs is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+ =

+ XEmacs is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+ =

+ You should have received a copy of the GNU General Public License
+ along with XEmacs; see the file COPYING.  If not, write to
+ the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA.  */
+ =

+ /* Synched up with: Not in FSF. */
+ =

+ /* author: Joel Peterson (tarzan@aosi.com) */
+ =

+ #include <config.h>
+ #include "lisp.h"
+ =

+ #include "bitmaps.h"
+ #include "buffer.h"
+ #include "console-glyph.h"
+ #include "frame.h"
+ #include "glyphs.h"
+ #include "glyphs-glyph.h"
+ #include "glyphs-x.h"
+ #include "insdel.h"
+ #include "opaque.h"
+ =

+ #include "sysfile.h"
+ =

+ #include <setjmp.h>
+ =

+ Lisp_Object Q_width;
+ Lisp_Object Q_height;
+ =

+ DEFINE_IMAGE_INSTANTIATOR_FORMAT (sub_frame);
+ =

+ Lisp_Object Qsub_framep;
+ =

+ =0C
+ =

+ /**********************************************************************=
**/
+ /*                      image instance methods                         =
 */
+ /**********************************************************************=
**/
+ =

+ static void
+ glyph_print_image_instance (struct Lisp_Image_Instance *p,
+ 			    Lisp_Object printcharfun,
+ 			    int escapeflag)
+ {
+   Lisp_Object device =3D p->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   p->device =3D locale;
+   MAYBE_DEVMETH (XDEVICE (locale), print_image_instance,
+ 		 (p, printcharfun, escapeflag));
+   p->device =3D device;
+ }
+ =

+ static void
+ glyph_finalize_image_instance (struct Lisp_Image_Instance *p)
+ {
+   Lisp_Object device =3D p->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   p->device =3D locale;
+   MAYBE_DEVMETH (XDEVICE (locale), finalize_image_instance, (p));
+   p->device =3D device;
+ }
+ =

+ static int
+ glyph_image_instance_equal (struct Lisp_Image_Instance *p1,
+ 			    struct Lisp_Image_Instance *p2, int depth)
+ {
+   Lisp_Object device =3D p1->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   int result;
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   p1->device =3D locale;
+   p2->device =3D locale;
+   result =3D DEVMETH_OR_GIVEN (XDEVICE (locale), image_instance_equal,
+ 			     (p1, p2, depth), 1);
+   p1->device =3D device;
+   p2->device =3D device;
+   return result;
+ }
+ =

+ static unsigned long
+ glyph_image_instance_hash (struct Lisp_Image_Instance *p, int depth)
+ {
+   Lisp_Object device =3D p->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   unsigned long result;
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   p->device =3D locale;
+   result =3D DEVMETH (XDEVICE (locale), image_instance_hash,
+ 		    (p, depth));
+   p->device =3D device;
+   return result;
+ }
+ =

+ static int
+ glyph_colorize_image_instance (Lisp_Object image_instance,
+ 			       Lisp_Object foreground, Lisp_Object background)
+ {
+   struct Lisp_Image_Instance *p=3D XIMAGE_INSTANCE (image_instance);
+   Lisp_Object device =3D p->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   int result;
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   p->device =3D locale;
+   result =3D DEVMETH (XDEVICE (locale), colorize_image_instance,
+ 		    (image_instance, foreground, background));
+   p->device =3D device;
+   return result;
+ }
+ =

+ =

+ =0C
+ =

+ /**********************************************************************=

+  *                         SUB_FRAME                                  *=

+  **********************************************************************=
/
+ =

+ static void
+ sub_frame_validate (Lisp_Object instantiator)
+ {
+   if (NILP (find_keyword_in_vector (instantiator, Q_width)) ||
+       NILP (find_keyword_in_vector (instantiator, Q_height)))
+     signal_simple_error ("Must supply both :width and :height",
+ 			 instantiator);
+ }
+ =

+ static int
+ sub_frame_possible_dest_types ()
+ {
+   return IMAGE_COLOR_PIXMAP_MASK;
+ }
+ =

+ #ifdef HAVE_X_WINDOWS
+ #include "console-x.h"
+ #include "glyphs-x.h"
+ #include "objects-x.h"
+ #include "xmu.h"
+ #endif
+ =

+ static void
+ sub_frame_instantiate (Lisp_Object image_instance, Lisp_Object instanti=
ator,
+ 		       Lisp_Object pointer_fg, Lisp_Object pointer_bg,
+ 		       int dest_mask)
+ {
+   /* This is bogus, but sub-frames can only be pixmaps, which only exis=
t
+      in X, so ....  Eventually, this should be made more portable. */
+   =

+ #ifdef HAVE_X_WINDOWS
+   =

+   /* This function can GC */
+   struct Lisp_Image_Instance *ii =3D XIMAGE_INSTANCE (image_instance);
+   Lisp_Object width =3D find_keyword_in_vector (instantiator, Q_width);=

+   Lisp_Object height =3D find_keyword_in_vector (instantiator, Q_height=
);
+   Lisp_Object locale =3D IMAGE_INSTANCE_DEVICE (ii);
+   /*
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (XDEVICE (device));
+   */
+   Display *dpy;
+   Screen *xs;
+   enum image_instance_type type;
+   Dimension d;
+ =

+   /*
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+     */
+   =

+   if (!DEVICE_X_P (XDEVICE (locale)))
+     signal_simple_error ("Not a sub-frame in an X device", locale);
+   =

+   dpy =3D DEVICE_X_DISPLAY (XDEVICE (locale));
+   xs =3D DefaultScreenOfDisplay (dpy);
+ =

+   d =3D DefaultDepthOfScreen (xs);
+   =

+   if (dest_mask & IMAGE_COLOR_PIXMAP_MASK)
+     type =3D IMAGE_COLOR_PIXMAP;
+   else
+     incompatible_image_types (instantiator, dest_mask,
+ 			      IMAGE_COLOR_PIXMAP_MASK);
+   =

+   x_initialize_pixmap_image_instance (ii, type);
+   =

+   IMAGE_INSTANCE_X_MASK (ii) =3D 0;
+   IMAGE_INSTANCE_X_PIXELS (ii) =3D 0;
+   IMAGE_INSTANCE_X_NPIXELS (ii) =3D 0;
+   IMAGE_INSTANCE_PIXMAP_WIDTH (ii) =3D XINT (width);
+   IMAGE_INSTANCE_PIXMAP_HEIGHT (ii) =3D XINT (height);
+   IMAGE_INSTANCE_PIXMAP_FILENAME (ii) =3D Qnil;
+ =

+   switch (type)
+     {
+     case IMAGE_MONO_PIXMAP:
+       break;
+ =

+     case IMAGE_COLOR_PIXMAP:
+       {
+ 	IMAGE_INSTANCE_PIXMAP_DEPTH (ii) =3D d;
+ 	IMAGE_INSTANCE_X_PIXMAP (ii) =3D XCreatePixmap (dpy,
+ 						      RootWindowOfScreen (xs),
+ 						      XINT (width),
+ 						      XINT (height), d);
+       }
+       break;
+     default:
+       abort ();
+     }
+ #endif /* HAVE_X_WINDOWS */
+ }
+ =

+ =0C
+ /**********************************************************************=
******
+  *                         Frame Specifier Object                      =
     *
+  **********************************************************************=
******/
+ =

+ DEFINE_SPECIFIER_TYPE (frame);
+ =

+ /* Validate a frame instantiator. */
+ =

+ static void
+ frame_validate (Lisp_Object instantiator)
+ {
+   CHECK_FRAME (instantiator);
+ }
+ =

+ static void
+ frame_after_change (Lisp_Object specifier, Lisp_Object locale)
+ {
+   /* #### do anything here? */
+ }
+ =

+ DEFUN ("frame-specifier-p", Fframe_specifier_p, Sframe_specifier_p, 1, =
1, 0 /*
+ Return non-nil if OBJECT is an frame specifier.
+ */ )
+      (object)
+      Lisp_Object object;
+ {
+   return (FRAME_SPECIFIERP (object) ? Qt : Qnil);
+ }
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*                            initialization                           =
 */
+ /**********************************************************************=
**/
+ =

+ void
+ syms_of_glyphs_glyph (void)
+ {
+   defsymbol (&Qsub_framep, "sub-framep");
+ =

+   defkeyword (&Q_width, ":width");
+   defkeyword (&Q_height, ":height");
+ =

+   defsubr (&Sframe_specifier_p);
+ }
+ =

+ void
+ console_type_create_glyphs_glyph (void)
+ {
+   /* image methods */
+ =

+   CONSOLE_HAS_METHOD (glyph, print_image_instance);
+   CONSOLE_HAS_METHOD (glyph, finalize_image_instance);
+   CONSOLE_HAS_METHOD (glyph, image_instance_equal);
+   CONSOLE_HAS_METHOD (glyph, image_instance_hash);
+   CONSOLE_HAS_METHOD (glyph, colorize_image_instance);
+ }
+ =

+ void
+ image_instantiator_format_create_glyphs_glyph (void)
+ {
+   INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (sub_frame, "sub-frame");
+ =

+   IIFORMAT_HAS_METHOD (sub_frame, validate);
+   IIFORMAT_HAS_METHOD (sub_frame, possible_dest_types);
+   IIFORMAT_HAS_METHOD (sub_frame, instantiate);
+ =

+   IIFORMAT_VALID_KEYWORD (sub_frame, Q_width, check_valid_int);
+   IIFORMAT_VALID_KEYWORD (sub_frame, Q_height, check_valid_int);
+ }
+ =

+ void
+ vars_of_glyphs_glyph (void)
+ {
+   Fprovide (Qsub_frame);
+ }
+ =

+ void
+ specifier_type_create_frame (void)
+ {
+   /* frame specifiers */
+ =

+   INITIALIZE_SPECIFIER_TYPE (frame, "frame", "framep");
+   SPECIFIER_HAS_METHOD (frame, validate);
+ }
+ =

+ void
+ complex_vars_of_glyphs_glyph (void)
+ {
+ #define BUILD_GLYPH_INST(variable, name)			\
+   Fadd_spec_to_specifier					\
+     (GLYPH_IMAGE (XGLYPH (variable)),				\
+      vector3 (Qxbm, Q_data,					\
+ 	      list3 (make_int (name##_width),			\
+ 		     make_int (name##_height),			\
+ 		     make_ext_string (name##_bits,		\
+ 				      sizeof (name##_bits),	\
+ 				      FORMAT_BINARY))),		\
+      Qglobal, Qglyph, Qnil)
+ =

+   BUILD_GLYPH_INST (Vtruncation_glyph, truncator);
+   BUILD_GLYPH_INST (Vcontinuation_glyph, continuer);
+ =

+ #undef BUILD_GLYPH_INST
+ }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/glyphs-glyph.h xemacs-19.15-b2-made/src/glyphs-glyph.h
*** xemacs-19.15-b2/src/glyphs-glyph.h	Wed Dec 31 19:00:00 1969
--- xemacs-19.15-b2-made/src/glyphs-glyph.h	Mon Nov 11 23:26:23 1996
***************
*** 0 ****
--- 1,43 ----
+ /* Define GLYPH specific objects for XEmacs.
+    Copyright (C) 1989, 1992, 1993, 1994, 1995 Free Software Foundation,=
 Inc.
+    Copyright (C) 1994, 1995 Board of Trustees, University of Illinois.
+    Copyright (C) 1996 Joel Peterson
+ =

+ This file is part of XEmacs.
+ =

+ XEmacs is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+ =

+ XEmacs is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+ =

+ You should have received a copy of the GNU General Public License
+ along with XEmacs; see the file COPYING.  If not, write to
+ the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA.  */
+ =

+ /* Synched up with: Not in FSF. */
+ =

+ =

+ /* Authorship:
+    Joel Peterson (tarzan@aosi.com), November 1996
+  */
+ =

+ #ifndef _XEMACS_GLYPHS_GLYPH_H_
+ #define _XEMACS_GLYPHS_GLYPH_H_
+ =

+ #include "lisp.h"
+ #include "specifier.h"
+ =

+ extern Lisp_Object Qsub_frame;
+ extern Lisp_Object Q_width;
+ extern Lisp_Object Q_height;
+ =

+ #define FRAME_SPECIFIERP(x) XSPECIFIER_TYPE (x, frame)
+ =

+ extern Lisp_Object Qsub_framep;
+ #endif
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/glyphs-x.c xemacs-19.15-b2-made/src/glyphs-x.c
*** xemacs-19.15-b2/src/glyphs-x.c	Sun Sep 15 17:23:43 1996
--- xemacs-19.15-b2-made/src/glyphs-x.c	Mon Nov 11 23:26:23 1996
***************
*** 155,161 ****
  =

    if (DEVICE_LIVE_P (XDEVICE (p->device)))
      {
!       Screen *scr =3D LISP_DEVICE_TO_X_SCREEN (IMAGE_INSTANCE_DEVICE (p=
));
  =

        if (IMAGE_INSTANCE_X_PIXMAP (p))
  	XFreePixmap (DisplayOfScreen (scr), IMAGE_INSTANCE_X_PIXMAP (p));
--- 155,162 ----
  =

    if (DEVICE_LIVE_P (XDEVICE (p->device)))
      {
!       Lisp_Object device =3D x_sub_frame_device_to_x_device (p->device)=
;
!       Screen *scr =3D LISP_DEVICE_TO_X_SCREEN (device);
  =

        if (IMAGE_INSTANCE_X_PIXMAP (p))
  	XFreePixmap (DisplayOfScreen (scr), IMAGE_INSTANCE_X_PIXMAP (p));
***************
*** 235,241 ****
     instance is already set -- this is the case when instantiate
     methods are called. */
  =

! static void
  x_initialize_pixmap_image_instance (struct Lisp_Image_Instance *ii,
  				    enum image_instance_type type)
  {
--- 236,242 ----
     instance is already set -- this is the case when instantiate
     methods are called. */
  =

! void
  x_initialize_pixmap_image_instance (struct Lisp_Image_Instance *ii,
  				    enum image_instance_type type)
  {
***************
*** 526,531 ****
--- 527,533 ----
    Lisp_Object device =3D XIMAGE_INSTANCE_DEVICE (image_instance);
    XColor xfg, xbg;
  =

+   device =3D x_sub_frame_device_to_x_device (device);
    generate_cursor_fg_bg (device, &foreground, &background, &xfg, &xbg);=

    if (!NILP (foreground) || !NILP (background))
      {
***************
*** 577,582 ****
--- 579,585 ----
    Drawable d;
    Pixmap pixmap;
  =

+   device =3D x_sub_frame_device_to_x_device (device);
    if (!DEVICE_X_P (XDEVICE (device)))
      signal_simple_error ("Not an X device", device);
  =

***************
*** 865,870 ****
--- 868,875 ----
    Screen *scr;
    enum image_instance_type type;
  =

+   device =3D x_sub_frame_device_to_x_device (device);
+ =

    if (!DEVICE_X_P (XDEVICE (device)))
      signal_simple_error ("Not an X device", device);
  =

***************
*** 1005,1012 ****
--- 1010,1019 ----
  =

    if (!NILP (mask_data))
      {
+       Lisp_Object device =3D IMAGE_INSTANCE_DEVICE (ii);
        GET_C_STRING_BINARY_DATA_ALLOCA (XCAR (XCDR (XCDR (mask_data))),
  				       gcc_may_you_rot_in_hell);
+       device =3D x_sub_frame_device_to_x_device (device);
        mask =3D
  	pixmap_from_xbm_inline (IMAGE_INSTANCE_DEVICE (ii),
  				XINT (XCAR (mask_data)),
***************
*** 1256,1261 ****
--- 1263,1270 ----
     */
    struct my_jpeg_error_mgr jerr;
  =

+   device =3D x_sub_frame_device_to_x_device (device);
+ =

    if (!DEVICE_X_P (XDEVICE (device)))
      signal_simple_error ("Not an X device", device);
  =

***************
*** 1713,1718 ****
--- 1722,1729 ----
    struct gif_unwind_data unwind;
    int speccount =3D specpdl_depth ();
  =

+   device =3D x_sub_frame_device_to_x_device (device);
+ =

    if (!DEVICE_X_P (XDEVICE (device)))
      signal_simple_error ("Not an X device", device);
  =

***************
*** 1971,1976 ****
--- 1982,1989 ----
    png_struct *png_ptr;
    png_info *info_ptr;
  =

+   device =3D x_sub_frame_device_to_x_device (device);
+ =

    if (!DEVICE_X_P (XDEVICE (device)))
      signal_simple_error ("Not an X device", device);
  =

***************
*** 2581,2586 ****
--- 2594,2601 ----
    int force_mono;
    unsigned int w, h;
  =

+   device =3D x_sub_frame_device_to_x_device (device);
+ =

    if (!DEVICE_X_P (XDEVICE (device)))
      signal_simple_error ("Not an X device", device);
  =

***************
*** 3244,3249 ****
--- 3259,3266 ----
    int count;
    Lisp_Object foreground, background;
  =

+   device =3D x_sub_frame_device_to_x_device (device);
+ =

    if (!DEVICE_X_P (XDEVICE (device)))
      signal_simple_error ("Not an X device", device);
  =

***************
*** 3339,3344 ****
--- 3356,3363 ----
    CONST char *name_ext;
    Lisp_Object foreground, background;
  =

+   device =3D x_sub_frame_device_to_x_device (device);
+ =

    if (!DEVICE_X_P (XDEVICE (device)))
      signal_simple_error ("Not an X device", device);
  =

***************
*** 3367,3373 ****
  			   Lisp_Object foreground, Lisp_Object background)
  {
    struct Lisp_Image_Instance *p;
! =

    p =3D XIMAGE_INSTANCE (image_instance);
  =

    switch (IMAGE_INSTANCE_TYPE (p))
--- 3386,3393 ----
  			   Lisp_Object foreground, Lisp_Object background)
  {
    struct Lisp_Image_Instance *p;
!   Lisp_Object device;
!   =

    p =3D XIMAGE_INSTANCE (image_instance);
  =

    switch (IMAGE_INSTANCE_TYPE (p))
***************
*** 3383,3390 ****
        return 0;
      }
  =

    {
!     Display *dpy =3D DEVICE_X_DISPLAY (XDEVICE (IMAGE_INSTANCE_DEVICE (=
p)));
      Screen *scr =3D DefaultScreenOfDisplay (dpy);
      Dimension d =3D DefaultDepthOfScreen (scr);
      Pixmap new =3D XCreatePixmap (dpy, RootWindowOfScreen (scr),
--- 3403,3412 ----
        return 0;
      }
  =

+   device =3D IMAGE_INSTANCE_DEVICE (p);
+   device =3D x_sub_frame_device_to_x_device (device);
    {
!     Display *dpy =3D DEVICE_X_DISPLAY (XDEVICE (device));
      Screen *scr =3D DefaultScreenOfDisplay (dpy);
      Dimension d =3D DefaultDepthOfScreen (scr);
      Pixmap new =3D XCreatePixmap (dpy, RootWindowOfScreen (scr),
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/glyphs-x.h xemacs-19.15-b2-made/src/glyphs-x.h
*** xemacs-19.15-b2/src/glyphs-x.h	Sun Mar 31 19:17:08 1996
--- xemacs-19.15-b2-made/src/glyphs-x.h	Mon Nov 11 23:26:24 1996
***************
*** 72,77 ****
--- 72,80 ----
  #define XIMAGE_INSTANCE_X_NPIXELS(i) \
    IMAGE_INSTANCE_X_NPIXELS (XIMAGE_INSTANCE (i))
  =

+ void x_initialize_pixmap_image_instance (struct Lisp_Image_Instance *ii=
,
+ 					 enum image_instance_type type);
+ =

  /**********************************************************************=
******
   *                            Subwindow Object                         =
     *
   **********************************************************************=
******/
***************
*** 95,100 ****
--- 98,105 ----
  =

    int being_displayed;		/* used to detect when needs to be unmapped */
  };
+ =

+ extern Lisp_Object Qxbm;
  =

  #endif /* HAVE_X_WINDOWS */
  #endif /* _XEMACS_GLYPHS_X_H_ */
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/glyphs.c xemacs-19.15-b2-made/src/glyphs.c
*** xemacs-19.15-b2/src/glyphs.c	Mon Jun 17 08:03:36 1996
--- xemacs-19.15-b2-made/src/glyphs.c	Mon Nov 11 23:26:24 1996
***************
*** 31,39 ****
--- 31,41 ----
  #include "buffer.h"
  #include "device.h"
  #include "elhash.h"
+ #include "extents.h"
  #include "faces.h"
  #include "frame.h"
  #include "glyphs.h"
+ #include "glyphs-glyph.h"
  #include "objects.h"
  #include "redisplay.h"
  #include "window.h"
***************
*** 51,57 ****
  Lisp_Object Qconst_glyph_variable;
  =

  /* Qtext, Qpointer defined in general.c */
! Lisp_Object Qmono_pixmap, Qcolor_pixmap, Qsubwindow;
  =

  Lisp_Object Vcurrent_display_table;
  =

--- 53,59 ----
  Lisp_Object Qconst_glyph_variable;
  =

  /* Qtext, Qpointer defined in general.c */
! Lisp_Object Qmono_pixmap, Qcolor_pixmap, Qsubwindow, Qsub_frame;
  =

  Lisp_Object Vcurrent_display_table;
  =

***************
*** 145,151 ****
  Given an IMAGE-INSTANTIATOR-FORMAT, return non-nil if it is valid.
  Valid formats are some subset of 'nothing, 'string, 'formatted-string, =
'xpm,
  'xbm, 'xface, 'gif, 'jpeg, 'png, 'tiff, 'cursor-font, 'font, 'autodetec=
t,
! and 'subwindow, depending on how XEmacs was compiled.
  */ )
       (image_instantiator_format)
       Lisp_Object image_instantiator_format;
--- 147,153 ----
  Given an IMAGE-INSTANTIATOR-FORMAT, return non-nil if it is valid.
  Valid formats are some subset of 'nothing, 'string, 'formatted-string, =
'xpm,
  'xbm, 'xface, 'gif, 'jpeg, 'png, 'tiff, 'cursor-font, 'font, 'autodetec=
t,
! 'sub-frame', and 'subwindow, depending on how XEmacs was compiled.
  */ )
       (image_instantiator_format)
       Lisp_Object image_instantiator_format;
***************
*** 650,656 ****
  	  write_c_string (")", printcharfun);
  	}
        break;
- =

      case IMAGE_SUBWINDOW:
        /* #### implement me */
        break;
--- 652,657 ----
***************
*** 1872,1877 ****
--- 1873,1886 ----
     of the form \"FONT fontname index [[mask-font] mask-index]\".
     Currently can only be instanced as `pointer', although this should
     probably be fixed.)
+ 'sub-frame
+   (A frame that lives in a glyph device and is displayed by placing tha=
t
+    glyph into a buffer.  Currently only implemented for the X device
+    since it's instanced as a `color-pixmap'.  Support should be added f=
or
+    instancing as `text' that can be displayed in a tty.  Creating a fra=
me
+    on a glyph device will automatically create a sub-frame image.
+    Although sub-frame images can be created from Lisp code, they are
+    currently useless outside of a glyph frame.)
  'subwindow
    (An embedded X window; not currently implemented.)
  'autodetect
***************
*** 1928,1933 ****
--- 1937,1947 ----
    is instantiated as a `pointer'.  Note that if the XBM image file
    specifies a hotspot, it will automatically be picked up if no
    explicit hotspot is given.)
+ :width
+ :height
+   (Only for `sub-frame'.  The keywords specify the size of the frame in=

+    pixels.  The color-pixmap image instance will be created in this
+    size.)
  :color-symbols
    (Only for `xpm'.  This specifies an alist that maps strings
    that specify symbolic color names to the actual color to be used
***************
*** 1965,1970 ****
--- 1979,1985 ----
  =

  static Lisp_Object mark_glyph (Lisp_Object, void (*) (Lisp_Object));
  static void print_glyph (Lisp_Object, Lisp_Object, int);
+ static void finalize_glyph (void *header, int for_disksave);
  static int glyph_equal (Lisp_Object, Lisp_Object, int depth);
  static unsigned long glyph_hash (Lisp_Object obj, int depth);
  static Lisp_Object glyph_getprop (Lisp_Object obj, Lisp_Object prop);
***************
*** 1973,1979 ****
  static int glyph_remprop (Lisp_Object obj, Lisp_Object prop);
  static Lisp_Object glyph_plist (Lisp_Object obj);
  DEFINE_LRECORD_IMPLEMENTATION_WITH_PROPS ("glyph", glyph,
! 					  mark_glyph, print_glyph, 0,
  					  glyph_equal, glyph_hash,
  					  glyph_getprop, glyph_putprop,
  					  glyph_remprop, glyph_plist,
--- 1988,1995 ----
  static int glyph_remprop (Lisp_Object obj, Lisp_Object prop);
  static Lisp_Object glyph_plist (Lisp_Object obj);
  DEFINE_LRECORD_IMPLEMENTATION_WITH_PROPS ("glyph", glyph,
! 					  mark_glyph, print_glyph,
! 					  finalize_glyph,
  					  glyph_equal, glyph_hash,
  					  glyph_getprop, glyph_putprop,
  					  glyph_remprop, glyph_plist,
***************
*** 2009,2014 ****
--- 2025,2048 ----
    write_c_string (buf, printcharfun);
  }
  =

+ static void
+ finalize_glyph (void *header, int for_disksave)
+ {
+   struct Lisp_Glyph *g =3D (struct Lisp_Glyph *) header;
+   if (GLYPH_SUB_FRAMEP (g))
+     {
+       Lisp_Object device, glyph;
+       XSETGLYPH (glyph, g);
+ =

+       device =3D Fget (glyph, Qdevice, Qnil);
+       if (!NILP (device))
+ 	{
+ 	  if (for_disksave) finalose (g);
+ 	  delete_device_internal (XDEVICE (device), 1, 0, 0);
+ 	}
+     }
+ }
+ =

  /* Glyphs are equal if all of their display attributes are equal.  We
     don't compare names or doc-strings, because that would make equal
     be eq.
***************
*** 2161,2166 ****
--- 2195,2206 ----
  	IMAGE_NOTHING_MASK | IMAGE_TEXT_MASK | IMAGE_MONO_PIXMAP_MASK |
  	  IMAGE_COLOR_PIXMAP_MASK | IMAGE_SUBWINDOW_MASK;
        break;
+     case GLYPH_SUB_FRAME:
+       {
+ 	XIMAGE_SPECIFIER_ALLOWED (g->image) =3D
+ 	  IMAGE_NOTHING_MASK | IMAGE_COLOR_PIXMAP_MASK;
+       }
+       break;
      case GLYPH_POINTER:
        XIMAGE_SPECIFIER_ALLOWED (g->image) =3D
  	IMAGE_NOTHING_MASK | IMAGE_POINTER_MASK;
***************
*** 2184,2189 ****
--- 2224,2232 ----
    g->after_change =3D after_change;
    XSETGLYPH (obj, g);
  =

+   if (g->type =3D=3D GLYPH_SUB_FRAME)
+     Fput (obj, Qextent, Qnil);
+ =

    set_image_attached_to (g->image, obj, Qimage);
  =

    return obj;
***************
*** 2200,2205 ****
--- 2243,2250 ----
  =

    if (EQ (type, Qbuffer))
      return GLYPH_BUFFER;
+   if (EQ (type, Qsub_frame))
+     return GLYPH_SUB_FRAME;
    if (EQ (type, Qpointer))
      return GLYPH_POINTER;
    if (EQ (type, Qicon))
***************
*** 2246,2254 ****
  Create a new, uninitialized glyph.
  =

  TYPE specifies the type of the glyph; this should be one of `buffer',
! `pointer', or `icon', and defaults to `buffer'.  The type of the glyph
! specifies in which contexts the glyph can be used, and controls the
! allowable image types into which the glyph's image can be
  instantiated.
  =

  `buffer' glyphs can be used as the begin-glyph or end-glyph of an
--- 2291,2299 ----
  Create a new, uninitialized glyph.
  =

  TYPE specifies the type of the glyph; this should be one of `buffer',
! `sub-frame', `pointer', or `icon', and defaults to `buffer'.  The type
! of the glyph specifies in which contexts the glyph can be used, and
! controls the allowable image types into which the glyph's image can be
  instantiated.
  =

  `buffer' glyphs can be used as the begin-glyph or end-glyph of an
***************
*** 2256,2261 ****
--- 2301,2309 ----
  instantiated as `nothing', `mono-pixmap', `color-pixmap', `text',
  and `subwindow'.
  =

+ `sub-frame' glyphs can be used as the begin-glyph or end-glyph of an
+ extent.  Their image can be instantiated as `color-pixmap'.
+ =

  `pointer' glyphs can be used to specify the mouse pointer.  Their
  image can be instantiated as `pointer'.
  =

***************
*** 2298,2303 ****
--- 2346,2353 ----
      {
      case GLYPH_BUFFER:
        return Qbuffer;
+     case GLYPH_SUB_FRAME:
+       return Qsub_frame;
      case GLYPH_POINTER:
        return Qpointer;
      case GLYPH_ICON:
***************
*** 2845,2850 ****
--- 2895,2901 ----
    defsymbol (&Qmono_pixmap, "mono-pixmap");
    defsymbol (&Qcolor_pixmap, "color-pixmap");
    /* Qpointer defined in general.c */
+   defsymbol (&Qsub_frame, "sub-frame");
    defsymbol (&Qsubwindow, "subwindow");
  =

    /* glyphs */
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/glyphs.h xemacs-19.15-b2-made/src/glyphs.h
*** xemacs-19.15-b2/src/glyphs.h	Wed May 15 21:20:20 1996
--- xemacs-19.15-b2-made/src/glyphs.h	Mon Nov 11 23:26:24 1996
***************
*** 49,54 ****
--- 49,55 ----
    tiff					color-pixmap
    cursor-font				pointer
    font					pointer
+   sub_frame				color-pixmap
    subwindow				subwindow
    inherit				mono-pixmap
    autodetect				mono-pixmap, color-pixmap, pointer,
***************
*** 404,409 ****
--- 405,411 ----
  {
    GLYPH_UNKNOWN,
    GLYPH_BUFFER,
+   GLYPH_SUB_FRAME,
    GLYPH_POINTER,
    GLYPH_ICON
  };
***************
*** 460,470 ****
--- 462,476 ----
  #define GLYPH_BASELINE(g) ((g)->baseline)
  #define GLYPH_FACE(g) ((g)->face)
  =

+ #define GLYPH_SUB_FRAMEP(g) (GLYPH_TYPE (g) =3D=3D GLYPH_SUB_FRAME)
+ =

  #define XGLYPH_TYPE(g) GLYPH_TYPE (XGLYPH (g))
  #define XGLYPH_IMAGE(g) GLYPH_IMAGE (XGLYPH (g))
  #define XGLYPH_CONTRIB_P(g) GLYPH_CONTRIB_P (XGLYPH (g))
  #define XGLYPH_BASELINE(g) GLYPH_BASELINE (XGLYPH (g))
  #define XGLYPH_FACE(g) GLYPH_FACE (XGLYPH (g))
+ =

+ #define XGLYPH_SUB_FRAMEP(g) (GLYPH_TYPE (XGLYPH (g)) =3D=3D GLYPH_SUB_=
FRAME)
  =

  extern Lisp_Object Vtruncation_glyph, Vcontinuation_glyph, Voctal_escap=
e_glyph;
  extern Lisp_Object Vcontrol_arrow_glyph, Vinvisible_text_glyph, Vhscrol=
l_glyph;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/minibuf.c xemacs-19.15-b2-made/src/minibuf.c
*** xemacs-19.15-b2/src/minibuf.c	Mon May 27 18:33:16 1996
--- xemacs-19.15-b2-made/src/minibuf.c	Mon Nov 11 23:26:24 1996
***************
*** 99,106 ****
        && !NILP (frame)
        && !NILP (XFRAME (frame)->minibuffer_window))
      {
!       struct window *w =3D XWINDOW (XFRAME (frame)->minibuffer_window);=

!       redisplay_move_cursor (w, 0, 0);
      }
  =

    return Qnil;
--- 99,110 ----
        && !NILP (frame)
        && !NILP (XFRAME (frame)->minibuffer_window))
      {
!       struct frame *f =3D XFRAME (frame);
!       struct device *d =3D XDEVICE (f->device);
!       struct window *w =3D XWINDOW (f->minibuffer_window);
!       Drawable drw;
!       drw =3D DEVMETH (d, drawable, (f));
!       redisplay_move_cursor (drw, w, 0, 0);
      }
  =

    return Qnil;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/objects-glyph.c xemacs-19.15-b2-made/src/objects-glyph.c
*** xemacs-19.15-b2/src/objects-glyph.c	Wed Dec 31 19:00:00 1969
--- xemacs-19.15-b2-made/src/objects-glyph.c	Mon Nov 11 23:26:24 1996
***************
*** 0 ****
--- 1,322 ----
+ /* GLYPH device-specific Lisp objects.
+    Copyright (C) 1993, 1994 Free Software Foundation, Inc.
+    Copyright (C) 1995 Board of Trustees, University of Illinois.
+    Copyright (C) 1995 Tinker Systems.
+    Copyright (C) 1995, 1996 Ben Wing.
+    Copyright (C) 1995 Sun Microsystems, Inc.
+    Copyright (C) 1996 Joel Peterson.
+    =

+ This file is part of XEmacs.
+ =

+ XEmacs is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+ =

+ XEmacs is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+ =

+ You should have received a copy of the GNU General Public License
+ along with XEmacs; see the file COPYING.  If not, write to
+ the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA.  */
+ =

+ /* Synched up with: Not in FSF. */
+ =

+ /* Authors: Joel Peterson (tarzan@aosi.com) */
+ =

+ #include <config.h>
+ #include "lisp.h"
+ =

+ #include "console-glyph.h"
+ =

+ #include "buffer.h"
+ #include "device.h"
+ #include "frame.h"
+ #include "insdel.h"
+ #include "objects.h"
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*                          color instances                            =
 */
+ /**********************************************************************=
**/
+ =

+ static int
+ glyph_initialize_color_instance (struct Lisp_Color_Instance *c,
+ 				 Lisp_Object name,
+ 				 Lisp_Object device, Error_behavior errb)
+ {
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   int result;
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   c->device =3D locale;
+   result =3D DEVMETH (XDEVICE (locale), initialize_color_instance,
+ 		    (c, name, locale, errb));
+   c->device =3D device;
+   return result;
+ }
+ =

+ static void
+ glyph_print_color_instance (struct Lisp_Color_Instance *c,
+ 			    Lisp_Object printcharfun,
+ 			    int escapeflag)
+ {
+   Lisp_Object device =3D c->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   c->device =3D locale;
+   DEVMETH (XDEVICE (locale), print_color_instance,
+ 	   (c, printcharfun, escapeflag));
+   c->device =3D device;
+ }
+ =

+ static void
+ glyph_finalize_color_instance (struct Lisp_Color_Instance *c)
+ {
+   Lisp_Object device =3D c->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   =

+   /* determine parent device from locale */
+   if (GC_FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   c->device =3D locale;
+   DEVMETH (XDEVICE (locale), finalize_color_instance, (c));
+   c->device =3D device;
+ }
+ =

+ static int
+ glyph_color_instance_equal (struct Lisp_Color_Instance *c1,
+ 			    struct Lisp_Color_Instance *c2,
+ 			    int depth)
+ {
+   Lisp_Object device =3D c1->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   int result;
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   c1->device =3D locale;
+   c1->device =3D locale;
+   result =3D DEVMETH (XDEVICE (locale), color_instance_equal,
+ 		    (c1, c2, depth));
+   c1->device =3D device;
+   c2->device =3D device;
+   return result;
+ }
+ =

+ static unsigned long
+ glyph_color_instance_hash (struct Lisp_Color_Instance *c, int depth)
+ {
+   Lisp_Object device =3D c->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   unsigned long result;
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   c->device =3D locale;
+   result =3D DEVMETH (XDEVICE (locale), color_instance_hash,
+ 		    (c, depth));
+   c->device =3D device;
+   return result;
+ }
+ =

+ static Lisp_Object
+ glyph_color_instance_rgb_components (struct Lisp_Color_Instance *c)
+ {
+   Lisp_Object device =3D c->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   Lisp_Object result;
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   c->device =3D locale;
+   result =3D MAYBE_LISP_DEVMETH (XDEVICE (locale), color_instance_rgb_c=
omponents,
+ 			       (c));
+   c->device =3D device;
+   return result;
+ }
+ =

+ static int
+ glyph_valid_color_name_p (struct device *d, Lisp_Object color)
+ {
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   return DEVMETH (XDEVICE (locale), valid_color_name_p,
+ 		    (d, color));
+ }
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*                           font instances                            =
 */
+ /**********************************************************************=
**/
+ =

+ static int
+ glyph_initialize_font_instance (struct Lisp_Font_Instance *f, Lisp_Obje=
ct name,
+ 				Lisp_Object device, Error_behavior errb)
+ {
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   int result;
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   f->device =3D locale;
+   result =3D DEVMETH (XDEVICE (locale), initialize_font_instance,
+ 		    (f, name, locale, errb));
+   f->device =3D device;
+   return result;
+ }
+ =

+ static void
+ glyph_mark_font_instance (struct Lisp_Font_Instance *f,
+ 			  void (*markobj) (Lisp_Object))
+ {
+   Lisp_Object device =3D f->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   f->device =3D locale;
+   MAYBE_DEVMETH (XDEVICE (locale), mark_font_instance,
+ 		 (f, markobj));
+   f->device =3D device;
+ }
+ =

+ static void
+ glyph_print_font_instance (struct Lisp_Font_Instance *f,
+ 			   Lisp_Object printcharfun,
+ 			   int escapeflag)
+ {
+   Lisp_Object device =3D f->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   f->device =3D locale;
+   DEVMETH (XDEVICE (locale), print_font_instance,
+ 	   (f, printcharfun, escapeflag));
+   f->device =3D device;
+ }
+ =

+ static void
+ glyph_finalize_font_instance (struct Lisp_Font_Instance *f)
+ {
+   Lisp_Object device =3D f->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+ =

+   /* determine parent device from locale */
+   if (GC_FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   f->device =3D locale;
+   DEVMETH (XDEVICE (locale), finalize_font_instance, (f));
+   f->device =3D device;
+ }
+ =

+ static Lisp_Object
+ glyph_font_instance_truename (struct Lisp_Font_Instance *f, Error_behav=
ior errb)
+ {
+   Lisp_Object device =3D f->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object result;
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   f->device =3D locale;
+   result =3D DEVMETH_OR_GIVEN (XDEVICE (locale), font_instance_truename=
,
+ 			     (f, errb), f->name);
+   f->device =3D device;
+   return result;
+ }
+ =

+ static Lisp_Object
+ glyph_font_instance_properties (struct Lisp_Font_Instance *f)
+ {
+   Lisp_Object device =3D f->device;
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object result;
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   f->device =3D locale;
+   result =3D MAYBE_LISP_DEVMETH (XDEVICE (locale), font_instance_proper=
ties,
+ 			       (f));
+   f->device =3D device;
+   return result;
+ }
+ =

+ static Lisp_Object
+ glyph_list_fonts (Lisp_Object pattern, Lisp_Object device)
+ {
+   struct device *d =3D XDEVICE (device);
+   Lisp_Object result;
+   Lisp_Object locale =3D DEVICE_GLYPH_LOCALE (d);
+   =

+   /* determine parent device from locale */
+   if (FRAMEP (locale))
+     locale =3D FRAME_DEVICE (XFRAME (locale));
+   result =3D MAYBE_LISP_DEVMETH (XDEVICE (locale), list_fonts,
+ 			       (pattern, locale));
+   return result;
+ }
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*                            initialization                           =
 */
+ /**********************************************************************=
**/
+ =

+ void
+ syms_of_objects_glyph (void)
+ {
+ }
+ =

+ void
+ console_type_create_objects_glyph (void)
+ {
+   /* object methods */
+ =

+   CONSOLE_HAS_METHOD (glyph, initialize_color_instance);
+   CONSOLE_HAS_METHOD (glyph, print_color_instance);
+   CONSOLE_HAS_METHOD (glyph, finalize_color_instance);
+   CONSOLE_HAS_METHOD (glyph, color_instance_equal);
+   CONSOLE_HAS_METHOD (glyph, color_instance_hash);
+   CONSOLE_HAS_METHOD (glyph, color_instance_rgb_components);
+   CONSOLE_HAS_METHOD (glyph, valid_color_name_p);
+ =

+   CONSOLE_HAS_METHOD (glyph, initialize_font_instance);
+   CONSOLE_HAS_METHOD (glyph, mark_font_instance);
+   CONSOLE_HAS_METHOD (glyph, print_font_instance);
+   CONSOLE_HAS_METHOD (glyph, finalize_font_instance);
+   CONSOLE_HAS_METHOD (glyph, font_instance_truename);
+   CONSOLE_HAS_METHOD (glyph, font_instance_properties);
+   CONSOLE_HAS_METHOD (glyph, list_fonts);
+ }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/objects-x.c xemacs-19.15-b2-made/src/objects-x.c
*** xemacs-19.15-b2/src/objects-x.c	Sun Sep  8 19:47:01 1996
--- xemacs-19.15-b2-made/src/objects-x.c	Mon Nov 11 23:26:24 1996
***************
*** 368,374 ****
        if (DEVICE_LIVE_P (XDEVICE (f->device)))
  	{
  	  Display *dpy =3D DEVICE_X_DISPLAY (XDEVICE (f->device));
- =

  	  XFreeFont (dpy, FONT_INSTANCE_X_FONT (f));
  	}
        xfree (f->data);
--- 368,373 ----
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/redisplay-glyph.c xemacs-19.15-b2-made/src/redisplay-glyph.c
*** xemacs-19.15-b2/src/redisplay-glyph.c	Wed Dec 31 19:00:00 1969
--- xemacs-19.15-b2-made/src/redisplay-glyph.c	Mon Nov 11 23:26:24 1996
***************
*** 0 ****
--- 1,653 ----
+ /* X output and frame manipulation routines.
+    Copyright (C) 1994, 1995 Board of Trustees, University of Illinois.
+    Copyright (C) 1994 Lucid, Inc.
+    Copyright (C) 1995 Sun Microsystems, Inc.
+    Copyright (C) 1996 Joel Peterson
+ =

+ This file is part of XEmacs.
+ =

+ XEmacs is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+ =

+ XEmacs is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+ =

+ You should have received a copy of the GNU General Public License
+ along with XEmacs; see the file COPYING.  If not, write to
+ the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA.  */
+ =

+ /* Synched up with:  Not in FSF. */
+ =

+ /* Author: Joel Peterson (tarzan@aosi.com) */
+ =

+ #include <config.h>
+ #include "lisp.h"
+ =

+ #include "console-glyph.h"
+ #include "glyphs-glyph.h"
+ =

+ #include "buffer.h"
+ #include "console.h"
+ #include "device.h"
+ #include "faces.h"
+ #include "frame.h"
+ #include "glyphs.h"
+ #include "window.h"
+ =

+ #ifdef HAVE_X_WINDOWS
+ #include "glyphs-x.h"
+ #else
+ #define IMAGE_INSTANCE_X_PIXMAP(p) 0
+ #endif
+ =

+ #include "redisplay.h"
+ =

+ static void glyph_clear_frame_windows (Lisp_Object window, Drawable x_w=
in,
+ 				       struct frame *container);
+ =

+ static void
+ glyph_set_container_frame (struct frame *f, Lisp_Object container)
+ {
+   struct glyph_device *g =3D DEVICE_GLYPH_DATA (XDEVICE (f->device));
+   g->container =3D container;
+ }
+ =

+ static Lisp_Object
+ glyph_container_frame (struct frame *f)
+ {
+   return FRAME_GLYPH_CONTAINER (f);
+ }
+ =

+ static Drawable
+ glyph_drawable (struct frame *f)
+ {
+   Lisp_Object frame;
+   Lisp_Object instance;
+   struct device *d =3D XDEVICE (f->device);
+   struct glyph_device *gd =3D DEVICE_GLYPH_DATA (d);
+   struct Lisp_Image_Instance *p;
+ =

+   frame =3D FRAME_GLYPH_LOCALE (f);
+   assert (!NILP (frame));
+   =

+   instance =3D glyph_image_instance (gd->glyph, frame, ERROR_ME_NOT, 1)=
;
+   =

+   assert (IMAGE_INSTANCEP (instance)
+ 	  && XIMAGE_INSTANCE_TYPE (instance) =3D=3D IMAGE_COLOR_PIXMAP);
+ =

+   p =3D XIMAGE_INSTANCE (instance);
+   return IMAGE_INSTANCE_X_PIXMAP (p);
+ }
+ =

+ /**********************************************************************=
*******
+  glyph_output_display_block
+ =

+  Given a display line, a block number for that start line, output all
+  runes between start and end in the specified display block.
+ =

+  This is essentially copied from x_output_display_block with direct cal=
ls
+  to x_output_* routines replaced with corresponding calls to the consol=
e
+  methods for the parent glyph console device.
+  **********************************************************************=
******/
+ static void
+ glyph_output_display_block (struct window *w, struct display_line *dl,
+ 			    int block, int start, int end, int start_pixpos,
+ 			    int cursor_start, int cursor_width,
+ 			    int cursor_height)
+ {
+   struct frame *f =3D XFRAME (w->frame);
+   struct frame *container =3D XFRAME (FRAME_GLYPH_CONTAINER (f));
+   struct device *parentd =3D XDEVICE (container->device);
+   struct console *c =3D XCONSOLE (parentd->console);
+   Drawable x_win;
+ =

+   emchar_dynarr *buf =3D Dynarr_new (Emchar);
+   Lisp_Object window;
+   =

+   struct display_block *db =3D Dynarr_atp (dl->display_blocks, block);
+   rune_dynarr *rba =3D db->runes;
+   struct rune *rb;
+ =

+   int elt =3D start;
+   face_index findex;
+   int xpos, width;
+   Lisp_Object charset =3D Qunbound; /* Qnil is a valid charset when
+ 				     MULE is not defined */
+ =

+   rb =3D Dynarr_atp (rba, start);
+ =

+   XSETWINDOW (window, w);
+   =

+   if (!rb)
+     {
+       /* Nothing to do so don't do anything. */
+       return;
+     }
+   else
+     {
+       findex =3D rb->findex;
+       xpos =3D rb->xpos;
+       width =3D 0;
+       if (rb->type =3D=3D RUNE_CHAR)
+ 	charset =3D CHAR_CHARSET (rb->object.chr.ch);
+     }
+ =

+   if (end < 0)
+     end =3D Dynarr_length (rba);
+   Dynarr_reset (buf);
+ =

+   x_win =3D glyph_drawable (f);
+   =

+   while (elt < end)
+     {
+       rb =3D Dynarr_atp (rba, elt);
+ =

+       if (rb->findex =3D=3D findex && rb->type =3D=3D RUNE_CHAR
+ 	  && rb->object.chr.ch !=3D '\n' && rb->cursor_type !=3D CURSOR_ON
+ 	  && EQ (charset, CHAR_CHARSET (rb->object.chr.ch)))
+ 	{
+ 	  Dynarr_add (buf, rb->object.chr.ch);
+ 	  width +=3D rb->width;
+ 	  elt++;
+ 	}
+       else
+ 	{
+ 	  if (Dynarr_length (buf))
+ 	    {
+ 	      CONMETH_OUTPUT_PRIMITIVE (c, string, (x_win, w, container, dl, b=
uf,
+ 						    xpos, 0, start_pixpos,
+ 						    width, findex, 0,
+ 						    cursor_start, cursor_width,
+ 						    cursor_height));
+ 	      xpos =3D rb->xpos;
+ 	      width =3D 0;
+ 	    }
+ 	  Dynarr_reset (buf);
+ 	  width =3D 0;
+ =

+ 	  if (rb->type =3D=3D RUNE_CHAR)
+ 	    {
+ 	      findex =3D rb->findex;
+ 	      xpos =3D rb->xpos;
+ 	      charset =3D CHAR_CHARSET (rb->object.chr.ch);
+ =

+ 	      if (rb->cursor_type =3D=3D CURSOR_ON)
+ 		{
+ 		  if (rb->object.chr.ch =3D=3D '\n')
+ 		    {
+ 		      CONMETH_OUTPUT_PRIMITIVE (c, eol_cursor,
+ 						(x_win, w, container, dl, xpos));
+ 		    }
+ 		  else
+ 		    {
+ 		      Dynarr_add (buf, rb->object.chr.ch);
+ 		      CONMETH_OUTPUT_PRIMITIVE (c, string,
+ 						(x_win, w, container, dl, buf,
+ 						 xpos, 0,
+ 						 start_pixpos, rb->width,
+ 						 findex, 1, cursor_start,
+ 						 cursor_width, cursor_height));
+ 		      Dynarr_reset (buf);
+ 		    }
+ =

+ 		  xpos +=3D rb->width;
+ 		  elt++;
+ 		}
+ 	      else if (rb->object.chr.ch =3D=3D '\n')
+ 		{
+ 		  /* Clear in case a cursor was formerly here. */
+ 		  int height =3D dl->ascent + dl->descent - dl->clip;
+ =

+ 		  CONMETH (c, clear_region, (x_win, window, container,
+ 					     findex, xpos,
+ 					     dl->ypos - dl->ascent,
+ 					     rb->width, height));
+ 		  elt++;
+ 		}
+ 	    }
+ 	  else if (rb->type =3D=3D RUNE_BLANK || rb->type =3D=3D RUNE_HLINE)
+ 	    {
+ 	      if (rb->type =3D=3D RUNE_BLANK)
+ 		CONMETH_OUTPUT_PRIMITIVE (c, blank,
+ 					  (x_win, w, container, dl, rb,
+ 					   start_pixpos,
+ 					   cursor_start, cursor_width));
+ 	      else =

+ 		{
+ 		  /* #### Our flagging of when we need to redraw the
+                      modeline shadows sucks.  Since RUNE_HLINE is only =
used
+                      by the modeline at the moment it is a good bet
+                      that if it gets redrawn then we should also
+                      redraw the shadows.  This won't be true forever.
+                      We borrow the shadow_thickness_changed flag for
+                      now. */
+ 		  w->shadow_thickness_changed =3D 1;
+ 		  CONMETH_OUTPUT_PRIMITIVE (c, hline, (x_win, w, container,
+ 						       dl, rb));
+ 		}
+ =

+ 	      elt++;
+ 	      if (elt < end)
+ 		{
+ 		  rb =3D Dynarr_atp (rba, elt);
+ =

+ 		  findex =3D rb->findex;
+ 		  xpos =3D rb->xpos;
+ 		}
+ 	    }
+ 	  else if (rb->type =3D=3D RUNE_DGLYPH)
+ 	    {
+ 	      Lisp_Object instance;
+ =

+ 	      if (XGLYPH_SUB_FRAMEP (rb->object.dglyph.glyph))
+ 		{
+ 		  Lisp_Object sf;
+ 		  =

+ 		  /* make sure sub-frame is up to date */
+ 		  sf =3D glyph_sub_frame_instance (rb->object.dglyph.glyph,
+ 						 w->frame);
+ 		  =

+ 		  if (FRAMEP (sf) && (FRAME_LIVE_P (XFRAME (sf))))
+ 		    {
+ 		      redisplay_sub_frame (XFRAME (sf), w->frame, 0);
+ 		      =

+ 		      /* set instance to the actual bitmap of the subframe */
+ 		      instance =3D glyph_image_instance (rb->object.dglyph.glyph,
+ 						       w->frame,
+ 						       ERROR_ME_NOT, 1);
+ 		    }
+ 		  else
+ 		    instance =3D Qnil;
+ 		}
+ 	      else
+ 		{
+ 		  instance =3D glyph_image_instance (rb->object.dglyph.glyph,
+ 						   window, ERROR_ME_NOT, 1);
+ 		}
+ 	      findex =3D rb->findex;
+ =

+ 	      if (IMAGE_INSTANCEP (instance))
+ 		switch (XIMAGE_INSTANCE_TYPE (instance))
+ 		  {
+ 		  case IMAGE_TEXT:
+ 		    {
+ 		      /* #### This is way losing.  See the comment in
+ 			 add_glyph_rune(). */
+ 		      Lisp_Object string =3D
+ 			XIMAGE_INSTANCE_TEXT_STRING (instance);
+ 		      convert_bufbyte_string_into_emchar_dynarr
+ 			(string_data (XSTRING (string)),
+ 			 string_length (XSTRING (string)),
+ 			 buf);
+ 		    =

+ 		      CONMETH_OUTPUT_PRIMITIVE (c, string,
+ 						(x_win, w, container,
+ 						 dl, buf, xpos,
+ 						 rb->object.dglyph.xoffset,
+ 						 start_pixpos, -1, findex,
+ 						 rb->cursor_type =3D=3D CURSOR_ON,
+ 						 cursor_start, cursor_width,
+ 						 cursor_height));
+ 		      Dynarr_reset (buf);
+ 		    }
+ 		    break;
+ 		  case IMAGE_MONO_PIXMAP:
+ 		  case IMAGE_COLOR_PIXMAP:
+ 		    CONMETH_OUTPUT_PRIMITIVE (c, pixmap,
+ 					      (x_win, w, container, dl,
+ 					       instance, xpos,
+ 					       rb->object.dglyph.xoffset,
+ 					       start_pixpos,
+ 					       rb->width, findex, cursor_start,
+ 					       cursor_width, cursor_height));
+ 		    break;
+ 		    =

+ 		  case IMAGE_POINTER:
+ 		    abort ();
+ 		    =

+ 		  case IMAGE_SUBWINDOW:
+ 		    /* #### implement me */
+ 		    break;
+ =

+ 		  case IMAGE_NOTHING:
+ 		    /* nothing is as nothing does */
+ 		    break;
+ 		    =

+ 		  default:
+ 		    abort ();
+ 		  }
+ =

+ 	      xpos +=3D rb->width;
+ 	      elt++;
+ 	    }
+ 	  else
+ 	    abort ();
+ 	}
+     }
+ =

+   if (Dynarr_length (buf))
+     CONMETH_OUTPUT_PRIMITIVE (c, string, (x_win, w, container, dl, buf,=
 xpos, 0,
+ 					  start_pixpos, width, findex,
+ 					  0, cursor_start, cursor_width,
+ 					  cursor_height));
+ =

+   /* #### This is really conditionalized well for optimized
+      performance. */
+   if (dl->modeline
+       && !EQ (Qzero, w->modeline_shadow_thickness)
+       && (f->clear
+ 	  || f->windows_structure_changed
+ 	  || w->shadow_thickness_changed))
+     CONMETH_OUTPUT_PRIMITIVE (c, bevel_modeline,
+ 			      (x_win, w, container, dl));
+ =

+   Dynarr_free (buf);
+ }
+ =

+ /* OUTPUT PRIMITIVES */
+ =

+ static void
+ glyph_output_string (Drawable drawing_area, struct window *w,
+ 		     struct frame *container,
+ 		     struct display_line *dl,
+ 		     emchar_dynarr *buf, int xpos, int xoffset,
+ 		     int clip_start, int width,
+ 		     face_index findex, int cursor,
+ 		     int cursor_start, int cursor_width,
+ 		     int cursor_height)
+ {
+   struct device *d =3D XDEVICE (container->device);
+   struct console *c =3D XCONSOLE (d->console);
+   =

+   CONMETH_OUTPUT_PRIMITIVE (c, string, (drawing_area, w,
+ 					XFRAME (FRAME_GLYPH_CONTAINER
+ 						(XFRAME (w->frame))),
+ 					dl, buf,
+ 					xpos, xoffset, clip_start, width,
+ 					findex, cursor, cursor_start,
+ 					cursor_width, cursor_height));
+ }
+ =

+ static void
+ glyph_output_eol_cursor (Drawable drawing_area, struct window *w,
+ 				struct frame *container,
+ 				struct display_line *dl, int xpos)
+ {
+   struct device *d =3D XDEVICE (container->device);
+   struct console *c =3D XCONSOLE (d->console);
+   =

+   CONMETH_OUTPUT_PRIMITIVE (c, eol_cursor, (drawing_area, w,
+ 					    XFRAME (FRAME_GLYPH_CONTAINER
+ 						    (XFRAME (w->frame))),
+ 					    dl, xpos));
+ }
+ =

+ static void
+ glyph_output_blank (Drawable drawing_area, struct window *w,
+ 			   struct frame *container,
+ 			   struct display_line *dl,
+ 			   struct rune *rb, int start_pixpos,
+ 			   int cursor_start, int cursor_width)
+ {
+   struct device *d =3D XDEVICE (container->device);
+   struct console *c =3D XCONSOLE (d->console);
+   =

+   CONMETH_OUTPUT_PRIMITIVE (c, blank, (drawing_area, w,
+ 				       XFRAME (FRAME_GLYPH_CONTAINER
+ 					       (XFRAME (w->frame))),
+ 				       dl, rb, start_pixpos, cursor_start,
+ 				       cursor_width));
+ }
+ =

+ static void
+ glyph_output_hline (Drawable drawing_area, struct window *w,
+ 			   struct frame *container,
+ 			   struct display_line *dl, struct rune *rb)
+ {
+   struct device *d =3D XDEVICE (container->device);
+   struct console *c =3D XCONSOLE (d->console);
+   =

+   CONMETH_OUTPUT_PRIMITIVE (c, hline, (drawing_area, w,
+ 				       XFRAME (FRAME_GLYPH_CONTAINER
+ 					       (XFRAME (w->frame))),
+ 				       dl, rb));
+ }
+ =

+ static void
+ glyph_output_pixmap (Drawable drawing_area, struct window *w,
+ 			    struct frame *container,
+ 			    struct display_line *dl,
+ 			    Lisp_Object image_instance, int xpos,
+ 			    int xoffset, int start_pixpos, int width,
+ 			    face_index findex,
+ 			    int cursor_start, int cursor_width,
+ 			    int cursor_height)
+ {
+   struct device *d =3D XDEVICE (container->device);
+   struct console *c =3D XCONSOLE (d->console);
+   =

+   CONMETH_OUTPUT_PRIMITIVE (c, pixmap, (drawing_area, w,
+ 					    XFRAME (FRAME_GLYPH_CONTAINER
+ 						    (XFRAME (w->frame))),
+ 					    dl, image_instance, xpos,
+ 					    xoffset, start_pixpos, width,
+ 					    findex, cursor_start, cursor_width,
+ 					    cursor_height));
+ }
+ =

+ static void
+ glyph_output_bevel_modeline (Drawable drawing_area,
+ 			     struct window *w,
+ 			     struct frame *container,
+ 			     struct display_line *dl)
+ {
+   struct device *d =3D XDEVICE (container->device);
+   struct console *c =3D XCONSOLE (d->console);
+   =

+   CONMETH_OUTPUT_PRIMITIVE (c, bevel_modeline, (drawing_area, w,
+ 						XFRAME
+ 						(FRAME_GLYPH_CONTAINER
+ 						 (XFRAME (w->frame))),
+ 						dl));
+ }
+ =

+ /* GENERIC DEVICE REDISPLAY METHODS */
+ =

+ static int
+ glyph_text_width (struct frame *f, struct face_cachel *cachel,
+ 		  CONST Emchar *str, Charcount len)
+ {
+   struct frame *container =3D XFRAME (FRAME_GLYPH_CONTAINER (f));
+   return FRAMEMETH_OR_GIVEN (container, text_width,
+ 			     (container, cachel, str, len), len);
+ }
+ =

+ static int
+ glyph_divider_width (struct frame *f)
+ {
+   struct frame *container =3D XFRAME (FRAME_GLYPH_CONTAINER (f));
+   return FRAMEMETH_OR_GIVEN (container, divider_width, (container), 0);=

+ }
+ =

+ static int
+ glyph_divider_height (struct frame *f)
+ {
+   struct frame *container =3D XFRAME (FRAME_GLYPH_CONTAINER (f));
+   return FRAMEMETH_OR_GIVEN (container, divider_height, (container), 0)=
;
+ }
+ =

+ static int
+ glyph_eol_cursor_width (struct frame *f)
+ {
+   struct frame *container =3D XFRAME (FRAME_GLYPH_CONTAINER (f));
+   return FRAMEMETH_OR_GIVEN (container, eol_cursor_width, (container), =
0);
+ }
+ =

+ static void
+ glyph_output_vertical_divider (Drawable x_win, struct window *w,
+ 			       struct frame *f, int clear)
+ {
+   struct frame *container =3D XFRAME (FRAME_GLYPH_CONTAINER (f));
+   =

+   FRAMEMETH (container, output_vertical_divider, (x_win, w, container, =
clear));
+ }
+ =

+ static void
+ glyph_clear_to_window_end (Drawable x_win, struct window *w,
+ 			   struct frame *f, int ypos1, int ypos2)
+ {
+   struct frame *container =3D XFRAME (FRAME_GLYPH_CONTAINER (f));
+   =

+   FRAMEMETH (container, clear_to_window_end, (x_win, w, container,
+ 					      ypos1, ypos2));
+ }
+ =

+ static void
+ glyph_clear_region (Drawable x_win, Lisp_Object locale, struct frame *f=
,
+ 		    face_index findex, int x, int y, int width, int height)
+ {
+   struct frame *container =3D XFRAME (FRAME_GLYPH_CONTAINER (f));
+   =

+   FRAMEMETH (container, clear_region, (x_win, locale, container, findex=
, x, y,
+ 				       width, height));
+ }
+ =

+ static void
+ glyph_clear_frame_window (Lisp_Object window, Drawable x_win,
+ 			  struct frame *container)
+ {
+   struct window *w =3D XWINDOW (window);
+   =

+   if (!NILP (w->vchild))
+     {
+       glyph_clear_frame_windows (w->vchild, x_win, container);
+       return;
+     }
+ =

+   if (!NILP (w->hchild))
+     {
+       glyph_clear_frame_windows (w->hchild, x_win, container);
+       return;
+     }
+ =

+   FRAMEMETH (container, clear_to_window_end, (x_win, w, container, =

+ 					      WINDOW_TEXT_TOP (w),
+ 					      WINDOW_TEXT_BOTTOM (w)));
+ }
+ =

+ static void
+ glyph_clear_frame_windows (Lisp_Object window, Drawable x_win,
+ 			   struct frame *container)
+ {
+   for (; !NILP (window); window =3D XWINDOW (window)->next)
+     glyph_clear_frame_window (window, x_win, container);
+ }
+ =

+ static void
+ glyph_clear_frame (struct frame *f)
+ {
+   Drawable x_win;
+   int x, y, width, height;
+   Lisp_Object frame;
+   struct frame *container =3D XFRAME (FRAME_GLYPH_CONTAINER (f));
+ =

+   x_win =3D glyph_drawable (f);
+   =

+   x =3D FRAME_LEFT_BORDER_START (f);
+   width =3D (FRAME_PIXWIDTH (f) - FRAME_REAL_LEFT_TOOLBAR_WIDTH (f) -
+ 	   FRAME_REAL_RIGHT_TOOLBAR_WIDTH (f));
+   /* #### This adjustment by 1 should be being done in the macros.
+      There is some small differences between when the menubar is on
+      and off that we still need to deal with. */
+   y =3D FRAME_TOP_BORDER_START (f) - 1;
+   height =3D (FRAME_PIXHEIGHT (f) - FRAME_REAL_TOP_TOOLBAR_HEIGHT (f) -=

+ 	    FRAME_REAL_BOTTOM_TOOLBAR_HEIGHT (f)) + 1;
+ =

+   XSETFRAME (frame, f);
+   /* #### this isn't right, since clear_region can install a backing pi=
xmap */
+   FRAMEMETH (container, clear_region, (x_win, frame, container, 0, x, y=
,
+ 				       width, height));
+   =

+   if (!UNBOUNDP (FACE_BACKGROUND_PIXMAP (Vdefault_face, frame))
+       || !UNBOUNDP (FACE_BACKGROUND_PIXMAP (Vleft_margin_face, frame))
+       || !UNBOUNDP (FACE_BACKGROUND_PIXMAP (Vright_margin_face, frame))=
)
+     {
+       glyph_clear_frame_windows (f->root_window, x_win, container);
+     }
+ }
+ =

+ static void
+ glyph_output_begin (struct device *d)
+ {
+   struct frame *container =3D XFRAME (DEVICE_GLYPH_CONTAINER (d));
+   FRAMEMETH (container, output_begin, (XDEVICE (FRAME_DEVICE (container=
))));
+ }
+ =

+ static void
+ glyph_output_end (struct device *d)
+ {
+   struct frame *container =3D XFRAME (DEVICE_GLYPH_CONTAINER (d));
+   FRAMEMETH (container, output_end, (XDEVICE (FRAME_DEVICE (container))=
));
+ }
+ =

+ static int
+ glyph_flash (struct frame *f)
+ {
+   Lisp_Object container =3D FRAME_GLYPH_CONTAINER (f);
+   struct frame *c;
+   if (NILP (container))
+     container =3D FRAME_GLYPH_SELECTED_LOCALE (f);
+   c =3D XFRAME (container);
+   return FRAMEMETH (c, flash, (c));
+ }
+ =

+ static void
+ glyph_ring_bell (struct frame *f, int volume, int pitch,
+ 		 int duration)
+ {
+   Lisp_Object container =3D FRAME_GLYPH_CONTAINER (f);
+   struct frame *c;
+   if (NILP (container))
+     container =3D FRAME_GLYPH_SELECTED_LOCALE (f);
+   c =3D XFRAME (container);
+   FRAMEMETH (c, ring_bell, (c, volume, pitch, duration));
+ }
+ =

+ =0C
+ /**********************************************************************=
**/
+ /*                            initialization                           =
 */
+ /**********************************************************************=
**/
+ =

+ void
+ console_type_create_redisplay_glyph (void)
+ {
+   /* redisplay methods */
+   CONSOLE_HAS_METHOD (glyph, text_width);
+   CONSOLE_HAS_METHOD (glyph, output_display_block);
+   CONSOLE_HAS_METHOD (glyph, divider_width);
+   CONSOLE_HAS_METHOD (glyph, divider_height);
+   CONSOLE_HAS_METHOD (glyph, eol_cursor_width);
+   CONSOLE_HAS_METHOD (glyph, output_vertical_divider);
+   CONSOLE_HAS_METHOD (glyph, clear_to_window_end);
+   CONSOLE_HAS_METHOD (glyph, clear_region);
+   CONSOLE_HAS_METHOD (glyph, clear_frame);
+   CONSOLE_HAS_METHOD (glyph, output_begin);
+   CONSOLE_HAS_METHOD (glyph, output_end);
+   CONSOLE_HAS_METHOD (glyph, flash);
+   CONSOLE_HAS_METHOD (glyph, ring_bell);
+   CONSOLE_HAS_METHOD (glyph, drawable);
+   CONSOLE_HAS_METHOD (glyph, set_container_frame);
+   CONSOLE_HAS_METHOD (glyph, container_frame);
+ =

+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (glyph, string);
+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (glyph, eol_cursor);
+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (glyph, blank);
+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (glyph, hline);
+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (glyph, pixmap);
+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (glyph, bevel_modeline);
+ }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/redisplay-output.c xemacs-19.15-b2-made/src/redisplay-output.c
*** xemacs-19.15-b2/src/redisplay-output.c	Sun Jun  9 11:48:59 1996
--- xemacs-19.15-b2-made/src/redisplay-output.c	Mon Nov 11 23:26:25 1996
***************
*** 42,51 ****
  =

  static int compare_runes (struct window *w, struct rune *crb,
  			  struct rune *drb);
! static void redraw_cursor_in_window (struct window *w,
  				     int run_end_begin_glyphs);
  void redisplay_output_window (struct window *w);
  =

  /**********************************************************************=
*******
   sync_rune_structs
  =

--- 42,54 ----
  =

  static int compare_runes (struct window *w, struct rune *crb,
  			  struct rune *drb);
! static void redraw_cursor_in_window (Drawable drawing_area, struct wind=
ow *w,
  				     int run_end_begin_glyphs);
  void redisplay_output_window (struct window *w);
  =

+ /* in redisplay.c */
+ Lisp_Object frame_glyph_set_likely_container (struct frame *f);
+ =

  /**********************************************************************=
*******
   sync_rune_structs
  =

***************
*** 193,200 ****
      return 0;
    else if (crb->type =3D=3D RUNE_DGLYPH &&
  	   (!EQ (crb->object.dglyph.glyph, drb->object.dglyph.glyph) ||
! 	    !EQ (crb->object.dglyph.extent, drb->object.dglyph.extent) ||
! 	    crb->object.dglyph.xoffset !=3D drb->object.dglyph.xoffset))
      return 0;
    else if (crb->type =3D=3D RUNE_HLINE &&
  	   (crb->object.hline.thickness !=3D drb->object.hline.thickness ||
--- 196,204 ----
      return 0;
    else if (crb->type =3D=3D RUNE_DGLYPH &&
  	   (!EQ (crb->object.dglyph.glyph, drb->object.dglyph.glyph) ||
! 	     !EQ (crb->object.dglyph.extent, drb->object.dglyph.extent) ||
! 	     crb->object.dglyph.xoffset !=3D drb->object.dglyph.xoffset ||
! 	     XGLYPH_SUB_FRAMEP (crb->object.dglyph.glyph)))
      return 0;
    else if (crb->type =3D=3D RUNE_HLINE &&
  	   (crb->object.hline.thickness !=3D drb->object.hline.thickness ||
***************
*** 422,435 ****
   Clear the lefthand outside border.
   **********************************************************************=
******/
  static void
! clear_left_border (struct window *w, int y, int height)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
    Lisp_Object window;
  =

    XSETWINDOW (window, w);
!   DEVMETH (d, clear_region, (window, DEFAULT_INDEX,
  			     FRAME_LEFT_BORDER_START (f), y,
  			     FRAME_BORDER_WIDTH (f), height));
  }
--- 426,439 ----
   Clear the lefthand outside border.
   **********************************************************************=
******/
  static void
! clear_left_border (Drawable drawing_area, struct window *w, int y, int =
height)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
    Lisp_Object window;
  =

    XSETWINDOW (window, w);
!   DEVMETH (d, clear_region, (drawing_area, window, f, DEFAULT_INDEX,
  			     FRAME_LEFT_BORDER_START (f), y,
  			     FRAME_BORDER_WIDTH (f), height));
  }
***************
*** 440,453 ****
   Clear the righthand outside border.
   **********************************************************************=
******/
  static void
! clear_right_border (struct window *w, int y, int height)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
    Lisp_Object window;
  =

    XSETWINDOW (window, w);
!   DEVMETH (d, clear_region, (window, DEFAULT_INDEX,
  			     FRAME_RIGHT_BORDER_START (f),
  			     y, FRAME_BORDER_WIDTH (f), height));
  }
--- 444,458 ----
   Clear the righthand outside border.
   **********************************************************************=
******/
  static void
! clear_right_border (Drawable drawing_area, struct window *w,
! 		    int y, int height)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
    Lisp_Object window;
  =

    XSETWINDOW (window, w);
!   DEVMETH (d, clear_region, (drawing_area, window, f, DEFAULT_INDEX,
  			     FRAME_RIGHT_BORDER_START (f),
  			     y, FRAME_BORDER_WIDTH (f), height));
  }
***************
*** 460,469 ****
   to correctly update cursor locations and only cursor locations.
   **********************************************************************=
******/
  void
! output_display_line (struct window *w, display_line_dynarr *cdla,
  		     display_line_dynarr *ddla, int line, int force_start,
  		     int force_end)
- =

  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
--- 465,474 ----
   to correctly update cursor locations and only cursor locations.
   **********************************************************************=
******/
  void
! output_display_line (Drawable drawing_area, struct window *w,
! 		     display_line_dynarr *cdla,
  		     display_line_dynarr *ddla, int line, int force_start,
  		     int force_end)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
***************
*** 611,618 ****
  =

  		      /* Clear the empty area. */
  		      DEVMETH (d, clear_region,
! 			       (window, get_builtin_face_cache_index (w,
! 								      face),
  				x, y, width, height));
  =

  		      /* Mark that we should clear the border.  This is
--- 616,623 ----
  =

  		      /* Clear the empty area. */
  		      DEVMETH (d, clear_region,
! 			       (drawing_area, window, f,
! 				get_builtin_face_cache_index (w, face),
  				x, y, width, height));
  =

  		      /* Mark that we should clear the border.  This is
***************
*** 705,713 ****
  	}
  =

        if (window_is_leftmost (w))
! 	clear_left_border (w, y, height);
        if (window_is_rightmost (w))
! 	clear_right_border (w, y, height);
      }
  =

    if (cdla)
--- 710,718 ----
  	}
  =

        if (window_is_leftmost (w))
! 	clear_left_border (drawing_area, w, y, height);
        if (window_is_rightmost (w))
! 	clear_right_border (drawing_area, w, y, height);
      }
  =

    if (cdla)
***************
*** 725,731 ****
  #define ADJ_ENDPOS (rb->endpos + dl->offset)
  =

  int
! redisplay_move_cursor (struct window *w, Bufpos new_point, int no_outpu=
t_end)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
--- 730,737 ----
  #define ADJ_ENDPOS (rb->endpos + dl->offset)
  =

  int
! redisplay_move_cursor (Drawable drawing_area, struct window *w,
! 		       Bufpos new_point, int no_output_end)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
***************
*** 734,740 ****
    struct display_line *dl;
    struct display_block *db;
    struct rune *rb;
! =

    int x =3D w->last_point_x[CURRENT_DISP];
    int y =3D w->last_point_y[CURRENT_DISP];
  =

--- 740,747 ----
    struct display_line *dl;
    struct display_block *db;
    struct rune *rb;
!   Lisp_Object container;
!   =

    int x =3D w->last_point_x[CURRENT_DISP];
    int y =3D w->last_point_y[CURRENT_DISP];
  =

***************
*** 764,769 ****
--- 771,785 ----
      }
    else
      {
+       if (FRAME_GLYPH_P (f))
+ 	{
+ 	  container =3D frame_glyph_set_likely_container (f);
+ 	  if (UNBOUNDP (container))
+ 	    return 0;
+ 	}
+       else
+ 	container =3D Qnil;
+ =

        DEVMETH (d, output_begin, (d));
  =

        /* #### This is a gross kludge.  Cursor handling is such a royal
***************
*** 775,781 ****
        else
  	rb->cursor_type =3D CURSOR_OFF;
        dl->cursor_elt =3D -1;
!       output_display_line (w, 0, cla, y, rb->xpos, rb->xpos + rb->width=
);
      }
  =

    w->last_point_x[CURRENT_DISP] =3D -1;
--- 791,798 ----
        else
  	rb->cursor_type =3D CURSOR_OFF;
        dl->cursor_elt =3D -1;
!       output_display_line (drawing_area, w, 0, cla, y, rb->xpos,
! 			   rb->xpos + rb->width);
      }
  =

    w->last_point_x[CURRENT_DISP] =3D -1;
***************
*** 788,794 ****
      {
        if (!no_output_end)
  	DEVMETH (d, output_end, (d));
! =

        return 1;
      }
  =

--- 805,812 ----
      {
        if (!no_output_end)
  	DEVMETH (d, output_end, (d));
!       if (!NILP (container))
! 	FRAMEMETH (f, set_container_frame, (f, Qnil));
        return 1;
      }
  =

***************
*** 803,812 ****
        rb->cursor_type =3D CURSOR_ON;
        dl->cursor_elt =3D 0;
  =

!       output_display_line (w, 0, cla, y, rb->xpos, rb->xpos + rb->width=
);
  =

        if (!no_output_end)
  	DEVMETH (d, output_end, (d));
        return 1;
      }
    else
--- 821,833 ----
        rb->cursor_type =3D CURSOR_ON;
        dl->cursor_elt =3D 0;
  =

!       output_display_line (drawing_area, w, 0, cla, y, rb->xpos,
! 			   rb->xpos + rb->width);
  =

        if (!no_output_end)
  	DEVMETH (d, output_end, (d));
+       if (!NILP (container))
+ 	FRAMEMETH (f, set_container_frame, (f, Qnil));
        return 1;
      }
    else
***************
*** 861,868 ****
  		  dl->cursor_elt =3D cur_rb;
  		  =

  =

! 		  output_display_line (w, 0, cla, cur_dl, rb->xpos,
! 				       rb->xpos + rb->width);
  =

  		  w->last_point_x[CURRENT_DISP] =3D cur_rb;
  		  w->last_point_y[CURRENT_DISP] =3D cur_dl;
--- 882,889 ----
  		  dl->cursor_elt =3D cur_rb;
  		  =

  =

! 		  output_display_line (drawing_area, w, 0, cla, cur_dl,
! 				       rb->xpos, rb->xpos + rb->width);
  =

  		  w->last_point_x[CURRENT_DISP] =3D cur_rb;
  		  w->last_point_y[CURRENT_DISP] =3D cur_dl;
***************
*** 871,876 ****
--- 892,899 ----
  =

  		  if (!no_output_end)
  		    DEVMETH (d, output_end, (d));
+ 		  if (!NILP (container))
+ 		    FRAMEMETH (f, set_container_frame, (f, Qnil));
  		  return 1;
  		}
  =

***************
*** 884,889 ****
--- 907,914 ----
  =

    if (!no_output_end)
      DEVMETH (d, output_end, (d));
+   if (!NILP (container))
+     FRAMEMETH (f, set_container_frame, (f, Qnil));
    return 0;
  }
  #undef ADJ_BUFPOS
***************
*** 896,906 ****
   the window.
   **********************************************************************=
******/
  static void
! redraw_cursor_in_window (struct window *w, int run_end_begin_meths)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
! =

    display_line_dynarr *dla =3D window_display_lines (w, CURRENT_DISP);
    struct display_line *dl;
    struct display_block *db;
--- 921,933 ----
   the window.
   **********************************************************************=
******/
  static void
! redraw_cursor_in_window (Drawable drawing_area, struct window *w,
! 			 int run_end_begin_meths)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
!   Lisp_Object container;
!   =

    display_line_dynarr *dla =3D window_display_lines (w, CURRENT_DISP);
    struct display_line *dl;
    struct display_block *db;
***************
*** 928,940 ****
       cursor. */
    if (rb->cursor_type =3D=3D CURSOR_ON)
      {
        if (run_end_begin_meths)
  	DEVMETH (d, output_begin, (d));
  =

!       output_display_line (w, 0, dla, y, rb->xpos, rb->xpos + rb->width=
);
  =

        if (run_end_begin_meths)
  	DEVMETH (d, output_end, (d));
      }
  }
  =

--- 955,980 ----
       cursor. */
    if (rb->cursor_type =3D=3D CURSOR_ON)
      {
+       if (FRAME_GLYPH_P (f))
+ 	{
+ 	  container =3D frame_glyph_set_likely_container (f);
+ 	  if (UNBOUNDP (container))
+ 	    return;
+ 	}
+       else
+ 	container =3D Qnil;
+ =

        if (run_end_begin_meths)
  	DEVMETH (d, output_begin, (d));
  =

!       output_display_line (drawing_area, w, 0, dla, y, rb->xpos,
! 			   rb->xpos + rb->width);
  =

        if (run_end_begin_meths)
  	DEVMETH (d, output_end, (d));
+ =

+       if (!NILP (container))
+ 	FRAMEMETH (f, set_container_frame, (f, Qnil));
      }
  }
  =

***************
*** 945,955 ****
   This is used to update the cursor after focus changes.
   **********************************************************************=
******/
  void
! redisplay_redraw_cursor (struct frame *f, int run_end_begin_meths)
  {
    struct window *w =3D XWINDOW (FRAME_SELECTED_WINDOW (f));
  =

!   redraw_cursor_in_window (w, run_end_begin_meths);
  }
  =

  /**********************************************************************=
*******
--- 985,996 ----
   This is used to update the cursor after focus changes.
   **********************************************************************=
******/
  void
! redisplay_redraw_cursor (Drawable drawing_area, struct frame *f,
! 			 int run_end_begin_meths)
  {
    struct window *w =3D XWINDOW (FRAME_SELECTED_WINDOW (f));
  =

!   redraw_cursor_in_window (drawing_area, w, run_end_begin_meths);
  }
  =

  /**********************************************************************=
*******
***************
*** 958,966 ****
   If window is topmost, clear the internal border above it.
   **********************************************************************=
******/
  static void
! redisplay_clear_top_of_window (struct window *w)
  {
    Lisp_Object window;
    XSETWINDOW (window, w);
  =

    if (!NILP (Fwindow_highest_p (window)))
--- 999,1009 ----
   If window is topmost, clear the internal border above it.
   **********************************************************************=
******/
  static void
! redisplay_clear_top_of_window (Drawable drawing_area, struct window *w,=

! 			       struct frame *f)
  {
    Lisp_Object window;
+   =

    XSETWINDOW (window, w);
  =

    if (!NILP (Fwindow_highest_p (window)))
***************
*** 983,989 ****
        y =3D FRAME_TOP_BORDER_START (f) - 1;
        height =3D FRAME_BORDER_HEIGHT (f) + 1;
  =

!       DEVMETH (d, clear_region, (window, DEFAULT_INDEX, x, y, width, he=
ight));
      }
  }
  =

--- 1026,1033 ----
        y =3D FRAME_TOP_BORDER_START (f) - 1;
        height =3D FRAME_BORDER_HEIGHT (f) + 1;
  =

!       DEVMETH (d, clear_region, (drawing_area, window, f,
! 				 DEFAULT_INDEX, x, y, width, height));
      }
  }
  =

***************
*** 995,1001 ****
   erased by setting min_start and/or max_end to positive values.
   **********************************************************************=
******/
  void
! redisplay_clear_bottom_of_window (struct window *w, display_line_dynarr=
 *ddla,
  				  int min_start, int max_end)
  {
    struct frame *f =3D XFRAME (w->frame);
--- 1039,1046 ----
   erased by setting min_start and/or max_end to positive values.
   **********************************************************************=
******/
  void
! redisplay_clear_bottom_of_window (Drawable drawing_area, struct window =
*w,
! 				  display_line_dynarr *ddla,
  				  int min_start, int max_end)
  {
    struct frame *f =3D XFRAME (w->frame);
***************
*** 1043,1049 ****
    if (ypos2 <=3D ypos1)
      return;
  =

!   DEVMETH (d, clear_to_window_end, (w, ypos1, ypos2));
  }
  =

  /**********************************************************************=
*******
--- 1088,1094 ----
    if (ypos2 <=3D ypos1)
      return;
  =

!   DEVMETH (d, clear_to_window_end, (drawing_area, w, f, ypos1, ypos2));=

  }
  =

  /**********************************************************************=
*******
***************
*** 1054,1060 ****
   update_values is false if we are only updating the modeline.
   **********************************************************************=
******/
  void
! redisplay_update_line (struct window *w, int first_line, int last_line,=

  		       int update_values)
  {
    struct frame *f =3D XFRAME (w->frame);
--- 1099,1106 ----
   update_values is false if we are only updating the modeline.
   **********************************************************************=
******/
  void
! redisplay_update_line (Drawable drawing_area, struct window *w,
! 		       int first_line, int last_line,
  		       int update_values)
  {
    struct frame *f =3D XFRAME (w->frame);
***************
*** 1075,1081 ****
        assert (Dynarr_length (cdla) =3D=3D Dynarr_length (ddla));
  =

        /* Output the changes. */
!       output_display_line (w, cdla, ddla, first_line, -1, -1);
  =

        /* Update the offsets. */
        if (update_values)
--- 1121,1127 ----
        assert (Dynarr_length (cdla) =3D=3D Dynarr_length (ddla));
  =

        /* Output the changes. */
!       output_display_line (drawing_area, w, cdla, ddla, first_line, -1,=
 -1);
  =

        /* Update the offsets. */
        if (update_values)
***************
*** 1148,1154 ****
       tty windows have been updated.  This cuts down on cursor
       flicker. */
    if (FRAME_TTY_P (f))
!     redisplay_redraw_cursor (f, 0);
    else
      DEVMETH (d, output_end, (d));
  }
--- 1194,1200 ----
       tty windows have been updated.  This cuts down on cursor
       flicker. */
    if (FRAME_TTY_P (f))
!     redisplay_redraw_cursor (drawing_area, f, 0);
    else
      DEVMETH (d, output_end, (d));
  }
***************
*** 1174,1180 ****
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
! =

    display_line_dynarr *cdla =3D window_display_lines (w, CURRENT_DISP);=

    display_line_dynarr *ddla =3D window_display_lines (w, DESIRED_DISP);=

  =

--- 1220,1227 ----
  {
    struct frame *f =3D XFRAME (w->frame);
    struct device *d =3D XDEVICE (f->device);
!   Drawable drawing_area;
!   =

    display_line_dynarr *cdla =3D window_display_lines (w, CURRENT_DISP);=

    display_line_dynarr *ddla =3D window_display_lines (w, DESIRED_DISP);=

  =

***************
*** 1265,1280 ****
  =

    /* Perform any output initialization. */
    DEVMETH (d, output_begin, (d));
! =

    /* If the window's structure has changed clear the internal border
       above it if it is topmost (the function will check). */
    if (f->windows_structure_changed)
!     redisplay_clear_top_of_window (w);
  =

    /* Output each line. */
    for (line =3D 0; line < Dynarr_length (ddla); line++)
      {
!       output_display_line (w, cdla, ddla, line, -1, -1);
      }
  =

    /* If the number of display lines has shrunk, adjust. */
--- 1312,1329 ----
  =

    /* Perform any output initialization. */
    DEVMETH (d, output_begin, (d));
!   drawing_area =3D DEVMETH (d, drawable, (f));
!   =

    /* If the window's structure has changed clear the internal border
       above it if it is topmost (the function will check). */
    if (f->windows_structure_changed)
!     redisplay_clear_top_of_window (drawing_area, w, f);
  =

    /* Output each line. */
    for (line =3D 0; line < Dynarr_length (ddla); line++)
      {
!       output_display_line (drawing_area, w,
! 			   cdla, ddla, line, -1, -1);
      }
  =

    /* If the number of display lines has shrunk, adjust. */
***************
*** 1287,1299 ****
    if (window_needs_vertical_divider (w)
        && (f->windows_structure_changed || f->clear))
      {
!       DEVMETH (d, output_vertical_divider, (w, f->windows_structure_cha=
nged));
      }
  =

    /* Clear the rest of the window, if necessary. */
    if (need_to_clear_bottom)
      {
!       redisplay_clear_bottom_of_window (w, ddla, need_to_clear_start,
  					need_to_clear_end);
      }
  =

--- 1336,1350 ----
    if (window_needs_vertical_divider (w)
        && (f->windows_structure_changed || f->clear))
      {
!       DEVMETH (d, output_vertical_divider, (drawing_area, w, f,
! 					    f->windows_structure_changed));
      }
  =

    /* Clear the rest of the window, if necessary. */
    if (need_to_clear_bottom)
      {
!       redisplay_clear_bottom_of_window (drawing_area, w, ddla,
! 					need_to_clear_start,
  					need_to_clear_end);
      }
  =

***************
*** 1325,1331 ****
       after all tty windows have been updated.  This cuts down on
       cursor flicker. */
    if (FRAME_TTY_P (f))
!     redisplay_redraw_cursor (f, 0);
    else
      DEVMETH (d, output_end, (d));
  =

--- 1376,1382 ----
       after all tty windows have been updated.  This cuts down on
       cursor flicker. */
    if (FRAME_TTY_P (f))
!     redisplay_redraw_cursor (drawing_area, f, 0);
    else
      DEVMETH (d, output_end, (d));
  =

diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/redisplay-tty.c xemacs-19.15-b2-made/src/redisplay-tty.c
*** xemacs-19.15-b2/src/redisplay-tty.c	Sun Sep  8 19:47:05 1996
--- xemacs-19.15-b2-made/src/redisplay-tty.c	Mon Nov 11 23:26:25 1996
***************
*** 93,106 ****
  static void term_get_fkeys (Lisp_Object keymap, char **address);
  =

  /**********************************************************************=
*******
   tty_text_width
  =

   tty's don't have fonts (that we use at least), so everything is
   considered to be fixed width.  In other words, we just return len.
   **********************************************************************=
******/
  static int
! tty_text_width (struct face_cachel *cachel, CONST Emchar *str,
! 		Charcount len)
  {
    return emchar_string_displayed_columns (str, len);
  }
--- 93,118 ----
  static void term_get_fkeys (Lisp_Object keymap, char **address);
  =

  /**********************************************************************=
*******
+  tty_drawable
+ =

+  tty's don't have drawables.  They will if frame-in-a-glyph gets
+  implemented for tty.
+  **********************************************************************=
******/
+ static Drawable
+ tty_drawable (struct frame *f)
+ {
+   return 0;
+ }
+ =

+ /**********************************************************************=
*******
   tty_text_width
  =

   tty's don't have fonts (that we use at least), so everything is
   considered to be fixed width.  In other words, we just return len.
   **********************************************************************=
******/
  static int
! tty_text_width (struct frame *f, struct face_cachel *cachel,
! 		CONST Emchar *str, Charcount len)
  {
    return emchar_string_displayed_columns (str, len);
  }
***************
*** 112,118 ****
   divider_width is a console method.
   **********************************************************************=
******/
  static int
! tty_divider_width (void)
  {
    return 1;
  }
--- 124,130 ----
   divider_width is a console method.
   **********************************************************************=
******/
  static int
! tty_divider_width (struct frame *f)
  {
    return 1;
  }
***************
*** 124,130 ****
   because divider_height is a console method.
   **********************************************************************=
******/
  static int
! tty_divider_height (void)
  {
    return 1;
  }
--- 136,142 ----
   because divider_height is a console method.
   **********************************************************************=
******/
  static int
! tty_divider_height (struct frame *f)
  {
    return 1;
  }
***************
*** 136,142 ****
   because eol_cursor_width is a console method.
   **********************************************************************=
******/
  static int
! tty_eol_cursor_width (void)
  {
    return 1;
  }
--- 148,154 ----
   because eol_cursor_width is a console method.
   **********************************************************************=
******/
  static int
! tty_eol_cursor_width (struct frame *f)
  {
    return 1;
  }
***************
*** 147,153 ****
   Perform any necessary initialization prior to an update.
   **********************************************************************=
******/
  #ifdef DEBUG_XEMACS
! void tty_output_begin (struct device *d);
  void
  #else
  static void
--- 159,165 ----
   Perform any necessary initialization prior to an update.
   **********************************************************************=
******/
  #ifdef DEBUG_XEMACS
! void tty_output_begin (struct device *f);
  void
  #else
  static void
***************
*** 415,421 ****
   Draw a vertical divider down the left side of the given window.
   **********************************************************************=
******/
  static void
! tty_output_vertical_divider (struct window *w, int clear)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct console *c =3D XCONSOLE (FRAME_CONSOLE (f));
--- 427,434 ----
   Draw a vertical divider down the left side of the given window.
   **********************************************************************=
******/
  static void
! tty_output_vertical_divider (Drawable drawing_area, struct window *w,
! 			     struct frame *container, int clear)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct console *c =3D XCONSOLE (FRAME_CONSOLE (f));
***************
*** 447,453 ****
   Clear the area in the box defined by the given parameters.
   **********************************************************************=
******/
  static void
! tty_clear_region (Lisp_Object window, face_index findex, int x, int y,
  		  int width, int height)
  {
    struct window *w =3D XWINDOW (window);
--- 460,467 ----
   Clear the area in the box defined by the given parameters.
   **********************************************************************=
******/
  static void
! tty_clear_region (Drawable drawing_area, Lisp_Object window,
! 		  struct frame *container, face_index findex, int x, int y,
  		  int width, int height)
  {
    struct window *w =3D XWINDOW (window);
***************
*** 492,498 ****
   background color.
   **********************************************************************=
******/
  static void
! tty_clear_to_window_end (struct window *w, int ypos1, int ypos2)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct console *c =3D XCONSOLE (FRAME_CONSOLE (f));
--- 506,513 ----
   background color.
   **********************************************************************=
******/
  static void
! tty_clear_to_window_end (Drawable drawing_area, struct window *w,
! 			 struct frame *container, int ypos1, int ypos2)
  {
    struct frame *f =3D XFRAME (w->frame);
    struct console *c =3D XCONSOLE (FRAME_CONSOLE (f));
***************
*** 520,526 ****
        Lisp_Object window;
  =

        XSETWINDOW (window, w);
!       tty_clear_region (window, DEFAULT_INDEX, x, ypos1, width, ypos2 -=
 ypos1);
      }
  }
  =

--- 535,542 ----
        Lisp_Object window;
  =

        XSETWINDOW (window, w);
!       tty_clear_region (drawing_area, window, container, DEFAULT_INDEX,=
 x,
! 			ypos1, width, ypos2 - ypos1);
      }
  }
  =

***************
*** 941,947 ****
  	  struct frame *f =3D XFRAME (frm);
  =

  	  /* Clear the bottom line of the frame. */
! 	  tty_clear_region (FRAME_SELECTED_WINDOW (f), DEFAULT_INDEX, 0,
  			    f->height, f->width, 1);
  =

  	  /* And then stick the cursor there. */
--- 957,964 ----
  	  struct frame *f =3D XFRAME (frm);
  =

  	  /* Clear the bottom line of the frame. */
! 	  tty_clear_region (0, FRAME_SELECTED_WINDOW (f), f,
! 			    DEFAULT_INDEX, 0,
  			    f->height, f->width, 1);
  =

  	  /* And then stick the cursor there. */
***************
*** 1046,1053 ****
  #endif /* 0 */
  =

  static int
! tty_flash (struct device *d)
  {
    struct console *c =3D XCONSOLE (DEVICE_CONSOLE (d));
    if (TTY_SD (c).visual_bell)
      {
--- 1063,1071 ----
  #endif /* 0 */
  =

  static int
! tty_flash (struct frame *f)
  {
+   struct device *d =3D XDEVICE (f->device);
    struct console *c =3D XCONSOLE (DEVICE_CONSOLE (d));
    if (TTY_SD (c).visual_bell)
      {
***************
*** 1063,1070 ****
   * tty_ring_bell - sound an audio beep.
   */
  static void
! tty_ring_bell (struct device *d, int volume, int pitch, int duration)
  {
    struct console *c =3D XCONSOLE (DEVICE_CONSOLE (d));
  =

    OUTPUT1 (c, TTY_SD (c).audio_bell);
--- 1081,1089 ----
   * tty_ring_bell - sound an audio beep.
   */
  static void
! tty_ring_bell (struct frame *f, int volume, int pitch, int duration)
  {
+   struct device *d =3D XDEVICE (f->device);
    struct console *c =3D XCONSOLE (DEVICE_CONSOLE (d));
  =

    OUTPUT1 (c, TTY_SD (c).audio_bell);
***************
*** 1521,1524 ****
--- 1540,1544 ----
    CONSOLE_HAS_METHOD (tty, output_end);
    CONSOLE_HAS_METHOD (tty, flash);
    CONSOLE_HAS_METHOD (tty, ring_bell);
+   CONSOLE_HAS_METHOD (tty, drawable);
  }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/redisplay-x.c xemacs-19.15-b2-made/src/redisplay-x.c
*** xemacs-19.15-b2/src/redisplay-x.c	Sun Jun 16 15:37:00 1996
--- xemacs-19.15-b2-made/src/redisplay-x.c	Mon Nov 11 23:26:26 1996
***************
*** 62,90 ****
  =

  #define EOL_CURSOR_WIDTH	5
  =

! static void x_output_pixmap (struct window *w, struct display_line *dl,=

  			     Lisp_Object image_instance, int xpos,
  			     int xoffset,
  			     int start_pixpos, int width, face_index findex,
  			     int cursor_start, int cursor_width,
  			     int cursor_height);
! static void x_output_vertical_divider (struct window *w, int clear);
! static void x_output_blank (struct window *w, struct display_line *dl,
  			    struct rune *rb, int start_pixpos,
  			    int cursor_start, int cursor_width);
! static void x_output_hline (struct window *w, struct display_line *dl,
  			    struct rune *rb);
  static void x_redraw_exposed_window (struct window *w, int x, int y,
  				     int width, int height);
  static void x_redraw_exposed_windows (Lisp_Object window, int x, int y,=

  				      int width, int height);
! static void x_clear_region (Lisp_Object window, face_index findex, int =
x,
  			    int y, int width, int height);
! static void x_output_eol_cursor (struct window *w, struct display_line =
*dl,
! 				 int xpos);
  static void x_clear_frame (struct frame *f);
  static void x_clear_frame_windows (Lisp_Object window);
! static void x_bevel_modeline (struct window *w, struct display_line *dl=
);
  =

  =

       /* Note: We do not use the Xmb*() functions and XFontSets.
--- 62,98 ----
  =

  #define EOL_CURSOR_WIDTH	5
  =

! static void x_output_pixmap (Drawable x_win, struct window *w,
! 			     struct frame *container, struct display_line *dl,
  			     Lisp_Object image_instance, int xpos,
  			     int xoffset,
  			     int start_pixpos, int width, face_index findex,
  			     int cursor_start, int cursor_width,
  			     int cursor_height);
! static void x_output_vertical_divider (Drawable x_win, struct window *w=
,
! 				       struct frame *container, int clear);
! static void x_output_blank (Drawable x_win, struct window *w,
! 			    struct frame *container, struct display_line *dl,
  			    struct rune *rb, int start_pixpos,
  			    int cursor_start, int cursor_width);
! static void x_output_hline (Drawable x_win, struct window *w,
! 			    struct frame *container, struct display_line *dl,
  			    struct rune *rb);
  static void x_redraw_exposed_window (struct window *w, int x, int y,
  				     int width, int height);
  static void x_redraw_exposed_windows (Lisp_Object window, int x, int y,=

  				      int width, int height);
! static void x_clear_region (Drawable x_win, Lisp_Object window,
! 			    struct frame *container, face_index findex, int x,
  			    int y, int width, int height);
! static void x_output_eol_cursor (Drawable x_win, struct window *w,
! 				 struct frame *container,
! 				 struct display_line *dl, int xpos);
  static void x_clear_frame (struct frame *f);
  static void x_clear_frame_windows (Lisp_Object window);
! static void x_output_bevel_modeline (Drawable x_win, struct window *w,
! 				     struct frame *container,
! 				     struct display_line *dl);
  =

  =

       /* Note: We do not use the Xmb*() functions and XFontSets.
***************
*** 199,204 ****
--- 207,357 ----
    return runs_so_far;
  }
  =

+ void debug_print (Lisp_Object); /* kludge! */
+ =

+ /**********************************************************************=
*******
+  x_get_gc
+ =

+  Given a number of parameters return a GC with those properties.
+  **********************************************************************=
******/
+ static GC
+ x_get_gc (struct device *d, Lisp_Object font, Lisp_Object fg, Lisp_Obje=
ct bg,
+ 	  Lisp_Object bg_pmap, Lisp_Object lwidth)
+ {
+   XGCValues gcv;
+   unsigned long mask;
+ =

+   memset (&gcv, ~0, sizeof (XGCValues));
+   gcv.graphics_exposures =3D False;
+   /* Make absolutely sure that we don't pick up a clipping region in
+      the GC returned by this function. */
+   gcv.clip_mask =3D None;
+   gcv.clip_x_origin =3D 0;
+   gcv.clip_y_origin =3D 0;
+   gcv.fill_style =3D FillSolid;
+   mask =3D GCGraphicsExposures | GCClipMask | GCClipXOrigin | GCClipYOr=
igin;
+   mask |=3D GCFillStyle;
+ =

+   if (!NILP (font))
+     {
+       gcv.font =3D FONT_INSTANCE_X_FONT (XFONT_INSTANCE (font))->fid;
+       mask |=3D GCFont;
+     }
+ =

+   /* evil kludge! */
+   if (!NILP (fg) && !COLOR_INSTANCEP (fg) && !INTP (fg))
+     {
+       /* #### I fixed once case where this was getting it.  It was a
+          bad macro expansion (compiler bug). */
+       fprintf (stderr, "Help! x_get_gc got a bogus fg value! fg =3D ");=

+       debug_print (fg);
+       fg =3D Qnil;
+     }
+ =

+   if (!NILP (fg))
+     {
+       if (COLOR_INSTANCEP (fg))
+ 	gcv.foreground =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (fg)).pixel=
;
+       else
+ 	gcv.foreground =3D XINT (fg);
+       mask |=3D GCForeground;
+     }
+ =

+   if (!NILP (bg))
+     {
+       if (COLOR_INSTANCEP (bg))
+ 	gcv.background =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (bg)).pixel=
;
+       else
+ 	gcv.background =3D XINT (bg);
+       mask |=3D GCBackground;
+     }
+ =

+   if (IMAGE_INSTANCEP (bg_pmap)
+       && IMAGE_INSTANCE_PIXMAP_TYPE_P (XIMAGE_INSTANCE (bg_pmap)))
+     {
+       if (XIMAGE_INSTANCE_PIXMAP_DEPTH (bg_pmap) =3D=3D 0)
+ 	{
+ 	  gcv.fill_style =3D FillOpaqueStippled;
+ 	  gcv.stipple =3D XIMAGE_INSTANCE_X_PIXMAP (bg_pmap);
+ 	  mask |=3D (GCStipple | GCFillStyle);
+ 	}
+       else
+ 	{
+ 	  gcv.fill_style =3D FillTiled;
+ 	  gcv.tile =3D XIMAGE_INSTANCE_X_PIXMAP (bg_pmap);
+ 	  mask |=3D (GCTile | GCFillStyle);
+ 	}
+     }
+ =

+   if (!NILP (lwidth))
+     {
+       gcv.line_width =3D XINT (lwidth);
+       mask |=3D GCLineWidth;
+     }
+ =

+   return gc_cache_lookup (DEVICE_X_GC_CACHE (d), &gcv, mask);
+ }
+ =

+ /**********************************************************************=
******/
+ /*                                                                     =
     */
+ /*                       X output helper routines                      =
     */
+ /*                                                                     =
     */
+ /**********************************************************************=
******/
+ =

+ /*
+   EmacsXClearAreaGC and EmacsXClearArea
+ =

+   A stupid hack to catch passing a pixmap to XClearArea.
+   Isn't there a way to know beforehand?
+   */
+ =

+ static void
+ EmacsXClearAreaGC (Display *display, Drawable w, int x, int y,
+ 		   unsigned int width, unsigned int height, Bool exposures,
+ 		   struct device *d, GC gc)
+ {
+   expect_x_error (display);
+   XClearArea(display, w, x, y, width, height, exposures);
+   if (x_error_occurred_p (display))
+     {
+       if (x_error_code (display) =3D=3D BadWindow)
+ 	{
+ 	  /* This is a Pixmap? */
+ 	  XFillRectangle (display, w, gc, x, y, width, height);
+ 	}
+       /* else #### Gee, we should really tell someone about
+ 	           this unexpected error */
+     }
+ }
+ =

+ static void
+ EmacsXClearArea (Display *display, Drawable w, int x, int y,
+ 		 unsigned int width, unsigned int height, Bool exposures,
+ 		 struct device *d, Lisp_Object locale)
+ {
+   expect_x_error (display);
+   XClearArea(display, w, x, y, width, height, exposures);
+   if (x_error_occurred_p (display))
+     {
+       if (x_error_code (display) =3D=3D BadWindow)
+ 	{
+ 	  /* This is a Pixmap? */
+ 	  GC gc;
+ 	  gc =3D x_get_gc (d, Qnil, FACE_BACKGROUND (Vdefault_face, locale),
+ 			 Qnil, Qnil, Qnil);
+ 	  XFillRectangle (display, w, gc, x, y, width, height);
+ 	}
+       /* else #### Gee, we should really tell someone about
+ 	           this unexpected error */
+     }
+ }
+ =

+ /* Non-zero if window is in the selected frame */
+ #define window_frame_really_selected_p(w, d)				\
+ ((EQ (w->frame, DEVICE_FRAME_WITH_FOCUS_REAL (d)))			\
+  && EQ (d->console, Vselected_console)					\
+  && NILP (CONSOLE_SELECTED_SUB_FRAME (XCONSOLE (d->console))))
+ =

  /**********************************************************************=
******/
  /*                                                                     =
     */
  /*                           X output routines                         =
     */
***************
*** 231,237 ****
     */
  =

  static int
! x_text_width (struct face_cachel *cachel, CONST Emchar *str,
  	      Charcount len)
  {
    int width_so_far =3D 0;
--- 384,390 ----
     */
  =

  static int
! x_text_width (struct frame *f, struct face_cachel *cachel, CONST Emchar=
 *str,
  	      Charcount len)
  {
    int width_so_far =3D 0;
***************
*** 257,263 ****
   divider_width is a device method.
   **********************************************************************=
******/
  static int
! x_divider_width (void)
  {
    return X_DIVIDER_WIDTH;
  }
--- 410,416 ----
   divider_width is a device method.
   **********************************************************************=
******/
  static int
! x_divider_width (struct frame *f)
  {
    return X_DIVIDER_WIDTH;
  }
***************
*** 272,278 ****
   smarter.
   **********************************************************************=
******/
  static int
! x_divider_height (void)
  {
    return 1;
  }
--- 425,431 ----
   smarter.
   **********************************************************************=
******/
  static int
! x_divider_height (struct frame *f)
  {
    return 1;
  }
***************
*** 284,290 ****
   because eol_cursor_width is a device method.
   **********************************************************************=
******/
  static int
! x_eol_cursor_width (void)
  {
    return EOL_CURSOR_WIDTH;
  }
--- 437,443 ----
   because eol_cursor_width is a device method.
   **********************************************************************=
******/
  static int
! x_eol_cursor_width (struct frame *f)
  {
    return EOL_CURSOR_WIDTH;
  }
***************
*** 310,315 ****
--- 463,474 ----
    XFlush (DEVICE_X_DISPLAY (d));
  }
  =

+ static Drawable
+ x_drawable (struct frame *f)
+ {
+   return XtWindow (FRAME_X_TEXT_WIDGET (f));
+ }
+ =

  /**********************************************************************=
*******
   x_output_display_block
  =

***************
*** 322,330 ****
  			int cursor_width, int cursor_height)
  {
    struct frame *f =3D XFRAME (w->frame);
    emchar_dynarr *buf =3D Dynarr_new (Emchar);
    Lisp_Object window;
! =

    struct display_block *db =3D Dynarr_atp (dl->display_blocks, block);
    rune_dynarr *rba =3D db->runes;
    struct rune *rb;
--- 481,492 ----
  			int cursor_width, int cursor_height)
  {
    struct frame *f =3D XFRAME (w->frame);
+   struct device *d =3D XDEVICE (f->device);
+   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
+   =

    emchar_dynarr *buf =3D Dynarr_new (Emchar);
    Lisp_Object window;
!   =

    struct display_block *db =3D Dynarr_atp (dl->display_blocks, block);
    rune_dynarr *rba =3D db->runes;
    struct rune *rb;
***************
*** 372,379 ****
  	{
  	  if (Dynarr_length (buf))
  	    {
! 	      x_output_string (w, dl, buf, xpos, 0, start_pixpos, width,
! 			       findex, 0, cursor_start, cursor_width,
  			       cursor_height);
  	      xpos =3D rb->xpos;
  	      width =3D 0;
--- 534,541 ----
  	{
  	  if (Dynarr_length (buf))
  	    {
! 	      x_output_string (x_win, w, f, dl, buf, xpos, 0, start_pixpos,
! 			       width, findex, 0, cursor_start, cursor_width,
  			       cursor_height);
  	      xpos =3D rb->xpos;
  	      width =3D 0;
***************
*** 391,403 ****
  		{
  		  if (rb->object.chr.ch =3D=3D '\n')
  		    {
! 		      x_output_eol_cursor (w, dl, xpos);
  		    }
  		  else
  		    {
  		      Dynarr_add (buf, rb->object.chr.ch);
! 		      x_output_string (w, dl, buf, xpos, 0, start_pixpos,
! 				       rb->width, findex, 1,
  				       cursor_start, cursor_width,
  				       cursor_height);
  		      Dynarr_reset (buf);
--- 553,565 ----
  		{
  		  if (rb->object.chr.ch =3D=3D '\n')
  		    {
! 		      x_output_eol_cursor (x_win, w, f, dl, xpos);
  		    }
  		  else
  		    {
  		      Dynarr_add (buf, rb->object.chr.ch);
! 		      x_output_string (x_win, w, f, dl, buf, xpos, 0,
! 				       start_pixpos, rb->width, findex, 1,
  				       cursor_start, cursor_width,
  				       cursor_height);
  		      Dynarr_reset (buf);
***************
*** 411,417 ****
  		  /* Clear in case a cursor was formerly here. */
  		  int height =3D dl->ascent + dl->descent - dl->clip;
  =

! 		  x_clear_region (window, findex, xpos, dl->ypos - dl->ascent,
  				  rb->width, height);
  		  elt++;
  		}
--- 573,580 ----
  		  /* Clear in case a cursor was formerly here. */
  		  int height =3D dl->ascent + dl->descent - dl->clip;
  =

! 		  x_clear_region (x_win, window, XFRAME (w->frame),
! 				  findex, xpos, dl->ypos - dl->ascent,
  				  rb->width, height);
  		  elt++;
  		}
***************
*** 419,426 ****
  	  else if (rb->type =3D=3D RUNE_BLANK || rb->type =3D=3D RUNE_HLINE)
  	    {
  	      if (rb->type =3D=3D RUNE_BLANK)
! 		x_output_blank (w, dl, rb, start_pixpos, cursor_start,
! 				cursor_width);
  	      else =

  		{
  		  /* #### Our flagging of when we need to redraw the
--- 582,589 ----
  	  else if (rb->type =3D=3D RUNE_BLANK || rb->type =3D=3D RUNE_HLINE)
  	    {
  	      if (rb->type =3D=3D RUNE_BLANK)
! 		x_output_blank (x_win, w, f, dl, rb, start_pixpos,
! 				cursor_start, cursor_width);
  	      else =

  		{
  		  /* #### Our flagging of when we need to redraw the
***************
*** 431,437 ****
                       We borrow the shadow_thickness_changed flag for
                       now. */
  		  w->shadow_thickness_changed =3D 1;
! 		  x_output_hline (w, dl, rb);
  		}
  =

  	      elt++;
--- 594,600 ----
                       We borrow the shadow_thickness_changed flag for
                       now. */
  		  w->shadow_thickness_changed =3D 1;
! 		  x_output_hline (x_win, w, f, dl, rb);
  		}
  =

  	      elt++;
***************
*** 446,457 ****
  	  else if (rb->type =3D=3D RUNE_DGLYPH)
  	    {
  	      Lisp_Object instance;
! =

! 	      XSETWINDOW (window, w);
! 	      instance =3D glyph_image_instance (rb->object.dglyph.glyph,
! 					       window, ERROR_ME_NOT, 1);
  	      findex =3D rb->findex;
! =

  	      if (IMAGE_INSTANCEP (instance))
  		switch (XIMAGE_INSTANCE_TYPE (instance))
  		  {
--- 609,642 ----
  	  else if (rb->type =3D=3D RUNE_DGLYPH)
  	    {
  	      Lisp_Object instance;
! 	      if (XGLYPH_SUB_FRAMEP (rb->object.dglyph.glyph))
! 		{
! 		  Lisp_Object sf;
! 		  =

! 		  /* make sure sub-frame is up to date */
! 		  sf =3D glyph_sub_frame_instance (rb->object.dglyph.glyph,
! 						 w->frame);
! 		  =

! 		  if (FRAMEP (sf) && FRAME_LIVE_P (XFRAME (sf)))
! 		    {
! 		      redisplay_sub_frame (XFRAME (sf), w->frame, 0);
! 		      =

! 		      /* set instance to the actual bitmap of the subframe */
! 		      instance =3D glyph_image_instance (rb->object.dglyph.glyph,
! 						       w->frame,
! 						       ERROR_ME_NOT, 1);
! 		    }
! 		  else
! 		    instance =3D Qnil;
! 		}
! 	      else
! 		{
! 		  XSETWINDOW (window, w);
! 		  instance =3D glyph_image_instance (rb->object.dglyph.glyph,
! 						   window, ERROR_ME_NOT, 1);
! 		}
  	      findex =3D rb->findex;
! 	      =

  	      if (IMAGE_INSTANCEP (instance))
  		switch (XIMAGE_INSTANCE_TYPE (instance))
  		  {
***************
*** 466,472 ****
  			 string_length (XSTRING (string)),
  			 buf);
  		    =

! 		      x_output_string (w, dl, buf, xpos,
  				       rb->object.dglyph.xoffset,
  				       start_pixpos, -1, findex,
  				       (rb->cursor_type =3D=3D CURSOR_ON),
--- 651,657 ----
  			 string_length (XSTRING (string)),
  			 buf);
  		    =

! 		      x_output_string (x_win, w, f, dl, buf, xpos,
  				       rb->object.dglyph.xoffset,
  				       start_pixpos, -1, findex,
  				       (rb->cursor_type =3D=3D CURSOR_ON),
***************
*** 475,489 ****
  		      Dynarr_reset (buf);
  		    }
  		    break;
- =

  		  case IMAGE_MONO_PIXMAP:
  		  case IMAGE_COLOR_PIXMAP:
! 		    x_output_pixmap (w, dl, instance, xpos,
  				     rb->object.dglyph.xoffset, start_pixpos,
  				     rb->width, findex, cursor_start,
  				     cursor_width, cursor_height);
  		    break;
! =

  		  case IMAGE_POINTER:
  		    abort ();
  		    =

--- 660,673 ----
  		      Dynarr_reset (buf);
  		    }
  		    break;
  		  case IMAGE_MONO_PIXMAP:
  		  case IMAGE_COLOR_PIXMAP:
! 		    x_output_pixmap (x_win, w, f, dl, instance, xpos,
  				     rb->object.dglyph.xoffset, start_pixpos,
  				     rb->width, findex, cursor_start,
  				     cursor_width, cursor_height);
  		    break;
! 		    =

  		  case IMAGE_POINTER:
  		    abort ();
  		    =

***************
*** 508,514 ****
      }
  =

    if (Dynarr_length (buf))
!     x_output_string (w, dl, buf, xpos, 0, start_pixpos, width, findex,
  		     0, cursor_start, cursor_width, cursor_height);
  =

    /* #### This is really conditionalized well for optimized
--- 692,698 ----
      }
  =

    if (Dynarr_length (buf))
!     x_output_string (x_win, w, f, dl, buf, xpos, 0, start_pixpos, width=
, findex,
  		     0, cursor_start, cursor_width, cursor_height);
  =

    /* #### This is really conditionalized well for optimized
***************
*** 518,541 ****
        && (f->clear
  	  || f->windows_structure_changed
  	  || w->shadow_thickness_changed))
!     x_bevel_modeline (w, dl);
  =

    Dynarr_free (buf);
  }
  =

  /**********************************************************************=
*******
!  x_bevel_modeline
  =

   Draw a 3d border around the modeline on window W.
   **********************************************************************=
******/
  static void
! x_bevel_modeline (struct window *w, struct display_line *dl)
  {
!   struct frame *f =3D XFRAME (w->frame);
!   struct device *d =3D XDEVICE (f->device);
    Display *dpy =3D DEVICE_X_DISPLAY (d);
!   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
!   EmacsFrame ef =3D (EmacsFrame) FRAME_X_TEXT_WIDGET (f);
    GC top_shadow_gc, bottom_shadow_gc, background_gc;
    Pixel top_shadow_pixel, bottom_shadow_pixel, background_pixel;
    XColor tmp_color;
--- 702,727 ----
        && (f->clear
  	  || f->windows_structure_changed
  	  || w->shadow_thickness_changed))
!     x_output_bevel_modeline (x_win, w, f, dl);
  =

    Dynarr_free (buf);
  }
  =

  /**********************************************************************=
*******
!  x_output_bevel_modeline
  =

   Draw a 3d border around the modeline on window W.
+  If W is a window in a subframe, then PARENT is the window in the actua=
l X
+  frame in which W is being displayed; otherwise, PARENT is the same as =
W.
+  x_win is the X Window or Pixmap into which the modeline should be rend=
ered.
   **********************************************************************=
******/
  static void
! x_output_bevel_modeline (Drawable x_win, struct window *w,
! 			 struct frame *container, struct display_line *dl)
  {
!   struct device *d =3D XDEVICE (container->device);
    Display *dpy =3D DEVICE_X_DISPLAY (d);
!   EmacsFrame ef =3D (EmacsFrame) FRAME_X_TEXT_WIDGET (container);
    GC top_shadow_gc, bottom_shadow_gc, background_gc;
    Pixel top_shadow_pixel, bottom_shadow_pixel, background_pixel;
    XColor tmp_color;
***************
*** 557,563 ****
    bottom_shadow_pixel =3D tmp_color.pixel;
    background_pixel =3D tmp_color.pixel;
  =

!   x_generate_shadow_pixels (f, &top_shadow_pixel, &bottom_shadow_pixel,=

  			    background_pixel, ef->core.background_pixel);
  =

    tmp_pixel =3D WINDOW_FACE_CACHEL_FOREGROUND (w, MODELINE_INDEX);
--- 743,749 ----
    bottom_shadow_pixel =3D tmp_color.pixel;
    background_pixel =3D tmp_color.pixel;
  =

!   x_generate_shadow_pixels (container, &top_shadow_pixel, &bottom_shado=
w_pixel,
  			    background_pixel, ef->core.background_pixel);
  =

    tmp_pixel =3D WINDOW_FACE_CACHEL_FOREGROUND (w, MODELINE_INDEX);
***************
*** 629,721 ****
    y =3D dl->ypos - dl->ascent - shadow_thickness;
    height =3D dl->ascent + dl->descent + 2 * shadow_thickness;
  =

!   x_output_shadows (f, x, y, width, height, top_shadow_gc, bottom_shado=
w_gc,
! 		    background_gc, shadow_thickness);
! }
! =

! void debug_print (Lisp_Object); /* kludge! */
! =

! /**********************************************************************=
*******
!  x_get_gc
! =

!  Given a number of parameters return a GC with those properties.
!  **********************************************************************=
******/
! static GC
! x_get_gc (struct device *d, Lisp_Object font, Lisp_Object fg, Lisp_Obje=
ct bg,
! 	  Lisp_Object bg_pmap, Lisp_Object lwidth)
! {
!   XGCValues gcv;
!   unsigned long mask;
! =

!   memset (&gcv, ~0, sizeof (XGCValues));
!   gcv.graphics_exposures =3D False;
!   /* Make absolutely sure that we don't pick up a clipping region in
!      the GC returned by this function. */
!   gcv.clip_mask =3D None;
!   gcv.clip_x_origin =3D 0;
!   gcv.clip_y_origin =3D 0;
!   gcv.fill_style =3D FillSolid;
!   mask =3D GCGraphicsExposures | GCClipMask | GCClipXOrigin | GCClipYOr=
igin;
!   mask |=3D GCFillStyle;
! =

!   if (!NILP (font))
!     {
!       gcv.font =3D FONT_INSTANCE_X_FONT (XFONT_INSTANCE (font))->fid;
!       mask |=3D GCFont;
!     }
! =

!   /* evil kludge! */
!   if (!NILP (fg) && !COLOR_INSTANCEP (fg) && !INTP (fg))
!     {
!       /* #### I fixed once case where this was getting it.  It was a
!          bad macro expansion (compiler bug). */
!       fprintf (stderr, "Help! x_get_gc got a bogus fg value! fg =3D ");=

!       debug_print (fg);
!       fg =3D Qnil;
!     }
! =

!   if (!NILP (fg))
!     {
!       if (COLOR_INSTANCEP (fg))
! 	gcv.foreground =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (fg)).pixel=
;
!       else
! 	gcv.foreground =3D XINT (fg);
!       mask |=3D GCForeground;
!     }
! =

!   if (!NILP (bg))
!     {
!       if (COLOR_INSTANCEP (bg))
! 	gcv.background =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (bg)).pixel=
;
!       else
! 	gcv.background =3D XINT (bg);
!       mask |=3D GCBackground;
!     }
! =

!   if (IMAGE_INSTANCEP (bg_pmap)
!       && IMAGE_INSTANCE_PIXMAP_TYPE_P (XIMAGE_INSTANCE (bg_pmap)))
!     {
!       if (XIMAGE_INSTANCE_PIXMAP_DEPTH (bg_pmap) =3D=3D 0)
! 	{
! 	  gcv.fill_style =3D FillOpaqueStippled;
! 	  gcv.stipple =3D XIMAGE_INSTANCE_X_PIXMAP (bg_pmap);
! 	  mask |=3D (GCStipple | GCFillStyle);
! 	}
!       else
! 	{
! 	  gcv.fill_style =3D FillTiled;
! 	  gcv.tile =3D XIMAGE_INSTANCE_X_PIXMAP (bg_pmap);
! 	  mask |=3D (GCTile | GCFillStyle);
! 	}
!     }
! =

!   if (!NILP (lwidth))
!     {
!       gcv.line_width =3D XINT (lwidth);
!       mask |=3D GCLineWidth;
!     }
! =

!   return gc_cache_lookup (DEVICE_X_GC_CACHE (d), &gcv, mask);
  }
  =

  /**********************************************************************=
*******
--- 815,822 ----
    y =3D dl->ypos - dl->ascent - shadow_thickness;
    height =3D dl->ascent + dl->descent + 2 * shadow_thickness;
  =

!   x_output_shadows (x_win, container, x, y, width, height, top_shadow_g=
c,
! 		    bottom_shadow_gc, background_gc, shadow_thickness);
  }
  =

  /**********************************************************************=
*******
***************
*** 728,733 ****
--- 829,838 ----
   The meaning of the parameters is something like this:
  =

   W		Window that the text is to be displayed in.
+  PARENT		If W is a window in a subframe, then PARENT is the window in
+  		the X frame that contains W; otherwise, PARENT is the same as
+ 		W.
+  X_WIN		The X Window or Pixmap that the string should be rendered into.=

   DL		Display line that this text is on.  The values in the
   		structure are used to determine the vertical position and
  		clipping range of the text.
***************
*** 752,774 ****
   The cursor is drawn sometimes whether or not CURSOR is set. ???
   **********************************************************************=
******/
  void
! x_output_string (struct window *w, struct display_line *dl,
! 		 emchar_dynarr *buf, int xpos, int xoffset, int clip_start,
  		 int width, face_index findex, int cursor,
  		 int cursor_start, int cursor_width, int cursor_height)
  {
    /* General variables */
!   struct frame *f =3D XFRAME (w->frame);
!   struct device *d =3D XDEVICE (f->device);
!   Lisp_Object device =3D Qnil;
    Lisp_Object window =3D Qnil;
    Display *dpy =3D DEVICE_X_DISPLAY (d);
-   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
  =

    int clip_end;
    =

    /* Cursor-related variables */
!   int focus =3D EQ (w->frame, DEVICE_FRAME_WITH_FOCUS_REAL (d));
    int cursor_clip;
    Lisp_Object bar_cursor_value =3D symbol_value_in_buffer (Qbar_cursor,=

  							 WINDOW_BUFFER (w));
--- 857,879 ----
   The cursor is drawn sometimes whether or not CURSOR is set. ???
   **********************************************************************=
******/
  void
! x_output_string (Drawable x_win, struct window *w, struct frame *contai=
ner,
! 		 struct display_line *dl, emchar_dynarr *buf, int xpos,
! 		 int xoffset, int clip_start,
  		 int width, face_index findex, int cursor,
  		 int cursor_start, int cursor_width, int cursor_height)
  {
    /* General variables */
!   struct device *d =3D XDEVICE (container->device);
!   struct device *fd =3D XDEVICE (XFRAME (w->frame)->device);
    Lisp_Object window =3D Qnil;
    Display *dpy =3D DEVICE_X_DISPLAY (d);
  =

    int clip_end;
    =

    /* Cursor-related variables */
!   int focus =3D window_frame_really_selected_p (w, fd);
! =

    int cursor_clip;
    Lisp_Object bar_cursor_value =3D symbol_value_in_buffer (Qbar_cursor,=

  							 WINDOW_BUFFER (w));
***************
*** 785,795 ****
    int i;
    struct face_cachel *cachel =3D WINDOW_FACE_CACHEL (w, findex);
  =

-   XSETDEVICE (device, d);
    XSETWINDOW (window, w);
    =

    if (width < 0)
!     width =3D x_text_width (cachel, Dynarr_atp (buf, 0), Dynarr_length =
(buf));
    height =3D dl->ascent + dl->descent - dl->clip;
  =

    /* Regularize the variables passed in. */
--- 890,900 ----
    int i;
    struct face_cachel *cachel =3D WINDOW_FACE_CACHEL (w, findex);
  =

    XSETWINDOW (window, w);
    =

    if (width < 0)
!     width =3D x_text_width (container, cachel,
! 			  Dynarr_atp (buf, 0), Dynarr_length (buf));
    height =3D dl->ascent + dl->descent - dl->clip;
  =

    /* Regularize the variables passed in. */
***************
*** 886,906 ****
  	      =

  	      if (ypos1_line < ypos1_string)
  		{
! 		  x_clear_region (window, findex, clear_start, ypos1_line,
! 				  clear_end - clear_start,
  				  ypos1_string - ypos1_line);
  		}
  	      =

  	      if (ypos2_line > ypos2_string)
  		{
! 		  x_clear_region (window, findex, clear_start, ypos2_string,
! 				  clear_end - clear_start,
  				  ypos2_line - ypos2_string);
  		}
  	    }
  	  else
  	    {
! 	      x_clear_region (window, findex, clear_start,
  			      dl->ypos - dl->ascent, clear_end - clear_start,
  			      height);
  	    }
--- 991,1011 ----
  	      =

  	      if (ypos1_line < ypos1_string)
  		{
! 		  x_clear_region (x_win, window, container, findex, clear_start,
! 				  ypos1_line, clear_end - clear_start,
  				  ypos1_string - ypos1_line);
  		}
  	      =

  	      if (ypos2_line > ypos2_string)
  		{
! 		  x_clear_region (x_win, window, container, findex, clear_start,
! 				  ypos2_string, clear_end - clear_start,
  				  ypos2_line - ypos2_string);
  		}
  	    }
  	  else
  	    {
! 	      x_clear_region (x_win, window, container, findex, clear_start,
  			      dl->ypos - dl->ascent, clear_end - clear_start,
  			      height);
  	    }
***************
*** 1108,1121 ****
  }
  =

  void
! x_output_x_pixmap (struct frame *f, struct Lisp_Image_Instance *p, int =
x,
  		   int y, int clip_x, int clip_y, int clip_width,
  		   int clip_height, int width, int height, int pixmap_offset,
  		   unsigned long fg, unsigned long bg, GC override_gc)
  {
    struct device *d =3D XDEVICE (f->device);
    Display *dpy =3D DEVICE_X_DISPLAY (d);
-   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
  =

    GC gc;
    XGCValues gcv;
--- 1213,1226 ----
  }
  =

  void
! x_output_x_pixmap (Drawable x_win, struct frame *f,
! 		   struct Lisp_Image_Instance *p, int x,
  		   int y, int clip_x, int clip_y, int clip_width,
  		   int clip_height, int width, int height, int pixmap_offset,
  		   unsigned long fg, unsigned long bg, GC override_gc)
  {
    struct device *d =3D XDEVICE (f->device);
    Display *dpy =3D DEVICE_X_DISPLAY (d);
  =

    GC gc;
    XGCValues gcv;
***************
*** 1187,1204 ****
  }
  =

  static void
! x_output_pixmap (struct window *w, struct display_line *dl,
  		 Lisp_Object image_instance, int xpos, int xoffset,
  		 int start_pixpos, int width, face_index findex,
  		 int cursor_start, int cursor_width, int cursor_height)
  {
!   struct frame *f =3D XFRAME (w->frame);
!   struct device *d =3D XDEVICE (f->device);
    struct Lisp_Image_Instance *p =3D XIMAGE_INSTANCE (image_instance);
    Lisp_Object window;
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
-   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
    int lheight =3D dl->ascent + dl->descent - dl->clip;
    int pheight =3D ((int) IMAGE_INSTANCE_PIXMAP_HEIGHT (p) > lheight ? l=
height :
  		 IMAGE_INSTANCE_PIXMAP_HEIGHT (p));
--- 1292,1308 ----
  }
  =

  static void
! x_output_pixmap (Drawable x_win, struct window *w, struct frame *contai=
ner,
! 		 struct display_line *dl,
  		 Lisp_Object image_instance, int xpos, int xoffset,
  		 int start_pixpos, int width, face_index findex,
  		 int cursor_start, int cursor_width, int cursor_height)
  {
!   struct device *d =3D XDEVICE (container->device);
    struct Lisp_Image_Instance *p =3D XIMAGE_INSTANCE (image_instance);
    Lisp_Object window;
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
    int lheight =3D dl->ascent + dl->descent - dl->clip;
    int pheight =3D ((int) IMAGE_INSTANCE_PIXMAP_HEIGHT (p) > lheight ? l=
height :
  		 IMAGE_INSTANCE_PIXMAP_HEIGHT (p));
***************
*** 1278,1287 ****
  	  clear_width =3D width;
  	}
  =

!       x_clear_region (window, findex, clear_x, clear_y,
! 		      clear_width, clear_height);
      }
! =

    /* Output the pixmap. */
    {
      Lisp_Object tmp_pixel;
--- 1382,1391 ----
  	  clear_width =3D width;
  	}
  =

!       x_clear_region (x_win, window, container, findex, clear_x,
! 		      clear_y, clear_width, clear_height);
      }
!   =

    /* Output the pixmap. */
    {
      Lisp_Object tmp_pixel;
***************
*** 1292,1299 ****
      tmp_pixel =3D WINDOW_FACE_CACHEL_BACKGROUND (w, findex);
      tmp_bcolor =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (tmp_pixel))=
;
  =

!     x_output_x_pixmap (f, p, xpos - xoffset, dl->ypos - dl->ascent, cli=
p_x,
! 		       clip_y, clip_width, clip_height,
  		       pwidth, pheight, pixmap_offset,
  		       tmp_fcolor.pixel, tmp_bcolor.pixel, 0);
    }
--- 1396,1404 ----
      tmp_pixel =3D WINDOW_FACE_CACHEL_BACKGROUND (w, findex);
      tmp_bcolor =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (tmp_pixel))=
;
  =

!     x_output_x_pixmap (x_win, container, p, xpos - xoffset,
! 		       dl->ypos - dl->ascent,
! 		       clip_x, clip_y, clip_width, clip_height,
  		       pwidth, pheight, pixmap_offset,
  		       tmp_fcolor.pixel, tmp_bcolor.pixel, 0);
    }
***************
*** 1304,1310 ****
        && (cursor_start < xpos + pwidth))
      {
        GC gc;
!       int focus =3D EQ (w->frame, DEVICE_FRAME_WITH_FOCUS_REAL (d));
        int y =3D dl->ypos - dl->ascent;
        struct face_cachel *cursor_cachel =3D
  	WINDOW_FACE_CACHEL (w,
--- 1409,1417 ----
        && (cursor_start < xpos + pwidth))
      {
        GC gc;
!       struct device *fd =3D XDEVICE (XFRAME (w->frame)->device);
!       int focus =3D window_frame_really_selected_p (w, fd);
!       =

        int y =3D dl->ypos - dl->ascent;
        struct face_cachel *cursor_cachel =3D
  	WINDOW_FACE_CACHEL (w,
***************
*** 1335,1347 ****
   Draw a vertical divider down the left side of the given window.
   **********************************************************************=
******/
  static void
! x_output_vertical_divider (struct window *w, int clear)
  {
    struct frame *f =3D XFRAME (w->frame);
!   struct device *d =3D XDEVICE (f->device);
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
-   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
    GC gc;
  =

    /* We don't use the normal gutter measurements here because the
--- 1442,1454 ----
   Draw a vertical divider down the left side of the given window.
   **********************************************************************=
******/
  static void
! x_output_vertical_divider (Drawable x_win, struct window *w,
! 			   struct frame *container, int clear)
  {
    struct frame *f =3D XFRAME (w->frame);
!   struct device *d =3D XDEVICE (container->device);
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
    GC gc;
  =

    /* We don't use the normal gutter measurements here because the
***************
*** 1358,1365 ****
  #ifdef HAVE_SCROLLBARS
    else
      x1 =3D WINDOW_RIGHT (w) - X_DIVIDER_WIDTH;
-   x2 =3D x1 + X_DIVIDER_SPACING;
  #endif
  =

  #ifdef HAVE_SCROLLBARS
    if (f->scrollbar_on_top)
--- 1465,1472 ----
  #ifdef HAVE_SCROLLBARS
    else
      x1 =3D WINDOW_RIGHT (w) - X_DIVIDER_WIDTH;
  #endif
+   x2 =3D x1 + X_DIVIDER_SPACING;
  =

  #ifdef HAVE_SCROLLBARS
    if (f->scrollbar_on_top)
***************
*** 1371,1381 ****
  =

    /* Draw the divider in the window. */
    {
-     /* Clear the divider area first.  This needs to be done when a
-        window split occurs. */
-     if (clear)
-       XClearArea (dpy, x_win, x1, y1, X_DIVIDER_WIDTH, y2 - y1, False);=

- =

      /* #### There needs to be some checks to make sure that whatever
         colors we choose, the line will be visible (not same color as
         default background.
--- 1478,1483 ----
***************
*** 1386,1391 ****
--- 1488,1499 ----
  		   WINDOW_FACE_CACHEL_FOREGROUND (w, MODELINE_INDEX),
  		   Qnil, Qnil);
  =

+     /* Clear the divider area first.  This needs to be done when a
+        window split occurs. */
+     if (clear)
+       EmacsXClearAreaGC (dpy, x_win, x1, y1, X_DIVIDER_WIDTH, y2 - y1,
+ 			 False, d, gc);
+ =

      /* Draw the divider line. */
      XFillRectangle (dpy, x_win, gc, x2, y1, X_DIVIDER_LINE_WIDTH, y2 - =
y1);
    }
***************
*** 1418,1431 ****
   of its face.
   **********************************************************************=
******/
  static void
! x_output_blank (struct window *w, struct display_line *dl, struct rune =
*rb,
  		int start_pixpos, int cursor_start, int cursor_width)
  {
!   struct frame *f =3D XFRAME (w->frame);
!   struct device *d =3D XDEVICE (f->device);
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
-   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
    GC gc;
    struct face_cachel *cursor_cachel =3D
      WINDOW_FACE_CACHEL (w,
--- 1526,1538 ----
   of its face.
   **********************************************************************=
******/
  static void
! x_output_blank (Drawable x_win, struct window *w, struct frame *contain=
er,
! 		struct display_line *dl, struct rune *rb,
  		int start_pixpos, int cursor_start, int cursor_width)
  {
!   struct device *d =3D XDEVICE (container->device);
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
    GC gc;
    struct face_cachel *cursor_cachel =3D
      WINDOW_FACE_CACHEL (w,
***************
*** 1476,1482 ****
  	      && cursor_start < (x + width))))
      {
        int cursor_height, cursor_y;
!       int focus =3D EQ (w->frame, DEVICE_FRAME_WITH_FOCUS_REAL (d));
        struct Lisp_Font_Instance *fi;
  =

        fi =3D XFONT_INSTANCE (FACE_CACHEL_FONT
--- 1583,1590 ----
  	      && cursor_start < (x + width))))
      {
        int cursor_height, cursor_y;
!       struct device *fd =3D XDEVICE (XFRAME (w->frame)->device);
!       int focus =3D window_frame_really_selected_p (w, fd);
        struct Lisp_Font_Instance *fi;
  =

        fi =3D XFONT_INSTANCE (FACE_CACHEL_FONT
***************
*** 1522,1534 ****
   Output a horizontal line in the foreground of its face.
   **********************************************************************=
******/
  static void
! x_output_hline (struct window *w, struct display_line *dl, struct rune =
*rb)
  {
!   struct frame *f =3D XFRAME (w->frame);
!   struct device *d =3D XDEVICE (f->device);
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
-   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
    GC gc;
  =

    int x =3D rb->xpos;
--- 1630,1641 ----
   Output a horizontal line in the foreground of its face.
   **********************************************************************=
******/
  static void
! x_output_hline (Drawable x_win, struct window *w, struct frame *contain=
er,
! 		struct display_line *dl, struct rune *rb)
  {
!   struct device *d =3D XDEVICE (container->device);
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
    GC gc;
  =

    int x =3D rb->xpos;
***************
*** 1570,1586 ****
   x_output_shadows
  =

   Draw a shadow around the given area using the given GC's.  It is the
!  callers responsibility to ste the GC's appropriately.
   **********************************************************************=
******/
  void
! x_output_shadows (struct frame *f, int x, int y, int width, int height,=

! 		  GC top_shadow_gc, GC bottom_shadow_gc, GC background_gc,
! 		  int shadow_thickness)
  {
    struct device *d =3D XDEVICE (f->device);
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
-   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
  =

    XSegment top_shadow[20], bottom_shadow[20];
    int elt;
--- 1677,1692 ----
   x_output_shadows
  =

   Draw a shadow around the given area using the given GC's.  It is the
!  callers responsibility to set the GC's appropriately.
   **********************************************************************=
******/
  void
! x_output_shadows (Drawable x_win, struct frame *f, int x, int y, int wi=
dth,
! 		  int height, GC top_shadow_gc, GC bottom_shadow_gc,
! 		  GC background_gc, int shadow_thickness)
  {
    struct device *d =3D XDEVICE (f->device);
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
  =

    XSegment top_shadow[20], bottom_shadow[20];
    int elt;
***************
*** 1713,1719 ****
   background color.
   **********************************************************************=
******/
  static void
! x_clear_to_window_end (struct window *w, int ypos1, int ypos2)
  {
    int height =3D ypos2 - ypos1;
  =

--- 1819,1826 ----
   background color.
   **********************************************************************=
******/
  static void
! x_clear_to_window_end (Drawable x_win, struct window *w, struct frame *=
container,
! 		       int ypos1, int ypos2)
  {
    int height =3D ypos2 - ypos1;
  =

***************
*** 1728,1754 ****
        XSETWINDOW (window, w);
  =

        if (window_is_leftmost (w))
! 	x_clear_region (window, DEFAULT_INDEX, FRAME_LEFT_BORDER_START (f),
  			ypos1, FRAME_BORDER_WIDTH (f), height);
  =

        if (bounds.left_in - bounds.left_out > 0)
! 	x_clear_region (window,
  			get_builtin_face_cache_index (w, Vleft_margin_face),
  			bounds.left_out, ypos1,
  			bounds.left_in - bounds.left_out, height);
  =

        if (bounds.right_in - bounds.left_in > 0)
! 	x_clear_region (window, DEFAULT_INDEX, bounds.left_in, ypos1,
! 			bounds.right_in - bounds.left_in, height);
  =

        if (bounds.right_out - bounds.right_in > 0)
! 	x_clear_region (window,
  			get_builtin_face_cache_index (w, Vright_margin_face),
  			bounds.right_in, ypos1,
  			bounds.right_out - bounds.right_in, height);
  =

        if (window_is_rightmost (w))
! 	x_clear_region (window, DEFAULT_INDEX, FRAME_RIGHT_BORDER_START (f),
  			ypos1, FRAME_BORDER_WIDTH (f), height);
      }
  }
--- 1835,1864 ----
        XSETWINDOW (window, w);
  =

        if (window_is_leftmost (w))
! 	x_clear_region (x_win, window, container, DEFAULT_INDEX,
! 			FRAME_LEFT_BORDER_START (f),
  			ypos1, FRAME_BORDER_WIDTH (f), height);
  =

        if (bounds.left_in - bounds.left_out > 0)
! 	x_clear_region (x_win, window, container,
  			get_builtin_face_cache_index (w, Vleft_margin_face),
  			bounds.left_out, ypos1,
  			bounds.left_in - bounds.left_out, height);
  =

        if (bounds.right_in - bounds.left_in > 0)
! 	x_clear_region (x_win, window, container, DEFAULT_INDEX,
! 			bounds.left_in,
! 			ypos1, bounds.right_in - bounds.left_in, height);
  =

        if (bounds.right_out - bounds.right_in > 0)
! 	x_clear_region (x_win, window, container,
  			get_builtin_face_cache_index (w, Vright_margin_face),
  			bounds.right_in, ypos1,
  			bounds.right_out - bounds.right_in, height);
  =

        if (window_is_rightmost (w))
! 	x_clear_region (x_win, window, container, DEFAULT_INDEX,
! 			FRAME_RIGHT_BORDER_START (f),
  			ypos1, FRAME_BORDER_WIDTH (f), height);
      }
  }
***************
*** 1767,1773 ****
    int line;
    int start_x, start_y, end_x, end_y;
    int orig_windows_structure_changed;
! =

    display_line_dynarr *cdla =3D window_display_lines (w, CURRENT_DISP);=

  =

    if (!NILP (w->vchild))
--- 1877,1884 ----
    int line;
    int start_x, start_y, end_x, end_y;
    int orig_windows_structure_changed;
!   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
!   =

    display_line_dynarr *cdla =3D window_display_lines (w, CURRENT_DISP);=

  =

    if (!NILP (w->vchild))
***************
*** 1802,1808 ****
  =

    if (window_needs_vertical_divider (w))
      {
!       x_output_vertical_divider (w, 0);
      }
  =

    for (line =3D 0; line < Dynarr_length (cdla); line++)
--- 1913,1919 ----
  =

    if (window_needs_vertical_divider (w))
      {
!       x_output_vertical_divider (x_win, w, f, 0);
      }
  =

    for (line =3D 0; line < Dynarr_length (cdla); line++)
***************
*** 1822,1828 ****
  	    }
  	  else
  	    {
! 	      output_display_line (w, 0, cdla, line, start_x, end_x);
  	    }
  	}
      }
--- 1933,1939 ----
  	    }
  	  else
  	    {
! 	      output_display_line (x_win, w, 0, cdla, line, start_x, end_x);
  	    }
  	}
      }
***************
*** 1832,1838 ****
    /* If there have never been any face cache_elements created, then thi=
s
       expose event doesn't actually have anything to do. */
    if (Dynarr_largest (w->face_cachels))
!     redisplay_clear_bottom_of_window (w, cdla, start_y, end_y);
  }
  =

  /**********************************************************************=
*******
--- 1943,1950 ----
    /* If there have never been any face cache_elements created, then thi=
s
       expose event doesn't actually have anything to do. */
    if (Dynarr_largest (w->face_cachels))
!     redisplay_clear_bottom_of_window (XtWindow (FRAME_X_TEXT_WIDGET (f)=
), w,
! 				      cdla, start_y, end_y);
  }
  =

  /**********************************************************************=
*******
***************
*** 1886,1895 ****
  =

   Clear the area in the box defined by the given parameters using the
   given face.
   **********************************************************************=
******/
  static void
! x_clear_region (Lisp_Object locale, face_index findex, int x, int y,
! 		int width, int height)
  {
    struct window *w =3D 0;
    struct frame *f =3D 0;
--- 1998,2008 ----
  =

   Clear the area in the box defined by the given parameters using the
   given face.
+  PARENT is the frame if LOCALE is a window.  (added to support subframe=
s)
   **********************************************************************=
******/
  static void
! x_clear_region (Drawable x_win, Lisp_Object locale, struct frame *conta=
iner,
! 		face_index findex, int x, int y, int width, int height)
  {
    struct window *w =3D 0;
    struct frame *f =3D 0;
***************
*** 1897,1903 ****
    Lisp_Object background_pixmap;
  =

    Display *dpy;
-   Window x_win;
  =

    if (WINDOWP (locale))
      {
--- 2010,2015 ----
***************
*** 1912,1920 ****
    else
      abort ();
  =

!   d =3D XDEVICE (f->device);
    dpy =3D DEVICE_X_DISPLAY (d);
-   x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
  =

    /* #### This function is going to have to be made cursor aware. */
    if (width && height)
--- 2024,2031 ----
    else
      abort ();
  =

!   d =3D XDEVICE (container->device);
    dpy =3D DEVICE_X_DISPLAY (d);
  =

    /* #### This function is going to have to be made cursor aware. */
    if (width && height)
***************
*** 2000,2007 ****
  	  XFillRectangle (dpy, x_win, gc, x, y, width, height);
  	}
        else
! 	{
! 	  XClearArea (dpy, x_win, x, y, width, height, False);
  	}
      }
  }
--- 2111,2118 ----
  	  XFillRectangle (dpy, x_win, gc, x, y, width, height);
  	}
        else
! 	{  =

! 	  EmacsXClearArea (dpy, x_win, x, y, width, height, False, d, locale);=

  	}
      }
  }
***************
*** 2013,2030 ****
   narrower than the normal cursor.
   **********************************************************************=
******/
  static void
! x_output_eol_cursor (struct window *w, struct display_line *dl, int xpo=
s)
  {
!   struct frame *f =3D XFRAME (w->frame);
!   struct device *d =3D XDEVICE (f->device);
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
-   Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f));
    GC gc;
    face_index elt =3D get_builtin_face_cache_index (w, Vtext_cursor_face=
);
    struct face_cachel *cursor_cachel =3D WINDOW_FACE_CACHEL (w, elt);
  			=

!   int focus =3D EQ (w->frame, DEVICE_FRAME_WITH_FOCUS_REAL (d));
    Lisp_Object bar_cursor_value =3D symbol_value_in_buffer (Qbar_cursor,=

  							 WINDOW_BUFFER (w));
  =

--- 2124,2141 ----
   narrower than the normal cursor.
   **********************************************************************=
******/
  static void
! x_output_eol_cursor (Drawable x_win, struct window *w, struct frame *co=
ntainer,
! 		     struct display_line *dl, int xpos)
  {
!   struct device *d =3D XDEVICE (container->device);
  =

    Display *dpy =3D DEVICE_X_DISPLAY (d);
    GC gc;
    face_index elt =3D get_builtin_face_cache_index (w, Vtext_cursor_face=
);
    struct face_cachel *cursor_cachel =3D WINDOW_FACE_CACHEL (w, elt);
  			=

!   struct device *fd =3D XDEVICE (XFRAME (w->frame)->device);
!   int focus =3D window_frame_really_selected_p (w, fd);
    Lisp_Object bar_cursor_value =3D symbol_value_in_buffer (Qbar_cursor,=

  							 WINDOW_BUFFER (w));
  =

***************
*** 2035,2047 ****
    int cursor_height, cursor_y;
    int defheight, defascent;
    =

!   XClearArea (dpy, x_win, x, y, width, height, False);
  =

    if (NILP (w->text_cursor_visible_p))
      return;
  =

-   gc =3D x_get_gc (d, Qnil, cursor_cachel->background, Qnil, Qnil, Qnil=
);
- =

    {
      Lisp_Object window =3D Qnil;
  =

--- 2146,2158 ----
    int cursor_height, cursor_y;
    int defheight, defascent;
    =

!   gc =3D x_get_gc (d, Qnil, cursor_cachel->background, Qnil, Qnil, Qnil=
);
! =

!   EmacsXClearAreaGC (dpy, x_win, x, y, width, height, False, d, gc);
  =

    if (NILP (w->text_cursor_visible_p))
      return;
  =

    {
      Lisp_Object window =3D Qnil;
  =

***************
*** 2083,2089 ****
  x_clear_frame_window (Lisp_Object window)
  {
    struct window *w =3D XWINDOW (window);
! =

    if (!NILP (w->vchild))
      {
        x_clear_frame_windows (w->vchild);
--- 2194,2201 ----
  x_clear_frame_window (Lisp_Object window)
  {
    struct window *w =3D XWINDOW (window);
!   struct frame *f =3D XFRAME (w->frame);
!   =

    if (!NILP (w->vchild))
      {
        x_clear_frame_windows (w->vchild);
***************
*** 2096,2102 ****
        return;
      }
  =

!   x_clear_to_window_end (w, WINDOW_TEXT_TOP (w), WINDOW_TEXT_BOTTOM (w)=
);
  }
  =

  static void
--- 2208,2215 ----
        return;
      }
  =

!   x_clear_to_window_end (XtWindow (FRAME_X_TEXT_WIDGET (f)),
! 			 w, f, WINDOW_TEXT_TOP (w), WINDOW_TEXT_BOTTOM (w));
  }
  =

  static void
***************
*** 2125,2134 ****
    height =3D (FRAME_PIXHEIGHT (f) - FRAME_REAL_TOP_TOOLBAR_HEIGHT (f) -=

  	    FRAME_REAL_BOTTOM_TOOLBAR_HEIGHT (f)) + 1;
  =

-   XClearArea (dpy, x_win, x, y, width, height, False);
- =

    XSETFRAME (frame, f);
  =

    if (!UNBOUNDP (FACE_BACKGROUND_PIXMAP (Vdefault_face, frame))
        || !UNBOUNDP (FACE_BACKGROUND_PIXMAP (Vleft_margin_face, frame))
        || !UNBOUNDP (FACE_BACKGROUND_PIXMAP (Vright_margin_face, frame))=
)
--- 2238,2247 ----
    height =3D (FRAME_PIXHEIGHT (f) - FRAME_REAL_TOP_TOOLBAR_HEIGHT (f) -=

  	    FRAME_REAL_BOTTOM_TOOLBAR_HEIGHT (f)) + 1;
  =

    XSETFRAME (frame, f);
  =

+   EmacsXClearArea (dpy, x_win, x, y, width, height, False, d, frame);
+ =

    if (!UNBOUNDP (FACE_BACKGROUND_PIXMAP (Vdefault_face, frame))
        || !UNBOUNDP (FACE_BACKGROUND_PIXMAP (Vleft_margin_face, frame))
        || !UNBOUNDP (FACE_BACKGROUND_PIXMAP (Vright_margin_face, frame))=
)
***************
*** 2143,2149 ****
   */
  =

  static int
! x_flash (struct device *d)
  {
    Display *dpy;
    Window w;
--- 2256,2262 ----
   */
  =

  static int
! x_flash (struct frame *f)
  {
    Display *dpy;
    Window w;
***************
*** 2151,2157 ****
    GC gc;
    XColor tmp_fcolor, tmp_bcolor;
    Lisp_Object tmp_pixel, frame;
-   struct frame *f =3D device_selected_frame (d);
    Widget shell =3D FRAME_X_SHELL_WIDGET (f);
    Dimension width, height;
  =

--- 2264,2269 ----
***************
*** 2196,2203 ****
  /* Make audible bell.  */
  =

  static void
! x_ring_bell (struct device *d, int volume, int pitch, int duration)
  {
    Display *display =3D DEVICE_X_DISPLAY (d);
  =

    if (volume < 0) volume =3D 0;
--- 2308,2316 ----
  /* Make audible bell.  */
  =

  static void
! x_ring_bell (struct frame *f, int volume, int pitch, int duration)
  {
+   struct device *d =3D XDEVICE (f->device);
    Display *display =3D DEVICE_X_DISPLAY (d);
  =

    if (volume < 0) volume =3D 0;
***************
*** 2252,2255 ****
--- 2365,2376 ----
    CONSOLE_HAS_METHOD (x, output_end);
    CONSOLE_HAS_METHOD (x, flash);
    CONSOLE_HAS_METHOD (x, ring_bell);
+   CONSOLE_HAS_METHOD (x, drawable);
+ =

+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (x, string);
+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (x, eol_cursor);
+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (x, blank);
+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (x, hline);
+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (x, pixmap);
+   CONSOLE_HAS_OUTPUT_PRIMITIVE_METHOD (x, bevel_modeline);
  }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/redisplay.c xemacs-19.15-b2-made/src/redisplay.c
*** xemacs-19.15-b2/src/redisplay.c	Mon Sep 16 17:48:48 1996
--- xemacs-19.15-b2-made/src/redisplay.c	Mon Nov 11 23:26:26 1996
***************
*** 41,46 ****
--- 41,48 ----
  #include <config.h>
  #include "lisp.h"
  =

+ #include "console-glyph.h"
+ =

  #include "buffer.h"
  #include "commands.h"
  #include "debug.h"
***************
*** 290,295 ****
--- 292,298 ----
  				     Bufpos point, int no_regen);
  static Bufpos line_start_cache_start (struct window *w);
  static Bufpos line_start_cache_end (struct window *w);
+ Lisp_Object frame_glyph_set_likely_container (struct frame *f);
  =

  /* This used to be 10 but 30 seems to give much better performance. */
  #define INIT_MAX_PREEMPTS	30
***************
*** 420,425 ****
--- 423,432 ----
     time redisplay completed */
  int windows_structure_changed;
  =

+ /* non-zero if a sub frame needs to be updated */
+ int sub_frame_changed;
+ int check_sub_frame_changed;
+ =

  /* If non-nil, use vertical bar cursor. */
  Lisp_Object Vbar_cursor;
  Lisp_Object Qbar_cursor;
***************
*** 486,498 ****
  {
    unsigned char charsets[NUM_LEADING_BYTES];
    Lisp_Object window =3D Qnil;
! =

    find_charsets_in_emchar_string (charsets, str, len);
    XSETWINDOW (window, w);
    ensure_face_cachel_complete (WINDOW_FACE_CACHEL (w, findex), window,
  			       charsets);
!   return DEVMETH (XDEVICE (FRAME_DEVICE (XFRAME (WINDOW_FRAME (w)))),
! 		  text_width, (WINDOW_FACE_CACHEL (w, findex),
  			       str, len));
  }
  =

--- 493,507 ----
  {
    unsigned char charsets[NUM_LEADING_BYTES];
    Lisp_Object window =3D Qnil;
!   struct frame *f;
!   =

    find_charsets_in_emchar_string (charsets, str, len);
    XSETWINDOW (window, w);
    ensure_face_cachel_complete (WINDOW_FACE_CACHEL (w, findex), window,
  			       charsets);
!   f =3D XFRAME (WINDOW_FRAME (w));
!   return DEVMETH (XDEVICE (FRAME_DEVICE (f)),
! 		  text_width, (f, WINDOW_FACE_CACHEL (w, findex),
  			       str, len));
  }
  =

***************
*** 503,508 ****
--- 512,521 ----
  			     Bufbyte *nonreloc, Lisp_Object reloc,
  			     Bytecount offset, Bytecount len)
  {
+   Lisp_Object container;
+   struct frame *f =3D XFRAME (w->frame);
+   int width;
+   =

    if (!rtw_emchar_dynarr)
      rtw_emchar_dynarr =3D Dynarr_new (Emchar);
    Dynarr_reset (rtw_emchar_dynarr);
***************
*** 511,519 ****
    if (STRINGP (reloc))
      nonreloc =3D string_data (XSTRING (reloc));
    convert_bufbyte_string_into_emchar_dynarr (nonreloc, len, rtw_emchar_=
dynarr);
!   return redisplay_text_width_emchar_string
      (w, findex, Dynarr_atp (rtw_emchar_dynarr, 0),
       Dynarr_length (rtw_emchar_dynarr));
  }
  =

  int
--- 524,546 ----
    if (STRINGP (reloc))
      nonreloc =3D string_data (XSTRING (reloc));
    convert_bufbyte_string_into_emchar_dynarr (nonreloc, len, rtw_emchar_=
dynarr);
! =

!   if (FRAME_GLYPH_P (f))
!     {
!       container =3D frame_glyph_set_likely_container (f);
!       if (UNBOUNDP (container))
! 	return 0;
!     }
!   else
!     container =3D Qnil;
! =

!   width =3D redisplay_text_width_emchar_string
      (w, findex, Dynarr_atp (rtw_emchar_dynarr, 0),
       Dynarr_length (rtw_emchar_dynarr));
+ =

+   if (!NILP (container))
+     FRAMEMETH (f, set_container_frame, (f, Qnil));
+   return width;
  }
  =

  int
***************
*** 539,545 ****
    XSETFRAME (frame, f);
    ensure_face_cachel_complete (&cachel, frame, charsets);
    return DEVMETH (XDEVICE (FRAME_DEVICE (f)),
! 		  text_width, (&cachel, Dynarr_atp (rtw_emchar_dynarr, 0),
  			       Dynarr_length (rtw_emchar_dynarr)));
  }
  =

--- 566,572 ----
    XSETFRAME (frame, f);
    ensure_face_cachel_complete (&cachel, frame, charsets);
    return DEVMETH (XDEVICE (FRAME_DEVICE (f)),
! 		  text_width, (f, &cachel, Dynarr_atp (rtw_emchar_dynarr, 0),
  			       Dynarr_length (rtw_emchar_dynarr)));
  }
  =

***************
*** 1749,1754 ****
--- 1776,1787 ----
    return NULL;
  }
  =

+ /* Non-zero if W is really the selected window */
+ #define window_really_selected_p(w, d)					\
+ ((w =3D=3D XWINDOW (FRAME_SELECTED_WINDOW (device_selected_frame (d))))=
	\
+  && EQ (d->console, Vselected_console)					\
+  && NILP (CONSOLE_SELECTED_SUB_FRAME (XCONSOLE (d->console))))
+ =

  /* Given a position for a buffer in a window, ensure that the given
     display line DL accurately represents the text on a line starting
     at the given position.
***************
*** 1893,1899 ****
      }
    else if (MINI_WINDOW_P (w) && !active_minibuffer)
      data.cursor_type =3D NO_CURSOR;
!   else if (w =3D=3D XWINDOW (FRAME_SELECTED_WINDOW (device_selected_fra=
me (d))))
      {
        data.bi_cursor_bufpos =3D BI_BUF_PT (b);
        data.cursor_type =3D CURSOR_ON;
--- 1926,1932 ----
      }
    else if (MINI_WINDOW_P (w) && !active_minibuffer)
      data.cursor_type =3D NO_CURSOR;
!   else if (window_really_selected_p (w, d))
      {
        data.bi_cursor_bufpos =3D BI_BUF_PT (b);
        data.cursor_type =3D CURSOR_ON;
***************
*** 2136,2142 ****
  			 line with a special "character rune" whose width
  			 is the EOL cursor width and whose character is
  			 the non-printing character '\n'. */
! 		      data.blank_width =3D DEVMETH (d, eol_cursor_width, ());
  		      *prop =3D add_emchar_rune (&data);
  		    }
  =

--- 2169,2175 ----
  			 line with a special "character rune" whose width
  			 is the EOL cursor width and whose character is
  			 the non-printing character '\n'. */
! 		      data.blank_width =3D DEVMETH (d, eol_cursor_width, (f));
  		      *prop =3D add_emchar_rune (&data);
  		    }
  =

***************
*** 2162,2168 ****
  		}
  	      else
  		{
! 		  data.blank_width =3D DEVMETH (d, eol_cursor_width, ());
  		  *prop =3D add_emchar_rune (&data);
  		}
  =

--- 2195,2201 ----
  		}
  	      else
  		{
! 		  data.blank_width =3D DEVMETH (d, eol_cursor_width, (f));
  		  *prop =3D add_emchar_rune (&data);
  		}
  =

***************
*** 2222,2228 ****
  		  /* We have to at least add a newline character so
                       that the cursor shows up properly. */
  		  data.ch =3D '\n';
! 		  data.blank_width =3D DEVMETH (d, eol_cursor_width, ());
  		  data.findex =3D DEFAULT_INDEX;
  		  data.start_col =3D 0;
  		  data.bi_start_col_enabled =3D 0;
--- 2255,2261 ----
  		  /* We have to at least add a newline character so
                       that the cursor shows up properly. */
  		  data.ch =3D '\n';
! 		  data.blank_width =3D DEVMETH (d, eol_cursor_width, (f));
  		  data.findex =3D DEFAULT_INDEX;
  		  data.start_col =3D 0;
  		  data.bi_start_col_enabled =3D 0;
***************
*** 2380,2386 ****
  		  /* This duplicates code down below to add a newline to
                       the end of an otherwise empty line.*/
  		  data.ch =3D '\n';
! 		  data.blank_width =3D DEVMETH (d, eol_cursor_width, ());
  =

  		  add_emchar_rune (&data);
  		}
--- 2413,2419 ----
  		  /* This duplicates code down below to add a newline to
                       the end of an otherwise empty line.*/
  		  data.ch =3D '\n';
! 		  data.blank_width =3D DEVMETH (d, eol_cursor_width, (f));
  =

  		  add_emchar_rune (&data);
  		}
***************
*** 2460,2466 ****
           whitespace routines below. */
  =

        data.ch =3D '\n';
!       data.blank_width =3D DEVMETH (d, eol_cursor_width, ());
        data.findex =3D DEFAULT_INDEX;
        data.start_col =3D 0;
        data.bi_start_col_enabled =3D 0;
--- 2493,2499 ----
           whitespace routines below. */
  =

        data.ch =3D '\n';
!       data.blank_width =3D DEVMETH (d, eol_cursor_width, (f));
        data.findex =3D DEFAULT_INDEX;
        data.start_col =3D 0;
        data.bi_start_col_enabled =3D 0;
***************
*** 3479,3488 ****
        struct rune rb;
  =

        /* If there is a horizontal scrollbar, don't add anything. */
!       if (window_scrollbar_height (w))
  	return;
  =

!       dl->ascent =3D DEVMETH (d, divider_height, ());
        dl->descent =3D 0;
        /* The modeline is at the bottom of the gutters. */
        dl->ypos =3D WINDOW_BOTTOM (w);
--- 3512,3522 ----
        struct rune rb;
  =

        /* If there is a horizontal scrollbar, don't add anything. */
!       if (window_scrollbar_height (w) ||
! 	  !WINDOW_HAS_VERTICAL_DIVIDER_P (w))
  	return;
  =

!       dl->ascent =3D DEVMETH (d, divider_height, (f));
        dl->descent =3D 0;
        /* The modeline is at the bottom of the gutters. */
        dl->ypos =3D WINDOW_BOTTOM (w);
***************
*** 4065,4074 ****
        Dynarr_length (formatted_string_emchar_dynarr), 0);
  }
  =

  /* Update just the modeline.  Assumes the desired display structs.  If
     they do not have a modeline block, it does nothing. */
  static void
! regenerate_modeline (struct window *w)
  {
    display_line_dynarr *dla =3D window_display_lines (w, DESIRED_DISP);
  =

--- 4099,4129 ----
        Dynarr_length (formatted_string_emchar_dynarr), 0);
  }
  =

+ Lisp_Object
+ frame_glyph_set_likely_container (struct frame *f)
+ {
+   Lisp_Object container;
+   =

+   container =3D FRAME_GLYPH_CONTAINER (f);
+   if (NILP (container))
+     {
+       container =3D FRAME_GLYPH_SELECTED_LOCALE (f);
+       if (NILP (container))
+ 	{
+ 	  container =3D FRAME_GLYPH_LOCALE (f);
+ 	  if (!FRAMEP (container))
+ 	    return Qunbound;
+ 	}
+       FRAME_GLYPH_CONTAINER (f) =3D container;
+       return container;
+     }
+   return Qnil;
+ }
+ =

  /* Update just the modeline.  Assumes the desired display structs.  If
     they do not have a modeline block, it does nothing. */
  static void
! regenerate_modeline (Drawable drw, struct window *w)
  {
    display_line_dynarr *dla =3D window_display_lines (w, DESIRED_DISP);
  =

***************
*** 4077,4083 ****
    else
      {
        generate_modeline (w, Dynarr_atp (dla, 0), DESIRED_DISP);
!       redisplay_update_line (w, 0, 0, 0);
      }
  }
  =

--- 4132,4138 ----
    else
      {
        generate_modeline (w, Dynarr_atp (dla, 0), DESIRED_DISP);
!       redisplay_update_line (drw, w, 0, 0, 0);
      }
  }
  =

***************
*** 4130,4135 ****
--- 4185,4191 ----
        /* If we're adding a new place marker go ahead and generate the
           modeline so that it is available for use by
           window_modeline_height. */
+       =

        generate_modeline (w, Dynarr_atp (dla, 0), type);
      }
  =

***************
*** 4140,4149 ****
  int
  real_current_modeline_height (struct window *w)
  {
    Fset_marker (w->start[CMOTION_DISP], w->start[CURRENT_DISP], w->buffe=
r);
    Fset_marker (w->pointm[CMOTION_DISP], w->pointm[CURRENT_DISP], w->buf=
fer);
  =

!   if (ensure_modeline_generated (w, CMOTION_DISP))
      {
        display_line_dynarr *dla;
  =

--- 4196,4222 ----
  int
  real_current_modeline_height (struct window *w)
  {
+   struct frame *f =3D XFRAME (w->frame);
+   Lisp_Object container;
+   int g;
+   =

    Fset_marker (w->start[CMOTION_DISP], w->start[CURRENT_DISP], w->buffe=
r);
    Fset_marker (w->pointm[CMOTION_DISP], w->pointm[CURRENT_DISP], w->buf=
fer);
  =

!   if (FRAME_GLYPH_P (f))
!     {
!       container =3D frame_glyph_set_likely_container (f);
!       if (UNBOUNDP (container))
! 	return 0;
!     }
!   else container =3D Qnil;
!   =

!   g =3D ensure_modeline_generated (w, CMOTION_DISP);
!   =

!   if (!NILP (container))
!     FRAMEMETH (f, set_container_frame, (f, Qnil));
!   =

!   if (g)
      {
        display_line_dynarr *dla;
  =

***************
*** 4374,4381 ****
     when dealing with buffer changes. */
  =

  static int
! regenerate_window_extents_only_changed (struct window *w, Bufpos startp=
,
! 					Bufpos pointm,
  					Charcount beg_unchanged,
  					Charcount end_unchanged)
  {
--- 4447,4454 ----
     when dealing with buffer changes. */
  =

  static int
! regenerate_window_extents_only_changed (Drawable drw, struct window *w,=

! 					Bufpos startp, Bufpos pointm,
  					Charcount beg_unchanged,
  					Charcount end_unchanged)
  {
***************
*** 4390,4396 ****
    /* Don't define this in the loop where it is used because we
       definitely want its value to survive between passes. */
    prop_block_dynarr *prop =3D NULL;
! =

    /* If we don't have any buffer change recorded but the modiff flag ha=
s
       been incremented, then fail.  I'm not sure of the exact circumstan=
ces
       under which this can happen, but I believe that it is probably a
--- 4463,4470 ----
    /* Don't define this in the loop where it is used because we
       definitely want its value to survive between passes. */
    prop_block_dynarr *prop =3D NULL;
!   struct frame *f =3D XFRAME (w->frame);
!   =

    /* If we don't have any buffer change recorded but the modiff flag ha=
s
       been incremented, then fail.  I'm not sure of the exact circumstan=
ces
       under which this can happen, but I believe that it is probably a
***************
*** 4404,4430 ****
    if (!EQ (Fmarker_buffer (w->last_point[CURRENT_DISP]), w->buffer)
        || pointm !=3D marker_position (w->last_point[CURRENT_DISP]))
      {
-       struct frame *f =3D XFRAME (w->frame);
        struct device *d =3D XDEVICE (f->device);
-       struct frame *sel_f =3D device_selected_frame (d);
        int success =3D 0;
  =

        if (w->last_point_x[CURRENT_DISP] !=3D -1
  	  && w->last_point_y[CURRENT_DISP] !=3D -1)
  	{
! =

! 	  if (redisplay_move_cursor (w, pointm, WINDOW_TTY_P (w)))
  	    {
  	      /* Always regenerate the modeline in case it is
                   displaying the current line or column. */
! 	      regenerate_modeline (w);
  	      success =3D 1;
  	    }
  	}
!       else if (w !=3D XWINDOW (FRAME_SELECTED_WINDOW (sel_f)))
  	{
  	  if (f->modeline_changed)
! 	    regenerate_modeline (w);
  	  success =3D 1;
  	}
  =

--- 4478,4501 ----
    if (!EQ (Fmarker_buffer (w->last_point[CURRENT_DISP]), w->buffer)
        || pointm !=3D marker_position (w->last_point[CURRENT_DISP]))
      {
        struct device *d =3D XDEVICE (f->device);
        int success =3D 0;
  =

        if (w->last_point_x[CURRENT_DISP] !=3D -1
  	  && w->last_point_y[CURRENT_DISP] !=3D -1)
  	{
! 	  if (redisplay_move_cursor (drw, w, pointm, WINDOW_TTY_P (w)))
  	    {
  	      /* Always regenerate the modeline in case it is
                   displaying the current line or column. */
! 	      regenerate_modeline (drw, w);
  	      success =3D 1;
  	    }
  	}
!       else if (!window_really_selected_p (w, d))
  	{
  	  if (f->modeline_changed)
! 	    regenerate_modeline (drw, w);
  	  success =3D 1;
  	}
  =

***************
*** 4551,4557 ****
  	line++;
      }
  =

!   redisplay_update_line (w, first_line, last_line, 1);
    return 1;
  }
  =

--- 4622,4628 ----
  	line++;
      }
  =

!   redisplay_update_line (drw, w, first_line, last_line, 1);
    return 1;
  }
  =

***************
*** 4562,4569 ****
     invariants located here. */
  =

  static int
! regenerate_window_incrementally (struct window *w, Bufpos startp,
! 				 Bufpos pointm)
  {
    struct buffer *b =3D XBUFFER (w->buffer);
    display_line_dynarr *cdla =3D window_display_lines (w, CURRENT_DISP);=

--- 4633,4640 ----
     invariants located here. */
  =

  static int
! regenerate_window_incrementally (Drawable drw, struct window *w,
! 				 Bufpos startp, Bufpos pointm)
  {
    struct buffer *b =3D XBUFFER (w->buffer);
    display_line_dynarr *cdla =3D window_display_lines (w, CURRENT_DISP);=

***************
*** 4592,4598 ****
    /* If nothing has changed in the buffer, then make sure point is ok
       and succeed. */
    if (BUF_BEGIN_UNCHANGED (b) =3D=3D -1 && BUF_END_UNCHANGED (b) =3D=3D=
 -1)
!     return regenerate_window_extents_only_changed (w, startp, pointm,
  						   extent_beg_unchanged,
  						   extent_end_unchanged);
  =

--- 4663,4669 ----
    /* If nothing has changed in the buffer, then make sure point is ok
       and succeed. */
    if (BUF_BEGIN_UNCHANGED (b) =3D=3D -1 && BUF_END_UNCHANGED (b) =3D=3D=
 -1)
!     return regenerate_window_extents_only_changed (drw, w, startp, poin=
tm,
  						   extent_beg_unchanged,
  						   extent_end_unchanged);
  =

***************
*** 4629,4635 ****
       moved return success otherwise fail in order to be safe. */
    if (line > dla_end)
      {
!       return regenerate_window_extents_only_changed (w, startp, pointm,=

  						     extent_beg_unchanged,
  						     extent_end_unchanged);
      }
--- 4700,4706 ----
       moved return success otherwise fail in order to be safe. */
    if (line > dla_end)
      {
!       return regenerate_window_extents_only_changed (drw, w, startp, po=
intm,
  						     extent_beg_unchanged,
  						     extent_end_unchanged);
      }
***************
*** 4724,4731 ****
  	      w->last_point_y[DESIRED_DISP] =3D line;
  	    }
  =

! 	  redisplay_update_line (w, line, line, 1);
! 	  regenerate_modeline (w);
  =

  	  /* #### For now we just flush the cache until this has been
               tested.  After that is done, this should correct the
--- 4795,4802 ----
  	      w->last_point_y[DESIRED_DISP] =3D line;
  	    }
  =

! 	  redisplay_update_line (drw, w, line, line, 1);
! 	  regenerate_modeline (drw, w);
  =

  	  /* #### For now we just flush the cache until this has been
               tested.  After that is done, this should correct the
***************
*** 4758,4764 ****
  		  || (extent_end_unchanged > ddl->end_bufpos)))
  	    {
  	      return
! 		regenerate_window_extents_only_changed (w, startp, pointm,
  							extent_beg_unchanged,
  							extent_end_unchanged);
  	    }
--- 4829,4835 ----
  		  || (extent_end_unchanged > ddl->end_bufpos)))
  	    {
  	      return
! 		regenerate_window_extents_only_changed (drw, w, startp, pointm,
  							extent_beg_unchanged,
  							extent_end_unchanged);
  	    }
***************
*** 4854,4866 ****
--- 4925,4950 ----
    int half;
    int elt;
    int first_elt =3D (MINI_WINDOW_P (w) ? 0 : 1);
+   struct frame *f =3D XFRAME (w->frame);
+   Lisp_Object container;
  =

+   if (FRAME_GLYPH_P (f))
+     {
+       container =3D frame_glyph_set_likely_container (f);
+       if (UNBOUNDP (container))
+ 	return 0;
+     }
+   else container =3D Qnil;
+   =

    if (type =3D=3D CMOTION_DISP)
      regenerate_window (w, start, point, type);
  =

    dla =3D window_display_lines (w, type);
    half =3D window_half_pixpos (w);
  =

+   if (!NILP (container))
+     FRAMEMETH (f, set_container_frame, (f, Qnil));
+   =

    for (elt =3D first_elt; elt < Dynarr_length (dla); elt++)
      {
        struct display_line *dl =3D Dynarr_atp (dla, elt);
***************
*** 4916,4922 ****
      (MINI_WINDOW_P (w) &&
       (f !=3D device_selected_frame (d)) &&
       !is_surrogate_for_selected_frame (f));
! =

    /* #### In the new world this function actually does a bunch of
       optimizations such as buffer-based scrolling, but none of that is
       implemented yet. */
--- 5000,5007 ----
      (MINI_WINDOW_P (w) &&
       (f !=3D device_selected_frame (d)) &&
       !is_surrogate_for_selected_frame (f));
!   Drawable drw;
!   =

    /* #### In the new world this function actually does a bunch of
       optimizations such as buffer-based scrolling, but none of that is
       implemented yet. */
***************
*** 4936,4943 ****
      }
  =

    /* Is this window the selected window on its frame? */
!   selected =3D
!     (w =3D=3D XWINDOW (FRAME_SELECTED_WINDOW (device_selected_frame (d)=
)));
    if (skip_selected && selected)
      return;
  =

--- 5021,5027 ----
      }
  =

    /* Is this window the selected window on its frame? */
!   selected =3D window_really_selected_p (w, d);
    if (skip_selected && selected)
      return;
  =

***************
*** 4951,4956 ****
--- 5035,5042 ----
        echo_active =3D 1;
      }
  =

+   drw =3D FRAMEMETH (f, drawable, (f));
+ =

    b =3D XBUFFER (w->buffer);
  =

    if (echo_active)
***************
*** 5067,5073 ****
  	{
  	  /* If not, we're done. */
  	  if (f->modeline_changed)
! 	    regenerate_modeline (w);
  =

  	  skip_output =3D 1;
  	  goto regeneration_done;
--- 5153,5159 ----
  	{
  	  /* If not, we're done. */
  	  if (f->modeline_changed)
! 	    regenerate_modeline (drw, w);
  =

  	  skip_output =3D 1;
  	  goto regeneration_done;
***************
*** 5087,5097 ****
  		  && w->last_point_x[CURRENT_DISP] !=3D -1
  		  && w->last_point_y[CURRENT_DISP] !=3D -1)
  		{
! 		  if (redisplay_move_cursor (w, pointm, FRAME_TTY_P (f)))
  		    {
  		      /* Always regenerate in case it is displaying
                           the current line or column. */
! 		      regenerate_modeline (w);
  =

  		      skip_output =3D 1;
  		      goto regeneration_done;
--- 5173,5184 ----
  		  && w->last_point_x[CURRENT_DISP] !=3D -1
  		  && w->last_point_y[CURRENT_DISP] !=3D -1)
  		{
! 		  if (redisplay_move_cursor (drw, w, pointm,
! 					     FRAME_TTY_P (f)))
  		    {
  		      /* Always regenerate in case it is displaying
                           the current line or column. */
! 		      regenerate_modeline (drw, w);
  =

  		      skip_output =3D 1;
  		      goto regeneration_done;
***************
*** 5100,5106 ****
  	      else if (!selected && !f->point_changed)
  		{
  		  if (f->modeline_changed)
! 		    regenerate_modeline (w);
  =

  		  skip_output =3D 1;
  		  goto regeneration_done;
--- 5187,5193 ----
  	      else if (!selected && !f->point_changed)
  		{
  		  if (f->modeline_changed)
! 		    regenerate_modeline (drw, w);
  =

  		  skip_output =3D 1;
  		  goto regeneration_done;
***************
*** 5141,5152 ****
  	   && !f->frame_changed
  	   && !truncation_changed
  	   && pointm >=3D startp
! 	   && regenerate_window_incrementally (w, startp, pointm))
      {
        if (f->modeline_changed
  	  || XINT (w->last_modified[CURRENT_DISP]) < BUF_MODIFF (b)
  	  || XINT (w->last_facechange[CURRENT_DISP]) < BUF_FACECHANGE (b))
! 	regenerate_modeline (w);
  =

        skip_output =3D 1;
        goto regeneration_done;
--- 5228,5239 ----
  	   && !f->frame_changed
  	   && !truncation_changed
  	   && pointm >=3D startp
! 	   && regenerate_window_incrementally (drw, w, startp, pointm))
      {
        if (f->modeline_changed
  	  || XINT (w->last_modified[CURRENT_DISP]) < BUF_MODIFF (b)
  	  || XINT (w->last_facechange[CURRENT_DISP]) < BUF_FACECHANGE (b))
! 	regenerate_modeline (drw, w);
  =

        skip_output =3D 1;
        goto regeneration_done;
***************
*** 5210,5216 ****
        Bufpos end =3D (w->window_end_pos[DESIRED_DISP] =3D=3D -1
  		    ? BUF_ZV (b)
  		    : BUF_Z (b) - w->window_end_pos[DESIRED_DISP] - 1);
- =

        update_line_start_cache (w, start, end, pointm, 1);
        redisplay_output_window (w);
      }
--- 5297,5302 ----
***************
*** 5416,5421 ****
--- 5502,5592 ----
    return 0;
  }
  =

+ /* redisplay a frame encapsulated within another object.
+    This redisplay draws the frame into the encapsulating object and is =
called
+    before the object itself is displayed.  Encapsulated devices are ign=
ored in
+    the normal redisplay loop. */
+ =

+ int
+ redisplay_sub_frame (struct frame *f, Lisp_Object container_frame,
+ 		     int preemption_check)
+ {
+   Lisp_Object Old, New;
+   struct device *d =3D XDEVICE (f->device);
+   int preempt;
+   =

+   Old =3D FRAMEMETH (f, container_frame, (f));
+   if (!NILP (Old))	/* avoid recursion */
+     return 0;
+   =

+   if (NILP (container_frame))
+     {
+       container_frame =3D frame_glyph_set_likely_container (f);
+       if (UNBOUNDP (container_frame))
+ 	return 0;
+     }
+   else
+     FRAMEMETH (f, set_container_frame, (f, container_frame));
+ =

+   /*
+   Old =3D d->_selected_frame;
+   if (NILP (Old))
+     {
+       XSETFRAME (New, f);
+       d->_selected_frame =3D New;
+     }
+   */
+   preempt =3D redisplay_frame (f, preemption_check);
+   FRAMEMETH (f, set_container_frame, (f, Qnil));
+   /*d->_selected_frame =3D Old;*/
+   =

+   return preempt;
+ }
+ =

+ /* marks all parent buffers as changed if a sub frame has changed */
+ =

+ static int
+ update_sub_frame_changed (struct device *d)
+ {
+   if (check_sub_frame_changed)
+     {
+       Lisp_Object extents;
+       Lisp_Object extent, next_extent, prev_extent;
+       EXTENT e;
+       int extent_list_changed =3D 0;
+       Lisp_Object glyph =3D DEVICE_GLYPH_GLYPH (d);
+ =

+       extents =3D Fget (glyph, Qextent, Qnil);
+       =

+       next_extent =3D extents;
+       prev_extent =3D Qnil;
+       while (!NILP (next_extent))
+ 	{
+ 	  extent =3D XCAR (next_extent);
+ 	  next_extent =3D XCDR (next_extent);
+ 	  e =3D XEXTENT (extent);
+ 	  if (EXTENT_LIVE_P (e))
+ 	    {
+ 	      extent_changed_for_redisplay (e, 1);
+ 	      sub_frame_changed =3D 1;
+ 	    }
+ 	  else
+ 	    {
+ 	      if (NILP (prev_extent))
+ 		{
+ 		  extent_list_changed =3D 1;
+ 		  extents =3D next_extent;
+ 		}
+ 	      else
+ 		XCDR (prev_extent) =3D next_extent;
+ 	    }
+ 	}
+       if (extent_list_changed)
+ 	Fput (glyph, Qextent, extents);
+     } =

+   return 0;
+ }
+ =

  /* Ensure that all frames on the given device are correctly displayed. =
*/
  =

  static int
***************
*** 5429,5434 ****
--- 5600,5608 ----
    if (DEVICE_STREAM_P (d)) /* nothing to do */
      return 0;
  =

+   if (DEVICE_GLYPH_P (d))
+     return update_sub_frame_changed (d);
+   =

    /* It is possible that redisplay has been called before the
       device is fully initialized.  If so then continue with the
       next device. */
***************
*** 5489,5495 ****
  	      || f->toolbar_changed || f->windows_changed
  	      || f->windows_structure_changed)
  	    {
! 	      preempted =3D redisplay_frame (f, 0);
  	    }
  =

  	  if (preempted)
--- 5663,5672 ----
  	      || f->toolbar_changed || f->windows_changed
  	      || f->windows_structure_changed)
  	    {
! 	      if (FRAME_GLYPH_P (f))
! 		preempted =3D redisplay_sub_frame (f, Qnil, 0);
! 	      else
! 		preempted =3D redisplay_frame (f, 0);
  	    }
  =

  	  if (preempted)
***************
*** 5555,5585 ****
        && !disable_preemption && preemption_count < max_preempts)
      goto done;
  =

!   DEVICE_LOOP_NO_BREAK (devcons, concons)
      {
!       struct device *d =3D XDEVICE (XCAR (devcons));
!       int preempted;
! =

!       if (d->buffers_changed || d->clip_changed || d->extents_changed
! 	  || d->faces_changed || d->frame_changed
! 	  || d->icon_changed || d->menubar_changed
! 	  || d->modeline_changed || d->point_changed || d->size_changed
! 	  || d->toolbar_changed || d->windows_changed
! 	  || d->windows_structure_changed)
  	{
! 	  preempted =3D redisplay_device (d);
! =

! 	  if (preempted)
  	    {
! 	      preemption_count++;
! 	      RESET_CHANGED_SET_FLAGS;
! 	      goto done;
! 	    }
  =

! 	  /* See comment in redisplay_device. */
! 	  if (d->size_changed)
! 	    size_change_failed =3D 1;
  	}
      }
    preemption_count =3D 0;
  =

--- 5732,5771 ----
        && !disable_preemption && preemption_count < max_preempts)
      goto done;
  =

!   extents_changed_set =3D 0;
!   sub_frame_changed =3D 1;
!   check_sub_frame_changed =3D 1;
!   while (sub_frame_changed)
      {
!       sub_frame_changed =3D 0;
!       =

!       DEVICE_LOOP_NO_BREAK (devcons, concons)
  	{
! 	  struct device *d =3D XDEVICE (XCAR (devcons));
! 	  int preempted;
! 	  =

! 	  if (d->buffers_changed || d->clip_changed || d->extents_changed
! 	      || d->faces_changed || d->frame_changed
! 	      || d->icon_changed || d->menubar_changed
! 	      || d->modeline_changed || d->point_changed || d->size_changed
! 	      || d->toolbar_changed || d->windows_changed
! 	      || d->windows_structure_changed)
  	    {
! 	      preempted =3D redisplay_device (d);
  =

! 	      if (preempted)
! 		{
! 		  preemption_count++;
! 		  RESET_CHANGED_SET_FLAGS;
! 		  goto done;
! 		}
! =

! 	      /* See comment in redisplay_device. */
! 	      if (d->size_changed)
! 		size_change_failed =3D 1;
! 	    }
  	}
+       check_sub_frame_changed =3D 0;
      }
    preemption_count =3D 0;
  =

***************
*** 5595,5600 ****
--- 5781,5788 ----
    toolbar_changed =3D 0;
    windows_changed =3D 0;
    windows_structure_changed =3D 0;
+   sub_frame_changed =3D 0;
+   =

    RESET_CHANGED_SET_FLAGS;
  =

    if (faces_changed)
***************
*** 5652,5659 ****
  {
    struct device *d =3D XDEVICE (XFRAME (w->frame)->device);
    struct buffer *b =3D XBUFFER (w->buffer);
!   Bufpos end =3D
!     ((w =3D=3D XWINDOW (FRAME_SELECTED_WINDOW (device_selected_frame (d=
))))
       ? BUF_PT (b)
       : marker_position (w->pointm[type]));
    int lots =3D 999999999;
--- 5840,5847 ----
  {
    struct device *d =3D XDEVICE (XFRAME (w->frame)->device);
    struct buffer *b =3D XBUFFER (w->buffer);
!   Bufpos end =3D =

!     (window_really_selected_p (w, d)
       ? BUF_PT (b)
       : marker_position (w->pointm[type]));
    int lots =3D 999999999;
***************
*** 6233,6241 ****
--- 6421,6431 ----
  int
  point_in_line_start_cache (struct window *w, Bufpos point, int min_past=
)
  {
+   struct frame *f =3D XFRAME (w->frame);
    struct buffer *b =3D XBUFFER (w->buffer);
    line_start_cache_dynarr *cache =3D w->line_start_cache;
    unsigned int top, bottom, pos;
+   Lisp_Object container;
  =

    validate_line_start_cache (w);
    w->line_cache_validation_override++;
***************
*** 6246,6251 ****
--- 6436,6449 ----
    if (min_past < 0 && min_past !=3D -1)
      min_past =3D -min_past;
  =

+   if (FRAME_GLYPH_P (f))
+     {
+       container =3D frame_glyph_set_likely_container (f);
+       if (UNBOUNDP (container))
+ 	return 0;
+     }
+   else container =3D Qnil;
+   =

    if (!Dynarr_length (cache) || line_start_cache_start (w) > point
        || line_start_cache_end (w) < point)
      {
***************
*** 6268,6273 ****
--- 6466,6473 ----
  	  if (!Dynarr_length (cache))
  	    {
  	      w->line_cache_validation_override--;
+ 	      if (!NILP (container))
+ 		FRAMEMETH (f, set_container_frame, (f, Qnil));
  	      return -1;
  	    }
  	}
***************
*** 6353,6358 ****
--- 6553,6560 ----
        || line_start_cache_end (w) < point)
      {
        w->line_cache_validation_override--;
+       if (!NILP (container))
+ 	FRAMEMETH (f, set_container_frame, (f, Qnil));
        return -1;
      }
  =

***************
*** 6397,6402 ****
--- 6599,6606 ----
  	  else
  	    {
  	      w->line_cache_validation_override--;
+ 	      if (!NILP (container))
+ 		FRAMEMETH (f, set_container_frame, (f, Qnil));
  	      return pos;
  	    }
  	}
***************
*** 6411,6416 ****
--- 6615,6622 ----
        if (pos =3D=3D new_pos)
  	{
  	  w->line_cache_validation_override--;
+ 	  if (!NILP (container))
+ 	    FRAMEMETH (f, set_container_frame, (f, Qnil));
  	  return -1;
  	}
      }
***************
*** 6422,6427 ****
--- 6628,6635 ----
  int
  point_would_be_visible (struct window *w, Bufpos startp, Bufpos point)
  {
+   struct frame *f =3D XFRAME (w->frame);
+   Lisp_Object container;
    struct buffer *b =3D XBUFFER (w->buffer);
    int pixpos =3D 0;
    int bottom =3D WINDOW_TEXT_HEIGHT (w);
***************
*** 6440,6445 ****
--- 6648,6661 ----
        return 0;
      }
  =

+   if (FRAME_GLYPH_P (f))
+     {
+       container =3D frame_glyph_set_likely_container (f);
+       if (UNBOUNDP (container))
+ 	return 0;
+     }
+   else container =3D Qnil;
+   =

    validate_line_start_cache (w);
    w->line_cache_validation_override++;
  =

***************
*** 6447,6452 ****
--- 6663,6670 ----
    if (start_elt =3D=3D -1)
      {
        w->line_cache_validation_override--;
+       if (!NILP (container))
+ 	FRAMEMETH (f, set_container_frame, (f, Qnil));
        return 0;
      }
  =

***************
*** 6474,6479 ****
--- 6692,6699 ----
  	  if (start_elt =3D=3D Dynarr_length (w->line_start_cache))
  	    {
  	      w->line_cache_validation_override--;
+ 	      if (!NILP (container))
+ 		FRAMEMETH (f, set_container_frame, (f, Qnil));
  	      return 0;
  	    }
  	}
***************
*** 6485,6490 ****
--- 6705,6712 ----
  	  if (bottom - pixpos < VERTICAL_CLIP (w, 0))
  	    {
  	      w->line_cache_validation_override--;
+ 	      if (!NILP (container))
+ 		FRAMEMETH (f, set_container_frame, (f, Qnil));
  	      return 0;
  	    }
  	}
***************
*** 6493,6498 ****
--- 6715,6722 ----
        if (point <=3D Dynarr_atp (w->line_start_cache, start_elt)->end)
  	{
  	  w->line_cache_validation_override--;
+ 	  if (!NILP (container))
+ 	    FRAMEMETH (f, set_container_frame, (f, Qnil));
  	  return 1;
  	}
  =

***************
*** 6511,6516 ****
--- 6735,6742 ----
  static Bufpos
  start_end_of_last_line (struct window *w, Bufpos startp, int end)
  {
+   struct frame *f =3D XFRAME (w->frame);
+   Lisp_Object container;
    struct buffer *b =3D XBUFFER (w->buffer);
    line_start_cache_dynarr *cache =3D w->line_start_cache;
    int pixpos =3D 0;
***************
*** 6527,6535 ****
      startp =3D BUF_ZV (b);
    cur_start =3D startp;
  =

    start_elt =3D point_in_line_start_cache (w, cur_start, 0);
    if (start_elt =3D=3D -1)
!     abort ();	/* this had better never happen */
  =

    while (1)
      {
--- 6753,6774 ----
      startp =3D BUF_ZV (b);
    cur_start =3D startp;
  =

+   if (FRAME_GLYPH_P (f))
+     {
+       container =3D frame_glyph_set_likely_container (f);
+       if (UNBOUNDP (container))
+ 	return startp;
+     }
+   else container =3D Qnil;
+ =

    start_elt =3D point_in_line_start_cache (w, cur_start, 0);
+ =

    if (start_elt =3D=3D -1)
!     {
!       if (!NILP (container))
! 	FRAMEMETH (f, set_container_frame, (f, Qnil));
!       return startp;
!     }
  =

    while (1)
      {
***************
*** 6543,6548 ****
--- 6782,6790 ----
  	  if (bottom - pixpos < VERTICAL_CLIP (w, 0))
  	    start_elt--;
  =

+ 	  if (!NILP (container))
+ 	    FRAMEMETH (f, set_container_frame, (f, Qnil));
+ =

  	  if (start_elt < 0)
  	    {
  	      w->line_cache_validation_override--;
***************
*** 6576,6581 ****
--- 6818,6827 ----
  	  if (from >=3D BUF_ZV (b))
  	    {
  	      w->line_cache_validation_override--;
+ =

+ 	      if (!NILP (container))
+ 		FRAMEMETH (f, set_container_frame, (f, Qnil));
+ =

  	      return (BUF_ZV (b));
  	    }
  =

***************
*** 6616,6629 ****
    int cur_elt;
    Bufpos cur_pos;
    int pixheight =3D pixpos - WINDOW_TEXT_TOP (w);
! =

    validate_line_start_cache (w);
    w->line_cache_validation_override++;
  =

    cur_elt =3D point_in_line_start_cache (w, point, 0);
    /* #### See comment in update_line_start_cache about big minibuffers.=
 */
    if (cur_elt < 0)
!     return point;
    while (1)
      {
        cur_pos =3D Dynarr_atp (w->line_start_cache, cur_elt)->start;
--- 6862,6889 ----
    int cur_elt;
    Bufpos cur_pos;
    int pixheight =3D pixpos - WINDOW_TEXT_TOP (w);
!   struct frame *f =3D XFRAME (w->frame);
!   Lisp_Object container;
!   =

!   if (FRAME_GLYPH_P (f))
!     {
!       container =3D frame_glyph_set_likely_container (f);
!       if (UNBOUNDP (container))
! 	return point;
!     }
!   else container =3D Qnil;
!   =

    validate_line_start_cache (w);
    w->line_cache_validation_override++;
  =

    cur_elt =3D point_in_line_start_cache (w, point, 0);
    /* #### See comment in update_line_start_cache about big minibuffers.=
 */
    if (cur_elt < 0)
!     {
!       if (!NILP (container))
! 	FRAMEMETH (f, set_container_frame, (f, Qnil));
!       return point;
!     }
    while (1)
      {
        cur_pos =3D Dynarr_atp (w->line_start_cache, cur_elt)->start;
***************
*** 6635,6640 ****
--- 6895,6902 ----
        if (pixheight < 0)
  	{
  	  w->line_cache_validation_override--;
+ 	  if (!NILP (container))
+ 	    FRAMEMETH (f, set_container_frame, (f, Qnil));
  	  return cur_pos;
  	}
  =

***************
*** 6647,6652 ****
--- 6909,6916 ----
  	  if (cur_pos <=3D BUF_BEGV (b))
  	    {
  	      w->line_cache_validation_override--;
+ 	      if (!NILP (container))
+ 		FRAMEMETH (f, set_container_frame, (f, Qnil));
  	      return (BUF_BEGV (b));
  	    }
  =

***************
*** 6732,6737 ****
--- 6996,7002 ----
        search_point =3D Dynarr_atp (w->line_start_cache, cur_elt)->start=
;
  =

        retval =3D start_with_line_at_pixpos (w, search_point, pixpos);
+       =

        w->line_cache_validation_override--;
        return retval;
      }
***************
*** 7221,7226 ****
--- 7486,7492 ----
  			    Bufpos *closest, Charcount *modeline_closest,
  			    Lisp_Object *obj1, Lisp_Object *obj2)
  {
+   /*Lisp_Object container, junk;*/
    struct device *d;
    struct pixel_to_glyph_translation_cache *cache;
    Lisp_Object window;
***************
*** 7431,7437 ****
        *w =3D 0;
        UPDATE_CACHE_RETURN;
      }
! =

    dla =3D window_display_lines (*w, CURRENT_DISP);
  =

    for (*row =3D 0; *row < Dynarr_length (dla); (*row)++)
--- 7697,7718 ----
        *w =3D 0;
        UPDATE_CACHE_RETURN;
      }
!   /* #### Find out what actually causes this core dump!
!   if (FRAME_GLYPH_P (f))
!     {
!       container =3D frame_glyph_set_likely_container (f);
!       if (UNBOUNDP (container))
! 	return 0;
!     }
!   else container =3D Qnil;
!   =

!   XSETWINDOW (junk, *w);
!   redisplay_window (junk, 0);
!   =

!   if (!NILP (container))
!     FRAMEMETH (f, set_container_frame, (f, Qnil));
!   */
!   =

    dla =3D window_display_lines (*w, CURRENT_DISP);
  =

    for (*row =3D 0; *row < Dynarr_length (dla); (*row)++)
***************
*** 7714,7729 ****
      {
        struct device *d =3D XDEVICE (XCAR (devcons));
        Lisp_Object frmcons;
! =

        DEVICE_FRAME_LOOP (frmcons, d)
  	{
  	  struct frame *f =3D XFRAME (XCAR (frmcons));
! =

  	  if (FRAME_VISIBLE_P (f) && FRAME_HAS_MINIBUF_P (f))
  	    {
  	      Lisp_Object window =3D FRAME_MINIBUF_WINDOW (f);
  	      redisplay_window (window, 0);
  	      call_redisplay_end_triggers (XWINDOW (window), 0);
  	    }
  	}
  =

--- 7995,8024 ----
      {
        struct device *d =3D XDEVICE (XCAR (devcons));
        Lisp_Object frmcons;
!       =

        DEVICE_FRAME_LOOP (frmcons, d)
  	{
  	  struct frame *f =3D XFRAME (XCAR (frmcons));
! 	  =

  	  if (FRAME_VISIBLE_P (f) && FRAME_HAS_MINIBUF_P (f))
  	    {
  	      Lisp_Object window =3D FRAME_MINIBUF_WINDOW (f);
+ 	      Lisp_Object container;
+ 	      =

+ 	      if (FRAME_GLYPH_P (f))
+ 		{
+ 		  container =3D frame_glyph_set_likely_container (f);
+ 		  if (UNBOUNDP (container) ||
+ 		      !EQ (WINDOW_DEVICE (XWINDOW (window)), f->device))
+ 		    continue;
+ 		}
+ 	      else container =3D Qnil;
+ 	      =

  	      redisplay_window (window, 0);
  	      call_redisplay_end_triggers (XWINDOW (window), 0);
+ =

+ 	      if (!NILP (container))
+ 		FRAMEMETH (f, set_container_frame, (f, Qnil));
  	    }
  	}
  =

***************
*** 7765,7771 ****
      }
  =

    f->clear =3D 1;
!   redisplay_frame (f, 1);
  =

    return unbind_to (count, Qnil);
  }
--- 8060,8069 ----
      }
  =

    f->clear =3D 1;
!   if (FRAME_GLYPH_P (f))
!     redisplay_sub_frame (f, Qnil, 1);
!   else
!     redisplay_frame (f, 1);
  =

    return unbind_to (count, Qnil);
  }
***************
*** 7793,7799 ****
        disable_preemption++;
      }
  =

!   redisplay_frame (f, 1);
  =

    return unbind_to (count, Qnil);
  }
--- 8091,8100 ----
        disable_preemption++;
      }
  =

!   if (FRAME_GLYPH_P (f))
!     redisplay_sub_frame (f, Qnil, 1);
!   else
!     redisplay_frame (f, 1);
  =

    return unbind_to (count, Qnil);
  }
***************
*** 7823,7830 ****
      {
        XFRAME (XCAR (frmcons))->clear =3D 1;
      }
    redisplay_device (d);
! =

    return unbind_to (count, Qnil);
  }
  =

--- 8124,8132 ----
      {
        XFRAME (XCAR (frmcons))->clear =3D 1;
      }
+   check_sub_frame_changed =3D 1;
    redisplay_device (d);
!   =

    return unbind_to (count, Qnil);
  }
  =

***************
*** 7851,7856 ****
--- 8153,8159 ----
        disable_preemption++;
      }
  =

+   check_sub_frame_changed =3D 1;
    redisplay_device (d);
  =

    return unbind_to (count, Qnil);
***************
*** 7878,7884 ****
    (frame)
       Lisp_Object frame;
  {
!   redisplay_redraw_cursor (decode_frame (frame), 1);
    return Qnil;
  }
  =

--- 8181,8192 ----
    (frame)
       Lisp_Object frame;
  {
!   struct frame *f;
!   Drawable drw;
!   f =3D decode_frame (frame);
!   =

!   drw =3D FRAMEMETH (f, drawable, (f));
!   redisplay_redraw_cursor (drw, f, 1);
    return Qnil;
  }
  =

diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/redisplay.h xemacs-19.15-b2-made/src/redisplay.h
*** xemacs-19.15-b2/src/redisplay.h	Mon Sep 16 17:48:50 1996
--- xemacs-19.15-b2-made/src/redisplay.h	Mon Nov 11 23:26:27 1996
***************
*** 25,30 ****
--- 25,37 ----
  #ifndef _XEMACS_REDISPLAY_H_
  #define _XEMACS_REDISPLAY_H_
  =

+ #ifdef HAVE_X_WINDOWS
+ #include <X11/X.h>
+ #else
+ /* No X - Drawable can be anything for now, since it won't be used */
+ typedef unsigned int Drawable;
+ #endif
+ =

  /* Redisplay DASSERT types */
  #define DB_DISP_POS		1
  #define DB_DISP_TEXT_LAYOUT	2
***************
*** 480,485 ****
--- 487,494 ----
  				       Lisp_Object reloc,
  				       Bytecount offset, Bytecount len);
  void redisplay (void);
+ int redisplay_sub_frame (struct frame *f, Lisp_Object container_frame,
+ 			 int preemption_check);
  struct display_block *get_display_block_from_line (struct display_line =
*dl,
  						   enum display_type type);
  layout_bounds calculate_display_line_boundaries (struct window *w,
***************
*** 530,546 ****
  int get_next_display_block (layout_bounds bounds,
  			    display_block_dynarr *dba, int start_pos,
  			    int *next_start);
! void redisplay_clear_bottom_of_window (struct window *w,
  				       display_line_dynarr *ddla,
  				       int min_start, int max_end);
! void redisplay_update_line (struct window *w, int first_line,
! 			    int last_line, int update_values);
  void redisplay_output_window (struct window *w);
! int redisplay_move_cursor (struct window *w, Bufpos new_point,
! 			   int no_output_end);
! void redisplay_redraw_cursor (struct frame *f, int run_begin_end_meths)=
;
! void output_display_line (struct window *w, display_line_dynarr *cdla,
! 			  display_line_dynarr *ddla, int line,
! 			  int force_start, int force_end);
  =

  #endif /* _XEMACS_REDISPLAY_H_ */
--- 539,557 ----
  int get_next_display_block (layout_bounds bounds,
  			    display_block_dynarr *dba, int start_pos,
  			    int *next_start);
! void redisplay_clear_bottom_of_window (Drawable drawing_area, struct wi=
ndow *w,
  				       display_line_dynarr *ddla,
  				       int min_start, int max_end);
! void redisplay_update_line (Drawable drawing_area, struct window *w,
! 			    int first_line, int last_line, int update_values);
  void redisplay_output_window (struct window *w);
! int redisplay_move_cursor (Drawable drawing_area, struct window *w,
! 			   Bufpos new_point, int no_output_end);
! void redisplay_redraw_cursor (Drawable drawing_area, struct frame *f,
! 			      int run_end_begin_meths);
! void output_display_line (Drawable drawing_area, struct window *w,
! 			  display_line_dynarr *cdla,
! 			  display_line_dynarr *ddla, int line, int force_start,
! 			  int force_end);
  =

  #endif /* _XEMACS_REDISPLAY_H_ */
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/sound.c xemacs-19.15-b2-made/src/sound.c
*** xemacs-19.15-b2/src/sound.c	Sat Jun  1 20:13:04 1996
--- xemacs-19.15-b2-made/src/sound.c	Mon Nov 11 23:26:27 1996
***************
*** 37,42 ****
--- 37,43 ----
  #endif
  =

  #include "commands.h"
+ #include "frame.h"
  #include "device.h"
  #include "redisplay.h"
  #include "sysdep.h"
***************
*** 304,310 ****
      }
  #endif  /* HAVE_NATIVE_SOUND */
  =

!   DEVMETH (d, ring_bell, (d, vol, pit, dur));
    return Qnil;
  }
  =

--- 305,311 ----
      }
  #endif  /* HAVE_NATIVE_SOUND */
  =

!   DEVMETH (d, ring_bell, (XFRAME (DEVICE_SELECTED_FRAME (d)), vol, pit,=
 dur));
    return Qnil;
  }
  =

***************
*** 344,351 ****
    if (NILP (arg) && !NILP (Vexecuting_macro))
      /* Stop executing a keyboard macro. */
      error ("Keyboard macro terminated by a command ringing the bell");
!   else if (visible_bell && DEVMETH (d, flash, (d)))
!     ;
    else
      Fplay_sound (sound, Qnil, device);
  =

--- 345,353 ----
    if (NILP (arg) && !NILP (Vexecuting_macro))
      /* Stop executing a keyboard macro. */
      error ("Keyboard macro terminated by a command ringing the bell");
!   else if (visible_bell &&
! 	   DEVMETH (d, flash, (XFRAME (DEVICE_SELECTED_FRAME (d)))))
!       ;
    else
      Fplay_sound (sound, Qnil, device);
  =

diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/symsinit.h xemacs-19.15-b2-made/src/symsinit.h
*** xemacs-19.15-b2/src/symsinit.h	Wed May 15 21:20:26 1996
--- xemacs-19.15-b2-made/src/symsinit.h	Mon Nov 11 23:26:27 1996
***************
*** 80,89 ****
--- 80,91 ----
  void syms_of_floatfns (void);
  void syms_of_fns (void);
  void syms_of_font_lock (void);
+ void syms_of_frame_glyph (void);
  void syms_of_frame_x (void);
  void syms_of_frame (void);
  void syms_of_free_hook (void);
  void syms_of_general (void);
+ void syms_of_glyphs_glyph (void);
  void syms_of_glyphs_x (void);
  void syms_of_glyphs (void);
  void syms_of_gui_x (void);
***************
*** 100,105 ****
--- 102,108 ----
  void syms_of_minibuf (void);
  void syms_of_mocklisp (void);
  void syms_of_objects_tty (void);
+ void syms_of_objects_glyph (void);
  void syms_of_objects_x (void);
  void syms_of_objects (void);
  void syms_of_print (void);
***************
*** 142,147 ****
--- 145,156 ----
  void console_type_create_redisplay_x (void);
  void console_type_create_scrollbar_x (void);
  void console_type_create_toolbar_x (void);
+ void console_type_create_glyph (void);
+ void console_type_create_device_glyph (void);
+ void console_type_create_frame_glyph (void);
+ void console_type_create_glyphs_glyph (void);
+ void console_type_create_objects_glyph (void);
+ void console_type_create_redisplay_glyph (void);
  =

  /* Initialize the specifier types (dump-time only). */
  =

***************
*** 149,154 ****
--- 158,164 ----
  void specifier_type_create_image (void);
  void specifier_type_create_objects (void);
  void specifier_type_create_toolbar (void);
+ void specifier_type_create_frame (void);
  =

  /* Initialize the structure types (dump-time only). */
  =

***************
*** 160,165 ****
--- 170,176 ----
  =

  void image_instantiator_format_create (void);
  void image_instantiator_format_create_glyphs_x (void);
+ void image_instantiator_format_create_glyphs_glyph (void);
  =

  /* Initialize the lstream types (dump-time only). */
  =

***************
*** 208,216 ****
--- 219,229 ----
  void vars_of_filelock (void);
  void vars_of_floatfns (void);
  void vars_of_font_lock (void);
+ void vars_of_frame_glyph (void);
  void vars_of_frame_tty (void);
  void vars_of_frame_x (void);
  void vars_of_frame (void);
+ void vars_of_glyphs_glyph (void);
  void vars_of_glyphs_x (void);
  void vars_of_glyphs (void);
  void vars_of_gui_x (void);
***************
*** 267,272 ****
--- 280,286 ----
  void complex_vars_of_extents (void);
  void complex_vars_of_faces (void);
  void complex_vars_of_glyphs (void);
+ void complex_vars_of_glyphs_glyph (void);
  void complex_vars_of_glyphs_x (void);
  void complex_vars_of_alloc (void);
  void complex_vars_of_menubar (void);
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/sysdep.c xemacs-19.15-b2-made/src/sysdep.c
*** xemacs-19.15-b2/src/sysdep.c	Mon Sep 16 17:47:54 1996
--- xemacs-19.15-b2-made/src/sysdep.c	Mon Nov 11 23:26:27 1996
***************
*** 840,846 ****
  init_baud_rate (struct device *d)
  {
    struct console *con =3D XCONSOLE (DEVICE_CONSOLE (d));
!   if (DEVICE_WIN_P (d) || DEVICE_STREAM_P (d))
      {
        DEVICE_BAUD_RATE (d) =3D 38400;
        return;
--- 840,846 ----
  init_baud_rate (struct device *d)
  {
    struct console *con =3D XCONSOLE (DEVICE_CONSOLE (d));
!   if (DEVICE_WIN_P (d) || DEVICE_STREAM_P (d) || DEVICE_GLYPH_P (d))
      {
        DEVICE_BAUD_RATE (d) =3D 38400;
        return;
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/toolbar-x.c xemacs-19.15-b2-made/src/toolbar-x.c
*** xemacs-19.15-b2/src/toolbar-x.c	Sun Mar 31 19:19:39 1996
--- xemacs-19.15-b2-made/src/toolbar-x.c	Mon Nov 11 23:26:28 1996
***************
*** 65,71 ****
      }
  =

    /* Draw the outline. */
!   x_output_shadows (f, x, y, width, height, top_shadow_gc,
  		    bottom_shadow_gc, background_gc, shadow_thickness);
  =

    /* Blank the middle. */
--- 65,71 ----
      }
  =

    /* Draw the outline. */
!   x_output_shadows (x_win, f, x, y, width, height, top_shadow_gc,
  		    bottom_shadow_gc, background_gc, shadow_thickness);
  =

    /* Blank the middle. */
***************
*** 116,123 ****
    background_gc =3D FRAME_X_TOOLBAR_BLANK_BACKGROUND_GC (f);
  =

    /* Draw the outline. */
!   x_output_shadows (f, tb->x, tb->y, tb->width, tb->height, top_shadow_=
gc,
! 		    bottom_shadow_gc, background_gc, shadow_thickness);
  =

    /* Clear the pixmap area. */
    XFillRectangle (dpy, x_win, background_gc, tb->x + shadow_thickness,
--- 116,124 ----
    background_gc =3D FRAME_X_TOOLBAR_BLANK_BACKGROUND_GC (f);
  =

    /* Draw the outline. */
!   x_output_shadows (x_win, f, tb->x, tb->y, tb->width, tb->height,
! 		    top_shadow_gc, bottom_shadow_gc, background_gc,
! 		    shadow_thickness);
  =

    /* Clear the pixmap area. */
    XFillRectangle (dpy, x_win, background_gc, tb->x + shadow_thickness,
***************
*** 157,163 ****
  	      height =3D IMAGE_INSTANCE_PIXMAP_HEIGHT (p);
  	    }
  =

! 	  x_output_x_pixmap (f, XIMAGE_INSTANCE (instance), tb->x + x_offset,
  			     tb->y + y_offset, 0, 0, 0, 0, width, height,
  			     0, 0, 0, background_gc);
  	}
--- 158,165 ----
  	      height =3D IMAGE_INSTANCE_PIXMAP_HEIGHT (p);
  	    }
  =

! 	  x_output_x_pixmap (x_win, f, XIMAGE_INSTANCE (instance),
! 			     tb->x + x_offset,
  			     tb->y + y_offset, 0, 0, 0, 0, width, height,
  			     0, 0, 0, background_gc);
  	}
***************
*** 205,212 ****
  	      dl.clip =3D fm.ascent + fm.descent - height;
  	    }
  =

! 	  x_output_string (w, &dl, buf, tb->x + x_offset, 0, 0, width,
! 			   DEFAULT_INDEX, 0, 0, 0, 0);
  	  Dynarr_free (buf);
  	}
  =

--- 207,214 ----
  	      dl.clip =3D fm.ascent + fm.descent - height;
  	    }
  =

! 	  x_output_string (x_win, w, f, &dl, buf, tb->x + x_offset, 0, 0,
! 			   width, DEFAULT_INDEX, 0, 0, 0, 0);
  	  Dynarr_free (buf);
  	}
  =

***************
*** 424,432 ****
        Lisp_Object frame;
  =

        XSETFRAME (frame, f);
!       DEVMETH (d, clear_region, (frame,
! 				 DEFAULT_INDEX, FRAME_PIXWIDTH (f) - 1, y, 1,
! 				 bar_height));
      }
  =

    SET_TOOLBAR_WAS_VISIBLE_FLAG (f, pos, 1);
--- 426,434 ----
        Lisp_Object frame;
  =

        XSETFRAME (frame, f);
!       DEVMETH (d, clear_region, (XtWindow (FRAME_X_TEXT_WIDGET (f)), fr=
ame,
! 				 f, DEFAULT_INDEX, FRAME_PIXWIDTH (f) - 1, y,
! 				 1, bar_height));
      }
  =

    SET_TOOLBAR_WAS_VISIBLE_FLAG (f, pos, 1);
***************
*** 462,468 ****
   =

    SET_TOOLBAR_WAS_VISIBLE_FLAG (f, pos, 0);
  =

!   DEVMETH (d, clear_region, (frame, DEFAULT_INDEX, x, y, width, height)=
);
    XFlush (DEVICE_X_DISPLAY (d));
  }
  =

--- 464,471 ----
   =

    SET_TOOLBAR_WAS_VISIBLE_FLAG (f, pos, 0);
  =

!   DEVMETH (d, clear_region, (XtWindow (FRAME_X_TEXT_WIDGET (f)), frame,=
 f,
! 			     DEFAULT_INDEX, x, y, width, height));
    XFlush (DEVICE_X_DISPLAY (d));
  }
  =

diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/toolbar.c xemacs-19.15-b2-made/src/toolbar.c
*** xemacs-19.15-b2/src/toolbar.c	Sun Sep  8 19:47:44 1996
--- xemacs-19.15-b2-made/src/toolbar.c	Mon Nov 11 23:26:28 1996
***************
*** 1686,1691 ****
--- 1686,1692 ----
  =

    /* #### this is ugly. */
    elt =3D list1 (Fcons (list1 (Qtty), Qzero));
+   elt =3D Fcons (Fcons (list1 (Qglyph), Qzero), elt);
  #ifdef HAVE_X_WINDOWS
    elt =3D Fcons (Fcons (list1 (Qx), make_int (DEFAULT_TOOLBAR_HEIGHT)),=
 elt);
  #endif
***************
*** 1694,1699 ****
--- 1695,1701 ----
  #endif
    set_specifier_fallback (Vdefault_toolbar_height, elt);
    elt =3D list1 (Fcons (list1 (Qtty), Qzero));
+   elt =3D Fcons (Fcons (list1 (Qglyph), Qzero), elt);
  #ifdef HAVE_X_WINDOWS
    elt =3D Fcons (Fcons (list1 (Qx), make_int (DEFAULT_TOOLBAR_WIDTH)), =
elt);
  #endif
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/window.c xemacs-19.15-b2-made/src/window.c
*** xemacs-19.15-b2/src/window.c	Sun Sep  8 19:45:45 1996
--- xemacs-19.15-b2-made/src/window.c	Tue Nov 12 09:03:28 1996
***************
*** 30,35 ****
--- 30,36 ----
  #include "lisp.h"
  =

  #include "buffer.h"
+ #include "console-glyph.h"
  #include "faces.h"
  #include "frame.h"
  #include "objects.h"
***************
*** 70,75 ****
--- 71,79 ----
  static void change_window_height (struct window *w, int delta, int widt=
hflag);
  =

  =

+ /* from redisplay.c */
+ Lisp_Object frame_glyph_set_likely_container (struct frame *f);
+ =

  #ifdef ENERGIZE
  extern void energize_buffer_shown_hook ();
  extern void energize_buffer_hidden_hook ();
***************
*** 85,90 ****
--- 89,97 ----
  /* Whether a modeline should be displayed. */
  Lisp_Object Vhas_modeline_p;
  =

+ /* Whether a vertical divider should be displayed if there is no modeli=
ne */
+ Lisp_Object Vhas_vertical_divider_p;
+ =

  /* Scroll if point lands on the bottom line and that line is partially
     clipped. */
  int scroll_on_clipped_lines;
***************
*** 174,179 ****
--- 181,187 ----
    /* Cached specifiers: */
    ((markobj) (window->display_table));
    ((markobj) (window->has_modeline_p));
+   ((markobj) (window->has_vertical_divider_p));
    ((markobj) (window->modeline_shadow_thickness));
  #ifdef HAVE_SCROLLBARS
    ((markobj) (window->scrollbar_width));
***************
*** 323,328 ****
--- 331,337 ----
    /* cached specifier values: will get set properly later */
    p->display_table =3D Qnil;
    p->has_modeline_p =3D Qnil;
+   p->has_vertical_divider_p =3D Qnil;
    p->modeline_shadow_thickness =3D Qnil;
  #ifdef HAVE_SCROLLBARS
    p->scrollbar_width =3D Qnil;
***************
*** 353,358 ****
--- 362,374 ----
    p->windows_changed =3D 1;
    p->shadow_thickness_changed =3D 1;
  =

+   /* #### these should be protected from garbage collection */
+   p->min_width =3D make_int (0);
+   p->min_height =3D make_int (0);
+   p->malleability_width =3D 100;
+   p->malleability_height =3D 100;
+   p->factors_needed =3D 1;
+   =

    return (val);
  }
  #undef INIT_DISP_VARIABLE
***************
*** 857,863 ****
  	modeline_height =3D 0;
        else
  	{
! 	  modeline_height =3D FRAMEMETH (f, divider_height, ());
  =

  	  if (!EQ (Qzero, w->modeline_shadow_thickness) && FRAME_WIN_P (f))
  	    modeline_height +=3D (2 * MODELINE_SHADOW_THICKNESS (w));
--- 873,889 ----
  	modeline_height =3D 0;
        else
  	{
! 	  Lisp_Object container;
! 	  if (FRAME_GLYPH_P (f))
! 	    {
! 	      container =3D frame_glyph_set_likely_container (f);
! 	      if (UNBOUNDP (container))
! 		return 0;
! 	    }
! 	  else container =3D Qnil;
! 	  modeline_height =3D FRAMEMETH (f, divider_height, (f));
! 	  if (!NILP (container))
! 	    FRAMEMETH (f, set_container_frame, (f, Qnil));
  =

  	  if (!EQ (Qzero, w->modeline_shadow_thickness) && FRAME_WIN_P (f))
  	    modeline_height +=3D (2 * MODELINE_SHADOW_THICKNESS (w));
***************
*** 1064,1070 ****
        if (scrollbar_width)
  	return scrollbar_width;
        else if (window_needs_vertical_divider (w))
! 	return FRAMEMETH (f, divider_width, ());
        else
  	return 0;
      }
--- 1090,1111 ----
        if (scrollbar_width)
  	return scrollbar_width;
        else if (window_needs_vertical_divider (w))
! 	{
! 	  Lisp_Object container;
! 	  int width;
! 	  =

! 	  if (FRAME_GLYPH_P (f))
! 	    {
! 	      container =3D frame_glyph_set_likely_container (f);
! 	      if (UNBOUNDP (container))
! 		return 0;
! 	    }
! 	  else container =3D Qnil;
! 	  width =3D FRAMEMETH (f, divider_width, (f));
! 	  if (!NILP (container))
! 	    FRAMEMETH (f, set_container_frame, (f, Qnil));
! 	  return width;
! 	}
        else
  	return 0;
      }
***************
*** 1076,1082 ****
        if (!EQ (Qzero, w->modeline_shadow_thickness))
  	return 0;
        else if (window_needs_vertical_divider (w))
! 	return FRAMEMETH (f, divider_width, ());
        else
  	return 0;
      }
--- 1117,1139 ----
        if (!EQ (Qzero, w->modeline_shadow_thickness))
  	return 0;
        else if (window_needs_vertical_divider (w))
! 	{
! 	  Lisp_Object container;
! 	  int width;
! 	  =

! 	  if (FRAME_GLYPH_P (f))
! 	    {
! 	      container =3D frame_glyph_set_likely_container (f);
! 	      if (UNBOUNDP (container))
! 		return 0;
! 	    }
! 	  else container =3D Qnil;
! 	  width =3D FRAMEMETH (f, divider_width, (f));
! 	  =

! 	  if (!NILP (container))
! 	    FRAMEMETH (f, set_container_frame, (f, Qnil));
! 	  return width;
! 	}
        else
  	return 0;
      }
***************
*** 1639,1644 ****
--- 1696,1879 ----
    return w->dedicated;
  }
  =

+ DEFUN ("set-window-height-min", Fset_window_height_min,
+        Sset_window_height_min, 2, 2, 0 /*
+ Set the minimum desired height for WINDOW to MIN.  This is not a hard l=
imit.
+ It also does nothing to prevent the user from explicitly resizing the w=
indow to
+ a height smaller than this.  It does constrain the Emacs geometry manag=
er when
+ the frame is resized.  The Emacs geometry manager will attempt to keep =
the
+ window at least this tall, but if the frame is too small, it can violat=
e this
+ minimum in order to continue displaying all windows.  window-min-height=
 still
+ determines the absolute minimum height that a window can have.
+ =

+ MIN can be either an integer or a symbol.  If it is a symbol, it can ei=
ther be
+ a variable or a function.  If it is a variable, then its value is taken=
 and
+ used as the minimum.  If it is a function, then the function is a calle=
d with
+ a single argument, the window, and its return value is the minimum.  In=
 either
+ case, the symbol is evaluated whenever the frame is resized.
+ */ )
+   (window, min)
+   Lisp_Object window, min;
+ {
+   struct window *w =3D decode_window (window);
+   w->min_height =3D min;
+   return min;
+ }
+ =

+ DEFUN ("set-window-width-min", Fset_window_width_min,
+        Sset_window_width_min, 2, 2, 0 /*
+ Set the minimum desired width for WINDOW to MIN.  This is not a hard li=
mit.
+ It also does nothing to prevent the user from explicitly resizing the w=
indow to
+ a width smaller than this.  It does constrain the Emacs geometry manage=
r when
+ the frame is resized.  The Emacs geometry manager will attempt to keep =
the
+ window at least this wide, but if the frame is too small, it can violat=
e this
+ minimum in order to continue displaying all windows.  window-min-width =
still
+ determines the absolute minimum width that a window can have.
+ =

+ MIN can be either an integer or a symbol.  If it is a symbol, it can ei=
ther be
+ a variable or a function.  If it is a variable, then its value is taken=
 and
+ used as the minimum.  If it is a function, then the function is a calle=
d with
+ a single argument, the window, and its return value is the minimum.  In=
 either
+ case, the symbol is evaluated whenever the frame is resized.
+ */ )
+   (window, min)
+   Lisp_Object window, min;
+ {
+   struct window *w =3D decode_window (window);
+   w->min_width =3D min;
+   return min;
+ }
+ =

+ DEFUN ("set-window-width-malleability", Fset_window_width_malleability,=

+        Sset_window_width_malleability, 2, 2, 0 /*
+ Set the amount by which frame resizes are absorbed by WINDOW to MALLEAB=
ILITY.
+ The malleability factor defaults to 100 for all windows.  A larger valu=
e means
+ that more of a frame resize will be absorbed by this window.  A smaller=
 value
+ means that less of a frame resize will be absorbed by this window.  A v=
alue of
+ 0 means that, if possible, the window won't be resized at all in respon=
se to
+ a frame resize.  Malleability is a relative measure; the absolute value=
 of the
+ malleability doesn't matter except in relation to the malleability fact=
ors of
+ the other windows in the frame.
+ */ )
+   (window, malleability)
+   Lisp_Object window, malleability;
+ {
+   struct window *w =3D decode_window (window);
+   int xmalleability =3D XINT (malleability);
+   if (xmalleability < 0)
+     w->malleability_width =3D 0;
+   else
+     w->malleability_width =3D xmalleability;
+   return make_int (w->malleability_width);
+ }
+ =

+ DEFUN ("set-window-height-malleability", Fset_window_height_malleabilit=
y,
+        Sset_window_height_malleability, 2, 2, 0 /*
+ Set the amount by which frame resizes are absorbed by WINDOW to MALLEAB=
ILITY.
+ The malleability factor defaults to 100 for all windows.  A larger valu=
e means
+ that more of a frame resize will be absorbed by this window.  A smaller=
 value
+ means that less of a frame resize will be absorbed by this window.  A v=
alue of
+ 0 means that, if possible, the window won't be resized at all in respon=
se to
+ a frame resize.  Malleability is a relative measure; the absolute value=
 of the
+ malleability doesn't matter except in relation to the malleability fact=
ors of
+ the other windows in the frame.
+ */ )
+   (window, malleability)
+   Lisp_Object window, malleability;
+ {
+   struct window *w =3D decode_window (window);
+   int xmalleability =3D XINT (malleability);
+   if (xmalleability < 0)
+     w->malleability_height =3D 0;
+   else
+     w->malleability_height =3D xmalleability;
+   return make_int (w->malleability_height);
+ }
+ =

+ DEFUN ("window-height-min", Fwindow_height_min,
+        Swindow_height_min, 1, 1, 0 /*
+ Return the minimum desired height for WINDOW as set by set-window-heigh=
t-min.
+ */ )
+   (window)
+   Lisp_Object window;
+ {
+   struct window *w =3D decode_window (window);
+   return w->min_height;
+ }
+ =

+ DEFUN ("window-width-min", Fwindow_width_min,
+        Swindow_width_min, 1, 1, 0 /*
+ Return the minimum desired width for WINDOW as set by set-window-width-=
min.
+ */ )
+   (window)
+   Lisp_Object window;
+ {
+   struct window *w =3D decode_window (window);
+   return w->min_width;
+ }
+ =

+ DEFUN ("frame-window-width-min", Fframe_window_width_min,
+        Sframe_window_width_min, 1, 2, 0 /*
+ Return width of FRAME such that all windows satisfy their width constra=
int.
+ With optional arg EXACTP non-nil, do not count window-min-width as a co=
nstraint.
+ Normally both window-min-width and the per window value set by
+ set-window-width-min are counted.  The return value of this function ca=
n be
+ used as a value to the frame property min-width to ensure that the fram=
e will
+ always be large enough to hold its windows.
+ */ )
+   (frame, exactp)
+   Lisp_Object frame, exactp;
+ {
+   struct frame *f =3D XFRAME (frame);
+   Lisp_Object window =3D FRAME_ROOT_WINDOW (f);
+   struct window *w =3D XWINDOW (window);
+   =

+   compute_window_size_factors (window, NILP (exactp) ? 1 : 0);
+   return make_int (w->minw);
+ }
+ =

+ DEFUN ("frame-window-height-min", Fframe_window_height_min,
+        Sframe_window_height_min, 1, 2, 0 /*
+ Return height of FRAME such that all windows satisfy their height const=
raint.
+ With optional arg EXACTP non-nil, do not count window-min-height as a
+ onstraint.  Normally both window-min-height and the per window value se=
t by
+ set-window-height-min are counted.  The return value of this function c=
an be
+ used as a value to the frame property min-height to ensure that the fra=
me will
+ always be large enough to hold its windows.
+ */ )
+   (frame, exactp)
+   Lisp_Object frame, exactp;
+ {
+   struct frame *f =3D XFRAME (frame);
+   Lisp_Object window =3D FRAME_ROOT_WINDOW (f);
+   struct window *w =3D XWINDOW (window);
+   =

+   compute_window_size_factors (window, NILP (exactp) ? 1 : 0);
+   return make_int (w->minh);
+ }
+ =

+ DEFUN ("window-width-malleability", Fwindow_width_malleability,
+        Swindow_width_malleability, 1, 1, 0 /*
+ Return the malleability of WINDOW as set by set-window-width-malleabili=
ty.
+ */ )
+   (window)
+   Lisp_Object window;
+ {
+   struct window *w =3D decode_window (window);
+   return make_int (w->malleability_width);
+ }
+ =

+ DEFUN ("window-height-malleability", Fwindow_height_malleability,
+        Swindow_height_malleability, 1, 1, 0 /*
+ Return the malleability of WINDOW as set by set-window-height-malleabil=
ity.
+ */ )
+   (window)
+   Lisp_Object window;
+ {
+   struct window *w =3D decode_window (window);
+   return make_int (w->malleability_height);
+ }
+ =

  /* FSFmacs has window-display-table here.  We have display table as a
     specifier. */
  =

***************
*** 2932,2938 ****
  /* The smallest acceptable dimensions for a window.  Anything smaller
     might crash Emacs.  */
  #define MIN_SAFE_WINDOW_WIDTH  (2)
! #define MIN_SAFE_WINDOW_HEIGHT (2)
  =

  /* Make sure that window_min_height and window_min_width are
     not too small; if they are, set them to safe minima.  */
--- 3167,3173 ----
  /* The smallest acceptable dimensions for a window.  Anything smaller
     might crash Emacs.  */
  #define MIN_SAFE_WINDOW_WIDTH  (2)
! #define MIN_SAFE_WINDOW_HEIGHT (1)
  =

  /* Make sure that window_min_height and window_min_width are
     not too small; if they are, set them to safe minima.  */
***************
*** 2947,2970 ****
      window_min_height =3D MIN_SAFE_WINDOW_HEIGHT;
  }
  =

  /* If *ROWS or *COLS are too small a size for FRAME, set them to the
     minimum allowable size.  */
  void
! check_frame_size (struct frame *frame, int *rows, int *cols)
  {
    /* For height, we have to see whether the frame has a minibuffer, and=

       whether it wants a modeline.  */
!   int min_height =3D
!     (FRAME_MINIBUF_ONLY_P (frame) ? MIN_SAFE_WINDOW_HEIGHT - 1
!      : (! FRAME_HAS_MINIBUF_P (frame)) ? MIN_SAFE_WINDOW_HEIGHT
!      : 2 * MIN_SAFE_WINDOW_HEIGHT - 1);
  =

    if (*rows < min_height)
      *rows =3D min_height;
    if (*cols  < MIN_SAFE_WINDOW_WIDTH)
      *cols =3D MIN_SAFE_WINDOW_WIDTH;
  }
  =

  /* Normally the window is deleted if it gets too small.
     nodelete nonzero means do not do this.
     (The caller should check later and do so if appropriate)  */
--- 3182,3789 ----
      window_min_height =3D MIN_SAFE_WINDOW_HEIGHT;
  }
  =

+ static int
+ compute_absolute_window_min_height (Lisp_Object window)
+ {
+   struct window *w =3D XWINDOW (window);
+   Lisp_Object child;
+   Lisp_Object first_child;
+   int height, w_height;
+   =

+   first_child =3D w->vchild;
+   if (NILP (first_child))
+     first_child =3D w->hchild;
+   =

+   child =3D first_child;
+ =

+   if (NILP (child))
+     {
+       int defheight, defwidth;
+ =

+       default_face_height_and_width (window, &defheight, &defwidth);
+ =

+       return MIN_SAFE_WINDOW_HEIGHT +
+ 	(WINDOW_HAS_MODELINE_P (w) ? 1 : 0) +
+ 	(window_scrollbar_height (w) / defheight);
+     }
+ =

+   height =3D MIN_SAFE_WINDOW_HEIGHT;
+   while (!NILP (child))
+     {
+       w_height =3D compute_absolute_window_min_height (child);
+       if (w_height > height) height =3D w_height;
+       child =3D XWINDOW (child)->next;
+     }
+   return height;
+ }
+ =

+ static int
+ compute_window_min_height (struct window *w)
+ {
+   int absolute_min;
+   Lisp_Object window;
+ =

+   XSETWINDOW (window, w);
+   absolute_min =3D compute_absolute_window_min_height (window);
+   =

+   return ((window_min_height > absolute_min)
+ 	  ? window_min_height
+ 	  : absolute_min);
+ }
+ =

  /* If *ROWS or *COLS are too small a size for FRAME, set them to the
     minimum allowable size.  */
  void
! check_frame_size (struct frame *f, int *rows, int *cols)
  {
    /* For height, we have to see whether the frame has a minibuffer, and=

       whether it wants a modeline.  */
!   int min_height;
  =

+   if (FRAME_MINIBUF_ONLY_P (f))
+     min_height =3D MIN_SAFE_WINDOW_HEIGHT - 1;
+   else
+     {
+       min_height =3D
+ 	compute_absolute_window_min_height (f->root_window);
+       if (FRAME_HAS_MINIBUF_P (f))
+ 	min_height +=3D MIN_SAFE_WINDOW_HEIGHT - 1;
+     }
+   =

    if (*rows < min_height)
      *rows =3D min_height;
    if (*cols  < MIN_SAFE_WINDOW_WIDTH)
      *cols =3D MIN_SAFE_WINDOW_WIDTH;
  }
  =

+ static int
+ compute_window_size_minimum (Lisp_Object window, Lisp_Object min)
+ {
+   struct window *w =3D XWINDOW (window);
+   =

+   /* rather than signal an error, which could be bad here,
+      we'll just set the minimum to 0 if something is wrong.
+      Of course, this is kind of silly, since we don't do anything to
+      catch errors while evaluating the function call. */
+   =

+   /* should this also check for FLOATP??? */
+   =

+   if (INTP (min))
+     return XINT (min);
+   else if (SYMBOLP (min))
+     {
+       /* inhibit GC here */
+       int old_gc_currently_forbidden =3D gc_currently_forbidden;
+       gc_currently_forbidden =3D 1;
+ 	  =

+       if (Ffboundp (min))
+ 	min =3D Ffuncall (1, &window);
+       else
+ 	min =3D symbol_value_in_buffer (min, w->buffer);
+       =

+       gc_currently_forbidden =3D old_gc_currently_forbidden;
+       =

+       if (INTP (min))
+ 	return XINT (min);
+     }
+   return 0;
+ }
+ =

+ /* recursively compute all window size factors for window w */
+ void
+ compute_window_size_factors (Lisp_Object window, int adjustp)
+ {
+   struct window *w =3D XWINDOW (window);
+   struct window *c;
+   Lisp_Object child;
+   int dir =3D 0;
+   int minw,minh;
+   unsigned long int malw,malh;
+   unsigned long int weight =3D 0;
+   int first =3D 1;
+ =

+ #if 0
+   {
+     char buf[80];
+     sprintf (buf, "WINDOW %X\n", w);
+     write_c_string (buf, Qexternal_debugging_output);
+   }
+ #endif
+   =

+   child =3D w->hchild;
+   if (NILP (child))
+     {
+       child =3D w->vchild;
+       dir =3D 1;
+     }
+   if (NILP (child))
+     {
+       /* leaf, compute values directly */
+       =

+       w->minw =3D compute_window_size_minimum (window, w->min_width);
+       w->minh =3D compute_window_size_minimum (window, w->min_height);
+ =

+       if (adjustp)
+ 	{
+ 	  int minh =3D compute_window_min_height (w);
+ 	  if (w->minw < window_min_width) w->minw =3D window_min_width;
+ 	  if (w->minh < minh) w->minh =3D minh;
+ 	}
+     }
+   else
+     {
+       minw =3D 0;
+       minh =3D 0;
+       malw =3D 0;
+       malh =3D 0;
+   =

+       while (!NILP (child))
+ 	{
+ 	  c =3D XWINDOW (child);
+ 	  =

+ 	  compute_window_size_factors(child, adjustp);
+ 	  =

+ 	  if (dir)
+ 	    {
+ 	      minh =3D minh + c->minh;
+ 	      if (first || c->minw > minw)
+ 		minw =3D c->minw;
+ 	      =

+ 	      weight =3D weight + c->pixel_width;
+ 	      malh =3D malh + c->pixel_width * c->malleability_height;
+ 	      if (first || c->malleability_width < malw)
+ 		malw =3D c->malleability_width;
+ 	    }
+ 	  else
+ 	    {
+ 	      /* vertically split windows */
+ 	      if (first || c->minh > minh)
+ 		minh =3D c->minh;
+ 	      minw =3D minw + c->minw;
+ 	      =

+ 	      if (first || c->malleability_height < malh)
+ 		malh =3D c->malleability_height;
+ 	      weight =3D weight + c->pixel_height;
+ 	      malw =3D malw + c->pixel_height * c->malleability_width;
+ 	    }
+ 	  =

+ 	  first =3D 0;
+ 	  child =3D c->next;
+ 	}
+       w->minh =3D minh;
+       w->minw =3D minw;
+       if (dir)
+ 	malh =3D malh / weight;
+       else
+ 	malw =3D malw / weight;
+       =

+       w->malleability_width =3D malw;
+       w->malleability_height =3D malh;
+     }
+ #if 0
+   {
+     char buf[80];
+     sprintf (buf, "       minimum width =3D %d\n", w->minw);
+     write_c_string (buf, Qexternal_debugging_output);
+ 	=

+     sprintf (buf, "       minimum height =3D %d\n", w->minh);
+     write_c_string (buf, Qexternal_debugging_output);
+     =

+     sprintf (buf, "       malleability width =3D %d\n", w->malleability=
_width);
+     write_c_string (buf, Qexternal_debugging_output);
+ 	=

+     sprintf (buf, "       malleability height =3D %d\n", w->malleabilit=
y_height);
+     write_c_string (buf, Qexternal_debugging_output);
+   }
+ #endif
+   w->factors_needed =3D 0;
+ }
+ =

+ /* Compute the pixel size of each child window in window from the windo=
w
+    specific minimum sizes and the malleability factors */
+ static void
+ compute_window_pixsize (Lisp_Object window, int new_pixsize, int old_pi=
xsize,
+ 			int set_height, int line_size)
+ {
+   struct window *w =3D XWINDOW (window);
+   struct window *c;
+   Lisp_Object child;
+   Lisp_Object first_child;
+   long int weight =3D 0;
+   int cursize, minsize;
+   int remaining_size;
+   int needed =3D 0;
+   int size, trial, pixels;
+   int tries =3D 0;
+   int time_to_punt =3D 0;
+   =

+   /* This function is only called if major_kid in
+      set_window_pixsize is non-nil. */
+   =

+   if (w->factors_needed)
+     {
+       compute_window_size_factors (window, 1);
+     }
+   =

+   if (set_height)
+     first_child =3D w->vchild;
+   else
+     first_child =3D w->hchild;
+   child =3D first_child;
+ =

+   assert (!NILP (child));
+   =

+   size =3D pixels =3D new_pixsize - old_pixsize;
+ =

+ #if 0
+   {
+     char buf[80];
+     sprintf (buf, "WINDOW %X\n", w);
+     write_c_string (buf, Qexternal_debugging_output);
+     =

+     sprintf (buf, "  NEXT %X\n", w->next);
+     write_c_string (buf, Qexternal_debugging_output);
+ =

+     if (NILP (w->hchild))
+       sprintf (buf, "  HCHILD (nil)\n");
+     else
+       sprintf (buf, "  HCHILD %X\n", w->hchild);
+     write_c_string (buf, Qexternal_debugging_output);
+     =

+     if (NILP (w->vchild))
+       sprintf (buf, "  VCHILD (nil)\n");
+     else
+       sprintf (buf, "  VCHILD %X\n", w->vchild);
+     write_c_string (buf, Qexternal_debugging_output);
+     =

+     sprintf (buf, "COMPUTING: change =3D %d\n",size);
+     write_c_string (buf, Qexternal_debugging_output);
+     =

+     sprintf (buf, "           new_pixsize =3D %d\n",new_pixsize);
+     write_c_string (buf, Qexternal_debugging_output);
+     =

+     sprintf (buf, "           set_height =3D %d\n",set_height);
+     write_c_string (buf, Qexternal_debugging_output);
+     =

+     sprintf (buf, "           line_size =3D %d\n",line_size);
+     write_c_string (buf, Qexternal_debugging_output);
+   }
+ #endif
+ =

+   while (!NILP (child))
+     {
+       weight =3D 0;
+       if (set_height)
+ 	while (!NILP (child))
+ 	  {
+ 	    c =3D XWINDOW (child);
+ 	    weight =3D weight + c->malleability_height;
+ 	    c->malh =3D c->malleability_height;
+ 	    needed =3D needed + c->minh;
+ 	    child =3D c->next;
+ 	  }
+       else
+ 	while (!NILP (child))
+ 	  {
+ 	    c =3D XWINDOW (child);
+ 	    weight =3D weight + c->malleability_width;
+ 	    c->malw =3D c->malleability_width;
+ 	    needed =3D needed + c->minw;
+ 	    child =3D c->next;
+ 	  }
+ =

+       if (weight =3D=3D 0)
+ 	{
+ 	  child =3D first_child;
+ 	  while (!NILP (child))
+ 	    {
+ 	      c =3D XWINDOW (child);
+ 	      c->malw =3D 1;
+ 	      c->malh =3D 1;
+ 	      weight =3D weight + 1;
+ 	      child =3D c->next;
+ 	    }
+ 	}
+   =

+       needed =3D needed * line_size;
+ =

+       if (new_pixsize < needed)
+ 	{
+ 	  /* punt */
+ 	  if (time_to_punt)
+ 	    goto cwp_punt;
+ 	  =

+ 	  /* recompute minimum sizes without adjusting for
+ 	     window_min_{height,width} variables */
+ 	  time_to_punt =3D 1;
+ 	  compute_window_size_factors (window, 0);
+ 	  needed =3D 0;
+ 	  child =3D first_child;
+ 	}
+     }
+   while (tries<2)
+     {
+ #if 0
+       {
+ 	char buf[80];
+ 	sprintf (buf, "           needed =3D %d\n",needed);
+ 	write_c_string (buf, Qexternal_debugging_output);
+ 	=

+ 	sprintf (buf, "           weight =3D %u\n",weight);
+ 	write_c_string (buf, Qexternal_debugging_output);
+       }
+ #endif
+       =

+       child =3D first_child;
+       remaining_size  =3D new_pixsize;
+       =

+       while (!NILP (child))
+ 	{
+ 	  c =3D XWINDOW (child);
+ 	  =

+ 	  if (set_height)
+ 	    {
+ 	      cursize =3D c->pixel_height;
+ 	      minsize =3D c->minh * line_size;
+ 	      =

+ 	      if (!NILP (c->next))
+ 		{
+ 		  trial =3D (pixels * c->malh + (weight >> 1)) / weight;
+ 		  trial =3D (trial / line_size) * line_size;
+ 		}
+ 	      else
+ 		trial =3D size;
+ 	    }
+ 	  else
+ 	    {
+ 	      cursize =3D c->pixel_width;
+ 	      minsize =3D c->minw * line_size;
+ 	      =

+ 	      if (!NILP (c->next))
+ 		{
+ 		  trial =3D (pixels * c->malw + (weight >> 1)) / weight;
+ 		  trial =3D (trial / line_size) * line_size;
+ 		}
+ 	      else
+ 		trial =3D size;
+ 	    }
+ #if 0
+ 	  {
+ 	    char buf[80];
+ 	    sprintf (buf, "           CHILD: %X\n",c);
+ 	    write_c_string (buf, Qexternal_debugging_output);
+ 	    =

+ 	    sprintf (buf, "                  cursize =3D %d\n",cursize);
+ 	    write_c_string (buf, Qexternal_debugging_output);
+ 	    =

+ 	    sprintf (buf, "                  minsize =3D %d\n",minsize);
+ 	    write_c_string (buf, Qexternal_debugging_output);
+ 	    =

+ 	    sprintf (buf, "                  remaining_size =3D %d\n",remainin=
g_size);
+ 	    write_c_string (buf, Qexternal_debugging_output);
+ 	    =

+ 	    sprintf (buf, "                  trial =3D %d\n",trial);
+ 	    write_c_string (buf, Qexternal_debugging_output);
+ 	  }
+ #endif
+   =

+ 	  if (trial + cursize < minsize)
+ 	    {
+ 	      if (remaining_size < minsize)
+ 		break;
+ 	      trial =3D minsize - cursize;
+ 	      if (!NILP (c->next))
+ 		{
+ 		  trial =3D (trial / line_size) * line_size;
+ 		  if (trial + cursize < minsize) trial =3D trial + 1;
+ 		  if (trial + cursize > remaining_size) break;
+ 		}
+ 	    }
+ =

+ #if 0
+ 	  {
+ 	    char buf[80];
+ 	    sprintf (buf, "                  trial =3D %d\n",trial);
+ 	    write_c_string (buf, Qexternal_debugging_output);
+ 	    =

+ 	    sprintf (buf, "                  new size =3D %d\n",trial + cursiz=
e);
+ 	    write_c_string (buf, Qexternal_debugging_output);
+ 	    =

+ 	    sprintf (buf, "                  remaining =3D %d\n",size - trial)=
;
+ 	    write_c_string (buf, Qexternal_debugging_output);
+ 	  }
+ #endif
+ 	  =

+ 	  c->new_pixsize =3D trial + cursize;
+ 	  size =3D size - trial;
+ 	  remaining_size =3D remaining_size - c->new_pixsize;
+ 	  =

+ 	  child =3D c->next;
+ 	}
+   =

+       if (NILP (child))
+ 	break;
+       else
+ 	{
+ #if 0
+ 	  {
+ 	    char buf[80];
+ 	    sprintf (buf, "FAILED: tries =3D %d\n",tries);
+ 	    write_c_string (buf, Qexternal_debugging_output);
+ 	  }
+ #endif
+ 	  =

+ 	  /* resize failed */
+ 	  if (tries)
+ 	    {
+ 	      struct window *mal_child;
+ 	      int mal;
+ 	      int old_pixels;
+ 	      =

+ 	      /* second re-try: set most malleable to minimum size
+ 		 until we have enough space for the remaining windows.
+ 		 This should never fail. */
+ 	      while (1)
+ 		{
+ 		  child =3D first_child;
+ 		  mal_child =3D NULL;
+ 		  mal =3D 0;
+ 		  while (!NILP (child))
+ 		    {
+ 		      c =3D XWINDOW (child);
+ 		      =

+ 		      if (set_height)
+ 			{
+ 			  if (c->malh >=3D mal)
+ 			    {
+ 			      mal_child =3D c;
+ 			      mal =3D c->malh;
+ 			    }
+ 			}
+ 		      else
+ 			{
+ 			  if (c->malw >=3D mal)
+ 			    {
+ 			      mal_child =3D c;
+ 			      mal =3D c->malw;
+ 			    }
+ 			}
+ 		      child =3D c->next;
+ 		    }
+ 		  if (!mal_child)
+ 		    goto cwp_punt;
+ 		  =

+ 		  old_pixels =3D pixels;
+ 		  =

+ 		  if (set_height)
+ 		    {
+ 		      mal_child->malh =3D -1;
+ 		      mal_child->new_pixsize =3D mal_child->minh * line_size;
+ 		      pixels =3D pixels + mal_child->pixel_height -
+ 			mal_child->new_pixsize;
+ 		    }
+ 		  else
+ 		    {
+ 		      mal_child->malw =3D -1;
+ 		      mal_child->new_pixsize =3D mal_child->minw * line_size;
+ 		      pixels =3D pixels + mal_child->pixel_width -
+ 			mal_child->new_pixsize;
+ 		    }
+ 		  =

+ 		  if (pixels * old_pixels <=3D 0)
+ 		    {
+ 		      /* done: rearrange other windows as normal */
+ 		      child =3D first_child;
+ 		      while (!NILP (child))
+ 			{
+ 			  c =3D XWINDOW (child);
+ 			  if (c->malw < 0)
+ 			    c->malw =3D 0;
+ 			  if (c->malh < 0)
+ 			    c->malh =3D 0;
+ 			  child =3D c->next;
+ 			}
+ 		      --tries;
+ 		    }
+ 		}
+ 	    }
+ 	  else
+ 	    {
+ 	      /* first re-try: re-weight by minimum size */
+ 	      weight =3D 0;
+ 	      child =3D first_child;
+ 	      while (!NILP (child))
+ 		{
+ 		  c =3D XWINDOW (child);
+ 		  =

+ 		  if (set_height)
+ 		    {
+ 		      if (c->pixel_height > c->minh * line_size)
+ 			c->malh =3D (c->malh * (c->pixel_height - c->minh * line_size)) / li=
ne_size;
+ 		      else
+ 			c->malh =3D 0;
+ 		      weight =3D weight + c->malh;
+ 		    }
+ 		  else
+ 		    {
+ 		      if (c->pixel_width > c->minw * line_size)
+ 			c->malw =3D (c->malw * (c->pixel_width - c->minw * line_size)) / lin=
e_size;
+ 		      else
+ 			c->malw =3D 0;
+ 			  =

+ 		      weight =3D weight + c->malw;
+ 		    }
+ 		  child =3D c->next;
+ 		}
+ 	    }
+ 	  size =3D pixels;
+ 	  ++tries;
+ 	}
+     }
+   if (!NILP (child))
+     {
+       int old_trial;
+     cwp_punt:
+ #if 0
+       {
+ 	char buf[80];
+ 	write_c_string ("PUNT!\n", Qexternal_debugging_output);
+ 	sprintf (buf, "           needed =3D %d\n",needed);
+ 	write_c_string (buf, Qexternal_debugging_output);
+       }
+ #endif
+       /* resize failed to meet criteria: punt */
+       cursize =3D 0;
+       old_trial =3D 0;
+       for (child =3D first_child; !NILP (child); child =3D c->next)
+ 	{
+ 	  c =3D XWINDOW (child);
+ 	  if (set_height)
+ 	    cursize =3D cursize + WINDOW_HEIGHT (c);
+ 	  else
+ 	    cursize =3D cursize + WINDOW_WIDTH (c);
+ 	  =

+ 	  trial =3D (((cursize * new_pixsize) << 1) + old_pixsize) /
+ 	    (old_pixsize << 1);
+ 	  =

+ 	  /* All but the last window should have a height which is
+ 	     a multiple of the default line height. */
+ 	  =

+ 	  if (!NILP (c->next))
+ 	    trial =3D (trial / line_size) * line_size;
+ 	  =

+ 	  c->new_pixsize =3D trial - old_trial;
+ 	  old_trial =3D trial;
+ 	}
+     }
+ #if 0
+   {
+     write_c_string ("DONE\n\n", Qexternal_debugging_output);
+   }
+ #endif
+   w->factors_needed =3D 1;
+ }
+ =

  /* Normally the window is deleted if it gets too small.
     nodelete nonzero means do not do this.
     (The caller should check later and do so if appropriate)  */
***************
*** 2986,2996 ****
    default_face_height_and_width (window, &defheight, &defwidth);
    line_size =3D (set_height ? defheight : defwidth);
  =

!   minsize =3D (set_height ? window_min_height : window_min_width);
    minsize *=3D line_size;
  =

-   check_min_window_sizes ();
- =

    if (!nodelete
        && !TOP_LEVEL_WINDOW_P (w)
        && new_pixsize < minsize)
--- 3805,3813 ----
    default_face_height_and_width (window, &defheight, &defwidth);
    line_size =3D (set_height ? defheight : defwidth);
  =

!   minsize =3D (set_height ? compute_window_min_height (w) : window_min_=
width);
    minsize *=3D line_size;
  =

    if (!nodelete
        && !TOP_LEVEL_WINDOW_P (w)
        && new_pixsize < minsize)
***************
*** 3031,3037 ****
      {
        int last_pos, last_old_pos, pos, old_pos, first;
        int pixel_adj_left =3D new_pixsize - old_pixsize;
-       int div_val =3D old_pixsize << 1;
  =

        /* Sometimes we may get called with our old size.  In that case
           we don't need to do anything. */
--- 3848,3853 ----
***************
*** 3041,3046 ****
--- 3857,3865 ----
        last_pos =3D first =3D (set_height ? WINDOW_TOP (w) : WINDOW_LEFT=
 (w));
        last_old_pos =3D 0;
  =

+       compute_window_pixsize (window, new_pixsize, old_pixsize,
+ 			      set_height, line_size);
+       =

        for (child =3D major_kid; !NILP (child); child =3D c->next)
  	{
  	  c =3D XWINDOW (child);
***************
*** 3055,3071 ****
  	      old_pos =3D last_old_pos + WINDOW_WIDTH (c);
  	      WINDOW_LEFT (c) =3D last_pos;
  	    }
  =

! 	  pos =3D (((old_pos * new_pixsize) << 1) + old_pixsize) / div_val;
! 	  /* All but the last window should have a height which is
!              a multiple of the default line height. */
! 	  if (!NILP (c->next))
! 	    pos =3D (pos / line_size) * line_size;
! =

  	  /* Avoid confusion: don't delete child if it becomes too small */
! 	  set_window_pixsize (child, pos + first - last_pos, 1, set_height);
  =

! 	  last_pos =3D pos + first;
  	  last_old_pos =3D old_pos;
  	}
  =

--- 3874,3903 ----
  	      old_pos =3D last_old_pos + WINDOW_WIDTH (c);
  	      WINDOW_LEFT (c) =3D last_pos;
  	    }
+ 	  =

+ 	  pos =3D c->new_pixsize;
  =

! #if 0
! 	  {
! 	    char buf[80];
! 	    sprintf (buf, "WINDOW %X\n", c);
! 	    write_c_string (buf, Qexternal_debugging_output);
! 	    =

! 	    sprintf (buf, "SET SIZE: pos =3D %d\n", pos);
! 	    write_c_string (buf, Qexternal_debugging_output);
! 	    =

! 	    sprintf (buf, "          first =3D %d\n", first);
! 	    write_c_string (buf, Qexternal_debugging_output);
! 	    =

! 	    sprintf (buf, "          last_pos =3D %d\n", last_pos);
! 	    write_c_string (buf, Qexternal_debugging_output);
! 	  }
! #endif
! 	  =

  	  /* Avoid confusion: don't delete child if it becomes too small */
! 	  set_window_pixsize (child, pos, 1, set_height);
  =

! 	  last_pos =3D last_pos + pos;
  	  last_old_pos =3D old_pos;
  	}
  =

***************
*** 3177,3182 ****
--- 4009,4015 ----
  {
    struct window *w;
    Lisp_Object old_selected_window =3D Fselected_window (Qnil);
+   Lisp_Object frame;
    =

    CHECK_LIVE_WINDOW (window);
    w =3D XWINDOW (window);
***************
*** 3208,3216 ****
      }
  =

    /* now select the window's frame */
!   set_frame_selected_window (XFRAME (WINDOW_FRAME (w)), window);
!     =

!   select_frame_1 (WINDOW_FRAME (w));
  =

    /* also select the window's buffer */
    Frecord_buffer (w->buffer);
--- 4041,4054 ----
      }
  =

    /* now select the window's frame */
!   frame =3D WINDOW_FRAME (w);
!   set_frame_selected_window (XFRAME (frame), window);
! =

!   if (FRAME_GLYPH_P (XFRAME (frame))
!       && NILP (FRAME_GLYPH_SELECTED_LOCALE (XFRAME (frame))))
!     set_sub_frame_locale (frame, Qnil);
! =

!   select_frame_1 (frame);
  =

    /* also select the window's buffer */
    Frecord_buffer (w->buffer);
***************
*** 3395,3403 ****
  =

    if (NILP (horflag))
      {
!       if (size < window_min_height)
  	error ("Window height %d too small (after splitting)", size);
!       if (size + window_min_height > window_char_height (o, 1))
  	error ("Window height %d too small (after splitting)", =

  	       window_char_height (o, 1) - size);
        if (NILP (o->parent)
--- 4233,4241 ----
  =

    if (NILP (horflag))
      {
!       if (size < compute_window_min_height (o))
  	error ("Window height %d too small (after splitting)", size);
!       if (size + compute_window_min_height (o) > window_char_height (o,=
 1))
  	error ("Window height %d too small (after splitting)", =

  	       window_char_height (o, 1) - size);
        if (NILP (o->parent)
***************
*** 3739,3745 ****
  #define MINSIZE(w)						\
    (widthflag							\
     ? window_min_width * defwidth				\
!    : (defheight * (MINI_WINDOW_P (XWINDOW (w)) ? 1 : window_min_height)=
))
  =

  #define CURBEG(w) \
    *(widthflag ? (int *) &WINDOW_LEFT (w) : (int *) &WINDOW_TOP (w))
--- 4577,4584 ----
  #define MINSIZE(w)						\
    (widthflag							\
     ? window_min_width * defwidth				\
!    : (defheight * (MINI_WINDOW_P (XWINDOW (w)) ? 1 :		\
! 		   compute_window_min_height (XWINDOW (w)))))
  =

  #define CURBEG(w) \
    *(widthflag ? (int *) &WINDOW_LEFT (w) : (int *) &WINDOW_TOP (w))
***************
*** 3752,3758 ****
  =

  #define MINCHARSIZE(window) \
    (widthflag ? window_min_width : MINI_WINDOW_P (XWINDOW (window)) \
!    ? 1 : window_min_height)
  =

  /* Unlike set_window_pixheight, this function
     also changes the heights of the siblings so as to
--- 4591,4597 ----
  =

  #define MINCHARSIZE(window) \
    (widthflag ? window_min_width : MINI_WINDOW_P (XWINDOW (window)) \
!    ? 1 : compute_window_min_height (XWINDOW (window)))
  =

  /* Unlike set_window_pixheight, this function
     also changes the heights of the siblings so as to
***************
*** 5531,5536 ****
--- 6370,6385 ----
    defsubr (&Sset_window_start);
    defsubr (&Swindow_dedicated_p);
    defsubr (&Sset_window_dedicated_p);
+   defsubr (&Sset_window_height_min);
+   defsubr (&Sset_window_width_min);
+   defsubr (&Sframe_window_width_min);
+   defsubr (&Sframe_window_height_min);
+   defsubr (&Sset_window_width_malleability);
+   defsubr (&Sset_window_height_malleability);
+   defsubr (&Swindow_height_min);
+   defsubr (&Swindow_width_min);
+   defsubr (&Swindow_width_malleability);
+   defsubr (&Swindow_height_malleability);
    defsubr (&Snext_window);
    defsubr (&Sprevious_window);
    defsubr (&Snext_vertical_window);
***************
*** 5608,5614 ****
    next_screen_context_lines =3D 2;
  =

    DEFVAR_INT ("window-min-height", &window_min_height /*
! *Delete any window less than this tall (including its modeline).
  */ );
    window_min_height =3D 4;
  =

--- 6457,6469 ----
    next_screen_context_lines =3D 2;
  =

    DEFVAR_INT ("window-min-height", &window_min_height /*
! *Delete any window less than this tall.
! If a window has them, window-min-height includes the modeline and
! horizontal scrollbar in its height calculation.  No window is allowed t=
o have
! fewer than 1 visible displayed line meaning that the absolute minimum w=
indow
! height is 1 for windows with neither a modeline or horizontal scrollbar=
; 2 for
! windows with one of these objects and 3 for windows with both.  This is=
 true
! regardless of the value of this variable.
  */ );
    window_min_height =3D 4;
  =

***************
*** 5668,5672 ****
--- 6523,6540 ----
  			    has changed, but not one to indicate that
  			    the modeline has been turned off or on. */
  			 some_window_value_changed,
+ 			 0, 0);
+ =

+   DEFVAR_SPECIFIER ("has-vertical-divider-p", &Vhas_vertical_divider_p =
/*
+ *Whether a vertical divider should be displayed when there is no modeli=
ne.
+ This is a specifier; use `set-specifier' to change it.
+ */ );
+   Vhas_vertical_divider_p =3D Fmake_specifier (Qboolean);
+   set_specifier_fallback (Vhas_vertical_divider_p,
+ 			  list1 (Fcons (Qnil, Qt)));
+   set_specifier_caching (Vhas_vertical_divider_p,
+ 			 slot_offset (struct window,
+ 				      has_vertical_divider_p),
+ 			 modeline_shadow_thickness_changed,
  			 0, 0);
  }
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/window.h xemacs-19.15-b2-made/src/window.h
*** xemacs-19.15-b2/src/window.h	Sun Mar 31 19:20:42 1996
--- xemacs-19.15-b2-made/src/window.h	Mon Nov 11 23:26:28 1996
***************
*** 187,192 ****
--- 187,193 ----
    Lisp_Object modeline_shadow_thickness;
    /* Non-nil means to display a modeline for the buffer. */
    Lisp_Object has_modeline_p;
+   Lisp_Object has_vertical_divider_p;
  #ifdef HAVE_SCROLLBARS
    /* Width of vertical scrollbars. */
    Lisp_Object scrollbar_width;
***************
*** 221,226 ****
--- 222,262 ----
  #endif
    Lisp_Object text_cursor_visible_p;
  =

+   /* values used to recompute window sizes when a change is made to the=
 frame.
+      These only affect resizes of non-leaf windows, which typically occ=
ur
+      because the frame was resized.  The algorithm tries to resize the =
windows
+      in such a way that these minimums are adhered to.  If the minimums=
 given
+      here are smaller than window_min_width or window_min_height, then =
the
+      window can still be deleted.  If the frame is too small to meet th=
e
+      minimums, then they will be ignored.  The malleability values dete=
rmine
+      how much of a resize event will be absorbed by a particular window=
 and
+      default to 100.  Larger values mean that the window will change si=
ze more
+      than other windows.  Smaller values mean that the window will chan=
ge size
+      less than other windows.  A value of 0 will prevent the windows si=
ze from
+      changing `automatically'.  For non-leaf windows, these values are =
computed
+      recursively from the window's children.  Currently, this is done o=
n an
+      as-needed basis from within set_window_pixsize.
+      note that min_width and min_height can be set to symbols; either a=
 variable
+      or a function that is called with the window as an argument to det=
ermine
+      the actual minimums.  This implies that set_window_pixsize can gar=
bage
+      collect.  Instead of allowing this, I've disabled GC while computi=
ng
+      these values.   -jip */
+ =

+   /* #### these should be protected from garbage collection while they =
are
+      stored here, but currently nothing is done to ensure this! */
+   Lisp_Object min_width;
+   Lisp_Object min_height;
+   int malleability_width;
+   int malleability_height;
+ =

+   /* used to cache the new size of the window and associated values whi=
le they
+      are being computed */
+   int minw;
+   int minh;
+   int malw;
+   int malh;
+   int new_pixsize;
+   =

    /* one-bit flags: */
  =

    /* marker used when restoring a window configuration */
***************
*** 238,244 ****
    /* new redisplay flag */
    unsigned int windows_changed :1;
    unsigned int shadow_thickness_changed :1;
!   };
  =

  #define CURRENT_DISP		0
  #define DESIRED_DISP		1
--- 274,283 ----
    /* new redisplay flag */
    unsigned int windows_changed :1;
    unsigned int shadow_thickness_changed :1;
!   =

!   /* Whether window size factors need to be recomputed */
!   unsigned int factors_needed :1;
! };
  =

  #define CURRENT_DISP		0
  #define DESIRED_DISP		1
***************
*** 345,350 ****
--- 384,391 ----
  /* Depth in minibuffer invocations */
  extern int minibuf_level;
  =

+ void compute_window_size_factors (Lisp_Object window,int adjustp);
+ =

  Lisp_Object allocate_window (void);
  int window_char_width (struct window *, int include_margins_p);
  int window_char_height (struct window *, int include_gutters_p);
***************
*** 421,427 ****
  #define WINDOW_TEXT_WIDTH(w) (WINDOW_TEXT_RIGHT (w) - WINDOW_TEXT_LEFT =
(w))
  =

  #define WINDOW_HAS_MODELINE_P(w) (!NILP (w->has_modeline_p))
! =

  #define MODELINE_OFF_SHADOW_THICKNESS_ADJUSTED(win)		\
   abs ((!WINDOW_HAS_MODELINE_P (win)				\
         ? ((XINT (win->modeline_shadow_thickness) > 1)		\
--- 462,468 ----
  #define WINDOW_TEXT_WIDTH(w) (WINDOW_TEXT_RIGHT (w) - WINDOW_TEXT_LEFT =
(w))
  =

  #define WINDOW_HAS_MODELINE_P(w) (!NILP (w->has_modeline_p))
! #define WINDOW_HAS_VERTICAL_DIVIDER_P(w) (!NILP (w->has_vertical_divide=
r_p))
  #define MODELINE_OFF_SHADOW_THICKNESS_ADJUSTED(win)		\
   abs ((!WINDOW_HAS_MODELINE_P (win)				\
         ? ((XINT (win->modeline_shadow_thickness) > 1)		\
diff -cr --unidirectional-new --exclude *.elc --exclude info xemacs-19.15=
-b2/src/xselect.c xemacs-19.15-b2-made/src/xselect.c
*** xemacs-19.15-b2/src/xselect.c	Sun Sep 15 17:23:40 1996
--- xemacs-19.15-b2-made/src/xselect.c	Mon Nov 11 23:26:29 1996
***************
*** 267,273 ****
  {
    struct device *d =3D decode_x_device (Qnil);
    Display *display =3D DEVICE_X_DISPLAY (d);
!   struct frame *sel_frame =3D selected_frame ();
    Window selecting_window =3D XtWindow (FRAME_X_TEXT_WIDGET (sel_frame)=
);
    /* Use the time of the last-read mouse or keyboard event. =

       For selection purposes, we use this as a sleazy way of knowing wha=
t the
--- 267,273 ----
  {
    struct device *d =3D decode_x_device (Qnil);
    Display *display =3D DEVICE_X_DISPLAY (d);
!   struct frame *sel_frame =3D device_selected_frame (d);
    Window selecting_window =3D XtWindow (FRAME_X_TEXT_WIDGET (sel_frame)=
);
    /* Use the time of the last-read mouse or keyboard event. =

       For selection purposes, we use this as a sleazy way of knowing wha=
t the
***************
*** 358,364 ****
        )
      {
  #ifdef MOTIF_INCREMENTAL_CLIPBOARDS_WORK
!       Widget widget =3D FRAME_X_TEXT_WIDGET (selected_frame());
  #endif
        long itemid;
  #if XmVersion >=3D 1002
--- 358,364 ----
        )
      {
  #ifdef MOTIF_INCREMENTAL_CLIPBOARDS_WORK
!       Widget widget =3D FRAME_X_TEXT_WIDGET (device_selected_frame(d));=

  #endif
        long itemid;
  #if XmVersion >=3D 1002
***************
*** 1074,1080 ****
    /* This function can GC */
    struct device *d =3D decode_x_device (Qnil);
    Display *display =3D DEVICE_X_DISPLAY (d);
!   struct frame *sel_frame =3D selected_frame ();
    Window requestor_window =3D XtWindow (FRAME_X_TEXT_WIDGET (sel_frame)=
);
    Time requestor_time =3D DEVICE_X_MOUSE_TIMESTAMP (d);
    Atom target_property =3D DEVICE_XATOM_EMACS_TMP (d);
--- 1074,1080 ----
    /* This function can GC */
    struct device *d =3D decode_x_device (Qnil);
    Display *display =3D DEVICE_X_DISPLAY (d);
!   struct frame *sel_frame =3D device_selected_frame (d);
    Window requestor_window =3D XtWindow (FRAME_X_TEXT_WIDGET (sel_frame)=
);
    Time requestor_time =3D DEVICE_X_MOUSE_TIMESTAMP (d);
    Atom target_property =3D DEVICE_XATOM_EMACS_TMP (d);

--------------480E554CB1EEFB140DCA4A0--


From xemacs-beta-request@cs.uiuc.edu  Thu Nov 14 12:10:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA06665 for xemacs-beta-people; Thu, 14 Nov 1996 12:10:38 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA06662 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 14 Nov 1996 12:10:37 -0600 (CST)
Received: from atomas.crim.ca (atomas.crim.ca [132.218.7.2]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA24578 for <xemacs-beta@cs.uiuc.edu>; Thu, 14 Nov 1996 12:10:09 -0600 (CST)
Received: (from paquette@localhost) by atomas.crim.ca (8.8.2/8.8.2) id NAA04384; Thu, 14 Nov 1996 13:09:34 -0500 (EST)
Date: Thu, 14 Nov 1996 13:09:34 -0500 (EST)
Message-Id: <199611141809.NAA04384@atomas.crim.ca>
From: Marc Paquette <paquette@crim.ca>
To: kifer@cs.sunysb.edu (Michael Kifer)
Cc: Marc Paquette <paquette@crim.ca>, xemacs-beta@cs.uiuc.edu
Subject: Re: A Toolbar for ediff in XEmacs 
In-Reply-To: <199611130014.TAA17633@cs.sunysb.edu>
References: <199611122323.SAA01381@atomas.crim.ca>
	<199611130014.TAA17633@cs.sunysb.edu>
Content-Type: text


Michael Kifer writes:
 > 
 > 
 > > 
 > > I really love ediff.  I think that it would be really nice to have a
 > > toolbar for it.
 > > 
 > > So, here it is.
 > 
 > This is what I was afraid of: people will start taking it seriously :-)
 > 
 > I think, though, that almost all of the patch should actually go in a new
 > file, say ediff-bar.el, `required' from ediff-init.
 > 

Fair enough.  Here is a second "bundle" with most of the new code in
ediff-toolbar.el.  If there is something else that should be changed,
I'm open to suggestions.

Also, if anybody would like to see something else added to the ediff
toolbar, now is the time to voice your desire.

 > 
 > 
 > 
 > 	--michael  
 > 
-- 
Marc Paquette                              |  Positron Inc.
Concepteur de Logiciel/Software Engineer   |  Montreal, Quebec
marcpa@positron.qc.ca                      |  www.positroninc.com
paquette@crim.ca


To install:

	1) Uudecode this into the top level directory of your XEmacs
	   distribution, i.e. the parent directory of lisp/, etc/, ...
	   and uncompress the .tar.gz file,
	2) Extract the tar file,
	3) Go in directory lisp/ediff,
	4) Apply the patches with "patch <ediff-patches",
	5) Byte compile ediff-toolbar.el
	6) Byte recompile this directory,
	7) Re-load modified files, or re-start your emacs.

	NOTE: For the menu items under "Tools" to appear on startup,
	      you have to re-dump your xemacs.

begin 644 ediff-toolbar.tar.gz
M'XL("#N6BC("`V5D:69F+71O;VQB87(N=&%R`.Q;!UA35QN.U19!Q;I15"*Q
M[.QI(@D;`X3(7H;("$L9,@1!B:A5JZW82AVU0BT4A8HX00&)BV%5^"NB%60[
M4$1`9!/NGX01"`'46K3V?@_/#?=]OW/N&3?G.^?CA1/LAH3\PP;%H8AX/!0"
MA4().*+H$XWO_>PSE(#!X#!X-`9'P`I8%`J'AT#QD'&PD*!@ET`H%.+K$N@6
MX#*RG]OZ(,@G:!S!_`?[^Z]U=0E$?CSSC\:CB.#\C_?\<]R]/3S@NO!@?[@>
M/"0`$>;J^UZ>(?@Z$W"X$><?C<%CA?./%4P_%D/$"Q`<D8B!0%'@_/_C!G/G
M>'C[<:`2<\\.]78/]H)B2'(C.7AQO#V]@H4>@@$,]G:#NGD)QE'2R]4[.,B)
M!=6&1LA!46$HE-;@B\?0V]$QM\&8L++A:!_&$5XPZ"$81GC!#<6PP@L)JS70
M,C&*PO97(<+0)"%&$&*8?LQ#A!&%&&Z0GZ@RD2=IH#=N_1<L2@KF,7*OA95A
MQ(#0W4/8*-P`1A)APM:2Q*4',)1X)-QZQTR,8@9*#XQ*;T?<AK1'U`T)/VQO
MRR2>(^J(!";11I24OO3-YEAOP":*'`2T<5[_`\9E_<>@!9L#T?J/(>!Q6.'Z
MCT>AB>#Z/QZ&U(#:KV1`-9!#EG$-B5>A;PD7./?&A;[%WR_$E^WFO]8_,$A4
M+(@=P`ED!WB'<=8**U0632Y)?!4:#CK(T,I:PCK[JA`604#=H#"4R`2<,EEP
MZ[HVA"/\7>`']0SD;,"+&)C@SCC098-@NQ`$=75Q6^,9Z!_BYVXM>)7U7`+U
MA37V5BYJ3F_EL%%,5.=[X<GDO\63R;T.B)%XT<\PAWY>6)@LQ4$*W^N`&,+W
M4H,=)/E>@PTXC%9>R`[A^XE!#J/P")&]Y?@/Z;5&KPTICQC"]SH-J1\AP<,D
M^$'C)IT7CUM?_</:CQC@^YHGV3_$Z.7[QVV$]@V,VPCM&[W_8XS?.W\_-E'`
M</OOB?]A8>,8_PG]\1^-0Q%%\1]#`./_?S3^"X,\82#\B^\TAMR!&P!P`P!N
M`,`-`&CO/?Z_Q]3OF^5_L;B!_"\6(\K_H@E@_/\@^=_14K]C9GW?:\(7)37A
M^U:EB=*QH0E?E#B;.S;F/@P35N8NRN:BAWB2WA3C].>;/0:W;#`Z"B9*0(LN
MP[%W&[,1,"EC]NXU@@G?CW[]#QB_]1^#1J/$^5^!HV#]QZ#`_.\'/_^Q==_?
MN0\S]KFO/]'[\9[LQH<?./*\&S_HS/2./&PT'B'B$:/P@PYU;\\C^GC$R#Q"
MH@=OP_<3@QW>AO\4WJ]_@`=/=I]2_'^/J=\WC/^8OO,?%H\BB,Y_&/#OO_^Y
M^.\IB/D?>VX7W`&`.P!P!P#N`#[A^*\G_*.?[H?2_V)Q1%#_^\'ROP-S/U(2
M6.PP6B98[/5NZ6"/@3RI&.O-G6(ET\&#T<$8!CN\M(3^5_04DF1J4YRC%>M_
MQ4\1ZW\'8;A!946588?H?\6]P4KI]9OK?\6E<5(PL?Z72!JJX!4IADD2Z6!1
M1]PDM+XX*9A(_TN0IO\5Y:,'H1[#/5$#8FH)_>\0#$P'?Z3K_WCK?]!8%`%%
M$.E_P/SO1Z#_&7@50/UOOSQEL/A%&M\KD1F5A[T1CQBE_A'E/Y+:G-'*2Y/_
M2+0/,08_3/XSK/_#Y#^2XS>:O.?ORW_Z!3`CR7^D\1+ZH#X'Z?(?F(;H!S::
M_$>:O`<Q!M\W;F+UCG3YCX9T><[`N(U2?G#?1Y+_C,6_]1$1#.'_GO@_KOI?
MHEC_2^S5_V)!_<]_-?Y_S/I?<`,`;@#`#0"X`?BDX_\'U?_B1?E?-!$'QO\/
MD?\=+?4[9M;W8]/_]BIFAV$#.5I)%:Z$CE8*1AJFP1W(A$I5ZTJKT4,*QI'0
M_PY!1RDM[2F]&!K4_X+V[NO_!]'_"/6_A%[]+QI<_S^&\]_[//J!$N`WXX?)
M5]Y>`-/G-1H/&X-_#P*<,9^/&(V'_4U^M/K':I_D!(`"GS%X4/_S"<7_\=?_
MX@;TOVA<K_X7@P;C_W\O_H,28'`'`.X`P!T`:!\N_GN[^?L%(01!$>$9/B[Q
M'X\F].I_"2@47O2_P&C!!Q:,_^-A2KLG3UXA%X;Y;*+$[$/J657^\:2Y3YN[
MYWBU;T]T/B5KD/3RVJVRYR?OU)=[>9XC'BM*4IY4XH7UC4DLM3W&+VTX=66U
MHIN>B5Y)=KIO8E8<_]2BU#A^^X.$W9S]1S8M+RV/W43.9,?G=82N\6K21D[]
MK/2,+V6J<FLJ3;WGM^H:V1LSS%2H*J2?4+?=71_$ADRZR"O-52Q-R\X[[+XH
M_9AI).^L\U'2;IQ3><)ZC;:M-W<\=HWPK7F6F3;I_K-7S\--K1Y-N\!261]X
M)#W^)Y_LA^7\+EIKW`L@^^PEX\(N:*3[J]\<#NPD^YQ(@H>H\R]G)UQ[#=L;
MLBW2[,:.9/?S]V`/)Q5U6"5/29(/8N4&SRC^7(_L\>UO/]N>I[?+-.$R3ERZ
M=U?AY!S<!J,I<ZPSU(O^O&->]_#'@M^=E-5+3MRKU@@MUC`TG)FT_,0"$[)E
MC-G%Z;_O_-7JCUKOYY:1AUG:E='-H7/S&W](K@$Z:VMHK:K[7+OSJI9"UW9/
MUYY:`Z`?R=SO:>U0+>7K+LAE_>84HQ\6>Z%QRN-*;A#`QUQDE?F]M$_+O!F2
M<7$54JEH#KX]=M/%HLY])JNG5/,`'=_]*EYSW573:M`W3K>=[0[,SF`^J]A`
M[O+91V4H5#^RXY9=9W8$5Q7$YMWPMSM<VG4XYWYI:?&QL&9/G].H@EU6"J%3
MKZZ5WU+H47C5\ZSR!)]K#YBP"7G>3PZI1'V!G`F514+14;OF55O+FG6H:U0M
M_'*F0L#U!,\NT_/KIWS_"B:+G$EO_7X+10YQ[O#BU-*4<Q5JM.3&,V$^_+W+
M:/[I^U_9U-^SI`;Q*27^#0"MAR03&E'2`S2M6PHH!0(-,L[7NWD-6P%N?$\<
MN>-4(-#RHR;KRB2("@0U8;,L)!_:`^@<K2BKYBT]7LV;5-3"4V)<!J)G`OBO
M(RGQV5N_V*CM>SG=[N6*U'T3LYT7W:Z_!U]`]EE[Y=>+V3&!&;\C'C<],=,Z
M=!Q?:P_Y:1,NI.N\PV[S(H\NIVV;&^A[@+IUN=P77<Z+@-NS[C31MK0WU-;Q
M;D9?2^D*:,N(E@EGAG)"%V8YOGJQ8\J:1.UU>=M@VV$3$5K/.VN.7[>@[(E9
M\/K*,JA*[5;>]IX0R$+;]<@R0$GM=68\D/>X,]HL:Z\VT%+9T7"X&;"[6$AK
M^0MQ"[+Z"P@6<G!"%@8`OJ'6=H7)=;-G&EP&%L%[G%JVID$#CER>+7O2JGZ>
M?$$RR3M%T_68P329W8X6.^C8]*L`)_10\M';9".G9FY=YMUNMNZ\R1L.H96;
MN'4E7S)20I\"]RY._.[D$\#(ZM"5FPK7K+Y:>$OC![55%3KQ;MT5*_,`3I.7
M[F&\5?B<0XY5@`EYLDS<_]II*D">JG/MUVN[=[0WR#9RD_TF=+/-F3-N(,E9
MO^0KK/-473C_1?H=KK7?'G7>GI[XF.DAE=,ZF?$]TSJC2R)5P@N;G]%^AA09
M`7]6R=&.F_UR#"`ANM:9O59:=$DFI)*36?QBD38_K[@H*'D]]M&\NG(CX-G5
M".2,*U_'I0%*WP&*Q=T5QRL!UTH@RP;@_M'-/@BYW#OW82$]@'L[+QBAT\&;
MT0Z@JWF)__/WO-MVMYWWN5O:T=]=SVE,L:OZTR>XZ`N9]%W;?!YDD'<?,CJ@
MT<VFK\E/R30]VAP%3+GCWZUT!-#OX+G<`+YN`F;?X^HC^)L_RU(L_R7UM>KE
MF"2S"T51TW4N/\NB8:H*L.OV\4^^2F)#OMQ(#A"T*`"@(0#B\79>Y,I7W(F-
M@'\A,/%S!0\(:N+F^9#\=7R@M?6YSX^Q92EV-^L;CU86M/NK7>?J+P"FG9K>
MP]W6GOK7])+JRY8+K);;FUQ0G7%!?L.9Z>O/3."<#"_:\N`/UY^C$N`%=I/O
MQE!J%<IL]YWAY9!.,/,7757&WCM+J&8EK'?WG3L?EG;T28+LU:C.RL=W#K)S
M$K#17!N+Q,391<^T7ETX];+\RWG45^T\:G5[]&FEIA8E6>6KN=SJ*^VTSD[F
MB[G74B9>BYVT.D/M>GGV[,JVZ;]]HYYH][3#)NUA0O-M3(=O^YRE/QR86\V)
MHC#D;VQHLM-\N;[RJ4QN1!GP4#NTK+D[**$K>C-%N;R)WU#">[A%N0555(.X
M/T76Y^$1[5N++UB[:^[)Q-XWO,KU.Z1WJ^&5VV)//Q@OF!OJH<6C;&4D(`N`
MZ8OE7K8"VVA`SF+Y*<#T.AZQ#JA3:S3+*-D!.;$.^%&VD5_9=:5M:P/W9N"1
MD_+YW64Y0%=,:TX-;U;<$:`R8LD+8'X14.2W+HW!4VIK2CW5>*R\[,;!K.?Q
ML>3&/4_WKBC1BR_=?C4PG?K4?3*F.K'[18+:-?Z&&3\_K<R-3X[]CE)F[!OR
M5ZA\.&"UL:#KY<T<9AS0$W\D>NJ"#I^V_<QY;!I[XYK3Q'K_AJ?1%8CLO^"M
MC;&M&R]I9_EW-`:T]JQO>EQ'B^PXP"^\'9C)\'_1L8]?;W<86K&[?M.CO#C`
M=>OF/INJ"MS,T>!V5%S=H:L5>]WG=C$N6?E,[@]G[%-DX:91*1H3]9W\K%QL
M=]./6+0:RSMVWG$JKM>R*$1HW:[72M):</V'YZN_"8_-.8.SB2>>?;YKA='N
M+?8V1J;PG0]]7*?]D;G+(?GG_1R'%'9"YYJ05I7Z!GG6RJZSJ3H*<R?UVJ/\
M0NY]&6Z/XD^M0'5UMR?M_O8)'H5<U8">YK\*N3LB7IN&:W<>:3!Z8=(^RS7U
MQN.?%+>55>]MM_!G+X?ZY5CH&9I!JW:ZKC#YI7*VKL?#O=SRS8HM5I7:`;*+
M%\;=;*Q\'!>_ITLILXN:V75-/F7>4L6T\\V_Y-'6-P@F]BGW<?.DJP6`7%5W
M:OSDBE*GUUN?Q%98IE8\==I2%A'Q0#/@3+@2LK1C?OZSVK1BW)>MT6<V)4_S
M3:J[E5)['!WDYSM?X'+NZ3S7V]D.K9:+IA/9R?%9S:SPLQN+/3+2BVL6L??'
M?!,1\5V*XI^_;CM*SVN^YTFU]%5HQ*K!7.^</P?7/)08XN+?D/0M4/=]+O=6
MP4:-7$!-J>-!!S-R<@VPLX[WJ].W+25*)CV,V&K%SC9EH$N=E>*G5&N3EG=Z
MY2'=@[>GGE_Q=1UV"LDT>V_"O'(.KT!E]DF9<A=>?$]@K$=7_4Y8E=UAI:8X
M0A<GJ:0A]3+_)K>]YXK7N>T]1W-":Y7D"^U;HYS;5_/C'T16WF5O!FB/FJ(I
M[<"I$F`WVJ5':99@W;@)G'6CJCSDGX5G+HZ#W(W8[/(99!9$M-2Y0]O2G:^7
MOCY%V1P:#<R<.2,NEWMC4C=@4<,SI'GE<DTO47N<MJBV%"@=V9.0T79_Z3:E
M&+5''JD(ME=P4KCYT8J-BH4Q7N4-L])^1%M7\UZ$&3`C^61LXG[TG=HG+3/V
MZUWB)^9<+\HZ,+F\H_E>'M`2E<>%`3O"Y@`[*F45@7C9;P'826"7'WKN1+4G
M!W+D4`_<;A]0V/9@(YRT*\@[;\8U^UWV._**>:=G,%VQB],K<_CS3^3L4ZBW
MY<Y>TU02X+LBISA9+<PU=U909'D&O"W5-,K9$RBJ"C@X:_)0R[^1#TPX_3P&
M@.2#1ZY_T?D/$1+RSY__B!BT^/R')8K.?W@\F/\=%W/E>'K[0873,WSVY1BJ
M]F9JRDMU-*@P->75MG@#,F&9D2;!4)]BZV"E:8S67:X#8Q"I7S%76.D0'-C(
M55\1].UU3991S58;+I5CF%"=8%9P.Q-3AB;#SDC7F`&C&EL[&N@M@=-7:-G:
MXN@,!H'.MJ,X.<&6D)8P]%$&=&5;4T<["IF\2HYAS+9=J4IVIK%I^LOH:@Q#
M0[H-"PEG4HT%=9C;..M;L`WMR+;Z%DC,*JW5#'-+"M9,2XU)9B(MC9WE&'2J
MIK[R<@,T5IGDK*ZO1];2LC$@,8RHVBB,`Y/%5%%AF=LRS:B494ML[>C6#&>F
M$YRZ`JNG"?^*21645B69L.R1FKK.>#VJK9V^(\7<=@F<1E]E3G?$V"`-8!1=
M;77C99;&%*J^D9&)LQW<B>5LQ;8U%ESD&$Q3!`N]BNVDINI@L,H$O\S07L>1
M;&))UR3BZ.SERLYT+:2UFL,2&UU5!RU+$M5DF2:1H,9:N=2:;8@5C)J..1UF
M#->V,$:A;5!X980168N^S(+`P!G;+V$OM38WL639,%`D4UV<-15'TOP*CW'4
MT$:BK0V<3.48=NI$A(F-F9Z&MHF9C;F:B38+9X+&X3`F6$LS%8,5CC@Z6LL<
MY6RJIZ&.M337I3L:JCL;V5BS[-785G(,;0N*VBIU#1-[-MO1$:'%9NE1L22F
ME:H]!J5#0:Y$(E%6^FPK58,E+)HSBVE@;,NV6:)BMDR;CC?'R3%0=GI4<^1J
M30?J$O9R-INE96JH;4=P,B=HDITL[0B.YOB5S/^S=^W]B2)+VW_73X&@HJ`@
M%T%!Q;LB<A&\H%Q:DS&[^6TVR29FYYQ/?]Y68V(R)I/,9F=V][4R.MI/=W55
M=U$%0G7C02:?5>H51>YPH9HE"G.S;H)@'M7E8J$MQ8K-M"<W,J7V(/!HOZ3-
M9ES842J<YDEJ)N281GV:*(-)B:%#D:LYJH?;0B!&]79@>FU?%,>!F5<G#:<X
M[@TRF1G!#VH3+)/N8UV2+O8!6O0R];F@86/>;\Q+976J-MM1O9HKF/'Z/$W:
M\T&UT!7=5B[-T4V5,.*E>"Q5*&789A%`,Q8+9%-)-5#69UE%8JJ-/A'528V5
M\1Z0-9E3""SL^63:E<QQCN("4Y_*=KXR$?C&U`&<*<DA`#1PW=BD[(U-#UJ+
M+\:;8!#8(/1QL<_Y9AAB8!(V@.K/0CEF`R#DB=$D%IO/VW-L'JO.FW,;Q4(P
M1&MPOH-)W;39KJOYT'X$@`\G<^#Z+'"$A-(P&F8WDU2PD6Z19=%KULVF185B
M#=IKN:!']61#[<F99-V09WQ)ZVFD(0ZF3:O?EJJC6:(Z;W>&P[)BC(2"3@W'
MLB>X[-P;MBD0ZH.H/NB`?CARR\`?<D,S#JIFPYQ1!K!=@&F*;@5>CXY-5+H\
MSD]P<B#YAHVC8Z--BS@>U6LHE4Q9&8.DM)D[:\1YSJ!:,6UH<<UJVJACIBN'
MY=R\E.\4S(GB*P3->ET`\*G2HZ,Z1]HY6@$CE^Z8;3BB>:]#TP!.3]^:%^!?
MQD(+<]F"HQ>F::/A5>::+P[2<8OVRW#&E*D<%*AQ"D?+5BR7UEJTGK`\JM>H
MJ1JKU]5A+AMS=8DOE-,93T$!U*`M]6H.IR:CN@"R8.:9/$@$L815F[:Y>-T7
M@3:NQ;*:J'1`($WG[MB`CB;)3SLQ>]#`>)LO.6B/C>I$PE%R1+8!LD%N`(*6
M+]1B;2?/56I"43!PP#:ZJ=@4Y$+,;P._U!&->D*F;3RD_#2T%CSLR57<%X=3
M.EYJFI1F5^U8;5"T2Z5DQ9X,.P$O=UW5=+VP.\W1Y<H\&S:A-54GLZC>"-0P
MW=%H/VR"SASC&!,P;JX+>G&[J@+?)4U]P-$Y!9>'>+D2:QF!V,>Y23`(1.B9
M2C-UG`ESXBR8)D'802NVSU@%0=%-7VDHOCQ2'*5'8:!@8,!,B$#QX9A/JW-K
MGH/'=WK]0:R-@!DT0S(8DDUL:@YP%_J3NCF3<_)8X8.`<TTKW]![2:V@Y7KH
M2*D-!748U8=6`=?=7ES2VS.J:Q09M=2#XY^6_+IN#(V:[^(`#=(FB(5E,*2G
MYAA/`U<<@`$G1'5EF#%`88Z:,;/2)<`P[:-\C[?=H1NG<QE,-3'?=DNN4RK2
M@682J@A%5C#5<ND01J(2[0/2]"<]N@Z4%F8K%FV!,30Z*Y-()J&MS:EY,H>E
M2LH$!*;<DU2A,I%&HAU.K*C>K6!4F/2[`SS`DJ:?[<]!J+B<JP55>FR0<[ZF
M<G2B1AAHB3'FTVF_&HS[U41+ZVAPS*MZARBH=DQ%)U3>:O`MS.PFLR.AZ1%0
MM3KT%]6R54\Y(RTS=EOC9KG-Z(E:$XX@#OV:.N^@546K3LM$0?2%9L8-0#Z?
M;*LUCINQCFV0F#&IS47:)%W3\>IA*AS@`!_A5K,>U:U^$;A]W*6!!KVP)5BS
M(69-W7B!['8'V5F8H+`)-A/2A%04IZ"5UW6[Z?M#.Q0F;E1/L"S;&LCU8B'N
M<3DO75$2(A%.QRY5P@<=LPP"*R@'$P?@5#-TPSEEDQ5?F9AC#92@WG5RE,G2
M#5(OD:B@E3K<)(/#D%=$#<IP:)$II8&LME"'`G9A,.W(=0J4\6!2K-O0IU)N
M-JNB@`*67T$-;PS<'``^7\&J)L!"`V1#$\SLAL61FE2ST'Y)"?.H@L&0;\:B
M^OH_Q=?MCN12-NV4!PKP6K2<<#V?ZTPGP,7[-1B<BD,`.+F3''.RKP0@:?9I
MM`,],HS!;=+I=:?NS$]YG6:\(>5ZM%SKIVW=\3K%>=5V>[+O$;FN!4;3>-'I
MN!FIT5-G62AY,,)E42R4K>D,C+*^8YJ&[>?I#G1DW>F8QF+:5#(K`C<H*_0H
M\"4O/O$$8$Y=H*PCD5<@%=GJF$7?Y,:^##I6B89^U,1;,R<(PZ(2./[(-H8C
MTZ/;'*B,Q+:-*?5P%$3U:::B@#&!5>')WO8USZ0!(`>L"N!1A=:&\7ZGS_2<
M,C_LU0E[H!*V0`S3)&_`4=/8+I8;Z08_3@CU8;O,*T4<:VFS8<O,>^R`<6RW
M[U2&_1YK28,TV2ND6K-.7["S\*0QJF<]NE=OUI)U-UW(\T62+#1*4CN5M36#
M$*1>J=7.%[4\]&1M?1349=VSIF6>-AQM."]`6ZOFXK'Y^L4U[4P`1E89@)HA
M!2:HN^:@0P>5Y%R0:<4N6\"D"\XDQ"N`(2N-M5?L5(*D%]?<^)@P[8H@)5VN
M[*J8RPN!0J,Q8Y!/H`QO5=U"K<[&>U4WQL2*NIU3@AGT:TF0YUQL9*&,6^KX
MIN52@M)U/0_WX!!KIF=9,SUAYV1=$YUNI@3*!@`#QNLHH0C/N&(9$EJI5@-$
MV$"S0!8`BTU53^%[0)F.#'0BZMZ8A8=BIZN0@3E-EAKJC)3SV1@VAO[<2P>]
MZ@B>:9L9K5+O9L2L(3.=(C%!A]-!N>[(TV+02I4QIZST>I3OCT:S_L2!0]F;
M1/51)5,6IQ)?AWTTI*$\E(AXE^_@?E#LT*VTGJ3G#H%FZT--&)*L450[^9H<
MAFH#.H2HWBP5@9.9^D1?!D0,3,=*BU:JC09P&YHY2\L-6I3PH19R1:^>!-HD
M90*/R(]UN0:Z43TORW@_CQ9SQ486(_.I6J7OH$Z--%6TF0BF+=-WVPG"Q2?M
M).B"J=UIP\N$0K7AYBLRO"X!225KZJU>63,U'PML>%""?J*KI^2P6\I/9C&?
M<D:-<37ON05ZW!B+7G64".?``4T80PN^%]*A-39#,B/@(3[8^',2>-D&79=+
M0,[HQF"FS+.,5TW&T7DLLSWUFL=@ZQ1=F<#S-#D@YUX5K]!@D&+C12B0WXP#
M.F!<+TC`+I/*T`AH<RI7Z\K(J87E1H^%MA8$I68M%O($Q;0U>ZI(.*M6FK/:
M9&+)SI3I3@R?TU5^D*<(X.&U.#?Q`JI!M5L-')X[S"AY%"\645,9MP<ECC/3
MI=3$[#BCO@*"`HXK-@UJDVH>N$H5A<&]:[4SP(:G9*YJ1/4,4\`(2A('T/&,
M!3K;&M3C8]'2J93J2*428XWJA)!2\)$<#N)\4,\,9A,W(P9)R4G`^1XT]'S'
MYR6`2Z7D*#4H"ST"K]4'M:RCZ+,9J51,UDU4BM`KNB):B%N/?B3*[SZAF4;:
MIOU8O]+C@86EYO.8$YU'EY>?CH_[_SU^_UE=_?SSQ3)[>WUQOOJ85+"OYG\)
M>_E?PCK_2^"YX^\_/R#_:W_N7\H#>U+GM7RP)Q6_<2&PQY2GS=MF9X/URE6Y
MPG9EJTV.$_^D=+N_`O^\YAO*-LMM':CY?HX+X7&'W(_@N&'V3FWV>WDRCILQ
M$U_-V!(.[#3![8#'C9?OF3$/.6EGN=U4B6?/:^[7.\1QEQ=VJ.]C7M@/]/_7
M?['_9UE&W#W_S?$BM_'_?/[H_W_X\]_[IO!QSX$+[UP`;/U0.)O[UB7`T,_W
M+`KL^IL,OYV=WRQ/;LY/?_WX)\BIIX\6[W_=XMB7:TC(VT\OXL17</DOQM_5
MOTS(!"'#]Q_4_P_`L7W\*_/_5OLBMDND?)8.X\2N?*_"(TY(GZ7/.WI8;&6'
M$Q)!4'M_Q'V-_?;$;IM'B?BB_9/^">E5^0GIN(CT/SK^?T@JV-?C/[?+_V9S
MK+")_\?[__]_X_]C%ICTY-NW+`!V(/P_L#C&_F/L/\;^8^P_QO]M_/]E>?'!
M*W^])?XSZV5?=K__YIG-_@\<*Q[7__R1\7]M"MG5\K?OF_Z]=^&_CN[8V8;^
MU5L]?07_2AXR]60)S4/+4&Y:OYCGO$&H5_'7VF]VBGJE_YT(V)_!7]VJZD_C
MV->WVOH*?^PO[?_OF.<==53=ZK<0Z!D.T!!Y-]75H:6Z+_`KO)^?47-5!WF!
M'_N-_)C#_-AOE8_].'Y=U1F:]A29W)RO5LM+Y.2_B#M&.(K)+9!OH9;11(YT
MI",=Z4A'.M*1CO1Q]#](D?O7[O/>VRL4V56)O-CJ2Z;/D:<ED2=-(B]6C$2>
MP9&'!AOTA6X>L,@++`\QW7R`8.2P])&'[B+[Y9LOD0/=19[(<@")/-$ALE^^
M:Q*)'%!MW5GD49$G3+>"1!X:1IX+\G34]C6X[W6_R4/+2"02>7$BG[\B7[6F
M@Z\WF.#!?]]*QY]ACW2D(QWI2$<ZTI%^X/W?Z^]\_Q=A&7:[_S,#2P6>W=S_
M%8[/?__H^[\?=^N7>]>MWY.W/=AUNKM#G/OR6:Z35VC3Q5^)?]?NMS>(7\2I
MTS7M5WB"4VN,>E+A&;Y&J-?Q5]J??`%_H=\S^!OP)_"'XR=/X0^7_X3Z2O_?
MVWS_M/D?,[3^H?'_[OK38K7\^"?`OIK_R^8>\K]$CEG'_[R8.\;_[T&[W-[M
MW'^9\WM??CC/]Q[\6^WY>*B,6Q[:O_"4VR7*[K5>I\SF/ATH6S[/4V6^W(VQ
MP!W8WU%X24;AV9Z/F_383<KP7LVS`S**!\I.'E.8]_1FON1XFCNP+^5QS\>C
M_W_T_]??U_^S#)=[N/[CV/7^3YS`'/W_C[S^VYK"C[H"7.R^%G*[*[WW[@5U
M^@IM>/Y;<&H!Z66<VF";&HM#^.+A_\6K^.GB=7SQ`K[M?P,?Q$\7U-OTIQ8'
M\4?&CXR>X\]5>8:?OHZ?OMY^-[HO]/\H!?7OM+]#^#&9YQ]#%^>WU_1?W`?"
MY\1\_L7X#VD3_WDVS[#\>B\H)L?R3`3)'^/_]YG_3;8O_;>8__QZ+1B&X1CA
M./_?>?ZW.=_7B]7I+\L/U?5K^7\<)SS,/\NM[__P.8$]GO]_#U(O/RW_(R'7
MO_Y,_V?YV^+T-LL4*8:GO["+7ZZN?J66%]'U%R1[]_86$D,Q[ZK-1;/9[/OX
M_S2\6R+FZ0J:#C0>*2]*\#*2*1:%*$F2;V?UTV3Y"3&N_H`7H`C+2ASDQ&_9
M5*M(EBMDB@@)WWD.J5:C2.K3\NR/]6IWFT,F^]OR\BX=160965Y^0JX7I^=G
MY\N;*!(E4S?+W^_.;Y8(OEM687.]G8Z2$(-,[B[O5\Q;L]@MNO#;W<7J_.QF
M\=L22<&:")(ZOUPM;Q:GJ_,_EO<%9TAJ`?M*G:POAZYW[$^O+E<W5Q?9D[NS
ML^6ZEY_@49:ZO%K!M[N+"^1@K5VUY>\'<21U>G=SL[Q</=3?B(!LFNRO%?$H
M]GV%%&0$17QD_/G\\M/5Y^SM<G5WG86Z0X6N+G>R;TNW56Z?,MN(!_'?LW#(
M%A!Y/[_KB\7YY;VJWR;1EL.'"+.G7'HSG*\8P]WM<F<UKUK#9I*WS?>:9*_W
M9FMC,/=6O[A]J')[=WU]=;."5?>40PZP0E8[9B]7N3R_V&J$/-'H_A@\OSQ?
M;;2[7>N"W(M^MERL[FZ6T(K7T.;PN#\Y2%W?7/U\"<5*+3Y]V@[+R=UJ=;4N
M0O`4NOX=X!;=R.VAH]LE<@N/R)O%:HEL#Y^SJQNDM7%;]S:-;&T8W6CZVI&W
MJ2#=KOY[L42VX'W)\F)YNEI^0OZL50=K?F@NEZW?0&1Y0U'41I&W:KI`=E;Q
M^7SUR[NTW)NQ-ZAYP*0.RXYL9;^].UEW!K_NR;TG!8*:YJL-WQR7UM;TOKAT
MW^*-<>FQ=N&-<6F/_Y^-2_>L7H]+/)\1$!*^_U][Q]J<-I+\#+]BBB^&"V(-
M=N+7W>X!<1)7.;;/)IMS;6W5"3&`UD*C2(,Q]^NONV=&#Q!8A&!_N+AVO6MI
MIGNFWX\9:#;)+_7&;L3@'U";1W<`,^T(!85/0,'M<,Y"[KE\2&H!'`TC)N`/
MV^&68P=V'V1@`,OP['E49G)L2RU5`\$C?T^R!U_,F`T>1Q+7E-%ZC#_T=<%6
MH*6H_.UBR&1=PYFYX(*F&=G%E<@QCP67=*-1?D,;&>/JP8*`+`,=A>_-&9B+
MN9@"1B0=TY8K8CT%+H*97>6LO'F=_?N<1N'RZZ`2DJ&-I&>D:N2PV^";9YR%
M4]]W_9&BE])69@>!YSHV:3,L$W[;K->[_TV9-I#6R)C^`7]T@8AR'O"475/O
M%),#8M>[5OV(O7EW5&^^)7:5M'8!%6`Z,B*J)4_U3%:=\,DWHX@I5#70K\!!
M:QM/>2HR1\HYHWDPTV)LR?OD^@;C>]"'9'$9]Y*VXTF88][A=TL)L#W"C^WE
M/`+!1`>5#%M825:B4BM8Z\5*9UV0&E<"X_'W;S'T7.]8*IV]!P$A*42=8#/;
MEVH>+@AEY#WU0R-V=_^Y<WW)E%3:@T<>2C<")?.$8WL,%,%%'6KH63<\!+Y.
M4*"4FM01!VSMB3M3">#^,[$?N&6FZ>C*(F![(&TD,2>M8Q29D\-F_3@C,F-0
M;Y*8./3309H2*-3IM@_R)$5(\@$"7*6G^!XTWQJ&8F(B&"LH!D5S,I@KS&6+
MGJR>VRT`MF;BSVWA`)0BHP!/Y0.N'DW/V!V-/6QLH.ZC!,1^3Y&)PSSF^O3*
MUC"T<U4FD&5-(,I)&FUQ7S:5KK>9+],S"OJR9'31'"L%/\>7O=O$EVE0.;[L
M;>++6F_1E\'O(Q)T(.U"[H0>L;;\&&.JVII,2VLC)F5S\#.3P/5`R]&*V(_"
M'1!O?0XK`SX[8^X\H"R@<*C4:I'%*N,;N/;(%Y%TP;]@R*N\\=$!N>.CPWIK
M7VEK''^ISU34IL\$B6I`-=F'B@UUT!C4T@!FJ/#:/2=1/<7/>78-(TD3/#,D
MP)<(]^7(.*T3X4*ZI]T>;OWRNMN^/"?/B4[3P)B)\`%CBX"'Z(M]XV&)[:?H
M1\?V(P:2:$GUI*I1*4O%O0T#K`=T!UA@^B8JA)4Z>*'(P_;!287@N`3D"GT!
MD?`D$[/B:C"<Z',FP!"'0!WZ\`L"(GQ>)PZ#&:=1Z/A#;H%'Y\E\>RB1#!!-
M.!ZW_6F`.](D40\@7HTBL.<7Y!Y"#%QF]MS,AVV"AZD$TVA<(6R50`05$]I$
M[#?&+$O5EM"SE53:!)+`57U@85NL"GHCV2*]6%:<:\\#LA[=R$6/$JP""7E<
M@059NN>[`LC!H5Z,2O=(&D=""HO:R-5`0)IJ32CI5B^C!S>@EQ$&/#,[-)'$
M;.R"/PS`8M;,8&416D='9!-:)ZUZ\T2;A5CL4X&`UJM$/<#9D29YD",#'5#L
M=;Z-SG``6Y%</<F\(YT"UGX"<=+4,/QL)-Q,J5YJ#4OZIU::RLMS-+SV?Z.H
M&17,T3W4K]=6-2I>_`@%4U601"\4_QZ`#B;,<^P0`ET/N*,Y'=<\]!0MHP*I
M8>H'M>+Q!,[8+)[0,PK&$\GHPX+Q1`K^MO&$!K483YR<'ARGX@G*C>&WBB?.
M0(RZ8L!/5X<6S\4071,\)!5>$QO@=^=:TI4@%!CTVU)%!,=O#S!\/WY[J,-W
M;5^:;"(`C8?'+$T*/('%X0-C+;'"YE'>46V^P;!["O94/TB,:_S_]I/*!!D;
M:KM-8RE&'ZHS/-4W<>*$G_&'SLT><8)I>=P?R7&-M93\FQD`MOBT4J8JC*$6
MY#FQTA!$O41[\-<T0GW!:MT$Y!QTN(JF`<TIJA1&/@8>$BP0$:K<'$\=^2.(
MTR'$%R,L]`$17*53F3F4<+*]U%OBQQ%EX,<0H9VD^0'*J"$/&BD7LY#H,F.I
MK64+(460[S=C]\+V\VU+:N;2E`*^/XUXT2XE@*2>3&;^.];--@L6GIWL\:',
M2D;1F2&B*3#UY_F.C?N_)M+AW@OU?UN'1\WF0O__\/#HZ&?_]R5^T",N,IZA
M+V]GRK,T9"]:Z"V4R^00@WFHU+Y;(\_+/H2<LSLQE#.TJ1\PA:8*:IU=^$Z#
M9K6G<BS"4_89R`YY^;<IEV#'_ZZX\$^P]"[@\1O?G(9C_THSJ!H\!-=+M6T[
ME%BW_GCU11=S:4S\)XX9XBHBO8HS+!DSQ_8A_H0,08;@$0"AB['KX!?8(7A>
M=SA'(/`,%LR50P:O-*$*.?Z!X#]RGX>VQVZF?<]UV*7K<!^KV;`F?!*-(1SI
M$QR<L8H20'07@SH&:6N$M>56'4/\*L325-H6`8ZJ(1B,K3U;)F-SMIKL:&`J
M56.(^U5P;O+?/M4V(=ZLXWPLA7^]Z'VZ_M)C[:M[]K5]>]N^ZMV?47@OX"U_
MY`J4.PD\%R##'D+;EW,@!T+X?'[;_013VIV+RXO>/:[_PT7OZOSNCGVXO@4!
MNFG?]BZZ7R[;M^SFR^W-]=TYQ/9W')?%S196D'-('`&2#;BT74^S]QY8&,':
MO(%*74+N<,CM!I`G8$'R>381/3T!J17E,#$-SUBDEJ4$K'M]<W]Q]1$SD2'F
M+'4V"R$[Q0Q$+WV]A-?9VQ/6XT`VSFX\K#-:[&Z*$`X.]HGZ'1%)'/VYS?9;
MS6;3:A[L']79E[LV[=1$J?DA*@+XA.D1"6C<`$0GZ%(&J*J8Z`354VE[#T@E
M[-HDB2""0?,/.0@\'&)VY4PGW)>JVW&*@N.JFCA&4!.@I@*'A;)8RHUE,.O`
M+$UEX$!I-!38OXSJQ%'0/E!Z][]@1`"8,3@(Y6+`8?2\CEGIC!@,%B&<9W9H
M8F2U".`UMYVQ1J`4!;8XH%K>1+5Z+F`I`VQ:#2%7T!!-V2TRB@*[9@J`R22!
M[SU,/P$A!X;J;I4^'^]/)WW,6H?FM#GIF))*TBL>![;8J$IO8,1EI*0:=N*)
M"(+X2`"3-(T:26TATP#)C:%5B^FYIK\^75?6$6Y/)=7P;[.5<(;(V#HV^_'L
M<*0K9R1&8QNS3@-".,XT<&'E+3.>ID?N(#7'LR$24_!!@LQ4%;0A:3"(@Q@_
M$M1UXQ$/09F5=![N&[C([B':+5448O]@AZU#_;)15N$]=SVLDU1_P7>-?58=
M@FB!E@"O?(<;2E$9/O.&[>FF1TUUP,K9\JXAH<^?8(Z#-=JE4PI)6J@R!3.'
M^CEJ[Y9*8DQ"]!0`?2PT,)9/QWJR`)^"28U54!$)+U[#J63^[D\JM3(F-P85
MY9L#,`^.%.%<E<TJ5S`VT[APD`E^K&V5E;LU!1RSXQ?<,*).;UC]76S#-Z;N
M]%V;;N]JM^42EO%NRJ7<7:M%M/7W*U:R#]2^5VQZ/<+WUU^O7AKEQ5V[<WG^
M_AFTZINDO@>M8O,=5=>(R1!:%&=PYS49W%FD=F?G#-X!RB(,[BPRN+,-@SL;
M:;`4K\MEO8(EQ8J?[E:A=XB\F&H3JB7]WFP!VRHY8&N_KJ;3"I9T+WZZ6YW?
M(?)BVD^HEDS`9@O8S@YDOK?P%24AY_N3*RO?[5(J7FPA120DYULEMUR,DI8>
MS64TE[HGD(#)&><^I20H@/A?RDR$3R?/L-@MAI;M4U=MC4!%]B-_'4&"!/H!
M3V,F7,L\V8W0[!#I>@&)T<1BL3GB[4S'M^GN3,::K(<_I14S^ZA8[G,.P_6Y
MVHA'5!Q<O4MJW+WH+LT'"E;,_Q;;U=U8S/2N:-KJ+85\&/)H_+*[2CXFHY+\
M46QGMVJ]YDBUKI-5[0>;:IEXI:.V?KO8;WT5FZ1QQ^*:^GLW]FA'"-?;(HTD
MMD2;(HW9C$U]?00U79@(^0AKJWUU"'%*1TYI+(Z)8M;'M;^EVDP*EJX`IN\!
MP=\>EWBWB6:/0KMO3036+]6IEE1G/@]B,ZZ%+2V`2F$_#/DBM#6(Z:2QRB:V
M1)J&I&\HK4&I@M<?@5)#>AXEK:W[PW;9+;K+[@_;Y3,HTX'>ECC3H%8CQ!!.
M(:K<T5DW[&7P<,3CRU'+2\#N#E[%P&^-[C.%/A++%U144VT$Z\6/I%'-(^%,
ML4<:HEGPYHTU&Y)@2ZJP"!`,]4X?"6N;Y]WL\RX^U]=!%PZ:90D#VQY:+JB8
MD$LW06F8/KI#%$'SDZ:'OHI%1X\P^N5/8,,B5Q7`517_(Y?ZM/2,FF7D)Z5@
M1.HT+`B]I*@S76BGL_4B`:/&[$60YL=6E*)T`[-A_!B>_-`0B2ZQ@U.4Q754
M0VYG#'W),'QA0:J]=\HJ-*0:ST@L.:MJ@J>AP0^QJE9;G.<+_]FIN%@]'7F%
M7N@S^&0\OH37CO9"NEV07NDI]86D"ZQBL['NP@Y<VQ,CFMX73]B9`SD:4,<,
M3TRID\L+MW9MJ<YITO$PFHI'R+P!=:D`V<B<Y>3LP^]?/YM+3Q/;!PF!4`1D
M;IG\I2IU0VF;)`9[@'7HAI-8$I6`ZG,XL9#FJRC&WEO:`@*QUO!@&/EC#`Y"
M6HU'QZ/:Y-SJD*ZR#=XX+ER'%".(ZI:AQS:+I!A3A.IP:WS_!8_>X0MLR#ZW
M?$LUE2W#)CI3_2M;OLNC=[.?Q'EFE#T%#Z2A>>[$!8&'MY99(UAJ=2LG$)'/
M]MILC\?7V)81U,JE]#G&Y<E]/EH]>4U3\=G`?:_ZQ^JHOY1+/'B,FSW3Y[1-
MOUD?!D"Z3+!WC1UVID44^Z]@+^AL;4W/)5-SJM@?Z*.0$?6]>8/1F.I:UB&<
M+03PSW+ICW4=R=+S,;$F1.6CT&<UDE/IR:`\3$FGM[0^\#48VH-':B1K-'ZV
MZYJ'HIT//Q6OP3NC3^@,K+]$GTB:*FMH4K;S$'36(.ALB*"3OX.DT[)Z&QW$
MDK[P$*,B7'A<++,5=%N=_/TD1?W5FVIOAJZ#Z'+)EY3[2CE1Y$K2Y865>>`S
MI8I2OM\PPE6L3/!GF2TB6:Z!QU?'\H;@6T*X?14U9S&IJEHIQ^GC4_I5^1?Z
M;XI3>+:4!50$5[-$RJ205<KQ\X:(9D]C$<I?Z,R7*B8!4++.:/$NZ=+N[_KV
M;71*#_FC[9VR*E@H<^Q*V7%U*Y?MX9DI"P(EM/GXP3%TF&1*A_7R)N,3&&Z"
MJ.7I337SW!^<@L_0M_:7;A^4<T]J@@N+Z-;,SZ/./W]^_OS\V?3G?[15UR$`
#&`$`
`
end


From xemacs-beta-request@cs.uiuc.edu  Thu Nov 14 19:45:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA08058 for xemacs-beta-people; Thu, 14 Nov 1996 19:45:33 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA08055 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 14 Nov 1996 19:45:32 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id TAA07309 for <xemacs-beta@cs.uiuc.edu>; Thu, 14 Nov 1996 19:45:31 -0600 (CST)
Received: (qmail 2453 invoked by uid 501); 15 Nov 1996 01:47:56 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: focus-follows-mouse patch
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 14 Nov 1996 17:47:55 -0800
Message-ID: <m2hgmst9h0.fsf@deanna.miranova.com>
Lines: 123
X-Mailer: Red Gnus v0.62/XEmacs 19.15

Thanks to some advice from Ben Wing I believe I've got the problem of
XEmacs trashing keyboard focus when the user is using
focus-follows-mouse mode nailed.

The following patch against 19.15beta2 provides a boolean variable
called `focus-follows-mouse'.  When this variable is nil, which I left
it by default, nothing changes.  When it is set to t, XEmacs will
refuse to throw keyboard focus on pop-to-buffer operations where the
destination buffer is another frame.  This shouldn't break ediff any
further.

This patch, along with Martin's patch already in beta2 satisfies the
objections I raised on this issue prior to the release of 19.14.

prim/buffer.el is dumped with XEmacs so bytecompile it before
redumping if you wish to try this out.

*** src/event-stream.c.orig	Sun Sep  8 16:46:29 1996
--- src/event-stream.c	Thu Nov 14 10:26:14 1996
***************
*** 74,79 ****
--- 74,82 ----
  /* Hook run when XEmacs is about to be idle. */
  Lisp_Object Qpre_idle_hook, Vpre_idle_hook;
  
+ /* Control gratuitous keyboard focus throwing. */
+ int focus_follows_mouse;
+ 
  #ifdef ILL_CONCEIVED_HOOK
  /* Hook run after a command if there's no more input soon.  */
  Lisp_Object Qpost_command_idle_hook, Vpost_command_idle_hook;
***************
*** 1636,1641 ****
--- 1639,1645 ----
  	 in emacs_handle_focus_change_final() is based on the _FOR_HOOKS
  	 value, we need to do so too. */
        if (!NILP (sel_frame) &&
+ 	  !focus_follows_mouse &&
  	  !EQ (DEVICE_FRAME_THAT_OUGHT_TO_HAVE_FOCUS (d), sel_frame) &&
  	  !NILP (DEVICE_FRAME_WITH_FOCUS_FOR_HOOKS (d)) &&
  	  !EQ (DEVICE_FRAME_WITH_FOCUS_FOR_HOOKS (d), sel_frame))
***************
*** 4157,4162 ****
--- 4161,4173 ----
  Errors running the hook are caught and ignored.
  */ );
    Vpre_idle_hook = Qnil;
+ 
+   DEFVAR_BOOL ("focus-follows-mouse", &focus_follows_mouse /*
+ Variable to control XEmacs behavior with respect to focus changing.
+ If this variable is set to t, then XEmacs will not gratuitously change
+ the keyboard focus.
+ */ );
+   focus_follows_mouse = 0;
  
  #ifdef ILL_CONCEIVED_HOOK
    /* Ill-conceived because it's not run in all sorts of cases


*** lisp/prim/buffer.el~	Sun Mar 31 16:22:25 1996
--- lisp/prim/buffer.el	Thu Nov 14 17:15:01 1996
***************
*** 65,76 ****
  If optional second arg NOT-THIS-WINDOW-P is non-nil, insist on finding
  another window even if BUFNAME is already visible in the selected window.
  If optional third arg is non-nil, it is the frame to pop to this
! buffer on."
    ;; #ifdef I18N3
    ;; #### Doc string should indicate that the buffer name will get
    ;; translated.
    ;; #endif
!   (let (buf window frame)
      (if (null bufname)
  	(setq buf (other-buffer (current-buffer)))
        (setq buf (get-buffer bufname))
--- 65,80 ----
  If optional second arg NOT-THIS-WINDOW-P is non-nil, insist on finding
  another window even if BUFNAME is already visible in the selected window.
  If optional third arg is non-nil, it is the frame to pop to this
! buffer on.
! If `focus-follows-mouse' is non-nil, keyboard focus is left unchanged."
    ;; #ifdef I18N3
    ;; #### Doc string should indicate that the buffer name will get
    ;; translated.
    ;; #endif
!   ;; This is twisted.  It is evil to throw the keyboard focus around
!   ;; willy-nilly if the user wants focus-follows-mouse.
!   (let ((oldbuf (current-buffer))
! 	buf window frame)
      (if (null bufname)
  	(setq buf (other-buffer (current-buffer)))
        (setq buf (get-buffer bufname))
***************
*** 83,91 ****
      (setq window (display-buffer buf not-this-window-p on-frame))
      (setq frame (window-frame window))
      ;; if the display-buffer hook decided to show this buffer in another
!     ;; frame, then select that frame.
!     (if (not (eq frame (selected-frame)))
  	(select-frame frame))
      (record-buffer buf)
!     (select-window window)
      buf))
--- 87,99 ----
      (setq window (display-buffer buf not-this-window-p on-frame))
      (setq frame (window-frame window))
      ;; if the display-buffer hook decided to show this buffer in another
!     ;; frame, then select that frame, (unless obeying focus-follows-mouse -sb).
!     (if (and (not focus-follows-mouse)
! 	     (not (eq frame (selected-frame))))
  	(select-frame frame))
      (record-buffer buf)
!     (if focus-follows-mouse
! 	(set-buffer oldbuf)
!       ;; select-window will modify the internal keyboard focus of XEmacs
!       (select-window window))
      buf))

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Thu Nov 14 23:17:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA08509 for xemacs-beta-people; Thu, 14 Nov 1996 23:17:27 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA08506 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 14 Nov 1996 23:17:26 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id XAA04295 for <xemacs-beta@xemacs.org>; Thu, 14 Nov 1996 23:17:23 -0600 (CST)
Received: from infodock.com ([206.13.40.192]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id VAA00512 for <xemacs-beta@xemacs.org>; Thu, 14 Nov 1996 21:16:53 -0800
Received: (from weiner@localhost) by infodock.com (8.8.0/8.7.3) id VAA01730; Thu, 14 Nov 1996 21:09:31 -0800
Date: Thu, 14 Nov 1996 21:09:31 -0800
From: Bob Weiner <weiner@infodock.com>
Message-Id: <199611150509.VAA01730@infodock.com>
To: muenkel@tnt.uni-hannover.de
CC: xemacs-beta@infodock.com
Subject: The following gives improved highlighting for your html mode.
Comments: Hyperbole mail buttons accepted, v04.02.

Please consider this new definition.  Note that the first
entry is simplified since I saw no point in matching to multiple
<tag> instances at once, nor did the change have any effect
in the HTML files I tested it on.  The second entry is my addtion for
tags that were not being highlighted and the 3rd and 4th remain the same.

(defvar hm--html-font-lock-keywords
  '(
    ("<!--.*-->\\|<[^>]*>" . font-lock-comment-face)
    ;; Highlight tags that have embedded strings
    ("\\(<[^> \t\n\r]*\\)[^>]*\\(>\\)"
     (1 font-lock-comment-face)
     (2 font-lock-comment-face))
    ("[Hh][Rr][Ee][Ff]=\"\\([^\"]*\\)\"" 1 font-lock-string-face t)
    ("[Ss][Rr][Cc]=\"\\([^\"]*\\)\"" 1 font-lock-string-face t))
  "Default expressions to highlight in the hm--html-mode.")


From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 02:02:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id CAA08851 for xemacs-beta-people; Fri, 15 Nov 1996 02:02:44 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id CAA08848 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 02:02:43 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id CAA16090 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 02:02:42 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA05735; Fri, 15 Nov 1996 00:01:38 -0800
Received: from etude.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id AAA25613; Fri, 15 Nov 1996 00:01:36 -0800
Received: by etude.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA26933; Fri, 15 Nov 1996 00:01:35 -0800
Date: Fri, 15 Nov 1996 00:01:35 -0800
Message-Id: <199611150801.AAA26933@etude.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: kifer@cs.sunysb.edu (Michael Kifer)
Cc: Marc Paquette <paquette@crim.ca>, xemacs-beta@cs.uiuc.edu
Subject: Re: A Toolbar for ediff in XEmacs 
In-Reply-To: <199611141809.NAA04384@atomas.crim.ca>
References: <199611122323.SAA01381@atomas.crim.ca>
	<199611130014.TAA17633@cs.sunysb.edu>
	<199611141809.NAA04384@atomas.crim.ca>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

Michael, if and when you feel that the version of ediff in XEmacs
should be upgraded to incorporate this patch, just let me or another
maintainer know.

Martin

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 14:00:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA14155 for xemacs-beta-people; Fri, 15 Nov 1996 14:00:33 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA14152 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 14:00:32 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id OAA07124 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 14:00:31 -0600 (CST)
Received: (qmail 6950 invoked by uid 501); 15 Nov 1996 20:03:01 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: [gnu.emacs.help,gnu.misc.discuss,comp.emacs] The C-h and delete controversy
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: multipart/mixed;
 boundary="Multipart_Fri_Nov_15_12:02:59_1996-1"
Content-Transfer-Encoding: 7bit
Date: 15 Nov 1996 12:02:59 -0800
Message-ID: <m2g22bktxo.fsf@deanna.miranova.com>
Lines: 67
X-Mailer: Red Gnus v0.62/XEmacs 19.15

--Multipart_Fri_Nov_15_12:02:59_1996-1
Content-Type: text/plain; charset=US-ASCII

I like option (3), and it appears to work fine.  Comments?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

--Multipart_Fri_Nov_15_12:02:59_1996-1
Content-Type: message/rfc822

Path: news.callamer.com!news1.crl.com!nexp.crl.com!nntp.crl.com!howland.erols.net!www.nntp.primenet.com!nntp.primenet.com!nntp.uio.no!ifi.uio.no!usenet
From: Erik Naggum <nobody@naggum.no>
Newsgroups: gnu.emacs.help,gnu.misc.discuss,comp.emacs
Subject: The C-h and delete controversy
Followup-To: gnu.emacs.help
Date: 14 Nov 1996 13:17:53 +0000
Organization: Naggum Software; +47 2295 0313; http://www.naggum.no
Lines: 37
Message-ID: <3056966273886559_-_@naggum.no>
Reply-To: emacs@naggum.no
NNTP-Posting-Host: naggum.no
X-Newsreader: Gnus v5.3/Emacs 19.34
Xref: news.callamer.com gnu.emacs.help:18437 gnu.misc.discuss:13063 comp.emacs:11480

there are a few ways to handle the backspace/delete problem, each with
their own set of problems.

(1) swap backspace and delete at the keyboard level (in Emacs):

    (keyboard-translate ?\C-h ?\C-?)
    (keyboard-translate ?\C-? ?\C-h)

however, this means that a number of keybindings that use C-h in
combination with other things randomly fail.  e.g. M-C-h runs mark-defun,
but ESC C-h runs backward-kill-word.  it is also far from obvious how to
use the help key in this setting.  the <help> key and <F1> needs to be
mentioned in a prominent place, because if the user can't type <delete> to
delete a character, in all likelihood, he can't type <delete> to get help,
either.  (using <delete> to get help is counter-intuitive in the extreme.)

(2) keep C-h as the help-char, but bind help-command to something else,
and bind C-h in global-map to the same as delete.

    (define-key ctl-x-map "?" 'help-command)
    (define-key global-map "\C-h" (lookup-key global-map "\C-?"))

since ? works as <help> in help-command, this might actually work well.

(3) like (2), but set help-char to the question mark (?), and hope the
usual functions would handle it right:

    (define-key ctl-x-map "?" 'help-command)
    (define-key global-map "\C-h" (lookup-key global-map "\C-?"))
    (setq help-char ??)

could people try this and report to <emacs@naggum.no>?  (followups are
directed to gnu.emacs.help.)

#\Erik
-- 
Please address private replies to "erik".  Mail to "nobody" is discarded.

--Multipart_Fri_Nov_15_12:02:59_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 16:45:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA14597 for xemacs-beta-people; Fri, 15 Nov 1996 16:45:33 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA14594 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 16:45:32 -0600 (CST)
Received: from hp.com (hp.com [15.255.152.4]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA11214 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 16:45:31 -0600 (CST)
From: BRAD_LINDSEY@HP-FtCollins-om4.om.hp.com
Received: from csitcom4.fc.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA079407896; Fri, 15 Nov 1996 14:44:56 -0800
Received: from  by csitcom4.fc.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.4 Openmail) id AA210247895; Fri, 15 Nov 1996 15:44:55 -0700
X-Openmail-Hops: 1
Date: Fri, 15 Nov 96 15:44:25 -0700
Message-Id: <H0000e1505838906@MHS>
Subject: How to reach Chuck Thompson at XEmacs
To: xemacs-beta@cs.uiuc.edu
Cc: HARDING_LAURA/HP-FtCollins_unix1@csitcom4.fc.hp.com

Item Subject: cc:Mail Text
     Greetings:
     
     I was hoping someone on this list could give me a phone number for Chuck 
     Thompson (or someone else) at XEmacs.  I need to discuss including XEmacs 
     in a product, but have been unable to reach Chuck via e-mail.
     
     Any help anyone can give would be greatly appreciated.
     
     Thanks,
     Brad Lindsey
     (970) 229-6073
     blindsey@fc.hp.com

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 17:49:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id RAA14835 for xemacs-beta-people; Fri, 15 Nov 1996 17:49:54 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA14832 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 17:49:53 -0600 (CST)
Received: from sweden.aosi.com (mail.aosi.com [206.98.255.22]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id RAA06263 for <xemacs-beta@xemacs.org>; Fri, 15 Nov 1996 17:49:50 -0600 (CST)
Received: from hlork ([206.98.254.50]) by sweden.aosi.com
          (post.office MTA v1.9.3b ID# 0-16356) with SMTP id AAA135;
          Fri, 15 Nov 1996 18:49:49 -0500
Sender: root@.aosi.com
Message-ID: <328D0481.3B351894@aosi.com>
Date: Fri, 15 Nov 1996 19:02:10 -0500
From: Joel Peterson <tarzan@aosi.com>
Organization: Me Tarzan, you Jane?
X-Mailer: Mozilla 3.0 (X11; U; Linux 1.3.97 i586)
MIME-Version: 1.0
To: Bob Weiner <weiner@infodock.com>, xemacs-beta@xemacs.org
Subject: Re: `frame in a glyph'
References: <199611130558.VAA20443@infodock.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Weiner wrote:
> 
> I just rejoined the xemacs-beta list, so I am unfamiliar with your glyph
> frames work.  What applications do you forsee or personally plan for them?
> What would anyone use them for at this point, i.e. what advantages do they
> give you over windows (overlapping perhaps?)?
> 
> Thanks,
> 
> Bob

The main purpose is to take advantage of emacs' encapsulation of objects
at the buffer level.  This has two immediate applications for me.  One
application is to encapsulate objects into text.  The other application
is in dialog boxes to serve as widgets.

I am currently working on providing `pretty' and functional dialog
boxes.  A one line high glyph frame will make a very powerful string
widget; a multi line glyph frame will be a very powerful text box widget
(especially when scrollbars are added).  I am adding code to allow
drawing a recessed 3-D border around glyphs.  Granted, there is more
overhead from implementing widgets using entire emacs frames rather than
just implementing the widgets directly.  However, there are two major
benefits from doing it the way that I did.  The most important is that
what you get within the `widget' is emacs and will always have all the
functionality and configurability of emacs; even when new features are
added to emacs.  The second benefit is that the `widget' is reusable for
other things.  There's not much that can be done with a string widget
other than using it as a string widget.

I wrote a huge amount of very hoary lisp code to manage a draggable
spreadsheet table embedded within an emacs buffer.  The user can click
on the `title bar' of the table and drag it to another location within
the text.  Using a "frame in a glyph", the entire table can be
encapsulated within another emacs buffer and the problem of moving it is
reduced to the problem of moving an annotation glyph.  This is much
simpler than moving a collection of text and extents (one for the entire
object, one for the table part, and one for each cell in the table) and
I get the benefit of being able to use buffer local variables to hold
information which is much more convenient that storing properties into
an extent.  I also have much more control over user interface
considerations when the table is active for input, and I don't have to
worry about it being clobbered by an editing change made from the
surrounding text.  At any point, I can replace the table with some other
object (say a picture), and the code for manipulating the object as a
whole continues to work with no changes.

Looking to the future, XEmacs will one day (I hope) be capable of
wrapping multiple lines of text around tall pixmaps and will offer other
`word processing' features.  The frame in a glyph is one of those word
processing features, similar in concept to a frame in Microsoft Word or
a desktop publishing package.

I should be able to distribute the dialog box code (or at least an
approximation of it).  The spreadsheet in emacs code is unlikely to ever
make it outside the walls of Dow Jones (where I work).  It's too bad,
because it's nice work, and UNIX could use a good, freely available
spreadsheet.  If I get time, I'll redo it at home.

That covers what I have personally planned for them.  I think the big
advantage of a glyph frame in general is that it is positioned relative
to a buffer position and may be fully or partially visible depending on
whether that buffer position is visible.  The same glyph frame can even
be visible in multiple emacs windows and be placed in multiple spots
within a buffer or across buffers.

The limitation on glyph frames is that their image is a specifier; and a
lot of redisplay code depends on knowing which emacs frame they are
displayed within.  This makes it difficult to display the same glyph
frame within multiple other frames.  The nature of the implementation of
the glyph frame is that a particular glyph frame cannot be
simultaneously displayed on two consoles of different type (this does
not prevent two glyph frames which just happen to display the same thing
from appearing on two different consoles).  Anything else should be
possible.

I hope this made sense :-).  I have a big deadline to meet at work that
requires these features, so there's been a whirlwind of implementing it,
and I'm not sure that I even understand fully what it's good for, and
where it needs to improve to get there.

I'm posting this response to the XEmacs list as well as sending it to
you, because I think it's important information that I somehow left out
of my original postings.

p.s. I do *not* speak for Dow Jones and Company, Inc.

-- 
And on the Eighth day, the Lord said "Let there be Advertisements."
And lo, there were advertisements.  And the Lord saw the
advertisements.  And the Lord went to the kitchen for a snack.
                - Joel Peterson
                       Supreme Deputy of scratching Dogbert behind the
                       ears until he has little leg spasms.

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 19:09:37 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA15037 for xemacs-beta-people; Fri, 15 Nov 1996 19:09:37 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA15034 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 19:09:33 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA06383 for <xemacs-beta@xemacs.org>; Fri, 15 Nov 1996 19:09:19 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id CAA07903; Sat, 16 Nov 1996 02:08:55 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: [Linus Torvalds <torvalds@cs.Helsinki.FI>] Re: Evil Sin: Who did this to me? Why?
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 02:08:53 +0100
Message-ID: <kigu3qqluca.fsf@jagor.srce.hr>
Lines: 45
X-Mailer: Red Gnus v0.61/XEmacs 19.14

I have mailed Linus that XEmacs 19.15 will probably have better
support for backspace-vs-C-h braindamage (I love that word, especially
on Erik:), refering to a Steve's message.  He answered with the
following mail (which he permitted me to redistribute) that contains
interesting propositions.

I like the part about copying the termios (or its relevant parts,
since it's system dependent) to Lisp.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"What is the sound of Perl?  Is it not the sound of a wall that
people have stopped banging their heads against?" -- Larry Wall
------- Start of forwarded message -------
Date: Sat, 16 Nov 1996 02:44:36 +0200 (EET)
From: Linus Torvalds <torvalds@cs.Helsinki.FI>
To: Hrvoje Niksic <hniksic@srce.hr>
Subject: Re: Evil Sin: Who did this to me? Why?
Message-ID: <Pine.LNX.3.95.961116024130.16670B-100000@linux.cs.Helsinki.FI>



On 16 Nov 1996, Hrvoje Niksic wrote:
> 
> Not all Emacs developers share Erik's view on this issue.  The next
> version of XEmacs will probably include a feature similar to what you
> proposed.

Good. I have this feeling Xemacs people are more willing to add helpful
features, and hopefully the other emacs will follow suit.

Note that while my example code sequence was in C, there is no reason it
should be C (other than the fact that I personally never use LISP so I
couldn't make a good example in LISP ;). Instead of using C, it might be
possible to just "export" the termios structure to the LISP layer, and
have the startup LISP stuff do the key bindings. I assume that some emacs
people would like that approach better..

(As long as it's the _startup_ LISP code that gets executed by default, so
that clueless newbies don't even have to know about it ;) 

		Linus

------- End of forwarded message -------

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 19:14:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA15058 for xemacs-beta-people; Fri, 15 Nov 1996 19:14:52 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA15055 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 19:14:51 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id TAA14498 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 19:14:50 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA00063; Fri, 15 Nov 1996 17:14:18 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA17813; Fri, 15 Nov 1996 17:14:15 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA05294; Fri, 15 Nov 1996 17:14:16 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA29939; Fri, 15 Nov 1996 17:14:13 -0800
Date: Fri, 15 Nov 1996 17:14:13 -0800
Message-Id: <199611160114.RAA29939@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu, Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Subject: [gnu.emacs.help,gnu.misc.discuss,comp.emacs] The C-h and delete controversy
In-Reply-To: <m2g22bktxo.fsf@deanna.miranova.com>
References: <m2g22bktxo.fsf@deanna.miranova.com>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

Steven> [1  <text/plain; US-ASCII (7bit)>]
Steven> I like option (3), and it appears to work fine.  Comments?

This is one of the biggest usability impediments to the acceptance of
XEmacs, and we finally have some kind of consensus that typing the
Backspace key in tty mode should never invoke help.  I completely
agree with Lars on this.  I would go further and suggest (as default):

- if the user hits Backspace, delete the previous character
- if the user hits Delete, delete the next character
(i.e. make delbackspace.el the default)

I'm rather surprised Erik offered to implement this.

Why do we have to have a help-char? Why not multiple such beasts?
Why doesn't f1 f1 give you more help, the way that C-h does?

Most tty keyboards these days do have an f1 key, as most tty's are
really PC's emulating a tty, and those all have f1 keys.
Unfortunately, you can't trust the terminal definition to really be
correct.

Martin

Steven> [2  <message/rfc822>]

Erik> [2.1 The C-h and delete controversy <nil>]
Erik> From: Erik Naggum <nobody@naggum.no>
Erik> Subject: The C-h and delete controversy
Erik> Date: 14 Nov 1996 13:17:53 +0000

Erik> there are a few ways to handle the backspace/delete problem, each with
Erik> their own set of problems.

Erik> (1) swap backspace and delete at the keyboard level (in Emacs):

Erik>     (keyboard-translate ?\C-h ?\C-?)
Erik>     (keyboard-translate ?\C-? ?\C-h)

Erik> however, this means that a number of keybindings that use C-h in
Erik> combination with other things randomly fail.  e.g. M-C-h runs mark-defun,
Erik> but ESC C-h runs backward-kill-word.  it is also far from obvious how to
Erik> use the help key in this setting.  the <help> key and <F1> needs to be
Erik> mentioned in a prominent place, because if the user can't type <delete> to
Erik> delete a character, in all likelihood, he can't type <delete> to get help,
Erik> either.  (using <delete> to get help is counter-intuitive in the extreme.)

Erik> (2) keep C-h as the help-char, but bind help-command to something else,
Erik> and bind C-h in global-map to the same as delete.

Erik>     (define-key ctl-x-map "?" 'help-command)
Erik>     (define-key global-map "\C-h" (lookup-key global-map "\C-?"))

Erik> since ? works as <help> in help-command, this might actually work well.

Erik> (3) like (2), but set help-char to the question mark (?), and hope the
Erik> usual functions would handle it right:

Erik>     (define-key ctl-x-map "?" 'help-command)
Erik>     (define-key global-map "\C-h" (lookup-key global-map "\C-?"))
Erik>     (setq help-char ??)

Erik> could people try this and report to <emacs@naggum.no>?  (followups are
Erik> directed to gnu.emacs.help.)

Erik> #\Erik
Erik> -- 
Erik> Please address private replies to "erik".  Mail to "nobody" is discarded.

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 19:11:38 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA15045 for xemacs-beta-people; Fri, 15 Nov 1996 19:11:38 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA15042 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 19:11:37 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA06392 for <xemacs-beta@xemacs.org>; Fri, 15 Nov 1996 19:11:27 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id CAA08132; Sat, 16 Nov 1996 02:11:15 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: A BS-based bug
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 02:11:15 +0100
Message-ID: <kigsp6alu8c.fsf@jagor.srce.hr>
Lines: 14
X-Mailer: Red Gnus v0.61/XEmacs 19.14

I have noticed a strange bug in C mode, with BS (backspace) key on X
consoles that have it (e.g. Sun console).  It is that BS works fine
for itself, but when I press `M-BS', I get mark-defun.  Pressing `C-h
c M-BS' yields in something like
M-BS runs the command mark-defun

Note that the problem exists *only* in C mode.  Other modes handle it
fine (M-BS runs backward-kill-word, as it should) on the very same
keyboard.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Good pings come in small packets.

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 19:45:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA15170 for xemacs-beta-people; Fri, 15 Nov 1996 19:45:44 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA15167 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 19:45:43 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA16718 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 19:45:34 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id CAA10295; Sat, 16 Nov 1996 02:44:42 +0100 (MET)
Sender: hniksic@public.srce.hr
To: Martin Buchholz <mrb@Eng.Sun.COM>
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu,
        Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Subject: Re: [gnu.emacs.help,gnu.misc.discuss,comp.emacs] The C-h and delete controversy
References: <m2g22bktxo.fsf@deanna.miranova.com> <199611160114.RAA29939@xemacs.eng.sun.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 02:44:42 +0100
In-Reply-To: Martin Buchholz's message of Fri, 15 Nov 1996 17:14:13 -0800
Message-ID: <kigloc2byph.fsf@jagor.srce.hr>
Lines: 18
X-Mailer: Red Gnus v0.62/XEmacs 19.14

Martin Buchholz (mrb@eng.sun.com) wrote:
> agree with Lars on this.  I would go further and suggest (as default):
> 
> - if the user hits Backspace, delete the previous character
> - if the user hits Delete, delete the next character
> (i.e. make delbackspace.el the default)

*Please* don't do it to me.  It would kill many many settings.  My DEC
keyboard happily sends DEL, and I don't want it to delete next
character.

Too many things depend on backspace and delete to invoke delbackspace
by default.  tty-s are another matter, of course.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm a Lisp variable -- bind me!

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 20:31:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA15285 for xemacs-beta-people; Fri, 15 Nov 1996 20:31:42 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA15282 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 20:31:41 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA21481 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 20:31:40 -0600 (CST)
Received: (qmail 13155 invoked by uid 501); 16 Nov 1996 02:34:11 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: [gnu.emacs.help,gnu.misc.discuss,comp.emacs] The C-h and delete controversy
References: <m2g22bktxo.fsf@deanna.miranova.com> <199611160114.RAA29939@xemacs.eng.sun.com> <kigloc2byph.fsf@jagor.srce.hr>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Hrvoje Niksic's message of 16 Nov 1996 02:44:42 +0100
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 15 Nov 1996 18:34:09 -0800
Message-ID: <m2loc2ix9a.fsf@deanna.miranova.com>
Lines: 37
X-Mailer: Red Gnus v0.62/XEmacs 19.15

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Martin Buchholz (mrb@eng.sun.com) wrote:

Martin> agree with Lars on this.  I would go further and suggest (as
Martin> default):

How did Lars get dragged into this, or did I miss something?

Martin> - if the user hits Backspace, delete the previous character
Martin> - if the user hits Delete, delete the next character
Martin> (i.e. make delbackspace.el the default)

Hrv> *Please* don't do it to me.  It would kill many many settings.
Hrv> My DEC keyboard happily sends DEL, and I don't want it to delete
Hrv> next character.

I have to agree with Hrvoje.  IMO the Motif bindings stink^H^H^H^H^H
are suboptimal.  I like the way zsh (and Erik's proposal) bypasses the
issue by making them both do the same Right Thing.

Hrv> Too many things depend on backspace and delete to invoke
Hrv> delbackspace by default.  tty-s are another matter, of course.

It's also a minimalist approach in that the only real binding affected
is C-h for help.

Linus is right too, if a luser has bound the tty erase key to
something else it ought to override XEmacs' usual definition of the
key.  Though in that event it would be appropriate to print a message
on start up to the effect that the Delete key has been set in a
fashion that may conflict with normal usage of the editor.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 20:54:16 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA15327 for xemacs-beta-people; Fri, 15 Nov 1996 20:54:16 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA15324 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 20:54:15 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA21715 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 20:54:14 -0600 (CST)
Received: (qmail 13410 invoked by uid 501); 16 Nov 1996 02:56:44 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: `frame in a glyph'
References: <199611130558.VAA20443@infodock.com> <328D0481.3B351894@aosi.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Joel Peterson's message of Fri, 15 Nov 1996 19:02:10 -0500
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 15 Nov 1996 18:56:43 -0800
Message-ID: <m2iv76iw7o.fsf@deanna.miranova.com>
Lines: 50
X-Mailer: Red Gnus v0.62/XEmacs 19.15

Thanks for the additional explanation Joel.

>>>>> "Joel" == Joel Peterson <tarzan@aosi.com> writes:

Joel> I wrote a huge amount of very hoary lisp code to manage a
Joel> draggable spreadsheet table embedded within an emacs buffer.
Joel> The user can click on the `title bar' of the table and drag it
Joel> to another location within the text.

You've implemented drag & drop within XEmacs? :-) Please say that part
of the code is available.  If we had drag & drop there are all sorts
of cool things we could do.  I have visions of the day I'll be able to
select a bunch of messages in Gnus by mouse and drag them into a
wastebasket icon.

 ...

Joel> Looking to the future, XEmacs will one day (I hope) be capable
Joel> of wrapping multiple lines of text around tall pixmaps and will
Joel> offer other `word processing' features.  The frame in a glyph is
Joel> one of those word processing features, similar in concept to a
Joel> frame in Microsoft Word or a desktop publishing package.

O.K.  We do need (IMO) to get some good word processing facilities
going with XEmacs.

Joel> I should be able to distribute the dialog box code (or at least
Joel> an approximation of it).  The spreadsheet in emacs code is
Joel> unlikely to ever make it outside the walls of Dow Jones (where I
Joel> work).  It's too bad, because it's nice work, and UNIX could use
Joel> a good, freely available spreadsheet.  If I get time, I'll redo
Joel> it at home.

Please do.  All we appear to have is DISMAL now, and it's pretty
dismal not having any Emacs 19 display bells & whistles.

 ...

The current planning on future versions of XEmacs has XEmacs 19.15
being the last of the v19's so we can drop the dual code bases as
soon as we can.  For this reason, it is not a good idea to introduce
destabilizing patches into it.  I would like to see this patch get
into the v20 baseline when feasible, since it sounds very much like A
Good Thing.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 21:20:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id VAA15425 for xemacs-beta-people; Fri, 15 Nov 1996 21:20:42 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id VAA15422 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 21:20:41 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id VAA22043 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 21:20:37 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id EAA16939; Sat, 16 Nov 1996 04:20:30 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@cs.uiuc.edu
Subject: Re: `frame in a glyph'
References: <199611130558.VAA20443@infodock.com> <328D0481.3B351894@aosi.com> <m2iv76iw7o.fsf@deanna.miranova.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 04:20:29 +0100
In-Reply-To: Steven L Baur's message of 15 Nov 1996 18:56:43 -0800
Message-ID: <kigiv76bu9u.fsf@jagor.srce.hr>
Lines: 12
X-Mailer: Red Gnus v0.62/XEmacs 19.14

Steven L. Baur (steve@miranova.com) wrote:
> The current planning on future versions of XEmacs has XEmacs 19.15
> being the last of the v19's so we can drop the dual code bases as
> soon as we can.  For this reason, it is not a good idea to introduce

Is 20.0 stable enough for this decision?  You are, of course, aware
that this would mean actually releasing 20.0 instead of 19.16.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm sure they'll listen to reason! -- Neal Stevenson, _Snow Crash_

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 21:41:22 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id VAA15485 for xemacs-beta-people; Fri, 15 Nov 1996 21:41:22 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id VAA15482 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 21:41:21 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id VAA22352 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 21:41:20 -0600 (CST)
Received: (qmail 13912 invoked by uid 501); 16 Nov 1996 03:43:51 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: focus-follows-mouse patch
References: <m2hgmst9h0.fsf@deanna.miranova.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Steven L Baur's message of 14 Nov 1996 17:47:55 -0800
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 15 Nov 1996 19:43:50 -0800
Message-ID: <m2g22aiu15.fsf@deanna.miranova.com>
Lines: 29
X-Mailer: Red Gnus v0.62/XEmacs 19.15

This patch needs a followup patch:

*** lisp/prim/buffer.el.1	Thu Nov 14 17:15:01 1996
--- lisp/prim/buffer.el	Fri Nov 15 19:26:30 1996
***************
*** 92,98 ****
  	     (not (eq frame (selected-frame))))
  	(select-frame frame))
      (record-buffer buf)
!     (if focus-follows-mouse
  	(set-buffer oldbuf)
        ;; select-window will modify the internal keyboard focus of XEmacs
        (select-window window))
--- 92,100 ----
  	     (not (eq frame (selected-frame))))
  	(select-frame frame))
      (record-buffer buf)
!     (if (and focus-follows-mouse
! 	     on-frame
! 	     (not (eq on-frame (selected-frame))))
  	(set-buffer oldbuf)
        ;; select-window will modify the internal keyboard focus of XEmacs
        (select-window window))

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 23:35:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA15732 for xemacs-beta-people; Fri, 15 Nov 1996 23:35:32 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA15729 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 23:35:31 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id XAA23856 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 23:35:30 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA08802 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 21:34:59 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id VAA02837; Fri, 15 Nov 1996 21:34:56 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA08365; Fri, 15 Nov 1996 21:34:57 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA03705; Fri, 15 Nov 1996 21:34:53 -0800
Date: Fri, 15 Nov 1996 21:34:53 -0800
Message-Id: <199611160534.VAA03705@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: `frame in a glyph'
In-Reply-To: <kigiv76bu9u.fsf@jagor.srce.hr>
References: <199611130558.VAA20443@infodock.com>
	<328D0481.3B351894@aosi.com>
	<m2iv76iw7o.fsf@deanna.miranova.com>
	<kigiv76bu9u.fsf@jagor.srce.hr>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Steven L. Baur (steve@miranova.com) wrote:
>> The current planning on future versions of XEmacs has XEmacs 19.15
>> being the last of the v19's so we can drop the dual code bases as
>> soon as we can.  For this reason, it is not a good idea to introduce

Hrv> Is 20.0 stable enough for this decision?  You are, of course, aware
Hrv> that this would mean actually releasing 20.0 instead of 19.16.

YES!

If necessary, we can always add the 5 most serious patches to 19.15 to
create 19.16, the same way Linus creates 1.2.7 while the development
version is a mildly broken 1.3.55.

When building 20.0 without Mule support, there is only one thing known
to be broken relative to 19.15, caesar-rotate, and even that will
likely be fixed in forthcoming gnus.  The Mule support itself can be
infinitely improved, but I use it daily without any stability
problems.

If we have a major incompatible release after 20.0 (the canonical
example is lexical scoping) we'll just make a 21.0.

Martin



From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 23:44:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA15773 for xemacs-beta-people; Fri, 15 Nov 1996 23:44:03 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA15770 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 15 Nov 1996 23:44:02 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA24908 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 23:43:56 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id GAA23792; Sat, 16 Nov 1996 06:43:30 +0100 (MET)
Sender: hniksic@public.srce.hr
To: Martin Buchholz <mrb@Eng.Sun.COM>
Cc: Hrvoje Niksic <hniksic@srce.hr>, xemacs-beta@cs.uiuc.edu
Subject: Re: `frame in a glyph'
References: <199611130558.VAA20443@infodock.com> 	<328D0481.3B351894@aosi.com> 	<m2iv76iw7o.fsf@deanna.miranova.com> 	<kigiv76bu9u.fsf@jagor.srce.hr> <199611160534.VAA03705@xemacs.eng.sun.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 06:43:29 +0100
In-Reply-To: Martin Buchholz's message of Fri, 15 Nov 1996 21:34:53 -0800
Message-ID: <kigd8xebnni.fsf@jagor.srce.hr>
Lines: 40
X-Mailer: Red Gnus v0.62/XEmacs 19.14

Martin Buchholz (mrb@eng.sun.com) wrote:
> Hrv> Is 20.0 stable enough for this decision?  You are, of course, aware
> Hrv> that this would mean actually releasing 20.0 instead of 19.16.
> 
> YES!

Great!  It means we'll have one source tree to maintain.  Won't that
be fun? ;-)

> When building 20.0 without Mule support, there is only one thing known
> to be broken relative to 19.15, caesar-rotate, and even that will
> likely be fixed in forthcoming gnus.  The Mule support itself can be
> infinitely improved, but I use it daily without any stability
> problems.

So, I compile 20.0 without Mule, and that's it -- I'm definitely
beginning to like the idea of releasing 20.0.  If nothing, we can ask
Erik to upgrade. :-)

> If we have a major incompatible release after 20.0 (the canonical
> example is lexical scoping) we'll just make a 21.0.

And multithreaded XEmacs will be 22.0.  That settles it. :-)

Speaking of currently unimplemented features, what happened to
multiple frames on tty-s?  I think it is quite a useful feature, and
it should not be too hard to implement (for someone acquainted with
XEmacs internals).  GNU Emacs has it, and I think we should have it
too -- it should have been in 19.14.

Another thing -- what about make-indirect-buffer?  The documentation
claims it exists, and when I try to use it, it says
"make-indirect-buffer not yet implemented, oops", which I find quite
obnoxious. :( The function should either be there, or not.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
* Q: What is an experienced Emacs user?
* A: A person who wishes that the terminal had pedals.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 00:09:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA15878 for xemacs-beta-people; Sat, 16 Nov 1996 00:09:57 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA15875 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 00:09:56 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id AAA25917 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 00:09:56 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA10028 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 22:09:25 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA03769; Fri, 15 Nov 1996 22:09:22 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA08497; Fri, 15 Nov 1996 22:09:22 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA03936; Fri, 15 Nov 1996 22:09:17 -0800
Date: Fri, 15 Nov 1996 22:09:17 -0800
Message-Id: <199611160609.WAA03936@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: `frame in a glyph'
In-Reply-To: <kigd8xebnni.fsf@jagor.srce.hr>
References: <199611130558.VAA20443@infodock.com>
	<328D0481.3B351894@aosi.com>
	<m2iv76iw7o.fsf@deanna.miranova.com>
	<kigiv76bu9u.fsf@jagor.srce.hr>
	<199611160534.VAA03705@xemacs.eng.sun.com>
	<kigd8xebnni.fsf@jagor.srce.hr>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> So, I compile 20.0 without Mule, and that's it -- I'm definitely
Hrv> beginning to like the idea of releasing 20.0.  If nothing, we can ask
Hrv> Erik to upgrade. :-)

I'm sure with a name and email address like yours, you'll want to
build --with-mule so that you can read Hrvatski with XEmacs.

Hrv> And multithreaded XEmacs will be 22.0.  That settles it. :-)

Did you just volunteer to implement this??

Hrv> Speaking of currently unimplemented features, what happened to
Hrv> multiple frames on tty-s?  I think it is quite a useful feature, and
Hrv> it should not be too hard to implement (for someone acquainted with
Hrv> XEmacs internals).  GNU Emacs has it, and I think we should have it
Hrv> too -- it should have been in 19.14.

Hrv> Another thing -- what about make-indirect-buffer?  The documentation
Hrv> claims it exists, and when I try to use it, it says
Hrv> "make-indirect-buffer not yet implemented, oops", which I find quite
Hrv> obnoxious. :( The function should either be there, or not.

There's no shortage of fun features for folks like you to implement :-)

As for myself, I'm volunteering to do some of the dull infrastructure
work like upgrading to autoconf 2.

Martin

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 00:16:23 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA15899 for xemacs-beta-people; Sat, 16 Nov 1996 00:16:23 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA15896 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 00:16:22 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA25959 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 00:16:21 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id HAA25402; Sat, 16 Nov 1996 07:16:13 +0100 (MET)
Sender: hniksic@public.srce.hr
To: Martin Buchholz <mrb@Eng.Sun.COM>
Cc: Hrvoje Niksic <hniksic@srce.hr>, xemacs-beta@cs.uiuc.edu
Subject: Re: `frame in a glyph'
References: <199611130558.VAA20443@infodock.com> 	<328D0481.3B351894@aosi.com> 	<m2iv76iw7o.fsf@deanna.miranova.com> 	<kigiv76bu9u.fsf@jagor.srce.hr> 	<199611160534.VAA03705@xemacs.eng.sun.com> 	<kigd8xebnni.fsf@jagor.srce.hr> <199611160609.WAA03936@xemacs.eng.sun.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 07:16:13 +0100
In-Reply-To: Martin Buchholz's message of Fri, 15 Nov 1996 22:09:17 -0800
Message-ID: <kig9182bm4y.fsf@jagor.srce.hr>
Lines: 46
X-Mailer: Red Gnus v0.62/XEmacs 19.14

Martin Buchholz (mrb@eng.sun.com) wrote:
> I'm sure with a name and email address like yours, you'll want to
> build --with-mule so that you can read Hrvatski with XEmacs.

Why?  I can read Croatian by specifying an iso-8859-2 font.  Or, do
you mean that there is something else I could get with Mule-ized
XEmacs?

> Hrv> And multithreaded XEmacs will be 22.0.  That settles it. :-)
> Did you just volunteer to implement this??

Unfortunately not.  I still have a lot to learn about XEmacs
internals.  And about multithreading, too. :-)

> Hrv> Speaking of currently unimplemented features, what happened to
> Hrv> multiple frames on tty-s?  I think it is quite a useful feature, and
> Hrv> it should not be too hard to implement (for someone acquainted with
> Hrv> XEmacs internals).  GNU Emacs has it, and I think we should have it
> Hrv> too -- it should have been in 19.14.
> 
> Hrv> Another thing -- what about make-indirect-buffer?  The documentation
> Hrv> claims it exists, and when I try to use it, it says
> Hrv> "make-indirect-buffer not yet implemented, oops", which I find quite
> Hrv> obnoxious. :( The function should either be there, or not.
> 
> There's no shortage of fun features for folks like you to implement
> :-)

I doubt I can do much about make-indirect-buffer, short of finding a
way to disable it completely.  As for multiple frames on tty-s, I'll
try to have a look at this in the future.

How similar is GNU Emacs code for handling this?  I don't think they
have the console stuff, etc. -- it will probably have to be written
from scratch, although that doesn't *sound* complex.

> As for myself, I'm volunteering to do some of the dull infrastructure
> work like upgrading to autoconf 2.

Yup, it would be quite nice.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 00:20:10 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA15907 for xemacs-beta-people; Sat, 16 Nov 1996 00:20:10 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA15904 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 00:20:09 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id AAA25982 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 00:20:09 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA10282; Fri, 15 Nov 1996 22:18:36 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA03951; Fri, 15 Nov 1996 22:18:33 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA08538; Fri, 15 Nov 1996 22:18:34 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA03961; Fri, 15 Nov 1996 22:18:29 -0800
Date: Fri, 15 Nov 1996 22:18:29 -0800
Message-Id: <199611160618.WAA03961@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu,
        Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Subject: Re: [gnu.emacs.help,gnu.misc.discuss,comp.emacs] The C-h and delete controversy
In-Reply-To: <kigloc2byph.fsf@jagor.srce.hr>
References: <m2g22bktxo.fsf@deanna.miranova.com>
	<199611160114.RAA29939@xemacs.eng.sun.com>
	<kigloc2byph.fsf@jagor.srce.hr>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Martin Buchholz (mrb@eng.sun.com) wrote:
>> agree with Lars on this.  I would go further and suggest (as default):
>> 
>> - if the user hits Backspace, delete the previous character
>> - if the user hits Delete, delete the next character
>> (i.e. make delbackspace.el the default)

Hrv> *Please* don't do it to me.  It would kill many many settings.  My DEC
Hrv> keyboard happily sends DEL, and I don't want it to delete next
Hrv> character.

I'm not quite sure what you mean by that.  In X you presumably have
keys labelled Backspace and Delete.  So you want them both to delete backwards?

Hrv> Too many things depend on backspace and delete to invoke delbackspace
Hrv> by default.  tty-s are another matter, of course.

There's no doubt that this will be a painful transition, and whoever
does it must don the asbestos suit first.

Martin

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 00:28:06 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA15946 for xemacs-beta-people; Sat, 16 Nov 1996 00:28:06 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA15943 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 00:28:05 -0600 (CST)
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id AAA26052 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 00:28:05 -0600 (CST)
Received: (qmail 14233 invoked by uid 52477); 16 Nov 1996 06:28:04 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Subject: Re: `frame in a glyph'
References: <199611130558.VAA20443@infodock.com> 	<328D0481.3B351894@aosi.com> 	<m2iv76iw7o.fsf@deanna.miranova.com> 	<kigiv76bu9u.fsf@jagor.srce.hr> <199611160534.VAA03705@xemacs.eng.sun.com> <kigd8xebnni.fsf@jagor.srce.hr>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sudish@mindspring.com>
Date: 16 Nov 1996 01:28:03 -0500
In-Reply-To: Hrvoje Niksic's message of 16 Nov 1996 06:43:29 +0100
Message-ID: <yviazq0imu4s.fsf@atreides.mindspring.com>
Lines: 13

Hrvoje Niksic <hniksic@srce.hr> writes:
> Martin Buchholz (mrb@eng.sun.com) wrote:
>> If we have a major incompatible release after 20.0 (the canonical
>> example is lexical scoping) we'll just make a 21.0.

> And multithreaded XEmacs will be 22.0.  That settles it. :-)

It will be GNU Emacs 20.0, if Guile lives up to it's promise.  The
current plan for GNU Emacs, I believe, is to replace the interpreter
with an elisp -> guile translator when Guile matures.  Has anyone
considered how we'll handle this?  

-Sudish

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 00:25:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA15919 for xemacs-beta-people; Sat, 16 Nov 1996 00:25:21 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA15916 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 00:25:20 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id AAA26029 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 00:25:20 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA10478 for <xemacs-beta@cs.uiuc.edu>; Fri, 15 Nov 1996 22:24:49 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA04112; Fri, 15 Nov 1996 22:24:46 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA08565; Fri, 15 Nov 1996 22:24:47 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA03972; Fri, 15 Nov 1996 22:24:43 -0800
Date: Fri, 15 Nov 1996 22:24:43 -0800
Message-Id: <199611160624.WAA03972@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: `frame in a glyph'
In-Reply-To: <kig9182bm4y.fsf@jagor.srce.hr>
References: <199611130558.VAA20443@infodock.com>
	<328D0481.3B351894@aosi.com>
	<m2iv76iw7o.fsf@deanna.miranova.com>
	<kigiv76bu9u.fsf@jagor.srce.hr>
	<199611160534.VAA03705@xemacs.eng.sun.com>
	<kigd8xebnni.fsf@jagor.srce.hr>
	<199611160609.WAA03936@xemacs.eng.sun.com>
	<kig9182bm4y.fsf@jagor.srce.hr>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Martin Buchholz (mrb@eng.sun.com) wrote:
>> I'm sure with a name and email address like yours, you'll want to
>> build --with-mule so that you can read Hrvatski with XEmacs.

Hrv> Why?  I can read Croatian by specifying an iso-8859-2 font.  Or, do
Hrv> you mean that there is something else I could get with Mule-ized
Hrv> XEmacs?

You could have simultaneous display of Latin-2 and Latin-1 in the same
buffer.  With the use of Mime the recipient of your email can do the same.
More realistically, you don't need to start up a new XEmacs with a
different font to read Croation - you can just say 
``Edit THIS file, encoded in Latin-2''.

Martin

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 00:26:28 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA15933 for xemacs-beta-people; Sat, 16 Nov 1996 00:26:28 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA15930 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 00:26:27 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA26037 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 00:26:16 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id HAA25915; Sat, 16 Nov 1996 07:25:56 +0100 (MET)
Sender: hniksic@public.srce.hr
To: Martin Buchholz <mrb@Eng.Sun.COM>
Cc: Hrvoje Niksic <hniksic@srce.hr>, Steven L Baur <steve@miranova.com>,
        xemacs-beta@cs.uiuc.edu, Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Subject: Re: [gnu.emacs.help,gnu.misc.discuss,comp.emacs] The C-h and delete controversy
References: <m2g22bktxo.fsf@deanna.miranova.com> 	<199611160114.RAA29939@xemacs.eng.sun.com> 	<kigloc2byph.fsf@jagor.srce.hr> <199611160618.WAA03961@xemacs.eng.sun.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 07:25:55 +0100
In-Reply-To: Martin Buchholz's message of Fri, 15 Nov 1996 22:18:29 -0800
Message-ID: <kig6836blos.fsf@jagor.srce.hr>
Lines: 26
X-Mailer: Red Gnus v0.62/XEmacs 19.14

Martin Buchholz (mrb@eng.sun.com) wrote:
> Hrv> *Please* don't do it to me.  It would kill many many settings.  My DEC
> Hrv> keyboard happily sends DEL, and I don't want it to delete next
> Hrv> character.
> 
> I'm not quite sure what you mean by that.  In X you presumably have
> keys labelled Backspace and Delete.  So you want them both to delete backwards?
> 

Nope -- I have one key labeled <X| or something like that, and I want
it to keep deleting backwards.  With what you propose, it would delete
forward.

> Hrv> Too many things depend on backspace and delete to invoke delbackspace
> Hrv> by default.  tty-s are another matter, of course.
> There's no doubt that this will be a painful transition, and whoever
> does it must don the asbestos suit first.

Agreed.  I don't know what the others think about it, but I don't like
the change.  Of course, it is a matter of opinion -- if you do make
the change, I'll grit my teeth and run xmodmap...

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Good pings come in small packets.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 00:42:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA16058 for xemacs-beta-people; Sat, 16 Nov 1996 00:42:54 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA16055 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 00:42:53 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id AAA26180 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 00:42:53 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA10910; Fri, 15 Nov 1996 22:42:22 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA04598; Fri, 15 Nov 1996 22:42:19 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA08650; Fri, 15 Nov 1996 22:42:20 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA04034; Fri, 15 Nov 1996 22:42:17 -0800
Date: Fri, 15 Nov 1996 22:42:17 -0800
Message-Id: <199611160642.WAA04034@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Sudish Joseph <sudish@mindspring.com>
Cc: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Subject: Re: `frame in a glyph'
In-Reply-To: <yviazq0imu4s.fsf@atreides.mindspring.com>
References: <199611130558.VAA20443@infodock.com>
	<328D0481.3B351894@aosi.com>
	<m2iv76iw7o.fsf@deanna.miranova.com>
	<kigiv76bu9u.fsf@jagor.srce.hr>
	<199611160534.VAA03705@xemacs.eng.sun.com>
	<kigd8xebnni.fsf@jagor.srce.hr>
	<yviazq0imu4s.fsf@atreides.mindspring.com>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Sudish" == Sudish Joseph <sudish@mindspring.com> writes:

Sudish> It will be GNU Emacs 20.0, if Guile lives up to it's promise.  The
Sudish> current plan for GNU Emacs, I believe, is to replace the interpreter
Sudish> with an elisp -> guile translator when Guile matures.  Has anyone
Sudish> considered how we'll handle this?  

If the FSF implements this, we will do as we always have: if we
consider it to be good, we will incorporate it.  It is looking less
likely that UIUC will hire someone to do this as a research project.

Martin

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 00:40:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA16031 for xemacs-beta-people; Sat, 16 Nov 1996 00:40:52 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA16028 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 00:40:51 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id AAA26166 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 00:40:51 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA10839; Fri, 15 Nov 1996 22:39:15 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA04444; Fri, 15 Nov 1996 22:39:12 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA08623; Fri, 15 Nov 1996 22:39:12 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA04020; Fri, 15 Nov 1996 22:39:07 -0800
Date: Fri, 15 Nov 1996 22:39:07 -0800
Message-Id: <199611160639.WAA04020@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu,
        Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Subject: Re: [gnu.emacs.help,gnu.misc.discuss,comp.emacs] The C-h and delete controversy
In-Reply-To: <kig6836blos.fsf@jagor.srce.hr>
References: <m2g22bktxo.fsf@deanna.miranova.com>
	<199611160114.RAA29939@xemacs.eng.sun.com>
	<kigloc2byph.fsf@jagor.srce.hr>
	<199611160618.WAA03961@xemacs.eng.sun.com>
	<kig6836blos.fsf@jagor.srce.hr>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Martin Buchholz (mrb@eng.sun.com) wrote:
Hrv> *Please* don't do it to me.  It would kill many many settings.  My DEC
Hrv> keyboard happily sends DEL, and I don't want it to delete next
Hrv> character.
>> 
>> I'm not quite sure what you mean by that.  In X you presumably have
>> keys labelled Backspace and Delete.  So you want them both to delete backwards?
>> 

Hrv> Nope -- I have one key labeled <X| or something like that, and I want
Hrv> it to keep deleting backwards.  With what you propose, it would delete
Hrv> forward.

(when (and (x-keysym-on-keyboard-p "BackSpace")
           (x-keysym-on-keyboard-p "Delete"))
  (make-Backspace-and-Delete-delete-in-opposite-directions))

The key function x-keysym-on-keyboard-p has already been implemented.

Does it return the right value on your system?

Martin

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 00:43:57 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA16065 for xemacs-beta-people; Sat, 16 Nov 1996 00:43:57 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA16062 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 00:43:56 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA26187 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 00:43:54 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id HAA26990; Sat, 16 Nov 1996 07:43:29 +0100 (MET)
Sender: hniksic@public.srce.hr
To: Martin Buchholz <mrb@Eng.Sun.COM>
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@cs.uiuc.edu,
        Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Subject: Re: [gnu.emacs.help,gnu.misc.discuss,comp.emacs] The C-h and delete controversy
References: <m2g22bktxo.fsf@deanna.miranova.com> 	<199611160114.RAA29939@xemacs.eng.sun.com> 	<kigloc2byph.fsf@jagor.srce.hr> 	<199611160618.WAA03961@xemacs.eng.sun.com> 	<kig6836blos.fsf@jagor.srce.hr> <199611160639.WAA04020@xemacs.eng.sun.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 07:43:28 +0100
In-Reply-To: Martin Buchholz's message of Fri, 15 Nov 1996 22:39:07 -0800
Message-ID: <kigzq0ia6b3.fsf@jagor.srce.hr>
Lines: 21
X-Mailer: Red Gnus v0.62/XEmacs 19.14

Martin Buchholz (mrb@eng.sun.com) wrote:
> (when (and (x-keysym-on-keyboard-p "BackSpace")
>            (x-keysym-on-keyboard-p "Delete"))
>   (make-Backspace-and-Delete-delete-in-opposite-directions))

Or:
(unless (and (x-keysym-on-keyboard-p "BackSpace")
             (x-keysym-on-keyboard-p "Delete"))
  (let-xemacs-behave-as-if-delbackspace-el-were-leaded))

This is beginning to make sense. :)

> The key function x-keysym-on-keyboard-p has already been implemented.
> Does it return the right value on your system?

Yup, it does.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm a Lisp variable -- bind me!

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 00:57:29 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA16133 for xemacs-beta-people; Sat, 16 Nov 1996 00:57:29 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA16130 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 00:57:28 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id AAA26394 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 00:57:26 -0600 (CST)
Received: (qmail 16472 invoked by uid 501); 16 Nov 1996 06:59:58 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: `frame in a glyph'
References: <199611130558.VAA20443@infodock.com> 	<328D0481.3B351894@aosi.com> 	<m2iv76iw7o.fsf@deanna.miranova.com> 	<kigiv76bu9u.fsf@jagor.srce.hr> <199611160534.VAA03705@xemacs.eng.sun.com> <kigd8xebnni.fsf@jagor.srce.hr> <yviazq0imu4s.fsf@atreides.mindspring.com>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Sudish Joseph's message of 16 Nov 1996 01:28:03 -0500
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 15 Nov 1996 22:59:57 -0800
Message-ID: <m2k9rm5xua.fsf@deanna.miranova.com>
Lines: 28
X-Mailer: Red Gnus v0.62/XEmacs 19.15

>>>>> "Sudish" == Sudish Joseph <sudish@mindspring.com> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> Martin Buchholz (mrb@eng.sun.com) wrote:
Martin> If we have a major incompatible release after 20.0 (the canonical
Martin> example is lexical scoping) we'll just make a 21.0.

Hrvoje> And multithreaded XEmacs will be 22.0.  That settles it. :-)

Sudish> It will be GNU Emacs 20.0, if Guile lives up to it's promise.
Sudish> The current plan for GNU Emacs, I believe, is to replace the
Sudish> interpreter with an elisp -> guile translator when Guile
Sudish> matures.  Has anyone considered how we'll handle this?

Threading emacs is a *big* deal, and I certainly am not very
interested in making a variant implementation of it.  On the other
hand, our respective C code bases are not very similar with 19.34 -vs-
19.15, and going to get less so with 20.0.

It's a lot of work any way you look at it.  I do consider
compatibility with GNU Emacs and cooperation/coordination with rms a
high priority though.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 01:11:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id BAA16224 for xemacs-beta-people; Sat, 16 Nov 1996 01:11:55 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id BAA16221 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 01:11:54 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id BAA26657 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 01:11:53 -0600 (CST)
Received: (qmail 16548 invoked by uid 501); 16 Nov 1996 07:14:25 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Making scroll-in-place the default
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 15 Nov 1996 23:14:24 -0800
Message-ID: <m2enhu5x67.fsf@deanna.miranova.com>
Lines: 139
X-Mailer: Red Gnus v0.62/XEmacs 19.15

Here's a sample set of patches to do it, if anyone wishes to try
it out.  I like this package *a lot*.

Thanks to Sudish Joseph for suggestions.

NOTE:
Gnus users will also want to do:

(add-hook 'gnus-article-mode-hook 'turn-off-scroll-in-place)


*** src/Makefile.in.in~	Sun Sep 15 11:31:09 1996
--- src/Makefile.in.in	Fri Nov 15 21:09:21 1996
***************
*** 1151,1156 ****
--- 1151,1157 ----
          ${lispdir}prim/isearch-mode.elc ${lispdir}prim/misc.elc \
  	${lispdir}modes/cc-mode.elc ${lispdir}packages/vc-hooks.elc \
          ${lispdir}prim/replace.elc ${lispdir}prim/specifier.elc \
+ 	${lispdir}packages/scroll-in-place.elc \
          ${lispdir}modes/auto-show.elc SUNPRO_LISP TTY_LISP \
          ${lispdir}bytecomp/bytecomp-runtime.elc FLOAT_LISP EPOCH_LISP \
          ${lispdir}prim/itimer.elc ${lispdir}ediff/ediff-hook.elc \

*** lisp/prim/loadup.el~	Sun Sep 15 11:33:02 1996
--- lisp/prim/loadup.el	Fri Nov 15 19:54:21 1996
***************
*** 136,141 ****
--- 136,142 ----
       (load-gc "text-mode")
       (load-gc "fill")
       (load-gc "cc-mode")
+      (load-gc "scroll-in-place")
       ;; we no longer load buff-menu automatically.
       ;; it will get autoloaded if needed.
       

*** lisp/packages/scroll-in-place.el~	Sun Jan 21 19:50:49 1996
--- lisp/packages/scroll-in-place.el	Fri Nov 15 20:07:18 1996
***************
*** 17,23 ****
  ;;;;
  ;;;; You should have received a copy of the GNU General Public License along
  ;;;; with GNU Emacs.  If you did not, write to the Free Software Foundation,
! ;;;; Inc., 675 Mass Ave., Cambridge, MA 02139, USA.
  
  ;;; Synched up with: Not in FSF.
  
--- 17,23 ----
  ;;;;
  ;;;; You should have received a copy of the GNU General Public License along
  ;;;; with GNU Emacs.  If you did not, write to the Free Software Foundation,
! ;;;; Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
  
  ;;; Synched up with: Not in FSF.
  
***************
*** 461,466 ****
--- 461,469 ----
  ;;;;   invoke scrolling commands (although many filters move point around,
  ;;;;   which will also confuse `scroll-window-in-place').
  
+ ;; sb -- Added turn-on and turn-off hook functions to prepare for making this
+ ;;  a standardly dumped package with XEmacs.
+ 
  ;; (provide 'scroll-in-place) at the end of this file.
  
  
***************
*** 495,501 ****
    ;; be worth it.
    )
  
! (defvar scroll-allow-blank-lines-past-eob nil
    "*When this variable is `nil' the \"in place\" scrolling commands will avoid
  displaying empty lines past the end of the buffer text.  In other words, just
  as you can't see \"dead space\" before the beginning of the buffer text, the
--- 498,504 ----
    ;; be worth it.
    )
  
! (defvar scroll-allow-blank-lines-past-eob t
    "*When this variable is `nil' the \"in place\" scrolling commands will avoid
  displaying empty lines past the end of the buffer text.  In other words, just
  as you can't see \"dead space\" before the beginning of the buffer text, the
***************
*** 625,630 ****
--- 628,643 ----
  set for all versions of Epoch 4 and for Lucid GNU Emacs 19.8.")
  
  
+ ;; Hook functions to make turning the mode on and off easier.
+ (defun turn-on-scroll-in-place ()
+   "Unconditionally turn on scroll-in-place mode."
+   (set (make-local-variable 'scroll-in-place) t))
+ 
+ (defun turn-off-scroll-in-place ()
+   "Unconditionally turn on scroll-in-place mode."
+   (set (make-local-variable 'scroll-in-place) nil))
+ 
+ 
  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  ;;;;
***************
*** 1547,1552 ****
--- 1560,1573 ----
  	  nil))
  
  
+ ;;; Some convenience redefinitions for modes that don't like scroll-in-place
+ (add-hook 'vm-mode-hook 'turn-off-scroll-in-place)
+ (add-hook 'vm-select-message-hook 'turn-off-scroll-in-place)
+ (add-hook 'vm-summary-mode-hook 'turn-off-scroll-in-place)
+ 
+ ;; This doesn't work with Red Gnus
+ ;; (add-hook 'gnus-article-mode-hook 'turn-off-scroll-in-place)
+ 
  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  ;;;;
***************
*** 1557,1561 ****
  
  (provide 'scroll-in-place)
  
! ;; End of file.
! 
--- 1578,1581 ----
  
  (provide 'scroll-in-place)
  
! ;;; scroll-in-place.el ends here

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 11:08:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id LAA20813 for xemacs-beta-people; Sat, 16 Nov 1996 11:08:21 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA20810 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 11:08:20 -0600 (CST)
Received: from wmperry.in.aventail.com (wmperry@wmperry.oz.net [207.13.185.53]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA07349 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 11:08:18 -0600 (CST)
Received: (from wmperry@localhost) by wmperry.in.aventail.com (8.7.6/8.7.3) id JAA00425; Sat, 16 Nov 1996 09:08:18 -0800
Date: Sat, 16 Nov 1996 09:08:18 -0800
Message-Id: <199611161708.JAA00425@wmperry.in.aventail.com>
From: "William M. Perry" <wmperry@aventail.com>
To: Sudish Joseph <sudish@mindspring.com>
Cc: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Subject: Re: `frame in a glyph'
In-Reply-To: <yviazq0imu4s.fsf@atreides.mindspring.com>
References: <199611130558.VAA20443@infodock.com>
	<328D0481.3B351894@aosi.com>
	<m2iv76iw7o.fsf@deanna.miranova.com>
	<kigiv76bu9u.fsf@jagor.srce.hr>
	<199611160534.VAA03705@xemacs.eng.sun.com>
	<kigd8xebnni.fsf@jagor.srce.hr>
	<yviazq0imu4s.fsf@atreides.mindspring.com>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;

Sudish Joseph writes:
>Hrvoje Niksic <hniksic@srce.hr> writes:
>> Martin Buchholz (mrb@eng.sun.com) wrote:
>>> If we have a major incompatible release after 20.0 (the canonical
>>> example is lexical scoping) we'll just make a 21.0.
>
>> And multithreaded XEmacs will be 22.0.  That settles it. :-)
>
>It will be GNU Emacs 20.0, if Guile lives up to it's promise.  The
>current plan for GNU Emacs, I believe, is to replace the interpreter
>with an elisp -> guile translator when Guile matures.  Has anyone
>considered how we'll handle this?  

  Do the same thing hopefully. :)

-Bill P.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 13:50:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA21164 for xemacs-beta-people; Sat, 16 Nov 1996 13:50:55 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA21161 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 13:50:53 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA09422 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 13:50:44 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id UAA29621; Sat, 16 Nov 1996 20:50:28 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Making scroll-in-place the default
References: <m2enhu5x67.fsf@deanna.miranova.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 20:50:27 +0100
In-Reply-To: Steven L Baur's message of 15 Nov 1996 23:14:24 -0800
Message-ID: <kign2whom4c.fsf@jagor.srce.hr>
Lines: 13
X-Mailer: Red Gnus v0.62/XEmacs 19.14

Steven L. Baur (steve@miranova.com) wrote:
> Here's a sample set of patches to do it, if anyone wishes to try
> it out.  I like this package *a lot*.

Can you post it as a lisp package -- does it have to be preloaded?
Currently I have disk-space problems with compiling XEmacs, but I
would still like to try it out.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 13:53:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA21177 for xemacs-beta-people; Sat, 16 Nov 1996 13:53:58 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA21174 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 13:53:57 -0600 (CST)
Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id NAA09460 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 13:53:49 -0600 (CST)
Received: from modas.Informatik.Uni-Tuebingen.De by macon.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA04846; Sat, 16 Nov 1996 20:53:47 +0100
Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03)
          id AA25296; Sat, 16 Nov 1996 20:53:45 +0100
Sender: sperber@informatik.uni-tuebingen.de
To: xemacs-beta@cs.uiuc.edu
Subject: Re: `frame in a glyph'
References: <199611130558.VAA20443@infodock.com> 	<328D0481.3B351894@aosi.com> 	<m2iv76iw7o.fsf@deanna.miranova.com> 	<kigiv76bu9u.fsf@jagor.srce.hr> <199611160534.VAA03705@xemacs.eng.sun.com> <kigd8xebnni.fsf@jagor.srce.hr> <yviazq0imu4s.fsf@atreides.mindspring.com>
Mime-Version: 1.0 (generated by tm-edit 7.52)
Content-Type: text/plain; charset=US-ASCII
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 16 Nov 1996 20:53:45 +0100
In-Reply-To: Sudish Joseph's message of 16 Nov 1996 01:28:03 -0500
Message-Id: <y9lpw1d3jg6.fsf@modas.informatik.uni-tuebingen.de>
Lines: 34
X-Mailer: Red Gnus v0.61/XEmacs 19.15

>>>>> "Sudish" == Sudish Joseph <sudish@mindspring.com> writes:

Sudish> Hrvoje Niksic <hniksic@srce.hr> writes:
>> Martin Buchholz (mrb@eng.sun.com) wrote:
>>> If we have a major incompatible release after 20.0 (the canonical
>>> example is lexical scoping) we'll just make a 21.0.

>> And multithreaded XEmacs will be 22.0.  That settles it. :-)

Sudish> It will be GNU Emacs 20.0, if Guile lives up to it's promise.  The
Sudish> current plan for GNU Emacs, I believe, is to replace the interpreter
Sudish> with an elisp -> guile translator when Guile matures.  Has anyone
Sudish> considered how we'll handle this?  

Just replacing elisp by Guile won't make Emacs multi-threaded.  I'm
not sure that Guile has thread support at the moment, but even if a
*lot* of conceptual effort would have to go into making the current
elisp code base and the C code multi-threaded.

We had this discussion before, but I still seriously doubt that Guile
will be a suitable substrate for Emacs.  It has a conservative
collector that is bound to leak---to what degree nobody knows, but
scm, Guile's ancestor/brother, tends to get into severe memory
fragmentation funks as its collector is non-moving.  It's also
impossible to fix that problem as the Guile code base has gotten much
too large.

There *are* better Scheme substrates out there that would make loading
alternative dialects and syntaxes pretty easy conceptually *and* have
solid GC and packae strategies, such as Scheme 48.  However, replacing
Elisp by any other substrate is bound to be MAJOR, MAJOR, MAJOR
effort.

Cheers =8-} Mike

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 14:31:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA21313 for xemacs-beta-people; Sat, 16 Nov 1996 14:31:03 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA21310 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 14:31:02 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id OAA00802 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 14:31:01 -0600 (CST)
Received: (qmail 20902 invoked by uid 501); 16 Nov 1996 20:33:29 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Making scroll-in-place the default
References: <m2enhu5x67.fsf@deanna.miranova.com> <kign2whom4c.fsf@jagor.srce.hr>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Hrvoje Niksic's message of 16 Nov 1996 20:50:27 +0100
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
Date: 16 Nov 1996 12:33:27 -0800
Message-ID: <m2hgmp231k.fsf@deanna.miranova.com>
Lines: 23
X-Mailer: Red Gnus v0.62/XEmacs 19.15

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Steven L. Baur (steve@miranova.com) wrote:

sb> Here's a sample set of patches to do it, if anyone wishes to try
sb> it out.  I like this package *a lot*.

Hrv> Can you post it as a lisp package -- does it have to be preloaded?

It does not.  Apply just the patch to scroll-in-place.el to the one in
19.14, and bytecompile it.  Then load it from site-start.el or at the
top of your .emacs.

Hrv> Currently I have disk-space problems with compiling XEmacs, but I
Hrv> would still like to try it out.

19.15 hasn't diverged enough at this point that you can't try some of
these things out on 19.14.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 14:59:58 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA21459 for xemacs-beta-people; Sat, 16 Nov 1996 14:59:58 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA21455 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 14:59:57 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA01379 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 14:59:49 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id VAA04885; Sat, 16 Nov 1996 21:59:33 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Making scroll-in-place the default
References: <m2enhu5x67.fsf@deanna.miranova.com> <kign2whom4c.fsf@jagor.srce.hr> <m2hgmp231k.fsf@deanna.miranova.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 21:59:32 +0100
In-Reply-To: Steven L Baur's message of 16 Nov 1996 12:33:27 -0800
Message-ID: <kigloc14uyz.fsf@jagor.srce.hr>
Lines: 29
X-Mailer: Red Gnus v0.63/XEmacs 19.14

Steven L. Baur (steve@miranova.com) wrote:
> It does not.  Apply just the patch to scroll-in-place.el to the one in
> 19.14, and bytecompile it.  Then load it from site-start.el or at the
> top of your .emacs.

Hmm, I didn't even know scroll-in-place was in 19.14 distribution.
Now I do. :-)

Anyway, this a terrific feature.  I vote for it being the default.  I
don't think it would break anything (other than Gnus goodies, but
that's fixed already), and it's a true improvement -- go for it.

> Hrv> Currently I have disk-space problems with compiling XEmacs, but I
> Hrv> would still like to try it out.
> 19.15 hasn't diverged enough at this point that you can't try some of
> these things out on 19.14.

Yup.  That's why I use 19.14 to hack Lisp.  Hacking C requires a
source around, and then it's better to use 19.15.

Speaking of hacking lisp, will my toolbar-new patch find its way into
19.15?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The IDIOT.  Usually a cretin, morpohodite, or old COBOL programmer
selected to be the system administrator by a committee of cretins,
morphodites, and old COBOL programmers.

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 15:58:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id PAA21592 for xemacs-beta-people; Sat, 16 Nov 1996 15:58:17 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id PAA21589 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 15:58:16 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id PAA02226 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 15:58:15 -0600 (CST)
Received: (qmail 22165 invoked by uid 501); 16 Nov 1996 22:00:43 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Making scroll-in-place the default
References: <m2enhu5x67.fsf@deanna.miranova.com> <kign2whom4c.fsf@jagor.srce.hr> <m2hgmp231k.fsf@deanna.miranova.com> <kigloc14uyz.fsf@jagor.srce.hr>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Hrvoje Niksic's message of 16 Nov 1996 21:59:32 +0100
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
Date: 16 Nov 1996 14:00:42 -0800
Message-ID: <m2n2whhf91.fsf@deanna.miranova.com>
Lines: 18
X-Mailer: Red Gnus v0.63/XEmacs 19.15

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Hmm, I didn't even know scroll-in-place was in 19.14
Hrv> distribution.  Now I do. :-)

Neither did I :-).

 ...

Hrv> Speaking of hacking lisp, will my toolbar-new patch find its way into
Hrv> 19.15?

Yes, but not before beta4.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 16:16:46 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA21626 for xemacs-beta-people; Sat, 16 Nov 1996 16:16:46 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA21623 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 16:16:45 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA07581 for <xemacs-beta@xemacs.org>; Sat, 16 Nov 1996 16:16:31 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id XAA11357; Sat, 16 Nov 1996 23:16:20 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: scroll-in-place gotcha
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 16 Nov 1996 23:16:19 +0100
Message-ID: <kigbucxu1n0.fsf@jagor.srce.hr>
Lines: 6

As I have said, it works like a charm, except at one place: press
`C-x C-f /usr/local/lib/', and press TAB several times in a row.
Things that happen are the result of scroll-in-place, I believe.

-- 
.Sig missing

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 16:50:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA21721 for xemacs-beta-people; Sat, 16 Nov 1996 16:50:34 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA21718 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 16:50:33 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id QAA02910 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 16:50:32 -0600 (CST)
Received: (qmail 22925 invoked by uid 501); 16 Nov 1996 22:53:04 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: scroll-in-place gotcha
References: <kigbucxu1n0.fsf@jagor.srce.hr>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Hrvoje Niksic's message of 16 Nov 1996 23:16:19 +0100
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
Date: 16 Nov 1996 14:53:02 -0800
Message-ID: <m2g229hctt.fsf@deanna.miranova.com>
Lines: 18
X-Mailer: Red Gnus v0.63/XEmacs 19.15

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> As I have said, it works like a charm, except at one place: press
Hrv> `C-x C-f /usr/local/lib/', and press TAB several times in a row.
Hrv> Things that happen are the result of scroll-in-place, I believe.

The buffer cycles around as before.  What is your setting of
scroll-allow-blank-lines-past-eob?  The new default will be t.

The fix though is to add
(add-hook 'list-mode-hook 'turn-off-scroll-in-place)
to the initialization.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 18:14:55 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id SAA21938 for xemacs-beta-people; Sat, 16 Nov 1996 18:14:55 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id SAA21935 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 18:14:50 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id SAA07707 for <xemacs-beta@xemacs.org>; Sat, 16 Nov 1996 18:14:47 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA05495; Sat, 16 Nov 1996 16:13:02 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA10214; Sat, 16 Nov 1996 16:12:31 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA13613; Sat, 16 Nov 1996 16:12:16 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA08871; Sat, 16 Nov 1996 16:12:14 -0800
Date: Sat, 16 Nov 1996 16:12:14 -0800
Message-Id: <199611170012.QAA08871@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Steven L Baur <steve@miranova.com>
Cc: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>, pinard@iro.umontreal.ca,
        Ulrich Drepper <drepper@gnu.ai.mit.edu>,
        XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: Internationalization
In-Reply-To: <m2iv75hdp4.fsf@deanna.miranova.com>
References: <m2vibermpl.fsf@proletcult.ifi.uio.no>
	<m23eyhg7oy.fsf@deanna.miranova.com>
	<m291883bzg.fsf@proletcult.ifi.uio.no>
	<m2pw1fj7z1.fsf@deanna.miranova.com>
	<m2iv769aj6.fsf@proletcult.ifi.uio.no>
	<m2iv75hdp4.fsf@deanna.miranova.com>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII

>>>>> "sb" == Steven L Baur <steve@miranova.com> writes:

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
>> Steven L Baur <steve@miranova.com> writes:

sb> It doesn't look like there's too much there.  This is one area we
sb> should have communication between the various emacs developers so we
sb> don't end up with two separate implementations.

Lars> Definitely.  Perhaps a mailing list should be set up to allow
Lars> people to discuss this?  There are many ways to go about doing
Lars> the internationalization, and most of them are probably wrong.
Lars> :-)

sb> Yes, please do set one up.  It would also set a good precedent if
sb> Emacs developers and XEmacs developers worked together on it.

Here's some history.

Today you can configure XEmacs with the --with-i18n3 flag, which will
give you an xemacs that will (try to) do message translation - brokenly.

There have been at least 2 implementations of message
internationalization in the past, and one of them has been completely
excised from the code.  This stuff is REALLY hard to get right.  The
basic problem is how to do translations when and only when they are
appropriate.  You don't ever want buffer names translated, for
example.  

XEmacs 20 today has translatable menubars with localizations for one
language, Japanese.  This is done via X resources.  Even in this
restricted case translation problems arise, since you don't want
`Help' translated if it's a buffer name in the Buffers menu.

Ben and jwz have done more thinking on this problem than I have.
XEmacs contains the following comments in lib-src/make-msgfile.lex:

--------------------- make-msgfile.lex -----------------------
/* Note: there is still much work to be done on this.

   1) Definition of Arg below won't handle a generalized argument
      as might appear in a function call.  This is fine for DEFUN
      and friends, because only simple arguments appear there; but
      it might run into problems if Arg is used for other sorts
      of functions.
   2) snarf() should be modified so that it doesn't output null
      strings and non-textual strings (see the comment at the top
      of make-msgfile.c).
   3) parsing of (insert) should snarf all of the arguments.
   4) need to add set-keymap-prompt and deal with gettext of that.
   5) parsing of arguments should snarf all strings anywhere within
      the arguments, rather than just looking for a string as the
      argument.  This allows if statements as arguments to get parsed.
   6) begin_paren_counting() et al. should handle recursive entry.
   7) handle set-window-buffer and other such functions that take
      a buffer as the other-than-first argument.
   8) there is a fair amount of work to be done on the C code.
      Look through the code for #### comments associated with
      '#ifdef I18N3' or with an I18N3 nearby.
   9) Deal with `get-buffer-process' et al.
   10) Many of the changes in the Lisp code marked
       'rewritten for I18N3 snarfing' should be undone once (5) is
       implemented.
   11) Go through the Lisp code in prim and make sure that all
       strings are gettexted as necessary.  This may reveal more
       things to implement.
   12) Do the equivalent of (8) for the Lisp code.
   13) Deal with parsing of menu specifications.

	--ben
   
*/

/* Long comment from jwz:

   (much of this comment is outdated, and a lot of it is actually
   implemented)
   
   
   PROPOSAL FOR HOW THIS ALL OUGHT TO WORK
   this isn't implemented yet, but this is the plan-in-progress

   
   In general, it's accepted that the best way to internationalize is for all
   messages to be referred to by a symbolic name (or number) and come out of a
   table or tables, which are easy to change.

   However, with Emacs, we've got the task of internationalizing a huge body
   of existing code, which already contains messages internally.

   For the C code we've got two options:

    - Use a Sun-like gettext() form, which takes an "english" string which
      appears literally in the source, and uses that as a hash key to find
      a translated string;
    - Rip all of the strings out and put them in a table.

   In this case, it's desirable to make as few changes as possible to the C
   code, to make it easier to merge the code with the FSF version of emacs
   which won't ever have these changes made to it.  So we should go with the
   former option.

   The way it has been done (between 19.8 and 19.9) was to use gettext(), but
   *also* to make massive changes to the source code.  The goal now is to use
   gettext() at run-time and yet not require a textual change to every line
   in the C code which contains a string constant.  A possible way to do this
   is described below.

   (gettext() can be implemented in terms of catgets() for non-Sun systems, so
   that in itself isn't a problem.)

   For the Lisp code, we've got basically the same options: put everything in
   a table, or translate things implicitly.

   Another kink that lisp code introduces is that there are thousands of third-
   party packages, so changing the source for all of those is simply not an
   option.

   Is it a goal that if some third party package displays a message which is
   one we know how to translate, then we translate it?  I think this is a
   worthy goal.  It remains to be seen how well it will work in practice.

   So, we should endeavor to minimize the impact on the lisp code.  Certain
   primitive lisp routines (the stuff in lisp/prim/, and especially in
   cmdloop.el and minibuf.el) may need to be changed to know about translation,
   but that's an ideologically clean thing to do because those are considered
   a part of the emacs substrate.

   However, if we find ourselves wanting to make changes to, say, RMAIL, then
   something has gone wrong.  (Except to do things like remove assumptions
   about the order of words within a sentence, or how pluralization works.)

   There are two parts to the task of displaying translated strings to the 
   user: the first is to extract the strings which need to be translated from
   the sources; and the second is to make some call which will translate those
   strings before they are presented to the user.
   
   The old way was to use the same form to do both, that is, GETTEXT() was both
   the tag that we searched for to build a catalog, and was the form which did
   the translation.  The new plan is to separate these two things more: the
   tags that we search for to build the catalog will be stuff that was in there
   already, and the translation will get done in some more centralized, lower
   level place.

   This program (make-msgfile.c) addresses the first part, extracting the 
   strings.
   
   For the emacs C code, we need to recognise the following patterns:
   
     message ("string" ... )
     error ("string")
     report_file_error ("string" ... )
     signal_simple_error ("string" ... )
     signal_simple_error_2 ("string" ... )
     
     build_translated_string ("string")
     #### add this and use it instead of build_string() in some places.
     
     yes_or_no_p ("string" ... )
     #### add this instead of funcalling Qyes_or_no_p directly.

     barf_or_query_if_file_exists	#### restructure this
     check all callers of Fsignal	#### restructure these
     signal_error (Qerror ... )		#### change all of these to error()
     
     And we also parse out the `interactive' prompts from DEFUN() forms.
     
     #### When we've got a string which is a candidate for translation, we
     should ignore it if it contains only format directives, that is, if
     there are no alphabetic characters in it that are not a part of a `%'
     directive.  (Careful not to translate either "%s%s" or "%s: ".)

   For the emacs Lisp code, we need to recognise the following patterns:
   
     (message "string" ... )
     (error "string" ... )
     (format "string" ... )
     (read-from-minibuffer "string" ... )
     (read-shell-command "string" ... )
     (y-or-n-p "string" ... )
     (yes-or-no-p "string" ... )
     (read-file-name "string" ... )
     (temp-minibuffer-message "string")
     (query-replace-read-args "string" ... )
     
   I expect there will be a lot like the above; basically, any function which
   is a commonly used wrapper around an eventual call to `message' or
   `read-from-minibuffer' needs to be recognised by this program.


     (dgettext "domain-name" "string")		#### do we still need this?
     
     things that should probably be restructured:
       `princ' in cmdloop.el
       `insert' in debug.el
       face-interactive
       help.el, syntax.el all messed up
     
   BPW: (format) is a tricky case.  If I use format to create a string
   that I then send to a file, I probably don't want the string translated.
   On the other hand, If the string gets used as an argument to (y-or-n-p)
   or some such function, I do want it translated, and it needs to be
   translated before the %s and such are replaced.  The proper solution
   here is for (format) and other functions that call gettext but don't
   immediately output the string to the user to add the translated (and
   formatted) string as a string property of the object, and have
   functions that output potentially translated strings look for a
   "translated string" property.  Of course, this will fail if someone
   does something like

      (y-or-n-p (concat (if you-p "Do you " "Does he ")
			(format "want to delete %s? " filename))))

   But you shouldn't be doing things like this anyway.

   BPW: Also, to avoid excessive translating, strings should be marked
   as translated once they get translated, and further calls to gettext
   don't do any more translating.  Otherwise, a call like

      (y-or-n-p (format "Delete %s? " filename))

   would cause translation on both the pre-formatted and post-formatted
   strings, which could lead to weird results in some cases (y-or-n-p
   has to translate its argument because someone could pass a string to
   it directly).  Note that the "translating too much" solution outlined
   below could be implemented by just marking all strings that don't
   come from a .el or .elc file as already translated.

   Menu descriptors: one way to extract the strings in menu labels would be
   to teach this program about "^(defvar .*menu\n" forms; that's probably
   kind of hard, though, so perhaps a better approach would be to make this
   program recognise lines of the form

     "string" ... ;###translate

   where the magic token ";###translate" on a line means that the string 
   constant on this line should go into the message catalog.  This is analagous
   to the magic ";###autoload" comments, and to the magic comments used in the
   EPSF structuring conventions.

  -----
  So this program manages to build up a catalog of strings to be translated.
  To address the second part of the problem, of actually looking up the
  translations, there are hooks in a small number of low level places in
  emacs.

  Assume the existence of a C function gettext(str) which returns the 
  translation of `str' if there is one, otherwise returns `str'.

  - message() takes a char* as its argument, and always filters it through
    gettext() before displaying it.

  - errors are printed by running the lisp function `display-error' which
    doesn't call `message' directly (it princ's to streams), so it must be
    carefully coded to translate its arguments.  This is only a few lines
    of code.

  - Fread_minibuffer_internal() is the lowest level interface to all minibuf
    interactions, so it is responsible for translating the value that will go
    into Vminibuf_prompt.

  - Fpopup_menu filters the menu titles through gettext().

    The above take care of 99% of all messages the user ever sees.

  - The lisp function temp-minibuffer-message translates its arg.

  - query-replace-read-args is funny; it does
      (setq from (read-from-minibuffer (format "%s: " string) ... ))
      (setq to (read-from-minibuffer (format "%s %s with: " string from) ... ))

    What should we do about this?  We could hack query-replace-read-args to
    translate its args, but might this be a more general problem?  I don't
    think we ought to translate all calls to format.  We could just change
    the calling sequence, since this is odd in that the first %s wants to be
    translated but the second doesn't.


  Solving the "translating too much" problem:
  The concern has been raised that in this situation:
   - "Help" is a string for which we know a translation;
   - someone visits a file called Help, and someone does something 
     contrived like (error buffer-file-name)
  then we would display the translation of Help, which would not be correct.
  We can solve this by adding a bit to Lisp_String objects which identifies
  them as having been read as literal constants from a .el or .elc file (as
  opposed to having been constructed at run time as it would in the above 
  case.)  To solve this:

    - Fmessage() takes a lisp string as its first argument.
      If that string is a constant, that is, was read from a source file
      as a literal, then it calls message() with it, which translates.
      Otherwise, it calls message_no_translate(), which does not translate.

    - Ferror() (actually, Fsignal() when condition is Qerror) works similarly.
*/

From xemacs-beta-request@cs.uiuc.edu  Sat Nov 16 23:06:31 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA22534 for xemacs-beta-people; Sat, 16 Nov 1996 23:06:31 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA22531 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 16 Nov 1996 23:06:30 -0600 (CST)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA12237 for <xemacs-beta@cs.uiuc.edu>; Sat, 16 Nov 1996 23:06:29 -0600 (CST)
Received: from xdiv.lanl.gov (xdiv.lanl.gov [128.165.116.106]) by mailhost.lanl.gov (8.7.6/8.7.3) with ESMTP id WAA00194; Sat, 16 Nov 1996 22:06:25 -0700 (MST)
Received: from branagh.lanl.gov (branagh.lanl.gov [128.165.16.72]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id WAA05208; Sat, 16 Nov 1996 22:06:25 -0700
Received: by branagh.lanl.gov (SMI-8.6/SMI-SVR4)
	id WAA01187; Sat, 16 Nov 1996 22:05:10 -0700
Date: Sat, 16 Nov 1996 22:05:10 -0700
Message-Id: <199611170505.WAA01187@branagh.lanl.gov>
From: John Turner <turner@xdiv.lanl.gov>
To: steve@miranova.com
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: scroll-in-place gotcha
In-Reply-To: <m2g229hctt.fsf@deanna.miranova.com>
References: <kigbucxu1n0.fsf@jagor.srce.hr>
	<m2g229hctt.fsf@deanna.miranova.com>
Reply-To: turner@lanl.gov

Steven L. Baur writes:
 > >>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:
 > 
 > Hrv> As I have said, it works like a charm, except at one place: press
 > Hrv> `C-x C-f /usr/local/lib/', and press TAB several times in a row.
 > Hrv> Things that happen are the result of scroll-in-place, I believe.
 > 
 > The buffer cycles around as before.  What is your setting of
 > scroll-allow-blank-lines-past-eob?  The new default will be t.
 > 
 > The fix though is to add
 > (add-hook 'list-mode-hook 'turn-off-scroll-in-place)
 > to the initialization.

Also note that scroll-in-place doesn't play nicely with VM.

So I have this in my .vm:

(add-hook 'vm-mode-hook
	  '(lambda ()
	     (make-variable-buffer-local 'scroll-in-place)
	     (setq scroll-in-place nil)
	     ))

-- 
John A. Turner
Los Alamos National Laboratory, MS B226, Los Alamos, NM 87545
Group: XTM (Radiation Transport Methods)
Location: TA-3, Bldg. 43, Rm. D150
Phone: 505-665-1303                   e-mail: turner@lanl.gov

From xemacs-beta-request@cs.uiuc.edu  Sun Nov 17 23:00:36 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id XAA28438 for xemacs-beta-people; Sun, 17 Nov 1996 23:00:36 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id XAA28435 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 17 Nov 1996 23:00:35 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id XAA08206 for <xemacs-beta@cs.uiuc.edu>; Sun, 17 Nov 1996 23:00:34 -0600 (CST)
Received: (qmail 2066 invoked by uid 501); 18 Nov 1996 05:03:04 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Profiling Data for Tower of Hanoi benchmark (19.15beta 2 1/2)
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Nov 1996 21:03:03 -0800
Message-ID: <m2ohgwxaew.fsf@deanna.miranova.com>
Lines: 33
X-Mailer: Red Gnus v0.63/XEmacs 19.15

Function Name  Call Count  Elapsed Time  Average Time
=============  ==========  ============  ============
bench-mark-1   1           39.257784000  39.257784000

((hanoi-move-ring . 34)
 (hanoi-draw-ring . 23)
 (hanoi-topos . 1)
 (raw-append-message . 1)
 (hanoi . 3)
 (store-match-data . 2)
 (match-data . 1)
 (do-auto-save . 1)
 (redisplay-echo-area . 1)
 (delete-backward-char . 12)
 (delete-char . 17)
 (clear-message . 1)
 (itimer-callback . 1)
 (undoable-stack-push . 1)
 (load-internal . 3)
 (sit-for . 45)
 (move-to-column . 3)
 (input-pending-p . 1)
 (previous-line . 1)
 (line-move . 8)
 (next-line . 1)
 ("(in redisplay)" . 3430)              <==================
 (goto-line . 3))

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Sun Nov 17 22:40:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id WAA28388 for xemacs-beta-people; Sun, 17 Nov 1996 22:40:42 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id WAA28385 for <xemacs-beta@spruce.cs.uiuc.edu>; Sun, 17 Nov 1996 22:40:41 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id WAA06738 for <xemacs-beta@cs.uiuc.edu>; Sun, 17 Nov 1996 22:40:40 -0600 (CST)
Received: (qmail 1777 invoked by uid 501); 18 Nov 1996 04:43:10 -0000
Sender: steve@deanna.miranova.com
Newsgroups: comp.emacs.xemacs
To: xemacs-beta@cs.uiuc.edu
Subject: Bench Marking XEmacs
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Organization: Miranova Systems, Inc.
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Nov 1996 20:43:04 -0800
Message-ID: <m23ey8ypwn.fsf@deanna.miranova.com>
Lines: 91
X-Newsreader: Red Gnus v0.63/XEmacs 19.15
Posted-To: comp.emacs.xemacs

The following message is a courtesy copy of an article
that has been posted as well.

Shane Holder posted a benchmark utility to this newsgroup a few days
ago, and I'd like to comment on it.  (It is *wonderful* news).

Shane> I've gone back to using emacs 19.34, just because things are so
Shane> slow in xemacs no flames intended.  I've included times from a
Shane> benchmark package I'm working on.  It's very simple, and
Shane> included at the bottom, I'd be interested in any
Shane> comments/flames.  I should do more iterations, but I just
Shane> haven't gotten that far yet.

First of all Shane, thank you for providing the benchmark.  The
biggest comment I have is that it appears to only cover display
performance.  If you want to do more tests, I would recommend doing
various non-display computational sorts of things.

Anyway, here are the results I got running it: (19.34 -vs- 19.14[1])
compiled with similar optimization settings (-O4, Linux/ELF 2.0
kernel, on a slow, stupid Cyrix 486/66).

Emacs 19.34
Function Name  Call Count  Elapsed Time  Average Time
=============  ==========  ============  ============
bench-mark-1   1           5.2587159999  5.2587159999 (hanoi)
bench-mark-2   1           22.319042000  22.319042000 (font-lock)
bench-mark-3   1           280.97348300  280.97348300 (next-line)
bench-mark-4   1           3.1149910000  3.1149910000 (make-frame)
bench-mark-6   1           148.00331200  148.00331200 (byte-compile)

Emacs 19.14
Function Name  Call Count  Elapsed Time  Average Time
=============  ==========  ============  ============
bench-mark-1   1           32.556711999  32.556711999 (hanoi)
bench-mark-2   1           24.582392999  24.582392999 (font-lock)
bench-mark-3   1           306.13799399  306.13799399 (next-line)
bench-mark-4   1           0.7691689999  0.7691689999 (make-frame)
bench-mark-6   1           262.15874100  262.15874100 (byte-compile)

First off notice that the biggest discrepancies are against hanoi and
the byte-compile tests.  The Tower of Hanoi game is extremely display
intensive.  The byte-compile test is comparing apples and oranges.
The XEmacs byte compiler is optimizing and the 19.34 byte-compiler is
not.  Turning off byte-compiler optimization via:

(defun bench-mark-6 ()
  ; Byte compile a file
  (let ((byte-optimize nil))
    (byte-compile-file large-lisp-file))
)

Resulted in a run time of:
Function Name  Call Count  Elapsed Time  Average Time
=============  ==========  ============  ============
bench-mark-6   1           155.63545000  155.63545000 (byte-compile)

Now, XEmacs is slower on each of the larger bench marks except the
make-frame one.  And markedly slower when displaying is involved.  I'd
say this is very strong evidence that the XEmacs performance problem
is solely tied up in the display.  Until the display is turned off
totally I'm willing to discount the differences in performance of the
other tests as well, since the byte-compile test involves a fair
amount of scribbling to the minibuffer.

Shane> I think I read an article by Steven Baur that said something
Shane> about byte compiles, and some other things being slow because
Shane> some part of the code was written in lisp for xemacs, where as
Shane> it's written in C for emacs.

This proved to be a false statement on my part.  The stuff I thought
was done in lisp turned out to be unused code.  On the other hand, I
am now aware of just how much optimizing the byte compiler does (*a
lot*) and am willing to trade off some performance on that for the
optimization, note that turning off optimization makes the performance
comparable to GNU Emacs 19.34, the speed demon.

Shane> I couldn't re-find the article to determine if it had anything
Shane> to do with display code.

It didn't.

We already know there were problems with the display code, it is good
to see that the engine appears to perform comparably, and once we lick
the display, we should be on a par speed-wise with Emacs again.

[1]
I don't have a handy 19.15 executable compiled with run-time debugging
turned off, that is *not* a fair comparison for benchmarking purposes.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 00:24:45 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA28729 for xemacs-beta-people; Mon, 18 Nov 1996 00:24:45 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA28726 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 00:24:43 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA12331 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 00:24:43 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA09347; Mon, 18 Nov 1996 00:24:37 -0600 (CST)
Message-Id: <199611180624.AAA09347@xemacs.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: Bench Marking XEmacs 
In-reply-to: Your message of "17 Nov 1996 20:43:04 PST."
             <m23ey8ypwn.fsf@deanna.miranova.com> 
Date: Mon, 18 Nov 1996 00:24:35 -0600
From: Chuck Thompson <cthomp@xemacs.org>

    Steven> We already know there were problems with the display code,
    Steven> it is good to see that the engine appears to perform
    Steven> comparably, and once we lick the display, we should be on
    Steven> a par speed-wise with Emacs again.

As I've said in the past but it seems to bear repeating: You will
_never_ get the XEmacs display engine to be as fast as the one in GNU
Emacs.  It is at least an order of magnitude more powerful and that
additional complexity comes with some additional overhead.

Also as I've said before do not assume that the slowness of redisplay
is actually within redisplay.  Being called incorrectly by the event
loop and excess running times of extent and specifier code have, in
the past, been where large chunks of the running time have actually
been.

This is not to say that there are not inefficiencies remaining in the
display code proper.  There most certainly are.  But before you start
spending time looking at the redisplay code to figure out where to
speed it up I suggest you do a bunch of Quantify runs to find out what
routines are actually eating up all of the time.


			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 03:57:17 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id DAA03019 for xemacs-beta-people; Mon, 18 Nov 1996 03:57:17 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id DAA03016 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 03:57:16 -0600 (CST)
Received: from jagor.srce.hr (jagor.srce.hr [161.53.2.130]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id DAA14740 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 03:56:55 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id VAA26611; Sun, 17 Nov 1996 21:35:28 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@cs.uiuc.edu
Cc: larsi@ifi.uio.no
Subject: Re: Making scroll-in-place the default
References: <m2enhu5x67.fsf@deanna.miranova.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 17 Nov 1996 21:35:27 +0100
In-Reply-To: Steven L Baur's message of 15 Nov 1996 23:14:24 -0800
Message-ID: <kigk9rkv4s0.fsf@jagor.srce.hr>
Lines: 16
X-Mailer: Red Gnus v0.63/XEmacs 19.14

Steven L. Baur (steve@miranova.com) wrote:
> NOTE:
> Gnus users will also want to do:
> (add-hook 'gnus-article-mode-hook 'turn-off-scroll-in-place)

Even with this, it doesn't work right with Gnus.  When I am at the end
of an article, and press SPC, it's fine.  But when it is the last
article, it doesn't want to exit the group.

Even `n' doesn't work when at the last article in a group.  Strange.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 04:13:42 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA03068 for xemacs-beta-people; Mon, 18 Nov 1996 04:13:42 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA03065 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 04:13:41 -0600 (CST)
Received: from jagor.srce.hr (root@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA09742 for <xemacs-beta@xemacs.org>; Mon, 18 Nov 1996 04:13:22 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id IAA17305; Mon, 18 Nov 1996 08:59:59 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: getloadavg.c
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 18 Nov 1996 08:59:57 +0100
Message-ID: <kighgmnltoi.fsf@jagor.srce.hr>
Lines: 101

It annoys me that on Solaris 2 you must be root to execute
(load-average).  So I played with a bit of old code, and changed
getloadavg() to work better on Solaris using rather obscure kstat
features.  With the following patch applied, every user can find the
average load.  This patch should probably be sent to bug-gnu-utils
too.

BTW, I think getloadavg() is very system-specific, and that its every
instance should be instanced.  This patch follows that practice.

Note that you must add -lkstat when linking, and that -lkvm is no
longer necessary.  I tested it, and it seems to work fine.

*** getloadavg.c.orig	Mon Nov 18 07:10:37 1996
--- getloadavg.c	Mon Nov 18 08:55:38 1996
***************
*** 382,391 ****
--- 382,397 ----
  #endif
  
  #include <stdlib.h>
+ #ifdef HAVE_UNISTD_H
  #include <unistd.h>
+ #endif
  
  #include <stdio.h>
  
+ #ifdef SUNOS_5
+ #include <kstat.h>
+ #endif
+ 
  /* LOAD_AVE_TYPE should only get defined if we're going to use the
     nlist method.  */
  #if !defined(LOAD_AVE_TYPE) && (defined(BSD) || defined(LDAV_CVT) || defined(KERNEL_FILE) || defined(LDAV_SYMBOL))
***************
*** 524,529 ****
--- 530,536 ----
     Return the number written (never more than 3, but may be less than NELEM),
     or -1 if an error occurred.  */
  
+ #ifndef SUNOS_5
  int
  getloadavg (double loadavg[], int nelem)
  {
***************
*** 973,978 ****
--- 980,1026 ----
  #endif
  }
  
+ #else /* SUNOS_5 */
+ /* getloadavg on SUNOS_5 is implemented using kstat (kernel stats),
+    thanks to Zlatko Calusic <zcalusic@srce.hr>.  Integrated to XEmacs
+    by Hrvoje Niksic <hniksic@srce.hr>.
+ 
+    You do not have to be the superuser for this function to work. */
+ int
+ getloadavg (double loadavg[], int nelem)
+ {
+   static kstat_ctl_t *kc;
+   static kstat_t *ksp;
+   static kstat_named_t *buf;
+   int elem;
+ 
+   if (!getloadavg_initialized)
+     {
+       kc = kstat_open();
+       if (!kc)
+         return -1;
+       getloadavg_initialized = 1;
+     }
+   ksp = kstat_lookup(kc, "unix", 0, "system_misc");
+   if (!ksp)
+       return -1;
+   if (kstat_read(kc, ksp, ksp->ks_data) < 0)
+     return -1;
+   buf = malloc(ksp->ks_data_size);
+   if (!buf)
+      return -1;
+   memcpy(buf, ksp->ks_data, ksp->ks_data_size);
+   if (nelem > 3)
+      nelem = 3;
+   for (elem = 0; elem < nelem; elem++)
+     loadavg[elem] = (buf + 6 + elem)->value.ul / 256.0;
+   free(buf);
+   return elem;
+ }
+ 
+ #endif /* SUNOS_5 */
+ 
+ 
  #endif /* ! HAVE_GETLOADAVG */
  
  #ifdef TEST


-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Contrary to popular belief, Unix is user friendly.  
It just happens to be selective about who it makes friends with.

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 04:33:14 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA03136 for xemacs-beta-people; Mon, 18 Nov 1996 04:33:14 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA03133 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 04:33:13 -0600 (CST)
Received: from jagor.srce.hr (root@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA09755 for <xemacs-beta@xemacs.org>; Mon, 18 Nov 1996 04:32:57 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.2/8.6.12.CI)
	id DAA24485; Mon, 18 Nov 1996 03:43:15 +0100 (MET)
Sender: hniksic@public.srce.hr
To: xemacs-beta@xemacs.org
Subject: Just a slight doc patchlet
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 18 Nov 1996 03:43:14 +0100
Message-ID: <kigzq0grum5.fsf@jagor.srce.hr>
Lines: 29

Of course, we do have format-time-string, so...

*** files.texi.orig     Mon Nov 18 03:36:57 1996
--- files.texi  Mon Nov 18 03:41:13 1996
***************
*** 1001,1008 ****
  is in the group with @sc{gid} 75.
  
  @item (8489 20284)
! was last accessed on Aug 19 00:09.  Unfortunately, you cannot convert
! this number into a time string in XEmacs.
  
  @item (8489 20284)
  was last modified on Aug 19 00:09.
--- 1001,1008 ----
  is in the group with @sc{gid} 75.
  
  @item (8489 20284)
! was last accessed on Aug 19 00:09.  Use @code{format-time-string} to
! convert this number into a time string.  @xref{Time Conversion}.
  
  @item (8489 20284)
  was last modified on Aug 19 00:09.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Contrary to popular belief, Unix is user friendly.  
It just happens to be selective about who it makes friends with.

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 06:17:59 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id GAA03434 for xemacs-beta-people; Mon, 18 Nov 1996 06:17:59 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id GAA03431 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 06:17:58 -0600 (CST)
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id GAA16788 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 06:17:57 -0600 (CST)
Received: (qmail 272 invoked by uid 52477); 18 Nov 1996 12:17:56 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@cs.uiuc.edu>
Cc: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Subject: Re: Making scroll-in-place the default
References: <m2enhu5x67.fsf@deanna.miranova.com> <kigk9rkv4s0.fsf@jagor.srce.hr>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sudish@mindspring.com>
Date: 18 Nov 1996 07:17:56 -0500
In-Reply-To: Hrvoje Niksic's message of 17 Nov 1996 21:35:27 +0100
Message-ID: <yvia7mnjha17.fsf@atreides.mindspring.com>
Lines: 9
X-Mailer: Red Gnus v0.62/XEmacs 19.15

Hrvoje Niksic <hniksic@srce.hr> writes:
> Even with this, it doesn't work right with Gnus.  When I am at the end
> of an article, and press SPC, it's fine.  But when it is the last
> article, it doesn't want to exit the group.

I've been using this for a year (a least) and haven't had any
problems.  Did you (setq scroll-allow-blank-lines-past-eob t)?

-Sudish

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 09:59:09 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id JAA04120 for xemacs-beta-people; Mon, 18 Nov 1996 09:59:09 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id JAA04117 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 09:59:08 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id JAA24665 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 09:59:06 -0600 (CST)
Received: (qmail 3825 invoked by uid 501); 18 Nov 1996 16:01:32 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Making scroll-in-place the default
References: <m2enhu5x67.fsf@deanna.miranova.com> <kigk9rkv4s0.fsf@jagor.srce.hr>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Hrvoje Niksic's message of 17 Nov 1996 21:35:27 +0100
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Nov 1996 08:01:31 -0800
Message-ID: <m23ey7qtno.fsf@deanna.miranova.com>
Lines: 71
X-Mailer: Red Gnus v0.63/XEmacs 19.15

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Steven L. Baur (steve@miranova.com) wrote:
sb> NOTE:
sb> Gnus users will also want to do:
sb> (add-hook 'gnus-article-mode-hook 'turn-off-scroll-in-place)

Hrv> Even with this, it doesn't work right with Gnus.  When I am at the end
Hrv> of an article, and press SPC, it's fine.  But when it is the last
Hrv> article, it doesn't want to exit the group.

Hrv> Even `n' doesn't work when at the last article in a group.  Strange.

This patch will be in Red Gnus v0.64.  The problem has nothing to do
with scroll-in-place.

To: gnus-bug@ifi.uio.no (The Gnus Bugfixing Girls + Boys)
Subject: XEmacs doesn't use integers for keyboard events
>From: Steven L Baur <steve@miranova.com>
Date: 16 Nov 1996 22:08:51 -0800
Message-ID: <m2pw1dz218.fsf@deanna.miranova.com>
X-Mailer: Red Gnus v0.63/XEmacs 19.15

Red Gnus v0.63; nntp 5.0; nnml 1.0; nnmh 1.0; nndir 1.0; nndoc 1.0; nnfolder 1.0
XEmacs 19.15 [Lucid] (i486-unknown-linux2.0.18) of Fri Nov 15 1996 on deanna.miranova.com

This patch fixes the bug I just reported.  (n and SPC not offering to
advance to next group).

===================================================================
RCS file: RCS/ChangeLog,v
retrieving revision 1.60
diff -u -r1.60 ChangeLog
--- ChangeLog	1996/11/16 20:54:06	1.60
+++ ChangeLog	1996/11/17 06:06:06
@@ -1,3 +1,8 @@
+Sat Nov 16 22:05:24 1996  Steven L Baur  <steve@miranova.com>
+
+	* gnus-sum.el (gnus-summary-next-article): XEmacs doesn't use
+	integers for keyboard events.
+
 Sat Nov 16 11:32:43 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>
 
 	* gnus-sum.el (gnus-summary-next-article): Ignore non-keyboard


===================================================================
RCS file: RCS/gnus-sum.el,v
retrieving revision 1.45
diff -u -r1.45 gnus-sum.el
--- gnus-sum.el	1996/11/16 20:54:06	1.45
+++ gnus-sum.el	1996/11/17 06:02:39
@@ -5332,7 +5332,9 @@
 			  "exiting"))
 	  (gnus-summary-next-group nil group backward)))
        (t
-	(when (numberp last-input-event)
+	(when (or (numberp last-input-event)
+		  (and (fboundp 'key-press-event-p)
+		       (key-press-event-p last-input-event)))
 	  (gnus-summary-walk-group-buffer
 	   gnus-newsgroup-name cmd unread backward))))))))
 

 ...

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 10:18:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA04197 for xemacs-beta-people; Mon, 18 Nov 1996 10:18:41 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA04194 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 10:18:40 -0600 (CST)
Received: from neal.ctd.comsat.com (exim@neal.ctd.comsat.com [134.133.40.21]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA10208 for <xemacs-beta@xemacs.org>; Mon, 18 Nov 1996 10:18:37 -0600 (CST)
Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2)
	id 0vPWP4-0003e1-00; Mon, 18 Nov 1996 11:18:34 -0500
From: Neal Becker <neal@ctd.comsat.com>
To: xemacs-beta@xemacs.org
Subject: images slow?
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.92)
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E0vPWP4-0003e1-00@neal.ctd.comsat.com>
Date: Mon, 18 Nov 1996 11:18:34 -0500

Has anyone noticed that loading of jpegs seems to be incredibly slow?
I notice that image loading with 'tm' seems to take unbelievable
amounts of time.  I haven't tried to track down why.

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 10:41:26 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA04297 for xemacs-beta-people; Mon, 18 Nov 1996 10:41:26 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA04294 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 10:41:25 -0600 (CST)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA25522 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 10:41:24 -0600 (CST)
Received: from jaguar.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id JAA00385; Mon, 18 Nov 1996 09:41:23 -0700
Received: by jaguar.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id JAA07779; Mon, 18 Nov 1996 09:41:22 -0700
Date: Mon, 18 Nov 1996 09:41:22 -0700
From: eeide@jaguar.cs.utah.edu (Eric Eide)
Message-Id: <199611181641.JAA07779@jaguar.cs.utah.edu>
To: xemacs-beta@cs.uiuc.edu
In-reply-to: Hrvoje Niksic's message of , Nov 16 <kign2whom4c.fsf@jagor.srce.hr>
Subject: Re: Making scroll-in-place the default

Hrvoje Niksic <hniksic@srce.hr> writes:

	Hrvoje> Can you post it as a lisp package -- does it have to be
	Hrvoje> preloaded?

`scroll-in-place' comes with XEmacs 19.14.  You can get it from the Ohio
State Emacs Lisp Archive and the following URL:

	http://www.cs.utah.edu/~eeide/emacs/scroll-in-place.el.gz

All of the versions are identical (I hope!).  If I start hacking on it again,
the copy I publish will hopefully improve :-).

And no, it doesn't have to be preloaded.  It overrides Emacs' built-in
scrolling functions.  (Probably should use advice, but s-i-p predates advice.)

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 10:49:52 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA04344 for xemacs-beta-people; Mon, 18 Nov 1996 10:49:52 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA04341 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 10:49:51 -0600 (CST)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA25865 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 10:49:50 -0600 (CST)
Received: from jaguar.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id JAA00687; Mon, 18 Nov 1996 09:49:43 -0700
Received: by jaguar.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id JAA07807; Mon, 18 Nov 1996 09:49:41 -0700
Date: Mon, 18 Nov 1996 09:49:41 -0700
From: eeide@jaguar.cs.utah.edu (Eric Eide)
Message-Id: <199611181649.JAA07807@jaguar.cs.utah.edu>
To: steve@miranova.com, xemacs-beta@cs.uiuc.edu
In-reply-to: Steven L Baur's message of , Nov 16 <m2g229hctt.fsf@deanna.miranova.com>
Subject: Re: scroll-in-place gotcha

[This message is basically a repeat of things I've said in previous messages.]

Steven L Baur <steve@miranova.com> writes:

	Steven> The buffer cycles around as before.  What is your setting of
	Steven> scroll-allow-blank-lines-past-eob?  The new default will be t.

I would prefer the default to stay `nil'.  Why do you believe the default
should change?

	Steven> The fix though is to add
	Steven> (add-hook 'list-mode-hook 'turn-off-scroll-in-place)
	Steven> to the initialization.

I will try to figure out what the incompatibility is.  In the meantime, I also
suggest removing the "\M-v" bindings that "list-mode" sticks in the minibuffer
keymaps.

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 10:53:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA04362 for xemacs-beta-people; Mon, 18 Nov 1996 10:53:13 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA04359 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 10:53:12 -0600 (CST)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA25957 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 10:53:11 -0600 (CST)
Received: from jaguar.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id JAA00790; Mon, 18 Nov 1996 09:53:10 -0700
Received: by jaguar.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id JAA07821; Mon, 18 Nov 1996 09:53:09 -0700
Date: Mon, 18 Nov 1996 09:53:09 -0700
From: eeide@jaguar.cs.utah.edu (Eric Eide)
Message-Id: <199611181653.JAA07821@jaguar.cs.utah.edu>
To: turner@lanl.gov, steve@miranova.com
CC: xemacs-beta@cs.uiuc.edu
In-reply-to: John Turner's message of Sat, Nov 16 <199611170505.WAA01187@branagh.lanl.gov>
Subject: Re: scroll-in-place gotcha

John Turner (turner@lanl.gov) writes:

	John> Also note that scroll-in-place doesn't play nicely with VM.

At one time I had a patch (to VM) that fixed the incompatibility.  The patch
was never officially published, and probably needs to be revised for current
versions of VM.

I will review the email messages that Kyle Jones and I exchanged at the time
and try to revise the patch.  I'll keep you posted.  Bug me if I don't.

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 10:35:40 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA04277 for xemacs-beta-people; Mon, 18 Nov 1996 10:35:40 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA04274 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 10:35:39 -0600 (CST)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA25406 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 10:35:39 -0600 (CST)
Received: from jaguar.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id JAA00258; Mon, 18 Nov 1996 09:35:38 -0700
Received: by jaguar.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id JAA07775; Mon, 18 Nov 1996 09:35:37 -0700
Date: Mon, 18 Nov 1996 09:35:37 -0700
From: eeide@jaguar.cs.utah.edu (Eric Eide)
Message-Id: <199611181635.JAA07775@jaguar.cs.utah.edu>
To: xemacs-beta@cs.uiuc.edu
In-reply-to: Steven L Baur's message of , Nov 15 <m2enhu5x67.fsf@deanna.miranova.com>
Subject: Re: Making scroll-in-place the default

Steven L Baur <steve@miranova.com> writes:

	Steven> + (add-hook 'vm-mode-hook 'turn-off-scroll-in-place)
	Steven> + (add-hook 'vm-select-message-hook 'turn-off-scroll-in-place)
	Steven> + (add-hook 'vm-summary-mode-hook 'turn-off-scroll-in-place)
	Steven> + ;; (add-hook 'gnus-article-mode-hook
        Steven>                'turn-off-scroll-in-place)

If `scroll-in-place' is to be the default behavior, then it would be preferable
to fix the incompatibilities with Gnus, VM, List mode, et al.  At one time I
had a fix for VM, but it probably needs to be revised.  I haven't ever examined
the internals of Gnus' scrolling code.  (Personally, I never have a problem
with Gnus/s-i-p.  Maybe it's because I don't use the critical feature.)

The issue of variable-height lines is also unresolved in the current code.

I am willing to tackle the incompatibilities again, especially if people have
an interest in making `scroll-in-place' the default behavior.

	Steven> ! (defvar scroll-allow-blank-lines-past-eob t

Hiding post-eob blank lines is a feature.  What is wrong with the current
default value?  Not surprisingly, I prefer `nil' as the default.

	Steven> + ;; Hook functions to make turning the mode on and off easier.
	Steven> + (defun turn-on-scroll-in-place ()
	Steven> +   "Unconditionally turn on scroll-in-place mode."
	Steven> +   (set (make-local-variable 'scroll-in-place) t))
	Steven> + 
	Steven> + (defun turn-off-scroll-in-place ()
	Steven> +   "Unconditionally turn on scroll-in-place mode."
	Steven> +   (set (make-local-variable 'scroll-in-place) nil))

I would suggest checking buffer-localness and then setting either the local or
global --- rather than always making the switch local.  In place scrolling is
supposed to be a "standard behavior," not a minor mode.

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 10:47:39 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA04316 for xemacs-beta-people; Mon, 18 Nov 1996 10:47:39 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA04313 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 10:47:36 -0600 (CST)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA10289 for <xemacs-beta@xemacs.org>; Mon, 18 Nov 1996 10:47:33 -0600 (CST)
Received: from jaguar.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id JAA00583; Mon, 18 Nov 1996 09:46:07 -0700
Received: by jaguar.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id JAA07800; Mon, 18 Nov 1996 09:45:57 -0700
Date: Mon, 18 Nov 1996 09:45:57 -0700
From: eeide@jaguar.cs.utah.edu (Eric Eide)
Message-Id: <199611181645.JAA07800@jaguar.cs.utah.edu>
To: hniksic@srce.hr, xemacs-beta@xemacs.org
In-reply-to: Hrvoje Niksic's message of , Nov 16 <kigbucxu1n0.fsf@jagor.srce.hr>
Subject: Re: scroll-in-place gotcha

Hrvoje Niksic (hniksic@srce.hr) writes:

	Hrvoje> As I have said, [scroll-in-place] works like a charm, except at
	Hrvoje> one place: press `C-x C-f /usr/local/lib/', and press TAB
	Hrvoje> several times in a row.  Things that happen are the result of
	Hrvoje> scroll-in-place, I believe.

I will look into this.

Personally, I never complete with TAB.  `s-i-p' allows you to scroll the
completions list with `M-v' and `C-v', although a recent XEmacs "improvement"
gets in the way of this.  In my `.emacs' I do:

	(define-key minibuffer-local-completion-map "\M-v" nil)
	(define-key minibuffer-local-must-match-map "\M-v" nil)

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 11:09:18 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id LAA04429 for xemacs-beta-people; Mon, 18 Nov 1996 11:09:18 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id LAA04426 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 11:09:17 -0600 (CST)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id LAA10553 for <xemacs-beta@xemacs.org>; Mon, 18 Nov 1996 11:09:13 -0600 (CST)
Received: from ouzo.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id KAA01203; Mon, 18 Nov 1996 10:09:13 -0700
Received: by ouzo.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id KAA02454; Mon, 18 Nov 1996 10:08:24 -0700
Date: Mon, 18 Nov 1996 10:08:24 -0700
Message-Id: <199611181708.KAA02454@ouzo.cs.utah.edu>
From: Eric Eide <eeide@cs.utah.edu>
To: XEmacs Beta Testers <xemacs-beta@xemacs.org>
Subject: `scroll-in-place' as Default?

(For those who don't recognize my name, I'm the author of `scroll-in-place'.)

I am willing to revise `scroll-in-place' to make it more suitable as a default
behavior.  This work would entail fixing various known incompatibilities with
VM, Gnus, List mode, etc.  I would suggest not making `scroll-in-place' the
default behavior until at least most of these package incompatibilities are
resolved.

An open issue, however, is that `scroll-in-place' isn't smart about variable
height lines.  I haven't thought about this very much; proposals are welcome.
(What does in-place mean in a variable-height, variable-width world?)

I don't know how severe the variable-height line problem is in practice.  For
me, it's almost never an issue because I use a single font and size almost
exclusively.  I suppose that for other people, however, an inability to cope
with variable-height lines could be a real barrier to usability.

Solving package incompatibilites is generally just a matter of hacking.
Solving the line-height problem, however, may require more fundamental
redesign.  I don't know if `scroll-in-place' should be default if it can't deal
with variable-height lines; opinions welcome.

Eric.

PS --- Also, if this is planned for 19.15, could somebody remind me of the
currently planned 19.15 development schedule?

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 12:10:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA04791 for xemacs-beta-people; Mon, 18 Nov 1996 12:10:54 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA04788 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 12:10:53 -0600 (CST)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA10919 for <xemacs-beta@xemacs.org>; Mon, 18 Nov 1996 12:10:48 -0600 (CST)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.8.2/8.8.2) with ESMTP id MAA03841; Mon, 18 Nov 1996 12:09:47 -0600 (CST)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id MAA29125; Mon, 18 Nov 1996 12:09:46 -0600 (CST)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id NAA05509; Mon, 18 Nov 1996 13:09:46 -0500
To: Eric Eide <eeide@cs.utah.edu>
cc: XEmacs Beta Testers <xemacs-beta@xemacs.org>
References: <199611181708.KAA02454@ouzo.cs.utah.edu> 
Subject: Re: `scroll-in-place' as Default? 
In-reply-to: (Your message of Mon, 18 Nov 1996 10:08:24 MST.)
             <199611181708.KAA02454@ouzo.cs.utah.edu> 
Mime-Version: 1.0 (generated by tm-edit 7.88)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 18 Nov 1996 13:09:45 -0500
Message-ID: <4390.848340585@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Eric" == Eric Eide <eeide@cs.utah.edu> writes:

    Eric> I don't know how severe the variable-height line problem is
    Eric> in practice.  For me, it's almost never an issue because I
    Eric> use a single font and size almost exclusively.  I suppose
    Eric> that for other people, however, an inability to cope with
    Eric> variable-height lines could be a real barrier to usability.

I also use a single font and a single size, and s-i-p is fantastic 99
44/100% of the time.  (I've used it ever since it was originally
released).

The only place it's annoying to me is reading mail with x-faces.
s-i-p doesn't do the right thing.  Either it scrolls too much and I
miss a few lines or it won't scroll at all so I can't see the last
line or two of the message.  I think anything is better than what it
does now.  I can live with not seeing the last line of a message, but
skipping lines while scrolling is quite annoying, because sometimes I
can't tell that it's happened.

Ray

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 12:06:02 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA04732 for xemacs-beta-people; Mon, 18 Nov 1996 12:06:02 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA04729 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 12:06:01 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id MAA29247 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 12:05:59 -0600 (CST)
Received: (qmail 5100 invoked by uid 501); 18 Nov 1996 18:08:28 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Making scroll-in-place the default
References: <199611181635.JAA07775@jaguar.cs.utah.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: eeide@jaguar.cs.utah.edu's message of Mon, 18 Nov 1996 09:35:37 -0700
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Nov 1996 10:08:27 -0800
Message-ID: <m2ralrp97o.fsf@deanna.miranova.com>
Lines: 75
X-Mailer: Red Gnus v0.63/XEmacs 19.15

Eric:  All your messages on this thread have just arrived in a big
batch.

>>>>> "Eric" == Eric Eide <eeide@jaguar.cs.utah.edu> writes:

Eric> Steven L Baur <steve@miranova.com> writes:
Steven> + (add-hook 'vm-mode-hook 'turn-off-scroll-in-place)
Steven> + (add-hook 'vm-select-message-hook 'turn-off-scroll-in-place)
Steven> + (add-hook 'vm-summary-mode-hook 'turn-off-scroll-in-place)
Steven> + ;; (add-hook 'gnus-article-mode-hook
Steven> 'turn-off-scroll-in-place)

Eric> If `scroll-in-place' is to be the default behavior, then it
Eric> would be preferable to fix the incompatibilities with Gnus, VM,
Eric> List mode, et al.

The critical incompatibility in Gnus & list-mode is based on the
assumption that scroll-up will eventually get (point) to (point-max).
I don't know about VM.

Eric> The issue of variable-height lines is also unresolved in the
Eric> current code.

Eric> I am willing to tackle the incompatibilities again, especially
Eric> if people have an interest in making `scroll-in-place' the
Eric> default behavior.

I believe there is.  It is quite fast, I like the fact that doing C-v
M-v in successive operations returns (point) to its original
position.

Steven> ! (defvar scroll-allow-blank-lines-past-eob t

Eric> Hiding post-eob blank lines is a feature.  What is wrong with
Eric> the current default value?  Not surprisingly, I prefer `nil' as
Eric> the default.

It violates the principle of least surprise.  When I hit C-v (or the
Page Down function key) I expect to see the cursor move towards the
end of the buffer.  When that flag is nil, doing that operation can
result in the cursor going in the wrong direction.  Note that the
situation on the other side works exactly as expected.  The cursor
*will* move to the top of the buffer.

Now, possible patches to fix this (while keeping that variable nil)
would include moving the cursor to the end of the buffer, but not
recentering the line in the window.  Or, instead of moving the cursor
in the wrong direction on the final scroll-up, just leaving it in
place.  I suspect making the former behavior work would solve the Gnus
and list-mode problems.

Steven> + ;; Hook functions to make turning the mode on and off easier.
Steven> + (defun turn-on-scroll-in-place ()
Steven> +   "Unconditionally turn on scroll-in-place mode."
Steven> +   (set (make-local-variable 'scroll-in-place) t))
Steven> + 
Steven> + (defun turn-off-scroll-in-place ()
Steven> +   "Unconditionally turn on scroll-in-place mode."
Steven> +   (set (make-local-variable 'scroll-in-place) nil))

Eric> I would suggest checking buffer-localness and then setting
Eric> either the local or global --- rather than always making the
Eric> switch local.  In place scrolling is supposed to be a "standard
Eric> behavior," not a minor mode.

Noted, although I'm not sure what you describe is a win.

scroll-in-place is a very nice feature, and I think it would be
reasonable to make it the default behavior.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 12:33:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA04926 for xemacs-beta-people; Mon, 18 Nov 1996 12:33:43 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA04923 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 12:33:41 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id MAA29859 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 12:33:41 -0600 (CST)
Received: (qmail 5585 invoked by uid 501); 18 Nov 1996 18:36:11 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: `scroll-in-place' as Default?
References: <199611181708.KAA02454@ouzo.cs.utah.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Eric Eide's message of Mon, 18 Nov 1996 10:08:24 -0700
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Nov 1996 10:36:10 -0800
Message-ID: <m2ohgvp7xh.fsf@deanna.miranova.com>
Lines: 37
X-Mailer: Red Gnus v0.63/XEmacs 19.15

>>>>> "Eric" == Eric Eide <eeide@cs.utah.edu> writes:
 ...
 [I addressed most of these points already]

Eric> An open issue, however, is that `scroll-in-place' isn't smart
Eric> about variable height lines.  I haven't thought about this very
Eric> much; proposals are welcome.  (What does in-place mean in a
Eric> variable-height, variable-width world?)

I'm using variably sized fonts and haven't had a problem so far.  We
will have to take a close look at W3 and TM though.

 ...

A final question is:
Are there any problems with copyright assigning scroll-in-place.el to
the FSF?

Eric> PS --- Also, if this is planned for 19.15, could somebody remind
Eric> me of the currently planned 19.15 development schedule?

Beta 3 will be out this week sometime.  I'd like to see 19.15 released
formally by the end of the year (Merry X-mas!), but that may not be
doable.  I do not think we should release 19.15 until the performance
issues have been addressed.

There is no 19.16 formally planned.  Work on v19 will stop and all
efforts will be put on 20.0.  /If/ severe enough problems are found
with 19.15 before 20.0 is completely stable, there will be (a)
maintenance release(s), until it is.  Given Martin's opinion on the
stability of 20.0, I _strongly_ doubt there will be a 19.16.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 12:44:13 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA04989 for xemacs-beta-people; Mon, 18 Nov 1996 12:44:13 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA04984 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 12:44:12 -0600 (CST)
Received: from sym.primuscorp.com (root@[207.14.28.20]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id MAA00076 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 12:44:11 -0600 (CST)
Received: from horus (horus.primuscorp.com [198.187.136.23]) by sym.primuscorp.com (8.6.11/8.6.9) with ESMTP id KAA11676; Mon, 18 Nov 1996 10:46:41 -0800
Received: from roy by horus (SMI-8.6/SMI-SVR4)
	id KAA29987; Mon, 18 Nov 1996 10:44:23 -0800
Received: by roy (SMI-8.6/SMI-SVR4)
	id KAA25648; Mon, 18 Nov 1996 10:44:25 -0800
Date: Mon, 18 Nov 1996 10:44:25 -0800
Message-Id: <199611181844.KAA25648@roy>
From: Damon Lipparelli <lipp@primus.com>
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@cs.uiuc.edu
Subject: Re: `scroll-in-place' as Default?
In-Reply-To: <m2ohgvp7xh.fsf@deanna.miranova.com>
References: <199611181708.KAA02454@ouzo.cs.utah.edu>
	<m2ohgvp7xh.fsf@deanna.miranova.com>
Reply-To: Damon Lipparelli <lipp@primus.com>
Organization: Primus Communications Corporation
X-Mailer: VM 5.96 (beta) [ XEmacs 19.15 (beta2) ]
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

> Beta 3 will be out this week sometime.  I'd like to see 19.15 released
> formally by the end of the year (Merry X-mas!), but that may not be
> doable.  I do not think we should release 19.15 until the performance
> issues have been addressed.

Has there been an administrative change w.r.t. to XEmacs?  Is Chuck no
longer maintaining things?

Just curious,
-lipp

ps: Are you expecting 20.0 b30 out this week, as well?

---

Concentrate on th'cute, li'l CARTOON GUYS!
 Remember the SERIAL NUMBERS!!  Follow the WHIPPLE AVE EXIT!!
 Have a FREE PEPSI!!  Turn LEFT at th'HOLIDAY INN!!
 JOIN the CREDIT WORLD!!  MAKE me an OFFER!!!

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 12:52:47 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA05091 for xemacs-beta-people; Mon, 18 Nov 1996 12:52:47 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA05088 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 12:52:46 -0600 (CST)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id MAA00487 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 12:52:44 -0600 (CST)
Received: from jaguar.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id LAA04455; Mon, 18 Nov 1996 11:52:40 -0700
Received: by jaguar.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id LAA08224; Mon, 18 Nov 1996 11:52:39 -0700
Date: Mon, 18 Nov 1996 11:52:39 -0700
From: eeide@jaguar.cs.utah.edu (Eric Eide)
Message-Id: <199611181852.LAA08224@jaguar.cs.utah.edu>
To: steve@miranova.com, xemacs-beta@cs.uiuc.edu
In-reply-to: Steven L Baur's message of , Nov 18 <m2ralrp97o.fsf@deanna.miranova.com>
Subject: Re: Making scroll-in-place the default

Steven L Baur <steve@miranova.com> writes:

	Steven> The critical incompatibility in Gnus & list-mode is based on
	Steven> the assumption that scroll-up will eventually get (point) to
	Steven> (point-max).  I don't know about VM.

Really?  I'll investigate.  I haven't used the scrolling builtins for a long
time, but I don't remember that they were guaranteed to move point to
point-max.  Rather, they simply signalled an error when eob was visible.
`s-i-p' does that, too, when the window being scrolled isn't the selected
window.

	Eric> Hiding post-eob blank lines is a feature.  What is wrong with
	Eric> the current default value?  Not surprisingly, I prefer `nil' as
	Eric> the default.

	Steven> It violates the principle of least surprise.  When I hit C-v
	Steven> (or the Page Down function key) I expect to see the cursor move
	Steven> towards the end of the buffer.  When that flag is nil, doing
	Steven> that operation can result in the cursor going in the wrong
	Steven> direction.  Note that the situation on the other side works
	Steven> exactly as expected.  The cursor *will* move to the top of the
	Steven> buffer.

If you are seeing this behavior, it is probably because XEmacs is recentering
point out from under `s-i-p'.  (`s-i-p' moves point onto the last line of the
window, which is clipped.  XEmacs detects that point is on a clipped line and
moves point.)

You are correct that C-v should never cause point to appear to move up, and I
believe that the current `s-i-p' code implements that behavior.  It's XEmacs
that is getting in the way :-).  Not only is the apparent behavior confusing;
it breaks the reversibility property.

If I have diagnosed the cause correctly, then setting the post-eob-lines flag
to `nil' won't fix the problem in all cases.  My solution to this problem
follows:

  + In `.emacs':

      (setq scroll-on-clipped-lines nil)
      (setq pixel-vertical-clip-threshold 12) ;; I use 12pt fonts.

  + Patch the function `scroll-window-in-place' to use XEmacs' function
    `window-displayed-height'.  I can't make a real patch at the moment, but
    one must change the initialization form for the local variable
    `window-height' to be this:

	 (window-height (if (fboundp 'window-displayed-height)
			    (window-displayed-height window)
			  (- (window-height window)
			     (if (if (fboundp 'window-minibuffer-p)
				     ;; The v19 idiom.
				     (window-minibuffer-p window)
				   ;; The v18 idiom.
				   (eq window (minibuffer-window)))
				 0 1))))

I've been using `s-i-p' with these changes for some time and haven't seen
XEmacs forcibly recenter point since.  If you make these changes and the
point-moves-up problem persists, let me know.  (A test case would help, too!)

Kepp those cards and letters coming :-)!

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 13:03:44 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA05146 for xemacs-beta-people; Mon, 18 Nov 1996 13:03:44 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA05143 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 13:03:43 -0600 (CST)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id NAA00757 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 13:03:43 -0600 (CST)
Received: from jaguar.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id MAA04856; Mon, 18 Nov 1996 12:03:39 -0700
Received: by jaguar.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id MAA08259; Mon, 18 Nov 1996 12:03:38 -0700
Date: Mon, 18 Nov 1996 12:03:38 -0700
From: eeide@jaguar.cs.utah.edu (Eric Eide)
Message-Id: <199611181903.MAA08259@jaguar.cs.utah.edu>
To: steve@miranova.com, xemacs-beta@cs.uiuc.edu
In-reply-to: Steven L Baur's message of , Nov 18 <m2ohgvp7xh.fsf@deanna.miranova.com>
Subject: Re: `scroll-in-place' as Default?

Steven L Baur <steve@miranova.com> writes:

	Steven> Are there any problems with copyright assigning
	Steven> scroll-in-place.el to the FSF?

I wrote `scroll-in-place' while I was a graduate student at the University of
Utah --- in my own time, but using the University's resources.  I will have to
ask around to see what if any claims the University could claim/would want to
assert.  I can't imagine that the University cares, but I know that the FSF
would want signed papers saying so.

I don't want to do the legwork on speculation that the FSF wants the code.  I'm
willing to do it once a request is made.

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 13:14:54 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id NAA05230 for xemacs-beta-people; Mon, 18 Nov 1996 13:14:54 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA05227 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 13:14:53 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA01233 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 13:14:53 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id NAA11096; Mon, 18 Nov 1996 13:14:47 -0600 (CST)
Message-Id: <199611181914.NAA11096@xemacs.cs.uiuc.edu>
To: Damon Lipparelli <lipp@primus.com>
cc: xemacs-beta@cs.uiuc.edu
Subject: Re: `scroll-in-place' as Default? 
In-reply-to: Your message of "Mon, 18 Nov 1996 10:44:25 PST."
             <199611181844.KAA25648@roy> 
Date: Mon, 18 Nov 1996 13:14:46 -0600
From: Chuck Thompson <cthomp@xemacs.org>

    Damon> Has there been an administrative change w.r.t. to XEmacs?
    Damon> Is Chuck no longer maintaining things?

That is the direction we're moving.  The next beta releases will be my
last.  I'll give full details when I get the next betas out which will
be sometime late this week.  I am actually working on them.



			-Chuck

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 14:27:33 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA05577 for xemacs-beta-people; Mon, 18 Nov 1996 14:27:33 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA05574 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 14:27:32 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id OAA03031 for <xemacs-beta@cs.uiuc.edu>; Mon, 18 Nov 1996 14:27:31 -0600 (CST)
Received: (qmail 7991 invoked by uid 501); 18 Nov 1996 20:29:58 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Making scroll-in-place the default
References: <199611181852.LAA08224@jaguar.cs.utah.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: eeide@jaguar.cs.utah.edu's message of Mon, 18 Nov 1996 11:52:39 -0700
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
Date: 18 Nov 1996 12:29:57 -0800
Message-ID: <m2iv73b0ze.fsf@deanna.miranova.com>
Lines: 39
X-Mailer: Red Gnus v0.63/XEmacs 19.15

>>>>> "Eric" == Eric Eide <eeide@jaguar.cs.utah.edu> writes:

Eric> Steven L Baur <steve@miranova.com> writes:

Eric> I've been using `s-i-p' with these changes for some time and
Eric> haven't seen XEmacs forcibly recenter point since.  If you make
Eric> these changes and the point-moves-up problem persists, let me
Eric> know.  (A test case would help, too!)

Eric> Kepp those cards and letters coming :-)!

Try these bits of advice as well.  They work for me with s-i-p,
resolve a many-times-asked FAQ, and make the scroll-up and scroll-down
commands more friendly in that they won't trash the zmacs region
(motion commands should not turn off selection).

(defadvice scroll-up (around scroll-up freeze)
  (interactive "_P")
  (let ((zmacs-region-stays t))
    (if (interactive-p)
	(condition-case nil
	    ad-do-it
	  (end-of-buffer (goto-char (point-max))))
      ad-do-it)))

(defadvice scroll-down (around scroll-down freeze)
  (interactive "_P")
  (let ((zmacs-region-stays t))
    (if (interactive-p)
	(condition-case nil
	    ad-do-it
	  (beginning-of-buffer (goto-char (point-min))))
      ad-do-it)))

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Mon Nov 18 22:16:00 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id WAA07038 for xemacs-beta-people; Mon, 18 Nov 1996 22:16:00 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id WAA07035 for <xemacs-beta@spruce.cs.uiuc.edu>; Mon, 18 Nov 1996 22:15:58 -0600 (CST)
Received: from sweden.aosi.com (mail.aosi.com [206.98.255.22]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id WAA11799 for <xemacs-beta@xemacs.org>; Mon, 18 Nov 1996 22:15:56 -0600 (CST)
Received: from hlork ([206.98.254.35]) by sweden.aosi.com
          (post.office MTA v1.9.3b ID# 0-16356) with SMTP id AAA156;
          Mon, 18 Nov 1996 23:15:52 -0500
Sender: root@.aosi.com
Message-ID: <32913633.CF00CA2@aosi.com>
Date: Mon, 18 Nov 1996 23:23:16 -0500
From: Joel Peterson <tarzan@aosi.com>
Organization: Me Tarzan, you Jane?
X-Mailer: Mozilla 3.0 (X11; U; Linux 1.3.97 i586)
MIME-Version: 1.0
To: Steven L Baur <steve@miranova.com>, xemacs-beta@xemacs.org
Subject: Re: `frame in a glyph'
References: <199611130558.VAA20443@infodock.com> <328D0481.3B351894@aosi.com> <m2iv76iw7o.fsf@deanna.miranova.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steven L Baur wrote:
> >>>>> "Joel" == Joel Peterson <tarzan@aosi.com> writes:
> 
> Joel> I wrote a huge amount of very hoary lisp code to manage a
> Joel> draggable spreadsheet table embedded within an emacs buffer.
> Joel> The user can click on the `title bar' of the table and drag it
> Joel> to another location within the text.
> 
> You've implemented drag & drop within XEmacs? :-) Please say that part
> of the code is available.  If we had drag & drop there are all sorts
> of cool things we could do.  I have visions of the day I'll be able to
> select a bunch of messages in Gnus by mouse and drag them into a
> wastebasket icon.

What I have now is drag & drop within a buffer (which isn't *that* hard
:-]).  I am planning on adding `real' drag & drop support using OffiX
(making XEmacs a drag source and a more sophisticated drop site).  I
haven't had time to really look at the OffiX protocol to see if it will
meet my needs, but I suspect that it will.  My idea was to add a
draggable property to extents which would either indicate that the
extent contents are the data or give a function to call to get the
data.  I'm not sure when I'll be able to do this; it might be next year,
it might be tomorrow.  In either case, I'm sure the code will be made
available.

> The current planning on future versions of XEmacs has XEmacs 19.15
> being the last of the v19's so we can drop the dual code bases as
> soon as we can.  For this reason, it is not a good idea to introduce
> destabilizing patches into it.  I would like to see this patch get
> into the v20 baseline when feasible, since it sounds very much like A
> Good Thing.

I actually wanted to develop this for v20 originally, but I have to
deliver a product in December, and there wasn't enough time to move my
other stuff over.  I'll have to eventually, since international support
is on the `necessary features' list for the future.

-- 
"The Secret to Procastination is...
 I'll finish this later.  I wonder what's on TV?"
                - Joel Peterson
                       Supreme Deputy of scratching Dogbert behind the
                       ears until he has little leg spasms.

From xemacs-beta-request@cs.uiuc.edu  Tue Nov 19 00:58:03 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA07508 for xemacs-beta-people; Tue, 19 Nov 1996 00:58:03 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA07505 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 19 Nov 1996 00:58:02 -0600 (CST)
Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA11980 for <xemacs-beta@xemacs.org>; Tue, 19 Nov 1996 00:57:58 -0600 (CST)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.8.2/8.7.3) with ESMTP id WAA28776 for <xemacs-beta@xemacs.org>; Mon, 18 Nov 1996 22:54:37 -0800 (PST)
Received: from 666.com (shellx.best.com [206.86.0.11]) by shellx.best.com (8.8.3/8.7.3) with SMTP id WAA15066 for <xemacs-beta@xemacs.org>; Mon, 18 Nov 1996 22:52:55 -0800 (PST)
Date: Mon, 18 Nov 1996 22:52:55 -0800 (PST)
Message-Id: <199611190652.WAA15066@shellx.best.com>
From: Ben Wing <ben@666.com>
To: xemacs-beta@xemacs.org, Bob Weiner <weiner@infodock.com>,
        Joel Peterson
    <tarzan@aosi.com>
Subject: Re: `frame in a glyph'
References: <199611130558.VAA20443@infodock.com>

This sounds like great work!  It's something like I once imagined
should be added to xemacs, but never had the chance to do it...
Hopefully it can be integrated into 20.0.

ben
--
(This message composed by voice)

>From xemacs-beta-request@cs.uiuc.edu  Fri Nov 15 15:51:46 1996
>Date: Fri, 15 Nov 1996 19:02:10 -0500
>From: Joel Peterson <tarzan@aosi.com>
>Organization: Me Tarzan, you Jane?
>To: Bob Weiner <weiner@infodock.com>, xemacs-beta@xemacs.org
>Subject: Re: `frame in a glyph'
>Content-Type: text/plain; charset=us-ascii
>X-Status: 
>
>Bob Weiner wrote:
>> 
>> I just rejoined the xemacs-beta list, so I am unfamiliar with your glyph
>> frames work.  What applications do you forsee or personally plan for them?
>> What would anyone use them for at this point, i.e. what advantages do they
>> give you over windows (overlapping perhaps?)?
>> 
>> Thanks,
>> 
>> Bob
>
>The main purpose is to take advantage of emacs' encapsulation of objects
>at the buffer level.  This has two immediate applications for me.  One
>application is to encapsulate objects into text.  The other application
>is in dialog boxes to serve as widgets.
>
>I am currently working on providing `pretty' and functional dialog
>boxes.  A one line high glyph frame will make a very powerful string
>widget; a multi line glyph frame will be a very powerful text box widget
>(especially when scrollbars are added).  I am adding code to allow
>drawing a recessed 3-D border around glyphs.  Granted, there is more
>overhead from implementing widgets using entire emacs frames rather than
>just implementing the widgets directly.  However, there are two major
>benefits from doing it the way that I did.  The most important is that
>what you get within the `widget' is emacs and will always have all the
>functionality and configurability of emacs; even when new features are
>added to emacs.  The second benefit is that the `widget' is reusable for
>other things.  There's not much that can be done with a string widget
>other than using it as a string widget.
>
>I wrote a huge amount of very hoary lisp code to manage a draggable
>spreadsheet table embedded within an emacs buffer.  The user can click
>on the `title bar' of the table and drag it to another location within
>the text.  Using a "frame in a glyph", the entire table can be
>encapsulated within another emacs buffer and the problem of moving it is
>reduced to the problem of moving an annotation glyph.  This is much
>simpler than moving a collection of text and extents (one for the entire
>object, one for the table part, and one for each cell in the table) and
>I get the benefit of being able to use buffer local variables to hold
>information which is much more convenient that storing properties into
>an extent.  I also have much more control over user interface
>considerations when the table is active for input, and I don't have to
>worry about it being clobbered by an editing change made from the
>surrounding text.  At any point, I can replace the table with some other
>object (say a picture), and the code for manipulating the object as a
>whole continues to work with no changes.
>
>Looking to the future, XEmacs will one day (I hope) be capable of
>wrapping multiple lines of text around tall pixmaps and will offer other
>`word processing' features.  The frame in a glyph is one of those word
>processing features, similar in concept to a frame in Microsoft Word or
>a desktop publishing package.
>
>I should be able to distribute the dialog box code (or at least an
>approximation of it).  The spreadsheet in emacs code is unlikely to ever
>make it outside the walls of Dow Jones (where I work).  It's too bad,
>because it's nice work, and UNIX could use a good, freely available
>spreadsheet.  If I get time, I'll redo it at home.
>
>That covers what I have personally planned for them.  I think the big
>advantage of a glyph frame in general is that it is positioned relative
>to a buffer position and may be fully or partially visible depending on
>whether that buffer position is visible.  The same glyph frame can even
>be visible in multiple emacs windows and be placed in multiple spots
>within a buffer or across buffers.
>
>The limitation on glyph frames is that their image is a specifier; and a
>lot of redisplay code depends on knowing which emacs frame they are
>displayed within.  This makes it difficult to display the same glyph
>frame within multiple other frames.  The nature of the implementation of
>the glyph frame is that a particular glyph frame cannot be
>simultaneously displayed on two consoles of different type (this does
>not prevent two glyph frames which just happen to display the same thing
>from appearing on two different consoles).  Anything else should be
>possible.
>
>I hope this made sense :-).  I have a big deadline to meet at work that
>requires these features, so there's been a whirlwind of implementing it,
>and I'm not sure that I even understand fully what it's good for, and
>where it needs to improve to get there.
>
>I'm posting this response to the XEmacs list as well as sending it to
>you, because I think it's important information that I somehow left out
>of my original postings.
>
>p.s. I do *not* speak for Dow Jones and Company, Inc.
>
>-- 
>And on the Eighth day, the Lord said "Let there be Advertisements."
>And lo, there were advertisements.  And the Lord saw the
>advertisements.  And the Lord went to the kitchen for a snack.
>                - Joel Peterson
>                       Supreme Deputy of scratching Dogbert behind the
>                       ears until he has little leg spasms.
>

From xemacs-beta-request@cs.uiuc.edu  Tue Nov 19 04:06:21 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA11467 for xemacs-beta-people; Tue, 19 Nov 1996 04:06:21 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA11464 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 19 Nov 1996 04:06:20 -0600 (CST)
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA12404 for <xemacs-beta@xemacs.org>; Tue, 19 Nov 1996 04:05:39 -0600 (CST)
Received: from hniksic@localhost by jagor.srce.hr (8.8.3/8.6.12.CI)
	id LAA18615; Tue, 19 Nov 1996 11:01:50 +0100 (MET)
Sender: hniksic@public.srce.hr
To: eeide@jaguar.cs.utah.edu (Eric Eide)
Cc: xemacs-beta@xemacs.org
Subject: Re: scroll-in-place gotcha
References: <199611181645.JAA07800@jaguar.cs.utah.edu>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 19 Nov 1996 11:01:49 +0100
In-Reply-To: eeide@jaguar.cs.utah.edu's message of Mon, 18 Nov 1996 09:45:57 -0700
Message-ID: <kighgmmmmia.fsf@jagor.srce.hr>
Lines: 13
X-Mailer: Red Gnus v0.63/XEmacs 19.14

Eric Eide (eeide@jaguar.cs.utah.edu) wrote:
> Personally, I never complete with TAB.  `s-i-p' allows you to scroll the
> completions list with `M-v' and `C-v', although a recent XEmacs "improvement"
> gets in the way of this.  In my `.emacs' I do:

There are many people who like that improvement (though I don't use
it).  However, Steve has posted a solution, with adding a hook.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

From xemacs-beta-request@cs.uiuc.edu  Tue Nov 19 07:56:50 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id HAA11986 for xemacs-beta-people; Tue, 19 Nov 1996 07:56:50 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA11983 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 19 Nov 1996 07:56:49 -0600 (CST)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by a.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id HAA26101 for <xemacs-beta@cs.uiuc.edu>; Tue, 19 Nov 1996 07:56:48 -0600 (CST)
Received: from mr1.exu.ericsson.se (mr1.exu.ericsson.com [138.85.147.11]) by gwa.ericsson.com (8.8.2/8.8.2) with ESMTP id HAA09369; Tue, 19 Nov 1996 07:55:25 -0600 (CST)
Received: from screamer.rtp.ericsson.se (screamer.rtp.ericsson.se [147.117.133.13]) by mr1.exu.ericsson.se (8.7.1/NAHUB-MR1.1) with SMTP id HAA10281; Tue, 19 Nov 1996 07:55:24 -0600 (CST)
Received: from rcur (rcur18.rtp.ericsson.se [147.117.133.138]) by screamer.rtp.ericsson.se (8.6.12/8.6.4) with ESMTP id IAA21736; Tue, 19 Nov 1996 08:55:22 -0500
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@cs.uiuc.edu
References: <199611181852.LAA08224@jaguar.cs.utah.edu>  <m2iv73b0ze.fsf@deanna.miranova.com> 
Subject: Re: Making scroll-in-place the default 
In-reply-to: (Your message of 18 Nov 1996 12:29:57 PST.)
             <m2iv73b0ze.fsf@deanna.miranova.com> 
Mime-Version: 1.0 (generated by tm-edit 7.88)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 19 Nov 1996 08:55:21 -0500
Message-ID: <5078.848411721@rtp.ericsson.se>
From: Raymond Toy <toy@rtp.ericsson.se>

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

    Steven> Try these bits of advice as well.  They work for me with
    Steven> s-i-p, resolve a many-times-asked FAQ, and make the
    Steven> scroll-up and scroll-down commands more friendly in that
    Steven> they won't trash the zmacs region (motion commands should
    Steven> not turn off selection).

Nice.  I've wanted something like this but never got around to doing
it.  May I make one suggestion?  Make these functions ding when you
get to the either end of the buffer, instead of silently ignoring it.
This makes the behavior consistent with C-p and C-n.

Ray

From xemacs-beta-request@cs.uiuc.edu  Tue Nov 19 10:40:27 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id KAA12539 for xemacs-beta-people; Tue, 19 Nov 1996 10:40:27 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id KAA12536 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 19 Nov 1996 10:40:26 -0600 (CST)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id KAA05764 for <xemacs-beta@cs.uiuc.edu>; Tue, 19 Nov 1996 10:40:26 -0600 (CST)
Received: from jaguar.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs)
	id JAA27516; Tue, 19 Nov 1996 09:40:25 -0700
Received: by jaguar.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id JAA15894; Tue, 19 Nov 1996 09:40:23 -0700
Date: Tue, 19 Nov 1996 09:40:23 -0700
From: eeide@jaguar.cs.utah.edu (Eric Eide)
Message-Id: <199611191640.JAA15894@jaguar.cs.utah.edu>
To: xemacs-beta@cs.uiuc.edu
In-reply-to: Raymond Toy's message of Tue, Nov 19 <5078.848411721@rtp.ericsson.se>
Subject: Re: Making scroll-in-place the default 

Raymond Toy (toy@rtp.ericsson.se) writes:

	>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

	Steven> Try these bits of advice as well.  They work for me with s-i-p,
	Steven> resolve a many-times-asked FAQ, and make the scroll-up and
	Steven> scroll-down commands more friendly in that they won't trash the
	Steven> zmacs region (motion commands should not turn off selection).

	Raymond> Nice.  I've wanted something like this but never got around to
	Raymond> doing it.  May I make one suggestion?  Make these functions
	Raymond> ding when you get to the either end of the buffer, instead of
	Raymond> silently ignoring it.  This makes the behavior consistent with
	Raymond> C-p and C-n.

Yes, this is a good idea.  I will implement it in the next `s-i-p'.

BTW, the issue of unconditionally deactivating the region on error was raised a
long time ago.  I can't seem to find my archives now, but I remember proposing
a new variable like `zmacs-region-dont-deactivate-on-error' to Jamie Z. back in
the Lucid Emacs days.  I wanted it so that `scroll-in-place' could bind it
before signalling a buffer boundary error.  It was never implemented; Jamie
thought that the always-deactivate behavior was desireable for consistency (?).

I guess that disciminating based on interactivity is the next best thing.

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .   University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide  . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From xemacs-beta-request@cs.uiuc.edu  Tue Nov 19 12:17:12 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id MAA12907 for xemacs-beta-people; Tue, 19 Nov 1996 12:17:12 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id MAA12904 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 19 Nov 1996 12:17:11 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id MAA09455 for <xemacs-beta@cs.uiuc.edu>; Tue, 19 Nov 1996 12:17:10 -0600 (CST)
Received: (qmail 18727 invoked by uid 501); 19 Nov 1996 18:19:38 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@cs.uiuc.edu
Subject: Re: Making scroll-in-place the default
References: <199611191640.JAA15894@jaguar.cs.utah.edu>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
In-Reply-To: eeide@jaguar.cs.utah.edu's message of Tue, 19 Nov 1996 09:40:23 -0700
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
Date: 19 Nov 1996 10:19:37 -0800
Message-ID: <m268327xs6.fsf@deanna.miranova.com>
Lines: 44
X-Mailer: Red Gnus v0.63/XEmacs 19.15

>>>>> "Eric" == Eric Eide <eeide@jaguar.cs.utah.edu> writes:
>>>>> "Raymond" ==  Raymond Toy (toy@rtp.ericsson.se) writes:
>>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

Steven> Try these bits of advice as well.

Raymond> Nice.  I've wanted something like this but never got around to
Raymond> doing it.  May I make one suggestion?  Make these functions
Raymond> ding when you get to the either end of the buffer, instead of
Raymond> silently ignoring it.  This makes the behavior consistent with
Raymond> C-p and C-n.

Eric> Yes, this is a good idea.  I will implement it in the next `s-i-p'.

Internal consistency is *everything*.  I don't like beeping, but I've
never been annoyed enough to turn it off, so definitely make them work
the same way.

Eric> BTW, the issue of unconditionally deactivating the region on
Eric> error was raised a long time ago.  I can't seem to find my
Eric> archives now, but I remember proposing a new variable like
Eric> `zmacs-region-dont-deactivate-on-error' to Jamie Z. back in the
Eric> Lucid Emacs days.  I wanted it so that `scroll-in-place' could
Eric> bind it before signalling a buffer boundary error.  It was never
Eric> implemented; Jamie thought that the always-deactivate behavior
Eric> was desireable for consistency (?).

Perhaps, but it is inconvenient /now/.  I don't like the variable you
propose in this instance, because I feel the current behavior is
always wrong.  If you *really* want the region turned off, you can
already hit the more convenient `C-g'.  I am a firm believer in the
notion that movement commands should only move and not have
state-changing side effects.

Eric> I guess that disciminating based on interactivity is the next
Eric> best thing.

That was to make it a minimalist change.  I didn't want to break
existing code.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

From xemacs-beta-request@cs.uiuc.edu  Tue Nov 19 19:08:41 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id TAA14584 for xemacs-beta-people; Tue, 19 Nov 1996 19:08:41 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id TAA14581 for <xemacs-beta@spruce.cs.uiuc.edu>; Tue, 19 Nov 1996 19:08:40 -0600 (CST)
Received: from deanna.miranova.com (qmailr@deanna.miranova.com [206.190.83.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id TAA13938 for <xemacs-beta@xemacs.org>; Tue, 19 Nov 1996 19:08:32 -0600 (CST)
Received: (qmail 26474 invoked by uid 501); 20 Nov 1996 01:11:05 -0000
Sender: steve@deanna.miranova.com
To: xemacs-beta@xemacs.org
Subject: [comp.emacs.xemacs] XEmacs: extents and keymaps
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: multipart/mixed;
 boundary="Multipart_Tue_Nov_19_17:11:04_1996-1"
Content-Transfer-Encoding: 7bit
Date: 19 Nov 1996 17:11:04 -0800
Message-ID: <m24tilr2on.fsf@deanna.miranova.com>
Lines: 65
X-Mailer: Red Gnus v0.65/XEmacs 19.15

--Multipart_Tue_Nov_19_17:11:04_1996-1
Content-Type: text/plain; charset=US-ASCII

Any comments from extents experts?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

--Multipart_Tue_Nov_19_17:11:04_1996-1
Content-Type: message/rfc822

>From gchen@shellus.com  Mon Nov 18 11:34:42 1996
Return-Path: <gchen@shellus.com>
Received: from dogwinkle by wentletrap.brc.shell.com (4.1/BRC-2.0)
	id AA05727; Mon, 18 Nov 96 11:34:42 CST
Sender: gchen@shellus.com
Message-Id: <32909E30.41C67EA6@shellus.com>
Date: Mon, 18 Nov 1996 11:34:40 -0600
From: "G. Chen" <gchen@shellus.com>
Organization: Shell Oil Company
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3_U1 sun4m)
Mime-Version: 1.0
Newsgroups: comp.emacs.xemacs
Cc: "Chen, G." <gchen@shellus.com>
Subject: XEmacs: extents and keymaps
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 0001
Content-Length: 1384

I've started to use XEmacs's lisp to customize my Unix programming
environment, and I really appreciate the power of Lisp in terms
of its expressiveness.

>From my limited experience of programming with extents and keymaps,
it appears that these primitive types have been implemented using
*inconsisitent* object-oriented (or data abstraction) paradigms as
far as inheritance is concerned:

Both extents and keymaps may have parents.  In the keymap primitive,
defining a specific key binding in an inheriting keymap (the child)
will take the precedence of that in its parent keymap (if defined
in the parent keymap, yet will *not* modify that key binding in the
parent keymap even if it's already defined.  IMHO, this is very
intuitive.  On the contrary, if an extent, say X, has a parent
extent, say Y, then Y will overshadow almost all the properties
of X.  If a property is changed through X, this change will
immediately affect not only Y, but also all other extents that
have Y as their parent extent.  This side-effect is not desired
in most, if not all, situations.  Think about it.  I think the
implementation of extents should honor localized properties in
favor of inherited properties, but not modify them in the
parent extent.

Any comments?

Chen
-- 
G. Chen, Subsurface IT / Shell Services / Shell Oil Company
Email: gchen@shellus.com                Voice: 713-245-7595

--Multipart_Tue_Nov_19_17:11:04_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Wed Nov 20 20:08:34 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id UAA22420 for xemacs-beta-people; Wed, 20 Nov 1996 20:08:34 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id UAA22417 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 20 Nov 1996 20:08:29 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id UAA15879 for <xemacs-beta@xemacs.org>; Wed, 20 Nov 1996 20:08:25 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA25394; Wed, 20 Nov 1996 18:07:45 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id SAA26055; Wed, 20 Nov 1996 18:07:20 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA29855; Wed, 20 Nov 1996 18:07:03 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA06202; Wed, 20 Nov 1996 18:07:02 -0800
Date: Wed, 20 Nov 1996 18:07:02 -0800
Message-Id: <199611210207.SAA06202@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: tm-en@chamonix.jaist.ac.jp
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Building gnus-art-mime.elc
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII

I've been integrating TM into XEmacs.  It would be nice if all the el
files would byte-compile without some special process, i.e. just like
all the other .el files.

Currently, when XEmacs tries to byte-compile gnus-art-mime.el, this
happens:

Compiling /home/mrb/e/t/build/sparc-S2-mule/lisp/tm/gnus-art-mime.el...
While compiling toplevel forms in file /home/mrb/e/t/build/sparc-S2-mule/lisp/tm/gnus-art-mime.el:
  !! File error (("Cannot open load file" "gnus-art"))

gnus-art is provide-ed in gnus-mime-old.el, which is not where you
would expect it.  It is traditional for files to provide only one
symbol, namely the one that names the current file.

Tomohiko, could you fix this to byte-compile correctly?

I'm sure there will be other changes to be made to get the TM package
to integrate cleanly as a standard part of an XEmacs distribution.

Here are some other problems to address:

- I need to remove the (hard-coded) load-path modifications in
  mime-setup.el - TM's elisp files are now always on load-path.

- bbdb-related files fail to byte-compile.  Since bbdb is not going to
  part of XEmacs this release, perhaps the bbdb-related files could be
  modified so that they will byte-compile even if bbdb is not present.

  Here's one idea for fixing it:  bbdb must be found at run-time, but
  not at compile time (untested - I've never used bbdb).

*** /tmp/geta6195	Wed Nov 20 18:04:11 1996
--- tm-bbdb.el	Wed Nov 20 18:03:11 1996
***************
*** 28,35 ****
  
  ;;; Code:
  
! (require 'bbdb)
! (require 'bbdb-com)
  (require 'std11)
  (require 'tm-ew-d)
  (require 'tm-view)
--- 28,40 ----
  
  ;;; Code:
  
! (eval-when (compile)
!   (ignore-errors
!     (require 'bbdb)
!     (require 'bbdb-com)))
! (eval-when (load eval)
!     (require 'bbdb)
!     (require 'bbdb-com))
  (require 'std11)
  (require 'tm-ew-d)
  (require 'tm-view)

- Presence of Multi-Lingual text in (like Tomohiko's Japanese name) in
  texinfo documentation causes errors when the texinfo is processed 
  using standard English TeX.

- Presence of `=' characters in filenames (.texi files) causes
  problems with some versions of make when those filenames are
  included in Makefiles.  I recommend never using `=' characters in
  filenames because of these makefile problems.

A version of XEmacs 20 should be available to beta testers `soon' with
TM included.

Thanks.

Martin

From xemacs-beta-request@cs.uiuc.edu  Wed Nov 20 22:00:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id WAA22796 for xemacs-beta-people; Wed, 20 Nov 1996 22:00:43 -0600 (CST)
Received: from a.cs.uiuc.edu (a.cs.uiuc.edu [128.174.252.1]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id WAA22793 for <xemacs-beta@spruce.cs.uiuc.edu>; Wed, 20 Nov 1996 22:00:43 -0600 (CST)
Received: from JATO.hackvan.com (hackvan.com [206.80.31.242]) by a.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id WAA13705 for <xemacs-beta@cs.uiuc.edu>; Wed, 20 Nov 1996 22:00:42 -0600 (CST)
Received: by JATO.hackvan.com (Linux Smail3.1.29.1 #27)
	id m0vQPdx-00071TC; Wed, 20 Nov 96 19:17 PST
Message-Id: <m0vQPdx-00071TC@JATO.hackvan.com>
Date: Wed, 20 Nov 96 19:17 PST
From: stig@hackvan.com (Stig)
To: xemacs-beta@cs.uiuc.edu
Subject: Keyboard tip...
X-PGPfone: Encrypted phone calls welcome @ tailgunner.hackvan.com
X-Face: V3#TB_`^vld7L-O4+Qk1%QYVRe6B2)Ia$tWrjprU|P'pM:Y{P5Io@~qxuL:&.;*?KU5.w_J
 ^t3S-[aLM9E*t3PKQ8FJs[+U5BYh4G'6xody^[oR"fukpjVI}3m!<;f)Ptipi4lD,R70]K3$pK"#c`
 [3S!^H~;A&1oo&;)-"R2]5%unJ8QeoXlo7n+h(rLQS?]SCWnHvm3/v7*RXE`,/;8g6j)&/


You might be interested in my new keyboard hack.  Now have a keyboard that
lets me do control, alt, and shift with my thumbs (as well as space).  Still
adapting to it, but this is almost the holy keyboard grail that I've been
seeking for a long time...

Damark is selling the Key Tronic FlexPro keyboard for $20+$6 shipping.

    http://www.cs.princeton.edu/~dwallach/tifaq/keyboards.html#kb-flexpro

    800 729 9000, part # b-9075-491613

Each half of the spacebar has two keyswitches.  In the default
configuration, you can get backspace and enter out of the extra switches.
In the hacked configuration, you can do whatever you want with them.  Note
that the hacked conficuration requires: #1 phillips, razor, soldering iron,
30ga wire wrap wire, a multimeter, a paper clip, some angled needlenose
pliers, and about 90 minutes...

I just ordered a few spares since this a closeout.  I might later sell my
Lexmark Select-Ease keyboard with control on the left thumb.  It's a more
solid keyboard, but it's less hackable.

    Stig

From xemacs-beta-request@cs.uiuc.edu  Thu Nov 21 06:39:20 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id GAA27798 for xemacs-beta-people; Thu, 21 Nov 1996 06:39:20 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id GAA27795 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 21 Nov 1996 06:39:18 -0600 (CST)
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id GAA16596 for <xemacs-beta@xemacs.org>; Thu, 21 Nov 1996 06:39:14 -0600 (CST)
Received: from localhost (Shuhei KOBAYASHI <shuhei-k@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id VAA19767; Thu, 21 Nov 1996 21:39:07 +0900 (JST)
From: Shuhei KOBAYASHI <shuhei-k@jaist.ac.jp>
To: Martin Buchholz <mrb@Eng.Sun.COM>
CC: tm-en@chamonix.jaist.ac.jp, XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: Building gnus-art-mime.elc
In-Reply-To: <199611210207.SAA06202@xemacs.eng.sun.com>
References: <199611210207.SAA06202@xemacs.eng.sun.com>
Organization: Japan Advanced Institute of Science and Technology, Hokuriku.
X-Mailer: VM 5.96 (beta) with tm patch / Mule 2.4 =?ISO-2022-JP?B?KA==?=
  =?ISO-2022-JP?B?GyRCOUhNVTJsGyhCKQ==?=
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: multipart/mixed;
 boundary="_Thu_Nov_21_21:38:08_1996-1"
Content-Transfer-Encoding: 7bit
Message-Id: <19961121213901Y/shuhei-k@jaist.ac.jp>
Date: Thu, 21 Nov 1996 21:39:01 +0900
X-Dispatcher: impost version 0.92+ (Aug. 9, 1996)
Lines: 52

--_Thu_Nov_21_21:38:08_1996-1
Content-Type: text/plain; charset=US-ASCII

>>>>> In [tm-en:956] Building gnus-art-mime.elc,
>>>>> Martin Buchholz <mrb@Eng.Sun.COM> wrote:
> - bbdb-related files fail to byte-compile.  Since bbdb is not going to
>   part of XEmacs this release, perhaps the bbdb-related files could be
>   modified so that they will byte-compile even if bbdb is not present.
> 
>   Here's one idea for fixing it:  bbdb must be found at run-time, but
>   not at compile time (untested - I've never used bbdb).

  tm-bbdb.el (and other tm modules) still supports Version 18 Emacs.
So we don't want to use `eval-when' at top-level.

  How about this?  (If OK, I'll fix mu-bbdb.el, too.)


--_Thu_Nov_21_21:38:08_1996-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="tm-bbdb.el.diff"
Content-Transfer-Encoding: 7bit

--- tm-bbdb.el	1996/10/22 05:28:23	7.19
+++ tm-bbdb.el	1996/11/21 11:18:04
@@ -28,11 +28,17 @@
 
 ;;; Code:
 
-(require 'bbdb)
-(require 'bbdb-com)
 (require 'std11)
 (require 'tm-ew-d)
 (require 'tm-view)
+(if running-emacs-18
+    (require 'bbdb-com) ; (require 'bbdb) implicitly
+  (eval-when (compile)
+    (ignore-errors
+      (require 'bbdb-com)))
+  (eval-when (load eval)
+    (require 'bbdb-com))
+  )
 
 
 ;;; @ mail-extr

--_Thu_Nov_21_21:38:08_1996-1
Content-Type: text/plain; charset=US-ASCII

Shuhei KOBAYASHI / <shuhei-k@jaist.ac.jp>

--_Thu_Nov_21_21:38:08_1996-1--

From xemacs-beta-request@cs.uiuc.edu  Thu Nov 21 14:21:32 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id OAA29541 for xemacs-beta-people; Thu, 21 Nov 1996 14:21:32 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id OAA29538 for <xemacs-beta@spruce.cs.uiuc.edu>; Thu, 21 Nov 1996 14:21:31 -0600 (CST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with SMTP id OAA17389 for <xemacs-beta@xemacs.org>; Thu, 21 Nov 1996 14:21:29 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA11741; Thu, 21 Nov 1996 12:20:17 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA19546; Thu, 21 Nov 1996 12:19:59 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA25678; Thu, 21 Nov 1996 12:19:52 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA04902; Thu, 21 Nov 1996 12:19:51 -0800
Date: Thu, 21 Nov 1996 12:19:51 -0800
Message-Id: <199611212019.MAA04902@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Shuhei KOBAYASHI <shuhei-k@jaist.ac.jp>
Cc: tm-en@chamonix.jaist.ac.jp, XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: Re: Building gnus-art-mime.elc
In-Reply-To: <19961121213901Y/shuhei-k@jaist.ac.jp>
References: <199611210207.SAA06202@xemacs.eng.sun.com>
	<19961121213901Y/shuhei-k@jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Shuhei" == Shuhei KOBAYASHI <shuhei-k@jaist.ac.jp> writes:

Shuhei> [1  <text/plain; US-ASCII (7bit)>]

Shuhei>   How about this?  (If OK, I'll fix mu-bbdb.el, too.)

It would be good if mu-bbdb.el was fixed as well.

Version tests should be avoided, if possible.  

How about this (untested):

(if (not (fboundp 'eval-when))
    (require 'bbdb-com)
  (eval-when (compile)
     (ignore-errors
        (require 'bbdb-com)))
   (eval-when (load eval)
      (require 'bbdb-com)))
 
Shuhei> -(require 'bbdb)
Shuhei> -(require 'bbdb-com)
Shuhei>  (require 'std11)
Shuhei>  (require 'tm-ew-d)
Shuhei>  (require 'tm-view)
Shuhei> +(if running-emacs-18
Shuhei> +    (require 'bbdb-com) ; (require 'bbdb) implicitly
Shuhei> +  (eval-when (compile)
Shuhei> +    (ignore-errors
Shuhei> +      (require 'bbdb-com)))
Shuhei> +  (eval-when (load eval)
Shuhei> +    (require 'bbdb-com))
Shuhei> +  )
 
Martin

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 22 00:17:56 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id AAA01173 for xemacs-beta-people; Fri, 22 Nov 1996 00:17:56 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA01170 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 22 Nov 1996 00:17:55 -0600 (CST)
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id AAA18805 for <xemacs-beta@xemacs.org>; Fri, 22 Nov 1996 00:17:52 -0600 (CST)
Received: from xdiv.lanl.gov (xdiv.lanl.gov [128.165.116.106]) by mailhost.lanl.gov (8.7.6/8.7.3) with ESMTP id XAA02487 for <xemacs-beta@xemacs.org>; Thu, 21 Nov 1996 23:17:53 -0700 (MST)
Received: from branagh.lanl.gov (branagh.lanl.gov [128.165.16.72]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id XAA05866; Thu, 21 Nov 1996 23:17:53 -0700
Received: by branagh.lanl.gov (SMI-8.6/SMI-SVR4)
	id XAA19851; Thu, 21 Nov 1996 23:16:27 -0700
Date: Thu, 21 Nov 1996 23:16:27 -0700
Message-Id: <199611220616.XAA19851@branagh.lanl.gov>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: 19.14 on Irix 6.2
Reply-To: turner@lanl.gov

A colleague has been trying to build 19.14 on Irix 6.2 for both
an R4400 machine and an R10k box.

In the following, note that:

terre is a 4x200MHz R10k box
ciel is a 150MHz R4400 box

He reports:

------- begin -------

I built xemacs on terre.  No, I can not get a binary that works on
both terre and and the r4400 irix 6.2 machines.  Most programs are no
problem, but xemacs just will not work on both.

The binary I build on ciel runs on the r4400 machines, but
drops core on terre.  The binary I build on terre drops core on an
r4400 machine.  I know that's not much to go on.  Ever seen similar
behavior?  -32 -mips2 was used, although I've tried other combinations
as well.

------- end -------

I know there are some SGI folks on xemacs-beta, so I waas wondering if
any of you know anything about this.

I realize this isn't 19.15beta-specific, but I've been terribly busy,
so I decided to wait until the next beta.

BTW, he's constantly giving me crap about XEmacs performance, and
after flirting with it he returned to "the Emacs formerly known as FSF
Emacs".  But he calls XEmacs on the 200MHz R10k box "somewhat quick".

Thanks.

-- 
John A. Turner
Los Alamos National Laboratory, MS B226, Los Alamos, NM 87545
Group: XTM (Radiation Transport Methods)
Location: TA-3, Bldg. 43, Rm. D150
Phone: 505-665-1303                   e-mail: turner@lanl.gov

From xemacs-beta-request@cs.uiuc.edu  Fri Nov 22 04:01:51 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id EAA05285 for xemacs-beta-people; Fri, 22 Nov 1996 04:01:51 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA05282 for <xemacs-beta@spruce.cs.uiuc.edu>; Fri, 22 Nov 1996 04:01:49 -0600 (CST)
Received: from pallas.spacetec.no (pallas.spacetec.no [192.51.5.92]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id EAA19197 for <xemacs-beta@xemacs.org>; Fri, 22 Nov 1996 04:01:45 -0600 (CST)
Received: (from tor@localhost) by pallas.spacetec.no (8.7.1/8.7.1) id LAA11907; Fri, 22 Nov 1996 11:01:05 +0100
Message-Id: <199611221001.LAA11907@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Fri, 22 Nov 1996 11:01:05 +0100
In-Reply-To: John Turner <turner@xdiv.lanl.gov>
       "19.14 on Irix 6.2" (Nov 22,  7:19)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: turner@lanl.gov, xemacs-beta@xemacs.org
Subject: Re: 19.14 on Irix 6.2

On Nov 22,  7:19, John Turner wrote:
>A colleague has been trying to build 19.14 on Irix 6.2 for both
>an R4400 machine and an R10k box.
>
>In the following, note that:
>
>terre is a 4x200MHz R10k box
>ciel is a 150MHz R4400 box
>
>He reports:
>
>------- begin -------
>
>I built xemacs on terre.  No, I can not get a binary that works on
>both terre and and the r4400 irix 6.2 machines.  Most programs are no
>problem, but xemacs just will not work on both.
>
>The binary I build on ciel runs on the r4400 machines, but
>drops core on terre.  The binary I build on terre drops core on an
>r4400 machine.  I know that's not much to go on.  Ever seen similar
>behavior?  -32 -mips2 was used, although I've tried other combinations
>as well.

I always have to re-dump xemacs on SGI whenever I install a patch that
affects the C library.

First I couldn't make an xemacs that worked on both 6.2 and 5.3 (5.3 dumped
version cored on 6.2 and 6.2 dumped version cored on 5.3).

Then I installed more Irix 6.2 patches, and the 6.2 xemacs started to dump
core on 6.2 too.  After re-dumping it was ok, and this version would actually
run on 5.3 as well!

After even another set of 6.2 patches I had to re-dump xemacs again, and
I suspect that it will no longer run on my 5.3 (patches stable) system,
although I haven't tested that yet.

Dave Olson (I think it was) at SGI indicated that it's sensitive to dynamic
library changes because xemacs is a dumped binary (temacs seems to be running
without problems, also when mixing 5.3/6.2).

As I have a shared nfs disk with binaries for 5.3 and 6.2 I work around 
the problem by letting /usr/local/bin/xemacs be a shell script, and I put
binaries in /usr/local/bin/xemacs/6.2/ and 5.3/ respectively.
The script looks like this:
#!/bin/sh -f
usr/local/bin/`uname -a | awk '{print $3}'`/xemacs-19.14 $*

I guess something similar could be done to work around different 6.2 
platforms/patch levels too, until someone finds a solution to the problem
of dumped binaries (if possible).

Regards,
Tor


From xemacs-beta-request@cs.uiuc.edu  Sat Nov 23 16:32:43 1996
Received: (from daemon@localhost) by spruce.cs.uiuc.edu (8.7.6/8.7.3) id QAA13755 for xemacs-beta-people; Sat, 23 Nov 1996 16:32:43 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (xemacs.cs.uiuc.edu [128.174.252.16]) by spruce.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA13752 for <xemacs-beta@spruce.cs.uiuc.edu>; Sat, 23 Nov 1996 16:32:41 -0600 (CST)
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.7.6/8.7.3) with ESMTP id QAA22656 for <xemacs-beta@xemacs.org>; Sat, 23 Nov 1996 16:32:38 -0600 (CST)
Message-Id: <199611232232.QAA22656@xemacs.cs.uiuc.edu>
To: xemacs-beta@xemacs.org
Subject: mailing list change
Date: Sat, 23 Nov 1996 16:32:38 -0600
From: Chuck Thompson <cthomp@xemacs.org>

This should be the last message sent to the xemacs* aliases through
the old, manual system.  Within the next 15 minutes they will be
switched over to being maintained by SmartList.  If you have any
problems that you cannot resolve through the automated system, please
send mail directly to me.


			-Chuck

