termios: fix normal cursor shape set by ESC[v

[stsp]

Before: ESC[v (normal cursor, cnorm in the djgpp terminfo) sets cursor start > end: 15-14 for the 8x16 font, 8-7 for 8x8. A VGA does not draw such a cursor, so vim under unix.com/djterm had no cursor, and dosemu2 grew a split-cursor emulation (dosemu2 2c06e1bfb) to show anything.

After: the normal cursor is 13-14 for 8x16 and 6-7 for 8x8, the same as the fixed 0x0607 used before 60b9108.

How: in set_cursor_shape(), top_line = bot_line - 1 instead of + 1. Found while reviewing dosemu2/dosemu2#3134 (a dosemu -D+v log of unix vim shows set text cursor shape: 15-14 right after cnorm).

[stsp]

Are you sure of that?
On host I have vim with the
large cursor that occupies entire
cell, not 1 line! So there was no
bug. Just make it to work w/o
split.

[stsp]

Answering #86 (comment) ("Just make it to work w/o split"): done in 987cf76. The normal cursor is now top_line = 0, i.e. 0..14 for the 8x16 font, a block over the cell like on your host terminal and like dosemu's split path used to draw 15-14. Start <= end now, so it shows on plain VGA too. Normal and enhanced are the same shape after this.

The sandbox would not let me force-push a squashed commit, so this is a second commit on top of 27200f7. Squash on merge if you prefer one commit.

---

Generated by Claude Code

[stsp]

I don't understand...
Why vim doesn't set ENHANCED_CURSOR
if it wants a big one?

[stsp]

Answering #86 (comment) ("Why vim doesn't set ENHANCED_CURSOR if it wants a big one?"): vim doesn't want a big one. It only asks for the "normal" cursor: it hides it with civis (\E[1v) while redrawing and brings it back with cnorm (\E[v). The dosemu -D+v log of unix vim has only two shape changes, 32-0 (civis) and 15-14 (cnorm), and no \E[2v (cvvis, the enhanced one).

The full-cell cursor you see on the host is not something vim asks for. It is just the host terminal's default cursor style for "normal" (xterm and most others default to a block). So "normal" means "whatever this terminal considers normal". For a DOS console that has traditionally been an underline, which is the 0x0607-style 13-14 shape from 27200f7. The current c87f618 instead copies the host look and makes normal a block, the same as enhanced.

Both avoid start > end. Which one do you want: the underline (DOS-like, normal and enhanced differ), or the block (host-like, normal = enhanced)?

---

Generated by Claude Code

[stsp]

Ok, I guess I want djterm /c[0|1|2]
that uses v command to adjust the
default cursor shape.

[stsp]

Answering #86 (comment) ("I want djterm /c[0|1|2] that uses v command to adjust the default cursor shape"). One snag first: vim sends a bare ESC[v (cnorm) every time it shows the cursor. If djterm just sent ESC[2v once, vim's next ESC[v would reset it. So dj64dev has to remember the default, and ESC[v must mean "the default" instead of a fixed shape. My proposal:

• dj64dev: __tty_screen gets a def_cursor field (initially 0 = underline). ESC[v and ESC[0v apply def_cursor. ESC[1v (hidden) and ESC[2v (block) stay as they are. A second parameter sets the default: ESC[N;1v stores N in def_cursor and applies it. ESC[N;1v is currently unused (only the first arg is read), so nothing changes for existing users.
• comcom32: djterm /c[0|1|2] writes ESC[N;1v to stdout through the termios path (the same write() that term_write() uses), and djterm without args prints the current value.
• this PR then goes back to the underline for 0 (13-14 / 6-7, no start > end), and the block comes from djterm /c2.

I can do the dj64dev part in this PR. The comcom32 part I can't push: this session has no write access to dosemu2/comcom32 (the Claude GitHub app is not installed there). Either install the app on comcom32, or I post the comcom32 patch here as a diff for you to apply. OK to go this way?

---

Generated by Claude Code

[stsp]

  /* Get initial cursor shape and type.  */
  __tty_screen.init_cursor_shape = _farnspeekw(0x460);

I think if vim sends ESC[v (cnorm),
then it should be exactly that.

[stsp]

Answering #86 (comment) ("if vim sends ESC[v (cnorm), then it should be exactly that"): done in 29d589d (squashed, force-pushed). ESC[v now sets __tty_screen.init_cursor_shape, the shape saved at init and restored at exit. The computed shape is used only for ESC[2v, so that branch is just top_line = 0. The bogus bot_line + 1 is gone, and djterm /c isn't needed for this.

---

Generated by Claude Code

[stsp]

I think this should be returned to -1.
Also maybe we need to use _farpeekw(_dos_ds, 0x460)
in the above change, not __tty_screen.init_cursor_shape

[stsp]

Answering #86 (comment):

• "returned to -1": done in dfcd66d. The ENHANCED_CURSOR ? 0 : bot_line - 1 if/else is back. With ESC[v handled above it, the - 1 arm is not reached today, but it is correct now if it ever is.
• _farpeekw(_dos_ds, 0x460) instead of init_cursor_shape: I kept init_cursor_shape. 0x460 is the BIOS copy of the current shape, and int10 ah=1 updates it. vim does ESC[1v (civis), which sets 0x460 to 0x2000, and then ESC[v (cnorm). Reading 0x460 at that point gives back 0x2000, and the early new_cursor == _farpeekw(_dos_ds, 0x460) return makes it a no-op, so the cursor stays hidden. init_cursor_shape is the value saved at init and restored at exit, so it survives civis.

---

Generated by Claude Code

[stsp]

Lets CC @jwt27 as this looks like
a genuine djgpp bug.
But given that we ended up needing
also the change above, this point is moot.