cursor cannot move to the error position from location list.

[yuga]

I use vim in terminal. After 0bef7ef3f6 commit, I cannot move cursor to the error position from location list with enter key. Vim reports the error "E92: Buffer not found".

[lcd047]

Please explain what did you do, what did you expect to happen, and what happens instead.

[yuga]

Sorry for that.

1. Open a simple shell script file to edit: $ vim test.sh
2. Write brah brah into the file.
3. Save the buffer, which contains some mistakes.
4. The buffer is written in the file, then checker detect errors and syntastic opens location list to show that.
5. In this time, the saved buffer still keep cursor.
6. Input <C-w><C-w> to move cursor into the location list.
7. Choose an error line like the below: test.sh|21 col 6 warning| Double quote to prevent globbing and word splitting. [SC2086]

• expected: The cursor will move into the buffer that shows test.sh. Its position will be line 21 col 6.
• actual: The cursor moves into the buffer. However its position is same to before moving to location list. And, vim reports the error message like the below: E92: Buffer 1718187119 not found

in my .vimrc

let g:syntastic_enable_signs=1
let g:syntastic_auto_loc_list=1
let g:syntastic_loc_list_height=5
let g:syntastic_java_javac_config_file_enabled=1
set statusline+=%#warningmsg#
set statusline+=%{SyntasticStatuslineFlag()}
set statusline+=%*

If doing SyntasticCheck instead of saving buffer, this issue does not occur. I use neobundle to load syntasitc, and also use many other plugins. So, this issue may be caused not only by syntastic.

Thanks.

[lcd047]

I can't reproduce the problem here (that is, the cursor moves as expected in your scenario). Still, commit 0bef7ef is a pretty far-reaching change, so it would be nice to understand what's going on.

Can you reproduce the problem if you disable all plugins except syntastic? Does the problem go away with this patch?

[yuga]

I would like to try in this weekend.

[yuga]

I can reproduce this problem even if all other plugins are disabled. It is also the same on the vim to which your patch is applied.

I created a bare vim environment by means of the following steps:

$ cd ~
$ mv .vim .vim.old
$ mv .vimrc. .vimrc.old
$ git clone [email protected]:scrooloose/syntastic.git .vim
$ cat > .vimrc <<EOS
filetype plugin on
let g:syntastic_enable_signs=1
let g:syntastic_auto_loc_list=1
let g:syntastic_loc_list_height=5
let g:syntastic_java_javac_config_file_enabled=1
EOS

This is my vim version:

$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jun 20 2014 03:13:00)
Included patches: 1-335
Modified by [email protected]
Compiled by jamessan@
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 -fstack-protector --param=ssp-buffer-size=4 -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-R1fHdQ/ruby2.1-2.1.2/debian/lib -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E  -Wl,-z,relro -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/perl/5.18/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]

Thank you, I can reproduce it now, I also got a segfault from it. I'll try to understand what's going on, and perhaps come up with a fix.

[lcd047]

Does the problem go away if you set g:syntastic_reuse_loc_lists to 0 before running the checker?

[yuga]

Yes. Cursor moves to the expected position with no errors.

[lcd047]

I'm pretty confident this is mainly caused by a bug in Vim. It may or may not also be caused by a bug in syntastic, but the root problem is a buffer overrun in Vim. It isn't really related to 0bef7ef, that commit just made the problem apparent.

I'm afraid I don't have any solution for it yet. I'll try to solve the bug in Vim, but the context is pretty complicated, and the relevant piece of code is not particularly well written. In the mean time, you can set g:syntastic_reuse_loc_lists to 0 as a workaround, but that's wasteful, and by no means a real fix. Sorry about that.

[lcd047]

For reference: my report at vim_dev.

[lcd047]

There doesn't seem to be any fix in sight for the problem. Setting g:syntastic_reuse_loc_lists to 0 is safe, so I did that in c1479f9.

[amadeus]

It looks like your patch may be merged in to mainline Vim!

[lcd047]

My patch in 7.4.379 solves a different, unrelated problem.

[amadeus]

Ahh ok.

[blueyed]

I am seeing a similar problem, although I have g:syntastic_reuse_loc_lists=0.

The location list displays the warnings (subtype=Style), but I get E42: No Errors when pressing Enter on one of them.

Using :lolder fixes it: it displays list 5/6 then, which seems to be the actual list (but the contents of the location list window does not change), and errors can be accessed.

After :lnewer (to list 6/6), an empty list is displayed, and when moving out of the window, the contents gets updated with the non-accessible errors/list again!

This is with the scss_linter checker.

I am using g:syntastic_auto_loc_list=1, the problem does not exist with the default (g:syntastic_auto_loc_list=2).

[blueyed]

I could bisect my issue from the comment above to 4c888855:

commit 4c888855d650581bd78c83902d8d58f9b518b67c
Author: LCD 47 <[email protected]>
Date:   Fri Jun 7 00:34:05 2013 +0300

    Sets the status line of the location window.

    Shows the command used to produce the error list on the status line of
    the location window.  Also fixed a (harmless) refresh bug.

(having set g:syntastic_reuse_loc_lists=0 in ~/.vimrc)

[blueyed]

It is caused by this bug in Vim (has a patch): https://groups.google.com/d/msg/vim_dev/WmuoFum2Lq4/w3UiiS9Wj2kJ

[lcd047]

@blueyed This might be a related bug (I can't really tell), but your patch doesn't solve the initial problem.

[blueyed]

Ok, would have been nice. Sorry for the noise.

Does :lolder fix / work around the initial issue maybe?

(The Vim bug is triggered by Syntastic's setwinvar (https://github.com/scrooloose/syntastic/commit/4c888855d650581bd78c83902d8d58f9b518b67c#diff-aa8064af5cca6d53758402972a41e913R160), and causes the issue in Syntastic in my setup. Since autocommands do not work as expected anymore (they are not properly blocked in certain situations), this can cause all kind of weird issues, like the E42 I was seeing.)

[lcd047]

Does :lolder fix / work around the initial issue maybe?

No.

[lkraav]

I'm also not getting vim to go to the error line from location window. It switches focus back to code buffer, but the cursor does not move from the previous location. g:syntastic_reuse_loc_lists=0 doesn't make a difference. Running vim 7.4.591. I can't tell from the discussion, is there a workaround?

[lcd047]

The workaround is to set g:syntastic_reuse_loc_lists to 0, but that has been the default for a while, and you're the first to report it again after that. Are you sure you don't have any other plugins and / or mapping that interfere with syntastic? That is, do you still see the problem if you disable all other plugins, and run :.ll to go to the error line from the loclist window rather than pressing Enter?

[lkraav]

Thank you sir for taking the time to educate me, that ":.ll" trick was great for verification. The problem was

nnoremap <cr> <c-w>w

How do I keep that rule in place while also having location list work correctly? Makes it easy to zip around splits.

The open status of this bug confused me a bit, because it made me think Syntastic may be at fault.

[amadeus]

@lkraav I use something like this to move around splits, which I find pretty intuitive

noremap <c-j> <c-w>j
noremap <c-k> <c-w>k
noremap <c-h> <c-w>h
noremap <c-l> <c-w>l

[lcd047]

How do I keep that rule in place while also having location list work correctly?

The quickfix buffer has filetype qf, you might try remapping <cr> from a ftplugin.

The open status of this bug confused me a bit, because it made me think Syntastic may be at fault.

It's still unresolved, and, while unlikely, the root cause could still be within syntastic. shrug

[fatih]

Btw, while working on https://github.com/fatih/vim-go/pull/607 I also came to the same issue. The problem I've found was opening the location list twice. I had an au event which would open the location list automatically. When I was on the file the action was executed, there was two lwindow commands that would fire, once from the actual command and one from the autocmd. Suddenly :ll and many other commands just failed. Eventually I've removed the autocmd and right now I'm only calling lwindow once. This seems to fix my problem. Fyi.

[lcd047]

@fatih If you have a fix for the problem described above for syntastic, please post a PR.

[fatih]

@lcd047 unfortunately i don't have any, I just wanted to share my thoughts about a situation that resembles the same problem I've encountered (combination of autocmd and therefore executing lwindow twice). If I find something I'll definitely let you know.

[wsdjeg]

i can not reproduce this in javac checker,and it works well

[lcd047]

Attempted fix: 7e986f1. There be dragons that way, so please test carefully and report any problem. "Interesting" cases are those with multiple windows; look for loclists out of synch with the main file. Perhaps also expect segfaults (but I think I understand now the root cause for that).