我从 Vim 外部复制文本。 ⌘V 在其他应用程序中粘贴文本没有问题。在 MacVim 中，它不起作用。
在插入模式下，什么都不显示。在正常模式下，我得到 E353: Nothing in register + 。当 set clipboard=unnamed 打开或关闭时会发生这种情况。
奇怪的是，这以前是有效的。怎么了？
最佳答案
如果您使用 tmux 并且有时您最初通过 mvim 命令行程序启动 MacVim，那么您可能会遇到促使我编写 reattach-to-user-namespace command 的问题。
我的猜测是剪贴板访问在以前的情况下有效，因为您碰巧通过“正常”GUI 方法(例如 Dock、Finder、Spotlight 等)启动了 MacVim。在您退出 MacVim 的先前实例并通过(例如)mvim 从 tmux session 内部重新启动它后，剪贴板后来变得无法访问。
核心问题是在某些上下文中(即在 tmux session 中)启动的程序最终会导致环境拒绝它们访问某些服务(例如 OS X 粘贴板)。
最初的发布在这里很重要。由 mvim -in-tmux 启动的新窗口(即使没有上面链接的包装程序)应该可以访问剪贴板，只要 MacVim 之前是“通过 GUI”启动的(也许仍然有一些 MacVim 窗口打开，或者你将 MacVim 配置为即使没有打开窗口也能继续运行)。相应地，要重新访问剪贴板，您需要关闭所有现有的 MacVim 窗口，退出应用程序，然后以可以访问剪贴板的方式(例如，通过 GUI，或“在包装器内部”)重新启动它。
一旦你安装了上面链接的包装程序(它也可以通过 MacPorts 和 Homebrew 获得)，你可以使用像 reattach-to-user-namespace mvim 这样的命令来确保 如果 它最终会启动一个新实例，然后启动一个新的 MacVim到剪贴板。您可以使用别名、shell 函数或脚本来确保始终“包装” mvim 。
其他几个命令也受益于“包装”( pbpaste 、 pbcopy 、 nohup 、 launchctl )，而不是使用您的单个命令来“包装您的单个 shell”，而不是使用您的子命令“包装器”修改的进程环境的一部分是由子进程继承的，因此“包装”您的 shell 将影响您从中运行的大多数命令。如果你使用 tmux，你可以配置你的 default-command 来自动“包装”你的默认 tmux shell:
set-option -g default-command "reattach-to-user-namespace -l zsh"
关于clipboard - 无法粘贴到 MacVim，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/16618992/