Skip to content

Conversation

@davidmh
Copy link

@davidmh davidmh commented May 6, 2025

Hi @Olical, I've been using Aniseed/Nfnl + Conjure for a while, it's been an absolute game changer for my personal development flow, thanks!

I noticed that this starter kit is still using Aniseed, so I figured you could be interested in migrating it to Nfnl.

I took a few liberties like adopting lazy.nvim as the plugin manager, and defining plugins in their own files. Hopefully nothing too different from what you had.

See individual plugins for details and let me know what you think.

davidmh added 2 commits May 6, 2025 09:49
Notable changes:

- Migrates away from Aniseed
- Update a few examples to use the latest Neovim APIs
- Check-in generated files
- Remove the sync script, lazy.nvim doesn't need it to update the
  plugins
- Introduce a projections file to ease navigation and define common
  templates
The "goto file" command looks for relative paths, since we're
transpiling lua from fennel, we want to consider fennel the source of
truth when available.

To do that, we need to update the `path`, `suffixesadd` and
`includeexpr` options to help vim understand how to read fennel paths
with lua fallbacks.

See `:h gf`
(lsp.pylsp.setup {})
(lsp.bashls.setup {})
(lsp.lua_ls.setup
{:settings {:Lua {:telemetry {:enable false}}}}))})
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking about adding mason and mason-lspconfig to ensure these dependencies are installed. Thoughts?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep I think that's a good pattern! I'm doing that over here + some other nice automatic things:

https://github.com/Olical/dotfiles/blob/d178b62cde51ee28e4cb317ca346208ab706329a/stowed/.config/nvim/fnl/plugins/lsp.fnl

@Olical
Copy link
Owner

Olical commented May 6, 2025

Oh nice, this is a great initiative, thanks! It definitely needed some love to bring it up to speed with all the modern plugins and ideas.

This looks great and I'll take a proper look as soon as I can. I guess the only guiding principal I can give is this: This repo should be a jumping off point that handles a bunch of the fiddly early bootstrapping and essential decisions for the user. But it should not aim to be a distribution like Astro or Lazy etc, it's not a kitchen sink, it's a minimal starter pack 😄

So whatever you feel like doing that you think fits into that idea, I say go for it. I'll be happy to garden and merge it into this repo. Alternatively, if you want to fork and continue this under your own repo I'll also happily send people your way from this readme.

@davidmh
Copy link
Author

davidmh commented May 6, 2025

it's not a kitchen sink, it's a minimal starter pack

I think I can trim out a few more plugins.

Separately, the common feedback I hear from peers when looking at starter kits is feeling like they don't know where to start, I would love to bake a guided tour, in the same spirit as :ConjureSchool, where each step opens a new file, and asks you to either read or update plugins and other settings.

I'll give it some thought, maybe that can be its own plugin that "ejects" itself at the end of the tour.

@Olical
Copy link
Owner

Olical commented May 7, 2025

Agreed, they can be overwhelming. So keeping this minimal and a guided tour of some kind sounds fantastic. I suppose automating the traversal of something like oil.nvim could also be a good way to show the directory structure.

And personally I lean away from automated ejection things because there's so much risk around accidentally overwriting or deleting something a user cared about. Also have to handle all the OS differences which might become quite a burden. I'd personally lean towards a demo mode that activates without install for the tour (like Conjure does) while also telling you where to drop the files to make it your own.

Like with https://github.com/Olical/clojure-giants-shoulders/ - I personally like telling people to copy this code or fork and modify rather than having it be something more magical than that. I've run into issues with things that "eject" in the past and I've struggled to find the source I wanted to read because it wasn't where I thought it'd be or it was some sort of template that would eventually generate files on disk.

That disconnect can be confusing. If the repo is instead exactly what you'll have in your own copy at the starting point, you can just browse exactly what you're going to get, not a thing that will generate your config. Hope that makes sense! I'm still open to being swayed, I just think a directory you put in the right place is simpler for everyone involved.

@davidmh
Copy link
Author

davidmh commented May 7, 2025

Yeah, that's a good point, I'll do some more cleanup soon, maybe having the general structure defined in the README is enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants