Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Shougo
    @Shougo
    I use on_source for it.
    MiSawa
    @MiSawa
    That's sounds correct approach. May be I should try make unite lazy.(I didn't investigate my configuration yet, but I got an error so I tried to find a simpler solution.) Anyway, thank you for your quick responses!
    Hendrik Roth
    @HendrikRoth
    This message was deleted
    Tobias Witt
    @ohcibi
    is build for dein#add() executed after updating the plugin as well or do I need to specify the same script in hook_post_update if a plugin needs to re-execute the build script after every update?
    Shougo
    @Shougo
    is build for dein#add() executed after updating the plugin as well
    Yes.
    You don't need to write the script.
    gisochre
    @gisochre

    Hi, @Shougo!
    do you have any examples of how you used

                                *dein#rollback()*
dein#rollback({date}[, {plugins}])

    function ? all {plugins} have to be specified explicitly?

    Shougo
    @Shougo
    all {plugins} have to be specified explicitly?
    Yes. No example though.
    Tobias Witt
    @ohcibi
    can I temporarily disable the cache competely? i'm currently debugging which of my plugins are incompatible with each other and i'm permanently unsure if I actually disabled/enabled the plugin now or not
    Shougo
    @Shougo
    You can use merged.
    I think dein#load_toml() or dein#load_dict() is easy way.
    You can specify the default option.
    Tobias Witt
    @ohcibi
    @Shougo yep i know about merged it helps for a single plugin. I was thinking about a way that disables it at once for all plugins (i.e. the equivalent of putting merged: 0 in every single call dein#add() call
    Tobias Witt
    @ohcibi
    is your idead to call load_toml or load_dict with an empty dictionary or something like that?
    Shougo
    @Shougo
    call dein#add() does not support default option.
    So you should use dein#load_toml() or dein#load_dict() or create the wrapper function instead.
    Nealot
    @nealot
    Hey guys, I was wondering if anyone has been able to lazy load vim-devicons and denite simultaneously? I've tried to use on_source('vim-devicons) to load denite before devicons but I can't seem to get it to work.
    Shougo
    @Shougo
    You must load vim-devicons before denite.
    Nealot
    @nealot
    Hi, https://github.com/ryanoasis/vim-devicons/wiki/usage states that I should load vim-devicons after I have loaded Denite. Is there a reason that Dein suggests otherwise?
    Nealot
    @nealot
    It works though, thanks!
    Shougo
    @Shougo
    Hi, https://github.com/ryanoasis/vim-devicons/wiki/usage states that I should load vim-devicons after I have loaded Denite. Is there a reason that Dein suggests otherwise?
    I don't know. I think it is wrong...
    vim-devicons change denite behavior.
    So it must be load before denite.
    Nealot
    @nealot
    Oh okay. Well I added on that wiki so nobody else runs into the same issue.
    Btw, what are the advantages of using toml for Dein? Is it only improving the readability or are there performance increases aswell?
    Shougo
    @Shougo
    Btw, what are the advantages of using toml for Dein? Is it only improving the readability or are there performance increases aswell?
    It just adds the readability.
    Tobias Witt
    @ohcibi
    note to self: if you symlink ~/.vim to ~/.config/nvim instead of the vimrc file directly dont forget to do it on your new computer as well
    Michael Yang (xdazz)
    @kiooss

    @Shougo
    In dein's readme, the example config is like below.

    call dein#add({path to dein.vim directory})
call dein#add('Shougo/deoplete.nvim')

    Can here be just call dein#add('Shougo/dein.vim')

    Shougo
    @Shougo
    You can write like it.
    But it adds the dein.vim path to Vim runtimepath.
    You have added the path to runtimepath in your vimrc.
    So it will be duplicated path.
    Michael Yang (xdazz)
    @kiooss
    Got it, thanks. @Shougo
    Tobias Witt
    @ohcibi
    @Shougo i'm curious. can you elaborate why one needs to explicitly tell dein to manage dein?
    Shougo
    @Shougo
    It is hard to tell
    You should know dein#add(local path) and dein#add(repository path) difference.
    You have installed dein.vim manually.
    So it should be dein#add(local path)
    Tobias Witt
    @ohcibi
    @Shougo in fact I don't know about the difference but I'm already blindly respecting that. But that wasn't my question. The question was, why do i need to tell dein at all that it should manage dein? (no matter if installed locally or per repository?) Is it to benefit from the caching for dein as well? Would dein work without telling dein to manage dein but then dein wouldn't be cached?
    Shougo
    @Shougo
    Hm.
    Of course, you don't have to manage dein.vim.
    Because it is already installed
    If you manage dein.vim, you can update dein.vim by dein.vim.
    It is not special feature.
    But it is useful and vim-plug doesn't support.
    Maik Klein
    @MaikKlein
    Any idea why I can't access the help file with :h dein?