<C-s> or <C-CR> seem to freeze vim...

  1. anonymous

    Odd behavior:

    On one of my linux boxes C-s and C-CR seem to pause vim. Assuming that (since it works on another linux box and a windows box) it was my vim config's fault, I moved ~/.vim to ~/.vim.bak and ~./vimrc to ~/.vimrc.bak and made a new config with only Command-T. No vimrc file, no other extensions. Vim still seems to freeze when I hit <C-s> or <C-CR> in the list. Interestingly, if the current buffer is unsaved and i just hit <CR>, Command-T opens the chosen buffer in a new horizontal split just fine. And <C-v> works.

    Any ideas? Never had to troubleshoot vim really so I'm kinda lost as to how to even approach the problem.

  2. Greg Hurrell

    The difference is most likely explained by a discrepancy in the terminal settings on the different machines (different terminals can send key presses in different ways). If you compare :set term? on the different machines you might see different terminals.

    The other things which might be different are the 'timeout', ttimeout', 'timeoutlen' and 'ttimeoutlen' settings. (See the Vim help for those.)

    Whatever the cause, however, the simplest thing to do will most likely be to override the mappings for those actions and pick ones which don't break on that machine where you're having the trouble (see :h command-t-options and scroll down to the list of mappings settings).

  3. anonymous

    Thanks much for the help!

    I run urxvt with the same config files on both linux boxes, in theory all the config files are source controlled so they should match but... reality and theory are often worlds apart :) I will look into urxvt config on both machines and read up on those vim help settings when I get home and can access linux box #2, the broken one (at work atm)!

    ... Did not submit this from work. home now: Remapping the key works. All the other settings, both terminal and vim seem identical between the two machines, mysterious but acceptable until I can find the time to track down the problem :)

    P.S. I really would had not even considered the terminal being at fault, interesting!

    P.P.S. This plugin is insanely awesome. Forgot to mention that in the first post. its like for(;;) {productivity++;} for large-scale apps with more than a few thousand files (yup, INFINITE LOOP OF PRODUCTIVITY).

  4. Greg Hurrell

    Well it's not really a "fault" of the terminal. That's just the way terminals work. For example, on mine when I press the "up" key it actually sends that as an escape sequence (ESC-O a); you can imagine how Vim interprets that... See :h term.txt, and particularly :h xterm-cursor-keys for more info on the subject.

  5. anonymous

    I'm having the same problems as the OP but am trying to avoid remapping all of the builtin commands.

    I have the same issue Wincent describes in that my terminal (well technically tmux, the teminal multiplexer) sends <Up> as <Esc>-OA. I've tried setting 

    set notimeout
set ttimeout
set timeoutlen=100

    in my vimrc but it doesn't make any difference. If I set notimeout and nottimeout then press <Esc> in insert mode then, as expected, nothing happens; with all timeouts disabled I need to press <Esc> x 2. This confirms that the timeout settings do have some effect in vim. It just seems that command-t doesn't pickup that particular setting. Could you possibly post the relevant parts of your vimrc Wincent so that I can see how you got it working? Thanks

  6. Greg Hurrell

    Well, 99% of the time I'm in MacVim which has no weird terminal issues.

    The other 1% of the time I'm in the Mac OS X Terminal, which advertises itself as xterm-color, which means that instead of <Esc> I dismiss with <C-c>.

    As for Command-T not picking up your ttimeout and related settings, it certainly should: those are global settings (active in all buffers), and Command-T is just using normal map commands (you can check them out in the controller.rb source file; see the register_for_keypresses method).

    On a side note, if you need to set a couple of special mappings or timeout overrides for a particular term type you could do it conditionally in your .vimrc with something like: 

    if &term == 'xterm-color' " or whatever your terminal is
  " custom mappings for that terminal here
endif
  7. anonymous Created , edited

    Well it turns out that I had misunderstood the purpose of the command-t mappings settings. I thought that the idea was to allow you to create an alternative mapping i.e. so that if <Up> does not work then you can use, say, <C-u> instead. I realise now that the purpose is to allow you to enter the sequence that the term actually sends.

    I've added let g:CommandTSelectPrevMap=['<C-p>', '<C-k>', '<Esc>OA', '<Up>'] to my vimrc which allows me to use the <Up> to scroll through the options which is what I wanted to achieve.

    During my investigations I realised that tmux seems to enable XON/XOFF process control which is possibly what's causing problems for the OP. It's not something that I ever use and so I explicitly disabled it in my zshrc with stty -ixon and now <C-s> works ok. <C-CR> does not work; it seems that under tmux <C-CR> sends NUL but mapping <NUL> doesn't have any effect. I'm happy with <C-s> so it's not an issue to me.

    Thanks for your help Wincent

Reply

This topic is now closed.

topic index