Skip to content
Commits on Jan 11, 2016
  1. @georgebrock

    Globally ignore compiled Python files.

    georgebrock committed
    The first time a `.py` file is run, or any time it's been modified, Python
    creates a `.pyc` file containing a bytecode representation.
    
    These bytecode files should always be ignored by Git, since keeping them
    updated in a repo would be time consuming and would serve no purpose.
Commits on Jan 8, 2016
  1. @calebthompson

    Add golang configuration samples

    calebthompson committed
    Add suggested Go configuration for Vim into the `ftplugin` folder and
    the vim-go plugin. We may use this as a template for adding further
    language-specific settings in the future for languages that aren't
    universally used by the team.
    
    * `fatih/vim-go`: The de-facto Golang Vim plugin.
    * `softtabstop=2`: As a side effect of setting how "large" a tab is in
      insert mode, Vim is able to delete tabs with the backspace key in
      Insert mode.
    * `compiler go`: Necessary for plugins using the `make` command, such as
      vim-dispatch.
    * `listchars=tab:\ \ `: Don't highlight tabs as "»·" as if they were
      problem characters in go files. Also recommended for *sh files and any
      others which which should also be using tabs.
    * `go_fmt_command = "goimports"`: Tell vim-go to use the `goimports`
      command rather than `gofmt`, which attempts to find dependencies and
      adds them to your import statement.
Commits on Dec 19, 2015
  1. @sgrif

    Better match the default behavior of ctrl-P when using ag

    sgrif committed
    When using ctrl-p without ag, the pattern given is not treated as a regular expression. Additionally, the value passed when first opening ctrl-p is not actually a valid PCRE regex, and produces an error when used on Windows. This modifies the options to treat the pattern as a string literal, not a regular expression, resolving the Windows problem, and better matching the behavior of ctrl-p without Ag.
Commits on Dec 18, 2015
  1. @geoffharcourt

    Extract filetype-specific setups to ftplugin

    geoffharcourt committed
    Vim's documentation advises that buffer-specific configuration based on
    a filetype should be performed via a file in `$HOME/.vim/ftplugin`:
    http://vimdoc.sourceforge.net/htmldoc/usr_41.html#41.12
    
    This change moves CSS/Sass-, Git commit message-, and Markdown-related
    editor settings into `ftplugin/gitcommit.vim` and
    `ftplugin/markdown.vim`, and rewrites those settings to avoid using
    `autocmd`, letting Vim execute `setlocal` when a file of the filetype is
    determined or set.
Commits on Dec 11, 2015
  1. @pedro-nonfree @geoffharcourt

    Update `bin/replace` script for better portability

    pedro-nonfree committed with geoffharcourt
    The existing implementation of the `replace` script does not work on
    GNU/Linux due to differences in the implementation of `sed`. This change
    reworks the process of the replacement to create temporary files,
    apply the changes to the files, and then move them into place. It will
    improve the script's portability for more OSes.
Commits on Dec 8, 2015
  1. @bernerdschaefer

    Use one space, not two, after punctuation.

    bernerdschaefer committed
    When using a join command (`gq`, `J`), vim defaults to adding two spaces
    after '.', '?', and '!'.
    
    Setting `nojoinspaces` causes vim to only insert a single space.
Commits on Nov 29, 2015
  1. @geoffharcourt

    Set `<leader>ct` shortcut to use Git ctags hook

    geoffharcourt committed
    In cbdcbce we introduced a Tim
    Pope-inspired Git template scheme that automatically ran `ctags`
    asynchronously through a hook after certain source control operations.
    This hook is bypassed if a user uses `<leader>ct` to reindex their tags
    from within Vim.
    
    This change binds `<leader>ct` to use a Vimscript function that will
    identify if the `ctags` hook exists in the local repository and executes
    it. The function falls back to existing functionality if the hook does
    not exist. We are moving the function out of `vimrc` as a first step
    toward breaking our Vim configuration up by topic area.
  2. @geoffharcourt

    Run `db:test:prepare` task on `migrate` alias

    geoffharcourt committed
    We removed `db:test:prepare` from the `migrate` alias in #260 because
    Rails 4.1 discouraged users from running the deprecated (at the time)
    Rake task. Rails brought back `db:test:load` in rails/rails#17739 due to
    user complaints about being unable to force a test database
    synchronization.
    
    Without dropping and recreating the test database from scratch, the
    current migration strategy of solely using `db:migrate` and
    `db:rollback` will never bring changes into test from a migration that
    was run, rolled back, modified, and then re-run.
    
    Running `db:test:load` or `db:test:prepare` on each migrate operation
    has a small performance penalty, but the task is only being run when you
    have a reason to want to check or force a synchronization of the
    database. Knowing for sure that your test and development databases are
    at the same point in their evolution is worthwhile.
    
    Running `db:test:prepare` or `db:test:load` after running our existing
    migrate alias added just under 1.0 seconds on average to the migrate
    operation on an application with a reasonably sized DB schema.
    
    diff --git a/aliases b/aliases index 6a0f602..102caca 100644 ---
    a/aliases +++ b/aliases @@ -9,7 +9,7 @@ alias v="$VISUAL" alias
    b="bundle"
    
     # Rails
    -alias migrate="rake db:migrate db:rollback && rake db:migrate"
    +alias migrate="rake db:migrate db:rollback && rake db:migrate db:test:prepare"
     alias s="rspec"
    
     # Pretty print the path
Commits on Nov 16, 2015
  1. @reshleman

    Remove Unused `move_to_front_of_path` Function

    reshleman committed
    In #440, a `move_to_front_of_path` function was introduced, but
    was [ultimately not used][1] when these changes were merged as f7c73f7.
    The function itself was not removed, however.
    
    This commit removes the unused function.
    
    [1]: #440 (comment)
Commits on Nov 14, 2015
  1. @geoffharcourt

    Add tab-completion with local branches for `git delete-branch`

    geoffharcourt committed
    This solution was heavily influenced by @keith's original contribution
    in #356, which I think may have worked on some but not all setups due to
    personal configuration differences.
    
    The solution in #356 added the `_git_delete_branch` function in the
    `zsh/completions` folder, which resulted in the tab-completion working
    against `git`, but not against our `g` function. With our new loading
    order where functions are loaded first and completions are loaded last,
    we can load the `_git_delete_branch` function before any completions are
    defined on `git`, `g`, or `hub`, allowing the `_git_delete_branch` shim
    to be used by all three of those git-invoking commands/functions.
    
    Close #355.
Commits on Nov 13, 2015
  1. @geoffharcourt

    Don't export `$PS1`

    geoffharcourt committed
    The `$PS1` variable does not need to be exported in order for `zsh` to
    use its contents to set prompt options. `export`ing it has the negative
    side-effect of polluting prompts in shells launched from `zsh`. The
    `export`ing of `$PS1` is the cause of #270, where using `sudo su` to
    become another user (launching a non-`zsh` shell) resulted in a
    corrupted prompt.
    
    Removing the `export` will allow `sh`/`bash`/`dash` and other shells to
    be launched from `zsh` without inheriting its prompt settings.
    
    Fix #270.
  2. @geoffharcourt

    Use `export -U` to deduplicate `$PATH`

    geoffharcourt committed
    In f7c73f7 we started to deduplicate
    `$PATH` using `typeset -U`, but that did not prevent duplicate `$PATH`
    entries when processes were launched that inherited the environment from
    an existing shell.
    
    Using `export -U` keeps the `$PATH` deduplicated even when tmux launches
    a new shell.
    
    Fix #443.
  3. @TheLonelyGhost @geoffharcourt

    Deduplicate `PATH` before exporting

    TheLonelyGhost committed with geoffharcourt
    Why:
    
    * Remove dupes from PATH
    
    How:
    
    $PATH is a scalar composed of contents of $path, so it uses typeset -U
    ("U" as in Unique) to ensure there are no dupes. It preserves the first
    occurrence in the array, since it would be searched first before others
    when matching a command in the directories in the PATH anyway.
Commits on Nov 6, 2015
  1. @teoljungberg @geoffharcourt

    Add `ctags` support for `attr_` definitions

    teoljungberg committed with geoffharcourt
    This change adds `ctags` support for `attr_{reader,writer,accessor)` in
    Ruby files.
  2. @mike-burns

    Split zsh configuration into smaller files

    mike-burns committed with Geoff Harcourt
    This allows people to incorporate the thoughtbot dotfiles into their own
    dotfiles in a more fine-grained manner.
    
    I left some things in zshrc that we should eventually handle more
    precisely:
    
    - Load `.zsh/functions/*`. This could instead be replaced with: `mv
      .zsh/functions/* .zsh/configs`.
    - Load `.aliases`. This could instead be replaced with: `mv .aliases
      .zsh/configs/aliases.zsh`.
    - Load `.zshrc.local`. This file can realistically go away entirely,
      with people adding their own files to `.zsh/configs`.
    
    A further refactoring, which I have done locally, is to introduce a
    `~/.sh/configs` directory, in which people can put POSIX-specific
    configuration that can be shared between GNU Bash, zsh, ksh, etc:
    aliases, functions, paths, prompts, and so on. But one step at a time.
    
    Other changes:
    * Move aliases setup to occur after loading other config, as some of our
      aliases depend on environment variables having been set, so alias
      loading must come last after we've sourced `zsh/configs`.
    
    * Move autocompletion for `g` function from the function definition to
      to `zsh/completions/_g`
    
    * Move `PATH` setup to `zsh/configs/post` to ensure it happens after
      other configuration that might alter the `PATH`
Commits on Nov 4, 2015
  1. @seanpdoyle

    Recognize JS Linter configuration files as JSON

    seanpdoyle committed
    Unfortunately, the convention for most JavaScript linters is to name
    their configuration `.${TOOL}rc`.
    
    In spite of this name, the configuration files are `JSON`. Forcing vim
    to recognize them as JSON would enable syntax highlighting and linting
    plugins (like syntastic) to recognize invalidly structured JSON.
Commits on Oct 30, 2015
  1. @geoffharcourt

    Update Bundler completion to include newer subcommands, fix help

    geoffharcourt committed
    The zsh-completions repository has some additional Bundler subcommands
    in their completion since we first implemented it a couple years ago.
    This change updates our `_bundle` autocompletion definition to include
    the subcommands `outdated` and `platform`, as well as separating values
    for `bundle help`.
    
    Separating the individual commands when defining candidates for `bundle
    help` allows tab-completion of those subcommands (e.g. hitting `<TAB>`
    with `bundle help in` would suggest `init` and `install` and tab
    complete either option.
    
    Changes imported from
    https://github.com/zsh-users/zsh-completions/blob/a59f5c3a0a0045148a241a9e069c17103bedf2cf/src/_bundle
  2. @geoffharcourt

    Bring more shell syntax into shellcheck compliance

    geoffharcourt committed
    **Bring executables into better shellcheck compliance**
    
    While evaluating linting and testing options for our shell
    configuration, a run of Shellcheck against our executables turned up
    some places where we could use more consistent syntax across our
    executables, such as always using a shebang or quoting `$HOME` when we
    build up a larger directory.
    
    **Update syntax for zsh functions and completions**
    
    A few changes found while linting zsh configs with shellcheck:
    
    * thoughtbot's [style guide] [guide] calls for `$(..)` over backticks
      when capturing command output
    * use `-gt` to test array length in arguments
    
    [guide]: https://github.com/thoughtbot/guides/tree/master/best-practices
Commits on Oct 23, 2015
  1. @gylaz @geoffharcourt

    Provide an example of specifying dotfiles dir

    gylaz committed with geoffharcourt
    Why:
    
    * There can be confusion on how to tell `rcup` where local dotfiles
      have been installed.
  2. @mislav

    Only colorize warning messages if stderr is a tty

    mislav committed with Geoff Harcourt
    This is to avoid outputting ANSI escape codes to scripts and log files.
  3. @mislav

    Move broken OS X /etc/zshenv detection to post-up hook

    mislav committed with Geoff Harcourt
    This is so it doesn't run every time when zsh starts in interactive
    mode, but just once per `rcup`.
  4. @mislav

    Detect OS X broken `/etc/zshenv` and suggest rename

    mislav committed with Geoff Harcourt
    If `/etc/zshenv` that calls `path_helper` is found on the system, assume
    OS X version pre-El Capitan and suggest that this file gets renamed to
    `zprofile` so that it only gets sourced on login shells and doesn't mess
    up PATH order on nested invocation of zsh.
  5. @mislav

    Detect if `~/.zshenv.local` changes PATH and suggest `.zshrc` instead

    mislav committed with Geoff Harcourt
    Warn people who might have PATH and similar configuration in their
    `~/.zshenv.local` that they should upgrade to `~/.zshrc.local` since
    that's a much better phase for such configuration. This is for backwards
    compatibility with people's personal configurations from pre-El Capitan
    days.
    
    The generic `.zshenv` file from zsh distribution[1] advises:
    
    > .zshenv is sourced on ALL invocations of the shell, unless the -f
    > option is set. It should NOT normally contain commands to set the
    > command search path, or other common environment variables unless you
    > really know what you're doing. E.g. running `PATH=/custom/path gdb program`
    > sources this file (when gdb runs the program via $SHELL), so you want
    > to be sure not to override a custom environment in such cases. Note
    > also that .zshenv should not contain commands that produce output or
    > assume the shell is attached to a tty.
    
    [1]: http://sourceforge.net/p/zsh/code/ci/master/tree/StartupFiles/zshenv
  6. @mislav

    Avoid suggesting that people use `.zshenv.local`

    mislav committed with Geoff Harcourt
    `.zshenv` is executed for all zsh programs, even those run from
    executables and not as an interactive shell, and furthermore due to
    OS X's use of `path_helper` in `/etc/zprofile` which runs after that,
    it's not a good place to configure additional PATH entries.
    
    From zsh(1) man page:
    
    > As /etc/zshenv is run for all instances of zsh, it is important that
    > it be kept as small as possible.
    
    So `.zshenv` is generally considered advanced usage and is not
    recommended that people drop their casual login shell config in here.
    Because of people's historical misuse of `.zshenv`, stop documenting it
    in the README and suggest that people do their PATH and other
    configuration in `.zshrc`.
  7. @mislav

    Move EDITOR and PATH tweaks from `.zshenv` to `.zshrc`

    mislav committed with Geoff Harcourt
    Making tweaks such as setting EDITOR or changing PATH only makes sense
    for interactive shells, e.g. those that open in your Terminal window or
    when you log in to a server. Non-interactive shells (such as those
    started by running `zsh myscript.zsh` or any executable with `zsh`
    shebang) should instead inherit those values from the environment.
    
    Furthermore, changing PATH in `~/.zshenv` is not advised since stock
    OS X `/etc/zprofile` will reoder PATH by means of `path_helper`, so it's
    better to make any additional PATH manipulation in `~/.zprofile` or
    `~/.zshrc`.
  8. @mislav

    Revert "Add instructions to fix path on OS X El Capitan"

    mislav committed with Geoff Harcourt
    For years, OS X has mistakently invoked `path_helper` in `/etc/zshenv`
    (affecting all zsh runtimes, even non-interactive shells such as
    scripts) instead of from `/etc/zprofile` where it should have been
    because it needs to only run once for a login shell.
    
    This frustrated a lot of users since `path_helper` would unexpectedly
    reorder their PATH by putting system paths first during nested
    invocations of zsh. Many have disabled their `path_helper` because they
    believed it to be the culprit. Instead, what they should have done is
    fixed the OS X configuration bug and renamed their `/etc/zshenv` to
    `/etc/zprofile`.
    
    Recently, El Capitan shipped and users of zsh rejoiced because it has
    finally fixed its faulty zsh configuration: the `path_helper` is now
    correctly invoked from `/etc/zprofile`. This was a deliberate change on
    Apple's part and is a BUG FIX, NOT A REGRESSION.
    
    However, now this project suggests the opposite: revert the El Capitan
    fix and move `/etc/zprofile` to `/etc/zshenv`. This is unwise since it
    teleports us to the olden days of broken zsh configuration. Please don't
    instruct users to break their system.
    
    This reverts commit 15de0bc.
Commits on Oct 21, 2015
  1. @geoffharcourt
Commits on Oct 16, 2015
  1. @seanpdoyle

    Add `git pf` alias

    seanpdoyle committed
    Using `--force-with-lease` allows one to force push without the risk of
    unintentionally overwriting someone else's work.
    
    The git-push(1) man page states:
    
    > Usually, "git push" refuses to update a remote ref that is not an
    > ancestor of the local ref used to overwrite it.
    >
    > This option overrides this restriction if the current value of the
    > remote ref is the expected value. "git push" fails otherwise.
    >
    > --force-with-lease alone, without specifying the details, will protect
    > all remote refs that are going to be updated by requiring their
    > current value to be the same as the remote-tracking branch we have for
    > them.
    >
    > --@calleerlandsson
    > -- thoughtbot/guides#363
  2. @geoffharcourt

    Remove zsh `jj` keybinding

    geoffharcourt committed
    As reported in #405, the `jj` keybinding is problematic for some users
    as it enters vi-mode whenever a user types a string that actually
    contains two consecutive `j`s.
    
    While consecutive `j`s are unusual in English, usernames with
    consecutive `j`s such as that of the contributor who reported the
    problem (@jjlangholtz) are common enough that we shouldn't force this
    mapping on users.
    
    Users can add their own keybinding to their local configuration or use
    the already-provided `Esc` binding to enter vi-mode.
    
    PR #405 contains other keybinding changes that we don't want to apply,
    this commit addresses only the `jj` binding.
  3. @codenamev @geoffharcourt
Commits on Oct 9, 2015
  1. @mike-burns

    Remove unused Easter egg

    mike-burns committed
    The `ranch` subcommand is annoying to skip and adds clutter to our
    system, which only encourages people not to use our dotfiles as a base.
    Remove it to get customizability back.
  2. @JoelQ

    Add custom git command `git ranch`

    JoelQ committed
    Sometimes when typing `git branch` I leave off the leading `b`, leading
    to the boring message:
    
    > git: 'ranch' is not a git command. See 'git --help'.
    
    This adds a custom `git ranch` command with a friendlier funny message.
Commits on Oct 8, 2015
  1. @andyw8

    Clarify integration with Exuberant Ctags

    andyw8 committed
    The ctags.vim plugin was removed in #375. I updated the README to
    document the Vim mapping for re-indexing a project's ctags.
Commits on Oct 3, 2015
  1. @geoffharcourt

    Use vim-projectionist and vim-rake

    geoffharcourt committed
    vim-projectionist provides vim-rails-like shortcuts for alternate and
    related files. It allows users to provide a custom set of "projections"
    that map filetypes to their alternate and related counterparts. Custom
    mappings can be declared in a JSON-like syntax.
    
    This change provides authors of gems and other non-Rails Ruby projects
    with access to the alternate file `:A` shortcuts to navigate between
    code and specs. vim-rake automatically maps code/spec mappings for Ruby
    files if vim-projectionist is available.
    
    Close #381.
  2. @geoffharcourt

    Merge pull request #424 from zillou/readme-command-fix

    geoffharcourt committed
    Fix syntax for OS X path_helper directions in README
Something went wrong with that request. Please try again.