Cursor moves when blinking

[RobertAudi]

When I press n (or N), the cursor moves to the first column of the buffer (in the gutter, if it's visible, ie: line numbers or git gutter) and then when the blinking stops the cursor moves back to the first character of the next match.

The normal behavior would be that the cursor moves to the first character of the next match while the match is blinking.

[ivyl]

I could not reproduce that error. Could you give me some sample buffer content and key sequence?
I have relative line numbers on and cursor never jumps beyond match, I even installed gitgutter to test that.
Still could not reproduce. Neither in vim, nor gvim.

[RobertAudi]

@ivyl Sorry about the late response. I made a screencast showcasing the bug: http://youtu.be/miz_Ut8T4jk

[RobertAudi]

However it is very possible that the source of the problem is a collision with another plugin, or a piece of code in my vimrc. Here is my vimrc: https://gist.github.com/AzizLight/0b3d2d3916d28848e83c

(I know, it's huge and I use A LOT of plugins...)

[RobertAudi]

I discovered that the issue happens when redraw is called by the plugin.

[RobertAudi]

Ah! The problem only appears in MacVim. Works fine in terminal Vim...

[venam]

Good to know the problem is solved. You should have bumped saying what version you were using when ivyl said he tried to reproduce the bug in gvim and vim.

[RobertAudi]

@venam Sorry about that. here is the info about my MacVim (mvim --version)

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 29 2013 02:17:27)
MacOS X (unix) version
Included patches: 1-22
Compiled by Homebrew
Huge version with MacVim GUI.  Features included (+) or not (-):
+acl             +file_in_path    +mouse_sgr       +tag_binary
+arabic          +find_in_path    -mouse_sysmouse  +tag_old_static
+autocmd         +float           +mouse_urxvt     -tag_any_white
+balloon_eval    +folding         +mouse_xterm     +tcl
+browse          -footer          +multi_byte      +terminfo
++builtin_terms  +fork()          +multi_lang      +termresponse
+byte_offset     +fullscreen      -mzscheme        +textobjects
+cindent         -gettext         +netbeans_intg   +title
+clientserver    -hangul_input    +odbeditor       +toolbar
+clipboard       +iconv           +path_extra      +transparency
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python          +viminfo
+cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con_gui  -lua             +rightleft       +windows
+diff            +menu            +ruby            +writebackup
+digraphs        +mksession       +scrollbind      -X11
+dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     +xim
+emacs_tags      +mouseshape      -sniff           -xsmp
+eval            +mouse_dec       +startuptime     -xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
+farsi           +mouse_netterm   +syntax          
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1  
Linking: cc   -L.   -L.    -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon       -lncurses -liconv -framework Cocoa   -fstack-protector -L/usr/local/lib  -L/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc -framework Python  -F/System/Library/Frameworks -framework Tcl -framework CoreFoundation -framework Ruby   

I installed MacVim using Homebrew, but I also tried the latest snapshot (which didn't fix the
problem).

And sorry to say that, but the issue is not resolved; I am not sure this is a bug in MacVim (even if it
is very likely).

[silouanwright]

Now working for me inside of MacVim as well

[ivyl]

I'm very sorry but I have no way of reproducing it. I have only Linux PCs laying around. I even asked my friend with Vim on Windows to test for that behavior. Everything works for him too.

From your descriptions it seems like it's MacVim fault. MacVim have to handle redrawing differently than other UIs. I would dig through MacVim's source code to see what happens inside, but there's no point without having a way to test it (using debugger to peep what happens inside would be a nice thing).

You could try discussing the issue with with MacVim's maintainers. Just do redraw/sleep loop (since it should be smallest instance to reproduce the effect of bling) and present it to them.

Thank you all for your feedback!

I'll keep this ticket opened - I'm interested in outcome.

[RobertAudi]

Ok guys, it is confirmed, it's a bug in MacVim. It is fixed in the master branch of MacVim though. To install it from Homebrew do the following:

brew remove macvim
brew install macvim --HEAD
brew linkapps

And everything is working fine now!

[ivyl]

Glad my little plugin helped track a bug in MacVim.

Good work, @azizLIGHT

[RobertAudi]

Actually, the MacVim bug is not fixed in HEAD apparently. More info here for the people interested: https://groups.google.com/forum/#!topic/vim_mac/z-IBAFHbQak

I don't think this issue should be reopened though since it's not an issue with the plugin. However, I do think a notice should be added to the README until the bug is fixed.

/cc @ivyl