E315: ml_get: invalid lnum: 32 #112
Comments
|
That's an error I've never seen. Mind sharing some more info about your OS, lua version, and vim version (macvim, vim-gtk, vim-qt, terminal, etc) |
|
Here is my vim --version output, used on ubuntu 15.10 x86_64 To reproduce i need just open 2 or more files and fast switch buffers between them (bind :bnext on C-tab or somewhere else). A few switches is enough. Maybe it has something to do with redrawing buffer content with highlighting? Does vim redraw in on every switch? It's just an ideda, but why else buffer switching will have something to do with color_coded? |
|
Hello! I experience this issue as well (editing 5 c files and switching between them with :bn or :bp): Environment: |
|
Yes, the number after |
|
Hey guys! The same issue happens to me from time to time on both Mac and Linux. I'm using the latest version of vim and lua from homebrew with default options on OSX 10.11.3. I guess there might be a conflict with one of my other plugins and I'm still digging into it. The following is a list of my installed plugins. May this be helpful to you. Plugin 'VundleVim/Vundle.vim'
Plugin 'mileszs/ack.vim'
Plugin 'jeaye/color_coded'
Plugin 'tacahiroy/ctrlp-funky'
Plugin 'ctrlpvim/ctrlp.vim'
Plugin 'rust-lang/rust.vim'
Plugin 'scrooloose/syntastic'
Plugin 'majutsushi/tagbar'
Plugin 'solarnz/thrift.vim'
Plugin 'SirVer/ultisnips'
Plugin 'mbbill/undotree'
Plugin 'vim-airline/vim-airline'
Plugin 'vim-airline/vim-airline-themes'
Plugin 'altercation/vim-colors-solarized'
Plugin 'Lokaltog/vim-easymotion'
Plugin 'tpope/vim-fugitive'
Plugin 'airblade/vim-gitgutter'
Plugin 'fisadev/vim-isort'
Plugin 'lervag/vim-latex'
Plugin 'terryma/vim-multiple-cursors'
Plugin 'hynek/vim-python-pep8-indent'
Plugin 'honza/vim-snippets'
Plugin 'tpope/vim-surround'
Plugin 'rdnetto/YCM-Generator'
Plugin 'Valloric/YouCompleteMe' |
|
Actually i tryed disabling ALL plugins, except NeoBundle and color_coded, and i still had this issue, so it's somewhere inside colorcoded. I'll be happy to provide more debugging info, just tell me how to do it, or what to check. |
|
I confirm this issue too. Ubuntu 15.10 amd64, newest vim from git repo, tryid disabling all plugins except color_coded and the problem is still there. It must be somewhere in |
|
According to the vim help, E315 is an internal vim error. I am unable to reproduce the error on my machine with my slightly older vim (Patches 1-1229). Maybe the bug was introduced recently? |
I don't think so. The reason I even started to build vim from source was this issue. So at least i had it in ubuntu 15.10 official vim from dist repo, i thought it will go away with newer vim but that never happend. And yes, it is vim's internal error, but it happens only if color_coded enabled, if I disable it even with |
|
I think I've located it. I have the following two lines in my set foldmethod=syntax
set foldlevel=99 |
I don't have this or any other folding settings in my vimrc, but still having an issue, maybe you had some another settings, that helped? Anyone can confirm solving problem by this? I even tryed disabling folding by |
|
@alientechnology |
|
@richardtsai, yes, I do have |
|
works fine: set hidden
" set foldmethod=syntax
" set foldlevel=99works, but quite slow when jumping between buffers: " set hidden
set foldmethod=syntax
set foldlevel=99gets errors occasionally: set hidden
set foldmethod=syntax
set foldlevel=99 |
|
Thanks for working on this, guys. You mentioned folding is quite slow when switching buffers. In general, it will be slow when moving or typing, since Vim doesn't offer a good way to know if any given line is within a closed or open fold; it requires looking at every fold to determine where the line lies and whether or not that fold is open. As a result, color_coded adds highlighting for any collapsed folds within the current buffer; combined with Vim's awfully slow highlighting, this can drastically slow down Vim as a whole. There's not much I can do about that though. As for this issue, I'm not yet sure if it's a Vim bug that color_coded is causing or some malpractice within color_coded that only shows up with these settings. |
|
@richardtsai, interesting, disabling |
|
@alientechnology you can leave |
|
@richardtsai that's what I just did, but didn't find anything, for now i think i have to leave without |
|
Have you guys seen https://github.com/critiqjo/lldb.nvim/issues/20? |
|
@jeaye yeah, I saw this, when i googled our the error I got, but it's neovim, I don't know if it is related to our situatuion, anyway it dosen't look like they have any solutions for now. Maybe it should be addressed to vim developers too, but for this we need to know what at least viml or lua call creates this problem. I can't be shure, but it looks like I see this error mostly when I'm trying to swich from not saved buffer, maybe that's why |
|
No, as i found later it has nothing to do with buffer being saved or not. I tried to run And when there is no error, it's just So maybe it has something to do with |
|
I ran into this E315 ml_get error too. Disabling either color_coded or the built-in matchparen.vim (enabled by default) seems to be able to avoid the error. However, so far I can't find reliable ways to reproduce the bug. Hence, when I said "avoid the error", it might well be that the bug was still there but hadn't come up yet. This is really a bizarre error and it seems to come from somewhere internal to vim. After a quick Google, apart from here in color_coded, this error has been reported in at least the following contexts:
|
|
Well for me reproducing is really easy. Open 3-4 buffers, do some |
|
When switching buffers, vim will start highlighting the new buffer. Internally, vim holds a pointer to the buffer it wants to highlight as a global variable. Sometimes the pointer will not get updated. Vim then tries to iterate over the old buffer using the line count of the new buffer. Does anyone want to try out this patch and see if this fixes it for them? diff --git a/src/syntax.c b/src/syntax.c
index e37dacb..16dcb99 100644
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -509,7 +509,7 @@ syntax_start(win_T *wp, linenr_T lnum)
* Also do this when a change was made, the current state may be invalid
* then.
*/
- if (syn_block != wp->w_s || changedtick != syn_buf->b_changedtick)
+ if (syn_block != wp->w_s || changedtick != syn_buf->b_changedtick || wp->w_buffer != syn_buf)
{
invalidate_current_state();
syn_buf = wp->w_buffer;Tried with the newest git commit 014069a7ac51557e531eb3c8b94e36f2193f6c21 |
|
@UnrealQuester I just tried your patch with same newest commit, and I couldn't reproduce this problem anymore, so looks like it helps. I will do more testing tomorrow, but basicly before this patch i got |
|
@alientechnology Thank you for confirming that the fix works, your help is highly appreciated. I will open up a PR for that. But first I need to look into the issue a bit more. git blame tells me that the check was there in 2010 but got removed with the conceal patch. This migth be just a workaround for a different issue higher up the call chain. |
|
@UnrealQuester at least what I can see, conceal still works, i use some stuff like |
|
The patch was merged into the current vim master as patch 1691. Can anyone confirm that the bug is now fixed with the latest version of vim? @jeaye Do you think we should add a FAQ entry or something for this? |
|
@UnrealQuester I confirm. Just built vim 1691 from git, and our problem isn't there anymore. |
|
@UnrealQuester Yep, I think a FAQ entry would be good. |
When I open a few C files in gvim, and switch between different buffers few times, after a little bit i'm getting this error and syntax coloring breaks. If I reopen the file, syntax coloring goes back, but after a few buffer switching i'm getting the same problem.
:CCerrorsays there is no error, unfortunatly I don't know how to get more debug information for this case, E315 as I know it vim's internal error, but if i disable color coded even by:CCtogglethe error goes away. I use vim compiled from git, let me know if I can provide any more useful information. This always reopening a file is pretty annoying.The text was updated successfully, but these errors were encountered: