From xemacs-m  Tue Sep 16 21:06:31 1997
Received: from dolphin.automatrix.com (dolphin.automatrix.com [198.69.29.254])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id VAA21218
	for <xemacs-beta@xemacs.org>; Tue, 16 Sep 1997 21:06:17 -0500 (CDT)
Received: (from skip@localhost) by dolphin.automatrix.com (8.8.5/8.8.3) id WAA20608; Tue, 16 Sep 1997 22:05:44 -0400 (EDT)
Date: Tue, 16 Sep 1997 22:05:44 -0400 (EDT)
Message-Id: <199709170205.WAA20608@dolphin.automatrix.com>
From: Skip Montanaro <skip@calendar.com>
To: xemacs-beta@xemacs.org
Subject: long lines cause regex to crap out...
Reply-to: skip@calendar.com (Skip Montanaro)
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII

In XEmacs 20.3 "Kiev" [Lucid] (i386-pc-bsdi2.1) of Tue Sep  9 1997 on dolphin.automatrix.com

Really long lines in compilation buffers (thousands of characters) cause
XEmacs to bomb frequently.  I reported this problem a couple weeks ago.  At
that time Colin Rafferty replied:

    By the way, this fails on the first line (the 4855 character `pydepend'), 
    so the rest of the *compilation* buffer is redundant.  I think that it
    is just choking on the size of the line.

    The way that compile.el builds up its regular expressions is naive.  You 
    might want to play with `compilation-error-regexp-systems-list' to
    reduce the matches to only what your system generates.

I set compilation-error-regexp-systems-list to '(gnu 4bsd comma of), with no
discernable positive effect.

I took a quick look at regexp.c and turned on DEBUG (oh, what a mistake that
turned out to be!).  If, as I suspect, Emacs' regex code is as intractable
as most others I've looked at in the past, I doubt I'll be able to make
heads or tails of anything, so I'm going to pass this along to the
wunderkinds to fix.

I will leave you all with my precise technical assessment of the situation
as I see it: It is really sucky (no, make that **really sucky** - asterisks
are exponential, so each asterisk increases the suckiness by a power of two)
that a text editor that can successfully perform complex edits of
multi-megabyte files (my main VM mbox file is about 5.5MB - I never have any
trouble with it) and which so frequently consumes more than 20 MB of virtual
memory should be so restrictive about the size of strings that can be fed to
its regular expression engine.

Can't something be done about this problem?

Thanks,

Skip Montanaro     | Musi-Cal Express - get your own private Musi-Cal
skip@calendar.com  | domain name! http://concerts.calendar.com/express.shtml
(518)372-5583      | WebFast - http://www.webfast.com/

