Struct LimitedBody 

struct LimitedBody {
    buf: Vec<u8>,
    newlines: usize,
    needed_lines: usize,
}

Accumulates response chunks until enough lines are received or MAX_BODY_BYTES is exceeded.

Fields

buf: Vec<u8>

newlines: usize

needed_lines: usize

Implementations

impl LimitedBody

fn new(needed_lines: usize) -> Self

fn is_complete(&self) -> bool

Whether enough lines have been received to build the code block.

fn push(&mut self, chunk: &[u8]) -> Result<(), GitHubExpandError>

Appends the part of chunk that is still needed, up to MAX_BODY_BYTES.

fn finish(self) -> String

Decodes the accumulated bytes.

Why not decode per chunk: a multi-byte sequence can straddle a chunk boundary, so decoding happens once over the joined bytes.

Why encoding_rs rather than String::from_utf8_lossy: this is the decode the replaced Response::text performed, so BOM sniffing keeps its behaviour — the BOM is dropped instead of showing up as an invisible U+FEFF, and a UTF-16 BOM selects UTF-16 instead of decoding to mojibake.

A UTF-16 body only survives being read in full: Self::push counts lines in raw bytes, so stopping at the 0A of a UTF-16LE \n (0A 00) leaves the final code unit incomplete. Counting lines in decoded text instead would mean decoding incrementally, which is not worth it for how rare such files are.

Why not read the Content-Type charset like Response::text does: the header is gone by the time chunks are joined. raw.githubusercontent.com serves charset=utf-8, which is also what text assumes when the charset is absent.