Backspace in gnome-terminal often deletes cluster

[Eberhard Beilharz]

If I have ខែ្ (U+1781 U+17c2 U+17d2) in the terminal and press backspace, the first backspace deletes U+17c2 U+17d2 so that I'm left with ខ (U+1781). Instead it should only delete the last codepoint, U+17d2.

If I have ខែ (U+1781 U+17c2) a backspace deletes only U+17c2, similarly if I have ខ្ (U+1781 U+17d2) where the backspace deletes U+17d2.

Further investigations show that backspace often deletes the entire cluster, i.e. diacritic(s) plus the base character, for example with x̣́ (U+0078 U+0301 U+0323) where a backspace deletes all three codepoints.

gnome-terminal should only delete the last codepoint [1].

A real live example where this behavior is problematic is when using ibus-keyman with the Khmer Angkor keyboard [2]. When typing xEjmr the expected output is ខ្មែរ (U+1781 U+17d2 U+1798 U+17c2 U+179a). Keyman does some reordering while typing to put the codepoints in a standardized order. Because gnome-terminal lacks support for surrounding text, the codepoints have to be deleted by emitting several backspace keypresses. Because of the deletion of the cluster the result in gnome-terminal is ្មែរ (U+17d2 U+1798 U+17c2 U+179a).

[1] https://github.com/keymanapp/keyman/wiki/Backspace-and-cluster-deletion
[2] https://github.com/keymanapp/keyman/issues/10481

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: gnome-terminal 3.44.0-1ubuntu1 [modified: usr/libexec/gnome-terminal-server]
ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3
Uname: Linux 6.5.0-14-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Fri Jan 26 12:21:42 2024
InstallationDate: Installed on 2022-04-12 (653 days ago)
InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Beta amd64 (20220329.1)
SourcePackage: gnome-terminal
UpgradeStatus: No upgrade log present (probably fresh install)

[Egmont Koblinger (egmont-gmail)]

It's never the terminal emulator (whether GNOME Terminal or any other terminal app) that decides what to print on a backspace keypress. The only thing it does is that it tells over the tty line that the backspace key has been pressed.

It's the remote party, which could be the application running inside (such as "bash", "vim" etc.), or the kernel's cooked mode handler code (e.g. if you're running "cat") that decides what to tell to the terminal how to update its canvas (such as e.g. retreat the cursor by one, print a space, and retreat the cursor again -> to achieve the visual effect of deleting the last single-cell character). The terminal emulator has no other choice than to blindly execute these instructions and update its canvas accordingly. (It cannot even tell if this requested display update was in any way connected to the backspace keypress or not, nor should it care.)

That's just the way this whole architecture looks like. You have to file a bugreport against whichever applications where backspace doesn't work as you'd expect it.

[Egmont Koblinger (egmont-gmail)]

By the way... absolutely independently from terminals...

U+17d2 is a combining accent. When I checked (many years ago), major graphical toolkits (e.g. GTK and QT) disagreed whether the backspace keypress should delete only the combining accent, or the entire glyph (base character + combining accents) at once. GTK did one, QT did the other (I can't recall which one did which).

I don't know if the world has changed since and has settled with one of these behaviors, having found out that one of these behaviors is clearly superior to the other. I would _guess_ that not much has changed. That is, both possible behaviors are reasonable, both have their pros and cons, and probably you cannot claim that the behavior _must_ be the one you're looking for.

If your input method cannot generate the symbols you need, and you need to press backspace as a workaround to get that, moreover, you need to rely on one particular behavior of backspace, then I'd argue that it's all the fault of your input method, it should be able to produce straight away whatever you wish to end up with.

[Egmont Koblinger (egmont-gmail)]

Maybe the bug you _really_ wanted to report is that gnome-terminal doesn't use the "surrounding text" feature of input methods?

[Eberhard Beilharz (ermshiperete)]

> It's never the terminal emulator (whether GNOME Terminal or any other terminal app) that decides what to print on a backspace keypress. The only thing it does is that it tells over the tty line that the backspace key has been pressed.

Makes sense. However, the user thinks of gnome-terminal because that's what he runs...

> If your input method cannot generate the symbols you need, and you need to press backspace as a workaround to get that, moreover, you need to rely on one particular behavior of backspace, then I'd argue that it's all the fault of your input method, it should be able to produce straight away whatever you wish to end up with.

Unfortunately that's not always possible. Please take a look at the wiki page under [1]. With complex writing systems there's more than one way to write a word which look 'correct' on the screen, but the order of the code points is different [2]. Not very good if you search for that word. Therefore Keyman allows to define keyboards that can auto-correct words so that you end up with the same order of the code points regardless which way you type [3]. And that requires to replace some codepoints typed previously.

> Maybe the bug you _really_ wanted to report is that gnome-terminal doesn't use the "surrounding text" feature of input methods?

That would be nice to have but until then it would be good to have backspace working properly. But as you wrote in an earlier comment that has nothing to do with gnome-terminal...

[1] https://github.com/keymanapp/keyman/wiki/Backspace-and-cluster-deletion
[2] https://www.sil.org/resources/archives/91817
[3] https://help.keyman.com/keyboard/khmer_angkor/1.0.7/KAK_Documentation_EN.pdf