Repository: microsoft/terminal
File: src/terminal/parser/stateMachine.cpp (C++)

Code before:
            ProcessCharacter(til::at(string, i));
            ++i;
        } while (i < string.size() && _state != VTStates::Ground);
    }

    // If we're at the end of the string and have remaining un-printed characters,
    if (_state != VTStates::Ground)
    {
        const auto run = _CurrentRun();

        // One of the "weird things" in VT input is the case of something like
        // <kbd>alt+[</kbd>. In VT, that's encoded as `\x1b[`. However, that's
        // also the start of a CSI, and could be the start of a longer sequence,
        // there's no way to know for sure. For an <kbd>alt+[</kbd> keypress,
        // the parser originally would just sit in the `CsiEntry` state after
        // processing it, which would pollute the following keypress (e.g.
        // <kbd>alt+[</kbd>, <kbd>A</kbd> would be processed like `\x1b[A`,
        // which is _wrong_).
        //
        // At the same time, input may be broken up arbitrarily, depending on the pipe's
        // buffer size, our read-buffer size, the sender's write-buffer size, and more.
        // In fact, with the current WSL, input is broken up in 16 byte chunks (Why? :(),
        // which breaks up many of our longer sequences, like our Win32InputMode ones.
        //
        // As a heuristic, this code specifically checks for a trailing Esc or Alt+key.
        // If we encountered a win32-input-mode sequence before, we know that our\x1b[?9001h
        // request to enable them was successful. While a client may still send \x1b{some char}
        // intentionally, it's far more likely now that we're looking at a broken up sequence.
        // The most common win32-input-mode is ConPTY itself after all, and we never emit
        // \x1b{some char} once it's enabled.
        if (_isEngineForInput)
        {
            const auto engine = static_cast<InputStateMachineEngine*>(_engine.get());
            const auto win32 = engine->EncounteredWin32InputModeSequence();
            if (!win32 && run.size() <= 2 && run.front() == L'\x1b')
            {
                _EnterGround();
                if (run.size() == 1)
                {
                    _ActionExecute(L'\x1b');
                }
                else
                {
                    _EnterEscape();
                    _ActionEscDispatch(run.back());
                }
                _EnterGround();
            }
        }
        else if (_state != VTStates::SosPmApcString && _state != VTStates::DcsPassThrough && _state != VTStates::DcsIgnore)
        {

Review comment (suggestion):
```suggestion
        // If we encountered a win32-input-mode sequence before, we know that our \x1b[?9001h
```

Code after:
            ++i;
        } while (i < string.size() && _state != VTStates::Ground);
    }

    // If we're at the end of the string and have remaining un-printed characters,
    if (_state != VTStates::Ground)
    {
        const auto run = _CurrentRun();

        // One of the "weird things" in VT input is the case of something like
        // <kbd>alt+[</kbd>. In VT, that's encoded as `\x1b[`. However, that's
        // also the start of a CSI, and could be the start of a longer sequence,
        // there's no way to know for sure. For an <kbd>alt+[</kbd> keypress,
        // the parser originally would just sit in the `CsiEntry` state after
        // processing it, which would pollute the following keypress (e.g.
        // <kbd>alt+[</kbd>, <kbd>A</kbd> would be processed like `\x1b[A`,
        // which is _wrong_).
        //
        // At the same time, input may be broken up arbitrarily, depending on the pipe's
        // buffer size, our read-buffer size, the sender's write-buffer size, and more.
        // In fact, with the current WSL, input is broken up in 16 byte chunks (Why? :(),
        // which breaks up many of our longer sequences, like our Win32InputMode ones.
        //
        // As a heuristic, this code specifically checks for a trailing Esc or Alt+key.
        // If we encountered a win32-input-mode sequence before, we know that our \x1b[?9001h
        // request to enable them was successful. While a client may still send \x1b{some char}
        // intentionally, it's far more likely now that we're looking at a broken up sequence.
        // The most common win32-input-mode is ConPTY itself after all, and we never emit
        // \x1b{some char} once it's enabled.
        if (_isEngineForInput)
        {
            const auto win32 = _engine->EncounteredWin32InputModeSequence();
            if (!win32 && run.size() <= 2 && run.front() == L'\x1b')
            {
                _EnterGround();
                if (run.size() == 1)
                {
                    _ActionExecute(L'\x1b');
                }
                else
                {
                    _EnterEscape();
                    _ActionEscDispatch(run.back());
                }
                _EnterGround();
            }
        }
        else if (_state != VTStates::SosPmApcString && _state != VTStates::DcsPassThrough && _state != VTStates::DcsIgnore)
        {
            // If the engine doesn't require flushing at the end of the string, we
            // want to cache the partial sequence in case we have to flush the whole