* clipboard: Reduce unnecessary special-casing on stdin
Ideally the parameter would just be removed-users could always
just do "clipcopy < some-file". but removing the parameter would break
backwards compatibility.
In any case, this simplifies the logic considerably.
* clipboard: Avoid unnecessary re-detection each time
Previously, OS detection would happen on each invocation. This makes it
happen once (unless it fails, in which case it will try again on the
next invocation).
This has the additional benefit of localizing the platform-specific
checks and commands, too, versus spreading them out in separate
functions.
* clipboard: Add support for several more clipboards
This implements essentially the same heuristic as neovim, with the additional
(existing) special support for Cygwin.
See: e682d799fa/runtime/autoload/provider/clipboard.vim (L55-L121)
- pbcopy, pbpaste (macOS)
- cygwin (Windows running Cygwin)
- wl-copy, wl-paste (if $WAYLAND_DISPLAY is set)
- xclip (if $DISPLAY is set)
- xsel (if $DISPLAY is set)
- lemonade (for SSH) https://github.com/pocke/lemonade
- doitclient (for SSH) http://www.chiark.greenend.org.uk/~sgtatham/doit/
- win32yank (Windows)
- tmux (if $TMUX is set)
* clipboard: Fix tmux clipcopy after testing
Tmux must have special handling for /dev/stdin since it's managing the
terminal itself. This was tested with tmux-2.9a on macOS.
* clipboard: Fix bad expansion of exit-code test
Current state: a user invokes `ipython` and is provided with the IPython
instance regarding the `$PATH`.
Proposed state: a user invokes `ipython` (which is a new alias in the
*python plugin*) and is provided with the proper IPython instance regarding
the currently activated virtualenv.
Example: the user's default Python is 2.7 with installed IPython 2.7. User
activates Python 3.5 virtualenv where he installs IPython 3.5. After
activating the environment, one expects `ipython` to run the version 3.5,
which does not happen by default. Instead, IPython 2.7 is used, which in
counter-intuitive and often causes problem.
Closes#5797
If I have custom configs (like theme customizations) I have to stash my changes and get them back after the update.
By adding the --autostash on upgrade.sh, if I have any changes not commited they'll be reapplied after the upgrade, allowing me to have temporary customizations without any harm to the upgrade process.
Also add comments and unset leftover variables, and print only the
name of the theme loaded.
When looking for $ZSH_CUSTOM themes, the chosen algorithm is to add
the theme names to the pool disregarding the path, and then source
whatever theme is selected with the same logic as the init script,
which is to source first custom themes even if there is another
default theme of the same name.
Co-authored-by: Mihai Serban <mihai.serban@gmail.com>
The statements for selecting a random theme in oh-my-zsh.sh and the themes
plugin are duplicate. Most people eventually settle on a theme, making those
lines in oh-my-zsh.sh superfluous. To address those, it may makes sense to put
the random theme functionality into a theme of its own (since themes are just
zsh scripts.
Gustavo Maia