Colors messed up with simple config

[gwww]

Using the new 2.0, with this simple config many colors end up changed from their default. When I run without a config the colors are much different. Since I'm not changing any colors it feels like a bug.

require("nightfox").setup {
  options = {
    styles = {
      comments = "italic",
    },
  },
}

vim.cmd "colorscheme nightfox"

Here is what I see on screen with the above config:

Here is what I see on screen when I use the config shown in the picture below:

[EdenEast]

Are there any errors that are thrown? Do you have a way of reproducing this issue. I am unable to reproduce your issue on my side. There is a minimal_init.lua that is a template for reproduceable configurations. Does the same issue happen when using this file?

[gwww]

Same with the minimal init.lua. Here is the init.lua:

-- `minimal_init.lua` used for reproducible configuration
-- Open with `nvim --clean -u minimal_init.lua`

local is_windows = vim.fn.has("win32") == 1
local function join(...)
  local sep = is_windows and "\\" or "/"
  return table.concat({ ... }, sep)
end

local root_tmp = is_windows and os.getenv("TEMP") or "/tmp"
local site_path = join(root_tmp, "nvim", "site")
local pack_path = join(site_path, "pack")
local install_path = join(pack_path, "packer", "start", "packer.nvim")
local compile_path = join(install_path, "plugin", "packer_compiled.lua")
vim.opt.packpath = site_path

local function load_plugins()
  local packer = require("packer")
  local use = packer.use
  packer.reset()
  packer.init({ compile_path = compile_path, package_root = pack_path })

  use("wbthomason/packer.nvim")
  use("EdenEast/nightfox.nvim")
  -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE

  packer.install()
end

_G.load_config = function()
  -- ADD INIT.LUA SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
  require("nightfox").setup({
      options = {
        styles = {
          comments = "italic",
        },
      },
  })

  vim.cmd('colorscheme nightfox')
end

if vim.fn.isdirectory(install_path) == 0 then
  vim.fn.system({ "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path })
end
load_plugins()
vim.cmd([[autocmd User PackerComplete ++once echo "Ready!" | lua load_config()]])

The images show both the colors I see on screen and the editing on the init.lua being used.

I'm using nvim 0.6.1 on M1 Mac. My nvim config directory has only the file init.lua in it.

The only thing that appear a bit odd in that I can't explain it is that without the setup options I don't see the "Ready!" message. With my setup options I do see the "Ready!" message.

Without the nightfox setup options:

With the nightfox setup options:

[EdenEast]

Hmmm that is very weird. What terminal are you using? were you able to view italics before? Does the same thing happen if you checkout the [v1.0.0](https://github.com/EdenEast/nightfox.nvim/tree/v1.0.0] tag? Also just to make sure you dont have compiled files. This can be checked with :NightfoxStatus and cleaned with :NightfoxClean (guessing that that is not the issue because the minimal_init also has the issue)

[gwww]

I use wezterm but just tried on iTerm2 without any difference.

I was using the 1.0.0 tagged version for about a month. Config here: https://github.com/gwww/dotfiles/blob/main/.config/nvim/lua/plugins/nightfox.lua It was working as expected.

I already had run :NightfoxStatus and it had X's for all the compiled entries.

I have switched back and forth between the 1.0.0 and new version a number of times while testing.

Is there any debugging I can try? I tried putting a couple of print statements in config.lua but they did not print. I think its getting called, not sure why the prints did not show up.

What version are nvim are you running? Could it be there's differences there?

[gwww]

I just ran nvim with -V20. Once with empty setup and once with the "broken" setup. I diff'ed the two logs. The only difference is the empty setup has about 300 highlight commands in it. The broken setup has none. Not sure what that means or why.

[EdenEast]

I am also using wezterm. For my neovim I use nightly

nvim -v

``` NVIM v0.7.0-dev Build type: Release LuaJIT 2.1.0-beta3 Compiled by nixbld Features: +acl +iconv +tui See ":help feature-compile" system vimrc file: "$VIM/sysinit.vim" fall-back for $VIM: " /nix/store/k0ycdg3znwf9z7ls867vg6wh3bqgqv74-neovim-unwrapped-master/share/nvim " Run :checkhealth for more info ```

If you are using nvim 0.7 have you updated your nightly recently. Now that I think about it I am trying out the new nvim_set_hl api that was added to the nightly. If you are on nightly but dont have that function then you would not get anything. If that is the case I should add to the current check to see if the nightly version also has the function. The current highlighting function is here.

A quick check if that is the issue would be to compile the theme with :NightfoxCompile (as the compile file does not use the new api yet) and see if that fixes it. I am going to add another guard around the nvim version either way.

[gwww]

I'm not running nightly. I've been trying to stay on stable once 0.6.0 dropped. So, does that explain it then -- nvim_set_hl is not in 0.6?

I think this means the Requirements section in the readme is out of date... might need neovim 0.7+. I can't imagine vim with lua works at all -- just a guess.

Trying a compile now.

[EdenEast]

Yes that is currently on nightly set for next release. If you compile does that work? if so then the check might not be correct.

[EdenEast]

Ah ok so I used 0.6.1 and it looks like I get the same issue. Looks like checking if nvim version is 0.7 does not pass. I will remove the nvim version until I do a better validation with different nvim versions

[gwww]

Running compile worked!

Maybe conditionally use nvim_set_hl if not on 0.7?

[EdenEast]

Just ran vim.fn.has("nvim-0.7") and it returns either 0 or 1 instead of true or false. Thank you helping me debug this!

[EdenEast]

Merged change should be resolved now. Please let me know if your issue is resolved or I should re-open your issue

[gwww]

I tested it and it works! Amazing how one wee little test took out the whole plug-in. Thanks for the plug-in and for the fix!!