-
Notifications
You must be signed in to change notification settings - Fork 1.1k
cursor cannot move to the error position from location list. #1127
Comments
Please explain what did you do, what did you expect to happen, and what happens instead. |
Sorry for that.
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. Thanks. |
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? |
I would like to try in this weekend. |
I can reproduce this problem even if all other plugins are disabled. I created a bare vim environment by means of the following steps: $ cd ~ $ mv .vim .vim.old $ mv .vimrc. .vimrc.old $ git clone git@github.com: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 pkg-vim-maintainers@lists.alioth.debian.org 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 |
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. |
Does the problem go away if you set |
Yes. Cursor moves to the expected position with no errors. |
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 |
For reference: my report at vim_dev. |
There doesn't seem to be any fix in sight for the problem. Setting |
It looks like your patch may be merged in to mainline Vim! |
My patch in 7.4.379 solves a different, unrelated problem. |
Ahh ok. |
I am seeing a similar problem, although I have The location list displays the warnings (subtype=Style), but I get Using After This is with the I am using |
I could bisect my issue from the comment above to 4c88885:
(having set |
It is caused by this bug in Vim (has a patch): https://groups.google.com/d/msg/vim_dev/WmuoFum2Lq4/w3UiiS9Wj2kJ |
@blueyed This might be a related bug (I can't really tell), but your patch doesn't solve the initial problem. |
Ok, would have been nice. Sorry for the noise. Does (The Vim bug is triggered by Syntastic's |
No. |
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? |
The workaround is to set |
Thank you sir for taking the time to educate me, that ":.ll" trick was great for verification. The problem was
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. |
@lkraav I use something like this to move around splits, which I find pretty intuitive
|
The quickfix buffer has filetype
It's still unresolved, and, while unlikely, the root cause could still be within syntastic. shrug |
Btw, while working on fatih/vim-go#607 I also came to the same issue. The problem I've found was opening the location list twice. I had an |
@fatih If you have a fix for the problem described above for syntastic, please post a PR. |
@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 |
i can not reproduce this in javac checker,and it works well |
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). |
Update: the problem is not really fixed (cf. my post to |
This problem has vexed me for years. I just get a workaround for this ( modified from #32 (comment) ) nmap <silent> <C-Up> :call <SID>LocationPrevious()<CR>
nmap <silent> <C-Down> :call <SID>LocationNext()<cr>
function! <SID>LocationPrevious()
try
lprev!
catch /:E776:/ " No location list
catch /:E553:/ " End/Start of location list
call <SID>LocationLast()
catch /:E926:/ " Location list changed
ll!
endtry
endfunction
function! <SID>LocationNext()
try
lnext!
catch /:E776:/ " No location list
catch /:E553:/ " End/Start of location list
call <SID>LocationFirst()
catch /:E926:/ " Location list changed
call <SID>LocationNext()
endtry
endfunction
function! <SID>LocationFirst()
try
lfirst!
catch /:E926:/ " Location list changed
call <SID>LocationFirst()
endtry
endfunction
function! <SID>LocationLast()
try
llast!
catch /:E926:/ " Location list changed
call <SID>LocationLast()
endtry
endfunction |
I have similar problems moving to the error line from the error message, using nvim 0.5.0 I get |
@artfulrobot Please consider switching to ALE instead, which is actively maintained and takes advantage of Vim 8+ features. Synrtastic is only useful for legacy Vim 7 setups these days. If you still insist on fixing the problem above please open a new issue, and explain what did you do, what did you expect to happen, and what happened instead. |
@lcd047 thanks for the reply! Yes, TBH I uninstalled Syntastic. I use CoC now anyway, but had liked the way Syntastic would put errors in my face whenever I saved a duff file - something I've not managed to repeat with CoC yet. Anyway, many thanks for your work and your reply. xx |
I use vim in terminal.
After 0bef7ef commit, I cannot move cursor to the error position from location list with enter key. Vim reports the error "E92: Buffer not found".
The text was updated successfully, but these errors were encountered: