robin

creating a native-feeling neovim picker

robin — Sat, 21 Mar 2026 00:00:00 +0000

</a> preface</h2>
Fuzzy searching in neovim has been a heavily debated topic for years. There were those we fought for telescope being merged into core (which fortunately did not happen), and those who felt that fuzzy picking is not a necessity. I've always felt that a general picker framework is an important core component of neovim - the same could be said for a file tree but that is not what this blogpost will focus on.
Initially file picking came from external software like fzf. The plugin would simply spawn a terminal window running fzf and use the returned value - a simple and clean solution that is still used in popular pickers like fzf-lua</a>. After that, telescope</a> got popular, a picker that used actual windows and UI components within neovim. Unfortunately, its configuration was limited and over time maintenance & development slowed down. Since then a few new ones have popped up, like mini-pick</a> and snacks.picker</a>. Both are widely used and regarded as great solutions. Unfortunately, i don't like either of them. I love mini.nvim</a> and its ecosystem but i don't feel like their vision of a picker fits neovim. As for snacks.picker</a>, ... let me just link this</a> (i should probably write a blogpost about folke).
So i went on to invent my own solution. I wanted something that was easy to configure and extend later, used neovim's base feature set as much as possible, and i was particularly interested in neovim-nightly's ui2 system. The ui2 system is a new feature set for neovim that uses windows for specific components of the UI: the message box and the cmdline. This allows for deeper extension of these features, like syntax highlighting within the cmdline. This also allows custom neovim UI's to draw their own components.
This ui2 framework particularly interested me because it allowed me to draw in the cmdline like it's a normal buffer. This is very similar to emacs' minibuffer feature, which allows plugin authors to use the same UI component (at the bottom of the screen) to show information.

artio.nvim</a> is a lightweight fuzzy picker for neovim built on top of the new ui2 window system. It aims to provide a simple and responsive selection UI without pulling in large dependencies or complex abstractions. It's API is intended to be easily usable and extendable by both users and plugin authors.

The plugin is intentionally small in scope. It focuses on doing one thing well: presenting selectable lists with fuzzy filtering (or custom sorters) in a clean, native-feeling way.

This also means it is compatible with neovim's vim.ui.select</code> api. This allows artio.nvim to act as a drop-in replacement for selection prompts used by other plugins and core features. Since vim.ui.select</code> allows plugin authors to passadditional attributes</a> to its props artio can use these to add additional functionality.

local</span> files</span> =</span> vim</span>.</span>iter</span></span>(</span>vim</span>.</span>fs</span>.</span>dir</span></span>(</span>'</span>.'</span></span>)</span></span></span>)</span></span></span>:</span>map</span></span>(</span>function</span>(</span>node</span>,</span> nodetype</span>)</span></span>
</span></span></span></span></span>    return</span> nodetype</span> ==</span> '</span>file'</span></span> and</span> node</span>
</span></span></span></span></span>  end</span></span></span>)</span></span></span>:</span>totable</span></span>(</span>)</span></span></span>
</span>
</span>vim</span>.</span>ui</span>.</span>select</span></span>(</span>files</span>,</span> {</span>
</span></span></span></span>    </span>prompt</span></span> </span>=</span></span> '</span>select dir'</span></span></span>,</span>
</span></span></span></span>    </span>format_item</span></span> </span>=</span></span> function</span>(</span>item</span>)</span></span> return</span> vim</span>.</span>fn</span>.</span>fnamemodify</span></span>(</span>item</span>,</span> '</span>:.'</span></span>)</span></span></span> end</span></span></span></span>,</span>
</span></span></span></span>
</span></span></span></span>    --</span> artio & mini.nvim exclusive:
</span></span></span></span></span>    </span>preview_item</span></span> </span>=</span></span> function</span>(</span>item</span>)</span></span>
</span></span></span></span></span></span>        return</span> vim</span>.</span>fn</span>.</span>bufadd</span></span>(</span>item</span>)</span></span></span>
</span></span></span></span></span></span>    end</span></span></span></span>,</span>
</span></span></span></span>    --</span> artio exclusive:
</span></span></span></span></span>    </span>get_icon</span></span> </span>=</span></span> function</span>(</span>item</span>)</span></span> return</span> require</span>(</span>'</span>mini.icons'</span></span>)</span></span></span>.</span>get</span></span>(</span>"</span>file"</span></span>,</span> item</span>.</span>v</span>)</span></span></span> end</span></span></span></span>,</span>
</span></span></span></span>  }</span></span>,</span> function</span>(</span>item</span>,</span> _</span>)</span></span> vim</span>.</span>cmd</span>.</span>cd</span></span>(</span>item</span>)</span></span></span> end</span></span></span>)</span></span></span>
</span></code></pre>
</a>
features</h2>
Artio provides a fuzzy-filtered selection window implemented entirely in lua.
it uses ui2 for layout and rendering, which keeps the interface consistent
with neovim-nightly's new ui implementation.</p>
Key features include:</p>

fuzzy & pattern matching (through the default sorter)</li>
vim.ui.select</code> replacement</li>
configurable preview window</li>
basic builtins: files, buffers, colorschemes, helptags, etc</li>
optional icon support for builtins (through mini-icons</a>)</li>
</ul>
Artio works well if you want a minimal picker for everyday navigation tasks.
Artio is not meant to be an extremely innovative fuzzy finder, nor is it meant
to be a plugin focused on performance. If you want these features, you can implement them yourself.</p>
For example, if you want to process fuzzy sorting through and external dependency you can do so by overwriting the default sorter:</p>
package</span>.</span>loaded</span></span>[</span>'</span>artio'</span></span>]</span></span>.</span>sorter</span></span> =</span> function</span>(</span>lst</span>,</span> input</span>)</span></span>
</span></span></span>    local</span> output</span> =</span> ...</span> --</span> run your external cmd through `vim.system`
</span></span></span></span>
</span></span></span>    --</span> process output and return matches
</span></span></span></span>    return</span> vim</span>.</span>iter</span></span>(</span>output</span>)</span></span></span>:</span>fold</span></span>(</span>{</span>}</span></span>,</span> ...</span>)</span></span></span>
</span></span></span>end</span></span></span>
</span></code></pre>
</a>
configuration</h2>
The configuration of artio is similarly designed like most neovim components:
to be extensible and flexible. E.g., you can simply change some resizing behavior
with config.shrink</code> or change the way the preview is drawn with
config.win.preview_opts</code>.</p>
an example setup could look something like this:</p>
vim</span>.</span>pack</span>.</span>add</span></span>(</span>{</span> "</span>https://codeberg.org/comfysage/artio.nvim"</span></span> }</span></span>)</span></span></span>
</span>
</span>--</span> after installation, calling its setup function allows you to adjust behavior
</span></span>--</span> such as window size, prompt placement, and characters for the ui.
</span></span>--</span> calling setup is entirely optional if you like the defaults.
</span></span>require</span>(</span>'</span>artio'</span></span>)</span></span></span>.</span>setup</span></span>(</span>{</span>
</span></span></span></span>  </span>opts</span></span> </span>=</span></span> {</span>
</span></span></span></span></span>    --</span> whether to draw the prompt at the bottom
</span></span></span></span></span></span>    </span>bottom</span></span> </span>=</span></span> false</span></span>,</span>
</span></span></span></span></span>    --</span> whether the window should shrink to fit the matches
</span></span></span></span></span></span>    </span>shrink</span></span> </span>=</span></span> false</span></span>,</span>
</span></span></span></span></span>    --</span> prefix for the prompt
</span></span></span></span></span></span>    </span>promptprefix</span></span> </span>=</span></span> "</span>"</span></span></span>,</span>
</span></span></span></span></span>    --</span> whether to draw the prompt title
</span></span></span></span></span></span>    </span>prompt_title</span></span> </span>=</span></span> false</span></span>,</span>
</span></span></span></span></span>    --</span> pointer for the selected match
</span></span></span></span></span></span>    </span>pointer</span></span> </span>=</span></span> "</span>"</span></span></span>,</span>
</span></span></span></span></span>  }</span></span></span>,</span>
</span></span></span></span>  </span>win</span></span> </span>=</span></span> {</span>
</span></span></span></span></span>    --</span> this can also be a fractal to indicate a percentage of the screen
</span></span></span></span></span></span>    </span>height</span></span> </span>=</span></span> 16</span></span>,</span>
</span></span></span></span></span>    --</span> works best with laststatus=3
</span></span></span></span></span></span>    </span>hidestatusline</span></span> </span>=</span></span> true</span></span>,</span>
</span></span></span></span></span>  }</span></span></span>,</span>
</span></span></span></span>}</span></span>)</span></span></span>
</span></code></pre>
Keymappings are left to the user. You can find some examples in the README</a>:</p>
vim</span>.</span>keymap</span>.</span>set</span></span>(</span>"</span>n"</span></span>,</span> "</span><leader><leader>"</span></span>,</span> "</span><Plug>(artio-files)"</span></span>)</span></span></span>
</span>vim</span>.</span>keymap</span>.</span>set</span></span>(</span>"</span>n"</span></span>,</span> "</span><leader>fg"</span></span>,</span> "</span><Plug>(artio-grep)"</span></span>)</span></span></span>
</span>
</span>--</span> smart file picker
</span></span>vim</span>.</span>keymap</span>.</span>set</span></span>(</span>"</span>n"</span></span>,</span> "</span><leader>ff"</span></span>,</span> "</span><Plug>(artio-smart)"</span></span>)</span></span></span>
</span>
</span>--</span> general built-in pickers
</span></span>vim</span>.</span>keymap</span>.</span>set</span></span>(</span>"</span>n"</span></span>,</span> "</span><leader>fh"</span></span>,</span> "</span><Plug>(artio-helptags)"</span></span>)</span></span></span>
</span>vim</span>.</span>keymap</span>.</span>set</span></span>(</span>"</span>n"</span></span>,</span> "</span><leader>fb"</span></span>,</span> "</span><Plug>(artio-buffers)"</span></span>)</span></span></span>
</span>vim</span>.</span>keymap</span>.</span>set</span></span>(</span>"</span>n"</span></span>,</span> "</span><leader>f/"</span></span>,</span> "</span><Plug>(artio-buffergrep)"</span></span>)</span></span></span>
</span>vim</span>.</span>keymap</span>.</span>set</span></span>(</span>"</span>n"</span></span>,</span> "</span><leader>fo"</span></span>,</span> "</span><Plug>(artio-oldfiles)"</span></span>)</span></span></span>
</span></code></pre>
These mappings are available through the <Plug></code></a> interface. These
are abstract 'keys' that have been mapped by plugin authors (like me) to certain action
and can be mapped to by users with their custom keybinds.</p>

</a>
future</h2>
Currently artio is in a relatively stable state. Improvements or changes might
be made to solve issues or improve performance but there (probably) won't be
any major api changes.</p>
As for possible future features, im mostly looking into leveraging async
handling of sorters but i'm open to further suggestions.</p>

</a>
closing</h2>

I discovered a lot of cool features and weird neovim quirks while designing
this plugin. Neovim's ui2 definitely is not finished yet and a minibuffer
feature (as the neovim core members have suggested</a>) is
still pretty far away. As i've stated on the neovim
repo</a>, the current ui2 implementation is really cool but
also kind of a footgun at times.</p>
In the end, im quite happy with what ive build ~it wont be the ultimate
solution for most people but it will be a solid solution for most people.</p>
If you're looking for the most performant and feature-rich picker artio
probably won't be for you - and thats fine!</p>
If you want a picker that feels simple, extensible, and closely aligned with
Neovim's prior design, artio is worth a look.</p>



site on a zig server
robin — Mon, 09 Mar 2026 00:00:00 +0000
ive been working on a minimal http server to host the static site contents on.
this is mostly because i want to get better at zig and thought itd be a fun
challenge :)</p>
it currently supports embedding the static files and a tiny virtual filesystem.</p>
i might expand it to support templates & generation and take more work off zola.</p>


evergarden userstyles
robin — Mon, 02 Mar 2026 00:00:00 +0000
evergarden is now available as a userstyle!!</p>
i created a small patcher for the catppuccin userstyles
repo</a> with the help of their lead
maintainer, @uncenter</a>. this allows us to use their amazing userstyles with evergarden
colors!</p>
the userstyles are available on github</a> and codeberg</a>.</p>
</p>


ebil tool
robin — Thu, 19 Feb 2026 00:00:00 +0000
i created a really cool and awesome tool for publishing your ebil.club</a> site.</p>
you can get the ebil tool from codeberg</a>.</p>
</p>


lylla now supports sections
robin — Sun, 15 Feb 2026 00:00:00 +0000
lylla now supports sections for statusline components. 3bf7259</code></a></p>
this uses a pr that has just been merged to nightly. #37153</code></a></p>
this feature was initially requested by me</em> :) #35806</code></a></p>
lylla is available on github</a> and codeberg</a>.</p>
</p>


mimi colorscheme
robin — Sat, 07 Feb 2026 00:00:00 +0000
mimi is a fuzzy & warm colorscheme inspired by june</a>'s cat.</p>
mimi is available on codeberg</a>.</p>
</p>


aspen plugin
robin — Tue, 03 Feb 2026 00:00:00 +0000
i created a plugin for neovim that simplifies some of the hassles of setting up
neovim's builtin completion.</p>
github</a> codeberg</a></p>


artio live mode toggle
robin — Sat, 24 Jan 2026 00:00:00 +0000
you can now toggle between live mode and fuzzy mode in artio! 82db9ac</code></a></p>
you can get artio from github</a> and codeberg</a>.</p>


artio released!
robin — Sun, 16 Nov 2025 00:00:00 +0000
ive been working on a extui fuzzy finder for neovim that uses nightly's new ui components.</p>
its available on github</a> and codeberg</a>.</p>
</p>


tending your editor config: building sylvee & lynn
robin — Wed, 13 Aug 2025 00:00:00 +0000

if you're like me and love configuring your neovim setup, you might reach a
point of customization where the different plugins you're using start holding
you back: different ui or keybinds start fighting eachother and keeping track of
lazy-loading for every plugin becomes unmanageable.</p>
most of the time you'll think to yourself that your setup has become too big and
surely if you just restart from scratch you'll avoid this next time ... but you
never do.</p>
thats why i decided to create a native-first neovim experience. i tried to
focus on bringing features to my editor using built-in building blocks and
components. this meant no nvim-cmp</a> or blink-cmp</a> and, most importantly, no
lazy.nvim</a>.</p>
</a>
philosophy and foundation</h3>

neovim has become incredibly powerful out-of-the-box and i want to take advantage of that.
so i created sylvee</a>, a native-first neovim configuration that builds on the amazing
features that have been added to neovim recently.</p>
to power plugin management i created a wrapper around vim.pack</code></a>, neovim
nightly's native plugin manager. this wrapper is called lynn.nvim</a>, and it
powers the configuration that i made.</p>
</a>
neovim's built-in features</h2>
sylvee was built to extend neovim's built-in features. i didn't want to wrap my
clean and powerful editor in a layer of bloated plugins. using neovim's
defaults has become incredibly user-friendly recently and i noticed that i
started deleting custom keymaps i added to my config; neovim's default binds
made more sense than my own.</p>
a perfect example of this is neovim's recent addition of built-in lsp keymaps:
from neovim 0.11 onwards, you'll able to use a bunch of gr</code>-prefixed keymaps to access
different lsp-related editor features. these include grn</code> to rename a symbol,
gra</code> to access code actions and grr</code> to get a list of references. similarly,
tpope's vim-unimpaired</a> has been
integrated into neovim: you can now use bracket + q</code> to switch items in the
quickfix list and bracket + b</code> to navigate the buffer list.</p>
apart from keymaps, a bunch of settings and autocmds are no longer
needed: setting the 'omnifunc'</a> to lsp completion is done
automatically when an lsp attaches and your folds will use treesitter
when available.</p>
neovim's builtin completion has also been greatly improved: since
version 0.11</code> you can already enjoy added highlights for matching
results and pre-inserted 'ghost-text', and in neovim nightly there is
now also support for 'autocomplete'</a> - enabling this option will make the completion popup
automatically appear while typing.</p>
lsp configuration has been a treat since vim.lsp.config</code></a> got added.
gone are the days of giant table's with configurations for all your
different lsp's. you can now split all your custom configs up into
files in the lsp/</code> directory of your config. these will automatically
get sourced. all you need to do is enable the lsp's you use using
vim.lsp.enable</code></a> and thats that. similarly, nvim-lspconfig</a> has been
simplified: you no longer have to even require</code> this plugin - just
throw it in your plugin list and it works.</p>

</a>
sylvee: keeping configuration gentle</h3>

a core part of sylvee is the idea that configuration should be simple and
minimal. this meant using the plugin/</code> to load custom scripts instead of death
by a thousand require</code> statements in your init.lua</code>.</p>
i didn't add custom keymaps unless a feature did not have a keymap builtin,
like :tabnew</code></a> which i bound to <C-w><tab></code>, or when the defaults required
ergonomics that would simply break my hand, like <C-^></code></a> to open the alternate
file which i bound to <C-j></code> (a keymap that surpringly wasn't used yet by neovim).</p>
additionally, i made exceptions for keymaps which i found to better fit neovim's
keymap model: switching tabs made more sense with bracket + <tab></code> than
gt/gT</code></a>. although the goal is minimalism, i didn't want to compromise on my
preferences - sylvee can be a little opinionated sometimes.</p>
</a>
lynn - a plugin manager with charm</h2>

</a>
why i don't like lazy.nvim or packer</h3>
over time the neovim community has reinvented plugin management time and time
again - to me the days of vim-plug</code> dont feel that far away and we've come a
long way since then. the plugin spec has changed massively: we started out with
simple url strings, expanded with some small options like renaming the plugin
dir or pinning to a version, and ended up with convoluted specs that integrate
both the plugin and your own configuration - thus becoming dependent on the
context of your specific neovim setup.</p>
this evolution was partly caused by the introduction of the
require('plugin').setup()</code> convention. whereas plugin used to set
configuration options using global vim.g</code></a> variables, they were now set with a
single line of imperative lua code. i find this change way better for clarity
but it didnt come without consequences. since configuration was now set with a
function plugin authors started using this function as the entry point of the
plugin - meaning whether your plugin was lazy-loaded or not became dependent on
when the user runs setup</code>. if you're wondering how this is different from how
lazy-loading done previously: neovim has a set of specific
directory names that, if in the runtimepath, will automatically get run or
added to the environment. this includes the plugin/</code> dir: authors would put
autocommands in their plugin/plugin-name.vim</code> to automatically initialize the
plugin whenever appropiate events happened in the editor.</p>
since the introduction of packer.nvim</a> and lazy.nvim</a> the plugin spec received a
new config</code> function (and with lazy.nvim</a> an even simpler opts</code> table). now
your configuration for a plugin, which in most cases was just calling setup</code>,
could now be done within the plugin spec. ... and now your plugins file is
filled with unrelated configs, differently indented functions, and opts</code> tables.</p>
finally, as mentioned earlier, vim.pack</code></a> got added in neovim-nightly. this powerful built-in plugin
manager allows you to finally load plugins without the need for a bootstrapped
package manager like lazy.nvim</a>. ... except there are some caveats. currently
vim.pack</code></a> only has support for the management</em> and installation</em> of plugins,
configuration is entirely up to the user. similarly, lazy-loading is assumed to
be done by plugins themselves (a sentiment that i entirely support). this means
that there are still definitely some limitations to using vim.pack</code></a> - which
led me to create lynn.nvim</a>, a plugin manager that leverages neovim's builtin
features which are responsible for all the heavy lifting and creates a configuration interface that fits
neovim's file based model.</p>
</a>
lynn as a lightweight wrapper: no magic, just convenience</h3>
lynn didnt need to do a lot: git cloning, installing, and setting up the plugin
path was already handled by vim.pack</code></a>. lynn simply needed to help with urls
(allowing you to use owner/repo</code> instead of https://github.com/owner/repo</code>),
allow lazy-loading if the plugin doesn't handle it by it self, and
automatically source your config.</p>
the url wrapping simply means that lynn will assume a owner/repo</code> format
refers to a github repo. additionally, lynn supports url aliases: you can use
server:owner/repo</code> to use a custom git server instead of github.</p>
lazy-loading is kept pretty simple. there's no usercommand wrapping or keymaps
that automatically source the plugin. instead, you can use the event</code> field to
create an autocommand for the plugin.</p>
configuration is where most of the magic lies, and funnily enough it's also the
simplest (just a few lines of lua code). lynn will automatically source any lua
file in the config/</code> directory of your config that matches the name of the
plugin. for mini.nvim</a> this means lynn will load config/mini.lua</code> and for
fzf-lua</a> this means lynn will load config/fzf.lua</code>. finding these files is
done by the :runtime</code> command - neovim already has a builtin mechanism for
finding files in your setup and there is no need for lua code going over your
filesystem.</p>
</a>
using lynn and sylvee</h2>

</a>
adding plugins to lynn</h3>
plugin specs are quite simple. you're probably already familiar with most of the fields it supports.</p>
a simple example would look like this:</p>
{</span>
</span></span>  '</span>owner/repo'</span></span>,</span>
</span></span>  </span>url</span></span> </span>=</span></span> '</span>https://github.com/owner/repo'</span></span></span>,</span> --</span> optionally specify a custom url
</span></span></span>  </span>name</span></span> </span>=</span></span> "</span>cool-repo"</span></span></span>,</span> --</span> optionally rename the plugin
</span></span></span>  </span>version</span></span> </span>=</span></span> "</span>main"</span></span></span>,</span> --</span> pin the plugin to a specific version, allows for the use of `vim.version`
</span></span></span>  </span>path</span></span> </span>=</span></span> "</span>path/to/plugin"</span></span></span>,</span> --</span> optionally specify a custom path
</span></span></span>  </span>deps</span></span> </span>=</span></span> {</span> "</span>dep1"</span></span>,</span> "</span>dep2"</span></span> }</span></span></span>,</span> --</span> specify dependencies
</span></span></span>  </span>event</span></span> </span>=</span></span> "</span>VimEnter"</span></span></span>,</span> --</span> specify an autocommand event
</span></span></span>  </span>lazy</span></span> </span>=</span></span> true</span></span>,</span> --</span> lazy-load the plugin
</span></span></span>  </span>after</span></span> </span>=</span></span> function</span>(</span>)</span></span> end</span></span></span></span>,</span> --</span> pass a function to run after the plugin is loaded, by default sources the `config/plugin-name.lua` file
</span></span></span>  </span>before</span></span> </span>=</span></span> function</span>(</span>)</span></span> end</span></span></span></span>,</span> --</span> pass a function to run before the plugin is loaded
</span></span></span>}</span></span>
</span></code></pre>
lazy loading is only done if lazy</code> is set to true</code> or an autocmd event is
specified. this means that normally lynn will load the plugin after neovim's
configuration stage is done.</p>
there are after</code> and before</code> fields but in most cases these should not have
to be used. after</code> will default to loading your config file so any important
code should go there. before</code> is only useful if you want to run code before
the plugin is loaded.</p>
</a>
using sylvee</h3>
using sylvee is as simple as cloning the repo and running neovim with NVIM_APPNAME</code></a> set to "sylvee"</code>.</p>
git</span></span> clone https://github.com/comfysage/sylvee.git ~</span></span>/.config/sylvee</span>
</span>NVIM_APPNAME</span>=</span>sylvee</span> nvim</span></span>
</span></code></pre>
this can be simplified even more by creating a quick wrapper script for sylvee:</p>
#</span></span>!/usr/bin/env sh</span>
</span></span>#</span></span> ~/.local/bin/sylvee</span>
</span></span>NVIM_APPNAME</span>=</span>sylvee</span> nvim</span></span> "</span>$</span>@</span></span>"</span></span></span>
</span></code></pre>
</a>
what sylvee and lynn don’t do</h2>

sylvee and lynn don't aim to solve every problem. they just try to stay out of
your way sylvee is a minimalistic approach that tries to remove the friction of
configuring neovim, and lynn is a small plugin manager that tries to remove
some annoyance with managing plugins. they won't solve all the problems in the
neovim space and they won't fit every use case.</p>
currently lynn does not go well with a nix-wrapped neovim setup. im working on
adding this by allowing you to disable vim.pack</code></a> within lynn - effectively
making lynn a lazy-loader for local plugins.</p>
lynn also does not support plugin lock files or snapshots since these features
are entirely dependent on neovim-core's implementation of vim.pack</code></a>. as soon
as this is added</a> i will make sure lynn doesn't get in its way.</p>
lynn currently does not support complex lazy-loading rules like mappings</code> or
cmd</code> fields to load on keymaps and commands since i think these hurt
performance in most situations and are simply not worth the trouble.
additionally, most of these can be implemented manually for specific
edge-cases.</p>
</a>
growing your own garden</h2>

i would also like to note that the philosophy of sylvee and lynn is not to be a
complete solution, but rather a starting point for those that want to build
their own customized configuration.</p>
sylvee is a starting point for your own garden. you can use it as a base, or
pick specific parts that you'd like to use. it can be a really strong base to
build off of, especially for those that prefer a more minimal setup. finding
features within your editor and knowing some of the basics, like the quickfix
list</a>, grep</a> and
marks</a>, will help you build your own garden.</p>
you can also use lynn as a standalone plugin manager for your neovim setup.
this might be useful if you want to keep your neovim setup simple and prefer to
use neovim's builtin plugin manager without having to deal with creating your
own lazy-loading solution (ofcourse thats always a viable and fun option).</p>

i hope that this setup works for you. i personally loved working on it and
learned a lot about how powerful of an editor neovim can be if you try to look
into some of its more complex aspects. the neovim core team has worked really
hard on creating an impressive and customizable out-of-the-box experience. i
admire them for all the work they've done and am looking forward to where we'll
go next.</p>
i've tried my best to work with</em> what neovim provides and against</em> what most
neovim distros are reaching for. i tried to balance neovim's defaults with some
additions that i would love to see in neovim in the future.</p>
if that sounds like your kind of garden, give sylvee and lynn a try. i think
they're something interesting to try out. if you have any questions or feedback
please let me know</a>!</p>
</a>
references</h1>
here are some references that add more context to this blogpost:</p>

a section</a> of the neovim docs explaining how to add lazy-loading to your plugin.</li>
a comment</a> by justinmk</a> explaining how lazy-loading should</em> be done in neovim.</li>
</ul>


evergarden for sublime
robin — Sun, 22 Jun 2025 00:00:00 +0000
evergarden is now available for sublime text. simply install it using package
control.</p>
</p>


evergarden palette now on npm
robin — Sun, 25 May 2025 00:00:00 +0000
you can install the evergarden palette as an npm package: @everviolet/palette</code></p>
here’s how to bring the garden into your stylesheets:</p>
/*</span> if you have it installed with a package manager & a css loader configured */</span></span>
</span>@</span>import</span> "</span>@everviolet/palette/css/fall.css"</span></span>;</span></span>
</span>
</span>/*</span> alternatively via unpkg */</span></span>
</span>@</span>import</span> url</span>(</span>"</span>https://unpkg.com/@everviolet/palette/css/fall.css"</span></span></span>)</span></span></span>;</span></span>
</span>
</span>.</span>button</span> </span>{</span>
</span></span>  background-color</span></span>:</span> </span>var</span>(</span>--</span>ev-winter-green</span></span></span>)</span></span></span></span>;</span>
</span></span>  color</span></span>:</span> </span>var</span>(</span>--</span>ev-winter-crust</span></span></span>)</span></span></span></span>;</span>
</span></span></span>}</span>
</span></code></pre>
@</span>use</span> "</span>@everviolet/palette/scss/evergarden"</span></span> as</span> *</span></span>;</span></span>
</span>
</span>.</span></span>button</span> </span>{</span>
</span>  background-color</span></span>:</span> $</span>green</span></span>;</span>
</span>  color</span></span>:</span> $</span>crust</span></span>;</span>
</span>}</span>
</span></code></pre>


evergarden site is live
robin — Sun, 06 Apr 2025 00:00:00 +0000
the little garden's grown a bit! the official evergarden theme site is now
available - you can now browse the palette, read about the project, and find
ports for your applications all in one comfy place.</p>
take a peek here: evergarden.moe</a></p>
(more updates, ease of use for developers, and mossy surprises coming soon)</p>


creating a colorscheme
robin — Wed, 12 Mar 2025 00:00:00 +0000
ever since I started using open source applications and code editors I got
sucked into the magic of syncing the themes of my different applications.
there's just something amazing about having all your applications using the
same styles and colors.</p>
naturally I got inspired by the thousands of colorschemes out there and created
my own, and then my next one, and then my next one. I have to admit that my
first few attempts lacked… a certain touch. while it was really fun to change
my applications to use a palette that I</em> created, the end result was pretty
bad. apparently, selecting random colors without thinking about their
relationship to eachother isnt the best recipe for creating a coherent color
scheme.</p>
in this small guide I will attempt to lay out some of tips I can give you in your
own colorscheme journey. these tips are based on my extensive time researching
color theory, both in creating colorschemes and art in
general.</p>
</a>
where to start</h3>
the best thing is to start with a concept. use a scene, videogame or movie you
like as inspiration. next, collect some images relating to your concept. by
creating a moodboard, you quickly have access to reference material for your
colorscheme.</p>
</a>
finding your neutral colors</h3>
every colorscheme starts with a background color. it is quite difficult to
select foreground colors until you know which color they will contrast with;
think of black on white for most websites. select a color in your reference
material that has a soft hue to it. try not to use a color that pops. instead
look for the color that is used as a backdrop. this color will often be either
blue, red-ish or purple. this is because most scenery in your daily
life is made of these colors; think of shadowy areas, surfaces lit up by the
sun and night scenery respectively.</p>
after you've selected your background color, we need a foreground color. theres
two ways to go about this. method one is shifting the lightness of your
background color up and shifting the saturation all the way down. using this
method, you get a quite analogous neutral palette. these palettes are perfect
for when you want to add other colors that pop. the second
method is the same as the first one but follows up by shifting the hue of your
foreground color by 180 degrees. this method will result in a complementary
neutral palette, which makes your final colorscheme look quite vibrant.</p>
next up is creating your neutral shades. this can simply be done by
incrementally changing the components of your background color until they reach
the value of your foreground color.</p>
</a>
how to select colors</h3>
look in your reference material for a single</em> color that you find
representative of your concept. next, crank up the lightness and
saturation until you're content with your color. this color will be the main
color used for syntax.</p>
for the rest of your palette, use the same saturation and lightness but move
the hue over about 60 to 90 degrees each time. by selecting colors that
differ only in one</em> component, either hue or lightness or saturation, you
create a palette that looks quite harmonious.</p>
</a>
adjusting your colors</h3>
you might notice that some of your colors look a little off. this is because
saturation and lightness in the hsl (or hsv) color space is not perceptually
uniform. this means that, to the human eye, colors with the same saturation and
lightness don't look</em> like they have the same saturation and lightness. to the
human eye, a blue or purple will look darker than a green or yellow. you
have to take this into account while creating your colorscheme.</p>
if you have a palette that is generally pretty vibrant but some colors look
washed out, try decreasing their brightness and increasing their saturation.
the inverse can be said for a pastel palette: do some colors look darker or
dirtier? try increasing their lightness and decreasing their saturation.</p>
in general, there are a few rules for a coherent palette: your reds and oranges
will have a higher saturation than your other colors, whereas your blues and
greens will have a lower saturation.</p>
</a>
look at community resources</h3>
to further help you on your journey I have selected a collection of resources I
discovered while researching colorschemes. the end result of these resources
might not look like something you</em> would want to create. nevertheless, it's
important to look at the choices these developers made and think about how you
could apply their ideas to your own work.</p>
an important resource that got me started on my colorscheme journey was
cocopon</a>'s vimconf 2017 presentation</a> on creating a
colorscheme.</p>
next, look at documentation for well-known palettes. many popular themes have
in-depth documentation on their palettes. they may even share some of the
knowledge theyve gained on the journey they took to create the colorscheme.
here's a selection of resources to start:</p>

the nord theme documentation</a></li>
the rose-pine documentation</a></li>
the catppuccin style guide</a></li>
the solarized documentation</a></li>
</ul>


building this site
robin — Wed, 22 Jan 2025 00:00:00 +0000
</a>
static site generation</h2>
while looking for a static site generator for my site i tried a few interesting
tools, like hugo and astro. i even tried building my own ssg (which failed
miserably). in the end i discovered zola, simple static site generator
written in rust. zola uses tera templates to build sites with minimal effort.</p>
zola separates content from templates. where markdown files can specify which
templates to use.</p>
</a>
templates</h3>
here is my blog page. it specifies a template to use for the section. in this
template i can use zola's section variables to create a dynamic posts page
(which i'll get into in a bit).</p>
+++
</span></span>title = "blog"
</span></span>description = "questionable ideas put to paper"
</span></span>sort_by = "date"
</span></span>template = "pages/blog.html"
</span></span>page_template = "pages/post.html"
</span></span>+++
</span></span></code></pre>
the blog page also specifies a page_template</code>. this is the template that will
be used for all child pages (my blogposts).</p>
in my pages/blog.html</code> template i can use zola's section variables to iterate
over all my blogposts and generate a list at build time.</p>
{% block content %}
</span>  {{ section.content | safe }}
</span>  <ul class="blog-previews">
</span>    {% for page in section.pages %}
</span>      {% include "partials/blogpreview.html" %}
</span>    {% endfor %}
</span>  </ul>
</span>{% endblock content %}
</span></code></pre>
</a>
build and deploy</h2>
to ease building and deploying the site i use nix to setup my tools and build.
because the site is static i simply can use github pages to deploy.</p>
the nix builder simply takes zola as a buildinput and runs the build. i then
copy the static content to the $out</code> directory.</p>
stdenvNoCC</span>.</span>mkDerivation</span> {</span>
</span>  src</span> =</span> ./.</span>;</span>
</span>
</span>  nativeBuildInputs</span> =</span> [</span>
</span>    zola</span>
</span>  ]</span>;</span>
</span>
</span>  buildPhase</span> =</span> ''</span>
</span></span>    runHook preBuild
</span></span>    zola build
</span></span>    runHook postBuild
</span></span>  ''</span></span>;</span>
</span>
</span>  installPhase</span> =</span> ''</span>
</span></span>    runHook preInstall
</span></span>
</span></span>    mkdir -p $out
</span></span>    cp -r public/* $out
</span></span>
</span></span>    runHook postInstall
</span></span>  ''</span></span>;</span>
</span>}</span>
</span></code></pre>
deployment is done using a single github
action you can find
here</a>.</p>



  
  update: codeberg ci</h6>
  
  
    deployment is now done with codeberg ci
using woodpecker using the config you can
find
here</a>
  </p>
</aside>
</a>
resources</h2>

    zola</a></li>
    
ebil.club</a></li>
    
evergarden</a></li>
    
nix</a></li>