Edit x/^/ i:// : Unexpectedly exuberant

[rjkroege]

Middling Edit x/^/ i:// : inserts // before every rune. Conceivably this is the right behaviour (is it?) but it deviates significantly from Acme.

[paul-lalonde]

It also comes with a nifty selection rendering artifact:

[paul-lalonde]

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

[rjkroege]

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

[paul-lalonde]

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.

[paul-lalonde]

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.

[rjkroege]

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

[paul-lalonde]

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.

[paul-lalonde]

Fixed in 03f4790

Backwards searches remain broken.