Mappings clash with vim-surround

  1. guns

    Recently, I tried searching for a css file by typing css, and I discovered that the cs mapping provided by vim-surround was putting me in normal mode in the search buffer, instead of typing cs! (the ds and ys mappings are also affected)

    I took a look at CommandT::Controller#register_for_key_presses, but I didn't see any obvious reason why the vim-surround mappings weren't being overridden. But, I haven't spent a lot of time digging into the nuances of Vimscript or the vim mappings system, so the reason may actually be obvious.

    The issue occurs in both urxvt and Terminal.app, where set term? is screen-256color-bce, rxvt-unicode, and xterm-color.

  2. guns

    I guess I should have read the link called wikitext markup before I posted... the inconsistent coloring above is from quoting with backtick-singlequote.

  3. Greg Hurrell

    (Edited your post to fix your markup.)

    I'm a vim-surround user too and haven't seen what you describe, so it must be something local to your set-up. I just tried to reproduce it and typing "css" at the Command-T prompt just searches for "css".

    Command-T doesn't try to override any existing mappings — that would be impossible seeing as it can't know what different mappings people have set up and it wouldn't make sense to try — but it does add its own mappings.

    Can you paste your .vimrc up somewhere so that we can look at? It seems likely to me that the cause is somewhere in there. Also, how did you install vim-surround and what version is it?

  4. guns

    So the problem is my own :(. Sorry to bring it to your door. If you don't mind taking a moment to help though, here is my .vimrc:

    http://github.com/guns/nerv-guns/blob/guns/etc/user.vimrc

    and my ~/.vim

    http://github.com/guns/nerv-guns/tree/guns/etc/user.vim

    vim-surround is installed straight from the github repo.

    --

    It's a lot to wade through, so if you would like to instead just give me a direction to pursue, that would also be much appreciated.

  5. guns

    Oh! I found it.

    I have set notimeout, because I like emacs-style mappings and am annoyed when vim times out my incantations.

    Setting set timeout seems to fix the issue, but I would prefer to keep that setting the way it is.

    Hmm...

  6. Greg Hurrell

    Instead of setting notimeout, have you considered setting a high timeoutlen?

    I have a hunch that that might fix the problem you're seeing without breaking your Emacs-style mappings (I could be wrong though, it's just a hunch).

    If you look in the Command-T source, specifically the MatchWindowclass, you'll see that inside the match window it sets the timeoutlen to 0 in order to make the keys respond immediately; my suspicion is that by setting notimeout you prevent the timeoutlen for having effect.

    If the suggested work around doesn't work for you we can look at other alternatives (Command-T, for example, could be patched to set timeout whenever the match window is displayed, and restore it to its previous value afterwards).

  7. guns

    Thanks for your help! I decided to just patch in the timeout setting for the match window just like you did for timeoutlen. Works perfectly, and seems like an appropriate addition.

    Thanks for your awesome plugin!

    From 5de1fb620f5a219217f960c13d5ae47aeec35721 Mon Sep 17 00:00:00 2001
    From: guns <sung@metablu.com>
    Date: Mon, 13 Sep 2010 15:16:50 -0500
    Subject: [PATCH] `set timeout' on match window creation and restore on close
    
    ---
     ruby/command-t/match_window.rb |    1 +
     ruby/command-t/settings.rb     |    2 ++
     2 files changed, 3 insertions(+), 0 deletions(-)
    
    diff --git a/ruby/command-t/match_window.rb b/ruby/command-t/match_window.rb
    index b5c10c9..eae0f87 100644
    --- a/ruby/command-t/match_window.rb
    +++ b/ruby/command-t/match_window.rb
    @@ -42,6 +42,7 @@ module CommandT
     
           # global settings (must manually save and restore)
           @settings = Settings.new
    +      ::VIM::set_option 'timeout'         # ensure mappings timeout
           ::VIM::set_option 'timeoutlen=0'    # respond immediately to mappings
           ::VIM::set_option 'nohlsearch'      # don't highlight search strings
           ::VIM::set_option 'noinsertmode'    # don't make Insert mode the default
    diff --git a/ruby/command-t/settings.rb b/ruby/command-t/settings.rb
    index 93af32f..c15016a 100644
    --- a/ruby/command-t/settings.rb
    +++ b/ruby/command-t/settings.rb
    @@ -33,6 +33,7 @@ module CommandT
           @report         = get_number 'report'
           @sidescroll     = get_number 'sidescroll'
           @sidescrolloff  = get_number 'sidescrolloff'
    +      @timeout        = get_bool 'timeout'
           @equalalways    = get_bool 'equalalways'
           @hlsearch       = get_bool 'hlsearch'
           @insertmode     = get_bool 'insertmode'
    @@ -44,6 +45,7 @@ module CommandT
           set_number 'report', @report
           set_number 'sidescroll', @sidescroll
           set_number 'sidescrolloff', @sidescrolloff
    +      set_bool 'timeout', @timeout
           set_bool 'equalalways', @equalalways
           set_bool 'hlsearch', @hlsearch
           set_bool 'insertmode', @insertmode
    -- 
    1.7.3.rc1.5.gd9b1
    
    
    
  8. Greg Hurrell

    Thanks for the patch. Looks sane enough. I can't really see any drawbacks to applying it, so will do so tomorrow.

  9. anonymous

    I run into this problem as well and discovered another bug. If you open the command-T and midstream decide to cancel (CTRL-C, i.e., not to open a file), the settings are never restored. Since the settings are saved and timeoutlen is changed to 0, after I cancel, my mappings don't work anymore (cuz the timeout len is still 0 and never restored to my original set value). Can you issue a patch for that? Thanks. Rick

  10. Greg Hurrell

    timeoutlen already is saved and restored (see the settings.rb file).

    Can you explain why or how it is not being restored?

Reply

This topic is now closed.