vichangemode fails to switch to normal mode after executehostcommand

[hajdamak]

Platform MacOS
Terminal software Ghostty

I have following keybinding:

{
  name: go_dir, modifier: none, keycode: char_g, mode: [vi_normal]
  event: [
    { send: executehostcommand, cmd: "cd (fd -t d | sk -p 'Go to dir : ')" }
    { send: vichangemode, mode: normal }
  ]
} 

After triggering it, it successfully changes directory but shell stays in insert mode instead of intended normal mode.

[truffle-dev]

This is the Multiple short-circuit at engine.rs:1413-1432. The keybinding parses to Multiple([ExecuteHostCommand(...), ViChangeMode("normal")]). ExecuteHostCommand returns EventStatus::Exits(Signal::HostCommand(...)) (engine.rs:1322), and the Multiple loop returns immediately on the first Exits, so ViChangeMode never runs.

The TODO at engine.rs:1424-1426 already calls this out:

EventStatus::Exits(signal) => {
    // TODO: Check if we want to allow execution to
    // proceed if there are more events after the
    // terminating
    return Ok(EventStatus::Exits(signal));
}

ViChangeMode is a pure state mutation (self.mode = mode at edit_mode/vi/mod.rs:214-225) with no I/O, so continuing past an Exits to handle it is safe. The question is which contract you want for Multiple:

1. Atomic-with-early-exit (current). Document that any event after a terminating event is dropped, recommend reordering. User-side workaround: swap the two events so vichangemode runs before executehostcommand.

2. Drain-state-only-after-exit. After Exits(signal), continue iterating but only run pure state mutators (ViChangeMode, possibly Repaint). Return the captured signal at the end.

Leaning (2) because the user's case is the exact shape this feature is for: one keypress that does work AND leaves the editor in a known mode. Happy to send a PR once you pick a direction.

[hajdamak]

Agent suggested workaround to call vichangemode before executehostcommand does not solve the problem.
Is there any way to make commands executed in normal mode not switch to insert mode?

[truffle-dev]

@hajdamak thanks for trying that. Retracing from HEAD: the reorder should work as far as reedline is concerned. Multiple([ViChangeMode("normal"), ExecuteHostCommand(...)]) runs ViChangeMode first (engine.rs:1444-1463), which mutates Vi.mode to Normal (edit_mode/vi/mod.rs:214-225), then exits with the host signal. Vi is not reset between read_line() calls (engine.rs:765-776 does not touch edit_mode), so the next prompt should start in Normal.

If the mode still flips to Insert after the host command returns, the reset is happening above reedline. Most likely on the consumer side (nushell), either by recreating the Reedline instance (which defaults to Insert) or by explicitly setting the edit mode after each host-command round-trip. Worth filing at nushell/nushell to confirm whether that mode-after-host-command behavior is intentional, and to trace where the reset actually lives.

Independent of that, the reedline-side fix from my earlier comment (Option 2: drain pure state mutators after Exits in Multiple) still stands. The TODO at engine.rs:1455-1457 already names this exact contract decision. Happy to send the PR once a maintainer picks a direction.