Plugin loaded but commands and completions not available (Lazy)

[euglevi]

Fist of all, thank you for the plugin. As someone who works with data using the neovim/kitty combination, I have been looking for something like this for a long time.

I am not sure why, but with Lazy as plugin manager the plugin is loaded but no command is available (and of course no completion). I am not lazy loading the plugin, just setting it up as a dependency to nvim-cmp as the other cmp completions. Kitty is set up properly with unix:@mykitty as socket, and other kitty plugins like vim-kitty-navigator are working fine. The output of the CmpStatus command is that kitty is an unknown source name. Do you have any ideas what could be going wrong?

[garyhurtz]

I had never looked into lazy.nvim, but this gave me a reason to do so. After getting a basic setup working I was able to see this (or a similar) issue, then I pretty quickly found the problem - the setup section of the readme missed an important detail.

For lazy you will need to add an init section:

    "garyhurtz/cmp_kitty",
    init=function()
        require("cmp_kitty"):setup()
    end

I just updated the readme to fix this. Give this a try and let me know if it works.

Thanks a lot for pointing this out.

[euglevi]

Thank you very much for this! Now commands work. CmpKittyLs gives the output you would expect. However, even if kitty is listed as source in the cmp setup I still do not see the completions. Now I am not sure it is an issue with Lazy.nvim anymore. With CmpStatus the source is listed as known but unavailable.

[garyhurtz]

OK, I studied lazy.nvim a bit more.

With the config below, this sequence is working on my system:

1. Copy the config below to a local file, add correct socket name, save as "lazy-kitty-init.lua" or similar
2. Start nvim with this config (nvim -u lazy-kitty-init.lua)
3. :CmpStatus verifies that cmp_kitty has loaded and is available (ie "kitty" appears in the ready sources list)
4. :CmpKittyLs returns the Kitty JSON response, confirming that the plugin and Kitty are communicating
5. Pick some unique text from another Kitty window and type a few letters to verify that it appears in completions.

Please give this a try and let me know what you find.

Note that I used cmp-buffer as a "known-good" reference while debugging the config, but it doesn't have anything to do with this plugin and can be removed from the config if you don't use it.

vim.opt.termguicolors = true
vim.opt.completeopt = "menu,menuone,noselect"
vim.opt.tabstop = 4

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"

if not vim.loop.fs_stat(lazypath) then
	vim.fn.system({
		"git",
		"clone",
		"--filter=blob:none",
		"https://github.com/folke/lazy.nvim.git",
		"--branch=stable", -- latest stable release
		lazypath,
	})
end

vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
	{
		"hrsh7th/nvim-cmp",
		opts = {
			completion = {
				keyword_length = 2,
			},
			sources = {
				{ name = "buffer" },
				{ name = "kitty", 
					option = {
						listen_on = "socket-name-here",
				        } 
			        },
		        },

		},
	},
	{
		"hrsh7th/cmp-buffer",
		dependencies = {
			{ "hrsh7th/nvim-cmp" },
		},
	},
	{
		"garyhurtz/cmp_kitty",
		dependencies = {
			{ "hrsh7th/nvim-cmp" },
		},
		init = function()
			require("cmp_kitty"):setup()
		end,
	},
})

[euglevi]

I tried but with the limited config I get this error at startup:

Failed to run `init` for **cmp_kitty**                                                                 
....local/share/nvim/lazy/cmp_kitty/lua/cmp_kitty/kitty.lua:110: Expected value but found T_END at character 1
# stacktrace:
  - /cmp_kitty/lua/cmp_kitty/kitty.lua:110 _in_ **update**
  - /cmp_kitty/lua/cmp_kitty/kitty.lua:32 _in_ **new**
  - /cmp_kitty/lua/cmp_kitty/source.lua:19 _in_ **new**
  - /cmp_kitty/lua/cmp_kitty/init.lua:1
  - nvim_temp.lua:50 _in_ **init**
  - nvim_temp.lua:20

Thank you for taking time to solve this issue and do not worry if it takes you more time - we all have proper work to do!

[garyhurtz]

I can reproduce this error if I intentionally set listen_on to the wrong socket.

You can check whether you are requesting the correct socket from the command line:

> kitty @ --to unix:@wrong-socket
> Error: dial unix @wrong socket: connect: no such file or directory

You may get a different error if you are using a different type of socket, but you will get similar feedback.

> kitty @ --to unix:@correct-socket
> <JSON response>

Obviously, substitute your own correct socket name ;-)

If this still doesn't help I will dig a bit deeper. In any case I will make a note to provide feedback that is more useful than a traceback when these kinds of errors happen.

[euglevi]

It does not help much. I think I put the correct socket. In my Kitty config file I have the listen_on option with the value unix:@mykitty and this is what I put in the plugin configuration. Obviously, if I use the command:

kitty @ --to unix:@mykitty ls

it does not give any sensible output because it needs, as by Kitty documentation, a suffix in the form -a 4 or 5-digitnumber. Is this the problem?

[garyhurtz]

Regarding the suffix, Kitty has some features that can use suffixes (for example, if you want to add the PID to the socket name), but they aren't required for communication. For example, the remote-control quick start in the Kitty docs doesn't use any suffix:

Remote control via a socket

First, start kitty as:
kitty -o allow_remote_control=yes --listen-on unix:/tmp/mykitty
The kitty --listen-on option tells kitty to listen for control messages at the specified UNIX-domain socket. See kitty --help for details. Now you can control this instance of kitty using the kitty @ --to command line argument to kitty @. For example:
kitty @ --to unix:/tmp/mykitty ls

If you can't communicate with Kitty using the command line, then it is unlikely that the plugin would be able to do so. At this point I would focus on getting the command line to work.

FYI one tool that can help disect the issue is the remote-control quick-start, since it overrides your config and "should just work". If you find that you can execute the quick-start and get a JSON response, then you have a good indicator that there is an issue in your config. If the quick-start isn't able to communicate either, then it seems that something else is preventing communication.

[euglevi]

With the minimal config, the plugin now seems to work. But I get the usual problem with the full config: commands work - they were working even before with the full config - but no autocompletions available.

If you have time, I would consider allowing the possibility of having the kitty_pid as a suffix with the hyphen after the listen_on value. As far as my experience goes, this is the standard way in which kitty does this when there is this option in the config file. Another option, and this is how I actually managed to get this working, is substituting the listen_on value with vim.env.KITTY_LISTEN_ON.

Thank you again for all your effort.

[garyhurtz]

Based on your feedback, I have a hunch at what the problem might be, so I just pushed a few logic changes that might address it. It is working on my system for both lazy and packer, but since I can't reproduce the issue you are seeing I don't have a test to be sure. Please check when you get a chance, and let me know if it addresses the issue.

I really like the idea of pulling the socket name from environment variables. I am wondering why I didn't think to do it that way to begin with. I implemented this as well, which has the benefit that the listen_on config option is no longer required.

thanks again for the feedback, and let me know how it goes.

[euglevi]

Thank you so much! Now it works! The only issue left seems to be the label. Not sure why but all completions from kitty have a 'text' label, much like the buffer ones.

Great that the listen_on option is not required anymore.

[garyhurtz]

Great news, glad you got it working. Hope you find it worth the effort. Regarding the labels, my priority for the first release was to cover the basics, then make cosmetic improvements (like labels) and implement new features. I have been working on improved labels, and expect to push an update in a day or two. Thanks again for the feedback.