Done Unix-like clear screen keystroke command.

[mfarah]

On Unix shells, ^L clears the screen. In TCC, this can be emulated with a Q&D alias like this:

@@^L=cls

... except it misses one thing: on Unix shells, whatever the command line had contained it's preserved and the user can keep editing it. Here, instead, the cls command is added to whatever the user had written in the first place, executing that command with an added "cls" as an (obviously wrong) argument. I'd like to have a keystroke command that duplicates the way the Unix shells clear the screen with ^L (which I'll then map to... ^L).

 

[vefatica]

I just stumbled on this thread. Was this really done? What's the keystroke?

 

[mfarah]

I'd certainly like to know, too!

 

[Charles Dye]

Would this be of interest? EditKeys Plugin

 

[vefatica]

I didn't try EditKeys but I wouldn't be surprised if the console APIs failed to do this properly in WindowsTerminal. This (below) works in a console and in WT (both having 42 rows here) to reposition the prompt at the top (second line, actually). It would be easy enough to code in a keyhandler. I suppose that, in a console, EditKeys just leaves the current command line intact and moves the window within the console screen buffer (yes/no?). I think that, in WT, you'd have to rewrite a command-line-in-progress; maybe not ... I'll experiment.

do i=1 to 41 (echo.) & echos ^e[1;1H

FWIW, both the console and WT have the "SU" control sequence (ScrollUp, ESC[<n>S) but it doesn't work correctly. The issue is about 3 years old so I doubt it'll be fixed any time soon.

 

[Charles Dye]

I didn't try EditKeys but I wouldn't be surprised if the console APIs failed to do this properly in WindowsTerminal. This (below) works in a console and in WT (both having 42 rows here) to reposition the prompt at the top (second line, actually). It would be easy enough to code in a keyhandler. I suppose that, in a console, EditKeys just leaves the current command line intact and moves the window within the console screen buffer (yes/no?). I think that, in WT, you'd have to rewrite a command-line-in-progress; maybe not ... I'll experiment.

do i=1 to 41 (echo.) & echos ^e[1;1H

FWIW, both the console and WT have the "SU" control sequence (ScrollUp, ESC[<n>S) but it doesn't work correctly. The issue is about 3 years old so I doubt it'll be fixed any time soon.

Yes, and yes. I scroll the screen if at all possible. And yes, Windows Terminal is less than perfectly compatible with the Console API.

 

[vefatica]

Windows Terminal is less than perfectly compatible with the Console API.

Yup, if you're used to thinking of a screen buffer of known and fixed size and a window that shows parts of it, you're not going to get very far in many endeavors. However, I do like using control sequences. This (below) works in WT (and fails miserably in a console). It handles in-progress and long command lines and being at the limit for the number of lines. Beyond that I haven't thought of how it might fail. "con" is an instance of a "CON" struct which wraps up a few useful things.

    // scroll so cmd-line-in-progress is at the top
    else if ( lstrcmp(lpki->pszKey, L"Alt-L") == 0 )        // Ctrl-L is taken
    {
        INT nRowOffset = lpki->nRow - lpki->nHomeRow;        // multiple-row cmd-line-in-progress?
        con.GetInfo();                                        // refresh csbi and CONOUT$ handle
        con.Emit_n(L"\x1b[?25l", 6);                        // to CONOUT$; cursor off (avoid any ugliness)
    
        // force scrolling until at the top
        for ( INT i = 0; i < con.csbi.dwSize.Y - 1 - nRowOffset; i++ )
        {
            con.Emit_n(L"\n", 1);
        }

        WCHAR seq[16];

        // cursor to first row and on; nRow/nColumn are 0-based; control sequences are 1-based
        len = wsprintfW(seq, L"\x1b[1;%dH\x1b[?25h", lpki->nColumn + 1);
        con.Emit_n(seq, len);

        // tell TCC about the move; 0-based vs. 1-based as above; nColumn doesn't change
        lpki->nHomeRow = 0;
        lpki->nRow = nRowOffset;
    }