diff --git a/src/content/config.ts b/src/content/config.ts index 50a0537..3c6cdd1 100644 --- a/src/content/config.ts +++ b/src/content/config.ts @@ -6,6 +6,7 @@ const base = z.object({ date: z.string().optional(), useKatex: z.boolean().optional(), useD3: z.boolean().optional(), + redirect: z.string().optional(), }); export const collections = { diff --git a/src/content/git/cp.nvim.mdx b/src/content/git/cp.nvim.mdx new file mode 100644 index 0000000..4e32c61 --- /dev/null +++ b/src/content/git/cp.nvim.mdx @@ -0,0 +1,46 @@ +--- +title: "cp.nvim" +slug: "cp.nvim" +date: "10/10/2025" +--- + +[Source code](https://github.com/barrett-ruth/cp.nvim) + +Things have changed since I last documented my competitive programming setup [here](https://barrettruth.com/posts/software/my-cp-setup.html). + +# my goals + +After many months of using the aforementioned `make` based setup, I had a few qualms: + +- I'm lazy: I grew tired of copying (and mis-copying) inputs, outputs, etc from online judges. +- I'm lazy: I frequently submitted incorrect solutions after erroneously asserting that my outputs matched those of the sample test cases +- External dependencies: it unsettles me that my bare-bones setup required copy-pasting an entire suite of scripts +- Non-native NeoVim experience: while composition and the UNIX philosophy are great, there's only so much you can do with pipes and files. + - Raw I/O files meant I couldn't see colored stdin/stdout + - Fine-grained per-testcase I/O was suspect--isolating and running a subset of test cases required manual intervention + +The solution was to leverage Neovim's great APIs to give me granular control over every aspect of my problem-solving experience. + +# the solution: cp.nvim + +The GitHub page documents the plugin well enough so I'll avoid re-hashing it here. Instead, what's more interesting to document is why I thought this was a worthwhile experience. + +1. Making Something Useful for Others: cp.nvim is an opportunity for me to make my first open-source project "right"--not some side project or demo, but a *real*, usable tool that I'll be rolling out to the public soon. I consider the following in my active development of the plugin: + +- Comprehensive continuous integration (*real* testing, linting, and more) +- [LuaRocks](https://luarocks.org/) integration (the future of NeoVim package management) +- Concise and thorough Vimdoc documentation that communicates effectively +- Modern lua tooling: use of [busted](https://lunarmodules.github.io/busted/), [selene](https://kampfkarren.github.io/selene/) and more integrated with the NeoVim lua interpreter +- Sensible user defaults & extreme customization +- Proper versioning, tagging, and releases + +2. The Neovim Community: I'm elated to finally give back to the community (even if no one uses this plugin). [folke](https://github.com/folke), [bfredl](https://github.com/bfredl), and [echasnovski](https://github.com/echasnovski) are my greatest inspirations as an open-source developer and I've had enough of taking without giving back. +- In the coming months I plan to contribute to [NeoVim core](https://github.com/neovim/neovim), including making `:checkhealth` asynchronous and integrating an [mdx](https://mdxjs.com/) parser. + +3. Learning Random things: I think this plugin is *really* cool by virtue of its efficacy and the miscellany of knowledge I accrued in the 15k+ LOC as of version v0.3.0. Some things I learned include: + +- ANSI terminal colors and escape codes: I wrote my own stateful ANSI escape sequence parser to map raw bytes to native NeoVim highlighted text +- Extmarks: NeoVim extmarks (`:h extmarks`) are extremely powerful. Here, I used them to apply dynamic highlighting across various components of the plugin but I also plan to leverage virtual text to catch compile errors in real-time +- VIM filetypes and diffing: Vim is strange and the event-based system is fragile. I faced filetype detection race conditions and odd side effects of functions (such as `:diffthis` resetting `foldcolumn`). +- [LuaCATS](https://github.com/LuaCATS): apparently writing comments is the best way to typecheck in lua... +- The (Neo)Vim event loop: Scraper subprocesses spawned with `vim.system`. Though a powerful API, I often had to obey the event loop and wrap side effects with `vim.schedule` to ensure they ran after jobs finished. This was useful to defer UI updates. diff --git a/src/content/software/cp.nvim.mdx b/src/content/software/cp.nvim.mdx index 6e26d1d..62b5706 100644 --- a/src/content/software/cp.nvim.mdx +++ b/src/content/software/cp.nvim.mdx @@ -1,46 +1,5 @@ --- title: "cp.nvim" slug: "cp.nvim" -date: "21/09/2025" +redirect: /git/cp.nvim.html --- - -[Source code](https://github.com/barrett-ruth/cp.nvim) - -Things have changed since I last documented my competitive programming setup [here](https://barrettruth.com/posts/software/my-cp-setup.html). - -# my goals - -After many months of using the aforementioned `make` based setup, I had a few qualms: - -- I'm lazy: I grew tired of copying (and mis-copying) inputs, outputs, etc from online judges. -- I'm lazy: I frequently submitted incorrect solutions after erroneously asserting that my outputs matched those of the sample test cases -- External dependencies: it unsettles me that my bare-bones setup required copy-pasting an entire suite of scripts -- Non-native NeoVim experience: while composition and the UNIX philosophy are great, there's only so much you can do with pipes and files. - - Raw I/O files meant I couldn't see colored stdin/stdout - - Fine-grained per-testcase I/O was suspect--isolating and running a subset of test cases required manual intervention - -The solution was to leverage Neovim's great APIs to give me granular control over every aspect of my problem-solving experience. - -# the solution: cp.nvim - -The GitHub page documents the plugin well enough so I'll avoid re-hashing it here. Instead, what's more interesting to document is why I thought this was a worthwhile experience. - -1. Making Something Useful for Others: cp.nvim is an opportunity for me to make my first open-source project "right"--not some side project or demo, but a *real*, usable tool that I'll be rolling out to the public soon. I consider the following in my active development of the plugin: - -- Comprehensive continuous integration (*real* testing, linting, and more) -- [LuaRocks](https://luarocks.org/) integration (the future of NeoVim package management) -- Concise and thorough Vimdoc documentation that communicates effectively -- Modern lua tooling: use of [busted](https://lunarmodules.github.io/busted/), [selene](https://kampfkarren.github.io/selene/) and more integrated with the NeoVim lua interpreter -- Sensible user defaults & extreme customization -- Proper versioning, tagging, and releases - -2. The Neovim Community: I'm elated to finally give back to the community (even if no one uses this plugin). [folke](https://github.com/folke), [bfredl](https://github.com/bfredl), and [echasnovski](https://github.com/echasnovski) are my greatest inspirations as an open-source developer and I've had enough of taking without giving back. -- In the coming months I plan to contribute to [NeoVim core](https://github.com/neovim/neovim), including making `:checkhealth` asynchronous and integrating an [mdx](https://mdxjs.com/) parser. - -3. Learning Random things: I think this plugin is *really* cool by virtue of its efficacy and the miscellany of knowledge I accrued in the 15k+ LOC as of version v0.3.0. Some things I learned include: - -- ANSI terminal colors and escape codes: I wrote my own stateful ANSI escape sequence parser to map raw bytes to native NeoVim highlighted text -- Extmarks: NeoVim extmarks (`:h extmarks`) are extremely powerful. Here, I used them to apply dynamic highlighting across various components of the plugin but I also plan to leverage virtual text to catch compile errors in real-time -- VIM filetypes and diffing: Vim is strange and the event-based system is fragile. I faced filetype detection race conditions and odd side effects of functions (such as `:diffthis` resetting `foldcolumn`). -- [LuaCATS](https://github.com/LuaCATS): apparently writing comments is the best way to typecheck in lua... -- The (Neo)Vim event loop: Scraper subprocesses spawned with `vim.system`. Though a powerful API, I often had to obey the event loop and wrap side effects with `vim.schedule` to ensure they ran after jobs finished. This was useful to defer UI updates. diff --git a/src/pages/[category]/[slug].astro b/src/pages/[category]/[slug].astro index d87c49a..885549e 100644 --- a/src/pages/[category]/[slug].astro +++ b/src/pages/[category]/[slug].astro @@ -24,11 +24,15 @@ export async function getStaticPaths() { const { post } = Astro.props; const category = Astro.params.category; const { Content } = await post.render(); -const data = post.data; -const pageTitle = `${category}/${data.title ?? post.slug}`; +const pageTitle = `${category}/${post.data.title ?? post.slug}`; + +console.log(Astro.props); +if (post.data?.redirect) { + return Astro.redirect(post.data.redirect, 301); +} --- - + {pageTitle}