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。我想要256色应用程序 在xterm中运行以便能够精确地再现背景颜色。

我的问题是：我如何让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，并且有足够的错误 使它圆（floor？）到37（0x25）而不是38（0x26）。文本渲染完成 在其他地方并没有同样的问题。

最后，我认为这主要是GTK的错。我真的不想碰这个 GTK现在来源，但至少我知道发生了什么。