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

Previous Next

Full log

View this message in rfc822 format

From: Ewan <ewan <at> etown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79298 <at> debbugs.gnu.org
Subject: bug#79298: patch: full color in windows terminal
Date: Wed, 03 Sep 2025 15:54:11 +0000

> > (1) ASCII control sequences require moving the cursor during redisplay,
> > (2) the Windows system cursor picks up these movements, and
> > (3) redisplay is slow enough that cursor jumps to the echo area are perceptible.
> > 
> > So, I've also implemented some changes to cursor handling in Windows TTY.
> 
> 
> I wish you brought this up for discussion before actually coding (and
> documenting) these extensive changes. I'd rather we stayed with the
> original use of the Windows Console APIs for everything except the
> true color support, if possible. AFAIK, there are no fundamental
> incompatibilities between these two features (if I'm mistaken, please
> describe the problems), and we need to keep the old Console APIs
> anyway for as long as we support the older Windows systems. Plus,
> AFAIK users can choose to use the legacy ConHost even on newer Windows
> versions, and I wouldn't want us to have to tell the users to tweak
> their Emacs should it turn out ConHost causes problems with the
> Virtual Terminal control sequences. And you have already bumped into
> problems with this, in the form of cursor flashing momentarily in the
> wrong places and slower redisplay.

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.

> In addition, the changes you propose introduce Windows-specific code
> into platform-independent source files, like dispnew.c, something we
> generally prefer to avoid.

Agreed, this is not ideal, I just couldn't think of another way to solve
the unstable cursor problem. I've been careful to ensure the functional
changes are only present when compiled for Windows, but if there is an 
alternative, I'm all for it.

> So let's take a step back and discuss the need for this part of the
> changes: what problems will we encounter if we leave cursor handling
> and the rest of console management to the old Console APIs, and use
> the new ASCII sequences only for true color? If the problems are not
> too hard to solve, I'd prefer to leave that code alone, with minimal
> necessary changes. If nothing else, it leaves use with code which was
> tested by many users during a long time.

In short, ASCII sequences for true color destabilize the system cursor 
appearance, because they undermine the "trick" we were turning.
As far as I can tell, there is no way around that.

> AFAIK users can choose to use the legacy ConHost even on newer Windows
> versions, and I wouldn't want us to have to tell the users to tweak
> their Emacs should it turn out ConHost causes problems with the
> Virtual Terminal control sequences.

Three things give me comfort on this front. One, Microsoft has added 
"support" for ASCII sequences (at least for color) to the Console.

"Some virtual terminal emulators support a palette of colors greater 
than the 16 colors provided by the Windows Console. For these extended 
colors, the Windows Console will choose the nearest appropriate color 
from the existing 16 color table for display."

Two, when initializing a TTY session on Windows, we request the 
ENABLE_VIRTUAL_TERMINAL_PROCESSING output mode. If not available,
e.g. on legacy systems, we disable the feature flag and revert to 
the older color display "trick".

Finally, the Emacs-drawn cursor replacing the system cursor when
w32-use-visible-system-caret is nil, is independent of ASCII sequence 
support. It depends only on the 'cursor' face being defined (I believe
it always will be), and just adds an additional pass, for at most two 
rows, through w32con_write_glyphs, which branches between old and new
based on the feature flag, and so should work with the legacy system.


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

Previous Next

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