Edit x/^/ i:// : Unexpectedly exuberant about edwood HOT 8 CLOSED

It also comes with a nifty selection rendering artifact:

from edwood.

And it would be difficult for me to argue that this is the correct behavior for '^'

from edwood.

Hm. I didn't get the background colours. But indeed, that's unfortunate.

from edwood.

This is unexpectedly ugly. Instead of porting the acme regexp, I used Go's builtin, and it matches up reasonably well. Until you want multiple "start of line" chars from a Reader. When you re-start, you get the "start of selection" match for ^, instead of the start of line. One solution is to find all of them, but the go regexp library offers FindReaderSubmatchIndex but not the FindAll variant.

from edwood.

How bad would it be if ^ matched not only newlines, but also start-of-range? That's the behaviour of the golang regexp, and it's bloody painful to work around. Enough that the Reader can't be told to ignore start-of-block matches on ^, which means expanding a []byte for our buffers. Augh. I have a plan for that that matches well with defragmenting the eventual data structure at least.

from edwood.

I think that it could be lived with? I think that I usually use the ^ on whole lines only so would seem fine?

from edwood.

Even more fun: acme itself is broken on $ matches. Select the middle line of

this is a
short text
to try Edit

and execute Edit x/$/a/junk/
Receive

this is ajunk
short text
to try Edit

rather than the expected

this is a
short textjunk
to try Edit

Edwood will get this right, and not match ^ and $ to start and end of range. Both will match start and end of document.

from edwood.

Fixed in 03f4790

Backwards searches remain broken.

from edwood.