Text.Truncate

Summary#

Text.Truncate(s, maxLength) returns s unchanged when it already fits, and otherwise shortens it to at most maxLength characters, ellipsis included, backing off to the last word boundary so a word is never cut in half.

Signature#

Text.Truncate(<string> s, <int> maxLength) -> string

Description#

The length bound includes the ellipsis (…, a single character). That is the point of the method: the usual reason to truncate is that you are spending a budget — a token budget in a prompt, a column width in a table — and a helper that can overshoot its own limit forces the caller to measure the result again.

Behaviour at the edges, each of which a hand-rolled version tends to get wrong:

• A single long word has no boundary to back off to, so it is cut hard: Text.Truncate("supercalifragilistic", 10) is "supercali…", not "".
• A leading space does not empty the string — the back-off only applies to a boundary found past the start.
• maxLength of 1 leaves room for the ellipsis alone; 0 or less returns an empty string rather than faulting.

Trailing whitespace is trimmed before the ellipsis is appended, so you never get "the quick …".

Text.Truncate runs in memory — call it on locals inside a function body, not inside a query predicate.

Examples#

string Excerpt(string body, int budget) {
  return Text.Truncate(body, budget);
}
// Excerpt("the quick brown fox jumps", 12)  ->  "the quick…"   (10 chars — inside the budget)
// Excerpt("hello", 20)                      ->  "hello"        (already fits, untouched)

Because the result is bounded, a budget loop can trust it:

var line = "- " + Text.Truncate(item.Content, 200) + "\n";
var cost = Text.Length(line) / 4;
if (used + cost > budget) { break; }

See also#

• Text.LastIndexOf — the backward search Text.Truncate is built on; reach for it directly only when you need the index itself rather than a shortened string
• String interpolation & format specifiers — building the strings you are truncating