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: Thu, 04 Sep 2025 09:40:18 +0000

> I'm not yet sure I understand the issues and the proposed solutions.
> 
> Let's back up a notch: Emacs in -nw mode on Unix systems already hides
> the cursor before writing glyphs, see tty_write_glyphs_1 and
> tty_write_glyphs_with_face. Why cannot we do the same in
> w32con_write_glyphs and w32con_write_glyphs_with_face, when
> WriteConsole is in use? Or what are the problems with doing that?

On Unix systems, this rapid off/on cycle appears to be fast enough
to be imperceptible. Not so on Windows. My understanding is that
cursor changes are just less efficient on Windows.

Perhaps some visuals will help. Just FYI, all of these effects are 
more pronounced with a colored background, because of the effect of
colored spaces on write_row (in dispnew.c), and even more so when the 
screen is full or changing significantly.

Here is a baseline - no hiding of the cursor, so it jumps:
https://sendvid.com/s25e79ou

This one is from a build where the cursor is hidden before and shown
after writing glyphs, as on Unix systems:
https://sendvid.com/41falj8d

And this one is where I ended up, hiding the cursor just for the 
call to write_row where the row to be written is the echo area.
The "flicker" is almost imperceptible, but still noticeable when 
attending to the cursor, and esp. on my (quite large) monitor,
when the 'q' in 'setq' is entered:
https://sendvid.com/p43vhzav

Frankly, the last of these is probably sufficient, and would 
go unnoticed by the vast majority of users. But it required 
changes to dispnew.c anyway, and being a perfectionist, I opted 
for the perfectly stable option (drawing our own cursor):
https://sendvid.com/6rxlxsfh


> Yes, I understand. But I would prefer to leave the old code used
> always, not just under the compatibility option (which should be
> needed only in rare cases anyway).

Totally understandable. It's fairly easy to just pull out the new
bits added to handle cursor movement, clearing lines, etc., with
ASCII sequences, and we just lose a tiny bit of efficiency.

Previous Next

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