refactor(structure): structurize nvim config

[CharlesChiuGit]

Firstly, sorry about forgot to create a new branch.
I structured the config in my own sense, @ayamir @Jint-lzxy please let me know if I need to change anything!

[CharlesChiuGit]

Some files are being capitalized are due the module conflicting. Wellcome to suggest a better strategy!

[Jint-lzxy]

Will push some changes later 👍

[Jint-lzxy]

Some files are being capitalized are due the module conflicting. Wellcome to suggest a better strategy!

It doesn't matter (also this would have no effect on case-insensitive systems like macOS). We can ensure that the relative path is unique, and the user config is always in the first place 👍

[CharlesChiuGit]

But the lsp will show warning? Or it's safe to ignore?

[Jint-lzxy]

But the lsp will show warning? Or it's safe to ignore?

Because it assumes that the current directory is also part of rtp. But yes it would be safer to have a different file name 👍

[ayamir]

The new structure is ok 👍. In this way, users can setup configured plugins with their own config easily without modifying default config.

[Jint-lzxy]

IMO this structure would be cleaner and could avoid the warnings in #458 (comment).

lua/
└── modules/
    ├── plugins/ <-- Set `lazy.nvim`'s load dir to this **string** and it will automatically load all specs
    │   ├── completion.lua
    │   ├── editor.lua
    │   ├── lang.lua
    │   ├── tools.lua
    │   └── ui.lua
    ├── configs/
    │   ├── completion/
    │   ├── editor/
    │   ├── lang/
    │   ├── tools/
    │   └── ui/
    └── utils/
        ├── icons.lua
        └── init.lua

any ideas?

[CharlesChiuGit]

So the config files in configs/completion/, for example, would be the exact same name as the actual module name? Like configs/completion/cmp.lua would be auto-loaded by lazy.nvim for cmp?

[Jint-lzxy]

So the config files in configs/completion/, for example, would be the exact same name as the actual module name? Like configs/completion/cmp.lua would be auto-loaded by lazy.nvim?

Since we've required that file in the spec, then it would behave like lazy.nvim auto-loaded this config to memory.

[CharlesChiuGit]

If this would work, then I think it's indeed a more sensible structure than my original one.

[Jint-lzxy]

completion["hrsh7th/nvim-cmp"] = {
	event = "InsertEnter",
	config = require("modules.configs.completion.cmp"), <- This line loads the config
	dependencies = {
		.....
	}
}

As this file (plugins/completion.lua) would be automatically required by lazy.nvim then "it would behave like lazy.nvim auto-loaded this config to memory."

[ayamir]

IMO this structure would be cleaner and could avoid the warnings in #458 (comment).

Agree.

[CharlesChiuGit]

I'm still a bit confuse tho. If we still need to specify config = require("modules.configs.completion.cmp"), then what does "auto-loaded" means? Or did I misunderstand sth?

For me, "auto-loaded" means lazy.nvim would load the config files without specifying it.

[Jint-lzxy]

I'm still a bit confuse tho. If we still need to specify config = require("modules.configs.completion.cmp"), then what does "auto-loaded" means? Or I misunderstand sth?

Actually, this is not auto-load. It behaves like auto-load. "Auto-load" here means:

Some users may want to split their plugin specs in multiple files.
Instead of passing a spec table to setup(), you can use a Lua module.

The specs from the module and any top-level sub-modules will be
merged together in the final spec, so it is not needed to add require
calls in your main plugin file to the other files.

As "The specs from the module and any top-level sub-modules will be merged together in the final spec", this auto-merging process (i.e., requiring all files inside modules.plugins) would also require the requires inside each plugin spec (*.lua). Then, all configs would be auto-loaded to memory since we've required it's parent plugins/<spec-name>.lua.

Here we supply a string to the setup function, not a table:

require("lazy").setup("modules.plugins")

[Jint-lzxy]

Auto-load here means we don't need to fetch and merge all plugin specs before lazy.nvim (specifically all plugin.luas). It'll handle this for us. It's indeed rather winding :(

[CharlesChiuGit]

Aha, got it. So it's more like a "auto-merge", even if each completion.lua, editor.lua, etc, are not lua tables?

That would be great! When we were using packer.nvim, we need to merge the tables by ourselves. But now lazy.nvim will handle this for us, nice!

[Jint-lzxy]

Aha, got it. So it's more like a "auto-merge"?

That would be great! When we were using packer.nvim, we need to merge the tables by ourselves. But now lazy.nvim will handle this for us, nice!

Yup that's it ;)

[CharlesChiuGit]

For user specific plugins, I think it should be like this.

lua/
└── modules/
    ├── plugins/
    │   ├── user.lua <--- user plugins
    │   ├── completion.lua
    │   ├── editor.lua
    │   ├── lang.lua
    │   ├── tools.lua
    │   └── ui.lua
    ├── configs/
    │   ├── user/ <--- user plugins' config files
    │   ├── completion/
    │   ├── editor/
    │   ├── lang/
    │   ├── tools/
    │   └── ui/
    └── utils/
        ├── icons.lua
        └── init.lua

[CharlesChiuGit]

Also, one more question. I'm always curious about why we make extra wrapper functions when setting keymaps?
Isn't that build up the difficultly for users to modify their own keymaps and more error prone?

Why not just do sth like this?
https://github.com/CharlesChiuGit/nvimdots.lua/blob/main/lua/keymap/init.lua

I think it's more native to neovim?

[Jint-lzxy]

To be short, it allows users to set [mode|keybinding] on one side, and use lua's colon syntax to chain specials on the other side.

Long answer:

        ┌─ sep     ┌── map_type (saving a lot of keystrokes)
     ["n|gb"] = map_cr("BufferLinePick"):with_noremap():with_silent(),
       │  └── map_key          │              └── special1    │
       └──── map_mode          └── map_content                └── special2 (chained)

This should be more intuitive one you get used to this.

The special part is similar to:

std::ostream& operator<<(std::ostream& out, Obj& obj)
    ^^^                    ^^^^^ return value can be reused / chained output

If you use C++.

[ayamir]

Personally, I think https://github.com/ayamir/nvimdots/wiki/Plugins shouldn't use table as a display format, and there's not need to explain the effect of each plugin. ppl can just click on the links and read it's README.

Whether to remove the explanation of the effect or not is optional. The purpose I added it is explain the plugins' function briefly.

I think using indents to display the relations of the plugins would be better, like in #458 (comment).

Maybe this format is clearer? It's ok.

[ayamir]

We could consider adding after/ftplugin and after/syntax.

This change can be introduced in #459.

[Jint-lzxy]

@CharlesChiuGit I plan to put plugins.md directly to wiki. This way users can get all information in one place.

I think using indents to display the relations of the plugins would be better, like in #458 (comment).

We can adopt those changes using - **<plugin-name> (bold)**: <simple-description>

[ayamir]

We can adopt those changes using - (bold):

So maybe CONTRIBUTING.md and commit style check should be created?

[CharlesChiuGit]

So maybe CONTRIBUTING.md and commit style check should be created?

Could be helpful if there's new plugins coming in from PRs.
And yeah, right now we're just yolo our commit style haha.

[ayamir]

I will implement it in next pr if ok.

[Jint-lzxy]

https://github.com/ayamir/nvimdots/wiki/Usage. I rewrote the first two parts. Hope this can be easily understood @CharlesChiuGit @ayamir

[ayamir]

https://github.com/ayamir/nvimdots/wiki/Usage. I rewrote the first two parts. Hope this can be easily understood @CharlesChiuGit @ayamir

We can set user to custom if we use custom in the code.

[Jint-lzxy]

We can set user to custom if we use custom in the code.

Updated.

[Jint-lzxy]

@ayamir External sites like zhihu also need to be updated. See 36f331f

[ayamir]

Done

[Jint-lzxy]

@CharlesChiuGit IMO it is unnecessary to introduce two empty files. Users can customize them according to the wiki.

[CharlesChiuGit]

ok i'll revert.

[ayamir]

Can be merged once the new release note done.