Colour bleeds right when writing a custom script in byobu

The problem is twofold. First, tmux by default converts the control-arrow keys from one type of escape sequence to another. So special keys such as controlleft are sent to vim without the modifier, e.g., left. If you use cat -v to see the different escape sequences, you might see something like this

^[OD

versus this (outside tmux):

^[[1;5D

The line

set-window-option -g xterm-keys on

fixes that aspect. The other part is that tmux by default uses the terminal description for screen. That terminal description does not describe the control-arrow keys. These entries from the terminal database would be the most appropriate for VTE (gnome-terminal):

• screen.vte
• screen.vte-256color

There are others, such as

• screen.xterm-new
• screen.xterm-256color

which would be automatically selected when running in screen if the corresponding TERM outside were vte, vte-256color, etc. tmux does not do this automatic-selection; you have to modify its configuration file.

By the way, there is no "screen.xterm" entry because it would interfere with some usages of screen. There is no conflict with TERM=xterm-new.

If you have a default (minimal) terminal database such as ncurses-base in Debian, you might not have those. More common would be xterm-256color, which is close enough to use with vim and tmux.

For example, if I add this to my .tmux.conf file, it behaves as you expect in vim:

set -g default-terminal "xterm-256color"

Further reading:

• XTERM Extensions (terminal database)
• vim: how to specify arrow keys
• How can I see what my keyboard sends?

byobu is just a wrapper around tmux, which is responsible for the behavior you're seeing. tmux is attempting to translate "keys" into the character sequence that xterm would encode modified special keys. In the manual, that's documented:

         xterm-keys [on | off]
                 If this option is set, tmux will generate xterm(1) -style
                 function key sequences; these have a number included to
                 indicate modifiers such as Shift, Alt or Ctrl.  The
                 default is off.

though in new/recent versions, reportedly the default is on. That exposed a problem, seen in this commit-message:

commit d52f579fd5e7fd21d7dcf837780cbf98498b10ce
Author: nicm <nicm>
Date:   Sun May 7 21:25:59 2017 +0000

    Up to now, tmux sees \033\033[OA as M-Up and since we turned on
    xterm-keys by default, generates \033[1;3A instead of
    \033\033[OA. Unfortunately this confuses vi, which doesn't understand
    xterm keys and now sees Escape+Up pressed within escape-time as Escape
    followed by A.

    The issue doesn't happen in xterm itself because it gets the keys from X
    and can distinguish between a genuine M-Up and Escape+Up.

    Because xterm can, tmux can too: xterm will give us \033[1;3A (that is,
    kUP3) for a real M-Up and \033\033OA for Escape+Up - in fact, we can be
    sure any \033 preceding an xterm key is a real Escape key press because
    Meta would be part of the xterm key instead of a separate \033.

    So change tmux to recognise both sequences as M-Up for its own purposes,
    but generate the xterm version of M-Up only if it originally received
    the xterm version from the terminal.

    This means we will return to sending \033\033OA instead of the xterm key
    for terminals that do not support xterm keys themselves, but there is no
    practical way around this because they do not allow us to distinguish
    between Escape+Up and M-Up. xterm style escape sequences are now the de
    facto standard for these keys in any case.

    Problem reported by jsing@ and subsequently by Cecile Tonglet in GitHub
    issue 907.