On 21.02.2020 10:32, Corinna Vinschen wrote:
On Feb 20 17:38, Corinna Vinschen wrote:
On Feb 20 17:22, Thomas Wolff wrote:
On 20.02.2020 17:04, Corinna Vinschen wrote:
On Feb 20 23:49, Takashi Yano wrote:
On Thu, 20 Feb 2020 15:22:45 +0100
Corinna Vinschen wrote:
On Feb 20 23:13, Takashi Yano wrote:
On Thu, 20 Feb 2020 14:44:59 +0100
Corinna Vinschen wrote:
But, here's a question: Why do we move the cursor to the right at all?
I assume this is compatible with legacy mode, right?
Hmm. This may be a bug of legacy console.
https://en.wikipedia.org/wiki/Null_character
says
(some terminals, however, incorrectly display it as space)
What about ignoring NUL in legacy mode too?
I'd like that, but this may be a problem in terms of backward
compatibility. The behaviour is so old, it actually precedes even the
import of Cygwin code into the original CVS repository, 20 years ago...
If so, can't we say it is the *specification* of TERM=cygwin
that NUL moves the cursor right?
Good point. Yes, in that case it's "working as designed" and
we just leave it as is. I push my patch.
See `man 5 terminfo`: if NUL does anything else than just padding, the
terminfo entry must contain a pad or npc entry, which it doesn't.
Trouble to be expected. I'd rather suggest to align the design with
applications' expectations.
Is that the cygwin terminfo or the xterm terminfo you're talking about?
In case of the cygwin terminfo, that would mean the cygwin terminal
emulation behaves differently from the terminfo for ages. I guess
you're right then, we should fix this in the cygwin terminal emulation
to make sure it behaves as descibed in its terminfo.
In case of the xterm terminfo, that would be no problem because my patch
drops the cursor movement for NUL.
Yeah, never mind, I checked the cygwin terminfo entry myself.
I pushed a patch removing the cursor movement on NUL and added
a matching comment instead.
Great, thanks! And sorry I'm sometimes a bit slow to respond...
