CLS removing lines from screen buffer

[MGibs]

I'm not sure if this is WAD, but it's definitely different behavior than what happens with TCMD 35.

Created this simple script to demonstrate the issue.

@echo off

DO i = 1 TO %1
   echo Line Number %i
enddo

When I execute this script passing in 10 as a parameter, it writes 10 lines to the screen.
Then if I execute a CLS command, it clears the screen, and there are no lines left in the scroll back buffer.

When I execute this script passing in 35 as a parameter, it writes 35 lines to the screen.
Then if I execute a CLS command, it clears the screen, but the scroll back buffer now only retains the first 4 lines written. The rest are gone.

Depending on your screen size, different parameters passed in might generate different results.

This happens in both ConHost and ConPTY consoles running under TCMD 36. It does not do this in TCMD 35.

Is that the expected behavior?

From TCMD 35 I'm used to all the previously displayed lines staying in the scroll back buffer, at least until the max buffer size is reached.

 

[vefatica]

I see something different. Here, with v36, CLS (no options) acts just like CLS /S, scrolling to clean viewport with everything in the scrollback.

 

[MGibs]

I checked. I'm really not making this up. See attached

 

[Jay Sage]

I thought I knew what was going on here, but things are really quite different. In a non-ConPTY session in version 36 and in previous versions, CLS is acting as though the /S option is present, namely, the buffer is being scrolled. Using the /S option doesn't seem to make any difference. I thought that maybe I had aliased CLS to "CLS /S", but I didn't. And I just looked for an option to make /S the default, but I didn't find one.

In a ConPTY session, the minute I start typing a new command, the screen scrolls so that the prompt is at the top of the screen. Aha, that is not happening with a new TCC session. However, once I have executed CLS once, it's as if the command is being repeated every time I start to type. Once there is new material in the buffer, it stops happening, until I issue another CLS.

The new console has certainly introduced a lot of anomalies!

 

[vefatica]

That's what it's supposed to do, clear what in the viewport (period!). Whatever was there is gone forever (I don't know about line 4 in your video). CLS /S will scroll to a clear screen; CLS /C will clear everything.

Jay, mine also acts like CLS /S with ConPty (as below).

As I said, I see something different (sorry no video). Before CLS.

After CLS and scroll back.

 

[vefatica]

Are we all on build 23?

 

[Jay Sage]

After I issue CLS, I can scroll back and see everything that was there before. Nothing has been removed from the buffer. It really is as if the /S option is present. When I run which cls, it tells me that it is an internal command, not an alias. cls /c does delete the entire buffer contents.

I was doing this in TCMD, but I didn't see anything different in a standalone TCC.

Vince, is there someplace where I could have set a default behavior for CLS?

 

[Jay Sage]

Yes, I'm on build 23. (And still hoping for a fix that will make the tabbed toolbar buttons that use %_selected work with ConPTY consoles.)

I have "Unicode output" unchecked. Maybe that makes a difference. The help says:

A CLS with no arguments when ANSI is enabled will now use ANSI escape sequences to clear the screen and home the cursor.​

Perhaps this arises because of the ANSI support in ConPTY consoles that has changed from previous versions..

 

[vefatica]

I'm also in TCMD36.

Vince, is there someplace where I could have set a default behavior for CLS?

Not that I know of.

 

[rconn]

For a ConPTY session, a CLS does the same as a CLS /S. There are some reasons for it:

1. That's the way Windows Terminal does it.
2. That's the way ANSI clear-screen sequences expect it.
3. A ConPTY session has no console buffer, or rather the console buffer is exactly the size of the screen. The buffer is created & handled in the host session (i.e., TCMD, WT, or whatever).
4. There's no discernible advantage to not doing that. If you really want to wipe out everything on the display & scrollback buffer, use /C.

 

[MGibs]

For a ConPTY session, a CLS does the same as a CLS /S. There are some reasons for it:

1. That's the way Windows Terminal does it.
2. That's the way ANSI clear-screen sequences expect it.
3. A ConPTY session has no console buffer, or rather the console buffer is exactly the size of the screen. The buffer is created & handled in the host session (i.e., TCMD, WT, or whatever).
4. There's no discernible advantage to not doing that. If you really want to wipe out everything on the display & scrollback buffer, use

Ok, I think I solved the mystery. When I recorded the video I had "ANSI colors" unchecked in the TCC Options (Windows tab).

When I checked it, and re-ran my test I'm now getting the same results as everyone else, where CLS works like CLS /S.

Rex - is what happened to me (losing rows from the screen buffer) supposed to be what happens when ANSI colors is not selected?

 

[rconn]

Rex - is what happened to me (losing rows from the screen buffer) supposed to be what happens when ANSI colors is not selected?

If ANSI is not active, then TCC reverts to the old behavior (a CLS wipes the current viewport).