Migrate to nix2vim?

[gytis-ivaskevicius]

Hi, I came around to your project and I gotta say - I love the amount of work you have put into this project, will definitely steal a few things :)

One of the things I'd like to see is migration to https://github.com/gytis-ivaskevicius/nix2vim/, It is a non-opinionated neovim wrapper that defines a simple API to define lua options. I think it would be great if this project was a higher degree of abstraction over nix2vim

[NotAShelf]

Hey! First and foremost, thank you for your interest. Glad to know I could be of any help to anyone with this project.

I am aware there are a bunch of "neovim wrapper" kind of projects, nix2vim being one of them. Which is one of the reasons why this project sparked into existence: none of those quite did what I wanted them to.

Taking another look at nix2vim after some time, I am not quite sure what exactly it would contribute to the project. Right now, this flake implements at least a decent way to add everything into a neovim configuration, so not entirely sure if I want to complicate even further, while breaking backwards compatibility with Lua - what everyone uses to configure their neovim before they take a dive into NixOS.

But of course, I am always open to new ways on how to improve this project, and will be on the lookout as nix2vim matures.

In the meantime, if you would like to demonstrate a sample implementation of your project into this flake, I would be happy to review it! And of course, answer your further questions as well.

[gytis-ivaskevicius]

What nix2vim does is it dynamically generates Lua from nix code, its a low-level abstraction and basically removes a need for modules as such: https://github.com/NotAShelf/neovim-flake/blob/main/modules/basic/default.nix. Instead of defining every possible option in vim and keeping everything up to date, you just have a dynamic generation of lua where users can define whatever they feel like using APIs

Dynamic lua2nix parser test: https://github.com/gytis-ivaskevicius/nix2vim/blob/master/checks/default.nix

API's example: https://github.com/gytis-ivaskevicius/nix2vim/blob/master/modules/essentials.nix

• vim - Allows users to set options
• set - Alias to vim.o (if I recall correctly, works as in usual vimscript set)
• nmap/inoremap/etc - Keys definition

and of course, there are other API's. modules directory contains my personal vim config and is an example for everyone else

nix2vim does not add first-class support for plugins, and this is where this flake comes in :))) I would absolutely love to see this repository as a higher degree abstraction that adds first-class support for plugins like tree-sitter/which-key/lsp/etc

[gytis-ivaskevicius]

*Let me know if you are interested and maybe I could prepare some POC

[NotAShelf]

Sorry for the late response.

I have expressed my uncertainty before, but once again: I am not sure if I really want to abstract the config through another nix wrapper while this is already supposed to be that wrapper. Additionally, wrapping lua with nix seems only counterproductive to me: people use lua and forcing people to use nix or/and vimscript (the one thing I strive to move away from) is not a route I wish to take.

However, I find nix2vim quite interesting so maybe we could offer nix2vim's functionality through a separate module or like a plugin?

[gytis-ivaskevicius]

nix2vim offers to define custom lua/vimscript for things that can not be represented in an FP manner.

However, I find nix2vim quite interesting so maybe we could offer nix2vim's functionality through a separate module or like a plugin?

It would probably conflict with some of the defined options by this project, and it does not make much sense to put lower-degree abstraction on top of higher degree

As I noted previously, it is a low-level abstraction that would drop a lot of boilerplate code for this project and would allow to easily define properties that are not supported by this project. If you think that it is not appropriate to use this as a base - I can't really say much else to prove you wrong

Quick example:
with nix2vim one would rewrite this https://github.com/NotAShelf/neovim-flake/blob/main/modules/assistant/tabnine.nix#L18-L26 as such:

setup.tabnine = {
  disable_auto_comment = true;
  accept_keymap = "<Tab>";
  dismiss_keymap = "<C-]>";
  debounce_ms = 800;
  execlude_filetypes = ["TelescopePrompt" "NvimTree" "alpha"];
};

This is cleaner and since its module system based - it allows users to overwrite these properties at will.

To reiterate, I would love to see this project as a higher degree abstraction where nix2vim provides base APIs and this project defines a bunch of drop-in modules and first-class support for plugins

[NotAShelf]

To be completely honest with you, the main problem is that nix2vim is above my knowledge of nix and as such I cannot predict the full effect of a potential integration - which is why I am acting with hesitation.

I share your excitement in implementing nix2vim to this flake, while I do not (yet) understand it completely, it does seem like a good project and I too would like to see it integrated with neovim-flake, but again, it is above my understanding of nix (and {,neo}vim).

If you would like to make a PR to implement this while I (and this project) go on a short hiatus, I would be more than happy to entertain such a PR. Otherwise, I unfortunately do not see myself able to write the impementationl myself in a close future.

[NotAShelf]

I've created #17 to track the status of a possible integration. It's not in my to-do list at the moment but I'll try to give it a try when I have the time.

[NotAShelf]

I can potentially work on it after the 0.3 release, which is (I hope) the last time I add new plugins.