v2.5 is released (Major Release)

[siduck]

Changelog

Added

• Starter template for NvChad which lets users use NvChad as a plugin, thus not needing custom config stuff.

• 7 New themes for base46:
  flexoki,
  jabuti,
  poimandres,
  mito-laser
  nano-light,
  flexoki-light,
  chadracula-evondev,
  Material-lighter, Material-darker, Rosepine-dawn, Solarized-oska

• Minimal terminal module which replaces nvterm which lets you created any amount of toggleable terminals , change bg color / highlights of each window etc.

• term table ( config ) in ui table of chadrc.

• Integrations list of base46 so you can exclude/include integrations supported by base46.

• Default lspconfig now exports on_init function which you can include in your custom lspconfig

• All nvchad modules will start with nvchad , example : require('nvchad.options')

Changed

• List of all defaults will be in lua/nvconfig instead of core/default_config
• Overriding modules for tabufline/statusline, its a lot easier now.
• Extended_integrations syntax for base46
• Mappings no longer use nvchad's custom syntax. It uses nvim's vim.keymap.set

Removed

• Custom config structure handling.
• Nvterm plugin
• NvChad updater
• chadrc's cmp options: border_color , selected_item_bg
• tabufline, show_numbers

Read https://nvchad.com/news/v2.5_release

[MartinDelille]

The following link doesn't work: https://nvchad.com/news/v2.5

[jhonvidal]

Try this https://nvchad.com/news/v2.5_release

[le4ker]

Is it a minor release since it requires to change the code under the custom directory?

[siduck]

simplescreenrecorder-2024-03-10_09.38.21.mp4

@bcyran tested with my own custom config, it works. The mapping part needs manual configuration.

[bcyran]

Yes, the script does work, it just doesn't cover all the possible cases and there are more things to fix than just mappings. In my case anyway but I would be very surprised if I'm the only one.

[siduck]

@bcyran improve the script then!

[bcyran]

I just don't think it's possible to perform such a migration with a script. Lua is a full blown programming language and neovim configs are programs, not just static files with data.

[siduck]

yes, but the script does work on most cases. I dont see why it wouldnt work, only the module paths are to be renamed. Except for the mappings one. For still using old mapping syntax, one could just add custom logic for it, example, looping over the whole mapping table, example:

[xarthurx]

I somehow agrees with @bcyran
For instance, after using the script, I got things like You need to set 'vim.g.maplocalleader' **BEFORE** loading lazy. And I have no clue where should I set it...

[xarthurx]

@siduck OK, after comparing and reading the code, I have more clue now...
So, if I have other plugins that are parallel with nvchad, then

- lua
  |- nvchad
  |- nvchadconfig
- init.lua

Otherwise, similar to the starterKit:

- lua
  |- config1
  |- config2
- init.lua

correct?

In this way, localleader stuff I mentioned above should be in the init.lua before nvchad and lazy is loaded.

[xarthurx]

No, the above interpretation is incorrect.
Only the starterkit structure is correct....

[siduck]

@xarthurx yes starterkit structure is correct, nvchad repo now will be used for importing its modules aka nvchad.options etc

starter's structure is very simple, like if you dont want nvchad.mappings, dont require it. And so on!

[xarthurx]

@siduck Thank you for the quick reply. One last question:
I'm using Which-key and my previous key mappings will integrate new mappings into the which-key menu.
The current new mechanism doesn't seem to load my previous which-key settings:

require "nvchad.mappings"

local M = {}
M.truzen = {
   n = {
      ["<leader>ta"] = { "<cmd> TZAtaraxis <CR>", "truzen ataraxis" },
      ["<leader>tm"] = { "<cmd> TZMinimalist <CR>", "truzen minimal" },
      ["<leader>tf"] = { "<cmd> TZFocus <CR>", "truzen focus" },
   },
}

Is there any documentation on that or how could I migrate?

[siduck]

@xarthurx you could just use vim.keymap.set to set mappings https://nvchad.com/docs/config/mappings

or make a wrapper function that loops over M table + each of its groups and sets mappings . ( v2.0 was doing this too, was using vim.keymap.set under the hood )

So ig u dont need core.utils.load_mappings('blabla') too, just load all mappings at start. Except for buffer specific ones, like our lspconfig's / gitsigns on_attach has

[siduck]

I'm going to post all the issues I encounter here so that others can find for reference:

I also modified LuaSnip to include my own snip folder. The migration script changed the past settings to:

	{
    "L3MON4D3/LuaSnip",
    opts = {
      history = true,
      updateevents = "TextChanged,TextChangedI",
      enable_autosnippets = true,
    },
    config = function(_, opts)
      -- load default luasnip config
      require("nvchad.configs.others").luasnip(opts)

      local luasnip = require("luasnip")
      luasnip.filetype_extend("typescriptreact", { "html" })
      require("luasnip/loaders/from_vscode").lazy_load()
    end,
  },

But there aren't any nvchad.config.others modules.

https://github.com/NvChad/NvChad/tree/v2.5/lua/nvchad/configs , yea others has been removed. i forgot this aspect in the script

[guzman109]

How do you call this "Minor Changes" when it completely changes the the configs structure? There is no custom directory anymore and I need to completely change all custom configs I had.

[siduck]

@xarthurx the migration script should work 90% of the time tho except for the mappings part, you can improve the script if you want.

Also no one's forcing y'all to use v2.5 this early, you can still use v2.0 and use nvim_appname feature to maintain v2.5 separately.

v2.5 was a rushed release because i will probably be inactive this month to april 11 and had decided this new syntax for v3.0 but i didnt wanted new users to read the old syntax and waste their time in migrating again to new syntax so I released this in a hurry

[guzman109]

Thanks for the reply. No I have not used or seen the migration script. I'll try it out.

As @xarthurx pointed out,this is not minor at all. This would have been better to be released with v3.0 as you are completely changing the structure of the system. You could have had this new structure in a nightly version and see what user feedback would have been like. This would give users a bit more time to be ready for the changes in the next major release rather than doing it in a minor release.

The removed section in your changelog alone indicates this would be a major release.

[siduck]

@guzman109 you're right, i always thought major/minor words in releases meant for features. I removed the minor word from this post.

This would give users a bit more time to be ready for the changes in the next major release rather

you can still use v2.0, and use nvim appname to use v2.5 & slowly migrate.

[guzman109]

@siduck Thanks again for your fast replies and hard work. I don't mean to pick on you in any way, this is a lesson learned for all of us. Thankfully your docs have always been amazing and I will migrate to v2.5.

[msundin]

@siduck I recommend having a look at Semantic Versioning which is a widely used best practice for versioning of software with clear definitions of a major/minor/patch release.

[ftqo]

I already posted this on Reddit, but I'm copying it here as it is more relevant:

Flexoki was not correctly ported. The light version is supposed to use the dark versions of those colors, and the dark version is supposed to use the light versions of those colors. The light version still looks nice, but it doesn't fit the purpose of the theme (to be "inky").

See the official Flexoki website for more details.

[siduck]

thx for correcting.try the fix branch of base46

[ftqo]

Looks good to me. As a last note, I think some of the greys can be replaced with the greys that are also on the spec page, but I'm not too sure how that would actually look in NvChad.

[siduck]

those greys are based on flexoki's bg color, they should be in steps i.e grey would be lighter by 6-7% by grey_fg and so on , so cant change them.