1. 12
  1.  

  2. 10

    I used to have my configuration nicely broken up into separate files, but I’ve since gone back to having one big vimrc. It’s a lot easier to continually tweak my setup if I can just open one file and run a search instead of taking a second to remember whether I want to be in functions, mappings, or abbreviations.

    1. 8

      Exactly.

      The urge to “architect” one’s text editor configuration should be dismissed. Treat your vimrc (or init.el) as your personal hackpad, an exocortex. There is zero reason for it to be organized: navigation is one of the primary strengths of vim and emacs.

      If something in your config finds a theme or structure, it makes sense to extract (and publish) it as a plugin. In all other cases, by treating your personal config as a formal project you are missing a vital mode of operation.

      1. 1

        I agree with the sentiment, but not necessarily with the problem.

        I could try merging my split files into one and see what happens by having searchable curly-brace blocks, but I don’t see why searching for a block is inherently easier than opening a well-named file.

        The instances where I’ve opened the wrong file first are few and far between.

        1. 1

          I could try merging my split files into one and see what happens by having searchable curly-brace blocks, but I don’t see why searching for a block is inherently easier than opening a well-named file.

          Who said anything about folds? It’s almost a “koan” moment: even when discussing de-architecting your config, you nevertheless assume the urge to decorate everything with curly-brace blocks.

          None of that is necessary. I have a 1000-line vimrc. Anything complicated is in a function or augroup. That means not only is it searchable, it also generates tags. Not to mention marks and VCS add other forms of context.

          1. 1

            I did. I tend to close folds and appreciate having something descriptive to navigate by. Closed folds and relnum is how I do a lot of it.

            I suppose augroup would yield a similar effect.

            Guess I should look into tag generation there, never bumped into it, nor really used augroups.

      2. 1

        Agreed. At some point I split my Bash config into multiple files, and now I have to remember if the alias I want to update is in the main file or in .bash_aliases. I thought I was being clever, turns out not so much.

        1. 1

          Similar here, but I haven’t completely undone the splitting. I’ve still kept some things broken out: https://github.com/ap/dotvim/tree/master/plugin

          But to paraphrase myself – the difference is I’m not distributing things around any more based on what they are (functions/mappings/abbreviations), I’m distributing them around based on which things belong together as a unit (these things together make Ctrl-N/Ctrl-P work like I want; these make * work like I want; etc). There aren’t a lot of things that are involved enough to deserve a whole file though, and everything else just goes in vimrc now.

          (One place where I have broken up stuff that I had together before is that now that all of Vim’s configuration files go inside .vim, I’ve gone to a separate gvimrc. Previously I never liked having both a ~/.vimrc and ~/.vim/ but didn’t feel like fighting it. But having to have a ~/.gvimrc as well was too much.)

          So by and large I just have one big file with everything… except for the handful of aspects of my environment that require more setup than just tweaking one or two knobs, which I keep together in a separate little file per aspect.

          I’ve been very happy with this balance.

          1. 1

            That has pretty much prevented me from breaking my config into multiple files. Doing so would be a two-step process to make a change: grep to find the appropriate file, open in vim, search/edit. It’s much faster to just open .vimrc in vim and search/edit.