<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Vim on Sad Frog Blog</title><link>https://sadfrogblog.com/tags/vim/</link><description>Recent content in Vim on Sad Frog Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 14 Sep 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://sadfrogblog.com/tags/vim/index.xml" rel="self" type="application/rss+xml"/><item><title>We can do better than `vim.g`</title><link>https://sadfrogblog.com/we_can_do_better_than_g/</link><pubDate>Thu, 14 Sep 2023 00:00:00 +0000</pubDate><guid>https://sadfrogblog.com/we_can_do_better_than_g/</guid><description>&lt;p&gt;Returning to the use of globals for all neovim configuration would be a step backward for the Neovim plugin ecosystem, especially when another better and easier &lt;a href="#split-setup-in-two"&gt;possibility&lt;/a&gt; exists.&lt;/p&gt;&#10;&lt;h2 id="some-history"&gt;Some History&lt;/h2&gt;&#10;&lt;p&gt;Recently, there&amp;rsquo;s been a bit of a debate going on in the Neovim community around how we should structure our plugins.&#10;One of the &lt;a href="https://mrcjkb.dev/posts/2023-08-22-setup.html" rel="noopener"&gt;arguments&lt;/a&gt; that&amp;rsquo;s been put forward has been that we should return to the older &amp;ldquo;vim&amp;rdquo; style of plugin configuration, i.e global variables that are picked up by our plugins at runtime to handle configuration.&lt;/p&gt;</description></item></channel></rss>