nvim-various-textobjs turns 30 selection shapes into motions

Four columns describe every object the plugin adds

The list of text objects is a table, and the table is the design. Each row names a text object, describes it in a sentence, states whether it has an inner and an outer form, records whether it can be forward seeking, and gives the default keymaps. That is more information per row than most plugin documentation gives, and it lets a reader answer the question that actually matters when choosing a motion, which is not what the object selects but how it behaves at the edges. An object like anyBracket is described as being between any parentheses, square brackets or braces in one line, with the outer form including the brackets, marked as forward seeking on a small scale, and bound to io and ao. An object like toNextClosingBracket goes from the cursor to the next closing bracket and can span multiple lines, and it is marked as forward seeking on a small scale too, with a single key C.

The indentation objects are the plugin's centre of gravity

Several of the objects are about indentation, which is the gap the standard Neovim text objects leave. The indentation object selects surrounding lines with the same or higher indentation, and the readme points to an overview from the separate vim-indent-object plugin for how it behaves, with the keymaps ii, ai and aI and a parenthesised iI. The restOfIndentation object goes downwards through lines with the same or higher indentation and is bound to R. The greedyOuterIndentation object is the outer indentation expanded to blank lines, and the description says what it is for, getting functions with annotations, with ag and ig as the keymaps. An outer form that includes a blank, like the standard ap and ip, is how the table records that behaviour. These are the objects that make the plugin worth a separate repository rather than a few lines in a user configuration.

The smaller objects are the ones you will actually reach for

The rest of the table is a set of surgical selections, and they are the ones that save the most time in daily editing. The subword object selects a segment of a camelCase, snake_case or kebab-case word, with the outer form including the trailing or leading separator character, bound to iS and aS. The value object takes the value of a key value pair or the right side of an assignment, excluding a trailing comment, and the description notes it does not work for multiline assignments, with iv and av. The key object is the other half, the key of a key value pair or the left side of an assignment, with the outer form including the equals sign or the colon, bound to ik and ak. There is also anyQuote for between any unescaped quote character in one line, toNextQuotationMark which can span multiple lines, restOfParagraph which is like the closing brace but linewise, entireBuffer for the whole file, lineCharacterwise for the current line but characterwise, and column which goes down until the indent or a shorter line and accepts a count for multiple columns. The number object is described as similar to the built in increment command, with an inner form of only digits and an outer form that includes the sign and the decimal point, and url selects http links or any other protocol.

The advanced section is where the plugin goes beyond selection

The table of contents lists a set of advanced topics that are not about text objects at all, which tells you the plugin is more than a catalogue. There is a section on dynamically switching text object settings, so the behaviour of a given object can change per buffer or per filetype rather than being fixed at install time. There is a section on what ii on an unindented line should do, and the title states the intended behaviour, that it should select the entire buffer, which is a precise edge case that most implementations leave undefined. There is a section on smarter gx and gf, the built in commands that act on whatever is under the cursor, which in the standard behaviour are unrelated to text objects at all. There are also sections on deleting surrounding indentation, yanking surrounding indentation, indenting the last paste, and going to the next occurrence of a text object. The last of those is the one that changes the model, because it turns a selection primitive into something you can iterate with, and the readme has an open section for other ideas.

Configuration, custom keymaps and a deprecation

The structure of the readme is a good guide to the plugin's shape. There is an Installation section, then a Configuration section with an Options subsection and a Use your own keymaps subsection, then a section on deprecated filetype specific text objects. That deprecation is the interesting part, because it says the plugin's direction is toward a smaller, more general set rather than a growing pile of special cases, and it implies that anything you had configured for the old filetype specific objects will need replacing. The Options subsection suggests the text objects are configurable, which is consistent with the advanced section on switching settings dynamically, and the custom keymaps section is where you avoid the collision problem, since the defaults include single letters like C, Q, R, L, n and a pipe, and several of those are already bound to something else in a typical configuration. The readme links to a dotfyle listing for the plugin, and the repository itself is small and mostly Lua.

Where the plugin stops

Two limits are worth stating. The first is that this is a bundle of motions and not a general editing framework, so the question it answers is selection and deletion, not navigation or refactoring, and a plugin that also handles those problems will have a different feel. The second is the keymap collision, which the readme addresses with a dedicated custom keymaps section, and it is the practical reason the defaults are the way they are. A single-letter default like n for nearEoL is convenient in a clean configuration and unusable in a busy one, and the plugin cannot know what else you have bound. The repository also carries the usual small-project tooling, a stylua configuration for Lua formatting, a luarc configuration for the language server, a rumdl configuration for the markdown linter, a typos configuration and a harper dictionary, all of which suggest the project is maintained with the same care as its code, even though the last push was on 2026-08-03 and there are no tagged releases to check a change against.

Editorial conclusion

nvim-various-textobjs suits a Neovim user who already has the built in text objects and keeps hitting the case they do not cover, such as an indented block in a YAML file or the key of a key value pair, and it suits anyone who wants a written catalogue of selection shapes to choose from. It is the wrong tool for a user who has not yet learned the standard objects, since the plugin assumes you know what an inner and outer object is, and it is the wrong tool if you want one specific behaviour in a single file type, since the README documents that filetype specific text objects are deprecated in favour of the general set. Before installing it, read the table of objects and check the default keymaps against the ones you already use, because several of the defaults are single letters that collide easily. The last push was on 2026-08-03 and the repository publishes no releases.

Frequently asked questions

Official sources

1. chrisgrieser/nvim-various-textobjs on GitHub
2. Issues
3. License: MIT
4. README