BUG: micro crashes if search query is \Q

[nikitax44]

steps to reproduce:

1. open any file
2. go to the end of any non-empty line
3. open find panel in regex mode
4. try to search for \Q
5. the micro will crash

Micro encountered an error: *errors.errorString regexp: Compile(`.(?:\Q)`): error parsing regexp: missing closing ): `.(?:\Q)`
regexp/regexp.go:313 (0x593cf4)
github.com/zyedidia/micro/v2/internal/buffer/search.go:45 (0x8bb84a)
github.com/zyedidia/micro/v2/internal/buffer/search.go:71 (0x8bbab0)
github.com/zyedidia/micro/v2/internal/buffer/search.go:170 (0x8bc506)
github.com/zyedidia/micro/v2/internal/action/actions.go:1122 (0x8f39f6)
github.com/zyedidia/micro/v2/internal/action/infopane.go:117 (0x90d0fb)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:516 (0x947757)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:455 (0x947130)
internal/runtime/atomic/types.go:194 (0x43bc2b)
runtime/asm_amd64.s:1700 (0x478d41)

If you can reproduce this error, please report it at https://github.com/zyedidia/micro/issues

[JoeKar]

While \Q compiles fine here...

micro/internal/buffer/search.go

Lines 157 to 161 in 219fb12

	if b.Settings["ignorecase"].(bool) {
	r, err = regexp.Compile("(?i)" + s)
	} else {
	r, err = regexp.Compile(s)
	}

...it will cause trouble in the moment it is compiled a second time within these patterns here...

micro/internal/buffer/search.go

Lines 44 to 50 in 219fb12

	if padMode == padStart {
	r = regexp.MustCompile(".(?:" + r.String() + ")")
	} else if padMode == padEnd {
	r = regexp.MustCompile("(?:" + r.String() + ").")
	} else if padMode == padStart|padEnd {
	r = regexp.MustCompile(".(?:" + r.String() + ").")
	}

...since every preceding character (after \Q) is considered literally instead as regex, till a \E would stop this sequence.

This is a regression of #3575, which we didn't realize before.

@matthias314:
Unfortunately I realized it here and not in the review again, that we still compile the regexp more than just once and furthermore run into trouble with the above pattern due to the usage of regexp.MustCompile() instead of regexp.Compile().

Possible patch:

diff --git a/internal/buffer/search.go b/internal/buffer/search.go
index a48e1f87..f0854272 100644
--- a/internal/buffer/search.go
+++ b/internal/buffer/search.go
@@ -17,7 +17,7 @@ const (
        padEnd
 )
 
-func findLineParams(b *Buffer, start, end Loc, i int, r *regexp.Regexp) ([]byte, int, int, *regexp.Regexp) {
+func findLineParams(b *Buffer, start, end Loc, i int, r *regexp.Regexp) ([]byte, int, int, *regexp.Regexp, error) {
        l := b.LineBytes(i)
        charpos := 0
        padMode := 0
@@ -41,15 +41,16 @@ func findLineParams(b *Buffer, start, end Loc, i int, r *regexp.Regexp) ([]byte,
                }
        }
 
+       var err error
        if padMode == padStart {
-               r = regexp.MustCompile(".(?:" + r.String() + ")")
+               r, err = regexp.Compile(".(?:" + r.String() + ")")
        } else if padMode == padEnd {
-               r = regexp.MustCompile("(?:" + r.String() + ").")
+               r, err = regexp.Compile("(?:" + r.String() + ").")
        } else if padMode == padStart|padEnd {
-               r = regexp.MustCompile(".(?:" + r.String() + ").")
+               r, err = regexp.Compile(".(?:" + r.String() + ").")
        }
 
-       return l, charpos, padMode, r
+       return l, charpos, padMode, r, err
 }
 
 func (b *Buffer) findDown(r *regexp.Regexp, start, end Loc) ([2]Loc, bool) {
@@ -68,7 +69,10 @@ func (b *Buffer) findDown(r *regexp.Regexp, start, end Loc) ([2]Loc, bool) {
        }
 
        for i := start.Y; i <= end.Y; i++ {
-               l, charpos, padMode, rPadded := findLineParams(b, start, end, i, r)
+               l, charpos, padMode, rPadded, err := findLineParams(b, start, end, i, r)
+               if err != nil {
+                       return [2]Loc{}, false
+               }
 
                match := rPadded.FindIndex(l)
 

[matthias314]

Good catch! I think it would be easiest to fix this in #3658, in the function currently named NewRegexpGroup. I'm going to push a revised version of that PR soon.