Linux text editors in 2026: pick by task, not by fandom

Why “which editor” is the wrong first question

On Linux you have about 40 different text editors installed by default depending on the distro. The real question is what you’re editing. A shell script, a markdown note, a Python file, a 2 GB log file, and a YAML config all want different things — modal editing, syntax highlighting, low latency on huge files, or just “let me write a sentence and save”.

This page picks eight editors that actually ship on mainstream distros in 2026 — four terminal, four GUI — and tells you when each one is worth opening.

Terminal editors

nano — the default that just works

nano is the only editor most distros ship with that opens, edits, and saves without a tutorial. The shortcut hints at the bottom are the entire user manual.

nano /etc/hosts          # edit a file
sudo nano /etc/fstab     # needs root
nano                     # open a new buffer, Ctrl+O to save

Useful shortcuts:

• Ctrl+O — write the file (Save)
• Ctrl+X — exit (asks to save if dirty)
• Ctrl+K — cut the current line
• Ctrl+W — search
• Ctrl+ — go to line number

nano is for when you don’t want to think. Config edits, one-off bash scripts, /var/log spelunking. Use it forever, no one will judge.

vim — already installed, already modal

Every Linux box has vim (or vi). You don’t have to love it, but you should be able to quit it:

vim file.txt

i              enter Insert mode
Esc            back to Normal
:w             save
:q             quit
:wq            save and quit
:q!            quit without saving
/pattern       search
:%s/old/new/g  replace in whole file
dd             delete a line
yy             yank (copy) a line
p              paste

That’s the 5% of vim that handles 95% of edits. The rest is a twenty-year rabbit hole with its own Stack Exchange. Use vim when it’s already open in front of you — for a 30-second config change, don’t bother starting anything else.

micro — modern terminal editor that doesn’t fight you

micro is what you wish nano was: mouse works, copy/paste between terminal and other apps works, plugins are easy. Install:

# Debian/Ubuntu
sudo apt install micro

# Fedora
sudo dnf install micro

# Or just download the binary
curl https://getmic.ro | bash

Things it does that nano can’t:

• Mouse cursor and selection
• System clipboard sync (Ctrl+Shift+C to copy out, Ctrl+Shift+V to paste in)
• Built-in plugin manager (:plugin install — try lsp, filemanager)
• Multiple cursors (Ctrl+Alt+Shift+Arrow to add a cursor on the next row)
• Split tabs with Ctrl+W → split horizontal / vertical

micro is the editor I’d hand to a coworker who’s on Linux and wants “like Notepad but in the terminal”. It honors Ctrl+S to save like a normal app.

neovim — vim, but with a config that loads

nvim is a clean re-implementation of vim with a real config language (Lua), async plugins, and built-in LSP. If you write code every day and want the modal editing model with modern tooling:

sudo apt install neovim
mkdir -p ~/.config/nvim
nvim ~/.config/nvim/init.lua

Minimal starter init.lua:

-- ~/.config/nvim/init.lua
vim.opt.number = true
vim.opt.relativenumber = true
vim.opt.expandtab = true
vim.opt.tabstop = 2
vim.opt.shiftwidth = 2

vim.keymap.set('n', '<leader>w', ':w<CR>', { desc = 'save' })

local lazypath = stdpath('data') .. '/lazy/lazy.nvim'
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({'git', 'clone', '--filter=blob:none',
    'https://github.com/folke/lazy.nvim.git', lazypath})
end
vim.opt.rtp:prepend(lazypath)
require('lazy').setup({})

With lazy.nvim as a plugin manager you add things like nvim-lspconfig, telescope.nvim (fuzzy file finder), and treesitter (real syntax) one repo at a time. It is genuinely powerful and genuinely a time sink. Don’t adopt it because someone on Reddit said so; adopt it because you’ve hit vim’s ceiling.

GUI editors

gedit — the GNOME default

If you’re on Ubuntu or Fedora Workstation, gedit is one click away. It opens fast, highlights syntax, and gets out of your way. For Markdown notes, gedit plus the gedit-plugins package (which adds a word count, a file browser panel, and a terminal-in-panel) is a surprisingly decent writing environment.

kate — the KDE power user tool

kate is what you get when KDE takes text editing seriously. Split views, project-wide search, terminal panel, real session management (it remembers what you had open last time). If you’re already in a KDE Plasma desktop, kate will eat lunch in front of gedit.

mousepad — XFCE and LXQt

mousepad is intentionally tiny. It does tabs, syntax highlighting, and search. That’s it. It’s the right answer on a Pi running XFCE because the alternatives would jank the display.

VS Code — the cross-platform one

code (Visual Studio Code) is a full IDE dressed as a text editor. It runs on Linux natively, with extensions for nearly every language, an integrated terminal, git tooling, and remote-SSH editing. It is Electron and it will use 800 MB of RAM to open a JSON file, which is the price of admission. If you write code professionally and don’t want to maintain a Neovim config, code is the sane choice.

Install on Ubuntu:

wget -qO- https://packages.microsoft.com/keys/microsoft.asc | 
  sudo gpg --dearmor -o /usr/share/keyrings/packages.microsoft.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/packages.microsoft.gpg] 
  https://packages.microsoft.com/repos/code stable main" | 
  sudo tee /etc/apt/sources.list.d/vscode.list > /dev/null
sudo apt update && sudo apt install code

Which one should you actually use

Things that trip people up

Where do my settings live? Different per editor:

• nano → ~/.nanorc
• vim → ~/.vimrc
• micro → ~/.config/micro/settings.json
• nvim → ~/.config/nvim/init.lua
• gedit → dconf (use dconf-editor)
• kate → ~/.config/katerc
• code → ~/.config/Code/User/settings.json

Editing files as root safely. Use sudoedit instead of sudo nano. It copies the file to a temp location, opens it as your user, then copies it back. Your editor crashes don’t corrupt the original, and you can run nano while keeping your colors:

sudoedit /etc/fstab

Mouse not working over SSH? Most terminal editors (vim, micro, nvim inside a normal terminal) read mouse events from the terminal emulator — if mouse mode is on and the SSH server and client both pass it through, dragging to select works. If it doesn’t, run unset TERM and try again, or check that AllowTcpForwarding yes is on the server’s sshd_config.

Font and rendering. If micro shows boxes for CJK characters, install a Noto CJK font:

sudo apt install fonts-noto-cjk

Then reopen the editor. Same trick for gedit/kate.

What about Emacs

Emacs is a Lisp interpreter that happens to edit text. It’s not on this list because it deserves its own page; apt install emacs ships GNU Emacs 28+ on every major distro, it does everything, and configuring it is the project itself. If you know you want it, you don’t need this article.

Closing

Don’t pick an editor from a listicle. Pick the one that came with the desktop you’re sitting at, learn its save-and-quit keystroke, and move on. The right time to switch is when you can name a specific thing your current editor can’t do — not before.

If you found this useful, the deep dives on vim, neovim config patterns, and VS Code over SSH go further on each of those.