🚀 go-pugleaf

GNU Emacs 18.53.11 on NeXT 1.0.1

There is a serious bug and a bugoid in regexp searching in 18.53.

Put in a fresh buffer 40 copies of the line
  "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:"

(setq RE "^\\([^ \n]+:\n\\)+\\([^ \n]+:\\)" )

Now, 

   (goto-char 0)
   (looking-at RE)

fails, even though

   (goto-char 801)
   (looking-at RE)

succeeds; the only difference should be the number of times the first
parenthesized expression matches.  Experiment shows that this is
sensitive to the number of characters (1305) matched (and not the
number of iterations).

A similar (related?) problem is that the regular expression given as
an example in the Regexps section of the Info manual for Emacs, namely
\(.*\)\1 fails for lines longer than 1280 characters.  Emacs isn't
supposed to have arbitrary line-length limits....

The second problem is that even on a small match (e.g. the last two
lines) (match-end 1) is incorrect: it points to the CR after the final
line.  This is presumably because the first ()+ expression matched up
to there before having to backtrack.  You can also elicit this
behavior in a buffer containing just "aaa" with (looking-at
"\\(a\\)*a"), which gives match-beg/end 1,4.

The documentation is very vague on this point, but presumably they
should be 2,3 (the last match).  You can make a case for 1,3 (although
if you want that you should presumably use "\\(a*\\)a" which _does_
work).  1,4 just seems to be an accident of implementation (it forgot
to adjust match-beg/end when backtracking).

	-s