Re: tmux messes up my backspace character
On Fri 15 Aug 2014 at 15:16:41 +0200, Steffen Nurpmeso wrote: Can't you simply `bind-key' over that? I don't think so. bind-key looks to be for commands only, not a general translation mechanism. But i'm out of ideas if not; i switched back to screen(1) due to it's charset conversion capabilities (i'm still using ISO-8859-x on all BSD VMs),o Yes, so do I, and I noticed that if I happen to access my systems from Linux, then tmux won't translate characters for use in utf8 terminals. requires significantly less CPU time and after I am also surprised by the high cpu time usage of tmux. I wonder what it is doing in all that time? The FAQ mentions something about automatic window renaming or somesuch - I'm going to try turning that off and see if that helps. And i guess your problem could be easily fixed with it's `term*' commands. I used screen before, and there the problem doesn't exist at all. It took a while to discover it in tmux because many programs can use whatever is set for the erase character, including bash. I noticed it in mutt, where ^H scrolls back a single line in a mail message. I have also mailed to the tmux-users mailing list, and I have discovered which code seems to be responsible for the translation: /* * Check for backspace key using termios VERASE - the terminfo * kbs entry is extremely unreliable, so cannot be safely * used. termios should have a better idea. */ bspace = tty-tio.c_cc[VERASE]; if (bspace != _POSIX_VDISABLE key == bspace) key = KEYC_BSPACE; in cvs/src/external/bsd/tmux/dist/tty-keys.c. Note that KEYC_BSPACE is '\177' or ASCII DEL, not backspace. --steffen -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpjgA7pgQ3hU.pgp Description: PGP signature
Re: tmux messes up my backspace character
Rhialto rhia...@falu.nl wrote: | Can't you simply `bind-key' over that? | |I don't think so. bind-key looks to be for commands only, not a general |translation mechanism. I now see tmux has also has a terminal-overrides.. oops, but mind you, i still was registered to tmux-users@ once the thread you have been pointed to was current, so i'm sorry i didn't remember that. But i have e.g. `bind a eval copy stuff \002' in my .screenrc -- `stuff' is a very powerful tool, too. | But i'm out of ideas if not; i switched back to screen(1) due to | it's charset conversion capabilities (i'm still using ISO-8859-x | on all BSD VMs),o | |Yes, so do I, and I noticed that if I happen to access my systems from |Linux, then tmux won't translate characters for use in utf8 terminals. So with screen i can stay in a single session, with tmux i couldn't: simply setting an UTF-8 flag on some window doesn't help to deal with different character sets. Though most is english, German Umlauts can well be transformed, even round-trip. I _really_ was surprised once i saw that this feature was missing, my guess is that administrators still live in a heterogeneous environment: all english. | requires significantly less CPU time and after | |I am also surprised by the high cpu time usage of tmux. I wonder what it |is doing in all that time? The FAQ mentions something about automatic |window renaming or somesuch - I'm going to try turning that off and see |if that helps. Worse, for 1.6 to compile on Snow Leopard i even had to adjust its usage of `struct bsdinfo', if i recall correctly, so i even had to blame myself? Ok, sometimes i wish screen would always display a status line with all currently open windows or at least had an option to always display the current one so that there would be no need to ^A-w (windows) or ^A-W (windowlist), but having one more line is a great thing. | And i guess your problem could be easily fixed with it's `term*' commands. | |I used screen before, and there the problem doesn't exist at all. It |took a while to discover it in tmux because many programs can use |whatever is set for the erase character, including bash. I noticed it in |mutt, where ^H scrolls back a single line in a mail message. | |I have also mailed to the tmux-users mailing list, and I have discovered |which code seems to be responsible for the translation: | |/* | * Check for backspace key using termios VERASE - the terminfo | * kbs entry is extremely unreliable, so cannot be safely | * used. termios should have a better idea. | */ |bspace = tty-tio.c_cc[VERASE]; |if (bspace != _POSIX_VDISABLE key == bspace) |key = KEYC_BSPACE; | |in cvs/src/external/bsd/tmux/dist/tty-keys.c. Note that KEYC_BSPACE is |'\177' or ASCII DEL, not backspace. So i hope for you that tmux(1) gets fixed (you wrote which shows to my mind a misunderstanding), back in February the thread ended with anyway try running stty verase ^? in tmux, at least from the developer side. Now that i know it but am back to screen, all i miss is `bind-key set-window-option force-width 80' (and ditto ` 0'), which was very nice to have when reviewing code, but i can still use `wc -L'. --steffen
Re: tmux messes up my backspace character
Rhialto rhia...@falu.nl wrote: |It seems that tmux translates the erase character, but it should not do |that. | |In my xterms I have set the option Backarrow key which causes the key |labeled backspace to generate an actual backspace (control-H) |character. Correspondingly, I have set stty erase ^H. | |Inside tmux, if I hit Backspace, I get a DEL character (^?). And somehow |it has set stty erase ^? as well. So apparently it translates the |external erase character to an internal one. | |All is good and well, but this means I can't type ^H any more! And there |are several programs where I would want that, such as mutt and vim. | |The manual doesn't contain the word erase... is there any less obvious |way to stop tmux doing this annoying thing? I simply want my internal |erase character the same as the external one, and no messing about with |translating backspace. Can't you simply `bind-key' over that? But i'm out of ideas if not; i switched back to screen(1) due to it's charset conversion capabilities (i'm still using ISO-8859-x on all BSD VMs), requires significantly less CPU time and after a week of work with full history (42000) it's ~50 MB, which is a 40% of tmux. All that matters to me. And i guess your problem could be easily fixed with it's `term*' commands. --steffen
