Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tidy and unified UI #698

Closed
vollowx opened this issue May 2, 2023 · 42 comments · Fixed by #833
Closed

Tidy and unified UI #698

vollowx opened this issue May 2, 2023 · 42 comments · Fixed by #833
Labels
cmp Nvim-cmp related issues complexity:non-trivial Self-contained but non-trivial amount of work enhancement New feature or request file-explorer Nvim-tree related issues

Comments

@vollowx
Copy link

vollowx commented May 2, 2023

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.

  1. same appearance for cmp and wilder
  2. clear appearance for bufferline and nvim-tree
  3. colored indent-blankline
  4. similar highlights for indent lines in nvim-tree, indent-blankline and outline of lspsaga

image

image

So I'm here to get to know if I could give a PR.

@vollowx vollowx added the enhancement New feature or request label May 2, 2023
@vollowx

This comment was marked as outdated.

@CharlesChiuGit
Copy link
Collaborator

CharlesChiuGit commented May 2, 2023

@Jint-lzxy 's #676 PR should alleviate some of your issues. It's mostly from upstream, so it needs more time to finish it.

@vollowx

This comment was marked as outdated.

@CharlesChiuGit
Copy link
Collaborator

ys, of course u can send pr about 2, 3, 4 first!

@vollowx

This comment was marked as outdated.

@Jint-lzxy
Copy link
Collaborator

@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):

telescope-new-ui

@Jint-lzxy Jint-lzxy added complexity:non-trivial Self-contained but non-trivial amount of work cmp Nvim-cmp related issues file-explorer Nvim-tree related issues labels May 2, 2023
@vollowx

This comment was marked as outdated.

@Jint-lzxy
Copy link
Collaborator

Should windows / floating window have border or not?

The following is the concept I plan to adopt:

  1. Border(s) should be used as a separator to distinguish between two rendering regions, as windows without border(s) still behave like having right-angled borders with 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)
  2. If a border is used for some reason, then:
    i. A right-angled border should be used as a "true" separator because it is less decorative than a rounded border. It should be mainly used to distinguish between two primary windows (e.g., the editor and nvim-cmp);
    ii. Rounded border(s) shall be used for other purposes, such as decorating 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 👍

dim_inactive = {
enabled = false,
-- Dim inactive splits/windows/buffers.
-- NOT recommended if you use old palette (a.k.a., mocha).
shade = "dark",
percentage = 0.15,
},

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) :)

@vollowx

This comment was marked as outdated.

@nullchilly
Copy link
Contributor

nullchilly commented May 3, 2023

Here is a sneak peak of Telescope's new UI (based on your PR):

telescope-new-ui

More than happy to merge this upstream under telescope = { nvchad = true }. However, I think the current Visual bg is a little hard to see:

image

@vollowx vollowx changed the title Update highlights for cmp, wilder, indent-blankline and nvim-tree. Tidy and unified UI May 6, 2023
@vollowx

This comment was marked as outdated.

@vollowx

This comment was marked as outdated.

@vollowx

This comment was marked as outdated.

@CharlesChiuGit
Copy link
Collaborator

i think it's better to discuss the following polls or issues under the pr, so we don't need to check two places 😹

@vollowx

This comment was marked as outdated.

@CharlesChiuGit
Copy link
Collaborator

CharlesChiuGit commented May 7, 2023

aha, sorry about that. i checked on my phone, so i thought the git diffs are the diagnostics lol

@vollowx
Copy link
Author

vollowx commented Jun 10, 2023

Progress

@vollowx

This comment was marked as resolved.

@vollowx
Copy link
Author

vollowx commented Jun 10, 2023

Unsure styles for indent-blankline

image

Differences

  • Highlight current level start and with surface0 bg.
  • Highlight current level indent line with surface1 fg.

@ayamir
Copy link
Owner

ayamir commented Jun 11, 2023

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.

@ayamir
Copy link
Owner

ayamir commented Jun 11, 2023

Unsure styles for nvim-tree

image

Differences

  • Filenames highlighted.
  • Git icons moved to the right.
  • Git ignored files will still display, but with grey color.

I like it.

@vollowx
Copy link
Author

vollowx commented Jun 11, 2023

Unsure styles for lualine

image

Ref

@vollowx

This comment was marked as resolved.

@ayamir
Copy link
Owner

ayamir commented Jun 11, 2023

Unsure styles for lualine

image

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.

@CharlesChiuGit
Copy link
Collaborator

CharlesChiuGit commented Jun 12, 2023

Unsure styles for nvim-tree

I like it too!

Unsure styles for indent-blankline

LGTM!

@ayamir
Copy link
Owner

ayamir commented Jun 17, 2023

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.

@vollowx
Copy link
Author

vollowx commented Jun 17, 2023

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)

image

Also, what about changing cmdheight from 2 to 1? The current command line may takes too much place.

@ayamir
Copy link
Owner

ayamir commented Jun 17, 2023

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)

image

Also, what about changing cmdheight from 2 to 1? The current command line may takes too much place.

LGTM.

@vollowx
Copy link
Author

vollowx commented Jun 17, 2023

Do we need such a lot file information? Maybe we can check this out first.

image

@Jint-lzxy
Copy link
Collaborator

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 from 2 to 1? The current command line may takes too much place.

Agreed

@Jint-lzxy
Copy link
Collaborator

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.

@vollowx
Copy link
Author

vollowx commented Jun 17, 2023

image

A little bit hard to see.

@vollowx
Copy link
Author

vollowx commented Jun 17, 2023

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.

image

image

* Why I moved Git diff to section c, or try some other solutions.

* Config

@ayamir
Copy link
Owner

ayamir commented Jun 17, 2023

image

A little bit hard to see.

Agree

@vollowx
Copy link
Author

vollowx commented Jun 23, 2023

IMO the original lualine highlights are too shiny, so here's my new idea.

image

@ayamir
Copy link
Owner

ayamir commented Jun 23, 2023

IMO the original lualine highlights are too shiny, so here's my new idea.

image

IMO no need for the filename due to duplicate with bufferline.

@vollowx
Copy link
Author

vollowx commented Jun 23, 2023

IMO the original lualine highlights are too shiny, so here's my new idea.
image

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.

@Jint-lzxy
Copy link
Collaborator

IMO the original lualine highlights are too shiny, so here's my new idea.

image

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

@ayamir
Copy link
Owner

ayamir commented Jun 28, 2023

we could then propose a new major release

Indeed, tons of changes have been pushed and a release is required 👍

@vollowx
Copy link
Author

vollowx commented Jun 30, 2023

IMO the original lualine highlights are too shiny, so here's my new idea.
image

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/...)

image

What about making a plugin like NvChad/base64 for united user experience between different color schemes? Or you may give some other advises.

@Jint-lzxy
Copy link
Collaborator

Jint-lzxy commented Jun 30, 2023

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

@vollowx
Copy link
Author

vollowx commented Jun 30, 2023

Got it, will a PR soon (the structure may be lengthy and jumbled, you probably need to modify it a lot 🤔 )

EDIT: at #833

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmp Nvim-cmp related issues complexity:non-trivial Self-contained but non-trivial amount of work enhancement New feature or request file-explorer Nvim-tree related issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants