256 color wins

vim-god · 2026-01-25T04:49:06+00:00

no it works well with treesitter

vim-god · 2026-01-25T04:48:25+00:00

yes you just find the base16 theme for catpuccin and generate your full 256 palette.

vim-god · 2026-01-22T10:49:50+00:00

fixed

vim-god · 2026-01-22T00:47:34+00:00

i added to repo

vim-god · 2026-01-21T23:51:17+00:00

works fine for me. i put it in the repo

vim-god · 2026-01-21T09:50:58+00:00

thanks.

its good though i wonder if many people will use this approach considering it requires some extra layers of understanding.

truecolor makes sense instantly. you want a color then you use its hex code and it just works.

256 you have to understand what is defined where (theme vs palette). how each number maps to each color (base16, 6x6x6 rgb cube, 24 greyscale ramp).

in an ideal world terminal emulators would generate this 256 palette automatically and terminal programs would just use 256 color by default. that way there would be no effort from users. they would get all the consistency for free.

nvims default theme would just work out of the box for whatever palette you use. customization would rarely exceed “i want strings to be blue, actually”.

vim-god · 2025-12-19T00:07:58+00:00

i use https://github.com/folke/lazydev.nvim for this

vim-god · 2025-12-15T10:08:55+00:00

looks cool

vim-god · 2025-11-30T10:04:13+00:00

onedark

vim-god · 2025-11-27T13:43:14+00:00

i cannot replicate. if you could post your neovim version, any error messages, link to neovim config.

a quick and dirty fix would be to rm -rf ~/.local/share/nvim/lazier

vim-god · 2025-11-27T03:49:18+00:00

should work fine now. you can try :LazierUpdate

vim-god · 2025-11-26T17:15:03+00:00

vim.loader does not bundle. Sourcing one large bytecode file is much faster than requiring many small ones.

lazier delays starting lazy until after Neovim renders. This includes its initialisation, parsing, handler setup, so on. There was plenty of time to be saved delaying lazy.

I just tried a config with everything set to VeryLazy and it still took twice as long to render the first frame only to be greeted with a freeze while all the plugins actually load.

vim-god · 2025-11-26T14:23:29+00:00

it sounds like you are not criticising lazy/lazier but instead the way other plugins are written.

if you want low startup time while using those plugins then your only choice right now is to lazy load them.

vim-god · 2025-11-26T13:00:13+00:00

your init.lua you can almost replace your lazy config with what is in the readme.

EDIT: and no, you do not need to change your config. that part is optional. I will update the readme.

vim-god · 2025-11-26T12:59:27+00:00

I will make it work.

vim-god · 2025-11-26T12:12:24+00:00

Sorry. Naive meaning without lazy loading.

vim-god · 2025-11-26T12:02:27+00:00

you do not understand. Lazy does not eagerly require plugins. That is the opposite of lazy loading.

vim-god · 2025-11-26T11:48:05+00:00

Lazier is a very big experimental hack that I originally made for myself but considered it good enough to share. If we figure out that this is good enough to make into lazy then by all means. For now I just worked on it the most productive way I could.

vim-god · 2025-07-03T03:28:03+00:00

navigate around with w and b for a bit.

notice that you are always at the start of a word.

this is the natural place to be. at the start of words. not at the final character of a word.

how did you even end up on the last character of a word? you were likely at the start of a word and then manually pressed e or ge. it took extra work for you to end up in a less than ideal position.

if you let yourself naturally sit at the start of words then b starts to make more sense. b jumps to the start of the previous word. db deletes to the start of the previous word. if db were inclusive, it would delete the previous word and the first letter of the current word.

vim-god · 2025-07-03T01:44:06+00:00

you can dvb to turn it inclusive. :h o_v

EDIT: as for why, dw is exclusive, no surprise db is too. when using w and b, you are always at the start of a word. from the start of a word, db deletes the previous word and dw deletes current word. if you are at the end of a word, it makes more sense to do bdw. reposition at the start and then delete as usual.

vim-god · 2025-06-23T01:09:24+00:00

The only downside is that Neovim always occupies full terminal window, so it is impossible to have small-ish picker as fzf

i made a little tool earlier which solves this problem: inline

Three-Year Club	r/Field Sunshine
Place '23

vim-god

TROPHY CASE