Background transparency setting broken

[baco]

Until 2 days ago I used to have the following working settings: init.vim:

let g:vscode_style = 'dark'
let g:vscode_transparent = v:true

silent! colorscheme vscode

but, as I only wanted background transparency on terminals and not on other UIs, I also had: ginit.vim:

if exists('g:colors_name') && g:colors_name == 'vscode'
    let g:vscode_transparent = v:false
    syntax reset
endif

all working like a charm. Transparent background on terminals default VSCode-like background otherwise.

After a recent merge, both settings stopped working. The documentation about them is gone, and there is no indication on how to keep having the settings in vim-script as it used to.

[Mofiqul]

Now you can achieve the same using the setup function.

Just overrides the Normal group like below

group_overrides = {
    -- this supports the same val table as vim.api.nvim_set_hl
    -- use colors from this colorscheme by requiring vscode.colors!
    Normal = { fg = c.vscFront, bg = 'NONE' },
}

You can also do transparent = true setup function

[baco]

I understand, but the setup function is Lua. For the time being I have not migrated my init.vim nor ginit.vim to init.lua (and I can not find the time to do that either, right now).

Perhaps you are suggesting I include something like lua require('vscode').setup({ transparent = true }) in my current init.vim. I've also detected an issue with that, calling :lua require('vscode').setup({ transparent = false }) later on to try to restore the background inside a Nvim UI (Nvim-GTK to be precise) doesn't bring the background back once it's been set to 'NONE'.

[Mofiqul]

It's because once you set transparent=true that vscBack is overwritten by NONE from #1e1e1e.

For your use case, you can use

local c = require('vscode.colors')
require('vscode').setup({
    transparent = false,
    group_overrides = {
        Normal = { fg=c.vscFront, bg= (vim.g.colors_name and vim.g.colors_name == 'vscode') and c.vscBack or c.vscNone},
    }
})

[Mofiqul]

@yochem also added backward compitibility. your existing setup supposed to work but sadly its not. In my setting its working. I am so sorry that I am currently too busy to look into. If someone fix I will merge it otherwise have to wait a bit.

[baco]

Ok, many things happening here:

1. the setting was renamed, used to be g:vscode_transparent, the same termination as the Lua setting, but it suddenly change to g:vscode_transparency: https://github.com/Mofiqul/vscode.nvim/commit/ecb73a11 .. https://github.com/Mofiqul/vscode.nvim/commit/5b812ce5

   
   -   if vim.g.vscode_transparent then
   -       colors.vscBack = 'NONE'
   -   end

• transparent = vim.g.vscode_transparency == 1, ...
• if opts.transparent then
• opts.color_overrides.vscBack = 'NONE'
• end

  
  2. Also the logic changed. Before, using the native Vim's boolean value (`v:true`) would work (because it was being stored/evaluated as it came), now it's explicitly compared to the literal `1`.

I still don't know why re-setting the option and the syntax wouldn't restore the color, because it seems to be doing almost the same in behind (.vscBack = 'NONE').

@yochem, which is gonna be, vim.g.vscode_transparent or vim.g.vscode_transparency? Can it evaluate to Lua's true, also when storing Vim's v:true in the options (seems more accurate)?

[yochem]

Hi, sorry for this! I based the backwards compatibility on the README, and found an error in it:

see here.

In the lua part the variable has a different name than in the vim part (transparency vs transparent). Also, both look to be using 1/0. The code however just evaluated the to-lua-converted vim.g.transparent value. The explicit check with == 1 was because Lua evaluates 0 also as true. I'll create a PR for it to fix this.

[yochem]

To comply to the documentation and code before my PR, I will only change vim.g.transparency to vim.g.transparent. Even though it would be better if all values could be set with v:true|v:false, I won't change it to that because the code that checks for the vim.g.vscode_* variables is only there for backwards compatibility.

I've also detected an issue with that, calling :lua require('vscode').setup({ transparent = false }) later on to try to restore the background inside a Nvim UI (Nvim-GTK to be precise) doesn't bring the background back once it's been set to 'NONE'.

Might this be because vim.g.vscode_transparent is still set to 1?

[baco]

I won't change it to that because the code that checks for the vim.g.vscode_* variables is only there for backwards compatibility.

Wouldn't be as easy as:

transparent = vim.g.vscode_transparency == true or vim.g.vscode_transparency == 1,
italic_comments = vim.g.vscode_italic_comment == true or vim.g.vscode_italic_comment == 1,

1. It would be more backwards compatible, even to those configs that use boolean values instead of integers
2. Technically speaking, checking the boolean value (rather than the integer one) would represent the exact same semantics used in the code before (as shown in the commits linked in my previous message)

[baco]

local c = require('vscode.colors')
require('vscode').setup({
    transparent = false,
    group_overrides = {
        Normal = { fg=c.vscFront, bg= (vim.g.colors_name and vim.g.colors_name == 'vscode') and c.vscBack or c.vscNone},
    }
})

@Mofiqul I've tried a variant of this (has the same outcome), putting in ginit.vim:

if exists('g:colors_name') && g:colors_name == 'vscode'
    let g:vscode_transparent = v:false
lua <<EOF
    local c = require('vscode.colors')
    require('vscode').setup({ group_overrides = { Normal = { fg=c.vscFront, bg=c.vscBack } } })
EOF
endif

Both variants work (yours and mine), but with the same weird effect. After restoring the background color, the front color for spaces become more brilliant than they should:

Instead, if I didn't make the background transparent on init.vim and tried to restored later on ginit.vim it should look dimmer:

Any idea on what's happening there and how could I solve that?