He prefers clean, minimalist setups with no unnecessary redundancy, a principle reflected in his dotfiles configuration. He enjoys coding, although his academic responsibilities and personal life often limit the time he can dedicate to it.

Amal created and actively maintains Shownamer, a lightweight Python-based CLI tool that retrieves metadata for locally stored TV shows, movies, and other media files, with a primary focus on batch renaming. He is currently improving its functionality and stability while avoiding unnecessary complexity and feature bloat.

He also created Zitchdog, a purple-based Neovim theme that supports many of the tools commonly used by developers, including terminals and CLI applications. Although he has had less time to maintain it recently, it remains one of his active projects.

Amal has also worked on several private client projects through freelancing. Despite having limited time for personal development work, he continues to maintain Shownamer and Zitchdog because they are part of his own workflow. Whenever he encounters an issue while using them, he makes an effort to fix it.

Neovim & Terminal

For his code editor, Amal uses Neovim. He migrated to it a few years ago after becoming frustrated with VS Code. Before that, he had used Sublime Text for quite some time.

Even then, he was interested in joining the Neovim community, so he tried sideloading Neovim despite not yet knowing how to use it. He simply wanted to explore it, and it eventually became one of the best decisions he had made. Over time, Neovim gradually became his daily driver.

Amal has now been using Neovim for around three years and continues to learn new things from creators such as TJ DeVries. He is also a fan of creators like Takuya Matsuyama and Adib Hanna, particularly the way they design and organize their development workflows. He even once asked Adib for his wallpaper on Reddit.

My workflow is very Git dependent, and as of late I try to shove tmux into wherever I can (I wish to master the defaults, as I will be working on a lot of servers in the future). I use lazygit for my Git workflow management as of late, as it gets the job done much faster than manually running git commit -m “foo”. I use delta for diff highlighting in lazygit, and a custom config that does not stray far from the defaults for tmux. Ever since I switched to Kitty (terminal), I had stopped using tmux, since the manual tabs and sessions in Kitty seemed to work really well for my workflow, but I am trying to go back to tmux lately.

I usually only use tiled windows, which is one of the main reasons I switched to Hyprland. I cannot seem to go back to a floating setup, and I am starting to despise booting into Windows, and I guess I know why.
Still, sign in pop ups and such look too strange while being tiled, so I have also set up a fairly good looking floating setup.

Favorite Tools

• Hyprland – A dynamic Wayland compositor used as the primary desktop environment.

• Kitty – The main terminal emulator, although Alacritty remains a favorite.

• Nautilus – The file manager of choice; nothing quite matches the clean GNOME aesthetic.

• Waybar and SwayNC – Used for the system status bar and notification center.

• Helium – The browser of choice and a strongly preferred alternative to Firefox.

• Zsh and Nushell – Zsh is the primary shell, with Nushell used occasionally.

• Oh My Posh – Used to configure the shell prompt instead of Starship or Oh My Zsh.

• MPV – A lightweight and highly configurable media player.

• Neovim – The only code editor in the workflow.

• KodeMono Nerd Font and the San Francisco font family – The primary fonts used throughout the setup.

Dotfiles

More information about Amal’s configuration is available in his dotfiles repository. He has also included high-quality images of his setup with the email.

There is no dedicated installation process or setup script. The configuration files are stored using the same directory structure they use on his system. However, the repository is compatible with GNU Stow.

Favorite Books

Technical

• The Rust Programming Language, 3rd Edition

Non-Technical

• Necromancer by Gordon R. Dickson

His journey with customization started back in school when he was using Windows. He spent hours browsing the r/unixporn subreddit and was fascinated by the amazing setups people shared. Seeing everyone’s unique workflows made him want to build one of his own, so he eventually switched to Linux and started experimenting with desktop customization. He never reached the level of many experienced users, but he learned a lot and enjoyed the process.

When he started college, he moved to a Mac. That’s when he discovered the macOS customization community through YouTube. Linkarzu was the creator who inspired him the most, and many ideas from his videos became the foundation of his setup.

It took him around two weeks to put everything together. He customized almost every part of his development environment, from his terminal and shell to Neovim and the command-line tools he uses every day. The only thing he never felt the need to change was the macOS menu bar. He actually prefers Apple’s default menu bar because he finds it clean, simple, and easy to use.

Neovim & Terminal

Shivam started using Neovim because he wanted to learn it after seeing so many developers use it. Since he was a complete beginner, he learned mostly through YouTube. Creators like Linkarzu, ThePrimeagen, and TypeCraft helped him understand the basics, and he gradually picked up the tools and plugins they used. He did not go too deep into customization, but over time he built a setup that fits his workflow.

For his terminal, he tried Alacritty, Kitty, and WezTerm before settling on Ghostty. It felt like the perfect balance of speed and simplicity. Everything from the font rendering to image support works great in it.

Favorite Tools

• Neovim — Used for coding, writing, and note-taking in a keyboard-driven environment.

• Ghostty — A lightweight terminal emulator that keeps the setup fast and simple.

• fzf — A fuzzy finder used to quickly search files, commands, and history.

• tmux — A terminal multiplexer for managing multiple terminal sessions and panes.

• Lazygit — A terminal UI for Git that makes commits, branches, and diffs easier to manage.

• Starship — A minimal shell prompt that shows useful context without adding clutter.

• eza — A modern replacement for ls with cleaner output and better file listing features.

• Gum — A tool for building interactive shell scripts and improving command-line aliases.

• yt-dlp — A command-line tool for downloading videos and media from supported sites.

Dotfiles

Shivam’s dotfiles contain the configuration for his macOS development environment, including Ghostty, Zsh, Neovim, tmux, and the command-line tools he uses.

You can find it here https://github.com/io-PEAK/dotfiles

Favorite Books

Technical

• Clean Code by Robert C. Martin

Non-Technical

• The Stranger by Albert Camus

One of the fastest ways to make Neovim feel like your editor is to understand options.

Options control the editor’s behavior: how text is displayed, how indentation works, how search behaves, where splits open, whether undo history persists, and much more.

This article focuses on the options you will see in many real-world configs. “Most used” is not an official Neovim ranking, so treat this as a practical list of common, high-value options that many people set early in their setup.

First: how Neovim options work

Neovim options come in a few scopes:

• global: affects the whole editor

• window-local: can differ per window

• buffer-local: can differ per buffer

In Lua, the most common ways to set them are:

vim.o.ignorecase = true      -- like :set, affects current scope
vim.wo.number = true         -- window-local option
vim.bo.expandtab = true      -- buffer-local option
vim.opt.scrolloff = 8        -- ergonomic Lua option interface

For list- and map-style options, vim.opt It is usually the nicest interface:

vim.opt.listchars = { tab = "» ", trail = "·", nbsp = "␣" }
vim.opt.wildignore:append({ "node_modules", ".git" })

If you want local behavior explicitly, use:

vim.opt_local.wrap = true
vim.opt_global.ignorecase = true

1. Line-number options

number

vim.wo.number = true

Shows the absolute line number for each line.

Why people use it:

• easier navigation

• easier code discussion

• easier error reference

This is one of the most common window options in Neovim configs.

relativenumber

vim.wo.relativenumber = true

Shows line numbers relative to the cursor line.

Why people use it:

• makes motions like 5j, 3k, d4j, y2k more intuitive

• combines well with normal-mode movement

A very common combo is:

vim.wo.number = true
vim.wo.relativenumber = true

That gives you an absolute number on the current line and relative numbers around it.

numberwidth

vim.wo.numberwidth = 4

Controls the minimum width of the number column.

You usually do not need to change this unless your layout feels cramped or you work in huge files a lot.

2. Indentation options

These options are among the most important because they affect how code is inserted and displayed.

tabstop

vim.bo.tabstop = 4

Controls how wide a literal tab character is displayed.

Important:

• This is about the display width of actual tab characters

• It does not, by itself, define indentation behavior for all editing actions

If a file literally contains tab characters, tabstop changes how wide they look.

shiftwidth

vim.bo.shiftwidth = 4

Defines how many columns count as one level of indentation for operations like >>, <<, and various indent features.

In practice:

• If you indent code by 2 spaces, use shiftwidth = 2

• If you indent by 4 spaces, use shiftwidth = 4

softtabstop

vim.bo.softtabstop = 4

Controls how <Tab> and <BS> behave in Insert mode.

This is about the editing feel of tabbing, not the visual width of existing tab characters.

A common pattern is:

vim.bo.tabstop = 4
vim.bo.shiftwidth = 4
vim.bo.softtabstop = 4

That keeps visual width, indent width, and insert-mode tab behavior aligned.

expandtab

vim.bo.expandtab = true

Makes pressing <Tab> insert spaces instead of a literal tab character.

This is one of the most commonly set buffer options because many codebases prefer spaces over tabs.

A common combination:

vim.bo.expandtab = true
vim.bo.tabstop = 2
vim.bo.shiftwidth = 2
vim.bo.softtabstop = 2

That gives you “2-space indentation using spaces.”

autoindent

vim.bo.autoindent = true

Copies the current line’s indentation when you start a new line.

This is a very useful baseline option and one of the simplest ways to make editing feel better immediately.

smartindent

vim.bo.smartindent = true

Adds simple indentation logic for C-like languages.

This can be useful, but it is worth knowing that many modern setups rely more on:

• filetype plugins

• Treesitter-based indentation

• LSP formatting

• formatter tools

So smartindent It is common, but not universal.

3. Search options

These are some of the best “quality of life” options in the editor.

ignorecase

vim.o.ignorecase = true

Makes searches case-insensitive.

So /foo can match:

• foo

• Foo

• FOO

This applies to normal search and also affects some completion behavior.

smartcase

vim.o.smartcase = true

Works with ignorecase.

Behavior:

• If your pattern is lowercase, the search is case-insensitive

• If your pattern contains uppercase letters, the search becomes case-sensitive

This is one of the most common search combinations:

vim.o.ignorecase = true
vim.o.smartcase = true

It feels natural because lowercase searches stay loose, while uppercase searches become precise.

hlsearch

vim.o.hlsearch = true

Highlights all matches from the last search pattern.

Why people like it:

• You can see all matches at once

• easier refactoring and scanning

Why do some people disable it?

• It can feel visually noisy

A common compromise is to leave it on and use:

:nohlsearch

When you want to clear the highlight temporarily.

incsearch

vim.o.incsearch = true

Shows matches as you type the search pattern.

This gives search a more interactive feel and is widely considered one of the nicest default behaviors.

4. Wrapping and reading text

wrap

vim.wo.wrap = false

Controls whether long lines wrap visually.

When on:

• long lines continue on the next screen line

When off:

• lines stay on one visual line, and the window scrolls horizontally

A lot of coding setups prefer:

vim.wo.wrap = false

Wrapped code lines can make the structure harder to read.

For prose or markdown, many people prefer wrap = true.

linebreak

vim.wo.linebreak = true

When wrapping is enabled, this breaks long lines at nicer boundaries instead of in the middle of a word.

This is especially useful for:

• markdown

• text notes

• prose writing

Common writing-oriented combo:

vim.wo.wrap = true
vim.wo.linebreak = true

breakindent

vim.wo.breakindent = true

When a wrapped line continues visually, keep the continuation indented.

This makes wrapped text much easier to read, especially in nested structures or prose with indentation.

A very nice text-editing combo is:

vim.wo.wrap = true
vim.wo.linebreak = true
vim.wo.breakindent = true

5. Cursor context and movement

scrolloff

vim.wo.scrolloff = 8

Keeps a minimum number of screen lines above and below the cursor.

This is one of the most widely used comfort settings in Neovim configs.

Why people like it:

• The cursor is not glued to the top or bottom of the window

• easier to keep context while moving

Common values:

• 4

• 8

• 10

sidescrolloff

vim.wo.sidescrolloff = 8

The horizontal version of scrolloff, used mainly when wrap is off.

Useful if you work with long lines and do horizontal scrolling.

cursorline

vim.wo.cursorline = true

Highlights the current cursor line.

Why people use it:

• easier to track the current line in dense code

• useful on large monitors

• especially nice in splits

Tradeoff:

• It can add visual weight, and the docs note it can slow redraw somewhat

Still, it is a very common option.

6. Split behavior

splitbelow

vim.o.splitbelow = true

Makes horizontal splits open below the current window.

Without it, new horizontal splits open above.

Most people who set this feel it matches natural spatial expectations better.

splitright

vim.o.splitright = true

Makes vertical splits open to the right of the current window.

This is another extremely common preference.

Together:

vim.o.splitbelow = true
vim.o.splitright = true

This is one of the most common “early config” choices in Neovim.

7. Signs, whitespace, and visual helpers

signcolumn

vim.wo.signcolumn = "yes"

Controls when the sign column is shown.

Signs are used by things like:

• diagnostics

• Git signs

• breakpoints

Why do people often set it to "yes"?

• prevents text from shifting left and right when signs appear or disappear

This is especially helpful when using LSP diagnostics.

list

vim.wo.list = true

Turns on “list mode,” which makes certain whitespace visible.

By default, it can show things like:

• tabs

• trailing spaces

• non-breaking spaces

Useful when:

• debugging indentation issues

• cleaning up whitespace

• spotting trailing blanks

listchars

vim.opt.listchars = {
  tab = "» ",
  trail = "·",
  nbsp = "␣",
}

Customizes how invisible characters are shown when list is enabled.

This is a classic “make the editor feel like mine” option.

8. Clipboard and mouse

clipboard

vim.opt.clipboard = "unnamedplus"

Integrates Neovim with the system clipboard.

A very common setup is:

vim.opt.clipboard = "unnamedplus"

That makes normal yank/delete/put operations use the + clipboard register as the unnamed register.

For many users, this is one of the first options they set.

mouse

vim.o.mouse = "a"

Enables mouse support in all major modes.

This allows things like:

• Clicking to move the cursor

• selecting text with the mouse

• resizing splits

Some users love this, some disable it completely. It is largely a preference.

9. Undo, files, and update behavior

undofile

vim.bo.undofile = true

Persists undo history to disk.

That means you can:

• close a file

• reopen it later

• still undo older changes

This is one of the most valuable options for long-term editing comfort.

updatetime

vim.o.updatetime = 250

Controls how long Neovim waits during inactivity before certain events fire, including CursorHold.

The docs also note it affects when the swap file is written.

Why do people often lower it from the default?

• snappier CursorHold behavior

• faster diagnostic popups or plugins relying on idle timing

Common values:

• 250

• 300

• 500

10. Color and terminal UI

termguicolors

vim.o.termguicolors = true

Enables 24-bit RGB color in the terminal UI.

On modern terminals, this is usually desirable, and Neovim will also try to detect support automatically.

If you use a modern color scheme, this option is very often part of the setup.

11. Completion and command-line comfort

completeopt

vim.opt.completeopt = { "menu", "menuone", "noselect" }

Controls how Insert-mode completion behaves.

A commonly used setup is:

vim.opt.completeopt = { "menu", "menuone", "noselect" }

Why people like it:

• show the completion menu

• keep behavior predictable

• Do not force-select the first item immediately

If you use Neovim’s native completion or a completion plugin, this option matters a lot.

wildmenu

vim.o.wildmenu = true

Enhances command-line completion, especially when pressing <Tab> in command-line mode.

This makes command-line completion much friendlier and is a very common option.

wildmode

vim.o.wildmode = "longest:full,full"

Controls how command-line completion behaves across repeated <Tab> presses.

A common choice:

vim.o.wildmode = "longest:full,full"

This makes command-line completion feel much smoother.

showcmd

vim.o.showcmd = true

Shows partial commands as you type them.

This is especially helpful when learning motions and operators because Neovim shows part of what you are building.

showmode

vim.o.showmode = false

Shows the current mode in the command area.

Many people disable this when their statusline already shows the current mode.

If you use the default UI, leaving it on is perfectly reasonable.

A practical “starter options” block

If you want a compact, practical set of commonly used options, this is a good starting point:

-- Line numbers
vim.wo.number = true
vim.wo.relativenumber = true

-- Indentation
vim.bo.expandtab = true
vim.bo.shiftwidth = 2
vim.bo.tabstop = 2
vim.bo.softtabstop = 2
vim.bo.autoindent = true

-- Search
vim.o.ignorecase = true
vim.o.smartcase = true
vim.o.hlsearch = true
vim.o.incsearch = true

-- UI / movement
vim.wo.cursorline = true
vim.wo.scrolloff = 8
vim.wo.signcolumn = "yes"

-- Splits
vim.o.splitbelow = true
vim.o.splitright = true

-- Files / system
vim.bo.undofile = true
vim.o.updatetime = 250
vim.opt.clipboard = "unnamedplus"
vim.o.termguicolors = true

-- Command line / completion
vim.opt.completeopt = { "menu", "menuone", "noselect" }
vim.o.wildmenu = true
vim.o.wildmode = "longest:full,full"

In a real config, many buffer- and window-local options are often set with vim.opt or through filetype-specific config instead of being forced globally everywhere. But as a learning block, this is a useful start.

How to think about options

The best way to learn Neovim options is not to memorize a giant list. Instead, think in categories:

• How do I want code to indent?

• How do I want search to feel?

• How much context do I want around the cursor?

• How should splits behave?

• Do I want system clipboard integration?

• Do I want persistent undo?

• How visible should whitespace and diagnostics be?

That is how most good configs evolve.

You do not need to set fifty options at once. Start with the ones that change your daily experience the most:

• line numbers

• indentation

• search

• scrolloff

• split behavior

• clipboard

• undofile

Then refine from there.

Final thoughts

Neovim options are one of the highest-leverage parts of the editor.

Plugins add features. Options shape behavior.

If you understand the common options, you can make Neovim feel cleaner, faster, calmer, and much more intentional without adding a single plugin.

And once you get comfortable with them, reading someone else’s config becomes much easier, too.

Suggested options to explore next

After the basics above, the next good options to learn are:

• formatoptions

• textwidth

• colorcolumn

• conceallevel

• foldmethod

• foldexpr

• spell

• spelllang

• sessionoptions

• shortmess

• timeoutlen

• cmdheight

• laststatus

• showtabline

Those are where configs start becoming more personal.

One of the most useful things you can learn in Neovim is how to shape your own editing experience.

This Go config is a good example of that. Instead of relying entirely on a plugin to define the workflow, it creates a set of custom commands that wrap the Go toolchain, a few helper binaries, and a small amount of LSP functionality.

That is the real lesson here:

Neovim gives you enough primitives to build the workflows you want yourself.

This is not an argument against plugins. Plugins are often excellent, and for many people, they are the fastest path to a polished setup. The point is that you do not have to stop there. When you understand how to write a few commands of your own, you can adapt Neovim to the way you actually work.

This article focuses on that idea: how custom commands can help you create a practical Go workflow, and what each command in this setup is doing.

The bigger lesson: build the experience you want

A lot of people think of Neovim customization in two extremes:

• Use only stock Neovim

• Install a plugin for everything

In practice, the sweet spot is often somewhere in the middle.

You might use plugins for things like:

• LSP

• completion

• Treesitter

• file navigation

• fuzzy finding

But for the small, repeated actions that define your personal workflow, custom commands are often the better tool.

That is what this setup demonstrates.

It takes common Go tasks and turns them into clear editor commands like:

• :GoBuild

• :GoRun

• :GoTest

• :GoTestFunc

• :GoModTidy

• :GoLint

• :GoAddTags

• :GoAlt

These are not abstract features hidden behind a large system. They are straightforward commands you can read, understand, and change.

That is valuable even if you already use plugins.

The key Neovim idea: user commands

The entire approach is built on Neovim’s command API.

A command is created like this:

vim.api.nvim_buf_create_user_command(0, "GoBuild", function(opts)
  -- implementation
end, {
  nargs = "?",
  desc = "go build",
})

That means:

• Create a user command called GoBuild

• Make it available for the current buffer

• let it take optional arguments

• define exactly what it does in Lua

This is one of the most practical APIs in Neovim.

Once you understand it, you stop thinking only in terms of keymaps and plugins. You start thinking in terms of editor actions you can define yourself.

That is how you create your own experience.

Why custom commands are useful

Custom commands are especially good when:

• The action already exists as a CLI command

• You run it often

• You want better defaults

• You want editor integration around it

• You want a clearer interface than “remember this shell command.”

That is exactly the case for a lot of Go development.

Go already has great tooling. So instead of trying to replace the toolchain, this config makes it easier to drive from inside Neovim.

The result is simple:

• Common actions become easier to trigger

• Defaults become smarter

• Related editor behavior can be handled automatically

• The workflow becomes more personal

The helper layer

Before the commands, the config defines a few helpers. These are what make the command implementations feel clean instead of repetitive.

notify()

A small wrapper around vim.notify().

This gives consistent feedback for success, failure, and informational messages.

run_cmd()

A reusable async command runner built on vim.system().

It handles:

• the command to run

• the working directory

• text output

• the callback after completion

This is important because it means each user command can focus on what it wants to do, not on reimplementing process management every time.

get_package_path()

Returns the current file’s directory.

That is useful for commands that should operate on the current package.

get_module_root()

Walks upward until it finds go.mod.

That is useful for commands that should run from the module root, such as:

• go build ./...

• go generate ./...

• go mod tidy

• go get ...

These helpers are small, but they are the reason the rest of the file stays readable.

The commands and what they teach

The nice thing about this config is that each command teaches a small pattern you can reuse elsewhere.

Build and run

:GoBuild

Wraps:

go build

Default target: ./...

This teaches a simple but useful pattern:

• Create a user command

• Provide a sensible default

• Allow optional custom args

• Run from the correct working directory

• Notify on success or failure

Example:

:GoBuild
:GoBuild ./cmd/api

This is not just a Go command. It is an example of how to turn a common shell task into a first-class editor action.

:GoRun

Wraps:

go run

Default target: .

This command opens a terminal split instead of collecting output in memory.

That teaches another important lesson: not every command should be handled the same way.

For:

• builds

• formatting

• quick background checks

An async process plus notification may be enough.

For:

• app output

• long-running tests

• interactive processes

A terminal buffer is often the better UI.

Example:

:GoRun
:GoRun ./cmd/server

:GoGenerate

Wraps:

go generate

Default target: ./...

After success, it runs :checktime.

That teaches a subtle but important point: a good custom command does not only launch an external process. It also handles the editor consequences of that process.

If files were regenerated on disk, the editor should notice.

That is part of creating a good experience.

Testing commands

:GoTest

Wraps:

go test -v

Default target: ./...

Runs in a terminal split.

This is a straightforward quality-of-life command, but it also shows the value of default behavior. Most of the time, you want the same flags and the same presentation. A command captures that once.

:GoTestFunc

This is one of the most interesting commands in the file.

It uses Treesitter to:

• find the syntax node under the cursor

• walk upward to the surrounding function

• read the function name

• check whether it looks like a Go test

• run only that test

So the command becomes a “run test under cursor” workflow.

That is a great example of how custom commands can combine:

• editor state

• syntax awareness

• an external tool

This is where writing your own commands becomes powerful. You are no longer limited to thin shell aliases. You can make the editor understand context.

:GoTestFile

This command runs tests for the current package directory.

Even though its name suggests “file,” it is really package-scoped based on the current file’s location.

Still, the underlying idea is useful: derive the target from the current buffer, then feed that into the Go toolchain automatically.

That pattern generalizes well to many languages.

:GoCoverage

Wraps a coverage workflow:

go test -coverprofile=coverage.out <args> && go tool cover -html=coverage.out

This is a good reminder that custom commands can bundle multiple steps into one action.

That is often where they become most valuable:

• not just exposing a command

• but encoding a workflow

Module commands

:GoModTidy

Wraps:

go mod tidy

Runs from the module root.

This is a good example of a command that is small but worth promoting into your editor workflow because it is common enough to deserve a name.

:GoModInit

Wraps:

go mod init <module-name>

This shows another common pattern: validate the user input first, then run the external command.

:GoGet

Wraps:

go get <package>

Runs from the module root and then checks for changed files.

This is the same general lesson again:

• pick the right working directory

• run the tool

• handle post-command editor state

That is the structure of many good custom commands.

Code-quality and code-generation commands

:GoVet

Wraps:

go vet

Default target: ./...

A simple example of surfacing an existing quality check directly in the editor.

:GoLint

Wraps:

golangci-lint run

Default target: ./...

This shows how custom commands can unify external tools into your own workflow without needing a large integration layer.

You are not replacing the linter. You are giving it a home inside your editor.

:GoDoc

Wraps:

go doc <symbol>

If no argument is passed, it uses the word under the cursor.

That is a useful pattern:

• accept manual input

• but derive a smart default from the current editing context

That is exactly the kind of small improvement that makes a setup feel personal.

:GoImpl

Uses the impl helper binary to generate interface implementation stubs and insert them into the current buffer.

This teaches another powerful pattern:

• run an external code generator

• capture its output

• insert that output directly into the buffer

That opens the door to a lot of custom workflows beyond Go.

:GoIfErr

Uses iferr if available, otherwise inserts a basic if err != nil { return err } block directly.

This is a very good design choice.

It teaches that custom commands should be helpful even when the ideal dependency is missing. Graceful fallbacks make personal tools much nicer to live with.

:GoModernize

Saves the file, runs a modernization action through gopls, then reloads the file.

This command is useful because it shows that your custom commands do not have to be limited to shell tools. They can also wrap language-server-powered workflows.

So your personal command surface can sit on top of:

• the Go CLI

• helper binaries

• LSP features

All of that can coexist cleanly.

:GoFillStruct

This command directly uses Neovim’s LSP client to request a code action and apply one related to filling struct fields.

This teaches a very modern pattern for Neovim configuration:

• use shell commands for toolchain tasks

• use LSP for semantic editor actions

• hide the ceremony behind a simple user command

That is exactly how you build your own experience.

:GoAddTags

Uses gomodifytags to add tags to a struct.

:GoRemoveTags

Uses gomodifytags to remove tags.

These are practical because they turn a somewhat awkward external tool invocation into a short, repeatable editor action.

That is one of the best uses of custom commands: turning slightly annoying workflows into one clean command.

Navigation commands

:GoAlt

Switches between:

• foo.go

• foo_test.go

:GoAltV

Does the same in a vertical split.

These commands are simple, but they show that custom commands are not only for running external tools. They are also great for navigation and editor movement.

Sometimes the best commands are the ones that remove tiny bits of friction dozens of times a day.

Tool-management commands

The config also includes commands for installing or updating common Go-related binaries:

• :GoInstallBinaries

• :GoUpdateBinaries

• :GoInstallBinary

These commands wrap go install ...@latest for tools like:

• goimports

• gomodifytags

• impl

• iferr

• gotests

• golangci-lint

• dlv

• staticcheck

• govulncheck

This section is useful because it reinforces the main idea of the article:
your editor can do more than edit text. It can become a command surface for your whole development workflow.

What this approach gives you

Writing commands like these gives you several benefits.

You understand your workflow better

Because you wrote it, you know what happens when you run it.

You can tune defaults around your real work

You decide:

• the flags

• the cwd

• the UI

• the notifications

• the fallback behavior

You can combine tools in ways plugins may not

You can mix:

• shell commands

• Treesitter

• LSP

• buffer edits

• terminal splits

• notifications

in exactly the way you want.

You become less dependent on one package doing everything

This does not mean avoiding plugins. It means learning how to extend Neovim yourself when the moment calls for it.

That is a more durable skill.

Where plugins still fit

Plugins still make a lot of sense.

They are especially useful when you want:

• broad feature coverage

• polished UI

• community conventions

• less setup work

• mature integrations you do not want to maintain yourself

There is no conflict here.

A strong Neovim setup often combines both:

• plugins for larger systems

• custom commands for personal workflows

That is probably the healthiest way to think about it.

Practical takeaway

The most useful lesson from this Go config is not “do not use plugins.”

It is this:

learn how to create your own commands, because that is how you turn Neovim into your editor.

Neovim already gives you the building blocks:

• vim.api.nvim_buf_create_user_command()

• vim.system()

• terminal buffers

• Treesitter

• LSP

• normal buffer APIs

With those pieces, you can build commands that feel native, save time, and reflect the way you actually work.

That is what this config demonstrates well.

Command summary

Build / run

• :GoBuild

• :GoRun

• :GoGenerate

Test

• :GoTest

• :GoTestFunc

• :GoTestFile

• :GoCoverage

Modules

• :GoModTidy

• :GoModInit

• :GoGet

Code tools

• :GoVet

• :GoLint

• :GoDoc

• :GoImpl

• :GoIfErr

• :GoModernize

• :GoFillStruct

• :GoAddTags

• :GoRemoveTags

Navigation

• :GoAlt

• :GoAltV

Tool management

• :GoInstallBinaries

• :GoUpdateBinaries

• :GoInstallBinary

Final thought

This setup is a good reminder that customization is not only about adding features. It is also about shaping behavior.

Plugins are one way to do that. Writing your own commands is another.

The real advantage of learning both is that you stop treating your editor as a fixed product and start treating it as a tool you can refine.

That is where Neovim becomes especially powerful.

His projects reflect a consistent theme: simplifying complex workflows and making technical concepts more accessible.

Some of his notable works include:

• StravaTUI — a terminal user interface for viewing Strava running stats

• animplotlib — a Python tool for creating data animations with minimal friction

• strange-attractor-visualiser — an educational web app for exploring chaotic systems visually

Outside of programming, Aymen spends his time running, playing guitar, and exploring film photography. He also writes about engineering, mathematics, and Neovim on his personal blog, where he shares both technical insights and photography.

Neovim & Terminal

Aymen’s workflow is centered around Neovim and the terminal. His primary terminal emulator is Ghostty, chosen for its speed and native feel, along with support for splits and tabs.

He began using Vim roughly seven years ago, initially as a LaTeX editor during his undergraduate studies. Around 2021, he transitioned to Neovim, and his configuration has continued to evolve alongside his needs.

A defining characteristic of his setup is a preference for building rather than installing. When new functionality is needed, he typically attempts to implement it using Neovim’s built-in capabilities. Only when necessary does he rely on external plugins.

One of the most important parts of his workflow is Neovim’s built-in terminal integration. This allows him to create tight feedback loops:

• Sending commands to compile LaTeX documents and refresh PDF previews

• Running interactive sessions such as IPython

• Executing code blocks directly from the editor, creating a notebook-like workflow

He has written in detail about this approach, including how it enables a lightweight alternative to Jupyter-style environments.

Favourite Tools

Aymen’s toolkit is minimal but highly optimized:

• Neovim — his primary editor for nearly all text-based work

• Ghostty — a terminal emulator with a native feel and strong performance

• fzf — for fast fuzzy searching across files and history

• fzf-lua — integrates fzf directly into Neovim

• zoxide — an intelligent replacement for cd, improving navigation efficiency

Dotfiles

Aymen keeps his configuration simple and practical. His dotfiles are publicly available, and his setup process reflects his philosophy of minimal overhead.

Rather than using complex installation scripts, he typically:

1. Clones the repository

2. Creates symlinks to the appropriate directories

Because he rarely switches machines, this approach has proven sufficient and avoids unnecessary complexity.

Desk Setup

Favourite Books

Technical

• Coulson and Richardson’s Chemical Engineering Design — a foundational text in chemical engineering

Non-Technical

• The Wind-Up Bird Chronicle by Haruki Murakami

What changed in 0.12?

Neovim 0.12 continues the native LSP direction introduced in 0.11:

• You define or extend server configs with vim.lsp.config().

• You activate them with vim.lsp.enable().

• You inspect health with :checkhealth vim.lsp.

• You manage enabled configs with built-in :lsp commands such as :lsp enable, :lsp disable, and :lsp restart.

This matters because native LSP configuration is now straightforward enough that you do not need an elaborate wrapper just to get language servers running.

The mental model

There are three separate concerns:

1. Neovim LSP client

   • Talks to language servers.

   • Handles keymaps, diagnostics, hover, rename, code actions, etc.

2. LSP server definitions

   • Per-server configs such as lua_ls, gopls, ts_ls, pyright, etc.

   • These can come from your own config, or from the nvim-lspconfig plugin.

3. Server installation

   • Actually getting the server binaries onto your machine.

   • Neovim does not install servers by itself.

   • Mason helps with this part.

A common source of confusion is mixing up configuration with installation.

Important reality: native LSP still benefits from nvim-lspconfig

If you want lots of ready-made server definitions, install neovim/nvim-lspconfig. In the Neovim 0.11+ model, its job is mainly to provide the lsp/ config files that Neovim can consume natively. You then use vim.lsp.enable() yourself instead of the old require('lspconfig').XYZ.setup(...) pattern.

So the modern split is:

• Neovim built-in LSP = runtime and activation

• nvim-lspconfig = catalog of server definitions

• Mason = installs tools

• mason-lspconfig = bridges Mason package names and LSP config names, and can auto-enable installed servers

Part 1 — Native LSP with no Mason

Minimal setup

This is the smallest practical setup if the language servers are already installed on your machine and discoverable in $PATH.

-- init.lua or lua/config/lsp.lua

-- Example: extend the built-in / lspconfig-provided config for lua_ls
vim.lsp.config('lua_ls', {
  settings = {
    Lua = {
      runtime = { version = 'LuaJIT' },
      diagnostics = {
        globals = { 'vim' },
      },
      workspace = {
        checkThirdParty = false,
        library = {
          vim.env.VIMRUNTIME,
        },
      },
      telemetry = { enable = false },
    },
  },
})

-- Enable one or more servers
vim.lsp.enable('lua_ls')
vim.lsp.enable({ 'gopls', 'jsonls' })

What this does

• vim.lsp.config('lua_ls', {...}) modifies or defines a config.

• vim.lsp.enable('lua_ls') tells Neovim to start or attach that server for matching buffers.

• If a server depends on root detection, the project needs the expected root markers such as .git, go.mod, package.json, and so on.

Where configs come from

Neovim can load LSP configs from multiple places.

Option A: define them in Lua code

vim.lsp.config('gopls', {
  settings = {
    gopls = {
      staticcheck = true,
      gofumpt = true,
    },
  },
})

vim.lsp.enable('gopls')

Option B: create config files on runtimepath

You can place a config file at:

~/.config/nvim/lsp/foo.lua

Example:

-- ~/.config/nvim/lsp/foo.lua
return {
  cmd = { 'true' },
  filetypes = { 'text' },
  root_markers = { '.git' },
}

Then enable it:

vim.lsp.enable('foo')

Option C: override a config from nvim-lspconfig

If you install nvim-lspconfig, its server definitions are loaded from lsp/ directories on runtimepath. You can override them either:

• with vim.lsp.config('server_name', {...}), or

• by adding files under after/lsp/

Example:

vim.lsp.config('rust_analyzer', {
  settings = {
    ['rust-analyzer'] = {
      cargo = { allFeatures = true },
      checkOnSave = true,
    },
  },
})

Recommended file structure

A clean structure is enough. You do not need a huge framework.

~/.config/nvim/
├── init.lua
└── lua/
    └── config/
        ├── lsp.lua
        └── autocmds.lua

Example:

-- init.lua
require('config.lsp')

-- lua/config/lsp.lua
vim.lsp.config('lua_ls', {
  settings = {
    Lua = {
      diagnostics = { globals = { 'vim' } },
    },
  },
})

vim.lsp.enable({ 'lua_ls', 'gopls', 'jsonls' })

Add practical LSP keymaps

Neovim ships LSP defaults, but most people still want buffer-local mappings on attach.

vim.api.nvim_create_autocmd('LspAttach', {
  callback = function(args)
    local bufnr = args.buf
    local map = function(mode, lhs, rhs, desc)
      vim.keymap.set(mode, lhs, rhs, { buffer = bufnr, desc = desc })
    end

    map('n', 'K', vim.lsp.buf.hover, 'LSP Hover')
    map('n', 'gd', vim.lsp.buf.definition, 'Go to definition')
    map('n', 'gD', vim.lsp.buf.declaration, 'Go to declaration')
    map('n', 'gi', vim.lsp.buf.implementation, 'Go to implementation')
    map('n', 'gr', vim.lsp.buf.references, 'References')
    map('n', '<leader>rn', vim.lsp.buf.rename, 'Rename symbol')
    map({ 'n', 'v' }, '<leader>ca', vim.lsp.buf.code_action, 'Code action')
    map('n', '<leader>f', function()
      vim.lsp.buf.format({ async = true })
    end, 'Format buffer')
  end,
})

Diagnostics configuration

A solid baseline:

vim.diagnostic.config({
  severity_sort = true,
  update_in_insert = false,
  float = {
    border = 'rounded',
    source = 'if_many',
  },
  underline = true,
  virtual_text = {
    spacing = 2,
    source = 'if_many',
    prefix = '●',
  },
  signs = {
    text = {
      [vim.diagnostic.severity.ERROR] = 'E',
      [vim.diagnostic.severity.WARN] = 'W',
      [vim.diagnostic.severity.INFO] = 'I',
      [vim.diagnostic.severity.HINT] = 'H',
    },
  },
})

Completion note

Neovim 0.12 has native completion improvements, but LSP completion behavior and UI are still often paired with a completion plugin such as nvim-cmp or alternatives. If you want pure built-in LSP only, you can still run LSP without any completion plugin.

LSP does not require Mason.
LSP also does not require nvim-cmp.

Typical server-specific examples

Lua (lua_ls)

vim.lsp.config('lua_ls', {
  settings = {
    Lua = {
      diagnostics = { globals = { 'vim' } },
      workspace = {
        checkThirdParty = false,
        library = {
          vim.env.VIMRUNTIME,
          '${3rd}/luv/library',
        },
      },
      telemetry = { enable = false },
    },
  },
})

vim.lsp.enable('lua_ls')

Go (gopls)

vim.lsp.config('gopls', {
  settings = {
    gopls = {
      staticcheck = true,
      gofumpt = true,
      usePlaceholders = true,
    },
  },
})

vim.lsp.enable('gopls')

TypeScript / JavaScript (ts_ls)

vim.lsp.config('ts_ls', {
  settings = {
    typescript = {
      inlayHints = {
        includeInlayParameterNameHints = 'all',
        includeInlayFunctionParameterTypeHints = true,
        includeInlayVariableTypeHints = true,
      },
    },
    javascript = {
      inlayHints = {
        includeInlayParameterNameHints = 'all',
        includeInlayFunctionParameterTypeHints = true,
        includeInlayVariableTypeHints = true,
      },
    },
  },
})

vim.lsp.enable('ts_ls')

Debugging native LSP

Start here, in this order:

1. Verify the config is enabled

:checkhealth vim.lsp

2. Inspect currently enabled configs

:lsp

3. Check filetype

:set filetype?

If the buffer filetype is wrong, the server may never attach.

4. Check root detection

Many servers need a project root. If you open a random file outside a recognizable workspace, the server may not start.

5. Check that the server executable exists

If you are not using Mason, make sure the binary is in your shell PATH.

Examples:

which gopls
which lua-language-server
which typescript-language-server

6. Turn on LSP logs if needed

vim.lsp.log.set_level('trace')

Then inspect the log:

vim.cmd('tabnew ' .. vim.lsp.log.get_filename())

Part 2 — Native LSP + Mason

Now the practical setup most people actually want.

What each plugin does

mason.nvim

Installs and manages external tools: LSP servers, formatters, linters, DAP adapters.

mason-tool-installer.nvim

Ensures a list of tools is installed automatically. Good for reproducible setups across machines.

mason-lspconfig.nvim

Bridges Mason with LSP config names. It can:

• translate names like lua_ls ↔ lua-language-server

• expose convenience commands like :LspInstall

• automatically enable installed LSP servers using vim.lsp.enable()

nvim-lspconfig

Still important. It provides the ready-made LSP config definitions that native Neovim can consume.

Recommended plugin set

For a modern Neovim 0.12 setup, this combination is the most practical:

• mason-org/mason.nvim

• mason-org/mason-lspconfig.nvim

• WhoIsSethDaniel/mason-tool-installer.nvim

• neovim/nvim-lspconfig

Even though the runtime is native, nvim-lspconfig remains useful because it ships the server configs.

Load order matters

Use this order:

1. mason.nvim

2. nvim-lspconfig

3. mason-lspconfig.nvim

4. mason-tool-installer.nvim

5. your vim.lsp.config(...) overrides

6. vim.lsp.enable(...) if you are enabling manually

Important points:

• mason.nvim should be set up early, not lazily deferred.

• mason-lspconfig.nvim expects both Mason and nvim-lspconfig to already be available.

Example with lazy.nvim

{
  'mason-org/mason.nvim',
  opts = {},
},
{
  'neovim/nvim-lspconfig',
},
{
  'mason-org/mason-lspconfig.nvim',
  dependencies = {
    'mason-org/mason.nvim',
    'neovim/nvim-lspconfig',
  },
  opts = {},
},
{
  'WhoIsSethDaniel/mason-tool-installer.nvim',
  dependencies = { 'mason-org/mason.nvim' },
  opts = {
    ensure_installed = {
      'lua_ls',
      'gopls',
      'ts_ls',
      'jsonls',
      'stylua',
      'prettier',
      'goimports',
    },
  },
}

That plugin spec is only half the story. You still need LSP config and activation.

Strategy A — Mason installs tools, you enable servers manually

This is the cleanest setup if you want full control.

Step 1: Mason

require('mason').setup()

Step 2: mason-tool-installer

require('mason-tool-installer').setup({
  ensure_installed = {
    'lua_ls',
    'gopls',
    'ts_ls',
    'jsonls',
    'stylua',
    'prettier',
  },
})

Because mason-lspconfig is present, mason-tool-installer can accept LSP config names like lua_ls and gopls, not only raw Mason package names.

Step 3: mason-lspconfig

require('mason-lspconfig').setup({
  automatic_enable = false,
})

This disables auto-enabling so you stay in charge.

Step 4: native Neovim LSP config

vim.lsp.config('lua_ls', {
  settings = {
    Lua = {
      diagnostics = { globals = { 'vim' } },
      workspace = { checkThirdParty = false },
      telemetry = { enable = false },
    },
  },
})

vim.lsp.config('gopls', {
  settings = {
    gopls = {
      staticcheck = true,
      gofumpt = true,
    },
  },
})

Step 5: Enable servers manually

vim.lsp.enable({
  'lua_ls',
  'gopls',
  'ts_ls',
  'jsonls',
})

Why choose this approach?

• predictable

• explicit

• easy to reason about

• avoids surprise attachments

• best if you want different behavior per machine or per project

Strategy B — Mason installs tools and mason-lspconfig auto-enables them

This is the lower-friction setup.

Step 1: Mason

require('mason').setup()

Step 2: mason-tool-installer

require('mason-tool-installer').setup({
  ensure_installed = {
    'lua_ls',
    'gopls',
    'ts_ls',
    'jsonls',
    'stylua',
    'prettier',
  },
})

Step 3: your overrides

Define server-specific config before auto-enable is expected to attach in real use.

vim.lsp.config('lua_ls', {
  settings = {
    Lua = {
      diagnostics = { globals = { 'vim' } },
      workspace = { checkThirdParty = false },
      telemetry = { enable = false },
    },
  },
})

vim.lsp.config('gopls', {
  settings = {
    gopls = {
      staticcheck = true,
      gofumpt = true,
    },
  },
})

Step 4: mason-lspconfig with automatic enable

require('mason-lspconfig').setup({
  automatic_enable = true,
})

With this setup, installed servers are automatically enabled via vim.lsp.enable().

Why choose this approach?

• fewer lines

• easier initial setup

• convenient for general-purpose configs

Downside

• less explicit

• can be harder to debug when you want selective behavior

Strategy C — auto-enable most servers, exclude a few

This is usually the best compromise.

require('mason-lspconfig').setup({
  automatic_enable = {
    exclude = {
      'rust_analyzer',
      'ts_ls',
    },
  },
})

Then enable excluded servers manually when you want special handling.

vim.lsp.config('ts_ls', {
  settings = {
    typescript = {
      inlayHints = {
        includeInlayParameterNameHints = 'all',
      },
    },
  },
})

vim.lsp.enable('ts_ls')

This pattern is useful for servers that often need custom root logic, custom formatting policy, or conflict handling.

Part 3 — Full example configuration

This is a complete practical example for Neovim 0.12.

-- lua/config/lsp.lua

require('mason').setup()

require('mason-tool-installer').setup({
  ensure_installed = {
    'lua_ls',
    'gopls',
    'ts_ls',
    'jsonls',
    'bashls',
    'stylua',
    'prettier',
    'shfmt',
  },
})

vim.lsp.config('lua_ls', {
  settings = {
    Lua = {
      runtime = { version = 'LuaJIT' },
      diagnostics = { globals = { 'vim' } },
      workspace = {
        checkThirdParty = false,
        library = {
          vim.env.VIMRUNTIME,
        },
      },
      telemetry = { enable = false },
    },
  },
})

vim.lsp.config('gopls', {
  settings = {
    gopls = {
      staticcheck = true,
      gofumpt = true,
      usePlaceholders = true,
    },
  },
})

vim.lsp.config('ts_ls', {
  settings = {
    typescript = {
      inlayHints = {
        includeInlayParameterNameHints = 'all',
        includeInlayFunctionParameterTypeHints = true,
        includeInlayVariableTypeHints = true,
      },
    },
    javascript = {
      inlayHints = {
        includeInlayParameterNameHints = 'all',
        includeInlayFunctionParameterTypeHints = true,
        includeInlayVariableTypeHints = true,
      },
    },
  },
})

require('mason-lspconfig').setup({
  automatic_enable = {
    exclude = { 'ts_ls' },
  },
})

vim.lsp.enable('ts_ls')

vim.diagnostic.config({
  severity_sort = true,
  update_in_insert = false,
  float = {
    border = 'rounded',
    source = 'if_many',
  },
  underline = true,
  virtual_text = {
    spacing = 2,
    source = 'if_many',
    prefix = '●',
  },
  signs = {
    text = {
      [vim.diagnostic.severity.ERROR] = 'E',
      [vim.diagnostic.severity.WARN] = 'W',
      [vim.diagnostic.severity.INFO] = 'I',
      [vim.diagnostic.severity.HINT] = 'H',
    },
  },
})

vim.api.nvim_create_autocmd('LspAttach', {
  callback = function(args)
    local bufnr = args.buf
    local map = function(mode, lhs, rhs, desc)
      vim.keymap.set(mode, lhs, rhs, { buffer = bufnr, desc = desc })
    end

    map('n', 'K', vim.lsp.buf.hover, 'LSP Hover')
    map('n', 'gd', vim.lsp.buf.definition, 'Go to definition')
    map('n', 'gD', vim.lsp.buf.declaration, 'Go to declaration')
    map('n', 'gi', vim.lsp.buf.implementation, 'Go to implementation')
    map('n', 'gr', vim.lsp.buf.references, 'References')
    map('n', '<leader>rn', vim.lsp.buf.rename, 'Rename symbol')
    map({ 'n', 'v' }, '<leader>ca', vim.lsp.buf.code_action, 'Code action')
    map('n', '<leader>f', function()
      vim.lsp.buf.format({ async = true })
    end, 'Format buffer')
  end,
})

Part 4 — Best practices

1. Use Mason for installation, native LSP for behavior

This is the cleanest separation.

• Mason manages binaries.

• vim.lsp.config() defines behavior.

• vim.lsp.enable() activates servers.

2. Keep overrides in one place

Have a single file such as:

lua/config/lsp.lua

or split by language if it gets large.

3. Prefer manual enable for special servers

Servers like TypeScript, Rust, or anything that may compete on formatting or needs custom root logic are often easier to manage explicitly.

4. Use :checkhealth vim.lsp first

That is the first debugging step now, not old habits built around legacy commands.

5. Do not confuse package names with config names

Examples:

• LSP config name: lua_ls

• Mason package name: lua-language-server

mason-lspconfig exists largely to bridge this mismatch.

6. nvim-lspconfig is still useful

Even if you are “doing native LSP,” nvim-lspconfig is still the easiest way to get sane server definitions without writing every config from scratch.

Part 5 — Common mistakes

Mistake 1: assuming Neovim installs servers

It does not. Native LSP config is not an installer.

Mistake 2: using the old require('lspconfig').SERVER.setup({}) mental model everywhere

That older style still appears in many guides, but for 0.12 the cleaner path is:

• vim.lsp.config()

• vim.lsp.enable()

Mistake 3: enabling before the server config is available

If you rely on definitions from nvim-lspconfig, make sure that the plugin is loaded before trying to enable a config.

Mistake 4: debugging the wrong layer

If a server is not attaching, isolate the problem:

• is the binary installed?

• is the filetype correct?

• is root detection working?

• is the config enabled?

Mistake 5: mixing formatter ownership without intention

Some LSP servers’ format. Some teams prefer dedicated formatters. Decide intentionally whether vim.lsp.buf.format() should use the server, an external formatter, or a filtered client list.

Part 6 — Recommended setup for most people

If you want the most practical answer:

• install nvim-lspconfig

• install mason.nvim

• install mason-tool-installer.nvim

• install mason-lspconfig.nvim

• Use Mason to install tools

• Use vim.lsp.config() for overrides

• Use either:

  • automatic_enable = false and vim.lsp.enable(...) manually, or

  • automatic_enable = { exclude = { ... } } for a hybrid approach

That gives you:

• native Neovim 0.12 LSP

• reproducible installs

• minimal boilerplate

• explicit control where it matters

References

1. Neovim LSP help: :help lsp, :help vim.lsp.config, :help vim.lsp.enable

2. Neovim 0.12 news: :help news-0.12

3. neovim/nvim-lspconfig README and lsp/ configs

4. mason-org/mason.nvim README

5. mason-org/mason-lspconfig.nvim README

6. WhoIsSethDaniel/mason-tool-installer.nvim README

This guide is organized around the changes that matter most in day-to-day use, with practical examples and a short migration checklist at the end.

At a glance

The most important additions in 0.12 are:

• Built-in plugin management with vim.pack

• Expanded built-in LSP support, including selectionRange, inlineCompletion, linkedEditingRange, documentLink, and viewport-only semantic tokens

• Native insert-mode auto-completion via the new 'autocomplete' option

• A redesigned experimental core UI (ui2)

• New commands such as :restart, :connect, and :uniq

• Useful new Lua APIs such as vim.net.request(), vim.fs.ext(), vim.list.unique(), and vim.list.bisect()

• Built-in plugins such as :Undotree and :DiffTool

• Breaking changes around diagnostics, Treesitter behavior, and renamed APIs

Official source: :help news-0.12.

1. Built-in plugin manager: vim.pack

Neovim 0.12 adds vim.pack, a built-in plugin manager. It is still marked experimental, but the official docs describe it as stable enough for daily use.

Basic usage

vim.pack.add({
  'https://github.com/sainnhe/gruvbox-material',
  'https://github.com/nvim-treesitter/nvim-treesitter',
  {
    src = 'https://github.com/neovim/nvim-lspconfig',
    version = 'v2.0.0',
  },
})

You can also use a table to set the plugin name explicitly:

vim.pack.add({
  {
    src = 'https://github.com/user/generic-name',
    name = 'my-plugin',
  },
})

Where plugins live

vim.pack manages plugins in a dedicated directory under your data path:

site/pack/core/opt

It also maintains a lockfile at:

~/.config/nvim/nvim-pack-lock.json

That lockfile should be treated like part of your config and kept under version control.

Updating plugins

vim.pack.update()

By default, this opens a confirmation buffer where you can review pending changes.

Useful variants:

vim.pack.update({ 'nvim-treesitter' })
vim.pack.update(nil, { force = true })
vim.pack.update(nil, { offline = true })
vim.pack.update(nil, { target = 'lockfile' })

Deleting plugins

vim.pack.del({ 'old-plugin' })

Important caveats

• vim.pack uses Git and expects plugin sources to be Git repositories.

• It is not a lazy-loading framework.

• During init.lua sourcing, plugin loading defaults differently than after startup, so read :help vim.pack if you rely on exact loading behavior.

• If a plugin is already on disk, vim.pack.add() does not automatically verify that its current revision matches the declared version; use vim.pack.update() to synchronize.

Events

PackChangedPre and PackChanged can be used for post-install or post-update hooks:

vim.api.nvim_create_autocmd('PackChanged', {
  callback = function(ev)
    if ev.data.spec.name == 'nvim-treesitter' then
      vim.system({ 'make' }, { cwd = ev.data.path })
    end
  end,
})

2. LSP improvements

Neovim 0.12 expands built-in LSP support significantly.

Native config and enable flow

The recommended built-in pattern is:

vim.lsp.config['lua_ls'] = {
  cmd = { 'lua-language-server' },
  filetypes = { 'lua' },
  root_markers = { { '.luarc.json', '.luarc.jsonc' }, '.git' },
}

vim.lsp.enable('lua_ls')

You can check whether it is attached with:

:checkhealth vim.lsp

New defaults and built-in mappings

Neovim now provides these global LSP mappings by default:

• gra → code actions

• gri → implementations

• grn → rename

• grr → references

• grt → type definition

• grx → run codelens

• gO → document symbols

• Ctrl-S in Insert mode → signature help

gx also handles textDocument/documentLink when the server supports it.

Newly supported or improved capabilities

0.12 adds or improves support for:

• textDocument/selectionRange

• textDocument/inlineCompletion

• textDocument/linkedEditingRange

• textDocument/documentLink

• textDocument/onTypeFormatting

• textDocument/semanticTokens/range for viewport-only semantic tokens

• workspace/codeLens/refresh

selectionRange fallback

If Treesitter is not active, visual-mode an / in selection falls back to LSP selectionRange.

Code lens and other features are not always on automatically

The docs explicitly note that some features may need to be enabled manually depending on your setup, including:

• code lens

• linked editing

• inlay hints

• inline completion

:lsp

Neovim 0.12 includes a built-in :lsp command for interactive client management.

3. Native insert-mode auto-completion

Neovim 0.12 adds the new 'autocomplete' option:

vim.o.autocomplete = true

This enables built-in insert-mode auto-completion without a third-party completion UI plugin.

Other completion-related additions

'complete' gained new flags:

• F{func} → complete using a named function

• F → complete using 'completefunc'

• o → complete using 'omnifunc'

It also supports limiting matches per source:

vim.o.complete = ".^5,t^3,w"

Useful popup menu options:

vim.o.pumborder = 'rounded'
vim.o.pummaxwidth = 40
vim.o.completeopt = 'menu,menuone,noselect'

Note that nearest is now a valid completeopt behavior for proximity-based sorting.

4. UI changes

Experimental ui2

Neovim 0.12 introduces ui2, an experimental redesign of the core messages and command-line UI.

Enable it with:

require('vim._core.ui2').enable()

What it changes:

• avoids many “Press ENTER” interruptions

• avoids delays from warnings like W10

• highlights the command line as you type

• exposes the pager as a regular buffer + window

Because it is explicitly marked experimental, it is best treated as something to try, not something to assume is stable in every workflow yet.

:restart

:restart

This restarts Neovim and reattaches all UIs.

:connect

:connect /tmp/nvim.sock

This dynamically connects the current UI to a server address.

Busy status

The 'busy' buffer status is shown in the default statusline using the symbol ◐.

5. Default statusline improvements

The default statusline is more useful in 0.12 and can show:

• diagnostic counts

• progress/status information

• busy state

• terminal exit information

Two notable helpers are:

vim.diagnostic.status()
vim.lsp.status()

If you already maintain a custom statusline, these APIs make it easier to integrate built-in diagnostics and LSP progress.

6. New Lua APIs worth knowing

vim.net.request()

Neovim now includes a built-in HTTP helper:

local res = vim.net.request('https://api.github.com/repos/neovim/neovim')
print(res.body)

vim.fs.ext()

print(vim.fs.ext('init.lua'))       -- lua
print(vim.fs.ext('archive.tar.gz')) -- gz

vim.list.unique()

local deduped = vim.list.unique({ 1, 2, 2, 3, 1 })

vim.list.bisect()

local idx = vim.list.bisect({ 10, 20, 30, 40 }, 25)

Other useful Lua additions

• vim.hl.range() now allows multiple timed highlights

• vim.tbl_extend() and vim.tbl_deep_extend() can take a function as conflict behavior

• vim.version.intersect() computes version-range intersections

• Iter:take() and Iter:skip() can accept predicates

• Iter:peek() works for all iterator types

• Iter:unique() deduplicates iterator output

7. Built-in plugins

:Undotree

:packadd nvim.undotree
:Undotree

This adds a built-in visual undo-tree navigator.

:DiffTool

:packadd nvim.difftool
:DiffTool path/to/dir1 path/to/dir2

This compares directories and files.

tohtml is now opt-in

:packadd nvim.tohtml
:TOhtml

tohtml is no longer loaded by default.

8. Treesitter changes

Markdown highlighting by default

Treesitter-based Markdown highlighting is enabled by default.

Built-in incremental selection

Neovim 0.12 adds built-in node-based selection:

• v then an → select outward

• v then in → select inward

• v then ]n → next sibling

• v then [n → previous sibling

This is especially useful if you want structural selection without relying on extra plugins.

Breaking change: get_parser()

vim.treesitter.get_parser() no longer throws on failure. It now returns nil when it cannot create a parser.

Old assumption:

local parser = vim.treesitter.get_parser(bufnr)

Safer 0.12 pattern:

local parser = vim.treesitter.get_parser(bufnr)
if parser then
  -- use parser
end

9. Diagnostics changes

Major breaking change: diagnostic signs

Diagnostic signs can no longer be configured with :sign-define or sign_define().

You must configure them through vim.diagnostic.config().

Example:

local sev = vim.diagnostic.severity

vim.diagnostic.config({
  severity_sort = true,
  signs = {
    text = {
      [sev.ERROR] = 'E',
      [sev.WARN]  = 'W',
      [sev.INFO]  = 'I',
      [sev.HINT]  = 'H',
    },
  },
})

Other diagnostic notes

• vim.diagnostic.disable() and vim.diagnostic.is_disabled() were removed

• the legacy signature of vim.diagnostic.enable() is no longer supported

• vim.diagnostic.status() is useful for statuslines

10. New editor commands and behaviors

New commands

• :restart → restart Neovim and reattach UIs

• :connect {addr} → connect current UI to a server

• :iput → like :put, but adjusts indent

• :retab -indentonly → retab only leading whitespace

• :uniq → deduplicate lines in the current buffer

• :wall ++p → write all buffers and create missing parent directories

• :help! → help lookup with smarter guessing

:source with a range can detect Lua

When a selected range contains a Lua code block, Neovim can detect and execute it as Lua.

Search completion

'wildchar' now enables completion in search contexts such as /, ?, :g, :v, and :vimgrep.

11. Changed defaults

Some defaults changed in 0.12:

• 'shelltemp' now defaults to false

• 'diffopt' now includes improved defaults such as indent-heuristic and inline:char

• 'shada' excludes /tmp/ and /private/ paths by default

• terminal 'scrollback' maximum increased to 1,000,000

Insert-mode Ctrl-R changed

Ctrl-R in Insert mode now inserts register contents literally by default.

If you relied on the older behavior that interpreted special characters, you may need to adjust your workflow.

12. Terminal improvements

Neovim 0.12 improves terminal behavior in several ways:

• support for synchronized output (DEC private mode 2026)

• support for clearing terminal scrollback via CSI 3 J

• nvim_open_term() can now be called on a non-empty buffer

• suspended PTY processes are shown as [Process suspended] and can be resumed by keypress

13. Notable new highlight groups and events

Highlight groups

Examples include:

• DiffTextAdd

• OkMsg

• StderrMsg

• StdoutMsg

• SnippetTabstopActive

• PmenuBorder

• PmenuShadow

New events

Examples include:

• CmdlineLeavePre

• MarkSet

• SessionLoadPre

• TabClosedPre

• PackChangedPre

• PackChanged

14. Breaking changes and migration checklist

These are the items most likely to affect existing configs or plugins.

Rename changes

• vim.diff → vim.text.diff

• semantic tokens start()/stop() usage moved to enable()

Diagnostics

• remove any :sign-define-based diagnostic sign setup

• move diagnostic sign configuration to vim.diagnostic.config()

• stop using removed functions like vim.diagnostic.disable()

Treesitter

• update code that assumes vim.treesitter.get_parser() throws on failure

Plugins

• tohtml is now opt-in

• old shellmenu plugin is removed

Providers

• Python 3.7 and 3.8 support were dropped

Options and behavior

• 'shelltemp' changed to false

• Insert-mode Ctrl-R now inserts register contents literally

15. Practical 0.12 config examples

Minimal modern structure

~/.config/nvim/
├── init.lua
├── nvim-pack-lock.json
└── lua/
    └── config/
        ├── init.lua
        ├── options.lua
        ├── keymaps.lua
        ├── diagnostics.lua
        ├── autocmds.lua
        └── pack.lua

init.lua

require('config')

lua/config/init.lua

require('config.options')
require('config.pack')
require('config.keymaps')
require('config.diagnostics')
require('config.autocmds')

lua/config/options.lua

vim.o.autocomplete = true
vim.o.pumborder = 'rounded'
vim.o.pummaxwidth = 40
vim.o.completeopt = 'menu,menuone,noselect,nearest'

lua/config/diagnostics.lua

local sev = vim.diagnostic.severity

vim.diagnostic.config({
  severity_sort = true,
  update_in_insert = false,
  float = {
    border = 'rounded',
    source = true,
  },
  signs = {
    text = {
      [sev.ERROR] = 'E',
      [sev.WARN]  = 'W',
      [sev.INFO]  = 'I',
      [sev.HINT]  = 'H',
    },
  },
})

lua/config/pack.lua

vim.pack.add({
  'https://github.com/sainnhe/gruvbox-material',
  'https://github.com/nvim-treesitter/nvim-treesitter',
})

16. What you can probably remove from your config

After upgrading to 0.12, you may be able to simplify your setup by removing or rethinking:

• custom diagnostic-sign definitions based on :sign-define

• manual statusline diagnostic counters

• ad-hoc HTTP wrappers for simple requests

• third-party undotree plugins if the built-in one is enough

• plugin-manager bootstrap code if you switch to vim.pack

Whether you should remove nvim-lspconfig or a third-party completion plugin depends on how much custom behavior you want. Neovim 0.12 reduces the need for them, but it does not automatically make them obsolete for every workflow.

Bottom line

Neovim 0.12 is a substantial release, but the most important story is not just new features. It is that more of the editor is now usable without a large stack of plugins.

The biggest practical wins are:

1. vim.pack for built-in plugin management

2. stronger built-in LSP support

3. native insert-mode auto-completion

4. cleaner diagnostics configuration

5. useful built-in UI and Lua improvements

If you upgrade, the first places to review are your plugin manager, diagnostic sign config, Treesitter parser assumptions, and any code that still uses renamed APIs.

References

• :help news-0.12

• :help vim.pack

• :help lsp

• :help diagnostic-signs

• :help ui2

• :help deprecated-0.12

He started in design, and that influence still shows up in how he approaches development — with attention to detail, aesthetics, and craft. Outside of code, he’s always gravitated toward creative subcultures: freestyle skiing, skateboarding, keyboards, photography, and climbing. Things that reward long-term practice.

He lives just outside Stockholm with his partner. When he’s not working, he’s usually outdoors — hiking, traveling, photographing, or building and maintaining open-source projects.

Earlier in his career, he was active in the developer meetup scene, attending, speaking, and organizing events.

Open Source

Albin maintains a few projects:

• https://github.com/albingroen/prismabuilder.io

• https://github.com/albingroen/react-cmdk

• https://github.com/albingroen/quick.nvim

Neovim & Terminal

Neovim has been his primary editor for nearly a decade.

The configuration is centered around frontend development — mainly TypeScript and React. It’s been refined slowly over the years. Plugins get pruned regularly. What remains is what he actually uses.

He publishes a small Neovim distribution called `quick.nvim`, though his personal setup is slightly modified to integrate better with tmux.

Current plugin list:

• blink.cmp — High-performance completion plugin with fuzzy matching and async support.

• conform.nvim — Lightweight formatter plugin that runs formatters on save with minimal config.

• friendly-snippets — Collection of preconfigured snippets for a wide range of languages and frameworks.

• gitsigns.nvim — Git integration that shows added, changed, and removed lines in the sign column.

• lazy.nvim — Modern plugin manager with lazy-loading, lockfiles, and a clean UI.

• mason-lspconfig.nvim — Bridge between Mason and lspconfig for automatic LSP server setup.

• mason.nvim — Portable package manager for LSP servers, linters, formatters, and DAP adapters.

• nvim-autopairs — Automatically closes brackets, quotes, and other paired characters as you type.

• nvim-lspconfig — Official quickstart configs for Neovim’s built-in LSP client.

• nvim-surround — Easily add, change, and delete surrounding pairs like quotes, brackets, and tags.

• nvim-treesitter — Treesitter integration for better syntax highlighting, indentation, and code navigation.

• nvim-ts-autotag — Automatically closes and renames HTML/JSX tags using Treesitter.

• nvim-ts-context-commentstring — Sets the correct comment style based on cursor location in embedded languages.

• oil.nvim — File explorer that lets you edit your filesystem like a normal buffer.

• onedark.nvim — Atom-inspired One Dark colorscheme with multiple style variants.

• plenary.nvim — Lua utility library used as a dependency by many popular plugins.

• render-markdown.nvim — Renders Markdown inline with headings, code blocks, and formatting styled in the buffer.

• telescope.nvim — Highly extensible fuzzy finder for files, grep results, LSP symbols, and more.

• typescript-tools.nvim — Native TypeScript language server integration with faster performance than tsserver wrappers.

• vim-rhubarb — GitHub integration for fugitive, enabling :GBrowse to open files on GitHub.

• vim-sleuth — Automatically detects and sets the correct indentation style for each file.

• vim-tmux-navigator — Seamless navigation between Neovim splits and tmux panes with the same keybindings.

• which-key.nvim — Displays a popup of available keybindings as you type, so you never forget a shortcut.

Favorite Tools

Terminal

• tmux — Terminal multiplexer for managing multiple sessions, windows, and panes from a single screen.

• Neovim — Hyperextensible Vim-based text editor built for modern workflows and plugin ecosystems.

• OpenCode — an AI-powered coding assistant that runs directly in your terminal.

• fzf — Blazing-fast general-purpose fuzzy finder for files, commands, and anything piped to it.

• zoxide — Smarter cd command that learns your most-used directories and jumps to them instantly.

• Fish Shell — User-friendly shell with autosuggestions, syntax highlighting, and sensible defaults out of the box.

GUI

• Ghostty — Fast, native terminal emulator built from the ground up with modern GPU rendering.

• Raycast — Productivity launcher for macOS that replaces Spotlight with extensible commands and integrations.

• Postico — Clean, intuitive PostgreSQL client for macOS.

• Zen — Privacy-focused browser built on Firefox with a minimal, distraction-free interface.

Dotfiles

You can find his dotfiles here:

https://github.com/albingroen/dotfiles

He uses fish instead of zsh. Built-in syntax highlighting, solid autocomplete, and noticeably faster startup. It’s been his default shell for a while now.

Desk Setup

Books

Technical

• Refactoring UI — Practical examples on building better interfaces without necessarily being a trained designer.

Non-Technical

• The Almanack of Naval Ravikant — A curated collection of Naval’s tweets over the years. Short, dense, reflective. A quick read that lingers longer than expected.

Filipe loves to rice his setup, he created a website to showcase his work: https://datsrice.datsfilipe.xyz/

Some of his side projects: https://github.com/datsfilipe/trxsh and https://github.com/datsfilipe/vesper.nvim

Neovim & Terminal

My terminal setup is built around speed and simplicity. I want tools that start fast, feel fast, and stay out of the way.

Zellij is at the core of how I organize sessions — I use it with a single plugin, `zellij-switch`, to flip between workspaces without clutter or drag. Everything else is chosen with a “fast, no-bloat” mindset.

Filipe transitioned from more complex setups to this minimal structure after years of refining and reevaluating what he actually uses. The emphasis is on workflows that feel intuitive and don’t interrupt flow.

Favourite Tools

• Zellij — Terminal workspace manager with a focus on simplicity and session switching via plugins.

• fish — A fast and ergonomic shell with sensible defaults.

• Alacritty — A performance-oriented terminal emulator that starts and runs quickly.

• eza — A modern replacement for `ls` with better defaults and nicer output.

• git — The baseline for version control; no extras, no unnecessary tooling.

• ghq — Organizes repositories cleanly so they appear where expected and integrate with Zellij sessions.

• bottom — System monitor that feels responsive without the overhead of Python-based alternatives.

Dotfiles

You can find Filipe’s dotfiles here: https://github.com/datsfilipe/dotfiles and his Neovim config here: https://github.com/datsfilipe/datsnvim

His dotfiles include scripts, configurations, and tooling tailored to fast session workflows, NixOS integration, and personal automations. They’re not drop-in plug-and-play, but they contain many patterns and ideas that can be adapted into other workflows.

Desk Setup

I'm a big fan of berserk as you can see, it's not my favourite anime cause the adaptation (original) was cut too early and the sequences were rly bad, but it's the only mangá I've ever read, and therefore my favourite. These keyboards are custom made but not by me, a guy from Brazil did those for me: https://www.instagram.com/tupinikeebs/. I want to get a smaller one like this and one flat in future (for usage with my laptop).

Favourite Books

• The Metamorphosis — Franz Kafka

• Fahrenheit 451 — Ray Bradbury

• Short stories - Edgar Allan Poe

• Posthumous Memoirs of Brás Cubas — Machado de Assis

Github: https://github.com/paulalden

Neovim & Terminal

I live in the CLI as much as possible, so my work flow is very Tmux focused. This is the 4th version of my Neovim config, I’ve tried using Lazyvim previously, but it changed so quickly that I found it too unstable for my professional daily driver. This config is based on Kickstart and has been used daily for Ruby development.

Favorite Tools

• Neovim – Modern, extensible Vim fork with async support and a built-in LSP client

• Tmux – Terminal multiplexer for managing multiple terminal sessions in one window

• FZF – Blazing-fast command-line fuzzy finder (great for files, history, git, etc.)

• Claude Code – AI-powered coding assistant by Anthropic, integrated into the terminal or IDE

• SketchyBar – Fully customizable macOS status bar replacement written in C

• Yabai – Tiling window manager for macOS with focus on scripting and automation

• ZSH – Powerful shell with better autocompletion, globbing, and customization than Bash

• LazyGit – Simple terminal UI for git commands – makes staging, committing, and branching effortless

Dotfiles

You can find Paul’s dotfiles here: https://github.com/paulalden/dotfiles

My dotfiles are a constant work in progress, but this iteration has been my daily driver for about a year.

Favorite Books

Non-technical book:

• Hyperion, by Dan Simmons

Technical:

• Eloquent Ruby by Russ Olsen

He enjoys learning new tools and languages, as well as building side projects. He has created Emacs packages (as an Emacs user), developed a functional database client at melocoton.app (which still needs refinement), and worked as an SRE for the past two years.

Passionate about servers, he maintains a home lab running VMs and containers. Currently, he is seeking a new job as a developer or SRE/platform engineer.

He founded Ruay Labs (ruaylabs.com—”ruay” means “build” in Quechua, the Inca language) to sell his ongoing projects. Eager to learn, he is focusing on streaming, having assisted with local meetup setups, and occasionally streams coding content in Spanish on Twitch at twitch.tv/erickgnavar.

He is also exploring 3D printing with a Bambu Lab A1, mastering 3D modeling and techniques while earning extra income through on-demand prints. He shares his learnings on his blog at https://erick.navarro.io/blog.

Neovim (Or Emacs) & Terminal

I use emacs, I’ve been using it for almost 10 years. I tried vim before. I love modal editing but I didn’t like vim script so I search for other options,

I really like lisp as editor configuration language. I love emacs because is a living program, I can change anything on the fly because it’s basically a lisp machine

which happens to have an editor. I use evil-mode to emulate vim. So I have the best of both worlds

Also I love magit(git client) and org(markdown on steroids)

I have some custom workflows coded in lisp, I can have many projects opened at the same time using perspectives(kinda workspaces) and move quickly between them.

I can make commits and PRs using magit, open a shell, run tests, make editions in the whole project using ripgrep and a custom workflow, rename files as text using dired,

have literate programming using org, and many other things

Favorite Tools

CLI Tools

• fzf: For history search with Ctrl-R in terminal and bash utilities.

• eza: Replacement for ls.

• bat: Replacement for cat.

• tmux: Terminal multiplexer; one session per project.

• ripgrep: Replacement for grep.

• mise: Version manager for Elixir, Rust, Zig, Node.js, Ruby; loads/unloads environment variables on directory change. Replaced asdf and direnv.

• uv: For Python virtualenvs and scripts; supports inline dependency metadata for quick scripts.

GUI Tools

• Emacs: Editor.

• Homerow: Keyboard-based clicking and scrolling on macOS.

• Cleanshot: Screen capture and annotation.

• Hammerspoon: Window management and helpers.

• Alfred: Spotlight replacement and clipboard manager; custom workflows.

• Espanso: Text expander.

• Dynowall: Backgrounds (self-made).

• Melocoton: Database client.

Dotfiles

You can find Erick’s configs here: https://github.com/erickgnavar/dotfiles

I use a custom script(setup.sh) to make installation(it works like stow).

Didn’t know stow existed back then. I use nixOS on linux and I was using nix-darwin on my work computer

Favorite Books

Technical book:

• A Philosophy of Software Design, by John Ousterhout

Non-technical:

• Song of Ice and Fire Series by GRRM

He enjoys customizing his workflow and experimenting with technologies that enable him to code more efficiently.

Explore his projects and learn more about him here: alexis-dev.vercel.app

Neovim & Terminal

I love my Neovim setup because it’s **fully tailored to my workflow**. The keybindings and automation features let me focus on coding instead of repetitive tasks. It’s designed to **scale with my projects**, supporting multiple programming languages seamlessly. Combined with OpenCode, Lazygit, Lazydocker, and other CLI tools, my setup helps me work faster, smarter, and more efficiently every day.

Favorite Tools

• Neovim - My main editor. I customized it for scalability, workflow automation, custom keybindings that never get in the way, and smooth support for multiple programming languages.

• kitty – A fast, feature-rich, cross-platform terminal emulator.

• tmux – A terminal multiplexer that allows me to easily manage multiple terminal sessions.

• fzf – A command-line fuzzy finder.

• opencode - An AI CLI that helps me code smarter and faster.

• lazygit – A terminal UI for Git to speed up version control.

• lazydocker – A terminal UI for Docker to speed up container management.

Dotfiles

Neovim Setup

Neovim Config: https://github.com/Alexis12119/nvim-config

Requirements

Before diving in, ensure these are installed:

On Windows, use Scoop.

• Git: lazygit

• Telescope dependencies:

  • fd

  • bat

  • ripgrep

  • make

  • mingw-nuwen

• Nerd Font (for icons):

  • JetBrainsMono

  • (Other fonts optional)

• Neovim: v0.11+

Installation

Preparation:

1. Ensure Neovim is not running.

2. Remove or move the existing ~/.config/nvim directory.

Installation:

• Linux / macOS:

bash <(curl -s https://raw.githubusercontent.com/Alexis12119/nvim-config/main/installer/install.sh)

• Windows (PowerShell):

Invoke-WebRequest https://raw.githubusercontent.com/Alexis12119/nvim-config/main/installer/install.ps1 -UseBasicParsing | Invoke-Expression

Dotfiles Setup

Dotfiles: https://github.com/Alexis12119/dotfiles

• Clone repo:

git clone https://github.com/Alexis12119/dotfiles.git ~/dotfiles

• Use stow to symlink into the home directory.

• Then install End-4 Dotfiles.

Favorite Books

• Bible

Neovim & Terminal

• I love that you can configure it to be unique to your own style without extra stuff

• I love how fast it is.

• I love using vim motions and macros and keymaps

• I love how you can find almost support to any functionality you need in an IDE

Favorite Tools

• Neovim

• Tmux: terminal multiplexer.

• Zoxide: a smarter cd command.

• Yazi: Blazing fast terminal file manager written in Rust, based on async I/O.

• fzf: A command-line fuzzy finder.

• Ghostty: Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.

• AIDente: AlDente gives you control over your MacBook’s charging behavior, helping you extend battery lifespan and maintain peak performance.

• AppCleaner: AppCleaner is a small application that allows you to uninstall unwanted apps thoroughly.

Dotfiles

You can find Yousef’s dotfiles here: https://github.com/YousefHadder/dotfiles (instructions can be found in the readme)

Desk Setup

Neovim & Terminal

My neovim config is pretty much based on kickstart.nvim - There's
no extra or complex configuration, it just works.

I discovered the terminal world when I started my high school CS
journey. Back then, my computer was a Lenovo ThinkPad X300 with 4GB of
RAM, an i3 as a processor, and a 256 SSD running Manjaro Linux. With
those specs, I knew that wasting resources on an IDE was a luxury.
Luckily, my brain exploded when I saw fitoria & petersanchez’s power Vim & tmux usage. Something in my brain said this is the way.

Most of my usage relies heavily on tmux popups. I used to be the guy
with dozens of Vim tabs and quite a few tmux windows. Popups are to me
a way to keep contextual information within a few keystrokes.

In my case, the main access to information is my editor. On this
screen, I know what and why I’m doing.

Now under the premise of easy access and tmux popups, just
`ctrl+space+j` in case I need a scratch terminal to debug or test
things

And `ctrl+space+a` if I want to play around with some AI tools

Of course modals can be stacked on top of each other

Favourite Tools

• Atuin: Fast, reliable, and easy to use shell history.

• Matterhorn: A feature-rich Unix terminal client for the Mattermost chat system.

• Lazydocker: The lazier way to manage everything docker.

• Posting: The modern API client that lives in your terminal.

• Ghostty: Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.

Dotfiles

You can find Oscar’s dotfiles here: https://github.com/oscarmcm/dotfiles

I don't think my dotfiles are something people can just plug and play,
but they have a few ideas that can be easily borrowed and improved.

Desk Setup

Favorite Books

• Technical

  • why's (Poignant) Guide to Ruby: Programming books should not be boring. And this has the perfect balance between learning and having fun.

• Non-Technical

  • Meditations - Marcus Aurelius

Neovim & Terminal

My Neovim setup consists of many modern plugins. Among them my favourites are :snacks, blink cmp and mini files.
snacks.nvim is a collection of plugins that just improves the quality of your neovim experience. It includes many features like fuzzy finding, image and content preview , indentlines with options to declare custom highlights etc.
blink.cmp is an alternative to nvim-cmp, but with a faster completion engine. It's really easier to configure and provides faster completion compared to nvim-cmp which was a bit more complicated for beginners.
mini.files is an awesome file explorer that allows you to edit files as if they are part of a buffer. Another alternative is oil.nvim which provides similar functionalities.

I have used many mainstream terminals, such as alacritty, foot, kitty, and wezterm, among others. But Ghostty seemed the best option for me. It's just perfect. From font rendering to image viewing, everything works in it.

Favourite Tools

• Neovim : for coding and taking notes

• fzf : for fuzzy finding

• Tmux : Terminal Multiplexing

• lazygit : a terminal UI for git

• yt-dlp : for downloading yt videos

• eza : “ls” alternative with icons

• Ghostty : Favourite Terminal

Dotfiles

You can find his dotfiles here: https://github.com/bibjaw99/workstation

Favorite Books

• Technical

  • Linux Bible by Christopher Negus

  • Learn Vimscript the Hard Way by Steve Losh

• Non-Technical

  • The Lord of the Rings by J.R.R Tolkein

In his free time, he enjoys fishing, developing open-source tools, restoring vintage hardware, exploring symbolic models of reality, and making his children laugh. When he needs a break from the modern stack, he dabbles in low-level programming with TempleOS and classic Assembly.

Neovim & Terminal

I love that Neovim feels like home — zero distractions, infinite extensibility. My setup uses Lua for quick startup and modular config. Combined with tmux, it creates a seamless workspace I can drop into from anywhere, even remote Raspberry Pi sessions.

Favorite Tools

Here are some of the tools he uses daily:

• Neovim + Lua config

• anaconda3 for package management

• IPython for live testing of scripts

• tmux for terminal multiplexing

• Btop for system monitoring

• ripgrep + fd for blazing search

• fzf for fuzzy everything

• Tide42 – his custom terminal IDE with color themes, auto-updates, and a sidekick terminal-based color picker tool (NPalette) and numerical charting (NChart)

Dotfiles

You can find his config here: https://github.com/logicmagix/tide42

Just clone it, run the installer script, and you’re good to go. It respects existing configs and works across major distros (Debian, Arch, macOS).
It’s also self-updating with --update built-in.

Desk Setup

Favorite Books

• Technical

  • The Art of Unix Programming by Eric S. Raymond

• Non-Technical

  • The Alchemist by Paulo Coelho

  • Hitchhiker’s Guide to the Galaxy by Douglas Adams

Aside from work, he spends most of his free time hanging out with his family, playing board games (there are more digital/online versions these days), and, of course, tinkering with his dotfiles and Neovim config, as well as following and talking to others who do the same.

Neovim and Terminal

My Neovim config is based on kickstart.nvim, though that was a long time ago. Now at the core of it are the mini.nvim and snacks.nvim plugins, and tinted-vim for my colorscheme. I lazy load everything, and can typically load Neovim with my almost 70 plugins in less than 80 ms, since only 20 or so of those are loaded on startup.

Favorite Tools

• WezTerm: terminal emulator

• tmux: terminal multiplexer

• Neovim

• fish: shell

• sesh: tmux plugin for quickly switching sessions

• Yazi: file explorer TUI

• tinted-theming: base16 colorschemes fork for all the things

• fzf: fuzzy finder and fzf.fish fzf plugin for fish shell

• zoxide: A smarter cd command

• atuin: magical shell history

• ov: pager

• fnm: Fast and simple Node.js version manager

• fx: JSON viewer & processor TUI

• posting: REST API client TUI

• Raycast: launcher, shortcuts, window management, converter and more

• Obsidian: notes

• Shottr: screenshot tool

• Lazygit: simple terminal UI for git commands

Dotfiles

Iain's main dotfiles are organized using stow, so others could use that to "apply" his dotfiles. However, he expects it would be more useful for people to simply browse the configuration files for a particular tool.

You can find his dotfiles here: https://github.com/iainsimmons/dotfiles

And his Neovim config. Instructions are in the README:
https://github.com/iainsimmons/nvim-config

Favorite Books

Iain isn't much of a reader and tends to focus on documentation sites rather than technical books. The only technical book he recalls from recent memory is "Hypermedia Systems."

For non-technical reading, one of his favorites from childhood, introduced to him by his dad, is "Magician" by Raymond E. Feist.

He also developed a Vim plugin that highlights keywords inside a buffer called interestingwords. A Lua version is coming out soon!

Neovim and Terminal

My Neovim setup incorporates modern Lua plugins such as Oil, Cmp, LuaLine, Conform, and Telescope, all managed with Lazy. Mason and Fidget primarily power the LSP environment.

I love the Nord Theme, which I have configured across every UI plugin, including components like autocomplete from CMP and code previews from Telescope.

More recently I've been using a fantastic Telescope extension called EasyPick. It allows custom data sources from shell invocations, which I like to use to list new and changed files from my git repo—essentially the key files you need in any coding session.

Favorite Tools

• LSD: The next-gen ls command.

• Bat: A cat(1) clone with syntax highlighting and Git integration.

• FPP: Facebook PathPicker is a simple command line tool that solves the perpetual problem of selecting files out of bash output.

• Starship: The minimal, blazing-fast, and infinitely customizable prompt for any shell.

• Zsh: shell.

• Neovim: Vim-based text editor.

• Tmux: Terminal multiplexer.

• Alacritty: Terminal emulator.

Dotfiles

You can find Luis’s dotfiles here: https://github.com/lfv89/norse.nvim

Favorite Books

Technical

• A Philosophy of Software Design by John Ousterhout

• Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann

Non-Technical

• Sapiens: A Brief History of Humankind by Yuval Noah Harari

I’m a software engineer with 10 years of experience from Brazil and a self-taught developer. I work at VTEX but have built software for various industries like logistics, finance, health, education, and digital commerce. I started my career with Java, discovered JavaScript along the way, and then came across OCaml, ReScript, and functional programming, which changed my career path. I've specialized in UI engineering, focusing on design systems, front-end and developer tooling, developer experience, and functional programming.

I was active in the open-source community, especially in the ReScript ecosystem, by creating and maintaining libraries. But for the past two years, I’ve been more focused on the Vim and tmux ecosystems, releasing projects like BetterVim and BetterTmux—that’s my attempt to make this ecosystem better with a top-notch developer experience.

Neovim and Terminal

I’ve been using Neovim and Tmux for years, and I started by copying a friend’s dotfiles. Three months later, as usual, I got tired of not knowing how to build my config from scratch. So, I created everything from scratch—the whole Neovim and Tmux config. It took me years to achieve a setup I was proud of, but in the end, it became a product, BetterVim. That’s right, I productified my Neovim config. I didn’t do this alone; I had two partners at the beginning, and now we’re two. I use this config daily, so beyond being a side project, it’s like a bonsai for me—I maintain it every day.

Now, I’m focused on TMUX, which I’ve been struggling with for years to achieve the perfect config, mostly related to developer experience (DX) principles. Recently, I launched an open-source project called BetterTmux that enhances my dotfiles. BetterTmux makes my config much easier by using React (you heard right) to build my TMUX config.

Favorite Tools

• BetterVim is a Neovim distribution featuring lots of slick defaults and an outstanding UI.

• BetterTmux is a framework for TMUX that leverages React and TypeScript to enable powerful customizations.

• Kitty Terminal Emulator

• Neovim

• Tmux Terminal Multiplexer

• Raycast A collection of powerful productivity tools all within an extendable launcher. Fast, ergonomic, and reliable.

Dotfiles

You can find Marcos’s dotfiles here http://github.com/vmarcosp/dotfiles (Read the install.sh file)

Desk Setup

Favorite Books

Technical:

• The Art of Computer Programming by Donald Knuth

Non-Technical:

• The Mystery of the Green House

Neovim and Terminal

It’s based on Astronvim, which is a most underrated nvim distro. It’s giving you all IDE features (like LunarVIM) out-of-the-box while keeping the configuration simple and easily extendable (which wasn’t the case for big nvim distros). Also, there is an astrocommunity repo https://github.com/AstroNvim/astrocommunity/ which contains ready copy-and-paste-to-go configuration file recipes for plugins which saves a huge amount of time while needing to install some handy and important plugins for work.

Outside the nvim, there is a tmux and my slimzsh shell that contains many handy aliases for quickly finding the projects and grep’ing the data in the most handy ways.

Of course, I extended the config by a lot, so it kinda became my very own thing after months of configuring it and I’m very proud of it. What do I love about it most?

It combines the best of both worlds - it’s beautiful and very practical (and fast). It gives me all the tools I need for my job and personal things while keeping it very simple and just as beautiful as possible. Also, it’s blazingly fast since it’s CLI-based

I enjoy practical things that are also beautiful at the same time. My config is practical, handy, and eye-pleasing at the same time  :)

— Kamil

Favorite Tools

• Tmux: Terminal multiplexer.

• Neovim: Vim-based text editor.

• lazygit: Simple terminal UI for git commands.

• lazydocker: The lazier way to manage everything Docker.

• arc: Web Browser.

• Obsidian: Note-taking app.

• excalidraw: Virtual collaborative whiteboard tool.

• Raycast: A collection of powerful productivity tools all within an extendable launcher. Fast, ergonomic, and reliable.

• keepassxc: Password manager.

• fzf: command-line fuzzy finder.

Dotfiles

I'm still messing around so it's not ready to use, but I hope anyone can find something valuable there :) — Kamil

You can find Kamil’s dotfiles here: https://github.com/Kamyil/.dotfiles/tree/main

Favorite Books

Technical:

• Design Patterns: Elements of Reusable Object-Oriented Software 1st Edition

Non-Technical

• Sherlock Holmes books