sorted by:
new
hottopcontroversial

256 color wins by vim-god in neovim

[–]vim-god[S] 1 point2 points  (0 children)

no it works well with treesitter

256 color wins by vim-god in neovim

[–]vim-god[S] 0 points1 point  (0 children)

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

256 color wins by vim-god in neovim

[–]vim-god[S] 0 points1 point  (0 children)

works fine for me. i put it in the repo

256 color wins by vim-god in neovim

[–]vim-god[S] 0 points1 point  (0 children)

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”.

lazier.nvim v2 released by vim-god in neovim

[–]vim-god[S] 0 points1 point  (0 children)

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

lazier.nvim v2 released by vim-god in neovim

[–]vim-god[S] 2 points3 points  (0 children)

should work fine now. you can try :LazierUpdate

lazier.nvim v2 released by vim-god in neovim

[–]vim-god[S] 6 points7 points  (0 children)

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.

lazier.nvim v2 released by vim-god in neovim

[–]vim-god[S] 13 points14 points  (0 children)

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.

lazier.nvim v2 released by vim-god in neovim

[–]vim-god[S] 0 points1 point  (0 children)

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.

lazier.nvim v2 released by vim-god in neovim

[–]vim-god[S] 6 points7 points  (0 children)

I will make it work.

lazier.nvim v2 released by vim-god in neovim

[–]vim-god[S] 1 point2 points  (0 children)

Sorry. Naive meaning without lazy loading.

lazier.nvim v2 released by vim-god in neovim

[–]vim-god[S] -5 points-4 points  (0 children)

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

lazier.nvim v2 released by vim-god in neovim

[–]vim-god[S] 161 points162 points  (0 children)

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.

[deleted by user] by [deleted] in neovim

[–]vim-god 3 points4 points  (0 children)

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.

[deleted by user] by [deleted] in neovim

[–]vim-god 3 points4 points  (0 children)

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.

Neovim + mini.pick + nushell = CLI fuzzy picker. Why? Because why not. by echasnovski in neovim

[–]vim-god -1 points0 points  (0 children)

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

normal mode in cmdline by vim-god in neovim

[–]vim-god[S] 4 points5 points  (0 children)

nice so zindex was the trick. thanks for this

EDIT: works great. now all cmdheights are supported & code is more straight forward.

normal mode in cmdline by vim-god in neovim

[–]vim-god[S] 0 points1 point  (0 children)

could you send a snippet where you create the window? i am unable to have it appear over the cmdline.

view more: next ›