Re: zcurses keycodes

[Ray Andrews <rayandrews@eastlink.ca>]

On 11/10/2015 01:36 AM, Peter Stephenson wrote:
> On Mon, 9 Nov 2015 16:55:26 -0800
> Ray Andrews <rayandrews@eastlink.ca> wrote:
>> I'm looking at a list of allowable keys in Sebastian's stuff, It includes:
>>
>> EOT
>> NAK
>> DLE
> Hmm... *those* look like ASCII key names rather than curses key
> definitions.  Try "man ascii" or
>
> http://man7.org/linux/man-pages/man7/ascii.7.html
>
> pws
>
Thanks Peter, yeah I know they're ASCII, but there seems to be a 
conflict, or one of those situations where one has no idea who owns a 
key.  I tried to add 'EXT' (^C of course), but it wouldn't take. The 
ones I mention show up in my editor as bright white boxes--clearly they 
are recognized as special--but no luck with EXT (tho I could capture ^C 
with " ${\x0A} ").

case "$NKEY" in
     (${\x0A})                ACTION='QUIT'; REPLY=-1 ;;
     ($'\n')                       REPLY=$IN[currentE]; ACTION='' ;;
     ($'\b'|\x7f|BACKSPACE) SEARCH_BUFFER="${SEARCH_BUFFER%?}" ;;
     (ETB\x17)                        [ "$SEARCH_BUFFER" = 
"${SEARCH_BUFFER% *}" ] &&\

" ETB " had to be added ... it didn't actually paste over, because I 
understand that it's some symbol, not literal text.  Point is that " ETB 
" 'works', but not  " EXT ".

So, I'm wondering who/where I'm not getting control of ^C via 'EXT' in 
zcurses.  Also, ^C behaves very strangely.  " zcurses input " treats ^C 
differently depending on whether the call is inside a function or not.  
In some situations it creates a repetition of the previous keystroke. 
Sometimes it exits the program, sometimes it's just ignored.  I was 
hoping that there'd be some zcurses/ncurses list of all accepted keys, 
where I'd hope to see some mention of the ASCII acronyms and in 
particular what's going on with ^C.  I'd suspect that something else, 
like the terminal, is getting in the way, but, again, I can handle ^C my 
way with " ${\x0A} " so it seems to be under my/zcurses control.