RIS leaves focus reporting on and an open synchronized update open, so `wait_stable` can never succeed
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
Research direction
Start in emu/seq.rs at the RIS arm around line 1680 and compare its reset behavior with soft_reset() around line 954. Update the RIS reset to clear the reported modes and any half-collected frame. Run the reproduction from the issue; done means wait_stable succeeds, focus_in sends nothing, and DECRQM reports both modes reset.
Written by the indexing model from the issue text.
Description
What happens. After ESC c, focus reporting (mode 1004) is still on, and an unfinished DEC 2026 synchronized update is still open:
// 20x4
printf '\033[?1004h\033[?2026hhalf\033cREADY'
focus_events()istrueafter the RIS, sofocus_in()sends^[[I, which the tty echoes onto the screen.wait_stabletimes out with "the application is inside an unfinished DEC 2026 synchronized update (Begin with no End)".- DECRQM answers
Setfor both 1004 and 2026.
Cause. The RIS arm in emu/seq.rs:1680 resets the cursor style, charsets, mouse tracking, IRM, tabs, links and any kitty upload. It does not reset focus_events or sync_update. soft_reset() (:954) does clear focus_events.
Why it matters. RIS is the "start over" sequence. A program that resets after a crash or a mode switch leaves every later stability wait doomed.
Fix. In the RIS arm, set focus_events = false and sync_update = false. Drop any half-collected frame as well.
Done when the repro's wait_stable succeeds, focus_in sends nothing, and DECRQM reports both modes reset.
- Dominant language
- Rust
- Stars
- 28
- Forks
- 24
- Avg merge
- 11h 23m
- Merged PRs (30d)
- 42
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from vyncint/termlens
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
Maintainers usually reply within 1 day
-
Release notes show a broken link: `extract-changelog.sh` copies a reference but not its definitionOpenbug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
All issues in vyncint/termlens
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
compiler P4 perf
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
HerringtonDarkholme/hd-lang#1044 ·
Maintainers usually reply within 1 day
-
good first issue help wanted r-docs
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
servo/rust-smallvec#824 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
akitaonrails/ai-usagebar#552 ·
Maintainers usually reply within 1 day