Analysis of swkp/dotfiles Repo

I did not notice that this repo had about 3,000 stars. That is A LOT.

Anyway, I came across dotbot by looking at GitHub’s dotfiles.github.io page.
DotBot, in a sentence, enhances a dotfiles repo by taking care of the “symlinking stuff”. Whether or not this is an accurate summary of DotBot is beside the point, so much as this is the problem you know of which it will solve.
– More importantly, I’d say, isn’t so much that it automatically sets-up the linking so-much-as that it serves as a convenient way to document what files go where. That is, dotfiles usually fall into the “write once and forget” category of programs. It would be nice to do better than that.

I came across skwp/dotfiles by way of the author’s “Cleanest vimrc You’ve Ever Seen” post. Excerpt:

After I [split my .vimrc up], I ended up with a vimrc that’s only about 90 lines long including very detailed comments about every section.

I think this is the cleanest vimrc you’ll see on the web. All my vim plugin settings are broken down into individual files, following a convention of one file per vim plugin that I use, plus some extra ones that are too small to be plugins.

I think the author here is being a bit daft to say his .vimrc is less than 100 lines of code; the .vimrc he split up was presumably longer, and the monolithic .vimrc (which the posts suggests is a problem) is being used to do what could be more modularised.
– Rather, a truly minimalistic .vimrc would be relying on convention-over-configuration. (Which isn’t necessarily a good idea with Vim, but whatever). – This is all beside the point; the goal is “more readable”.

At any rate, skwp/dotfiles makes for a good “case study” of how to make a clean dotfiles repo. Here are some notes:

• BAD: Rakefile to manage symlinking. A brief glance shows that there’s a lot of “data” (this file symlinks to this location). This wouldn’t be so bad if the Rakefile were generated by some other means, but just seems The Wrong Way(tm) to go about it.

• GOOD: Folders for each program; e.g. directory for vim/, separate from tmux/. I’m not 100% sure whether this is wholly good; but if we draw comparison to how we keep programs tidy, this parallels with subfolders for packages/modules.
  – I learned that the “vimify” folder is for readline/editline. It’d be nice if this were more obvious, and not just “vimifying”-that-magic-terminal.

• BAD: doc/ folder. While I’m all for documentation, especially for justifying why which plugins were chosen etc., here the design philosophy of “split up things into different files by topic” is taken too far. e.g. A note about keymaps has some useful information, but it’s one file for only a paragraph. – This is the kindof thing a programming journal is good for, but notes like this shouldn’t be so difficult to access as this.
  e.g. Notes about commands for specific plugins is useful, (I’d forget things like this too, writing it down is good), but these comments are too far away from where they are relevant.

  tComment - gcc to comment a line, gcp to comment blocks, nuff said

• GOOD: Vim’s Vundle Enhancement
  In vim/vundles/ there are a bunch of *.vundle files, which each have the Plugin 'user/repo' lines. These get sourced by vim/vundles.vim (alas, manually; feature or bug, I don’t know. There are advantages/disadvantages each way, I guess, if you want to sometimes disable some collection(s) of plugins).
  Whatsmore, vim/settings/ contains a bunch of <topic>.vim files, almost all of which are for plugins. e.g. ctrlp.vim. The unfortunate thing is some of these files are 1 line long, so this becomes a tradeoff between being able to read everything in a .vimrc, and having a clean, modularised setup.
  – One must ask whether a monolithic .vimrc is really so untidy.
  There’re also disadvantages to this approach. e.g. vim/settings/solarized.vim, it’s unclear why au VimEnter * so ~/.vim/settings/solarized.vim is needed; just seems “bad” to me.
  vim/settings.vim is responsible for sourcing these settings files; there’s an interesting example of how one could go about OS-specific sourcing.

• GOOD: small note, [vim/ftplugin/gitcommit.vim] has setlocal spell (i.e. enable spellchecking), as well as a Vim-include-guard. The former is probably worth having.

Ammendment: (27/01): While I’ve not yet tried splitting up my .vimrc yet, I did spare half a thought in trying to split up my fish config, & tmux config.
I think ideally, I could specify in a .local (or .user file) installation-specific locations, e.g. some $POWERLINE_PATH, etc. and then the “global” config could pick up on this.
– Unfortunately, I don’t know tmux scripting well enough to know for certain, but my impression was it wasn’t easy to do that; at least not how I expected.

I quickly ran into “configuration vs convention”; e.g., what is worth putting in a “global” config, if it needs to depend on a variable set in a per-user config?
Or setting $EDITOR to nvim, but this may not work on OSX? (Override it in OSX.user.config? Explicitly test for presence of nvim in /usr/bin?).
Rather, I wondered how much really belonged in the global config; and if “not much”, then what convenience is there in having some dotfiles manager like DotBot?