GNU bug report logs - #79298
patch: full color in windows terminal

Previous Next

Package: emacs;

Reported by: Ewan <ewan <at> etown.dev>

Date: Sun, 24 Aug 2025 06:07:02 UTC

Severity: normal

Merged with 79297

Full log


Message #52 received at 79298 <at> debbugs.gnu.org (full text, mbox):

From: Ewan <ewan <at> etown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79298 <at> debbugs.gnu.org
Subject: Re: bug#79298: patch: full color in windows terminal
Date: Wed, 03 Sep 2025 17:05:56 +0000
> > 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?

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).

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).





This bug report was last modified 6 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.