Crash when switching to window that was in insert mode and switched away from by mouse.

[cessen]

Summary

If you have two sub-windows open in Helix with different files, enter insert mode on one of them, switch to the other sub-window via mouse support, and then switch back to the first with keybindings, Helix crashes with the following backtrace:

thread 'main' panicked at 'not implemented', helix-term/src/ui/editor.rs:1292:34
stack backtrace:
   0: rust_begin_unwind
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:143:14
   2: core::panicking::panic
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:48:5
   3: <helix_term::ui::editor::EditorView as helix_term::compositor::Component>::handle_event
             at /home/cessen/Projects/helix/helix-term/src/ui/editor.rs:1292:34
   4: helix_term::compositor::Compositor::handle_event
             at /home/cessen/Projects/helix/helix-term/src/compositor.rs:147:19
   5: helix_term::application::Application::handle_terminal_events
             at /home/cessen/Projects/helix/helix-term/src/application.rs:387:32
   6: helix_term::application::Application::event_loop::{{closure}}
             at /home/cessen/Projects/helix/helix-term/src/application.rs:236:21
   7: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/future/mod.rs:91:19
   8: helix_term::application::Application::run::{{closure}}
             at /home/cessen/Projects/helix/helix-term/src/application.rs:758:26
   9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/future/mod.rs:91:19
  10: hx::main_impl::{{closure}}
             at /home/cessen/Projects/helix/helix-term/src/main.rs:116:30
  11: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/future/mod.rs:91:19
  12: tokio::park::thread::CachedParkThread::block_on::{{closure}}
             at /home/cessen/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.19.2/src/park/thread.rs:263:54
  13: tokio::coop::with_budget::{{closure}}
             at /home/cessen/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.19.2/src/coop.rs:102:9
  14: std::thread::local::LocalKey<T>::try_with
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/thread/local.rs:442:16
  15: std::thread::local::LocalKey<T>::with
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/thread/local.rs:418:9
  16: tokio::coop::with_budget
             at /home/cessen/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.19.2/src/coop.rs:95:5
  17: tokio::coop::budget
             at /home/cessen/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.19.2/src/coop.rs:72:5
  18: tokio::park::thread::CachedParkThread::block_on
             at /home/cessen/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.19.2/src/park/thread.rs:263:31
  19: tokio::runtime::enter::Enter::block_on
             at /home/cessen/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.19.2/src/runtime/enter.rs:151:13
  20: tokio::runtime::thread_pool::ThreadPool::block_on
             at /home/cessen/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.19.2/src/runtime/thread_pool/mod.rs:90:9
  21: tokio::runtime::Runtime::block_on
             at /home/cessen/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.19.2/src/runtime/mod.rs:482:43
  22: hx::main_impl
             at /home/cessen/Projects/helix/helix-term/src/main.rs:118:5
  23: hx::main
             at /home/cessen/Projects/helix/helix-term/src/main.rs:35:21
  24: core::ops::function::FnOnce::call_once
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Reproduction Steps

Causing the crash is easy and reliable:

1. Open Helix.
2. Split the view into two windows (e.g. space w v).
3. Load a different file into each window.
4. Enter insert mode (i) on the first window.
5. Click on the second window with the mouse.
6. Switch back to the first window with keybindings (e.g. space w w).

Note: it's important that the files in each window be different files. Loading the same file or having the scratch buffer in both doesn't cause the a crash.

Helix log

No response

Platform

Linux (NixOS 22.05)

Terminal Emulator

xfce4-terminal

Helix Version

Descovered on helix 22.05 (27609f50), confirmed to still be present on latest master ad15e7b5e8918e1521683c7f5c63d77e00c58023

[archseer]

Seems to be #2051

[the-mikedavis]

Yeah let's close in favor of #2051

[the-mikedavis]

This falls into the same unimplemented! as #2051 but not for the same reason. The w key event from the view transition sequence (<C-w>w) applies to the newly focused view. So the mode-change hook sees the normal mode of the originally focused view as Normal and the newly focused view as Insert and tries to lookup the key sequence bound to the current event: w. It sees the sequence of commands bound to w and tries to save them as if they were used to enter insert mode, which is unimplemented (covered by #2051).

It's possible to reproduce this from another angle by changing the rotate_view command to another key like <C-w>m since m yields a KeymapResult::Pending which also falls into the unimplemented!() block.

Instead, the w should be consumed earlier and mode-change and history checkpoint hooks shouldn't be triggered - similar for the behavior when the last view is closed and the application is about to exit.

[archseer]

Hmm, a potential fix is to always look up the same document: the one that was current at the start of handle_event. I wonder if this would have any edge cases though (like the completion not being cleared anymore).

[archseer]

Actually, we should probably switch documents back to normal mode if they lose focus, I do also wonder if mode should be editor-wide rather than per document.

[cessen]

Yeah, I feel like making modes editor-wide makes the most sense. At least, I can't think of any situation where you would want different modes in different documents.

[webdev23]

On a side note, Helix reacts as follow, while fed by pipe:

hx <<< i opens Helix in normal mode, with the the i written in the scratch buffer.

This is unexpected behavior. It should react exactly as is the same keystrokes were send by the user. Eq:

hx <<< i starts in insert mode with a blank scratch buffer.