https://github.com/neovim/neovim/pull/41587
courtesy of justinmk

In my previous video, many of you asked me for markdown images using vim.ui.img, so here is a complete example.

I cover how to:

• Detect images under the cursor
• Handle cursor movement with autocommands
• Preview local images using relative and absolute paths
• Preview images hosted on the web
• Make HTTP requests to download remote images
• Parse Markdown image syntax
• Display images directly inside Neovim using `vim.ui.img`

Source code:
https://github.com/FractalCodeRicardo/dev-config/tree/master/nvim/lua/my/markdown-images

local api = vim.api
local fn = vim.fn
local img = vim.ui.img
local net = vim.net

local function parse_image(line)
  local l = vim.trim(line)
  local is_image = l:sub(1, 2) == "!["

  if not is_image then
    return nil
  end

  local image = vim.split(l, "%(")[2]
  image = image:sub(1, #image - 1)
  return image
end

local function is_web(file)
  return file:sub(1, 4) == "http"
end

local function get_blob(file, callback)
  if not is_web(file) then
    callback(fn.readblob(file))
    return
  end

  net.request(
    file,
    {},
    function(err, res)
      callback(res.body)
    end
  )
end

api.nvim_create_autocmd("CursorMoved", {
  callback = function()
    local win = api.nvim_get_current_win()
    if not api.nvim_win_is_valid(win) then
      return
    end

    local line = api.nvim_get_current_line()
    local file = parse_image(line)

    if file == nil then
      return
    end

    if not is_web(file) and fn.filereadable(file) ~= 1 then
      return
    end

    get_blob(file, function(content)
      vim.schedule(function()
        img.set(content, {
          col = 55,
          row = 1,
          width = 35,
          height = 15
        })
      end)
    end)
  end
})

A breakdown of how Neovim registers work under the hood and their common quirks, so that you can use them effectively in your workflow.

Topics covered:

• Unnamed ("") vs. yank register ("0)
• Named registers ("a-"z) and appending ("A-"Z)
• Numbered registers and small deletes ("-)
• Black hole register ("_) for silent deletions
• System clipboard ("+, "*") registers
• Contextual registers: Current file ("%), command (":), search ("/)

As a beginner, I always wondered: can I run Neovim natively on an iPad?

And 6 years later...

I'm not a beginner anymore, so I can finally answer that question myself:

Yes. You can.

I built a native Neovim app for iPad.

Under the hood, it runs Neovim compiled to WASM in headless mode inside a WebView. The WebView itself is basically invisible — just a 1×1 pixel view on screen.

Headless Neovim sends UI events over RPC to the app, and the app parses those events and renders the Neovim UI directly using Metal on the GPU.

So... is this a GPU-accelerated native Neovim build for iPad?

Well, I'm not sure whether WASM counts as "native." But compared with using an SSH terminal emulator, or running Linux in a VM and then running Neovim inside that, I'd say this is progress.

It's still at a very early stage, and there are plenty of usability problems left to solve.

But it works. Demo: https://youtu.be/eDGLKUj3KEc?si=hea5KotIHWNSq2LZ

I'd love to hear what the Neovim community thinks, especially any advice on where to take it next.

That's the whole post.

Telescope makes me so much faster when going through code, if the developers are seeing this, I love you guys.

hello everyone;)

my problem with lua config was discovery - thinking "this plugin probably has an option for that" and not wanting to dig through docs to find out

so every plugin gets a config menu with its options listed and described (you can hook up functionality to custom keymaps etc). generates one init.lua, installs via vim.pack, output has no dependency on the app

plugin support comes from json schemas, its not hardcoded, so supporting new one doesn't mean touching the app code. 28 ship with it

https://github.com/dejwi/vinela

honest bit: if you enjoy writing your config by hand you won't want/like this, and that's fair. posting in case someone who’s more casual about their setup wants the same thing

Neovim 0.13 introduces vim.ui.img, a new API that makes working with images directly from Neovim much easier.

In this video, I take a look at the new vim.ui.img API and explore how it works. We'll go through the main functions, including get, set, and del, and then use them to build practical examples.

You'll see how to:

• Get, create, and delete images with vim.ui.img
• Move images programmatically
• Resize images dynamically
• Create a simple live image preview inside

Source Code:

https://github.com/FractalCodeRicardo/dev-config/tree/master/nvim/lua/my/vim-img

SOLVED (below)

I used `ts_ls`, with the default configuration like https://github.com/nvim-lua/kickstart.nvim

Suddenly today, the lsp is not working anymore, no idea why.
The lsp is correctly enabled, but when I check the client there are none {}

I don't really understand what changed and why it's now not working

If anyone has a miracle magical debugging solution to propose, feel free !

What I have tried so far
- delete and reinstall my vim.pack
- restart/enable/disable the lsp

- tried to use the latest stable nvim
- the lsp binary typescript-language-server seems to work fine

Thanks !

SOLVED

I found the bug: a new deno.json was created and was used
But since it did not had any lsp configuration, the lsp wasn't working

Solution: delete the deno.json and keep the good tsconfig.json

Thanks !

In the scenario shown on the screenshot, when I'm in insert mode in a line which only contains whitespace, if I press Escape to go back to normal mode, the whitespace is deleted, and the line becomes empty.

So after I press Escape, the two tabs are deleted, the line becomes empty.
Does anyone know what setting or plugin might be doing this?
It only happens if the line _only_ contains whitespace. If there is at least one non-whitespace character on the line, then the whitespace (even if it's trailing) is preserved.

If I start neovim without using any of my config, then it does not happen, so it seems something in my config is causing this, but I don't know how I could pinpoint the cuplrit, any advice is appreciated.

Monthly meme thread

I used `ts_ls`, with the default configuration like https://github.com/nvim-lua/kickstart.nvim

Suddenly today, the lsp is not working anymore, no idea why.
The lsp is correctly enabled, but when I check the client there are none {}

I don't really understand what changed and why it's now not working

If anyone has a miracle magical debugging solution to propose, feel free !

What I have tried so far
- delete and reinstall my vim.pack
- restart/enable/disable the lsp

- tried to use the latest stable nvim
- the lsp binary typescript-language-server seems to work fine

Thanks !

Hey vimmers!

A while back I shared md-render.nvim, a Markdown rendering engine for Neovim: https://github.com/delphinus/md-render.nvim — two things have landed since then that I think are worth a look.

Headings are now drawn at a real font size. Kitty's text sizing protocol (OSC 66) gives every level its own scale, from 2.00x for # down to 1.17x for ######, and the plain heading stays in the buffer underneath so nothing else changes. Kitty 0.40+ only; everywhere else it costs nothing and headings look exactly as they always did.

The other is :vert MdRender split, which puts the source and the rendered view side by side. Edits propagate live, and the cursor and scroll position are synced both ways.

Requires Neovim 0.12+ now, and a Kitty Graphics Protocol compatible terminal for inline media as before. The file in the video ships with the repo — nvim +"MdRender pager" assets/whats-new.md after cloning shows the same thing. Feedback welcome, especially on the scaled headings; they're new and Kitty-only.

:h vim.lsp:Config filetype option says

Filetypes the client will attach to, or nil for ALL filetypes.

Lets say I'm using clangd vim.lsp.config('clangd', { cmd = { 'clangd' }, filetypes = { 'c', 'cpp' } }) vim.lsp.enable('clangd')

When checking :checkhealth vim.lsp, I'll have clangd enabled even if I dont have a C/C++ buffer open. vim.lsp: Enabled Configurations ~ - clangd: - cmd: { "clangd" } - filetypes: c, cpp Can this become a problem if have multiple LSPs enabled? If so can/should I only load LSPs based on opened buffers like ``` vim.api.nvim_create_autocmd("BufEnter", { pattern = { 'c', 'cpp' }, callback = function() local ft = vim.bo.filetype

    if ft == 'c' or ft == 'cpp' then
        vim.lsp.enable('clangd')
    end
    -- others LSPs here
    --
    --
end,

}) ```

I use codecompanion a lot and with all the ways to manage context and use tools it's all I could ask for. The only snag is when trying to share screenshots of errors or the UI, there is no way to paste images directly into codecompanion. There is a way to add an image file but I want to skip the hassle of saving the screenshot to disk. Any options?

Hey, I used kickstart.nvim when I first started using vim around 2 years ago and now I've made my own configurations. Why does kickstart not use lazy nvim. I've been using it for a while, is it bad. Am I missing out on something for not using it. My settings are a whole of a lot simpler compared to what other people have because I just use lazy and add set up certain settings as I see fit.

Also when you push your settings to github, should you put anything in the .gitignore. I currently have nothing in my .gitignore.

For context my dotfiles: https://github.com/Barmanji/dotfiles/tree/master/nvim/.config/nvim

# ISSUE 1: LAG-

Issue: When I open a tsx/jsx/.md files then it lags for 5-10 seconds first time then it works fine.

Temp Solution: If i delete big files like node_modules, .git, .next, .agent, .claude all other other AI Slop which gets auto download for some reason then it works fine again.

-> I tried excluding them in vtsls lsp and treesitter but it doesnt seems to be working and i need those big files for my work as well (even with node_modules alone it lags for 3-5 second for the first time)

# ISSUE 2: Treesitter-

issue: So when i open a tsx file html elements (<div>, <html>, <main> etc) doenst get colored automatically, i have to press "K" (Shift-K: its a lsp.buf.hover set, then it shows color back)

NOTE: Even with the above discussed technique the color in JSX file doesnt come so i am litreally staring at <divs> with black and white color. [image 1st]

Its been 2 days and I am dead solving them, would love if you can help me or give your time so i can share my screen or share SS's so show.

I've been working on fk_markdown.nvim , a Markdown renderer/previewer for Neovim, and one feature I really wanted was to make Markdown feel less like plain text and more like an actual document.

The interesting part is that it supports both image and LaTeX rendering, not just syntax highlighting.

Images inside Neovim

You can embed images directly in your Markdown and have them rendered while working inside Neovim.

So instead of seeing:

![architecture](./images/architecture.png)

you can actually see the image in the editor.

This is especially useful if you use Markdown for documentation, notes, research, READMEs, or technical writing.

$\LaTeX$ equations

It also supports rendering LaTeX math, including inline and block equations.

For example:

Inline: $E = mc^2$

$$
\int_0^\infty e^{-x^2} dx = \frac{\sqrt{\pi}}{2}
$$

The goal is to make mathematical notes readable without constantly switching to a browser or external Markdown viewer.

And there's a web preview too

The same Markdown can be viewed through a web preview, with images and LaTeX rendered there as well.

So the workflow becomes something like:

Write Markdown → see rendered images/math in Neovim → open web preview when you want a full-page view

I built this primarily because I wanted a Markdown workflow that stays inside Neovim while still handling the things that usually make Markdown previews necessary.

Would love to hear what other features people would want in a Neovim Markdown renderer.

GitHub: fk_markdown.nvim

It's still early

fk_markdown.nvim is currently in its initial phase, so there are likely bugs, edge cases, and things that don't work perfectly yet.

I'm sharing it early because I'd really appreciate feedback from the Neovim/Markdown community. If you try it and run into something weird, please open an issue or let me know. Contributions and ideas are also very welcome.

and this plugin is highly inspired by render-markdown.nvim

Hey, folks!

Since the first release of celeste_comment.nvim and my last post here, I've received some great feedback and also ran into a few issues myself during daily use. Over the past couple of weeks, I've been fixing bugs and improving the documentation, and I'm happy to say a new version is now out.

I've seen some comments on other platforms asking: "Neovim already has built-in commenting, so why do we need another plugin?"

My answer is -- if you like any of the following:

1. Prefer the commenting experience you get in editors like VSCode/Zed
2. Like the sticky cursor behavior
3. Enjoy keeping visual selection after comment/uncomment
4. Need block comment support
5. Want toggle comment in insert mode with sticky cursor
6. Care about preserving regular marks and extended marks after commenting
7. Need explicit "force add comment" and "force remove comment" actions
8. Want out-of-the-box comment support for JSX/TSX and similar file types

Then give celeste_comment.nvim a try! I'd love to hear your feedback!

So in the motion.txt gO gives you the table of contents and I am interested in finding out how that code is implemented. Anyone know where to look in the neovim code for that?

I've been using neovim for about two years now and recently found neovide. Like most gui's it has better colors and better rendering than I'm able to get from my terminal emulator (ghostty). Some of the animations are definitely a nice addition, and thankfully I can turn off the ones that aren't.

Unsurprisingly, adding a gui app doesn't work well with my existing tmux workflow of putting nvim on tab 1 as I can't swap to it using my existing tmux bindings.

I'm curious if anyone else has run into this in the past and if/how they solved it.

Any advise greatly appreciated.

TL;DR: Tired of silent plugin breakages and acting as an unpaid sysadmin for my text editor, I'm adopting the "Wading Depth" rule. Keep Neovim shallow (fast, minimal plugins), use Helix for zero-maintenance stability, and offload complex text processing to Kakoune + standard Python scripts. Stop trying to build a fragile Lua IDE and let standard Unix tools do the heavy lifting.

The Neovim Paradox: When Customization Becomes an Unpaid Sysadmin Job

You know the exact feeling. You open your terminal to get some actual work done, but something is off. Your statusline has vanished. Or your autocomplete is suddenly lagging.

So, you do what we all eventually do: you execute the nuclear option. You wipe ~/.local/share/nvim. You clear ~/.cache. You delete your lazy-lock.json. You reinstall every single plugin from scratch on a mathematically pristine setup. You open a file, holding your breath, and... the statusline is still gone.

No massive red error text. No traceback. Just a silent, invisible race condition between a colorscheme load order and an icon dependency update that decided to gaslight you for the next three hours.

Welcome to the unpaid systems administrator job that is modern Neovim.

Don't get me wrong—Neovim is a phenomenal piece of software. The total exposure of its API to Lua is a superpower. The ability to write a 50-line script that creates a custom, proximity-based picker for my exact workflow is something no other editor can match. But the community has aggressively sold this romantic idea of building the "perfect personalized IDE," while quietly ignoring a brutal reality: the return on investment (ROI) for maintaining a monolithic, heavily abstracted configuration is completely broken.

The effort of maintaining the tool should never outweigh the effort of hand-assembling the work itself.

After my last fight with a vanishing UI element, I realized it was time to stop drowning in plugin dependency trees and redefine my relationship with my text editor stack. I call it the "Wading Depth" philosophy.

It is a pragmatic approach to surviving terminal editors. It means aggressively stripping your setup back to the shallows—leveraging Neovim for its raw native speed and lightweight scripting, but actively refusing to buy into fragile, deeply nested IDE ecosystem plugins. More importantly, it means knowing when to abandon the Lua black box entirely and hand off the heavy text manipulation to indestructible, Unix-native workflows using tools like Kakoune and standard Python scripts.

If you are tired of your configuration acting like a temperamental pet, here is how to triage your tooling, embrace transparent failures, and finally get your time back.

Silent Failures vs. Transparent Failures

There is a fundamental difference between a tool that crashes and a tool that lies to you.

When you build a massive, interdependent configuration in Neovim, you are essentially constructing a highly complex state machine inside a Lua black box. When something goes wrong—say, an icon package updates and breaks compatibility with your statusline—the editor rarely screams. To prevent a total crash, the rendering loop just safely swallows the error. The UI fails silently. You are left staring at a blank space at the bottom of your terminal, guessing which of your 40 plugins decided to stop talking to the others.

You aren't debugging your code anymore; you are debugging a fragile ecosystem's internal lifecycle.

This is exactly where the "selection-first" Unix philosophy of an editor like Kakoune completely shifts the paradigm. Kakoune does not attempt to embed an entire programming ecosystem into its memory space to manage list formatting, sorting, or complex text extraction. Instead, it acts as a lightweight interactive router for the environment you already control.

If I have a messy block of raw project notes that needs to be formatted into a structured Markdown checklist, I don't go hunting for a markdown-formatter.nvim plugin. I highlight the text, press |, and pipe the selection directly into a custom Python script.

The editor treats the text simply as a standard Unix stream—passing it to standard input (sys.stdin) and replacing the buffer with standard output (stdout).

This architecture guarantees what I call transparent failure.

If my Python script has a typo, a syntax error, or a missing module, Kakoune doesn't panic. It doesn't drop my UI, corrupt my buffer, or freeze the terminal. It safely catches the failure, aborts the text replacement, and prints the standard Python traceback right on the screen. It fails exactly because it was my fault, and it tells me exactly why. I read the error, fix my Python script, and run it again 10 seconds later.

By pushing the heavy lifting out of the editor and into standalone shell or Python scripts, you eliminate the plugin sprawl. More importantly, you build workflows that are immune to package manager drift. A Python script reading standard input today will behave exactly the same way twenty years from now, completely bypassing the endless churn of the modern editor ecosystem.

The Pragmatic Triage: Stop Fighting Editor Religions

The developer ecosystem loves a holy war. We are constantly pressured to pick one editor, pledge absolute allegiance to it, and force it to do everything from managing git conflicts to tracking our calendars.

But you don't have to commit to one editor religion. By treating your terminal tools as a pragmatic triage system rather than an identity, you can completely eliminate configuration anxiety. Here is how to divide the labor:

1. Neovim: The "Wading Depth" Daily Driver Keep Neovim for what it is genuinely best at: blistering speed, familiar motions, and highly targeted Lua scripts (like that custom proximity-based picker). But aggressively stay in the shallows. Use thin, unopinionated integrations like the mini.nvim suite instead of massive IDE plugin stacks. If a feature requires three different plugins to communicate asynchronously just to render a UI element, it does not belong in your Neovim config.

2. Helix: The Zero-Maintenance Sanctuary When Neovim is acting up, or you just need to drop into a codebase and write without distractions, Helix is the ultimate fallback. Because Helix ships with Tree-sitter, LSP integration, and fuzzy finding entirely built-in, there is no fragile plugin system to break. It is a walled garden, but it is a frictionless one. You trade customizability for absolute, guaranteed stability.

3. Kakoune: The 20-Year Workshop For heavy structural text manipulation and complex data parsing, Kakoune is the long-term investment. Rather than embedding a massive, shifting API, Kakoune embraces the Unix philosophy by acting as an interactive client for your existing shell. You visually select text using its intuitive object-first model, and pipe it directly through standard Python or POSIX scripts. A text-processing script you write today will work exactly the same way two decades from now, completely immune to editor updates.

Conclusion: Reclaiming Your Time

At the end of the day, text editors are just tools to move characters on a screen. If the process of maintaining the tool starts feeling more complex than the software you are trying to write, you have lost the plot.

The developer community's obsession with the "perfect configuration" is a trap. It is okay to admit that configuring Neovim is exhausting. It is okay to use Helix because you don't want to think about package managers today. And it is incredibly liberating to write a standard Python script, pipe it through Kakoune, and know that you will never have to debug it after an editor update.

Stop acting as an unpaid systems administrator for your own terminal. Strip the dependencies, build durable Unix pipelines for the heavy lifting, and get back to the actual work.

Tags: #neovim #kakoune #helix #unix-philosophy #developer-tools #productivity #linux #vim

I love vifm. I have no idea why it's basically never mentioned.

I was searching for a TUI file manager a few years back and the closest thing to vim was ranger but it didn't really click for me as well as other options.

Then I found out about vifm which is exactly what I wanted:

• It has the same concepts of windows/tabs/keymaps/commands with the same defaults (motions also work)
• I can define custom keymaps and commands
• Autocmds! For example, I can set it to sort by name on DirEnter if I want a specific directory sorted some other way than the default
• I can decide how I want different filetypes to be previewed/opened using custom commands with fallbacks
• It has marks! Which are really useful for quick navigation (I defined a few marks in my config like 'd to go to ~/Downloads or 'c to go to ~/.config
• There's also :history which shows recent directories I can jump to
• I can also preview images inside the terminal which is super helpful

My only caveat would be that the default delete action actually sends to vifm trash directory, this is done so cut operations can be performed by deleting and pasting like in neovim but it still copies the file to the trash directory instead of just deleting/moving it like rm and mv do so I still use rm and mv for that. You can disable that behavior but tbh sometimes cutting small files is helpful and I treat rm/delete operations very seriously (been cut a few times before!) so I don't want to accidentally trigger a delete if I type dd.

Why not use a plugin like mini.files?

I love mini.files and use it extensively when actually using nvim. Its way of operation is also exactly what I wanted (basically like oil.nvim but with a better ux from my point of view). But vifm is an actual file manager with commands/marks/history while mini.files is perfect for quick file operations in the same project while working inside nvim.

I have vifm remapped to v in my .zshrc as well as a hyprland keybinding setting mainMod + E to kitty -e vifm. Also, when inside vifm I just open nvim in the cwd with ctrl+O and after quitting nvim end up back in vifm

Here are some useful snippets I have in my config (some may be defaults because I last edited it a long time ago and don't remember which is which):

set shell=/usr/bin/zsh
set grepprg="rg\ --color=never\ -Hn\ %i\ %a\ %s\ %u"
set findprg=fd\ --color=never\ %p\ %s\ %u
set sort=-mtime
set history=10000
set undolevels=100
set relativenumber
autocmd DirEnter ~/Pictures/* setlocal sort=+name

mark P ~/Pictures/
mark R /
mark c ~/.config/
mark d ~/Downloads/
mark h ~/
mark l ~/.local/share/
mark m /mnt/
mark r /run/media/
mark t ~/.local/share/vifm/trash/
mark u /usr/share/




command! df df -h %m 2> /dev/null
command! diff vim -d %f %F
command! zip zip -r %c.zip %f
command! run !! ./%f
command! make !!make %a
command! mkcd :mkdir %a | cd %a
command! vgrep vim "+grep %a"
command! reload :write | restart full
command! fdfzfdir :set noquickview | :execute 'goto' fnameescape(term('fd --type d | fzf --reverse 2>/dev/tty'))
command! fdfzffile :set noquickview | :execute 'goto' fnameescape(term('fd --type f | fzf --reverse  2>/dev/tty'))

" open pdfs using zathura in the background so closing vifm doesn't close zathura
filextype {*.pdf},<application/pdf> zathura %f %i &, apvlv %f &, xpdf %f &

" preview pdfs as txt using pdftotext
fileviewer {*.pdf},<application/pdf> pdftotext -nopgbrk %c - 
fileviewer *.ipynb pandoc -f ipynb -t gfm %c


" Toggle visibility of preview window
nnoremap w :view<cr>
vnoremap w :view<cr>gv
nnoremap <tab> <nop>
nnoremap <tab><tab> :tabnew<cr>
nnoremap <tab>d :tabclose<cr>
nnoremap <tab>] :tabnext<cr>
nnoremap <tab>[ :tabprev<cr>
nnoremap . za
nnoremap T :!kitty -d %d &<CR>
nnoremap J 5j
nnoremap K 5k
nnoremap <C-s> <C-w>s
nnoremap <C-v> <C-w>v
nnoremap <C-r> :reload<cr>
nnoremap < <c-w><
nnoremap > <c-w>>
nnoremap x <c-w>p
nnoremap <c-j> <c-w>j
nnoremap <c-k> <c-w>k
nnoremap <c-l> <c-w>l
nnoremap <c-h> <c-w>h
nnoremap = <c-w>=
nnoremap | <c-w>|
nnoremap <space> <nop>
nnoremap <space><space> :history<cr> 
nnoremap <space>f :find<space>
nnoremap <space>d :fdfzfdir<cr>
nnoremap <space>e :fdfzffile<cr>

nnoremap o :file<CR>
nnoremap <c-o> :!nvim<CR>
" Quit vifm
nnoremap q :quit<CR>

" Open file in the background using its default program
nnoremap gb :file &<cr>l

So if you haven't already, try vifm and show it some love!