Telescope, Treesitter et les plugins essentiels pour coder dans Neovim
- Publié le
- ·8 min de lecture
Au-delà du LSP
OK, un LSP bien configuré, c'est déjà pas mal. Mais ça suffit pas. Pour vraiment transformer Neovim en un vrai environnement de développement, il faut ajouter une couche de plugins solides qui gèrent la recherche, la manip de code et tout ce qui touche à Git. Je vais vous montrer ceux que j'utilise tous les jours, et franchement, sans eux, je serais perdu.
Telescope : chercher TOUT
Telescope c'est mon couteau suisse. Le plugin que j'utilise le plus dans ma config, sans doute 10x par jour. C'est un fuzzy finder - en gros, ça vous permet de chercher des fichiers, du texte, des buffers, de l'aide, vraiment tout ce que vous pouvez imaginer, le tout depuis une seule interface unifiée et élégante.
Performance avec fzf-native
Maintenant, par défaut Telescope c'est... pas terrible en perf sur un gros projet. Des milliers de fichiers à chercher? Vous allez sentir la latence. Bref, j'ai installé l'extension telescope-fzf-native. C'est un binaire compilé en C qui remplace l'algorithme de recherche par défaut. La différence? C'est la nuit et le jour. Vraiment.
Keybindings (les vrais shortcuts qu'on utilise)
local builtin = require("telescope.builtin")
vim.keymap.set("n", "<leader>ff", builtin.find_files, { desc = "Find files" })
vim.keymap.set("n", "<leader>fg", builtin.live_grep, { desc = "Live grep" })
vim.keymap.set("n", "<leader>fb", builtin.buffers, { desc = "Buffers" })
vim.keymap.set("n", "<leader>fh", builtin.help_tags, { desc = "Help tags" })
vim.keymap.set("n", "<leader>fr", builtin.oldfiles, { desc = "Recent files" })
vim.keymap.set("n", "<leader>fw", builtin.grep_string, { desc = "Grep word under cursor" })
vim.keymap.set("n", "<leader>/", builtin.current_buffer_fuzzy_find, { desc = "Fuzzy find in buffer" })
Vous utilisez surtout <leader>ff pour ouvrir un fichier, <leader>fg pour balayer le projet entier avec une recherche textuelle. Et puis <leader>/? C'est mon killer feature - tu cherches dans le buffer courant, c'est 100x mieux que le / vanilla.
Configuration et filtres (spoiler: les patterns d'ignore c'est CRUCIAL)
require("telescope").setup({
defaults = {
path_display = { "truncate" },
file_ignore_patterns = {
"node_modules/",
".git/",
".next/",
"dist/",
"%.lock",
"%.min%.js",
"%.min%.css",
},
mappings = {
i = {
["<C-j>"] = require("telescope.actions").move_selection_next,
["<C-k>"] = require("telescope.actions").move_selection_previous,
["<C-q>"] = require("telescope.actions").send_selected_to_qflist
+ require("telescope.actions").open_qflist,
},
},
},
})
Parlons des détails, parce que franchement, c'est là où la magie se produit :
- Ignore patterns : Bon, ici j'ai blacklisté
node_modules,.git,.next,dist, les lock files et les minifiés. Pourquoi? Parce qu'en faire une recherche sur un Next.js, sans ça, tu vas avoir genre 50 000 résultats pourris. Ahh et aussi%.locket%.min.js- c'est du regex Lua, pas du glob classique. - Path display truncate : Les chemins trop longs c'est chiant à lire. La troncature les rend plus digestes.
- C-j/C-k en insert mode : Navigation dans les résultats sans quitter le mode insertion. Petit truc mais ça change tout dans le workflow.
- C-q : Envoie les résultats à la quickfix list. Hyper utile quand tu veux faire un search-and-replace sur plusieurs fichiers d'un coup.
Ah et la preview? Elle utilise Treesitter pour la coloration syntaxique directement dans le panneau. Pas du regex miteux - du vrai parsing.
Treesitter : plus qu'une coloration syntaxique
Treesitter - c'est pas juste un coloriseur syntaxique (d'ailleurs, si c'était juste ça, ça serait une déception). Non. C'est un vrai parser incrémental qui comprend la structure du code. Il sait où commencent et finissent les fonctions, où sont les commentaires, comment les blocs s'imbriquent. Pas du regex primitif comme dans les vieux editeurs - du vrai parsing d'AST.
Mes parsers (18 au total, ça couvre presque tout)
require("nvim-treesitter.configs").setup({
ensure_installed = {
"bash", "c", "css", "dockerfile", "go", "html",
"javascript", "json", "lua", "markdown", "markdown_inline",
"python", "rust", "tsx", "typescript", "vim", "vimdoc", "yaml",
},
auto_install = true,
highlight = { enable = true },
indent = { enable = true },
})
18 parsers. Bash, C, CSS, Docker, Go, HTML, JavaScript, JSON, Lua, Markdown, Python, Rust, TypeScript, Vim, YAML... Franchement c'est les langages que j'utilise 95% du temps. Et si un jour je dois travailler en Elixir ou en Clojure? auto_install = true fait que ça s'installe tout seul. Magique.
Autotag pour HTML/JSX (un vrai game-changer en React)
nvim-ts-autotag c'est en aparté mais ça mérite d'être mentionné. Vous fermez une balise HTML ou JSX, et Treesitter vous la ferme automatiquement. Mieux encore: vous modifiez le tag d'ouverture? Le tag de fermeture se met à jour tout seul. Avant d'avoir ça, j'avais l'habitude de laisser des balises pas fermées. Maintenant? Impossible de faire erreur.
Tailwind CSS (trois plugins parce que pourquoi pas)
Frontend? J'ai intégré trois trucs Tailwind :
- tailwind-tools.nvim : Aperçu des couleurs directement dans le buffer. Les longues listes de classes sont "concealed" (cachées) pour la lisibilité. Et l'ordre des classes? Trié automatiquement. C'est du luxe.
Les indispensables de l'édition
nvim-autopairs
{
"windwp/nvim-autopairs",
event = "InsertEnter",
config = function()
local npairs = require("nvim-autopairs")
npairs.setup({
check_ts = true,
})
-- Intégration avec nvim-cmp
local cmp_autopairs = require("nvim-autopairs.completion.cmp")
require("cmp").event:on("confirm_done", cmp_autopairs.on_confirm_done())
end,
}
Fermeture automatique des parens, crochets, accolades, guillemets - tout ce qui doit être fermé. Mais le truc cool c'est check_ts = true - il demande à Treesitter avant de fermer. Pas de parenthèse orpheline dans un commentaire, pas de guillemet cassé dans une string. Intelligent. Et intégration cmp? Quand tu acceptes une complétion, les paires se ferment aussi.
Comment.nvim (commenter du code sans penser)
{
"numToStr/Comment.nvim",
opts = {},
}
gcc toggle une ligne de code entre commentée/décommentée. gc suivi d'un motion? gcap commente un paragraphe entier. gc3j commente 3 lignes. Le plugin sait quel symbole de commentaire utiliser selon la langue du fichier. Pas besoin de réfléchir.
nvim-surround (manipuler les "parenthèses")
{
"kylechui/nvim-surround",
version = "*",
event = "VeryLazy",
opts = {},
}
Vous avez un mot et vous voulez le mettre entre guillemets? Entre parenthèses? Entre backticks? C'est exactement à ça que nvim-surround sert.
ys{motion}{char}- ajouter un wrapper.ysiw"entoure le mot sous le curseur de guillemets.cs{old}{new}- changer.cs"'remplace les guillemets doubles par des simples. Je fais ça tous les jours.ds{char}- supprimer.ds(enlève les parenthèses autour de l'expression.
todo-comments.nvim (ne pas oublier qu'on laisse des TODOs)
{
"folke/todo-comments.nvim",
event = "VimEnter",
dependencies = { "nvim-lua/plenary.nvim" },
opts = { signs = false },
}
Vous laissez un TODO ou un FIXME dans votre code? Ce plugin les highlight en couleurs différentes. TODO en bleu, FIXME en rouge, BUG en orange. Comme ça tu les vois dans le code et tu les oublies pas.
Formatting avec Conform.nvim (surtout ne pas gérer ça à la main)
Le formatage automatique est géré par Conform.nvim :
{
"stevearc/conform.nvim",
event = "BufWritePre",
config = function()
require("conform").setup({
formatters_by_ft = {
javascript = { "prettier" },
typescript = { "prettier" },
typescriptreact = { "prettier" },
javascriptreact = { "prettier" },
css = { "prettier" },
html = { "prettier" },
json = { "prettier" },
yaml = { "prettier" },
markdown = { "prettier" },
lua = { "stylua" },
python = { "ruff_format" },
},
format_on_save = {
timeout_ms = 3000,
lsp_format = "fallback",
},
})
vim.keymap.set({ "n", "v" }, "<leader>cf", function()
require("conform").format({ async = true, lsp_format = "fallback" })
end, { desc = "Format file or selection" })
end,
}
Voilà le plan:
- Prettier pour tout ce qui est web - JS, TS, CSS, HTML, JSON, YAML, Markdown. J'ai galéré 2 heures pour bien le configurer la première fois, mais c'est rock-solid maintenant.
- Stylua pour le Lua (incluant ma config Neovim). Parce que oui, même ton éditeur doit être formaté proprement.
- ruff_format pour Python (c'est plus rapide que black et ça regarde, ça ressemble à du vrai code).
- Format on save qui se déclenche avec un timeout de 3 secondes. Pas assez long? Ça passe au LSP fallback.
- Fallback LSP - si rien d'autre marche, demande au LSP de formater.
<leader>cfsi tu veux formater manuellement (rare, mais ça aide à déboguer).
Les binaires? Mason les installe tout seul grâce à mason-conform. Je n'ai jamais eu à les installer à la main.
Gitsigns : voir Git dans la marge (c'est joli, je vous jure)
Gitsigns affiche les changements Git directement dans la colonne de signes, ligne par ligne. Des petits blocs colorés qui indiquent ce qui a changé.
{
"lewis6991/gitsigns.nvim",
opts = {
on_attach = function(bufnr)
local gitsigns = require("gitsigns")
local map = function(mode, l, r, opts)
opts = opts or {}
opts.buffer = bufnr
vim.keymap.set(mode, l, r, opts)
end
-- Naviguer entre les changements
map("n", "]h", gitsigns.next_hunk, { desc = "Next hunk" })
map("n", "[h", gitsigns.prev_hunk, { desc = "Previous hunk" })
-- Actions sur les hunks
map("n", "<leader>hs", gitsigns.stage_hunk, { desc = "Stage hunk" })
map("n", "<leader>hr", gitsigns.reset_hunk, { desc = "Reset hunk" })
map("n", "<leader>hp", gitsigns.preview_hunk, { desc = "Preview hunk" })
map("n", "<leader>hb", gitsigns.blame_line, { desc = "Blame line" })
end,
},
}
Les symboles dans le gutter? Ils disent "ajouté", "modifié", "supprimé". Les keybindings vous laissent naviguer entre les hunks (]h / [h), de les stage/reset individuellement, de voir le diff avant de commiter, ou de regarder qui a changé cette ligne (blame). Tout sans quitter Neovim.
Pour finir
Voilà l'arsenal. Telescope pour chercher n'importe quoi instantanément. Treesitter pour comprendre le code en profondeur. Conform qui formate tout proprement sans que vous le demandiez. Gitsigns pour voir l'histoire du code dans la marge. C'est pas des plugins flashy - chacun fait une chose, et la fait bien. C'est exactement la philosophie Unix que j'adore dans Neovim.
Article précédent
← Migrer ses données Synology vers un NAS Debian sans rien perdreArticle suivant
Docker sur NAS : architecture réseau et bonnes pratiques→