diff --git a/.gitignore b/.gitignore
index 6c06062..0d3112b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,4 +7,3 @@ zig-pkg
# dev
.direnv/
-*.tar
diff --git a/.nvim.lua b/.nvim.lua
deleted file mode 100644
index b8cd975..0000000
--- a/.nvim.lua
+++ /dev/null
@@ -1,2 +0,0 @@
-vim.lsp.enable("lua_ls", false)
-vim.lsp.enable("emmylua_ls")
diff --git a/build.zig b/build.zig
index 55c3062..d91a28d 100644
--- a/build.zig
+++ b/build.zig
@@ -13,30 +13,6 @@ pub fn build(b: *std.Build) !void {
.optimize = optimize,
});
- const exe_options = b.addOptions();
- mod.addOptions("opts", exe_options);
-
- const opt_version_string = b.option([]const u8, "version-string", "Override version string. Default is to find out with git.");
- const version_slice = if (opt_version_string) |version| version else v: {
- if (!std.process.can_spawn) {
- std.debug.print("error: version info cannot be retrieved from git. version must be provided using -Dversion-string\n", .{});
- std.process.exit(1);
- }
-
- var code: u8 = undefined;
- const git_rev_untrimmed = try b.runAllowFail(&[_][]const u8{
- "git",
- "-C", b.build_root.path orelse ".", // affects the --git-dir argument
- "--git-dir", ".git", // affected by the -C argument
- "rev-parse", "HEAD",
- }, &code, .ignore);
- const git_rev = std.mem.trim(u8, git_rev_untrimmed, " \n\r");
-
- break :v git_rev;
- };
- const version = try b.allocator.dupeZ(u8, version_slice);
- exe_options.addOption([:0]const u8, "version", version);
-
const exe = b.addExecutable(.{
.name = "maivi",
.root_module = b.createModule(.{
diff --git a/data/about.tkt b/data/about.tkt
deleted file mode 100644
index 6524af5..0000000
--- a/data/about.tkt
+++ /dev/null
@@ -1,35 +0,0 @@
-+++
-title = "about me :)"
-+++
-
-~ ✨ i'm passionate about:
-
-
-
software (neovim, nix, rust, and more)
-
aesthetics (colorschemes, ui design, minimalism)
-
nature & mythology (gardens, forests, folklore)
-
-
-~ 🌱 in my projects, i blend these passions together:
-
-
-
evergarden (a soft, nature-inspired colorscheme)
-
lynn (a lightweight neovim plugin manager)
-
ivy (a nix-based neovim setup)
-
... and more.
-
-
-
- "Among the roses, beneath the twilight." 🌙🌿
-
-
-== how this site was build
-
-this site is build using the following tools:
-
-- [maivi], for html templating in lua
-- nix, for reproducible builds everywhere
-
-you can read more about it [here](/blog/building-this-site).
-
-[maivi]: https://codeberg.org/comfysage/site
diff --git a/data/blog/building-this-site.tkt b/data/blog/building-this-site.tkt
deleted file mode 100644
index 58b26f7..0000000
--- a/data/blog/building-this-site.tkt
+++ /dev/null
@@ -1,102 +0,0 @@
-+++
-title = "[outdated] building this site"
-date = 2025-01-22
-modified = 2026-01-07
-desc = "my tiny adventure in static site generation"
-tags = site,
-+++
-
-= static site generation
-
-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.
-
-zola separates content from templates. where markdown files can specify which
-templates to use.
-
-== templates
-
-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).
-
-~~~ markdown
-+++
-title = "blog"
-description = "questionable ideas put to paper"
-sort_by = "date"
-template = "pages/blog.html"
-page_template = "pages/post.html"
-+++
-~~~
-
-the blog page also specifies a `page_template`. this is the template that will
-be used for all child pages (my blogposts).
-
-in my `pages/blog.html` template i can use zola's section variables to iterate
-over all my blogposts and generate a list at build time.
-
-~~~ tera
-{% block content %}
- {{ section.content | safe }}
-
- {% for page in section.pages %}
- {% include "partials/blogpreview.html" %}
- {% endfor %}
-
-{% endblock content %}
-~~~
-
-= build and deploy
-
-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.
-
-the nix builder simply takes zola as a buildinput and runs the build. i then
-copy the static content to the `$out` directory.
-
-~~~ nix
-stdenvNoCC.mkDerivation {
- src = ./.;
-
- nativeBuildInputs = [
- zola
- ];
-
- buildPhase = ''
- runHook preBuild
- zola build
- runHook postBuild
- '';
-
- installPhase = ''
- runHook preInstall
-
- mkdir -p $out
- cp -r public/* $out
-
- runHook postInstall
- '';
-}
-~~~
-
-deployment is done using a single github
-action you can find
-[here](https://codeberg.org/comfysage/site/src/commit/0b94d7338c1d7c50c09635b4d20fbeab552d58fd/.github/workflows/deploy.yml).
-
-< (note) ~ update: codeberg ci
-< deployment is now done with codeberg ci using woodpecker using the config
-< you can find [here][codeberg ci]
-
-[codeberg ci]: https://codeberg.org/comfysage/site/src/commit/0b94d7338c1d7c50c09635b4d20fbeab552d58fd/.woodpecker/deploy.yaml
-
-= resources
-
-
diff --git a/data/blog/creating-a-colorscheme.tkt b/data/blog/creating-a-colorscheme.tkt
deleted file mode 100644
index f96e7b0..0000000
--- a/data/blog/creating-a-colorscheme.tkt
+++ /dev/null
@@ -1,107 +0,0 @@
-+++
-title = "creating a colorscheme"
-date = 2025-03-12
-desc = "a small guide based on my own experiences"
-tags = colorscheme,
-+++
-
-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.
-
-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_ 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.
-
-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.
-
-== where to start
-
-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.
-
-== finding your neutral colors
-
-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.
-
-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.
-
-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.
-
-== how to select colors
-
-look in your reference material for a _single_ 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.
-
-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_ component, either hue or lightness or saturation, you
-create a palette that looks quite harmonious.
-
-== adjusting your colors
-
-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_ 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.
-
-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.
-
-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.
-
-== look at community resources
-
-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_ 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.
-
-an important resource that got me started on my colorscheme journey was
-[cocopon](https://github.com/cocopon)'s vimconf 2017 [presentation](https://speakerdeck.com/cocopon/creating-your-lovely-color-scheme) on creating a
-colorscheme.
-
-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:
-
-- [the nord theme documentation](https://www.nordtheme.com/docs/colors-and-palettes)
-- [the rose-pine documentation](https://rosepinetheme.com/palette/)
-- [the catppuccin style guide](https://github.com/catppuccin/catppuccin/blob/main/docs/style-guide.md)
-- [the solarized documentation](https://ethanschoonover.com/solarized/)
diff --git a/data/blog/neovim-artio-picker.tkt b/data/blog/neovim-artio-picker.tkt
deleted file mode 100644
index 950188a..0000000
--- a/data/blog/neovim-artio-picker.tkt
+++ /dev/null
@@ -1,219 +0,0 @@
-+++
-title = "creating a native-feeling neovim picker"
-date = 2026-03-21
-desc = "working on a neovim general picker using the ui2 framework and native features"
-tags = neovim,plugin
-+++
-
-= preface
-
-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]. After that, [telescope] 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] and [snacks.picker]. Both are
-widely used and regarded as great solutions. Unfortunately, i don't like either
-of them. I love [mini.nvim] and its ecosystem but i don't feel like their vision
-of a picker fits neovim. As for [snacks.picker], ... [let me just link this](/blog/neovim-native-configuration#why-i-don-t-like-lazy-nvim-or-packer) (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.
-
-= overview
-
-[artio.nvim] 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` 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` allows plugin authors to pass
-[additional attributes][vim-ui-select-attributes] to its props artio can use these to add additional
-functionality.
-
-~~~ lua
-local files = vim.iter(vim.fs.dir('.')):map(function(node, nodetype)
- return nodetype == 'file' and node
- end):totable()
-
-vim.ui.select(files, {
- prompt = 'select dir',
- format_item = function(item) return vim.fn.fnamemodify(item, ':.') end,
-
- -- artio & mini.nvim exclusive:
- preview_item = function(item)
- return vim.fn.bufadd(item)
- end,
- -- artio exclusive:
- get_icon = function(item) return require('mini.icons').get("file", item.v) end,
- }, function(item, _) vim.cmd.cd(item) end)
-~~~
-
-= features
-
-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.
-
-Key features include:
-
-- fuzzy & pattern matching (through the default sorter)
-- `vim.ui.select` replacement
-- configurable preview window
-- basic builtins: files, buffers, colorschemes, helptags, etc
-- optional icon support for builtins (through [mini-icons])
-
-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.
-
-For example, if you want to process fuzzy sorting through and external dependency you can do so by overwriting the default sorter:
-
-~~~ lua
-package.loaded['artio'].sorter = function(lst, input)
- local output = ... -- run your external cmd through `vim.system`
-
- -- process output and return matches
- return vim.iter(output):fold({}, ...)
-end
-~~~
-
-= configuration
-
-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` or change the way the preview is drawn with
-`config.win.preview_opts`.
-
-an example setup could look something like this:
-
-~~~ lua
-vim.pack.add({ "https://codeberg.org/comfysage/artio.nvim" })
-
--- after installation, calling its setup function allows you to adjust behavior
--- such as window size, prompt placement, and characters for the ui.
--- calling setup is entirely optional if you like the defaults.
-require('artio').setup({
- opts = {
- -- whether to draw the prompt at the bottom
- bottom = false,
- -- whether the window should shrink to fit the matches
- shrink = false,
- -- prefix for the prompt
- promptprefix = "",
- -- whether to draw the prompt title
- prompt_title = false,
- -- pointer for the selected match
- pointer = "",
- },
- win = {
- -- this can also be a fractal to indicate a percentage of the screen
- height = 16,
- -- works best with laststatus=3
- hidestatusline = true,
- },
-})
-~~~
-
-Keymappings are left to the user. You can find some examples in the [README]:
-
-~~~ lua
-vim.keymap.set("n", "", "(artio-files)")
-vim.keymap.set("n", "fg", "(artio-grep)")
-
--- smart file picker
-vim.keymap.set("n", "ff", "(artio-smart)")
-
--- general built-in pickers
-vim.keymap.set("n", "fh", "(artio-helptags)")
-vim.keymap.set("n", "fb", "(artio-buffers)")
-vim.keymap.set("n", "f/", "(artio-buffergrep)")
-vim.keymap.set("n", "fo", "(artio-oldfiles)")
-~~~
-
-These mappings are available through the [``][plug-key] 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.
-
-# TODO: comparison with other pickers
-# - position relative to builtin UI
-# - related tools and comparison
-# - contrast with Telescope
-# - contrast with fzf-lua
-# - contrast with snacks
-
-= future
-
-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.
-
-As for possible future features, im mostly looking into leveraging async
-handling of sorters but i'm open to further suggestions.
-
-# TODO:
-# - future direction
-# - possible improvements
-# - areas intentionally left open
-# - maintenance philosophy (long-term intent)
-
-= closing
-
-# closing summary (wrap-up)
-# restating purpose
-# who should use it
-# who probably should not
-
-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][minibuffer-issue]) is
-still pretty far away. As i've stated [on the neovim
-repo][minibuffer-issue__me], the current ui2 implementation is really cool but
-also kind of a footgun at times.
-
-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.
-
-If you're looking for the most performant and feature-rich picker artio
-probably won't be for you - and thats fine!
-
-If you want a picker that feels simple, extensible, and closely aligned with
-Neovim's prior design, artio is worth a look.
-
-[artio.nvim]: https://github.com/comfysage/artio.nvim
-[README]: https://codeberg.org/comfysage/artio.nvim/src/branch/main/README.md "README.md"
-[fzf-lua]: https://github.com/ibhagwan/fzf-lua
-[telescope]: https://github.com/nvim-telescope/telescope.nvim
-[mini.nvim]: https://github.com/nvim-mini/mini.nvim
-[mini-pick]: https://github.com/nvim-mini/mini.picker
-[mini-icons]: https://github.com/nvim-mini/mini.icons
-[snacks.picker]: https://github.com/folke/snacks.nvim
-[plug-key]: https://neovim.io/doc/user/map.html#%3CPlug%3E ""
-[vim-ui-select-attributes]: https://github.com/neovim/neovim/pull/37360
-[minibuffer-issue]: https://github.com/neovim/neovim/issues/35456
-[minibuffer-issue__me]: https://github.com/neovim/neovim/issues/35456#issuecomment-3538862420
diff --git a/data/blog/neovim-native-configuration.tkt b/data/blog/neovim-native-configuration.tkt
deleted file mode 100644
index b30cb1c..0000000
--- a/data/blog/neovim-native-configuration.tkt
+++ /dev/null
@@ -1,303 +0,0 @@
-+++
-title = "tending your editor config: building sylvee & lynn"
-date = 2025-08-13
-desc = "my adventure building a native-first neovim experience"
-tags = neovim,config
-+++
-
-# intro
-# - why i wanted a quieter, native-first neovim experience
-# - frustration with sprawling plugin ecosystems and fragile abstractions
-# - goal: a configuration that feels like neovim, not a replacement for it
-# - result: sylvee, a native-first neovim distro — and lynn, the small plugin manager that powers it
-
-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.
-
-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.
-
-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] or [blink-cmp] and, most importantly, no
-[lazy.nvim].
-
-== philosophy and foundation
-
-# section 1: philosophy and foundation
-# (what kind of user sylvee is built for)
-# - starting from neovim’s built-in features
-# - avoiding wrapping everything in custom logic
-# - respecting the defaults, only extending when necessary
-# - the garden metaphor: letting neovim bloom on its own
-
-neovim has become incredibly powerful out-of-the-box and i want to take advantage of that.
-so i created [sylvee][], a native-first neovim configuration that builds on the amazing
-features that have been added to neovim recently.
-
-to power plugin management i created a wrapper around [`vim.pack`], neovim
-nightly's native plugin manager. this wrapper is called [lynn.nvim][], and it
-powers the configuration that i made.
-
-= neovim's built-in features
-
-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.
-
-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`-prefixed keymaps to access
-different lsp-related editor features. these include `grn` to rename a symbol,
-`gra` to access code actions and `grr` to get a list of references. similarly,
-[tpope's vim-unimpaired](https://github.com/tpope/vim-unimpaired) has been
-integrated into neovim: you can now use `bracket + q` to switch items in the
-quickfix list and `bracket + b` to navigate the buffer list.
-
-apart from keymaps, a bunch of settings and autocmds are no longer
-needed: setting the ['omnifunc'] to lsp completion is done
-automatically when an lsp attaches and your folds will use treesitter
-when available.
-
-neovim's builtin completion has also been greatly improved: since
-version `0.11` 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'] - enabling this option will make the completion popup
-automatically appear while typing.
-
-lsp configuration has been a treat since [`vim.lsp.config`] 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/` 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`] and thats that. similarly, [nvim-lspconfig] has been
-simplified: you no longer have to even `require` this plugin - just
-throw it in your plugin list and it works.
-
-# TODO: mention `vim.pack`
-
-= sylvee: keeping configuration simple
-
-a core part of sylvee is the idea that configuration should be simple and
-minimal. this meant using the `plugin/` to load custom scripts instead of death
-by a thousand `require` statements in your `init.lua`.
-
-i didn't add custom keymaps unless a feature did not have a keymap builtin,
-like [`:tabnew`] which i bound to ``, or when the defaults required
-ergonomics that would simply break my hand, like [``] to open the alternate
-file which i bound to `` (a keymap that surpringly wasn't used yet by neovim).
-
-additionally, i made exceptions for keymaps which i found to better fit neovim's
-keymap model: switching tabs made more sense with `bracket + ` than
-[`gt/gT`]. although the goal is minimalism, i didn't want to compromise on my
-preferences - sylvee can be a little opinionated sometimes.
-
-= lynn: a plugin manager with charm
-
-== why i don't like lazy.nvim or packer
-
-over time the neovim community has reinvented plugin management time and time
-again - to me the days of `vim-plug` 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.
-
-this evolution was partly caused by the introduction of the
-`require('plugin').setup()` convention. whereas plugin used to set
-configuration options using global [`vim.g`] 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`. 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/` dir: authors would put
-autocommands in their `plugin/plugin-name.vim` to automatically initialize the
-plugin whenever appropiate events happened in the editor.
-
-since the introduction of [packer.nvim] and [lazy.nvim] the plugin spec received a
-new `config` function (and with [lazy.nvim] an even simpler `opts` table). now
-your configuration for a plugin, which in most cases was just calling `setup`,
-could now be done within the plugin spec. ... and now your plugins file is
-filled with unrelated configs, differently indented functions, and `opts` tables.
-
-finally, as mentioned earlier, [`vim.pack`] 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]. ... except there are some caveats. currently
-[`vim.pack`] only has support for the _management_ and _installation_ 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`] - which
-led me to create [lynn.nvim], 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.
-
-== lynn as a lightweight wrapper: no magic, just convenience
-
-lynn didnt need to do a lot: git cloning, installing, and setting up the plugin
-path was already handled by [`vim.pack`]. lynn simply needed to help with urls
-(allowing you to use `owner/repo` instead of `https://github.com/owner/repo`),
-allow lazy-loading if the plugin doesn't handle it by it self, and
-automatically source your config.
-
-the url wrapping simply means that lynn will assume a `owner/repo` format
-refers to a github repo. additionally, lynn supports url aliases: you can use
-`server:owner/repo` to use a custom git server instead of github.
-
-lazy-loading is kept pretty simple. there's no usercommand wrapping or keymaps
-that automatically source the plugin. instead, you can use the `event` field to
-create an autocommand for the plugin.
-
-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/` directory of your config that matches the name of the
-plugin. for [mini.nvim][] this means lynn will load `config/mini.lua` and for
-[fzf-lua][] this means lynn will load `config/fzf.lua`. finding these files is
-done by the `:runtime` 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.
-
-= using lynn and sylvee
-
-== adding plugins to lynn
-
-plugin specs are quite simple. you're probably already familiar with most of the fields it supports.
-
-here's an example with all the possible options:
-
-~~~ lua
-{
- 'owner/repo',
- url = 'https://github.com/owner/repo', -- optionally specify a custom url
- name = "cool-repo", -- optionally rename the plugin
- version = "main", -- pin the plugin to a specific version, allows for the use of `vim.version`
- path = "path/to/plugin", -- optionally specify a custom path
- deps = { "dep1", "dep2" }, -- specify dependencies
- event = "VimEnter", -- specify an autocommand event
- lazy = true, -- lazy-load the plugin
- after = function() end, -- pass a function to run after the plugin is loaded, by default sources the `config/plugin-name.lua` file
- before = function() end, -- pass a function to run before the plugin is loaded
-}
-~~~
-
-lazy loading is only done if `lazy` is set to `true` or an autocmd event is
-specified. this means that normally lynn will load the plugin after neovim's
-configuration stage is done.
-
-there are `after` and `before` fields but in most cases these should not have
-to be used. `after` will default to loading your config file so any important
-code should go there. `before` is only useful if you want to run code before
-the plugin is loaded.
-
-== using sylvee
-
-using sylvee is as simple as cloning the repo and running neovim with [`NVIM_APPNAME`] set to `"sylvee"`.
-
-~~~ bash
-git clone https://github.com/comfysage/sylvee.git ~/.config/sylvee
-NVIM_APPNAME=sylvee nvim
-~~~
-
-this can be simplified even more by creating a quick wrapper script for sylvee:
-
-~~~ bash
-#!/usr/bin/env sh
-# ~/.local/bin/sylvee
-NVIM_APPNAME=sylvee nvim "$@"
-~~~
-
-== what sylvee and lynn don’t do
-
-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.
-
-currently lynn does not go well with a nix-wrapped neovim setup. im working on
-adding this by allowing you to disable [`vim.pack`] within lynn - effectively
-making lynn a lazy-loader for local plugins.
-
-lynn also does not support plugin lock files or snapshots since these features
-are entirely dependent on neovim-core's implementation of [`vim.pack`]. [as soon
-as this is added][neovim/pr/lock] i will make sure lynn doesn't get in its way.
-
-lynn currently does not support complex lazy-loading rules like `mappings` or
-`cmd` 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.
-
-[neovim/pr/lock]: https://github.com/neovim/neovim/issues/34776
-
-= growing your own garden
-
-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.
-
-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][neovim/docs/qflist], [grep][neovim/docs/grep] and
-[marks][neovim/docs/marks], will help you build your own garden.
-
-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).
-
-[neovim/docs/qflist]: https://neovim.io/doc/user/quickfix.html
-[neovim/docs/grep]: https://neovim.io/doc/user/quickfix.html#_5.-using-:vimgrep-and-:grep
-[neovim/docs/marks]: https://neovim.io/doc/user/motion.html#_7.-marks
-
-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.
-
-i've tried my best to work _with_ what neovim provides and _against_ 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.
-
-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](https://github.com/comfysage/sylvee/discussions)!
-
-= references
-
-here are some references that add more context to this blogpost:
-
-- a [section](https://neovim.io/doc/user/lua-plugin.html#_lazy-loading) of the neovim docs explaining how to add lazy-loading to your plugin.
-- a [comment](https://github.com/neovim/neovim/issues/35562#issuecomment-3239702727) by [justinmk][] explaining how lazy-loading _should_ be done in neovim.
-
-[sylvee]: https://github.com/comfysage/sylvee "sylvee: minimal & native-first neovim config"
-[lynn.nvim]: https://github.com/comfysage/lynn.nvim "lynn.nvim: native-first neovim plugin manager with charm"
-['autocomplete']: https://neovim.io/doc/user/options.html#'autocomplete'
-['omnifunc']: https://neovim.io/doc/user/options.html#'omnifunc'
-[`:tabnew`]: https://neovim.io/doc/user/tabpage.html#%3Atabnew
-[``]: https://neovim.io/doc/user/editing.html#CTRL-%5E
-[`NVIM_APPNAME`]: https://neovim.io/doc/user/starting.html#_nvim_appname
-[`gt/gT`]: https://neovim.io/doc/user/tabpage.html#gt
-[`vim.g`]: https://neovim.io/doc/user/lua.html#vim.g
-[`vim.lsp.config`]: https://neovim.io/doc/user/lsp.html#_config
-[`vim.lsp.enable`]: https://neovim.io/doc/user/lsp.html#vim.lsp.enable()
-[`vim.pack`]: https://neovim.io/doc/user/pack.html#_plugin-manager
-[blink-cmp]: https://github.com/Saghen/blink.cmp
-[fzf-lua]: https://github.com/ibhagwan/fzf-lua
-[justinmk]: https://github.com/justinmk
-[lazy.nvim]: https://github.com/folke/lazy.nvim "shitty plugin manager"
-[mini.nvim]: https://github.com/echasnovski/mini.nvim
-[nvim-cmp]: https://github.com/hrsh7th/nvim-cmp
-[nvim-lspconfig]: https://github.com/neovim/nvim-lspconfig
-[packer.nvim]: https://github.com/wbthomason/packer.nvim
diff --git a/data/index.tkt b/data/index.tkt
deleted file mode 100644
index 22b8f41..0000000
--- a/data/index.tkt
+++ /dev/null
@@ -1,23 +0,0 @@
-== 🪴 garden
-
-welcome to my internet garden, a cozy corner of the internet for storing my ideas and sharing what i'm working on.
-
-~~~ bash
-curl -L robinwobin.dev
-~~~
-
-in my garden you can find my [blog posts](/blog) and more frequently some small [notes](/notes).
-
-this is where i keep the tools i've built - small creations designed to make
-development smoother, workflows simpler, and ideas easier to bring to life.
-
-