After using atuin interactively, home key stops working in the shell

[uber6]

When I first open my terminal (terminator, gnome terminal, xterm), home key works as intended. However, after going interactive on Atuin and exit out, home key stop working (the cursor doesn't go to the beginning of the line)

[axelkar]

Does invoking /usr/bin/reset fix the issue?

[uber6]

Does invoking /usr/bin/reset fix the issue?

No it does not. As a matter of fact, End key doesn't work either.

[JaCoB1123]

I noticed the same issue and just noticed it's because of atuin. For me calling /usr/bin/reset does fix the issue though. It only helps until the next usage of atuin though.

While not working, Home prints "H" and End prints "F".

Edit: some more information:
In urxvt with zsh Home/End just stop working and don't do anything.
In wezterm with zsh Home/End input "H" and "F".
In urxvt and wezterm with bash everything seems to be working fine.

Edit2:
Commenting the two echoti-calls from the atuin init zsh seems to fix the problem.

# echoti rmkx
# swap stderr and stdout, so that the tui stuff works
# TODO: not this
# shellcheck disable=SC2048
output=$(RUST_LOG=error atuin search $* -i -- $BUFFER 3>&1 1>&2 2>&3)
# echoti smkx

[JaCoB1123]

# Switch to cursor mode, then back to application
echoti ke
# swap stderr and stdout, so that the tui stuff works
# TODO: not this
# shellcheck disable=SC2048
output=$(RUST_LOG=error atuin search $* -i -- $BUFFER 3>&1 1>&2 2>&3)
echoti ks

This seems to work as well (seen https://zsh.sourceforge.io/FAQ/zshfaq03.html in Section 3.8).

[tpoliaw]

I am also seeing this problem.

For me echoti ke and echoti ks return errors (no such terminfo capability) but something that did work was swapping the rmkx and smkx in the original. I think this makes more sense as (per terminfo and the zsh docs @JaCoB1123 linked), smkx is enter application mode and rmkx is leave back to normal mode, but I'm not sure what the original intention was. Is crossterm expecting a particular state?

I think it also explains why ke and ks worked when in that order for the terminals where those are available. @JaCoB1123 does swapping them to match the original order bring the bug back?

[JaCoB1123]

I actually just noticed the linked FAQ mentions echotc instead of echoti as well, which work interchangeably for me.

I'm able to reproduce the issue using the original (rmkx/smkx) and it's working with the lines swapped, removed or replaced by ke/ks. Reading the terminfo page @tpoliaw linked, swapping the lines seems to be the correct way to continue. I just created #1149 as a potential fix