Helix panics if we try to jump to a non existent line

[IgnisDa]

Summary

As the title says.

Reproduction Steps

I tried this:

1. hx . and then select a random file.
2. In a different terminal, I ran yarn add zod.
3. Back in helix I did a global search on zod (using <space> + /). Then I highlighted the entry in the yarn.lock. But I did not open the file.
4. I went to the terminal, and did yarn remove zod
5. Went back to helix and selected the entry highlighted in step 3.

I expected this to happen:

Helix to not panic and show an error saying the line you jumped to does not exist

Instead, this happened:

Helix panicked with this error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Line index out of bounds: line index 4998, Rope/RopeSlice line count 4993', /build/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/ropey-1.5.1-alpha/src/rope.rs:764:41
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Helix log

No response

Platform

Linux

Terminal Emulator

alacritty 0.12.0-dev (ed67aa3c)

Helix Version

helix 22.12

[pascalkuthe]

You can produce the same bug with the following steps (note that all kinds of autsafe must be disabled):

• hx bar
• insert a bunch of lines like foo1\nfoo2\nfoo3\n...
• save with :w
• clear the buffer with %d
• open the picker with the search for the last line you typed (like foo20)
• select the bar (the preview will be empty/look weird but no crash yet)
• hit ener => observe crash

The issue is fundamentally that we assume that the FS at the time of the grep corresponds to the state of the buffer (either loaded from the FS on enter or already in memory). This can also just manifest as weirdly offset lines (an issue I have run into before) I added a bounds-check in #5639 which fixes the panic but it might be nice to use the buffer instead of the on-disk file during global search if it exists. I think the case of the on-disk file changing is rare enough to ignore.