ntbbloodbath / doom-one.nvim Goto Github PK
View Code? Open in Web Editor NEWdoom-emacs' doom-one Lua port for Neovim
License: MIT License
doom-emacs' doom-one Lua port for Neovim
License: MIT License
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.
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.
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?
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:
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?
Transparency does not work on my neovim.
MyEnv:
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
Both appear to use base5
for the light theme which makes it hard to distinguish comments from surrounding code
Hello, I really enjoy this theme but I would like to change the color of the vertical split between windows.
I want to change the white to something to fit the lualine. I have tried tweaking with the theme file, specifically these settings on lines 100-102:
set_hl("WildMenu", { bg = palette.dark_blue, fg = "fg" })
set_hl("Separator", { fg = palette.bg_alt })
set_hl("VertSplit", { bg = "bg", fg = palette.gray })
But I cannot seem to get it working. Any help would be appreciated, thank you.
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: >
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!
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!
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?
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.
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)
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. : )
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?
I tried upgrading from eb45022 to the latest master of this theme, but I hit a regression with diff views.
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.
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
.
@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.
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!
Highlight groups used by the built-in spellchecker (SpellBad, SpellLocal, SpellCap, SpellRare) are not configured, and thus use their default (rather flashy) colors.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.