为何 Emacs 至今不支持 font ligatures

目前的主流编辑器(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)

我不是作者,就是个给 homebrew 打包的…

作者是这个 Bitbucket

1 个赞

因为GUI的Emacs是根据字符宽度来排列的。如果能支持的话,也就不需要设置字体就能中英文等宽了。

你没发现其它编辑器要做到等宽都用不着换字体吗。。

3 个赞

请问 mac port 启用 ligatures 是启用 “mac-auto-operator-completion-mode” ?

C-h f一下就知道了。 的确是这个。

我看支持列表里的编辑器并没有比不支持列表里的编辑器更“主流”啊?:joy:

以上是关于标题栏选项。

区别是emacs-plus是基于官方版整合了几个补丁(比如标题栏),而mac-port本身已经集成了比较多的特色功能,比如macOS原生词典,支持emoji,触控板手势,过渡动画,自定义修饰键,未保存时终止关机之类的。

1 个赞

的确很好看,对编程来说未必都是好事,如果没有对比,很容易混淆 ===

对,是这个。

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 除了半圆缺角,两个 = 的连字符比不连字的 == 要短一些,左右两侧少许空白,并不会造成混淆。其他连字符也是同样的效果。