HDTenEightyP/NetNews huggingface dataset:
From: sbb@eng.SUn.COM (Steve Byrne)
Subject: GNU ST on DOS + Windows 3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 22 Nov 1992 19:42:27 GMT

"matt@bacchus.esa.oz.au" writes:
 >     Anyone ported GNU Smalltalk to DOS and Windows 3,1 yet? I don't
 >     want to start on it if it's already done or in the process. Any
 >     tips / hints if it's not already? ta ...

Matt,

I don't know of a successful port of GNU Smalltalk to DOS, yet.  The basic
limitation is that version 1.1.1 (the current version) needs a relatively
large, linear address space.  You could probably get by with 2 1-meg chunks,
plus something like 200k for other assorted memory needs, but performance may
a bit.

You should be able to start from the m-i386-sysv.h configuration file.  The
code is relatively portable among workstations and larger machines, but it has
no notion of near and far pointers; you'd probably have to use an extender and
use the large (huge?) memory model on a 386 (maybe 286's would work, don't
know).

Good luck!  There are lots of people who could be greatful for this port!

Steve

Newsgroups: gnu.smalltalk.bug
From: perelet@avignon.wri.com (Oleg Perelet)
Subject: GNU Smalltalk and GNU ObjC interface?
Organization: Wolfram Research, Inc.
Distribution: gnu
Date: Mon, 23 Nov 1992 21:05:06 GMT

Sorry, it's request, not bug post.

Will it be possible to put Smalltalk and ObjC together?
Is anybody doing this alredy, if yes i'll be glad to
help. I was trying to make something work on NeXT using
proxy's, but it seems like GNU ObjC don't have support
for distributed objects. So seems like it should be done
on low level (like C call in current version of Smalltalk).
Thanx. 

Newsgroups: gnu.emacs.bug
From: ash+@cmu.edu (Ashvini Sharma)
Subject: Fwd: reporting a bug in emacs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 15 Nov 1992 03:46:16 GMT

hi folks,
    one of the user at my site got this error. Does anybody know what it
means? Is there any other source where I could find out what this error
meant? perhaps one of the files with emacs? We are running Gnu Emacs
18.58.1 on a pmax, ultrix 4.2

thanks
ash

---------- Forwarded message begins here ----------

This happened when I asked for a completion on a file name in the command line:


Possible completions are:
#<EMACS BUG: INVALID DATATYPE (#o 20) Save your buffers immediately and
please report this bug>	#<EMACS BUG: INVALID DATATYPE (#o 20) Save your
buffers immediately and please report this bug>



Newsgroups: gnu.emacs.bug
From: hatrjo@hat-fi.kone.COM (Risto Jokinen)
Subject: Domain_OS 10.4
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 17 Nov 1992 23:45:35 GMT

I compile emacs 18.57 with HP-changes (directory actually comes trough HP,
compiled for 400 and 700 series machines), anyway I compile program for the
APOLLO DOMAIN_OS 10.4 using 425 series (040) machine, and after few changes 
I get it to work. It works, but maybe once in day, hour or in minute it says,
segmentation fault. This usually occurs if xemacs windows size is changed, or when 
number of keys is pressed in short time. I include tb file, it maybe says something
maybe not. I still have 17...version without this problem... tnx.

APOLLO DOMAIN_OS TB:
----------------------
 ./xemacs.x process.c
Segmentation fault
25% //domino/emacs/src) tb
Process        3154 (parent 3100, group 3154)
Time           92/11/17.21:28()
Program        /emacs/src/xemacs.x
Status         0901000B: segmentation violation fault (UNIX/signal)
In routine     "kill" line 87
Called from    "fatal_error_signal" line 149
Called from    "pfm_$fault" line 3300
Called from    diagnostic frame (00040004) reference to illegal address (OS/MST manager)
Called from    "input_available_signal" line 1359
Called from    "pfm_$fault" line 3300
Called from    diagnostic frame (0901001A) i/o is possible on a descriptor fault (UNIX/signal)
Called from    "ec2_$wait_svc" line 157
Called from    "select" line 219
Called from    "wait_reading_process_input" line 1629
Called from    "kbd_buffer_read_command_char" line 1129
Called from    "read_command_char" line 973
Called from    "read_key_sequence" line 1491
Called from    "command_loop_1" line 661
Called from    "internal_condition_case" line 1006
Called from    "command_loop_2" line 533
Called from    "internal_catch" line 815
Called from    "command_loop" line 515
Called from    "recursive_edit_1" line 400
Called from    "Frecursive_edit" line 382
Called from    "main" line 490
Called from    "unix_$main" line 123
Called from    "<apollo_c_startup>" line 31999
Called from    "PM_$CALL" line 176
Called from    "pgm_$load_run" line 871
Called from    "pgm_$invoke_uid_pn" line 1006

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


Newsgroups: gnu.emacs.bug
From: grossjoh@lucy.ls6.INformatik.uni-dortmund.DE (Kai Grossjohann)
Subject: Re: autosave of large buffers
Reply-To: Kai Grossjohann <grossjoh@ls6.informatik.uni-dortmund.de>
Organization: Universitaet Dortmund, Lehrstuhl Informatik VI
Distribution: gnu
Date: Mon, 23 Nov 1992 18:43:39 GMT

>>>>> On Fri, 20 Nov 1992 07:10:44 GMT,
>>>>> macrakis@osf.ORG (Stavros Macrakis) said:

> Incremental saves would be far cheaper, and Emacs already has the
> information to do them, in the form of undo data.  So why not save the
> undo data instead?  (except for buffers backed up by copying)  To
> protect against file deletion, a #-link could be made to the base
> file.  Of course, there is still the danger of the file being modified
> in place by someone else.

Well, as far as I understand, Emacs works with plain ASCII files that every
text editor can read. As soon as we start using this incremental save feature
we're no longer compatible to the rest of the world.

But, if there is an ISO standard about this, well, then I think it's worth
considering. BTW, I find these auto-saves of large buffers annoying, too.

	\Kai
--
  Kai Grossjohann            Phone (voice): 49 231 75 30 15
  Baroper Str. 331 App. 510  E-Mail: 
  W-4600 Dortmund 50         grossjoh@ls6.informatik.uni-dortmund.de
  Germany
From: harvey@bucknell.EDU (Mike Harvey)
Newsgroups: gnu.emacs.bug
Subject: fill.el bug and fix
Date: 17 Nov 92 14:48:53 GMT
Reply-To: harvey@bucknell.edu
Distribution: gnu
Organization: Bucknell University, Lewisburg, PA

I have found a bug in fill.el for versions 18.58 and 18.59.  
When filling an included message in rmail, the header should
be left untouched, as it was in version 18.57.  The newer 
versions fill the header as well as the message body.

The fix for this is as follows:

   diff -r1.1 fill.el
   219c219
   <	     (while (looking-at "[^ \t\n]*:")
   ---
   > 	     (while (looking-at "^[ \t\n]*[^ \t\n]*:")





Mike Harvey
Systems Engineer
Bucknell University
Lewisburg, PA 17837
harvey@sol.cs.bucknell.edu
Newsgroups: gnu.emacs.bug
From: cogen@ll.mit.edu (David Cogen)
Subject: c++ mode has problems.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 05:33:38 GMT

I have noticed several problems with c++ mode. Is c++ mode a supported part of
gnuemacs? I am using emacs version 18.57.3, and the file c++-mode.el begins as
follows:

  ;; C++ code editing commands for Emacs
  ;; 1987 Dave Detlefs  (dld@cs.cmu.edu) 
  ;; and  Stewart Clamen (clamen@cs.cmu.edu).
  ;; Done by fairly faithful modification of:
  ;; c-mode.el, Copyright (C) 1985 Richard M. Stallman.

(Is this the right one?)

Anyway, here are the problems:


1) Parenthesis-like characters are treated as such even if they are embedded in
a string or character constant. For example:

  // -*- C++ -*-

  static char chars [80];
  
  int fun ()
  {
    int i,j,k;
    for (i=0; chars[i]!=']'; i++);
    return i;
  }

The embedded `]` matches the parenthesis following the for.


2) Comments are not ignored for the purpose of matching parentheses. Examples:

  int ff ()
  {
    // This comment should be ignored. }
    more_code_here ();
  }

  int gg ()
  {
    /* This comment should be ignored. } */
    mode_code_here ();
  }

In both cases, the } inside the comment terminates the { at the beginning of
the function. But really, all text inside a command must be ignored. (I realize
that this may be difficult with /* ... */ comments, but with // comments it
should be very easy to implement.)


2.5) The above applies to conditionally defined code as well. For example,
braces inside an #if 0...#endif construct. I believe these should be ignored as
well. 


3) Old style comments are messed up when doing c++-indent-defun (ESC C-x).
Before: 

  int hh ()
  {
    /* A multiline comment in a c++ function.
       I'll make it span several lines.
       Another line.
       Yet another. 
     */
  }

After:

  int hh ()
  {
    /* A multiline comment in a c++ function.
      I'll make it span several lines.
        Another line.
          Yet another. 
            */
  }


David Cogen.


Newsgroups: gnu.emacs.bug
From: boaz@concerto.lcs.mit.edu (Boaz Ben-Zvi)
Subject: Running Emacs sets terminal in "pass8"
Organization: MIT Laboratory for Computer Science
Distribution: gnu
Date: Mon, 23 Nov 1992 03:15:32 GMT

Description of the problem:

  I log in via 2400 bd modem (and through a CISCO box) to a DecStation
  5000 running Ultrix 4.2 (using a Z29 terminal in ANSI mode)
      ==> Everythilng is OK (stty everything reports "-pass8")
  I run emacs 18.57 (no problem here) and exit.
      ==> Half the keys on my keyboard are dead (stty all reports "pass8")

Temporary solution: create an alias (from those keys that work) that
  does "stty -pass8" and use it after running emacs.

-- Boaz
--

===============================================================================
  _              _            __         __ ___  _ _   __ ___    ____      ___
 /_) _  _  __   /_) _   __ __ _/    o     |   |   \| __ |   |     /    \ |   |
/__)(_)(_|__/  /__)(_'_/ /   /__\/_(        __|_ __\    | __|_     \  __\| __|_
          __)                                           |                      
===============================================================================
 Boaz Ben-Zvi <boaz@crl.dec.com>           Home: (617) 494-1279  <boaz@mit.edu>
===============================================================================
From: quiroz@cs.rochester.edu (Cesar Quiroz)
Newsgroups: gnu.emacs.bug
Subject: Re: cl.elc is not behaving like a compiled cl.el
Date: 17 Nov 92 02:19:59 GMT
Reply-To: quiroz@cs.rochester.edu (Cesar Quiroz)
Distribution: gnu
Organization: University of Rochester, Department of Computer Science

In <9211161417.AA02701@ask.cs.cornell.edu>,
cliff@cs.cornell.edu (Cliff Krumvieda) wrote:

| ... I checked around and discovered that, although,
| emacs-18.58/lisp/cl.el and emacs-18.59/lisp/cl.el are identical
| files, emacs-18.58/lisp/cl.elc and emacs-18.59/lisp/cl.elc differ.
| ...
| Is this a bug with some optimizing byte-compiler?

Nope, just the usual brain damage in cl.el.  Probably cl.elc was
compiled from a clean directory, without the prior loading.  I have
tried a few quick-and-dirty schemes to do this automatically, but
all have caused an infinite loop somewhere, so short of splitting
cl.el again in the half dozen files it used to be...

BTW, version 3.0beta is available in the usual place

	cs.rochester.edu:cl.{el,elc,ChangeLog}

I expect it will turn into 3.0 by the time Version 19 is out.
Meanwhile, I will appreciate any feedback.  (Especially a proven way
to live with its raveled structure as one file, and still get it
compiled in one shot.  Conversely, if someone finds the time to put
the files so that macros appear before they are used...)

-- 
                                      Cesar Quiroz
Newsgroups: gnu.emacs.bug
From: schoen@ghost.dsi.unimi.it
Subject: Demacs with auto-fill often truncates words
Organization: Computer Science Dep. - Milan University
Distribution: gnu
Date: Tue, 17 Nov 1992 16:31:38 GMT

It often happen using DEMACS on  a 386 PC that a line of text is
truncated in the middle of a word, when auto-fill-mode is on. I noticed
this ONLY in correpsondance with the letter 'z'. Example: typing this
sentence:

Is this a problem of zizuzozaze zizuzozaze zizuzozaze zizuzozzaze zizuzozaze 

after the final blank demacs gives the following:

Is this a problem of zizuzozaze zizuzozaze zizuzozaze zizuzozzaze ziz
uzozaze 


Almost always a word containing a z at the end of the line is
incorrectly truncated this way. I never noticed a similar behaviour with
different letters. 
Anybody has the same problem?
Suggestions?
Where to look for possible solutions??
thanks
-- 
+---------------------------------------------------------------------------+
| Fabio Schoen                                  e-mail:                     |
| Dipartimento di Scienze della Informazione    schoen@ghost.dsi.unimi.it   |
| via Comelico 39/41 - room    S235             schoen@imiucca.csi.unimi.it |


Newsgroups: gnu.emacs.bug
From: njs@watson.ibm.com (Nicholas J. Simicich)
Subject: [jat60@cd.amdahl.com: Closing a window in epoch kills xterms]
Reply-To: Nick Simicich <njs@watson.ibm.com>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 22:51:38 GMT

Could you please remove me from this list?  I'm swamped with mail.  I
just can't read it all.

Nick Simicich


Received: by cpunk.watson.ibm.com (AIX  2.2/2.A)
          id AA09893; Fri, 30 Oct 92 07:00:58 EST
Received: from watson.vnet.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R2)
   with BSMTP id 2894; Fri, 30 Oct 92 07:00:57 EST
Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0"
          id <A.GNULISTS.NOTE.YKTVMV.4968.Oct.30.07:00:55.-0500>
          for njs@watson; Fri, 30 Oct 92 07:00:56 -0500
Received: from life.ai.mit.edu by watson.ibm.com (IBM VM SMTP V2R2) with TCP;
   Fri, 30 Oct 92 07:00:54 EST
Received: by life.ai.mit.edu (4.1/AI-4.10) id AA08710; Fri, 30 Oct 92 00:00:13 EST
Return-Path: <gnulists@ai.mit.edu>
Received: from cookie-crisp (cookie-crisp.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA08657; Thu, 29 Oct 92 23:59:48 EST
Received: by cookie-crisp (4.1/AI-4.10) id AA06911; Thu, 29 Oct 92 23:58:13 EST
Resent-Date: 29 Oct 92 21:23:18 GMT
Resent-Message-Id: <9210300458.AA06911@cookie-crisp>
Received: from ames.arc.nasa.gov by life.ai.mit.edu (4.1/AI-4.10) id AA29031; Thu, 29 Oct 92 16:23:29 EST
Received: from charon.amdahl.com by ames.arc.nasa.gov with SMTP id AA21002
  (5.65c/IDA-1.4.4 for <gnu-emacs-bug@ames.arc.nasa.gov>); Thu, 29 Oct 1992 13:23:22 -0800
Received: from amdahl.uts.amdahl.com by charon.amdahl.com (4.0/SMI-4.1/DNS)
	id AA07087; Thu, 29 Oct 92 13:23:19 PST
Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.12)
	id <m0mkhKo-0000pUC@amdahl.uts.amdahl.com>; Thu, 29 Oct 92 13:23 PST
Received: by juts.ccc.amdahl.com (/\../\ Smail3.1.14.4 #14.6)
	id <m0mkhKo-0000R3C@juts.ccc.amdahl.com>; Thu, 29 Oct 92 13:23 PST
Original-To: gnu-emacs-bug@ames.arc.nasa.gov
From: jat60@cd.amdahl.com (jeff techau)
Newsgroups: gnu.emacs.bug
Subject: Closing a window in epoch kills xterms
Message-Id: <fc9M02Kq28cl01@JUTS.ccc.amdahl.com>
Date: 29 Oct 92 21:23:18 GMT
Organization: Amdahl Corporation, Sunnyvale CA
To: bug-gnu-emacs@prep.ai.mit.edu
Resent-From: bug-gnu-emacs-request@prep.ai.mit.edu

I'm running epoch 4.0.1 on SunOS 4.1.1 on a SPARC 1+ running the XNEWS server
and mwm.  If I close an epoch screen (ie, Xwindow) using either the window
manager Close or epoch C-z 0 (remove-screen), I occasionally experience
the death of an unrelated xterm window (unrelated meaning I didn't start
epoch from that xterm).  The error message I get from xterm is:

xterm:  warning, error event receieved:
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  2 (X_ChangeWindowAttributes)
  Minor opcode of failed request:  0
  Resource id in failed request:  0xf00018
  Serial number of failed request:  3081
  Current serial number in output stream:  3081

It would appear to the untrained eye that epoch is sending Bad stuff to
my xterm.  Is this a known bug?  If so, is there a known fix?  Could this
be an xterm bug?  I've never seen this problem except when closing epoch
screens.

- jeff techau     (408) 737-5432        jat60@cd.amdahl.com
                  Amdahl Corporation    Sunnyvale, CA



Newsgroups: gnu.emacs.bug
From: gaumondp@ere.umontreal.CA (Gaumond Pierre)
Subject: Emacs installation (again)
Keywords: installation
Organization: Universite de Montreal
Distribution: gnu
Date: Fri, 20 Nov 1992 16:53:56 GMT

As I reported in a previous posting, the "mkdir" dependancy in the Makefile file
of the main directory of Emacs (18.59) distribution may fail to create
the directories if more than one element are missing in the path names.

So, I suggest to change the "mkdir" dependancy in the Makefile as follows (or
something similar):

mkdir: FRC
	for file in ${LIBDIR} ${BINDIR} ${MANDIR}
	do
	  dir=`echo $file | sed -e 's/^\([^/]*\)/.*$/\1/'`
	  for sub in `echo $file | tr '/' ' '`
	  do
	    dir=$dir/$sub
	    -mkdir $dir
	  done
	done

NOTE:
I'm not familiar with make rules to replace variable names. Please, check if
the "$file, $dir, etc..." variables will be replaced properly by the shell
instead of make itself.
-- 
Pierre Gaumond.        gaumondp@ERE.UMontreal.CA
Services Informatiques, Universite de Montreal. 
C.P. 6128, Succursale "A", Montreal,            
Quebec, Canada.   H3C 3J7                       


Newsgroups: gnu.emacs.bug
From: cliff@cs.cornell.edu (Cliff Krumvieda)
Subject: cl.elc is not behaving like a compiled cl.el
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 04:17:09 GMT

Howdy:

We're running emacs-18.59 on sparcs and SunOS 4.1.1.  Consider the
following elisp code:

======================================================================
(require 'cl)
(when (not (fboundp 'message-no-log))
  (setf (symbol-function 'message-no-log)
	(symbol-function 'message)))
======================================================================

Emacs-18.58 has no problem evaluating this, but emacs-18.59 complains
with:

 No `setf' update-function for `(symbol-function (quote message-no-log))'

I checked around and discovered that, although, emacs-18.58/lisp/cl.el
and emacs-18.59/lisp/cl.el are identical files,
emacs-18.58/lisp/cl.elc and emacs-18.59/lisp/cl.elc differ.  I then
recomplied emacs-18.59/lisp/cl.el, started a new emacs, loaded the new
.elc file, and evaluated the code above without problems.

Is this a bug with some optimizing byte-compiler?

						--Cliff Krumvieda

Newsgroups: gnu.emacs.bug
From: macrakis@osf.ORG (Stavros Macrakis)
Subject: autosave of large buffers
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 07:10:44 GMT

Epoch 4.0.1 of Tue Jul 21 1992 on phoenix (aix-v3) (Emacs 18.58)

File operations can be very time-consuming on large buffers, both
because of the I/O cost and because the whole buffer needs to be
swapped in.  This is psychologically acceptable when you explicitly
save a buffer, but is very annoying when it is an autosave (especially
an autosave on the large buffer while you're working on a small
buffer!).  It's especially annoying when the change to the large
buffer was accidental (yes, I know I should use C-x C-r
(find-file-read-only) instead of C-x C-f (find-file)....).

Incremental saves would be far cheaper, and Emacs already has the
information to do them, in the form of undo data.  So why not save the
undo data instead?  (except for buffers backed up by copying)  To
protect against file deletion, a #-link could be made to the base
file.  Of course, there is still the danger of the file being modified
in place by someone else.

	-s



Newsgroups: gnu.emacs.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Patch for Emacs 18.59/Ultrix 4.2A/gcc/X
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Fri, 20 Nov 1992 11:07:42 GMT

This patch is necessary to get x11term.c to compile properly.  The reason:
Xlib.h's prototypes depend on Xutil.h, and vice versa.  Real smart, guys.
Perhaps the check for Ultrix should be generalized to DECwindows.

*** x11term.h~  Mon Jul 13 20:09:05 1992
--- x11term.h   Fri Nov 20 02:25:09 1992
***************
*** 1,3 ****
--- 1,6 ----
+ #ifdef ultrix
+ #define NeedFunctionPrototypes 0
+ #endif
  #include <X11/Xlib.h>
  #include <X11/Xatom.h>
  #include <X11/keysym.h>

--
Jason Merrill					jason@jarthur.claremont.edu
This is a self-referential .sig which is not particularly interesting.

Newsgroups: gnu.emacs.bug
From: wjs@wang.COM (William Smith)
Subject: Re: emacs 18.59 under SCO 3.2.2
Organization: Wang Labs, Lowell MA, USA
Distribution: gnu
Date: Tue, 17 Nov 1992 00:18:49 GMT

duplain@btcs.bt.co.UK (Andy Duplain) writes:

>	Has anyone managed to get emacs 18.59 working under SCO 3.2.2 ?
>	When I run emacs I get "select: Invalid argument" in the echo
>	area.

   The select() system in the default C library on SCO 3.2.2 (and ODT 1.1,
maybe 3.2.1 and ODT 1.0 as well) does not work with emacs.  If you are
compiling for SCO and you do not have TCP/IP installed, use the patch
included at the end of this post or just comment out HAVE_SELECT in sco.h.
If you have TCP/IP installed add "#define SCO_SOCKETS" to your config.h.
If you have both TCP/IP and X Windows also add "#define HAVE_X11".  The
select() call in libsocket.a works properly (actually Xselect).  The
resulting config.h file should having the following for TCP/IP and X windows.

---- piece of config.h file ----
...
...
#define SCO_SOCKETS		/* use this if you have TCP/IP */
#define HAVE_X11		/* use this if have X Windows  */
#include "s-sco3-2-2.h"		/* OS release (for 3.2.1 read file comments)*/
...
...
#define HAVE_X_WINDOWS		/* don't forget to uncomment this for X */
---- end config.h -------
   
------add this to s-sco3-2-2.h to fix select() problem--------
...
...
#include "s-sco.h"

#if !defined(SCO_SOCKETS) && !defined(HAVE_X11)
#undef HAVE_SELECT  /* select() in standard C lib broken */
#endif
...
...
------end s-sco3-2-2.h patch--------
-- 
/*-------------------------------------------------------------------------
   William J. Smith, Wang Labs M/S 019-72B, 1 Industrial Ave      
   Lowell, MA 01851-5161,  (508) 967-6901, email: wjs@wiis.wang.com
--------------------------------------------------------------------------*/

Newsgroups: gnu.emacs.bug
From: jimb@totoro.cs.oberlin.edu (Jim Blandy)
Subject: Try this: (funcall '(autoload "file" nil nil nil))
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 14 Nov 1992 21:25:09 GMT

>   Try this: (funcall '(autoload "files" nil nil nil))
>
>   I always get sth like: Fatal error (11).Memory fault(coredump)
>
>The same on Motorola Delta emacs 18.58

A patch:

*** eval.c.~1~  Thu Nov 14 18:01:42 1991
--- eval.c      Sun Nov 15 02:11:51 1992
*************** do_autoload (fundef, funname)
*** 1245,1250 ****
--- 1245,1251 ----
    int count = specpdl_ptr - specpdl;
    Lisp_Object fun, val;
  
+   CHECK_SYMBOL (funname, 1);
    fun = funname;
  
    /* Value saved here is to be restored into Vautoload_queue */

Newsgroups: gnu.emacs.bug