Bug #1860: arrow keys don't work under tmux/screen

diff --git a/ruby/command-t/controller.rb b/ruby/command-t/controller.rb
index 29e61b6..01e7a3c 100644
--- a/ruby/command-t/controller.rb
+++ b/ruby/command-t/controller.rb
@@ -262,6 +262,10 @@ module CommandT
       !!(::VIM::evaluate('&term') =~ /\Avt100/)
     end
 
+    def screen?
+      !!(::VIM::evaluate('&term') =~ /\Ascreen/)
+    end
+
     def register_for_key_presses
       # "normal" keys (interpreted literally)
       numbers     = ('0'..'9').to_a.join
@@ -294,7 +298,7 @@ module CommandT
           end
         else
           [value].flatten.each do |mapping|
-            map mapping, key unless mapping == '<Esc>' && (xterm? || vt100?)
+            map mapping, key unless mapping == '<Esc>' && (xterm? || vt100? || screen?)
           end
         end
       end

Comments

1. Greg Hurrell 8/27/2011

   Thanks for the patch. I'm not a heavy screen user myself but I'll try it out, and there are some people I work with that are inside screen all day long, so I'll ask them to check it out too.

   As for binding to h and j in the file-selection pane (I presume you meant j and k), I gather you are referring to when the file-listing area has focus and not the prompt, right?

2. Jack OConnor 9/12/2011

   I've hit the same bug inside tmux. For me, it doesn't matter whether I'm actually inside tmux or not, only whether $TERM is set to 'screen'. So when I set $TERM to 'xterm-256color' in my bashrc file (which I do to make the solarized colorscheme work properly), it actually fixes this issue.

3. anonymous 9/13/2011

   I have had this problem too when using tmux. Starting vim with "-T xterm" fixed the problem described by this issue, but caused other problems related to terminal emulation.

   I've just applied this patch and it indeed fixes the problem.

4. Nadav Samet 9/25/2011

   /subscribe. I applied this patch in https://github.com/thesamet/Command-T and sent a pull request.

5. Nadav Samet 12/28/2011

   Ping. What's blocking applying this patch? It seems as a reasonable fix for this issue and I've been personally using it in both Mac OS X and Linux under tmux with no problem.

6. Greg Hurrell 12/28/2011

   I have no objection to applying it, but I'm not sure if it's needed. I'm using Command-T inside tmux without problems.

   I've got this in my ~/.vimrc and even the <ESC> key works, as well as the cursor keys:

   if &term =~ "xterm"
     let g:CommandTCancelMap     = ['<ESC>', '<C-c>']
     let g:CommandTSelectNextMap = ['<C-n>', '<C-j>', '<ESC>OB']
     let g:CommandTSelectPrevMap = ['<C-p>', '<C-k>', '<ESC>OA']
   endif

   (Note: my TERM environment variable is set to xterm-256color.)

7. Nadav Samet 12/31/2011

   My TERM variable is set to screen-256color. Setting it to xterm-256color causes termination emulation issues under tmux. From the tmux man page: "The TERM environment variable must be set to screen for all programs running inside tmux. New windows will automatically have TERM=screen added to their environment, but care must be taken not to reset this in shell start-up files."

8. Greg Hurrell 1/2/2012

   In my experience, on the platforms I use tmux (Mac OS X, CentOS, Ubuntu), xterm-256color works better than screen-256color, despite what the tmux man page says.

9. Nadav Samet 1/2/2012

   As the anonymous guy said on September 12, I'm also running into terminal emulation problems with xterm-256color under tmux. In particular, vim's background color (dark gray) does not cover the entire window (only appears under the text). Screenshot: http://imgur.com/mYF2k

   Bug #1860 is a Command-T bug: it is caused by the fact that Command-T makes a special case for xterm and vt100 in controller.rb, yet it leaves 'screen' out. There's nothing broken about the screen termcap. It is just that Command-T doesn't consider it as a terminal that uses escape sequences.

10. Greg Hurrell 1/3/2012

    No, it's not a Command-T bug. Command-T never set out to provide out-of-the-box support for the millions of possible combinations of distros, terminal emulators, color schemes, Vim versions, configuration files etc. Instead, it provides a manner in which people can customize the mappings so that any aberrant ones they might have can be made to work no matter what combination of possible variables might exist in their local environment.

    The fact that it makes a special case for a couple of the more common examples (xterm and vt100) does not make the failure to special case screen also a bug. The reason why I wasn't in a hurry to add more special overrides was because it is a slippery slope to start down; it starts to appear like you are "supporting" whatever combination of user-specific aspects in the local environment, and before you know it you have a ridiculously long list of exceptions and overrides, when all along the ability of the user to override the specific mappings that don't work for them is actually enough.

    Note: as I said above, I have no objections to applying the patch, but this is not a bug in Command-T.

11. Nadav Samet 1/3/2012

    If you'd prefer, there could be a user configurable vim variable the lists the terminals we make a special case for. As long as the user have a way to make his terminal of choice work in Command-T, we'll all be happy.

12. Nadav Samet 2/12/2012

    Hi Wincent, I just wanted to check if you're ready to apply the patch. Thanks, Nadav

13. Greg Hurrell 3/25/2012

    I'm going to apply the patch and close the pull request. Marking this ticket as closed.

14. Greg Hurrell 3/25/2012

    Status changed:

    • From: new
    • To: closed

Add a comment

Comments are now closed for this issue.