actions-preview.nvim: seeing what an LSP code action will do before you take it

Code actions without seeing what they do

actions-preview.nvim is a Neovim plugin that previews code with LSP code actions applied. The problem it solves is narrow and familiar: your language server offers a code action, you pick it, and the buffer changes. If the action was wrong, or applied to more than you expected, you find out afterwards.

The plugin's answer is to run the action in a scratch state and show you the diff between the current buffer and the result. You then decide whether to keep it. The README's installation snippet shows the intended entry point, a mapping on the visual and normal modes bound to the code_actions function:

use {
  "aznhe21/actions-preview.nvim",
  config = function()
    vim.keymap.set({ "v", "n" }, "gf", require("actions-preview").code_actions)
  end,
}

That is the whole integration for packer.nvim. The plugin is GPL-3.0 licensed, written in Lua, and the last push to the repository was on 2026-04-22, with no GitHub releases published, so installation is from the source repository rather than a tagged artifact.

The audience is a Neovim user with a language server configured who wants a confirmation step in the middle of an edit-refactor loop, and who is willing to configure a picker and a diff algorithm. The plugin is a previewer, not a code action engine, and it does not replace the LSP client's own action list.

Four picker backends and why that matters

The plugin does not bring its own user interface for choosing the action. It lists four backends it can drive: telescope.nvim, mini.pick, nui.nvim and snacks.nvim. The configuration makes the choice explicit, with a priority list of preferred backend:

  -- priority list of preferred backend
  backend = { "telescope", "minipick", "snacks", "nui" },

That ordering is a list of preference rather than a requirement, and each backend has its own options block in the setup function. The telescope block extends the dropdown theme with a table of your own, and it exposes two function hooks: make_value for building the table of values to display, and make_make_display for the function used in the display of an entry, with the README pointing at the telescope documentation for entry_display.

The nui block is the most detailed, because nui.nvim is a component library and the plugin exposes its layout, its selection component and its preview area separately. The component direction is col or row, the keymap for the selection component is configurable, the layout has a position and a size with width, height, min_width and min_height, and the preview and select areas each have their own size and a border with a style and a padding. The relative option is set to editor.

The snacks block is the smallest, a layout with a preset of default and a type annotation of snacks.picker.Config.

Why four backends rather than one is worth noting for an adopter. It means the plugin does not force a picker dependency on you, which matters for people who moved off telescope, and it means the plugin has to maintain compatibility with four separate APIs as they change. The trade-off is flexibility against the maintenance surface that comes with it.

The diff options and the highlight_command list

Two configuration areas carry most of the behaviour.

The first is the diff table, and the default is minimal:

  -- options for vim.diff(): https://neovim.io/doc/user/lua.html#vim.diff()
  diff = {
    ctxlen = 3,
  },

The README points at the vim.diff documentation for the full option set, and the example config shows the additional ones in use, an algorithm set to patience and ignore_whitespace set to true. That is a meaningful choice for a preview, because patience diff is slower but produces a more readable alignment for the kind of structured edits refactors produce, and ignoring whitespace stops a reformat from filling the preview with noise. The algorithm option depends on your Neovim build supporting it, which is worth checking before you configure it.

The second is highlight_command, which is disabled by default and must be set by you. It is a priority list of external commands that highlight the diff, searched from the top for whichever is available. The README shows the three built-in helpers, hl.delta, hl.diff_so_fancy and hl.diff_highlight, plus hl.commands for a pipeline of your own and hl.with_pager for the same with a pager.

The arguments are optional in each case, with sensible defaults assumed: delta with no argument means the delta binary, diff-so-fancy with no argument means diff-so-fancy and less -R, and diff-highlight with no argument means diff-highlight with a colordiff and less -R command. The existence of less is optional, and colordiff and less are optional for diff-highlight as well.

There is a platform caveat stated for Windows users, and it is specific rather than general. This feature only works with PowerShell and does not operate with cmd.exe, so you need to set your Neovim up to use PowerShell by following the shell-powershell help.

The list also accepts a function, which is executed during setup. The README notes this is useful for require calls at definition time, such as in lazy.nvim.

The limitation the README is most candid about

There is a FAQ entry that answers the question every user eventually asks, and its title is the error message you will otherwise see: Preview is not available for this action instead of a diff.

The short answer is implementation limitations in some language servers. It is not possible to compute and display diffs in these language servers, because they realize code actions by means of a command rather than a text edit. A code action that says run this shell command to fix the problem gives the plugin nothing to diff against your buffer, so it cannot show you a preview.

That is the hard boundary of the whole approach, and it is a property of the server rather than of the plugin. The server decides what a code action is, and the plugin can only preview the ones that are expressed as edits. Servers that return edits for most actions, which is the common case for a language server that knows how to rewrite a specific range, will work well.

The practical consequence is that the preview is available for some actions and not others, and the failure mode is a message rather than an empty pane, which is a reasonable way to handle it. But if the code actions you most want to check are the ones your server expresses as commands, this plugin will not help you, and no configuration will change that.

It is also worth being clear that this plugin does not change what an action does. It shows you the result of applying it, and you accept or reject. The action still comes from your language server and still does what the server says it does.

Reproducing the README's own look

The FAQ includes a configuration to reproduce the appearance of the README, which is a small but useful sign of how the plugin is meant to be used. The config sets the telescope sorting_strategy to ascending, the layout_strategy to vertical, and a layout_config with width 0.8, height 0.9, prompt_position top, a preview_cutoff of 20, and a preview_height function that returns max_lines minus 15.

require("actions-preview").setup {
  telescope = {
    sorting_strategy = "ascending",
    layout_strategy = "vertical",
    layout_config = {
      width = 0.8,
      height = 0.9,
      prompt_position = "top",
      preview_cutoff = 20,
      preview_height = function(_, _, max_lines)
        return max_lines - 15
      end,
    },
  },
}

Note that this config uses telescope = with a table rather than the vim.tbl_extend call in the default configuration, so the two forms differ and the telescope-specific block is replaced rather than merged when you write it this way. That is a detail worth copying carefully, because in Lua a table assignment replaces the default and the extend call merges with it.

The layout choices in the README config are tuned for a large preview, which makes sense for this plugin. A diff is the payload, and the picker list is a menu rather than the content, so a wide window with a tall preview is the sensible default for reading a refactor.

The repository layout is small and consistent with a focused plugin. There is a lua/ directory for the plugin code, a .github/ directory, a LICENSE, a README.md, and a stylua.toml, which is the configuration for the StyLua formatter used by Lua projects. There is no separate documentation directory, no test directory and no release configuration in the listing, so the README and the FAQ inside it carry the whole documentation burden, and there are no GitHub releases published.

Editorial conclusion

Adopt actions-preview.nvim if you use Neovim with an LSP and you routinely accept code actions without reading them, and you want to see the diff first. Do not adopt it if your language server implements code actions as opaque commands, because the plugin cannot show a diff for those, or if you are on Neovim older than 0.10, which is the stated minimum. Verify first that your server returns a text edit rather than a command, that one of the four picker backends is installed, and that the diff algorithm you configure in the diff table is available in your Neovim build.

Frequently asked questions

Official sources

1. aznhe21/actions-preview.nvim on GitHub
2. Issues
3. License: GPL-3.0
4. README