🚀 go-pugleaf

jwz@lucid.com (Jamie Zawinski) writes:
> I'll bet the reason for this is the new regex.c that FSF19 is using; VM uses
> some regexps that will perform pessimally in FSF19.  Lucid Emacs still uses
> the same regex.c that was in v18 because the new one's time requirements have
> gone ballistic.  We're talking going from 0 seconds to 27 seconds when
> matching a pattern against a buffer that only contains 70 characters!
>
> The reason for this is that Posix compliance has forced a change in the
> semantics of regexp matching: a regexp is supposed to match the largest
> possible substring, whereas in v18, it matched the longest possible substring
> of the *first* match it found.

Um. Er. How on earth will this work?

What happens when my buffer looks like this:

    "111111 a 222222222 ac 333333333333333333333333333 c 444"

and I replace regular expression "a.[^c]*c" with "x".  Under the new
scheme, will replace-regexp search for the longest match to replace first,
resulting in

    "111111 a 222222222 x 444"

or will replace-regexp just replace the first one as it does now to give

    "111111 x 333333333333333333333333333 c 444".

This raises an interesting question of what emacs does to replace all
occurances in a buffer...

Interested,
Michael.


--
----------------------------/|-|--|-|--|------Michael-Smith-------------------
smith@pell.anu.edu.au      /_| |\ | |  |      Mathematics Research Section
--------------------------/--|-|-\|-|_/|------Australian-National-University--