相较于Emacs，emacsclient的弊端有哪些？能否将emacsc始终别名emacsclient？

嘿，这两个问题问得挺实在的，结合我多年用Emacs的经验，给你详细说说：

emacsclient确实启动快，但它本质是“客户端”，依赖后台的Emacs守护进程，这就导致它有不少天生的局限：

• 没法单独跑起来：要是后台没开emacs --daemon，emacsclient要么直接报错，要么自动帮你启动一个守护进程——这时候第一次启动的速度和直接开Emacs没差，完全体现不出它的优势。
• 完全依赖守护进程的状态：所有emacsclient会话共享同一个守护进程的配置、插件和状态。比如你在一个client里装了新插件，所有client都会立刻生效，但要是守护进程崩了，所有打开的client都会跟着挂掉。而且有些需要在Emacs启动阶段触发的全局钩子或者系统级配置，在client里根本没法重新触发，因为守护进程早就初始化完了。
• 启动参数支持有限：直接开Emacs的时候，你能用emacs --debug-init调试启动问题，或者emacs --init-file ~/my-test-config.el用自定义配置启动，但emacsclient的参数选项少得可怜，这些常用的调试和定制功能都没法直接用。
• 做不到完全隔离的环境：要是你需要同时开两个完全独立的Emacs环境（比如一个用工作配置，一个用私人配置），emacsclient根本做不到——因为它共享同一个守护进程的所有状态。但直接开多个Emacs实例就能轻松实现隔离。

绝对不建议这么做，很多场景下会给你添乱，原因主要有这几点：

• 首次启动和临时独立实例需求无法满足：如果后台没守护进程，别名后的emacs（也就是emacsclient）会自动启动守护进程，但这时候速度没优势。而且要是你只是想临时开一个不共享状态的独立Emacs实例，别名之后你得特意取消别名或者用绝对路径调用原生emacs，非常麻烦。
• 调试和定制场景直接失效：比如你要调试启动配置的错误（emacs --debug-init），或者用测试配置启动Emacs，emacsclient不支持这些参数，别名之后这些常用的调试操作就没法直接做了，得绕很大的弯子。
• 守护进程崩溃会牵连所有会话：要是后台的守护进程崩了，你再执行别名后的emacs，要么启动失败，要么重新开一个守护进程，但之前所有client的状态都丢了。而直接启动Emacs的话，每个实例都是独立的，一个崩了不影响其他。
• 系统工具或脚本可能兼容出问题：有些系统脚本、工具或者第三方插件会直接调用emacs命令，它们预期的是原生的Emacs进程，而不是连接到守护进程的client。别名之后，这些工具可能会出现奇怪的行为——比如有些脚本需要Emacs执行完命令就退出，emacsclient的行为和原生Emacs在这种场景下可能不一致。

内容的提问来源于stack exchange，提问作者Li Chen