wbthomason / packer.nvim

A use-package inspired plugin manager for Neovim. Uses native packages, supports Luarocks dependencies, written in Lua, allows for expressive config
MIT License
7.87k stars 266 forks source link

Question: what to use to make plugin inactive if condition #288

Closed datwaft closed 3 years ago

datwaft commented 3 years ago

Hello, this should be a quick question, what should I use to make a plugin inactive if a condition is true?

For example, I want to use my neovim configuration for vscode nvim plugin, so I want to disable some plugins if the vscode nvim plugin is detected, I am doing it like this:

local nocode = function()
  return vim.fn.exists('g:vscode') == 0
end

With that function I want to disable my statusline plugin if nocode is false, so I can do it like this:

use {
  'datwaft/bubbly.nvim',
  config = require'plugins.statusline',
  cond = { nocode }, -- true if vscode is not detected
}

Or like this:

use {
  'datwaft/bubbly.nvim',
  config = require'plugins.statusline',
  disable = not nocode(), -- true if vscode is detected
}

The problem with the first one is that it makes the plugin optional, and that breaks my statusline.

Which one should be preferable to use?

wbthomason commented 3 years ago

Can you expand on why the first one breaks your statusline? Otherwise, that's exactly what I'd suggest using.

datwaft commented 3 years ago

I am not exactly sure, but I have the theory that my configuration is being loaded after the plugin files are already loaded, so my configuration overrides variables that the plugin created.

See https://github.com/datwaft/bubbly.nvim/issues/103 for more information.

Investigating a little bit more, it seems its not only my statusline that fails, fern.vim also fails when the cond key is used

image

wbthomason commented 3 years ago

Looking at the linked issue, it seems like the problem is that bubbly reads configuration from variables in g:, but those variables aren't set before bubbly is loaded? If so, you want the setup key rather than the config key (setup runs before a plugin is loaded).

For fern, can you post the relevant config snippet?

datwaft commented 3 years ago

If so, you want the setup key rather than the config key (setup runs before a plugin is loaded)

I will try it tomorrow (here it's like midnight), but yes, it's the one I should be using; I wonder why config originally worked.

For fern, can you post the relevant config snippet?

Here is my configuration snippet:

    use {
      {
        'lambdalisue/fern.vim',
        requires = { 'antoinemadec/FixCursorHold.nvim' },
        config = require'plugins.file-explorer',
        cond = { nocode },
      },
      {
        'lambdalisue/fern-git-status.vim',
        requires = { 'lambdalisue/fern.vim' },
        cond = { nocode },
      },
      {
        'lambdalisue/fern-renderer-nerdfont.vim',
        requires = { 'lambdalisue/fern.vim' },
        cond = { nocode },
      },
      {
        'lambdalisue/fern-hijack.vim',
        requires = { 'lambdalisue/fern.vim' },
        cond = { nocode },
      },
    }

Here is plugins.file-explorer module:

return function()
  if not vimp then
    return
  end
  vimp.nnoremap({'override', 'silent'}, '<C-n>', ':Fern . -drawer -toggle -width=40 -reveal=%<cr>')
  vim.g['fern#renderer'] = 'nerdfont'
end

I will also try the setup tomorrow with fern, maybe then it will work.

I also had problems with the builtin lsp plugins, but I don't know if its related to this.

wbthomason commented 3 years ago

Your plugins.file-explorer snippet looks like it closes over the vimp module, which will cause errors because Lua's loadstring cannot handle upvalues. Additionally, I'm surprised you don't get an error from your requires keys - for plugins that you already install and configure in another clause, those should reference just the plugin name, e.g. fern.vim instead of lambdalisue/fern.vim (yes, this is confusing and should be improved).

Other than that...I'm not really seeing anything that should cause the errors you get with fern.

datwaft commented 3 years ago

Your plugins.file-explorer snippet looks like it closes over the vimp module, which will cause errors because Lua's loadstring cannot handle upvalues.

vimp is a global so it shouldn't cause any problem.

And, about the requires, every single require I am using is like that, seems really strange that it doesn't give me any error.

About fern, it's very strange, maybe something about the internal design of the plugin. If I remove the cond key it works perfectly, so I don't have much idea about why it is happening.

Tomorrow I will make a minimal reproducible example.

datwaft commented 3 years ago

I will try it tomorrow (here it's like midnight), but yes, it's the one I should be using; I wonder why config originally worked.

Using the key setup seems to make it work with cond (success), but now it gives me another error; it seems that the plugin is loaded before lsp-status.nvim, even if I use the after key. Or maybe lsp-status is not even being loaded at all.

Here is the error:

image

Because it is my own plugin I can know that its caused because the Lua module called lsp-status doesn't exists yet, as you can see here.

Here are the configuration snippets:

    use {
      'datwaft/bubbly.nvim',
      after = 'lsp-status.nvim',
      setup = require'plugins.statusline',
      cond = { nocode },
    }
    use {
      'nvim-lua/lsp-status.nvim',
      cond = { nocode },
    }

If I delete the line cond = { nocode }, of lsp-status.nvim it works. I don't know if this is a bug or intended behaviour. Could be related to this:

I also had problems with the builtin lsp plugins, but I don't know if its related to this.

In a little bit I will make the example for fern.

datwaft commented 3 years ago

In a little bit I will make the example for fern.

About this, maybe it was fixed overnight because it doesn't happen anymore and I haven't changed the code for that yet.

image

wbthomason commented 3 years ago

Fascinating. If you can reproduce the issue, I'd be interested to hear about it (and please re-open this issue). Otherwise, I'm glad things are working now!