How often are you starting vim? The great thing about current OSes vs those of the 30+ years ago, you can have multiple terminals and apps open at one time. When working on code, I keep a vim session up the entire time with the files I'm editing loaded and just switch terminals to compile and test. A mouse (trackpad) flick takes little time.
On Sunday, July 16, 2023 at 5:20:26 PM UTC-4 Manas wrote: > On Sun, Jul 16, 2023 at 09:05:37PM -0000, Lifepillar wrote: > > 170ms are also spent loading buffers. Do you need those to be loaded > > eagerly at startup? Also, is context.vim for ConTeXt? ConTeXt support is > > built-in into Vim (`:help ft-context`): do you need a plugin for that? > > If so, why loading it at startup? > No it is different. [context.vim](https://github.com/wellle/context.vim) > > I have found it quite useful for large codebases. > > > > > In general, if you see `autoload` paths in the output of --startuptime, > > you should look further, because those are likely files that do not need > > to be loaded at once. > > > > You may shave some time off by avoiding loading built-in plugins that > > you know you'll never use. In my vimrc, I disable some of those as > > follows: > > > > let g:loaded_getscriptPlugin = 1 > > let g:loaded_gzip = 1 > > let g:loaded_logiPat = 1 > > let g:loaded_rrhelper = 1 > > let g:loaded_tarPlugin = 1 > > let g:loaded_vimballPlugin = 1 > > let g:loaded_zipPlugin = 1 > > > > But your startup time is relatively high (mine is <60ms, an order of > > magnitude less than yours, but still three times more than `vim > > --clean`!), so I'd first act on the slowest parts. Certainly, you should > > (and likely could) try to bring the number of autocommands close to > > zero. > > > > > My autocommands are just scattered throughout vimrc. Most of them are > > > like: > > > > > > au FileType <list> [mappings|calls] > > > > > > Maybe there is a way to organize them better? > > > > Put filetype-specific stuff under > > > > ~/.vim/after/ > > > > For instance, these are a few things you may put in > > ~/.vim/after/ftplugin/tex.vim for (La)TeX files: > > > > " Local settings > > setlocal conceallevel=0 > > > > " Filetype-specific mappings > > nnoremap <silent><buffer> <leader>tp :<c-u>update<cr>:PdfLaTeX<cr> > > > > " Filetype-specific commands > > command! -buffer -nargs=? -complete=file PdfLaTeX call > local#tex#typeset(<q-args>) > > > > Anything that does not need to be immediately available when the > > filetype is set goes into a corresponding autoload file. In the example > > above, the typeset() function is needed only when the user executes > > :PdfLateX. That function is then defined in a separate > > ~/.vim/autoload/local/tex.vim (I put my own stuff under a `local` > > directory, but that's just my convention: any tree structure under > > `autoload` will do). > > > > Btw, this example is in legacy Vim script, but if you are starting > > afresh I'd recommend using the new Vim 9 script syntax. See `:help > > vim9`. > > > > The same concept applies to your vimrc: anything that does not need to > > be set at once when Vim starts should be turned into an autoload > > function. > > > > > And there are a ton of plugins too. Is there any way to only source > them > > > conditionally? > > > > Yes. Put them under ~/.vim/pack/SOMEDIR/opt, where SOMEDIR is a name of > > your choice. Then, use `packadd` to load them when necessary, either > > manually or automatically. For instance, this is my Tagbar configuration > > in my vimrc: > > > > let g:tagbar_ctags_bin = '/opt/local/bin/uctags' > > nnoremap <silent> <leader>vt :<c-u>silent call local#tagbar#toggle()<cr> > > > > Then, the function that lazily loads the plugin and toggles the tag bar > > is in ~/.vim/autoload/local/tagbar.vim: > > > > fun! local#tagbar#toggle() > > if !exists("g:loaded_tagbar") > > packadd tagbar > > endif > > TagbarToggle > > endf > > > > You are using a plugin manager: I would also check whether the plugin > > manager has a way to defer loading plugins. > > > > > I can also try removing some of the old plugins. I haven't done a > > > cleanup in a while. > > > > That's a very good idea: as you become more comfortable with Vim, you > > should review your plugins and get rid those that you are able to > > replace with your own code (if you are willing to spend time on writing > > your own stuff, of course) or with Vim built-in functionality. > > > > For each plugin, ask you yourself: > > > > - do I really need this? Maybe Vim already provides >90% of what the > > plugin does, and I just need to learn Vim a bit better. I may live > > without the remaining <10%, write my own code to fill the gap, or find > > another plugin that covers just that 10%. Sites like > > https://vim.fandom.com/wiki/Vim_Tips_Wiki may be helpful. > > - Am I fully making use of this plugin? Sometimes, a plugin has > > a hundred features, but I am using two or three. Maybe, I can > > implement those two or three features myself? > > - Is there an equivalent plugin that's less complex and possibly faster? > > Fortunately, the Vim plugin ecosystem is vast. And the less popular > > alternative is often as good or better than "what people is using". > > > > Hope this helps, > > Life. > > > > These are really phenomenal tips. Thanks a lot, Life. I am refactoring > the plugins now. I hope to make things under 100ms. > > -- > Manas > -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/16f22aa8-2593-4a59-88f3-9c7e521d725fn%40googlegroups.com.
