Text FIELD NOTES · 4 MIN READ
Find & Replace, Line Sorting, and Joining Text
Three edits that turn notes into lists: literal vs regex replacement with a count of what changed, why 10 sorts before 9, and how separators define the output.
Three edits turn a pile of messy notes into something usable: replace the wrong strings, sort what remains, and join the lines into one list. Each is a one-line operation in principle, and each hides a small amount of genuine computer science — how matching works, why 10 sorts before 9, and what a separator is really doing.
Find and replace: literal first
Plain find-and-replace is a substring operation: find every occurrence of an exact string, swap in the replacement, and report how many swaps happened. The count matters — it is your proof of what the tool touched. Replace cat with dog case-insensitively in cat, CAT, cat and the tool reports three replacements and dog, dog, dog; with case sensitivity on, the answer is one replacement and dog, CAT, cat. The Find and Replace Text tool shows both knobs: case sensitivity and whether the replacement applies globally or only to the first match. A literal mode also means the find string is treated as plain text — a search for C:\path or 3 * 4 matches those exact characters, with no surprises.
When literal is not enough: regex mode
Some replacements are patterns, not strings: "every run of spaces", "any four-digit year", "the semicolons with optional padding around them". Regex mode exists for these. A pattern like \s*;\s* matches a semicolon plus any whitespace hugging it, so replacing it with | normalizes ragged a ; b into a | b in one pass. The tradeoff is that regex metacharacters — . ^ $ * + ? ( ) [ ] { } | \ — now mean something else, which is exactly why the literal mode exists as the default. The full syntax is a subject of its own; How Regular Expressions Work walks it from \d to greedy quantifiers.
Sorting lines: alphabetical, with one sharp edge
Sorting a list of lines is a comparison sort, and the details live in the comparison. Line sorting is case-insensitive by default, so banana\nApple\ncherry sorts to Apple\nbanana\ncherry — capital letters do not jump to the front as they would in a raw character-code sort. Descending order flips the comparison, and a trim option lets each line shed its padding before the comparison so an indented zebra lands where it belongs.
The sharp edge is numbers. A line sorter compares text, and text comparison is lexicographic — character by character, left to right:
input: 9\n10\n100\n2
sorted: 10\n100\n2\n9
That is correct string order: 10 starts with 1, which sorts before 2, so every 10-something precedes every 2-something. It is not numeric order, and no option makes it so, because the tool's contract is lines, not values. If a list must sort numerically, zero-pad it first (009, 010, 100) — padding restores agreement between the two orders.
Joining: the separator is the data model
Joining collapses a stack of lines into a single string with a delimiter between items: one\ntwo\nthree becomes one, two, three. The separator choice is quietly a data-model decision — , makes a sentence-like list, | makes a table row, \n reflows lines back into lines, and an empty separator concatenates. The Text Joiner splits on lines or on words, trims each item, drops empty items automatically, and offers a dedupe pass so the joined output never contains the same item twice. That trim-and-drop behavior is worth noticing: it means the joiner assumes input lines are items, not prose, so feeding it a paragraph and splitting on lines mostly re-creates the paragraph — which is sometimes exactly what you want.
The full pass, in order
Chained, the three operations are a small data pipeline. Take a scribbled list of tool names with duplicated entries and stray semicolons: first a find-and-replace normalizes the delimiters (\s*;\s* → newline, or a cleanup of stray characters), then the Text Cleanup Pipeline trims and dedupes, then the Line Sorter alphabetizes, and finally the joiner produces the one-line comma list for pasting into an email or a config file. Doing the steps in that order is not fussiness — each stage assumes its input is already clean, and the pipeline only produces trustworthy output if it is.
Try it yourself
Start in the Find and Replace Text tool: replace a word both case-sensitively and case-insensitively and compare the replacement counts, then flip to regex mode and try \s+>\s+ style patterns. Sort the same small list in the Line Sorter with numbers mixed in to meet the lexicographic edge for yourself. Finish in the Text Joiner: join with a comma, then with | , then turn on dedupe and watch a duplicated line vanish from the output.