ncurses中的颜色对未使用正确的颜色

问题描述 投票:4回答:1

我正在尝试使用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到底发生了什么?

P.S。如果我使用Lisp会使事情变得更困难,我真的感到抱歉,我知道这不是通用语言。当时这似乎是个好主意,到目前为止还不错...

编辑:我已重新启用libncursesw6.1,并启用了--with-trace,这是来自跟踪文件的相关信息:

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,根据调试信息,颜色对应该是颜色13上的颜色8(与代码中的颜色匹配),但是trace文件指出它是实际上使用第五对颜色,我在代码中的任何地方都没有使用过:

+ 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

因此,我上面的猜测确实是正在发生的事情。即使颜色和颜色对正确地pass传递给了ncurses,颜色对5和7也显示为相同。

我正在尝试使用ncursesw6.1(链接到PicoLisp)。据我所知,PicoLisp以这样的方式直接传递值,即我通过非C语言调用ncurses的事实不应该是...

unix colors terminal ncurses picolisp
1个回答
0
投票

根据@ christopher-dumas,问题是PicoLisp中的error

好吧,我知道问题出在哪里颜色对的实现不正确,因为Picolisp仅具有右移运算,并且操作数顺序与C所使用的相反。显然,我最初采用颜色对的来源是错误的。对于新的实现,我从ncurses源代码中的lib_gen.c复制了它。新的实现是:

© www.soinside.com 2019 - 2024. All rights reserved.