Bug: do not get completions anymore for issues and mentions

[chrisgrieser]

I haven't used the plugin in a while, but it seems that for some reason it stopped working for me, I don't get any completions anymore. Completions for commits ( : ) work, but not for mentions or issues ( # and @ ).

Given that at least on the surface level it looks like my previous problem ( #47 ), I already checked and confirmed the following:

• pwd is set correctly
• :CmpStatus correctly lists git as a ready source
• filetype is correctly set to gitcommit
• :lua print(require("cmp_git.utils").is_git_repo()) reports true
• [I enabled cmp_git for the lua filetype](I enabled cmp_git for the lua filetype), and the same thing happens here.
• I am still using the minimal config as before:

cmp.setup.filetype("gitcommit", {
	sources = cmp.config.sources {
		{name = "git"},
	},
})
require("cmp_git").setup()

[petertriho]

Is the repo hosted on gitlab or github?

[chrisgrieser]

github

[rafamadriz]

Same problem here, adding minimal config to reproduce:

local on_windows = vim.loop.os_uname().version:match "Windows"

local function join_paths(...)
    local path_sep = on_windows and "\\" or "/"
    local result = table.concat({ ... }, path_sep)
    return result
end

vim.cmd [[set runtimepath=$VIMRUNTIME]]

local temp_dir = vim.loop.os_getenv "TEMP" or "/tmp"

vim.cmd("set packpath=" .. join_paths(temp_dir, "nvim", "site"))

local package_root = join_paths(temp_dir, "nvim", "site", "pack")
local install_path = join_paths(package_root, "packer", "start", "packer.nvim")
local compile_path = join_paths(install_path, "plugin", "packer_compiled.lua")

local function load_plugins()
    require("packer").startup {
        {
            "wbthomason/packer.nvim",
            "hrsh7th/nvim-cmp",
            { "petertriho/cmp-git", requires = "nvim-lua/plenary.nvim" },
        },
        config = {
            package_root = package_root,
            compile_path = compile_path,
        },
    }
end

_G.load_config = function()
    local cmp = require "cmp"

    cmp.setup {
        snippet = {
            expand = function(args) require("luasnip").lsp_expand(args.body) end,
        },
        mapping = cmp.mapping.preset.insert {
            ["<C-b>"] = cmp.mapping.scroll_docs(-4),
            ["<C-f>"] = cmp.mapping.scroll_docs(4),
            ["<C-Space>"] = cmp.mapping.complete(),
            ["<C-e>"] = cmp.mapping.abort(),
            ["<CR>"] = cmp.mapping.confirm { select = true },
        },
    }

    require("cmp_git").setup()
    cmp.setup.filetype("gitcommit", {
        sources = cmp.config.sources {
            { name = "git" }, -- You can specify the `cmp_git` source if you were installed it.
        },
    })
end

if vim.fn.isdirectory(install_path) == 0 then
    vim.fn.system { "git", "clone", "https://github.com/wbthomason/packer.nvim", install_path }
    load_plugins()
    require("packer").sync()
    vim.cmd [[autocmd User PackerComplete ++once lua load_config()]]
else
    load_plugins()
    require("packer").sync()
    _G.load_config()
end

[Curs3W4ll]

Hi !

That's an amazing plugin! Thanks for your work.

But I have the same issue, only commits works, PR, issues, and mentions do nothing.

I used gh CLI and though I wrongly configured it so I tried token in env var but it did not work too.

[cseickel]

I have the same problem but only for the octo filetype. It works fine when editing a commit message. I also tried adding "*" to the filetypes and everything worked correctly in a lua file but still not in an octo buffer.

For me at least, this is purely an issue with the octo filetype.

[dpetka2001]

I also have problem with octo regarding mentions, issues, PRs etc. But you can use <C-x><C-o> omnifunc completion that octo provides to get around this problem.

[vitorf7]

I am having the same problem and I don't believe the cmp-git is even available and for some reason when I try to do ctrl + x I am not getting any octo completion either.

[dpetka2001]

Do you by any chance have <c-x> mapped to anything else?

[vitorf7]

I don't believe I do, however after looking at the octo documentation I saw that there was a section on how to add the onmifunc auto complete and it said to add this:

vim.keymap.set("i", "@", "@<C-x><C-o>", { silent = true, buffer = true })
vim.keymap.set("i", "#", "#<C-x><C-o>", { silent = true, buffer = true })

After I did that it started working.
Off course the end goal will be to get cmp-git to actually be loaded with octo files and get it to auto complete but as you said for now it is a workaround.

[dpetka2001]

Strange I didn't need to add these keymaps to my configuration. It just worked out of the box. Anyway, glad you solved this.

[dpetka2001]

Oh you said in your first post that you only do <c-x> for autocompletion. You should do <c-x><c-o>. First Ctrl-x and then Ctrl-o.

[vitorf7]

Oh 🤦‍♂️ Yeah this is what happens when you I don't pay attention and also am a noob at this

[GitMurf]

Has anyone figured this out? I am having the same issues.

[GitMurf]

cc @chrisgrieser @vitorf7 @petertriho @dpetka2001 @cseickel @Curs3W4ll @rafamadriz

This should fix it. Can use my fork (https://github.com/GitMurf/cmp-git) until the PR gets merged: #61

[petertriho]

Not sure if this will fix all the issues so I'll keep this open.

[GitMurf]

Another thing to note is that even with this fix above, I had an issue on another machine when I changed the default shell to powershell (instead of CMD). When i flipped it back to using cmd.exe as my default nvim terminal shell then it worked. In case any Windows users are still having problems.

[classabbyamp]

do any of you happen to have CLICOLOR_FORCE in your env? I had that set so tree would be coloured, but it seems gh also interprets that and that messes up this plugin's parsing of gh output

[ZeroKnight]

[EDIT] For context, I'm editing a gitcommit file via fugitive in a repository with a Github remote.

I've noticed this issue as well and I'm attempting to trace what's going on. Without diving too deeply, I've so far noticed something that could be related to the problem.

This line calls ipairs(parsed):

cmp-git/lua/cmp_git/utils.lua

Line 212 in 8dfbc33

for _, item in ipairs(parsed) do

So I threw in a vim.print to inspect parsed at this point. If I edit a commit message and type a #, parsed ends up being a key/value table rather than an array-like table:

{
  authorizations_url = "https://api.github.com/authorizations",
  code_search_url = "https://api.github.com/search/code?q={query}{&page,per_page,sort,order}",
  commit_search_url = "https://api.github.com/search/commits?q={query}{&page,per_page,sort,order}",
  current_user_authorizations_html_url = "https://github.com/settings/connections/applications{/client_id}",
  current_user_repositories_url = "https://api.github.com/user/repos{?type,page,per_page,sort}",
  current_user_url = "https://api.github.com/user",
  emails_url = "https://api.github.com/user/emails",
  emojis_url = "https://api.github.com/emojis",
  events_url = "https://api.github.com/events",
  feeds_url = "https://api.github.com/feeds",
  followers_url = "https://api.github.com/user/followers",
  following_url = "https://api.github.com/user/following{/target}",
  gists_url = "https://api.github.com/gists{/gist_id}",
  hub_url = "https://api.github.com/hub",
  issue_search_url = "https://api.github.com/search/issues?q={query}{&page,per_page,sort,order}",
  issues_url = "https://api.github.com/issues",
  keys_url = "https://api.github.com/user/keys",
  label_search_url = "https://api.github.com/search/labels?q={query}&repository_id={repository_id}{&page,per_page}",
  notifications_url = "https://api.github.com/notifications",
  organization_repositories_url = "https://api.github.com/orgs/{org}/repos{?type,page,per_page,sort}",
  organization_teams_url = "https://api.github.com/orgs/{org}/teams",
  organization_url = "https://api.github.com/orgs/{org}",
  public_gists_url = "https://api.github.com/gists/public",
  rate_limit_url = "https://api.github.com/rate_limit",
  repository_search_url = "https://api.github.com/search/repositories?q={query}{&page,per_page,sort,order}",
  repository_url = "https://api.github.com/repos/{owner}/{repo}",
  starred_gists_url = "https://api.github.com/gists/starred",
  starred_url = "https://api.github.com/user/starred{/owner}{/repo}",
  topic_search_url = "https://api.github.com/search/topics?q={query}{&page,per_page}",
  user_organizations_url = "https://api.github.com/user/orgs",
  user_repositories_url = "https://api.github.com/users/{user}/repos{?type,page,per_page,sort}",
  user_search_url = "https://api.github.com/search/users?q={query}{&page,per_page,sort,order}",
  user_url = "https://api.github.com/users/{user}"
}

Given this, ipairs(parsed) never enters the loop since there are no integer indices to iterate over, so items ends up empty. This is the first I'm looking at this codebase so, flying blind, I naively tried simply changing ipairs to pairs. But this threw an error when it gets to the handle_item callback, which I believe ends up being the function here:

cmp-git/lua/cmp_git/sources/github.lua

Lines 136 to 148 in 8dfbc33

	function(issue)
	if issue.body ~= vim.NIL then
	issue.body = string.gsub(issue.body or "", "\r", "")
	else
	issue.body = ""
	end
	if not issue.updatedAt then
	issue.updatedAt = issue.updated_at
	end
	return format.item(config, trigger_char, issue)
	end

Using pairs, item (and thus issue) ends up being a string, so it obviously errors when the callback expects issue to be a table. So it's definitely supposed to be an ipairs call.

So then I would have to guess that the parsed table is ending up with an unexpected value. Not sure if I'm off base here, but that's what I've been able to sus out so far; maybe this is enough for someone more familiar with this code to glean some insight.

[petertriho]

@ZeroKnight is this with gh cli or through the api?

[ZeroKnight]

@ZeroKnight is this with gh cli or through the api?

In my case, it's trying to go through the API via curl as a fallback, as I've just noticed that while I do have gh installed, it's not configured on the machine I'm on currently.

I did some more poking, and I noticed that because it's going through this code path, the curl_url argument of get_items becomes relevant:

cmp-git/lua/cmp_git/sources/github.lua

Lines 124 to 135 in 8dfbc33

	github_url(
	git_info.host,
	string.format(
	"repos/%s/%s/issues?filter=%s&state=%s&per_page=%d&page=%d",
	git_info.owner,
	git_info.repo,
	config.filter,
	config.state,
	config.limit,
	1
	)
	),

get_issues_job builds the curl_url with github_url, but it always returns https://api.github.com, which explains the result I saw for parsed. Looking at github_url:

cmp-git/lua/cmp_git/sources/github.lua

Lines 33 to 41 in 8dfbc33

	local github_url = function(git_host, path)
	local url = ""
	if git_host == "github.com" then
	url = "https://api.github.com"
	else
	url = string.format("https://%s/api/v3/%s", git_host, path)
	end
	return url
	end

It will indeed always return the API root url because git_host is "github.com". Again, I'm not keen on everything going on here, but this seems odd to me.

[ZeroKnight]

@petertriho This seems to fix it, actually:

 local github_url = function(git_host, path)
     local url = ""
     if git_host == "github.com" then
-        url = "https://api.github.com"
+        url = string.format("https://api.github.com/%s", path)
     else
         url = string.format("https://%s/api/v3/%s", git_host, path)
     end

The issues from my repo are populated in the cmp results with this patch.

[ZeroKnight]

Also, unrelated but curl_args is global here:

cmp-git/lua/cmp_git/sources/github.lua

Lines 43 to 46 in 8dfbc33

	local get_items = function(callback, gh_args, curl_url, handle_item, handle_parsed)
	local gh_job = utils.build_job("gh", callback, gh_args, handle_item, handle_parsed)
	curl_args = {

Missing a local :)

[petertriho]

@ZeroKnight Ah yes, I see now where/when the issue popped up. I've only ever used the gh cli so never noticed the issue. Would you like to open a PR or I can push a fix now?

[ZeroKnight]

Making a PR right now! :)

[petertriho]

Awesome, thanks

[petertriho]

Oops wasn't meant to close. Still have issues with windows

[ZeroKnight]

That's my bad, I added a "fixes" line to the commit message out of habit. Sorry! 😅

[benelan]

do any of you happen to have CLICOLOR_FORCE in your env? I had that set so tree would be coloured, but it seems gh also interprets that and that messes up this plugin's parsing of gh output

Thanks for the hint! My issue was that I set CLICOLOR=1 in my shell startup scripts. In gh help environment it says:

CLICOLOR: set to 0 to disable printing ANSI colors in output.

I created #70, which resolves the issue on my end.