Curious bug in ZMACS

[barmar@Think.COM (Barry Margolin)]

    Date: Tue, 8 Jan 91 12:01 PST
    From: bushnell@EOS.arc.nasa.gov

	    The bug is only sensitive to the number of lines between the first and second occurrences
	    of the search string, which must start with a #\Return.  It appears when the number of 
	    lines is (- (expt 2 n) 1), where n6.  The lines do not have to be blank.  It does not 
	    matter what is outside of the (+ (expt 2 n) 1) line block.  

Actually, I think it happens whenever the number of blank lines is
64n-1, for n>0.  Here's a relevant excerpt from INCREMENTAL-SEARCH:

		       ;; If the level we were working on is still not finished,
		       ;; search at most 100 more lines.  If we find it or the end of the buffer
		       ;; before then, this level is determined and we can work on the next.
		       ;; Otherwise, we remain in the :GO state and do 100 more lines next time.
		       (MULTIPLE-VALUE (NEW-BP TIME-OUT)
			 (SEARCH BP1 *IS-STRING*
				 (AREF *IS-REVERSE-P* P1) NIL 100
				 NIL *ALPHABETIC-CASE-AFFECTS-SEARCH*	;---
				 SKIP-TABLE REOCCURRENCE-TABLE))

This is in octal, so that "100 more lines" is actually 64 lines.  It
only searches 100 lines at a time so that it can check whether the user
has typed rubout or c-G in a timely fashion when it's in the midst of a
failing search.

The problem is that SEARCH-CR-FULL (the searching function that is used
when the search string contains a Return) checks for reaching the line
count before performing the comparison, and reports a "time out".  When
it times out, the NEW-BP that it returns is supposed to be the place to
resume searching; it simply returns a BP pointing to the beginning of
the line it timed out on.  However, when the search string begins with a
Return, it should actually return a pointer to the *previous* line,
because it's already past the newline that it needs to match the initial
Return against on the next search.

All the editors I've ever worked with that stored their buffer as a
sequence of lines (rather than as a big string) have had bugs regarding
searching for strings containing newline.

Here's a pretty simple fix (I don't think posting this should be a
problem -- it's only one line, and only sites with source can really
make use of it).  My changes are in lowercase (I usually use bold, but I
don't believe in sending fonted text to mailing lists unless I expect
most readers to be using Lispms).  This version has one smaller bug: if
it is called with a search string that begins with Return and
LINES-TO-SEARCH is 1, if it times out it will return a pointer to the
same line it started on, so the caller will likely loop forever; a fix
that moves the line count check to after the comparison shouldn't have
this bug, but I doubt anything calls it like that.  I'll send this
better fix to Symbolics.

Source compare made by Barmar on 1/08/91 19:58:55			-*-Fundamental-*-
of File EPOCH-1:/data2/lispm.sct/sys/rel-8-0/zwei/search.lisp.~146~
with Buffer search.lisp /data2/lispm.sct/sys/rel-8-0/zwei/ EPOCH-1:
**** File EPOCH-1:/data2/lispm.sct/sys/rel-8-0/zwei/search.lisp, Line #147, After "(DEFUN SEARCH-CR-FULL (BP STRING REVERSEP FIXUP
-P NLPOS LINES-TO-SEARCH LIMIT-BP)"
		    (RETURN-FROM SEARCH-CR-FULL (VALUES (BEG-OF-LINE LINE) T)))
**** Buffer search.lisp /data2/lispm.sct/sys/rel-8-0/zwei/ EPOCH-1:, Line #147, After "(DEFUN SEARCH-CR-FULL (BP STRING REVERSEP F
IXUP-P NLPOS LINES-TO-SEARCH LIMIT-BP)"
		    (RETURN-FROM SEARCH-CR-FULL (VALUES (BEG-OF-LINE (if crleads
									 (line-previous-in-buffer line)
									 LINE))
							T)))
***************