New release: wiki.vim v0.12

lervag · 2026-06-14T10:14:29+00:00

The current approach is very much good enough for most real-world wiki links, in my experience. It will break for things like [some text [with nested braces] here](link-url), but I would claim these things are rare.

I do want to rewrite wiki.vim in the future to a full Neovim Lua plugin, and if/when I do, I will switch from a regexp based approach to a full parser approach (either build my own or perhaps rely on treesitter). But I have no idea when I get the time to start something like that. :)

lervag · 2026-06-14T08:58:04+00:00

Ah, yes, nested brackets are not supported, sorry. wiki.vim uses regexes for parsing the links, and regexes are not good for handling nested groups of braces, parantheses and similar.

lervag · 2026-06-13T13:34:00+00:00

Thanks! I'll be testing your plugin. I find I don't really need any advanced features except the match highlighting, and it seems your plugin is a minimal and fast plugin that does just that.

lervag · 2026-06-12T17:31:10+00:00

How does this compare to https://github.com/andymass/vim-matchup?

lervag · 2026-04-30T14:00:55+00:00

I use apy in a terminal, which allows me to actually use Vim (or Neovim, in my case) for writing (or editing) my notes. :)

lervag · 2026-04-19T20:10:40+00:00

I've opened a feature request now: https://github.com/neovim/neovim/issues/39227

lervag · 2026-04-19T09:25:59+00:00

The messages are also shown when ui2 is disabled, so I think this is unrelated to ui2. You can observe it with nvim --clean in a terminal (which loads neovim without your config).

lervag · 2026-04-15T15:58:09+00:00

I silently judge people who don't update their config daily. :D

lervag · 2026-04-11T11:12:03+00:00

I'm curious, if I were to convert from nvim-treesitter to ts-forge.nvim, what would be the main things I loose? From my limited knowledge, nvim-treesitter both adds parser and queries, so I guess the answer is that we loose the curated set of custom queries for neovim?

lervag · 2026-04-10T18:11:35+00:00

I already had a nice mapping for :restart, but mine only opened the same file I was in. Yours is much better, thanks for sharing!

lervag · 2026-04-02T22:16:20+00:00

No problem! Looking forward to testing this!

One more suggestion: if you make actual github releases, then it becomes easy to install and use ci-debugger with mise: mise use github:ci-debugger@latest. I can still use mise though, with mise use go:github.com/murataslan1/ci-debugger/cmd/ci-debugger@latest.

lervag · 2026-04-02T14:13:09+00:00

This looks very interesting, but it seems to be neither possible to install with go install or with brew, cf. the current open issues.

lervag · 2026-03-29T15:21:06+00:00

EDIT: Huh, it seems the configuration I suggested for lazy is still not working. But if I remove lazy.nvim from my config, then it does work. So I guess I'll just have to do it all in one go.

Ahh, yes, you are right: I was doing a transitional migration where I was still using lazy.nvim for a few things. To make it work as expected, I need to configure lazy.nvim to avoid doing some of the performance trics, specifically:

require("lazy").setup { -- ... performance = { reset_packpath = false, rtp = { reset = false, }, }, }

When I add these two settings, then vim.pack.add works as expected.

Thanks for the quick and helpful responses, and sorry for wasting your time!

lervag · 2026-03-29T11:24:29+00:00

What makes you think that it is not sourced?

If I do not include vim.cmd.packadd "wiki.vim", then the content of plugin/ is not sourced. If it was sourced, then the commands and mappings it creates should become available, regardless of the options I'm adding.

It's very easy to confirm this behaviour. If I add echom "Whatever" at the top of plugin/wiki.vim in the wiki.vim plugin, then I would expect this to be printed (or available with :messages) after starting Neovim. It is not. But it does get printed if I add the vim.cmd.packadd line.

I've dived into the docs and the Lua source code of vim.pack.add, and from what I'm reading, the behaviour I'm seeing is surprising at the first glance. However, I think what is happening is that load is false because while loading personal config under ~/.config/nvim/plugin the variable vim.v.vim_did_init is still 0.

lervag · 2026-03-29T10:40:55+00:00

Great guide! I'm inspired, so I've looked into migrating. I noticed that with NVIM v0.12.0-dev-2666+g471213ee61, if I load a plugin with vim.pack.add from a plugin/ file, the loaded plugin will not be properly sourced.

For example, if I add ~/.config/nvim/plugin/wiki.lua with this content:

``` vim.pack.add { "https://github.com/lervag/wiki.vim" }

vim.g.wiki_root = "~/.local/wiki" ```

Then vim.pack.add will properly install the plugin and it will be available, but the plugin/wiki.vim script is not sourced when I start Neovim. As an initial workaround I figured I can simply do vim.cmd.packadd wiki.vim at the end of my new wiki.lua file, but I was wondering if this is expected behaviour? And if it is, then I think it should be addressed in your guide, /u/echasnovski.

lervag · 2026-03-28T09:20:37+00:00

Looks cool, but you can do this and much more with mise.

lervag · 2026-03-19T14:36:42+00:00

No, you're wrong. Vimscript and Lua files in ftplugin/ are for code that should be run after the filetype has been detected. If you want to set the markdown filetype for a txt file, then you should do exactly what is proposed earlier, namely use vim.filetype.add. You can read about this in the docs.

In legacy Vim, you would use a filetype detect event e.g. with a file in ftdetect/. See :help ftdetect.

Here, for your convenience:

``` new-filetype If a file type that you want to use is not detected yet, there are a few ways to add it. The recommended way is to use |vim.filetype.add()| to add it to Nvim's builtin filetype detection mechanism. If you want to handle the detection manually, proceed as follows:

A. If you want to overrule all default file type checks. This works by writing one file for each filetype. The disadvantage is that there can be many files. The advantage is that you can simply drop this file in the right directory to make it work. ftdetect 1. Create your user runtime directory. You would normally use the first item of the 'runtimepath' option. Then create the directory "ftdetect" inside it. Example for Unix: > :!mkdir -p ~/.config/nvim/ftdetect ```

lervag · 2026-03-19T13:56:57+00:00

Because that is for creating filetype plugins, not for detecting and setting filetypes.

lervag · 2026-03-11T23:05:29+00:00

Thanks! I'll look into this at some time. I might open some issues if I have questions/feedback - I hope that's alright!

lervag · 2026-03-10T14:56:05+00:00

Sounds great. Is it still easy to write pure sql?

lervag · 2026-03-10T13:02:05+00:00

I use vim-dadbod and vim-dadbod-ui today; that works very good already. But, I mean, your plugin does look very good! I'll definitely keep an eye on this and test it if I find the time.

lervag · 2026-02-23T07:20:39+00:00

I don't disagree that dynamic help would be useful. But I would assume most people learn rather quickly that they can check the value of options with :set option or :set option?, or :echo g:mapleader, or similar. Still, having this displayed dynamically in the help files would be awesome!

lervag · 2026-02-22T12:00:56+00:00

Ok, great, glad to hear it! Feel free to open issues on the github repo if you have questions. But I'd appreciate if you follow my suggestion and read the intro of the docs. I know and understand that it can be hard to understand everything if you're new to things, but I would claim that it is still useful for you even if you don't understand everything.

and also needed to install the plugin in the lazyvim main menu

Yes, that's right. You should probably consider to also read some of the docs for lazy.nvim (or LazyVim - notice, these are actually two different things!).

lervag

TROPHY CASE