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

Make Catppuccin consistent across plugins in regards to floating windows #439

Closed
89iuv opened this issue Mar 24, 2023 · 4 comments
Closed
Labels
enhancement New feature or request

Comments

@89iuv
Copy link
Contributor

89iuv commented Mar 24, 2023

Thank you very much for this wonderful theme that for me it has become the face of neovim.

There are inconsistencies between how floating windows are displayed.
For the purpose of visualizing the problem i have provided screenshots from telescope, which-key and nvim-cmp.

Default:

Screenshot 2023-03-24 at 07 16 15

Screenshot 2023-03-24 at 07 16 44

Screenshot 2023-03-24 at 07 18 27

Given the fact that every plugin can choose how to implement the border for it's window this was inevitable but it can be fixed.

Solution1: with borders

Screenshot 2023-03-24 at 07 33 44

Screenshot 2023-03-24 at 07 42 17

Screenshot 2023-03-24 at 07 42 04

Solution2: no borders

Screenshot 2023-03-24 at 07 19 47

Screenshot 2023-03-24 at 07 20 13

Screenshot 2023-03-24 at 07 20 39

Issue with solution2
in order to distinguish the floating window from the rest of the application, the background color needs to be somewhere between base and overlay2.
To close to base and it will blend with the buffer.
To close to overlay2 and it tends to blend with cursor line and comments making it hard to distinguish them.

The question

What would be a guideline in regards to floating windows and borders in order to have a consistent experience across plugins in Catppuccin?

I would be happy to help with PR to address this inconsistencies.

@89iuv 89iuv added the enhancement New feature or request label Mar 24, 2023
@nullchilly
Copy link
Contributor

nullchilly commented Mar 24, 2023

Hey, thank you so much for such high effort suggession!

Chapter 1: With borders

nvim-cmp is a different beast, we will need users to manually add this to their configuration. In fact I wanted to add border option for cmp a long time ago but never managed to find the time. Some possible option would look like:

cmp = {
  enabled = true,
  border = {
    completion = true,
    documentation = true
  }
}
{
  "hrsh7th/nvim-cmp",
  opts = {
    window = {
      completion = {
        border = { "", "", "", "", "", "", "", "" },
        winhighlight = "Normal:CmpPmenu,FloatBorder:CmpBorder,CursorLine:PmenuSel,Search:None",
      },
      documentation = {
        border = { "", "", "", "", "", "", "", "" },
        winhighlight = "Normal:CmpPmenu,FloatBorder:CmpBorder,CursorLine:PmenuSel,Search:None",
      },
    },
  },
},

It might look something like this:

image

Chapter 2: No borders

We used to have telescope with no border by default but some people didn't like it

I think we can add an option for telescope

telescope = {
  enabled = true,
  border = false
}

image

In the screenshot you provided Find files is a little hard to notice, I would prefer something similar to nvchad's integration:

image

Chapter 3: Consistency

One important aspect to take into consideration is personal preference, personally I don't think which-key needs a border

image

I also want telescope with no border and cmp with border but just for completion.

We can provide a floating_border option. Due to the ad-hoc nature of floating windows implementation in each plugin, I think we should default to "auto" instead of trying to be consistency out of the box

require("catppuccin").setup {
  floating_border = "auto" | "on" | "off"
}

If off it would be equivalent to

require("catppuccin").setup {
  integration = {
    telescope = { enabled = true, border = false },
    cmp = { enabled = true, border = false },
    which_key = { enabled = true, border = false }
  }
}

@89iuv
Copy link
Contributor Author

89iuv commented Mar 24, 2023

I like the idea of having a global variable to toggle the borders on | off or auto, and then using plugin specific configuration to override the border per plugin.
It makes it easy to have a consistent experience while also providing the flexibility to chose and match styles across different plugins.

On issue i still have is in regards to the background color of the floating window.
Here we have the situation where not all floating windows have the same background and if you select to have no border then it will blend with either the file explorer or the editor.

One solution could be to use crust for all floating windows which will ensure that they are visible distinguishable from the file explorer and editor irrespective of the border settings.

What do you thing would be a good color choice for floating window border and floating window background?

@nullchilly
Copy link
Contributor

nullchilly commented Mar 24, 2023

I think we can set bg to NONE with border on, something like this would work:

Pmenu = { bg = border and C.none or C.crust }

@89iuv
Copy link
Contributor Author

89iuv commented Mar 31, 2023

The conclusion of this issue is that catppuccin is responsible to configure how the floating window border looks but it is up to the user to configure if a floating window has or does not have a border and what type of border characters to use.

While in some situation we "fake" the absence of a floating window border by setting the bg and fg to the same color, we can not "fake" the presence of a border where a border was not added.

The best approach here is to link from the plugin highlights back to the catppuccin highlights so that the settings will propagate from theme to plugin.
The user can then decide to add or remove the border of the plugin and he can also overwrite the highlight groups of the theme( and propagate the changes to the plugins), or the plugin only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants