user config support (or make it easy to update config without erasing anything) about nvchad HOT 81 CLOSED

I'd suggest having a centralized config file with a global var to take vals from, like so:

nvchad_globals.lua

local globs = {}


globs.indentation = 4
globs.statusline = "galaxyline"
globs.wrap_lines = false
globs.treesitter.ensure_installed = "all"
-- and the rest....

return globs

and then call them where and when needed:

some_config_file.lua

if (require("path.to.nvchad_globals")["statusline"] == "galaxyline") then
    require("galaxyline")
else
    print("NVChad: Unsupported statusline. Sorry...")
end

Furthermore, @ceylog , I personally don't think it's the best idea to have nvchad as your config and then pulling from the repo to "update it". For example: if in nvchad @siduck76 decides to set the indentation to 4 but you have it set to 2 in your local config then there will be a conflict. This is not a program but an awesome config, which means that the settings are relative to the users' needs.

A "workflow" that makes more sense is to fork the repo and set this repo as an "upstream" while you modify the config in your fork's main branch (or any other) and then when ground-breaking changes are done here (e.g. adding support for an LSP) you could fetch from upstream into a local branch and then cherry-pick what you need.

But again, that's my opinion...

from nvchad.

or we can go all out like spacevim 😆

from nvchad.

I have achieved this in my personal config. It's still a work in progress because yesterday I switched to NvChad for convenience, so not everything is within that file, yet...

from nvchad.

@G-Rowell thanks for your work! I'll think about adding global option after 1.0v release so keep it on hold for a while :v

from nvchad.

Commenting here too for reference ( same comment in pr 168 )

How about adding a custom.sample.lua to repo, not custom.lua

But, we will originally use custom.lua only. A check will be added if custom.lua is present for error handling

custom.sample.lua will contain all the configuration which are change able without breaking with core nvchad setup.

By all configuration, i mean vim options( enable dashboard or not ), mappings, etc

The sample custom config will contain the values which are set in nvchad by default.

So, even if user renames custom.sample.lua to custom.lua, should get default configs and then they can start messing with it .

from nvchad.

Commenting here too for reference ( sample comment in pr 168 )

How about adding a custom.sample.lua to repo, not custom.lua

But, we will originally use custom.lua only. A check will be added if custom.lua is present for error handling

custom.sample.lua will contain all the configuration which are change able without breaking with core nvchad setup.

By all configuration, i mean vim options( enable dashboard or not ), mappings, etc

The sample custom config will contain the values which are set in nvchad by default.

So, even if user renames custom.sample.lua to custom.lua, should get default configs and then they can start messing with it .

sounds cool! NvChad will be kinda initially complete after 1.0v so we'll add the custom.lua after it!

from nvchad.

Shouldn't this be closed.user config is implemented and we can update.pocco is working on something to update.but we can do updates now using git pull and nvim +Packersync

from nvchad.

Shouldn't this be closed.user config is implemented and we can update.pocco is working on something to update.but we can do updates now using git pull and nvim +Packersync

yes I'll close this when the update command is added to new docs ( site ) , Aki is working on a updater.lua so gotta wait

from nvchad.

@ceylog Im still learning neovim and lua so it'll take some time , For now just check every commit I make. adding changes manually wouldnt be that hard.

from nvchad.

That is what I was trying to say.

from nvchad.

I'd suggest having a centralized config file with a global var to take vals from, like so:

nvchad_globals.lua

local globs = {}


globs.indentation = 4
globs.statusline = "galaxyline"
globs.wrap_lines = false
globs.treesitter.ensure_installed = "all"
-- and the rest....

return globs

and then call them where and when needed:

some_config_file.lua

if (require("path.to.nvchad_globals")["statusline"] == "galaxyline") then
    require("galaxyline")
else
    print("NVChad: Unsupported statusline. Sorry...")
end

Furthermore, @ceylog , I personally don't think it's the best idea to have nvchad as your config and then pulling from the repo to "update it". For example: if in nvchad @siduck76 decides to set the indentation to 4 but you have it set to 2 in your local config then there will be a conflict. This is not a program but an awesome config, which means that the settings are relative to the users' needs.

A "workflow" that makes more sense is to fork the repo and set this repo as an "upstream" while you modify the config in your fork's main branch (or any other) and then when ground-breaking changes are done here (e.g. adding support for an LSP) you could fetch from upstream into a local branch and then cherry-pick what you need.

But again, that's my opinion...

this might make the config more complex and bloated , for now I think updating NvChad via commits would be right until it gets stable.

from nvchad.

I never wanted to have a global config.lua for nvchad , thought it added unneeded complexity and bloat but seeing your config gives me some hope :D

from nvchad.

what do you mean by custom configuration options.

from nvchad.

Whaddaya mean.
There is more than a dozen config files for customizing it and it's well organized.
You should probably edit those files rather than creating your own.
You have the option to source your config files if you created separate ones.

from nvchad.

Ok will work on that.

from nvchad.

@ceylog Im still learning neovim and lua so it'll take some time , For now just check every commit I make. adding changes manually wouldnt be that hard.

Great.😄

from nvchad.

I do understand @ceylog issue, I am running an older version of the repo that I modified to my liking. I noticed that packer transforms all .lua files into a folder/lua.lua which makes the usage of rsync impossible.

A potential solution, although not pretty, is separating all .lua files in the folder/lua.lua as it was a few months ago.

Of note, when I am creating a pr I fork the most up-to-date state of hte repo.

from nvchad.

@pocco81 that is a really great idea to make a branch and all. but I ain't the owner man.

from nvchad.

@pocco81 if you would like to add that checkout my fork here. And maybe create a Pull Request ;)

from nvchad.

Is this still an issue as @siduck76 made his statement

from nvchad.

@ashincoder yes , I'll think about this till next month. I'll see what I can do something while still letting NvChad bloat free and suckless.

from nvchad.

@ceylog I have made global config support in StarVim

from nvchad.

@pocco81 is this what you meant here StarVim

from nvchad.

Why isn't anyone replying to this issue. @siduck76 you can check StarVim here and see what I have implemented to setup a global config

from nvchad.

Why isn't anyone replying to this issue. @siduck76 you can check StarVim here and see what I have implemented to setup a global config

Cuz this thing feels complex :c

from nvchad.

idk if adding it will make the config bloated xd

from nvchad.

What do you mean by bloated 🤔

from nvchad.

bloated means overfill and extended.

from nvchad.

i saw starvim's config.lua , it looked too long so got scared

from nvchad.

Long does'nt mean scary does it. You just have read through all the things then you will understand. StarVim should get a star 😄

from nvchad.

Long does'nt mean scary does it. You just have read through all the things then you will understand. StarVim should get a star

if you showed an easy way for global config then I'd consider having it! config looks much cleaner without it tho ngl

from nvchad.

I don't think there is a easy way. You have to describe every option to global so that the user can change according to his taste.

from nvchad.

I don't think there is a easy way. You have to describe every option to global so that the user can change according to his taste.

what files are related to config.lua?

I think adding these 60~ lines could be nice , the rest lang stuff isnt needed

https://github.com/ashincoder/StarVim/blob/dev/lua/config.lua#L60

from nvchad.

They are for changing the formatter. I will remove the linter cause they don't do anythin as I have tested

from nvchad.

They are for changing the formatter. I will remove the linter cause they don't do anythin as I have tested

ohh so the global config is only config.lua? i thought we need to define more stuff in other files

from nvchad.

For the user config sv-config.lua file is there

from nvchad.

I have achieved this in my personal config. It's still a work in progress because yesterday I switched to NvChad for convenience, so not everything is within that file, yet...

Ohhh, That's a good idea

from nvchad.

I have achieved this in my personal config. It's still a work in progress because yesterday I switched to NvChad for convenience, so not everything is within that file, yet...

dang thats a lot :l

from nvchad.

I mean, you don't need to have all of that. I personally like to have my stuff centralized, but if you wanted to you could just have a centralized config for autocommands, highlights, mappings and abbreviations, which are things most users would like to configure themselves. In here and here you'll find the modules that do that in my config.

from nvchad.

dang thats a lot :l

It's the same as what you'd normally have in nvchad, but in just one place, for convenience :]

from nvchad.

centralizing highlights would be a huge pain , NvChad already has such stuff in highlights.lua .

from nvchad.

@siduck76 Theming in general is a pain in nvchad, first all it should be imported as a colorscheme that neovim recognises.

from nvchad.

I also agree there should be a separate file for user configs. It makes easier to update NvChad for those who fork it. If changes are made to the other config files there are conflicts during updates. It's not that manually updating from the commits is a lot of work but I guess it would just be more convenient to have something like that.

from nvchad.

@siduck76 Theming in general is a pain in nvchad, first all it should be imported as a colorscheme that neovim recognises.

I have thought about it but won't implement it , also nvchad already has 4 chad themes. Tools a lot of time to make em . Since their original themes don't look that good I had to change many colors for syntax highlighting and 26~ colors for rest of the highlights. If I added the highlight stuff in theme base16 theme plugin itself then it gets hard for the user to write his own highlights so better add the user highlights and those user highlights shall get commented in the theme plugin like vertsplit highlight etc so stuff won't highlight twice.

from nvchad.

@siduck76 Theming in general is a pain in nvchad, first all it should be imported as a colorscheme that neovim recognises.

I have thought about it but won't implement it , also nvchad already has 4 chad themes. Tools a lot of time to make em . Since their original themes don't look that good I had to change many colors for syntax highlighting and 26~ colors for rest of the highlights. If I added the highlight stuff in theme base16 theme plugin itself then it gets hard for the user to write his own highlights so better add the user highlights and those user highlights shall get commented in the theme plugin like vertsplit highlight etc so stuff won't highlight twice.

I don't understand, how are these reasons relavant to making a colorscheme recognised by nvim ? 🤔

from nvchad.

Doesn't nvim recognize base16 plugin?

from nvchad.

Doesn't nvim recognize base16 plugin?

Try :Telescope colorscheme

That's what i was talking about

from nvchad.

Doesn't nvim recognize base16 plugin?

Try :Telescope colorscheme

That's what i was talking about

Ohh that stuff , why not make the theme switcher with telescope? Like letting it execute certain stuffs for changing nvchad bsse16 and nvchad global theme

from nvchad.

Doesn't nvim recognize base16 plugin?

Try :Telescope colorscheme
That's what i was talking about

Ohh that stuff , why not make the theme switcher with telescope? Like letting it execute certain stuffs for changing nvchad bsse16 and nvchad global theme

Ohh, you mean a custom implementation which will show just our themes

from nvchad.

Will that be that easy. You may have to write a function to implement it

from nvchad.

Will that be that easy. You may have to write a function to implement it

PR's are welcome :D

from nvchad.

Im noob with telescope so it'd be hard for me at the moment xd

from nvchad.

also the telescope window should have all 4 nvchad themes

selecting a theme and pressing enter on it should execute :

• change vim.g.nvchad_theme first
• require the highlights.lua file

from nvchad.

also the telescope window should have all 4 nvchad themes

selecting a theme and pressing enter on it should execute :

• change vim.g.nvchad_theme first
• require the highlights.lua file

requiring the highlights won't be enough, you have to reload bufferline and statusline before too

from nvchad.

also the telescope window should have all 4 nvchad themes
selecting a theme and pressing enter on it should execute :

• change vim.g.nvchad_theme first
• require the highlights.lua file

requiring the highlights won't be enough, you have to reload bufferline and statusline before too

oh shit yes and even webdevicons too

from nvchad.

also the telescope window should have all 4 nvchad themes
selecting a theme and pressing enter on it should execute :

• change vim.g.nvchad_theme first
• require the highlights.lua file

requiring the highlights won't be enough, you have to reload bufferline and statusline before too

oh shit yes and even webdevicons too

or source $MYVIMRC

probably will work

from nvchad.

I mean,
a fair few neovim & plugin settings can be overwritten by a user config file?

Eg:
Normal NvChad setup & config structure
THE LAST thing that is done is source custom.lua (require custom.setup())
custom.lua is an NvChad provided file in which config is overridden to the users preferred

Eg:
NvChad sets tabs to 4 spaces,
NvChad sources the custom.lua - setup(),
custom.lua - setup() sets tabs to 2 spaces

from nvchad.

I don't know if this approach is perfect, but it could well work,
as it keeps all the NvChad settings,

and the user only has in their config file their preferences (only have to include specific settings they want to change?)

from nvchad.

Very easy to implement:
make custom.lua, give it the boilerplate lua format & some comments,
add custom.lua to .gitignore,
add the call to custom.lua - config() in init.lua
commit.

Means that this custom.lua stays in the repo, but the gitignore means it's touched by git when contributors work on pull requests? (so keeps users in NvChad, while keeping their own configs)

from nvchad.

Implemented a working prototype:

#168

Hopefully I'm not being too naive with this?
This also doesn't extend towards custom colour configs, not sure how that would interact with my PR

from nvchad.

Could also have a branch to test this functionality,
so that it can plug right into 1.0v?

It could be a way to ease some load off of @siduck76, have two people be responsible for the branch/custom config,
then before merge to main have siduck check off?

Dunno, either way I'm chill

from nvchad.

Could also have a branch to test this functionality,
so that it can plug right into 1.0v?

It could be a way to ease some load off of @siduck76, have two people be responsible for the branch/custom config,
then before merge to main have siduck check off?

Dunno, either way I'm chill

yeah sounds good! Im going to release 1.0v at this month's ending so gotta wait! you can create a theme switcher in the meantime , next month I'll add a a different branch for the global config stuff :)

from nvchad.

So who are you going to assign that branch to

from nvchad.

Next month :0 ! I mean @G-Rowell idea was goood :)

from nvchad.

Next month :0 ! I mean @G-Rowell idea was goood :)

Freaking zoomers with no patience 😝

from nvchad.

Next month :0 ! I mean @G-Rowell idea was goood :)

yeah I have college these days so such huge changes like global config would need some tinkering! so next month lul .

from nvchad.

So who are you going to assign that branch to

Didnt think about assigning for now , anyone can add PR for global config in that different branch

from nvchad.

@Akianonymus join the gitter community master!

from nvchad.

@Akianonymus join the gitter community master!

Ooh, we have gitter community, will join

( just saw in readme )

from nvchad.

There's an issue with vim.g.theme being recognized in icons.lua ...
It works in highlights.lua , but returns nil in icons.lua .. a very odd behavior :/

from nvchad.

There's an issue with vim.g.theme being recognized in icons.lua ...
It works in highlights.lua , but returns nil in icons.lua .. a very odd behavior :/

Use latest nvchad

from nvchad.

So I've achieved full config capacity from one single file and also better modularization (structured like one unix systems boot), better lsp conf, better utils, etc... but that is not relevant to this issue in my personal fork. Take a look:

Unfortunately my personal fork is very very different from nvchad, and because of that I can't PR this. I'm just posting this here in case somebody wanted to kind of know how a system structured like such would work. And also, @siduck76, in case you were wondering, it doesn't affect my startup time:

from nvchad.

I think we can soon implement this after 1.0v or before 1.0 itself xD.

but one thing Im sure , I wont add highlights and theme color tables in the global config at all!

from nvchad.

also stuffs like this wont be added :

since they're not present in nvchad's config itself xD. would be nice not to add each and every nvim's default options

from nvchad.

As I said, this is my personal config so that's why I have so many settings and stuff (which (if I'm not wrong) are not the defaults).

Also, there are some things like, for instance, autocommands that depend on plugins that should not be in the main config file but in the plugins' conf (for obvious reasons)

With that said, I'd be more than happy to help in the development of this feature :)

from nvchad.

As I said, this is my personal config so that's why I have so many settings and stuff (which (if I'm not wrong) are not the defaults).

Also, there are some things like, for instance, autocommands that depend on plugins that should not be in the main config file but in the plugins' conf (for obvious reasons)

With that said, I'd be more than happy to help in the development of this feature :)

yeah cool :)

from nvchad.

@ceylog 0efa21c

from nvchad.

@siduck76 do u think on adding orgmode.nvim

from nvchad.

@siduck76 do u think on adding orgmode.nvim

yes in 2.0v

from nvchad.

ok

from nvchad.

https://nvchad.netlify.app/docs/getting%20started/setup/#update

from nvchad.