HDTenEightyP/NetNews huggingface dataset:
From: blome@namu01.gwdg.de (Rainer Blome 18805516)
Subject: Try this: (funcall '(autoload "file" nil nil nil))
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 15:59:38 GMT

hi folks!


Try this: (funcall '(autoload "files" nil nil nil))

I always get sth like: Fatal error (11).Memory fault(coredump)

Any filename instead of "files" will do.
I use GNU Emacs 18.57.2 of Mon Sep 30 1991 on namu11.gwdg.de (berkeley-unix).
This surely isn't the way autoload was intended to be used, but crashing is a
bit of an exaggerated reaction to weird lisp style, is it? ;-)
From: gaumondp@ere.umontreal.CA (Gaumond Pierre)
Newsgroups: gnu.emacs.bug
Subject: Re: Emacs installation
Date: 12 Nov 92 16:59:13 GMT
Distribution: gnu
Organization: Universite de Montreal

In article <1992Nov11.204807.25796@cc.umontreal.ca> gaumondp@ere.umontreal.CA (Gaumond Pierre) writes:
>I have a question about the "Makefile" on the main directory of the 18.59
>version of Emacs.
>
>Why don't you use the "-p" option of mkdir in the "mkdir" dependancy?
>
>mkdir: FRC
>	-mkdir ${LIBDIR} ${BINDIR} ${MANDIR}

	I found myself the answer, I was on a System V Unix. I logged myself
	on a BSD Unix and the "-p" option does not exist.

	So, one has to build by hand the directories before doing the make
	command.

>You asssume that only the last part of the path names does not exist. This is
>probably the case with default values on most systems, but if we decide to
>create, say, a test version, with directory names having more than one
>component that don't exist, mkdir will not create the directory.
-- 
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: gaumondp@ere.umontreal.CA (Gaumond Pierre)
Subject: Emacs installation
Organization: Universite de Montreal
Distribution: gnu
Date: Wed, 11 Nov 1992 20:48:07 GMT

I have a question about the "Makefile" on the main directory of the 18.59
version of Emacs.

Why don't you use the "-p" option of mkdir in the "mkdir" dependancy?

mkdir: FRC
	-mkdir ${LIBDIR} ${BINDIR} ${MANDIR}

You asssume that only the last part of the path names does not exist. This is
probably the case with default values on most systems, but if we decide to
create, say, a test version, with directory names having more than one
component that don't exist, mkdir will not create the directory.

Thanks.
-- 
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: karl@claude.cs.umb.edu (Karl Berry)
Subject: emacs 18.59 and ISC 2.2.1
Reply-To: karl@cs.umb.edu
Organization: Gnus Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 05:54:48 GMT

Emacs 18.59 doesn't quite compile as-is on a 386 running Interactive
Unix 2.2.1 (using s-isc2-2.h and m-intel386.h), using GNU make 3.62 and
gcc (2.2.2, but the precise version is irrelevant, I had these troubles
before).  I did:

make LIBDIR=$gnu/lib/emacs CC="gcc -traditional -O"

1) src/ymakefile doesn't include the magic .NOEXPORT target to make GNU
   make not export all environment variables, and so gcc couldn't exec ld.

2) the netinet/in.h header file on this system (stupidly) does the
following:

#if defined(__i386__) && !defined(NO_ASM) && !defined(__STDC__)
   <weird asm statements only understood by cc)
...

Since I was compiling with -traditional, the asm statements were being
read.  My fix: define NO_ASM.  I did this on the command line, but I think
it should probably be added to s-isc2-2.h.  It seems unlikely to hurt.

I was using -traditional in the first place because the POSIX-ified
ISC header files don't work right when __STDC__ is defined without lots
of changes; I sent you those changes for 18.58 and you said you'd rather
just not support POSIX on this system.

Newsgroups: gnu.emacs.bug
From: haibt@theory.lcs.mit.edu (Carolyn Norton)
Subject: emacs bug?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 18:05:26 GMT

I just got the following error message from emacs (actually, NEmacs).  I
save the buffers  and can send them to you as well..

  	Wrong type argument: natnump, #<EMACS BUG:  ILLEGAL DATATYPE
	(#O 50) Save your buffers immediately and please report this bug> 

I wasn't sure how to save any information about the processes which
were running at the time

- Carolyn Norton
  haibt@theory.lcs.mit.edu


Newsgroups: gnu.emacs.bug
From: pinkas@skywalker.intel.com (Israel Pinkas)
Subject: x11term.c bug in 18.59
Organization: Software Technologies, INTeL Corporation, Santa Clara, CA
Distribution: gnu
Date: Thu, 12 Nov 1992 18:32:15 GMT

Emacs version
    18.59 (may be in earlier versions)

Environment
    USL SVR4.2/i386

config.h
    s-usg5-4.h
    m-intel386.h
    HAVE_X_WINDOWS

Other mods
    SVR4 needs CPP=/lib/cpp in src/Makefile

Bug description
    1. Emacs calls free() with a pointer that was returned by
    XrmGetResource().  Since Emacs did not allocate this memory, it should
    not assume that it is free()able.

    2. XrmGetResource() returns a pointer to a static area that is later
    overwritten.  Emacs should copy the data returned by XrmGetResource()
    to a buffer that it allocates with malloc().

Repeat with
    Place a resource in .Xdefaults that can be changed from inside Emacs
    (e.g. *foreground: #000000000000).  Change the resource inside Emacs
    (e.g. M-x x-set-foreground-color red).  Emacs will die calling free().

Fix
    Emacs should make a copy of the data returned by XrmGetResource().
    Context diff follows.

Comments
    Someone should determine whether the XGetDefault() calls could ever
    suffer from the same problem.


-Israel Pinkas

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

*** e59/src/x11term.c.orig	Wed Nov 11 18:30:06 1992
--- e59/src/x11term.c	Wed Nov 11 18:36:42 1992
***************
*** 1631,1638 ****
  
        if (XrmGetResource (db, iname, cname, &dummy, &value))
  	{
! 	  if (entry->varp)
! 	    *entry->varp = (char*)value.addr;
  	}
        else
  	{
--- 1631,1640 ----
  
        if (XrmGetResource (db, iname, cname, &dummy, &value))
  	{
! 	  if (entry->varp) {
! 	    *entry->varp = (char *)xmalloc((size_t)value.size);
! 	    bcopy((char*)value.addr, *entry->varp, (size_t)value.size);
! 	  }
  	}
        else
  	{
--
Israel Pinkas		pinkas@stps18.intel.com		408-765-4210

	"Everybody's askaird of death, until it hits you ...
	 then you don't care"		-Archie Bunker

Newsgroups: gnu.emacs.bug
From: pds@lemming.webo.dg.com (Paul D. Smith)
Subject: Problem with shell subprocesses in Emacs 18.59
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 12:40:07 GMT

Emacs 18.59, on DG AViiON running DG/UX.

I noticed after the previous patch I sent that subprocesses in Emacs
which use process groups (like shell mode) weren't accepting the INTR
and TSTP signals (C-c C-c and C-c C-z).

After a bit of poking in process.c:process_send_signal(), it turns out
that if you're using BSD ioctls (which we do on DG/UX) then TIOCGETC
is used to retrieve the proper char to send down the pipe, and if
you're using SysV then TCGETA ioctl is used.

However, on DG/UX for some reason neither of those is completely
accurate although both are supported: TIOCGETC returns a structure
containing all \0 chars and TCGETA returns the INTR char OK, but
returns \0 for TSTP.

However, I discovered that if you don't special-case either of these
and just pass them as normal signals to the subprocess via the
killpg() call, everything works fine.

So, what I did was to add a !defined(DGUX) to the #ifndef
SIGNALS_VIA_CHARACTERS in process.c (see below) so neither of the
switch (signo) constructs were compiled in (see patch below)

I'm not sure whether you want to add a new #define for this (systems
which don't need special handling of INTR, QUIT, and TSTP signals) or
just leave this as a special case for DGUX.

                                                                paul
-----
 ------------------------------------------------------------------
| Paul D. Smith                          |    paul_smith@dg.com    |
| Data General Corp.                     | pds@lemming.webo.dg.com |
| Network Systems Development Division   |                         |
| Open Network Systems Development       |   "Pretty Damn S..."    |
 ------------------------------------------------------------------
-------------------------------------------------------------------------------
--- process.c-dist      Sun Oct 25 00:42:04 1992
+++ process.c   Tue Nov 10 17:30:23 1992
@@ -2169,7 +2169,7 @@
     {
       /* If possible, send signals to the entire pgrp
         by sending an input character to it.  */
-#ifndef SIGNALS_VIA_CHARACTERS
+#if !defined (SIGNALS_VIA_CHARACTERS) && !defined (DGUX)
 #if defined (TIOCGLTC) && defined (TIOCGETC)
       struct tchars c;
       struct ltchars lc;
@@ -2192,7 +2192,7 @@
 #endif
        }
 #endif /* have TIOCGLTC and have TIOCGETC */
-#endif /* not SIGNALS_VIA_CHARACTERS */
+#endif /* not SIGNALS_VIA_CHARACTERS && not DGUX */
       /* It is possible that the following code would work
         on other kinds of USG systems, not just on the IRIS.
         This should be tried in Emacs 19.  */

Newsgroups: gnu.emacs.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: Emacs 18.59 on IBM RT
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 05:55:02 GMT

Emacs 18.59 doesn't quite compile as-is on an IBM RT running AOS (4.3
BSD) using gcc 2.3.1: m-ibmrt.h unconditionally defines alloca=_Alloca,
but this is wrong if gcc is being used.  Here is a small patch that makes the
define conditional.

Sat Nov  7 07:21:05 1992  Karl Berry  (karl@red.cs.umb.edu)

        * m-ibmrt.h (C_SWITCH_MACHINE) [!__GNUC__]: Make the -Dalloca
          conditional; we don't need it for gcc.

*** ./ORIG/m-ibmrt.h	Tue Jan  8 09:54:26 1991
--- ./m-ibmrt.h	Sat Nov  7 03:47:24 1992
***************
*** 126,132 ****
--- 126,134 ----
  
  /* Special switches to give the C compiler.  */
  
+ #ifndef __GNUC__
  #define C_SWITCH_MACHINE -Dalloca=_Alloca
+ #endif
  
  /* Don't attempt to relabel some of the data as text when dumping.
     It does not work because their virtual addresses are not consecutive.

Newsgroups: gnu.emacs.bug
From: nickel@cs.tu-berlin.DE (Juergen Nickelsen)
Subject: Re: Another bug with y-or-n-p in 18.59
Reply-To: nickel@cs.tu-berlin.de
Organization: STONE Project, Technical University of Berlin, Germany
Distribution: gnu
Date: Mon, 9 Nov 1992 13:35:46 GMT

In article <NICKEL.92Nov6214416@desaster.cs.tu-berlin.de>
I wrote:

> But the behaviour in 18.59 is still not really satisfying: It is now
> simply impossible to interrupt y-or-n-p if it has been invoked from a
> process filter. This is not what I want; I think it should be
> interruptible as usual.

In the meantime I have been told that inhibit-quit is set to t in a
process filter, to make y-or-n-p interruptible I have to set it to nil
explicitly.  Thanks!

--
Juergen Nickelsen

Newsgroups: gnu.emacs.bug
From: nickel@cs.tu-berlin.DE (Juergen Nickelsen)
Subject: Another bug with y-or-n-p in 18.59
Reply-To: nickel@cs.tu-berlin.de
Organization: STONE Project, Technical University of Berlin, Germany
Distribution: gnu
Date: Fri, 6 Nov 1992 20:44:17 GMT

There had been a bug in 18.58: If y-or-n-p was invoked from a process
filter and the user interrupted it with C-g, Emacs looped emitting
C-g's. This has been fixed.

But the behaviour in 18.59 is still not really satisfying: It is now
simply impossible to interrupt y-or-n-p if it has been invoked from a
process filter. This is not what I want; I think it should be
interruptible as usual.

--
Juergen Nickelsen

Newsgroups: gnu.emacs.bug
From: rlk@think.com (Robert L Krawitz)
Subject: rfc822 in 18.55 (yah, sorry 'bout that...)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 8 Nov 1992 16:33:50 GMT

The following from: line appears to throw rfc822 into an infinite loop
(or at least, that's what the debugger showed the parser to be working
on).

While clearly an erroneous address, an infinite loop isn't what I would
consider appropriate behavior.

From: rbrooks1@cc.swarthmore.edu> (Rob Brooks)

Newsgroups: gnu.emacs.bug
From: enami@sys.PTg.sony.co.JP (enami tsugutomo)
Subject: (string-match "[A-[]" "A") fails when case-fold-search
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 06:19:02 GMT

In GNU Emacs 18.59.0 of Tue Nov 10 1992 on kitt (berkeley-unix)

(string-match "[A-[]" "A") fails when case-fold-search is t.  This is
because bug in regex.c.  PATFECTH does implecit translate, so we must
use PATFETCH_RAW.  Here is a patch.

--enami.
===================================================================
RCS file: RCS/regex.c,v
retrieving revision 1.1
diff -u -r1.1 regex.c
--- 1.1	1992/11/10 04:55:00
+++ regex.c	1992/11/10 04:55:51
@@ -404,12 +404,12 @@
 	  /* Read in characters and ranges, setting map bits */
 	  while (1)
 	    {
-	      PATFETCH (c);
+	      PATFETCH_RAW (c);
 	      if (c == ']' && p != p1 + 1) break;
 	      if (*p == '-' && p[1] != ']')
 		{
-		  PATFETCH (c1);
-		  PATFETCH (c1);
+		  PATFETCH_RAW (c1);
+		  PATFETCH_RAW (c1);
 		  if (translate)
 		    while (c <= c1)
 		      {

Newsgroups: gnu.emacs.bug
From: mjw+@cs.cmu.edu (Michael Witbrock)
Subject: named macro problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 11:43:51 GMT

   Gnuemacs 18.56.3 CRASHES if you do a ctrl u repetition of an invocation of
   a named keyboard macro

   e.g.
   ctrl-U meta-X fixnet
   where fixnet is a name-last-keyboard-macro result will cause it
   gnuemacs to exit. very annoying when it happens. (both time it was on
   a rs6000, once here, once a year ago at another site) 

   Does anyone have any idea why this happens, and whether it has been
fixed in a later release. I don't do this often, but when I do....


michael

Newsgroups: gnu.emacs.bug
From: eostrom@nic.gac.edu (Erik Ostrom)
Subject: manual-program not found
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 20:14:56 GMT

doing M-x manual-entry RET creat RET (under emacs 18.59) gave me
(file-error "Searching for program" "no such file or directory" "/usr/bin/man")
because paths.el set manual-program wrong.  Suggested fix, assuming
NeXTs generally have this file setup and it's not some weird local quirk:

*** paths.el-orig	Thu Nov  5 14:12:29 1992
--- paths.el	Thu Nov  5 14:12:55 1992
***************
*** 73,79 ****
  You may set this variable to nil in your `.emacs' file if you do not wish
  the terminal-initialization file to be loaded.")
  
! (defconst manual-program (if (eq system-type 'berkeley-unix)
  			     "/usr/ucb/man" "/usr/bin/man")
    "Program to run to print man pages.")
  
--- 73,79 ----
  You may set this variable to nil in your `.emacs' file if you do not wish
  the terminal-initialization file to be loaded.")
  
! (defconst manual-program (if (memq system-type '(berkeley-unix next-mach))
  			     "/usr/ucb/man" "/usr/bin/man")
    "Program to run to print man pages.")
  

Newsgroups: gnu.emacs.bug
From: winkler@sunburn.stanford.edu (Phyllis Winkler)
Subject: note from Don Knuth
Reply-To: winkler@cs.stanford.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 05:19:59 GMT

If I'm using emacs version 18.58 (berkeley-unix),
and if I'm running M-x shell in a buffer,
and if the program in that buffer is executing merrily and sending
            stuff to standard output (i.e., to that buffer),
and if I meanwhile decide to look at bytes near the top of the buffer
and if I use the narrow-to-region command so that only a small part
            of the upper buffer material is displayed,
   then the bottom end of the displayed material moves down by n chars
   whenever n more chars are sent to standard output
even though the region I've narrowed to was supposed to have a
fixed lower boundary, well above where that standard output would
ordinarily appear without narrowing.

Since the value of n has no semantic significance in the narrowed
region, the result can be disconcerting...

Of course one can live with this. I report it only because emacs is so
wonderful in every other respect.

Newsgroups: gnu.emacs.bug
From: warsaw@nlm.NIh.GOV (Barry A. Warsaw)
Subject: Re: some commands should save window configuration
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
Distribution: gnu
Date: Thu, 5 Nov 1992 21:42:57 GMT

>>>>> "Jonathan" == Jonathan R. Ferro <jf41> writes:

    Jonathan> I like emacs' ability to start some feature and keep it
    Jonathan> readily available over the course of an entire session
    Jonathan> through judicious use of "C-x b".  If there's one thing
    Jonathan> I can NOT stand it's emacs features that "help" me when
    Jonathan> I finally quit by putting me back in the window
    Jonathan> configuration I was in OVER THREE HOURS AGO.

I agree. One package I've recently downloaded and started to use which
*really* makes buffer management so much better is wicos.el, written
by Heikki Suopanki <suopanki@phoenix.oulu.fi>.  I think this used to
be called screens.el.  Give it a look.  For me its one of those
can't-go-back-or-do-without packages.

Newsgroups: gnu.emacs.bug
From: duplain@btcs.bt.co.UK (Andy Duplain)
Subject: emacs 18.59 under SCO 3.2.2
Organization: BT Customer Systems, Brighton, UK
Distribution: gnu
Date: Thu, 12 Nov 1992 10:54:05 GMT

	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.


-- 
Andy Duplain, BT Customer Systems, Brighton, UK.            duplain@rtf.bt.co.uk
#define	DISCLAIMER      My views and opinions are my own, and not my company's

Newsgroups: gnu.emacs.bug
From: rfinch@caldwr.UUCP (Ralph Finch)
Subject: demacs: fix for tags tables
Followup-To: comp.emacs
Organization: Calif. Dept. of Water Resources
Distribution: gnu
Date: Thu, 5 Nov 1992 19:00:45 GMT

Does anybody else have problems with tag tables with demacs?  I
did...here's a routine I modified to fix it.  Seems the 'read'
function in the original wasn't returning quite the right value, so I
avoided it.  Replace tag-table-files in your tags.el file or make sure
this gets loaded after that file.  Warning: this has not been
throughly checked!  It's something I hacked out quickly, and offer
here just in case somebody else has the same problem.



(defun tag-table-files ()
  "Return a list of files in the current tag table.
File names returned are absolute."
  (save-excursion
   (visit-tags-table-buffer)
   (or tag-table-files
       (let (files)
	(goto-char (point-min))
	(while (re-search-forward "\n\\([^,]+\\),[0-9]+$" nil t)
	  (setq files (cons (expand-file-name
			     (buffer-substring (match-beginning 1) (match-end 1))
			     (file-name-directory tags-file-name))
			    files))
	  (goto-char (match-end 0))
	  )
	(setq tag-table-files (nreverse files))))))


--
Ralph Finch			916-653-8268
rfinch@water.ca.gov		...ucbvax!ucdavis!caldwr!rfinch
Any opinions expressed are my own; they do not represent the DWR

Newsgroups: gnu.emacs.bug
From: jv@mh.NL (Johan Vromans)
Subject: Flickering cursor in X11 emacs 18.59
Organization: Multihouse Automation, the Netherlands
Distribution: gnu
Date: Mon, 9 Nov 1992 08:53:29 GMT

Hi,

I have noticed that in emacs 18.59, when running under X, the cursor
flickers (i.e. is turned off and on again) while typing at the end of
the line. It does not happen while inserting text.
The system is DECsystem5000/200, running Ultrix 4.3.

18.58 does not have this behaviour.

Is this a bug or intentional?

	Johan
--
Johan Vromans				       jv@mh.nl via internet backbones
Multihouse Automatisering bv		       uucp:..!{uunet,sun4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands  phone/fax: +31 1820 62911/62500
------------------------ "Arms are made for hugging" -------------------------

Newsgroups: gnu.emacs.bug
From: jgd@acl.lanl.gov (Jerry G. DeLapp)
Subject: Re: 18.59 problem -- Error in init file
Reply-To: jgd@acl.lanl.gov
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 06:06:27 GMT

I think I've found the problem. The system was snarfing my .emacs file even
though I'd done an su root to do the build and was testing as root. Is it
possible that the algorithm for finding the .emacs file is connecting to the
wrong place? That is, when su'ed to another user, I sort of expect emacs to
look for .emacs in the other user's home. In the case of root, /.emacs instead
of ~jgd/.emacs.

Anyway, as soon as I moved my .emacs aside the error message went away. But
I'd sure like to know how this works.

Jerry G. DeLapp -- ACL System Scientist -- (505) 665-4531 <jgd@lanl.gov>
Computing beyond the Bleeding Edge -- The Advanced Computing Laboratory

Newsgroups: gnu.emacs.bug
From: ange@hplb.hpl.hp.com (Andy Norman)
Subject: expand-file-name BUG?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 14:11:00 GMT

GNU Emacs version: 18.58
Hardware: HP9000/425s
OS: HP-UX 7.05

It may be a bug or a feature.  The Emacs lisp expression:

  (expand-file-name "/.")

evaluates to the empty string "".

I would have expected either "/" or "/.".

					-- ange -- <><

					ange@hplb.hpl.hp.com


Newsgroups: gnu.emacs.bug
From: gaumondp@ere.umontreal.CA (Gaumond Pierre)
Subject: Emacs installation
Organization: Universite de Montreal
Distribution: gnu
Date: Wed, 11 Nov 1992 21:21:42 GMT

I have a question about the "Makefile" on the main directory of the 18.59
version of Emacs.

Why don't you use the "-p" option of mkdir in the "mkdir" dependancy?

mkdir: FRC
	-mkdir ${LIBDIR} ${BINDIR} ${MANDIR}

You asssume that only the last part of the path names does not exist. This is
probably the case with default values on most systems, but if we decide to
create, say, a test version, with directory names having more than one
component that don't exist, mkdir will not create the directory.

Thanks.

-- 
Pierre Gaumond.        gaumondp@ERE.UMontreal.CA
Services Informatiques, Universite de Montreal. 
C.P. 6128, Succursale "A", Montreal,            
Quebec, Canada.   H3C 3J7
From: gaumondp@ere.umontreal.CA (Gaumond Pierre)
Newsgroups: gnu.emacs.bug
Subject: Re: Emacs installation
Date: 12 Nov 92 16:18:16 GMT
Distribution: gnu
Organization: Universite de Montreal

Sorry if the same article came many times, there seems to be some
problem on our local News server.

-- 
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: scottm@intime.INTime.COM (Scott Michel)
Subject: Formatting emacs.texi w/makeinfo or (texinfo-format-buffer)
Organization: -- J/24 -- Racers Home for Programmers
Distribution: gnu
Date: Tue, 10 Nov 1992 01:20:09 GMT

Emacs 18.59 (no patches at all. Actually 18.58 with the 18.59 patches applied)
s-sco3-2-2.h, m-intel386.h

I was crazy enough to do this. However, Emacs complains that it knows nothing
about "@finalout" or "@top". These are the two major offenders, although I'm
sure there are more.

Using makeinfo 1.40, I get messages about nodes missing "Up" nodes.

Either way, I'm being hosed (or Emacs is, I'm not quite sure).

Don't bother me with "Use the info files in the distribution" 'cause I've
already nuked them.

-scottm


Newsgroups: gnu.emacs.bug