1. 引言
上一篇文章中，我们介绍了如何用 lua 来配置 neovim：
最近，我又将工作环境迁移到了 windows 中，在 windows + wsl2 的环境下进行日常的开发工作，这样一来，neovim 在 wsl 内就显现出了一些新的问题，于是我也就对 neovim 的一些配置进行了修改，本文，我们就来聊聊，我在 wsl 中使用 neovim 的过程中遇到了哪些问题以及是如何解决的。
关于 wsl2 的安装和升级，以及可能遇到的问题，之前的文章已经介绍过，可以参看之前的文章：
关于我本文讲到的 nvim 配置，我已经推送到了我的 github上，可以自取：
2. 编码问题
首当其冲，我遇到的问题就是编码问题。因为 unix 系统的编码方式默认使用的是 unicode 编码，而 windows 默认的编码格式则是 gbk 编码，这样一来，文本从 windows 复制，再粘贴到 wsl 中时，就会出现乱码，反过来也是一样。
但实际上，windows 默认编码格式采用 gbk 也是微软的无奈之举，因为有大量的历史包袱需要兼容。对于主要使用现代软件的我们来说，绝大部分软件都已经指定了编码格式，而不是采用 win32 API 的默认编码格式，所以即使修改了 windows 的默认编码格式，一般也不会有什么影响。
windows10 开始，提供了将默认编码格式切换为 UTF-8 的设置选项：在设置 -> 时间和语言 -> 语言和区域的“管理语言设置”选项下，点击会弹出“区域”设置对话框。在“管理”标签页，点击“更改系统区域设置”按钮，会弹出“区域设置”对话框。勾选其中的“Beta：使用 Unicode UTF-8 提供全球语言支持”，然后点击确定按钮，重启电脑即可生效。
这个操作既然隐藏得这么深，并且还特意标注了“Beta”，就说明这一操作是有风险的。这个设置的原理是，早在 dos 时代，微软为了操作系统的多语言适配，创造了一个“本地代码页”的概念，也就是让不同的国家和地区使用不同的本地编码集，有点类似于现在软件多语言版本的语言配置文件。随着时代的发展，软件普遍都采用了 unicode 编码，将各个语言的字符集全部都编入这一套编码集中，所以 unicode 编码又称为“万国码”、“统一码”。然而，windows 为了兼容以前使用本地代码页的程序，仍然为不同语言版本的系统 API 返回对应的代码页，中文系统下，就会返回 cp936 这个页，对应的编码方式就是 gbk 编码方式下的具体格式，例如 gb2312、gb18030 等。
所以，一旦勾选并应用了这个 Beta 功能，windows API 返回的本地代码页会变更为 65001，有些依赖本地代码页这一传统功能的软件，如果又没有适配 65001 代码页，就会出现乱码，甚至崩溃。但也不必过分担心，如果你发现乱码和崩溃涉及到了你经常使用的软件，那你可以选择再改回来即可。
应用这一功能的好处也很明显，首先是 wsl 等等 unix 生成的文件、文件名在 windows 上都不再会出现乱码，同时，如果软件运行的路径中包含中文，原本很多会崩溃的国外软件也不再会崩溃了，所以我还是选择打开了这个选项，并且用着感觉很不错。推荐在 windows 下工作的开发者开启这个选项。
不过开启这个选项以后，我在 cmd 和 powershell 内，遇到了很多本地化后的软件会出现乱码，这个也很好解决，只需要在这些命令执行前，先执行以下命令，重新设置本地代码页为 cp936 即可：
chcp 936
2. 让 wsl2 中的 neovim 使用 windows 剪贴板
上一篇文章中我们介绍过，开启以下选项，可以让 neovim 使用系统剪贴板，从而 neovim 中的复制粘贴更加符合直观预期：
vim.opt.clipboard = 'unnamedplus'
然而，当 neovim 的装在 wsl2 中的时候，由于 wsl2 相当于是一个运行在 hyper-v 上的虚拟机，在其中的剪贴板自然也就和外面的 windows 系统不互通了。
解决办法是让 neovim 每次复制和粘贴发生时，都让它通过 clip.exe 与外部交互，就可以获取到 windows 剪贴板的信息了。具体的配置如下：
do local clip, opts = '/mnt/c/Windows/System32/clip.exe', {}
function opts.callback()
if vim.v.event.operator ~= 'y' then return end
vim.fn.system(clip, vim.fn.getreg(0))
end
if vim.fn.executable(clip) then
opts.group = vim.api.nvim_create_augroup("WSLYank", {clear = true})
vim.api.nvim_create_autocmd("TextYankPost", opts)
end
end
这样一来，在 wsl 中，每当复制和粘贴文本，就会默认执行 clip.exe，实现与宿主机剪贴板的互通。
3. 换行问题
经过上述配置，又引入了新的问题，那就是换行问题。windows 是以 rn 两个字符来进行换行的，而在 unix 中，则是以 n 一个字符来实现换行的。这样一来，一旦从 wsl 中复制一段文本进入到 windows 的剪贴板，再粘贴，就会发现每一行的末尾莫名其妙地变成了 rn 换行。
那么， 如何进行配置实现自动替换 rn 为 n 呢？可以增加以下配置：
function ReplaceCrLfOnPaste()
local cursor_save = vim.fn.getpos('.')
vim.fn.setreg('+', vim.fn.substitute(vim.fn.getreg('+'), 'rn$', 'n', ''))
vim.fn.setpos('.', cursor_save)
end
vim.api.nvim_exec([[
augroup ReplaceCrLfOnPaste
autocmd!
autocmd TextYankPost * lua ReplaceCrLfOnPaste()
augroup END
]], false)
4. 结语
经过三年多主要使用 MacOS 来办公以后，最近迁移到 windows 平台从事开发工作，感觉还是有挺大变化。由于我日常主要是使用 JetBrains 家的 IDE 进行开发，而这些 IDE 又是跨平台的，所以我的日常工作在哪个平台都可以正常地开展。
而 windows 自从有了多桌面和 linux 子系统的加持，日常的开发体验也日趋完善。尤其是近来 wsl2 更新以后，让 wsl2 与宿主机共用同一个 ip，并且 wsl2 可以通过设置是否使用 windows 的系统代理以及 wsl2 的网络模式等等众多参数，让 wsl2 的使用越来越和 windows 本身无缝地衔接起来。
唯一美中不足的是，wsl2 与宿主机之间的 io 通信仍然效率很低，如果将代码放在 windows 磁盘上，然后在 wsl 中编译，那个编译速度实在让人抓狂，于是我选择将代码全部放在 wsl 中，然后启用 wslg，也就是图形化的 linux 界面来运行 JetBrains 程序。除了额外多出来的边框以外，在操作上与 windows 原生程序并没有什么区别，怪不得很多人调侃说 windows 现在已经成为了用户量最大的 linux 发行版。
更让人感到惊喜的是，wsl 和其他虚拟机一样，支持导出和导入，这样一来，在工作电脑、家用电脑之间同步自己独特的工作环境就变得异常轻松了。
不过 windows terminal 就有些失望了，虽然在运行速度、毛玻璃效果等方面让人感受到这是一个现代的产品，但在功能上，现在还是十分欠缺，所以我还是选择使用了开源的 WindTerm 来作为我的 terminal 工具。
总的来说，windows 作为开发环境已经做到非常方便好用了，相较于多年前的使用，也能够深切体会到它的变化和进步，还是让人比较满意的。
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，一年会员只需98元，全站资源免费下载 点击查看详情
站 长 微 信： lzxmw777
