You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A late response to a secondary DA request gets passed on to the client #2984
If the outer TTY takes longer than a second to reply to [>0c (secondary DA request), the eventual reply (e.g., \033[>0;10;1c) gets passed to the client and may end up in unexpected places -- perhaps in a file that one has opened in an editor.
Execution flow goes like this:
tmux starts.
tmux sends [>0c to the outer TTY (tty_send_requests) and starts a 1s timer.
when the timer expires (tty_start_timer_callback), tmux sets TTY_HAVEDA bit.
when the reply eventually arrives, tty_keys_device_attributes doesn't look at it because TTY_HAVEDA is set.
Unfortunately, I don't have logs. I've reconstructed this from a bug report from a user of my code (romkatv/zsh4humans#177 (comment)).
I don't know which terminal but it's on Windows 11. I'm 100% with you that it's not normal for a terminal to take over a second to reply. My response from the bug I linked above:
A proper fix would be to figure out why your terminal takes so long to reply and fix it.
I've implemented a workaround in my code so that \033[>0;10;1c at random times doesn't break me. I've opened this issue in case you'll find this information useful. It's fine with me if you deprioritize or close it.
@nicm this was happening for me on Windows 11 using Windows Terminal 1.11.2921.0. @romkatv was kind enough to fix the problem in his package so this is not an urgent priority but I suspect, especially given the growth of Windows Terminal (it's now "built-into" Windows 11) others may see it soon too.
I have bumped the timeout to three seconds, the change will be in GitHub when it syncs later on. If this still happens I think you will need to either live with it or talk to the terminal developers about why it is taking so long. Thanks!
Activity
nicm commentedon Nov 22, 2021
What terminal takes more than a second to respond to this?
romkatv commentedon Nov 22, 2021
I don't know which terminal but it's on Windows 11. I'm 100% with you that it's not normal for a terminal to take over a second to reply. My response from the bug I linked above:
I've implemented a workaround in my code so that
\033[>0;10;1cat random times doesn't break me. I've opened this issue in case you'll find this information useful. It's fine with me if you deprioritize or close it.nicm commentedon Nov 22, 2021
We can probably bump it to 2 or 5 seconds or something, I'll take a look next week.
shah commentedon Nov 23, 2021
@nicm this was happening for me on
Windows 11usingWindows Terminal 1.11.2921.0. @romkatv was kind enough to fix the problem in his package so this is not an urgent priority but I suspect, especially given the growth of Windows Terminal (it's now "built-into" Windows 11) others may see it soon too.nicm commentedon Nov 29, 2021
I have bumped the timeout to three seconds, the change will be in GitHub when it syncs later on. If this still happens I think you will need to either live with it or talk to the terminal developers about why it is taking so long. Thanks!
github-actions commentedon Dec 30, 2021
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.