neovim: use mini.base16 for colorscheme

[soulsoiledit]

Switches both the neovim and nixvim modules to use mini.base16.

Closes #535

[donovanglover]

This is how base16.nvim looks for me:

And this is how mini.nvim looks:

Making this change optional would be nice.

[trueNAHO]

Making this change optional would be nice.

We could add options to enable specific color scheme setters.

@soulsoiledit, can you elaborate on how the algorithms of base16.nvim and mini.nvim plugins technically differ? For example, the mini.nvim plugin already explains its algorithm: https://github.com/echasnovski/mini.base16/blob/95db7f0ea89fbc60b321dbe23d39c1502a07a20e/lua/mini/base16.lua#L223-L257. Based on this comparison we can decide which one should be the default.

[soulsoiledit]

In this context, the algorithms don't differ at all. The algorithm described in mini-base16 only applies when you want to provide a subset of colors, ie only background, foreground, and accent. In that case, it generates a suitable palette based on those colors.

Since we are providing the full palette, mini.base16 calls this function (https://github.com/echasnovski/mini.base16/blob/95db7f0ea89fbc60b321dbe23d39c1502a07a20e/lua/mini/base16.lua#L446) instead, which does the same thing as base16-nvim, grabbing colors directly from the palette given.

I'm fine with keeping base16-nvim as the default.

[trueNAHO]

Since we are providing the full palette, mini.base16 calls this function (https://github.com/echasnovski/mini.base16/blob/95db7f0ea89fbc60b321dbe23d39c1502a07a20e/lua/mini/base16.lua#L446) instead, which does the same thing as base16-nvim, grabbing colors directly from the palette given.

In that case, why do the colors look different:

This is how base16.nvim looks for me:

And this is how mini.nvim looks:

Is it because some plugins are explicitly themed by mini.nvim?

I'm fine with keeping base16-nvim as the default.

If the premise of mini.nvim is to be base16.nvim with additional plugin support, then it might be better to make mini.nvim the default.

[soulsoiledit]

mini assigns that highlight group, builtin variables such as (this, self, etc), as part of "special symbols" within a language, while base16-nvim assigns them the same as other variables.

[trueNAHO]

In that case, why do the colors look different:

[...]

Is it because some plugins are explicitly themed by mini.nvim?

mini assigns that highlight group, builtin variables such as (this, self, etc), as part of "special symbols" within a language, while base16-nvim assigns them the same as other variables.

The visible change is probably caused by mini.nvim's intervention with Treesitter. Just search for tree in https://github.com/echasnovski/mini.base16/blob/95db7f0ea89fbc60b321dbe23d39c1502a07a20e/lua/mini/base16.lua.

[soulsoiledit]

This patch causes the following error without any additional inputs.stylix.inputs.<INPUTS>.follows declarations:

I'm not sure what's going on here. I checked the pinned version of nixpkgs in stylix, and the mini.nvim version there does seem to have mini.base16 included.

Making this change optional would be nice.

I have added this option under stylix.targets.neovim.plugin and stylix.targets.nixvim.plugin.

[trueNAHO]

This patch causes the following error without any additional inputs.stylix.inputs..follows declarations:

I'm not sure what's going on here. I checked the pinned version of nixpkgs in stylix, and the mini.nvim version there does seem to have mini.base16 included.

There is probably something wrong with my setup. I will try to test this tomorrow.

I have added this option under stylix.targets.neovim.plugin and stylix.targets.nixvim.plugin.

I performed the following changes to this PR:

• Properly merge commit 8b6d33479ef5 ("neovim: add plugin selection option") into the commits 75394d92ff3f ("nixvim: set colorscheme with mini.base16") and d58790127e38 ("neovim: set colorscheme with mini.base16")
• Rename stylix.targets.neovim.plugin to stylix.targets.neovim.colorscheme
• Improve stylix.targets.neovim.colorscheme description

[trueNAHO]

I will try to test this tomorrow.

I added my Tested-by tag to commit 7d5d9a44b317 ("nixvim: add stylix.targets.nixvim.colorscheme option").

[danth]

In that case, why do the colors look different

Ideally the color usage should be as close to the upstream style guide as possible. Our own style guide currently just refers to that link when it comes to text editors. Unfortunately, the guide isn't very specific in some cases, such as the example with this and self, hence the differences as each plugin author has used their own preference.

From the screenshots above, I personally prefer this new plugin since it differentiates between variables and boolean values in Nix, although that's just one of I assume many differences.

According to the upstream guide, nether of these are totally correct - variables should be red and booleans should be yellow (unless @donovanglover's chosen scheme has non-standard colors).

[trueNAHO]

Ideally the color usage should be as close to the upstream style guide as possible. Our own style guide currently just refers to that link when it comes to text editors. Unfortunately, the guide isn't very specific in some cases, such as the example with this and self, hence the differences as each plugin author has used their own preference.

[...]

According to the upstream guide, nether of these are totally correct - variables should be red and booleans should be yellow (unless @donovanglover's chosen scheme has non-standard colors).

Until the style guide has been expanded 1, it won't hurt to provide a new colorscheme plugin. Once the VIM highlight groups are implemented in Stylix 1, we can replace both colorscheme plugins with the VIM highlight groups.

[donovanglover]

I think the colors are different due to nvim-lspconfig and treesitter. I mainly like base16-nvim for its usage of italics and other style differences (like export being blue in JS/TS) but it does seem different than the spec.

Theme is selenized-black if anyone wants to try it.

[trueNAHO]

@soulsoiledit, could summarize the status of this PR or what is blocking it from our side?

[soulsoiledit]

On my end, it's telling me that it needs another review apart from the last pusher (you).

[soulsoiledit]

On my end, it's telling me that it needs another review apart from the last pusher (you).

@danth Could you help out? :)

[trueNAHO]

@danth, can you do a merge commit for this PR? AFAIK, I only have permission to do squash commits via the GitHub UI.

[danth]

@trueNAHO done :)