Comments (6)
Hi @richardstrnad π, thanks for your contribution π
Basically, the PR can't have broken the support because there has never been explicit support for the lewis6991/gitsigns.nvim
plugin.
I was wondering why it might break anyway and found out that it is the way how the plugin uses highlighting groups, or better said which ones: it defines it own ones, which is the best way, but they also fall back to groups of other plugins like SignifySign*
that is defined by mhinz/vim-signify
.
Before PR #294 the groups for the mhinz/vim-signify
plugin where loaded unconditionally so lewis6991/gitsigns.nvim
picked them up since Nord does not define any GitSigns*
group, but now the groups are only loaded when the mhinz/vim-signify
plugin has been loaded too. Therefore the style with Nord βbreakβ when only the lewis6991/gitsigns.nvim
plugin is loaded.
I'd say this is not a problem of the PR but only just a side effect. We could add dedicated support for the lewis6991/gitsigns.nvim
plugin, but I would like to avoid adding more Neovim specific plugins/features as a dedicated Nord port for Neovim is in the pipeline.
@spywhere thanks for the reproduction snippet ππΌ
This definitely looks more like a problem which could be related to the way how βvanillaβ Vim(8) and Neovim loading code, especially when using third-party plugin managers which might behave differently as well.
After playing around with multiple plugins that are explicitly supported by Nord, loaded with different Vim(8) and Neovim plugin managers, I noticed various problems with the way how plugins and loaded, especially their order and when the code is applied to global namespaces to be available to other scripts. I've often had reports regarding this issue and up to today this is still the most annoying reason why users having problems when it comes to loading Nord plugin options.
Anyway, I decided to revert the changes from PR #294 because I haven't thought about the fact that the plugin loading order could be random and the Nord plugin might be loaded before the ones that are supported, but the highlighting groups will be missing because of this. The advantage of having faster loading times which are only in the nanosecond range is way to
The advantage that it is only minimally faster (we're talking about nanoseconds here) is too small compared to the fact that the actual functionally of the plugin could no longer work properly.
from vim.
That's exactly the issue I have!
Temp fix
cd ~/.config/nvim/plugged/nord-vim
git checkout a8256787edbd4569a7f92e4e163308ab8256a6e5
from vim.
I can confirm the breaking on the vim-signify
plugin as well.
Here's a reproducible configurations for neovim
plugin_home = vim.fn.stdpath('cache') .. '/nord.tmp'
vim_plug_url = 'https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim'
vim_plug = plugin_home .. '/plug.vim'
if vim.fn.filereadable(vim_plug) == 0 then
vim.cmd(
'silent !curl -fLo ' .. vim_plug .. ' --create-dirs ' .. vim_plug_url
)
end
vim.opt.runtimepath:append(plugin_home)
vim.fn['plug#begin'](plugin_home)
vim.fn['plug#']('mhinz/vim-signify')
vim.fn['plug#']('arcticicestudio/nord-vim')
vim.fn['plug#end']()
if vim.fn.isdirectory(plugin_home .. '/nord-vim') == 0 then
vim.cmd('PlugInstall --sync | q')
end
print('before loaded_signify: ', vim.g.loaded_signify)
vim.cmd('colorscheme nord')
print('after loaded_signify: ', vim.g.loaded_signify)
Save it as some-name.lua
and run it via nvim -u some-name.lua
So this block of code is not loaded when setting the color scheme
from vim.
I'm not sure should I start a new issue, it is an aesthetic issue but in regards to Gitsigns as well. The highlights for nord is thick compare to other themes. Where can we configure this?
Gruvbox-material:
from vim.
Instead of simply either conditionally or un-conditionally loaded plugin related highlights. I think we could introduce a new option to let the user choose if they want to change how it behaves.
In general, more features always good to have but more importantly is how to get those features roll out. And one easy way to make it happy for all is to opt-in into a new feature through configuration options.
Regardless, I think you would know best if it would be benefit or not. So revert the change is fine to me in this case.
from vim.
Feature flags are often a good way, but it also comes with the cost of cluttering code with more and more conditions, especially when you have to maintain multiple deployment paths and some features are mutual.
However, in this case a feature flag would also not because the problem that plugins might be loaded in random order still exists. It also depends whether the user calls the function to load the Nord plugin before or after other plugins that it supports, so e.g. when the line to load the mhinz/vim-signify
plugin comes after the one of Nord in the users configuration the current condition will fail because the global loaded_signify
variable has not been declared and set.
Reverting the change it currently the only reliable way to ensure that it works for all users regardless of their own configurations or plugin managers behavior.
from vim.
Related Issues (20)
- GitHub Flow migration HOT 1
- From `master` to `main`
- Possible to override `nord` variables outside the plugin? HOT 2
- Tank you for changing 'master' to 'main'... HOT 1
- Underline doesn't work in windows terminal HOT 7
- Weird Syntax Highlighting for neovim HOT 5
- Theme looks weird on WSL HOT 3
- theme does not set `Terminal` highlight group HOT 3
- Fix image asset URLs after `nord-docs` GitHub flow and `main` branch migration
- Just a question about the laststatus line HOT 1
- Northern Post β The state and roadmap of Nord
- `nordtheme` organization migration
- Possible conflict induced by the name of the repository HOT 2
- Different color between text mode and math mode in LaTeX HOT 2
- Adapt remaining `arcticicestudio` "fade-out" changes
- text.diff not working with Nord Theme HOT 1
- Highligted words in visual mode are invisible in neovim HOT 4
- Can't get theme working in VIM 9.0.1499 HOT 1
- I recently used Nord again
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vim.