21:32 <krobelus> if fish spawns a child program that pushes progressive enhancement flags and crashes (without popping), then the progressive enhancement flag stack is stale. Now a child bash (which does not yet read CSI u) will have broken ctrl keys etc. A SSH connection drop effectively acts as such a crash. I think ideally the OpenSSH client would add some logic to make sure to restore the progressive enhancement

21:32 <krobelus> flag stack but I'm not sure if they're open to that. For now, I'd want to add a workaround to fish, as follows: on startup, record the size of the flag stack. After executing an external program, check if the size is the same. If not, then pop any excess elements. I think we'd only need a way to query the stack size.

21:33 <krobelus> Sounds somewhat complicated but I think it's better than making the user run "reset"

21:37 <krobelus> I have never used a request that expects a response from the terminal, I wonder if there is any guarantee like "the next read will return the response (and not keyboard input)".. but I guess it doesn't really matter for my use.

21:40 <rockorager> krobelus: the canonical way is to issue another request which every terminal responds to

21:40 <rockorager> eg primary device attributes

21:41 <rockorager> if you get a response to that and not the first, then you expect that you’ll never get a response

21:43 <rockorager> personally I think CSI 5 n is a good candidate, you get fewer bytes back and it’s just a “OK” response basically

21:44 <rockorager> Ah, but your issue is the next read. Is fish using async reads?