Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From 8c9c920325fa10440a96736ba58ec647a0365e22 Mon Sep 17 00:00:00 2001
|From: "Avi Halachmi (:avih)" <avihpit@yahoo.com>
|Date: Sat, 18 Apr 2020 13:56:11 +0300
|Subject: [PATCH] application-sync: support Synchronized-Updates
|
|See https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec
|
|In a nutshell: allow an application to suspend drawing until it has
|completed some output - so that the terminal will not flicker/tear by
|rendering partial content. If the end-of-suspension sequence doesn't
|arrive, the terminal bails out after a timeout (default: 200 ms).
|
|The feature is supported and pioneered by iTerm2. There are probably
|very few other terminals or applications which support this feature
|currently.
|
|One notable application which does support it is tmux (master as of
|2020-04-18) - where cursor flicker is completely avoided when a pane
|has new content. E.g. run in one pane: `while :; do cat x.c; done'
|while the cursor is at another pane.
|
|The terminfo string `Sync' added to `st.info' is also a tmux extension
|which tmux detects automatically when `st.info` is installed.
|
|Notes:
|
|- Draw-suspension begins on BSU sequence (Begin-Synchronized-Update),
|  and ends on ESU sequence (End-Synchronized-Update).
|
|- BSU, ESU are "\033P=1s\033\\", "\033P=2s\033\\" respectively (DCS).
|
|- SU doesn't support nesting - BSU begins or extends, ESU always ends.
|
|- ESU without BSU is ignored.
|
|- BSU after BSU extends (resets the timeout), so an application could
|  send BSU in a loop and keep drawing suspended - exactly like it can
|  not-draw anything in a loop. But as soon as it exits/aborted then
|  drawing is resumed according to the timeout even without ESU.
|
|- This implementation focuses on ESU and doesn't really care about BSU
|  in the sense that it tries hard to draw exactly once ESU arrives (if
|  it's not too soon after the last draw - according to minlatency),
|  and doesn't try to draw the content just up-to BSU. These two sides
|  complement eachother - not-drawing on BSU increases the chance that
|  ESU is not too soon after the last draw. This approach was chosen
|  because the application's main focus is that ESU indicates to the
|  terminal that the content is now ready - and that's when we try to
|  draw.
|---
| config.def.h |  6 ++++++
| st.c         | 48 ++++++++++++++++++++++++++++++++++++++++++++++--
| st.info      |  1 +
| x.c          | 22 +++++++++++++++++++---
| 4 files changed, 72 insertions(+), 5 deletions(-)
|
|diff --git a/config.def.h b/config.def.h
|index 6f05dce..80d768e 100644
|--- a/config.def.h
|+++ b/config.def.h
--------------------------
Patching file config.def.h using Plan A...
Hunk #1 succeeded at 56.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/st.c b/st.c
|index 76b7e0d..0582e77 100644
|--- a/st.c
|+++ b/st.c
--------------------------
Patching file st.c using Plan A...
Hunk #1 succeeded at 231.
Hunk #2 succeeded at 845.
Hunk #3 succeeded at 856.
Hunk #4 succeeded at 864.
Hunk #5 succeeded at 1024.
Hunk #6 succeeded at 1926.
Hunk #7 succeeded at 2473.
Hunk #8 succeeded at 2486.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/st.info b/st.info
|index 8201ad6..b32b446 100644
|--- a/st.info
|+++ b/st.info
--------------------------
Patching file st.info using Plan A...
Hunk #1 succeeded at 191.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/x.c b/x.c
|index 210f184..27ff4e2 100644
|--- a/x.c
|+++ b/x.c
--------------------------
Patching file x.c using Plan A...
Hunk #1 succeeded at 1861.
Hunk #2 succeeded at 1898.
Hunk #3 succeeded at 1912.
Hunk #4 succeeded at 1937.
Hunk #5 succeeded at 1948.
Hmm...  Ignoring the trailing garbage.
done