🆕 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".
• Release plan for Lua rewrite #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.

[wincent]

Ok @deathmaz, @yujinyuz; seems reasonable; added to the default mappings in 1d40403.

[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 005b695 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?

[wincent]

@vheon: I had thought about that while implementing the fallback, but didn't want to make any hasty decisions. Like, should the title include the word "fallback" to make it clear why the "wrong" scanner is being used? Would an :echomsg be better? Should it be displayed in some other way? I agree with you that we should say something, but I wasn't sure what the best way to do that might be.

[vheon]

In an ideal world probably a user might want the title to say something like:

CommandT [ find (fall-backed from git) ]

So that I know what I ended up with and what I actually wanted to with a vim.notify saying why the first scanner wasn't usable. This way the notification about the error can be read if found relevant but the fact that we fall-backed is kept persistent in the Prompt title.
Considering, however, that in a properly configured environment the fallback is rare to happen and that as you mentioned early the scanner is launched in the C code and we should have then a mechanism to pass the error to the Lua code I'm not sure if the whole notification is worth the trouble. I mean, yes it would be a much complete experience but the ROI isn't there I think.

[wincent]

@vheon Current proposal for communicating that a fallback happened is up in c16b272 — it just shows "fallback" in the end because I figure that we can't show complete diagnostic info in the title area, so there's not much value in saying more than that — it's just a cue that something didn't work. We can definitely looking at providing more detail via vim.notify() in the future though.

[vinitkumar]

@wincent Enjoying this plugin with my neovim. One small gripe(mostly because I couldn't find it in documentation), how do I make it ignore directories (e.g: node_modules)? It slows massively because it also indexes node_modules from my project.

[vinitkumar]

@wincent Enjoying this plugin with my neovim. One small gripe(mostly because I couldn't find it in documentation), how do I make it ignore directories (e.g: node_modules)? It slows massively because it also indexes node_modules from my project.

Alright, I think vim.cmd[[ let g:CommandTFileScanner = "git"]] is the way to go, or is there a better way for this?

[wincent]

@vinitkumar: If you're using the older Ruby implementation, there are a number of ways to ignore files. Using the git scanner is one of them (that's what your command does). If you have/use Watchman, using the watchman scanner is another option (depending on how it is configured it may or may not index node_modules, but the whole point of Watchman is to be fast regardless). Another is to configure g:CommandTWildIgnore or Vim's own 'wildignore' setting (as described in command-t-wildignore).

In the newer Lua implementation, similar story — you can use :CommandTGit or :CommandTRipgrep (which will all ignore similar files), or :CommandTWatchman (which is supposed to be fast by design). In general, the Lua implementation should be faster anyway — perhaps fast enough that you don't care about the cost of indexing/searching in node_modules. I haven't (yet) added any ignore-related settings in the Lua implementation; I might if there is demand for them (but my preference is to keep things simple — using the Git finder is a simple way to search only "noteworthy" files).

[vinitkumar]

@vinitkumar: If you're using the older Ruby implementation, there are a number of ways to ignore files. Using the git scanner is one of them (that's what your command does). If you have/use Watchman, using the watchman scanner is another option (depending on how it is configured it may or may not index node_modules, but the whole point of Watchman is to be fast regardless). Another is to configure g:CommandTWildIgnore or Vim's own 'wildignore' setting (as described in command-t-wildignore).

In the newer Lua implementation, similar story — you can use :CommandTGit or :CommandTRipgrep (which will all ignore similar files), or :CommandTWatchman (which is supposed to be fast by design). In general, the Lua implementation should be faster anyway — perhaps fast enough that you don't care about the cost of indexing/searching in node_modules. I haven't (yet) added any ignore-related settings in the Lua implementation; I might if there is demand for them (but my preference is to keep things simple — using the Git finder is a simple way to search only "noteworthy" files).

I am using lua implementation. Perhaps, I will peek into your nvim config and see what you have done?

[wincent]

@vinitkumar

I am using lua implementation. Perhaps, I will peek into your nvim config and see what you have done?

Ah, there is nothing to configure if you want to use the Git finder. Just invoke :CommandTGit instead of :CommandT. If you want to set up a mapping for that, something like this would do:

vim.keymap.set('n', '<Leader>t', '<Plug>(CommandTGit)')

This is (kind of) documented here.

[vheon]

@wincent I'm not sure if this is actually a bug or if simply I'm not used to the sorter engine of Command-T:

I'm "working" on my dotfiles (https://github.com/vheon/home) using the git scanner with this configuration
https://github.com/vheon/home/blob/137693a1866da57f026231b55b4423efdffee81b/roles/neovim/files/nvim/lua/plugins.lua#L175-L180

If in the root directory I run :CommandTGit and search for tmux this is what I get

but if I search for .tmux this is what I get

Is it on purpose?

[wincent]

@vheon Yes, dotfiles are ignored by default. There are two settings that change this behavior:

• always_show_dot_files (defaults to false).
• never_show_dot_files (defaults to false).

With these defaults, you don't see the dotfiles unless your query includes the dot. With always_show_dot_files = true, you will see them regardless of the query. With never_show_dot_files = true, you won't see them even if your query includes a dot. Setting both to true doesn't make any sense, and Command-T will print an error if you try to do so.

[vheon]

As usual the RTFM would have solved my confusion without making noise here 😞 Thanks @wincent!

[LunarWatcher]

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.

@wincent For the record, you were mostly correct.

I stumbled into this independently a while ago (I maintain a fork of jiangmiao/auto-pairs, where the bug was triggered by lsp-zero), and opened an issue about it in the nvim repo. Strictly speaking, it's neovim that's at fault here. Yes, mapping Lua callbacks is valid, but Neovim mishandles how the callbacks are represented in a different API call, and also failed to document it. Nvim can either fix it to make the return values consistent, or document the actual behaviour of maparg() in nvim (the latter of which would be an incompatibility that's incredibly annoying to integrate into a plugin that isn't exclusively for nvim, but whatever; problem for future me if the issue ever gets handled).

Because an existing API function's return values isn't respected (nor is the outlier documented, making workarounds annoying on a good day), and lua function mappings don't return a value compatible with maparg()'s docs, the function explodes. Until the exact behaviour is documented (i.e. the behaviour is documented so the function can be considered stable again), or maparg is fixed, the bug is in Neovim, just elsewhere. I doubt it's going to be fixed any time soon though.

There are a few workarounds though, one of which you've already found; mapping it to something other than a lua function is fine, because that returns a valid value from maparg.

However, due to the nature of command-t, I'll argue disabling auto-pairs, or at least the cr map, in the command-t buffer is a good strategy. No mapping means no weird return values, and I doubt command-t benefits from the <cr> map in auto-pairs anyway.

With jiangmiao, I'd recommend running let b:autopairs_map_cr = 0 . If not in command-t itself, an autocmd FileType for the end-user also works fine. It just needs to be executed before auto-pairs is run¹. Using let b:autopairs_loaded = 1 is also an option, and this fully prevents the plugin from loading.

My fork (which has the same problem) has a buffer filetype blacklist as well:

let g:AutoPairsFiletypeBlacklist = ["<insert command-T filetype here>"]

and works similarly to setting b:autopairs_loaded. The main advantage is that it can be set without waiting for the buffer to load, so no weird init order problems, if any exist. That said, my fork will complain loudly and explicitly (with some solutions) if rhs isn't present, so it's at least slightly more clear about the problem.

Anyway, welcome to the world of trying to map common keys (cr, space, tab, and backspace) in Vim - it sucks :p

Footnotes

1. If command-t executes after auto-pairs, I assume it'll override <CR> instead, which is fine. The problem only appears when command-t, or any other plugin, maps a lua callback before auto-pairs tries to map <CR>. If the execution order is the other way around, it's not a problem. ↩