[Bug] Unexpected behaviour when editting file with julia-vim.
hungpham3112 opened this issue · 5 comments
Without julia-vim:
bandicam.2022-04-07.09-31-01-172.mp4
With julia-vim:
bandicam.2022-04-07.09-37-52-695.mp4
In the below video, autocomplete is broken in .jl file, but when I switch to .vim file the snippet is fine, and when come back to .jl file, the snippet works miraculously.
bandicam.2022-04-07.09-38-58-294.mp4
Julia settings:
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
" Plugin: Julia-vim "
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
let g:latex_to_unicode_auto = 1
let g:latex_to_unicode_file_types = ['julia', 'python']
Today I was working with python file, error also happens with python snippets.
Hello, this will require some additional information. Most importantly: what do you use for the snippets, and how is it configured? Also, possibly less crucial: is this vim or neovim, and which version? What is your operating system?
Hello, this will require some additional information. Most importantly: what do you use for the snippets, and how is it configured? Also, possibly less crucial: is this vim or neovim, and which version? What is your operating system?
Sorry about that:
Vim version:
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Apr 7 2022 22:02:16)
MS-Windows 64-bit GUI version with OLE support
Included patches: 1-4710
Compiled by appveyor@APPVYR-WIN
Huge version with GUI. Features included (+) or not (-):
+acl +cmdline_info +extra_search +langmap +num64 +scrollbind -termresponse -vtp
+arabic +comments -farsi +libcall +ole +signs +textobjects +wildignore
+autocmd +conceal +file_in_path +linebreak +packages +smartindent +textprop +wildmenu
+autochdir +cryptv +find_in_path +lispindent +path_extra +sodium/dyn -tgetent +windows
+autoservername +cscope +float +listcmds +perl/dyn +sound +timers +writebackup
+balloon_eval +cursorbind +folding +localmap +persistent_undo +spell +title -xfontset
-balloon_eval_term +cursorshape -footer +lua/dyn +popupwin +startuptime +toolbar -xim
+browse +dialog_con_gui +gettext/dyn +menu -postscript +statusline +user_commands +xpm_w32
++builtin_terms +diff -hangul_input +mksession +printer -sun_workshop +vartabs -xterm_save
+byte_offset +digraphs +iconv/dyn +modify_fname +profile +syntax +vertsplit
+channel +directx +insert_expand +mouse +python/dyn +tag_binary +vim9script
+cindent -dnd +ipv6 +mouseshape +python3/dyn -tag_old_static +viminfo
+clientserver -ebcdic +job +multi_byte_ime/dyn +quickfix -tag_any_white +virtualedit
+clipboard +emacs_tags +jumplist +multi_lang +reltime -tcl +visual
+cmdline_compl +eval +keymap +mzscheme/dyn +rightleft -termguicolors +visualextra
+cmdline_hist +ex_extra +lambda +netbeans_intg +ruby/dyn +terminal +vreplace
system vimrc file: "$VIM\vimrc"
user vimrc file: "$HOME\_vimrc"
2nd user vimrc file: "$HOME\vimfiles\vimrc"
3rd user vimrc file: "$VIM\_vimrc"
user exrc file: "$HOME\_exrc"
2nd user exrc file: "$VIM\_exrc"
system gvimrc file: "$VIM\gvimrc"
user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$HOME\vimfiles\gvimrc"
3rd user gvimrc file: "$VIM\_gvimrc"
defaults file: "$VIMRUNTIME\defaults.vim"
system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /GF /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DFEAT_XPM_W32 -DHAVE_SODIUM -DDYNAMIC_SODIUM -DDYNAMIC_SODIUM_DLL=\"libsodium.dll\" /I "C:\libsodium\include" -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 /source-charset:utf-8 /MP -DHAVE_STDINT_H /Ox /GL -DNDEBUG /Zl /MT /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_MSWIN -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DFEAT_DIRECTX_COLOR_EMOJI -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=\"lua54.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python310.dll\" -DFEAT_MZSCHEME -I "C:\racket\include" -DMZ_PRECISE_GC -DDYNAMIC_MZSCHEME -DDYNAMIC_MZSCH_DLL=\"libracket3m_da32rk.dll\" -DDYNAMIC_MZGC_DLL=\"libracket3m_da32rk.dll\" -DFEAT_PERL -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl532.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_DLL=\"x64-msvcrt-ruby300.dll\" -DRUBY_VERSION=30 -DFEAT_HUGE /Fd.\ObjGXOULYHRZAMD64/ /Zi
Linking: link /nologo /opt:ref /LTCG /HIGHENTROPYVA:NO oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib netapi32.lib uuid.lib user32.lib /machine:AMD64 version.lib winspool.lib comctl32.lib libcmt.lib oleaut32.lib /nodefaultlib:lua54.lib /STACK:8388608 /nodefaultlib:python27.lib /nodefaultlib:python310.lib winmm.lib WSock32.lib Ws2_32.lib xpm\x64\lib-vc14\libXpm.lib /PDB:gvim.pdb -debug
OS: Windows 11
I'm using coc.nvim and coc-snippets for completion.
coc.nvim:
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
" Plugin: Coc-nvim "
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
"Completion settings
"Use <tab> for trigger completion and navigate to the next complete item
inoremap <silent><expr> <Tab>
\ pumvisible() ? "\<C-n>" :
\ coc#expandableOrJumpable() ?
\ "\<C-r>=coc#rpc#request('doKeymap', ['snippets-expand-jump',''])\<CR>" :
\ <SID>check_back_space() ? "\<Tab>" :
\ coc#refresh()
inoremap <silent><expr> <S-Tab>
\ pumvisible() ? "\<C-p>" :
\ coc#refresh()
function! s:check_back_space() abort
let col = col('.') - 1
return !col || getline('.')[col - 1] =~# '\s'
endfunction
"Select the first completion item and confirm the completion when no item has been selected:
inoremap <silent><expr> <CR> pumvisible() ? coc#_select_confirm()
\: "\<C-g>u\<CR>\<c-r>=coc#on_enter()\<CR>"
let g:coc_snippet_next = '<Tab>'
let g:coc_snippet_prev = '<S-Tab>'
if has('nvim-0.4.0') || has('patch-8.2.0750')
nnoremap <silent><nowait><expr> <C-d> coc#float#has_scroll() ? coc#float#scroll(1) : "\<C-f>"
nnoremap <silent><nowait><expr> <C-u> coc#float#has_scroll() ? coc#float#scroll(0) : "\<C-b>"
inoremap <silent><nowait><expr> <C-d> coc#float#has_scroll() ? "\<c-r>=coc#float#scroll(1)\<cr>" : "\<Right>"
inoremap <silent><nowait><expr> <C-u> coc#float#has_scroll() ? "\<c-r>=coc#float#scroll(0)\<cr>" : "\<Left>"
vnoremap <silent><nowait><expr> <C-d> coc#float#has_scroll() ? coc#float#scroll(1) : "\<C-f>"
vnoremap <silent><nowait><expr> <C-u> coc#float#has_scroll() ? coc#float#scroll(0) : "\<C-b>"
endif
nnoremap <silent> K :call <SID>show_documentation()<CR>
function! s:show_documentation()
if (index(['vim','help'], &filetype) >= 0)
execute 'h '.expand('<cword>')
elseif (coc#rpc#ready())
call CocActionAsync('doHover')
else
execute '!' . &keywordprg . " " . expand('<cword>')
endif
endfunction
if exists('g:did_coc_loaded')
autocmd CursorHold * silent call CocActionAsync('highlight')
endif)
let g:coc_global_extensions = ['coc-json',
\'coc-vimlsp',
\'coc-snippets',
\'coc-powershell',
\'coc-markdownlint',]
I don't think this is a problem with any settings, because it just happen when I use this plugin. There is probably a conflict with autopairs. For details, look at my repo in here
Is there any update for this issue?
I initially blamed coc-nvim's async behavior meeting vim's input system and consequently being weird. I was wrong.
The map alone actually behaves lie it should. It's when I enabled julia-vim with LaTeX expansion that stuff fell apart. Here's why:
auto-pairs' <CR> is a <script> mapping. This is stuff that can be expanded normally if normal mapping semantics are followed. You lot don't follow the normal mapping semantics and dump the contents of the map:
julia-vim/autoload/LaTeXtoUnicode.vim
Lines 643 to 645 in fca7e3e
you print what you're given, and you literally get <SNR>145_AutoPairsOldCRWrapper73<SNR>145_AutoPairsReturn because that's the literal string of the mapping. Coc.nvim being involved is actually irrelevant. Disabling the <CR> mapping for coc yields <SNR>145_AutoPairsReturn instead, which is still the auto-pairs' <CR> mapping being eaten away.
Coc.nvim doesn't properly conflict with auto-pairs, because it still produces a <CR> that auto-pairs internally eats to produce identical output, as if coc.nvim never did a thing. The beauty of this is that this is in place of <CR>. if an existing map is found, the equivalent previous map is set to `:
And because coc.nvim's mapping ends in <cr> in the else condition auto-pairs' functions get eaten into, coc.nvim has no effect. That's an aside.
I believe, however, that this can be fixed. Just not easily.
Ternary exists, and can be used. This does create a challenge in terms of priority, but that's honestly just a footnote in the bigger problem. I have no idea what the code for this would look like, but a check for whether or not julia-vim makes a substitution would need to be in place; if it passes, return it (or possibly blank if julia-vim's function is run first, the result stored in a variable, and that variable then gets checked for the ternary). How this works with mixed expr and non-expr is not really something I know, especially if <SNR> or <Plug> are involved. <Plug> has to be mapped, so that alone wipes exec-style approaches off the table.
This would be trivial if Vim had an easy way to signal the early termination of a map, but it doesn't. Everything from this point is ugly instead.
The only other alternative is to not try to be compatible, and just wipe out any existing <CR> maps, at least if it contains SID, SNR, or Plug. <C-R> is sent as a literal key, and I believe feedkeys should be able to interpret it, but everything else will not be.
From a compatibility perspective, it sucks. It'll kill coc.nvim maps as well as auto-pairs. But it'll keep stuff functional, and realistically... these maps are already broken. Auto-pairs just happened to be the very painfully obvious actor that got in between the coc maps and the bad julia-vim maps.
Or, y'know, provide an option to allow remapping the LaTeX expansion key for people who decide they like the feature, just not at the expense of other plugins.