Closed 231tr0n closed 3 months ago
Hi @231tr0n! Thanks for raising the issue. I'll be adding support for fzf-lua very soon :)
Hello @echasnovski!
Hope I'm not being too cheeky asking this of you, but I can see you've made contributions to several other colorschemes just in the last day. I thought I'd jump on the opportunity to see if you'd be interested in adding Offical Mini Support™ to cyberdream.nvim as well. Would love input from the original author!
@231tr0n I've added a borderless theme for fzf-lua that looks like this:
This mimics the default telescope theme quite closely. For it to look correct, you need to set fzf_colors
to true
in your fzf config. E.g.
return {
"ibhagwan/fzf-lua",
dependencies = { "nvim-tree/nvim-web-devicons" },
config = function()
require("fzf-lua").setup({
fzf_colors = true,
})
end,
}
@scottmckendry, Is support for vim-fugitive possible. I did not want to create a new defect, so I modified the existing one. If possible can you make the diff changes a bit darker if this is planned. Currently, they are way too light in color.
Hello @echasnovski!
Hope I'm not being too cheeky asking this of you, but I can see you've made contributions to several other colorschemes just in the last day. I thought I'd jump on the opportunity to see if you'd be interested in adding Offical Mini Support™ to cyberdream.nvim as well. Would love input from the original author!
Hi @scottmckendry!
Since you are the first one to ask this (and nicely so), here you go. I'd like to explicitly stress though, that this is not an Offical Mini Support™, but my attempt to make 'mini.nvim' experience more pleasant for users. I'd much rather enjoy seeing that color scheme authors or their users add this kind of support on their own (it is explicitly stated as a welcome way to contribute to 'mini.nvim' with an explicit list of highlight groups needed for full support).
I would also like to give some feedback for issues that were apparent when adding 'mini.nvim' support:
Visual
highlight group defines both foreground and background. This is generally ok (although I prefer background only), but the result has way too low contrast ratio (1.71, to be exact). To the point that text is barely readable.Diff*
highlight only through foreground is rarely a good choice for usability. Mostly because they are used to highlight already highlighted text. Using background highlighting is usually a better choice. I'd prefer something like what is used for MiniDiffOverXxx
highlight groups in PR.CursorLine
and CursorColumn
highlight groups define lines used to quickly locate cursor on screen. As cursor can be used in floating windows, it is reasonable to have those two groups be such that they are visible both in normal and floating windows. Hence I am not really sure what the purpose of custom MiniFilesCursorLine
is.util.blend()
in the highlight group definitions. This allows for a more coherent future definitions in plugin extensions.Hope this helps.
You're a ⭐ @echasnovski! Thanks for the excellent feedback. Especially around useability and contrast. I want the colorscheme to be as friendly as possible for users and contributors alike.
Appreciate all your hard work on neovim and mini! It's people like you that make the neovim community such a pleasure to be a part of 💚
@231tr0n I've fixed the highlights for vim-fugitive's :Git diff
command in the latest commit. As far as I can tell, everything else looks pretty good out of the box. If you spot anything else, let me know 🙂
@scottmckendry The mini.statusline and MiniHiPatterns dont look properly with the latest changes. MiniHipatternsNote MiniHipatternsTodo MiniHipatternsHack MiniHipatternsHack MiniStatuslineModeReplace MiniStatuslineModeCommand MiniStatuslineModeInsert MiniStatuslineModeVisual MiniStatuslineModeNormal MiniStatuslineModeOther are the related highlight groups afaik. Is it possible to change these properly for better visibility?
Should be resolved now. Pretty sure this would only be an issue when transparency is enabled - due to the bg
color being set to "NONE". Let me know if the most recent change fixes it 👍🏻
Should be resolved now. Pretty sure this would only be an issue when transparency is enabled - due to the
bg
color being set to "NONE". Let me know if the most recent change fixes it 👍🏻
@scottmckendry yup it fixes it. One last addon, currently if we open buffers horizontally using :split command, there is visually no seperator spearating the two buffers horizontally. Vertically there is a line but my doubt was can something be done about this horizontally. As you can see in the above picture there are 4 buffers open altough I can hardly distinguish the two horizontally open buffers on the left pane. Can some kind of separator be put for this one particular scenario if possible.
Oh, that's an easy one! Just set hide_fillchars
to false
(or remove the option entirely since this is the default) in your config and the separators will reappear 🙂
Oh, that's an easy one! Just set
hide_fillchars
tofalse
(or remove the option entirely since this is the default) in your config and the separators will reappear 🙂
It is false in my case but still i dont see any separators horizontally.
Hmmm... I'm not 100% sure what that could be then. Could you try defining the fillchar manually in your config?
This line here, update it to vim.o.fillchars = [[eob: ,fold: ,foldopen:,foldsep: ,foldclose:,horiz:─]]
to see if there's any change.
If not, it might be getting overridden somewhere else.
Hmmm... I'm not 100% sure what that could be then. Could you try defining the fillchar manually in your config? This line here, update it to
vim.o.fillchars = [[eob: ,fold: ,foldopen:,foldsep: ,foldclose:,horiz:─]]
to see if there's any change.If not, it might be getting overridden somewhere else.
It is still the same even after the change you suggested.The thing is vertical line is coming, only horizontal is the issue.
Looks like it might be a global statusline thing. If you run :set laststatus=3
does that fix it?
Looks like it might be a global statusline thing. If you run
:set laststatus=3
does that fix it?
Yup this fixes it. Thank you soo much @scottmckendry.
CLosing this issue.
You're a ⭐ @echasnovski! Thanks for the excellent feedback. Especially around useability and contrast. I want the colorscheme to be as friendly as possible for users and contributors alike.
Appreciate all your hard work on neovim and mini! It's people like you that make the neovim community such a pleasure to be a part of 💚
You're welcome! Best of luck keeping up with the not-always-easy burden of maintaining a color scheme.
- Having
Diff*
highlight only through foreground is rarely a good choice for usability. Mostly because they are used to highlight already highlighted text. Using background highlighting is usually a better choice. I'd prefer something like what is used forMiniDiffOverXxx
highlight groups in PR.
I've remembered the other (probably more prominent) reason why Diff*
highlight groups usually have distinctive background. DiffAdd
, DiffChange
, and DiffDelete
are used to highlight whole lines, meaning the part after end of line is also highlighted. If there is no background attribute in those highlight groups, this is not visible. And there is also an issue of highlighting whitespace with these groups.
I've just added a fix for this in the latest commit. Gave it a spin with diffview.nvim and it looks SOO much better! Thank you again 🙂
Question or Suggestion
Can support for entire mini.nvim suite and fzf-lua be added. Currently this theme doesn't support mini.statusline, mini.indentscope afaik.