tmux messes up my backspace character

[Rhialto]

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.

-Olaf.

[Steffen Nurpmeso]

Rhialto <***@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

[Rhialto]

Post by Steffen Nurpmeso
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.

Post by Steffen Nurpmeso
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.

Post by Steffen Nurpmeso
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.

Post by Steffen Nurpmeso
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.

Post by Steffen Nurpmeso
--steffen

-Olaf.

[Steffen Nurpmeso]

Rhialto <***@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