Comments (13)
Thanks for the suggestion. I'm sure that it's something that can be easily implemented.
from gitsigns.nvim.
Plus one here, otherwise it's not possible to have separate highlighting of text & signs.
It would be nice also to support existing GitGutterXxxLineNr groups, as a few colorscheme add support for that.
from gitsigns.nvim.
I've got this working locally (was pretty simple infact), the only thing I'm struggling with is how to configure this. My current plan is to add numhl: boolean
to the config which just simply enables the use of GitSignsNum*
highlight groups. The only reason for the enable switch is to stop the highlight groups from polluting the highlight namespace though I'm not sure how much that matters.
My other idea was to just take the highlight group used for signs and reverse it for the numhl but not sure if this is too restricted.
Opinions? Ideally I'd like enabling this feature to be as simple as possible (hence the second idea), but would also like to allow flexibility.
from gitsigns.nvim.
Implemented this in #20. Can merge if people are ok with this.
from gitsigns.nvim.
I found that I had to add
hi link GitSignsAddNr DiffAdd
hi link GitSignsChangeNr DiffModified
hi link GitSignsDeleteNr DiffDelete
in order to see any colors (which is fine if intended!). Works like a charm though, thanks!
from gitsigns.nvim.
The intention is that if GitSigns*Nr
aren't defined, then they are defined automatically using the foreground of signs.*.hl
as the background.
Can you check if something gets automatically defined by removing the hi links
and running :hi GitSignsAddNr
?
from gitsigns.nvim.
I get GitSignsAddNr xxx cleared
.
from gitsigns.nvim.
Interesting, that is unintended. Not sure why it doesn't work, the code is pretty simple:
for t, sign_name in pairs(sign_map) do
local cs = config.signs[t]
if config.numhl and not hl_exists(cs.numhl) then
-- If highlight 'numhl' is not defined, create it to be the reverse of
-- texthl highlight fg->bg
local ctermfg = api.nvim_get_hl_by_name(cs.hl, false).foreground
local ctermbg = ctermfg and ('ctermbg=%d'):format(ctermfg) or ''
local guifg = api.nvim_get_hl_by_name(cs.hl, true).foreground
local guibg = guifg and ('guibg=#%x'):format(guifg) or ''
if ctermbg ~= '' or guibg ~= '' then
vim.cmd(('highlight %s %s %s'):format(cs.numhl, ctermbg, guibg))
end
end
sign_define(sign_name, {
texthl = cs.hl,
text = cs.text,
numhl = config.numhl and cs.numhl
})
end
With numhl
disabled, can you verify the result of
:lua print(vim.api.nvim_get_hl_by_name('GitSignsAddNr', false))
is E5108: Error executing lua [string ":lua"]:1: Invalid highlight name: GitSignsAddNr
And if it's not much to ask, could you add a few print
statements in the patch and see exactly why the highlights aren't being defined?
Otherwise we can just submit the PR as is and figure this issue at some other point in the future.
from gitsigns.nvim.
Can confirm the above lua snippet errors in the expected way.
A few things I noticed:
-
not hl_exists(cs.numhl)
is false, so this conditional is never entered -
Even if i force it to enter that conditional,
api.nvim_get_hl_by_name(cs.hl, false).foreground
is nil, so it doesn't perform the highlight..foreground
doesn't seem to existapi.nvim_get_hl_by_name(cs.hl, false)
seems to be yield{true = 6}
.api.nvim_get_hl_by_name(cs.hl, true)
seems to yield{background = 4346703}
so if i do
[true]
, and.background
respectively, I finally get highlights (what seems to me the same colors i got from thelink
highlights i do above -
Unsure if relevant but your PR also modifies https://github.com/lewis6991/gitsigns.nvim/blob/develop/lua/gitsigns.lua#L233, which seems to never be hit because
cs.show_count
doesn't exist (unless i either set it on the default sign config, or manually set my own config. -
if i do that, i then get an error because it doesn't send the opts in as a table, like your above
sign_define
does.
from gitsigns.nvim.
Thanks for investigating.
not hl_exists(cs.numhl) is false, so this conditional is never entered
So that implies cs.numhl
exists at that point? Or hl_exists
isn't working properly.
api.nvim_get_hl_by_name(cs.hl, false)
seems to be yield{true = 6}
.
api.nvim_get_hl_by_name(cs.hl, true)
seems to yield{background = 4346703}
Well that's strange. What's the definitions for the highlights you use in config.signs.*.hl
? Maybe this code is making too many assumptions? Either that or my only other guess is that your neovim is too old. Are you running a recent build?
Unsure if relevant but your PR also modifies https://github.com/lewis6991/gitsigns.nvim/blob/develop/lua/gitsigns.lua#L233, which seems to never be hit because cs.show_count doesn't exist (unless i either set it on the default sign config, or manually set my own config.
This is for a different feature that I haven't documented yet (see #14) so I wouldn't expect that branch to execute.
Without being able to reproduce your env there's not much I can do. Would you be able to debug further? Otherwise we can just submit?
from gitsigns.nvim.
So that implies cs.numhl exists at that point? Or hl_exists isn't working properly.
yes cs.numhl matches the default config values
What's the definitions for the highlights you use in config.signs.*.hl?
I'm not setting these, they are what the default values the plugin defines are.
your neovim is too old. Are you running a recent build?
I'm on a very recent (like friday) version of master of neovim. I can dig up the precise commit if you think that's important.
Or if you use nix (package manager) i can give you my precise overlay.
In any case, I can always just explicitly set the highlights myself that i mentioned above (which seem to exactly match the behavior that happens if i make the changes i mentioned in my previous comment to make it work), so I'm happy either way to keep debugging or leave it be
from gitsigns.nvim.
yes cs.numhl matches the default config values
The default numhl highlights aren't defined by default and get defined during setup via that conditional. You can find out if they are defined by running :highlight [hl group]
. Assuming they aren't defined when they hit that conditional, can you try running
print(vim.inspect(vim.api.nvim_get_hl_by_name(GitSignsAddNr, _)))
before you run gitsigns.setup
and report the output. This is essentially the implementation of hl_exists
. My only guess right now is that function isn't working properly.
I'm not setting these, they are what the default values the plugin defines are.
Then you'll be using DiffAdd
, DiffChange
and DiffDelete
. Can you find out what these are defined as in your colorscheme by running :highlight DiffAdd
etc?
I'm on a very recent (like friday) version of master of neovim. I can dig up the precise commit if you think that's important.
Or if you use nix (package manager) i can give you my precise overlay.
Don't worry, I'm sure it's recent enough.
from gitsigns.nvim.
The default numhl highlights aren't defined by default and get defined during setup via that conditional.
Oh, I thought you meant literally cs.numhl
which is 'GitSignsDeleteNr'
etc. Where hl_exists(cs.numhl)
yields true
.
print(vim.inspect(vim.api.nvim_get_hl_by_name('GitSignsAddNr', _)))
Yields: GitSignsAddNr xxx cleared
with gitsigns.setup {numhl = true}
or
E5108: Error executing lua [string ":lua"]:1: Invalid highlight name: GitSignsAddNr
without having called setup
(or with setup where numhl = false
).
Can you find out what these are defined as in your colorscheme by running :highlight DiffAdd etc?
DiffAdd xxx guibg=#42534f
DiffChange xxx guibg=#42534f
DiffDelete xxx guibg=#534f56
from gitsigns.nvim.
Related Issues (20)
- Feature request: add the ability to ignore blank lines for git blames.
- Sign column not respecting colors from gruvbox HOT 3
- new line at end of file cause trace HOT 2
- Feature request: get commit hash for the current line HOT 1
- Error when switching between index and worktree version of file (using vim-fugitive) HOT 6
- Error when deleting a buffer before `blame_line` loads
- Having problems with `gitsigns` and `nvim-colorizer` HOT 2
- Gitsigns fails to run `git --version` HOT 8
- `gitsigns_head` shows `nil` instead of revision
- Feature Request: Allow changing blame base.
- gitsign cannot attach if nvim starts from "run" window HOT 2
- Attempt to index a nil value after executing "GDelete" HOT 2
- Syntax highlighting fails after opening linehl HOT 1
- Configuring git blame HOT 2
- Error after update – gitsigns: Ignoring invalid configuration field 'on_attach_pre' HOT 8
- Git current line blame overlap with text when split windows HOT 1
- git blame fails -- looks like the git command is incorrect HOT 3
- error in executing `:Gitsigns preview_hunk_inline ` HOT 2
- null-ls format panic when apply path PR#983 HOT 3
- Gitsigns assertion error in folder not using git HOT 1
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 gitsigns.nvim.