231 lines
8.2 KiB
Bash
231 lines
8.2 KiB
Bash
#!/bin/zsh
|
|
#
|
|
# .zsh_plugins.txt - antidote plugins file
|
|
#
|
|
|
|
### Overview
|
|
#
|
|
# The `.zsh_plugins.txt` file is used by antidote to configure Zsh bundles. Bundles are
|
|
# just a fancy way of referring to Zsh utilities, frameworks, prompts, or plugins.
|
|
# `.zsh_plugins.txt` is used by antidote to generate a static `.zsh_plugins.zsh` file,
|
|
# which can then be sourced in your `.zshrc`. You can use this file as a starting point
|
|
# for your own config. Strip out instructional comments (ie: lines beginning with a '#')
|
|
# and any plugins you don't need, then add what you like and make it yours!
|
|
#
|
|
# NOTE: Order matters in this file! Some bundles need to be last, and others are
|
|
# prerequisites. Read the documentation for the plugins you use to ensure proper
|
|
# configuration.
|
|
#
|
|
###
|
|
|
|
|
|
### Regular Plugins
|
|
#
|
|
# Plugins are the simplest kind of bundles. You can point to a full git URL, or if you
|
|
# assume GitHub.com, then you can use the user/repo shorthand.
|
|
#
|
|
###
|
|
https://github.com/peterhurford/up.zsh
|
|
rummik/zsh-tailf
|
|
mattmc3/zman
|
|
agkozak/zsh-z
|
|
|
|
|
|
### Local Plugins
|
|
#
|
|
# Plugins don't have to come from GitHub. You can also use local files or directories to
|
|
# host your own custom plugins.
|
|
#
|
|
###
|
|
$ZDOTDIR/.aliases
|
|
#$ZDOTDIR/custom/plugins/example
|
|
|
|
### Local Plugins with Variables
|
|
#
|
|
# If you want to use variables in this file, you will need to use the envsubst utility.
|
|
# It may come installed on your system, or be available in your OS package manager. Or,
|
|
# you can use the Python one-liner wrapper function included in this sample project.
|
|
# To replace environment variables, you need to change your `antidote bundle` call to
|
|
# this.
|
|
#
|
|
# zsh_plugins=${ZDOTDIR:-~}/.zsh_plugins.zsh
|
|
# envsubst <${zsh_plugins:r}.txt | antidote bundle >|$zsh_plugins
|
|
#
|
|
###
|
|
# reference your own plugins
|
|
# $ZSH_CUSTOM/plugins/nodejs
|
|
# $ZSH_CUSTOM/plugins/python
|
|
# $ZSH_CUSTOM/plugins/ruby
|
|
|
|
|
|
### Prompts
|
|
#
|
|
# You can make certain themes available to the built-in Zsh prompt command using the
|
|
# `kind:fpath` annotation. A theme is not active for the prompt until this command is
|
|
# run:
|
|
#
|
|
# autoload -Uz promptinit && promptinit
|
|
# prompt ${prompt_name:-pure}
|
|
#
|
|
# There are two ways to load prompts.
|
|
# - Add multiple prompt plugins to your `$fpath` with `kind:fpath` and then later in
|
|
# your .zshrc run the Zsh built-in `prompt` to select the theme.
|
|
# - Or, just load one prompt like a regular plugin.
|
|
#
|
|
###
|
|
|
|
# Use kind:fpath for prompts you want available to promptinit.
|
|
romkatv/powerlevel10k
|
|
|
|
# Or, just load a prompt plugin the normal way.
|
|
#sindresorhus/pure
|
|
|
|
|
|
### Utilities
|
|
#
|
|
# Utilities aren't traditional Zsh plugins - they aren't sourced Zsh scripts. Instead
|
|
# they provide commands that can be executed from your terminal session. One good
|
|
# example is zsh-bench, which is a utility that benchmarks your Zsh config. Utility
|
|
# bundles can often be made available simply with the `kind:path` annotation.
|
|
#
|
|
###
|
|
romkatv/zsh-bench kind:path
|
|
hkupty/ssh-agent
|
|
|
|
### Frameworks
|
|
#
|
|
# Frameworks are a collection of Zsh features, settings, and plugins meant to ease
|
|
# Zsh configuration. Unfortunately, all that power can come with serious drawbacks.
|
|
# Frameworks can often set more settings or aliases than you need, cluttering your Zsh
|
|
# config and slowing things down. Use with caution!
|
|
#
|
|
# Frameworks are handled in antidote using the `path:location/of/plugin` annotation.
|
|
#
|
|
###
|
|
|
|
### Framework: Oh-My-Zsh
|
|
#
|
|
# Oh-My-Zsh is a very popular Zsh framework. You might choose to use plugins from OMZ
|
|
# in your own config. Depending on which plugins you use, you may also need to include
|
|
# OMZ's entire "lib" directory. If you do this, be careful - "lib" configures a lot of
|
|
# very broad settings. If you are familiar with what you are doing, you may choose to
|
|
# only include parts of "lib".
|
|
#
|
|
# # use all of lib
|
|
# ohmyzsh/ohmyzsh path:lib
|
|
# # -OR-, only use only the specific files we care about
|
|
# ohmyzsh/ohmyzsh path:lib/clipboard.zsh
|
|
#
|
|
####
|
|
# ohmyzsh/ohmyzsh path:lib
|
|
#ohmyzsh/ohmyzsh path:plugins/copybuffer
|
|
# ohmyzsh/ohmyzsh path:plugins/copyfile
|
|
# ohmyzsh/ohmyzsh path:plugins/copypath
|
|
# ohmyzsh/ohmyzsh path:plugins/extract
|
|
# ohmyzsh/ohmyzsh path:plugins/magic-enter
|
|
# ohmyzsh/ohmyzsh path:plugins/fancy-ctrl-z
|
|
#ohmyzsh/ohmyzsh path:plugins/git
|
|
#ohmyzsh/ohmyzsh path:plugins/kubectl
|
|
|
|
|
|
### Framework: Prezto
|
|
#
|
|
# Prezto is another popular Zsh framework. You might choose to use parts of it in your
|
|
# config alongside/instead of OMZ. Prezto has some key differences from OMZ. For
|
|
# starters, it doesn't have a lib directory and it calls its plugins 'modules'. Its
|
|
# modules also often have functions directories that need autoloaded. And, because it's
|
|
# meant to be used as an integrated framework, Prezto modules don't operate well as
|
|
# cherry-picking independent plugins, so using Prezto with antidote is not recommended
|
|
# for anyone but the most advanced Zsh users.
|
|
#
|
|
###
|
|
|
|
# Prezto can be difficult to assemble because it's so interdependent.
|
|
# Use at your own risk.
|
|
# sorin-ionescu/prezto path:modules/helper/functions kind:autoload
|
|
# sorin-ionescu/prezto path:modules/helper
|
|
# sorin-ionescu/prezto path:modules/environment
|
|
# sorin-ionescu/prezto path:modules/terminal
|
|
# sorin-ionescu/prezto path:modules/editor
|
|
# sorin-ionescu/prezto path:modules/directory
|
|
# sorin-ionescu/prezto path:modules/git/functions kind:autoload
|
|
# sorin-ionescu/prezto path:modules/git
|
|
|
|
# And Prezto has tons more...
|
|
# sorin-ionescu/prezto path:modules/history
|
|
# sorin-ionescu/prezto path:modules/spectrum
|
|
# sorin-ionescu/prezto path:modules/utility/functions kind:autoload
|
|
# sorin-ionescu/prezto path:modules/utility
|
|
# sorin-ionescu/prezto path:modules/completion
|
|
# sorin-ionescu/prezto path:modules/history-substring-search
|
|
# sorin-ionescu/prezto path:modules/prompt/functions kind:autoload
|
|
# sorin-ionescu/prezto path:modules/prompt
|
|
# sorin-ionescu/prezto path:modules/python
|
|
# sorin-ionescu/prezto path:modules/python/functions kind:autoload
|
|
# sorin-ionescu/prezto path:modules/osx conditional:ismacos
|
|
# sorin-ionescu/prezto path:modules/osx/functions kind:autoload conditional:ismacos
|
|
|
|
|
|
### Framework: zsh-utils
|
|
#
|
|
# zsh-utils is a micro-framework that is also well suited to pair with antidote. It
|
|
# provides much of the same core functionality from other bigger frameworks without the
|
|
# bloat or performance hit. Using zsh-utils, you may find you don't need much else.
|
|
# If you want a really thin framework, this is great.
|
|
#
|
|
###
|
|
belak/zsh-utils path:history
|
|
belak/zsh-utils path:utility
|
|
belak/zsh-utils path:editor
|
|
|
|
### Deferred Plugins
|
|
#
|
|
# Antidote allows you to defer loading plugins. This is similar to concepts like "turbo
|
|
# mode" in other plugin managers. Antidote handles deferring plugins by leveraging
|
|
# romkatv/zsh-defer, which "defers execution of a zsh command until zsh has nothing else
|
|
# to do and is waiting for user input". In general, you should not defer plugins unless
|
|
# you know for sure they properly support deferred loading, and there are no adverse
|
|
# side-effects (see: https://github.com/romkatv/zsh-defer#Caveats). However, for
|
|
# certain plugins, this can greatly increase your zsh startup speed.
|
|
#
|
|
###
|
|
# Syntax highlighting
|
|
#zsh-users/zsh-syntax-highlighting kind:defer
|
|
zdharma-continuum/fast-syntax-highlighting kind:defer
|
|
|
|
|
|
### Completions
|
|
#
|
|
# You may want to add some additional completions to Zsh. Completions look in your fpath
|
|
# for completion functions, which are functions named with a leading underscore
|
|
# (eg: _git). You need to add all supplemental completions to your fpath prior to
|
|
# running `compinit` to use completions functionality properly. You will want to find
|
|
# a completion plugin that runs `compinit` for you, or you can run it yourself in
|
|
# your .zshrc after antidote loads like this:
|
|
#
|
|
# autoload -Uz compinit && compinit
|
|
#
|
|
###
|
|
|
|
# zsh-users/zsh-completions is a popular plugin for adding supplemental completions.
|
|
# We combine the `path:` and `kind:fpath` annotations here:
|
|
zsh-users/zsh-completions path:src kind:fpath
|
|
|
|
|
|
# Compinit plugins should be near the end of .zsh_plugins.txt so that $fpath has been
|
|
# fully populated. Use zsh-utils for its completion plugin.
|
|
belak/zsh-utils path:completion
|
|
|
|
|
|
### Final Plugins
|
|
#
|
|
# Remember plugin order matters! Put plugins that need run last at the bottom of your
|
|
# .zsh_plugins.txt file.
|
|
#
|
|
###
|
|
|
|
# These popular core plugins should be loaded at the end
|
|
zsh-users/zsh-autosuggestions kind:defer
|
|
zsh-users/zsh-history-substring-search
|
|
|