<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
      <title>Chish</title>
      <link>https://chish.dev</link>
      <description>Chish&#39;s blog, guides, and devlogs</description>
      <generator>Zola</generator>
      <language>en</language>
      <atom:link href="https://chish.dev/rss.xml" rel="self" type="application/rss+xml"/>
      <lastBuildDate>Sat, 14 Nov 2026 00:00:00 +0000</lastBuildDate>
      <item>
          <title>How I dropped LazyVim and wrote my own configuration from scratch</title>
          <pubDate>Sat, 14 Nov 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://chish.dev/blog/writing-own-neovim-config/</link>
          <guid>https://chish.dev/blog/writing-own-neovim-config/</guid>
          <description xml:base="https://chish.dev/blog/writing-own-neovim-config/">&lt;p&gt;The hardest part of adopting Neovim isn&#39;t learning modal editing or deciphering Lua--
it&#39;s the overwhelming paralysis of choice. When three different plugins seemingly do the exact same job,
and every forum thread argues passionately for a different one, it is absurdly easy to spiral into
&lt;a rel=&quot;external&quot; href=&quot;https://en.wikipedia.org/wiki/Analysis_paralysis&quot;&gt;analysis paralysis&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;To escape that loop and just get back to writing code, I took the shortcut everyone recommends:
I installed &lt;a rel=&quot;external&quot; href=&quot;https://www.lazyvim.org/&quot;&gt;LazyVim&lt;/a&gt;.&lt;/p&gt;</description>
      </item>
      <item>
          <title>Escaping AI Tutorial Hell and Learning to Actually Think in Code</title>
          <pubDate>Wed, 09 Sep 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://chish.dev/blog/ai-hell-and-confusion/</link>
          <guid>https://chish.dev/blog/ai-hell-and-confusion/</guid>
          <description xml:base="https://chish.dev/blog/ai-hell-and-confusion/">&lt;p&gt;Two friends and I are building a regex parser and interactive TUI in Go for Hack Club-- basically regex101,
but running directly inside the terminal using Bubble Tea.&lt;/p&gt;
&lt;p&gt;One took the engine (lexer, parser, NFA matcher), the second built the bridge between the two, and I took the TUI.&lt;/p&gt;
&lt;p&gt;Early in the project, I caught myself falling into a dangerous habit that almost every junior dev
is struggling with right now. I stopped it before it ruined my learning, broke the crutch, and forced
myself to build the core architecture from first principles.&lt;/p&gt;</description>
      </item>
      <item>
          <title>Fixing Sphinx&#39;s Hyphen-Eating Search</title>
          <pubDate>Tue, 01 Sep 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://chish.dev/blog/hyphen-search-regex/</link>
          <guid>https://chish.dev/blog/hyphen-search-regex/</guid>
          <description xml:base="https://chish.dev/blog/hyphen-search-regex/">&lt;p&gt;So Sphinx&#39;s search was doing this annoying thing where searching for &lt;code&gt;-v&lt;/code&gt;
or &lt;code&gt;--force&lt;/code&gt; just... returned nothing. Even in docs that literally have
those exact flags written out.&lt;/p&gt;
&lt;h3 id=&quot;the-mystery-python-indexer-vs-javascript-search&quot;&gt;&lt;!-- anchor-link.html --&gt;
&lt;a href=&quot;#the-mystery-python-indexer-vs-javascript-search&quot; aria-label=&quot;Anchor link for the-mystery-python-indexer-vs-javascript-search&quot;&gt;###&lt;/a&gt;
The Mystery: Python Indexer vs JavaScript Search&lt;/h3&gt;
&lt;p&gt;My first instinct was to go poke the JS search code since, well, that&#39;s
what actually runs the query right. But that&#39;s only treating the symptom
lol, by the time a query even reaches the JS side, the index has ALREADY
lost the hyphens. Turns out the Python indexer was stripping leading
hyphens before terms even got stored. So &lt;code&gt;-v&lt;/code&gt; was being indexed as just
&lt;code&gt;v&lt;/code&gt;, and no amount of JS fixing was ever gonna find that.&lt;/p&gt;
&lt;h3 id=&quot;flags-vs-compound-words&quot;&gt;&lt;!-- anchor-link.html --&gt;
&lt;a href=&quot;#flags-vs-compound-words&quot; aria-label=&quot;Anchor link for flags-vs-compound-words&quot;&gt;###&lt;/a&gt;
Flags vs Compound Words&lt;/h3&gt;
&lt;p&gt;Real fix had to happen on the Python side, regex change. The annoying part
was telling apart something like &lt;code&gt;-v&lt;/code&gt; (a flag, keep the hyphen) from the
hyphen inside &lt;code&gt;extra-curricular&lt;/code&gt; (a compound word, don&#39;t treat it special).
Those two cases look kinda similar but need totally different handling...&lt;/p&gt;
&lt;p&gt;This is what led me to &lt;strong&gt;negative lookbehind&lt;/strong&gt;, which I&#39;d genuinely never used
before. &lt;code&gt;(?&amp;lt;!pattern)&lt;/code&gt; basically checks &quot;hey is this pattern NOT sitting
right before me&quot; without actually consuming any characters. Zero width
check, so it doesn&#39;t eat part of what you&#39;re trying to match.&lt;/p&gt;
&lt;h3 id=&quot;the-regex-fix&quot;&gt;&lt;!-- anchor-link.html --&gt;
&lt;a href=&quot;#the-regex-fix&quot; aria-label=&quot;Anchor link for the-regex-fix&quot;&gt;###&lt;/a&gt;
The Regex Fix&lt;/h3&gt;
&lt;p&gt;Ended up with this:&lt;/p&gt;
&lt;pre class=&quot;giallo&quot; style=&quot;color: #E1E4E8; background-color: #24292E;&quot; &gt;&lt;code data-lang=&quot;regexp&quot;&gt;&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #F97583;&quot;&gt;(?&amp;lt;!&lt;/span&gt;&lt;span style=&quot;color: #79B8FF;&quot;&gt;\w&lt;/span&gt;&lt;span style=&quot;color: #F97583;&quot;&gt;)&lt;/span&gt;&lt;span style=&quot;color: #DBEDFF;&quot;&gt;-&lt;/span&gt;&lt;span style=&quot;color: #F97583;&quot;&gt;{1,2}&lt;/span&gt;&lt;span style=&quot;color: #79B8FF;&quot;&gt;\w[\w-]&lt;/span&gt;&lt;span style=&quot;color: #F97583;&quot;&gt;*|&lt;/span&gt;&lt;span style=&quot;color: #79B8FF;&quot;&gt;\w&lt;/span&gt;&lt;span style=&quot;color: #F97583;&quot;&gt;+&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Reading it out... match one or two hyphens followed by a word character
(and then whatever word/hyphen stuff after), BUT only if there&#39;s not
already a word character sitting right before those hyphens. That&#39;s what
kicks out the &lt;code&gt;extra-curricular&lt;/code&gt; case while still letting &lt;code&gt;-v&lt;/code&gt; and
&lt;code&gt;--force&lt;/code&gt; through clean. The &lt;code&gt;|\w+&lt;/code&gt; at the end is just... normal word
matching for everything that isn&#39;t hyphen-flag-shaped.&lt;/p&gt;
&lt;p&gt;PR&#39;s up against Sphinx now. Fingers crossed for review lol.&lt;/p&gt;
</description>
      </item>
    </channel>
</rss>
