In Atuin UI interprets backspace as literal ^h

[manel-bc]

Opening the Atuin UI and pressing the backspace key writes an h to the input. To delete the previous character I need to press ctrl+backspace.

I assume it has to do with backspace, ^H, being interpreted as the literal ^H in some way, hence why ctrl "cancels out" the ^.

I can reproduce in:

• cool-retro-terminal
• xterm

OS: Arch linux
Atuin version: 18.0.1

[akinomyoga]

I was actually wondering if this behavior of ignoring Ctrl in unprocessed Ctrl+Letter is intended or not.

As for the backspace key, there are variations among terminals about how the backspace key is transmitted in the terminal-to-application stream. Some terminals use C-? (\x7F) and some terminals use C-h (\x08). I'm not sure whether ratatui/crossterm tries to resolve this variation, but if that is the case, maybe this can be a ratatui/crossterm issue.

edit: crossterm is translating the binary representation to the key information. However, backspace seems to be assumed to be always ^? here. In the past, I surveyed which terminal sends which code for backspace and C-backspace keys as summarized here. Most terminals send ^? for the backspace key. Terminology, Solaris console, Minix console, RLogin, and Poderosa send ^H for backspace.

[manel-bc]

Thanks for the info 🙏, first of all.
Wouldn't this be an issue in any TUI using those libs? I've used other programs that use ratatui/crossterm, like gitui and they behave as expected.

[manel-bc]

I tested atuin in the kitty terminal emulator and it works fine there.

[akinomyoga]

Wouldn't this be an issue in any TUI using those libs?

I think so.

like gitui and they behave as expected.

Thanks for the information. gitui seems to resolve the issue at the application level here. ...But wait, this code seems to be just introduced last week in extrawurst/gitui#2051 6915df9. Maybe this is unrelated.

[mjf]

It's not an easy thing, I think. I temporarily resolved this with:

XTerm.VT100.Translations: #override\n\
        <KeyPress> BackSpace: string(0x7f)

in my ~/.Xresources for I was too lazy to find some proper way. There is also very good description/explanation about the backspace stuff in the xterm(1) manual and on TLDP.

---

UPDATE: The solution for XTerm is far from ideal for several reasons (e.g., it breaks recent versions of Vim etc.) so I would beg for fixing it in atuin, please. Thank you.

---

UPDATE 2: It seems that on my system the issue can be resolved with:

XTerm.VT100.backarrowKey: false
XTerm.VT100.backarrowKeyIsErase: false

Perhaps it helps somebody too...

[bithack3r]

I'm on Kali Linux 2024.1
QTerminal 1.4.0

I have same problem with backspace being replaced by 'h' and Ctrl+h working as backspace

[akinomyoga]

Ideally, this kind of handling should be resolved at the lower level of crossterm, but I guess it would be hard to expect crossterm to implement it properly. To properly implement it, one needs to prepare a list of the behavior of every terminal, and one also needs to identify the terminal it connects to.

An easy solution is to assign the same feature to all of C-h, C-?, backspace, and C-backspace, whose representations are mixed with one another depending on the terminal. (P.S. This is actually the solution ble.sh takes.)

[akinomyoga]

We are currently assigning different features to backspace and C-backspace.

atuin/atuin/src/command/client/search/interactive.rs

Lines 375 to 381 in 8e9e7b9

	KeyCode::Backspace if ctrl => self
	.search
	.input
	.remove_prev_word(&settings.word_chars, settings.word_jump_mode),
	KeyCode::Backspace => {
	self.search.input.back();
	}

Depending on the terminal, they might be swapped. That is, crossterm may report KeyCode::Backspace with ctrl when the user presses Backspace and report KeyCode::Backspace with !ctrl when the user presses Ctrl+Backspace.

---

edit: The upstream crossterm seems to be collecting the issues related to the key representations in crossterm-rs/crossterm#685, which also includes some backspace issues. However, they are just collecting the information and do not seem to make any effort.

---

edit2: There is a PR that solves the issue in crossterm-rs/crossterm#506. However, it seems to be blocked because of the terminal dependency.