Would you be open to making this configurable? about vapournvim HOT 13 CLOSED

Thank you for the great PRs. They are quite helpful. And the modularization idea is great! I will definitely merge the PR.

from vapournvim.

Thank you for your note - really appreciate it.
Sure, It would be great to make a global variable to be able to set different preferences in a single file and make VapourNvim easier to use.

from vapournvim.

Cool. I'll create a new branch to introduce this with plugins, so we can discuss whether it's an appropriate route to go for you.

from vapournvim.

Hope you don't mind the various PRs heh.

Before I make this change, having gotten what I feel an MVP to you and it getting merged, I'm wondering about a small change to make it cleaner.

Have a ./lua/vapour folder that has an init.lua that defines the Vapour object, and then inside of that directory there's also utils, options, plugins, etc...

Then in the ./init.lua file we would do this (semi-pseudo):

require('vapour') -- This would also include vapour.utils since those really shouldn't be modified post-user config
require('vapour-user-config')
require('vapour.options')
require('vapour.plugins')
require('vapour.keymappings')

This would also move vapour-globals to vapour as well.

It would keep a clean namespace. Maybe plump up the module stack a bit but given how Lua works I don't think it'd be an issue.

Granted, I'm also a fan of modularization so doing things like this makes more sense to me, but if you're not on board with it then I don't want to waste your time.

But if you're on board with this I'll make a branch and PR it when done.

from vapournvim.

Cool, so I'll get started on that. :) This one might take me a bit longer.

What I'll do is make a PR for the structural changes first, then after that's merged I'll work on the config changes because I don't want to throw too much into PRs if I can help it.

from vapournvim.

After #11 is merged, I'll do the last part of this which is to make the stuff configurable.

from vapournvim.

There's 1 more piece to this I think that will be helpful right now and that's making the root key to which-key configurable (or allowing overriding).

I.e.: <leader>t is mapped to ToggleTerm, and I find that plugin useful but I run tests more than actual terminal work, so <leader>t for me would be more beneficial to map to run tests, while <leader>T would be acceptable for terminal.

But at the same point from what I can see the dev branch is mostly of my PRs unless you've done further work on it as well. Is it safe to merge that into master now?

from vapournvim.

I still get errors from treesitter plugins so I think I should replace autotag and rainbow with rainbow_parenthesis and vim-closetag otherwise it will just keep causing errors.

from vapournvim.

from vapournvim.

They are the same errors that you were facing with lazy loading.

from vapournvim.

I have fixed it. I just need to make a commit and then I will merge dev into master.

from vapournvim.

I don't get the errors after dd5bd3b. Now I will merge dev into main.

from vapournvim.

Cool. I'm going to consider this resolved myself and close it out. Because while there's still more work that can be done, it's gotten to a pretty stable state I'd say.

from vapournvim.