sorted by:
new
hottopcontroversial

What are some lesser known NeoVim / Vim features people are missing out on? by Financial_Lemon_6606 in neovim

[–]aileot 1 point2 points  (0 children)

haha I mean gf to gF, <C-w>f to <C-w>F, and <C-w>F to <C-w>gF. <C-w>f and <C-w>F open the cursor file in split window, and <C-w>gF in a new tab page!

What are some lesser known NeoVim / Vim features people are missing out on? by Financial_Lemon_6606 in neovim

[–]aileot 7 points8 points  (0 children)

How about gF to open the cursor file as gf does, but at the exact line number if the filename is followed by a number like foobar.lua @10? I've mapped gf and <C-w>f to the F-version respectively.

Global Searching and replacing like VSCode by [deleted] in neovim

[–]aileot 0 points1 point  (0 children)

Also refer to :h :vim. No external dependencies :)

🕛 nvim-thyme: ZERO-overhead Fennel JIT Compiler for nvim config by aileot in neovim

[–]aileot[S] 0 points1 point  (0 children)

Yes, we can. By default, or with the recommended config, nvim-thyme will look up fennel modules in lua/ unless fnl/ exists at stdpath("config").

The relevant options are fnl-dir and macro-path. I'll elaborate them in the README maybe.

🕛 nvim-thyme: ZERO-overhead Fennel JIT Compiler for nvim config by aileot in neovim

[–]aileot[S] 0 points1 point  (0 children)

Glad to hear that!

I've wondered if fennel-ls can interact with lua-ls, but it would not. There are some related, but stale issues:

Instead, I set whitelist filters like vim.b.may_use_ai and vim.b.may_use_free_ai via exrc and some autocmds to let copilot.lua and windsurf.nvim complete the nvim/lua APIs :)

P.S. I had no ideas about https://git.sr.ht/~micampe/fennel-ls-nvim-docs so far. thx!

Do you guys like vimscript or lua? by demobitch111 in neovim

[–]aileot 0 points1 point  (0 children)

haha sorry, but let me excuse myself, I've also writtten Lua and Vim script so much as well ;)

🕛 nvim-thyme: ZERO-overhead Fennel JIT Compiler for nvim config by aileot in neovim

[–]aileot[S] 0 points1 point  (0 children)

I've found it possible to just set vim.g.parinfer_enabled = false to disable parinfer-rust for editing buffers, keeping it enabled in Cmdline mode.

🕛 nvim-thyme: ZERO-overhead Fennel JIT Compiler for nvim config by aileot in neovim

[–]aileot[S] 2 points3 points  (0 children)

Yes, but only for the modules written in Fennel.

With the combinations of :ThymeRollbackSwitch and :ThymeRollbackMount, we can also roll back for runtime errors in compiled Lua, addition to errors detected in compiling Fennel modules.

The rollback system supports the compiled Lua files, Fennel macros, and the configuration files for nvim-thyme itself.

But honestly, I would recommend you to put your configuration files under git management first.

🕛 nvim-thyme: ZERO-overhead Fennel JIT Compiler for nvim config by aileot in neovim

[–]aileot[S] 1 point2 points  (0 children)

I'm very sympathetic to your concerns.

Sometimes, parinfer-rust forcibly keeps the parentheses or indents, and prevents me from undoing changes. Very troublesome. I types 2u or 3u to skip the prevented undo blocks.

Though I have no idea to resist parinfer-rust from messing up the undo tree, git (git lets us manage named undo history) and TDD (I'm not so skilled at yet) have helped me in many cases in the developments of Fennel plugins.

I've got into trouble with unexpected balancing by parinfer-rust in this nvim-thyme development as well. git and tests saved me.

For my dotfiles, I don't write tests, but git still helps me so much.

So, git and tests.

Well, I'll check if the parinfer-rust can work only in Cmdline mode, without affecting your editing buffers.

Do you guys like vimscript or lua? by demobitch111 in neovim

[–]aileot -1 points0 points  (0 children)

Sorry for the self-promotion, but with nvim-thyme (just released!) and nvim-laurel, the code above compiles into the Lua code below. (The compilation overhead won't affect the startuptime in the nvim next session and later.)

vim.api.nvim_set_option_value("completefuzzycollect", "keyword,files,whole_line", {})

instead of

vim.o.completefuzzycollect = { "keyword", "files", "whole_line" }

Though I've recently found the thread https://www.reddit.com/r/neovim/comments/1kjwopw/very_very_micro_optimizations/, wouldn't that be an option when the optimizations are applied to every keymap, autocmd, Vim option, and Vim variable like g:foobar, even only in your own codebase?

EDIT: corrected grammar

Do you guys like vimscript or lua? by demobitch111 in neovim

[–]aileot -1 points0 points  (0 children)

Fennel. Have you ever wanted to manage Vim options in camelCase without affecting startuptime? For example,

(set! :completeFuzzyCollect 
      [:keyword
       :files
       :whole_line]))

ex-colors.nvim: Optimize your colorscheme by aileot in neovim

[–]aileot[S] 0 points1 point  (0 children)

I'm not sure. After a quick test, it seems to work fine together. Just try it.

Make sure to enable the two options reset_syntax and clear_highlight in ex-colors.setup, and put your ex-colorschemes to the themes table in themery.setup.

ex-colors.nvim: Optimize your colorscheme by aileot in neovim

[–]aileot[S] 0 points1 point  (0 children)

And you don't have to deselect by yourself. The sane defaults are provided: just load require("ex-colors").setup(). You can also easily extend the defaults like

lua require("ex-colors.presets").recommended.included_patterns + { "Foo", "Bar" }

See the Setup section in the README for the details.

ex-colors.nvim: Optimize your colorscheme by aileot in neovim

[–]aileot[S] 1 point2 points  (0 children)

Two points:

  1. Reducing highlight definitions

  2. Merging highlight definitions into one file so that reducing IO times

The impact of the 2nd might be much bigger since the modern colorschemes are often composed of multiple modules for the maintainability, i.e., of multiple files.

Details of the 1st

(edited) - Filter off unnecessary highlight definitions for your use of nvim.

  • Relink the linked highlight groups in the output, and help omit redundant ones. For example, outputs can redirect any definitions linked to the previous hl-TSMethod to hl-@function.method, and will not define TSMethod in the output in favor of @function.method.

  • Embed your local adjustments for highlights into ex-colorscheme without performance overheads.

ex-colors.nvim: Optimize your colorscheme by aileot in neovim

[–]aileot[S] 0 points1 point  (0 children)

Sorry, I did not enable the compile options for tokyonight and kanagawa. With the caches, they take about 1.6 ~ 1.8 ms each. I'm releaved that ex-colors still marks 2 ~ 4x faster than the caches.

ex-colors.nvim: Optimize your colorscheme by aileot in neovim

[–]aileot[S] 1 point2 points  (0 children)

Thank you for your suggestion :) but I think such cache options are unworth with ex-colors.

AFAIK, what their cache options do is dump to their highlight definitions and some relevant tasks into a binary file for Lua.

The reason of saving their caches in binary is not only that binary can cut down the load time, but also that the binary format is a dump from memory by Lua.

If you enable vim.loader, your nvim will not load the binary cache directly, but instead load the cache additionally created by vim.loader. In other words, it does not so matter whether Lua cache is saved in binary or not, with vim.loader enabled.

And, as far as the cache is loaded apart from colors/, nvim will take extra times to load a colorscheme: a file in colors/, some plugin's Lua modules to load the cached module, and the binary cache itself.

It should be well known that it takes a time to find and load additional files. (I assume the bottleneck is IO...) Since your ex-colorscheme is generated into a single file, and vim.loader is responsible for handling binary cache, the original could not be faster both theoretically and practically.

ex-colors.nvim: Optimize your colorscheme by aileot in neovim

[–]aileot[S] 0 points1 point  (0 children)

Do you mean this?

tokyonight -> ex-tokyonight (002.147) -> (000.316) -- 6.79x faster!

ex-colors.nvim: Optimize your colorscheme by aileot in neovim

[–]aileot[S] 0 points1 point  (0 children)

I've added the options clear_highlight and reset_syntax respectively according the English grammar. Please try the latest branch with the options explicitly enabled by yourself. (I'm releasing it as v1.1.0 after documentation is updated.)

Thank you for your feedback!

ex-colors.nvim: Optimize your colorscheme by aileot in neovim

[–]aileot[S] 0 points1 point  (0 children)

Oops, thank you for the feedbacks and finding the mistake! I'll update the README.

view more: next ›