Open blueyed opened 10 years ago
mr
commented
10 years ago Is it possible that omnicomplete is grabbing stuff from awesome? From the docs:
"The omni completion support works by enumerating and loading all installed modules. If module loading has side effects this can have unintended consequences!"
Importing awesome stuff could have unintended side effects and crash everything.
blueyed
commented
10 years ago Hmm, since I was/am merely interested in completion for the awesome libraries, this would make it less useful.
Would I have to test it with something along the lines of "LUA_PATH=/some/path/where/awesome/is/not/installed vim"?
A simple test case, which should work, would be useful.
Does it work for you?
mr
commented
10 years ago I'm not sure. It's broken for me as well, and I also run awesome.
blueyed
commented
10 years ago The new blacklist setting appears to help:
let g:lua_omni_blacklist = ['pl\.strict', 'lgi\..']I am now seeing other problems, without a crash though:
Omnifunc returned bad value to YCM! Vim(lua):[string "vim chunk"]:8: bad argument #1 to 'insert' (table expected, got userdata)
It seems to badly interact with the redir used in quickfixsigns:
Omnifunc returned bad value to YCM! Vim(lua):[string "vim chunk"]:8: bad argument #1 to 'insert' (table expected, got userdata)
Omnifunc returned bad value to YCM! Vim(redir):E121: Undefined variable: output
Omnifunc returned bad value to YCM! Vim(redir):E121: Undefined variable: output
Error detected while processing function QuickfixsignsSet..<SNR>142_UpdateLineNumbers..QuickfixsignsListBufferSigns..<SNR>142_Redir:
line 5:
E121: Undefined variable: output
Error detected while processing function QuickfixsignsSet..<SNR>142_UpdateLineNumbers:
line 15:
E171: Missing :endif
Error detected while processing function QuickfixsignsSet:
line 62:
E171: Missing :endif
Omnifunc returned bad value to YCM! Vim(lua):[string "vim chunk"]:8: bad argument #1 to 'insert' (table expected, got userdata)
Error detected while processing function QuickfixsignsSet..<SNR>142_UpdateLineNumbers..QuickfixsignsListBufferSigns..<SNR>142_Redir:
line 5:
E121: Undefined variable: output
Error detected while processing function QuickfixsignsSet..<SNR>142_UpdateLineNumbers:
line 15:
E171: Missing :endif
Error detected while processing function QuickfixsignsSet:
line 62:
E171: Missing :endif
xolox
commented
10 years ago Which exact version of Vim are you running? And which version of Lua does the Lua Interface for Vim load? For me arg is a regular table, for you it seems to be a userdata object (probably a proxy object created by the Lua Interface for Vim). This is the first I'm seeing of this, so probably I'm running an older version of Vim than you guys. Makes sense?
xolox
commented
10 years ago This issue has shown that it can be useful to disable the file type plug-in's use of the Lua Interface for Vim. I realize that doesn't actually solve the real problem yet, and I'll work towards doing so, however now you can:
let g:lua_internal = 0To stop Vim from crashing while still being able to use omni completion where it works (if it works anywhere at all :-). If the Lua Interface for Vim has indeed been changed to employ userdata proxy objects then this option should allow you to properly use the plug-in until the issue is fixed.
blueyed
commented
10 years ago Which exact version of Vim are you running?
I am following the hg tip / git master (mirror: https://github.com/b4winckler/vim.git), currently 7.4.316.
After adding let g:lua_internal = 0 to my current settings it works much better!
Although the manual chaining I have in place might cause these issues:
_VERSION, and, arg …<C-x><C-o> after e.g. utils. it completes with this context, but has the utils. prefix then.awful = require("awful")Regarding my settings, I currently I have:
let g:lua_check_syntax = 0 " done via syntastic
let g:lua_complete_keywords = 0 " interferes with YouCompleteMe
let g:lua_complete_globals = 0 " interferes with YouCompleteMe?
let g:lua_complete_library = 0 " interferes with YouCompleteMe
let g:lua_complete_dynamic = 0 " interferes with YouCompleteMe
let g:lua_complete_omni = 1 " Disabled by default. Likely to crash Vim!
let g:lua_omni_blacklist = ['pl\.strict', 'lgi\..']
let g:lua_define_omnifunc = 1 " must be enabled also (g:lua_complete_omni=1, but crashes Vim!)
let g:lua_define_completion_mappings = 0
let g:lua_internal = 0But also commenting all the lua_complete_* settings it appeared to behave similar.
I've noticed that there is g:lua_define_completefunc, which gets disabled implicitly by YCM / my custom chaining.
Maybe that is something that's expected to be there if not disabled?
I have tried to use it when setting up awesome, and have now tried only a bit to use it. Let me know if I should try it with less customization.
xolox
commented
10 years ago After compiling the latest and greatest Vim from source I finally ran into the following issue myself:
bad argument #1 to 'insert' (table expected, got userdata)This was just fixed in 4746f4d4bddb51619c2956d73adfb22b73e066dd so you should be able to switch back to using the Lua Interface for Vim instead of an external Lua interpreter. The caveat about it being possible to crash Vim still exists though (fundamentally it can't be solved).
meijieru
commented
8 years ago hello,I have the same issue with you,have you solve the problem?
While the docs warn about enabling the omni-completion, it should probably work with a simple
test.luafile?When completion is triggered, Vim crashes.
Manually executing the
:luafile .../lua-ftplugin/misc/lua-ftplugin/omnicomplete.luacmdline (seen in the backtrace) does not result in a crash, but this error:Line 82 is:
Here is the scrambled screen from the crash:
It seems to be related to issue #16.
Any pointers about how to debug this would be appreciated.
I have an uncommon LUA_PATH (for awesome window manager):.
…/awesome/lib/?.lua.in;/usr/share/lua/5.2/?.lua;, but unsetting it still crashes Vim on