search input is duplicated on Windows

[ErichDonGubler]

Describe the bug

Key input in search is duplicated by non-press events reported by crossterm (e.g., Release events). This only affects Windows, as far as I know, since it's the only platform that has KeyboardEnhancementFlags::REPORT_EVENT_TYPES always set. This feature was introduced with the consumption of crossterm 0.26.1, viz., 39224c3, where key repeat and release events were added but not handled in minus code.

To Reproduce

1. Enter search functionality with some input suitable for testing.
2. Begin typing a search query, i.e., cat. Observe that letters are repeated, i.e., ccaatt, cacatt, etc.

I was able to reproduce this using this file layout in a new Cargo project:

• Cargo.toml:

  [package]
  name = "tmp-xz0anm"
  version = "0.1.0"
  edition = "2021"
  
  [dependencies]
  lipsum = "0.9.1"
  minus = { version = "5.6.1", features = ["dynamic_output", "search"] }

• src/main.rs:

  use std::{fmt::Write, thread, time::Duration};
  
  fn main() {
      let mut pager = minus::Pager::new();
      let pager_thread = thread::spawn({
          let pager = pager.clone();
          move || minus::dynamic_paging(pager)
      });
      for word in lipsum::lipsum(2_000).split_whitespace() {
          writeln!(pager, "{word}").unwrap();
          thread::sleep(Duration::from_millis(10));
      }
      pager_thread.join().unwrap().unwrap();
  }

Expected behavior

Screenshots

I don't think this is necessary, but can provide screenshots on request.

Environment:

• OS: Windows
• Terminal: Wezterm
• Shell: Nushell
• minus Version: 5.4.0 is the youngest release that does not reproduce this issue. 5.5.0 and onwards (ATOW, 5.6.1 is the latest) reproduce it, being broken by 39224c3.

Additional context

Noticed as the root cause of martinvonz/jj#3448.

crossterm upstream issue: crossterm-rs/crossterm#797

crossterm upstream is planning on making the KeyboardEnhancementFlags::REPORT_EVENT_TYPES feature opt-in with crossterm-rs/crossterm#778. However, this change still seems desirable, since it's more robust and correct overall.