FEY as a modular Neovim framework

[faerryn]

Upon @tami5's request, Here be discussion for making FEY work for YOU as a modular framework!

[kkharji]

A framework for configuring neovim with lua should adhere to the following requirements:

• FR1: It should not have a say over what mappings or options to set, but rather provide the easiest and performance efficient way to set them. mappings and options are sooooo personal for every long term vim user
• FR2: It should not change or modify nvim config path, but rather be controlled from it
• FR3: It should not install or update plugins, but rather provide methods for installing, checking, updating them (wrappers).
• FR4: It should autoload and install plugins under modules/category/module or modules/module, if available, and if not don't do anything, and let the user structure their calls for installation or configuration on their own, thus acting as a library rather than a framework.
• FR5: It should not have predefined set of plugins unless its extremely necessary for it to function and serve it purpose (i.e. minpack, lua libraries). However, it should have an example list of plugin that should be installed and actvited in global scope, such as the ones defined now in root/packages.lua
• FR6: It should provide wrappers around setting autocmd, mappings, and options, where the should be define in dict/tables that contains the key and the values, for example:

local global_opts = {
  ---| Buffers ---
  hidden          = true; -- This shold be default!!!
  autoread        = true; -- Automaticly update file buffer if it changed
  autowrite       = true; -- Write file on set command
  autochdir       = false; -- we will be using vim-rooter
}

fey.set_options = function (o, t) 
  for k, v in pairs(o) do vim.t[k] = v end
end

fey.set_options(global_opts, o)

• FR7: It should be developed with functional style, I.e. no function with side effect, nothing left out in the open (i.e. everything is enclosed within a function, and called within other function), and if that the cases it should use functional library such as Moses.

• FR8: Its source code should be extremely easy to reason and understand (modularity, comment rich), so that contributes can easy understand whats going on and contribute.

Please, add additional requirements, or refer to a requirement to further discuss it and reason with it.

[faerryn]

1. I like FR6 and FR8, will see what I can do.
2. FR 2 - we need to control init.vim to actually run FEY code. I think the user would appreciate a clean directory to work in, such as ~/.config/fey
3. FR 3 - minpac and the fey script already do that?
4. FR 4 - autoloading modules is something I decided against when I started the project. I want it to be easy to disable and re-enable modules just by editing init.lua. Plus, I think that FEY should provide default modules so that a person can just use it and be done.
5. FR1, and 5 - one can just copy a module they want to modify into ~/.config/fey and change whatever they want about it. The user-defined module will always be evaluated instead of the default module. As mentioned before, I think default modules are a good thing.

[kkharji]

FR 2 - we need to control init.vim to actually run FEY code. I think the user would appreciate a clean directory to work in, such as ~/.config/fey

Having separate path is just an extra place to maintain, as a user I don't want to worry about another path, and as I'm used to ~/.config/nvim, I don't want it to change just because I adapted fey framework. In user init.vim, perhaps, the user shall have a function that check if fey is available in say ~/.cache/fey or ~/.local/share/fey and sourced it, otherwise download it.

For example, I'm using the following to check if minpack is installed, and as a work around to skip running fey install:

local is_dir = function(path) 
  local p = vim.fn.expand(path)
  if os.execute(string.format('[ -d "%s" ]', p)) == 0 then
    return true
  else 
    return false
  end
end

local check_minpac = function()
  local minpacpath = string.format('%s/pack/minpac/opt/', vim.fn.stdpath('cache'))
  if not is_dir(minpacpath) then 
    if vim.fn.input("Download minipack? (y for yes) ") ~= "y" then -- TODO:(tami) just download and tell me you are downloading
      return
    end
    vim.fn.mkdir(minpacpath, 'p')

    local out = vim.fn.system(string.format(
      'git clone %s %s',
      'https://github.com/k-takata/minpac',
      minpacpath .. 'minpac'
    ))

    print(out) -- TOOD:(tami) remove
    print("Downloading minpac ...")
    return
  end
end

check_minpac()
-- after that fey wrappers can be called ...

FR 3 - minpac and the fey script already do that?

No, fey has minpac.add calls to plugins in modules/*/*/packages.lua and root/packages.lua. FR3 means that fey shouldn't do that, but rather it should provide a method fey.add that wrap packadd minpac | call minpac#add(..). Another function I think is extremely important is fey.tap that return false if the package is not installed. Great for configuration part of the module: say I commented out a fey.add(X), and I have configuration for X, I could wrap it with if fey.tab(X) then vim.cmd'...'

FR 4 - autoloading modules is something I decided against when I started the project. I want it to be easy to disable and re-enable modules just by editing init.lua.

I think its a great idea to have control over what module "i.e. plugin/configuration set" should be loaded, but I don't agree with init.lua 'array of modules should be loaded' as the best implementation for "easy to disable and re-enable user modules".

Perhaps, a line in modules///config.lua should decide whether this configuration should be loaded. With this in place the user doesn't need to edit one file for this configuration set to be loaded. Still having an array of modules in init.lua is not a bad idea, and I think is enough for now.

Plus, I think that FEY should provide default modules so that a person can just use it and be done.

I've seen that you made condition that checks if the user has module/ defined and loads, and if not load default one, which I think it is a great idea. However, having the scope of fey changed to a framework, this isn't its job to do. Perhaps, it can be moved to skel/module as a configuration reference or restructured in example-module.md, or better in installation guide we can have something like this:

To get started with the default configuration and start migrating your vim config to lua: cp $HOME/.local/share/fey/skel/modules-ex $HOME/.config/nvim and you should have a string point. .... or something like that

FR1, and 5 - one can just copy a module they want to modify into ~/.config/fey and change whatever they want about it. The user-defined module will always be evaluated instead of the default module. As mentioned before, I think default modules are a good thing.

Previous comment offer better alternative.

[faerryn]

Hmm. I feel that one would do good writing their own config from scratch if we get too basic. The user should not have to care about ~/.config/nvim, only ~/.config/fey, so it is just 1 path to maintain. I think I'm aiming at a fatter project than you. Perhaps you'd be interested in creating a lean lua core (which FEY could use)? I'm not really aiming at a pure framework, more of a DOOM emacs things where it is easy to extend, modify, lean down, and organize.

I think that it may be a good idea to break this project into 2 components: one framework and one distro. The framework will be lean and mean and highly versatile, while the distro will be a full fat distro 😄

[kkharji]

Creating a framework isn't basic, as it will require a lot of thought to make it easy and fast to use. Speaking of doom and distro like project, as I made it clear, there are a lot of them out there, and fey wouldn't be any different, just another project clams to be the fastest, and provide better set of default that you as a vim beginner will have great experience in and can start editing stuff right away (I was one, and I used doom, thinkvim, spacevim ,... etc and endup leaving it).

Where as if fey is a framework then it can be targeted towards existing vim users, that considering using neovim, or configure there neovim in lua in at most simplest and efficient way, backed by a group of users who's using fey as a framework and as the core of there neovim configuration.

It can be broken down into two project, but more maintenance and complexity will result out of that. Hey if you really want develop a disto then go ahead, I believe you will do a great job, as I'm learning a lot from your code. And I'll try to create my own framework after solving and collecting useful functions.

[faerryn]

If you do end up with a cool and awesome framework, please send me a link! I would love to see what I can learn from it 👍

[kkharji]

If you do end up with a cool and awesome framework, please send me a link! I would love to see what I can learn from it +1

Sure thing, thanks