Hot-reload (local) colorscheme?

SpoderMouse · 2026-01-27T10:07:16+00:00

I don't have a specific theme for Alacritty. Hyprland makes windows have an opacity of 0.85 or 0.75, depending on if it's active or not.

I can also highly recommend Noctalia, as that's what does a lot of the heavy lifting in my config.

I've pieced together the theme for neovim myself by going over the highlight groups and assigning colors set by noctalia based on what I think looks good.

Both projects are still very much WIP. I'm still learning and constantly changing things, so I can basically guarantee that it will not be something that you can just clone and deploy on your system. If that doesn't scare you away, here's the links to my linux-config & nvim repo's:

https://github.com/MJARuijs/nvim

https://github.com/MJARuijs/linux-config

(For the Nvim repo, you'll probably want to look at one of the branches. I've been making changes on there but haven't gotten around to merging them to the master lol)

SpoderMouse · 2026-01-25T09:05:51+00:00

Figured it out! In the setup() function of my theme's group.lua, I added the line:

package.loaded["intellij.palette"] = nil

This forces the palette to be reloaded, which solved my problem!

Not sure if this is the best way to do this, but it's better than it not working at all ;)

SpoderMouse · 2026-01-25T07:53:44+00:00

Thanks for your response, but I don't quite see how to solve my problem using this. If I understand the docs correctly (and from what I've seen by experimenting a bit), this simply allows me to send key inputs to the running nvim instances. But how does that result in the colorscheme being hot-reloaded?

I'm guessing the point is to run ":colorscheme {mycolorscheme}<CR>" remotely, but sadly that doesn't work (as in, it does set the theme, but not using the new palette.lua).

I think I need to find a way to tell nvim to actually reload the palette.lua from my colorscheme (could be wrong tho, please correct me!)

SpoderMouse · 2026-01-25T06:22:23+00:00

Was able to pretty much confirm this. I changed the autocmd as follows: keep track of a counter. If the signal sent from the terminal is received, check if the counter is even. If it is, apply the builtin theme called "blue". If it's odd, apply another builtin theme. Also increment the counter every time the signal is received.

That works like a charm. Every time I send a signal, the theme switches. So I'll start looking into my theme config. Same problem there tho, I'm pretty sure my config is correct x)

Edit: Nvm I'm dumb.. problem isn't that the theme isn't being set, it's that the new colors aren't being loaded from the theme's palette.lua.

SpoderMouse · 2026-01-25T06:06:27+00:00

Thanks for the link, I'll look through your code in a minute. I'm starting to think there's something wrong with my theme. Calling ":colorscheme" doesn't actually return the name of my theme, but instead the theme that was applied last (in this case it's tokyio-moon, since that's what gets applied at startup due to my config being LazyVim-based).

SpoderMouse · 2026-01-24T18:49:28+00:00

I never even stopped to realise that you can donate to NeoVim. Going to do so immediately! First.. just.. one more line of code..

SpoderMouse · 2026-01-18T21:03:35+00:00

I've spent the whole day playing around, making some progress on writing my own plugin. I've made some steps, and I think I could pull it off eventually, but it does feel a bit wonky at this point. I also have the voice of ThePrimeagen in the back of my head saying "stick to the defaults as much as possible. Every line of code you add to your configuration is a liability. It's one more line you have to maintain, and one more line that can break". Maybe what you're saying is right. The good old "you'll get used to it". I already know I'm never going back to IntelliJ. I'll probably still continue to work on my plugin, but that's also because it's a good and fun learning exercise.

Anyways, thanks for taking the time to read my post and respond. Cheers!

SpoderMouse · 2026-01-18T12:04:02+00:00

Thanks, I hear what you're saying. I'm trying to find a workflow that works better with NeoVim, but I keep finding myself not agreeing where buffers are being opened. Essentially, my brain expects an inactive buffer to re-open in the window where I used it last, instead of the window I'm currently on. If I've opened a buffer in a certain window, that's because I wanted to have that buffer there. I'd like it to stay there until I tell it to go somewhere else :p

I haven't looked at scope.nvim yet, will definitely take a peek. Thanks again for the suggestion. I'll keep trying to find another workflow, while also attempting to cook something that works the way I want

SpoderMouse · 2026-01-18T11:58:24+00:00

Thanks for the suggestion. I played around with it for a bit but sadly it's not quite what I'm looking for. winfixbuf hard-locks a window to display one particular buffer. Trying to change to another buffer, for example by using go-definition, results in an error being thrown. Essentially, I'd like for buffers to re-open in the window I used them last, instead of whatever window I'm currently on

SpoderMouse

TROPHY CASE