🆕 Command-T 6.0.0 release — compendium issue

[wincent]

Command-T 6.0.0

• 6.0.0-a.0 Release notes.
• 6.0.0-a.1 Release notes.
• 6.0.0-a.2 Release notes.
• 6.0.0-a.3 Release notes.
• 6.0.0-a.4 Release notes.
• 6.0.0-b.0 Release notes.
• 6.0.0-b.1 Release notes.
• |command-t-upgrading|.
• Blog post, "Command-T v6.0 — the Lua rewrite".
• https://github.com/wincent/command-t/issues/391
• 5-x-release branch (if you wish to remain on the previous release serious).

Now, this is a beta release (see |command-t-known-issues|), a total rewrite, subject to change, incompletely documented, with known bugs and feature gaps. But, because the entire world installs Neovim plugins by pointing at HEAD of main, people are probably going to end up trying this whether they intend to or not.

So, this feedback issue is to gather together common questions and bug reports. I also created this discussion thread for folks who prefer that format.

Information to include when reporting issues

• What version of Neovim are you running? ie. nvim --version
• What operating system are you running on? (eg. macOS Monterey, Arch Linux etc)
• What system architecture? (eg. arm64, x86_64 etc)
• How did you install Command-T? (eg. what package manager, if any, did you use?)
• How have you configured Neovim and/or Command-T?
• Do you have a minimal repro example, or a link to your dotfiles repo?
• What other plug-ins do you have running, and have you tried reproducing the problem without them?

Summary

packer.nvim set-up

use {
  'wincent/command-t',
  run = 'cd lua/wincent/commandt/lib && make',
  setup = function ()
    vim.g.CommandTPreferredImplementation = 'lua'
  end,
  config = function()
    require('wincent.commandt').setup()
  end,
}

Via comment.

[deathmaz]

Hi, i tried to install new version with packer but having issues:

    use {
      'wincent/command-t',
      run = 'cd lua/wincent/commandt/lib && make',
      config = function()
        vim.g.CommandTPreferredImplementation = 'lua'
        require('wincent.commandt').setup({})
      end
    }

:checkhealth wincent.commandt

wincent.commandt: require("wincent.commandt.health").check()
========================================================================
  - INFO: Command-T version: 6.0.0-a.0

## Checking that C library has been built
  - INFO: Build directory is:
    /home/maz/.local/share/nvim/site/pack/packer/start/command-t/lua/wincent/commandt/lib
  - OK: library can be `require`-ed and functions called

## Checking for optional external dependencies
  - OK: (optional) `watchman` binary found
  - OK: (optional) `git` binary found
  - OK: (optional) `find` binary found
  - OK: (optional) `rg` binary found

but when i open neovim i get this message:

packer.nvim: Error running config for command-t: ...ack/packer/start/command-t/lua/wincent/commandt/init.lua:343: bad argument #1 to 'pairs' (table expected, got nil)

When calling :CommandT i get this:

Error executing Lua callback: .../start/command-t/lua/wincent/commandt/private/window.lua:131: Vim(let):E716: Key not present in Dictionary: "rhs"                                              
stack traceback:                                                                                                                                                                                
        [C]: in function 'nvim_set_current_win'                                                                                                                                                 
        .../start/command-t/lua/wincent/commandt/private/window.lua:131: in function 'focus'                                                                                                    
        .../start/command-t/lua/wincent/commandt/private/prompt.lua:148: in function 'show'                                                                                                     
        ...cker/start/command-t/lua/wincent/commandt/private/ui.lua:133: in function 'show'                                                                                                     
        ...ack/packer/start/command-t/lua/wincent/commandt/init.lua:113: in function 'file_finder'                                                                                              
        ...im/site/pack/packer/start/command-t/plugin/command-t.lua:36: in function <...im/site/pack/packer/start/command-t/plugin/command-t.lua:35>

My neovim is on https://github.com/neovim/neovim/commit/09c6ce8c4e4c6415cca9b834539ed0df461373f6

[wincent]

Thanks for the report @deathmaz; it doesn't like the empty table passed to setup(). This is a bug, which I'll push a fix for presently. In the meantime, you can work around it by inserting a finders key into the setup; eg:

require('wincent.commandt').setup({finders = {}})

[wincent]

Should be fixed in e59f7406a565b574caabb77ec8079e0ed180e3a9.

[deathmaz]

Thank you, it fixed the packer issue, but

Error executing Lua callback: .../start/command-t/lua/wincent/commandt/private/window.lua:131: Vim(let):E716: Key not present in Dictionary: "rhs"                                              
stack traceback:                                                                                                                                                                                
        [C]: in function 'nvim_set_current_win'                                                                                                                                                 
        .../start/command-t/lua/wincent/commandt/private/window.lua:131: in function 'focus'                                                                                                    
        .../start/command-t/lua/wincent/commandt/private/prompt.lua:148: in function 'show'                                                                                                     
        ...cker/start/command-t/lua/wincent/commandt/private/ui.lua:133: in function 'show'                                                                                                     
        ...ack/packer/start/command-t/lua/wincent/commandt/init.lua:113: in function 'file_finder'                                                                                              
        ...im/site/pack/packer/start/command-t/plugin/command-t.lua:36: in function <...im/site/pack/packer/start/command-t/plugin/command-t.lua:35>                                            

still remains

EDIT: this happens right after i call :CommandT

[wincent]

Going to grab a fresher build of Neovim and see if I can repro. I'll keep you posted @deathmaz.

[wincent]

I got a new build (after a bit of help here) but it doesn't repro for me with HEAD of Neovim's master, so it's not version-related.

I think the stack trace may be a bit misleading here because an error message like:

E716: Key not present in Dictionary: "rhs"

is the kind of thing you would expect to see when accessing a missing key in a Vimscript dictionary, like this:

:echo {}['rhs']

But that's obviously not happening here directly (there are no Vimscript calls). What I suspect is happening is that the topmost line in the stack trace is causing a new window to gain focus:

vim.api.nvim_set_current_win(self._main_window)

and then some autocmd is firing, and that's where the error is being thrown. The kinds of failure mode you expect from a bad call to nvim_set_current_win() are more like this:

:lua vim.api.nvim_set_current_win('garbage')
E5108: Error executing lua [string ":lua"]:1: Expected Lua number
:lua vim.api.nvim_set_current_win(nil)
E5108: Error executing lua [string ":lua"]:1: Expected Lua number
:lua vim.api.nvim_set_current_win({wat=true})
E5108: Error executing lua [string ":lua"]:1: Expected Lua number
:lua vim.api.nvim_set_current_win(100000000)
E5108: Error executing lua [string ":lua"]:1: Invalid window id: 100000000

@deathmaz do you have a copy of your dotfiles anywhere public so that I could try and repro this further locally?

[deathmaz]

no unfortunately, but i was able to find that https://github.com/jiangmiao/auto-pairs is causing the issue. If i disable the plugin, the issue is gone. I don't have any settings for the plugin, just use 'jiangmiao/auto-pairs' to install it

[wincent]

Interesting @deathmaz. I haven't reproduced this yet, but my working theory is that it's happening here in auto-pairs:

let info = maparg('<CR>', 'i', 0, 1)
if empty(info)
  let old_cr = '<CR>'
  let is_expr = 0
else
  let old_cr = info['rhs']
  " ... etc

It sees the <CR> mapping that Command-T sets up (insert mode), and that mapping doesn't have 'rhs' because it's actually a Lua callback. Passing in Lua callbacks to Neovim's vim.keymap.set() API is legit, so this seems like a bug in auto-pairs.

As a workaround, it may be possible to provide an override to the default mapping. But first, do something like this to confirm the theory:

require('wincent.commandt').setup({
  mappings = {
    i = {
      ['<CR>'] = false,
    },
  },
})

That will prevent the standard <CR> mapping from being created. You should be able to open :CommandT without it blowing up, although you won't be able to open a file; it will at least prove that the hypothesis is correct though. Then the challenge is to come up with an alternative mapping that has the same effect without using a Lua callback and therefore avoids triggering the bug in auto-pairs. This might be a bit tricky because the code that's doing the actual opening at the moment is private and can't be called externally... 🤔

In the meantime, you could assign a different mapping to open, just to see it working, like, for example:

require('wincent.commandt').setup({
  mappings = {
    i = {
      ['<CR>'] = false,
      ['<C-o>'] = 'open',
    },
  },
})

[deathmaz]

But first, do something like this to confirm the theory:

require('wincent.commandt').setup({
  mappings = {
    i = {
      ['<CR>'] = false,
    },
  },
})

yes, it worked indeed, I don't have the error any more

[wincent]

i guess you meant

Yes, I did. Thanks, @deathmaz.

Anyway, I did a little refactoring in 25ff997799bfc708d8c5d3a3198f78a67bc20fe8 that will allow you to work around the problem in auto-pairs by using a private API:

require('wincent.commandt').setup({
  mappings = {
    i = {
      ['<CR>'] = "<C-o>:lua require('wincent.commandt.private.ui').open('edit')<CR>",
    },
  },
})

Hopefully auto-pairs can be updated at some point so that this hack won't be needed any more (and that's why I'm not making this into an official API, as I don't want to permanently increase the API surface area; but FWIW, the internals probably aren't going to change that much — at least, I'll do my best not to change them). It's probably worth filing a bug report upstream in any case.

[deathmaz]

thank you, it seems that the plugin is not supported any more https://github.com/jiangmiao/auto-pairs/issues/309, i switched to https://github.com/windwp/nvim-autopairs instead. I think there's no need to produce workarounds in this case.

I have another question: each time i run :PackerCompile command i'm getting this message:

commandt.setup():                                                                                                                                                                               
  `commandt.setup()` was called after Ruby plugin setup has already run 

[wincent]

@deathmaz: These two files are in the plug-in:

1. plugin/command-t.vim
2. plugin/command-t.lua

Neovim will load them in that order — Vimscript always comes before Lua. So, in order to force the Lua to take precedence over the Ruby, you need call require('wincent.commandt').setup() before the Ruby has a chance to load. I would suggest moving your:

vim.g.CommandTPreferredImplementation = 'lua'

outside of the packer use callback, early on in your ~/.config/nvim/init.lua, but that's not quite enough... you would need to move the setup() call too, and I get why you can't do that without breaking from packer's intended usage patterns.

So, I think I need to soften this check:

https://github.com/wincent/command-t/blob/5390172818b6b582027e6803ad7602627dfa786e/lua/wincent/commandt/init.lua#L181-L186

🤔 — I think I can actually just drop it. As long as you hoist the vim.g.CommandTPreferredImplementation = 'lua' statement up outside of the packer callback, there won't be any unwanted messages, and everything should get initialized in the right way (ie. preferring Lua over Ruby).

Made that change in 05b434a7dd3e2963bf03d521da73e1ee20f2ce1c.

[deathmaz]

according to docs, packer has setup callback:

setup = string or function,  -- Specifies code to run before this plugin is loaded.

will it be fine to do like this:

    use {
      'wincent/command-t',
      run = 'cd lua/wincent/commandt/lib && make',
      setup = function ()
        vim.g.CommandTPreferredImplementation = 'lua'
      end,
      config = function()
        require('wincent.commandt').setup()
      end,
    }

or is it better to move vim.g.CommandTPreferredImplementation = 'lua' even before packer was initialised?

[wincent]

@deathmaz: You can try it from the setup callback and see if it works. If it doesn't work, you'll know because :CommandT will show the old Ruby UI instead of the Lua one, which is very visually different.

Hoisting the statement up is also fine, because all it is doing is setting a global variable with no immediate side-effects, which is basically "free" and won't slow down start-up in any measurable way (it probably takes about a microsecond to evaluate that statement, so there is not much benefit in deferring it).

[deathmaz]

thank you for the explanation, works fine with setup callback

[vinitkumar]

Hi @wincent.

I get this error:

Error detected while processing /Users/vinitkumar/.config/nvim/init.lua:
E5113: Error while calling lua chunk: /Users/vinitkumar/.config/nvim/lua/base.lua:43: module 'wincent.commandt' not found:
        no field package.preload['wincent.commandt']
        no file './wincent/commandt.lua'
        no file '/opt/homebrew/Cellar/luajit-openresty/2.1-20220411/share/luajit-2.1.0-beta3/wincent/commandt.lua'
        no file '/usr/local/share/lua/5.1/wincent/commandt.lua'
        no file '/usr/local/share/lua/5.1/wincent/commandt/init.lua'
        no file '/opt/homebrew/Cellar/luajit-openresty/2.1-20220411/share/lua/5.1/wincent/commandt.lua'
        no file '/opt/homebrew/Cellar/luajit-openresty/2.1-20220411/share/lua/5.1/wincent/commandt/init.lua'
        no file './wincent/commandt.so'
        no file '/usr/local/lib/lua/5.1/wincent/commandt.so'
        no file '/opt/homebrew/Cellar/luajit-openresty/2.1-20220411/lib/lua/5.1/wincent/commandt.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
        no file './wincent.so'
        no file '/usr/local/lib/lua/5.1/wincent.so'
        no file '/opt/homebrew/Cellar/luajit-openresty/2.1-20220411/lib/lua/5.1/wincent.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
        [C]: in function 'require'
        /Users/vinitkumar/.config/nvim/lua/base.lua:43: in main chunk
        [C]: in function 'require'
        /Users/vinitkumar/.config/nvim/init.lua:1: in main chunk
Press ENTER or type command to continue

Any ideas how to fix this?

This is how I installed it

diff --git a/lua/plugins.lua b/lua/plugins.lua
index 5655c32..898147c 100644
--- a/lua/plugins.lua
+++ b/lua/plugins.lua
@@ -43,5 +43,16 @@ packer.startup(function(use)
   use 'lewis6991/gitsigns.nvim'
   use 'dinhhuy258/git.nvim' -- For git blame & browse
        use 'tpope/vim-commentary'
+       use "ellisonleao/gruvbox.nvim"
+       use {
+               'wincent/command-t',
+               run = 'cd lua/wincent/commandt/lib && make',
+               setup = function ()
+                       vim.g.CommandTPreferredImplementation = 'lua'
+               end,
+               config = function()
+                       require('wincent.commandt').setup()
+               end,
+       }
 end)

[wincent]

Not a Packer user myself but that config looks right to me. I'm not familiar with how you're supposed to use it but the stack trace shows that it's looking for wincent.commandt in a bunch of places and finding it nowhere — is there some Packer command you have to run to get it to actually pull down the latest HEAD of main/master? (Like :PackerUpdate or something?)

@vinitkumar, can you verify that the file you're trying to require really is on the filesystem? Specifically lua/wincent/commandt/init.lua.

[wincent]

FWIW @vinitkumar, I just installed Packer in a VM and see the same error as you do if I run :PackerCompile. But if I run :PackerInstall, I see it download the Command-T source code and it works.

[vinitkumar]

Turns out I was loading in another file require('wincent.commandt').setup(), and that was causing the error.

Thanks for taking the time and effort to help out. I will test it out on my prod codebases and report bugs. Thanks 🙇🏼

[deathmaz]

Hi @wincent ,when i press Ctrl-w in nvim buffer in insert mode, it will delete the word, the same goes for example when i use https://github.com/ibhagwan/fzf-lua. But this is not the case for command-t. Should it be explicitly defined somehow?

[wincent]

when i press Ctrl-w in nvim buffer in insert mode, it will delete the word, the same goes for example when i use https://github.com/ibhagwan/fzf-lua. But this is not the case for command-t. Should it be explicitly defined somehow?

I'm not sure. This is because the prompt window in Command-T uses :set buftype=prompt. Try setting that in a normal Vim window and you'll see that <C-w> isn't mapped in that kind of window. Quoting :h prompt-buffer:

The CTRL-W key can be used to start a window command, such as CTRL-W w to
switch to the next window.  This also works in Insert mode (use Shift-CTRL-W
to delete a word). When leaving the window Insert mode will be stopped.  When
coming back to the prompt window Insert mode will be restored.

So... we could try to set up an override for the behavior that Vim wants, but I am not sure whether that would be a good idea or not. Would Shift-CTRL-W work for you @deathmaz?

[deathmaz]

thank you for the explanation. The thing is that i'm using kitty terminal and by default Shift-CTRL-W is mapped to close current kitty window. I checked how it's implemented in telescope and it seems they mapped <C-w> to execute <c-s-w>. I tried this for command-t:

        require('wincent.commandt').setup({
          mappings = {
            i = {
              ["<C-w>"] = "<c-s-w>"
            }
          }
        })

and it works fine at first sight

[wincent]

I tried this for command-t

Yep @deathmaz, I was going to suggest something like that. Not sure if we should make it the default or not, but I am leading towards "yes, we should".

[yujinyuz]

I had a similar issue with neo-tree and applied the fix inside nvim-autopairs.. it's quite weird though https://github.com/nvim-neo-tree/neo-tree.nvim/pull/376

[wincent]

Ok @deathmaz, @yujinyuz; seems reasonable; added to the default mappings in https://github.com/wincent/command-t/commit/1d40403af6ded306967024d0badf0fe7dba4b9b3.

[vheon]

If you try to run :CommandTGit in a directory which is not a git repo you get something like this

I guess in the old version it would fallback to the files scanner so now is a little uglier.

[wincent]

Yep, this is a known issue @vheon. There is no fallback implemented yet for any of these things. Possible failure modes include:

• Running :CommandTGit when git is not installed.
• Running :CommandTRipgrep when rg is not installed.
• Running :CommandTWatchman when watchman is not installed (or there is some other problem with Watchman daemon).

I had been postponing figuring out a solution for this because I wasn't sure what the best approach was. The problem is that the scanners all degrade "gracefully"; instead of returning errors, they effectively just return empty lists. As such, there are a number of main options, not necessarily mutually exclusive of one another:

1. We teach the scanner_t type to include a status member that allows us to communicate something back to the callers.
2. We teach the callers to interpret an empty result list as a cue to try again using a fallback mechanism; in an empty directory this would give a false negative but a relatively harmless one (ie. you might run :CommandTRipgrep in an empty folder, and Command-T would take that as a cue to try again with the standard scanner, which would of course also return an empty list).
3. If we do "2", and maybe even if we don't, we may also want to swallow stderr so it doesn't leak back in any visible way (ie. that would mean changing a call to git ... into git ... 2> /dev/null etc). The only catch is that this may make trouble-shooting harder (users could edit out or change the redirect, I guess).
4. We teach the callers to be a bit smarter before even trying to run a command that will definitely fail; eg. we might check to see if rg exists before trying to run it.

I haven't thought deeply on it, but I feel like "2" + "3" sound like a reasonable idea, for starters. We might later want to do "4". I don't find "1" very appealing at this stage.

[wincent]

I pushed https://github.com/wincent/command-t/commit/005b695588630b06f2cf15444858f3b4dd320242 to implement a couple of those fallback ideas (specifically "2" and "3", like I said). Not sure if it's the best approach, but it's worth a shot. 🤷

[vheon]

My initial thoughts were simply to not let the error be displayed like that and maybe push a message through vim.notify, but before reading the code I thought that you were spawning the process from Lua through the job api and then send the candidates to the C code through the slab but I'm seeing now that your're calling the command in the C code directly so it wouldn't be that easy.

Anyway I'll give it a spin tomorrow at work, thanks for the quick response and fix!

[vheon]

@wincent before discovering the problem with scanners.git.untracked #405 I was puzzled because it was using the fallback to the find scanner but the title in the Prompt window was kept as git. Do you think command-t should signal somehow that the candidates I'm seeing are not coming from the scanner I asked for but that it fallback to something else?