unix - ncurses 中的颜色对没有使用正确的颜色

标签 unix colors terminal ncurses picolisp

我正在尝试使用 ncursesw6.1(链接到 PicoLisp)。据我所知,PicoLisp 以这样一种方式直接传递值,以至于我通过非 C 语言调用 ncurses 的事实不应该是一个因素 [1] .但是,当我尝试使用颜色对(这样定义)时:

(curses "init_pair" NIL 1 *COLOR-SCHEME-TEXT *COLOR-SCHEME-BACKGROUND-DARK)
(curses "init_pair" NIL 2 *COLOR-SCHEME-COMMENT *COLOR-SCHEME-BACKGROUND-DARK)
(curses "init_pair" NIL 3 *COLOR-SCHEME-FUNCTION *COLOR-SCHEME-BACKGROUND-DARK)
(curses "init_pair" NIL 4 *COLOR-SCHEME-VALUE *COLOR-SCHEME-BACKGROUND-DARK)
(curses "init_pair" NIL 5 *COLOR-SCHEME-BACKGROUND-DARK *COLOR-SCHEME-COMMENT)
(curses "init_pair" NIL 6 *COLOR-SCHEME-BACKGROUND-DARK *COLOR-SCHEME-FUNCTION)
(curses "init_pair" NIL 7 *COLOR-SCHEME-BACKGROUND-DARK *COLOR-SCHEME-VALUE)

它不起作用。相反,颜色对 1、2 和 3 都显示为相同的颜色对。然后 4 和 6 显示为 *COLOR-SCHEME-COMMENT超过 *COLOR-SCHEME-BACKGROUND-DARK并且 5 和 7 显示为 4 和 6 的反面。这似乎与我输入的内容没有任何逻辑关系。更奇怪的是,当我使用非自定义颜色(颜色 0-7)时,它也不起作用,因此通过 init_color 定义了这些配色方案颜色。与它无关。

我已经单独测试了颜色对 1 的颜色,所以我知道颜色被正确初始化。
init_pair究竟是怎么回事? ?

附言如果我使用 Lisp 使这变得更难,我真的很抱歉,我知道它不是一种通用语言。当时这似乎是个好主意,到目前为止还不错……

编辑:我已经用 --with-trace 重新编译了 libncursesw6.1启用,这是来自跟踪文件的相关信息:
called {init_pair(0x1d74d00,1,10,8)
+ return }0
+ called {init_pair(0x1d74d00,2,12,8)
+ return }0
+ called {init_pair(0x1d74d00,3,11,8)
+ return }0
+ called {init_pair(0x1d74d00,4,13,8)
+ return }0
+ called {init_pair(0x1d74d00,5,8,12)
+ return }0
+ called {init_pair(0x1d74d00,6,8,11)
+ return }0
+ called {init_pair(0x1d74d00,7,8,13)
+ return }0

这些确实是正确的值,所以正确的值被传递给 init_pair .虽然自定义颜色不是问题,但对于那些想知道的人,这里是 trace *COLOR-SCHEME 上的文件信息颜色:
started color: COLORS = 256, COLOR_PAIRS = 65536
+ return }0
+ called {init_color(0x1d74d00,8,216,228,252)
+ + called {tparm("\e]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\e\\", 8, 216, 228, 252)
+ + return }"\e]4;8;rgb:37/3A/40\e\\"
+ return }0
+ called {init_color(0x1d74d00,9,908,956,896)
+ + called {tparm("\e]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\e\\", 9, 908, 956, 896)
+ + return }"\e]4;9;rgb:E7/F3/E4\e\\"
+ return }0
+ called {init_color(0x1d74d00,10,968,968,968)
+ + called {tparm("\e]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\e\\", 10, 968, 968, 968)
+ + return }"\e]4;10;rgb:F6/F6/F6\e\\"
+ return }0
+ called {init_color(0x1d74d00,11,612,748,1000)
+ + called {tparm("\e]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\e\\", 11, 612, 748, 1000)
+ + return }"\e]4;11;rgb:9C/BE/FF\e\\"
+ return }0
+ called {init_color(0x1d74d00,12,508,252,340)
+ + called {tparm("\e]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\e\\", 12, 508, 252, 340)
+ + return }"\e]4;12;rgb:81/40/56\e\\"
+ return }0
+ called {init_color(0x1d74d00,13,612,136,272)
+ + called {tparm("\e]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\e\\", 13, 612, 136, 272)
+ + return }"\e]4;13;rgb:9C/22/45\e\\"
+ return }0

另外,虽然我设置了wborder使用颜色对 7 的函数,根据调试信息,它应该是颜色 8 而不是颜色 13(与我的代码中的匹配),trace文件说它实际上使用了颜色对 5,我没有在代码中的任何地方使用它:
+ called {wborder(0x1da6cd0,{' ' = 040},{' ' = 040},{' ' = 040},{' ' = 040},{' ' = 040},{' ' = 040},{' ' = 040},{' ' = 040})
using {' ' = 040 | {A_BOLD|A_COLOR{5 = {color8, color12}}}}, {' ' = 040 | {A_BOLD|A_COLOR{5 = {color8, color12}}}}, {' ' = 040 | {A_BOLD|A_COLOR{5 = {color8, color12}}}}, {' ' = 040 | {A_BOLD|A_COLOR{5 = {color8, color12}}}}, {' ' = 040 | {A_BOLD|A_COLOR{5 = {color8, color12}}}}, {' ' = 040 | {A_BOLD|A_COLOR{5 = {color8, color12}}}}, {' ' = 040 | {A_BOLD|A_COLOR{5 = {color8, color12}}}}, {' ' = 040 | {A_BOLD|A_COLOR{5 = {color8, color12}}}}
+ return }0

所以,我上面的猜测是,确实,正在发生的事情。颜色对 5 和 7 显示相同,即使颜色和颜色对正确传递给 ncurses。

最佳答案

根据@christopher-dumas 的说法,问题是 error在 PicoLisp 中:

Okay I figured out what the problem was
color-pairs was implemented incorrectly, because Picolisp only has a right-shift operation, and the operand order is the oppsite of what C uses. Apparently, the source where I took the origional implementation of color-pairs was wrong. For the new implementation, I copied it from lib_gen.c in the ncurses source code. The new implementation is:


   (de color-pair (n)
       (& (>> -8 n) (>> -8 (- (>> -8 1) 1))))

在 ncurses 中,颜色对值是 chtype 中的一个 8 位字段。或 attr_t ,定义在 curses.h 标题。这是模板中的引用(@cf_cv_1UL@ 被替换以处理不允许数字后缀 UL 的非常旧的编译器):
#define NCURSES_ATTR_SHIFT       8
#define NCURSES_BITS(mask,shift) (NCURSES_CAST(chtype,(mask)) << ((shift) + NCURSES_ATTR_SHIFT))
...
#define A_COLOR     NCURSES_BITS(((@cf_cv_1UL@) << 8) - @cf_cv_1UL@,0)

关于unix - ncurses 中的颜色对没有使用正确的颜色,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53908383/

相关文章:

c - C套接字中需要多个连接

jquery - CSS3 - 修复透明导航 : Is there a way to color an element depending on the actually visible background of the element?

colors - Amstrad CPC 颜色

objective-c - OS X GUI Cocoa 应用程序与 shell 交互

unix - tmpfs docker 容器中没有足够的可用空间

linux - 检查进程的状态并在 unix 中完成时启动另一个脚本

linux - 使用 sed 将起始字符更改为另一个字符

java - 从 Java 调用 Windows 颜色系统

c - 是否可以将打印到终端的所有内容记录到 C 中的文本文件中?

java - 以编程方式从java调用Linux终端中的python脚本