HDTenEightyP/NetNews huggingface dataset:
From: bahder@adelphi-tbb.army.mil (Thomas B. Bahder)
Subject: libg++ on NeXT
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 17:59:46 GMT

I would like to use C++ on the NeXT machine.  Is there anyone out  
there that uses it on NeXT ?

I am trying to put the gnu C++ library, libg++, on a couple of NeXT  
machines.  The NeXT (mach 2.1 release) comes with a version of the  
C++ compiler, called cc++, which is based on the gnu compiler g++  
version 1.36.4. However, no libraries are supplied.

I obtained libg++ by ftp from prep.ai.mit.edu.  In the documentation  
for installing libg++, it says that one must have a version of the  
g++ compiler which is more recent than the version of libg++.   
Therefore, it seems that I need to first install a more current  
version of g++ than what is supplied with the NeXT's mach 2.1  
release.  Is this true ?   


I would like to do it the easiest way, i.e., to install only libg++  
if possible.  Any help on this would be greatly appreciated.

Tom Bahder

Applied Physics Branch
U.S.Army Laboratory Command
Harry Diamond Laboratories
(soon to be: Army Research Laboratory) 

Adelphi, Maryland 20783

email: bahder@adelphi-tbb.army.mil 


tel. 301-394-2042
fax: 301-394-2103
Newsgroups: gnu.gcc.help
From: zack@bosslogic.COM (Zacharias Beckman)
Subject: Help with exception handling?  GCC 2.1.
Reply-To: zack@bosslogic.com
Organization: Boss Logic Inc.
Distribution: gnu
Date: Wed, 15 Apr 1992 18:34:57 GMT

Can anyone tell me why this program:

#include <iostream.h>
class gorp {
    public:
        gorp() { cout << "gorp created.\n"; }
};
main()
{
    try {
        f();
    }

    catch (gorp) {
        cout << "caught gorp.\n";
    }
}
void f()
{
    throw gorp;
}

Fails to compile when using -fansi-exceptions in GCC 2.1, as in:

dolphin% gcc -fansi-exceptions test.cc -o test -Wall -g -O  
-I/usr/local/include/libg++ -L/usr/local/lib -lg++
test.cc: In function `int  main ()':
test.cc:11: warning: implicit declaration of function `f'
test.cc:17: warning: control reaches end of non-void function
test.cc: In function `void  f ()':
test.cc:21: parse error before `;'

As though the "throw" keyword is not recognized?  Thanks in advance!
-- 
 Zacharias J Beckman - Lower Code Dweller - Boss Logic Inc - zack@bosslogic.com
 To be "matter of fact" about the world is to blunder into fantasy --- and dull
 fantasy at that, as the real world is strange and wonderful.  -- R. A. Heinlen
 Those opinions I express herein are my own, I'm fairly sure.  -- Z. J. Beckman
From: calyx.corp@mixcom.mixcom.com (calyx.corp)
Newsgroups: gnu.gcc.help
Subject: trying to get gcc 2.1 from prep.ai.mit.edu
Keywords: GNU gcc
Date: 17 Apr 92 16:37:16 GMT
Article-I.D.: mixcom.1992Apr17.163716.20160
Distribution: usa
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.

I am trying to download gcc 2.1 from prep.ai.mit.edu.
My access is through ftpmail.

According to the "How to get GNU software by Internet FTP or by UUCP"
document (/pub/gnu/FTP, last updated 20 Jan 92), it says that gcc is avaiable
in /pub/gnu under the filename gcc.tar-M.N.Z where M.N is the release, in
this case 2.1.  I get an email message back saying that that filename doesn't
exist.  I get the same problems trying to request these files:

Template         version wanted   filename used
------------------------------------------------------
gas-M.N.tar.Z    1.38.1           gas-1.38.1.tar.Z
gdbm-M.N.tar.Z   1.5              gdbm-1.5.tar.Z
dld-M.N.tar.Z    3.2.3            dld-3.2.3.tar.Z

The guide doesn't explain how to build the filename if there are more than
two components to the release ID.

Since I don't have access to a real internet node, I can't use true
anonymous ftp to connect to the system with the files I want to get the
filenames correct.  I'm getting more info on using "archie", but is this
going to provide me with archive listings of incorrect filenames, just like
in the /pub/gnu/FTP document?

- Nels Olsen
-- 
calyx.corp@mixcom.com
Newsgroups: gnu.gcc.help
From: doug@foxtrot.ccmrc.ucsb.edu (Douglas Scott)
Subject: turning off "#pragma once" warnings
Organization: Gnus Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 22:34:33 GMT

In gcc/g++ 2.1:

Is there a way to turn off the warnings about #pragma once being obsolete, or
will I have to hack cccp.c to shut it up?  :-)

Thank you

---
Douglas Scott                              (805)893-8352
Center for Computer Music Research and Composition
University of California, Santa Barbara
Internet: (NeXTMail ok)   <doug@foxtrot.ccmrc.ucsb.edu>
From: jwz@lucid.com (Jamie Zawinski)
Subject: gnu.emacs.bug "Path: " headers are bogus
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 17:41:40 GMT

Hi folks,

When I make a post to gnu.emacs.bug, or send mail to bug-gnu-emacs, the
message is never shipped back to this site via NNTP.  Our news guru tells
me that this is because the Path header that gets generated contains the
name of our site, which causes C-news to assume that we already have the
article.  The path header on one of my recent postings looked like this 
by the time it made it to CMU:
Apparently that "!lucid.com!jwz" at the end is what's breaking things.
That should probably be "!prep.ai.mit.edu!bug-gnu-emacs" instead, since
that's the moderation address, which is where this message was inserted
into the news stream.  This is what other moderated groups do
(rec.humor.funny, for example.)

	-- Jamie

Newsgroups: gnu.emacs.bug
From: wolfgang@wsrcc.COM (Wolfgang S. Rupprecht)
Subject: Re: tagging schemes (was Re: Help: Decstation malloc returns too big value.)
Organization: W S Rupprecht Computer Consulting, Fremont CA
Distribution: gnu
Date: Sat, 11 Apr 1992 21:48:10 GMT

kyle@uunet.uu.net (Kyle Jones) writes:
>What I wonder is whether the memory saved is worth the complexity
>in determining types and all the bit masking that's needed to get
>usable pointers.

I once instrumented up garbage-collect to count the number of integers
in use in a typical emacs run.  It was on the order of 1k integers.

If anyone thinks a few k of extra storage is going to be noticable in
emacs they clearly are talking about MicroGnu or something like that. ;-)

-wolfgang
-- 
Wolfgang Rupprecht    wolfgang@wsrcc.com (or) wsrcc!wolfgang
Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511

Newsgroups: gnu.emacs.bug
From: jkp@cs.hut.fi (Jyrki Kuoppala)
Subject: Bug report for emacs 18.58
Organization: Helsinki University of Technology, Finland.
Distribution: gnu
Date: Mon, 6 Apr 1992 23:16:51 GMT

A bug in emacs 18.58, all machines which don't define CANNOT_DUMP
and have newer non-standards parts to be dumped in the build process.

Symptoms:

My paths.h sets the load path to "/p/emacs/lisp/hut:/p/emacs/lisp";
the code in lread.c adds "../lisp" in front of load path when loading
and dumping emacs.  This causes trouble if there a preferred elisp
file which is to be dumped in the local elisp dir 'lisp/hut' (in this
case a newer dired which is loaded in site-init.el); temacs dumps the
file that is later in the load path variable (the old dired from
../lisp).

I think it would be better if the ../lisp dir would be appended to the
end of the path specified in paths.h rather than the beginning.

Place of the bug:

in lread.c, in function init_read() there's the code:

#ifndef CANNOT_DUMP
  if (!NULL (Vpurify_flag))
    Vload_path = Fcons (build_string ("../lisp"), Vload_path);
#endif /* not CANNOT_DUMP */

Suggested fix:

Change the code to:

#ifndef CANNOT_DUMP
  if (!NULL (Vpurify_flag))
    {
      Lisp_Object len;
      Lisp_Object args[2];

      XFASTINT (len) = 1;
      args[0] = Vload_path;
      args[1] = Fmake_list(len, build_string ("../lisp"));
      Vload_path = Fappend (2, args);
    }
#endif /* not CANNOT_DUMP */

to append "../lisp" to the end of load-path instead of the beginning.
(There probably is a better/easier way to do this, but you get the idea.)

//Jyrki

Newsgroups: gnu.emacs.bug
From: carson@cs.columbia.edu (Carson A. Gaspar)
Subject: Emacs 18.58 config file for SCO UNIX 3.2.2
Organization: Columbia University Department of Computer Science
Distribution: gnu
Date: Tue, 7 Apr 1992 19:37:37 GMT

This is a replacement for s-sco.h in 18.58 that enables the X code and fixes
some #define problems that crop up when X is enabled.  Note that
CLASH_DETECTION apparently depends on fchmod, which is not present in
SCO UNIX 3.2.2.  It _may_ be possible to use "#define fchmod(f, m)
while(0)" as a work-around (see m-dpx2.h).

---8<---clip 'n save--->8---

#include "s-usg5-3.h"

/* Use termios instead of termio, to turn off C-z.  */

#define HAVE_TCATTR

/* It's possible for Emcs to suspend itself.  */

#undef NOMULTIPLEJOBS

/* The setsid system call exists.  */

#define HAVE_SETSID

/* The rename system call exists.  */

#define HAVE_RENAME

/* Include ptem.h, not sioctl.h.  */

#define NO_SIOCTL_H
#define NEED_PTEM_H

/* Inhibit macro definition of `signal' in m-intel386.h.  */

#define DONT_DEFINE_SIGNAL

/* We cannot get alloca from -lPW because various other symbols
   in that library conflict with symbols in GCC.  */

#ifdef	__GNUC__
#define alloca(x) __builtin_alloca (x)
#else
#define C_ALLOCA
#undef HAVE_ALLOCA
#define STACK_DIRECTION	-1
#define SHORTNAMES
#endif /* __GNUC__ */

/* TIOCWINSZ doesn't work on ptys.  */
#define BROKEN_TIOCGWINSZ

#define HAVE_TIMEVAL

#define HAVE_SELECT

#define HAVE_PTYS

#define HAVE_SOCKETS

#define USG_SYS_TIME

#define HAVE_RANDOM

#define BSTRING

#define HAVE_GETTIMEOFDAY

#define LIBS_MACHINE -lsocket

#define USE_UTIME

/* SCO does not have fchmod, so
#define CLASH_DETECTION
cannot be used */
-- 
			    Carson Gaspar
	       carson@cs.columbia.edu  |  BIX: cgaspar

Newsgroups: gnu.emacs.bug
From: ishikawa@ds5200. (Chiaki Ishikawa)
Subject: Re: Help: Decstation malloc returns too big value.
Reply-To: ishikawa@personal-media.co.jp
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 01:11:52 GMT

In GNU Emacs 18.55.49 of Wed Apr  8 1992 on ds5200 (berkeley-unix)

Hello.

Thanks to the posting of Mr. John M. Farrell,
the problem seems to be solved now.

I have recompiled the emacs on Decstation 5200, ULTRIX ds5200 4.1 0
RISC and am running it right now.

It looks that the m-pmax.h header file I had was outdated, and after
checking the ld manual page, I am convinced that the incorrect setting
of DATA_START and missing DATA_SEG_BITS were the culprit of the
malloc() problem.

Sorry to have wasted the bandwidth with my incorrect setup.

The good news is I have heard from some Japanese netters that
multi-language Emacs (not only for Japanese, but can support other
language character sets) based on 18.57(8? I am not sure) is being
beta-tested among Japanese users, and when it is released, I can switch
to much newer version of Emacs. Being able to use Japanese
input/output is essential for my work.

Happy hacking.

------------------------------------------------------------------
    Chiaki Ishikawa                       Phone:+81-3-5702-0351
  Personal Media Corp.                      FAX:+81-3-5702-0359
 MY Bldg, 1-7-7 Hiratsuka,   UUNET: ... uunet!pmcgw!ishikawa, or
 Shinagawa-ku, Tokyo 142                ishikawa%pmcgw@uunet.uu.net
        JAPAN                JUNET:     ishikawa@personal-media.co.jp
------------------------------------------------------------------




Newsgroups: gnu.emacs.bug
From: pln@egret1.stanford.edu (Patrick L. Nolan)
Subject: Fortran tags with underscore are truncated
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 00:42:44 GMT

I've just started using emacs (18.58) with etags and fortran mode. 
It looks as if there's a bug in the TAGS file.  For instance I have 
a subroutine check_params which lives in a file called 'check_params.f'. 
The appropriate entry in the TAGS file is 
 
check_params.f,31 
      subroutine check_14,383 
         
Note that 'params' and the usual parenthesis are  missing from the 
second line.  It does the same thing for all the names that contain 
underscores.  If I search using the tag 'check_' it will be found.
 
Is this a bug?  Is there a fix or workaround? 
 
(Sun 4, SunOS 4.1.1) 
~

Newsgroups: gnu.emacs.bug
From: kjartan@daimi.aau.dk (Kjartan Stefansson)
Subject: Scroll-backward bug in view mode
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 16:36:47 GMT

When the end of buffer is visible in view-mode, M-v (bound to
View-scroll-lines-backward) works incorrectly.  Instead of
scrolling backwards, the view-mode is exited, as if the user had
tried to scroll *forward*.

This is due to the trick in View-scroll-lines-backward (defined in
view.el), calling View-scroll-lines-forward with a negative
argument.  The first thing View-scroll-lines-forward does is to
check if end of buffer is visible, and if so, it exits!

This bug is in version 18.58 (as well as in 18.55).

Kjartan Stefansson
(kjartan@daimi.aau.dk)

Newsgroups: gnu.emacs.bug
From: jkp@cs.hut.fi (Jyrki Kuoppala)
Subject: Bug report for emacs 18.58
Organization: Helsinki University of Technology, Finland.
Distribution: gnu
Date: Wed, 8 Apr 1992 03:36:40 GMT

> I'm not sure that moving ../lisp to the end is a good solution.  It
> should be in front of the directories that the installed Emacs will
> use.  That is, in your example, ../lisp should really go *between* the
> other two path elements, resulting in
> 
> 	"/p/emacs/lisp/hut:../lisp:/p/emacs/lisp"
> 
> That way, your customizations will be consulted, then the lisp library
> in the build tree, and finally the path of the soon-to-be-installed
> lisp library.

I agree.

> The Emacs 19 Makefile offers a variable called `lisppath', which is a
> colon-separated list of directories for Emacs to search for lisp.
> Suppose we added another (yet another!) variable to set, perhaps
> called `buildlisppath', which is prepended to `lisppath' when Emacs is
> dumping; it would default to "../lisp", and you could change it to
> "/p/emacs/lisp/hut:../lisp".
> 
> How does that sound?

Hmm, looks a bit too complicated to me - I'd have to change two
variables.

How about this: have just one variable, extralisppath or something
like that which is added before the /p/emacs/lisp directory.  For
example, assuming emacs 19 uses the same configure procedure as other
GNU programs, I would edit a file (Makefile.in) to have extralisppath
as /p/gnu/lib/emacs/lisp/hut or rather ${emacslibdir}/lisp/hut,
configure emacs with ./configure --prefix=/p/gnu proc-machine-os.  The
build process would then set lisppath to
/p/gnu/lib/emacs/lisp/hut:/p/emacs/lisp and buildlisppath to
/p/gnu/lib/emacs/lisp/hut:../lisp:/p/emacs/lisp.  This way I would
need to change only one variable to add a local lisp dir - perhaps
there could even be a default value for extralisppath, for example
${emacslispdir}/lisp/local to recommend people not to clutter up the
lisp dir with local additions.  This would make upgrading emacs a lot
easier.

//Jyrki

Newsgroups: gnu.emacs.bug
From: montra@ghost.dsi.unimi.it (Paolo Montrasio)
Subject: can't compile epoch 4.? on my hpux 8.0 machine
Organization: Computer Science Dep. - Milan University
Distribution: gnu
Date: Fri, 10 Apr 1992 11:29:17 GMT

I got the source for epoch4.0p0 and tried to compile it on an
hp9000/855 machine running under hpux 8.0. All worked well until the
makefile in the src directory run temacs to load the lisp code and
dump it. I got this error message:

[regular output of temacs...]
Loading local/netunam...
Loading local/gnuserv...
Pure Lisp storage exhausted
^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don't know what this does mean. I looked for hints into
README/INSTALL files but I didn't find any reference to this error. I
successfully compiled other versions of emacs (not Epoch) without
running into this kind of problem.

I'm not a regular reader of this group so I don't know if other
people has incourred into this problem too, neither if someone already
solved it.

I'll greatly appreciate any help, by E-mail or follow-up in this group.

Thank you.

                             _____
                            /     \ 
.--------------------------|\ P M /|---------------------------------------.
|                          |_\   /.|   |        Paolo Montrasio            |
| Don't study, don't work, |--\_/--|   |        montra@ghost.dsi.unimi.it  |
|      play the Core War!   \ \_/ /    |        montra@[149.132.2.1]       |
|                          __|---|__   |        MILANO - ITALY             |
`------------------------/           \-------------------------------------'


Newsgroups: gnu.emacs.bug
From: tower@prep.ai.mit.edu
Subject: tags-search pulls all files into memory
Organization: Project GNU, Free Software Foundation,
           675 Mass. Ave., Cambridge, MA  02139, USA   +1 (617) 876-3296
Distribution: gnu
Date: Sat, 11 Apr 1992 06:01:16 GMT

   From: jbw@cs.bu.edu (Joe Wells)
   Date: Fri, 10 Apr 92 16:51:48 -0400
   
   You will notice that tags-search has left all the files mentioned in the
   TAGS table lying around in memory, even though the searched-for string
   does not occur in any of them.
   
   This is fixed in my rewrite of tags.el.
   
This can be a lose.  What if one does a lot of tags searches off the
same TAGS file?  One would be re-reading a lot of files into memory
over and over again.  You might luck out and have some of the blocks
leff in the buffer cache, but not often on most machines.

At the minumin, you should make the behaviour a user option.

A better solution is to keep a list of files the current search isn't
in, and delete those files from memory, if memory becomes precious.

-len

PS: Does your package has a delete all files mentioned in the TAGS
file command?  If not, add it.

   
   
Newsgroups: gnu.emacs.bug
From: tmckearn@cs.loyola.edu (Thomas McKearney)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 11 Apr 1992 14:25:47 GMT

found 1 bug in emacs:

	When doing a ^T to transpose characters in an empty buffer, the 
buffer-modify flag is set. 

the version of emacs we run is:
GNU Emacs 18.55.53 of Tue Sep 11 1990 

thanks

Newsgroups: gnu.emacs.bug
From: pot@fly.cnuce.cnr.it (Francesco Potorti`)
Subject: autosave protection
Reply-To: pot@cnuce.cnr.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 09:06:00 GMT

   I have just realised that autosave files are autosave, independent
   of the permission bits for their corresponding original files. It
   seems to me this is a problem. This is also a problem with respect
   to non-file buffers. For example, if I am sending sensitive mail,
   my *mail* buffer gets written out into my top-level directory for
   the world to consider and peruse while I am writing the msg. Not
   good.

I agree this is a SERIOUS problem.  Probably it would be enough to set
mode 600 for all autosave files

				Francesco Potorti`
				-- pot@cnuce.cnr.IT

Newsgroups: gnu.emacs.bug
From: carlg@ed.wv.tek.COM (Carl Goodwin)
Subject: a bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 14:39:59 GMT

For several years, I've been using Gnu Emacs on various platforms.  Most
of my experience is with a very old version (if it ain't broke...), namely:
GNU Emacs 18.44.17 of Wed Jun 22 1988

More recently, I've moved up to:
GNU Emacs 18.52.1 of Tue Jan 15 1991

And just last week:
GNU Emacs 18.57.2 of Mon Jun 10 1991

Last week I ran into my first serious problem on the latter version.
The problem was not present in earlier versions.  The key I use for
"Meta" (and have used on the same workstation for years) has a keysym of
0xff20.  Whenever I used the key as a Meta modifier, I got an additional
"space" character in my file buffer.  The surprising thing is that the
key ALSO worked as Meta!  By issuing the following xmodmap commands, I
was able to swap keysyms with an unused key (keysym 0xffe7) on my
keyboard, thusly:

xmodmap -e "clear mod1"
xmodmap -e "keycode 93 = Multi_key"
xmodmap -e "keycode 100 = Meta_L"
xmodmap -e "add mod1 = Meta_L"

and voila; the problem disappeared.

It's interesting to note that a M-x describe-key <CR><Meta><CR> prior to
this fix revealed that the key was:

self-insert-command:
Insert this character.  Prefix arg is repeat-count.

Apparently, part of emacs thought that the key was a SPC character,
another that is was the Meta modifier.


Any insight on how to fix this in the source would be appreciated.




Newsgroups: gnu.emacs.bug
From: ishikawa@ds5200. (Chiaki Ishikawa)
Subject: Help: Decstation malloc returns too big value.
Reply-To: ishikawa@personal-media.co.jp (or ishikawa%pmcgw@uunet.uu.net)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 05:42:51 GMT

In GNU Emacs 18.55.46 of Mon Apr  6 1992 on ds5200 (berkeley-unix)

Dear Netter,

This is not a bug of Emacs itself, I suppose. Rather it seems to me a 
peculiarity of DEC Ultrix ds5200 version.

SYSTEM: 
	DEC ULTRIX ds5200 4.1 0 RISC
	Decstation 5200.

SYMPTOM:
	Emacs crashes in routines alloc.c since sometimes malloc()
returns a very large address, that is a value that has non-zero value
in the upper 8 bits.
As is known, Emacs Lisp cell stores the lower 24 bits (depedning on
the setup) of an address into a lisp cell. The upper 8 bits
is used for data tag (and marker for garbage collection).

Lisp Cell.
	<- tag -> <----- address          ->
	xxxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

Hence, if an address returns by malloc() exceeds the value expressible
in 24 bits, fatal problem can arise.
(Of course, this ignores certain segmented architecture such as IBM,
HP, or DG. But MIPS is supposed to be a linear addressble machine with
no segmentation.)

It seems that occasionally, malloc does return a value larger than
0xFFFFFF. (I checked the return value in malloc.c by masking it with
0xFF000000.)
When this happens, after being stored into a lisp cell, and then
retrieved to generate an address, the address ends up with an invalid
(meaningless) value.

Example:	malloc returns 0x01000120
		stored as      0xdd000120	(dd is the data tag).
	reverted to addresss   0x00000120	(invalid address!)

Does anyone have any idea how I can overcome this problem on Ultrix
4.1? 
I have never seen this bug on other machine (such as Sun3,
HP9000/3xx).
It looks that sbrk() sometimes returns a big value?

Also, I wonder if I can tell the system to load the whole data and
code into a lower address space. I noticed that 0x800000 is used to
load the data for ld command line. undump code also seems to use this
constant defined in header file. I wonder if this can be lowered to
something else.

Regards,

------------------------------------------------------------------
    Chiaki Ishikawa                       Phone:+81-3-5702-0351
  Personal Media Corp.                      FAX:+81-3-5702-0359
 MY Bldg, 1-7-7 Hiratsuka,   UUNET: ... uunet!pmcgw!ishikawa, or
 Shinagawa-ku, Tokyo 142                ishikawa%pmcgw@uunet.uu.net
        JAPAN              (Inside Japan only, ishikawa@personal-media.co.jp)
------------------------------------------------------------------




Newsgroups: gnu.emacs.bug
From: gwk@crmunich0.cray.com (Georg-Wilhelm Koltermann)
Subject: justify-line bug in EMACS 18.57
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 23:12:13 GMT

There is a bug in fill.el in GNU Emacs version 18.57 that bites when
you try to fill and justify (i. e. M-number M-q) a paragraph which
has a fill-prefix. The column calculation for justify-line is off
by the length of the fill prefix, causing the filled lines to become
that much too long (exceeding the set fill-column).

The following patch fixes this bug:

*** fill.el.old	Tue Apr 14 19:41:20 1992
--- fill.el	Tue Apr 14 19:40:32 1992
***************
*** 159,165 ****
  	(forward-char -1)
  	(insert ? ))
        (goto-char (point-max))
!       (setq ncols (- fill-column (current-column)))
        (if (search-backward " " nil t)
  	  (while (> ncols 0)
  	    (let ((nmove (+ 3 (% (random) 3))))
--- 159,165 ----
  	(forward-char -1)
  	(insert ? ))
        (goto-char (point-max))
!       (setq ncols (- fill-column (current-column) (length fill-prefix)))
        (if (search-backward " " nil t)
  	  (while (> ncols 0)
  	    (let ((nmove (+ 3 (% (random) 3))))


Georg

Newsgroups: gnu.emacs.bug