HDTenEightyP/NetNews huggingface dataset:
From: gallo@sirius.gsi.fr (Jean-Luc Gallo)
Newsgroups: gnu.gcc.help
Subject: VA_LIST ON HP/UX PA with GCC2.2.2
Summary: VA_LIST ON HP/UX with GCC 2.2.2
Date: 19 Aug 92 11:20:27 GMT
Organization: GSI Generale de Service Informatique
X-Newsreader: Tin 1.1 PL4



I want to use va_list with GNU ANSI C on HP PA without 
having to check for arguments' type (va_arg()) like it can 
be done with sunOS. I would like to call vsprintf
or vfprintf too.
Gnu precises it's not yet possible with the 2.2.2 version of gcc.
Has anybody resolved this problem?

Please Email the answer to Jean-Luc.Gallo@gsi.fr
Thank's in advance
Jean-Luc



--
==============================================================================
| Jean-Luc Gallo                       | E-mail: Jean-Luc.Gallo@gsi.fr       |
| GSI (Generale Service Informatique)  | Voice : (33)-1-45667889             |
| 45 Rue de la procession              | Fax   : (33)-1-47344692             |
| 75015 PARIS                          |                                     |
==============================================================================
Newsgroups: gnu.smalltalk.bug
From: stickler@cc.helsinki.FI (Patric M Stickler)
Subject: Re: Disk Thrashing!?! HELP!
Organization: University of Helsinki
Distribution: gnu
Date: Thu, 13 Aug 1992 06:17:52 GMT

And does anyone know of a port of either 1.1 or 1.2 to the 
IBM RS/6000 running AIX 3.x ???



//////////////////////////////////////////////////////////////////////////
  Patrick M. Stickler (psti@wsoy.fi)      The comments contained herein
  WSOY, Information Systems Division      do not necessarily reflect the
  Bulevardi 12, 00121 Helsinki Finland    official views of my employer.
//////////////////////////////////////////////////////////////////////////


Newsgroups: gnu.smalltalk.bug
From: twpierce@amhux1.amherst.edu (Tim Pierce)
Subject: emacs 18.58: invalid default-directory after su
Organization: Amherst College, Amherst MA
Distribution: gnu
Date: Sat, 15 Aug 1992 18:39:51 GMT

I am running Emacs 18.58 under Ultrix 4.2 here (on a DECstation
5000/133) and encountered the following peculiar problem.  When I "su
root", change to another directory, and invoke emacs, the value of
default-directory is initialized to what my directory was _before_ the
su, making things rather annoying when I use find-file, for example.

Peeking at files.el and startup.el tells me that Emacs initializes
default-directory on startup to the value of the PWD environment
variable, which is inherited from the environment of its parent
process.  I suspect this is caused by the fact that my login shell is
tcsh while root's is csh.

Naturally, I could avoid this by changing either my login shell or
root's, or doing "su - root" rather than "su root".  But it doesn't
seem like I should HAVE to.  Any thoughts?

-- 
____ Tim Pierce                / "Bisexual just means you pay for it."
\  / twpierce@amherst.edu      /  
 \/ (BITnet: TWPIERCE@AMHERST) /   -- Rock Hudson
From: root@uxws02.onco.noaa.gov (Operator)
Newsgroups: gnu.emacs.bug
Subject: EMACS on SPARC
Date: 13 Aug 92 20:14:29 GMT
Distribution: gnu
Organization: GNUs Not Usenet


	Thanks for your prompt reply to my question about errors
compiling emacs.  Kevin in the UK pointed me to the right file.  This
has allowed me to build emacs, but when I run it I get "Fatal error
(6). Abort".  The executables are isolated in their own directory
which is on my path.  Ther are four: ctags, emacs, emacsclient and
etags.  Unfortunately, I can't print the manuals because I do not have
access to TeX yet.  BTW, once I get TeX are there minimalist
directions for dumping the manuals to my postscript printer?
						Thanks, TOM
Newsgroups: gnu.emacs.bug
From: piet@cs.ruu.NL (Piet van Oostrum)
Subject: bug in pop-to-buffer
Reply-To: piet@cs.ruu.nl (Piet van Oostrum)
Organization: Dept of Computer Science, Utrecht University, The Netherlands
Distribution: gnu
Date: Thu, 20 Aug 1992 12:41:17 GMT

I noticed that in emacs 18.58 pop-to-buffer does not properly set the point
if that has been changed in the mean-time. Whereas switch-to-buffer does
this correctly. E.g:

(defun ttt (new-buffer)
  (interactive "bbuffer:")
  (set-buffer new-buffer)
  (goto-char 1)
  (pop-to-buffer new-buffer)
)

The point in new-buffer will not be at 1. It will if you replace
pop-to-buffer with switch-to-buffer. In 18.55 this was working correctly

I noticed that switch-to-buffer calls set-window-buffer whereas
pop-to-buffer calls select-window

select-window calls SET_PT (marker_position (w->pointm)) which (I think)
sets the point to the value it did have on the previous edit operation,
regardless of any changes made. In 18.55 this was only done if the old and
the new window had the same buffer.

I can temporarily go around this with the following;

(defun my-pop-to-buffer (buffer &optional other)
  (set-window-point (display-buffer buffer other) (point))
  (pop-to-buffer buffer other))
-- 
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806   Uucp:   uunet!mcsun!ruuinf!piet
Telefax:   +31 30 513791   Internet:  piet@cs.ruu.nl   (*`Pete')

Newsgroups: gnu.emacs.bug
From: pot@fly.cnuce.cnr.it (Francesco Potorti`)
Subject: repeatable illegal instruction bug in emacs 18.57
Reply-To: pot@cnuce.cnr.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 17 Aug 1992 14:55:00 GMT

   I defined a function to speed up setting the debug-on-error flag:

   (defun debug ()
     (interactive)
     (setq debug-on-error t))

   Unfortunately, it appears that 'debug' is already defined in debug.el:

   (defun debug (&rest debugger-args)
      ...

   When I type M-x debug, then cause an error (by typing "M-< C-b", for
   example) emacs hangs for a while, then dumps core.  I'd normally expect
   this to stop after a short time, saying "Lisp nesting exceeds
   max-lisp-eval-depth", but it doesn't in this case.

The same happens on a Motorola Delta running emacs 18.58.
The emacs process begins to slowly eat up memory until it dumps core.
The whole story is very slow: every ~1 min. the process size increases by
approx. 800Kbytes.

		    Francesco Potorti`	| pot@cnuce.cnr.IT (Internet)
				 	| 39369::pot       (DECnet)
					| (39)(50)593203   (voice)

Newsgroups: gnu.emacs.bug
From: jkp@cs.HUt.FI (Jyrki Kuoppala)
Subject: Emacs 18.58, mode of ~/.newmail and some other mail files
Organization: Helsinki University of Technology, Finland.
Distribution: gnu
Date: Wed, 12 Aug 1992 03:29:28 GMT

Emacs 18.58 rmail uses the default mode by `umask' to write the file
~/.newmail when transferring mail from the spool file to the user's
RMAIL file.  It would seem that a better guess at how the user wants
her email file modes to be would be to look at the spool file or RMAIL
file modes.

The mode for the autosave of the *mail* buffer also appears to be just
from the umask - perhaps this mode could also be copied from the RMAIL
or spool file.  Same seems to hold for the file %backup%~.

A related possible problem: when emacs is adding to the RMAIL file,
the file RMAIL is readable to all:

jkp@laphroaig '~' 394: L RMAIL
-rw-------   1 jkp      other     1908372 Aug 11 23:26 RMAIL
jkp@laphroaig '~' 397: : > RMAIL 
jkp@laphroaig '~' 398: L .newmail 
-rw-r--r--   1 jkp      other        3336 Aug 12 00:18 .newmail
jkp@laphroaig '~' 399: rm .newmail 
rm: remove `.newmail'? y
jkp@laphroaig '~' 400: 
jkp@laphroaig '~' 400: 
jkp@laphroaig '~' 400: L RMAIL  (at this time emacs is in the process
                                 of writing to the RMAIL file)
-rw-r--r--   1 jkp      other     1670444 Aug 12  1992 RMAIL

//Jyrki

Newsgroups: gnu.emacs.bug
From: ralf@up3aud1.gwdg.de (Ralf Fassel)
Subject: abbrev-mode bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 11 Aug 1992 17:06:46 GMT

Guten Tag,
found sth that looks like a bug in abbrev-mode in
(emacs-version) "GNU Emacs 18.57.4 of Thu Apr 16 1992 on hinz (berkeley-unix)"
running on a Sun-Sparc IPC, SunOS 4.1.2.

my-shell-prompt: emacs -q
then execute lisp-expessions (or laod-file with contents:)

(define-abbrev-table 'lisp-mode-abbrev-table '(
    ("abb" "abbrev" nil 0)
    ))
(abbrev-mode 1)


Now insert 'abb', type ESC-' (abbrev-prefix-mark) to mark 'abb' 
as prefix and insert 'mode ' to expand the abbrev.
Screen looks like
>abbrev-mode <
where it should be
>abbrevmode <
(arrows to show spaces). 

It seems to be a screen-updating problem, because a redisplay or 
deletion of characters in front of the minus-sign makes the screen 
show up the correct contents of the buffer.

Best regards 
Ralf

---------------------------------------------------------
Ralf Fassel                   III.Physikalisches Institut
Internet: ralf@up3aud1.gwdg.de          Buergerstr. 42-44
Phone: (Germany)(551)39-7730            W-3400 Goettingen
FAX:   (Germany)(551)39-7720                      Germany

Newsgroups: gnu.emacs.bug
From: me@sunburn.stanford.edu (Martin Frost)
Subject: COMPOSE meta key generates space on DECstations in 18.58
Reply-To: me@cs.stanford.edu
Organization: Computer Science Department, Stanford University.
Distribution: gnu
Date: Thu, 13 Aug 1992 04:24:28 GMT

I've discovered that the COMPOSE key on various DECstations, in addition to
acting as the META key, causes an extra space to be "typed" at emacs.  This
must be a well known problem by now.  What's the cause/solution?  Thanks.

This is in emacs 18.58.  18.57 didn't have this problem.
--
------------------
Martin Frost		Computer Science Department, Computer Facilities
Systems Programmer	Stanford University, Stanford, CA  94305-2140
me@CS.Stanford.EDU	(or decwrl!labrea!me or mfrost@stanford.bitnet)

Newsgroups: gnu.emacs.bug
From: jsp@betz.biostr.washington.edu (Jeff Prothero)
Subject: outline-mode
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 11:32:40 GMT

BUG:
  In 18.58 (at least) outline.el:outline-mode docstring has
  the keybindings hardwired instead of using \\{outline-mode-map}

RANDOM VERBIAGE:

* If you are Eric S Raymond, I'd not mind having your email address
  :).  (I'm the Jeff you met at Matuszek's.)

* I, at least, think outline-mode looks very handy for C and lisp
  files as well as straight outline editing:  I'm adding the
  outline commands to c-mode and the lisp modes, using ^O as the
  prefix key for them (and moving open-line to ^O^O).  And changing
  outline-mode proper to use ^O as the prefix too, for compatibility.
  Somehow ^O seems more mnemonic for 'outline' anyhow :).

ad astra
Jeff / jsp@glia.biostr.washington.edu

Newsgroups: gnu.emacs.bug
From: geoffo@cs.unsw.oz.AU (Geoff Oakley)
Subject: Bug in etags building up the TEXTAGS table
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 18 Aug 1992 21:49:32 GMT

There is an apparent bug in etags in building up the TEXTAGS table.

The source file etags.c includes:

++  /* Default set of control sequences to put into TEX_toktab.
++     The value of environment var TEXTAGS is prepended to this.  */
++  
++  static char *TEX_defenv =
++    ":chapter:section:subsection:subsubsection:eqno:label:ref:cite:bibitem:typeout";
++  
  
    [ stuff ommitted ]
  
++  
++    /* Append deafult string to environment. */
++    env = (char *) getenv (evarname);
++    if (!env)
++      env = defenv;
++    else
++      env = concat (env, defenv, "");
++  
++    /* Allocate a token table */
++    for (size = 1, p=env; p;)
++      if ((p = index (p, ':')) && *(++p))
++        size++;
++    tab = (struct TEX_tabent *) xmalloc (size * sizeof (struct TEX_tabent));
++  
++    /* Unpack environment string into token table. Be careful about */
++    /* zero-length strings (leading ':', "::" and trailing ':') */
++    for (i = 0; *env;)
++      {
++        p = index (env, ':');
++        if (!p)			/* End of environment string. */
++  	    p = env + strlen (env);
++        if (p - env > 0)
++  	    {	/* Only non-zero strings. */
++  	      tab[i].name = savenstr (env, p - env);
++  	      tab[i].len = strlen (tab[i].name);
++  	      i++;
++  	    }
++        if (*p)
++  	    env = p + 1;
++        else
++  	    {
++  	      tab[i].name = NULL;	/* Mark end of table. */
++  	      tab[i].len = 0;
++  	      break;
++  	    }
++      }


Now, `size' is calculated to the one more that the number of colons in
`env'.  If the environment variable TEXTAGS contains a real string,
then the number of tags in the resulting `env' is also one more than
the number of colons (ie, number-of-tags=`size').  All these tags are
added to the table, filling the table up, but a final NULL entry is
then added to terminate the table.  This overfills the table and can
cause trashed memory.

A solution is to increment size (by one more).


Geoff O


	       geoffo@spectrum.cs.unsw.oz.au
Geoff Oakley:  CS & E, UNSW, PO Box 1, Kensington, NSW 2033, Australia
	       Phone: +61 2 697 4043	Fax: +61 2 313 7987

Newsgroups: gnu.emacs.bug
From: jbw@cs.bu.edu (Joe Wells)
Subject: no after-write-file-hooks variable
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 18 Aug 1992 09:38:18 GMT

There is no after-write-file-hooks variable in Emacs 18.58.  There should
be.

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

Newsgroups: gnu.emacs.bug
From: ppoh@amethyst.tcs.tufts.edu (Paul B. Poh)
Subject: .emacs file problem
Organization: Tufts University - Medford, MA
Distribution: gnu
Date: Fri, 14 Aug 1992 15:12:47 GMT

I'm running emacs 18.58, I created a .emacs file with the following two
lines:

(global-set-key "\M-Ou" 'goto-line)
(global-set-key "\M-g" 'goto-line)

When I run emacs, the key sequence "\M-Ou" does not get set to 'goto-line.
Doing a M-x apropos goto-line shows:

goto-line	ESC g

however I can set the key sequence "\M-Ou" key by doing a M-x
eval-expression (global-set-key "\M-Ou" 'goto-line) in emacs.

But more interestingly, when I run the same .emacs file under X.

% emacs -display machine:0.0

The key sequence "\M-Ou" does get set correctly.

Using various other characters should as a, p, f instead of u can 
also change the result of wheather the key sequences gets bound.

M-x describe-bindings doesn't show that other of those bindings 
are already used.

Any ideas? :=)
--
Paul Poh                        Unix Systems Programmer
ppoh@amethyst.tcs.tufts.edu     Computer Services, Tufts University

Newsgroups: gnu.emacs.bug
From: carlisle@cs.man.ac.UK (David Carlisle)
Subject: killing an empty region
Organization: Department of Computer Science, University of Manchester
Distribution: gnu
Date: Tue, 11 Aug 1992 16:29:21 GMT

 GNU Emacs 18.57.4 of Wed Apr  3 1991 on r8e (berkeley-unix)

Killing an empty region puts nil on the kill ring.

If this is yanked back, it produces an error:

Wrong type argument: char-or-string-p, nil

To repeat this (with the standard key bindings)

C-SPC C-w C-y

killing an empty region should put either "" or nothing on the ring,
or the yank functions should skip nil entries.

--
                           David Carlisle
                                    JANET: carlisle@uk.ac.man.cs

                                    Computer Science Department
                                    Manchester University
                                    Oxford Road
                                    Manchester
                                    England
                                    M13 9PL

Newsgroups: gnu.emacs.bug
From: kyle@wendy-fate.uu.net (Kyle Jones)
Subject: Re: invalid buffer-file-name crashes emacs
Organization: UUNET Communications
Distribution: gnu
Date: Thu, 13 Aug 1992 11:18:33 GMT

dan@math.uiuc.edu writes:
 > Do this to make emacs 18.58 crash with an illegal instruction on a vaxstation
 > II running Ultrix 2.0.
 > 
 > (find-file "junk.foo")
 > (setq buffer-file-name (cons "asdf" "qwer"))
 > (insert "asdf")

Confirmed this on a Sun SLC running 4.1.2.  Made the kernel howl
in pain...

sendsig: bad signal stack pid=22240, sig=11
sigsp = 0xebf17898, action = 0x75400, upc = 0x66848


Newsgroups: gnu.emacs.bug
From: steiner@bakerst.rutgers.edu
Subject: ispell-buffer bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 20 Aug 1992 17:16:09 GMT

In GNU Emacs 18.58.1 of Fri Jul 10 1992 on klinzhai.rutgers.edu (berkeley-unix)

If you ispell-buffer a tex file, it comes back and says "Current
buffer has no processes".  This is because emacs wants to kill the
ispell process when the ispell-args has changed (eg, it's a tex file
so -t is used) but doesn't check if it has one already running.  So
the following patch will work:

*** ispell.el.ORIG	Thu Nov 21 16:30:17 1991
--- ispell.el	Thu Aug 20 17:49:23 1992
***************
*** 291,297 ****
      (message "Starting new ispell process...")
      (if (not (equal ispell-args ispell-old-args))
  	(progn  ; we have to kill and restart
! 	  (quit-process ispell-process)
  	  (setq ispell-old-args ispell-args)))
      (and (get-buffer ispell-out-name) (kill-buffer ispell-out-name))
      (setq ispell-process (apply 'start-process "ispell"
--- 291,297 ----
      (message "Starting new ispell process...")
      (if (not (equal ispell-args ispell-old-args))
  	(progn  ; we have to kill and restart
! 	  (if ispell-process (quit-process ispell-process))
  	  (setq ispell-old-args ispell-args)))
      (and (get-buffer ispell-out-name) (kill-buffer ispell-out-name))
      (setq ispell-process (apply 'start-process "ispell"


Also the ispell will complain about things like '\hbox' even though
the -t flag is used.  It should ignore tex commands with the -t flag.
I haven't looked into this one yet.

ds

Dave Steiner
arpa: Steiner@BakerSt.Rutgers.Edu or Steiner@Rutgers.Edu
uucp: ...{backbone site}!rutgers!bakerst.rutgers.edu!steiner

Newsgroups: gnu.emacs.bug
From: mjn@mmi-dev-1.jet.UK (Mark J Neale)
Subject: compile mode sometimes kills wrong process
Organization: Joint European Torus
Distribution: gnu
Date: Thu, 13 Aug 1992 19:25:10 GMT

GNU Emacs 18.57.8 of Wed Jul 22 1992 on mmi-dev-1 (berkeley-unix)

I have discovered that sometimes starting a compilation process when
another one is running kills the wrong process. To test this, start a
shell. Then start a compilation process (or grep) which takes a while
to complete. From the shell buffer, start another compilation. You get
a prompt saying there is one already running and do you want to kill
it. Wait for the compilation to complete and then type yes. The shell
then terminates.

To fix this, patch compile.el according to the diffs below.

*** emacs/lisp/compile.el       Wed Jan  9 21:57:05 1991
--- work/EMACS/local/lisp/compile.el    Thu Aug 13 15:16:18 1992
***************
*** 71,79 ****
              (yes-or-no-p "A compilation process is running; kill it? "))
          (condition-case ()
              (let ((comp-proc compilation-process))
!               (interrupt-process comp-proc)
!               (sit-for 1)
!               (delete-process comp-proc))
            (error nil))
        (error "Cannot have two compilation processes")))
    (setq compilation-process nil)
--- 71,81 ----
              (yes-or-no-p "A compilation process is running; kill it? "))
          (condition-case ()
              (let ((comp-proc compilation-process))
!               (if comp-proc
!                   (progn
!                     (interrupt-process comp-proc)
!                     (sit-for 1)
!                     (delete-process comp-proc))))
            (error nil))
        (error "Cannot have two compilation processes")))
    (setq compilation-process nil)
--
      #                   Mark Neale (mjn@jet.uk)
      #  ######   #####   Juggling with the parameters of Fusion.
      #  #          #
      #  #####      #     Joint European Torus, Culham Lab. OX14 3EA, UK
#     #  #          #     +44 235 465272
 #####   ######     #     Any opinion expressed above is.
-- 
      #                   Mark Neale (mjn@jet.uk)
      #  ######   #####   Juggling with the parameters of Fusion.
      #  #          #
      #  #####      #     Joint European Torus, Culham Lab. OX14 3EA, UK
#     #  #          #     +44 235 465272
 #####   ######     #     Any opinion expressed above is.
- Disclaimer: Please note that the above is a personal view and should not 
  be construed as an official comment from the JET project.

Newsgroups: gnu.emacs.bug
From: barmar@think.com (Barry Margolin)
Subject: Re: possible bug in rmail-reply command
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: gnu
Date: Wed, 19 Aug 1992 20:08:55 GMT

In article <9208180902.AA00911@naja.gr.osf.org> jose@gr.osf.ORG writes:
>I found a possible bug in the rmail-reply command: when you reply, the
>Re: field is not inserted in the subject field. Besides, if the
>subject already contains the Re: field, it gets deleted.

I believe this is intentional.  Some of us don't believe that the "Re:" is
necessary.  If you sort messages by subject, this keeps the original and
its replies together.  The In-Reply-To field is enough to indicate that a
message is a reply; why do you feel "Re:" is also necessary?

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: gnu.emacs.bug
From: Frank_Ritter@shamo.soar.cs.cmu.edu
Subject: Reserving a keybinding for menus
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 14 Aug 1992 19:30:26 GMT

Here is a modest proposal to reserve a keybinding.
If this doesn't come under a bug, please forward onto the right place.

Emacs is mostly keystroke-based, but menus would be a useful adjunct
for novices, even keystroke ones.

We can't just use pop-up windows in X, for sometimes people dial up,
although this should be standard too.

   This keybinding should hold across across modes -- it must be a
   convention.  This makes GNU-Central the place to propagate it.

I suggest that C-h C-m be reserved for this use. C-h is help, and a
menu is actually a type of help, letting command names be saved in
recognition memory instead of recall memory.

Right now I also use C-c C-m in many small modes (soar-mode,
taql-mode, dismal-mode, soon s-mode), and I can count on that for my
users, but I know that outside of those modes, it would also be handy
to a menu.

I can provide a sample menu package, simple-menu.el.  It is not
necessarily the best, and there are places where I know it could use
improvement, but it serves, and provides a lower bound on
functionality.  

   Type C-c C-m, get a list of items in the mini-buffer, type their first
   letter, get another menu, or execute that command.  Type ? or SPC, and
   get a help message generated from the menu and commands.

Frank Ritter@cs.cmu.edu       best mail drop
      ritter@psy.cmu.edu      my real affiliation
        fr07@andrew.cmu.edu   where the above two point to
(412) 268-2969
(412) 681-5739 (incoming fax)

Newsgroups: gnu.emacs.bug
From: maechler@stat.math.ethz.CH (Martin Maechler)
Subject: emacs-18.58/INSTALL file
Reply-To: Martin Maechler <maechler@stat.math.ethz.ch>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 18 Aug 1992 14:07:29 GMT

   From: danj1@ihspa.ATt.COM (Dan Jacobson)
   Date: Thu, 6 Aug 1992 21:21:00 GMT

   Here we have part of the emacs-18.58/INSTALL file

   |3) Declare the place in the file system where Emacs will
   | be once installed.  This is done in the file `src/paths.h'.
   ......

   How many of us have edited paths.h by hand after reading the first
   paragraph, only later seeing that we didn't have to do that, once we
   read down to the second paragraph.

   Please put a "---but see below" or a "... by build-install, see
   below." at the end of the first paragraph.

   This happens to me every time I install a new emacs.


YES, I absolutely agree !
Martin Maechler <maechler@stat.math.ethz.ch>			<><
Seminar fuer Statistik, SOL F5 \\ ETH (Federal Inst. Technology)
8092 Zurich	SWITZERLAND  	phone: x-41-1-256-3408

Newsgroups: gnu.emacs.bug