public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Kevin Locke <kevin@kevinlocke.name>
Cc: Takashi Yano <takashi.yano@nifty.ne.jp>, cygwin@cygwin.com
Subject: Re: Screen clearing in CMD without "Legacy Console Mode"
Date: Wed, 5 May 2021 15:07:04 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2105051500410.50@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <YIwcGRttJhUueeRG@kevinlocke.name>

Hi,

On Fri, 30 Apr 2021, Kevin Locke wrote:

> On Fri, 2021-04-30 at 23:53 +0900, Takashi Yano wrote:
> > On Fri, 30 Apr 2021 08:25:12 -0600 Kevin Locke wrote:
> >> I'm investigating an issue in Git for Windows[^1], which also affects
> >> Cygwin.  The issue is that, when using CMD (i.e. Command Prompt) on
> >> Windows 10 1703 or above with "Legacy Console Mode"[^2] disabled, if
> >> TERM=cygwin is set in the environment, the console is not cleared when
> >> vi exits.  To demonstrate, with Cygwin 3.2.0, in CMD with "Legacy
> >> Console Mode" disabled:
> >>
> >> cd C:\cygwin64
> >> set TERM=cygwin
> >> bin\vi etc\bash.bashrc
> >> :q
> >>
> >> After exiting vi, the console window has not been cleared and content
> >> from etc\bash.bashrc remains visible, making further use of the console
> >> difficult until cleared.
> >
> > Why on earth do you want to set TERM=cygwin?
> > If you don't set TERM=cygwin, TERM is automatically set to
> > xterm-256color, in which the issue does not occur.

TERM=cygwin would be correct right until the time when you toggle
`ENABLE_VIRTUAL_TERMINAL_PROCESSING` under our feet.

That is, when the Cygwin process is called, this flag is not set, so
`TERM=xterm-256color` would be incorrect. And then when the Cygwin process
returns, the flag is set, and the calling process should somehow guess
that `TERM` should be set differently.

Oh, and you probably expect the caller to then figure out whether the flag
was _actually_ toggled, just in case we're running on a Windows 10 version
that is too old to understand that flag.

If you expect CMD to be no longer used after the Cygwin process returns,
that might be a valid world view. But that is probably not a very tenable
world view.

If Cygwin is unable to handle `TERM=cygwin` correctly when
`ENABLE_VIRTUAL_TERMINAL_PROCESSING` is toggled, then Cygwin should
definitely, absolutely, with 100% certainty _not_ toggle that flag when
`TERM` is already set to `cygwin`!

Ciao,
Johannes

> Unfortunately, I am not clear on that myself.[^6]  According to Johannes
> Schindelin[^7]:
>
> > We specifically set TERM so that Cygwin (or more correctly, the MSYS2 runtime) uses ANSI sequences...
>
> Hopefully he (or another of the Git for Windows contributors) can add
> more specifics.
>
> Thanks,
> Kevin
>
> [^6]: https://github.com/git-for-windows/git/issues/3177#issuecomment-828507812
> [^7]: https://github.com/git-for-windows/git/issues/3177#issuecomment-826834976
>

  reply	other threads:[~2021-05-05 13:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 14:25 Kevin Locke
2021-04-30 14:53 ` Takashi Yano
2021-04-30 15:02   ` Kevin Locke
2021-05-05 13:07     ` Johannes Schindelin [this message]
2021-05-06  9:12       ` Takashi Yano
2021-05-06  9:15         ` Takashi Yano
2021-04-30 16:40   ` Brian Inglis
2021-04-30 17:11     ` Takashi Yano
2021-04-30 18:00   ` Jack Adrian Zappa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2105051500410.50@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=cygwin@cygwin.com \
    --cc=kevin@kevinlocke.name \
    --cc=takashi.yano@nifty.ne.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).