Emacs框架背景颜色和默认面部背景设置相等,但#010101显示不同

Question

我将框架背景颜色和默认面部背景颜色都设置为#262626:

(add-to-list 'default-frame-alist '(background-color . "#262626"))
(set-face-attribute 'default nil
                    :background "#262626")

尽管如此,它们的呈现方式略有不同:

差异几乎不明显.如果你在GIMP或类似的中看到这个,你可以看到有文字的背景是#262626,而没有文字的背景(空白行)是#252525.这困扰我.

奇怪的是,为两者设置#242424时不会发生同样的事情:

那么为什么不使用#242424并完成它呢？我坚持#262626,因为我希望Emacs与我的xterms颜色相同,而我的xterms就是那种颜色,因为它在256色表中的数字是235.我希望在xterm中运行的256色应用程序能够精确地再现背景颜色.

我的问题是:我如何让Emacs渲染帧背景和文本背景相同？

(我意识到我听起来像一个疯狂的人关心这个,但没有理由为什么它不能正常工作,这让我疯了.)

这是Arch Linux上的Emacs 24.3.

Answer 1

啊哈！我已经发现了问题所在。这是一个可恶的舍入错误。

• 这是 bzr rev 116690（git commit 08885465fcc080f369f0958fcd85e37e28a7526f）。

• ./autogen.sh， 然后：

  ./configure --prefix=/opt/emacs/usr --sysconfdir=/opt/emacs/etc \
      --libexecdir=/opt/emacs/usr/lib --localstatedir=/opt/emacs/var \
      --with-x-toolkit=gtk3 --with-xft CFLAGS=-g
  

• 安装目录位于下方/opt/emacs，以避免破坏现有安装。

• make, (sudo) make install, gdb src/emacs.

罪魁祸首是xg_set_widget_bg函数src/gtkutil.c。在第 1039 行设置断点，该断点根据浮点颜色值设置背景：

gtk_widget_override_background_color (w, GTK_STATE_FLAG_NORMAL, &bg);

就我而言，第一次调用xg_set_widget_bg是无关紧要的。第二个是有趣的地方。戳结构：

Breakpoint 1, xg_set_widget_bg (f=0x1209908, w=0x1658110, pixel=2500134) at gtkutil.c:1039
1039          gtk_widget_override_background_color (w, GTK_STATE_FLAG_NORMAL, &bg);
(gdb) print xbg
$1 = {pixel = 2500134, red = 9764, green = 9764, blue = 9764, flags = 7 '\a', pad = 0 '\000'}
(gdb) print bg
$2 = {red = 0.14898908979934386, green = 0.14898908979934386, blue = 0.14898908979934386, alpha = 1}
(gdb) print bg.red * 0xffff
$3 = 9763.9999999999982
(gdb) print bg.red * 0xff
$4 = 37.992217898832678
(gdb) set bg.red = bg.green = bg.blue = (double)0x26 / 0xff
(gdb) print bg
$5 = {red = 0.14901960784313725, green = 0.14901960784313725, blue = 0.14901960784313725, alpha = 1}
(gdb) print bg.red * 0xffff
$6 = 9765.9999999999982
(gdb) print bg.red * 0xff
$7 = 37.999999999999993

cont，然后看到问题神奇地消失了。调试器非常酷。

如果您想了解 Emacs 如何获取 中的值xbg，还可以查看xfns.c。当您说 时(set-background-color "#262626")，Emacs 将每个分量转换为 0x2600，然后向 X 询问最接近的颜色值。这里是 9764 (0x2624)。您可以使用 进行验证xmag，因为它报告 16 位组件。

显然，GTK 将其像素值缩放为 0xff，并且有足够的误差使其四舍五入（下限？）为 37 (0x25)，而不是 38 (0x26)。文本渲染是在其他地方完成的，不会出现同样的问题。

最后，我认为这主要是 GTK 的错。我现在不想接触 GTK 源代码，但至少我知道发生了什么。