Closed vollowx closed 1 year ago
update: highlight for lspsaga's outline lspsaga#1050
@Jint-lzxy 's #676 PR should alleviate some of your issues. It's mostly from upstream, so it needs more time to finish it.
You mean some of the problems are from catppuccin/nvim
right? So I will wait for them :P
They other changes are not problems, they are just for customization (2, 3 and 4)
ys, of course u can send pr about 2, 3, 4 first!
pr is ready at #699
@huge-pancake Many thanks for your contribution 👍 But due to the complexity of #676 (most highlight groups and actual hex codes for those antonomasias [e.g., C.base -> #1E1E2E
] will undergo significant changes), hence to avoid repetitive work, this PR will be merged after #676 is completed. I will also refer to your PR while reimplementing those hl groups.
Here is a sneak peak of Telescope's new UI (based on your PR):
Got it, hope #676/upstream update will come out soon.
Also there're some problems I haven't solve yet:
settings.lua
to control this. (also see catppuccin/nvim#439)WinSeparator
to hide border in outline (lspsaga) like nvim-tree, but this will influence all the borders between window and window. Maybe lspsaga should provide a highlight OutlineBorder
. (may be solved in nvimdev/lspsaga.nvim#1054)crust
) should be lighter (NvChad) than the color of the tabs or darker (default, VSCode)?Btw, I think in the field of UI, NvChad relly does very well.
Should windows / floating window have border or not?
The following is the concept I plan to adopt:
hl-Normal
as foreground. Hence, say if two overlapping windows won't make it hard for users to distinguish between them, the border(s) should be omitted and colors (bg) with different saturation levels should be used for differentiation. (For example, Telescope
)null-ls
's information window (since its highlight (bg) defaults to hl-Normal
, which makes it difficult for users to distinguish between those windows).It should be decided by users themselves
I'm not very supportive of allowing users to customize such option b/c it is difficult to manage the borders of all plugins using the same interface. Additionally, for some windows users may not want to have borders enabled, while for some other they may wish they could have different colors. However, the way(s) to configure color- and border-style for a specific window differentiates from plugins to plugins (API differences), plus the fact that those values must be supplied during initialization (using border-character or style names) - this ultimately leads to a lot of work while still making it hard to meet all the needs. IMHO If users really want to change these appearances, they should make changes to a specific config file themselves.
but this will influence all the borders between window and window
Hmm AFAIK this is impossible with nvim 0.9, as it requires low-level API support (providing an option to set window-specific hl-VertSplit
when creating a new split). But let's wait and see how glepnir would handle this 😄
Bufferline's inactive background ... should be lighter ...
Actually catppuccin provides such option (dim_inactive), but this was not adopted due to several design defects. IMO now it's time to introduce this back to the config 👍 https://github.com/ayamir/nvimdots/blob/3be4c9bc862ce8f67e4ce712cff893b96d215754/lua/modules/configs/ui/catppuccin.lua#L7-L13
Btw, I think in the field of UI, NvChad relly does very well.
💯💯 Agreed. In fact, I took heavy inspiration from NvChad's UI design (as a stepping-stone for further configuration) :)
Here is a sneak peak of Telescope's new UI (based on your PR):
![]()
More than happy to merge this upstream under telescope = { nvchad = true }
. However, I think the current Visual bg is a little hard to see:
I added something more, the PR is now at #718 (to follow branch naming spec).
I also made a new lualine style like this
Not sure if I should add it into the PR.
Highlights become broken when transparent_background
is true
i think it's better to discuss the following polls or issues under the pr, so we don't need to check two places 😹
Highlights are now fixed at this commit.
i think it's better to discuss the following polls or issues under the pr, so we don't need to check two places joy_cat
Sure.
duplicate diagnostic sections
hmm I didn't see any duplicate sections
mode | filetype, filename | branch, diff /// /// disgnostic | workspace | location
aha, sorry about that. i checked on my phone, so i thought the git diffs are the diagnostics lol
Progress
Telescope
, #772, #783cmp
and wilder
, #772ts-context
, #772alpha
with default highlight names, #772nvim-tree
with Git highlight, #800bufferline
with less shiny highlights working with nvim-tree
and lspsaga
indent-blankline
with current level highlights, #803lualine
with new UI, #833Unsure styles for nvim-tree
Differences
Unsure styles for indent-blankline
Differences
surface0
bg.surface1
fg.Highlights are now fixed at this commit.
i think it's better to discuss the following polls or issues under the pr, so we don't need to check two places joy_cat
Sure.
duplicate diagnostic sections
hmm I didn't see any duplicate sections
mode | filetype, filename | branch, diff /// /// disgnostic | workspace | location
IMO no need to add filename to lualine
because it already appears in bufferline
.
Unsure styles for
nvim-tree
Differences
- Filenames highlighted.
- Git icons moved to the right.
- Git ignored files will still display, but with grey color.
I like it.
Unsure styles for
nvim-tree
Differences
- Filenames highlighted.
- Git icons moved to the right.
- Git ignored files will still display, but with grey color.
I like it.
Will make a pr next week.
Unsure styles for
lualine
Ref
Maybe it's better to swap the position of lsp servers and project dir. Because not all of files have lsp support, it will be more distinguishable.
Unsure styles for
nvim-tree
I like it too!
Unsure styles for
indent-blankline
LGTM!
be it's better to swap the position of lsp servers and project dir. Because not all of files have lsp support, it will be more distinguishable.
ok for me.
Maybe it's better to swap the position of lsp servers and project dir. Because not all of files have lsp support, it will be more distinguishable.
Maybe move both LSP servers and diagnostics to the center, move project directory and Python environment to the right like this?
(the Python environment can be displayed as well, though I don't use python so that it's not in the image)
Also, what about changing cmdheight
from 2
to 1
? The current command line may takes too much place.
Maybe it's better to swap the position of lsp servers and project dir. Because not all of files have lsp support, it will be more distinguishable.
Maybe move both LSP servers and diagnostics to the center, move project directory and Python environment to the right like this?
(the Python environment can be displayed as well, though I don't use python so that it's not in the image)
Also, what about changing
cmdheight
from2
to1
? The current command line may takes too much place.
LGTM.
Do we need such a lot file information? Maybe we can check this out first.
Maybe move both LSP servers and diagnostics to the center, move project directory and Python environment to the right like this?
💯 Agreed! I mean we can classify those components as:
-------------------------------------------------------------------------------
|Normal|main|<ft-icons>| LSP~ |~/.config/nvim|<multi-sec>|50:1|
a b c (center) x y z
-------------------------------------------------------------------------------
| | | | | | |
| | | LSP-related stuffs |-- workspace | |
| | | (might be empty) fileinfo -----| |
| | |------ edit status (RO, [+]...) |
| |----- git editor info ----|
|---- edit modes
The reason why LSP is placed in the center is b/c there'll be no missing components on the left- and right-hand sides under those unsupported file types.
Also, what about changing
cmdheight
from2
to1
? The current command line may takes too much place.
Agreed
Do we need such a lot file information?
FWIW we should first classify those components and then discuss what might be filled in for each section.
A little bit hard to see.
Do we need such a lot file information?
FWIW we should first classify those components and then discuss what might be filled in for each section.
* Why I moved Git diff to section c, or try some other solutions.
* Config
A little bit hard to see.
Agree
IMO the original lualine highlights are too shiny, so here's my new idea.
IMO the original lualine highlights are too shiny, so here's my new idea.
IMO no need for the filename due to duplicate with bufferline.
IMO the original lualine highlights are too shiny, so here's my new idea.
IMO no need for the filename due to duplicate with bufferline.
It's only for myself as I set the bufferline
option always_show_bufferline
to false
, it'll be filled with something other (as the spec @Jint-lzxy gave, like file state) if this really be merged.
IMO the original lualine highlights are too shiny, so here's my new idea.
LGTM! @volpan It would be great if you could push a commit for this! I will make several minor adjustments, and if everything looks good, we could then propose a new major release 👍
btw, thanks very much for sticking with us! :D
we could then propose a new major release
Indeed, tons of changes have been pushed and a release is required 👍
IMO the original lualine highlights are too shiny, so here's my new idea.
LGTM! @volpan It would be great if you could push a commit for this! I will make several minor adjustments, and if everything looks good, we could then propose a new major release +1
btw, thanks very much for sticking with us! :D
Just wondering how can I sync this color scheme to every palette because I rebuilt the whole color scheme. (It can't work even with Catppuccin-Latte/...)
What about making a plugin like NvChad/base64 for united user experience between different color schemes? Or you may give some other advises.
Just wondering how can I sync this color scheme to every palette \<...>
@volpan What u need is a function for ur custom theme and have that registered under <event> ColorScheme
(this works only for catppuccin
but can be expanded to fit any colorscheme):
--- lualine.lua
return function()
----------- other configs -----------
local custom_theme = function()
local cp = require("catppuccin.palettes").get_palette()
return {
normal = {
a = { bg = cp.lavender, fg = cp.mantle, gui = "bold" },
b = { bg = cp.surface1, fg = cp.lavender },
c = { bg = cp.mantle, fg = cp.text },
}
-- More configs...
}
end
vim.api.nvim_create_autocmd("ColorScheme", {
group = vim.api.nvim_create_augroup("LualineColorScheme", { clear = true }),
pattern = "*",
callback = function()
require("lualine").setup({ options = { theme = custom_theme() } })
end,
})
----------- other configs -----------
require("lualine").setup({
options = {
theme = custom_theme(),
},
-- More configs...
})
end
Got it, will a PR soon (the structure may be lengthy and jumbled, you probably need to modify it a lot :thinking: )
EDIT: at #833
Straightly go to this comment.
Feature description
The highlights for cmp, nvim-tree, wilder and indent-blankline now is untidy and always catch my focus when I should focus on my code.
Additional information
I had already modified the highlights for them.
So I'm here to get to know if I could give a PR.