ntbbloodbath / doom-one.nvim Goto Github PK

View Code? Open in Web Editor NEW

199.0 3.0 30.0 396 KB

doom-emacs' doom-one Lua port for Neovim

License: MIT License

Lua 100.00%

neovim neovim-colorscheme neovim-lua neovim-lsp treesitter doom colorscheme

doom-one.nvim's Introduction

doom-one.nvim

Features • Install • Screenshots • Contribute

Come join the dark side, we have cookies.

This colorscheme is ported from doom-emacs' doom-one.

IMPORTANT: This colorscheme requires Neovim >= 0.6.x to work!

Notices

2022-08-08: doom-one is now using Neovim global variables for configurations again. It is using the same configuration options, see Install.
2021-10-05: doom-one configurations are now defined in a setup function, see Install to know the valid setup options.
2021-06-16: since the colorscheme is now 100% lua, your neovim must include this.

Features

Opt-in italic comments
Opt-in terminal colors
Opt-in TreeSitter support
Opt-in transparent background
Opt-in support for numerous plugins (nvim-tree, barbar, lspsaga, etc)
Opt-in First class support for Neorg

Install

Packer

use({
    'NTBBloodbath/doom-one.nvim',
    setup = function()
        -- Add color to cursor
		vim.g.doom_one_cursor_coloring = false
		-- Set :terminal colors
		vim.g.doom_one_terminal_colors = true
		-- Enable italic comments
		vim.g.doom_one_italic_comments = false
		-- Enable TS support
		vim.g.doom_one_enable_treesitter = true
		-- Color whole diagnostic text or only underline
        vim.g.doom_one_diagnostics_text_color = false
		-- Enable transparent background
		vim.g.doom_one_transparent_background = false

        -- Pumblend transparency
		vim.g.doom_one_pumblend_enable = false
		vim.g.doom_one_pumblend_transparency = 20

        -- Plugins integration
		vim.g.doom_one_plugin_neorg = true
		vim.g.doom_one_plugin_barbar = false
		vim.g.doom_one_plugin_telescope = false
		vim.g.doom_one_plugin_neogit = true
		vim.g.doom_one_plugin_nvim_tree = true
		vim.g.doom_one_plugin_dashboard = true
		vim.g.doom_one_plugin_startify = true
		vim.g.doom_one_plugin_whichkey = true
		vim.g.doom_one_plugin_indent_blankline = true
		vim.g.doom_one_plugin_vim_illuminate = true
		vim.g.doom_one_plugin_lspsaga = false
	end,
	config = function()
        vim.cmd("colorscheme doom-one")
    end,
})

Neorg support

If you want to get the best neorg look you will surely want to get headlines.nvim plugin.

doom-one already comes with sane defaults for headlines in Neorg buffers. However, you will need a custom configuration to get them working as expected:

require("headlines").setup({
    norg = {
        headline_highlights = {"Headline1", "Headline2", "Headline3", "Headline4", "Headline5", "Headline6"},
        codeblock_highlight = {"NeorgCodeBlock"},
    }
})

Neorg buffer with headlines plugin:

Extras

Extra color configs for kitty can be found in extras. To use them, refer to their respective documentation.

Screenshots

Dark variant:

Light variant:

Contribute

Fork it (https://github.com/NTBBloodbath/doom-one.nvim/fork)
Create your feature branch (git checkout -b my-new-feature)
Commit your changes (git commit -am 'Add some feature')
Push to the branch (git push origin my-new-feature)
Create a new Pull Request

License

doom-one.nvim is MIT licensed.

doom-one.nvim's People

Contributors

Stargazers

Watchers

doom-one.nvim's Issues

Async loading

Sorry, on a roll this morning.

So I've also noticed a few colorscheme authors making their themes async to try and save milliseconds off the startup time, which is a whole other conversation since I think people have become a bit obsessed with that. Anyway I think a colorscheme isn't a good candidate for being async because a lot of things in a vim setup are dependent on being able to reliably check the colours in the colorscheme after the colorscheme autocommand has run whereas now colours are set at unpredictable times in my case I have highlights which I override for lots of different use cases after calling colorscheme doom-one which suddenly can't find the colorscheme colours since there's a race condition, and they aren't set now.

But more generally a lot of plugins use the Colorscheme autocommand to reapply highlighting and so if things are async there will be race conditions there as well. For example, bufferline re applies its highlights when the colorscheme autocommand is called by checking what colours the theme has defined, but now this is likely to fail since those colours will be being set asynchronously.

Add spellcheck-related highlight groups

Highlight groups used by the built-in spellchecker (SpellBad, SpellLocal, SpellCap, SpellRare) are not configured, and thus use their default (rather flashy) colors.

Consumeable color palette

It would be useful if we could get the color palette so we could use consistent color when overriding highlight group.

For example, in tokyonight.nvim, we can do something like this

local colors = require("tokyonight.colors").setup({})
local utils = requires("tokyonight.util")

aplugin.background = colors.bg_dark
aplugin.my_error = util.brighten(colors.red1, 0.3)

Supporting hop

Doom-one is my favorite colorscheme. I recently started using hop plugin which works like easy-motion. When you activate the plugin (:HopWord), some letters need to be highlighted. This doesn't happen on this colorscheme. A quickfix is to set the highlight colors manually:

vim.cmd("hi HopNextKey guifg=#ff9900")
vim.cmd("hi HopNextKey1 guifg=#ff9900")
vim.cmd("hi HopNextKey2 guifg=#ff9900")

However, it would be nice if this is done directly in the colorscheme.

Setting background=light should change to the light variant of the colorscheme

Hi,

So I just had a look at using the light variant of the colorscheme and noticed that setting the background=light or dark doesn't change the appropriate version of the colorscheme. It seems it can only be enabled by changing the colorscheme manually to the new light variant name.

In most colorschemes in vim that support both a light and dark variant, simply changing the background should be enough to trigger the dark or light theme variant so a user can do

function toggle_background()*
 vim.o.background = vim.o.background == "dark" and "light" or "dark"
end

And the colorscheme can be changed on the fly with a mapping or even just setting background in the commandline.

Some examples of themes that do this are.

I think this is actually how nvim is designed to be used since you can see this in :h background

						*'background'* *'bg'*
'background' 'bg'	string	(default "dark")
		global
When set to "dark" or "light", adjusts the default color groups for
that background type.  The |TUI| or other UI sets this on startup
(triggering |OptionSet|) if it can detect the background color.

This option does NOT change the background color, it tells Nvim what
the "inherited" (terminal/GUI) background looks like.
See |:hi-normal| if you want to set the background color explicitly.
					*g:colors_name*
When a color scheme is loaded (the "g:colors_name" variable is set)
setting 'background' will cause the color scheme to be reloaded.  If
the color scheme adjusts to the value of 'background' this will work.
However, if the color scheme sets 'background' itself the effect may
be undone.  First delete the "g:colors_name" variable when needed.

Normally this option would be set in the vimrc file.  Possibly
depending on the terminal name.  Example: >

Setup function makes overriding highlights inconsistent

Hi @NTBBloodbath 👋🏿 ,

recently I noticed a setup function was added which is nice but adding it seems to make overriding highlights with my custom highlights work inconsistently. Basically my setup is that on the Colorscheme autocommand I call a custom highlight function which I have always had regardless of the colorscheme there are just certain highlights that I want a certain way no matter what colorscheme I use.

Anyway I think that since the setup function also loads the colorschemes highlights it can end up changing the highlights after the colorscheme has already loaded so it happens after the autocommand and my highlight overrides are ignored.

I'm not sure why specifically the plugin needs to load the colorscheme again after setup but am wondering if highlighting by this colorscheme can be restricted to that event otherwise it's impossible to consistently override the colorscheme's highlights.

Does this make sense?

Comments have same color as foreground for light theme

Both appear to use base5 for the light theme which makes it hard to distinguish comments from surrounding code

Bufferline highlighting

@NTBBloodbath I just noticed the changes to the bufferline highlighting, I just thought it was worth noting that I actually designed bufferline to be agnostic of colorschemes where possible.

I'm not sure where or how it started but colorscheme authors have started overriding the plugins internal highlights which I never exposed on purpose since it is not really what I intended. I would have made them private if possible, so the only way to change them was a user using their plugin config. The idea with that plugin is that someone could change between like 10 colorschemes and their bufferline would look roughly the same, but now all sorts of different colours are applied by different themes.

Can this change please be optional, since I'd rather at least the option of things behaving normally.

For example, my bufferline now looks like

The separator colour is greenish and the bufferline fill is changed to be the same as the tabs themselves which breaks the effect of it being like a darker shadowed background (which was the original intent)

Lol sorry for the long spiel, definitely something I've been thinking about a lot with that plugin and just happened to land here since this is the theme I use.

Mac use doom-one

Am I using it wrong?

I just downloaded it and used it without doing anything else, but it didn't work

[Bug report] bad argument #2 to '?' (number expected, got nil)

Hello there, hope you're doing well.

I updated today and got the following error:

Error detected while processing /home/user/.config/nvim/init.lua:
E5113: Error while calling lua chunk: /home/user/.config/nvim/lua/core/colors.lua:36: Vim(colorscheme):
E5113: Error while calling lua chunk: ...te/pack/packer/start/doom-one.nvim/lua/doom-one/init.lua:
448: bad argument #2 to '?' (number expected, got nil)
stack traceback:
        [builtin#89]: at 0x7f4c2be4a4b0
        ...te/pack/packer/start/doom-one.nvim/lua/doom-one/init.lua:448: in function 'set_colorscheme'
        ...site/pack/packer/start/doom-one.nvim/colors/doom-one.lua:9: in main chunk
        [C]: in function 'cmd'
        /home/user/.config/nvim/lua/core/colors.lua:36: in main chunk
        [C]: in function 'require'
        /home/user/.config/nvim/init.lua:8: in main chunk
stack traceback:
        [C]: in function 'cmd'
        /home/user/.config/nvim/lua/core/colors.lua:36: in main chunk
        [C]: in function 'require'
        /home/user/.config/nvim/init.lua:8: in main chunk

The following is the color.lua (which I didn't change anything for a long time):

-- Add color to cursor
vim.g.doom_one_cursor_coloring = false
-- terminal colors
vim.g.doom_one_terminal_colors = false
-- Enable italic comments
vim.g.doom_one_italic_comments = false
-- Enable TS support
vim.g.doom_one_enable_treesitter = true
-- Color whole diagnostic text or only underline
vim.g.doom_one_diagnostics_text_color = false
-- Enable transparent background
vim.g.doom_one_transparent_background = false

-- Pumblend transparency
vim.g.doom_one_pumblend_enable = false
vim.g.doom_one_pumblend_transparency = 20

-- Plugins integration
vim.g.doom_one_plugin_nvim_tree = true
vim.g.doom_one_plugin_whichkey = true
vim.g.doom_one_plugin_indent_blankline = true
vim.g.doom_one_plugin_lspsaga = true
vim.g.doom_one_plugin_barbar = true
vim.g.doom_one_plugin_neorg = false
vim.g.doom_one_plugin_telescope = false
vim.g.doom_one_plugin_neogit = false
vim.g.doom_one_plugin_dashboard = false
vim.g.doom_one_plugin_startify = false
vim.g.doom_one_plugin_vim_illuminate = false

vim.cmd([[colorscheme doom-one]])

:version
NVIM v0.8.0
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by builduser

Any help is much appreciated. Thank you!

Cannot distinguish selection when using `:s///c` with `hlsearch`

When using :substitute with the c flag while hlsearch is on, you cannot distinguish the selected match from the other matches. The issue seems to be that this theme sets the same highlights for Search and IncSearch. See also :h hl-IncSearch.

Transparency does not work

Transparency does not work on my neovim.

MyEnv:

NVIM v0.7.2
windows 11 - powershell 7

Error message:

packer.nvim: Error running config for doom-one.nvim: [string "..."]:0: Vim(colorscheme):E5113: Error while calling lua chunk: ...site\pack\packer\opt\doom-one.nvim/lua/doom-one/init.lua:43: 'bg' is not a valid color
stack traceback:
^I[C]: in function 'nvim_set_hl'
^I...site\pack\packer\opt\doom-one.nvim/lua/doom-one/init.lua:43: in function 'set_hl'
^I...site\pack\packer\opt\doom-one.nvim/lua/doom-one/init.lua:74: in function 'set_colorscheme'
^I...a\site\pack\packer\opt\doom-one.nvim\colors\doom-one.lua:9: in main chunk
^I[C]: in function 'cmd'
^I[string "..."]: in function <[string "..."]:0>
^I[C]: in function 'pcall'
^I...ers\fengwk\AppData\Local\nvim\plugin\packer_compiled.lua:60: in function 'try_loadstring'
^I...ers\fengwk\AppData\Local\nvim\plugin\packer_compiled.lua:96: in function <...ers\fengwk\AppData\Local\nvim\plugin\packer_compiled.lua:10>
^I[C]: in function 'pcall'
Press ENTER or type command to continue
^I...ers\fengwk\AppData\Local\nvim\plugin\packer_compiled.lua:10: in main chunk

I see is that the nvim_set_hl function cannot receive bg, what should I do?

-- init.lua 74
set_hl("EndOfBuffer", { bg = "bg", fg = "bg" })

-- init.lua 43
local function set_hl(group, values)
	vim.api.nvim_set_hl(0, group, values)
end

Only getting dark background headings

Hi! I am wondering if there is a special setting to set for getting the colorful highlights of the headings. I just copied all of the settings as described. I am only getting dark highlights:

Feature request: Option for changing the background

This is my favorite colorscheme. Any chance you could add the option to change the background to darker shades? For example, the atom one colorscheme provides such an option.

Bufferline behavior with different colors

Hi again,
I found a weird behaviour with bufferline on my machine with a lot of colours except doom-monokai-flatland.
Here is what I have with monokai-flatland:

The behaviors and colors seem correct to me.
Here is doom-one as a difference:

It is very difficult to see which tab is active and which one is inactive.

In addition, I was thinking of using a different tabline or bufferline like barbar, but deactivating tabline in doomrc results in a lot of errors with bufferline not being installed.

EDIT: The issue with barbar is coming from barbar's side, which is using a variable called "Special" that nvim does not like (and does not exist(?)).

If you need more info, please let me know!

TSFunction highlights are not being set on first loading nvim

Hi 👋🏾 ,

Thanks for working on this. I'd been hoping for a lua based alternative to the vimscript colorscheme since that was contributing quite a lot to my startup time.

One thing I've noticed since moving over though is that function highlights aren't applied until something else is triggered. Initially highlights for TSFunction aren't being coloured correctly despite the Function highlight group showing up correctly.

when I print the value of the highlight groups I see

and Function shows

so they seem to be set correctly but aren't highlighted in the buffer.

The minimal init.lua I can reproduce this with is

vim.cmd("packadd! doom-one.nvim")
vim.cmd("packadd nvim-treesitter")

vim.cmd("syntax enable")

vim.o.termguicolors = true

vim.cmd [[colorscheme doom-one]]

require("nvim-treesitter.configs").setup {
  highlight = {
    enable = true
  }
}

Just as a side note I've noticed that when I open a neogit buffer or use TSHighlightCapturesUnderCursor from treesitter-playground to investigate they suddenly appear. I'm sure it isn't really about those specific plugins but maybe something async is happening or something waiting on an autocommand maybe?

is there a way to change the color of the cursor without changing its shape?

this pertains to the option:

vim.g.doom_one_cursor_coloring = false

when I use this option, I get the cursor color, change, yes, but also the shape. could I just get the color to change?

my vim.opt cursor setup is: opt.guicursor = "n-c-sm:block,i-ci-ve:block,r-v-cr-o:block" -- block only

thanks in advance for the feedback and the theme!

transparnet background does not work

Thanks for the great color scheme. I love it. After updating to the latest version, transparent doesn't work.
The code in the Customization variables doesn't run again after calling the setup function. move this block to load_colorscheme does work. I'm not familiar with lua, so I don't know if is not elegant to just move this block into load_colorscheme function. So I made no PR. : )

Colorscheme doesn't render properly

Hello, love the colorscheme and all the work you and other contributors have put into it. I think that my issue is similar to Issue #17 by akinsho but not entirely sure so decided to make a new issue.

Environment: MacOS Catalina (10.15.7), Kitty Terminal, Fish Shell, Neovim (v0.7.0)

Problem: setup function doesn't work properly and renders the theme to look like the following:

In my plugins.lua, I have the following code snippet to install w/ packer and setup the colorscheme:

use {
  'NTBBloodbath/doom-one.nvim',
  config = [[require('colors/DOOM')]],
}

In colors/DOOM.lua, I have the following:

require('doom-one').setup({
        cursor_coloring = false,
         terminal_colors = false,
         italic_comments = false,
         enable_treesitter = true,
         transparent_background = false,
         pumblend = {
             enable = true,
             transparency_amount = 20,
         },
         plugins_integrations = {
             neorg = true,
             barbar = true,
             bufferline = false,
             gitgutter = false,
             gitsigns = true,
             telescope = false,
             neogit = true,
             nvim_tree = true,
             dashboard = true,
             startify = true,
             whichkey = true,
             indent_blankline = true,
             vim_illuminate = true,
             lspsaga = false,
        },
})

vim.cmd("colorscheme doom-one")

Now, I did notice that in my colors/DOOM.lua file if I did: vim.cmd("colorscheme rose-pine") and then vim.cmd("colorscheme doom-one"), the theme came up properly. So I don't know why I need to invoke another theme and the doom color theme for the theme to work properly. Any suggestions?

diff view regression from older version of the theme

I tried upgrading from eb45022 to the latest master of this theme, but I hit a regression with diff views.

This was the old display:

This is the new display:

so now in diff views, the syntax highlight is lost: everything is entirely red or green. That makes review when new files are added very hard, because the whole file is green, without syntax highlight, while in the old display, the background was green, but the file was syntax highlighted.

Visual mode highlight in light mode makes text hard to read

Thanks for porting this theme! In light mode, the visual mode highlighting makes a lot of the text hard to read. I've attached a screenshot for reference:

Left: nvim 0.8 in vimr with doom-one.vim
Center: nvim 0.9 in Alacritty with doom-one.nvim
Right: Doom Emacs with default light theme (The coloring is more basic, maybe because I haven't set up treesitter in Emacs.)

In Emacs, the highlight is a medium gray that leaves the text much easier to read. Could the visual-mode highlight in doom-one.nvim be changed to look like the Emacs version?