Vim on Clément Joly – Open-Source, Rust & SQLite

Vim Registers

Thu, 29 Jan 2026 14:05:41 +0000

Copy-paste History

Implicit

Register	Content
`"`	Effectively last used register. Writes to register `0`.
`0`	Last yank.
`1`	`d`/`c` with `%`,`(`, `)`, `, `/`, `?`, `n`, `N`, `{` and `}` or whole line.
`-`	Last small delete (less than a line). Can be the same as `1`.
`2`-`9`	Last content of `1`, `2`, etc. `9` is lost.
`+` `*`	System clipboards (X11/Wayland clipboard and primary).

Explicit

Register	Content
`a`-`z`	Named, use freely. Doesn’t fill numbered registers.
`A`-`Z`	Append to that named register.

Read-Only

Register	Content
`.`	Last inserted text (similar to `.` to repeat).
`%`	Current file name.
`#`	Alternate file name.
`:`	Last executed command line. Run with `@:`.

No Read or Write

Register	Content
`=`	Run an expression.
`_`	Black hole.

Cargo Info in Neovim, or How Simple Features Go a Long Way

Mon, 21 Oct 2024 22:39:34 +0100

⚡ TL;DR

Open cargo info in Vim or neovim for the package under the cursor using these 4 lines of Lua.

Cargo info

Rust 1.82 was released a couple of days ago. It’s packed with improvements, but one in particular caught my eye. Cargo now has a info sub-command. It displays details about a package in the registry from the comfort of your terminal. Here is an example:

$ cargo info lazy_static
lazy_static #macro #lazy #static
A macro for declaring lazily evaluated statics in Rust.
version: 1.5.0
license: MIT OR Apache-2.0
rust-version: unknown
documentation: https://docs.rs/lazy_static
repository: https://github.com/rust-lang-nursery/lazy-static.rs
crates.io: https://crates.io/crates/lazy_static/1.5.0
features:
  spin        = [dep:spin]
  spin_no_std = [spin]
note: to see how you depend on lazy_static, run `cargo tree --invert --package lazy_static@1.5.0`

Vim and neovim generally composes well with other terminal tools. So how can we easily integrate cargo info and neovim?

Demo

The goal is to press a key and display the cargo info for the crate under the cursor in a Cargo.toml file. Like this:

To run this asciicast without javascript, use asciinema play https://joly.pw/blog/cargo-info-in-neovim/demo.json with Asciinema

Introducing `keywordprg`

In the above demonstration, we press K over a crates name. Then neovim executes the program set in keywordprg, appending the work under the cursor. So if the cursor is on lazy_static

[dev-dependencies]
iai = "0.1"
insta = "1.40.0"
lazy_static = "1.5.0"
#   ^ cursor is here when we press K
mktemp = "0.5"

and keywordprg is set to cargo info, the command cargo info lazy_static is executed in a new terminal.

We can further improve this. Since we want a fast answer (without checking the remote repository), let’s use cargo info --offline. And we would like pretty colors, let’s force that using --color=always.

We only want to alter keywordprg when a Cargo.toml file is edited, because it makes no sense to call cargo info in a Python file. We can use a ftplugin for toml files for that¹, so that the plugin is only loaded and executed when a toml file is executed. Furthermore we can change the setting only when opening a file named “Cargo.toml”, instead of changing it for every toml file. We can put the necessary configuration in ~/.config/nvim/ftplugin/toml.lua², like so:

if vim.endswith(vim.fn.bufname(), "Cargo.toml") then
  vim.opt_local.keywordprg = "cargo info --color=always --offline"
end

-- Add chars that are often part of keys, especially in rust crates
-- (https://toml.io/en/v1.0.0#keys)
vim.opt_local.iskeyword:append "-"

The Lua code above also changes the iskeyword preference. This is so that tokio-test is considered as one word (a “keyword” in Vim parlance), instead of two (tokio and test). With this set, doing K on tokio-test will behave properly, because tokio-test is passed to the command, instead of just tokio.

One final note: the above configuration was the only thing sourced in the demo. All the rest is default, vanilla, neovim 0.10.2. And this does not even require recent neovim features, it has been supported in Vim for many years.

Learnings

Obviously this could be further refined. Other options could be passed to cargo info, like -v to make it more verbose and list dependencies. Some more scripting could add useful features to further improve the integration. For this particular problem, there are even a full plugin with many more features. But the point is to showcase a simple and robust integration³, applicable in a wide variety of contexts. In particular when the use case is too niche, a full plugin is too costly to write and maintain for the benefits it provides.

Let’s highlight the takeaways from this post that are applicable in a wide variety of contexts.

First, a number of Neovim commands can do something with the keyword under the cursor. Adjusting what counts as a keyword boundary is often, but not always, done in the syntax file of a particular language. Or you may just want to make a different trade off and set your own iskeyword value.

Second, the K mapping is often used to look up a word in a documentation (it is set to open man pages by default). It even works in visual mode, looking up the selected text. And arbitrary Vim or shell commands can be used, instead of the default :Man.

Please do read the corresponding parts of the Vim manual linked in this section to learn more. Next time, you may come up with your own quick integration between Vim and another tool. Happy hacking!

✏ Edit

2024-10-22: Clarify why we use nvim settings instead of a plugin like crates.nvim

To keep the example simple, we don’t clean-up the local preferences that are set here. See the documentation for best practices when sharing ftplugins. ↩︎
It’s also possible to do this in Vimscript instead of Lua. ↩︎
Thanks to @dpom@fosstodon.org for pointing out that crates.nvim has that feature already. ↩︎

From UltiSnips to LuaSnip

Sun, 15 May 2022 07:06:49 +0100

⚡ TL;DR

LuaSnip is fast and doesn’t have to be complicated. Give it a try!

ℹ️ About UltiSnips

Local NeoVim Plugin Development

Tue, 02 Nov 2021 14:28:13 +0000

ℹ️ Note

2023-05-20: Updated to account for the features of NeoVim 0.9 and obsolete plugins

You have found a (Neo)Vim plugin that you want to fiddle with, either to contribute changes upstream or for your own use. Sounds familiar? Here are some tips and tricks I use for my NeoVim plugin development. The aim of these small tricks is to iterate faster on changes, by loading your changes in a live NeoVim instance as quickly as possible.

We will use telescope-repo.nvim as an example but it is applicable to any plugin (although some sections of this post only apply to Lua NeoVim plugins).

Load Local Plugin Version

When developing, you make your changes to a local git repository, for instance ~/ghq/github.com/cljoly/telescope-repo.nvim. To test those changes, you need to tell NeoVim to load the plugin from the local repository, instead of using the location set by your plugin manager. To do this, just append the following near the beginning of your init.lua file:

vim.opt.runtimepath:prepend("~/ghq/github.com/cljoly/telescope-repo.nvim")

Note the :prepend. It will ensure that your local dev version will override anything installed by your nvim package manager. This way no need to uninstall your plugin when developing!

Reloading Changes in a Live NeoVim Instance

You have now made some changes to the plugin that you would like to test. In doing so, you start a second NeoVim instance and open a set of files, change a bunch of settings…

You then change something in the code, but you don’t want to restart you test NeoVim instance, as that would mean reopening files and altering settings all over again. But just doing require(…) is not enough, because require caches already loaded files and doesn’t reload them if they are loaded already.

If you use telescope, you can use the reloader picker. You can then select the module you want to reload, like so:

Telescope reloader in action

You type “telescop repo” and the corresponding Lua module surfaces. It will be reloaded when you hit Enter.

Under the hood, telescope reload uses plenary:

require("plenary.reload").reload_module(selection.value)

which handle various cases (like whether impatient.nvim is used at the time of writing). Despite this careful handling, sometimes, a plugin may not fully reload. In that case, you want to automate as much of the setup as possible on NeoVim restart.

If All Else Fails

Sometimes, a “soft” reloading is not enough and you need to restart NeoVim. For instance, if we are testing the :Telescope repo list command and need to open /tmp/file, we can do:

nvim +'Telescope repo list' /tmp/file

and even place this in an infinite loop with a sleep command, to escape the loop more easily once we are done.

Of course, you will want to replace Telescope repo list with the command you want to test. You can also add more setup by supplying multiple “+'…'” arguments)

All Set

Now that you are all set, you can go on and write complete plugins! You may find the following resources useful in your journey:

the :help lua-guide.txt has a lot of resources to write plugins and alter NeoVim’s configuration,
- 2n.pl walks through writing a simple plugin,
set up a Language Server Protocol for Lua,
- and maybe even a full-blown plugin for Lua plugin development,
to test a piece of Lua code real quick, :=my.lua.code(here) is great. For bigger pieces of code, luapad can be useful: it provides a scratch buffer where the result of a Lua snippet is displayed as you type.