🚀 go-pugleaf

Concerning: GNU Emacs 18.55.13 of Tue Nov 21 1989 on vega (berkeley-unix),
	    Run on a SparcStation 1 under SunOS 4.0.3.  Vega is a Sun-4/260.

The following bug concerns a REGEXP that uses the *magic* number of 9
sub-REGEXPressions!   The resulting match (using looking-at) is
successful, but the TWO initial sub-REGEXPressions are totally wrong,
and in addition they overlap with the following sub-REGEXPressions.
So, here is the data:

The REGEXP:

\(\(\<.+\>\)[ 
] *\)?vol\.\([^ ,]+\),[ 
] *no\.\([^ ,]+\),[ 
] *\(\(.*\)[ 
] *\)?\([0-9][0-9][0-9][0-9]\),[ 
] *p\.\([---0-9+]+\),[ 
] *\([0-9]+[ 
] *Refs\)

The lines visually terminating with "[" are really the pattern "[ \n]". 

The narrow-to-ed buffer that we are looking-at:

"vol.20,  no.1,  March 1988, p.36-43, 63 Refs, Coden: IIETDM, ISSN:
0740-817X, CCCC: 0740-817X/88/$2.00, Country of Publ.: USA"

\0 = "vol.20,  no.1,  March 1988, p.36-43, 63 Refs"

\1 = "vol.20,  no.1,  March "	-- completely erroneous!  Should be NIL!

\2 = "vol"			--      "         "          "   "   " !

\3 = "20"

\4 = "1"

\5 = "March "

\6 = "March"

\7 = "1988"

\8 = "36-43"

\9 = "63 Refs"

If anyone has a work-around, I would *love* to hear about it.  This is
the *THIRD* GNU Emacs REGEXP bug that I've found -- working on *ONE*
small piece of lisp code!!

Thanks in advance to all!  Bug-gnu-emacs@prep.ai.mit.edu. are you
listening? 

--
Ralph P. Sobek			  Disclaimer: The above ruminations are my own.
ralph@laas.fr				   Addresses are ordered by importance.
ralph@laas.uucp, or ...!uunet!laas!ralph		
If all else fails, try:				      sobek@eclair.Berkeley.EDU
===============================================================================
Reliable software should kill people reliably! -Andy Mickel, Pascal News #13,78