GNOME Bugzilla – Bug 420039
VTE doesn't distinguish between backspace and control-backspace
Last modified: 2015-05-03 20:31:51 UTC
When the user types a backspace into VTE, it sends it off as either C-h, C-?, or the delete character regardless of whether the control key is pressed. This is frustrating, as it means that the behavior of control-backspace can't be customized for Emacs or other programs that use Readline. This patch adds an additional element to the VteTerminalEraseBinding enum, VTE_ERASE_VARYING, that causes backspace and control+backspace to send different characters. I have backspace sending C-? while control-backspace sends C-h, although this is an essentially arbitrary decision; it could just as easily be the other way around. Thanks for your consideration. Index: src/vte.c =================================================================== --- src/vte.c (revision 1851) +++ src/vte.c (working copy) @@ -4240,6 +4240,14 @@ special = "kD"; suppress_meta_esc = TRUE; break; + case VTE_ERASE_VARYING: + if (terminal->pvt->modifiers == GDK_CONTROL_MASK) + normal = g_strdup("); + else + normal = g_strdup(""); + normal_length = 1; + suppress_meta_esc = FALSE; + break; /* Use the tty's erase character. */ case VTE_ERASE_AUTO: default: @@ -4269,6 +4277,7 @@ break; case VTE_ERASE_DELETE_SEQUENCE: case VTE_ERASE_AUTO: + case VTE_ERASE_VARYING: default: special = "kD"; break; Index: src/vte.h =================================================================== --- src/vte.h (revision 1851) +++ src/vte.h (working copy) @@ -147,7 +147,8 @@ VTE_ERASE_AUTO, VTE_ERASE_ASCII_BACKSPACE, VTE_ERASE_ASCII_DELETE, - VTE_ERASE_DELETE_SEQUENCE + VTE_ERASE_DELETE_SEQUENCE, + VTE_ERASE_VARYING } VteTerminalEraseBinding; /* Values for the anti alias setting */
Created attachment 84867 [details] [review] A proposed patch to fix this. I hadn't realized I could attach a patch, so I included it in my report :p. Here's the patch as an attachment, though, just in case.
*** Bug 436697 has been marked as a duplicate of this bug. ***
Why this patch isn't applied?
Still a problem in 0.28.
*** Bug 683145 has been marked as a duplicate of this bug. ***
Can we please get the patch in? Or if not, just get this fixed?
patch/ticket are five years old? this would be very nice to have.
Is there any way to help speed this through? The patch is already written.. so..
What does xterm do? What does Konsole do? That's the kind of info needed to move this forward. Otherwise, as the patch author himself says: "this is an essentially arbitrary decision" Also needed is a the gnome-terminal patch to expose this new option.
Fixing this (i.e. sending different signals, or allowing the option to send different signals) or not is not an arbitrary decision. However, I concede that picking which *different* signals to send is an arbitrary decision. As in, picking ^? for Backspace or ^H for Control+Backspace or the other way around. Both xterm and Konsole send or allow sending different signals (i.e. don't have this bug). xterm, out of the box, sends ^? for Backspace and ^H for Ctrl+Backspace. Konsole sends ^? for both, however it allows the option to customize everything. (To configure similarly to xterm, the change is pretty simple. Just go to Settings/Configure Current Profile../Input/Edit.. then change "Backspace" to "Backspace-Ctrl" and add a new entry "Backspace+Ctrl" with output "\b"). The original patch is correct, in that it simply adds a new option that sends ^? for Backspace and ^H for Ctrl+Backspace. If the user needs it, he can change to it. If not, he can just ignore. Indeed, there's a need to add a gnome-terminal patch (isn't it a different project than vte?). But as this vte patch simply adds a new option, rather than making a breaking change, that can come in later (I'll personally start an issue/patch as soon as this vte patch is in, as I'm particularly interested in this). Furthermore, there are other terminals that also depend on vte which could benefit, for example Guake (http://guake.org/). Thanks for your interest in this, Behdad.
(In reply to comment #10) > The original patch is correct, in that it simply adds a new option that sends > ^? for Backspace and ^H for Ctrl+Backspace. If the user needs it, he can change > to it. If not, he can just ignore. We don't maintain software by adding a new option every time someone proposes one... That said, if the new behavior exactly matches xterm, that's reason enough to do that, since matching xterm is the main goal when it comes to emulation behavior. ChPe, do you think you would have time to adjust the patch and commit it? I don't like the name 'varying'. Perhaps just replace with 'xterm'?
Sigh. I hate adding ever more workarounds, instead of fixing this outright (by using terminfo). But since that won't happen for a long time yet, ok... Let's rename to XTERM and also use an octal escape in the strdup instead of putting that thing as literal in the code. And a g-t patch needs to be done too; I'm only committing this if it's used in g-t.
+ if (terminal->pvt->modifiers == GDK_CONTROL_MASK) Shouldn't test for equality here I think, just '&', unless xterm behaves this way too.
I'm glad this is finally getting attention (or is it released already?). Question: if we use ^? for backspace and ^H for ctrl+backspace, how would we distinguish ctrl+h from ctrl+backspace? Can we invent a new escape sequence for ctrl+backspace? Or is this something we must live with?
This bug/problem is still alive and kicking. What's the current status of it? Christian Persch, you were about to commit the patch to fix this?
I think we should re-evaluate the backspace/delete options we provide. Now that we only emulate xterm, we should have exactly the same options.
All of xterm, hterm, linux, konsole map Control-Backspace to ^H by default. I believe VTE should do the same thing, even if it was not configurable. Until now, BS and C-BS did the same thing, so it's extremely unlikely that anyone even uses C-BS - why would he? Hence, this change would not break existing users, while providing a bit of useful functionality.
Ctrl+Backspace deletes an entire word in gedit. It deletes an entire word in Libre Office. It deletes an entire word in the Chrome and Firefox address bars. It deletes an entire word in Sublime Text. It deletes an entire word in the Nemo search bar. Due to this problem, I can't make it delete an entire word in Gnome Terminal. That makes me sad. Gnome developers, please, help!!!
This bug is eight years old. People who were born when this bug was first announced are old enough to walk. Franz Kafka would do a doubletake at the absurdity. It's even still marked "NEW"!
Sorry guys, I didn't notice this bugreport, not even when I filed a duplicate. Marking as anachronistic dup because the other one has a patch I'm about to apply. *** This bug has been marked as a duplicate of bug 733246 ***