Port for Neovim
shaunsingh opened this issue · 18 comments
Neovim is a Vim-fork focused on extensibility and usability, and offers many features that regular vim doesn't provide, such as lua support.
https://github.com/nvim-treesitter/nvim-treesitter is a plugin for Neovim that parses text/code and offers better syntax highlighting based on it. However, this plugin (along with some others such as nvim-lsp, nvim-dashboard, lualine, etc), require a color-scheme that specifies the color groups used.
Although the vim-version of the theme works with neovim, I thought it would be nice to have a lua version, as well as one that takes full advantage of neovim features.
I have a draft available here: https://github.com/shaunsingh/nord.nvim, and the colors used are available here: https://github.com/shaunsingh/nord.nvim/blob/master/lua/nord/colors.lua.
Before I went ahead with the project, I wanted to check with you if it would be a good fit for the Nord theme, if the Colors match your specifications, and if it is ok to go forward.
I tweaked the colors and syntax groups a bit to align more with the colors described in the documentation for the pallets. Notable differences are yellow (nord13) instead of Snow White (Nord 4) for constants, and light blue (Nord 7) instead of Snow White (Nord 4) for function names, as I feel it gives a little more pop to the theme
I also updated the comment color to something slightly brighter (similar to nord3_gui_bright for The Nord-vim theme), this change is not present in the screenshots
Final Screenshots:
Full Screenshots:
Kotlin
Groovy
.iml
Specific Screenshots
Statusline:
Tabline/bufferline (barbar):
Number line
Comments:
Sample Function:
Enums and Variables:
Annotation, Constructers, and Errors:
Filetree(nerdtree):
:help file (doc 25 for example)
Popup-menu (completion):
Popup-menu (which key)
Hi @shaunsingh 👋, first of all thanks for your contribution 👍
Even though I use "default" Vim I've noticed that many people are waiting with excitement for Neovim version 0.5 and all of its features, but I am not so sure of all of these Vim forks. On one side its great to see that the community is actively working together to improve Vim, but as soon as a fork starts to bring in non-backwards changes, or tries to establish its own concepts, things will get ugly at some point in time. Don't get me wrong here, its really great to see that Neovim tries to improve the developer experience, i.e. by supporting multi-purpose languages like Lua, but this comes often with the cost of dividing more and more from the origin project.
One of the advantages of Vim is that it comes with almost every Unix distribution by default and developers can simply load their configurations, i.e. when starting a SSH session, and they can use their customized setup without many effort. Neovim on the other side is still too new to be included and requires either the installation through a package manager, manual download/compilation or can't be used at all due to permission restrictions in environments critical environments, i.e. user policies in SSH sessions.
Another point I'm currently not sure about is what are the real differences to a "normal" Vim theme and what are the actual advantages. Sure, some will say “it's new and modern“ or “it's faster than Vim script“, but these are in no way arguments that can be weighed against the effort that arises when creating a new official Nord port which would add +98% maintenance overhead to keep both projects in sync.
As far as I understand a Lua theme for Neovim also only just defines the highlighting groups like a "normal" Vim theme so adding support for Neovim specific plugins is still easily possible. I know that many users would like to use TreeSitter and adding support for it to the Nord Vim project is planned to be implemented and released within the next weeks (looks like nordtheme/vim#253 was closed due to the false assumption that this issue will resolve TreeSitter support).
Would be nice to hear from your and also opinions from others. I'm a bit concerned about the gap that keeps getting bigger between Vim forks.
I apologize for the late response.
Even though I use "default" Vim I've noticed that many people are waiting with excitement for Neovim version 0.5 and all of its features, but I am not so sure of all of these Vim forks. On one side its great to see that the community is actively working together to improve Vim, but as soon as a fork starts to bring in non-backwards changes, or tries to establish its own concepts, things will get ugly at some point in time. Don't get me wrong here, its really great to see that Neovim tries to improve the developer experience, i.e. by supporting multi-purpose languages like Lua, but this comes often with the cost of dividing more and more from the origin project.
I understand your point of view. Many people (including myself), consider neovim a separate editor to vim, but if you would like to keep the two color schemes as one to reduce maintenance, it may be a better option in the long run
Another point I'm currently not sure about is what are the real differences to a "normal" Vim theme and what are the actual advantages. Sure, some will say “it's new and modern“ or “it's faster than Vim script“, but these are in no way arguments that can be weighed against the effort that arises when creating a new official Nord port which would add +98% maintenance overhead to keep both projects in sync.
The main difference is that It's much faster. I benchmarked the two and it took about 6ms to launch nord.nvim, compared to about 11ms for nord.vim. This is in part to async (which loads the unnecessary highlights after launch/splashscreen), as well as the speed of lua.
As far as I understand a Lua theme for Neovim also only just defines the highlighting groups like a "normal" Vim theme so adding support for Neovim specific plugins is still easily possible. I know that many users would like to use TreeSitter and adding support for it to the Nord Vim project is planned to be implemented and released within the next weeks (looks like nordtheme/vim#253 was closed due to the false assumption that this issue will resolve TreeSitter support).
You would be correct. However, I personally believe adding Neovim-specific features to a colorscheme most people use on stock vim doesn't make much sense. Along with that, there are several other neovim lua plugins you would ideally have to add support for (nvim-tree, barbar, lualine, etc), which don't make much sense in a vim colorscheme. Similarly, adding highlight groups for vim plugins (nerd tree, airline) don't make much sense in a neovim colorscheme.
I do understand if you would like to keep the two color schemes as one, in which case I will try to convert my additions to vimscript and PR them to the nord.vim repository if thats fine with you.
Would be nice to hear from your and also opinions from others. I'm a bit concerned about the gap that keeps getting bigger between Vim forks.
I think it would be best to implement tree-sitter support as a separate port project rather than tying it to the existing vim project. I understand your reluctance to bother with "yet another fork" but neovim has really emerged as the dominant vim fork and stands tall in its own right.
It also has its own rich ecosystem of plugins that a theme might want to support and since there is an emphasis on using Lua for neovim specific plugins, these plugins are not backward compatible with Vim itself. Supporting them along with Vim's plugins would add a lot of bloat to the Vim port.
I know that many users would like to use TreeSitter and adding support for it to the Nord Vim project is planned to be implemented and released within the next weeks
If this is indeed on track then I'd much rather receive tree-sitter support in this port itself so that I can continue to use the vim plugins that this port supports instead of waiting for a new port that will not just have to implement tree-sitter support but also additionally support neovim plugins.
I've been slowly improving my port over the last few months. As of now, any files highlighted by the legacy regex-based highlighting should look exactly like Nord-vim, apart from the identifier color which was a conscious change. In treesitter highlighting, I find nord.nvim looks far better than its vim counterpart. The port also has support for all the major neovim-specific (lua) plugins, which Nord-vim does not.
As @lokesh-krishna said, over the past few years neovim has really emerged as the dominant vim fork and stands tall in its own right. The neovim repository is approaching almost double the stars that vim has.
There are a few tricks (e.g. async loading treesitter and plugin highlights) that I can't back port to the Nord-vim theme. I also have support for around 20 or so neovim-specific (lua) plugins, that don't have much of a place in the Nord-vim theme, considering the majority of the Nord-vim's users use vim (not neovim).
In my opinion, having an official neovim port would allow neovim plugins to have their place without bloating up the Nord-vim repository. This would also avoid having duplicate neovim-specific plugins that do the same thing as their vim counterparts (e.g. hop.nvim and easy motion, nvim-tree and nerd tree)
I've also spoken to a few others, and they mentioned they switched from Nord-vim to nord.nvim. They also mentioned if someone were to PR my neovim-specific improvements back to the Nord-vim repo, they were unlikely to switch back.
In the meantime, if anyone feels like back porting the changes, all the highlights for plugins are here: https://github.com/shaunsingh/nord.nvim/blob/f58f77dee66babac1a859c2b552797d8128e1f86/lua/nord/theme.lua#L277, apart from a few of them (which I plan to correct), the majority adhere to the 16 colors, so it should be easy enough.
As for maintenance, I don't plan to stop working on the project anytime soon. If there are any changes you make (or have made) in Nord-vim, that you prefer be included in nord.nvim as well, feel free to open an issue or shoot me an email and I'll get on it. If you need any screenshots, then feel free to reach out as well.
I don't know if there's any precedent for this but as far as worthy candidates go for an unofficial port to be made the base for an official port project, I can't think of a better candidate than nord.nvim. It's very comprehensive in its coverage and as tough as it is to make any kind of promises in the open source world, the mere fact that @shaunsingh is willing to commit to it instead of leaving it at a best effort basis is promising.
I for one would love to see this become an official port project and think it's solid enough to be brought into the fold already.
[@shaunsingh] The main difference is that It's much faster. I benchmarked the two and it took about 6ms to launch nord.nvim, compared to about 11ms for nord.vim.
Even though better performance is always nice, but in scenarios like opening an editor, especially when it comes to milliseconds, it has 0 relevance. This is just my my opinion, but if one insist that an editor has to open faster than the blink of an eye something in the mind set of the user is wrong. I open my editor one time a day (or even leave it open in when my system is in hibernation) and that's it. I prioritize the requirement that my editor runs smoothly during usage much higher so that I can work without interruption.
Anyway, this is still a positive side effect of Neovim.
[@shaunsingh] I personally believe adding Neovim-specific features to a colorscheme most people use on stock vim doesn't make much sense. Along with that, there are several other neovim lua plugins you would ideally have to add support for (nvim-tree, barbar, lualine, etc), which don't make much sense in a vim colorscheme. Similarly, adding highlight groups for vim plugins (nerd tree, airline) don't make much sense in a neovim colorscheme.
[@shaunsingh] In my opinion, having an official neovim port would allow neovim plugins to have their place without bloating up the Nord-vim repository. This would also avoid having duplicate neovim-specific plugins that do the same thing as their vim counterparts (e.g. hop.nvim and easy motion, nvim-tree and nerd tree)
100%. And this is also the reason why I've decided to create an official "Nord Neovim" port project.
After digging more into Neovim's ecosystem and goals I see why users switching away from "vanilla" Vim.
[@lokesh-krishna] I think it would be best to implement tree-sitter support as a separate port project rather than tying it to the existing vim project.
Thetree-sittersupport in Nord Vim was indeed only added due to the high demand of users who like to use it. As soon as the official port for Neovim is available this will be removed again, including any other Neovim-only features.
[@shaunsingh] The neovim repository is approaching almost double the stars that vim has.
Don't get me wrong, but GitHub stars are pointless and only fulfill the purpose of the typical way to control the human behavior of "addiction binding" for the maintainers as well as an empty satisfaction. A number in a database doesn't say anything about project quality but only about spreading the degree of awareness. Relying on such stupid numbers would imply that Git (~39.4k stars), the amazing beast that empowers the world of code, is less "important" or "famous" than React (~175k stars), also an awesome project any my all-time-favorite library for UIs but also "just" a JS project that is way less relevant to keep the whole IT industry running 😜
Next steps
I've decided to create an official "Nord Neovim" port project which is justified by the points mentioned above, but note that this won't happen overnight. The fact that users often only perceive the work maintainers do for projects they use does not mean that these maintainers are not also working on various projects. In my case this includes a huge amount of work and time effort to keep Nord running while also working on other OSS, job and private projects. Of course, a port project that works could be glued together in a short time, but this is wasted time and ends up taking more than double the time to get it right afterwards (a.k.a "sewn with a hot needle").
To clarify my decision again I want to make sure that the main reason is to keep both projects "clean" and stop the mix of "monolith" theme that supports multiple flavors of Vim. Reducing "Nord Vim" back to provide a good base for basic Vim usage (e.g. when running in remote shell sessions or simple editing tasks) while building up "Nord Neovim" for power users (with terminal based IDE use cases) is a way that helps to better support multiple preferences.
A rough overview of the next steps:
- Building up the new "Nord Neovim" port project that provides basic support for core UI elements and syntax highlighting.
- Porting Neovim-only features from "Nord Vim" into "Nord Neovim".
- Evaluating and implementing support for Neovim specific features and plugins that are almost similar in their function and stability to their counterpart currently supported "Nord Vim".
- Updating "Nord Vim" documentations and project state:
4.1 Document about "feature freeze" for Neovim-only features and plugin support.
4.2 Document about removal of Neovim-only features and plugin support when "Nord Vim" reaches major version1.0.0.
4.3 Notify users about the new "Nord Neovim" port project so that they can switch if they're only using Neovim anyway or maybe want to do it then.
During initial development the new "Nord Neovim" port project repository visibility could be private to prevent users from adapting too early to prevent the typical "early access disappointment" due to wrong expectations and the lack of ability to understand how initial project development works.
Even though better performance is always nice, but in scenarios like opening an editor, especially when it comes to milliseconds, it has 0 relevance. This is just my my opinion, but if one insist that an editor has to open faster than the blink of an eye something in the mind set of the user is wrong. I open my editor one time a day (or even leave it open in when my system is in hibernation) and that's it. I prioritize the requirement that my editor runs smoothly during usage much higher so that I can work without interruption.
Thats definitely true. Personally for me its just the fun of making everything as fast as possible. In real world usage I open neovim maybe 4, 5 times a day, and my neovim gui is the bottleneck for startuptime. I imagine the majority of users don't care much, or won't notice the benefit.
Don't get me wrong, but GitHub stars are pointless and only fulfill the purpose of the typical way to control the human behavior of "addiction binding" for the maintainers as well as an empty satisfaction. A number in a database doesn't say anything about project quality but only about spreading the degree of awareness. Relying on such stupid numbers would imply that Git (~39.4k stars), the amazing beast that empowers the world of code, is less "important" or "famous" than React (~175k stars), also an awesome project any my all-time-favorite library for UIs but also "just" a JS project that is way less relevant to keep the whole IT industry running 😜
I didn't really know how else to discuss neovim's popularity as neither of the projects publish usage statistics. I personally believe that stars are useless too, but the point was to justify that neovim was popular enough for its own port, not that it was more "important" or "famous" or anything of that sort 😄. Regardless, I think both of us are thinking on a similar page now.
I've decided to create an official "Nord Neovim" port project which is justified by the points mentioned above, but note that this won't happen overnight. The fact that users often only perceive the work maintainers do for projects they use does not mean that these maintainers are not also working on various projects. In my case this includes a huge amount of work and time effort to keep Nord running while also working on other OSS, job and private projects. Of course, a port project that works could be glued together in a short time, but this is wasted time and ends up taking more than double the time to get it right afterwards (a.k.a "sewn with a hot needle").
Thanks for considering and approving the port! Of course it will take time, and I would like to rewrite certain parts of the theme in the process. I understand that you have many responsibilities outside of just OSS work, and you likely have other port projects currently underway as well. It makes sense to take it slow with the project and refine everything to a comfortable point before public release.
To clarify my decision again I want to make sure that the main reason is to keep both projects "clean" and stop the mix of "monolith" theme that supports multiple flavors of Vim. I just put that as an extra benefit, the vast majority of people don't care about startuptime.
This was one of the main reasons I made the nord.nvim theme. It wasn't about being in lua, moreso the "original" nord-vim theme had lots of features and highlights and features I didn't use, and close to no neovim plugin support. I feel like more and more of the vim power users (those who want a ide-like text editor) are moving to neovim, so it makes sense to start keeping the nord-vim theme more minimalistic.
Before I used neovim, I actually opted to use the nord palette with a colorscheme based off of romainl's apprentice. I like my vim config to be minimal and quick, as opposed to my featurefull neovim configuration, and I imagine a few others are in a similar boat.
Reducing "Nord Vim" back to provide a good base for basic Vim usage (e.g. when running in remote shell sessions or simple editing tasks) while building up "Nord Neovim" for power users (with terminal based IDE use cases) is a way that helps to better support multiple preferences.
Just to clarify, does this mean that you will be removing certain features from the vim colorscheme to make it more minimal, or will you just freeze/remove the neovim-specific plugin additions?
During initial development the new "Nord Neovim" port project repository visibility could be private to prevent users from adapting too early to prevent the typical "early access disappointment" due to wrong expectations and the lack of ability to understand how initial project development works.
Of course! Early development is always rough, and people often set their expectations too high. With time we can deliver a much more polished plugin.
[@shaunsingh] Just to clarify, does this mean that you will be removing certain features from the vim colorscheme to make it more minimal, or will you just freeze/remove the neovim-specific plugin additions?
Basically both.
The first step is to freeze features that are only relevant for Neovim like supported plugins and specific groups like terminal_color_* (Neovim terminal colors). In terms of "freeze" that means that no more code changes will be made like improvements or bug fixes.
The second step is to mark them as deprecated. I'm not sure yet if adding a warning message is possible that will be displayed only once (not sure if/where to store states), but the deprecation will be announced through all possible channels that are relevant for "Nord Vim".
The third and last step is to remove the features in "Nord Vim" version 1.0.0 which indicates to users that there are definitely breaking changes and they need to make sure they adapt to them, e.g. by switching to the new "Nord Neovim" port project.
For anyone watching this issue, currently I'm just waiting on neovim api's nvim_set_hl to finalize, as it currently doesn't allow updating global highlights such as Normal and VISUAL (and its unstable)
Neovim 0.7 released w/ improvements to lua api in general and to nvim_set_hl in particular. Hope that helps @shaunsingh.
Indeed, rewrite is almost done!
I went ahead and ported the existing Nord-vim to lua. I removed all the clutter from plugins and it's only the bare Neovim highlight groups that are configured in the Nord-vim config. I'm putting it out here for anyone to copy, I have no clue how to turn it into a plugin or anything like it, but feel free to do so. I basically did the port because I found https://github.com/shaunsingh/nord.nvim way to colourful and bold.
If you are like me, then you maybe enjoy this as a starting point: https://github.com/jan-xyz/Dotfiles/blob/88a1952ca080653a954087f1145c5ee6ca0789f8/nvim/colors/nord.lua
I made my above config available at https://github.com/jan-xyz/nord.nvim
@svengreb I don't intent to add any more features to it than is absolutely required to stay up-to-date with Nord and Neovim, as such it will probably remain quite barebones. That's why I can imagine that it could be a good basis to get going with an official port. If you think that's the case just let me know and I am happy to let go of it and hand everything over to you. I would also be open to help maintaining it.
@jan-xyz thanks a lot for the no-bloat, faith to the original port!
IMO this color scheme definitely needs a captain who uses Neovim, and therefore is able to add sound, basic support for Neovim specific highlights, which are currently lacking upstream.
Maintaining a Lua port to achieve that isn't even required. https://github.com/sainnhe/everforest is one example of Vim color scheme that fully supports Neovim, and is very popular in both communities of users.
I've been using nord.vim (and other nord themes everywhere I can!) on a daily basis and can't thank you enough for this theme @svengreb. Seeing that official nvim support is unlikely, and inspired by @jan-xyz's port, I took a stab at one myself. It was a good learning experience around nvim plugin creation and theming. I intend to daily drive this and add more specific neovim highlights as needed. https://github.com/hoelter/nord.nvim
@jan-xyz I ported over more than you did, but I stuck with all of the original highlights as much as possible. I went with 24bit color support only which simplified some of the assignments.
@antoineco I agree with you that a lua version is definitely not required and could increase the maintenance burden, along with being less convenient for those that have a config which works in neovim and vim. However, by splitting them each could become more focused and somewhat simplified. If they're focused enough on vim and neovim respectively, it may decrease the problem of keeping them in sync because I don't think the core highlight groups change all that frequently (though I could be very wrong about this).
I made some changes to my port that address some open issues that are neovim specific or low hanging fruit:
nordtheme/vim#347 -> hoelter/nord.nvim#3
nordtheme/vim#344 -> hoelter/nord.nvim#2
nordtheme/vim#173 -> hoelter/nord.nvim#4
Innocent bystander and barrel-kicker here. There is https://github.com/EdenEast/nightfox.nvim#nordfox, which works really well with neovim and supports all your favorite cli tools. It looks pretty "nordish" to me. Just fyi, sry for the noise.
That looks like a great theme all around, but I think it deviates from the nord color pallette based on their definitions here. Seems like a great option for a close approximation that'll just work with lots of plugin support.