There are, apparently, more things we need to configure. @BlakeWilliams shared
http://dance.computer.dance/posts/2015/04/using-ctags-on-modern-javascript.html
which outlines a bunch more things that don't work out of the box. For
example, ES2015 classes and their methods are not properly found, even
with this PR. There's more work to do here.
After using byebug on any Ruby file, the sessions history is written to
this file. It shouldn't be part of our repositories, so we ignore it.
See also: https://github.com/thoughtbot/suspenders/pull/710
Problem:
Currently the `for` in bash will break up lists by whitespace, so if a
filename has a space in it the `for` will break it up incorrectly.
AG will separate the files with a newline character, so this temporarily
overwrites the `IFS` to be used correctly for this use case.
[Docs](https://bash.cyberciti.biz/guide/$IFS)
* `noexpandtab` will ensure tabs are used instead of staces when tabbing
or auto-indenting.
* `softtabstop=2` isn't needed because we are already setting
`tabstop=2` in our `.vimrc`.
We do most of our client work on Github,
and a large portion of our personal projects
are hosted there.
fugitive.vim currently supports
opening the current file in the current branch
in a browser at Github through the `Gbrowse` command.
That command is [slated to be removed to make fugitive
agnostic about coding sites](fugitive-docs).
The capability to quickly generate or view a Github URL
specific to the current branch
can be useful in PR reviews
or other discussions about code.
This change adds rhubarb.vim,
a plugin that implements the slated-to-be-removed
functionality of fugitive that works with Github.
It also provides the user with omni-completion (`<C-x><C-o>`)
to autocomplete Github issues, issue URLs, and collaborators.
[fugitive-docs]: 18d6d1ab82/doc/fugitive.txt
vim-rspec is an excellent Vim plugin for running RSpec tests but there
are many of us who run different kinds of tests on any given day.
vim-test is built to support a wide array of test frameworks and
strategies for executing those tests.
vim-test ships with support for several languages and frameworks in use
on thoughtbot projects today:
* Ruby (both RSpec and Minitest)
* Elixir (ExUnit and espec)
* Go (gotest)
* Python (nose, pytest, djangotest, djangonose)
* JavaScript (jasmine, mocha)
It also supports several execution strategies I have seen people use at
thoughtbot:
* Dispatch
* vim-tmux-runner
* Tslime
* Terminal.app/iTerm.app tabs
* neovim's native terminal
* `:!`
vim-test is extensible, both for additional languages/frameworks and for
execution contexts. See: https://github.com/janko-m/vim-test
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.
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.
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.
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.
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.
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.
In cbdcbce01d 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.
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
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.
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.
In f7c73f7c1b 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.
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.
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`
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.
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
a59f5c3a0a/src/_bundle
**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
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.
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
`.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`.
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`.
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 15de0bcfee.
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
> -- https://github.com/thoughtbot/guides/pull/363
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.
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.
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.
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.
OS X 10.11 changes the file where `path_helper` is invoked from
`/etc/zshenv` to `/etc/zprofile`. The change results in `path_helper`
rearranging the path in such a way that interferes with path changes
made in `.zshenv`.
This README update instructs users to rename `/etc/zprofile` to
`/etc/zshenv` so that `.zshenv` (and `.zshenv.local`) will be loaded
*after* `path_helper` is called, maintaining the desired precedence of
paths.
Thanks to @reshleman and @ventsislaf for investigating and offering
solutions.
In #408 a user reported errors after pulling down master and opening
Vim without having run `rcup`. This documentation change updates the
section on `rcup` to advise running the command after pulling from the
origin.
Other changes:
* Removed outdated references to `m` and `rk` aliases, which have been
removed from the repository.
* Added reference to `migrate` alias, which remains in the repository.
