vim/YouCompleteMe
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Auto merge of #2645 - micbou:drop-bufread-event, r=Valloric

Browse Source 
[READY] Drop BufRead event

Since [we don't parse the buffer if no filetype is set](ad00f4c3f4/autoload/youcompleteme.vim (L334)), calling `s:OnBufferRead` on the `BufRead` event is only useful if the buffer filetype is set. But if that's the case, this means that the `FileType` event was fired before the `BufRead` one and thus the `s:OnBufferRead` function is already called. So, there is no point in calling `s:OnBufferRead` on the `BufRead` event. In fact, this costs us a `BufferVisit` and a `FileReadyToParse` request for nothing.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2645)
<!-- Reviewable:end -->
This commit is contained in:
zzbot 2017-05-14 13:44:24 -07:00 committed by GitHub
commit 9448748e80
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
autoload/youcompleteme.vim
View File

@ -85,12 +85,12 @@ function! youcompleteme#Enable()
" Note that these events will NOT trigger for the file vim is started with; " Note that these events will NOT trigger for the file vim is started with;
" so if you do "vim foo.cc", these events will not trigger when that buffer " so if you do "vim foo.cc", these events will not trigger when that buffer
" is read. This is because youcompleteme#Enable() is called on VimEnter and " is read. This is because youcompleteme#Enable() is called on VimEnter and
" that happens *after* BufRead/FileType has already triggered for the " that happens *after* FileType has already triggered for the initial file.
" initial file. " We don't parse the buffer on the BufRead event since it would only be
" We also need to trigger buf init code on the FileType event because when " useful if the buffer filetype is set (we ignore the buffer if there is no
" the user does :enew and then :set ft=something, we need to run buf init " filetype) and if so, the FileType event has triggered before and thus the
" code again. " buffer is already parsed.
autocmd BufRead,FileType * call s:OnBufferRead() autocmd FileType * call s:OnFileTypeSet()
autocmd BufEnter * call s:OnBufferEnter() autocmd BufEnter * call s:OnBufferEnter()
autocmd BufUnload * call s:OnBufferUnload() autocmd BufUnload * call s:OnBufferUnload()
autocmd CursorHold,CursorHoldI * call s:OnCursorHold() autocmd CursorHold,CursorHoldI * call s:OnCursorHold()
@ -100,10 +100,10 @@ function! youcompleteme#Enable()
autocmd CompleteDone * call s:OnCompleteDone() autocmd CompleteDone * call s:OnCompleteDone()
augroup END augroup END
" BufRead/FileType events are not triggered for the first loaded file. " The FileType event is not triggered for the first loaded file. However, we
" However, we don't directly call the s:OnBufferRead function because it " don't directly call the s:OnFileTypeSet function because it would send
" would send requests that can't succeed as the server is not ready yet and " requests that can't succeed as the server is not ready yet and would slow
" would slow down startup. " down startup.
if s:AllowedToCompleteInCurrentBuffer() if s:AllowedToCompleteInCurrentBuffer()
call s:SetCompleteFunc() call s:SetCompleteFunc()
endif endif
@ -414,7 +414,7 @@ function! s:OnCompleteDone()
endfunction endfunction
function! s:OnBufferRead() function! s:OnFileTypeSet()
if !s:AllowedToCompleteInCurrentBuffer() if !s:AllowedToCompleteInCurrentBuffer()
return return
endif endif