ScrPut always moves the cursor to the end of the written string

[MGibs]

It's behaving as if the /U parameter is present, even when it is not

This code

cls & scrput 10 10 bright white on black Hello & echo There

Looks like this in TCMD35

and like this in TCMD36

 

[rconn]

SCRPUT used to write directly to the screen using a console API. Because of a bug in Windows Terminal + ConPTY, this was changed in v36 to write via an ANSI sequence in a helper function. The helper function did not reset the cursor, because 99.999% of the time when that write routine was called the user either didn't care where the cursor was, or they wanted it to follow the text output.

I have made a change for the next build in SCRPUT to check for /C or /U, and if neither are specified then SCRPUT will save the current cursor position and restore it after calling the output helper function.

 

[MGibs]

I would agree with you that in most cases I don't care where the cursor is or I want it to follow the text. But I did have a specific case where I wanted it to return to its original position. But working around that situation using a SCREEN command to reposition the cursor is also trivial.

I just brought it up since it changed and the behavior didn't match the docs. I know you loathe breaking changes, but in this case I wouldn't complain if you left it alone and updated the docs to define the new default behavior.

 

[vefatica]

In WindowsTerminal (and probably TCMD and a modern console) you can save the cursor position with ECHOS ^e[s and restore it with ECHOS ^e[u. I've read ^e7 and ^e8 do the same (resp.) but I've never tried them.