Click to see contents
This plugin is in its early stages, so not many colorschemes support it. If you use/encounter any of these colorschemes, please issue a PR for them. It is so easy to do so 👌 (just requires little knowledge of lua and highlight groups).
-
Fork the colorscheme's repository.
-
Create a file at
/lua/barbecue/theme/[name].lua
(in the colorscheme plugin) and copy template inside it.NOTICE:
[name]
is the colorscheme's name (known by neovim). An easy way to achieve it is by running:lua =vim.g.colors_name
inside neovim while you have the colorscheme loaded. -
In the colorscheme plugin, find the palette module which is being consumed by the entire theme (usually named
colors.lua
orpalette.lua
).Examples: colors.lua, palette.lua.
NOTE: Find a use case for the module you've found and see how it's being
require
d. -
Open the file you copied in step 2 and follow its guidelines.
-- replace the following line with the require statement you've found in step 3
local c = require("something")
-- this table contains a mapping from color name to highlight value
-- (highlight value being the third parameter of vim.api.nvim_set_hl)
local M = {
-- this is a fallback for the rest of the colors
normal = {
-- the whole winbar's background
-- recommended to use SignColumn's or LineNr's background
-- "none" for transparent (kind of)
bg = "none",
-- foreground of the parts that have no specific color (empty table)
fg = c.fg_dark,
},
ellipsis = { fg = c.dark5 }, -- Conceal's or Normal's fg
separator = { fg = c.dark5 }, -- Conceal's or Normal's fg
modified = { fg = c.warning }, -- BufferVisibleMod's fg (a yellow color)
dirname = { fg = c.dark5 }, -- Conceal's or Normal's fg
basename = { fg = c.fg_dark, bold = true }, -- normal's fg and bold are recommended
context = { fg = c.fg_dark }, -- normal's fg is recommended
context_file = { fg = c.fg_dark }, -- CmpItemKindFile's fg
context_module = { fg = c.yellow }, -- CmpItemKindModule's fg
context_namespace = { fg = c.yellow }, -- CmpItemKindModule's fg
context_package = { fg = c.blue }, -- CmpItemKindModule's fg
context_class = { fg = c.orange }, -- CmpItemKindClass's fg
context_method = { fg = c.blue }, -- CmpItemKindMethod's fg
context_property = { fg = c.green1 }, -- CmpItemKindProperty's fg
context_field = { fg = c.green1 }, -- CmpItemKindField's fg
context_constructor = { fg = c.blue }, -- CmpItemKindConstructor's fg
context_enum = { fg = c.orange }, -- CmpItemKindEnum's fg
context_interface = { fg = c.orange }, -- CmpItemKindInterface's fg
context_function = { fg = c.blue }, -- CmpItemKindFunction's fg
context_variable = { fg = c.magenta }, -- CmpItemKindVariable's fg
context_constant = { fg = c.magenta }, -- CmpItemKindConstant's fg
context_string = { fg = c.green }, -- String's fg
context_number = { fg = c.orange }, -- Number's fg
context_boolean = { fg = c.orange }, -- Boolean's fg
context_array = { fg = c.orange }, -- CmpItemKindStruct's fg
context_object = { fg = c.orange }, -- CmpItemKindStruct's fg
context_key = { fg = c.purple }, -- CmpItemKindVariable's fg
context_null = { fg = c.orange }, -- Special's fg
context_enum_member = { fg = c.green1 }, -- CmpItemKindEnumMember's fg
context_struct = { fg = c.orange }, -- CmpItemKindStruct's fg
context_event = { fg = c.orange }, -- CmpItemKindEvent's fg
context_operator = { fg = c.green1 }, -- CmpItemKindOperator's fg
context_type_parameter = { fg = c.green1 }, -- CmpItemKindTypeParameter's fg
}
return M
-
Fork and clone this repository
git clone https://github.com/[user]/barbecue.nvim.git
-
Change your config so that neovim will load your locally cloned plugin
-
local spec = { "utilyre/barbecue.nvim", dev = true, -- ... }
-
use({ "~/projects/barbecue.nvim", -- ... })
-
-
Create a feature branch and do what you want to do
git checkout -b feature/[pr-subject] # or git checkout -b bugfix/[pr-subject]
-
Format your code with stylua.
The following command will check if everything is formatted based on the guidelines
stylua -c .
-
Create a draft PR while working on your changes to prevent other people from working on the same thing separately.
-
Use feature branch.
-
Title PRs the same way as commit headers.
-
Adopt Conventional Commits' specification for commit messages.
-
Consider opening a dedicated issue explaining the bug or the missing feature and referring to that issue in the PR.
-
How can I keep my branch up to date with
main
?-
Rebase towards
main
git rebase main
-
Force push
git push -f
-