Slight flicker due to unnecessary re-parse.

[crashmaster]

Hello!

I've read the FAQ point about this issue, I have the latest versions both from YCM and syntastic (yes, I'm using that as well).
I still experience slight flicker every time when moving the cursor after the update time (2s) is up.

Wouldn't it be a good approach to update (recompile) only, when there were changes in the actual file?
And for that using this vim mechanism:

b:changedtick
The total number of changes to the current buffer.
It is incremented for each change.
An undo command is also a change in this case.
This can be used to perform an action only when the buffer has changed.
Example:
  :if my_changedtick != b:changedtick                                                  
  :   let my_changedtick = b:changedtick                                               
  :   call My_Update()
  :endif

According my quick'n'dirty changes it works, I only had issues with multiple buffers (somehow the newly opened buffer's last_change variable was not initialized, weird), anyway I guess it was because of my lack of vim scripting knowledge...

What is your opinion about this?

Thanks a lot, and YCM is an awesome tool!

uname -a:

% uname -a
Linux aaa 3.8.13-gentoo #3 SMP Tue Jun 18 09:48:31 CEST 2013 x86_64 AMD Phenom(tm) II X4 945 Processor AuthenticAMD GNU/Linux

Vim version:

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jun 17 2013 18:49:09)
Included patches: 1-1214
Modified by Gentoo-9999
Huge version without GUI.  Features included (+) or not (-):
+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    
+farsi           +mouse_netterm   +syntax          
   system vimrc file: "/etc/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: x86_64-pc-linux-gnu-gcc -c -I. -Iproto -DHAVE_CONFIG_H     -march=amdfam10 -O2 -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linking: x86_64-pc-linux-gnu-gcc   -Wl,-E  -Wl,-O1 -Wl,--as-needed -L/usr/local/lib -Wl,--as-needed -o vim        -lm -lncurses -lelf -lnsl   -lacl -lattr -lgpm -ldl   -Wl,-E -Wl,-O1 -Wl,--as-needed  -L/usr/lib64/perl5/5.12.4/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lc -L/usr/lib64/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic      

[vheon]

It's not related to the issue, but since b:changedtick was mentioned: @Valloric have you considered using b:changedtick inside s:BufferTextChangedSinceLastMoveInInsertMode() instead of checking the lenght of the line? I wanted to try it myself but if you already reject this solution I will not waste time.

[Valloric]

I have to admit I was unaware of the existence of b:changedtick. Sounds like something YCM should be using.

[vheon]

I knew b:changedtick from looking at vim-repeat's code, don't know if could be of any help for see it in action

[Valloric]

I've already changed s:BufferTextChangedSinceLastMoveInInsertMode() to use it on my machine but I'm still testing it.

[Valloric]

I've pushed a commit to the dev branch that only forces a file parse when the buffer is changed. I'm also using the b:changedtick var for s:BufferTextChangedSinceLastMoveInInsertMode(). I'd appreciate you guys testing it out.

@crashmaster These two changes will probably not resolve your problem which is not caused by the reparse on CursorHold but by the diagnostic update (see s:UpdateDiagnosticNotifications()) that also runs on CursorHold. I can't call that function only when the file has been changed because that function extracts diagnostic data from a previous compilation call that was triggered in the past.

To resolve your flickering issue, you have two options:

1. Update to latest upstream Syntastic (NOT the copy from vim.org, the copy from the github repo).
2. Use gvim instead of console vim.

I never get the flicker issue with latest Syntastic in gvim or console vim, so one or the other should fix this for you.

[vheon]

I just switch to the dev branch (and btw if vundle could handle branch would be much better but apparently they don't give a damn ) and I dont know if this behavior is wanted since I was experience the same on my local branch when I was trying the b:changedtick feature: if I am in a test.c file like this:

void function_name()
{
    struct test_t t = {{.i = 5}};
    struct test_t i = {{.c = '4'}};

        stru
/*       ^^^        */ 

    printf("%p\n", &t);
    printf("%p\n", &i);
}

after the st YCM offers me a bunch of suggestion, after the str just a few and after the stru just struct. When I was on the master branch if I moved the cursor back with the arrow the PopUp menu disappeared, but in the dev branch (like it does in mine) when I move the cursor back it shows me the suggestion for str and then the suggestion for st. The real problem with this is that if I move back and then select a suggestion the rest of the word after the cursor still remain. If it wasn't for that you could call it a feature.

I don't know if I explained myself well :(

[Valloric]

@vheon Thanks for testing it out.

I noticed this myself and it's shitty. I'm reverting the implementation of s:BufferTextChangedSinceLastMoveInInsertMode() to the old version since it didn't have the problem.

The reason why b:changedtick is being changed in that instance is because of the feedkeys() call in s:InvokeCompletion() and there's no going around that.

[vheon]

@Valloric I suspected about feedkeys(), too bad :( Does it influence s:OnFileReadyToParse too?

[Valloric]

@vheon No, the s:OnFileReadyToParse changes are good.

[crashmaster]

@Valloric
I've just checked out the changes in s:OnFileReadyToParse().
As far as I can tell, it is working good, and this is exactly, what I wanted (no reparse on movement, when stopping here and there for a while).
With reverting the changes in s:BufferTextChangedSinceLastMoveInInsertMode(), the b:ycm_changedtick.insert_mode_move is superfluous I guess.

Thanks a lot and greetings!