warning on unknown CSI for DECRQM #955
Labels
bug
Something isn't working
fixed-in-nightly
This is (or is assumed to be) fixed in the nightly builds.
Comments
wez
added a commit
that referenced
this issue
Jul 24, 2021
The original design of the vtparse crate was inspired by the vte crate. There were some assumptions about the shape of CSI sequences that were lossy and that is posing a problem when it comes to implementing DECRQM. This commit improves the situation by adjusting CsiParam to be capable of capturing all of the possible parameters as well as intermediates. This commit isn't done; I just need to push it to transfer it to another machine. refs: #882 refs: #955
wez
added a commit
that referenced
this issue
Jul 25, 2021
The original design of the vtparse crate was inspired by the vte crate. There were some assumptions about the shape of CSI sequences that were lossy and that is posing a problem when it comes to implementing DECRQM. This commit improves the situation by adjusting CsiParam to be capable of capturing all of the possible parameters as well as intermediates. This commit isn't done; I just need to push it to transfer it to another machine. refs: #882 refs: #955
wez
added a commit
that referenced
this issue
Jul 25, 2021
This commit removes the intermediates parameter and collapses it together with the parameters themselves. This allows us to model DECSET (eg: `CSI ? 1 l`) correctly. Previously this would get reported as: ``` params: [1], intermediates: ['?'], code: 'l' ``` but since the intermediates are logically things that precede the code, the canonical interpretation of that would be as if we'd received `CSI 1 ? l`. AFAICT, DECSET isn't conforming to ECMA 48 when it comes to this sequence. That made things a bit of a headache in the CSI parser, so what we do now is to treat intermediates as parameters so that it is much simpler to reason about and match in the CSI parser; we now get: ``` params: ['?', 1], code: 'l', ``` refs: #955
wez
added a commit
that referenced
this issue
Jul 25, 2021
This commit hooks up DECRQM so that we can report that we implement synchronized updates, and then refines the code that manages sending data to the terminal model; the first cut at synchronized updates was a bit simplistic, and now we make a point of "flushing" pending actions when we start a sync point, and again as soon as we release the sync point. This smooths out the jaggies around the orca that I mentioned in dcbbda7 and while testing this, I realized that recent parser changes had mangled processing bundled dec private mode sequences where multiple modes were specified in the same overall escape sequence. I've added the missing unit test case for this and made that work again. refs: #955 refs: #882
wez
added
the
fixed-in-nightly
|
confirmed! |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the bug
Notcurses issues a DECRQM (https://vt100.net/docs/vt510-rm/DECRQM.html) for property 2026 upon startup, checking for Synchronized Mode support. Wezterm prints a diagnostic along the lines of:
2021-07-19T01:09:04.881Z WARN wezterm_term::terminalstate > unknown unspecified CSI: "?$2026p"The exact query being sent is:
../src/lib/termdesc.c:#define SUMQUERY "\x1b[?2026$p"Environment (please complete the following information):
To Reproduce
\x1b[?2026$phttps://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2
https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec
Expected behavior
No reply is required since the feature is not supported. There's no need to print the diagnostic, however.
Additional context
You asked me to file these, so I'm doing so.
With this and #954 knocked out, Notcurses will no longer provoke outbursts from WezTerm on startup.
The text was updated successfully, but these errors were encountered: