Re: [mpg123-devel] [PATCH] term_posix: Ignore escape sequences

[Thomas O. <tho...@or...>]

Am Mon, 20 Oct 2025 12:39:54 -0500 (CDT)
schrieb Peter Tirsek <pe...@ti...>: 

> All of those also fit the 
> same simple pattern of escape, followed by one or more characters from 
> my list, then terminated by one not in that list, so I think my simple 
> hack still holds.

I was more thinking about differing escape sequence introductions, like
8 bit sequences using a literal CSI character. Don't seem relevant. But
impossible?

> Assuming you only get escape sequences from a well-behaved terminal on 
> a well-behaved connection with minimal input lag and latency, I agree. 
> I wouldn't think mpg123 gets used remotely much, so the connection is 
> likely to be very stable. However, if for some reason this assumption 
> doesn't hold, e.g. if the user hits the escape key manually,

OK, I'll need some time to think and read about how these sequences can
enter the UI. I assumed one keypress = one sequence, but that might not
be true at all.

What about the user pressing ESC manually? Mpg123 gets a literal 0x1b that
does get followed by a sequence. Your approach would swallow the next
valid terminal control key, wouldn't it?

> Although the patch that keeps track of state is a little more robust, I 
> think for all practical purposes the loop idea is just fine, 

I read that even Microsoft has an idea of ANSI control sequences. Not
sure if that applies to input in term_win32.c, but maybe we should move
this a level higher up?

If the control sequence looping is around term_get_key() in term.c,
then we got all platforms covered _and_ have sequence detection via the
select logic on the lower level. If there is just 0x1b and the next
term_get_key() doesn't give a following character, it was a lone ESC to
be ignored?

If running on a link with abysmal latency that turns a single burst of
4 bytes into single chars 10 ms apart (might think about reducing that
delay, though … 10 ms is quite long while playing audio), then you'll
have false negatives on sequence detection. Would be rather bad
experience anyway … and if your mpg123 instance is that far off, are
you listening?

Maybe we could reduce the select timeout, or actually … if looking for
a sequence, setting do_delay=0 might be sensible, to keep the overall
select waiting down, keeping playback smooth. Or a normal timeout of 5
ms and 1 ms for each additional character …


Alrighty then,

Thomas