Problem with screen refresh

[surfmikko]

Syntastic noobie here, so firstly A big thank you for a great plugin! :)

For me the problem is that occasionally Syntastic causes edit window to corrupt. This happens when saving file and start typing before syntactic went trough checking and refreshing screen.

This can be reproduced by saving bigger file on slightly laggy virtual machine, when saving big enough file and immediately try navigating to line with "j" / "k". For example just press down "j" for a while and editing window gets garbled.

So after saving you can have one or two lines offset between in-memory buffer and what is displayed on screen. Then with fast fingers you jsut edit or delete the wrong line.

Garbled window gets redrawn fine with :redraw! or ^L.

I have tried altering the g:syntastic_full_redraws settings, but no change in behaviour.

---

let g:syntastic_python_pylint_args='-d W0232 -f parseable -r n -i y'

let g:syntastic_check_on_open=0 let g:syntastic_aggregate_errors=0

let g:syntastic_enable_highlighting = 0 let g:syntastic_echo_current_error=1

let g:syntastic_enable_balloons = 0 let g:syntastic_auto_jump=0

let g:syntastic_full_redraws=1

---

Centos 6.3:

$ vim --version VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Apr 5 2012 10:17:30) Included patches: 1-411 Modified by bugzilla@redhat.com Compiled by bugzilla@redhat.com Huge version without GUI. Features included (+) or not (-): +arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent -clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse -mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme -netbeans_intg -osfiletype +path_extra +perl +postscript +printer +profile +python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard -xterm_save system vimrc file: "/etc/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" fall-back for $VIM: "/usr/share/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -g -pipe -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=1 -D_REENTRANT -D_GNU_SOURCE -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib64/perl5/CORE -I/usr/include/python2.6 -pthread
Linking: gcc -Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE -L/usr/local/lib -o vim -lselinux -lncurses -lacl -lgpm -Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE -fstack-protector -L/usr/lib64/perl5/CORE -lperl -lresolv -lutil -lc -L/usr/lib64/python2.6/config -lpython2.6 -lutil -lm -Xlinker -export-dynamic

[lcd047]

This is more of a Vim problem than a syntastic poblem. Syntastic calls redraw (or redraw!) at the right moment; if it leaves garbage behind, then either Vim or the ncurses backend doesn't do its part of the job. As far as I can tell, there isn't much elase that can be done in syntastic to change that behaviour. shrug

On a side note, the default value for syntastic_full_redraws is 1 in non-GUI Vim, so if you want to play with knobs you might try turning it off, rather than on.

$ vim --version VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Apr 5 2012 10:17:30) Included patches: 1-411

Upgrading Vim might help. More than 1000 patches have ben released since 7.2.411...

[surfmikko]

Ok, thanks! Some things just ain't perfect.. not even Vim. I have same issue with default OSX version:

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 16 2012 15:12:57)

I tried writing similar effect plugin named "slow save". Here it seems that "sleep" command captures any input, and after that redraw works just fine.

Would that also be possible for whole plugin? Would it be possible to call redraw a bit later?

---

if exists("g:loaded_slowsave") finish endif let g:loaded_slowsave = 1

let s:save_cpo = &cpo set cpo&vim

autocmd BufWritePost * call s:UpdateErrors()

function! s:UpdateErrors() echo "Sleeping for a second..." sleep 1 redraw endfunction

let &cpo = s:save_cpo

[lcd047]

Vim 7.3 is still 1000+ patches behind 7.4.

The difference between your plugin and syntastic is that in the case of syntastic Vim saves a "context" before running an external command, then restores it when the command finishes. Perhaps surprisingly, that's handled by a really hairy piece of code. I'm actually surprised there aren't more people seeing redraw problems at that particular point. :)

Also Vim doesn't have a mechanism for running async commands. There is currently a (long) discussion going on in vim_dev about a patch adding timed events, but that still has a long way to go before being adopted in the main Vim.

I'm afraid your best bet is to upgrade Vim to 7.4, and, if the problem still persists, find a simple scenario that reproduces it, and get it fixed in Vim. There is no reasonable fix for it in syntastic, sorry.

[myint]

Just for reference, I see this in Vim 7.4.

$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 10 2013 15:29:35)
MacOS X (unix) version
Included patches: 1-52
Compiled by myint@macbookpro.local
Huge version without GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
-balloon_eval    +float           +mouse_urxvt     -tag_any_white
-browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
-clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      -toolbar
+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      -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
   system vimrc file: "/opt/local/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/opt/local/share/vim"
Compilation: /usr/bin/gcc-4.2 -c -I. -Iproto -DHAVE_CONFIG_H   -I/opt/local/include -DMACOS_X_UNIX -no-cpp-precomp  -pipe -Os -arch x86_64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: /usr/bin/gcc-4.2   -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -L/usr/local/lib -o vim        -lm  -lncurses -liconv -lintl -framework Cocoa     -L/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/config-3.3m -lintl -framework CoreFoundation -lpython3.3m

[lcd047]

@myint This looks like a bug in ncurses, or perhaps a bug in termcap / terminfo. Syntastic has exactly zero control on that kind of details.

[msabramo]

A similar issue with vim 7.4 where syntastic with active checking can mess up the terminal if you type too fast:

https://github.com/scrooloose/syntastic/issues/1068

[airblade]

Syntastic calls redraw (or redraw!) at the right moment

@lcd047 Please could you explain when the right moment is? (I ask because a plugin of mine occasionally exhibits screen-garbling in terminal vim.) I can't find any info in vim's help or on the web. Also when should one use redraw and when redraw!?

Thanks in advance!

[lcd047]

I can explain when is the right moment to call redraw in syntastic: when the text shown on the command line changes (that is, when you have syntastic_echo_current_error set, and you move the cursor up and down). This is mentioned in Vim's help: try :help :echo-redraw. And the difference between redraw and redraw! is that the latter clears the screen before redraw, while the former doesn't.

I wouldn't venture to make a statement about the right moment to call redraw in general. There are too many layers involved. In theory, the only situation when you should care about such things is the one described above: when you echo things to the command line window; everything else should be handled automatically by Vim, the curses library, terminfo / termcap, and the terminal / window manager itself. In practice it doesn't work quite like that, because of quirks in terminal capabilities, missing or bad terminfo / termcap entries, and bugs. That's the main reason why redraw! exists besides redraw in the first place. Syntastic uses a simple heuristic: terminal Vim uses redraw!, GUI Vim uses redraw, essentially because window managers are smarter than terminals.

Now, if you get screen garble in terminal Vim, that's almost always a bug outside your code. It's a major pain in the rear to find out exactly which component is responsible for it, and, once you get it figgured out, it's an even bigger pain to fix. Sometimes you can work around it in your code; most of the time you can't, and you're likely to waste inordinate amounts of time proving to yourself that you can't. Personally, I'd rather spend my time in more useful ways, especially when the problem is in a project I'm maintaining purely for fun, such as syntastic. Other people (f.i. @Valloric, of YCM fame) take the opposite view, that you should workaround in your code any bugs users may encounter, and are likely to conclude I'm an arsehole for refusing to go there. Life happens. :)

[Valloric]

@lcd047 I don't think you're an arsehole, you just have different priorities than I do. I respect that.

[airblade]

@lcd047 That's very useful information. Thank you very much for taking the time to explain it. Much appreciated!

[sharipov-ru]

did anyone find a workaround for that?

[msabramo]

I turn off syntactic in terminal mode vim. I tend to use terminal mode vim for quick edits and don't need the syntax checking. For a longer session I'll use GUI vim or an IDE.

[myint]

@sharipov-ru, I resort manual to redraws when this happens via control-l.

[lcd047]

@sharipov-ru Try other versions of Vim, other terminal programs, other versions of the curses library, other settings of TERM.

If you have enough time on your hands you might try debugging it. Run something like this to capture Vim's output:

vim some_file | tee some_other_file

Vim will complain about output note being a terminal, but it will work. Then you can locate the offending escape sequence in some_other_file, and look it up in termcap or (depending on your Vim) in the relevant terminfo entry. Once you have a termcap / terminfo name for the escape sequence, you can try looking it up in Vim sources, the curses library, or whatever other software is involved.

[nmschulte-aviture]

Drat! I just started using Syntastic (and a whole slew of other nice plugins, finally), and I'm running into this issue left and right! My fingers and habits are just too fast for this, I suppose. To be clear, I'm running into redraw issues due to typing immediately after a save, as the OP describes.

(this is Vim from Debian Sid):

$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jun 13 2015 05:48:14)
Included patches: 1-712
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by buildd@
Huge version without GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
-balloon_eval    +float           +mouse_urxvt     -tag_any_white
-browse          +folding         +mouse_xterm     +tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
-clientserver    -hangul_input    +netbeans_intg   +title
-clipboard       +iconv           +path_extra      -toolbar
+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      +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
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/usr/include/tcl8.6  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_LARGEFILE64_SOURCE=1  
Linking: gcc   -L. -Wl,-z,relro -L/build/ruby2.1-_39Jjj/ruby2.1-2.1.5/debian/lib -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E  -fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim        -lm -ltinfo -lnsl  -lselinux  -lacl -lattr -lgpm -ldl  -L/usr/lib -llua5.2 -Wl,-E  -fstack-protector -L/usr/local/lib  -L/usr/lib/x86_64-linux-gnu/perl/5.20/CORE -lperl -ldl -lm -lpthread -lcrypt -L/usr/lib/python2.7/config-x86_64-linux-gnu -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions  -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -ldl -lz -lpthread -lieee -lm -lruby-2.1 -lpthread -lgmp -ldl -lcrypt -lm    

[lcd047]

@nmschulte-aviture I'm afraid the situation hasn't changed in the mean time. Sorry about that. Syntastic still has no control over any of the above. Not sure what else I could tell you.

[nmschulte-aviture]

@lcd047, understood entirely. I was more posting here that a more recent of Vim/stack still has not resolved the issue for posterity and others' info. Being more deliberate with my saving, as well as the hint about CTRL+L for redraw, is my solution.

[msabramo]

Another possibility is to use the GUI vim instead of a terminal one. Could even modify your vimrc so that it only activates syntastic when in GUI mode.

[manishtoons]

same issue with me, hitting Ctrl+L is correcting the buffer's visual issue

[lcd047]

@manishtoons Same solution for you then: reporting the issue upstream might help, for suitable values of "upstream". shrug

[motizuki]

I had this issue using Vim 7.4+ with vim-tmux-navigator plugin. By pressing , (to move to the tmux pane below) while syntastic is scanning a file the window gets garbled. In order to solve this issue (nasty workaround), I've chained a redraw in the tmuxnavigatedown binding like that: nnoremap <silent> <c-j> :TmuxNavigateDown<cr>:redraw!<cr> Cheers,

[opendevnet]

For posterity if anyone else is trying to solve this frustrating issue (decades of typing ctrl+l don't make it more pleasant) I used autocommand and bound :redaw!to as many events and file types as I could in order to force a "fix".

It probably slowed things down a bit, but the machine had 16 cores and 64G of RAM so I didn't notice. I began narrowing down the events that triggered the screen scrambling (QuickFixCmd was notorious) but never seriously debugged this; there is some good advice on how to do that in this thread.

Using the :au command's "events" subsystem was just a way to overcome what seemed to be some kind of timing issue for screen redrawing (alluded to in https://github.com/scrooloose/syntastic/issues/699) but one which probably lives deeper down in ncurses or terminfo.

Thanks for Syntastic.

"  force  a :redraw! on "events" that scramble the screen with
"  syntax highlighting enabled.

set ttyfast
au FileWritePost * :redraw!
au TermResponse * :redraw!
au TextChanged * :redraw!
au QuickFixCmdPre * :redraw!
au QuickFixCmdPost * :redraw!

[lcd047]

@opendevnet

Using the :au command's "events" subsystem was just a way to overcome what seemed to be some kind of timing issue for screen redrawing

No. That was your way of brute forcing around the fact that the order of execution of autocmds is not well-defined. So some of your redraw!s are actually run before the events they are supposed to fix. :smile:

This is such a waste of time and energy. Here's a more rational approach:

1. If you're having redraw problems in gVim, report them to vim_dev.
2. If you're having redraw problems in terminal Vim running in any other terminal than xterm, try to reproduce them with (a recent version of) plain xterm. If you can't, then report the problems to the developers of your fancy terminal.
3. If you're having redraw problems in terminal Vim running in xterm then report them to the maintainers of your distribution, as they most likely have messed up your termcap / terminfo.

Try this before spending your time brute-forcing redraw. It isn't a complete algorithm, but IMO it does cover the most common causes.

[dhinus]

@motizuki good workaround. I had to modify it slightly to include it in my .vimrc:

autocmd VimEnter * nnoremap <silent> <c-j> :TmuxNavigateDown<cr>:redraw!<cr>

Without autocmd VimEnter *, the custom mapping was overwritten by the default mapping included in the vim-tmux-navigator plugin, as plugins are loaded after the .vimrc file.

[niloct]

@opendevnet

Using the :au command's "events" subsystem was just a way to overcome what seemed to be some kind of timing issue for screen redrawing

No. That was your way of brute forcing around the fact that the order of execution of autocmds is not well-defined. So some of your redraw!s are actually run before the events they are supposed to fix. 😄

This is such a waste of time and energy. Here's a more rational approach:

1. If you're having redraw problems in gVim, report them to vim_dev.
2. If you're having redraw problems in terminal Vim running in any other terminal than xterm, try to reproduce them with (a recent version of) plain xterm. If you can't, then report the problems to the developers of your fancy terminal.
3. If you're having redraw problems in terminal Vim running in xterm then report them to the maintainers of your distribution, as they most likely have messed up your termcap / terminfo.

Try this before spending your time brute-forcing redraw. It isn't a complete algorithm, but IMO it does cover the most common causes.

I can confirm that syntastic has the issue on this thread, when vim is running inside a docker container. Thanks for your checklist \o/