On Fri, Jun 29, 2012 at 10:14:35PM +0200, Erik Faye-Lund wrote: > > Backspace shouldn't be making it to git at all; it should be handled at > > the terminal input layer, because we are not putting the terminal into > > raw mode. > > I don't get it. How can the terminal ever interpret the backspace, when > we've already put the character it's supposed to erase in a strbuf? Sure, > the echo can be correctly dealt with (probably with the exception of the > border case of erasing characters from the prompt text), but once we've put > the characters into a buffer, the terminal cannot erase it. Because a terminal in non-raw mode is typically line-oriented, and your program doesn't get to see any input at all until the user hits enter. Try this on your linux box: strace -e read cat You should be able to type characters and backspace erase them, all without seeing any activity from strace. When you hit enter, you should see the full text you typed read as a single syscall. If the backspacing doesn't work, then there is a configuration mismatch between what linux's tty driver expects and what your terminal emulator is sending (the former is probably expecting ^? as the erase character, and the latter is sending ^H). > > If that is the case, I wonder if your 'stty erase' settings > > do not match what your terminal emulator is sending. > > I have no idea what that even means. And having to fiddle around with > terminal settings just makes git feel cheap. But it's not git that is broken. It's your configuration. Fixing git is a band-aid, and other programs will still be broken. Of course, I may be mis-diagnosing your problem. Did you try this: > > If you run "stty erase ^H" and then run git, does it work? ? > > I think (3) is the only sane thing, > > though. Even if we handled \b, that is not what all terminals generate. > > In particular, most linux terminal emulators these days will generate > > DEL (aka ^? or 0x7f) on backspace. This problem needs to be solved at > > the terminal layer, and I suspect is just a configuration issue in your > > setup. > > As I already said, I don't think this is the case. Inserting 0x7f in a > strbuf does not delete the preceding char... Of course not. Control characters should be handled by the terminal driver, and shouldn't make it to git at all. Backspacing works perfectly well on correctly configured systems, and it should not be git's responsibility to care about it at all for line-oriented input (and if we _did_ want to handle it ourselves, we should use a real terminal library like readline or curses). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html