-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add git signs to neovim highlight groups for coloring #31
Comments
The relevant code is here. What I'm doing is registering the signs like
Perhaps I just expose all these options from
And potentially allow the user to specify a pre-existing sign as well? |
Currently, I have the below working as intended, with no upfront complications: if u.is_empty(vim.fn.sign_getdefined('TriptychGitAdd')) then
vim.fn.sign_define('TriptychGitAdd', { text = signs_config.add, texthl = 'TriptychSignGitAdd' })
end
if u.is_empty(vim.fn.sign_getdefined('TriptychGitModify')) then
vim.fn.sign_define('TriptychGitModify', { text = signs_config.modify, texthl = 'TriptychSignGitModify' })
end
if u.is_empty(vim.fn.sign_getdefined('TriptychGitRename')) then
vim.fn.sign_define('TriptychGitRename', { text = signs_config.rename, texthl = 'TriptychSignGitRename' })
end
if u.is_empty(vim.fn.sign_getdefined('TriptychGitUntracked')) then
vim.fn.sign_define('TriptychGitUntracked', { text = signs_config.untracked, texthl = 'TriptychSignGitUntracked' })
end
vim.cmd("highlight TriptychSignGitAdd ctermfg=114 guifg=#98c379")
vim.cmd("highlight TriptychSignGitModify ctermfg=180 guifg=#e5c07b")
vim.cmd("highlight TriptychSignGitRename ctermfg=39 guifg=#61afef")
vim.cmd("highlight TriptychSignGitUntracked ctermfg=204 guifg=#e06c75") It's a little janky as is, because I had to unroll the loop over the signs_to_text table. I can probably update the config to include a color as a string, in the form "guifg=#000000" or "ctermfg=210" and concatenate that to the vim.cmd argument, but by default include both. I could also update the signs_to_text table to work nicer, so it can be put back in the loop. What do you think? |
I've made the edits on my fork of the project, the new color config looks like this: git_signs = {
enabled = true,
signs = {
add = '+',
modify = '~',
rename = 'r',
untracked = '?',
},
colors = {
add = { fg = '#98c379' },
modify = { fg = '#e5c07b' },
rename = { fg = '#61afef' },
untracked = { fg = '#e06c75' },
},
}, I chose to specify the colors in a different table than the signs' text because I didn't want to break already existing configs. I also converted the sign definition back to a loop, the new definition looks like this: local signs_config = vim.g.triptych_config.git_signs
local signs_to_text = {
['TriptychGitAdd'] = {
text = signs_config.signs.add,
texthl = 'TriptychSignGitAdd',
hl = signs_config.colors.add,
},
['TriptychGitModify'] = {
text = signs_config.signs.modify,
texthl = 'TriptychSignGitModify',
hl = signs_config.colors.modify,
},
['TriptychGitRename'] = {
text = signs_config.signs.rename,
texthl = 'TriptychSignGitRename',
hl = signs_config.colors.rename,
},
['TriptychGitUntracked'] = {
text = signs_config.signs.untracked,
texthl = 'TriptychSignGitUntracked',
hl = signs_config.colors.untracked,
},
}
-- Register the signs if they're not already
for sign_name, opts in pairs(signs_to_text) do
if u.is_empty(vim.fn.sign_getdefined(sign_name)) then
vim.fn.sign_define(sign_name, { text = opts.text, texthl = opts.texthl })
vim.api.nvim_set_hl(0, opts.texthl, opts.hl)
end
end I also added the types for the color table and the highlights to |
I think it would be preferable to update the existing config options so that they're of type So if vim.fn.sign_define(sign_name, { text = value }) And if vim.fn.sign_define(sign_name, value) The problem with treating |
That makes sense, I can shift it around. But how will the color itself be represented in the config? Because the sign_define method does not allow you to pass a color in as an argument, so will that still be part of the separate "colors" table? If that's the case, then the color options will already match the tabular options that you want. |
The idea is that the user would specify the highlight group, rather than a colour directly. I think this is preferable for a few reasons
I don't mind implementing this myself if it's unclear? |
Oh, I see what you mean. I can try to implement it myself, and get a PR by tonight. |
Describe the problem you're having
As title says.
Proposed solution(s)
I'm currently looking into the actual code of the plugin to potentially handle it myself, but my first impression is that this should be placed in either
syntax_highlighting.lua
orview.lua
.Additional context
N/A.
The text was updated successfully, but these errors were encountered: