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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 04 Sep 2025 07:42:02 +0300

> Date: Wed, 03 Sep 2025 17:05:56 +0000
> From: Ewan <[email-masked]>
> Cc: [email-masked]
> 
> WriteConsoleOutput (used by the old code) doesn't move the cursor, but
> can't be used for ASCII control sequences, and is being phased out by 
> Microsoft. WriteConsole is required for ASCII sequences, and moves the
> cursor. Hiding the system cursor before every move/call to WriteConsole 
> and showing it after, makes for a very unstable cursor (flickers wildly).

I meant hiding it at the beginning of an update (in
w32con_update_begin) and showing it at the end of the update, which we
already do.  Then we can move it at will without it appearing on the
screen, right?

> Previously, we maintained the "cursor" throughout the update as an internal 
> coordinate variable, without "realizing" the position in the system cursor,
> through a call to SetConsoleCursorPosition, until the after-update hook. 
> That is no longer possible -- the system cursor position must be realized 
> in real-time. Hiding the system cursor the whole time, and replacing it
> with a (nominal) "cursor" drawn in with the rest of the glyphs, achieves 
> the same effect that we had before, in light of the new constraint. The
> (actual, system) cursor jumps around, invisibly, during the write, while 
> the (nominal, visible) cursor stays stable, then makes one discrete move 
> (when its new row is written).

It sounds like you are describing what I suggested above, so we agree
on how to handle this when WriteConsole is in use?  But what do you
mean by "replacing it with a (nominal) "cursor" drawn in with the rest
of the glyphs" in this context?  I thought if we hide the cursor, it
is simply not shown, although the system maintains its position, and
so should we.  Then why "replacing", and what is the "nominal cursor"?