Prevent flickering in nushell due to FTCS marks

src/host/screenInfo.cpp

@@ -2323,7 +2323,10 @@ void SCREEN_INFORMATION::SetTerminalConnection(_In_ VtEngine* const pTtyConnecti
     if (pTtyConnection)
     {
         engine.SetTerminalConnection(pTtyConnection,
-                                     std::bind(&StateMachine::FlushToTerminal, _stateMachine.get()));
+                                     [&stateMachine = *_stateMachine]() -> bool {
+                                         ServiceLocator::LocateGlobals().pRender->NotifyPaintFrame();
+                                         return stateMachine.FlushToTerminal();
+                                     });
     }
     else
     {

src/renderer/vt/XtermEngine.cpp

@@ -526,18 +526,17 @@ CATCH_RETURN();
     RETURN_IF_FAILED(_fUseAsciiOnly ?
                          VtEngine::_WriteTerminalAscii(wstr) :
                          VtEngine::_WriteTerminalUtf8(wstr));
-    // GH#4106, GH#2011 - WriteTerminalW is only ever called by the
+    // GH#4106, GH#2011, GH#13710 - WriteTerminalW is only ever called by the
     // StateMachine, when we've encountered a string we don't understand. When
-    // this happens, we usually don't actually trigger another frame, but we
-    // _do_ want this string to immediately be sent to the terminal. Since we
-    // only flush our buffer on actual frames, this means that strings we've
-    // decided to pass through would have gotten buffered here until the next
-    // actual frame is triggered.
-    //
-    // To fix this, flush here, so this string is sent to the connected terminal
-    // application.
+    // this happens, we will trigger a new frame in the renderer, and
+    // immediately buffer this wstr (representing the sequence we didn't
+    // understand). We won't immediately _Flush to the terminal - that might
+    // cause flickering (where we've buffered some state but not the whole
+    // "frame" as specified by the app). We'll just immediately buffer this
+    // sequence, and flush it when the render thread comes around to paint the
+    // frame normally.
 
-    return _Flush();
+    return S_OK;
 }
 
 // Method Description:

src/renderer/vt/invalidate.cpp

@@ -120,6 +120,10 @@ CATCH_RETURN();
         _circled = circled;
     }
 
+    // If we flushed for any reason other than circling (i.e, a sequence that we
+    // didn't understand), we don't need to push the buffer out on EndPaint.
+    _noFlushOnEnd = !circled;
+
     _trace.TraceTriggerCircling(*pForcePaint);
 
     return S_OK;

src/renderer/vt/paint.cpp

@@ -94,7 +94,21 @@ using namespace Microsoft::Console::Types;
         RETURN_IF_FAILED(_MoveCursor(_deferredCursorPos));
     }
 
-    RETURN_IF_FAILED(_Flush());
+    // If this frame was triggered because we encountered a VT sequence which
+    // required the buffered state to get printed, we don't want to flush this
+    // frame to the pipe. That might result in us rendering half the output of a
+    // particular frame (as emitted by the client).
+    //
+    // Instead, we'll leave this frame in _buffer, and just keep appending to
+    // it as needed.
+    if (_noFlushOnEnd) [[unlikely]]
+    {
+        _noFlushOnEnd = false;
+    }
+    else
+    {
+        RETURN_IF_FAILED(_Flush());
+    }
 
     return S_OK;
 }

src/renderer/vt/vtrenderer.hpp

@@ -139,6 +139,7 @@ namespace Microsoft::Console::Render
 
         bool _resizeQuirk{ false };
         bool _passthrough{ false };
+        bool _noFlushOnEnd{ false };
         std::optional<TextColor> _newBottomLineBG{ std::nullopt };
 
         [[nodiscard]] HRESULT _WriteFill(const size_t n, const char c) noexcept;