Panic in search_prev with an inefficient match pattern

[trink]

Steps to Reproduce

1. :o helix-term/src/commands.rs
2. 129G # goto_line
3. 196fh # find_next_char
4. * # search_selection
5. N # search_prev

Release and Debug

thread 'main' panicked at 'damm forward compatability', index.crates.io-6f17d22bba15001f/regex-cursor-0.1.3/src/engines/hybrid/search.rs:837:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:578:5
   1: core::panicking::panic_fmt
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:67:14
   2: regex_cursor::engines::hybrid::search::find_fwd
   3: regex_cursor::engines::hybrid::try_search
   4: regex_cursor::engines::meta::strategy::Strategy::search
   5: core::iter::traits::iterator::Iterator::fold
   6: helix_term::commands::search_impl
   7: helix_term::commands::search_next_or_prev_impl
   8: helix_term::ui::editor::EditorView::handle_keymap_event::{{closure}}
   9: helix_term::ui::editor::EditorView::handle_keymap_event
  10: <helix_term::ui::editor::EditorView as helix_term::compositor::Component>::handle_event
  11: helix_term::compositor::Compositor::handle_event
  12: helix_term::application::Application::run::{{closure}}
  13: tokio::runtime::park::CachedParkThread::block_on
  14: tokio::runtime::context::runtime::enter_runtime
  15: tokio::runtime::runtime::Runtime::block_on
  16: hx::main

Possible Resolution

See pascalkuthe/regex-cursor#4

However the error is not propagated up, so it looks like the search wrapped around when it actually aborted.

[pascalkuthe]

great` catch! I missed this because regex-automat marks error as non-exhaustive so I missed there was another variant. I created a new bugfix release for this so we just need to bump the dependency in helix. I would appreciate if you create a PR for that since that will make it easier on our end

[pascalkuthe]

I would need to look into the error propagation in more detail but I am pretty sure that wrapped around is the correct result here (it's the expected output when there is only a single match). This error is probably handled internally somewhere in the meta engine.