Feature: parsed lua function and code

[Alexnortung]

Description

I would like to have my lua code for my configs parsed by nixvim and report errors if I made typos or other mistakes. The idea is that we often use rawTypes to write custom logic for our configs, but sometimes you might write mistakes, and there isn't an lsp that can help me here since it is a nix string. This would then lead to me finding out in runtime that I made an error in my config and then having to fix it and rebuild. This can be a somewhat annoying process to deal with and would be great to catch in build time.

By doing this we can also check other things, such as if an options should be a function or a single node in the abstract synax tree.

Possible solution / proposal

I think we should keep the rawType just the way it is and still let users be able to write raw code if they want to.

helpers.mkRawSafe function

This function should do the same as mkRaw, but also parse the string and check for errors at build time. If there are any errors the build will fail.

Behind the scenes we it would create an attrset like { __raw = "..."; __rawOptions = { parse = true; }; }. I guess this can be checked by toLuaObject and raise/throw an error if the parse was not possible.

helpers.luaFunctionType type and mkLuaFunction function

the luaFunctionType type would accept rawType too to be compliant with the previous statement, but would look something like this

{
  __raw = "...";
  __rawOptions = {
    parse = true
    parseSingleValue = true;
    parseValueTypes = [ "function" ];
  };
}

The luaFunctionType would then only accept "function" in the parseValueTypes.

luaSingleValueType type and mkLuaValue function

This should be very similar to mkLuaFunction and luaFunctionType, but has parseValueTypes = [ "all" ]

Closing thoughts

This is of course just a rough draft, I am not sure the naming is the best, but I think it gives the gist. I would like to hear the opinions of other contributors/maintainers.

[pta2002]

How would this parsing/checking work? Not really feasible to check if it's valid lua code IMO...

[Alexnortung]

I think we should use a separate package/program that has an easy interface to work with. Parsing is often done really quickly so I don't see how it is not feasible?

There are options for a lua parser.

Here is a parser written in lua, we would have to wrap it in a program https://github.com/thenumbernine/lua-parser

Here is a cli program in python, it is not in nixpkgs, but it may be worth trying to get it in there first https://pypi.org/project/luaparser/

Of course the very best thing would be to have a parser written in nix, but that seems like it would be a project for itself.

[GaetanLepage]

I am honestly unable to decide whether it is a good idea or not.

• On the one hand, it could indeed help the user and make his life easier which is a very positive goal.
• On the other hand, I fear that it would add complexity and also be out of scope of this project. In this sense, I tend to go back to what other NixOS/HM modules do and, for the most part (of course there are some exceptions), they are limited to generate config files and install software from nixpkgs.

I am neither sold on the idea nor strongly against it. So if you come up with a good solution that does not appear to have major drawbacks, I will be glad to include it :)

[Alexnortung]

Alright, I get what you mean, I really like this project and I may want too many features for the scope of Nixvim. I have been thinking a little of making a separate repo that contains this functionality and maybe also #221 if I can make it work.

However I think that Nixvim should still be able to support just the types without adding more complexity.

To make this issue and #221 work, I think a small refactor of toLuaObject is needed. The only thing I would like to change is that I can hook into it with a middle or something and that it may also return a set of extra config which should be applied. I can try to make a draft of this today or at some point in the week.

I defenitely think that this is needed to be able to extend on Nixvim's core functionality.

Let me know what you think of this :)

[GaetanLepage]

Alright, I get what you mean, I really like this project and I may want too many features for the scope of Nixvim. I have been thinking a little of making a separate repo that contains this functionality and maybe also #221 if I can make it work.

However I think that Nixvim should still be able to support just the types without adding more complexity.

To make this issue and #221 work, I think a small refactor of toLuaObject is needed. The only thing I would like to change is that I can hook into it with a middle or something and that it may also return a set of extra config which should be applied. I can try to make a draft of this today or at some point in the week.

I defenitely think that this is needed to be able to extend on Nixvim's core functionality.

Let me know what you think of this :)

This makes perfect sense to me. I am more than ready to have a look at such proposition ! Glad that you are motivated and ambitious for this project :)