Subject: Re: bug#79298: patch: full color in windows terminal

From: Eli Zaretskii <[email-masked]>
Date: Wed, 03 Sep 2025 19:38:06 +0300

> Date: Wed, 03 Sep 2025 15:54:11 +0000
> From: Ewan <[email-masked]>
> Cc: [email-masked]
> 
> Not a problem, the implementation will be of use to me regardless of 
> whether it goes in to master, the documentation is just to explain it 
> to others. However, there is, I think, a fundamental incompatibility 
> between the mechanism supporting true color, and the way we were doing 
> things. There's a short bit about this in the manual entry. We could 
> stick with use of the API to move the  cursor, clear lines, etc. - 
> that's all just a matter of choice (before, we jumped through hoops with 
> the API to achieve things there are now specific control sequences for). 
> 
> But the previous implementation achieved color display by direct writes
> to regions of the screen (using WriteConsoleOutput etc.), not requiring 
> cursor movement. The cursor was only moved once, at the very end of an 
> update cycle. That was what enabled the stable cursor appearance (and
> there are comments about this "trick" dating back to MSDOS). But for 
> true color support, that is not an option. We have to use WriteConsole 
> (or printf, etc.), which move the cursor during the write, and that is
> what (re-)introduces the "unstable cursor" problem. AFAIK, it is not 
> that redisplay is now inherently slower, per se... It is that it now 
> requires cursor movement, and if the MSDOS commentary still holds up, 
> this is "expensive" at a low level - enough so that it is perceptible,
> mostly because we make such frequent use of the echo area.

Why can't we turn off the cursor before calling WriteConsoleOutput,
then turn it on again, after the call returns and we move the cursor
to its original place?

> I share the concern about this all being relatively untested. I'll put
> it through the motions in my (limited) use of Windows, but there 
> will probably be some bugs I don't catch. In any case, it's made my 
> use of terminal Emacs on Windows tolerable (if not pleasant!).

For this reason, I'd prefer to make as few changes as possible in the
console-related management code.  Where we must do that, fine, but
let's try leaving the rest intact, as it was tested by time and many
users (and we had in the past some tricky issues, which are now
resolved).