不同于 Python 之类的项目， C/C++ 的项目需要有专门的编译环境，一般国内公司都会搭建特定的编译环境机器，把一些私有的库等依赖放在上面。而这些编译环境的工具链一般都比较老旧，有的编译环境可能还无法访问外网，甚至也没有提供代理间接访问外网。因此想要在这样的环境中使用 Emacs 开发代码着实不是一件容易的事。
一个可行的方法是在自己的工作机器上维护一个开发环境跑 Emacs ，需要编译的时候把代码同步到编译机器（使用 sshfs 、 sftp 等），编译过程中发现的编译问题，在本地修复好之后，再次同步，如此往复。
但是有一个问题，整个流程太过繁琐，需要不停地手工同步。即使像 sshfs 这样无须同步的方式，在本地编辑时偶尔卡顿会比较明显。最让人无法接受的是，在修复编译的过程中，需要手工定位到具体的文件及行数，繁琐而且效率低。
你可能会说为什么不用 Tramp 模式直接在远端的编译环境中直接编辑文件呢？的确， Tramp 编辑代码没有问题，体验也挺流畅的，但它无法解决你无法自由控制远端环境这个缺点，比如你想集成 ag/rg 到 Emacs 中，光安装程序可能就很折腾；而且如果公司有多套编译环境时，每个环境都维护 Emacs 会是一个麻烦。
经过一段时间的摸索，我感觉自己还是比较喜欢在本地编辑然后同步代码编译这种方式，这个过程可以自动化。另外很重要的一点需求是，它需要能够像 M-x compile 那样在 Emacs 中很方便地使用 M-x next-error and M-x previous-error 来自动定位编译有问题的代码行，这样不仅提高修复编译错误的效率，还能保护视力。
按照上述思路我最终写了这样一个小插件 ppcompile ， pp 二字代表 ping-pong ，表示每次编译就像打乒乓球一样。本地先发球，利用 rsync 把代码同步到远端，远端编译之后回球，然后本地再转换 *compilation* buffer 中远端的路径，这样 Emacs 就能够正确地识别编译错误，从而帮助我直接打开对应的错误文件及行数。
使用方式上，只需要把 ppcompile.el 拷贝到 load-path 中进行加载，然后设置一些选项即可。具体可以参考项目 README 。当前提供以下几个命令：
ppcompile-ping仅同步代码到远端ppcompile-pong仅在远端编译ppcompile同步代码以及编译，即一次 ping-pong 往返。 这个命令和ppcompile-pong命令在使用上同时考虑了 compile 命令的使用习惯，会遵循你的compilation-read-command设置决定是否编译时弹窗让你选择编译命令。ppcompile-config-project配置项目配置到根目录的.dir-locals.el中，主要是为了方便有很多项目时的个性化定制需求，否则直接配置全局的就可以了。ppcompile-toggle-debug调试开关命令，在开启的情况下会把当前执行的命令行打印到*Message*中。
目前，我自己使用 ppcompile 已经没有什么问题了，它在最近的项目开发中帮我节省了不少精力，欢迎大家试用和使用 :)