Respect blink_cursor config when escape sequences request cursor blink

[sporteka2]

When blink_cursor=false is set in ~/.mlterm/main, the cursor should never blink. However, escape sequences like DECSET 12 (\e[?12h) and DECSCUSR with odd styles (1, 3, 5) could override this setting and enable blinking.

This patch adds a blink_cursor flag to vt_parser_t that stores whether cursor blinking is allowed by config. The flag is checked in two places:

• set_vtmode() for VTMODE_33 (DECSET/DECRST ?12) — skip setting CS_BLINK when blink_cursor is false
• parse_vt100_escape_sequence() for DECSCUSR (CSI SP q) — don't add CS_BLINK to odd styles when blink_cursor is false

The flag is preserved and updated when blink_cursor config is changed at runtime.

Fixes #169

[arakiken]

Thanks.
The blink_cursor option determines initial values ​​such as the cursor shape.
It is not intended to lock the cursor to a specific shape.

So, I’ve added --igncsi / ignored_csi_list to ignore specific CSI sequences.
-> e9556cb

Could you please use it to ignore DECSCUSR, as shown below? (Add a following line to ~/.mlterm/main to ignore ^[[1 q, ^[[3 q and ^[[5 q.)

ignored_csi_list = 1 q,3 q,5 q

[sporteka2]

After exiting opencode/cline, the cursor starts blinking again, despite the blink_cursor = false setting and/or ignored_csi_list = 1 q,3 q,5 q. Reproduced on mlterm 3.9.x.

[arakiken]

In my environment, when I launched mlterm with 'ignored_csi_list=1 q,3 q,5 q' specified, the cursor did not start blinking after exiting opencode,
It is possible that adding 33l to ignored_csi_list might cause the blinking to stop after exiting opencode/cline.
ignored_csi_list = 1 q,3 q,5 q,33l

To investigate and reproduce this issue, could you please provide ~/.mlterm/*.log generated when launching mlterm with --logseq option?

[sporteka2]

I ran mlterm with --logseq and captured the log you asked for. The root cause is that opencode sends \x1b[0 q (DECSCUSR style 0 = blinking block) when it exits, and 0 q is not in the suggested ignore list, so the blinking returns:

... \x1b[?1049l \x1b[?2031l \x1b]0;\x07 \x1b]12;default\x07 \x1b]112\x07 \x1b[0 q \x1b[?25h \x1b[?25h \x1b[?2004h ...

Right before 0 q there is the cursor-color reset (\x1b]12;default\x07 \x1b]112\x07), then \x1b[0 q re-asserts a blinking block cursor. That's the immediate trigger — but \x1b[33l (DECRST 33) can also re-enable blink, so a per-sequence ignore list is fragile: with ignored_csi_list = 1 q,3 q,5 q,33l it still blinks because 0 q is missing, and even adding 0 q only fixes this one app.

Proposed fix: treat blink_cursor config as "never blink when false" rather than merely an initial value. The patch in this PR adds a blink_cursor flag to vt_parser_t and gates the two spots that set CS_BLINK from escape sequences:

• set_vtmode() for VTMODE_33 — skip CS_BLINK when blink_cursor is false
• parse_vt100_escape_sequence() for DECSCUSR (CSI SP q) — don't add CS_BLINK to any style when blink_cursor is false (covers 0 q, 1 q, 3 q, 5 q)

With this, blink_cursor = false is honored for every escape sequence (including 0 q and 33l) regardless of which application sends them, matching kitty/alacritty/wezterm and closing #169.