Initial feedback

[Olical]

I hope you like the look of nfnl in these early stages. Please let me know what you think here!

[tylerw]

Looking forward to trying this out! I am a big fan and current user of Aniseed, but it was different enough from standard Fennel that made use of other plugins a bit of a chore, as well as generating lots of unnecessary diagnostic messages from the LSP. I'm sure that is part of the reason you created nfnl.

I'm glad to see the standard library you included, that will make my config migration a bit easier. After the project is considered relatively stable, adding a migration guide from Aniseed would probably help many users.

[Olical]

Yeah my goal is to basically create Aniseed without some of the choices I regretted and a little less special sauce in the syntax department. I'm also not reinventing wheels like testing, instead I'm deferring to plenary's test harness, actually making use of the Lua Neovim ecosystem that kinda sprung up after Aniseed was well under way.

Also building it with my lessons in plugin/config development differences in mind. Tried to write it in a way that didn't require special cases, scripts, sed-editing of compiled output. I'm trying to make this a lot more elegant so things just slot together with the rest of the ecosystem nicely, no extra work required.

Macros were one of the major headaches with Aniseed, I think I've hit a really nice UX for them with this project. They're actually viable and not a pain anymore! I think!

Also generating API docs for the Lua modules instead of manually keeping them in sync with a text file is going to make a big difference.

I'll be sure to write up a migration guide once I'm happy with the interface and config. There's really not much interface, my hope is that for 95% of people they just need to touch .nfnl.fnl and then code, but for some people I think they'll want a very small amount of config to compile .fnl files at the root of their project, like init.fnl -> init.lua in their Neovim config.

Just need to find a nice way to support 99% of cases with the defaults ideally.

[Olical]

I'm using LSP pretty heavily with the nfnl codebase to catch mistakes etc, it's not doing much autocompletion but the unused references stuff is VERY helpful!

[nbardiuk]

I have switched from Aniseed to nfnl for my neovim config. My usage is very limited - one big file, didn't split into modules.

What was not obvious to me is that Conjure ships with vendored Aniseed which means:

• I can import utilities from aniseed (temporary)
• Conjure evaluations still work for fnl files

What I like is that nfnl has less magic 🧙🏻 compared to Aniseed:

• easier to figure out when compilation happens
• there is less custom compilation happening like in modules feature

One annoyance with nfnl is that I need to take care of lua files. I went with recommend option to commit them to repo, which make sense.

So far I like it, thank you

[Olical]

Awesome, thank you so much for the feedback! And yeah, Conjure's default client for .fnl is an Aniseed client with a bundled version of Aniseed. I think it's mentioned in the help text etc but it trips up a LOT of people.

That will probably change over time as I migrate Conjure to be built with nfnl and the default fnl client may swap to using it by default. Or maybe I'll swap the client based on a heuristic? Sounds scary, but possible.

I'm going to write a tool to convert my Aniseed code to pure Fennel soon I think, that'll make converting Conjure a lot easier. The test suite will be much harder to port to plenary's busted style, but will do it eventually.

What I like is that nfnl has less magic 🧙🏻 compared to Aniseed:

Yep! I wanted it to be "magic" in the sense that it "just works" and doesn't even need to load unless you're editing .fnl files but tried to remove any "bad magic" around special syntax or weird requirements and assumptions. Hopefully this helps nfnl live in harmony with the rest of the fennel+lua nvim ecosystem.

And yeah, I've spoken about the lua files being in your hands a few times now, it's definitely a polarizing topic, but I just have to ask people to trust me. It's worth it for the good things it brings. That's a hard choice I made after many hard lessons over the years of tinkering with this stuff.

There's always alternatives like hotpot which are amazing for that more "don't let me see the lua" approach. nfnl now overlaps a lot more with those existing fnl nvim tools, it just takes quite a minimal approach to it that tries to integrate with native nvim things as deeply as possible.

Thanks again for the feedback! I'll keep it in mind 🙂

[datwaft]

Good news, I just tested nfnl with my macros and it works out of the box! I only installed the macros using Lazy and they worked out of the box! (If anyone needs context they can see this issue: Olical/conjure#286, it was happening with both Aniseed and Conjure).

Additionally, I am working on MacOS, so you can add to the README that it works on MacOS too!

Here is my current demo configuration: https://github.com/datwaft/nvim-nfnl

[rafaeldelboni]

I've been using nfnl config based for a week now and I'm really liking so far, I don't know if is placebo or the lazy.nvim replacing packer.nvim, but it feels faster now.

I still don't like the idea of committing my lua files, but I get why you decided to follow this option.