Closed NullCGT closed 2 years ago
ahhh this is almost always the result of some divergent control sequence being emitted by the terminal. let me rebuild my alacritty and see waht's up. if you run notcurses-input
, do you see a bunch of crap? if so, the output of notcurses-info -v 2>
will likely point to the culprit.
If you run
notcurses-input
, do you see a bunch of crap?
Yup. So much crap scrolling past that it takes several seconds to see it all. I've uploaded the output of notcurses-info -v
:
ok, i can reproduce this problem with the latest alacritty. thanks for bringing this to my attention! i should have it fixed shortly.
Awesome! Thank you for the fantastic library.
yeah malformed palette info
block_on_input:2377:blocking on input availability
block_on_input:2434:waiting on 1 fds (ibuf: 0/8192)
block_on_input:2461:poll returned 1
block_on_input:2479:got events: tI
read_input_nblock:2091:read 2252B from 0 (5940B left)
process_melange:2293:input 0 (0)/2252 [0x1b] ( )
process_escape:2128:initialized automaton to 1
process_escape:2140:walk result on 91 ([): 0 2
process_escape:2140:walk result on 62 (>): 0 364
process_escape:2140:walk result on 48 (0): 0 372
process_escape:2140:walk result on 59 (;): 0 373
process_escape:2140:walk result on 49 (1): 0 374
process_escape:2140:walk result on 55 (7): 0 374
process_escape:2140:walk result on 48 (0): 0 374
process_escape:2140:walk result on 48 (0): 0 374
process_escape:2140:walk result on 59 (;): 0 375
process_escape:2140:walk result on 49 (1): 0 376
da2_cb:1253:read secondary device attributes
da2_cb:1303:might be alacritty 0.17.0
process_escape:2140:walk result on 99 (c): 2 377
process_melange:2293:input 12 (0)/2240 [0x1b] ( )
process_escape:2128:initialized automaton to 1
process_escape:2140:walk result on 93 (]): 0 409
walk_automaton:570:unexpected transition on 409[48]
process_escape:2140:walk result on 48 (0): -1 0
process_melange:2293:input 13 (0)/2239 [0x5d] (])
process_melange:2293:input 14 (0)/2238 [0x30] (0)
process_melange:2293:input 15 (0)/2237 [0x3b] (;)
process_melange:2293:input 16 (0)/2236 [0x72] (r)
process_melange:2293:input 17 (0)/2235 [0x67] (g)
process_melange:2293:input 18 (0)/2234 [0x62] (b)
process_melange:2293:input 19 (0)/2233 [0x3a] (:)
process_melange:2293:input 20 (0)/2232 [0x31] (1)
process_melange:2293:input 21 (0)/2231 [0x64] (d)
process_melange:2293:input 22 (0)/2230 [0x31] (1)
process_melange:2293:input 23 (0)/2229 [0x64] (d)
process_melange:2293:input 24 (0)/2228 [0x2f] (/)
process_melange:2293:input 25 (0)/2227 [0x31] (1)
process_melange:2293:input 26 (0)/2226 [0x66] (f)
process_melange:2293:input 27 (0)/2225 [0x31] (1)
process_melange:2293:input 28 (0)/2224 [0x66] (f)
process_melange:2293:input 29 (0)/2223 [0x2f] (/)
process_melange:2293:input 30 (0)/2222 [0x32] (2)
process_melange:2293:input 31 (0)/2221 [0x31] (1)
process_melange:2293:input 32 (0)/2220 [0x32] (2)
process_melange:2293:input 33 (0)/2219 [0x31] (1)
process_melange:2293:input 34 (0)/2218 [0x1b] ( )
process_escape:2128:initialized automaton to 1
process_escape:2140:walk result on 92 (\): 1 0
process_melange:2293:input 36 (0)/2216 [0x1b] ( )
process_escape:2128:initialized automaton to 1
process_escape:2140:walk result on 93 (]): 0 409
process_escape:2140:walk result on 49 (1): 0 410
walk_automaton:570:unexpected transition on 410[59]
process_escape:2140:walk result on 59 (;): -1 0
process_melange:2293:input 37 (0)/2215 [0x5d] (])
so it looks like alacritty is just leaving the status code off entirely, and beginning the sequence with ESC followed by N and a semicolon. hrnmmm. probably ought file a bug against them, but let me see if i can handle this easily also.
no, this is just bad on their part. this causes an ambiguity where it's impossible to differentiate between the response to a default bg/default fg queuy and a query for palette items 10 and 11. no bueno. hah, and indeed, the only two responses which do not trigger errors are 10 and 11:
process_escape:2140:walk result on 47 (/): 0 417
process_escape:2140:walk result on 52 (4): 0 417
process_escape:2140:walk result on 97 (a): 0 417
process_escape:2140:walk result on 52 (4): 0 417
process_escape:2140:walk result on 97 (a): 0 417
process_escape:2140:walk result on 27 ( ): 0 419
fgdef_cb:1399:default foreground 0xb9ca4a
process_escape:2140:walk result on 92 (\): 2 418
process_melange:2293:input 277 (0)/1975 [0x1b] ( )
process_escape:2128:initialized automaton to 1
process_escape:2140:walk result on 93 (]): 0 409
process_escape:2140:walk result on 49 (1): 0 410
process_escape:2140:walk result on 49 (1): 0 420
process_escape:2140:walk result on 59 (;): 0 421
process_escape:2140:walk result on 114 (r): 0 422
process_escape:2140:walk result on 103 (g): 0 423
process_escape:2140:walk result on 98 (b): 0 424
process_escape:2140:walk result on 58 (:): 0 425
process_escape:2140:walk result on 101 (e): 0 426
process_escape:2140:walk result on 55 (7): 0 426
process_escape:2140:walk result on 101 (e): 0 426
process_escape:2140:walk result on 55 (7): 0 426
process_escape:2140:walk result on 47 (/): 0 426
process_escape:2140:walk result on 99 (c): 0 426
process_escape:2140:walk result on 53 (5): 0 426
process_escape:2140:walk result on 99 (c): 0 426
process_escape:2140:walk result on 53 (5): 0 426
process_escape:2140:walk result on 47 (/): 0 426
process_escape:2140:walk result on 52 (4): 0 426
process_escape:2140:walk result on 55 (7): 0 426
process_escape:2140:walk result on 52 (4): 0 426
process_escape:2140:walk result on 55 (7): 0 426
process_escape:2140:walk result on 27 ( ): 0 428
bgdef_cb:1382:default background 0xe7c547
ok, i really don't want to try and handle this. it's a straight-up bad bug on alacritty's part, and one they must have introduced recently. let me go bitch at them.
alright, yeah, i could try to work around this, but it would have an ambiguity in the protocol. i've filed a bug against alacritty, and ideally they'll agree and fix it quickly. this behavior can't have been in there very long, as i know alacritty worked at the time of the Notcurses 3.0.7 release. so there'll be like two or three weeks of bad alacritty out there, but what's one to do?
sorry i can't offer a better solution =. if alacritty comes back saying they're not fixing it, i'll revisit this, but i think it's pretty clear that it's their (bad) bug.
Awesome! Thank you for the fantastic library.
awww, thanks for the kind words =].
let me know if you find this resolution unacceptable.
 Ask me about Roguelikes!
hah, i've got a custom Nethack-themed GPU backplate coming in a week or two =]
Wow, that backplate is fantastic! Definitely captures a great moment :D
I'm actually specifically experimenting with notcurses for a personal roguelike project of mine. I originally wrote the console windowport code using ncurses, since it's what I'm comfortable with, but I decided to branch out a little bit and experiment with more modern libraries. I have it mostly ported to notcurses, but was a little surprised when I launched the game and saw my character begin zooming around the screen at a million miles an hour.
This resolution totally makes sense. It's down to alacritty to fix the issue. In the meantime, I'll just use kitty or xterm for testing.
oh that's just a screenshot of when i finally ascended after 19 years of playing that game off and on =]. alright, thanks very much for bringing this to my attention. if alacritty people haven't responded by tomorrow or so, i'll go ahead and patch it up and send them a PR. hack on!
alright we have a fix from @chrisduerr in https://github.com/alacritty/alacritty/pull/5982. i've verified that it works by merging it locally. i imagine they'll merge it pretty soon.
calling this fixed. the system works!
My program depends on getting blocking input from notcurses, similar to the following:
When I start my program, however, notcurses_get reads in a long string of inputs, as if there is a large amount of data in stdin. I confirmed via gdb that no inputs were erroneously passed in via user error, and that this takes place before the user has the chance to pass any input to the program. This input all appears to have the evtype NCTYPE_UNKNOWN.
Interestingly, this bug only seems to occur in alacritty. I ran the same program with kitty and it ran as intended.
COLORTERM=truecolor LANG=en_US.UTF-8 TERM=alacritty
Notcurses version: Notcurses 3.0.7 Terminal: Alacritty v0.10.1