This is a temporary fix, at least for my particular keymap.

                        self.last_insert.0 = match self.keymaps.get(mode, key) {
                            KeymapResult::Matched(command) => command,
                            KeymapResult::MatchedSequence(commands) => {
                                commands.last().unwrap().clone()
                            }
                            // FIXME: insert mode can only be entered through single KeyCodes
                            _ => unimplemented!(),
                        };

This works well for my keymap:

[keys.normal]
C = ["collapse_selection", "extend_to_line_end", "change_selection"]

But maybe self.last_insert.0 should take the last command that switches to insert mode and not just the last command of the sequence.

@icanhazcheeze saw your implementation here too icanhazcheeze@930b4a5

But maybe self.last_insert.0 should take the last command that switches to insert mode and not just the last command of the sequence.

Yeah exactly. Maybe the mode transition logic should happen in https://github.com/helix-editor/helix/blob/master/helix-term/src/ui/editor.rs#L803-L823= instead so we can determine the exact command that switched?

Just want to drop a note here that I run into this multiple times a day via the trigger described in #3090. Thankfully, I save obsessively, so I don't lose a substantial amount of work from it.

But it would be nice to see the priority bumped on this, since it's a crash that's very easy to accidentally trigger as a user even in Helix's default configuration. (Unfortunately, I don't have the bandwidth to try to fix this myself right now. :-/)

I stumbled upon this error as well for the same reason (trying to remap C to change to end of line). Just voicing my support for this fix. Thanks!

Being able to use https://github.com/LGUG2Z/helix-vim without code changes would be awesome...

I just want to make sure this is emphasized: this bug is easily triggered in the default configuration with no keybinding customization whatsoever. I have multiple crashes a day from this in the default configuration. I believe this is a critical bug.

I am worried that this is getting lost due to the relatively benign title and description of this issue, which makes it sound like it's only preventing certain keybinding customizations.

On the contrary, this is easily triggered (resulting in a crash) in a completely vanilla installation with zero custom configuration. The critical trigger for this bug is described in the now-marked-duplicate #3090.

(I'm not intending to be pushy here, I just want to make sure this isn't lost among the comments that (unintentionally) obscure how critical a bug this is.)

EDIT:
I goofed a little. It doesn't happen in a completely default config. I thought it did, because I don't have any seemingly relevant keybinding changes in my config (e.g. mode switches) and it could be triggered without using any of my custom keys.

This is a minimal config.toml that crashes in combination with following the steps in #3090:

keys.normal.w = ["no_op"]

Importantly, you never have to use the custom binding. It just has to be defined, and then follow the steps in #3090. It seems specific to the w key, since I can have other bindings defined, and as long as w isn't custom-bound it all works fine. It also seems specific to binding w to a command sequence, because w = "no_op" is also fine.

Looks like I was too hasty in marking #3090 as a duplicate 😓. Sorry @cessen! I'll re-open that and I'll post a change to fix it too.

@the-mikedavis

No worries! I realize I may have come across a bit aggressive, which wasn't my intention. I just wanted to make sure the issue didn't get lost in the weeds.

Thanks so much for looking into it!

Merged #2634 to resolve the panic but it would still be good to repeat the whole sequence: #2634 (comment)