This change uses a git 2.15 feature to change the diff colors for lines
that have been moved rather than added or deleted. It provides a cue to
readers that a line's content has not changed.
Adding this setting in gitconfig should not break earlier git. (Tested
against 2.14 and the change had no effect.)
This change prevents chained commands from continuing execution if the
`git merge` is operation would be unsuccessful such as a common
operation when a feature branch is ready to be merged and pushed:
```
git merge-branch && git push origin
```
If the origin/master and the local master have any difference, we return
status 1 and stop execution rather then emit a false success.
h/t: @croaky
Fix#563.
`zsh/configs/prompt.zsh` sets up the dotfile's custom prompt. It
currently does so in a way which prevents overriding the prompt for
specific invocations of zsh.
I noticed this because I've got a helper script for getting a shell
fully configured to work with the AWS CLI that ends with
`PS1='[aws] ' exec "$SHELL"` to distinguish the shell from other
sessions. With a vanilla zsh (and bash) setup, this correctly sets the
prompt on the new shell.
Here's a minimal demonstration with vanilla zsh:
```
bernerdscha-ltm% echo $PS1
%m%#
bernerdscha-ltm% PS1="hi> " exec zsh
hi>
```
And with dotfiles:
```
dotfiles bs-override-ps1 % echo $PS1
${SSH_CONNECTION+"%{$fg_bold[green]%}%n@%m"}%{$fg_bold[blue]%}%c%{$reset_color%}$(git_prompt_info) %#
dotfiles bs-override-ps1 % PS1="hi> " exec zsh
dotfiles bs-override-ps1 %
```
This PR updates prompt.zsh to only update the prompt if there's not an
existing exported PS1 variable. The export check is relevant because in
the default case where PS1 is not explicitly set by the user it will
have already been set (but not exported) by the default zsh configs.
ASDF manages languages versions for many languages instead of just one.
This commit adds ASDF to path and completions for zsh, so that it's
easier to use.
We've been using vim-plug over Vundle since 5724d12 (April 2015). Users
have had long enough to migrate their `vimrc.bundles.local` to use
vim-plug's `Plug` command.
ASDF has plugins for Ruby, Node, Elixir, Haskell, Scala, Go, etc.
Instead of finding and installing a new tool each time we have need for
a version manager in a new tools, we can use the same tool we already
know, adding a new plugin.
This change is the result of a successful [research card][1] and has a
corresponding change to [laptop][2].
[1]: https://trello.com/c/MVbfz8e5/676-asdf-for-tool-management
[2]: https://github.com/thoughtbot/laptop/pull/502
Thanks to rcm and the `post-up` hook file, the dotfiles do a great job
of keeping things up to date.
This change adds a bit of detail and specificity to the README around
updating, specifically clarifying the need to run `rcup` after pulling
to link new files and install new vim plugins.
* if .vim/autoload/plug.vim already exists, then use PlugUpgrade to get
the newest version. This should fix#524.
* change from PlugInstall to PlugUpdate which doesn't just install new
plugins but also updates existing ones.
To [append a project's local `bin/` directory to `$PATH`][dotfiles],
the dotfiles check for the existence of a special directory: `git/.safe`.
This commit is inspired by [thoughtbot/suspenders#837][#837]:
> The idea behind the .git/safe is that I run it manually and explicitly
> after I trust the directoy and the team behind the project.
> Creating it as part of the setup script defeats the point of that. Doing
> so without explcitly telling the user comes across as sneaky, perhaps.
> (I do expect all devs to read setup scripts before running them -- but I
> also know that they do not!)
> Switch this script to inform the user that they have no `.git/safe`
> directory but might like to make one.
Since suspenders may no longer mark projects safe by default, this
commit introduces the `git trust-bin` command to do so.
[dotfiles]: af75a673b1/zsh/configs/post/path.zsh (L9-L10)
[#837]: https://github.com/thoughtbot/suspenders/pull/837
We have an rcm `post-up` hook that installs plugins after running
`rcup`. It does this by directly loading the `.vimrc.bundles` file,
which means our regular `.vimrc` file is not sourced. This lead to
`has_async` being undefined.
By moving the definition into the `vimrc.bundles` we ensure it's
available when that `post-up` hook runs. It remains available when
needed in `vimrc` because we use it there *after* sourcing the bundles.
Now that we're using `ALE`, we're making use of the async features
available in Vim8 and NeoVim. If you try to use these dotfiles on Vim 7,
you'll get a host of errors from ALE.
This change does two things:
1. It writes an error when starting in an unsupported vim version.
2. It skips loading ALE in those versions.
The thinking behind the second change is to leave vim in a more usable
state with minimal annoyance after the initial error.
ALE is an Asynchronous Linting Engine which works with Vim 8 and NeoVim
to lint your code "as you type". It does so without blocking the main
thread by using the asynchronous features of both of those Vim versions.
A number of us in Boston have been using ALE for some time now with
great success. The asynchronous nature means linting does not block
other interactions with Vim and it's been nice to get linting feedback
more often than buffer write.
Many of us find the "as-you-type" linting to be performant enough to
actually be a distraction, so this PR tones that down some. With this
configuration, ALE will lint on cursor hold durations of 1 second and
when leaving insert mode in addition to buffer write, buffer read, and
file type change.
In 16219a31db we implemented a post-up
hook that checked for a problematic `/etc/zshenv` file. OSX/macOS has
changed the file responsible for executing `path_helper` and loading the
system paths multiple times, and this script change issued a warning to
users if `path_helper` might be called in such a way that their paths
could be unexpectedly reordered.
The script used colored output to highlight this problem for the user,
and relied on Bash's script path introspection (through `$BASH_SOURCE`)
to print the location of the `post-up` hook to assist the user in
troubleshooting and understanding where our warning came from.
This change removes the hook's reliance on GNU Bash in favor of `sh`. It
uses the POSIX-compliant `$0` to determine the hook location (this
method is less robust than Bash's `$BASH_SOURCE`, but is available in
all POSIX shells) and removes colored output in the warning to be
compatible with shells that don't support colored output.
Fix#517.
It seems like JavaScript/ES6 is becoming more common for us to run into
in the wild compared to CoffeeScript
with the advent of Babel / transpiling.
Eventually, we'll probably want to remove kchmck/vim-coffee-script.
Users working on CoffeeScript applications would need to move that
plugin into their personal dotfiles.
Some tmux users have reported that when running `rcup` that during the
post-up hook Vim would issue errors about input not coming from a
terminal and then the terminal would look and behave unexpectedly.
Running `reset` after the Vim plugin install step in `post-up` appears
to resolve the issue.
Fix#516.
The `UnPlug` command allows a user to remove a plugin from vim-plug's
list of plugins to install/activate. This command can be used to
selectively ignore shared plugins from `vimrc.bundles` without needing
to overwrite the entire file with a personal replacement.
This change is dependent on vim-plug continuing to use the `g:plugs`
global variable.
Why:
I occasionally will try to zoom in on a pane with the key combination of
C-s then z. However, instead of having the agility to remove my finger
from the ctrl key, I clumsily continue to have it depressed while
applying pressure to the z key. This results in the `suspend-client`
command being executed by tmux. I am then left not knowing what to do
and I can't reattach to the session the that terminal window. It's very
disconcerting and I wish it hadn't happened.
This PR:
Removes the binding for `suspend-client`.
I added this four years ago but haven't been using it.
Not common enough to be included in company-wide dotfiles?
Can move to personal dotfiles if desired.
This change prevents the `post-up` hook from breaking the terminal for
the rest of the session when running `rcup`. Since the session is
completely automated, we don't need input from the terminal once Vim
launches.
In #488 there was some confusion over where to clone the dotfiles
repository before running `rcm`. While the repository can be placed
anywhere, by default users should be placing it in `~/dotfiles` if they
are using the default installation instructions and an unmodified
`.rcrc`.
Close#488.
The use case for push-line-or-edit:
1. You are in the middle of typing a long command, perhaps something
involving `tar`.
2. You realize that you must first run another command, such as `man
tar`.
3. You invoke `push-line-or-edit`, which gives you a fresh prompt. You
type `man tar` and read as needed.
4. When the command (`man tar`) finishes, the long command you
half-typed is back, exactly as you left off.
Other use cases are realizing that you're in the wrong directory before
you press enter, changing your Ruby version before you press enter on
that `bundle` command, or in general being partway through something and
realizing that you're not quite ready to run it yet.
While here, turn off start/stop output control, which gives us back the
^Q keybinding.
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.
