How to import coq

[s1n7ax]

In the readme it shows following snippet.

local lsp = require "lspconfig"

lsp.<server>.setup(<stuff...>)                              -- before
lsp.<server>.setup(coq.lsp_ensure_capabilities(<stuff...>)) -- after

Apparently require('coq') is a function and what needs to be passed in to the function?

[ms-jpq]

coq imports itself when your package manager loads it.

dont worry, it does like almost zero work and just registers two functions to the global scope, one to start the program when you call :COQnow and other one is coq.lsp_ensure_capabilities

[s1n7ax]

    for _, lsp in ipairs(servers) do
        lspconfig[lsp].setup(coq.lsp_ensure_capabilities({
                                        ^^^ attempt to index global 'coq' (a nil value)
            on_attach = on_attach_callback,
        }))
    end

I'm using packer and loading lspconfig, lspinstall and all the other stuff after coq. completion starts after :COQnow but still get above error. One reason not to have global variable on top of other scope reasons i guess. In completion it shows the templates literally as well.

[ms-jpq]

humm im not familiar with packer. I will need to test it, maybe it loads plugins lazily and there is a special option not to?

coq does almost zero work on load so it should be ok to eagerly load it.

and yeah the snippet template showing is intentional, some snippets do not have names and only their snippet body.

Its probably best to show it imo, so you know what each one does.

[QuiiBz]

Same issue here with Plug as a package manager: E5108: Error executing lua [string ":lua"]:55: attempt to index global 'coq' (a nil value). Shouldn't we put a require("coq")?

[s1n7ax]

Are you sure plugin/coq.vim is getting called when there is a coq.lua file? Otherwise in coq.lua setting a global variable inside the function.

[ms-jpq]

OH packer skips calling plugin/coq.nvim if coq.lua exists?

I will need to investigate that, I assumed all plugin managers called *.vim files, always.

[ms-jpq]

I will do that tomorrow probably, i have no brain cells left for tonight,

and I promise my mom id go to Ikea with her, so tomorrow night, sorry about delay

[s1n7ax]

@ms-jpq Ok i checked it. coq.vim also being loaded.

I added some print statements

my conf
coq.vim
coq.lua

Somehow someway this is the order. It was not because packer lazy loading it (I think) because packer does not lazy load unless there are additional loading conditions are there. In my case I don't have any conditions.

[matu3ba]

@ms-jpq Did you try putting every variable and function into a table and return the table?

local M = {}
M.config = default_config
function M.init(config)
...
end
return M

and then calling via

lua require("iswap").init()
command ...

should work. For some reason also function init().

I dont understand the usage of luaeval and how it interacts with luaeval. My guess is that you try to use call which only works for calling vim code.
Why do you need the coq.vim at all? You can just use a function for the setup, which the user calls.

[creativenull]

Investigating this as well, seems like coq is a global variable that is set from lua/coq.lua so looks like if you're lazy loading it with packer BUT setting your lspconfig setups before loading coq.nvim then it will not work. You want to make sure it is loaded before your lspconfig setups, and usually it's discouraged to lazy load lspconfig as it does it's own lazy loading internally so it won't hurt to load them both on demand (Will need to see if it's possible to just lazy load coq.nvim).

Best thing is to not lazy load it and just load it on demand, then you have the coq variable available, no need to require('coq'), plugin/coq.vim will require it and set the coq global variable:

-- load with packer
use {'neovim/nvim-lspconfig'}
use {'ms-jpq/coq_nvim'}
...

-- somewhere after packer have loaded lspconfig and coq
lsp.<server>.setup(coq.lsp_ensure_capabilities(<your config>)) 

[ms-jpq]

I think @creativenull has got this?

I will try it later after IKEA and put it in the docs.

---

@matu3ba I actually need coq.vim for a single reason:

let s:top_level = resolve(expand('<sfile>:p:h:h'))

I need the absolute path of coq.nvim's install folder so I can figure out where to store stuff. I think I can probably remove this though.

[matu3ba]

let s:top_level = resolve(expand(':p:h:h'))

plenary.nvim (intended to be eventually nvim lua std) has a convenient parent method and :absolute.

Unfortunately there is still no git library or anything in plenary for getting the git_root (which would be a clearner solution).
see this issue nvim-lua/wishlist#6

plenary.nvim is already used by telescope, so using it as dependency would not be too much of an additional dependency.

nvim-lspconfig uses inside utils.lua are hacky search reverse 100 times until you find a .git in the folder.

[ms-jpq]

oh wtf, packer actually loads everything! lazily by default. I will need to read the docs to find out how to mark coq as an exception, as it performs it's own lazy loading

[creativenull]

Pretty sure when calling :PackerCompile will make it lazy load next time? But i'm not too sure how exactly packer does it w/o the compile file. It could be they lazy load everything like you said, but then what's the use of them adding the plugins in pack/*/start/* directory by default when no options are passed loading via packer.

[s1n7ax]

@ms-jpq I tried to remove expand('<sfile>:p:h:h') calling it inside the coq.lua

print(api.nvim_eval("expand('<sfile>:p:h:h')"))
print(api.nvim_eval("expand('<sfile>:p:h')"))
print(api.nvim_eval("expand('<sfile>:p')"))

> /home/s1n7ax/.config/nvim
> /home/s1n7ax/.config/nvim/plugin
> /home/s1n7ax/.config/nvim/plugin/packer_compiled.lua

So you are going to need that coq.vim.

[ms-jpq]

yeah thank you for the help, ive been testing this and its tricky. because packer tries to lazy load coq.nvim while coq.nvim is already lazily loaded, the double lazy loading thing obviously doesn't work.

[ms-jpq]

Ok i think I got it

#26

vim.schedule(function ()
  local lsp = require "lspconfig"
  require("packer").loader("coq_nvim coq.artifacts")
  lsp.<server>.setup(require("coq")().lsp_ensure_capabilities(<stuff...>))
end)

had to read packers code to figure it out

[s1n7ax]

I guess you don't need to manually load if it is being accessed in the next event loop and it is a dependency. This works for me

use {
    'kabouzeid/nvim-lspinstall',
    run = function()
        require('nvim.plugins.lspinstall').install_servers()
    end,
    requires = {
        {'neovim/nvim-lspconfig'}
    },
}

use {
    'neovim/nvim-lspconfig',
    config = function() require('nvim.plugins.lsp') end,
    requires = {
        {'ms-jpq/coq_nvim', branch = 'coq'},
        {'ms-jpq/coq.artifacts', branch = 'artifacts'},
    },
}

vim.schedule(function()
    vim.cmd('COQnow')
    for _, lsp in ipairs(servers) do
        lspconfig[lsp].setup(coq.lsp_ensure_capabilities({
            on_attach = on_attach_callback,
        }))
    end
end)

[ms-jpq]

thanks @s1n7ax I will add your comment to the readme.

[ms-jpq]

I dont think COQnow is required though, that will eagerly load coq.nvim.

unless you want that of course

[s1n7ax]

O_o It won't start unless I add COQnow. Plugin is up to date

[ms-jpq]

0.o ok maybe use my manual load method haha, I guess ill remove ur comment to reduce confusion.

oh and everybody please update your repo or else my snippet wont work.

[npielawski]

I don't know if I didn't update properly or if the issue only addressed Packer, but I still get the nil value problem. I am using Plugged.

[ms-jpq]

Oh ok nevermind, I thought it only affected packer. I will test out Plugged and see what it does different.

[akinsho]

FWIW packer does not lazy load by default. One of the main differences between it and other solutions is that it uses vim's native packages feature :h packages this means that the time when things are loaded is different to other package managers that manually manipulate vim's runtimepath. One key difference is that it means that native packages load after a user's init file is read.

When Vim starts up, after processing your .vimrc, it scans all directories in
'packpath' for plugins under the "pack/*/start" directory. First all those
directories are added to 'runtimepath'. Then all the plugins are loaded.
See |packload-two-steps| for how these two steps can be useful.

In the specific case of this plugin I think the issue is that unlike other lua modules that conventionally expose their modules to then be used programatically, this plugin returns a function from it's lua module which it then tries to load in the plugin directory, so this is likely happening later than when a user might try to use it in their packer setup.

I think a better solution would be to just return the coq module from the lua module so a user can require'coq'.lsp_stuff(). If the module is dependent on the location of the script then you can alternatively use

function script_path()
   local str = debug.getinfo(2, "S").source:sub(2)
   return str:match("(.*/)")
end

print(script_path())

to get the location of the file that the function was called from (source)

So the coq module should do something more like

local coq = {}
function coq.setup()
 local start_location = ... -- derive this with the above snippet
 ... -- other stuff
end

function coq.lsp_function_thing()
 -- logic here
end

return coq -- rather than return function() ... end

[ms-jpq]

#88

its done.

I will close this issue. If things still don't work, please re-open it.