GitLab

Just found this typo while browsing through the `plugins` folder ... and it "hurt sme" :hurtrealbad:

Currently it shows for example the following:

  DEVICE_ID  -- transport_id:2

which doesn't really ease device selection. I've adapted the awk script to print
device name with it's model name, see the example below:

  DEVICE_ID  -- Pixel_3(blueline)

mvn: unify changes, refactor and cleanup

* Maven profiles for current pom.xml file
* Maven profiles for pom hierarchy
* Ommiting comments in profiles

Avoids forking to tput and some systems don't have tput

Update year in LICENSE.txt

Added stackoverflow to web-search plugin

Changing namespace and restarting pods with kubectl

add brew install path to search

Plugin: Updates spotify plugin to current master (as of 2019-01-31)

Added Plugin for Roswell (LISP)

[Laravel] Add aliases and README

Adding Timer plugin

Fix emacs client terminal

Ads brew cask update to brew plugin

* The check for the asdf installation directory is more precise:

    The existence of the directory `$HOME/.asdf` does not mean that it is the installation
    directory of `asdf`. It will also be created after installing at least one asdf plugin.

* Completions, while installed with homebrew, are now expected on an alternative location.

This change references `$RANDOM` outside the subshell to refresh it for the
next subshell invocation. Otherwise, subsequent runs of the function get the
same value and, if run simultaneously, they may clobber each others' temp .z
files.

This is due to how zsh distributes RANDOM values when running inside a
subshell:

  subshells that reference RANDOM will result in identical pseudo-random
  values unless the value of RANDOM is referenced or seeded in the parent
  shell in between subshell invocations

See: http://zsh.sourceforge.net/Doc/Release/Parameters.html#index-RANDOM

Fixes #7562

Fixes (probably MacOS) issue:
> ggfl
zsh: command not found: ggfl

recent `brew install jenv` installs to `/usr/local/bin/jenv`, auto-discover it for recent brew installs to avoid secondary, slower search

This change makes the plugin check if an identity is loaded by looking
first at the key filename reported by `ssh-add -l`. This fixes the use
case where ssh-keygen is not able to output the fingerprint of a key,
such as the one reported on #7516.

Now, for an identity to be passed onto ssh-add, it has to fail the
match for a loaded identity, both filename and signature.