目前的主流编辑器（Macvim, Atom, VSCode, TextMate …），除了 Emacs，几乎都支持的特性，没理由Emacs不支持啊
如果用 prettify-symbol-mode 来模拟，会有字符长度不同所带来的各种问题
Some Haskellers have resorted to Unicode symbols (⇒, ← etc.), which are valid in the ghc. However they are one-character-wide and therefore eye-strainingly small.
Mac port 支持。
官方的估计是哪个平台的支持拖了后腿？
蛙，活捉mac port 作者！话说Macport 和 emacs-plus 区别有哪些呢，有关Mac UI的一些特性好像 emacs-plus 也有？
–with-natural-title-bar Build with an inferred title bar colour (–HEAD is supported) –with-no-title-bars Build with a patch for no title bars on frames (neither --HEAD nor --devel currently supported)
因为GUI的Emacs是根据字符宽度来排列的。如果能支持的话，也就不需要设置字体就能中英文等宽了。
你没发现其它编辑器要做到等宽都用不着换字体吗。。
请问 mac port 启用 ligatures 是启用 “mac-auto-operator-completion-mode” ？
C-h f一下就知道了。 的确是这个。
以上是关于标题栏选项。
区别是emacs-plus是基于官方版整合了几个补丁（比如标题栏），而mac-port本身已经集成了比较多的特色功能，比如macOS原生词典，支持emoji，触控板手势，过渡动画，自定义修饰键，未保存时终止关机之类的。
对，是这个。
Mac port 是基于之前 Carbon port 的改进，而现在官方的 Emacs 支持是另起炉灶的 Nextstep port，为了照顾 GNUstep 项目。不过我对 Emacs-plus 了解不多所以不好比较。
Mac port 的渊源和特性具体的可以看 Mac port 的 README-mac，写的非常详细。 https://bitbucket.org/mituharu/emacs-mac/src/2c7094c3affa620011b762a7f93268fdf8a7f75e/README-mac?at=master&fileviewer=file-view-default
@twlz0ne 我觉得 Ligature 的绘画对字体设计的水平要求其实很高，不只是简单的把看上去很 fancy 的符号画出来就完事的。同样是双等号的设计，PragmataPro 里在下面那条横线中间加上了一个半圆形的缺口，兼顾了美观和识别性。
我认为等宽问题会变得更复杂，其他编辑器应该是先解决了等宽，然后才支持这个特性。
要求更高我同意，但是能不能真正做到兼顾美观和辨识是个问题。
通常样板给出效果的看起来很美，一旦放到真实场景中，可能效果就没那么明显，比如你提到的 pragmatapro (如果把图片字号缩放到接近编辑器字体大小，半圆形缺口很容易被忽略)：
而我前面提到的 Fira Code 更糟，展示的样板就给了两种几乎一样、只是长度稍有区别的符号。如果单独出现，很难区分是哪一种：
PragmataPro 除了半圆缺角，两个 = 的连字符比不连字的 == 要短一些，左右两侧少许空白，并不会造成混淆。其他连字符也是同样的效果。
