Everyone!! suggestion required for removal of custom dir

[siduck]

Hi guys stance on removing the custom dir and the userconfig stuff? I know this might be a huge breaking change but nvchad was initially designed to be used as a base config only and a base config must be clean+easy to understand i.e shouldnt require docs to explain such basic stuffs.

I know updating nvchad might get hard as the user would have to fork nvchad and then copy paste from git commits or just resolve the conflicts! But nvchad would soon get stable after v2.0, so it'd get easy to update once a week or so and we would consider adding chad userconfigs i.e modified base nvchad config for "x" language development such as a ready to use configs for python , c++ , web development etc and these configs would be mentioned on the main website ( maintainers of such configs must keep their configs uptodate with base nvchad config )

We were supposed to use the defaults of all the plugins but we failed to keep the installing method of plugins easy as we have our own way to define plugins which isnt a good thing, we were supposed to stick with the packer's method and this might create great confusion among newbies. NvChad was supposed to remain a simple config with a bunch of useful functions as utilities such as theme switcher, terminal toggler etc.

In my opinion, removing the custom dir and adhering to the standard nvim configuration techniques would be better. This way users would be able learn nvim configuration stuff on their own as well.

• React with :+1: -> remove custom config
• React with :-1: -> keep custom config

I'll check the results after May 2

Anyways this is how the custom-less config looks (WIP)

https://github.com/NvChad/NvChad/tree/customless

EDIT : CUSTOM CONFIG WILL NOT BE REMOVED. Dont worry!

[xarthurx]

Agree. Also make it easier to transfer the user settings in/out of nvChad.

[johnsiras]

I'm sticking to the old one 😅.

[AstroShen]

agree to adhere to nvim config style!

[siduck]

I'm sticking to the old one sweat_smile.

it brings un-necessary complexity and many users come up with their preferences such as we only had cmp lazy loaded by default but some faced issues with nvim-cmp-lsp then we had to add an option to unlazyload cmp , there were users who didnt like cmp and wanted to use coq.nvim so we added another option to disable cmp .. bruh this just adds a lil bloat to the config and makes it more complex imo ;(

[tomasky]

I think it's just ok now !

[zbirenbaum]

I used NvChad in the old days and maintained my own fork, but merge conflicts are an unholy pain.

While I like the idea of adding user configs, and would be happy to include some of my numerous ones (like the one I wrote dimming unused functions because I thought it was cool, but the existing plugin was slow and poorly optimized) I think that allowing users to edit outside of custom is going to cause a lot of Issue posts on merge conflicts and on things breaking that users believe is on our end, but actually was caused by them. In fact, I'm pretty sure I remember that being an issue in the old days, which is why custom was created.

I'm sticking to the old one sweat_smile.

it brings un-necessary complexity and many users come up with their preferences such as we only had cmp lazy loaded by default but some faced issues with nvim-cmp-lsp then we had to add an option to unlazyload cmp , there were users who didnt like cmp and wanted to use coq.nvim so we added another option to disable cmp .. bruh this just adds a lil bloat to the config and makes it more complex imo ;(

I think that was the whole reason we changed the plugin loading process though. Behind the scenes, we do things exactly how packer expects it. It's not possible to provide a solutions for everyone, and trying gives bloat. The current implementation lets users that want more control disable whatever they want and override as they please. Just for fun I have every NvChad base plugin overridden in my user plugin table or removed in chadrc if I don't use it.

I think the current method of setting a bunch of defaults, but making all of them changeable from chadrc is smart, and in comparison to some of the other large neovim base configs, we stay very much on the lightweight side of 'bloat'

Take a look at spacevim's code base if you don't believe me https://github.com/SpaceVim/SpaceVim

I think the real issue that is being pointed out here, is that sometimes we are a little too quick to implement things that users want as part of the base, rather than telling them "do it yourself"

[siduck]

Yes we do the how packer expects but it'd get confusing for newbies. And yes the current userconfig stuff might be lightweight bloat as compared to that from other neovim distributions but nvchad initially was never meant to be a "framework" like lunarvim etc, it was just a base config.

Removing the userconfig stuff would remove lots of complexity layers and confusion imo, it would be great to have the standard way of defining neovim config I think

another victim of the userconfig https://github.com/NvChad/NvChad/issues/923 :worried:

[divan]

I'm trying to use NvChad for the second time now, and keep struggling with basic things like "override some plugin's hotkey" or "set up new plugin".

Here are my main pain points.

1. Changing hotkeys for existing plugins:

For example, I want to change Telescope's find_files hotkey. Ideally I would just go to my nvim/nchad config file and just type "new hotkey" – find_files_function (preconfigured by nvchad's config). Instead now I need to learn the whole nvchad's config structure, open few .lua files just to make sense out of it. (Plus, as I'm not a lua developer, I don't have Lua lsp configured and navigating lua code is hard).

First, I was modyfing nvchad non-custom/ code – it was just a fastes way to make it work. After update (and git reset) I had to find another way to change hotkey, and I copy-pasted code from NvChad docs. It didn't work. I spent half an hour looking for a ways to see logs or understand how to validate config, no luck. After few more hours of experiments I made hotkey working.

2. Finding the hotkey for the action

ANvChad uses its own set of predefined hotkeys. I'm find with it and want to learn them. For example, I forgot what is the key for lsp references. I know about cheatsheet, but I don't understand how it works, where doesn't get keys, and if they even correct, plus it's hard to navigate. It's much easier just to open nvim config and check. Now, when I find the relevant keymap mapping in the config it looks like this:

map("n", plugin_maps.references, "<cmd>lua vim.lsp.buf.references()<CR>")

No clue what's the plugin_maps.references is. Now I need to hunt down the config where it is defined. (It sounds easy when you intimately knows the config and have Lua lsp configured, but for newbie who just tries to configure it in the first time, it's a challenge).

3. Configuring new plugins

Another typical action is to add a new plugin, configure it and define keys. Again, it starts with a quesiton "how the hell do I do it". You have to read docs, and learn that you have manually create some custom/ folders and files, and populate them with example config. Slighest mistake there is not reported, so you just editing custom configs, restarting nvim and checking if it even works. It takes hours. Another cognitive challenge is to constantly convert plugins configuration / keymapping code from plugins's README's to the nvchad custom/. confug. Given there is multiple ways to do the same thing it's becoming even more challenging.

Like currently I'm struggling to configure Telescope find_files to use working directory of the project (or initial dir when nvim was opened) instead of cwd, of the files. I google some lua function example, but I have no idea how use with core.utils map() function, which expects the vim command string as a parameter and not lua function.

So basically every action becomes a hour(s) long challenge and this is frustrating.

So, yes, I thing getting rid of custom/ folder makes total sense. Current NvChad config is great for people who has intimate knowleged of it's structure and well-versed with Lua and nvim config. But for users it would be great to have just a set of easily-overridable defaults, and, allowing to use own nvim config. NvChad was an eye-opener for me how good current nvim development ecosystem is, and I appreciate your work a lot.

[zbirenbaum]

@divan I have a couple of things I'd like to point out about your post

1. Changing hotkeys for existing plugins:

If you know the function you need to call, all you have to do is map the new hotkey. If its already a different hotkey, that hotkey will be overridden when you map it. By the same token, if you want to use an NvChad hotkey for something else, you remap it to that thing. Technically, there is a vim.api.nvim_del_keymap, but I've never actually seen it used since most people operate under the idea that there's no "hotkey removal" in neovim, it's removed when you remap it.

2. Finding the hotkey for the action

First: On finding what something is, grep -rnw . -e "some search term" will search every file in every subdirectory for said string and tell you where all it can be found. Telescope also has similar functionality I believe. I also believe there is a 'cheatsheet' plugin that can tell you, but I'm not sure how it works as I don't use it. If you want to change that mapping, you can just set it to something else in chadrc

Second: The map function is awful, I agree, but all it does is allow the omission of an opts argument from the vim.api.nvim_set_keymap function. Everyone agrees having to use a vim command string for setting a keymap is awful, you aren't alone, but nvim_set_keymap requires it. If you would like to use a lua function, you can, but need to be on nightly instead of .6, which is why it is not used here, many people including @siduck use .6. If you have .7 you can do something like this:

local opts = { noremap = true, silent = true }
vim.keymap.set('n', '<C-n>', function () require("dap").step_into() end, opts)

google some lua function example, but I have no idea how use with core.utils map()

You don't have to use core.utils.map, that's just a function that keeps the code cleaner by omitting some args that are always passed to nvim_set_keymap

As for your third point, configuring new plugins is as easy or difficult as it would be without NvChad. If you have some specific trouble, I am happy to try and help you out, but the thing you said about mappings really has me confused here.

Lua scripting has a learning curve for sure, and I'm sorry to hear you have had such a rough go so far, but to be honest most of the stuff here seems like you misunderstood and thought that NvChad functions have to be used to work properly, when they actually don't or are things that you would struggle with even without NvChad.

If you are mostly interested in code snippets and seeing how to do certain complex tasks, take a look at my config and let me know what questions you have, I am happy to explain.

https://github.com/zbirenbaum/NvCustom

[zbirenbaum]

Yes we do the how packer expects but it'd get confusing for newbies. And yes the current userconfig stuff might be lightweight bloat as compared to that from other neovim distributions but nvchad initially was never meant to be a "framework" like lunarvim etc, it was just a base config.

Removing the userconfig stuff would remove lots of complexity layers and confusion imo, it would be great to have the standard way of defining neovim config I think

another victim of the userconfig #923 worried

I think once we get NvChad into a "maintenance" state this is valid, but as long as we are updating fairly regularly the pains of trying to merge in changes will far outweigh the benefits.

I would also wait for the .7 stable release which should happen within a few months, as it adds many, many features which dramatically simplify many things. I've already refactored much of the code, including the theme repository, to use the new apis and am willing to work on the rest once that drops. If we can get to a 'good' state to maintain by then, once .7 drops I would be good with cleaning out all the user config stuff while refactoring.

[siduck]

Yes we do the how packer expects but it'd get confusing for newbies. And yes the current userconfig stuff might be lightweight bloat as compared to that from other neovim distributions but nvchad initially was never meant to be a "framework" like lunarvim etc, it was just a base config. Removing the userconfig stuff would remove lots of complexity layers and confusion imo, it would be great to have the standard way of defining neovim config I think another victim of the userconfig #923 worried

I think once we get NvChad into a "maintenance" state this is valid, but as long as we are updating fairly regularly the pains of trying to merge in changes will far outweigh the benefits.

I would also wait for the .7 stable release which should happen within a few months, as it adds many, many features which dramatically simplify many things. I've already refactored much of the code, including the theme repository, to use the new apis and am willing to work on the rest once that drops. If we can get to a 'good' state to maintain by then, once .7 drops I would be good with cleaning out all the user config stuff while refactoring.

few months? i thought it was in april :worried:

[divan]

@zbirenbaum thank you for such an elaborate answer.

Re: grepping – what I meant is that with "normal" configuration (be it lua or vimrc) you really can use grep to quickly find what the key. I.e. you grep over "nowrap" and see the line like "nmap W :set wrap!". That gets you quckly to the answer. Grepping NvChad config doesn't give you an answer, it'll lead to something like: 'map("n", maps.misc.toggle_wrap, ":set wrap! ")' and doesn't answer you question until you figure out where the heck 'toggle_wrap' is defined. Again, this config design looks nice when you have initimate knowledge of it and work on the structure day and night, but for the new user who just wants to learn the hotkeys – it's a pain.

Thank you for providing your custom configs, I'll take a look at that. But the more I get to learn nvim and lua configuration, the more I question why I need NvChad? Initially I thought it's a solution for simplifying burden with nvim configuration and sensible defaults, but now it's clear that in order to configure even simple stuff (again, like changing hotkeys) I need to learn nvim/lua anyway, plus NvChad configuration system/logic on top of it.

Also re: mapping – this is a general rant for many languages/frameworks – it seems like there are many ways to achieve the same in lua/nvim. Obviously, it's easy to justify the reasons of each method, but generally it creates a cognitive overload for anyone who's learning. As NvChad introduces it's own config structure/logic – it would be cool to defined one "right" way to do things – like defining hotkeys, or configuring plugins. That's, actually, the reason why I used core.utils' 'map' function – I thought it's the preferred way to map.

Anyway, great jobs guys!

[siduck]

@divan

so basically this table in default_config

so within that table, there's a lspconfig table

[zbirenbaum]

few months? i thought it was in april :worried:

I'm pretty sure you are right. I thought it was soon but didn't know the date of the top of my head and didn't want to give false ideas

[zbirenbaum]

@zbirenbaum thank you for such an elaborate answer.

Re: grepping – what I meant is that with "normal" configuration (be it lua or vimrc) you really can use grep to quickly find what the key. I.e. you grep over "nowrap" and see the line like "nmap W :set wrap!". That gets you quckly to the answer. Grepping NvChad config doesn't give you an answer, it'll lead to something like: 'map("n", maps.misc.toggle_wrap, ":set wrap! ")' and doesn't answer you question until you figure out where the heck 'toggle_wrap' is defined. Again, this config design looks nice when you have initimate knowledge of it and work on the structure day and night, but for the new user who just wants to learn the hotkeys – it's a pain.

Thank you for providing your custom configs, I'll take a look at that. But the more I get to learn nvim and lua configuration, the more I question why I need NvChad? Initially I thought it's a solution for simplifying burden with nvim configuration and sensible defaults, but now it's clear that in order to configure even simple stuff (again, like changing hotkeys) I need to learn nvim/lua anyway, plus NvChad configuration system/logic on top of it.

Also re: mapping – this is a general rant for many languages/frameworks – it seems like there are many ways to achieve the same in lua/nvim. Obviously, it's easy to justify the reasons of each method, but generally it creates a cognitive overload for anyone who's learning. As NvChad introduces it's own config structure/logic – it would be cool to defined one "right" way to do things – like defining hotkeys, or configuring plugins. That's, actually, the reason why I used core.utils' 'map' function – I thought it's the preferred way to map.

Anyway, great jobs guys!

I definitely understand your sentiment. The idea of NvChad is to give people something to work off of. Even a decent lua programmer might struggle to write a 300 line statusline config or find it frustrating, especially if they don't know the api calls for certain things.

While personally I could implement many of the plugins I use from scratch, I don't because it's just not a good use of my time. Ones that I see potential for notable improvement in I occasionally will, but it's just not worth it most of the time.

By the same token, learning lua isn't necessarily sufficient to write a good neovim config. The neovim api is long, and getting to a comfortable point with the more "backend" parts of it, the pieces only touched by plugin devs or extremely complex configs requires many, many hours of reading documentation. For the more low level parts even the documentation isn't sufficient at times and I have to go into the source to figure things out.

NvChad provides those hooks, so that even if you don't like the defaults, you can copy them and edit them slightly, or just use the general idea. Many people just want a functional editor without 20-40 hours of reading documentation and coding who are also served well by the system of allowing for certain aspects of NvChad to be editable.

I would like to emphasize, this is probably the most important part of this post: The time it takes to learn how to do something like set a keymap or track down a variable is minuscule compared to the time it takes to learn how to properly lazy load, hook into the lsp, control windows and buffers from scripts, configure sources for completions, etc, and then debug it all. You may spend an hour on trying to get some random thing working, but you would spend 10s of hours trying to get everything working. Even if you copy and pasted code, from plugin pages, those are mostly quick guides, and often people end up with multi hundred or thousand line init.lua because they don't know how to properly modularize that code.

If you want to tear out the pieces you like from the plugin configs and write the rest yourself, please do, in fact as a programmer I would encourage that approach. Just know, that when the APIs change, things become deprecated, and your whole config was copied and pasted, it's not going to be fun to debug. We do that for you with NvChad.

While I can sympathize with your sentiment of wanting a "correct" way of doing things, the truth of the matter is that there rarely is one in any programming, and definitely not for a project like neovim where the "best" way to do something changes almost every update as more features are added and more vimscript removed.

There's a thousand ways to implement the same algorithms, the right way optimizing for space isn't necessarily the right way when optimizing for time.

We try to optimize for our users time. We know you could have a more concise config if you knew exactly what you want and how to write it, but when you have an idea for a new feature you may not know where to start.

With all that said, I do think that your criticism of the key maps is very valid, and I have my own contentions with that particular piece of our code as well. When .7 officially drops I'll be doing a full pass to convert everything to the new keymap api, and I'll take your thoughts into account while doing it.

@divan sorry for the essay but this is something that I'm sure a lot of people have wondered, and I think it's good to have the whole explanation out in writing. Even I have thought a lot about why I use NvChad.

Nowadays I use NvChad just because I like working on the project and I think it helps newcomers out. Starting out though, exploring the code base was instrumental in learning how to write good configs. My original ones were disorganized copy and pasted code. Now I could write the whole thing from scratch if I needed to, and intelligently organize it to avoid repetition. A lot of that is thanks to having a solid set of examples to work with and mess around with when I had the time over the course of quite a while. My hope is, that it serves a similar purpose for other people and helps them be productive and learn to love neovim as much as I do while doing so.

Finally, while I shared a similar sentiment starting out, and I resented that I had to learn a 'useless' language like lua which I thought of as pointless and just for implementing games, I have come to love it. I actually enjoy working in lua now, it's fast, it's flexible, it's taught me to think of functions entirely differently, and my code quality has improved in other languages too as a result. There's an elegance to doing everything in tables, and the emphasis on treating functions as first class values is a great feature. Many languages like Python have that ability, but outside of exceptions like maybe lisp, few go out of their way to advertise that you can do so, let alone encourage it.

[siduck]

oldest nvchad config :laughing:

[zbirenbaum]

oldest nvchad config :laughing:

775 line init.vim, thanks for proving my point about long copy pasted init files 😂.

Brings back memories though, I'm pretty sure I recognize more than a few snippets.

Thanks for the nostalgia @siduck made me smile

[johnsiras]

When will v2.0 release?

[siduck]

When will v2.0 release?

first the current issues must get -> 0 and after 0.7v release

[Doomwhite]

Oh God, just when I thought I had found an intelligible nv config, everything is gonna change.

[danipozo]

As a recent NvChad user, I can say I am very happy with the current state of things and I agree with this comment.

[siduck]

Oh God, just when I thought I had found an intelligible nv config, everything is gonna change.

one last breaking change!

[marvelman3284]

Personally I will most likely be sticking with the old version

[Animeshz]

I was symlinking ~/.config/nvchad to ~/.config/nvim/lua/custom it was synced easily and worked nice!

The installation process I too think is a bit complicated so would be nice if can be simplified down, but creating patches/diffs and applying that is an unnecessary burden than just tapping rsync/git.

[Animeshz]

Also my last penny: patches, if are un-centralized will one day or other break / produce a conflict, and forcing them to maintain isn't a good thing. Not good thing for new git user either (and pulling updates to nvchad after patch applied can mess up too).

A better approach if I can give just derives from UnixPhilosophy i.e. Store data in flat text files. Just let it be inherited by userland, if sth breaks it might need 3-4 lines to be changed and notified and not a large email to the maintainer to push updates to his diff/patch.

[bjesus]

The "custom" settings are the thing I like the most about NvChad... I wanted a sensible default that I can make slight adjustments to. If I'll need to manage conflicts with every update now - that's a lot of work. The two reasons given: (a) adhering to the standard nvim configuration techniques, and (b) users would be able learn nvim configuration stuff on their own - they don't speak to me and users like me. We're using NvChad because it works and because we don't want to learn about nvim configuration stuff.

Perhaps we're a minority - but I suspect that users like me are simply less active in the project precisely because they don't know anything about nvim configuration. We're using and loving NvChad because it solved the problem of needing to learn how to configure nvim, and so we're mostly using it quietly and we don't end up voting in these kind of polls...

[justin-f-perez]

It's a little speculative but @bjesus hints at a good point that I agree with and hope the maintainers of NvChad will keep in mind while weighing the 👍 and 👎 : folks who are actively involved with/contributing to NvChad are more likely to 👍 because they have the experience and familiarity with neovim to contribute to a project like this one. Newbs face a higher barrier to entry.

nvchad was initially designed to be used as a base config only

I think it's a good goal to not add new abstractions where not necessary- but I might also suggest "don't get too weighed down by the intent of past design decisions." It's OK for projects to evolve.

we failed to keep the installing method of plugins easy

I think I disagree but I'm unsure whether this part was referring to customizing the base plugins provided by NvChad or if it refers to adding new plugins. If this is referring to installing new (not provided by NvChad) plugins, I disagree 100%. AFAIK the only difference between adding a new plugin via nvchad vs. vanilla neovim is a little boilerplate and omission of use, otherwise they seem to be structurally/syntactically identical...

users would be able learn nvim configuration stuff on their own as well

I think they already do, and this proposal will have the opposite effect...

I had 0 understanding of lua a few months ago, decided to give nvchad a try, and had to poke around in e.g. core/default_config to figure out what was goin on. It was a little frustrating- but it would have been extremely frustrating to debug my own fork. I'm still a lua noob but I do know a little now; I'm still a neovim config noob, but I know a little of that too. NvChad provided a critical stepping stone for both. I think removing the user config stuff will just make it impossible for noobs to debug modifications or resolve merge conflicts, so they'll just stick to the base config and ultimately won't learn any nvim configuration stuff.

On a related note, @divan makes an excellent point about debug-ability of NvChad custom config- when you f*ck it up, it often just fails silently. In fact, the only reason I happened to notice this particular issue to start writing this comment is because I was debugging why my custom config wasn't working after updating. It turns out nvchad blindly suppresses errors while loading custom.chadrc. New users will have an easier time learning neovim configuration if their mistakes aren't hidden from them (although I suspect this was an oversight and not intentional.)

[zbirenbaum]

For the record, I agree with virtually everything @justin-f-perez said above. In addition, I think a lot of people believe that they want no custom dir and to hack things themselves, but I really doubt most of our users have experience with projects like st or dwm which have a virtually identical process to what is proposed.

Once we start having to release bug fixes in the main repo or make changes to account for deprecation, users are going to start getting merge conflicts and all sorts of confusion during rebasing.

That said, this doesn't really affect me, but if I'm being honest, I have heavy doubts regarding most of the people who gave a :+1: to this post actually liking the results. Ideas can sound good on paper to people, but if they wanted to spend tons of time fixing merge conflicts and maintaining things in the face of breaking changes, I don't see why they need a base to work with at all, they could just copy the configs from nvchad and leave out the rest.

@siduck I know you use st and dwm, and I have too, but how easy was is to get multiple patches working together when you were first getting started? I would encourage everyone who upvoted this post to go to https://st.suckless.org/ and get a basic term running with 4 or so patches. I'll even list some for you:

1. boxdraw
2. clipboard
3. xresources
4. ligatures (Careful! applying ligatures and boxdraw requires a different patch 😄 And I hope you didn't want scrollback or alpha because thats a different patch and its not included in the ligatures+boxdraw one, get ready to write some compatibility fixes in C!)

Now that you've spent an hour or 3 doing that, take a bit to think about whether you really want to experience that every time you want to change some NvChad settings, and deal with the conflicts you likely had to above whenever setting up two vaguely related plugins or features that happen to both change mappings or something.

Now take another moment to realize that those patches likely won't be officially supported, nor will they necessarily be written by maintainers like @siduck and myself, so assistance with them will be:

• A. primarily from whoever you obtained the patch from
• B. far more time consuming and difficult for anyone else to provide, so for some issues you may be entirely on your own.

While I said at the start I mostly agreed with @justin-f-perez, there's one point I strongly disagree with, and I think it's probably the opposite of what he believes:

It's a little speculative but @bjesus hints at a good point that I agree with and hope the maintainers of NvChad will keep in mind while weighing the +1 and -1 : folks who are actively involved with/contributing to NvChad are more likely to -1 because they have the experience and familiarity with neovim to contribute to a project like this one.

I think anyone with a decent amount of experience with lua or nvchad isn't going to be affected by this much. Even if the codebase changes, most people actively involved or capable of writing their own configurations from scratch will naturally be able to map it out again pretty quickly, and I would really, really hope our contributors would put their perception of the average user's needs above the hour or two of their time it would take to get to know a heavily modified codebase.

In fact, I think the more advanced users are likely the ones upvoting this. They are the ones who can deal with the issues talked about above in this post and this entire thread. Furthermore, the truly average user isn't sitting on github looking over the issues and voting on this. Their config works, they don't do anything to break it, so they have no reason to. Notice that despite NvChad having 8.5k stars (Not all users star, and not all stars are users, but I would bet there's more of the former than the latter) there are only ~43 votes on this poll at the time of me posting this.

[justin-f-perez]

oops! @zbirenbaum you're absolutely right- I got my 👍 and 👎 mixed up. I too believe power users are least likely to be affected, and most in favor of getting rid of user config stuff. Sorry for the confusion; I'll edit that post to fix it

PS: I wonder if any thumbs on the OP are accidents in the wrong direction too... ~maybe for future polls~ ~💾 for "keep feature"~ ~⛔ for "delete feature"~ ~Just a little easier to keep straight semantically (thumbs up just means "approval", but after scrolling away from the OP it's easy to forget if it's "approval of the feature being cut" or "approval of the feature itself")~ EDIT: nvm i think github limits you to 👍👎😄🎉😕❤️🚀👀

@siduck There's a private beta for "Discussions Polls"... it already filled up but

Sorry, we reached capacity for the private beta. However, 👀 we'll be launching more broadly very soon👀 , so stay tuned!

~... but maybe "launching more broadly" meant "at the organization level"...~

~> Limited to the first 5 organizations that respond~

~but they already added 8 (sounds like a soft limit to me! can't hurt to drop a quick comment and try to get in!)~

Oops, that last one is about launching discussions at the organization level, not polls. 😴 apologies for the noise. I followed https://github.com/evi-liu so hopefully I'll get notified if they mention any new chance to join poll beta

[siduck]

bruh where are the 30 likes? what happened :/

[zbirenbaum]

Whoa @siduck you're right, that's an insane difference. I guess some people read the discussion and changed their minds.

Or maybe one dude made 20 accounts just to vote more and then felt bad. idk

[siduck]

Whoa @siduck you're right, that's an insane difference. I guess some people read the discussion and changed their minds.

I was very happy knowing that many are against the custom config :(((

[siduck]

in case the favor turns for custom config, We will no longer help users with custom config related issues and such issues will be automatically closed!!!!!!!!!!!!! let them read the fine manual :angry: :laughing:

[zbirenbaum]

Whoa @siduck you're right, that's an insane difference. I guess some people read the discussion and changed their minds.

I was very happy knowing that many are against the custom config :(((

But why though? I think that if they wanted something like that they would maintain their own.

in case the favor turns for custom config, We will no longer help users with custom config related issues and such issues will be automatically closed!!!!!!!!!!!!! let them read the fine manual angry laughing

I don't disagree with this at all. We should have a bot that pastes a comment with a link to the docs into issues we auto close for that reason or something.

[Animeshz]

Trust me, non-custom config gotta be even more harder to maintain. Those patches and reading/finding their manual. Updating/rebasing after applying patches, etc.

[siduck]

Whoa @siduck you're right, that's an insane difference. I guess some people read the discussion and changed their minds.

I was very happy knowing that many are against the custom config :(((

But why though? I think that if they wanted something like that they would maintain their own.

in case the favor turns for custom config, We will no longer help users with custom config related issues and such issues will be automatically closed!!!!!!!!!!!!! let them read the fine manual angry laughing

I don't disagree with this at all.

un-needed bloat, the custom config has gotten us 100+ issues bruh, its easy to work with it when you read the docs but at first glance it looks intimidating and nvchad was initially meant to be used as a base config. Removing the custom config will remove all the clutter from nvchad and the config would look standard, clean and easy to understand for any existing neovim lua user without having the need to read docs for just maintaining a nvim config!

[siduck]

Trust me, non-custom config gotta be even more harder to maintain. Those patches and reading/finding their manual. Updating/rebasing after applying patches, etc.

there arent any patches, once the custom config gets removed . you just fork nvchad and add whatever changes you want. This way nvchad users would actually be aware of how nvim configs work and they'd get to know more about the config. Also after v2.0 nvchad will become very stable as i dont think there'd be much to add in the nvchad repo unlike the base16/extensions repo which will constantly be improving with new themes and features.

[zbirenbaum]

Whoa @siduck you're right, that's an insane difference. I guess some people read the discussion and changed their minds.

I was very happy knowing that many are against the custom config :(((

But why though? I think that if they wanted something like that they would maintain their own.

in case the favor turns for custom config, We will no longer help users with custom config related issues and such issues will be automatically closed!!!!!!!!!!!!! let them read the fine manual angry laughing

I don't disagree with this at all.

un-needed bloat, the custom config has gotten us 100+ issues bruh, its easy to work with it when you read the docs but at first glance it looks intimidating and nvchad was initially meant to be used as a base config. Removing the custom config will remove all the clutter from nvchad and the config would look standard, clean and easy to understand for any existing neovim lua user without having the need to read docs for just maintaining a nvim config!

Don't get me wrong, I see your point and understand both sides of the argument, especially having worked on the project for ages, but I was honestly shocked at the upvotes. I think how fast it went up kinda shows it was the more active advanced users voting. Many of them probably saw the posts here and felt like it was gonna hurt avg user.

Thing is, most of our users very, very likely don't know any lua outside of how to make a table to pass into packer use, and how to copy and paste configs from github. Honestly many of those 100+ issues I could tell that was the case.

[Animeshz]

I don't understand how'd updates be pushed/applied, common unix structure puts package specific default config are anyway at /usr/share and custom be in /etc which is inherited from /usr/share :thinking: otherwise package manager will overwrite config every update.

[siduck]

Whoa @siduck you're right, that's an insane difference. I guess some people read the discussion and changed their minds.

I was very happy knowing that many are against the custom config :(((

But why though? I think that if they wanted something like that they would maintain their own.

in case the favor turns for custom config, We will no longer help users with custom config related issues and such issues will be automatically closed!!!!!!!!!!!!! let them read the fine manual angry laughing

I don't disagree with this at all.

un-needed bloat, the custom config has gotten us 100+ issues bruh, its easy to work with it when you read the docs but at first glance it looks intimidating and nvchad was initially meant to be used as a base config. Removing the custom config will remove all the clutter from nvchad and the config would look standard, clean and easy to understand for any existing neovim lua user without having the need to read docs for just maintaining a nvim config!

Don't get me wrong, I see your point and understand both sides of the argument, especially having worked on the project for ages, but I was honestly shocked at the upvotes. I think how fast it went up kinda shows it was the more active advanced users voting. Many of them probably saw the posts here and felt like it was gonna hurt avg user.

Thing is, most of our users very, very likely don't know any lua outside of how to make a table to pass into packer use, and how to copy and paste configs from github. Honestly many of those 100+ issues I could tell that was the case.

yea i wouldnt want such noobs using nvchad as we dont intend to spoonfeed our users, we'd rather get them strong with neovim configuration in general unlike those ready to use frameworks such as lunarvim,spacevim which are "noob friendly"

[zbirenbaum]

Trust me, non-custom config gotta be even more harder to maintain. Those patches and reading/finding their manual. Updating/rebasing after applying patches, etc.

there arent any patches, once the custom config gets removed . you just fork nvchad and add whatever changes you want. This way nvchad users would actually be aware of how nvim configs work and they'd get to know more about the config. Also after v2.0 nvchad will become very stable as i dont think there'd be much to add in the nvchad repo unlike the base16/extensions repo which will constantly be improving with new themes and features.

I thought the whole idea mentioned somewhere was that we would have "config mods" in the form of patches for them to use.

Manually trying to do it would almost be worse than patches. I can already see the typo issue posts.

I don't understand how'd updates be pushed/applied, common unix structure puts package specific default config are anyway at /usr/share and custom be in /etc which is inherited from /usr/share thinking otherwise package manager will overwrite config every update.

Second that we edit a file user does too there a merge conflict they have to resolve. I'd wager many users don't even know how to do that which is another reason I think its an awful idea. Benefit of patches is if you are advanced it makes reverting, rebasing, and doing some other advanced stuff with commits easier I guess.

[siduck]

I don't understand how'd updates be pushed/applied, common unix structure puts package specific default config are anyway at /usr/share and custom be in /etc which is inherited from /usr/share thinking otherwise package manager will overwrite config every update.

idk about the unix structure, you just maintain your nvchad fork and resolve the conflicts in github itself

[siduck]

Trust me, non-custom config gotta be even more harder to maintain. Those patches and reading/finding their manual. Updating/rebasing after applying patches, etc.

there arent any patches, once the custom config gets removed . you just fork nvchad and add whatever changes you want. This way nvchad users would actually be aware of how nvim configs work and they'd get to know more about the config. Also after v2.0 nvchad will become very stable as i dont think there'd be much to add in the nvchad repo unlike the base16/extensions repo which will constantly be improving with new themes and features.

I thought the whole idea mentioned somewhere was that we would have "config mods" in the form of patches for them to use.

Manually trying to do it would almost be worse than patches. I can already see the typo issue posts.

I don't understand how'd updates be pushed/applied, common unix structure puts package specific default config are anyway at /usr/share and custom be in /etc which is inherited from /usr/share thinking otherwise package manager will overwrite config every update.

Second that we edit a file user does too there a merge conflict they have to resolve. I'd wager many users don't even know how to do that which is another reason I think its an awful idea. Benefit of patches is if you are advanced it makes reverting, rebasing, and doing some other advanced stuff with commits easier I guess.

hmm i thought patches are just suckless stuff lol :laughing: , integrating patches with nvchad seems like a good idea :smiling_imp:

[Animeshz]

Don't even think of making nvchad a dwm :hocho: (jk :laughing:)

[zbirenbaum]

yea i wouldnt want such noobs using nvchad as we dont intend to spoonfeed our users, we'd rather get them strong with neovim configuration in general unlike those ready to use frameworks such as lunarvim,spacevim which are "noob friendly

I'm trying to find it, but we were literally listed in a post where a bunch of the main Neovim devs + plugin authors were discussing how to better explain things to their base. NvChad and LunarVim (I think) were the two configs their "Type B" users are most likely to use (ones with generally very little technical knowledge) vs "Type A" who are likely to active research plugins and write their own stuff who are likely to maintain their own configs.

I'm pretty sure you've gotten used to working in lua so you might be overestimating what other people are capable of. I have a habit of doing the same thing. I released a couple plugins of my own the other day and some of the issues I saw brought me back down to earth, and reeeeeeeeeeeeeaaaaaaaaaalllllllly think this was a bad idea.

hmm i thought patches are just suckless stuff lol laughing , integrating patches with nvchad seems like a good idea smiling_imp

Please no, but patches are not just suckless. Linux kernel gets developed through a mailing list where people mail patches. There's a mail format option in the git command for generating patches even.

Patches are also how I managed to move the 9 commits to terminal.lua I wrote in main NvChad repo and keep them in the ext repo.

[siduck]

yea i wouldnt want such noobs using nvchad as we dont intend to spoonfeed our users, we'd rather get them strong with neovim configuration in general unlike those ready to use frameworks such as lunarvim,spacevim which are "noob friendly

I'm trying to find it, but we were literally listed in a post where a bunch of the main Neovim devs + plugin authors were discussing how to better explain things to their base. NvChad and LunarVim (I think) were the two configs their "Type B" users are most likely to use (ones with generally very little technical knowledge) vs "Type A" who are likely to active research plugins and write their own stuff who are likely to maintain their own configs.

I'm pretty sure you've gotten used to working in lua so you might be overestimating what other people are capable of. I have a habit of doing the same thing. I released a couple plugins of my own the other day and some of the issues I saw brought me back down to earth, and reeeeeeeeeeeeeaaaaaaaaaalllllllly think this was a bad idea.

I know only basic lua, no plugin knowledge! knowing basic lua is a must pre-requisite for using nvchad. Only basic lua knowledge is required , NO lua plugin knowledge like you! bruh

I was talking about just things like "figure out why this path isn't right". I had to go into the dotfiles for at least 3 people for figure out their problems.

[siduck]

i'd want nvchad to list under type A ! :anger: feels sad when they put us with lunarvim,spacevim as those are some ootb frameworks unlike us

[zbirenbaum]

i'd want nvchad to list under type A ! anger feels sad when they put us with lunarvim,spacevim as those are some ootb frameworks unlike us

I think we are much better, I wouldn't be involved with the project if we were anywhere near as bad as them, but compared to maintaining your own multi thousand line config we are much simpler.

[siduck]

i'd want nvchad to list under type A ! anger feels sad when they put us with lunarvim,spacevim as those are some ootb frameworks unlike us

I think we are much better, I wouldn't be involved with the project if we were anywhere near as bad as them, but compared to maintaining your own multi thousand line config we are much simpler.

yea we'd get more simpler once we remove the custom config stuff and then we'd just have a normal config integrated with some personal plugins ( like base16, extensions etc) and make them featureful

[zbirenbaum]

yea we'd get more simpler once we remove the custom config stuff and then we'd just have a normal config integrated with some personal plugins ( like base16, extensions etc) and make them featureful

I was thinking of making a very highly optimized config with custom color schemes lazy loading organized extremely carefully a while ago. I ended up porting our base16 to the 0.7 lua api and have daily driven it since February.

If you want this to be an option, I'd be happy to take a stab at finishing that config and releasing it under the org as a fast as all hell base for our more technical users to work off of. I would need to get through the next couple weeks of papers and projects that are due though.

I am pretty sure my custom dir loads faster than vanilla NvChad, but idk how tbh,especially with how extensive my plugins and configs are. My plugin table is over 380 lines long and almost all config is external to it.... I get like 40ms on my 5 year old laptop, and between 23-30 on my desktop depending on if I have some stuff disabled. I think I get 65 or so on my laptop and 40 or so on my desktop running with no custom dir.

Every time I try to replicate what I think it is and PR it though, never seems to have nearly as much of an effect on vanilla. No clue why. Point is, random stuff adds up, and even I have no clue why it does something other than a general idea half the time. I've had to mess with schedule() and defer for hours to figure out some random behavior.

What i'm trying to say is, there are definite improvements that can be made, but to get them done requires an immense amount of planning, and if inexperienced users try to mess with it, they won't get the performance they expect.

Right now we have a "sandbox" where they can't break anything that can't be easily tracked down and fixed.